From nobody Mon Jul 5 08:32:44 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5F85811E2F22 for ; Mon, 5 Jul 2021 08:32:47 +0000 (UTC) (envelope-from michael.osipov@siemens.com) Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com [194.138.20.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail-eagle.siemens.com", Issuer "Siemens Issuing CA Intranet Server 2017" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GJJpk36MLz4ZVn for ; Mon, 5 Jul 2021 08:32:46 +0000 (UTC) (envelope-from michael.osipov@siemens.com) Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle2.siemens.com (Postfix) with ESMTPS id B94E8468181 for ; Mon, 5 Jul 2021 10:32:44 +0200 (CEST) Received: from DEMCHDC89YA.ad011.siemens.net (demchdc89ya.ad011.siemens.net [139.25.226.104]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id A6B281A56D35F for ; Mon, 5 Jul 2021 10:32:44 +0200 (CEST) Received: from DEMCHDC8A2A.ad011.siemens.net (139.25.226.108) by DEMCHDC89YA.ad011.siemens.net (139.25.226.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Mon, 5 Jul 2021 10:32:44 +0200 Received: from DEMCHDC8A2A.ad011.siemens.net ([139.25.226.108]) by DEMCHDC8A2A.ad011.siemens.net ([139.25.226.108]) with mapi id 15.01.2176.014; Mon, 5 Jul 2021 10:32:44 +0200 From: "Osipov, Michael" To: "freebsd-ports@FreeBSD.org" Subject: Commit Bug 252564 - devel/nexus2-oss Thread-Topic: Commit Bug 252564 - devel/nexus2-oss Thread-Index: AddxeBxHpMX7UKr8R2+JiJutOxnWzA== Date: Mon, 5 Jul 2021 08:32:44 +0000 Message-ID: <34ff6bdb7b2e426ea87d05eb7e1f89b0@siemens.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-07-05T08:32:42Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=43dec7a5-9a6e-4a08-8327-47e72d7a94db; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [139.21.146.184] x-tm-as-product-ver: SMEX-14.0.0.3080-8.6.1018-26260.006 x-tm-as-result: No-10--11.106200-8.000000 x-tmase-matchedrid: B8hCuJB8uD4XfmJvMkpJAZW2sEHNJAAn7xTEU85S9ZZ+J3gtIe0gA35L mbb/xUualLc3nRzXiU2eAiCmPx4NwHJnzNw42kCx2bNx1HEv7HAqtq5d3cxkNZd/mwLf2BVUlq1 MkvkDXXtv5JkeoIhmD9NW6sNEo1hkzFEoxsSF6mawFMlIPaIBbQ== x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No x-tmase-result: 10--11.106200-8.000000 x-tmase-version: SMEX-14.0.0.3080-8.6.1018-26260.006 x-tm-snts-smtp: 8526A63C9110750F4C9792F8451F94D40FBD76201BDC3164F0B0F4E429A8DFCD2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4GJJpk36MLz4ZVn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=siemens.com; spf=pass (mx1.freebsd.org: domain of michael.osipov@siemens.com designates 194.138.20.69 as permitted sender) smtp.mailfrom=michael.osipov@siemens.com X-Spamd-Result: default: False [-2.90 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+exists:194.138.20.69.spf.siemens.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.97)[-0.970]; NEURAL_HAM_SHORT(-0.73)[-0.730]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[siemens.com,none]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:198573, ipnet:194.138.20.0/23, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports]; RCVD_IN_DNSWL_HI(-0.50)[194.138.20.69:from] X-ThisMailContainsUnwantedMimeParts: N Rm9sa3MsDQoNCmNhbiBzb21lb25lIGtpbmRseSBhcHBseSBteSBwYXRjaCBmb3IgdGhpcyBwb3J0 PyBJIGFtIHRoZSBwb3J0IG1haW50YWluZXIuDQoNClRoYW5rcw0K From nobody Mon Jul 5 08:34:13 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E3D3B11E3E81 for ; Mon, 5 Jul 2021 08:34:15 +0000 (UTC) (envelope-from michael.osipov@siemens.com) Received: from gw-eagle1.siemens.com (gw-eagle1.siemens.com [194.138.20.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail-eagle.siemens.com", Issuer "Siemens Issuing CA Intranet Server 2017" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GJJrR2smYz4bPr for ; Mon, 5 Jul 2021 08:34:15 +0000 (UTC) (envelope-from michael.osipov@siemens.com) Received: from mail3.dc4ca.siemens.de (mail3.dc4ca.siemens.de [139.23.14.198]) by gw-eagle1.siemens.com (Postfix) with ESMTPS id AF0454F01CC for ; Mon, 5 Jul 2021 10:34:13 +0200 (CEST) Received: from DEMCHDC8A1A.ad011.siemens.net (sop-solman.siemens.com [139.25.226.107]) by mail3.dc4ca.siemens.de (Postfix) with ESMTPS id AB51A2AC64B3 for ; Mon, 5 Jul 2021 10:34:13 +0200 (CEST) Received: from DEMCHDC8A2A.ad011.siemens.net (139.25.226.108) by DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Mon, 5 Jul 2021 10:34:13 +0200 Received: from DEMCHDC8A2A.ad011.siemens.net ([139.25.226.108]) by DEMCHDC8A2A.ad011.siemens.net ([139.25.226.108]) with mapi id 15.01.2176.014; Mon, 5 Jul 2021 10:34:13 +0200 From: "Osipov, Michael" To: "freebsd-ports@FreeBSD.org" Subject: Commit Bug 255949 - devel/websvn: update to 2.6.1 Thread-Topic: Commit Bug 255949 - devel/websvn: update to 2.6.1 Thread-Index: AddxeHgKSBt0vqySRji+7uvaaAllUA== Date: Mon, 5 Jul 2021 08:34:13 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-07-05T08:34:12Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=24f92ed5-f547-461a-8fb6-efdca0a19492; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [139.21.146.184] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4GJJrR2smYz4bPr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=siemens.com; spf=pass (mx1.freebsd.org: domain of michael.osipov@siemens.com designates 194.138.20.72 as permitted sender) smtp.mailfrom=michael.osipov@siemens.com X-Spamd-Result: default: False [-2.91 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+exists:194.138.20.72.spf.siemens.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.138.20.72:from]; NEURAL_HAM_MEDIUM(-0.96)[-0.958]; NEURAL_HAM_SHORT(-0.76)[-0.755]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[siemens.com,none]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:198573, ipnet:194.138.20.0/23, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports]; RCVD_IN_DNSWL_HI(-0.50)[194.138.20.72:from] X-ThisMailContainsUnwantedMimeParts: N Rm9sa3MsDQoNCmNhbiBzb21lb25lIGtpbmRseSBhcHBseSBteSBwYXRjaCBmb3IgdGhpcyBwb3J0 PyBJIGFtIHRoZSBwb3J0IG1haW50YWluZXIuDQoNCkl0IGNvbnRhaW5zIGEgZml4IGZvciBDVkUt MjAyMS0zMjMwNS4NCg0KVGhhbmtzDQo= From nobody Mon Jul 5 09:01:08 2021 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8A8B411E61E6 for ; Mon, 5 Jul 2021 09:01:08 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GJKRS3TSRz4dhy for ; Mon, 5 Jul 2021 09:01:08 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5E9602311F for ; Mon, 5 Jul 2021 09:01:08 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.15.2/8.15.2) with ESMTP id 165918JF065827 for ; Mon, 5 Jul 2021 09:01:08 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.15.2/8.15.2/Submit) id 165918s4065822; Mon, 5 Jul 2021 09:01:08 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202107050901.165918s4065822@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Mon, 5 Jul 2021 09:01:08 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-ThisMailContainsUnwantedMimeParts: N Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ games/exult | 1.7.0.20210603 | snapshot-v1.7.0.20210705 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Mon Jul 5 11:55:39 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B043411FF16D for ; Mon, 5 Jul 2021 11:55:18 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GJPJP6VcLz4vR2; Mon, 5 Jul 2021 11:55:17 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-ed1-x529.google.com with SMTP id h2so23410074edt.3; Mon, 05 Jul 2021 04:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=Vz0HXCffPYXZcwjgXSL8V/hZVGSw3vkCI/X1AJIeIMI=; b=rzRVG3m/xeWoEzT/XtKL1Vuc78GsGIiXoK7XIyIKzscl9YnsoObDAyUlh940/A4MHI 9mn+c2BjIsHJBwXxTAsn5ZnejpdLyxzZRl5+EfJeFEI6mg6ZHldUtmKVDVS14utuwRt8 Ycr37cdmtuVRk68mRbnddrYnHfs1PQ3ylBFlrjBVSNCkDHh+fOEgY+bZW8LM1btg4msy QbgjvMRXTiJnWxd1zMVLicy+bXIcUrUUwHdugNxP+GO7tHBM6wLK3tYQ+GFMwR/4TN1j w0rohdfl3qNS7VJBnMYOErBVQQzWHSB+NfssrJ/hfFbjmHbP465bShAlbAy3QuytPXtX tkEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=Vz0HXCffPYXZcwjgXSL8V/hZVGSw3vkCI/X1AJIeIMI=; b=K+tPgygYQGbNSRBVGlPlc1LUMAm/cwHrQXDIFTyybStVnxzqmoLbvb1nd+Sn6xh/JO 31mxyaTKnCvlEElcn3UUd6nYEeZ9Ge+Que8jeQNtiPZlbKIJ8HfHg9hmkI173XObFc52 lRMyfRelOXUgsDqxnhOTzL/EYna3VjFzLH25GUVkkdD9MmOcxL9kwt5Ny5X5PlvLLkrb qJZuZMN5GEwo3jxbzoU781JnPCY3WkamHoT08ql9PDBoncvJ+ASAKihIpK9vxaRQB/xQ N9cm9bQUAFnLMvS7N7CdZ1qmt3k8oBtcpo+EjWnGA3KKeqlwEawerdIh9CW/63u+U0Ia 5hZA== X-Gm-Message-State: AOAM533RQKWIFOTLz7W3c7RWnMlnNQoQLoNLBZmEsxYP52r/bgVJaWm9 0tBl77oywLFyF/2Aw5DWbJ45HTbYqeo= X-Google-Smtp-Source: ABdhPJymIMIeJttw9AmTW6wLubSFmCF/CB1G9Q5+4bPIec7z5+tLi4ks2JXDs16PDUWfVCf/3jv7Ug== X-Received: by 2002:a05:6402:40c3:: with SMTP id z3mr15175736edb.375.1625486115215; Mon, 05 Jul 2021 04:55:15 -0700 (PDT) Received: from laptop.domain ([86.57.155.118]) by smtp.gmail.com with ESMTPSA id a5sm188987edj.20.2021.07.05.04.55.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jul 2021 04:55:14 -0700 (PDT) Date: Mon, 5 Jul 2021 14:55:39 +0300 From: "Sergey V. Dyatko" To: Cc: lbartoletti@FreeBSD.org Subject: Missing MOVED entry Message-ID: <20210705145539.1b53cfed@laptop.domain> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GJPJP6VcLz4vR2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=rzRVG3m/; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sergeydyatko@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=sergeydyatko@gmail.com X-Spamd-Result: default: False [-2.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::529:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.92)[0.921]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::529:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports] X-ThisMailContainsUnwantedMimeParts: N Hi, FYI: misc/qtchooser was removed in commit be86c4fe23e089aeef1ed7467161c2ce321a8c81 but there is no line in MOVED file Possible I'm wrong but I thought that it was necessary to drop a note in this file -- wbr, Sergey From nobody Mon Jul 5 15:33:39 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3D37511DCAF5 for ; Mon, 5 Jul 2021 15:33:43 +0000 (UTC) (envelope-from lbartoletti@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GJV8R1Lhtz4YKV; Mon, 5 Jul 2021 15:33:43 +0000 (UTC) (envelope-from lbartoletti@FreeBSD.org) Received: from iMac-de-Loic.local (unknown [IPv6:2a01:e34:ef45:d440:6d65:71cb:f09b:c54f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: lbartoletti) by smtp.freebsd.org (Postfix) with ESMTPSA id 8D3902C964; Mon, 5 Jul 2021 15:33:42 +0000 (UTC) (envelope-from lbartoletti@FreeBSD.org) Subject: Re: Missing MOVED entry To: "Sergey V. Dyatko" , freebsd-ports@freebsd.org References: <20210705145539.1b53cfed@laptop.domain> From: =?UTF-8?Q?Lo=c3=afc_Bartoletti?= Message-ID: <17354542-a47e-20b3-6bc4-c3dc2a7243e1@FreeBSD.org> Date: Mon, 5 Jul 2021 17:33:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 In-Reply-To: <20210705145539.1b53cfed@laptop.domain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-ThisMailContainsUnwantedMimeParts: N Hi, Yes, I forgot to push it with git. The entry has been added in feb5a1f6a6b682ff2ec9f67c592931fbaf347282 Thanks to amdmi3@ Loïc Le 05/07/2021 à 13:55, Sergey V. Dyatko a écrit : > Hi, > > FYI: > misc/qtchooser was removed in commit be86c4fe23e089aeef1ed7467161c2ce321a8c81 > but there is no line in MOVED file > > Possible I'm wrong but I thought that it was necessary to drop a note in > this file > > -- > wbr, Sergey > From nobody Tue Jul 6 22:32:45 2021 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6A2DD11D744E for ; Tue, 6 Jul 2021 22:32:55 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKHPf3mMpz3PHw for ; Tue, 6 Jul 2021 22:32:54 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.16.1/8.16.1) with ESMTPS id 166MWjpI007871 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 7 Jul 2021 00:32:45 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 166MWjLA007870 for ports@freebsd.org; Wed, 7 Jul 2021 00:32:45 +0200 (CEST) (envelope-from fuz) Date: Wed, 7 Jul 2021 00:32:45 +0200 From: Robert Clausecker To: ports@freebsd.org Subject: Supply difficult to build assets as an extra distfile? Message-ID: List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4GKHPf3mMpz3PHw X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su X-Spamd-Result: default: False [0.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:41d0:8:e508::1:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.82)[0.818]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2001:41d0:8:e508::1:from:127.0.2.255]; DMARC_NA(0.00)[fuz.su]; NEURAL_HAM_LONG(-0.22)[-0.219]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[ports]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Greetings! As requested on reddit [1], I would like to make a port for WriteFreely [2], a "publishing platform for writers." While the project itself is an easily ported Go program, it requires assets to be generated using a Node.js tool as a part of the build. [3] Unfortunately that means having to wrangle with NPM to get the code generated in a fixed version and that seems very hard. Would it be acceptable to generate these assets on my machine and roll them into a distfile so the port can be built without involving any NPM shenanigans? I would add a makefile target to generate said distfile so committers can audit that the distfile has been generated correctly. Please let me know how to proceed here. Yours, Robert Clausecker [1]: https://www.reddit.com/r/freebsd/comments/o7px9b/-/h31pg0w/ [2]: https://github.com/writefreely/writefreely [3]: https://writefreely.org/docs/latest/developer/setup -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Wed Jul 7 09:44:55 2021 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C36C71221D18 for ; Wed, 7 Jul 2021 09:45:20 +0000 (UTC) (envelope-from steve@mouf.net) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKZKX4Z5rz4SVk for ; Wed, 7 Jul 2021 09:45:20 +0000 (UTC) (envelope-from steve@mouf.net) Received: from lrrr.mouf.net (2603-6080-7702-bf01-24ad-58bb-f157-8fb2.res6.spectrum.com [IPv6:2603:6080:7702:bf01:24ad:58bb:f157:8fb2]) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id 1679j1hA045369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 7 Jul 2021 09:45:07 GMT (envelope-from steve@mouf.net) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mouf.net; s=mail; t=1625651113; bh=OAqWgxYo43RU21K/WMpOH99qi4VAc/sk7wLdWftHwbU=; h=Subject:To:References:From:Date:In-Reply-To; b=TNMRgqKJgc4hklQNcXQ45bqyFLdPNhFiCPF3kK1UUjW+wJhikDYExGmTiBiRYLw4X pqtPmyntEqRaJc+sFXnl5vWynNOwBlHoEsA9wS94Wl7vbkNbCtwXlkRmQczmJZf0xT qxaYu3NAUUYQ/q7HW0q5MogD6etUVsHN4lIBxcSE= Subject: Re: Supply difficult to build assets as an extra distfile? To: Robert Clausecker , ports@freebsd.org References: From: Steve Wills Message-ID: <63f4cba8-1e5b-6ae2-3d15-d8a8b76cdd30@mouf.net> Date: Wed, 7 Jul 2021 05:44:55 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]); Wed, 07 Jul 2021 09:45:08 +0000 (UTC) X-Spam-Status: No, score=0.3 required=4.5 tests=KHOP_HELO_FCRDNS,NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 4GKZKX4Z5rz4SVk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, On 7/6/21 6:32 PM, Robert Clausecker wrote: > Greetings! > > As requested on reddit [1], I would like to make a port for WriteFreely [2], > a "publishing platform for writers." While the project itself is an easily > ported Go program, it requires assets to be generated using a Node.js tool > as a part of the build. [3] Unfortunately that means having to wrangle with NPM > to get the code generated in a fixed version and that seems very hard. > > Would it be acceptable to generate these assets on my machine and roll them > into a distfile so the port can be built without involving any NPM shenanigans? > I would add a makefile target to generate said distfile so committers can > audit that the distfile has been generated correctly. I think that's fine, I do something similar with security/vault. Cheers, Steve From nobody Wed Jul 7 12:17:39 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D434F8D6FF3; Wed, 7 Jul 2021 12:17:48 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.41.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKdjR5tgBz4pWw; Wed, 7 Jul 2021 12:17:47 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300Fb4F0558010938f8309A8230D1.dip0.t-ipconnect.de [IPv6:2003:fb:4f05:5801:938:f830:9a82:30d1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 4GKdjJ1hrGzh1X; Wed, 7 Jul 2021 14:17:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625660260; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=tAISFw/mN9MIcEZNVA3CPuTvgXYg5P6g8Hic53xw09o=; b=sNGkRoQKFanDeX0ubuJr7N6PHHVZ/lIGGBmXSCVzhKozbc6e8Z3Cd8BGE/898RcwNoG1cu saiuQO1zCiZuwvzCJg/zqDmzsneAXkXrApN/SzQBNV0vwc3LHtGEOsetV5oBnwU7CG/aFb Iwpa618NTc7R6G2nP2A2cB6H04Yni6RcdT/yk09C7O+9/7aeDbJnt4/OA4XqxKEEgxQD9m j96s4xugMlN7fh/WFwCBEjIpEKDNvK1BkUFcpcxv4/43s5wsMBnLKuGdq1uclkMVTKmoyf WqtEaTrC/RfVXfbn7uNMQWk0CpDwynEF9LlhfMhQ9RkvGOR1F45hcCdudOzF+g== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: security/rkhunter without hashes after recent STABLE-13 update Message-Id: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> Date: Wed, 7 Jul 2021 14:17:39 +0200 Cc: lukasz@wasikowski.net To: FreeBSD-STABLE Mailing List , FreeBSD ports X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GKdjR5tgBz4pWw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ellael.org header.s=dkim header.b=sNGkRoQK; dmarc=pass (policy=quarantine) header.from=ellael.org; spf=pass (mx1.freebsd.org: domain of trashcan@ellael.org designates 91.121.41.56 as permitted sender) smtp.mailfrom=trashcan@ellael.org X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[ellael.org:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.41.56]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; SPAMHAUS_ZRD(0.00)[91.121.41.56:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ellael.org:+]; DMARC_POLICY_ALLOW(-0.50)[ellael.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[91.121.41.56:from]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports,freebsd-stable]; RCVD_COUNT_TWO(0.00)[2] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: N Hi, I noticed that after my last upgrade to stable/13-n246157 (from = stable/13-n246147) that /usr/local/var/lib/rkhunter/db/rkhunter.dat = started lacking hashes. Regarding rkhunter.conf the default setting is: HASH_CMD=3DSHA256 and: If just the command name is given, and it is one of MD5,=20 SHA1, SHA224, SHA256, SHA384 or SHA512, then rkhunter will first = look for the=20 relevant command, such as 'sha256sum', and then for 'sha256'. If I do modify the setting to ... HASH_CMD=3D/sbin/sha256 =E2=80=A6 rkhunter.dat shows hashes again. Ok, that can be fixed.=20 But I wonder if my findings have something to do with security/rkhunter = at all, because that port didn't change recently.=20 Can someone point me into the right direction, how to find out if the = output of /sbin/sha256sum changes between stable/13-n246147 and = stable/13-n246157? Regards, Michael= From nobody Wed Jul 7 15:25:50 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8B31411D8577; Wed, 7 Jul 2021 15:26:07 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [135.125.211.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKjtl2nF4z3k25; Wed, 7 Jul 2021 15:26:07 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300Fb4F0558010938f8309A8230D1.dip0.t-ipconnect.de [IPv6:2003:fb:4f05:5801:938:f830:9a82:30d1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4GKjtZ53ZvzVC; Wed, 7 Jul 2021 17:25:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625671559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s9QNjfIUNuoTMxDyJmkrr41Z4ACt60UWHW+Q1kuEKbE=; b=vC3JuTr806vatpRtdQ1LNvdNi0LVf9ORBblDZVXhMzeN6XvbRbcdo1sSl7xGfjgeu6RuMo Q6l6coQSexd/pkbaQ7FPz+/ez1i/3/zCJjYMqksQ318GVeO+dkNnhlNzurGKRXqbNJQjfa b3UNjrgwZ+CFNxjLGOIzvZ2M9/sLxuJ7u4WROyUZA5mBHGWMcwnihEyUhHaSdaWfD1P8SQ GQ2V2yfmqcK491V0IwQtkEv7+XK2W1+g+xHGU71buMzcXAEh3R10TKuMZG4oiXSqpDf9vv m4Qth6n5mdiyRjMy9pgWHdtl7yjaGfXFPBSU6FFJREHf2ENSA4linCA4cHa9NA== Content-Type: text/plain; charset=utf-8 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: security/rkhunter without hashes after recent STABLE-13 update In-Reply-To: Date: Wed, 7 Jul 2021 17:25:50 +0200 Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser Content-Transfer-Encoding: quoted-printable Message-Id: References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> To: Warner Losh X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GKjtl2nF4z3k25 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: >=20 > On Wed, Jul 7, 2021 at 6:19 AM Michael Grimm via freebsd-stable = wrote: >> Can someone point me into the right direction, how to find out if the >> output of /sbin/sha256sum changes between stable/13-n246147 and >> stable/13-n246157? >=20 > This is likely an incompletely merged set of changes to md5, et al. I > recently added the 'sum' variations, but > did so from an incomplete description so I got the output format wrong = in a > couple of cases. se@ went in and > fixed that, and added a lot of compat tests to make sure they weren't > further regressions. >=20 > b33d1898c1b0 is the latest fix, from Jun 29th in -current and merged = to > stable/13 Jul 6th. It's at n246188 so a little too late unless you = have a > slight kernel mismatch with your userland/jail. I didn' tsee any = changes > between n246147 or n146157 that would do this, though. What's the hash = that > you have at n246157? I think it should be fd5b08977630. No, it's stable/13-n246157-fd5b0897763 I will give a n246188+ user land a try, and ... > So the change is expected, but if the change to all the *sum programs = is > incompatible still, I know I'd like to know (as I'm sure se@ would as > well). All the *sum programs are very new and designed to be 100% > compatible with the linux versions and if they aren't that needs to be > fixed. =E2=80=A6 I will report back. Regards, Michael =20= From nobody Wed Jul 7 16:10:45 2021 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7EBB711E00EC for ; Wed, 7 Jul 2021 16:10:55 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (mailserver.netfence.it [78.134.96.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mailserver.netfence.it", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKktQ04G6z3rDg for ; Wed, 7 Jul 2021 16:10:53 +0000 (UTC) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18]) (authenticated bits=0) by soth.netfence.it (8.16.1/8.16.1) with ESMTPSA id 167GAjSq053210 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 7 Jul 2021 18:10:45 +0200 (CEST) (envelope-from ml@netfence.it) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netfence.it; s=202105; t=1625674245; bh=5qNtcixtKBHz0mW7NX3gS6F7Jz9+F+rJ6cPHtSMht+0=; h=To:From:Subject:Date; b=BCDImfRqN8QmLdumgKgO8rUUWhgcBRXTpvKhQ3uMmjrrOt0Fj3QhSclkZw9DGvBaQ /2qiVTLaSjqV5FoAhkqt+67MhH4IZXtbsRa9+z8lz2vT3yR2Pai1tL7r52J+LJKgDR xF9Kk50WYNzUqHwmy3ChZh2lhCUuPFf3Q5Xwozj8= X-Authentication-Warning: soth.netfence.it: Host alamar.local.netfence.it [10.1.2.18] claimed to be alamar.ventu To: ports@freebsd.org From: Andrea Venturoli Subject: Cannot fetch net/geoipupdate in poudriere Message-ID: Date: Wed, 7 Jul 2021 18:10:45 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GKktQ04G6z3rDg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netfence.it header.s=202105 header.b=BCDImfRq; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 78.134.96.152 as permitted sender) smtp.mailfrom=ml@netfence.it X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[netfence.it:s=202105]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:78.134.96.152]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[78.134.96.152:from:127.0.2.255]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; DKIM_TRACE(0.00)[netfence.it:+]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; NEURAL_HAM_SHORT(-0.50)[-0.498]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[78.134.96.152:from]; ASN(0.00)[asn:35612, ipnet:78.134.0.0/17, country:IT]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[ports] X-ThisMailContainsUnwantedMimeParts: N Hello. I'm trying to build all my ports after the switch to 2021Q3. I've got a problem with net/geoipupdate, which fails the fetch stage (full log follows). Strangely "cd /usr/ports/net/geoipupdate/ ; make fetch" on the same machine works. Any hint? bye & Thanks av. ------------------ =>> Building net/geoipupdate build started at Wed Jul 7 18:07:29 CEST 2021 port directory: /usr/ports/net/geoipupdate package name: geoipupdate-4.7.1 building for: FreeBSD 122amd64-default-job-01 12.2-RELEASE FreeBSD 12.2-RELEASE 1202000 amd64 maintained by: adamw@FreeBSD.org Makefile ident: Poudriere version: 3.3.6 Host OSVERSION: 1202000 Jail OSVERSION: 1202000 Job Id: 01 ---Begin Environment--- SHELL=/bin/csh OSVERSION=1202000 UNAME_v=FreeBSD 12.2-RELEASE 1202000 UNAME_r=12.2-RELEASE BLOCKSIZE=K MAIL=/var/mail/root STATUS=1 HOME=/root PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin LOCALBASE=/usr/local USER=root LIBEXECPREFIX=/usr/local/libexec/poudriere POUDRIERE_VERSION=3.3.6 MASTERMNT=/usr/home/poudriere/data/.m/122amd64-default/ref FTP_PROXY=http://proxy1.ventu:8080/ HTTPS_PROXY=http://proxy1.ventu:8080/ POUDRIERE_BUILD_TYPE=bulk PACKAGE_BUILDING=yes SAVED_TERM=screen PWD=/usr/home/poudriere/data/.m/122amd64-default/ref/.p/pool P_PORTS_FEATURES=FLAVORS SELECTED_OPTIONS MASTERNAME=122amd64-default HTTP_PROXY=http://proxy1.ventu:8080/ SCRIPTPREFIX=/usr/local/share/poudriere OLDPWD=/usr/home/poudriere/data/.m/122amd64-default/ref/.p SCRIPTPATH=/usr/local/share/poudriere/bulk.sh POUDRIEREPATH=/usr/local/bin/poudriere ---End Environment--- ---Begin Poudriere Port Flags/Env--- PORT_FLAGS= PKGENV= FLAVOR= DEPENDS_ARGS= MAKE_ARGS= ---End Poudriere Port Flags/Env--- ---Begin OPTIONS List--- ===> The following configuration options are available for geoipupdate-4.7.1: DOCS=off: Build and/or install documentation MANPAGES=off: Build and/or install manual pages ===> Use 'make config' to modify these settings ---End OPTIONS List--- --MAINTAINER-- adamw@FreeBSD.org --End MAINTAINER-- --CONFIGURE_ARGS-- --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- MAKE=gmake XDG_DATA_HOME=/wrkdirs/usr/ports/net/geoipupdate/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/net/geoipupdate/work HOME=/wrkdirs/usr/ports/net/geoipupdate/work TMPDIR="/tmp" PATH=/wrkdirs/usr/ports/net/geoipupdate/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin SHELL=/bin/sh CONFIG_SHELL=/bin/sh --End CONFIGURE_ENV-- --MAKE_ENV-- CGO_ENABLED=1 CGO_CFLAGS="-I/usr/local/include" CGO_LDFLAGS="-L/usr/local/lib" GOARM= GOPATH="/distfiles/go/net_geoipupdate" GOBIN="/wrkdirs/usr/ports/net/geoipupdate/work/bin" GO111MODULE=on GOFLAGS=-modcacherw GOSUMDB=sum.golang.org CONFFILE=/usr/local/etc/GeoIP.conf DATADIR=/usr/local/share/GeoIP VERSION=v4.7.1 XDG_DATA_HOME=/wrkdirs/usr/ports/net/geoipupdate/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/net/geoipupdate/work HOME=/wrkdirs/usr/ports/net/geoipupdate/work TMPDIR="/tmp" PATH=/wrkdirs/usr/ports/net/geoipupdate/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local CC="cc" CFLAGS="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " CPP="cpp" CPPFLAGS="" LDFLAGS=" -fstack-protector-strong " LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" --End MAKE_ENV-- --PLIST_SUB-- PORTDOCS="@comment " OSREL=12.2 PREFIX=%D LOCALBASE=/usr/local RESETPREFIX=/usr/local LIB32DIR=lib DOCSDIR="share/doc/geoipupdate" EXAMPLESDIR="share/examples/geoipupdate" DATADIR="share/geoipupdate" WWWDIR="www/geoipupdate" ETCDIR="etc/geoipupdate" --End PLIST_SUB-- --SUB_LIST-- PREFIX=/usr/local LOCALBASE=/usr/local DATADIR=/usr/local/share/geoipupdate DOCSDIR=/usr/local/share/doc/geoipupdate EXAMPLESDIR=/usr/local/share/examples/geoipupdate WWWDIR=/usr/local/www/geoipupdate ETCDIR=/usr/local/etc/geoipupdate --End SUB_LIST-- ---Begin make.conf--- USE_PACKAGE_DEPENDS=yes BATCH=yes WRKDIRPREFIX=/wrkdirs PORTSDIR=/usr/ports PACKAGES=/packages DISTDIR=/distfiles FORCE_PACKAGE=yes PACKAGE_BUILDING=yes PACKAGE_BUILDING_FLAVORS=yes #### /usr/local/etc/poudriere.d/make.conf #### JAVA_PREFERRED_PORTS=JAVA_PORT_NATIVE_OPENJDK_JDK_1_8 DISABLE_LICENSES=yes WITH_DEBUG_PORTS+=ports-mgmt/pkg #WITH_DEBUG_PORTS+=sysutils/xfce4-settings WITH_DEBUG_PORTS+=x11/pixman WITH_DEBUG_PORTS+=x11-drivers/xf86-video-ati-legacy WITH_DEBUG_PORTS+=x11-servers/xorg-server CLAMAVUSER=mailnull WITH_CCACHE_BUILD=yes CCACHE_DIR=/root/.ccache #### /usr/ports/Mk/Scripts/ports_env.sh #### _CCVERSION_921dbbb2=FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2) Target: x86_64-unknown-freebsd12.2 Thread model: posix InstalledDir: /usr/bin _ALTCCVERSION_921dbbb2=none _CXXINTERNAL_acaad9ca=FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2) Target: x86_64-unknown-freebsd12.2 Thread model: posix InstalledDir: /usr/bin "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "--hash-style=both" "--enable-new-dtags" "-o" "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "/dev/null" "-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" CC_OUTPUT_921dbbb2_58173849=yes CC_OUTPUT_921dbbb2_9bdba57c=yes CC_OUTPUT_921dbbb2_6a4fe7f5=yes CC_OUTPUT_921dbbb2_6bcac02b=yes CC_OUTPUT_921dbbb2_67d20829=yes CC_OUTPUT_921dbbb2_bfa62e83=yes CC_OUTPUT_921dbbb2_f0b4d593=yes CC_OUTPUT_921dbbb2_308abb44=yes CC_OUTPUT_921dbbb2_f00456e5=yes CC_OUTPUT_921dbbb2_65ad290d=yes CC_OUTPUT_921dbbb2_f2776b26=yes CC_OUTPUT_921dbbb2_b2657cc3=yes CC_OUTPUT_921dbbb2_380987f7=yes CC_OUTPUT_921dbbb2_160933ec=yes CC_OUTPUT_921dbbb2_fb62803b=yes _OBJC_CCVERSION_921dbbb2=FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2) Target: x86_64-unknown-freebsd12.2 Thread model: posix InstalledDir: /usr/bin _OBJC_ALTCCVERSION_921dbbb2=none ARCH=amd64 OPSYS=FreeBSD _OSRELEASE=12.2-RELEASE OSREL=12.2 OSVERSION=1202000 PYTHONBASE=/usr/local HAVE_COMPAT_IA32_KERN=YES _SMP_CPUS=8 CONFIGURE_MAX_CMD_LEN=524288 HAVE_PORTS_ENV=1 #### Misc Poudriere #### GID=0 UID=0 DISABLE_MAKE_JOBS=poudriere ---End make.conf--- --Resource limits-- cpu time (seconds, -t) unlimited file size (512-blocks, -f) unlimited data seg size (kbytes, -d) 33554432 stack size (kbytes, -s) 524288 core file size (512-blocks, -c) unlimited max memory size (kbytes, -m) unlimited locked memory (kbytes, -l) unlimited max user processes (-u) 34275 open files (-n) 1024 virtual mem size (kbytes, -v) unlimited swap limit (kbytes, -w) unlimited socket buffer size (bytes, -b) unlimited pseudo-terminals (-p) unlimited kqueues (-k) unlimited umtx shared locks (-o) unlimited --End resource limits-- =================================================== =========================================================================== =================================================== ===> geoipupdate-4.7.1 depends on file: /usr/local/sbin/pkg - not found ===> Installing existing package /packages/All/pkg-1.16.3.txz [122amd64-default-job-01] Installing pkg-1.16.3... [122amd64-default-job-01] Extracting pkg-1.16.3: .......... done ===> geoipupdate-4.7.1 depends on file: /usr/local/sbin/pkg - found ===> Returning to build of geoipupdate-4.7.1 =========================================================================== =================================================== ===> geoipupdate-4.7.1 depends on file: /usr/local/bin/go - not found ===> Installing existing package /packages/All/go-1.16.5,1.txz [122amd64-default-job-01] Installing go-1.16.5,1... [122amd64-default-job-01] Extracting go-1.16.5,1: .......... done ===> geoipupdate-4.7.1 depends on file: /usr/local/bin/go - found ===> Returning to build of geoipupdate-4.7.1 ===> geoipupdate-4.7.1 depends on package: ca_root_nss>0 - not found ===> Installing existing package /packages/All/ca_root_nss-3.63.txz [122amd64-default-job-01] Installing ca_root_nss-3.63... [122amd64-default-job-01] Extracting ca_root_nss-3.63: ... done ===== Message from ca_root_nss-3.63: -- FreeBSD does not, and can not warrant that the certification authorities whose certificates are included in this package have in any way been audited for trustworthiness or RFC 3647 compliance. Assessment and verification of trust is the complete responsibility of the system administrator. This package installs symlinks to support root certificates discovery by default for software that uses OpenSSL. This enables SSL Certificate Verification by client software without manual intervention. If you prefer to do this manually, replace the following symlinks with either an empty file or your site-local certificate bundle. * /etc/ssl/cert.pem * /usr/local/etc/ssl/cert.pem * /usr/local/openssl/cert.pem ===> geoipupdate-4.7.1 depends on package: ca_root_nss>0 - found ===> Returning to build of geoipupdate-4.7.1 =========================================================================== =================================================== ===> Fetching all distfiles required by geoipupdate-4.7.1 for building ===> Fetching github.com/maxmind/geoipupdate/v4 dependencies # get https://proxy.golang.org/golang.org/x/sys/@v/v0.0.0-20201026173827-119d4633e4d1.mod # get https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod # get https://proxy.golang.org/github.com/kr/text/@v/v0.2.0.mod # get https://proxy.golang.org/github.com/spf13/pflag/@v/v1.0.5.mod # get https://proxy.golang.org/github.com/gofrs/flock/@v/v0.8.0.mod # get https://proxy.golang.org/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.mod # get https://proxy.golang.org/gopkg.in/check.v1/@v/v1.0.0-20200902074654-038fdea0a05b.mod # get https://proxy.golang.org/github.com/stretchr/testify/@v/v1.7.0.mod # get https://proxy.golang.org/gopkg.in/yaml.v3/@v/v3.0.0-20200615113413-eeeca48fe776.mod # get https://proxy.golang.org/github.com/pkg/errors/@v/v0.9.1.mod # get https://proxy.golang.org/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.mod: Get "https://proxy.golang.org/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.mod": x509: certificate signed by unknown authority # get https://proxy.golang.org/gopkg.in/check.v1/@v/v1.0.0-20200902074654-038fdea0a05b.mod: Get "https://proxy.golang.org/gopkg.in/check.v1/@v/v1.0.0-20200902074654-038fdea0a05b.mod": x509: certificate signed by unknown authority # get https://proxy.golang.org/gopkg.in/yaml.v3/@v/v3.0.0-20200615113413-eeeca48fe776.mod: Get "https://proxy.golang.org/gopkg.in/yaml.v3/@v/v3.0.0-20200615113413-eeeca48fe776.mod": x509: certificate signed by unknown authority # get https://proxy.golang.org/github.com/stretchr/testify/@v/v1.7.0.mod: Get "https://proxy.golang.org/github.com/stretchr/testify/@v/v1.7.0.mod": x509: certificate signed by unknown authority # get https://proxy.golang.org/golang.org/x/sys/@v/v0.0.0-20201026173827-119d4633e4d1.mod: Get "https://proxy.golang.org/golang.org/x/sys/@v/v0.0.0-20201026173827-119d4633e4d1.mod": x509: certificate signed by unknown authority # get https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod: Get "https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod": x509: certificate signed by unknown authority # get https://proxy.golang.org/github.com/kr/text/@v/v0.2.0.mod: Get "https://proxy.golang.org/github.com/kr/text/@v/v0.2.0.mod": x509: certificate signed by unknown authority # get https://proxy.golang.org/github.com/gofrs/flock/@v/v0.8.0.mod: Get "https://proxy.golang.org/github.com/gofrs/flock/@v/v0.8.0.mod": x509: certificate signed by unknown authority # get https://proxy.golang.org/github.com/spf13/pflag/@v/v1.0.5.mod: Get "https://proxy.golang.org/github.com/spf13/pflag/@v/v1.0.5.mod": x509: certificate signed by unknown authority # get https://proxy.golang.org/github.com/pkg/errors/@v/v0.9.1.mod: Get "https://proxy.golang.org/github.com/pkg/errors/@v/v0.9.1.mod": x509: certificate signed by unknown authority go: github.com/davecgh/go-spew@v1.1.1: Get "https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod": x509: certificate signed by unknown authority *** Error code 1 Stop. make: stopped in /usr/ports/net/geoipupdate =>> Cleaning up wrkdir ===> Cleaning for geoipupdate-4.7.1 build of net/geoipupdate | geoipupdate-4.7.1 ended at Wed Jul 7 18:07:35 CEST 2021 build time: 00:00:06 !!! build failure encountered !!! From nobody Wed Jul 7 18:47:36 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3FC231226266; Wed, 7 Jul 2021 18:47:46 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [IPv6:2001:41d0:701:1000::1685]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKpMQ0XpRz4jH0; Wed, 7 Jul 2021 18:47:45 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300fb4f0558010938F8309a8230D1.dip0.t-ipconnect.de [IPv6:2003:fb:4f05:5801:938:f830:9a82:30d1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4GKpMF4DCRzfR; Wed, 7 Jul 2021 20:47:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625683657; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zgKVcjthq8dFr1kuYQ22kGOTlEpCJZeYixvGiyzH6SY=; b=YYejBfHy8xLk49coqWSYJ5599YLAMkKeB4K/B1Wt8uPR5Bkcz747BqxNRLpvwqEMNNb889 uZfL/hWMp9q0KAVpmfF1099w73+kUnE4MGVCAyQfsJ+qIT5ppI+HBNI6z8EMBf6fOFqGTe yHCAPVOCLjRa4vDUZAt/JEdPZofGdyZQFZzMZxseZBNL7dBAeE2MHOi/iH42OEImsd9RKd NiUBXbUZFrqqi98/2EpJJ1kkzOUBWnDhjf+oba2sTG7uTnUxyPXbAbqj96fjCb1vrPXWpG jEGGogAW4aGfPeNqPWwBmHbgT4PYsNrvZq6YorvHaAz8SYmi08IHSDOzhIrJ0A== Content-Type: text/plain; charset=utf-8 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: security/rkhunter without hashes after recent STABLE-13 update In-Reply-To: Date: Wed, 7 Jul 2021 20:47:36 +0200 Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser Content-Transfer-Encoding: quoted-printable Message-Id: <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> To: Warner Losh X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GKpMQ0XpRz4jH0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > On Wed, Jul 7, 2021 at 9:26 AM Michael Grimm = wrote: >> Warner Losh wrote: >>> What's the hash that you have at n246157? I think it should be = fd5b08977630. >>=20 >> No, it's stable/13-n246157-fd5b0897763 >>=20 >> I will give a n246188+ user land a try, and ... >=20 > Great. Please do let me know... I started this for compatibility so I > didn't have > to keep hacking simple scripts for FreeBSD and if something is screwed = up > that means it's falling short of the goal... >=20 >>> So the change is expected, but if the change to all the *sum = programs is >>> incompatible still, I know I'd like to know (as I'm sure se@ would = as >>> well). All the *sum programs are very new and designed to be 100% >>> compatible with the linux versions and if they aren't that needs to = be >>> fixed. >>=20 >> =E2=80=A6 I will report back. >=20 > Excellent! I am running stable/13-n246205-9e06b34bb5d, now.=20 But I do have to report that rkhunter is still lacking to calculate = hashes when using sha256sum instead of sha256. In a previous mail you wrote: "I recently added the 'sum' variations".=20= Does that mean that sha256sum (et al.) didn't exist before? That could = explain why rkhunter didn't fail before. Example output: KBN> sha256 crontab.mike=20 SHA256 (test.dat) =3D = 829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9 KBN> sha256sum test.dat 829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9 = test.dat If I am not mistaken does rkhunter cut that output string into relevant = junks. In both cases the hash is at different positions, though ... > Sorry for any hassle this work is causing. No big deal for rkhunter, a workaround exists ;-) Regards, Michael From nobody Wed Jul 7 20:24:09 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9CDE611E2FA9; Wed, 7 Jul 2021 20:24:13 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [135.125.211.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKrVj2Rggz3Bvq; Wed, 7 Jul 2021 20:24:12 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300fb4f0558010938F8309a8230D1.dip0.t-ipconnect.de [IPv6:2003:fb:4f05:5801:938:f830:9a82:30d1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4GKrVd4XLnz1DJ; Wed, 7 Jul 2021 22:24:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625689449; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=txTHjwjF1PUp8Egjf9oMd0Lhs2ezEr2SOEGQPFTkoAQ=; b=w9I1dn6Vkj41GFv4xCxL3bK22o+ZkT6ZO3np2bYUrLbi9bQ9gzUj7hf1QtGlZMP4u4dRqe o0yvj1LCxvTz+DAtEsurvsxyMVVHJCeSHGSWoSmdeTREBwixG0/j8cjVFfVxyPyOYhG2s0 c6hTb7XlIvt2u5ULOrFUIp81unnI0S4Q7B+nqsHHBwlMAehWkttPoMv7hWQjDmHZZqpimJ NWhu2G0VuVNbgAFU621/iUjUfZ+3CiREIvuQDLiBdAWf00NsVHpdqPqXF6yT95nPVlfVCf G03GJSKoLPOxi2RY7n52MxT7xnRaa7XGDwGCnXRUGYrZbMLEmKvbDZyyvJDOnQ== Message-Id: <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> Content-Type: multipart/mixed; boundary="Apple-Mail=_D505DE2F-C582-4001-BDE4-19F198707C1B" List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: security/rkhunter without hashes after recent STABLE-13 update Date: Wed, 7 Jul 2021 22:24:09 +0200 In-Reply-To: Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser To: Warner Losh References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GKrVj2Rggz3Bvq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_D505DE2F-C582-4001-BDE4-19F198707C1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Warner Losh wrote: >=20 > On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm = wrote: >> Warner Losh wrote: >>> Sorry for any hassle this work is causing. >>=20 >> No big deal for rkhunter, a workaround exists ;-) >=20 > I think the reason is that it automatically switched to using = sha256sum > because it was present, but it didn't automatically change = #HASH_FLD_IDX=3D4 > to be 1. The shell script is tricky enough that I've not looked = through it > all. I'd argue this is a bug in the get_sha_hash_function which = doesn't > adjust the HASH_FLD_IDX based on which version it finds. Instead, it = sets > it unconditionally to 4 on *BSD or DragonFly. >=20 > Warner >=20 > P.S. I think it needs something like the following updated > patch-files_rkhunter and/or changes upstream. I don't know what this = port > does, apart from what I've just read. Can you see if this fixes this? Your rkhunter script seems to be different to mine =E2=80=A6 MWN> patch < rkhunter.diff=20 Hmm... Looks like a unified diff to me=E2=80=A6 The text leading up to this was: =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 |--- files/rkhunter.orig 2018-02-24 16:08:27.000000000 = -0700 |+++ files/rkhunter 2021-07-07 13:38:56.094378000 -0600 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Patching file rkhunter using Plan A=E2=80=A6 Hunk #1 succeeded at 4751. Hunk #2 failed at 7525. Hunk #3 succeeded at 19734 (offset 3 lines). Hunk #4 failed at 19810. 2 out of 4 hunks failed--saving rejects to rkhunter.rej done But anyway, you nailed it! That fixes rkhunter. It will now produce = hashes for both /sbin/sha256 and /sbin/sha256sum. The attached patch (diff to new rkhunter script with both succeeding = hunks) will work for the rkhunter-1.4.6 script. Thanks and with kind regards, Michael --Apple-Mail=_D505DE2F-C582-4001-BDE4-19F198707C1B-- From nobody Wed Jul 7 21:53:20 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0E7971223068 for ; Wed, 7 Jul 2021 21:53:26 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKtTc6wl3z3kqG for ; Wed, 7 Jul 2021 21:53:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 167LrLwW061238 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 7 Jul 2021 14:53:21 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 167LrKsu061237; Wed, 7 Jul 2021 14:53:20 -0700 (PDT) (envelope-from fbsd) Date: Wed, 7 Jul 2021 14:53:20 -0700 From: bob prohaska To: freebsd-ports@freebsd.org Cc: bob prohaska Subject: Too many pythons in poudriere Message-ID: <20210707215320.GA60914@www.zefox.net> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4GKtTc6wl3z3kqG X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-1.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N In trying to compile www/chromium under poudriere on a Pi3 there comes a point when five python2.7 sessions totaling more than 2 GB in size are running at once. Obviously, swap is swamped and the Pi3 is running at a crawl. It hasn't givem up, however. Poudriere was started with -J 2 and make is limited to 2 jobs. Is there an analogous limit to how many pythons are loosed at once? It looks like there's only one builder, so it isn't obvious that -J 1 would help; I'll try it if this job stops prematurely. Progress, such as it is, can be seen at http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-07-05_14h06m26s/build.html The last time www/chromium was compiled (using make) on this machine I don't remember seeing such a python jam. If it happened at all the Pi3 worked through it faster than presently. Thanks for reading, bob prohaska From nobody Thu Jul 8 02:04:25 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9823711F2856 for ; Thu, 8 Jul 2021 02:04:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GL03N30Vlz4j8C for ; Thu, 8 Jul 2021 02:04:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625709869; bh=ESxIk9LA3/TkulmtR+k6OhYt3qH9p0mCBx5iAmB7FRE=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=aQ8GbkW2rharZJSJcuCSl9fFZ1l3morJkORzQ/MnjnkIJNg2iKBthPrNy3tWwfIO0rw2qH/jjQ8X0O+iS1czR71sN3ChQPztf5enth8wF/O922t2optVvDpIoReJ4EBrGE+xmLdaVvd6RZWvS9QgvIm2bhfS2snwxdfCffEY9hMthn4QfnQvIexe4uwpuBNun0uEZ2GoV7JO1wwij3A4Zhg9jZz4sgKKX2fvwkzEG0sfdcDEBo3PvoSXk+JGrGf//1ESkr+aO68b0islBLo3jGehw3tfo41socrxxiimxespzHiZNXyb6RKlX/2LI97SguTqgxGd7eMIqqxTVa3zdw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625709869; bh=4i5M887ku+QcKPbm0KyAPQhYHa7iXjP/MvpXtQ/+Vh/=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=j0Qps7eXheGYLUplJEkGsKfQkLma6HqBI9gtf1QEi+juTvuspFYCFIsJSrnprR+/ndppA61uCTo4VEv93imGDPuq0qnjOAPvq7zHhD4sQr44gSMg+sKaFMo6r2ZHrys2k/wxu77XoOwtSdzDlG9PDGDqAm/yv7LthmLtN/jjG7yE6/m0i61SEDBoI2QccQFxLUr8VIqQlhuWWLyOKLjjHlrIbaJjYgP5GG1637MLhQoy5XtR7iM8gJttsvp6qkgrSfwVAKaAvV9dXice9aBLV4t9SuOGPba9RsiDheO2InxK1siv9iXCtv4EOrGu2z4MW5hSaHtx9OTHJv0jzuvbRg== X-YMail-OSG: 5Z3mhuEVM1mUYo14Wc7GGNmdyKMBR.79aXPSWLGT.wZk8_jn56xJn_upjfiCgTz pcooyeotCLMihb22tupHehT8kZQVTu85SecAZmyoH3teD7kTgy2mr1_m67SWOynV.lWoLZ7Ey.c9 YYD7MVw0n1xWPoRivOXMV_D0YXHeXZLvUDQ.fm9E6kLQYeQk3HiEg4XbNrdr8B5wCDB8gos.11.O EaIP8bC.vAVYReElXoDK73HUP56_lb4W4N4na7uT8O8hOlQze_mz4XECTJHN83MtgM8x1Q10nCTk AyCAdzdU.trI_ERL.qTIayS03qkjzGNSi.R_CIyJ0tO8PTnuBmnHC9kLAYCBuf_OLqGPNz7X8WdW Inm3l57S7Xbfeer5D0eEQ50kbVbhvcJ8h34DE69mbYEqeXVJ4GEVYgVJCXp34NEfco9NyG_iKZ5X mZiMMWGptykaN_Al4hR.eRwavNA7GeLja1IS0ngtw4LtZQkZpcn_eifi3MrrZKFuVIzi2y9Un_iF mAWoVPfn1GoHXUSTIGarXZWkKGq16zii_HyF8Tvu.lEqrmoHXC9jbOEdp9rzNCg8AqB52kW0nhs9 zlpKr2d.ctBmgwdMcL8PtXIBXijER4wxGJ0tpkcePlabKCLOyJQQU1iS4ABL4BRIGawYH5VpRmXI qpiFZbdPsZwQKXE83IdtQucpPA3XVadoRhcVDi3BpOzeNxLyVOCRtI2.TNljfnbcSMARL5g_VjHP DcP0s2dlwAYLI5AFYhKAYBJjA5M6U1uekHTArsqovt9jIKlTTacTKpKGqgsu9bM_UeeE.KK837L7 cfDzzW5s9_pJQlEOgPS7Y1Zd8vQZeuI2L3ulSz3yHjNPTPdB6FJ_tYdTUfpmG2e.4xoXuK1GR1mR LDAQ4q9Njc7x00SCnDgukk8DLGhmw.vJUZJhFOpotXiknO3vMGtzG_OqxsoTGRK1My71VUjA8xDL Y_7goGzK.UmGf74I0WvH8OBMpTKII_sX2s.cPcJYCgD9xrfVId1N_v6q6agjfuzXYQDeYL6s_qas 63ociwksLZLbM5SWcqmrQT.WYJv1N4NfGHxu9lApKjVFFIbcuVVfhY9WvRgNt6Z4KwlgVV9g07u0 i0v1q48Usu5nnJDgyeNQsgX361RNvKci5dSSjtUJpUhksappTNVTw_UCqGa9fRX1fji.sZJhZ.OE UcE0xgHB_mb0KDiJ1XVNAi0netsdYG_L.aMbVdvq671CINjs0PX9P2cLK9Ebgip2az0LPOjrn49K mx3LqC0_kiMwlLwxHRHEb9yPFdc7zaPfQVZIA1MvMKyZZjdq4uEuPOzpFZjaVQKcPAa6QmVtSown capnjcHdrlzJT54H7R_2e269asTu3x9j_xG8RJXZyCTC4iUez8HCPk_BpR5Wny96r6wYJ7ANQSXx FZ_8NYSWrxWXlAvyBlIu2E.cZVH5HCgcTzuBLd0dP4R0KeFxW76wGHtrgRO7rm.NR2QWsjTTOBlj Q7AWtIPYe92Oz6vW9uvPzCmz8k8AzTrPYWcHH3eOpG99oeYxGmn0myvoy4MnVr0jqJ62UPxf6uOO F8mEGisDfK4GxO8Pi7i.aVLnSTY6B2b5lVwEb1q9prEWs.15Prz7z65nedcL833s2wKZxLeIf1bV 0U8xqi12mvtGK4176CfoZbS3wIbiGOvmJUFvEIm_8zVuQ4L4tHOloEW9CdO2ThgVJZNZy3.PoSpw WkYTBgoMbr32i8F02EW6y31EPLURLofuRCYD9AFXImQJe5YBentOjNmQld6ddb0e5YZjttMSOjze Wq5QAuKu0d0Nhq2i3aNA7F8k1yRsl7aW8VecIqu8fBdVKiF5MNNFY2t9mhwyiU6fZC6ufOUq6ubr 5d6CIL9FwC3iHTJhay8E2ZAZ1R4Jm2nwQnjtqxSfmjW8Y9WCmrFMJZzI8r8eKe1wdIAUGtt0.N45 dPNmtP_lKXZzrzQqxZAUqmj4ojy2JcPz8uXAARz2SJgOJbokTxY7ENDuHf0OrkCcruXGPdO8qPtw 6hX5K94wYfjW2UzzYgEyGQDOAWqQHKqCZdNU1cgNnGzluhdQpjuwS28Fbu_eXdjgW4iBlEBKnI7a YA.Gm2OSbED167n12WAwTp0RnMbBdLFrEMjl3duFVCilQKqqWjfYRHtjtb1obr7cH6cs88dL9Kgr GR729yvQWuCTarFJUxnQsI.ok.01EYvMW6OFhfG7kvOUrxz2Df81ZH6dlctXuqnwyvcEwVduXC59 gk1oEm6ANUVRmhIU3ieMs_lEIRhC.BmlLjaPVl2nBnUCtX_foUpEvykU83dDvcxZ8R0L9nYXyaTa gmNBy43jhP7hHHbr0cDyQoXOK9zSwat8OlTLpnhR60fdBzh_lazpSMGUGfAqcZ0jiwQuxbHEG0Kz aZma5ToVM2e9KY_vgzMU.v0pkKhfEGmypj4aTVcw015pzZnBw47_278NhDbooEjr6FKnE3Zm8gSG TzZuaem8SM7.FssO3zgIDMVYfglvij9w- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Jul 2021 02:04:29 +0000 Received: by kubenode542.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 63ffb5a6afe926f50819420cfab9f40c; Thu, 08 Jul 2021 02:04:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere Message-Id: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> Date: Wed, 7 Jul 2021 19:04:25 -0700 Cc: freebsd-ports@freebsd.org To: fbsd@www.zefox.net X-Mailer: Apple Mail (2.3654.100.0.2.22) References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C.ref@yahoo.com> X-Rspamd-Queue-Id: 4GL03N30Vlz4j8C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aQ8GbkW2; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.48 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.98)[-0.982]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N From: bob prohaska wrote on Date: Wed, 7 Jul 2021 14:53:20 -0700 : > In trying to compile www/chromium under poudriere on a Pi3 there > comes a point when five python2.7 sessions totaling more than 2 GB > in size are running at once. Obviously, swap is swamped and the Pi3 > is running at a crawl. It hasn't givem up, however. >=20 > Poudriere was started with -J 2 and make is limited to 2 jobs.=20 > Is there an analogous limit to how many pythons are loosed at > once? It looks like there's only one builder, so it isn't > obvious that -J 1 would help; I'll try it if this job stops > prematurely. It will not help. There were no competing build jobs. > Progress, such as it is, can be seen at >=20 > = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-07-05= _14h06m26s/build.html By the time I looked it had run out of swap space: Swapinfo 100.00% and had stopped for build/timeout after 50:33:26 . For reference, including "swap_pager: out of swap space" and "swp_pager_getswapspace(1): failed": QUOTE Wed Jul 7 15:20:34 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1831744 11456 99% /dev/mmcsd0s2b 1843200 1832328 10872 99% Total 3686400 3664072 22328 99% . . . Wed Jul 7 15:20:46 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1838356 4844 100% /dev/mmcsd0s2b 1843200 1838928 4272 100% Total 3686400 3677284 9116 100% . . . Wed Jul 7 15:20:56 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1841260 1940 100% /dev/mmcsd0s2b 1843200 1841836 1364 100% Total 3686400 3683096 3304 100% . . . Wed Jul 7 15:21:08 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1843000 200 100% /dev/mmcsd0s2b 1843200 1843124 76 100% Total 3686400 3686124 276 100% . . . Jul 7 15:20:58 www kernel: swap_pager: out of swap space . . . Wed Jul 7 15:21:20 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1843128 72 100% /dev/mmcsd0s2b 1843200 1843140 60 100% Total 3686400 3686268 132 100% . . . Jul 7 15:20:58 www kernel: swap_pager: out of swap space . . . Wed Jul 7 15:21:30 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1843160 40 100% /dev/mmcsd0s2b 1843200 1843116 84 100% Total 3686400 3686276 124 100% . . . Jul 7 15:20:58 www kernel: swap_pager: out of swap space . . . Wed Jul 7 15:21:45 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1843192 8 100% /dev/mmcsd0s2b 1843200 1843192 8 100% Total 3686400 3686384 16 100% Jul 7 15:20:58 www kernel: swap_pager: out of swap space Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed . . . Wed Jul 7 15:22:05 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1843192 8 100% /dev/mmcsd0s2b 1843200 1843192 8 100% Total 3686400 3686384 16 100% Jul 7 15:20:58 www kernel: swap_pager: out of swap space Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed . . . Wed Jul 7 15:48:46 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1843192 8 100% /dev/mmcsd0s2b 1843200 1843192 8 100% Total 3686400 3686384 16 100% Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed . . . Wed Jul 7 15:57:01 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1843192 8 100% /dev/mmcsd0s2b 1843200 1843192 8 100% Total 3686400 3686384 16 100% Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed . . . Wed Jul 7 15:57:21 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1843192 8 100% /dev/mmcsd0s2b 1843200 1843192 8 100% Total 3686400 3686384 16 100% Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed . . . Wed Jul 7 16:31:52 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 1843192 8 100% /dev/mmcsd0s2b 1843200 1843192 8 100% Total 3686400 3686384 16 100% Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed Jul 7 16:13:16 www kernel: swp_pager_getswapspace(3): failed . . . Wed Jul 7 17:47:11 PDT 2021 Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 32696 1810504 2% /dev/mmcsd0s2b 1843200 33572 1809628 2% Total 3686400 66268 3620132 2% END QUOTE It looks like for the configuration as it is, the bulk build needs to build such that the load average stays near 1 or less, avoiding near 2 or more: no use of ALLOW_MAKE_JOBS=3Dyes during the bulk build is one way to do that. In http://www.zefox.org/~bob/poudriere.conf (modified for illustration): # By default MAKE_JOBS is disabled to allow only one process per cpu # Use the following to allow it anyway #ALLOW_MAKE_JOBS=3Dyes # List of packages that will always be allowed to use MAKE_JOBS # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports # which holdup the rest of the queue to build more quickly. #ALLOW_MAKE_JOBS_PACKAGES=3D"pkg ccache py*" I'll also note that: http://www.zefox.org/~bob/poudriere.d/make.conf should not ever have the "ALLOW_MAKE_JOBS=3Dyes" that is does: it is the wrong symbol for that kind of context. poudriere converts ALLOW_MAKE_JOBS to something else used in make. QUOTE (not modified for illustration) ALLOW_MAKE_JOBS=3Dyes MAKE_JOBS_NUMBER=3D2 #.if ${.CURDIR:M*www/chromium} #MAKE_JOBS_NUMBER_LIMIT=3D2 #.endif #.if ${.CURDIR:M*databases/sqlite3} #MAKE_JOBS_NUMBER_LIMIT=3D2 #.endif #.if ${.CURDIR:M*www/firefox} #MAKE_JOBS_NUMBER_LIMIT=3D2 #.endif END QUOTE >=20 > The last time www/chromium was compiled (using make) on this machine=20= > I don't remember seeing such a python jam. If it happened at all the=20= > Pi3 worked through it faster than presently.=20 Which was the old make: -j1 vs. -j2 vs. -j3 vs. -j4 ? The ALLOW_MAKE_JOBS=3Dyes use is like -j4 in your 4 core context. Lack of ALLOW_MAKE_JOBS=3Dyes is like -j1 . The -jN is for the number of make processes allowed to be active per builder, including when there is only one builder. The ALLOW_MAKE_JOBS=3Dyes meant that there was likely a massive amount of paging activity that was taking up much of the time. That would still have been true with a much lager swap space: it is a type of context where Lack of ALLOW_MAKE_JOBS=3Dyes may well take notably less time to finish. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jul 8 02:11:59 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5744911F3959 for ; Thu, 8 Jul 2021 02:12:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GL0D810kYz4k84 for ; Thu, 8 Jul 2021 02:12:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625710326; bh=sGhS34aYH4fUWsaFak5WObxueJakWrxFKBguweOkVq8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Rx07qxyxK8k/lXcAii+i3VqxYzcjnb5G50Kk+76LhBpwYOjoAm4Xo74T1Iy9BKCk7993Hic/uv2UcGRfswyzpFfx1CIJxFgktAye/Lm/GNic1yZNIScUqSyfwRZCPM9/hqBYFG8RZYw2UZcp9wESRBaBNUpFlvKKVoH0K8fYUVpFvbomU4BtjiAdgjkY9TSYTEpAtS2ov5535hfT8XZqmpzr+yUktsxzynQ+QKTpchCiy97jqCOrh09hosgREbeBfvosOOn0o0DlSWhYuFc64wpgPUAhtsIdJ+4WOpRJ7+L5YK1tuQuogF76XGdMWJe/VwsylGUklbePtWWJHX8BwQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625710326; bh=3xeMZEcGKpWElgMQ7XkH2U0VKoF3di41c2WFEtuOEl4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=C/VdoZmR830wIITY24SZc5d9lJhlAMOE3NYxiNQziUteJidR45IoXQGlGgNVPw4pEfRR4kw3Y8NqJtS5uoWPJ3WfUQNYpmBK99r7TR9ikO/nmsfP56WWGblY6EWU1a88FaWpmx3SRgR6X2Wa3gYUB94GpArk5e7CCARIrPWLC+X7Ran/ZbIiJ9qLx7dlcWifoNQkdWsPwphHYAB+3Kp7GBfxYlUWOOZjitK4pdHPfl/7CRv0b/W7rFXg/5pzHu3vdBQ28G7/TAnspE3/SrhdCo6NX1s36nA1Vjr6xa4ixmms1pK/oZTJ3EbBcwaXh8e+eraUSeU87TnCAt4FJmbIbQ== X-YMail-OSG: 9LFZM.oVM1kmFRRlTMKY3CI4nOzGiS9lnwNOob1reoSbsxS83GRlArNNvy_JbOB TC1p82uUJ_60B.Dhn5RTqqNOQhc5w3E7CEJA8bry3hq6d52qeUXUOYu_xhBlyWsqHLlthc8xyIVN ucMSbCl4MJrGehDvUlCazbhctHesLzhq.erfzlkrO9DovmgcXyAVNtRF2ufXrHx7P_0SV_bKHKie S.3eoIN_emgFguu_IPw2XeHQ3RprOgAGFs9H4UyQwLjiiafnvav.3BBdSIlIIDjLCHAUm_7wyvNc AHaX4.aoFrMZajVRKCLBEiFLEwZ7MalOmEzIs7xS7VGIRzVzivyuMWkMl68LVDd13_6RRgazTkEf lnWf9_dEcexzgp.UyrNhboq.Yb7aYyZVffTZVzIW4ACNlFXg25duJcgP0LukRwHcFR8WSS0FRYq8 2oUQWR4xG8e35uyUNeO9usT8RukHYO0mH2AZRJXuQtXxFYQ4YuEQagFMm8nAqIcDtXgCXVEFFSmM KyLtSJlzK3qkH7sethZ5rHD1IyhWA4yD_Vd8Zi2DLyy8Lzbx6cW9SUqHR.Ssg37JGbB4gZbELvfa JLyVJtfzttwCYCaPzL7MgI49tOkX0nd9D4h.RSn9kE9gj2mnz84nEIshsHQgZtupd29YZXrifTvH UrPWLjfZ_AXNKFf4UqAFkEFuX2nyrMC_9.LE8STgreWnkkLaCtYq8onIg5EmAi.MwwoSsn5WfQLe hfP_NaLtHscPc7D4zv1wbUFC.9VbgXuGmxG9RkWk043kXmXJRIgvzPpSWyffB5yq71JW4t6eGEcx eEHVOO7r2U5VOffDQ_E_dyi4PRcJlwUrNdzL6_HJdkE9ULPkMhjh03DKPSaeqn0YjeBycDs.RL4S H3fZKGATJbAD79ADQnqqz67b7FslOiAiZddv8EJM12ABbW8Mr2.xVitmKmkqubjLlF8S2zwELrY7 Ml8A2EoRfN0R_9totxENYDReMnS.VO9CEsz4avTi3qtMZa6_xSnMwPdN1UojxunRSsOoRjpiQNyh ruWedr6yAytIN6QDWm65mrwrkcSFIrxRmIUNl0YtkPcwaJX2uxGq4bf8jRRpL5Ty3s46flHjzeCC SOdPhUoFMC3KpwzeMrnte86Kr7OKYBk4_CKblLIVmIw_Rtf2K29LrIuDt_0YOWQH0_LUPcde9Gho OXezO4LfkjlvZzCGi1Ru6jIDezec3DS3vUm02PCplB33TzjTv9GDHvOQ.WgwnYXam2esTtJ0HgbY F3l1w_f0sOM9Yp6_NDkxWlTRbDj9v26Bwvpf77lVc2xbjgPUujvB0o1gdMVtIwIhqA4yC.h37WVT 4BGz26fhKH1XCLulq0kZQdxmkUwx6FWdwRMB5hrIBGtM0vGlcl5aCbUpDlSqAnOPa9SwwrGgubAv QqwyFHCipHkTf7.lmsAR0hqez2fiesQ7VNNjgPynva69ihRc7h8v4PRaGZeqLE3LRGREj.MVT617 RLzuUK0_VV7eK4Op8DSSDb2TyylWEmhNZAIrHEuEOAnpiVIb374Pwy8E1JGwdKPq0LHa9S2wvf1N tJb9wZNaqs2VO2OjCeTIjncXz_PuHAf7MqrBW_OYxQoezNPLfIrxhcSWKqkdzaJfqCKMvyv2QQE2 UMTZhKXaqrXU2C9ZA6fuWtjqr4jDo6YDoNpK5CBDndEbO_YtZ28C0ctzvv0ayNBGutgrULitK68Y 90zgGqW21jSw1.rKETG6ja166Pbm6s2mOVe5yL4Wu8e9UkXXv1rXb6eELidX91ATBqBLcggDApak 7d.PTp_B5f9jn7IUnbxV7vwVESmFyN9sDy5Os5Ztx0IHCISERYscunZHHya68TdI4XqTkqVD0dIh 2cxLtiKIPlHM5cvyw6fv563qiW5Ih90XED1g8V14mveyyQUa8NHCfblHzkLDKbDk8qbWsD1gbSKr OKWbPcZ6FPPWedLaG0yVO_ctIPuAjLIan0FFBoLvG_dHA5lnnM2cdYicJLQeXhhsBjl01Ww_DvPk nNNRzdCn4s7GueEqbIDtyNxV4dZao4mY14xl64jRZFDSt6hhk4C3.rRyzfPCVNxdlG2RJY52HnnK 9yuO4mLbHLGmiQXHp0WwlEW.l1YkMbLZTErUvP.dSFpAut7txj.1rw3NNJtYJM3u0PMxQkSjOiEm lfahl5AMIoi8fczLOCApbqGWvgcTX40hZODchtjQNcDciA1GW5St2YkM4ZH31uvEPc3rpcjlbC_e huJn0KfJNt9_xxBHnsK5.gH_KphCBTVPxUKEGSqR1KVqdbKX6Tkv5SbDSfWVVathxSnhBLO4h.fJ wWYoItHHMYAXzndQy39Nc4Itoy9d5GdKAyA6M2t3IjmAAXQgPW52M6wqbBS7drjRif5r_66OQQn6 ro20kHZ9msH8uWc_eCnbDdGegE0ZLhS1mk8Ocv7ab_nMkmEbWyDq5nGg_jIP1sJNnyg5GhKBIZCv 99nRzHj89lrkFOIrQuQvUcyVuRh1vI9nOp7X5YfVgj_rorVbbv4GhpfHUKJQIMVgV2IeBhDHtfaW O_3TYctM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Jul 2021 02:12:06 +0000 Received: by kubenode534.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a09f798e6d0029076ecb1fe2ce24428d; Thu, 08 Jul 2021 02:12:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> Date: Wed, 7 Jul 2021 19:11:59 -0700 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GL0D810kYz4k84 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Rx07qxyx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.48 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.98)[-0.980]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.146:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.146:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-7, at 19:04, Mark Millard wrote: > From: bob prohaska wrote on > Date: Wed, 7 Jul 2021 14:53:20 -0700 : >=20 >> In trying to compile www/chromium under poudriere on a Pi3 there >> comes a point when five python2.7 sessions totaling more than 2 GB >> in size are running at once. I should have orignially noted right here that such is because of the use of: ALLOW_MAKE_JOBS=3Dyes You need to avoid that for the www/chromium build. >> Obviously, swap is swamped and the Pi3 >> is running at a crawl. It hasn't givem up, however. >>=20 >> Poudriere was started with -J 2 and make is limited to 2 jobs.=20 >> Is there an analogous limit to how many pythons are loosed at >> once? It looks like there's only one builder, so it isn't >> obvious that -J 1 would help; I'll try it if this job stops >> prematurely. >=20 > It will not help. There were no competing build jobs. >=20 >> Progress, such as it is, can be seen at >>=20 >> = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-07-05= _14h06m26s/build.html >=20 > By the time I looked it had run out of swap space: >=20 > Swapinfo 100.00% >=20 > and had stopped for build/timeout after 50:33:26 . >=20 > For reference, including "swap_pager: out of swap space" > and "swp_pager_getswapspace(1): failed": >=20 > QUOTE >=20 > Wed Jul 7 15:20:34 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1831744 11456 99% > /dev/mmcsd0s2b 1843200 1832328 10872 99% > Total 3686400 3664072 22328 99% > . . . > Wed Jul 7 15:20:46 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1838356 4844 100% > /dev/mmcsd0s2b 1843200 1838928 4272 100% > Total 3686400 3677284 9116 100% > . . . > Wed Jul 7 15:20:56 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1841260 1940 100% > /dev/mmcsd0s2b 1843200 1841836 1364 100% > Total 3686400 3683096 3304 100% > . . . > Wed Jul 7 15:21:08 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1843000 200 100% > /dev/mmcsd0s2b 1843200 1843124 76 100% > Total 3686400 3686124 276 100% > . . . > Jul 7 15:20:58 www kernel: swap_pager: out of swap space > . . . > Wed Jul 7 15:21:20 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1843128 72 100% > /dev/mmcsd0s2b 1843200 1843140 60 100% > Total 3686400 3686268 132 100% > . . . > Jul 7 15:20:58 www kernel: swap_pager: out of swap space > . . . > Wed Jul 7 15:21:30 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1843160 40 100% > /dev/mmcsd0s2b 1843200 1843116 84 100% > Total 3686400 3686276 124 100% > . . . > Jul 7 15:20:58 www kernel: swap_pager: out of swap space > . . . > Wed Jul 7 15:21:45 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1843192 8 100% > /dev/mmcsd0s2b 1843200 1843192 8 100% > Total 3686400 3686384 16 100% > Jul 7 15:20:58 www kernel: swap_pager: out of swap space > Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed > . . . > Wed Jul 7 15:22:05 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1843192 8 100% > /dev/mmcsd0s2b 1843200 1843192 8 100% > Total 3686400 3686384 16 100% > Jul 7 15:20:58 www kernel: swap_pager: out of swap space > Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed > . . . > Wed Jul 7 15:48:46 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1843192 8 100% > /dev/mmcsd0s2b 1843200 1843192 8 100% > Total 3686400 3686384 16 100% > Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed > Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed > . . . > Wed Jul 7 15:57:01 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1843192 8 100% > /dev/mmcsd0s2b 1843200 1843192 8 100% > Total 3686400 3686384 16 100% > Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed > Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed > . . . > Wed Jul 7 15:57:21 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1843192 8 100% > /dev/mmcsd0s2b 1843200 1843192 8 100% > Total 3686400 3686384 16 100% > Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed > Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed > . . . > Wed Jul 7 16:31:52 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 1843192 8 100% > /dev/mmcsd0s2b 1843200 1843192 8 100% > Total 3686400 3686384 16 100% > Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed > Jul 7 16:13:16 www kernel: swp_pager_getswapspace(3): failed > . . . > Wed Jul 7 17:47:11 PDT 2021 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 32696 1810504 2% > /dev/mmcsd0s2b 1843200 33572 1809628 2% > Total 3686400 66268 3620132 2% >=20 > END QUOTE >=20 > It looks like for the configuration as it is, the > bulk build needs to build such that the load > average stays near 1 or less, avoiding near 2 or > more: no use of ALLOW_MAKE_JOBS=3Dyes during the bulk > build is one way to do that. >=20 > In http://www.zefox.org/~bob/poudriere.conf (modified > for illustration): >=20 > # By default MAKE_JOBS is disabled to allow only one process per cpu > # Use the following to allow it anyway > #ALLOW_MAKE_JOBS=3Dyes > # List of packages that will always be allowed to use MAKE_JOBS > # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports > # which holdup the rest of the queue to build more quickly. > #ALLOW_MAKE_JOBS_PACKAGES=3D"pkg ccache py*" >=20 > I'll also note that: >=20 > http://www.zefox.org/~bob/poudriere.d/make.conf >=20 > should not ever have the "ALLOW_MAKE_JOBS=3Dyes" that > is does: it is the wrong symbol for that kind of > context. poudriere converts ALLOW_MAKE_JOBS to something > else used in make. >=20 > QUOTE (not modified for illustration) > ALLOW_MAKE_JOBS=3Dyes > MAKE_JOBS_NUMBER=3D2 > #.if ${.CURDIR:M*www/chromium} > #MAKE_JOBS_NUMBER_LIMIT=3D2 > #.endif > #.if ${.CURDIR:M*databases/sqlite3} > #MAKE_JOBS_NUMBER_LIMIT=3D2 > #.endif > #.if ${.CURDIR:M*www/firefox} > #MAKE_JOBS_NUMBER_LIMIT=3D2 > #.endif > END QUOTE >=20 >=20 >>=20 >> The last time www/chromium was compiled (using make) on this machine=20= >> I don't remember seeing such a python jam. If it happened at all the=20= >> Pi3 worked through it faster than presently.=20 >=20 > Which was the old make: -j1 vs. -j2 vs. -j3 vs. -j4 ? >=20 > The ALLOW_MAKE_JOBS=3Dyes use is like -j4 in your 4 core > context. Lack of ALLOW_MAKE_JOBS=3Dyes is like -j1 . >=20 > The -jN is for the number of make processes allowed to be > active per builder, including when there is only one builder. >=20 > The ALLOW_MAKE_JOBS=3Dyes meant that there was likely a massive > amount of paging activity that was taking up much of the > time. That would still have been true with a much lager > swap space: it is a type of context where Lack of > ALLOW_MAKE_JOBS=3Dyes may well take notably less time to > finish. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jul 8 02:27:54 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2EF3511F6760 for ; Thu, 8 Jul 2021 02:28:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GL0ZX0Tk9z4n6l for ; Thu, 8 Jul 2021 02:28:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625711282; bh=ITeRNE/Xp19hxwo5zMztE8XUnSh/YFMRrLPeQtdDHdo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PyaDnmVB2++EBTp8tUI8aOG13URPso1+dBQq+1VDv6trwN0m2ciHO8vEjVj/bGRVAdPkHWooYu/U/V67Y+3bQH84sPTTD5yDXoHyuDM2gUxpTClqYV1ZenC7NUXTlEuWJQvcptuTOytm8vUDW34CHhcLSy0XIuJOly1GoU8TGO5dl9wxcUx+ByZHuLWog2jteII5RAKG/I17rTfejkT6V/zUK8XnYvyN2xOsDK3vFOSdqUTei/yQncmYBB3hcagQisV//dJkuHv3Lz9qZgzHcXTWAY3pMTNUIbGJa3zz/nx6MZrCyo7YxUrOOfMTwRFIxbAIhSohSmI+HELpD3gBQQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625711282; bh=niV8lUpndxPSB0u/HsI5D0Cj6TAQLONRxUyO7jch9pZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OhtGAkusDUBk99ZqC+3hN7mqkmYTFps7PMqt4JG3O0zPtWNHMVG6DYOUAd2HLM0gnQqx6+GhSMHbGqjRH2X58d4aOefVwJzWox3d+aG24ckTthoGzjoxvJNRo+ZUGV2o71zVSiB+4RGap67uTca1WZsadc7Zq1uRDrpXoF8fGD8lSqZg5KYBTJ2Y/Fsj9vJ7li8xb8YRmneELSGir0hS0ASK6ofwnevRLHe+OzLgdzz/0dZIS68Nc8DdjZREXz3E54T0+JRntluPYoyCpCrva7kNGMsQRpUHEpmIwCwE1cm/Pb67aCF4x8oxxqbzhR4itxprSBQ9PGnCPLQuZNMUeg== X-YMail-OSG: 7UIGmwwVM1mZl8S3kKkRXjSNT1Yz0j9khMUarGKvSpYTJA1M_QiARjsTh7pk6o_ HkP1uEvvCDjjvkHpWhcVN2hn8fHSADzM7xQrECNisiRKKHjoiotF55W49PLp2nKnOvuIOY84nSoW D1Efb7PjOeyVgei_pYdE3l28Wh5wZtMsQbtV6zqIJhfstS_wTaRpkyjk9ijkFVqJhSOdIKfK.WRh YI_F4S6byJZGClpDYTtNf.bAVlZwwsHCaHqSWBD27qkTD04NYGE81sK_XzLv__zo5K5C3BrVeW6e jPiOdeTFjjd.o4vribEteRnABW7TMYpmQhl6j0c2cQYjZXUkSAzNp3BapqmTMWEx.aNBqjfvLzgB KCXbW4OlJbIFxEw06VeyV_wHfUzYQEESNdI58b4t3_eFI4i1q5Xjud1KVQeoqmLkHKYX6LWpI6ca py4jhg3EawR68bZx4LL1cqFMGn2.aKgRASU6z48GfAkz0vLIXxfHRYL15_iXLhmrgf.dffZ6qMPp 02A5dfYQuq38LwFXdNicn0__2DJ5Ir13_ciIBYwDWrTcrR1JFxh0pgH7XMJ_n_7UIVHF7ACxZFqD XcbDmiYb9aVmhTQUEwXg057IGq6BCk0HuVjNyKvERWbye5a2mWRIsbMmjgKMyCq0w2OMtP8Qkc_. RlOQTBpCKMeTPQRoKeNTCNaCFEzGwx0ziA7Ikc2WWkH7SIfKh2NP_inDi13gylK_grd77Qmzmsd4 yQ6AiHEknM3tkxURIYfNbT9F.9PDonUXpkeG0.TUSww1lA6wW1Pi27rh1Pd5MB_Th7sJF8YaFRRH .wl6NukxVhFgh6S2SbGDkQt..ZJEicmXaaBh08MBRW4QbWdUJ1TsD17awk9HBYkgTbn1kLcDuZ2u r7rP.GoWFuwpK_Yvnmp3Vg6cq5M0xLx1Ezh6urxGjjficGuUKkkDVV_p0X2unlX3C8RJYURbFxEY Jjp8gOHO7irgsxI7ayiTcmj2oVhXQNL8rZpzzOXIVjlxCZcu1gSfuPTg8NRtirEHYMjoBWT4327G 7P.DMVb7fLUa0BCi86nw5Lg.mtP90VtrHPM.ukQ.LSh7tSPq9ZbnDTacV3suhP2qhs8IjVDBgXmG GH1oi9tS7WqwHAPBJzA6nyrAMOgFKHW0P3GJSd6k_IJKBNxgADFx86lqV0SluQEmla3aeiUC1Zjj _R1CI_fTV6IzBqsOvA3NvE2ANzeFgdGXboTraKWqxMCPmcwamkg9_b9SHOatxj9vnJVjwkJ7xcm2 JJLwzbKiAXtmhidaBAZNapqXe9ZFrcFEfGnHjaDO5HCMQYae4EwOMR4tdRh2gkPtvHPZhwqfkCV3 sdYWE3UaLfyiwV3_cNbhG.5SUMAgwkOUXHlMyXzUeeujCN1A117Oj9QtEybnrvcedu8enYJXEBYv xW8jt7meeQHtjDJjElFa250sGsc3wom4h3lxbYIZFBXYEaEiKQn0rg.bdi_tJN9GUrHq45ZmlLGi GNu3SZgRfNSoz6Jyr4XXoaPOnJMrHVfVrOXVQUpKe1Zg76UMZT2JQNa.TOMtMINvkYNzOvqHT7o2 Jc4kl9l7WWIuJuC4XKTKuV1RVo_qj90gktMqzomHKkghyV7K7GAvHN9tjIJGvHfoSXUTi0qBGkGK 9tizY6vlsR3MSGhHc6GQ73tcQtbor.u4BdvUArbnK2EMu.W3pNW4l6seY4J7AQwJMYVWKlpzOnQp ZiX4bx5wMteiXkyF9_7omFs5guEGXFl43DvYMdkw5BlqDjE5BNjfCVHfwblvmzOU7NiE.91qkpgn 4rtmNxhymXyYItTxOoNN3znWO7N308Dl7ZqhryaF3C.jiWa1boqG5YsrHGixK86Lqekov_2R7FLB 6w5p3eNgKcgBJxuT_9PfgTZLIL40o2LrXPtZoqxQk5v9gvdJsgxkk3eO7jsLrutZkT1ZsJiF4Y7L 76hq6u8V4XL2ak.UWlMY2GMp6bPXBcrwCPg5PLqq.94quBnxnI7eg7TcEPL4yCdWQltpdyRiMbDe Ya_DE8AR8N7n61NrbCsMf1WmtCW.tPaWrF_oglkJk3N5Jd9V3ypExUgqEND0GJdO7OUizQkxEaP9 YeuoxjGKDuVRMfZOjegXOokPjIcqI.RSTRsqO24VxEOtPztN0h6.YYjzZnWJO5SmripCXzfmlHgl NqoRfm7Voi3Ee6lZIbJbXKP0FMZ8PM9k0tuPZSRDUF9ap0MfsEZC5rLjkk5rqsFwcZsKdx5jvPA1 ZeqRfIcml3VuZcEPz8DyxY1mouT2Wv84OIm4o7zr4NmM8tyJhv_Bau_6cuj55Jv53sSRAAUiGy9c 6Y4rIOo8EeWT2vh1jreHN3VfheFiXXPBre3j85igqG.EW_dDAsKfaZSebRtiInRia6Q4mSG_Chln Bzfdg0cYZu9mjrRHwKFiak_YKLU8g_FjauC6ePpzgM3TDI9Bxg6CFR6IKL2TSZ8HJrpdiQC3S8D0 jtJFJm7t0bAmvAGbYSwd9I1MqaHA0s9_1TviXMpVBMHW2xDns2Vw2OIMuemRjsJHkKlKEP07_tkq tnCyWegBSo68- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Jul 2021 02:28:02 +0000 Received: by kubenode523.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6b36816130b852653b4c65610c84d375; Thu, 08 Jul 2021 02:27:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: Date: Wed, 7 Jul 2021 19:27:54 -0700 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GL0ZX0Tk9z4n6l X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PyaDnmVB; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.84:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-7, at 19:11, Mark Millard wrote: > On 2021-Jul-7, at 19:04, Mark Millard wrote: >=20 >> From: bob prohaska wrote on >> Date: Wed, 7 Jul 2021 14:53:20 -0700 : >>=20 >>> In trying to compile www/chromium under poudriere on a Pi3 there >>> comes a point when five python2.7 sessions totaling more than 2 GB >>> in size are running at once. >=20 > I should have orignially noted right here that such is > because of the use of: ALLOW_MAKE_JOBS=3Dyes >=20 > You need to avoid that for the www/chromium build. >=20 >>> Obviously, swap is swamped and the Pi3 >>> is running at a crawl. It hasn't givem up, however. >>>=20 >>> Poudriere was started with -J 2 and make is limited to 2 jobs.=20 >>> Is there an analogous limit to how many pythons are loosed at >>> once? It looks like there's only one builder, so it isn't >>> obvious that -J 1 would help; I'll try it if this job stops >>> prematurely. >>=20 >> It will not help. There were no competing build jobs. >>=20 >>> Progress, such as it is, can be seen at >>>=20 >>> = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-07-05= _14h06m26s/build.html >>=20 >> By the time I looked it had run out of swap space: >>=20 >> Swapinfo 100.00% >>=20 >> and had stopped for build/timeout after 50:33:26 . >>=20 >> For reference, including "swap_pager: out of swap space" >> and "swp_pager_getswapspace(1): failed": >>=20 >> QUOTE >>=20 >> Wed Jul 7 15:20:34 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1831744 11456 99% >> /dev/mmcsd0s2b 1843200 1832328 10872 99% >> Total 3686400 3664072 22328 99% >> . . . >> Wed Jul 7 15:20:46 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1838356 4844 100% >> /dev/mmcsd0s2b 1843200 1838928 4272 100% >> Total 3686400 3677284 9116 100% >> . . . >> Wed Jul 7 15:20:56 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1841260 1940 100% >> /dev/mmcsd0s2b 1843200 1841836 1364 100% >> Total 3686400 3683096 3304 100% >> . . . >> Wed Jul 7 15:21:08 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1843000 200 100% >> /dev/mmcsd0s2b 1843200 1843124 76 100% >> Total 3686400 3686124 276 100% >> . . . >> Jul 7 15:20:58 www kernel: swap_pager: out of swap space >> . . . >> Wed Jul 7 15:21:20 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1843128 72 100% >> /dev/mmcsd0s2b 1843200 1843140 60 100% >> Total 3686400 3686268 132 100% >> . . . >> Jul 7 15:20:58 www kernel: swap_pager: out of swap space >> . . . >> Wed Jul 7 15:21:30 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1843160 40 100% >> /dev/mmcsd0s2b 1843200 1843116 84 100% >> Total 3686400 3686276 124 100% >> . . . >> Jul 7 15:20:58 www kernel: swap_pager: out of swap space >> . . . >> Wed Jul 7 15:21:45 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1843192 8 100% >> /dev/mmcsd0s2b 1843200 1843192 8 100% >> Total 3686400 3686384 16 100% >> Jul 7 15:20:58 www kernel: swap_pager: out of swap space >> Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed >> . . . >> Wed Jul 7 15:22:05 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1843192 8 100% >> /dev/mmcsd0s2b 1843200 1843192 8 100% >> Total 3686400 3686384 16 100% >> Jul 7 15:20:58 www kernel: swap_pager: out of swap space >> Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed >> . . . >> Wed Jul 7 15:48:46 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1843192 8 100% >> /dev/mmcsd0s2b 1843200 1843192 8 100% >> Total 3686400 3686384 16 100% >> Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed >> Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed >> . . . >> Wed Jul 7 15:57:01 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1843192 8 100% >> /dev/mmcsd0s2b 1843200 1843192 8 100% >> Total 3686400 3686384 16 100% >> Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed >> Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed >> . . . >> Wed Jul 7 15:57:21 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1843192 8 100% >> /dev/mmcsd0s2b 1843200 1843192 8 100% >> Total 3686400 3686384 16 100% >> Jul 7 15:21:33 www kernel: swp_pager_getswapspace(3): failed >> Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed >> . . . >> Wed Jul 7 16:31:52 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 1843192 8 100% >> /dev/mmcsd0s2b 1843200 1843192 8 100% >> Total 3686400 3686384 16 100% >> Jul 7 15:48:44 www kernel: swp_pager_getswapspace(1): failed >> Jul 7 16:13:16 www kernel: swp_pager_getswapspace(3): failed >> . . . >> Wed Jul 7 17:47:11 PDT 2021 >> Device 1K-blocks Used Avail Capacity >> /dev/da0s2b 1843200 32696 1810504 2% >> /dev/mmcsd0s2b 1843200 33572 1809628 2% >> Total 3686400 66268 3620132 2% >>=20 >> END QUOTE >>=20 >> It looks like for the configuration as it is, the >> bulk build needs to build such that the load >> average stays near 1 or less, avoiding near 2 or >> more: no use of ALLOW_MAKE_JOBS=3Dyes during the bulk >> build is one way to do that. >>=20 >> In http://www.zefox.org/~bob/poudriere.conf (modified >> for illustration): >>=20 >> # By default MAKE_JOBS is disabled to allow only one process per cpu >> # Use the following to allow it anyway >> #ALLOW_MAKE_JOBS=3Dyes >> # List of packages that will always be allowed to use MAKE_JOBS >> # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports >> # which holdup the rest of the queue to build more quickly. >> #ALLOW_MAKE_JOBS_PACKAGES=3D"pkg ccache py*" >>=20 >> I'll also note that: >>=20 >> http://www.zefox.org/~bob/poudriere.d/make.conf >>=20 >> should not ever have the "ALLOW_MAKE_JOBS=3Dyes" that >> is does: it is the wrong symbol for that kind of >> context. poudriere converts ALLOW_MAKE_JOBS to something >> else used in make. >>=20 >> QUOTE (not modified for illustration) >> ALLOW_MAKE_JOBS=3Dyes >> MAKE_JOBS_NUMBER=3D2 >> #.if ${.CURDIR:M*www/chromium} >> #MAKE_JOBS_NUMBER_LIMIT=3D2 >> #.endif >> #.if ${.CURDIR:M*databases/sqlite3} >> #MAKE_JOBS_NUMBER_LIMIT=3D2 >> #.endif >> #.if ${.CURDIR:M*www/firefox} >> #MAKE_JOBS_NUMBER_LIMIT=3D2 >> #.endif >> END QUOTE >=20 Looks like you could use: MAKE_JOBS_NUMBER=3D2 .if ${.CURDIR:M*www/chromium} MAKE_JOBS_UNSAFE=3D .endif to have www/chromium build as, essentially, -j1 . One thing that MAKE_JOBS_UNSAFE=3D leads to is: MAKE_JOBS_NUMBER=3D1 (Or you could put the MAKE_JOBS_UNSAFE=3D in the www/chromium makefile .) >>=20 >>>=20 >>> The last time www/chromium was compiled (using make) on this machine=20= >>> I don't remember seeing such a python jam. If it happened at all the=20= >>> Pi3 worked through it faster than presently.=20 >>=20 >> Which was the old make: -j1 vs. -j2 vs. -j3 vs. -j4 ? >>=20 >> The ALLOW_MAKE_JOBS=3Dyes use is like -j4 in your 4 core >> context. Lack of ALLOW_MAKE_JOBS=3Dyes is like -j1 . >>=20 >> The -jN is for the number of make processes allowed to be >> active per builder, including when there is only one builder. >>=20 >> The ALLOW_MAKE_JOBS=3Dyes meant that there was likely a massive >> amount of paging activity that was taking up much of the >> time. That would still have been true with a much lager >> swap space: it is a type of context where Lack of >> ALLOW_MAKE_JOBS=3Dyes may well take notably less time to >> finish. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jul 8 04:08:54 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5F6E78D57E8 for ; Thu, 8 Jul 2021 04:09:02 +0000 (UTC) (envelope-from tatsuki_makino@hotmail.com) Received: from KOR01-PS2-obe.outbound.protection.outlook.com (mail-ps2kor01olkn0810.outbound.protection.outlook.com [IPv6:2a01:111:f400:fead::810]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GL2q20TBPz52P3 for ; Thu, 8 Jul 2021 04:09:01 +0000 (UTC) (envelope-from tatsuki_makino@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XFiGiT9edceooXJMXZXPX6f5eSBetoW+8rem09QbiPIz9YQyueiZwqKgAhRJwwRnygpNuwUV+POp8QhH3dRblvZ1n6hcF3NCUEM8t7bNoxtfNArwsDCwOFaLkZbReQBASwQEWCfeaXkXWg5KNJy2UK8CfYSmre+Mbinu6ubFAeTT+PsgjFQb3fobLY45Qu5GlDGyZRYcxlMZAE6Cr/cafYX6n33/6qOxdSmmUNKSwx8X5q8+kkl26N7z2YpT+lS6E9XMrUX3X0C+RmKgqj2i0hwGCC41f0JvhNkpuUxl7ioGt7VwFWy0eM0x/AH7meX7YhKGaYb9SildW9dMlzwMXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IoAafx5QpCoi9JUnaNuieE/ppYe9gBqSVRfkzQX9nA0=; b=dBjfkjfkfhmfM4HlX2hU0QxSd65Y/7WN6rUivqdLps00yCIFlusa4V40Ox5O3Dw53HAfPXaDlK4B4e+yCwhCWv6IcJ4FoBWbhLy0NFi8u4tRYLWnibfUsq9Pbr9ev1d54OQgKVNz6q916bRXoTNITm2vGF+YFUGJkZ3k1KHkYb10Xh7WRl85QpUaN0GajmMdCG4oNEfw0Xj3aNzxxvljmrOBrDufbOAbuvDdtnXfRCqNsETHhwRJKMoBVHyHD5hADVqlkdAUM+X3cnIorP1ohsxYqmehTh7vIOy5W5fBF3hpwK6yZpOtqSGyGKVNXQVtoSAbaAvIdZwgKJ0mdIPeFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IoAafx5QpCoi9JUnaNuieE/ppYe9gBqSVRfkzQX9nA0=; b=mI0sPgqnsCaVgXexvtaLRThLMurQlAMmA9lK/5W9sr1vQCK8uoNfMsy7si9lsXj80ZBkzHizO57ubycvPYAD+YIHJg1b7rAlNkNdR6tkTZjY5nOInPdrFJNL+evVAULKwXAmCow93UW+q8Xr0XlF0IOVChG1Rm3JGCNQ0yKZyiLowj3EW46lJGbixrSOYQkRRqDe+/7txVcwD91R5dU4AJx8xX7WDjncOwj9ys0HiPD+6e0o7yuf3k8VXOT3DKsvDwWLbUuZBMNbczryVuZClRbZarxWFoggOJ1NrROLIprWPMUq/cD7m4OVfVGAB/soCFjSLLHhlIud3JGDeFObcA== Received: from PSAPR03MB5639.apcprd03.prod.outlook.com (2603:1096:301:66::13) by PS2PR03MB3848.apcprd03.prod.outlook.com (2603:1096:300:35::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.10; Thu, 8 Jul 2021 04:08:57 +0000 Received: from PSAPR03MB5639.apcprd03.prod.outlook.com ([fe80::8493:3be8:5755:904b]) by PSAPR03MB5639.apcprd03.prod.outlook.com ([fe80::8493:3be8:5755:904b%5]) with mapi id 15.20.4308.022; Thu, 8 Jul 2021 04:08:57 +0000 Subject: Re: Too many pythons in poudriere To: bob prohaska , freebsd-ports@freebsd.org References: <20210707215320.GA60914@www.zefox.net> From: Tatsuki Makino Message-ID: Date: Thu, 8 Jul 2021 13:08:54 +0900 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 In-Reply-To: <20210707215320.GA60914@www.zefox.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TMN: [K+U7bpaErEwZ47Vycc7ituBDqjv07ICY] X-ClientProxiedBy: TYAPR04CA0018.apcprd04.prod.outlook.com (2603:1096:404:15::30) To PSAPR03MB5639.apcprd03.prod.outlook.com (2603:1096:301:66::13) X-Microsoft-Original-Message-ID: <20278c5c-386f-652b-b1db-d1bd3c912ee3@hotmail.com> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from T4.test (121.95.68.68) by TYAPR04CA0018.apcprd04.prod.outlook.com (2603:1096:404:15::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20 via Frontend Transport; Thu, 8 Jul 2021 04:08:56 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6f187b8c-24e5-4ab9-4ea1-08d941c61b45 X-MS-Exchange-SLBlob-MailProps: mBRmoEB1kyJ0BRW1x2M9PRZ6jjA34H6mOWKpT84xPHTySRsAmFplT2HtUByj9bYEba7pshMw6zBzwVgLa/13kiRvTiRrZzRuswxFkUiEIyMT8C3DM6uyNe35ZB7IMy7EPvEx6kvvIMEhFsqmJ8hQbGIlZ3nIcX96TY/T5a17RuzIwZYR/iYGsLCRY3MOLC4AvG1H+VtQbZapjfzowNotBY7m+TVvB5S82drAZ2KTCAI49dVyLghvMsxidzPqF7A3sQ5dk0bMED9BqFUWVrxm+8m+T1zdhzRBnAT09A9X/0s4/rD2fLIC+HUwkHm8ORJvzWLlrxPwoo/nYs6NBl4NuQ+2HnjSw97LRxczYNdzpkWFHH+td4L8plGrA/OQIzWp+rFVB61r4dA4/wA14c0zm8iLLGtaSFzunXPSpLUA0X0RafqyeWCwZN5d/8+odmMJ1xJ0iI0nMMOKlwts9WdWsagqAVG5pRizzcQOlFfRI2tk02EMI2pfCSG13h6MQAM1S53sFasGSkZtVZWk2HnDNcaKHZ4PJoLguuslVpFVoiT3dBWVIIbfKkYPO4uJ7Kus4AD+XNVsNbNF5nR2LD6XxdzkScpu9VtmqMFXGCSEdr9F50SvEk5NmDSo+Qr0mv0UKtz0WVSKB1EhGcoadm76V35WSeTMIICkYCFACT+PXIpJ3705NjdgPkyHifAdtRntYVO/yLbXGwUVwnx3CoxE0+2UfQmUsqIF3Sf+3Dnx7EJTu3qB9tAv11b/IlUSdpL29BGWRmPo4cw= X-MS-TrafficTypeDiagnostic: PS2PR03MB3848: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JEF1aK+goTuCwAaDnIeHdoUkVieYn2hgsjkF52i0c2HnpJ6chQL0ba6gTgrBugbuiWEpohv5xUeuE/JueJjmz4MMNJlMbwSW+4l6nddrxvex1QrguWZta+yXN3Wy6yH7EWE9vVqUQSASPNO7CElQXLTVFFfKG6+U4wS7UVEL9HJL1rsW4aI1HwpsBuTMsBh8NTQzachl0YpboCqlbhoNZNu2g1OliN5aMZYSjFghu62EU5p8XE6uzsQeAdtSvbyT7xLWvuHAZ2SXS1MscawyVJXcHaEG5f/af4CZgGOmaoF27uLjblyuot5l+2Wi5eP+A+mYxdjryf57oS6IlIsWe18WMiNJg48c0yH3V7wX8lGWYdztC+SnCSHgkQPrZpbV17Ocu6rnUWwg04OpOF6ldux4JiE/JT+tNx0F5fHOXaUmWxJcLkWGD6PKeWISxWI38cGhCvcO9gTy4wmVt08CChxMuly9luzRihoh0RFSOmA= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: wjI8ZP9EKBMtPQHwqzpwiAk9k1dXHVtg4XlfmnXhkb8zbYGyGqSfw75yoWXJBHqaRMP/8DRiZp8b9GRSowhQ6GI2Mns0gV8iZXActhnMB3lX2JP6+7Ce2vU80N/SszY4RSy1DYtCglKbkU07GxMpRQ== X-OriginatorOrg: sct-15-20-3174-8-msonline-outlook-792b7.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 6f187b8c-24e5-4ab9-4ea1-08d941c61b45 X-MS-Exchange-CrossTenant-AuthSource: PSAPR03MB5639.apcprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2021 04:08:57.0574 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PS2PR03MB3848 X-Rspamd-Queue-Id: 4GL2q20TBPz52P3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N bob prohaska wrote on 2021/07/08 06:53: > Progress, such as it is, can be seen at > http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-07-05_14h06m26s/build.html I saw it too. I think you need to adjust MAX_EXECUTION_TIME in /usr/local/etc/poudriere.conf. MAX_EXECUTION_TIME=604800 # <- 1 week? Maybe even a week is not enough :) If you haven't adjusted this, then you may want to redo your current try. Also, since it is Apache, please add an Alias to /usr/local/share/poudriere/html, such as /usr/local/share/examples/poudriere/httpd.conf.sample. :) From nobody Thu Jul 8 08:10:55 2021 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6CEBC122C58B for ; Thu, 8 Jul 2021 08:10:55 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GL8B72jYpz3mBM for ; Thu, 8 Jul 2021 08:10:55 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 467441D784 for ; Thu, 8 Jul 2021 08:10:55 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1688AtgY041520 for ; Thu, 8 Jul 2021 08:10:55 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.15.2/8.15.2/Submit) id 1688AtWX041519; Thu, 8 Jul 2021 08:10:55 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202107080810.1688AtWX041519@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Thu, 8 Jul 2021 08:10:55 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-ThisMailContainsUnwantedMimeParts: N Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ databases/go-pgweb | 0.11.7 | v0.11.8 ------------------------------------------------+-----------------+------------ sysutils/google-compute-engine-oslogin | 20191018.00 | 20210707.00 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Thu Jul 8 08:25:55 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B7CD0122F652; Thu, 8 Jul 2021 08:25:58 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [5.196.167.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GL8WV40hRz3phY; Thu, 8 Jul 2021 08:25:57 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [IPv6:2001:41d0:a:71bf::1]) by mail.freebsd.systems (Postfix) with ESMTP id 99EF61DEC2; Thu, 8 Jul 2021 10:25:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at freebsd.systems Received: from mail.freebsd.systems ([5.196.167.1]) by mail.freebsd.systems (scan.freebsd.systems [5.196.167.1]) (amavisd-new, port 10026) with ESMTP id 85n_KnvjRlHu; Thu, 8 Jul 2021 10:25:55 +0200 (CEST) Received: from [192.168.168.3] (89-70-50-99.dynamic.chello.pl [89.70.50.99]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.freebsd.systems (Postfix) with ESMTPSA id 32C841DD70; Thu, 8 Jul 2021 10:25:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wasikowski.net; s=default; t=1625732755; bh=e9VqsPM3whcy2lR8j99UNL38Q9Th3IbijLloMHrsOis=; h=To:Cc:References:From:Date:In-Reply-To; b=uMfyf40D2qqHMTFngE/NCR5cntUigkNGIhS2dJHjNU2oq+/PDFXOE7lWDjyLM36ui zF5bMTdmxzdHoDyf0haKNPBixD9fQy37x54dgqozFHX363UaAXu2XHKoqBaWXuqZXO 6kXTGcGkad6S1JpcsNhajAyJ2BaOIZ+1n15trxnzFZPe6Xch7KMobKDbK/V67MZyf2 5tcQe4fcNNKiEUM9f05pYdSagFVXYlJJ3YbXSpTD0o+vRE5BBYYztML88LOPKtX3xJ dvTFq1WW0kEDTFQfmUXEkv61sx3jHHNhjvSQmZBQuDZyNblG0ecB2BsMc6GnetDBYJ laESezA+CtwbQ== Subject: Re: security/rkhunter without hashes after recent STABLE-13 update To: Warner Losh , Michael Grimm Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , Stefan Esser References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> From: =?UTF-8?Q?=c5=81ukasz_W=c4=85sikowski?= Message-ID: Date: Thu, 8 Jul 2021 10:25:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: pl Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4GL8WV40hRz3phY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N W dniu 2021-07-07 o 22:35, Warner Losh pisze: > The attached patch (diff to new rkhunter script with both succeeding > hunks) will work for the rkhunter-1.4.6 script. > > > Great! I see you've cc'd lukasz. I'll assume that he can commit it, but > if there's an issue, please let me know! This patch breaks rkhunter on 12.2-RELEASE, hashes are not calculated. -- Best regards, Łukasz Wąsikowski From nobody Thu Jul 8 09:17:07 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 419818D6251; Thu, 8 Jul 2021 09:17:09 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GL9fY17rmz4Qll; Thu, 8 Jul 2021 09:17:09 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f1f2f007ca904cdc22dde0c.dip0.t-ipconnect.de [IPv6:2003:cd:5f1f:2f00:7ca9:4cd:c22d:de0c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 527E42D5CD; Thu, 8 Jul 2021 09:17:08 +0000 (UTC) (envelope-from se@freebsd.org) From: Stefan Esser To: Michael Grimm , Warner Losh Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> Subject: security/rkhunter without hashes after recent STABLE-13 update Message-ID: <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> Date: Thu, 8 Jul 2021 11:17:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 In-Reply-To: <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GxeD6L2ZH33KPpGC8vsNLNvpZgPiZw8R2" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GxeD6L2ZH33KPpGC8vsNLNvpZgPiZw8R2 Content-Type: multipart/mixed; boundary="PhEMBSXfMc8zoSFWPwaQWT8IQX0EdkuQ7"; protected-headers="v1" From: Stefan Esser To: Michael Grimm , Warner Losh Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net Message-ID: <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> Subject: security/rkhunter without hashes after recent STABLE-13 update References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> In-Reply-To: <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> --PhEMBSXfMc8zoSFWPwaQWT8IQX0EdkuQ7 Content-Type: multipart/mixed; boundary="------------F0E6835EAC1DDC280EA83B43" Content-Language: en-US This is a multi-part message in MIME format. --------------F0E6835EAC1DDC280EA83B43 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 07.07.21 um 22:24 schrieb Michael Grimm: > Warner Losh wrote: >> >> On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm wr= ote: >>> Warner Losh wrote: >=20 >>>> Sorry for any hassle this work is causing. >>> >>> No big deal for rkhunter, a workaround exists ;-) >> >> I think the reason is that it automatically switched to using sha256su= m >> because it was present, but it didn't automatically change #HASH_FLD_I= DX=3D4 >> to be 1. The shell script is tricky enough that I've not looked throug= h it >> all. I'd argue this is a bug in the get_sha_hash_function which doesn'= t >> adjust the HASH_FLD_IDX based on which version it finds. Instead, it s= ets >> it unconditionally to 4 on *BSD or DragonFly. [...] >=20 > But anyway, you nailed it! That fixes rkhunter. It will now produce has= hes for both /sbin/sha256 and /sbin/sha256sum. >=20 > The attached patch (diff to new rkhunter script with both succeeding hu= nks) will work for the rkhunter-1.4.6 script. >=20 > Thanks and with kind regards, > Michael Hi Warner and Michael, the reason I added full support for the -c option was that a port build f= ailed since it assumed that if the name of the hash program ended in "sum" it w= as fully compatible with the Coreutils program of that name and that is supp= orted the "-c digestfile" option. This is a general problem when we gain compatibility with some other OS (= TM): Ports often assume that availability of a program (MACRO, include file, .= =2E.) means it is the real thing, and not only attempt of an emulation of the m= ost important feature (i.e. only considering a very specific use case). An alternative (and my preferred fix) would be to not search for the *sum= functions on FreeBSD, and thus not having to adjust the HASH_FLD_IDX vari= able: -- files/rkhunter.orig 2018-02-24 23:08:27 UTC +++ files/rkhunter @@ -4750,7 +4750,12 @@ get_sha_hash_function() { return fi - HFUNC=3D`find_cmd sha${SHA_SIZE}sum` + case ${OPERATING_SYSTEM} in + FreeBSD) + HFUNC=3D`find_cmd sha${SHA_SIZE}` ;; + *) + HFUNC=3D`find_cmd sha${SHA_SIZE}sum` ;; + esac if [ -z "${HFUNC}" ]; then HFUNC=3D`find_cmd sha${SHA_SIZE}` The suggested patch is attached. I did not want to change more lines than= required, and other BSDs could easily added to the special case, should they be affected, too. And I'd assume that this patch could be accepted by the upstream ... Michael, could you please test this patch? (I do not have rkhunter installed on my system ...) Regards, STefan --------------F0E6835EAC1DDC280EA83B43 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="rkhunter-port.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rkhunter-port.diff" ZGlmZiAtLWdpdCBhL3NlY3VyaXR5L3JraHVudGVyL2ZpbGVzL3BhdGNoLWZpbGVzX3JraHVu dGVyIGIvc2VjdXJpdHkvcmtodW50ZXIvZmlsZXMvcGF0Y2gtZmlsZXNfcmtodW50ZXIKaW5k ZXggYmQ3MGMzYTI3NmY0Li42MTZjNTg5YWUxMTIgMTAwNjQ0Ci0tLSBhL3NlY3VyaXR5L3Jr aHVudGVyL2ZpbGVzL3BhdGNoLWZpbGVzX3JraHVudGVyCisrKyBiL3NlY3VyaXR5L3JraHVu dGVyL2ZpbGVzL3BhdGNoLWZpbGVzX3JraHVudGVyCkBAIC0xLDYgKzEsMjAgQEAKLS0tLSBm aWxlcy9ya2h1bnRlci5vcmlnCTIwMTQtMDMtMTIgMjA6NTQ6NTUgVVRDCistLS0gZmlsZXMv cmtodW50ZXIub3JpZwkyMDE4LTAyLTI0IDIzOjA4OjI3IFVUQwogKysrIGZpbGVzL3JraHVu dGVyCi1AQCAtNzI3NSw2ICs3Mjc1LDkgQEAgZG93bmxvYWRfZmlsZSgpIHsKK0BAIC00NzUw LDcgKzQ3NTAsMTIgQEAgZ2V0X3NoYV9oYXNoX2Z1bmN0aW9uKCkgeworIAkJcmV0dXJuCisg CWZpCisgCistCUhGVU5DPWBmaW5kX2NtZCBzaGEke1NIQV9TSVpFfXN1bWAKKysJY2FzZSAk e09QRVJBVElOR19TWVNURU19IGluCisrCUZyZWVCU0QpCisrCQlIRlVOQz1gZmluZF9jbWQg c2hhJHtTSEFfU0laRX1gIDs7CisrCSopCisrCQlIRlVOQz1gZmluZF9jbWQgc2hhJHtTSEFf U0laRX1zdW1gIDs7CisrCWVzYWMKKyAKKyAJaWYgWyAteiAiJHtIRlVOQ30iIF07IHRoZW4K KyAJCUhGVU5DPWBmaW5kX2NtZCBzaGEke1NIQV9TSVpFfWAKK0BAIC03NTIyLDYgKzc1Mjcs OSBAQCBkb3dubG9hZF9maWxlKCkgewogIAkJcm0gLWYgIiR7T1VUUFVUX0ZJTEV9IiA+L2Rl di9udWxsIDI+JjEKICAKICAJCWNhc2UgIiR7UktIV0VCQ01EX0JBU0V9IiBpbgo= --------------F0E6835EAC1DDC280EA83B43-- --PhEMBSXfMc8zoSFWPwaQWT8IQX0EdkuQ7-- --GxeD6L2ZH33KPpGC8vsNLNvpZgPiZw8R2 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmDmwpMFAwAAAAAACgkQR+u171r99URI HAgAlv+3InNypIQjAxvqXgljkWRUZRx/lA5NH+cxeV9pSpY1vUNzrw7HoTUo63MJAZnscYVBgnCR U8ErDCbS27iyQAakgdNMOpFSu7GcMJfxWg9ykfpKtt9toPJksx0wrUTjV8rBZwl7fNBGfnzmNa41 EcsHQWS/uTw7BFBcEX73YH3cT8gr+KOeXYeS2RWNoQ6vXt/UOAlt50sBLgAjnxkFJWqrRK+nStfh 46KnNZ9/NCfy7SivXnd0mE5ztl+IyOCm2Dj+BOgEmqvJCV7+v2FnXlHFlWPQV3Civ65yEEkohEWD g1JkfU3CHk3/jih/y6wDyu11Yk6MGyQaP0hV6U6ESQ== =Ol13 -----END PGP SIGNATURE----- --GxeD6L2ZH33KPpGC8vsNLNvpZgPiZw8R2-- From nobody Thu Jul 8 09:39:33 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8350F11E1B64 for ; Thu, 8 Jul 2021 09:39:37 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (mailserver.netfence.it [78.134.96.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mailserver.netfence.it", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLB8R5qpfz4V6Z for ; Thu, 8 Jul 2021 09:39:35 +0000 (UTC) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18]) (authenticated bits=0) by soth.netfence.it (8.16.1/8.16.1) with ESMTPSA id 1689dXGX004024 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 8 Jul 2021 11:39:33 +0200 (CEST) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.netfence.it: Host alamar.local.netfence.it [10.1.2.18] claimed to be alamar.ventu To: freebsd-ports@freebsd.org From: Andrea Venturoli Subject: Cannot build INDEX on 12.2 (2021Q3 branch) Message-ID: <8c450781-eeba-2e0b-91c7-8dfb718fefe3@netfence.it> Date: Thu, 8 Jul 2021 11:39:33 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GLB8R5qpfz4V6Z X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 78.134.96.152 as permitted sender) smtp.mailfrom=ml@netfence.it X-Spamd-Result: default: False [-1.79 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[78.134.96.152:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:78.134.96.152]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[78.134.96.152:from:127.0.2.255]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; NEURAL_HAM_SHORT(-0.99)[-0.991]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:35612, ipnet:78.134.0.0/17, country:IT]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] X-ThisMailContainsUnwantedMimeParts: N Hello. Seems like sysutils/omnibackup looks for Postgres 9.5, which is gone. Nothing fancy in /etc/make.conf. > # make index > Generating INDEX-12 - please wait..--- describe.accessibility --- > --- describe.arabic --- > ... > --- describe.x11-wm --- > make_index: /usr/ports/sysutils/omnibackup: no entry for /usr/ports/databases/postgresql95-client > Done. bye av. From nobody Thu Jul 8 11:58:30 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9D9831224AAC for ; Thu, 8 Jul 2021 11:58:34 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (mailserver.netfence.it [78.134.96.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mailserver.netfence.it", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLFDn2vFnz4mbp for ; Thu, 8 Jul 2021 11:58:33 +0000 (UTC) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.local.netfence.it [10.1.2.18]) (authenticated bits=0) by soth.netfence.it (8.16.1/8.16.1) with ESMTPSA id 168BwUwZ026392 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 8 Jul 2021 13:58:30 +0200 (CEST) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.netfence.it: Host alamar.local.netfence.it [10.1.2.18] claimed to be alamar.ventu Subject: Re: Cannot build INDEX on 12.2 (2021Q3 branch) From: Andrea Venturoli To: freebsd-ports@freebsd.org References: <8c450781-eeba-2e0b-91c7-8dfb718fefe3@netfence.it> Message-ID: <9154287d-94d2-1af7-2408-2ee8b498f6b0@netfence.it> Date: Thu, 8 Jul 2021 13:58:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 In-Reply-To: <8c450781-eeba-2e0b-91c7-8dfb718fefe3@netfence.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GLFDn2vFnz4mbp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 78.134.96.152 as permitted sender) smtp.mailfrom=ml@netfence.it X-Spamd-Result: default: False [-3.48 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[78.134.96.152:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:78.134.96.152]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[78.134.96.152:from:127.0.2.255]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; NEURAL_HAM_SHORT(-0.68)[-0.680]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:35612, ipnet:78.134.0.0/17, country:IT]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] X-ThisMailContainsUnwantedMimeParts: N On 7/8/21 11:39 AM, Andrea Venturoli wrote: > Hello. > > Seems like sysutils/omnibackup looks for Postgres 9.5, which is gone. > Nothing fancy in /etc/make.conf. > >> # make index >> Generating INDEX-12 - please wait..--- describe.accessibility --- >> --- describe.arabic --- >> ... >> --- describe.x11-wm --- >> make_index: /usr/ports/sysutils/omnibackup: no entry for >> /usr/ports/databases/postgresql95-client Please, disregard. I had not seen that postgres95-client was installed, unused, forgotten... Sorry for the noise. bye av. From nobody Thu Jul 8 12:16:44 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 24F53122774C; Thu, 8 Jul 2021 12:16:48 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [IPv6:2001:41d0:701:1000::1685]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLFdq6yv5z4pxq; Thu, 8 Jul 2021 12:16:47 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300FB4F03f5013d64EC276C99a51F.dip0.t-ipconnect.de [IPv6:2003:fb:4f03:f501:3d64:ec27:6c99:a51f]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4GLFdm5t1Yz6jd; Thu, 8 Jul 2021 14:16:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625746604; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wqzz6QbVDXeMjJ3ZuLP69RKqgsI5cOcEOzjr1QgyLbs=; b=bgdVigHaUv6KY8OOvRAPIKtRXyawJaRcLWcpIviBENWgjjlhBOH48gBSvwspCBbkVQHgmt 1IHR7VCRRf0d5C+Q8pDI4YZhaNyXbP08FqXGzb8jYCisd6wOytrVJLpqROh6+J42AfyArc zbvCWEjbGKzg1NQzmGGEeCXENec/FptS6fr1fxaT6FTIkmsJwTN9qdSa/4Bm7BttTkJD+k 4fUdO1w57QcNJpMjS53hA2e/p+IdlTlcGbjetWpbBLvFltmxb29h+PL42rfUH8JlEFIyJM 8TSie4uRkbDh8bvw2aMYqGRi5b+A2OODlmv80Y0CBB9j5sHfx7y0UTxNP1nIJg== Content-Type: text/plain; charset=utf-8 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: security/rkhunter without hashes after recent STABLE-13 update In-Reply-To: <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> Date: Thu, 8 Jul 2021 14:16:44 +0200 Cc: Warner Losh , FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GLFdq6yv5z4pxq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: N Hi Stefan, Stefan Esser wrote > Am 07.07.21 um 22:24 schrieb Michael Grimm: >> Warner Losh wrote: >>> On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm = wrote: >>>> Warner Losh wrote: >>>>> Sorry for any hassle this work is causing. >>>>=20 >>>> No big deal for rkhunter, a workaround exists ;-) >>>=20 >>> I think the reason is that it automatically switched to using = sha256sum >>> because it was present, but it didn't automatically change = #HASH_FLD_IDX=3D4 >>> to be 1. The shell script is tricky enough that I've not looked = through it >>> all. I'd argue this is a bug in the get_sha_hash_function which = doesn't >>> adjust the HASH_FLD_IDX based on which version it finds. Instead, it = sets >>> it unconditionally to 4 on *BSD or DragonFly. > [...] >>=20 >> But anyway, you nailed it! That fixes rkhunter. It will now produce = hashes for both /sbin/sha256 and /sbin/sha256sum. >>=20 >> The attached patch (diff to new rkhunter script with both succeeding = hunks) will work for the rkhunter-1.4.6 script. >=20 > Hi Warner and Michael, >=20 > the reason I added full support for the -c option was that a port = build failed > since it assumed that if the name of the hash program ended in "sum" = it was > fully compatible with the Coreutils program of that name and that is = supported > the "-c digestfile" option. >=20 > This is a general problem when we gain compatibility with some other = OS (TM): > Ports often assume that availability of a program (MACRO, include = file, ...) > means it is the real thing, and not only attempt of an emulation of = the most > important feature (i.e. only considering a very specific use case). >=20 > An alternative (and my preferred fix) would be to not search for the = *sum > functions on FreeBSD, and thus not having to adjust the HASH_FLD_IDX = variable: >=20 > -- files/rkhunter.orig 2018-02-24 23:08:27 UTC > +++ files/rkhunter > @@ -4750,7 +4750,12 @@ get_sha_hash_function() { > return > fi >=20 > - HFUNC=3D`find_cmd sha${SHA_SIZE}sum` > + case ${OPERATING_SYSTEM} in > + FreeBSD) > + HFUNC=3D`find_cmd sha${SHA_SIZE}` ;; > + *) > + HFUNC=3D`find_cmd sha${SHA_SIZE}sum` ;; > + esac >=20 > if [ -z "${HFUNC}" ]; then > HFUNC=3D`find_cmd sha${SHA_SIZE}` >=20 > The suggested patch is attached. I did not want to change more lines = than > required, and other BSDs could easily added to the special case, = should > they be affected, too. >=20 > And I'd assume that this patch could be accepted by the upstream ... >=20 > Michael, could you please test this patch? I can confirm that your patch works perfectly well.=20 No more workaround needed, now rkhunter calculates sha256 hashes as = usual. Thanks for that.=20 Now, =C5=81ukasz need's to confirm that rkhunter at 12.2-RELEASE will = calculate those hashes as well. Regards, Michael= From nobody Thu Jul 8 15:45:58 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0DB8D12221EA for ; Thu, 8 Jul 2021 15:45:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLLH91dr3z3l7H for ; Thu, 8 Jul 2021 15:45:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 168FjwJx069286 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 8 Jul 2021 08:45:59 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 168FjwBQ069285; Thu, 8 Jul 2021 08:45:58 -0700 (PDT) (envelope-from fbsd) Date: Thu, 8 Jul 2021 08:45:58 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-ports@freebsd.org Subject: Re: Too many pythons in poudriere Message-ID: <20210708154558.GB60914@www.zefox.net> References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4GLLH91dr3z3l7H X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Even with -J1 and no ALLOW_MAKE_JOBS I'm still seeing five pythons occupying at least 3 GB on the loose. I'm fairly sure this didn't happen when using make by itself (IIRC it was -j2). I also got rid of the mistaken directive in poudriere.d/make.conf. There is a #MAX_MEMORY=8 in poudriere.conf, presumably GB. That looks like a good knob to play with. Would setting it to something like 3 or 4 help? RAM plus swap presently totals 4.6 GB. It looks like the present try will run out of swap eventually, but I'll let it go for now to see if anything interesting happens. Thanks for reading!! bob prohaska From nobody Thu Jul 8 16:41:13 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0C7A81229162 for ; Thu, 8 Jul 2021 16:41:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLMW65V8Bz3sVy for ; Thu, 8 Jul 2021 16:41:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625762480; bh=+16efBj8mL3dnF4qTzG6/tL1HHJKgN6ChaAyihkTs88=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Kstq0jzYiD4rP4Zj51DUGJYbJTkwSyVl9OPRY4OPE93jdQKgOoxBVK5SKhXxNl3pa/VA0+AmfCHD2QmFYCPkNQlhv9V3N5BcZFuwDoVrYsyyF/AnP8y/qx9Ahu5kMDebN5rb9uZ0X/OP0322jc6roTd/fPkCY9Cl8tnJwpQXz7snxA5kGM4kTE9oNoPnIpxd8JNNPjifndu3yDjZy1imuUmz8iYSlGyhOUc+sQC4m/TIupK4d8FuplkIN1jezAAFfOepRJGtB3XZ3yZShXMMnaxgHRVFy2uqDEUBLhUxvnZ8Mchfy2KLWDd+gc2+p8fxCH7fDpIqhWxC42hx/NzXdA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625762480; bh=kkdVMEPiW4c6hBcYgpA85jaE+sQpLDKCkPpJ+61Z4r6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G0JKsermHDrWpA2hTdCcfpzOby1Xo/FojDRu6LJf+/liNPiDIcHNuHB54l7iBLLgriF/jHI8UcLcQsYhIkE6/9roDVj28dUSjmHpLZSxlD9/WIL48iB3tmTi7x+awkrHynEEjKpiMrbd2dx3eKOHwBAaFenItre9+RR80XIcUHiU/Vkp+bST5hP1SxGaZWdqLnS2f08QVMsAPs6eJD4S0ma4DfRXC9F0LZ7uzjXF3c7O8pHEQ2II0C/vld3SED0RbaFIVPexYjtW/1sN16l4cFq3flKsAkdSY9PZevAk6MTUPK98S54AzjNcqBWnN8/XgiRN7j2gbBFPuvljyt6DHw== X-YMail-OSG: IsLhq_wVM1n9vyQYAoq1jltp.fq11f6bv3Z6Puln.gn.NXbbd54qd4RbUTtQajc nQuNkkJOvHdAehqgiytlxWBhq1r3162Ry0BlfeHOaRwfiGAt_UMjGOIGqMeOWV10mbLdCPMRC5ml aA61lCHFv2XVdBahEfTHdAcptyQOq2KF3v6bke1vkm4rO9BsanGb67mdOJhh73AGaBipfwjgRz3L Ij6MB3ns33MRrqclHkP.jZMgO8eLyuAyEIEwvbA6t7NcU0QwRXOn.0i87ZoJAUhvpB3ItARQ_whp lloum74ey4WOy_SAqqqNK8wgHR9gMn_qXm.ASf.HlWYbgOEsD9MTEMw9L0hFR7P2MMHZBjxBc4m0 btMJdmwoJ3F8w83RNCXkgTiUoUjodFJx.zmYSj1N2KMUvYWI59cXZNt7J8N9IZtvHTj0mU2K4YKi 0ixzVZe3tidSgvYJIYniF.V.RhmrMSinj97aARf91hPOE4DFaHgMj.WDDJBtzR0MlDOBpElEuMfZ m2F1k2hU2eGDhuDfAcb4vouMhJS2E1T4I.yaaELTvYvtvCILtmsRuoXHVjLg8cG1B2Bu70Z3Ge82 uU_yQc.Va2Q901MbRBkHZRlb3P_jwe8efx3uhfyfxLzenJXG2NSOF5PAg7YDDo8XFtfqkz5XAcwL xWnI.YXEa3I4fKAIQhYZUoso_bgz0hsEXiWOyErz4G8XhBS1le_NXbJA7jSGDTUbKqCDQm.o2yl5 tEsuPYRyCkL7jtCXZIChUew7pMZ20sciaEqfIy_Yezj2XhlWjNIHsq4Btko.3tGTz4XUmcZNkHrU gIpJUC9mFOW1H3oYyUE6gaG3VXKEHFhYaJXF1CNrmq58w0eZJTyRHXFr5qD6UiJ4ELXWL1CqQpku nI83K.ghuXVqPViTztj27u.DhcRZLaFXX2pwPtu4u.Poa7.Q2Kj0iGfLegvuPARZBtIpBaKt4W0t aWMQS2oG1AcTyz4C5N8x8ELE.q7ur76UzgObuhrPA78ihsagzgKL4NMIibUE2ZVr19VIOx5_xU16 Ad_7ne5H1fp8OleqYGibkkM2yn.IHEvH3i.l8BNVZkgS1kzRZpvCvf.4Clbi0INGABrNGmCRcIbC 3BlJE1F13kG3ptFFgSg8tjjGOsTvr.XrVYTnLRC_SlVdRKJyFTq0Y5a55yScKxLTwXnq_PCipv7J 2nZDqRSwX102GQJ6VSgMuheNHlAQEnDNJJ9P3FGEZJEN.I7dXVhdMt2ZAJCrb5tp.bMyhtVCyLYm MUrB4e31i1q.YmGoB8N17EF3x5kXRf0IJpJAJgLAkvnF9O48lgg2oGsLqvS5aF69oqrd2gt33hmX 5Y_XXPwWsTkrDjDETD3jg1KF3t5btoms7nfP81uCu6zs7pnHA1pQDUQ_ILmgHqreLVrh7UhKZKgc NDLYrKqSNMziIXOpcjn.X9WzPUHeSXzZIoVsB9irWAkoi8Tr1uUWfEqmrgojo5SIBdpoT63c8vmJ .BmwocxqvIufRtmNAUF3SB5QzjftPrGGulEaF_EJITsf3v7_xz_FYlsYD2h_uEJDCqyBMZ_QGN3p xvsG4yC1MV6JHLw612Jvd23ym9x95cdOkVZ4QkZJXURSmaJxQbYGdo99RW1rrNOV4i0Ck9sRat8f 7YZoV239oTQsGXq3WMpDb.9J0JEAEvW2GZRnMXgFrXNz8Hw.NAZUIwSh9gkeBBpqIs0mBaM_B0By po1Tj5rvooLwIBAV7RU4r92qGEjsjMOQfMTVJhw3mLKLbWKaTqad0iS4y6p_faaL8af5RgyjPKxZ bH3Q7XfVE9Q60x0Mk4EcVBlfQZxaCZe86IX_ZbsR0Ednpl.3OjG8n5fIFkKSAwim9PN0xPfBnT7z rx.dYnypRbQ9AdSlx5INqQvwo7dzs4pA_6VY7yvA1v2Btz.wY2SfO6gGhC4VlFw_F0Hjd8OZjiVD EMdmKrdamMPxr.Nj3Kg7Xn.FS7UWo5.Zw.ouzTYPSh7NRbWj6aL67VM3a4uEs8CzGnt14iUvwHJ8 xs4ZAOEkbg9r2GigOIVDE1pYBbK0XkQQfrc_ClYvJM0E4Zbc9D.lyKGe.KKpIPBfGa_LrS030j4_ LTWgJwx_uTZb576jVgh3iD8ojU_LkV7.kmyvh9xjY5BJbTqyCJthdmQ8TJf9erRFzzzdSilwrVTL ez9qph93WynE.gOHu32XpHaEJaF67cKraEuH5KuY1srPQeP4XU.mQt5pyh9rcShHipV0lxzxKKJA VCbgyTfgLteupGW9.OZ5eWUhG1D5EiuZm3QqCE29eLxt7M0ZssaSjCWsYVKc0PW7Zhr0Xg4NfASV kFLefkblAYbiDqZhNjzoLwjeCPYjVJr7X39Fi3UcPhl7TsjQesWqVPV5KIyolrZMlobARqTOU94A 7btae1FjT1VWr3y4k2aYyWtA9FHnjA7_NTSpi6l.KdteP.Pr9Z4MoarmLgzBZMMCF44A7oDq6xSr eHxNbwsW82aLcNTgHNDLkeYddT9X3PvOUvT0TiybJ.ypbCQw0zPRaT.Jdso.PUhB3O8VR3jNSxsW H65NIGCwEmH8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Jul 2021 16:41:20 +0000 Received: by kubenode552.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8fb3070d3cf35945c0c00c484ee80073; Thu, 08 Jul 2021 16:41:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: <20210708154558.GB60914@www.zefox.net> Date: Thu, 8 Jul 2021 09:41:13 -0700 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GLMW65V8Bz3sVy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-8, at 08:45, bob prohaska wrote: > Even with -J1 and no ALLOW_MAKE_JOBS I'm still > seeing five pythons occupying at least 3 GB on > the loose. Actually I just looked and saw: Swapinfo 7.36% (Unlike the 83% or so I saw somewhat around 3 hours ago.) Load Averages (220%) 2.20 2.18 1.76 Elapsed 12:54:56 I do not see a swaplog in http://www.zefox.org/~bob/swaplogs/ to look at. So I can not see how much the peak swap space usage was so far (approximately). > I'm fairly sure this didn't happen > when using make by itself (IIRC it was -j2). > I also got rid of the mistaken directive in > poudriere.d/make.conf. When I look at http://www.zefox.org/~bob/poudriere.d/make.conf now I see: ALLOW_MAKE_JOBS=yes #MAKE_JOBS_NUMBER=2 #.if ${.CURDIR:M*www/chromium} #MAKE_JOBS_NUMBER_LIMIT=2 #.endif #.if ${.CURDIR:M*databases/sqlite3} #MAKE_JOBS_NUMBER_LIMIT=2 #.endif #.if ${.CURDIR:M*www/firefox} #MAKE_JOBS_NUMBER_LIMIT=2 #.endif which does not match your wording. But http://www.zefox.org/~bob/poudriere.conf does show ALLOW_MAKE_JOBS=yes commented out: # By default MAKE_JOBS is disabled to allow only one process per cpu # Use the following to allow it anyway #ALLOW_MAKE_JOBS=yes #MAKE_JOBS_NUMBER=2 # List of packages that will always be allowed to use MAKE_JOBS # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports # which holdup the rest of the queue to build more quickly. #ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py*" (The interface for seeing the files does not show timestamps so I can not tell when updates were done.) (This is the wrong place for a MAKE_JOBS_NUMBER= use but it is commented out.) To see what is getting CPU time that leads to the load averages being around 2 might take using something like top sorted by cpu time and watching for a while. > There is a > #MAX_MEMORY=8 > in poudriere.conf, presumably GB. Documented as GiB: # How much memory to limit jail processes to for *each builder* # in GiB (default: none) #MAX_MEMORY=8 Per builder, not per-make-process. Within a builder each make-process shares that size space with the others. > That > looks like a good knob to play with. Would > setting it to something like 3 or 4 help? If the memory use exceeds what you set, the builder process is likely killed. It looks to be a way to have one or both of the following true: A) Stop the builder somewhat before the whole system runs out of memory (and swap space). This is likely a better failure mode handling: it could avoid the system hanging up. B) Prevent interfering other processes outside the builder by being sure the system still has available memory for other activities. But when I looked at the scripts it turns into jexec (and jexecd) command line options but man jexec did not document the options that I could see. No found for "man jexecd". So I'm guessing. > RAM plus swap presently totals 4.6 GB. > It looks like the present try will run out of > swap eventually, but I'll let it go for now > to see if anything interesting happens. It may later fail again, but the swap space usage is not large as of when I looked. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jul 8 17:54:36 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CB4F38D2EF4 for ; Thu, 8 Jul 2021 17:54:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLP7b3rc9z4WKM for ; Thu, 8 Jul 2021 17:54:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 168HsbPs071391 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 8 Jul 2021 10:54:37 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 168HsaRQ071390; Thu, 8 Jul 2021 10:54:36 -0700 (PDT) (envelope-from fbsd) Date: Thu, 8 Jul 2021 10:54:36 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-ports@freebsd.org Subject: Re: Too many pythons in poudriere Message-ID: <20210708175436.GA70414@www.zefox.net> References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4GLP7b3rc9z4WKM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jul 08, 2021 at 09:41:13AM -0700, Mark Millard wrote: > > > On 2021-Jul-8, at 08:45, bob prohaska wrote: > > > Even with -J1 and no ALLOW_MAKE_JOBS I'm still > > seeing five pythons occupying at least 3 GB on > > the loose. > > Actually I just looked and saw: > > Swapinfo 7.36% > > (Unlike the 83% or so I saw somewhat around 3 hours ago.) > > Load Averages (220%) 2.20 2.18 1.76 > > Elapsed 12:54:56 > > I do not see a swaplog in http://www.zefox.org/~bob/swaplogs/ > to look at. So I can not see how much the peak swap space > usage was so far (approximately). Started a new swaplog: http://www.zefox.org/~bob/swaplogs/202107182930.log It came within a whisker of running out of swap, then abruptly the python threads vanished and the build seems to be proceeding. I'm curious if this was blind luck, or some adaptive behavior by poudrirere. One other oddity: occasionally one see in top a PID using more than 100% WCPU. Is one thread occupying two cores? > > > I'm fairly sure this didn't happen > > when using make by itself (IIRC it was -j2). > > I also got rid of the mistaken directive in > > poudriere.d/make.conf. > > When I look at http://www.zefox.org/~bob/poudriere.d/make.conf > now I see: > > ALLOW_MAKE_JOBS=yes > #MAKE_JOBS_NUMBER=2 > #.if ${.CURDIR:M*www/chromium} > #MAKE_JOBS_NUMBER_LIMIT=2 > #.endif > #.if ${.CURDIR:M*databases/sqlite3} > #MAKE_JOBS_NUMBER_LIMIT=2 > #.endif > #.if ${.CURDIR:M*www/firefox} > #MAKE_JOBS_NUMBER_LIMIT=2 > #.endif > > which does not match your wording. > Thank you for catching my error. _now_ it's fixed. [snip] > To see what is getting CPU time that leads to > the load averages being around 2 might take > using something like top sorted by cpu time > and watching for a while. > > > There is a > > #MAX_MEMORY=8 > > in poudriere.conf, presumably GB. > > Documented as GiB: > > # How much memory to limit jail processes to for *each builder* > # in GiB (default: none) > #MAX_MEMORY=8 > > Per builder, not per-make-process. > Within a builder each make-process shares > that size space with the others. > > > That > > looks like a good knob to play with. Would > > setting it to something like 3 or 4 help? > > If the memory use exceeds what you set, the builder > process is likely killed. [snip] I was hopeful it might inhibit starting new PIDs when memory/swap is below some threshold. Guess not. Thanks for writing! bob prohaska From nobody Thu Jul 8 18:13:16 2021 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DA5F38D54D8 for ; Thu, 8 Jul 2021 18:13:20 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLPYC5qJ2z4YVS for ; Thu, 8 Jul 2021 18:13:19 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm1-x330.google.com with SMTP id k16-20020a05600c1c90b02901f4ed0fcfe7so4610413wms.5 for ; Thu, 08 Jul 2021 11:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=oPYYo369GbiFQCL1wsCe2K7KTBBMM4MXsDXR9vzMif0=; b=SLpXbFXHZ3Og2H+LXbR8LI4ZtjYF0qria6fbIP0frq2cKla2tLuvvC0r2aDAW2E/Ry UmHTd1eGG/ehYHxAQZH1WoCnMF3/5SK9tXTy9PAoCdo/RVoPMKLZxDXhrYzB1niMOYZk k6wK6Fh4V7syt5hCROC0y5OfUws3i8hiDTZMPeHMYmtYAgJP2fDpneMazroqSEH8FTqv 7QhnAh6DlFt4aii3KqoXEZWHfA+aTsN/WKvRvP9A5dbm/U++0Re6f6SfVId/4efbXL/p fkKqzZEEoLJPFLMjKrXw/Jf1DGg5CUChvHYMhZktfblf3letDMNWGCCRoT+dtJGWfDf9 CuSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=oPYYo369GbiFQCL1wsCe2K7KTBBMM4MXsDXR9vzMif0=; b=nkGrjf1dsS2C53Ny10jtPODaZylzCu2TF8tJoQDM+kEzVEz6bektS9slnjaEgtK+e7 6DGC/CYVjIe+txTO89Uh2Ea/akfys8fD3ByM+LT0q4WUIUdedef4hxq+qbSVVqpUiCsP QTNXnAr1wKWij2RJA2SCKURz7h7QeW6vljPBI8nShPMRMe1lf4kUVkJTNYI3SOklRZHu n8KpRHP7USZAgPKZIf2ZgZI3xjNLcnIsJZsB954/zwZjvtXRPLGYSgCnhyKHxshiNHn9 H3HX3CasEmtuFGlUmwXMYebYEZAkU2RdBfV0yKRqV4teewmW8man8Q+t/C8WhuEdqLvY BCtQ== X-Gm-Message-State: AOAM53144gojkOV+k8tuTLozTWgIYlCITjgABTZWt3Qn/H1RWk3m+kFo FH6Dg3aysy+kbR4eDstX7CsYxHecHkY= X-Google-Smtp-Source: ABdhPJxFBPdgSnutBIWIOIqFueMl4cRlP5iXCkMrd7HPaCGPDx2AwZXmKGQXN6Agd2yAuMvhA6ErJw== X-Received: by 2002:a1c:f314:: with SMTP id q20mr6799041wmq.154.1625767997477; Thu, 08 Jul 2021 11:13:17 -0700 (PDT) Received: from gumby.homeunix.com (host-92-1-116-226.as13285.net. [92.1.116.226]) by smtp.gmail.com with ESMTPSA id g15sm2643061wmh.16.2021.07.08.11.13.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jul 2021 11:13:16 -0700 (PDT) Date: Thu, 8 Jul 2021 19:13:16 +0100 To: ports@freebsd.org Subject: Re: Too many pythons in poudriere Message-ID: <20210708191316.3bb3ebfa@gumby.homeunix.com> In-Reply-To: <20210708175436.GA70414@www.zefox.net> References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; amd64-portbld-freebsd12.2) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GLPYC5qJ2z4YVS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=googlemail.com header.s=20161025 header.b=SLpXbFXH; dmarc=pass (policy=quarantine) header.from=googlemail.com; spf=pass (mx1.freebsd.org: domain of rwmaillists@googlemail.com designates 2a00:1450:4864:20::330 as permitted sender) smtp.mailfrom=rwmaillists@googlemail.com X-Spamd-Result: default: False [-3.51 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[92.1.116.226:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::330:from]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.51)[-0.509]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::330:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::330:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[ports] Reply-To: rwmaillists@googlemail.com From: RW via ports X-Original-From: RW X-ThisMailContainsUnwantedMimeParts: N On Thu, 8 Jul 2021 10:54:36 -0700 bob prohaska wrote: > One other oddity: occasionally one see in top a > PID using more than 100% WCPU. Is one thread occupying two cores? By default top shows information about processes. Presumably it's one process with multiple threads. From nobody Thu Jul 8 20:35:12 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 129D811F69CD for ; Thu, 8 Jul 2021 20:35:26 +0000 (UTC) (envelope-from admin@puredarwin.org) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLSj92c7yz4p8y for ; Thu, 8 Jul 2021 20:35:25 +0000 (UTC) (envelope-from admin@puredarwin.org) Received: by mail-wm1-x342.google.com with SMTP id a5-20020a7bc1c50000b02901e3bbe0939bso4873387wmj.0 for ; Thu, 08 Jul 2021 13:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puredarwin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=nkWK/mxeejUofcGdrm+lKcY2uWo2m03HOHgr0Ti5ivY=; b=H7dvpsUyagymlcuaDbxdcDbjUjPuaVTgkCmiktxVPNmGqNkzgLR49lfPhRmDOPDXE/ /Sc1u9/Iys0uoO4OU+r7oLdy3q0J6rZ7jVB3Y2doA+nGOchn/+aIvFuHowRpv+tXnyMr fMFY7u6XdXoJLm/bLe187lsQfvCKSpAtmRshNZhbifvM5xxCO40yxXWL7BixkPKtX/2W 9Phs2nL0eP1Z61ZCiYR4dXYV6Sylq2ykOvkzKi+rxWf5oXhvi1Nfk6yO71plbl+vX20A GnHFCfH1jkYhjISgvi3peZG/ie1w3LsJaRXuD6EtVpMVdlCp+M8raEFIa2O/XgqtftOz fhww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nkWK/mxeejUofcGdrm+lKcY2uWo2m03HOHgr0Ti5ivY=; b=b8j7Md0iWkevdNbJzdOO2aDpgEQOyG1MBv+nzNshLyMIjixoZ8xuHjXFUplFsR5ctR 982P8qHOZ4DdNi++Rdv+WHzl9bxlRbI4S3M6eE/UA+s35FCToz6DuPF1a3o4Arl8UA5O NlvtrLFGyOYsRrD5EEApjuDzX2PwigezMchAUhqjuMb3Mz2OROl0GGG3B3PeTcJdnYh5 oGdRKQ3n6n7u4x2f+RX4wmV0Qeqp58t/lWsdhPd5zTuBFEuwA8gLyZJpdnJ9Qnol1SLt dLr3ho0Rie6Lp8FkikkWVywAlQMOzim0iqcSiKIfBugilI6VS9NxLnBmPY4dyq5DAwYn GUHw== X-Gm-Message-State: AOAM531ItPGb+wvAcDgfPL+SmYqU+cWtpPQ0prwoGS6eIpLIdVRR8pKJ x7LNEJ2208CjA/iEd3zHN2eLmzpwOiDAiYKTVe3E4gfkQxif1FXKDo70YN4p X-Google-Smtp-Source: ABdhPJx01NeJLgQw1QZ3pvPr9pg/wGUnKQ6MwfBvaon+XX5NqNixNhrqui7LRw0LBcekDyH8GeZnWPPF/0hqWlcknxI= X-Received: by 2002:a1c:ed10:: with SMTP id l16mr7330234wmh.8.1625776523785; Thu, 08 Jul 2021 13:35:23 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 From: probono Date: Thu, 8 Jul 2021 20:35:12 +0000 Message-ID: Subject: Proposal: Include the Application Name in Ports and Packages To: freebsd-ports@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GLSj92c7yz4p8y X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puredarwin-org.20150623.gappssmtp.com header.s=20150623 header.b=H7dvpsUy; dmarc=none; spf=none (mx1.freebsd.org: domain of admin@puredarwin.org has no SPF policy when checking 2a00:1450:4864:20::342) smtp.mailfrom=admin@puredarwin.org X-Spamd-Result: default: False [1.54 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[puredarwin-org.20150623.gappssmtp.com:s=20150623]; FREEFALL_USER(0.00)[admin]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.46)[-0.462]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::342:from:127.0.2.255]; DMARC_NA(0.00)[puredarwin.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[puredarwin-org.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::342:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[probono@puredarwin.org,admin@puredarwin.org]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::342:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[probono@puredarwin.org,admin@puredarwin.org]; MAILMAN_DEST(0.00)[freebsd-ports]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hello, This is a proposal to include the Application Name in Ports and Packages. Happy to hear your thoughts on this. Kind regards, probono Terminology ----------- Application Port: A port that contains a graphical application and hence has an Exec= key in its share/applications/*.desktop file Application Name: The application name (as intended by the application author). It may contain uppercase characters, whitespace, and special characters. Examples: "Qalculate!", "KTurtle", "SpeedCrunch". Port Name: The package name is lowercase and does not contain special characters. Most frequently it is not identical to the Application Name. Examples: Examples: "math/qalculate", "lang/kturtle", "math/speedcrunch". Package Name: Same as with the Port Name. Examples: "qalculate", "kturtle", "speedcrunch". Situation --------- The Application Name is the #1 metadata that should be shown to users in application catalogs, package managers, app centers, app stores, and so on. Basic tasks should be simple. Knowing the Application Name is a very basic task yet suprisingly nether Ports nor Packages contain this information: Currently there is no way to know the Application Name from looking at the files in /usr/ports/, and pkg only displays the Package Name but not the Application Name. App centers like freshports.org, OctoPkg, and GhostBSD Software Station hence also cannot show the Application Name but have to resort to showing Port Names without having to download all packages first, which defeats the purpose of having Ports/Packages metadata outside of the packages themselves. When BSD was started, it was centered mostly around command line tools, which usually have names equal to the Package Name, so in the beginning this was not an issue. But with graphical applications, this is no longer the case. Heuristics ---------- 1. In most cases, the Application Name is contained in the value of the Name= key in the share/applications/*.desktop file of the main application contained in the port. 2. If one of the first few words in the pkg-desc file is the word "is", then the word(s) appearing before "is" in the pkg-desc file often contain the Application Name. But this heuristic breaks for descriptions that do not follow the "X is a Y" structure. 3. If the port contains an AppStream metainfo file in share/metainfo/, then the "name" key in the first "component" element often contains the Application Name. But over 1,200 ports with share/applications/* are currently lacking a share/applications/* file. Proposal -------- 1. For Application Ports, include the Application Name as a mandatory key in the Makefile. 2. Add checks to Ports tooling in order to ensure consistency of the Application Name across the desktop file, the pkg-desc file, and the AppStream metainfo file. 3. Populate the Application Name for all Application Ports (doing this initialy can largely be automated using the heuristics described above) 4. Once this is implemented, adjust pkg(8) metadata and tooling to bring the Application Name into Packages and their repositories as well 4. Once this is implemented, adjust pkg(8) metadata and tooling to bring the Application Name into Packages and their repositories as well 5. Update App centers like freshports.org, OctoPkg, and GhostBSD Software Station to display (and make searchable) the Application Name Best Practice ------------- HaikuDepot, the app center in Haiku, is using Application Names: https://www.haiku-os.org/docs/userguide/en/applications/haikudepot.html Interested parties ------------------ * GhostBSD: https://github.com/ghostbsd/software-station (confirmed) * helloSystem: https://github.com/helloSystem/hello/issues/173 (confirmed) * Potentially FreshPorts * Potentially NomadBSD * Potentially OctoPkg From nobody Thu Jul 8 20:59:52 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1B41612228D5 for ; Thu, 8 Jul 2021 21:00:02 +0000 (UTC) (envelope-from tatsuki_makino@hotmail.com) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254059.outbound.protection.outlook.com [40.92.254.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLTFX5QMSz4rsb for ; Thu, 8 Jul 2021 21:00:00 +0000 (UTC) (envelope-from tatsuki_makino@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XUTwKYipt0rqsFHwM15wwwx360e/BCme3c4f/N73tQjw0wgN1U7StrVqsVNv1JdMaYw6uPmc2Nb3CO1f0kKVcWdVm4f253pWZmPA9o+J0e6tcUYRhNlvf10vZ9fb7GPEEVtY8VXRoa3a7on6qvPbOa4SYJMBC+75gbugqNVWBRoTQTH1IUkguJFefNUhP6IdRuxg9tta5Z3OKI7Ez6Uu7VSteVYPqV6PKaNZaNZDLkefyvuGPkBdC539hLo/6YvHrsWzlaXE6QicqGv0wzU509SSaFyNKpgoLbwvMdC5cWvFzU77IP01iUOVcua2Is+NWMs19di3SpKaosPMebq5Cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ni3OKLOmZKVj8KNQ8j4elnCbCtpEhRGITu2abG5vvVU=; b=bvXiWwUJOfFwj3hdGK2rcZ6popEhLg7r6MnAf4hjtuFMps5wmvh+KtyquDckcpMY8g2/ghgDCaGIETxj8GiISTwU0yp3bmH3gm4QEYINTXE8k6ZWnSS/lbDqmT0022kVQXJ7qVoGWfzWynC0UIXQkRVgpTB6PSs9BFOMcawSWe+6BDUFyq9eXYiYhv+LzDKSQJpT9ikvw2PzWhdPWM7rOdQCkdfmBM9LbzANsayKLM1M4I7rb/cQTyhdbB3x1s8RExGCmJjL4580VJGvucwtDcTDgQkSywzWa8qRJlZGx+UcOwvXKeQQcoiiump9DaZVafTwiVIlVaqoFHN4uQU2Ew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ni3OKLOmZKVj8KNQ8j4elnCbCtpEhRGITu2abG5vvVU=; b=qi2PzdEq76Vw8Mw3oYW82eyziEcXtgh+KLCq37Wp4sx0rL4YGp/zlCiTmObUTdn2NlhAEWiNxY4DeGOBEyTbYOUhV/rojqt6afmM8pnj1e5A7m/qTZLNE5Jn/SLLrGk30yrIZPVV7MNH83ECeNEcbyE0Dp5XDz3ULvDKDxC5CVHBnw1LorI6GfFGLLASqpsB4Qz7yYFfhmbCnh8Fdjp1tK7yZuWhedJW8lCp56b77N0FugTZU7C77juiXHUV9qlHIz5c5/LALKX+oHYRvFDifbL7U46JyGGrcKbSJgVsi+3ZfGjljvfr0dw/mBa4tEkgHLYju35U7xQLEuVVt40OYw== Received: from PSAPR03MB5639.apcprd03.prod.outlook.com (2603:1096:301:66::13) by PS1PR0302MB2506.apcprd03.prod.outlook.com (2603:1096:803:5::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.8; Thu, 8 Jul 2021 20:59:55 +0000 Received: from PSAPR03MB5639.apcprd03.prod.outlook.com ([fe80::8493:3be8:5755:904b]) by PSAPR03MB5639.apcprd03.prod.outlook.com ([fe80::8493:3be8:5755:904b%6]) with mapi id 15.20.4331.012; Thu, 8 Jul 2021 20:59:55 +0000 Subject: Re: Too many pythons in poudriere To: bob prohaska Cc: freebsd-ports@freebsd.org References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> From: Tatsuki Makino Message-ID: Date: Fri, 9 Jul 2021 05:59:52 +0900 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 In-Reply-To: <20210708175436.GA70414@www.zefox.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TMN: [1+BXNr0UobYS+BigkSyJRTJnkgXhpI0O] X-ClientProxiedBy: TYAP286CA0030.JPNP286.PROD.OUTLOOK.COM (2603:1096:404:8014::17) To PSAPR03MB5639.apcprd03.prod.outlook.com (2603:1096:301:66::13) X-Microsoft-Original-Message-ID: List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from T4.test (121.95.68.68) by TYAP286CA0030.JPNP286.PROD.OUTLOOK.COM (2603:1096:404:8014::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.21 via Frontend Transport; Thu, 8 Jul 2021 20:59:55 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cc509605-51d0-42b4-768b-08d9425356c1 X-MS-Exchange-SLBlob-MailProps: KvCwBtHRxSmQ6DqpnqxGNHoZBVgkhKofPj7hCxlpnRKI6sGw4I5EWFHHaHQknU/y9rNs1jvqj1XKvmf91ToifFGHjewdHD4mF5mmqWyKgnLFVdq+TxwOfDUz+KVj3ZdS+vbfsSXbnoXzVuxJuhC1fSqO/XrsJwnj8WoWZyizDMeYvYfA5wmt4/UsfZ8DmUb6AV7wwgLRaQzuWkTp7OIPXQ9eg1gipdiRW9jD/2T2bYxbVl4UC8ry3CZjrXfxKD0as7QfZxqAzVw6odqVmNtyJJ0BD5oARgICk47Ibnf+FXTUuoD2NbxMh+7GCW1lawH638MmVVJEdxVeLxfseKVlzWTPE+sQP7OxeEaOSy9GeGXUCh7CmS1/JQ3yYkZK3jOahOAKVyseXWJqGY/Q/0HE/rA5IT9REWUekc1ofLtCbHO/jLUSsUkIhQaelOp65ip+1LRDdEN64MDx36+DxTfOoKHo5+N5g8lIBY3opZ5Tbx23baHlxeUUfefGwj2rDgwvWTslDrPxQyTSiWa0jkIE1hA2BGTcRBxD+WOCWf7ngRVdgogV5/mID6UM7vQjhqdKo3M/yMCh11c73NmyLbiyolxhyjXZWtkQ+uPWpiRe0FFF4vNWc2Q1g99DHPcEVWSIe2m2u6KIOAyKOX+SU/n2hrCIgqgF/aQe X-MS-TrafficTypeDiagnostic: PS1PR0302MB2506: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: guO798fx+LNfQDxczsjQN3Np23tF6Z1wtbPCH62/cZTUXpHYDA1M1xt+ziRD+zs/pdMzHyPCWIjBGvUdPhSDUiGXY854VtNPISPoYAUFrFmpa7GK44KhVHy5MG0EwRy+2BtiqEkmDQRwAFc++s5JzOB+jz8Jh4s7dRZQaDq7Zp/NVu4PEP2S0yUzHbfDc/7i8NVh3DNZGTJW1srxSJ5ZcbDB8H2wjPkIidtoy7rMqQjA8jwF/kmDG/CoZQhqCjjMVtzm4dhHa+of/FRFJdYh0ta6pTRjr3SUcZ6A/nDM3GFNqoAlH6mtYuVxr2VpxO3G35OPQDB8HQlVIhQB+LloCgZDtx7wa35T2gUTkB9djHmIMD7bBJCFN8L65CjGH/MPufLj9whHXtkwV1VtyB+rR4/mN/Jk7SxwMsnMPH+u3BTm/bKV8yo3/QkaDJ52UGOz X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 387JVXUN05tcWP1+6TdJalMqsnhHP9NbrgEfF/NFWkgxUJphgJ0c1EfiyW4D7wr3I5g990aaBZ7ksD0BoUeuYmoCHG5zfSJ5gJZRqWjwKBJzpCa1N1LQwO5h9IvEMWEdwfy3FTguZO9BguzkAdi3KQ== X-OriginatorOrg: sct-15-20-3174-8-msonline-outlook-792b7.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: cc509605-51d0-42b4-768b-08d9425356c1 X-MS-Exchange-CrossTenant-AuthSource: PSAPR03MB5639.apcprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2021 20:59:55.9105 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PS1PR0302MB2506 X-Rspamd-Queue-Id: 4GLTFX5QMSz4rsb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N bob prohaska wrote on 2021/07/09 02:54: > Started a new swaplog: Connect a USB mass storage device that you have no use for. Mount the file system in it. Create a file in that file system like dd if=/dev/zero of=/mnt/somefile. Attach it to the memory disk like mdconfig /mnt/somefile. Add it to the swap. Ask Mark to explain the details to you :) From nobody Thu Jul 8 21:11:43 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E1CBF1224B0C for ; Thu, 8 Jul 2021 21:11:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLTWG4YxCz4v3l for ; Thu, 8 Jul 2021 21:11:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625778712; bh=HXJfEonMycDgNGThSLFSX01kdYU4cCVKpW0FzYWAcAo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=toBvKtHllhy94+2yX45GnY/kXiaBd3DpLN5rj5hgleAVgLi/THpjMoObjHTR3wH2rAe1UvstHWiZkrvstV//h9/vra7XqTAK7D1T8a7rHoJHkK4IGlyNpYY8xH3auR8XhUpOR7IHOdvJGppTBINUIP7+p+ZOJ+O/5jrdQNkUm8Sttf/iUUDGCIT1eKNuyOROSvghZnbJ5bcZLA0YgmI9ySpm3fqrscxn+jpS76p6IVsnAlVqsj+MPro4r2IKpO4+4hDsnzEk0pQPUB27t4FWz97iJ8r6k5NTGgn26U1NA0CSEUI8TGs5TtqxjNkKYepNIbjUkenElyJh7/eiSHgdKQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625778712; bh=Uk0UbZOBLTqZljtPGZFIC0vv6PnOLEaV7K6IvQwq+FV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DKbE4lkRnF0l3MnezX7upNdn+cXgH0eptWLc71exNvA2rl1DRyzQE6VhrzULio4evuSMGoFct+y/kxeWvh6XTPDA5ulzwcNZwaL+TEbGJlCx1aDYDBOQnKeyLiZ2vULCwsd2Ksn6xQGiV8KUmw/a+DZWZugHeyZY/Bn4PsVf/I+1oPz0rEr9lvz3legk55vW2kkXgoMzEdgTjSToi0fO8ky5iFBTFJ93zadOO2A/GmlxA7NgwMGNXA8KbD4j5FP5PwaFwxZw0LJooNdBx6WPkucSRvh0Qq8DN2Y7umwSsz4EhBT2QPMsmRl9X8pA62NgMJUe4yHQTwKQw24atue+lw== X-YMail-OSG: k2AmuoQVM1l86SMX38lzPRbxC8ihzaNkUwI1NFEKu26ZHFUuPzm8RHvvOIGLy2p diHvBqmA.jL51rHdE7FQlcJL6F8s.pLhDJdZUFE9dCYumpKA4ThxK01R220Til3em122HmtQA1eK CdvDHcaS5eEOh_wbS2Z0iaOX68UIuxvJ37sBgz9ZvyelUPrdnrPZPkI1tc28w49iILaEW259DxFi 3vctWmg0OP5PjOe2ELJxYLubtdD7xQ8Mg.8FiB4kBYzVPzaxSBsEpAwQ2LTW1wbhcpqxvsAkJm4g MrclPMT9k2Fx5gCvPUhdYjsoRNnr9HT3ukXYUe1f8awhAfNsQfQvKdfrZwqHpmNMqkQ7TlPbBgyP _1_ikdy7ziNNVy5E_351CTZmJJlexHqyuNRuHuY0ZKAWMWHXecGdgA3rSBWYDFl.g95XuHlnQ4kY ldLXCo2dZU8d2Dr0W72Q5b4_T39ifVst6ZFLMLyJDRILl_4jFfn86SbCYYUP3yUdFrVeIRM2vzyt 47V48K3pXQRZ0o_z92cjoM5uw0oQYyQX8l1vbW2aDUXPJX90hNrpMXttel1dfrMTOMt6YEtyn31g 4nlpFt_cHoOz5PQlpo9AMfQ6QV3FYAc8jbnQZTxsaLMRiGREHd8lj7ObFG3uskNUfZcj7xz6d5un TCQ9fAiKVdpZYuCKa.4mCPChOtxzjBLntAgXo6WmRtY3Kj4IYy44cMTyG3Wh78QJo4Im8GCN9MuK HgNHMsG1SeuZm5deIJYjObBzOTEu.jjI_AGM9JUYuqcCqnUz1zfw0lz9w3kz9uCOiLLtXuTFqdR9 wkAZE8WMzkocirBrZ296ht9cEhNK7hHYll_NuhMnViycQ8IFAKxV0kAvd6VwM7wqEefiKUGDVhpq R4.9jqLHgUfGkqnYWF.YXT234VFBTvzmf7R.KlGcM3V4.87AJdLONtZzJ9VaN4XmWa71l0vLHitr Nj8bC6QTHfEftjnu2nC80WueSFoIxwh22nC6hRHMjP2ZWJjpfylIOVLBgVe1XttrllkhejT.qyUk IPsSSYWKdmrowYha4I5muntsUzBntLYw0XkFYE4R1cjkdRFtilKYjsFrwiC_CyCo8nOfHfdBAA.M XMdilmIgUmd9bi70ONoYHZSzBPQaNyiBONaDu_H7RZMocXuyr7b1naPkkks_y9FBjn6hwmR0tnb3 PgglgUWo9mrQYg7gZtoKYm2g6NhmBZzOowqpi9UHgtBonZjpdBBur_pCeC5kBNlXsp8LC1wlSOhN rsOzzbyrECC72FkvQVCnr3P1NuhOklbg00v4rO.TxgnGaL_KTieTiVaIGXnHiv3JcDaF4TxEcr21 C8lLGR7deUuC2ygEML4mer_Lfmo5LNOkuFfwAqa0hgBBMATXWa7k6EMVUf1Tk3wiL4vIqqQMWMAg XifQwdAM_PVAzvAYQp0qF9eyLrIQUEEcBi0HOrRtEvWK9VCsLqCRnj5vyX0H.XyxFUseO5bU_cWa C0cnsMojhf316DOPRbbg51jpyHvEjUM6vsLbh1OBqOUZ6jKGehMuFmdypXnzXX2L5VK8mLC0_U10 aix89Ks0lFl0okM0HUgnQy1QDr_Gy0dnAMvpQXyA_g4FbkcCGBV1hxk1UptyDJjn.CFKldbYBc0f KK7ezLIoc0e8H08.HhX4BTdMeQQFVPAdaM2_f13ytcHW78476jNPSNnT3ZAvOQDYTWqu3f_M.EE0 4PgnKUUoDi1DsH4koGA6W.xqiS94haJihc4nPIYcxF5AhayimJab8sHbyq5QumOGTRTZs7Y_HHYM Q7wagu1pZfCEUKsAee9Fe6HBVRwfLmYtiafu__EKSu.qaE.tTZTvekVj62haKx4k.oVeL6u8ArUQ Jf2njl0.lje6GsWurvCYdSLAUlj.wudqlzo0mxPwc7phXfg03ck5BVAXJbAXrQyPlu3a.5zakxau Iyye5AgJTec_YoVAq0WINRfW3b8jdI3mlOVfBxtcVruxlKRO4Njba83u_vvGoZBaxsxewNIJaOu6 D1CO9mmvEXpGyMEMN7.ofZzhYGWxJp9S5qah0n4vKHGWRfMgZ_FmHNCOJfqWmmvxiAxkGe_s.xV3 lnx6LODHeMH9I926ZBEGNcBv8ZUL.oqh5YgPYOop1ODXPeUtCzM8G4sjaC7.DH0iiRRvEKrr6t6B ySaAUm6nKNKIyOFP9pLIkh4.bKuRm9CMeKWT46Oi4K8VPFhSQmeDgUrNV_SaLjXUczfdz.lT0PIL puTndOlozeaOqalmCjwHRbjHXpPy6K5gG7v41AL4STEsD4z.8sbg_556FLQ9sAx27cQXHPjYHTXi YpJSq.aEoPCll8B1gvBOUdvaHKw_s5lZwpf3oINWwJ8UyK7cUiBuddyoJppc1uNnpT8NqdnaOuOX wkOGNlQnmOaJBysHwXN_WQ6hN3tmkPPM9EjY5IWeNqKQweZ57JKAf5wivQwGpQSqd3rYzxfn_cHk Eruv.43Sr712a8ntwMJqtrKnTrzjPMytecA2rfrTRm4sXl5kCISfqL9clPraCdNmDqieBjSgrNAT S33V1UBf8sQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Jul 2021 21:11:52 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6fc7813bae8c6bec61a763c36b9f014d; Thu, 08 Jul 2021 21:11:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: <20210708175436.GA70414@www.zefox.net> Date: Thu, 8 Jul 2021 14:11:43 -0700 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GLTWG4YxCz4v3l X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-8, at 10:54, bob prohaska wrote: > On Thu, Jul 08, 2021 at 09:41:13AM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2021-Jul-8, at 08:45, bob prohaska wrote: >>=20 >>> Even with -J1 and no ALLOW_MAKE_JOBS I'm still >>> seeing five pythons occupying at least 3 GB on >>> the loose. >>=20 >> Actually I just looked and saw: >>=20 >> Swapinfo 7.36% >>=20 >> (Unlike the 83% or so I saw somewhat around 3 hours ago.) >>=20 >> Load Averages (220%) 2.20 2.18 1.76 >>=20 >> Elapsed 12:54:56 >>=20 >> I do not see a swaplog in http://www.zefox.org/~bob/swaplogs/ >> to look at. So I can not see how much the peak swap space >> usage was so far (approximately). >=20 > Started a new swaplog: > http://www.zefox.org/~bob/swaplogs/202107182930.log >=20 > It came within a whisker of running out of swap, then abruptly > the python threads vanished and the build seems to be proceeding. Did you update any thing, such as /usr/ports/ , between the 50+ hr run and the new one? The new one spent over 6 hours at: [05:50:59] [ 8% 3914/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools ../../third_party/blink/renderer/build/scripts/make_names.py = gen/third_party/blink/renderer/modules/event_interface_modules_names.json5= --output_dir gen/third_party/blink/renderer/modules [12:22:32] [ 8% 3915/47953] python = ../../third_party/blink/renderer/bindings/scripts/generate_bindings.py = --web_idl_database = gen/third_party/blink/renderer/bindings/web_idl_database.pickle = --root_src_dir ../../ --root_gen_dir gen --output_core_reldir = third_party/blink/renderer/bindings/core/v8/ --output_modules_reldir = third_party/blink/renderer/bindings/modules/v8/ enumeration = callback_function callback_interface interface namespace typedef union [12:22:36] [ 8% 3916/47953] touch = obj/third_party/blink/renderer/bindings/generate_bindings_all.stamp [12:22:39] [ 8% 3917/47953] touch = obj/third_party/blink/renderer/bindings/modules/event_modules_names.stamp [12:22:42] [ 8% 3918/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools ../../third_party/blink/renderer/build/scripts/make_names.py = ../../third_party/blink/renderer/modules/event_target_modules_names.json5 = --output_dir gen/third_party/blink/renderer/modules [12:22:42] [ 8% 3919/47953] touch = obj/third_party/blink/renderer/bindings/modules/event_target_modules_names= .stamp The 50+ hour one did not: [03:56:05] [ 8% 3848/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools ../../third_party/blink/renderer/build/scripts/make_names.py = gen/third_party/blink/renderer/modules/event_interface_modules_names.json5= --output_dir gen/third_party/blink/renderer/modules [03:56:05] [ 8% 3849/47953] touch = obj/third_party/blink/renderer/bindings/modules/event_modules_names.stamp [03:56:06] [ 8% 3850/47953] python = ../../third_party/blink/renderer/bindings/scripts/collect_idl_files.py = --idl_list_file = __third_party_blink_renderer_bindings_web_idl_in_core_for_testing___build_= toolchain_linux_clang_arm64__rule.rsp --component core --output = gen/third_party/blink/renderer/bindings/web_idl_in_core_for_testing.pickle= --for_testing [03:56:06] [ 8% 3851/47953] touch = obj/third_party/blink/renderer/bindings/web_idl_in_core_for_testing.stamp [03:56:06] [ 8% 3852/47953] touch = obj/third_party/blink/renderer/bindings/scripts/cached_jinja_templates.sta= mp [03:56:06] [ 8% 3853/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools ../../third_party/blink/renderer/build/scripts/make_names.py = ../../third_party/blink/renderer/modules/event_target_modules_names.json5 = --output_dir gen/third_party/blink/renderer/modules [03:56:09] [ 8% 3854/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools = ../../third_party/blink/renderer/build/scripts/core/style/make_computed_st= yle_initial_values.py = ../../third_party/blink/renderer/core/css/css_properties.json5 = ../../third_party/blink/renderer/core/css/computed_style_field_aliases.jso= n5 = ../../third_party/blink/renderer/platform/runtime_enabled_features.json5 = ../../third_party/blink/renderer/core/style/computed_style_extra_fields.js= on5 --output_dir gen/third_party/blink/renderer/core/style --gperf gperf [03:56:09] [ 8% 3855/47953] touch = obj/third_party/blink/renderer/bindings/modules/event_target_modules_names= .stamp The build step numbers are different for the same command: 3914/47953 vs. 3848/47953 (But I do not know if the build technique tries to keep the partial ordering for build steps stable across build attempts from the similar starting conditions.) It almost seems like like a system level check in what process(s) have large amounts swap space in use would be appropriate when this sort of thing happens, not that I've done such before. My understanding is that top's per-process reporting of swap space usage is problematical when the display is set to display such information. > I'm curious if this was blind luck, or some adaptive behavior > by poudrirere. Poudriere does not control chrome's internel build steps. The notation like [ 8% 3849/47953] is not from poudriere. > One other oddity: occasionally one see in top a > PID using more than 100% WCPU. Is one thread occupying two cores? A process can have multiple threads instead of just one but each thread runs on at most one cpu (core here) at a time. Top can do either of: A) show a count of threads in each process shown vs. B) show a line for each thread instead of for each process Top can also display the unique thread number instead of the process number (shared by all threads in the process). (But not both at the same time.) Showing thread numbers is probably only commonly selected when (B) is in use. In (B) mode, if the process number is being shown, then there will be one example of the number per thread shown that is from the process. But I'll note that, if I remember right, python is a single threaded language. It would probably take use of language bindings to other langauges for multiple threads to be involved (indirectly) in a python process. >>=20 >>> I'm fairly sure this didn't happen >>> when using make by itself (IIRC it was -j2). It did not happen at that point in the 50+ hr run either. >>> I also got rid of the mistaken directive in >>> poudriere.d/make.conf. >>=20 >> When I look at http://www.zefox.org/~bob/poudriere.d/make.conf >> now I see: >>=20 >> ALLOW_MAKE_JOBS=3Dyes >> #MAKE_JOBS_NUMBER=3D2 >> #.if ${.CURDIR:M*www/chromium} >> #MAKE_JOBS_NUMBER_LIMIT=3D2 >> #.endif >> #.if ${.CURDIR:M*databases/sqlite3} >> #MAKE_JOBS_NUMBER_LIMIT=3D2 >> #.endif >> #.if ${.CURDIR:M*www/firefox} >> #MAKE_JOBS_NUMBER_LIMIT=3D2 >> #.endif >>=20 >> which does not match your wording. >>=20 >=20 > Thank you for catching my error. _now_ it's fixed. >=20 > [snip] >> To see what is getting CPU time that leads to >> the load averages being around 2 might take >> using something like top sorted by cpu time >> and watching for a while. >>=20 >>> There is a=20 >>> #MAX_MEMORY=3D8 >>> in poudriere.conf, presumably GB. >>=20 >> Documented as GiB: >>=20 >> # How much memory to limit jail processes to for *each builder* >> # in GiB (default: none) >> #MAX_MEMORY=3D8 >>=20 >> Per builder, not per-make-process. >> Within a builder each make-process shares >> that size space with the others. >>=20 >>> That >>> looks like a good knob to play with. Would >>> setting it to something like 3 or 4 help? >>=20 >> If the memory use exceeds what you set, the builder >> process is likely killed.=20 > [snip]=20 >=20 > I was hopeful it might inhibit starting new PIDs > when memory/swap is below some threshold. Guess not.=20 poudriere does not control the internals of the builder's attempted operations beyond what the port supports. (And there are not port-specific interfaces for such control. poudriere treats ports the same way in general.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jul 8 22:47:17 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1CF268D326D for ; Thu, 8 Jul 2021 22:47:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLWdR0MHdz3Qgm for ; Thu, 8 Jul 2021 22:47:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625784441; bh=TAO250dI6V8WDMN7Vx73llPYhDimO3CCWOrGbRQGvTQ=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=nbeG1XNMDipgT28qxEYlEbyuyHKNXWK4P5OKzDPHHUT6Drt8+58E77eqmsFildaMXZ1fii3Cz6Zehs1pSx+VIaeGXdsq6ReVJHmXICknQo8m084oiCSEI2rV9HG5rzoBDcvck8j8b2BDUy57df7wtFCqpNyQNEQIeIIkWNV/IhArhiwFve4899SYeTlCuU3ganHx3fl1saBS+JVCNM1KMQae1QQigB6oGEBDBnBFk1r+7/aVNH+/h3IJ757YT4XCc7GYo0r59CcVbx6c9/Y0pfuqpBjbOudu+pnCSFiPx3k7JPBZ4v24MeeHpuN2wA1DXqgGusUMSLbNuTcl9wy/Yg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625784441; bh=nUl3WhNM+14Ke0G72JoLcccMbxzV/DWgFkF3VUURtaR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=I8REroaNHi3/armO0qG53C+trKE1k38BnKK5A1CC6apmmqexv20jcMVQngkwq24xq0HsbGFlCSXVlVrXiVdvBdymX7ftEq8Q4538fMMpVzvqZipEhPRhjE0xMycr6l2Pz0tb/lyHVHPwXM2oJ1uSTd7UpW6Bj4X8JCXVDcCpgLB9L2TV0u++O6XPGbKYD1fPCavCo83IOhnkMu3CgKq3SNL18pjE1qkBlJIjt8i96hQEJLaS6hZ0pLSQ2Wc2CNXRk34Okptr8KEscwemoaCw1DgrqxDAumxGlKPJiDSVXJysbb8ZlT330xp9mvyeuPqLYcMy686bco2qN/wls0zH8A== X-YMail-OSG: jLNpzTwVM1l6by6MHVuU5QEMHOuFn1Tn_YNeHo9vFKvuq9wadRHNa1swz1NJ_cC dEaAhywhg84Xq0vhtwk9wZi8mlqA5ZGeld5H5V84bKkuV7rVOc6zexXbwpRvLAuqNsLOlwaJtPss RuBYGhFGrfyqAhg0Mzqv284KZ710N09aC492zXV0WWTsmmFJwZTEHlG9aN2mB8RK2E.WvwseEuRx 9SOy7_kVuMBcbSre41sQjKcyFhu3e5UB6DbFHCKQIxHoA1yI7P7iOpO0KEPR0bBgMcUVINcphZjY KeqWQDehjJZFlFMRUhJxMSHGaExk8736F7brvZCtuMqmwqgF0YNcLsyapyqywGkhFMVDds4boBWI GqXIYD242oZONsWrsY_QFXyVd2gvKGrEb6DBybuLQS.LjADHqj0eBrMefy5kL5att2RwnTXJUxLu diyxWvo_9nKLS1FQCsh4pvilOWwrPjaC5I93shtspfb1BmFAEc30Yy1nwwYZSHqDHmhs0nHdw7EV Qn8arvIpvlbpt6psR.wbaxPaYeV.flbsNx_Hdk0hHPHbZSAcRCf7SzY23u7OcGD8gwuljspZ9_IQ vYn9EDEhzzKTfFAvQmBf0B5KZQj3h5yvefNVl1Dn3De2QzvpwayGZvN5cZ4LwPQ4fiGoApjzsIIY HeMAHbY8.7KdTsa5GaX8uuf1zQ183d_Kfpe26o3v1D6ATtdA3HAkyqzIzVUsLvI2PWe3kVJbNjQQ jOD6o8ZefY7G_J2Q2m2rgFxudH9mdXRsRFygibRFrE9A.rT6x1b57fnmylCyOl.o.XEAH8a5cZTX ha7.BanaRWMIrpoOrfZ1lQuPv6dapTxaAiDOQgZF1P.tQdKCdpqXAF_42bZyvDc6mqJq3O0VzSrr x1XJU9HF7rJqk79DNtej2kKnJcXAyjaDWnVwqVPsXRQRrE3GCfIIgpin8Oq3s9hrdqvxUpEX1b2p kMMdG2SFb08sd2bf0kAAA69NOkc7NxXJsuPra8YfalnxliEilUFrJ.UJX7sOgdRX1AA6jsWU90lw xBuv8OLZnHoaR_zWDWIVZ5jKi7I_RxbwE0a0HEQhJ14gT55gKVQsEKTeFIOH71dapSpCOiXZuCNR uetVrDSjPY5bS22HfREnFNTfVwgaODnIUY3CF3_V_3Ya1VbweKUWzN.vvOSuedEABDM6WL2gBOao oocZObPjyqXTO6uTdP8.geAithMOSefBjlnqxN5Gkng8ymnHgHXqL3wlNNGdwvyb.Fl9dVKCp2Nq IRE.7ffG8AU7OyW4sKV92WBEwkBgiKqxWmZvL5V69LmPiYW_kvZG2ocHZtaa2LrAlv3nGjQKtLQN Vb7qHD1ft9ndjSc.oAXWWUVbWAfZvVCxTLrhFGLDWipetA0B0n22lh68xCRdbduIegYEO1DK8vQX ZfL1uO7QqTnB_vPhjMeLku9RSjCXzaFApNxCote6cnByV0qlSIhloD09Ok4sf_V9xpVz5LD9h3Ya fm4XLOyLT8TGQWlgNo3TRfWfrKJmrsxG2rGD3Jp6U9NY6slpGggi2nGZxNPMK9O0Biq.VNPoJvTe Vp3hPqe5IrSEZ7bkhV1Zk1O6VBShy_dpCLi07ioqSKNok6kpS4HT29SESAAHaErA0.niv9kfgNl_ Q0bgfHrrpbcSqpBf2D9MU6lnGdzWgISvMv_YDOIDokFSViix7pNiwwgB65SRfjx0aUd9VPYQsSpK .z1sG0i73d6ghODF3C5puD0xzfIRbKJq_95EIsXhHh0cvYtAtTBc.qpg0NP6L4CH4e6Ji8GiA3mV cRb8mp_dHHCwi_t5DsehdFnIg5FLGBW1s.R4fTy8.bpjqf1O5uEUh874qH8WT.Xt95o4avMhkREX EI3zuSdILDvlIGKk0Fj3r6lwOycHZm9Fr3kcxrP56HcLACxtPasPPOsgUdr8H6mA9CH9pAizNoa_ c.B7haGKecYR0JZf44dZ0gR.f6_6Snyx2irrE8qM4p2JwGk6E.WvZcOiNwB4kMVWWr_nxVLs9Hg0 Qc6qVBByXQTJTuXJQ6nXSYpxEXi7I6FCms_gUO_44o3MdSjNbyuDu5y7hnCxE4N0hnkOKhddQGHS PWlPu.X8sK9ylcoVlp7wkl8lOGA4wNSpV9SqLWivf23HvfOD6VPQw4RUpYJ8YDHR141CFoQxtBAW t2EJECdr0lEQ8LK9Ulb1cW5u0Uwxw_R1hU__.pO4e7LIs6sSTqLGlGyTj.7IFbfaTel5G5dYbW4h kh2VwNPDwcLRmk.Ivsq7p595rcBeO2JtAlKxKsmpAdJYfgq4U8RDjmyekKsbGAAKG1IIYibCZ2Vk KJLvUldi.2YzYf9gU._yWddIPlDg7sau525aX.dDvBCG8Ww6zdyjVhwKqumTb4pBEfRnuyiTRHrA BAbJqxfkIkbdrNJPK7pfsnHrG5bTl2e4TbjDnC_ZQrXfDujcAqI3eHn_VBc9My20Sc4Inym5IQaf 9kJqh.O320681lFPoTK34jH.64.D0lNUTgoW_Pf.rdtqzTjpXi3QCb8zpSk77LStZqPawFbntCO8 L2Gb_AJeeDfL66JgeLVnDKjJH04fOZdRbgGEqRDaCgMABlO_4o5RSEFXVtrnmSz5tt2fgdUCLUue pfKAJAHrxRx7QDDmbMA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Jul 2021 22:47:21 +0000 Received: by kubenode541.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9103a0d63bdac73597ad51d4be392a50; Thu, 08 Jul 2021 22:47:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere Message-Id: <4A6DD11F-6C9B-4BE9-81BF-F5B6A40CC08D@yahoo.com> Date: Thu, 8 Jul 2021 15:47:17 -0700 Cc: bob prohaska , freebsd-ports@freebsd.org To: Tatsuki Makino X-Mailer: Apple Mail (2.3654.100.0.2.22) References: <4A6DD11F-6C9B-4BE9-81BF-F5B6A40CC08D.ref@yahoo.com> X-Rspamd-Queue-Id: 4GLWdR0MHdz3Qgm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nbeG1XNM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.82 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[hotmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.205:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.68)[0.677]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N From: Tatsuki Makino wrote on Date: Fri, 9 Jul 2021 05:59:52 +0900 : > bob prohaska wrote on 2021/07/09 02:54: > > Started a new swaplog: >=20 > Connect a USB mass storage device that you have no use for. > Mount the file system in it. > Create a file in that file system like dd if=3D/dev/zero = of=3D/mnt/somefile. > Attach it to the memory disk like mdconfig /mnt/somefile. > Add it to the swap. Bob already has the swap space: Device 1K-blocks Used Avail Capacity /dev/da0s2b 1843200 26944 1816256 1% /dev/mmcsd0s2b 1843200 26956 1816244 1% Total 3686400 53900 3632500 1% This is nearly as much as is allowed without getting swapon-time-frame notices of the form: warning: total configured swap (??? pages) exceeds maximum recommended = amount (??? pages). Bob may be stuck with a choice among: A) running the RPi3B (1 GiByte RAM) mistuned such that the above messages are reported (or adjusting other kernel tradeoffs explicitly to avoid the message) vs. B) building www/chromium on another machine that has more RAM then installing the package built on the RPi3B for later use vs. C) giving up on building www/chromium at all, using a pre-built package vs. D) giving up on even using www/chromium on the RPi3B. Bob is familiar with doing (A). I'm the one that requested that he try not doing so as part of trying to isolate a problem building devel/llvm10 . That problem was later identified to be a different issue. (A) does make other kernel resource tradeoffs, either implicitly or explicitly. I do not know how to well manage the tradeoffs involved so I never recommend (A). Others may know what they are doing for making such tradeoffs. However, even if Bob does (A) there may be other issues that he will run into. Form build attempt to build attempt he is having problems leading to massive swap space usage at differing points in the build. The same step sometimes works fine and other times fails. This suggests another issue may be present (racy leak?). > Ask Mark to explain the details to you :) I would never recommend using files for swap space on FreeBSD, only swap partitions. See comments 7 and 8 of: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 for notes from Konstantin Belousov that lead me to not do so. (8 is a reference to other material.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jul 8 22:51:38 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0FFEB8D4504 for ; Thu, 8 Jul 2021 22:51:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLWkT0pV4z3RFy for ; Thu, 8 Jul 2021 22:51:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625784703; bh=QUZ68WMaAo1CQe9wsJ8U7ry4lxVcmAnr796CT2esKSM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=k5HVW3NbThDqGtRqiO4eh89lcWKcnAtbSAUHx50qNFkqhOi56DkdGzy/XOupwcKFvd8jRB1jaxD5wRRDVVjeY9u5S81WqwrfQyqyis0h4+EyhEdJ/m6R6CsVNYoSuEwHAPztJuOyCOSnDHbmrpu4hVVD4++fXl+rczXPAw1K+EBgpHBCw6Ybs/NopKRLk9yGWWNScnshuSZIYyJjq+7QqyVwvrRCABuKwmMax4JwffiT8nhbCnxG5jENwn5eSxZQedzfBdTei3ECwgdbOFEZK3DmkQrI52f3x1Wn3eobEeN3bZVQibz+pLp1ORFSNPHAPjtUmt/Om15lCeGFvcHRvA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625784703; bh=9373Imw6xOZQ5Rs+2Hh6Om0R1xBaj2Ny54oPtVs0Gm4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Rm85l2ad7R87uanzXLBbReJealkfq4tsT8iiRCSPlFediizoLrQuB0W8Z+9IELE/V5yU3n0Sf8fgKZCtizVwFiZojMUYYE53qYdFYnfxd+dh6klD7NHOhILmbx1GU7USFTXnu7/rENuLEwOWJV1vrUQEtjAS2F9QcOUxSv0rw9ngX7E+e5wpkLJKbk2QJ3eRU/9Wmz10SCTNSdAoJq+3NNu3+Su73H/+N/qNuLQvReOnD8TF9dB25xa+WL0UTYctfT9+VixYViSI2F+WbJtrY4xEVErIChLHNaQFXkMA9Bwtc10Dv3GwzfuRPtRgIfXmdAdA3nYnlVqq+QoYbvlJOg== X-YMail-OSG: hTYkEQUVM1m90QEfaOzXna1CyTLjH52YSshlwdA7W6xsIkwJbkuGBmxCfk8_NJ_ VXYlx7tz6a3uEKzXSgmdFBPXW2leYEoMYxKrPzLksolWUHe4cwR6jT2oJZeLVo35bKkLKlN.E4yC FZr8HFK2X7TMNwogVcbgTOj_9G3qvcduPjZLtPJAtPIabHeLfn243zM5vQIUF5g6C2kyNE556pLm Mhn2RIxjG3Ua_et6fxD6LJWWoXEJQaxCCwUh6ygZ098DBbCqbet8OQpcEvRAYwSqJxFVc0qNFjcx OdDTZoshJF7Xdpmv2VcoRsAxFO65T_kJdT26COwNECLUZYm_YkFlbofnrqzFm4oPbbqY_Mx3neCt ky9D2DiJoBtg30KCCHDIDgM2ZdmBTeajbwVqnfDIZkPMkUqSdmFo7bIoGwUjDgUyRDmK8MXkg0CW IWvjEukcr5PbtWlQatS_eRdEQzvFhKNoopMb5CqmsV8WuAsi5CgaRCi5bkUp3E2zELfJRoERhT4L oB4whe9fSYIuv.uJyG27AiPMGhcT7wxhydmAZZJt3wO36xSkkFeP3pxBPen9t9s0XstFlrQ0bgLy 1jL_4A6M.0.pRCtd6lYurC0Ch8umCQYYw4qXGpJY0RKOUrk31k2li8mPTPUOq7K3PzMt0sSkfVRc TRO_fYUhZoTF5tU9DzkO1o3.N7vPzBXOvsPMPEHO_ZisXsuIHZ2uFod.KGJutBcGkBLf4sxeegxV y4S_0I4Ad7e2EkS9hmBfgUJXm88JdxFex0DtYp1mvW8Jpn4SVe453YipX6WDtlIZdAbht98dBx9o paNmpDq4abp4h574WGinhHXuCsGP13Vs2OJzvRPqGAZ7O79PhNfhWArLJr.oAu8x2upe864bA9Vi fNRgkS9SW6gkl3h8NNEXQmlXnRtaLyj2LZ.GMGcJdGeUdDwUZZkV1wPoN.sCDwQXZOISJspG5gDJ H0onP0l2ySjNQ1K5YfYxtnL2XWtB_F4a1Nm8BT5KgUP7DpTJDftWSQs2H0fNNXLjdl0glwSrd_xb 7gYAnWilcszgYN.pj9Yp3buW8C1kjM7oZThSAiklKV11psxIGBzTwZPB9.LcVz8w185fJNbuFwl8 dkeL.16OQAVa.DmbD_QlcaKQq57Thm0bobXRE7gnX3jGnxZuIFB_5l3eUddGHuv0HfgvZ5q5jdyQ BEQ.fqFsnok7m34AfDUbC_MSyyuivuLYTa1k8TS9zwkfkXRNvDXK6jCZRicQKcJ_Yf0PMAFSnwaB jFuOUPToiABs4lc00j9uPKM9i2a9ozWUhdg69yyfkM01DZdfpD1avT4TjbBXtA6PXVclqVyWTkrQ bMQXEylM1QXIJRYnDeGGwigq_4BNFCdNOVQF.DpBv1lfWo4cnDNBJySo0GZkAjzY6A4uVGpQXQ56 I4wYN6hgI7gxU1p0O8NbZ9c20k.nCk1hxJyHRWB7MvimwTTk2lnHNorXF3DljGvNB6xQoIH38gpn JhYtaI88ongFvvJgJPM5EbxNMYdP8QD.qMdKPgENHC_8TkN0KP4exVsuO17dnjBDhOgZblqsUmiA d4bVldHF54cFy9ItKxWtlyuWOS5xbflYZFPPnURZjCUwHrDKh5VruCgiEYjEmCzysTg5ippu945e BavO9EXrs5eRUXhuhrcADigtwq4EnIKuJ1urn9SiZx4SPriRuwEMeiOzjRtRtMeXJYCKs9OzhIg5 48L6vMAAQb.mFdhiGsc85yTO.kU8exPZOw8b0HsQMIhHsWJGd8B4HBiF5IdMXRgY7MLNVQ.gLHtc daHl0KY128zgPC0QcvM8KaPval.pJtGd.EIN0T0EaKH0cuC3xDLeMjOO40kIn02OHcuYHMBYkR1u ei9KKbHBi_tORPKFj2Pn1WlR77a5O4K2g26dQr6TFRZY2Y3fhk4xYf.Nwx.no0wdeG0EIa9iLt.7 iZR8mNL4Q_QliUFltANzlJ6WkzZPXq1l4n7ebxCI1mACh.06uuiLJGmWjO5DhXwYfJSDgGaZlued qCtbzeI9L5IKlhzYo5GGpIy5lc84GtmeKWez.Lc90ghuaBjg5Tgpn44B258hEUOxK224lqu8Q5gh a_NvLOryoFQjdn32u167dtNtOJ2CaFNaueoyZTqnbGgWGlv26ElRaSTEjoGjlPzlVJPAk3_NUmvo NBFUXtHFnfwlpMTDIQOq.7jt.hHHWqFLCIr5wFQ_fXyqGTZD_NMUJIr8b1sMKGgsZUUJBXFpU23Q kns7nIQwFZUyZq.TMmDY1qv81q1fZW1eUZp7_INrNumj46.FJ0Z9tqe9lJAPnCnXyqAVLvzdMFcE rdwZ4yf4JMTlb9UdUrBKniEoVA2IRPox2apYL_ktLTgbMwaf.K8ksNzVZmyk9OoXH16Y9g7f8voD BoGx9KMweBe_G5E8shVQ6rEOBES3sFA0lgj4KSgRpUFU3uDbEtLwWG0t2P2OzmYBhkXxv8Bgaqcf tcoOTYvbB96ikGKQ0UR9Hz2SuKpXfDOJSn_p43Ca7V4HSxFsKVproq69iT_QG2_blgXtu4B6QWkR CPUBIcfx2H2xH_dyHuKfuTQTLHV3zwu.K15_V4w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 8 Jul 2021 22:51:43 +0000 Received: by kubenode520.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 14659c7fdf4f90e1d3d48f044d58be0e; Thu, 08 Jul 2021 22:51:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: <4A6DD11F-6C9B-4BE9-81BF-F5B6A40CC08D@yahoo.com> Date: Thu, 8 Jul 2021 15:51:38 -0700 Cc: bob prohaska , freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A6DD11F-6C9B-4BE9-81BF-F5B6A40CC08D@yahoo.com> To: Tatsuki Makino X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GLWkT0pV4z3RFy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=k5HVW3Nb; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.82 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[hotmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.31:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.68)[0.676]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.31:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-8, at 15:47, Mark Millard wrote: > From: Tatsuki Makino wrote on > Date: Fri, 9 Jul 2021 05:59:52 +0900 : >=20 >> bob prohaska wrote on 2021/07/09 02:54: >>> Started a new swaplog: >>=20 >> Connect a USB mass storage device that you have no use for. >> Mount the file system in it. >> Create a file in that file system like dd if=3D/dev/zero = of=3D/mnt/somefile. >> Attach it to the memory disk like mdconfig /mnt/somefile. >> Add it to the swap. >=20 > Bob already has the swap space: >=20 > Device 1K-blocks Used Avail Capacity > /dev/da0s2b 1843200 26944 1816256 1% > /dev/mmcsd0s2b 1843200 26956 1816244 1% > Total 3686400 53900 3632500 1% >=20 > This is nearly as much as is allowed I should have said something like "on a 1 GiByte RAM machine" here in the sentence that I've split with this note. > without getting > swapon-time-frame notices of the form: >=20 > warning: total configured swap (??? pages) exceeds maximum recommended = amount (??? pages). >=20 > Bob may be stuck with a choice among: >=20 > A) running the RPi3B (1 GiByte RAM) mistuned such that > the above messages are reported (or adjusting other > kernel tradeoffs explicitly to avoid the message) > vs. > B) building www/chromium on another machine that has > more RAM then installing the package built on the > RPi3B for later use > vs. > C) giving up on building www/chromium at all, using a > pre-built package > vs. > D) giving up on even using www/chromium on the RPi3B. >=20 > Bob is familiar with doing (A). I'm the one that > requested that he try not doing so as part of trying > to isolate a problem building devel/llvm10 . That > problem was later identified to be a different issue. > (A) does make other kernel resource tradeoffs, > either implicitly or explicitly. I do not know how > to well manage the tradeoffs involved so I never > recommend (A). Others may know what they are doing > for making such tradeoffs. >=20 > However, even if Bob does (A) there may be other issues > that he will run into. Form build attempt to build > attempt he is having problems leading to massive swap > space usage at differing points in the build. The same > step sometimes works fine and other times fails. This > suggests another issue may be present (racy leak?). >=20 >> Ask Mark to explain the details to you :) >=20 >=20 > I would never recommend using files for swap space on > FreeBSD, only swap partitions. See comments 7 and 8 of: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 >=20 > for notes from Konstantin Belousov that lead me to > not do so. (8 is a reference to other material.) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Jul 8 23:51:35 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 19B1811E6459; Thu, 8 Jul 2021 23:51:38 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [5.196.167.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLY3Y6Xclz3s22; Thu, 8 Jul 2021 23:51:37 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [IPv6:2001:41d0:a:71bf::1]) by mail.freebsd.systems (Postfix) with ESMTP id 3EEFB1EBC2; Fri, 9 Jul 2021 01:51:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at freebsd.systems Received: from mail.freebsd.systems ([IPv6:2001:41d0:a:71bf::1]) by mail.freebsd.systems (scan.freebsd.systems [IPv6:2001:41d0:a:71bf::1]) (amavisd-new, port 10026) with ESMTP id TXLaGeOM826E; Fri, 9 Jul 2021 01:51:36 +0200 (CEST) Received: from [192.168.168.3] (89-70-50-99.dynamic.chello.pl [89.70.50.99]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.freebsd.systems (Postfix) with ESMTPSA id AB6BC1EBC1; Fri, 9 Jul 2021 01:51:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wasikowski.net; s=default; t=1625788296; bh=/86pV7dxgYgslvMSAVy3Z7VjvsEDXIyFwULWLNU+Pqw=; h=To:Cc:References:From:Date:In-Reply-To; b=E02KQ7fyxxLE8sUSvz7ZMhDRNs5kgezRcyxRupuqN1AHv0rHm4ruKTLeMdqzByzX2 g7AiyLy68sL+xzH5SVhsZ5WXAaK2S8YRSeZVRaUIBAqvkgd86y/7p/SobNlCh2q0vo Nj3888JMMg44N+Dcf6WB0Axx4jR1z/Cbe0QFmY66XQMhRb4z34w8UGAy2alNnYey99 81o0A7jMhlZoIHVnVBvrTjpznGzGqg3IrYf10YMhjPTOhnYgwD3E/0Gj/wwDCT8HVF 0pQrdogvmpqlxZ3qr2ZWuQwswUhY4vLyTwIj0Q6+XYpYNt96lDwNkJKo8CUZtuBVvC 7v54beb7SNHpQ== Subject: Re: security/rkhunter without hashes after recent STABLE-13 update To: trashcan@ellael.org, Stefan Esser Cc: Warner Losh , FreeBSD-STABLE Mailing List , FreeBSD ports References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> From: =?UTF-8?Q?=c5=81ukasz_W=c4=85sikowski?= Message-ID: <6bd6fc12-f872-9560-81a0-5b9385fc85cd@wasikowski.net> Date: Fri, 9 Jul 2021 01:51:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: pl Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4GLY3Y6Xclz3s22 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N W dniu 2021-07-08 o 14:16, Michael Grimm via freebsd-stable pisze: > I can confirm that your patch works perfectly well. > No more workaround needed, now rkhunter calculates sha256 hashes as usual. > > Thanks for that. > > Now, Łukasz need's to confirm that rkhunter at 12.2-RELEASE will calculate those hashes as well. Works like a charm, thank you Stefan. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257065 -- Best regards, Łukasz Wąsikowski From nobody Fri Jul 9 00:17:24 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B155312357D6 for ; Fri, 9 Jul 2021 00:17:26 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLYdL4lBLz4RJj; Fri, 9 Jul 2021 00:17:26 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 6FC224C1B; Fri, 9 Jul 2021 00:17:26 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id CE2D141BAA; Fri, 9 Jul 2021 02:17:24 +0200 (CEST) Date: Fri, 9 Jul 2021 02:17:24 +0200 From: Baptiste Daroussin To: probono Cc: freebsd-ports@freebsd.org Subject: Re: Proposal: Include the Application Name in Ports and Packages Message-ID: <20210709001724.bfxw2apzgkqdjqqm@aniel.nours.eu> References: List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Thu, Jul 08, 2021 at 08:35:12PM +0000, probono wrote: > Hello, > > This is a proposal to include the Application Name in Ports and Packages. > Happy to hear your thoughts on this. > > Kind regards, > probono > > > Terminology > ----------- > > Application Port: A port that contains a graphical application and > hence has an Exec= key in its share/applications/*.desktop file > > Application Name: The application name (as intended by the application > author). It may contain uppercase characters, whitespace, and special > characters. Examples: "Qalculate!", "KTurtle", "SpeedCrunch". > > Port Name: The package name is lowercase and does not contain special > characters. Most frequently it is not identical to the Application > Name. Examples: Examples: "math/qalculate", "lang/kturtle", > "math/speedcrunch". > > Package Name: Same as with the Port Name. Examples: "qalculate", > "kturtle", "speedcrunch". > > Situation > --------- > > The Application Name is the #1 metadata that should be shown to users > in application catalogs, package managers, app centers, app stores, > and so on. > Basic tasks should be simple. Knowing the Application Name is a very > basic task yet suprisingly nether Ports nor Packages contain this > information: Currently there is no way to know the Application Name > from looking at the files in /usr/ports/, and pkg only displays the > Package Name but not the Application Name. > App centers like freshports.org, OctoPkg, and GhostBSD Software > Station hence also cannot show the Application Name but have to resort > to showing Port Names without having to download all packages first, > which defeats the purpose of having Ports/Packages metadata outside of > the packages themselves. > When BSD was started, it was centered mostly around command line > tools, which usually have names equal to the Package Name, so in the > beginning this was not an issue. But with graphical applications, this > is no longer the case. > > Heuristics > ---------- > > 1. In most cases, the Application Name is contained in the value of > the Name= key in the share/applications/*.desktop file of the main > application contained in the port. > > 2. If one of the first few words in the pkg-desc file is the word > "is", then the word(s) appearing before "is" in the pkg-desc file > often contain the Application Name. But this heuristic breaks for > descriptions that do not follow the "X is a Y" structure. > > 3. If the port contains an AppStream metainfo file in share/metainfo/, > then the "name" key in the first "component" element often contains > the Application Name. But over 1,200 ports with share/applications/* > are currently lacking a share/applications/* file. > > Proposal > -------- > > 1. For Application Ports, include the Application Name as a mandatory > key in the Makefile. > > 2. Add checks to Ports tooling in order to ensure consistency of the > Application Name across the desktop file, the pkg-desc file, and the > AppStream metainfo file. > > 3. Populate the Application Name for all Application Ports (doing this > initialy can largely be automated using the heuristics described > above) > 4. Once this is implemented, adjust pkg(8) metadata and tooling to > bring the Application Name into Packages and their repositories as > well > > 4. Once this is implemented, adjust pkg(8) metadata and tooling to > bring the Application Name into Packages and their repositories as > well > > 5. Update App centers like freshports.org, OctoPkg, and GhostBSD > Software Station to display (and make searchable) the Application Name > > Best Practice > ------------- > > HaikuDepot, the app center in Haiku, is using Application Names: > https://www.haiku-os.org/docs/userguide/en/applications/haikudepot.html > > Interested parties > ------------------ > > * GhostBSD: https://github.com/ghostbsd/software-station (confirmed) > * helloSystem: https://github.com/helloSystem/hello/issues/173 (confirmed) > * Potentially FreshPorts > * Potentially NomadBSD > * Potentially OctoPkg > I think there is a way more simple way to do it. Simply add a new annotation to the package with the Application Name(s) when it is relevant. I add plural because some ports do provide multiple Application Name(s). And you will have the information everywhere. See how CPE is implemented in the ports tree to see how to do that. That will do all you ask for if I am not mistaking ;) Best regards, bapt From nobody Fri Jul 9 07:41:14 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7119C8D21CA for ; Fri, 9 Jul 2021 07:41:27 +0000 (UTC) (envelope-from antxxxx@gmail.com) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLlTf2tHxz3jP4 for ; Fri, 9 Jul 2021 07:41:26 +0000 (UTC) (envelope-from antxxxx@gmail.com) Received: by mail-io1-f51.google.com with SMTP id g22so11512691iom.1 for ; Fri, 09 Jul 2021 00:41:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7iR/L+dtS5BSgbuGWXAV7xTfJGWd0aMp3vXlkYAQhbA=; b=jXmLTeBkt/LXN8K5lMnLQoxsHZEiKQBvwYrgc4PLIh+iCr1hMPj4ztZ4e5EmdN1D6D xe8gATsKmJQxb0F1bkU/8w1XKwQ72z7rW9I/HolBS+zD6Ui/WhZFn6EYkMD0Y79t/96G lz3CWP985mnolHVLFBQJaxospldKd7Xv+Jx74LIEMkKpHemRvXaIRH+qYkpF+zdvCYj7 L6R/MCYAludWocMMrwzIC7dBz9CVz0jdPfMZ5u4OXEALtr5tyMf8Gcc6X5e0xnud1zwR DCABTiOgeLvg96Ttfz0hvQYL4LjDjV73rqCybdV2bVSUidaGeAU6SYA6JDC/E9CRy9It TAew== X-Gm-Message-State: AOAM531BNxPz5sdkUwS7oMh0cvTwGM+PlMf4Ik8EXFfymz9OysW2PUt9 eDJwRyberELh1W2Cmma9nnydfmhXHgtJtPplAOm4SQ+jJ9w= X-Google-Smtp-Source: ABdhPJxqMbvbN1cr3S+XDMZSCHX3MRXTA6cfa8j3fSg1tOTAIyhYitoBo7V9Q94jlrNnT0/s1E+5ewyq0L3HKTeAp6w= X-Received: by 2002:a05:6638:3594:: with SMTP id v20mr30571449jal.25.1625816485217; Fri, 09 Jul 2021 00:41:25 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 From: Anthony Brown Date: Fri, 9 Jul 2021 08:41:14 +0100 Message-ID: Subject: how to rename a port To: freebsd-ports Content-Type: multipart/alternative; boundary="00000000000012497d05c6abe6f2" X-Rspamd-Queue-Id: 4GLlTf2tHxz3jP4 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of antxxxx@gmail.com designates 209.85.166.51 as permitted sender) smtp.mailfrom=antxxxx@gmail.com X-Spamd-Result: default: False [2.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.51:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; DMARC_NA(0.00)[found-it.net]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[209.85.166.51:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.995]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.51:from]; NEURAL_SPAM_SHORT(0.99)[0.993]; FORGED_SENDER(0.30)[anthony@found-it.net,antxxxx@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.51:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[anthony@found-it.net,antxxxx@gmail.com]; MAILMAN_DEST(0.00)[freebsd-ports] X-ThisMailContainsUnwantedMimeParts: Y --00000000000012497d05c6abe6f2 Content-Type: text/plain; charset="UTF-8" Hi I am the maintainer for https://www.freshports.org/net-mgmt/unifi-poller/ and the upstream project has had to change its name to unpoller so I want to change the port name to reflect this. How should I manage the user and group previously created in /usr/ports/UID and /usr/ports/GID for this? Should I rename the previously added user/group, or should I add a new user/group and mark the previous one as available again? Also, apart from adding an entry to /usr/ports/MOVED (and updating port location in /usr/ports and port files) is there anything else I need to do to mark the port as moved? Thanks Anthony --00000000000012497d05c6abe6f2-- From nobody Fri Jul 9 08:36:43 2021 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2EED811E3046 for ; Fri, 9 Jul 2021 08:36:44 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLmjS0r5Fz3sHW for ; Fri, 9 Jul 2021 08:36:44 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 03D3C116BA for ; Fri, 9 Jul 2021 08:36:44 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org ([127.0.1.10]) by portscout.nyi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1698ahKM086214 for ; Fri, 9 Jul 2021 08:36:43 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.15.2/8.15.2/Submit) id 1698ahKG086213; Fri, 9 Jul 2021 08:36:43 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <202107090836.1698ahKG086213@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Fri, 9 Jul 2021 08:36:43 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-ThisMailContainsUnwantedMimeParts: N Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ graphics/povray37 | 3.7.0.9 | v3.7.0.10 ------------------------------------------------+-----------------+------------ lang/gprolog | 1.4.5 | 1.5.0 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From nobody Fri Jul 9 19:46:47 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4D8BE1270C87 for ; Fri, 9 Jul 2021 19:46:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GM3Zk6Hd9z4vtN for ; Fri, 9 Jul 2021 19:46:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625860013; bh=2ZA0TNzEnX7EDNGVRK7UWqvdSjgP/pqcEScHmatCCH4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WsG5+zp/F8ZvEpqSJEu32TUUJb/BmGv8xpHNVJL8LGSW2llbf+gRifiItAsLtOgvCu5gFfQd6X2Zg4aD2paXlUMxB/PQ7P6z88xJzExpAS0jZSbuazVFxTMx1ybtZDjBo/augcPlmDxRqLyrTD2aizAiM1jcj8dqZq3MTJe3Xq+ccIVYUblTfsOMtGXAeIbjXWboIOBH5sIeEBF2hoXdPe63En4pqxQFiP+tEnXA5FfGCIp9kHU7G5r3ICd6BmdagLX8ol+eZB2c2j0SEPYhbSzZllvDZscRzv7rxwSgj/TSc9fXjJ6J+dlvArjYefGXPGFv5Qzttg9x6/zGBiuQjw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625860013; bh=u2BQUwTzbKPUyiRAXnxJjfRYjzEU0sdf1Z6P9QeHlmS=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=r24LrjP7yN5twRms1QHcaStmw6LU6Dk0muAkhBySyEmq7pxryu+wmGfYbU0nLEHWXoTqml7UI3kEDBF6AJJP93igHa4PAtkIkDGFv7Se+ZqEzW20HOuKSL16uJgC1FoNF2UwHZc62jTFVepB93wi5GqI16UqeJaoBIBuFwh/8CfiWLs22g7plcSBoEJOP3bWbvGXIyJJV5RPvtnk+2gkkN/1/5GGRYhNLPlKcgZcePBlM9yWVo+plchmScwPr7A1tdObiBIKHqy3uL3JYc0eIAKL4yLrsjokGrGH/eNmqfCfH8G2PDdFoNbgU+d/Gb0xXHXrHgyOZ01ObAEXHivVwQ== X-YMail-OSG: dW0eOJYVM1mQMuUAld9VEYtR7MnYqxWlE3cGDoF1aV4ZxgiGiDv3mmWWgM_GlM_ VTPrzPdoovofzqs.EOdXbE6.bFg7B3eRBryLLnPH4tjOqBIwrtpu2BXdjs4GJmM9GiCi_oFh6EXD f_3WPMg9r2t5qZRWi5Jz_sjzGmAH.yT1DrO5buSRr9j73JqFLkeXPG6gRmmpNqW7k2K9ijlFEM9P rEHOEXLSICqSwgMiIv.4KdY2t0JNIDtGTpyfbGGa3xy3l5lcpzVBFfD.MvSZXTswiSds4Aa7kYTm XWds9dJoqtgVPHjd1mgEEN84PoZnraIUzOSBLvnptEI0GSDIUgVzMljGK5eAV77vnuohB3e0wNgX 3UvVO7HKVaVXrfcxIYNfQjMUyoy8S9vxX6OJ.CrdYA4xRU_hPBt_mFOW1iF8GiDbQIQM_Sda5cw9 2RSOrSNlAF_LEem.yRUj3Xj1Lsu0xrLA3xUfLYKJ2hayTBUjdMhbmHS28n476Vh7hwsjoDKzRsuH mNTgSKrxkfJ4O4IXWJwM9R0cPyqWbnpIvSO0ffX2D95D0AWEfL4jF_tLSCMfuqpvZJj84zFJUg15 ItF7c.fln.4Xa2kuwUxsmzGvhU6Fl61YAE3bjCBx19X2K3wFLEpI3J_T2NWI8iV_OHHP.JYucZTB bdsUkBcyCIqNqdJa9VS51upvRXrytzkchfnTTnN3yPoRQDJ5vpa_7ocaSk264Tje5U3ZPfebxx1n QXJK4pwGxchIdL0RY0vFkTiamnxJNMf43vsiH6MTJWt1IEh5qc4fyE0lOsvHUywcK_eWXljyHt5w mVhcbZACQK.fQlCaduXzpSOgm4q4BVRVWP8iXPURuIh3TOfvtxZY3EiDnnPoCRlT0apY8.QjyZgT xmTXeySnRPy08amBsur0rhl23XudYsnp6aZ4FBeRMtsNYG5beutuYubvHsdNGMbYovEwHrbKquh9 WibZIK7fSq543vwFU_f2Coi0ImUr_BcIRwmjjmSZkdUkplKgFgpw1mamzC.SIENjvZQF257oi6JG WKNlUjlRJXIql6_L6Bin7_ahnaBlQlpXIvrLimzOmWBs_Bfj6GmGD9822RfI4gjnKdwFE1pKlr.N c0h.n5qE_8WvwGInTmn.0F2cnS3kwU_tkUDRvGU8Z.6IlqWTotyVJk9hTPN7cMs2ZncvmYR7sbRX aDskSzw8eTsi4hVPPL.KxNT6.Ulk.sfwKGlZxELt18PvY7M1i5rNB0KXZmA9_5mzqruYyK3vKin0 nEtQVuLfJHq0uAd8GmvlwS7bNqOtIpa4JnG3pKSWkAcW60LvdgU289nO3bCCvsjUjfX7cFjnFUVO K5ZpwdDulQz7kl9RPrWskEQYO3f2euOd70cGIXXaPL1q2sG1W4wtgkGTsvPKNw3u65_CHdWRsKxF RHie1LEkMuFMGK9D2teecKMh.XnryI1f9eHvbOJrLc0iex3.Q5Wq0_EZ5FGJK.US87xVXlrE6MIp BjRelY4S0qTMUwPFpHom4zF9AqLJbKR98TEAz3Dh2Rsbs0fVCWXHZNn2OCHb4SD_PiuPLyO5XpKq .FIuEUDTEYXCowBRCkhfWpovzfo0wFj60E_pgRuwjh_clnmrKu5dNhE1wSKzG4k4nKP9jAIQK9JH rO4YLWqMsiSAlqMOnzNKvGkqqjt2R.IhWnXuNyAvPmzRJWpriowIaSOEBDQKtCBAJxmmNYlOlxKG 3fT66H65M7N.rNMsH6gL2RybFQo979pJBliQDagKeAoF.BHN1KDjze3kHdhwVhzNEV.zzkcIY41g LtBsX3YTKzNxl2Wj9vnXUnqEy4s9AmEOkSYa6A1fC8km4UMPhkakp64rSJYkY.RxNFU0VGMjZSDT p9Bk.zTIMo2zXExmXbb3EEAhGF3tRUkgW.sptY034DoejFwH3_Qq1WlCBodDZvaQ9Uck4Hq3H0kX dgDjJ0FwC1LFq0tAcIVpUCg24SIk0PdrmFbSrfkmQuN.ISCIGQrdDs2JP6SaE4DjRsX7uzzlBA2P e7jtd.5PYs5N9VPEd7BlrVV6Pj5akwyR3Ilg79mfvmEfeQSnvFMZ.NEHZSxMcxEWKdjVgSOy_3Kc zxC24my5XJfQiuK7Gox.7bwEicJZBwp2Ra9FIoKyMdFpu2H1PSF9D4dG_RSXNxlJPvRlb0qFDHOx 4TApKK.G2iDtHU4e0XRdUcuqV9FPs_dCLp9Yg1ArL.XvX7y_nAQvZh6qrbVYXIf5KugAHnXsPQ43 Em_iCAaSuXsytfYcpVvW_p4VVPcYAzLfKTj6ttbNzBs40F02Fxv6Lw6YDJAVngX95WMXhdel2aWf cl3q6IkhBcVlInOMMmoekaPZSV.y4L4s31QY.OJTadxyx8T5IJ5A3wxuOKXIqSjtWVlUS__q4ci2 xBKy6WDoCnE830.WVT_nNmbtHrEEoq13I._RLxRLXBHo4M.NLcIpoLhCEH.c0U2x_XQC_KRY_Vhe DxG7X4i00oHBSOEG2Cv4An2L2.fUmX4v.lw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 9 Jul 2021 19:46:53 +0000 Received: by kubenode524.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fca4721c91b8223b7b9cb2e93ef89c55; Fri, 09 Jul 2021 19:46:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> Date: Fri, 9 Jul 2021 12:46:47 -0700 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6D9BAA86-CB85-42E9-B4FC-6272141CFFDB@yahoo.com> References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GM3Zk6Hd9z4vtN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WsG5+zp/; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.46 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.83:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.957]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.83:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-8, at 14:11, Mark Millard wrote: > On 2021-Jul-8, at 10:54, bob prohaska wrote: >=20 >> On Thu, Jul 08, 2021 at 09:41:13AM -0700, Mark Millard wrote: >>>=20 >>>=20 >>> On 2021-Jul-8, at 08:45, bob prohaska wrote: >>>=20 >>>> Even with -J1 and no ALLOW_MAKE_JOBS I'm still >>>> seeing five pythons occupying at least 3 GB on >>>> the loose. >>>=20 >>> Actually I just looked and saw: >>>=20 >>> Swapinfo 7.36% >>>=20 >>> (Unlike the 83% or so I saw somewhat around 3 hours ago.) >>>=20 >>> Load Averages (220%) 2.20 2.18 1.76 >>>=20 >>> Elapsed 12:54:56 >>>=20 >>> I do not see a swaplog in http://www.zefox.org/~bob/swaplogs/ >>> to look at. So I can not see how much the peak swap space >>> usage was so far (approximately). >>=20 >> Started a new swaplog: >> http://www.zefox.org/~bob/swaplogs/202107182930.log >>=20 >> It came within a whisker of running out of swap, then abruptly >> the python threads vanished and the build seems to be proceeding. >=20 > Did you update any thing, such as /usr/ports/ , between the 50+ hr > run and the new one? The new one spent over 6 hours at: >=20 > [05:50:59] [ 8% 3914/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools ../../third_party/blink/renderer/build/scripts/make_names.py = gen/third_party/blink/renderer/modules/event_interface_modules_names.json5= --output_dir gen/third_party/blink/renderer/modules > [12:22:32] [ 8% 3915/47953] python = ../../third_party/blink/renderer/bindings/scripts/generate_bindings.py = --web_idl_database = gen/third_party/blink/renderer/bindings/web_idl_database.pickle = --root_src_dir ../../ --root_gen_dir gen --output_core_reldir = third_party/blink/renderer/bindings/core/v8/ --output_modules_reldir = third_party/blink/renderer/bindings/modules/v8/ enumeration = callback_function callback_interface interface namespace typedef union > [12:22:36] [ 8% 3916/47953] touch = obj/third_party/blink/renderer/bindings/generate_bindings_all.stamp > [12:22:39] [ 8% 3917/47953] touch = obj/third_party/blink/renderer/bindings/modules/event_modules_names.stamp > [12:22:42] [ 8% 3918/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools ../../third_party/blink/renderer/build/scripts/make_names.py = ../../third_party/blink/renderer/modules/event_target_modules_names.json5 = --output_dir gen/third_party/blink/renderer/modules > [12:22:42] [ 8% 3919/47953] touch = obj/third_party/blink/renderer/bindings/modules/event_target_modules_names= .stamp >=20 >=20 > The 50+ hour one did not: >=20 > [03:56:05] [ 8% 3848/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools ../../third_party/blink/renderer/build/scripts/make_names.py = gen/third_party/blink/renderer/modules/event_interface_modules_names.json5= --output_dir gen/third_party/blink/renderer/modules > [03:56:05] [ 8% 3849/47953] touch = obj/third_party/blink/renderer/bindings/modules/event_modules_names.stamp > [03:56:06] [ 8% 3850/47953] python = ../../third_party/blink/renderer/bindings/scripts/collect_idl_files.py = --idl_list_file = __third_party_blink_renderer_bindings_web_idl_in_core_for_testing___build_= toolchain_linux_clang_arm64__rule.rsp --component core --output = gen/third_party/blink/renderer/bindings/web_idl_in_core_for_testing.pickle= --for_testing > [03:56:06] [ 8% 3851/47953] touch = obj/third_party/blink/renderer/bindings/web_idl_in_core_for_testing.stamp > [03:56:06] [ 8% 3852/47953] touch = obj/third_party/blink/renderer/bindings/scripts/cached_jinja_templates.sta= mp > [03:56:06] [ 8% 3853/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools ../../third_party/blink/renderer/build/scripts/make_names.py = ../../third_party/blink/renderer/modules/event_target_modules_names.json5 = --output_dir gen/third_party/blink/renderer/modules > [03:56:09] [ 8% 3854/47953] python = ../../third_party/blink/renderer/build/scripts/run_with_pythonpath.py -I = ../../third_party/blink/renderer/build/scripts -I ../../third_party -I = ../../tools = ../../third_party/blink/renderer/build/scripts/core/style/make_computed_st= yle_initial_values.py = ../../third_party/blink/renderer/core/css/css_properties.json5 = ../../third_party/blink/renderer/core/css/computed_style_field_aliases.jso= n5 = ../../third_party/blink/renderer/platform/runtime_enabled_features.json5 = ../../third_party/blink/renderer/core/style/computed_style_extra_fields.js= on5 --output_dir gen/third_party/blink/renderer/core/style --gperf gperf > [03:56:09] [ 8% 3855/47953] touch = obj/third_party/blink/renderer/bindings/modules/event_target_modules_names= .stamp >=20 >=20 > The build step numbers are different for the same > command: >=20 > 3914/47953 > vs. > 3848/47953 >=20 > (But I do not know if the build technique tries to > keep the partial ordering for build steps stable > across build attempts from the similar starting > conditions.) >=20 > It almost seems like like a system level check in what > process(s) have large amounts swap space in use would > be appropriate when this sort of thing happens, not > that I've done such before. My understanding is that > top's per-process reporting of swap space usage is > problematical when the display is set to display such > information. Going in different direction, when you updated: /usr/local/poudriere/poudriere-system to have Jail OSVERSION: 1400024 (and probably matching the host OS main-n247590-5dd84e315a9), matching /usr/src/ as well, did you rebuild all your ports under the coherent combination? Or are you still using port builds in poudriere that were built with the jail OSVERSION being older than the /usr/src/ the builds were based on? Just like devel/llvm10 had a command that only-sometimes had problems when built via the incoherent combination, other ports could have odd behavior --but only sometimes. My guess is that you have not done such because it would have taken far more time than I've noticed in your activities. I recommended before doing such a rebuild of the ports and then a reinstall of them. Given the odd behaviors being observed that do not repeat each time tried, I still make the recommendation. >> I'm curious if this was blind luck, or some adaptive behavior >> by poudrirere. >=20 > Poudriere does not control chrome's internel build steps. > The notation like [ 8% 3849/47953] is not from poudriere. >=20 >> One other oddity: occasionally one see in top a >> PID using more than 100% WCPU. Is one thread occupying two cores? >=20 > A process can have multiple threads instead of just one > but each thread runs on at most one cpu (core here) at a > time. >=20 > Top can do either of: >=20 > A) show a count of threads in each process shown > vs. > B) show a line for each thread instead of for each > process >=20 > Top can also display the unique thread number instead > of the process number (shared by all threads in the > process). (But not both at the same time.) Showing > thread numbers is probably only commonly selected when > (B) is in use. >=20 > In (B) mode, if the process number is being shown, > then there will be one example of the number per > thread shown that is from the process. >=20 > But I'll note that, if I remember right, python is > a single threaded language. It would probably take > use of language bindings to other langauges for > multiple threads to be involved (indirectly) in a > python process. >=20 >>>=20 >>>> I'm fairly sure this didn't happen >>>> when using make by itself (IIRC it was -j2). >=20 > It did not happen at that point in the 50+ hr run > either. >=20 >>>> I also got rid of the mistaken directive in >>>> poudriere.d/make.conf. >>>=20 >>> When I look at http://www.zefox.org/~bob/poudriere.d/make.conf >>> now I see: >>>=20 >>> ALLOW_MAKE_JOBS=3Dyes >>> #MAKE_JOBS_NUMBER=3D2 >>> #.if ${.CURDIR:M*www/chromium} >>> #MAKE_JOBS_NUMBER_LIMIT=3D2 >>> #.endif >>> #.if ${.CURDIR:M*databases/sqlite3} >>> #MAKE_JOBS_NUMBER_LIMIT=3D2 >>> #.endif >>> #.if ${.CURDIR:M*www/firefox} >>> #MAKE_JOBS_NUMBER_LIMIT=3D2 >>> #.endif >>>=20 >>> which does not match your wording. >>>=20 >>=20 >> Thank you for catching my error. _now_ it's fixed. >>=20 >> [snip] >>> To see what is getting CPU time that leads to >>> the load averages being around 2 might take >>> using something like top sorted by cpu time >>> and watching for a while. >>>=20 >>>> There is a=20 >>>> #MAX_MEMORY=3D8 >>>> in poudriere.conf, presumably GB. >>>=20 >>> Documented as GiB: >>>=20 >>> # How much memory to limit jail processes to for *each builder* >>> # in GiB (default: none) >>> #MAX_MEMORY=3D8 >>>=20 >>> Per builder, not per-make-process. >>> Within a builder each make-process shares >>> that size space with the others. >>>=20 >>>> That >>>> looks like a good knob to play with. Would >>>> setting it to something like 3 or 4 help? >>>=20 >>> If the memory use exceeds what you set, the builder >>> process is likely killed.=20 >> [snip]=20 >>=20 >> I was hopeful it might inhibit starting new PIDs >> when memory/swap is below some threshold. Guess not.=20 >=20 > poudriere does not control the internals of the > builder's attempted operations beyond what the > port supports. (And there are not port-specific > interfaces for such control. poudriere treats > ports the same way in general.) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Jul 9 23:07:38 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6BFF91242058 for ; Fri, 9 Jul 2021 23:07:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GM82K0ss9z3qym for ; Fri, 9 Jul 2021 23:07:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 169N7cSL083702 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 9 Jul 2021 16:07:39 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 169N7cwF083701; Fri, 9 Jul 2021 16:07:38 -0700 (PDT) (envelope-from fbsd) Date: Fri, 9 Jul 2021 16:07:38 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-ports@freebsd.org Subject: Re: Too many pythons in poudriere Message-ID: <20210709230738.GA83522@www.zefox.net> References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> <6D9BAA86-CB85-42E9-B4FC-6272141CFFDB@yahoo.com> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D9BAA86-CB85-42E9-B4FC-6272141CFFDB@yahoo.com> X-Rspamd-Queue-Id: 4GM82K0ss9z3qym X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jul 09, 2021 at 12:46:47PM -0700, Mark Millard wrote: > > Going in different direction, when you updated: > > /usr/local/poudriere/poudriere-system > > to have Jail OSVERSION: 1400024 (and probably > matching the host OS main-n247590-5dd84e315a9), > matching /usr/src/ as well, did you rebuild all > your ports under the coherent combination? > No. > Or are you still using port builds in poudriere that > were built with the jail OSVERSION being older than > the /usr/src/ the builds were based on? > Yes. > Just like devel/llvm10 had a command that only-sometimes > had problems when built via the incoherent combination, > other ports could have odd behavior --but only sometimes. > > My guess is that you have not done such because it would > have taken far more time than I've noticed in your > activities. > Correct! > I recommended before doing such a rebuild of the ports > and then a reinstall of them. Given the odd behaviors > being observed that do not repeat each time tried, I > still make the recommendation. > Just to be clear, after updating kernel and world I gather the suggestion is to repeat # cd /usr/src # make installworld DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 # make distrib-dirs DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 # make distribution DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 Next, cd /usr/local/poudriere poudriere jail -d main -C all to get rid of the old jail and packages, then re-make the jail with # poudriere ports -c -m null -M /usr/ports # poudriere jail -c -j main -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT Have I got this right? One thing I'm hesitant about is the -C all option. Thanks for all your help! bob prohaska From nobody Sat Jul 10 00:12:57 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BE0031272104 for ; Sat, 10 Jul 2021 00:13:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GM9Tp3MV7z4T61 for ; Sat, 10 Jul 2021 00:13:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625875980; bh=vDCWyXD5uwUWu5ms1X6LOBbYrRwBrbruuDgsVFGEhyM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XqtlXH0axH0GPLXmhEaSdAp6w1PPv02hJhXsQ+HPCs1lilB5srYWz8fHQm01vF59OBiwlR0zFsyJHyb6ZgWbqFJ7UwARb5lpc6XUK6GW87eIX2WoeiUDOksMdM6gewGli0swQj3p88FEG0x8bBajhrM2ZlRy8qq81nj/JDqx9jW0d5ExXKgMp8n0gJ5njX/xC/WFz0wswCLgDrN1KW8QLFeBBGEPg8VMKRKdMnMDqPSTh0iE/UKV5LAgiHVel8o2ogCBMpTDGJR+U/oByiwZVKZY6mHr7vhQLUFyBxNOAV54xLVuxInGHjZ/QtndzLZLkBdTFHvyueUM3cz+b2Wuaw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625875980; bh=VwZXB1AgpJF1Y7iQ3JKkU7iMIZuuDyDtAJyH0XxAaop=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oqeWlTrQyYQFP0kxpwKANjrPxGxk+kG+iMQ9Ok6+694BpVRxEcibjP7QdcL/dsvtrzjKJvP52UM58D+5weMlgwZ5UlyUIUsJyYxCW3L79zh9GhR3QHhdAPBFn1spHBNkN4XP9cOO0uYSU56aE9WF0SHb01KL6vBPCFhPklWP512cJnvLwycYhnAuT0DfqvCakXd5AldTVjyxFCfIAJIBgNVgslqCOct1X9vj8cVFFiggy+B15LbzCTSB66lbS1YoRlK4WT4yvheIAdWz0q8nX+2w97UcivM4bG3TZrq1+LHkE8QbUBCaxXY+jU0oUSln5Vas6V4fm4zmhIeG98DvXQ== X-YMail-OSG: ViR03tgVM1knDzuxgjLiMCByLen8aCXr0zIo_vmgu4iGD2RhdDrcJ_TaSDsb1Xu Z..uNLLb2FPAyntLAzudSBFsNRzVGscAQiVtqLQazUAPQ8RXwXq028KhQLFQrB3gXWoYCno2teBB vTpoWmBWpcaZ6gIKnGhtED9J4uc8Jm4oaTHUTqZQdXqjkegBaKW2tZRvAx9.q7KgjgxyH59yFW5s NG0xqFC9vUyt6x9pDaM5lrWlO5BnG0dXyBVvNJo409uN8UH2S8humFr_S8T1mdvVXFCPz4oA8oBy 4UzHruqMqzockJfhEGG9t_TfEnv2Jju9G7y7GSkefe7Y6COiUbIf.0pr5tNR62U.dHnGWCwXwTXW O6mt9F4D.LkIjEgnSmVVbZ2XfsDbtGtnmfa6ZPxuQlqgdWGadgUdrY8R.02wkdvwpo1zDY6j_gtU 1eKfBZw.bqnupNdSK.7sVh1LnnKui12_cFCW1csfyKhHpw5t5NFOld5OQykKF37ibVzUkh9phTHR IP1QHTqnBwjGGGXGGoix6In41GxQ.7GlOd44kRFynwAvSimWyqB.JKFjEbjTmHKaTf9YLANP2oxK fIV22DQp1RDuowpW0sQ.qtoTm0cGBfjgQltPxE.Ce7rjtvZo0wJZd12y7VUDAzGju02bhS1dKlPh 39zyEw6ongOwL3IP7ySdMquR8lurD6x2BWsz3iOOXBUlLRc2fCylU3mUs9KEdll1xvwArM8DZM.B UXe_6OnsnKIW0E.9aFkM_AMn8_hL5ZqoQovoz.L48gi4wQ9p8McV5Z_rqRpnA4SE3LISLLb7zC7A cnaoOQUE.1aQFANtsPef0iCzd2LKcj3F2SNNn623SXBQ9aoSUDgxwwydtTvTF2n1TVNLzst1tmfr sHYp.ENYv0HDWcV1eFnpC297AqCCQWZevJemDn.eOBSE2X_IjVbaqc42Gj14G3mk6t_4NNYQz_lT w6r.JXfV82qUjNeYur1I.fDLQG2z6hxQCJJmRVvWPphP.dfFfPB65rmYQxFzYkpAOe1w1kGKTilX Cxqm02jdqLhiJUKi4yVyGmHj9L5gPwYUzKuRCqYQLdWT0PrJaCH3qJLu_S9Swk8sDPvsIAYHJTNt 99lowszQlmq0Mq5AT6oD3JypuDiXHM5tS_tM2FEbw4I7WiFHW1wgHgEgGGciLx6FmPYs2DaN3RLw NzWV2c_9YuFy8ug8.KSXvFBe25aZaSR7EQ7xdSSaITyKZBrLdeigGEi9qBaA_Pj.FqUQVYxMJci2 rnkXH0ZRQDwCiUTo100rCzvinYz.znRPJd2dohec.0MDrPM1mFA.3k_7AvDq24e7.Z5ljZZhgCFq YpuddoixFA8g07C1TLRDIrrF03EE7vNVaglWOSNBCjCBs_js52vm3oVz9wkg0.7MZnU0AMLg_doZ aplAo4GaUs6D_8DTaDmJsmSQzsBNKMAr8eUXq7waVA813OVugsX7AHHuGO_Ep4Z15hHNaCjwHRVy dwn8Fq_rHIJOTGGzZMsoK1cj_kS_dNgx6k1q2e5W54ky0wvB2o67Pf2hAQ.e.lOA0wLhGq4L0udt IV41FvkcTXlNNaoadD2svV_TSA1WVuoZ8cOXCVj1kewm3dPqkcEC0bI.8BoTbG7xYROhH5u0XHf9 3Vp6EtG.UzovMxOzkqmj2ZJFJyeEp5OwFe76n80NTIU0fJrOSkwVUS_Wi71FZnTzbAo0KCgHEnHD ExDyMF8bfsaFSy.bm2GGJnqj1IUbhEbLuh0dmw0eK1mFCmWZHbhyBYQaswSxC_MJI9hkJLDvJ4o3 acsZkA2pGwLePKUJCj9yk0Ymofa4mn.2gUaWxWwMZmj99brPm.8L4WM3Bc4XaLBCkqPGhdhnolw_ jklHxLslxExfKhCz315caDtt0Z2g9Lvmob6Ukf_s4HTX8Dt5Yq21pHqZjKEP1kJ31xZY8H.5w23H qFxVATy2WMCxBz_CcWCtOiuRvdTNrDEpvEzgzSUtq1U8ibwpf8Ll6kQlvystav8ZZE_Itvftx6n3 .YxOAQcoa9BJb_.jW4PWND1pyiiTkid1aWZ74Fer7iEBvVJJSq2eeDql0GiXPxjgKEMmWRZ1urrF _YRVqd2w1SXO6dUdfMy9WjoP_O_gUB1H55GqAyajTlTlkUPCE0HjS6h7ma6MFJVj55DIQHZt138S m2NRR2_cYLmh7673.PJkG3FIYl9Wf_oTzsG3UN5KbgcKNncHC1_pwxQ9SJ3.pHMslhiA0.hR3dH5 b3jwDt_J48NjmgtoFNXT.V0gWeCBPkeTJbbgE7215Xg2pFR98P0WLtZbpQqyhUz08ryoKkGaDC2x ANXDZ6MxzKyrP5RGbxoOGNtUN0CvKlnVLQ5AbkEq1Mx9EP3X8YlRF5JhSBHHEMFrgJalbxLR02Mh HzLeak4SxjI0scK3kY_ZhF6w50ZefSiKrlAGPvoIgANmhIJ8oZMkwv5fw4NPFfRl2mUxEIroOMtn EPt9wmfEYP1wDKGY3H.oE.1artOzLcfXs8HYgTI8uk7frZLUAi7eGjYb.6W0qI.cnZa84K7LT0kJ 8YGyyDbag9xX9 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 10 Jul 2021 00:13:00 +0000 Received: by kubenode500.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1a843aa11e1a9de01149e9e7a77d23e0; Sat, 10 Jul 2021 00:12:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: <20210709230738.GA83522@www.zefox.net> Date: Fri, 9 Jul 2021 17:12:57 -0700 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0313838D-C54A-4517-A53B-C70B4EDDE296@yahoo.com> References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> <6D9BAA86-CB85-42E9-B4FC-6272141CFFDB@yahoo.com> <20210709230738.GA83522@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GM9Tp3MV7z4T61 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-9, at 16:07, bob prohaska wrote: > On Fri, Jul 09, 2021 at 12:46:47PM -0700, Mark Millard wrote: >>=20 >> Going in different direction, when you updated: >>=20 >> /usr/local/poudriere/poudriere-system >>=20 >> to have Jail OSVERSION: 1400024 (and probably >> matching the host OS main-n247590-5dd84e315a9), >> matching /usr/src/ as well, did you rebuild all >> your ports under the coherent combination? >>=20 > No. >> Or are you still using port builds in poudriere that >> were built with the jail OSVERSION being older than >> the /usr/src/ the builds were based on? >>=20 >=20 > Yes. >=20 >> Just like devel/llvm10 had a command that only-sometimes >> had problems when built via the incoherent combination, >> other ports could have odd behavior --but only sometimes. >>=20 >> My guess is that you have not done such because it would >> have taken far more time than I've noticed in your >> activities. >>=20 > Correct! >=20 >> I recommended before doing such a rebuild of the ports >> and then a reinstall of them. Given the odd behaviors >> being observed that do not repeat each time tried, I >> still make the recommendation. >>=20 >=20 > Just to be clear, after updating kernel and world I gather the=20 > suggestion is to repeat >=20 > # cd /usr/src > # make installworld DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 > # make distrib-dirs DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 > # make distribution DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 I though you had already synchronized = /usr/local/poudriere/poudriere-system to match /usr/src/ and the host root file system in use. If so, no = reason to repeat until /usr/src/ (and the booted host root file system) is = updated for some reason. Avoid mixes where /usr/src/ is mismatched with the root file system at the time. Of course, you might want to do another update to those for all I know. One thing you did not show was the command for after the above block of 4 commands for updates: # make -DBATCH_DELETE_OLD_FILES delete-old = DESTDIR=3D/usr/local/poudriere/poudriere-system DB_FROM_SRC=3D1 If you have not done that yet, it would be appropriate. For the current context of starting over, another command that is appropriate (that would normally be delayed to after all the poudreire bulk commands are done [were prior package builds were instead being put to use]) is: # make -DBATCH_DELETE_OLD_FILES delete-old-libs = DESTDIR=3D/usr/local/poudriere/poudriere-system DB_FROM_SRC=3D1 I'll note that the host updating procedure also involves using delete-old and, after package updates are all installed, delete-old-libs . (No explicit DESTDIR=3D or DB_FROM_SRC=3D use involved for the root file system update.) > Next,=20 > cd /usr/local/poudriere > poudriere jail -d main -C all > to get rid of the old jail and packages, then re-make the jail with=20 >=20 > # poudriere ports -c -m null -M /usr/ports > # poudriere jail -c -j main -m null -M = /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT >=20 > Have I got this right? One thing I'm hesitant about is=20 > the -C all option.=20 No reason to delete and recreate the jail, just do a bulk build that rebuilds the ports. The first "poudriere bulk" of a sequence can use the "-c" option to clear out the existing packages (and logs) before the builders start building. As far as I know you eventually want to install: # pkg install chromium (that will also install things required to run chromium). I'm not sure if you have a list of other packages that you want explicitly installed. So my notes below need not cover everything that you want to do. (I do not know if ALLOW_MAKE_JOBS=3D and such is appropriate for the llvm10 bulk build but it may fit in the resources okay:) # poudriere bulk -j main -c devel/llvm10 > = bulk_from_scratch_for_llvm10_1st.log (I'm unclear if you would want a -J? to limit the builders count for the above command: if so, use it too.) That -c will first clear out the existing package builds (and the logs according to the documentation). Then it will start from scratch building the required ports. This will build a lot of ports, those needed to in turn build devel/llvm10 . So having -J1 used and ALLOW_MAKE_JOBS missing would make for a very long build time. You probably want to allow some combination of multiple cores to be in use, possibly also involving MAKE_JOBS_NUMBER=3D use. You know more about what combinations worked before. Reminder that ALLOW_MAKE_JOBS=3D control would go in: /usr/local/etc/poudriere.conf but MAKE_JOBS_NUMBER=3D control would go in: /usr/local/etc/poudriere.d/make.conf (I do not know if ALLOW_MAKE_JOBS=3D and such is appropriate for the rust bulk build but some combination may fit in the resources okay:) # poudriere bulk -j main lang/rust > bulk_for_rust_2nd.log (I'm unclear if you would want a -J? to limit the builders count for the above command: if so, use it too. You know more about what combinations worked before.) (Without ALLOW_MAKE_JOBS=3D is likely appropriate --or at least the MAKE_JOBS_NUMBER=3D may be needed-- for:) # poudriere bulk -j main www/chromium > bulk_for_chromium_3rd.log (I'm unclear if you would want a -J? to limit the builders count for the above command: if so, use it too. You know more about what combinations worked before.) Note that the management of the limited RPi3B context involves adjusting things like ALLOW_MAKE_JOBS=3D and -J? usage for each huge build to limit resource use to an appropriate scale for those builds. For smaller builds, more can be allowed (more adjustments). I do not know if there are other ports that you would want to build and later install that are not automatically built by the above or if you have a list of such in a file that can be used with -f . In your context this would probably be a list of ports that do not involve huge builds, given that you had already done the above bulk runs (and any others that might involve more huge builds). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Jul 10 17:40:10 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1386811E4328 for ; Sat, 10 Jul 2021 17:40:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMck14H9Gz4YB0 for ; Sat, 10 Jul 2021 17:40:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 16AHeAVm092404 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 10 Jul 2021 10:40:11 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 16AHeAAE092403; Sat, 10 Jul 2021 10:40:10 -0700 (PDT) (envelope-from fbsd) Date: Sat, 10 Jul 2021 10:40:10 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-ports@freebsd.org Subject: Re: Too many pythons in poudriere Message-ID: <20210710174010.GA91320@www.zefox.net> References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> <6D9BAA86-CB85-42E9-B4FC-6272141CFFDB@yahoo.com> <20210709230738.GA83522@www.zefox.net> <0313838D-C54A-4517-A53B-C70B4EDDE296@yahoo.com> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0313838D-C54A-4517-A53B-C70B4EDDE296@yahoo.com> X-Rspamd-Queue-Id: 4GMck14H9Gz4YB0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jul 09, 2021 at 05:12:57PM -0700, Mark Millard wrote: > On 2021-Jul-9, at 16:07, bob prohaska wrote: [big snip] > > Just to be clear, after updating kernel and world I gather the > > suggestion is to repeat > > > > # cd /usr/src > > # make installworld DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 > > # make distrib-dirs DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 > > # make distribution DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 > > I though you had already synchronized /usr/local/poudriere/poudriere-system > to match /usr/src/ and the host root file system in use. If so, no reason > to repeat until /usr/src/ (and the booted host root file system) is updated > for some reason. Avoid mixes where /usr/src/ is mismatched with the root > file system at the time. > > Of course, you might want to do another update to those for all I know. > I tend to update /usr/src and /usr/ports somewhat randomly, based on elapsed time or in response to trouble of some kind. It looks like that habit may be the source of at least some of my trouble. > One thing you did not show was the command for after the above block of > 4 commands for updates: > > # make -DBATCH_DELETE_OLD_FILES delete-old DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 > > If you have not done that yet, it would be appropriate. > > For the current context of starting over, another command that > is appropriate (that would normally be delayed to after all the > poudreire bulk commands are done [were prior package builds > were instead being put to use]) is: > > # make -DBATCH_DELETE_OLD_FILES delete-old-libs DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1 > I got burned by a delete-old-something long ago, broke most of the installed ports, and haven't touched it since. In this case it does seem appropriate. Added to the update to-do list. > I'll note that the host updating procedure also involves using > delete-old and, after package updates are all installed, > delete-old-libs . (No explicit DESTDIR= or DB_FROM_SRC= use > involved for the root file system update.) > It resembles the command that bit me.... > > Next, > > cd /usr/local/poudriere > > poudriere jail -d main -C all > > to get rid of the old jail and packages, then re-make the jail with > > > > # poudriere ports -c -m null -M /usr/ports > > # poudriere jail -c -j main -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT > > > > Have I got this right? One thing I'm hesitant about is > > the -C all option. > > No reason to delete and recreate the jail, just do a bulk build that > rebuilds the ports. The first "poudriere bulk" of a sequence can use > the "-c" option to clear out the existing packages (and logs) before > the builders start building. > Aye, there's the rub.... It appears that incremental updates are a costly approach (world/kernel, then a port, then world/kernel...). It seemed one could get away with it using make in the ports tree, though perhaps some of my troubles with that approach had the same origin. > As far as I know you eventually want to install: > > # pkg install chromium > > (that will also install things required to run chromium). > > I'm not sure if you have a list of other packages that > you want explicitly installed. So my notes below need > not cover everything that you want to do. > Getting a running version of chromium was the origninal goal. The train seems to have run off the tracks......8-) > (I do not know if ALLOW_MAKE_JOBS= and such is appropriate for the > llvm10 bulk build but it may fit in the resources okay:) > > # poudriere bulk -j main -c devel/llvm10 > bulk_from_scratch_for_llvm10_1st.log > > (I'm unclear if you would want a -J? to limit the builders > count for the above command: if so, use it too.) > > That -c will first clear out the existing package builds (and > the logs according to the documentation). Then it will start > from scratch building the required ports. > > This will build a lot of ports, those needed to in turn build > devel/llvm10 . So having -J1 used and ALLOW_MAKE_JOBS missing > would make for a very long build time. You probably want to > allow some combination of multiple cores to be in use, > possibly also involving MAKE_JOBS_NUMBER= use. You know more > about what combinations worked before. > > Reminder that ALLOW_MAKE_JOBS= control would go in: > > /usr/local/etc/poudriere.conf > > but MAKE_JOBS_NUMBER= control would go in: > > /usr/local/etc/poudriere.d/make.conf > That is a helpful distinction unclear to me till now. > (I do not know if ALLOW_MAKE_JOBS= and such is appropriate for the > rust bulk build but some combination may fit in the resources okay:) > > # poudriere bulk -j main lang/rust > bulk_for_rust_2nd.log > > (I'm unclear if you would want a -J? to limit the builders > count for the above command: if so, use it too. You know > more about what combinations worked before.) > > (Without ALLOW_MAKE_JOBS= is likely appropriate --or at least the > MAKE_JOBS_NUMBER= may be needed-- for:) > > # poudriere bulk -j main www/chromium > bulk_for_chromium_3rd.log > > (I'm unclear if you would want a -J? to limit the builders > count for the above command: if so, use it too. You know > more about what combinations worked before.) > > Note that the management of the limited RPi3B context involves > adjusting things like ALLOW_MAKE_JOBS= and -J? usage for each > huge build to limit resource use to an appropriate scale for > those builds. For smaller builds, more can be allowed (more > adjustments). Since I usually play with ports one at a time, is there any advantage to using testport versus bulk? Better diagnostics, maybe? > > I do not know if there are other ports that you would want > to build and later install that are not automatically built > by the above or if you have a list of such in a file that > can be used with -f . In your context this would probably > be a list of ports that do not involve huge builds, given > that you had already done the above bulk runs (and any others > that might involve more huge builds). > It's clear that by segregating build dependencies from run dependencies poudriere provides a valuable service. Might there be a make target in ports that cleans up no-longer-needed build dependencies during installation of a given port? That would, I think, have been enough to avoid the python27 conflicts. Is there a plain-language description of the logic poudriere follows for building ports? I found this: https://forums.freebsd.org/threads/pkg-package-repository-using-ports-mgmt-poudriere-with-or-without-zfs.38859/ but it doesn't really touch on the topics I'm looking for. Something on the level of a simplified flowchart or (gasp!) PowerPoint, maybe? Thanks for reading, and all your help! bob prohaska From nobody Sat Jul 10 20:49:21 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 22A1E127A820 for ; Sat, 10 Jul 2021 20:49:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMhwS5CZVz4vRM for ; Sat, 10 Jul 2021 20:49:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625950167; bh=jV2mM9XiCl23Jqpb6r5yz+R+n0Xo4zyjyjrwYTnVIW4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Y3Oi3x9UJokSUN6T92mVNNVNoBFnyxFT2dfOeP2uc4TloPH73p/v1At00r04Z6Klnk1RSYrIJBprLCUScxFmQ6QFKDFChRuSUqJGBwCaBr4jHkf6YrvK2XkL7RQCjKVUXJhuNKgVcb99Krgb9LiMGKFr0WqIsMnKfYCKGCDcaCOQ1X8htE64Ad0LM3oEDUIUs9oixUdhe2QNrRmlI4ph9CRmtH8v+B38fJFBekrNNXcCNG3OzpHJZwu1HqcWUR0hfXd3T3kaAJbh7XAcABH1M/a1uYY+BBnr9P/+w7FKj10z8F86pec5xJb52JYAZcjAsCNlbFUi8TNjafdJxHyeew== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625950167; bh=ltgAdtUa7V2U8JzMa0QBO/8mTDgm//dTqYnQtnqcIMP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QZvr3TvtKK8s/AafCnkMOSKvq3BON3U8N6ggSQckF4szLS65fu3C1vYKLUcchQ821cO84Ap7YuTJRiEui13ktQIzn7DDZT9xgZjGubf193XPboWstf0/Jiiqw7yFaRphxGLYJtAzXqRaxqYrrwsRG/vK7gfSQ258Ky1XYnfVC5tTnMwzJEVr3z4fIbJ4K6mCKd2VGqa3qvNuMqVvcVo4MXO5hGQkkx2eBH6ypIKg6JD6LS5cjDwC5QDH96SN2SM57eI4+A38uKmYJS2t7DfZdCaiANRkFcwFSF4gLyZ/1H39XTj88TLmAeckvPhFYchBhHzDpNOwojg33/pvXzT/Nw== X-YMail-OSG: v6CpMJUVM1kvxeKDX5xdDXQVkk3ejY7D9xvfytU.3_4IKv_5_MvLYQIiwgi5l8_ a7PlRKd_43tYk78_fS1vvfXiVkaXq8K4CWvqHIU.igAYhgxopRyLSpCMMJyNev6sr4YTiCIrXL6X 9aUsm3AgOM3KddduIgQFEo2IBDjwd6zfWLIMw8lShXb3W2EZZVOnmjbQxs4mN6DITh7Yny6Wa8SA b9UZwoAn6I0utnBbHzD8fABo.N1hNDxfwRGwqYzT6T9fBhJ07kaeM74eLYCx.LkwkG3zOKvuCbVa .J0rwM9H99FqPZZCBoJTtsP0LxaYjQKjRzGtXKVGhHw8UPi9wiU6AEUFHhBbQvQ4FvfGMvaqAfIC wg96ZNqRKDTdy4nyUbBdIcZ3AUwagU8VZaKm4ZSJlG6GYmJGK797CksAzlvzoH6CNID3uWiHG4iI tLS69XWw2Ht7ubV8WvAW0TIif4FjPK7h0sGgedQX_we772CYR7vwKJZUvvQXsIYCdLPgiibGAoHM OnxRAXol20lQfKa3udeTvbOYIDee34ROoepPwxWlqPcFwfYdk8.izVZyqiUJteZlMSrKVsB9QQIo OrfR1RysnZiIijfp1IYNyw.vHY.Ijib8HMMNX3Hd45t4aJ0jONNyfhFnmAwboipA5ls1EGilR9s0 qSVCM5MZL0udtCoVXPcjf2YMBX6iyde_XWKtCw7wrh3hd.I0q7cULb7md2WrtpozKq4uPBtXJRBb KI5Qpn1sF4SsVLJkiJqcS43gyPfdn_S_reXAYQ8.Birk1bGA7PE6H2JhbscV8f3n6YSf7E9SvXB4 K9.MgGbsGyJNuOSkMUVMECZxZ3ur3h5q3OepSYOHvRLmxEgfhRwgxZ8_tf7p6M.6QcMUDI5tQ9bp Hph_qhsrfYnRfUbvlnc_6OA1_vuUoX7WUMrpfhbDbCd_u4B6KO5HfSL8xsucy0uDpszalQqYoarb YA_Y.HpIM_nPsw10Z4Lh07cYEDbDvEUK2IWFygZlbLws87OAT9j5kpfOeKFG1nun5IJSJaorcFPH ukIvOsWNN3fEVT8.k1ranLiRA6crNsj9lxiknAiXKI8STPGG8JEcXhyNkLNpYuJq6tefiKzu8jrY gvas9298wrNkSoZRBbYHHEwf0SY4pmLqq0oJU5V8rNP75MNq.j1BVjrIx_l4cXlvQwi66FtUA2zd aHBcX0N8EfHoapf0gq6PWefkIvjP3VDtt.74TTFhXTrt.WTNJnw68DGRJYU2UKOhzGoyX_ehpRdG EzsGe4RGjYa69ecDJvV.TP.X1wIRUKp6s5QDplypUyQ8hOsl3.A_JX0kxY3.rnRkd0JdGJ33BqYB IW4sR_dasdxk14_zPIDojIfIo_zwXLq8UIEXeTy.bmV2Su4_NQZyU_T57tkma__mh7BnTT4iiiAf _TDlQ.X8fJ9qRl77zS6yth.mSylf6JVWPqA4puy4jPIQjF2x0SLL8K9dNWMXXM3rCazCWPj977Tj owWiIjCF7jRsO05i7tLsTrTf869PdubyH8eu0reC2sb_4l75gq7TENgNqr4Y8S0cNgRQ0fvhgxdf RjZzJIfe9Rjvo.3WzqFpLKiZs2RFNLdVTQO0fv6dpcGZF0D_2upPDqpZg8BhqsRiNGKKNbG0_gyA E9vGt0_UOSpy1Y6X_GTA1SySbvM4aKjx_wSM7F4Su45mkyteTY_v2Pg2xEIf4_30zu6Wv_ZDis2m 1ySXZTWnbbJFp43VtVRlDW5BU89Zmex.NAKHAu.hf80usqm17pYQuY.iZmJqbsezy1IdVwBAdLmK jYNFBupNIGkX.sxo6_dgGYiWDledFhOU0UBzVCw9s0LDtlii9AFpIgkJvpM1Aq902USgdvKiFfYH AF9Hevwwno.L_4UM4zjsiu897vQGpg3soVEWT2pynswzJzStluglXzLeJ0OuVTe2Y12x1wIFMZlj pO0NKGVOhTm4jDWeuPUmaunTCv_qPp7nFqG4XkHsWh7Pfvs2zkeIB04aCBqhMs_pZWQIR4QJPTrT xu0hYvhZx2bkErjGtHIooXn6MnPDmauoyy85JzYDGWwHrc95tKPoQrntcbVm.JhtyOShc8bhFrMC yRnhmZa0F_g_YxMbnCaNc79dpKs9kIG7npMwmyO38xJIehink6xi6CKz8aHhivtdd25ZcoXqM_Zb PNy3.pGcOoCuiRwdh4hIYgiFJKwlX9eYXgnAYiriuaskxHhNojUzx4oPSLqu1Hf2hMPlTn0HoGQb 2yAottMYmfEhlRLQtlytBW4Abeq14H1qug94t98gfsacqjowUeb5.GJiyKjrS.KuJcn60qY7E4Qj 9Cmp7myx61PmZ2GkBFyXNVmMCqbDqcySPlFBdW8wCww0sze71KXj0t2eLJtHCSfsupzEDv4OH.uG MkndTfl86TN_uVkuD1LWM1ypw2t1HNkd1OUjHQ4nBe79AKpqqZrqf5VbbMn93YBCdwvLr6eZzAvj IH1nVFZKz_47br5zEWW76TILlgbl9rmjiI9jZ9hzK.NvgUTiNpSfLvHP6jSTa8AbHWpkw0uYKVLb 5BaLHXg.8Nhb9IE.ZE_wT0Zv_d7y0KuZZd8r6K.ZldeTaV0aulvw0GkIJdbd.Og9MPUltBW5SkpS h.YMSh8Gb5IxuetiXjDZB67ZzcBPjvUWQVeaOtJl80CZX2BT7ZOdYWPGxHQ.a X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sat, 10 Jul 2021 20:49:27 +0000 Received: by kubenode538.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 81f24faee1ce70537a7f524a75649ce4; Sat, 10 Jul 2021 20:49:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: <20210710174010.GA91320@www.zefox.net> Date: Sat, 10 Jul 2021 13:49:21 -0700 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> <6D9BAA86-CB85-42E9-B4FC-6272141CFFDB@yahoo.com> <20210709230738.GA83522@www.zefox.net> <0313838D-C54A-4517-A53B-C70B4EDDE296@yahoo.com> <20210710174010.GA91320@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GMhwS5CZVz4vRM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-10, at 10:40, bob prohaska wrote: >=20 > On Fri, Jul 09, 2021 at 05:12:57PM -0700, Mark Millard wrote: >> On 2021-Jul-9, at 16:07, bob prohaska wrote: > [big snip]=20 >=20 >=20 >=20 >>> Just to be clear, after updating kernel and world I gather the=20 >>> suggestion is to repeat >>>=20 >>> # cd /usr/src >>> # make installworld DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 >>> # make distrib-dirs DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 >>> # make distribution DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 >>=20 >> I though you had already synchronized = /usr/local/poudriere/poudriere-system >> to match /usr/src/ and the host root file system in use. If so, no = reason >> to repeat until /usr/src/ (and the booted host root file system) is = updated >> for some reason. Avoid mixes where /usr/src/ is mismatched with the = root >> file system at the time. >>=20 >> Of course, you might want to do another update to those for all I = know. >>=20 >=20 > I tend to update /usr/src and /usr/ports somewhat randomly, based on > elapsed time or in response to trouble of some kind. It looks like = that > habit may be the source of at least some of my trouble.=20 >=20 >> One thing you did not show was the command for after the above block = of >> 4 commands for updates: >>=20 >> # make -DBATCH_DELETE_OLD_FILES delete-old = DESTDIR=3D/usr/local/poudriere/poudriere-system DB_FROM_SRC=3D1 >>=20 >> If you have not done that yet, it would be appropriate. >>=20 >> For the current context of starting over, another command that >> is appropriate (that would normally be delayed to after all the >> poudreire bulk commands are done [were prior package builds >> were instead being put to use]) is: >>=20 >> # make -DBATCH_DELETE_OLD_FILES delete-old-libs = DESTDIR=3D/usr/local/poudriere/poudriere-system DB_FROM_SRC=3D1 >>=20 > I got burned by a delete-old-something long ago, broke most of the = installed ports, and haven't > touched it since. In this case it does seem appropriate. Added to the = update to-do > list. delete-old-libs should only be used after the ports/packages have been updated and installed --unless one is starting from scratch anyway. >> I'll note that the host updating procedure also involves using >> delete-old and, after package updates are all installed, >> delete-old-libs . (No explicit DESTDIR=3D or DB_FROM_SRC=3D use >> involved for the root file system update.) >>=20 >=20 > It resembles the command that bit me.... My guess is that you ran delete-old-libs before having installed updated packages/ports. Having old libraries can lead to its own problems if they continue to be used in places instead of those places updating to the newer library versions. >>> Next,=20 >>> cd /usr/local/poudriere >>> poudriere jail -d main -C all >>> to get rid of the old jail and packages, then re-make the jail with=20= >>>=20 >>> # poudriere ports -c -m null -M /usr/ports >>> # poudriere jail -c -j main -m null -M = /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT >>>=20 >>> Have I got this right? One thing I'm hesitant about is=20 >>> the -C all option.=20 >>=20 >> No reason to delete and recreate the jail, just do a bulk build that >> rebuilds the ports. The first "poudriere bulk" of a sequence can use >> the "-c" option to clear out the existing packages (and logs) before >> the builders start building. >>=20 >=20 > Aye, there's the rub.... It appears that incremental updates are a > costly approach (world/kernel, then a port, then world/kernel...). > It seemed one could get away with it using make in the ports tree, > though perhaps some of my troubles with that approach had the same > origin. =20 You are still trying to get back to a correct environment so things are not normal yet. Plus you are trying to build things that are too big for the environment you are using to just automatically handle it. So you are having to manage the resource use explicitly as you go. [I do not do that: so far I've used systems that have enough resources to allow ALLOW_MAKE_JOBS=3D and all cpus(/cores) to be used by each builder for the things I build, devel/llvm*'s tending to be the largest builds but two or more of those at a time has happened. I'd likely need adjustments for whatever the biggest port builds are.] Use of -c is a very rare thing for me. But when your /usr/src/ goes from something like 1400024 to 1400025, poudriere should notice and to a full rebuild automatically. (So the in world installed in /usr/local/poudriere/poudriere-system better be a match to the /usr/src/ at the time.) The reason for the full rebuild is that the type of change might require it. There is no separate, more detailed, indication about what actually needs to be built. Anyway, poudriere will fully rebuild on a regular basis during periods where that number is changing on a regular basis. main tends to have such changes on a fairly regular basis. >> As far as I know you eventually want to install: >>=20 >> # pkg install chromium >>=20 >> (that will also install things required to run chromium). >>=20 >> I'm not sure if you have a list of other packages that >> you want explicitly installed. So my notes below need >> not cover everything that you want to do. >>=20 >=20 > Getting a running version of chromium was the origninal goal. > The train seems to have run off the tracks......8-) >=20 >> (I do not know if ALLOW_MAKE_JOBS=3D and such is appropriate for the >> llvm10 bulk build but it may fit in the resources okay:) >>=20 >> # poudriere bulk -j main -c devel/llvm10 > = bulk_from_scratch_for_llvm10_1st.log >>=20 >> (I'm unclear if you would want a -J? to limit the builders >> count for the above command: if so, use it too.) >>=20 >> That -c will first clear out the existing package builds (and >> the logs according to the documentation). Then it will start >> from scratch building the required ports. >>=20 >> This will build a lot of ports, those needed to in turn build >> devel/llvm10 . So having -J1 used and ALLOW_MAKE_JOBS missing >> would make for a very long build time. You probably want to >> allow some combination of multiple cores to be in use, >> possibly also involving MAKE_JOBS_NUMBER=3D use. You know more >> about what combinations worked before. >>=20 >> Reminder that ALLOW_MAKE_JOBS=3D control would go in: >>=20 >> /usr/local/etc/poudriere.conf >>=20 >> but MAKE_JOBS_NUMBER=3D control would go in: >>=20 >> /usr/local/etc/poudriere.d/make.conf >>=20 >=20 > That is a helpful distinction unclear to me till now. >=20 >> (I do not know if ALLOW_MAKE_JOBS=3D and such is appropriate for the >> rust bulk build but some combination may fit in the resources okay:) >>=20 >> # poudriere bulk -j main lang/rust > bulk_for_rust_2nd.log >>=20 >> (I'm unclear if you would want a -J? to limit the builders >> count for the above command: if so, use it too. You know >> more about what combinations worked before.) >>=20 >> (Without ALLOW_MAKE_JOBS=3D is likely appropriate --or at least the >> MAKE_JOBS_NUMBER=3D may be needed-- for:) >>=20 >> # poudriere bulk -j main www/chromium > bulk_for_chromium_3rd.log >>=20 >> (I'm unclear if you would want a -J? to limit the builders >> count for the above command: if so, use it too. You know >> more about what combinations worked before.) >>=20 >> Note that the management of the limited RPi3B context involves >> adjusting things like ALLOW_MAKE_JOBS=3D and -J? usage for each >> huge build to limit resource use to an appropriate scale for >> those builds. For smaller builds, more can be allowed (more >> adjustments). >=20 > Since I usually play with ports one at a time, is there any > advantage to using testport versus bulk? Better diagnostics, > maybe?=20 man poudriere-testport: The specified port will be tested for build and packaging problems. = All missing dependencies will first be built in parallel. = TRYBROKEN=3Dyes is automatically defined in the environment to test ports marked as = BROKEN. See FLAVORS in poudriere(8) for supported FLAVORS syntax.\ but has a longer description in man poudriere. I'm going to quote that about what I think is different from bulk vs. the same as bulk when a single port is listed on the poudriere command line: QUOTE [with notes] Test a single port This second example show how to use poudriere for a single port. = Take the example of building a single port; poudriere testport -o category/port -j myjail all the tests will be done in myjail. It starts the jail, then mount the ports tree (nullfs), then mounts = the package dir (poudriere/data/packages/--), = then it mounts the ~/ports-cvs/mybeautifulporttotest (nullfs) it builds = all the dependencies (except runtime ones) and log it to = poudriere/data/logs/testport/jailname/default/mybeautifulporttotest.log). [Ignore the ~/ports-cvs/mybeautifulporttotest detail from what I can = tell. However, I believe this is indicating that the places that some things = would go for normal use will not be used. Some temporary place is apparently used instead and the material in that temporary place is not kept long = term.] If packages for the dependencies already exist, then poudriere will = use them. [Other than a temporary spot vs. the normal place, this is like bulk.] When all the dependencies are built, packages for them are created = so that next time it will be faster. [This does indicate that, like bulk, the dependencies will be remembered and reused when built. That does not say that the port being tested will be remembered or resued, however.] All the dependency phase is done with PREFIX =3D=3D LOCALBASE. After that it will build the port itself with LOCALBASE !=3D PREFIX [There is a testport option -P for "Use custom prefix".] [bulk would use the normal PREFIX =3D=3D LOCALBASE unless the port itself makes assignments. This is a test for if the port is handling PREFIX and LOCALBASE correctly. The earlier ~/ports-cvs/mybeautifulporttotest material is possibly trying to reference to where the unusual place PREFIX might be. But I see nothing in the scripts constructing that kind of path automatically.] and log the build to = poudriere/data/logs/testport/jailname/default/mybeautifulporttotest.log [Again ignore the "mybeautifulporttotest.log" naming detail. bulk would not put the log file under poudriere/data/logs/testport/jailname/default/ .] Poudriere will try to: install it, create a package from it, = deinstall it, check for cruft left behind and propose the line to add to = pkg-plist if needed. [bulk would not do such an install/create package from = installed/deinstall in some temporary place to test the installation/deinstallation = handling.] END QUOTE I do not see any differences there that helps in your build activities or for better error/warning messages about the types of errors that you get. I'd just use bulk, listing one port on the command line, not testport . (I do not use testport because I'm not developing ports or significant changes to port Makefiles and such.) Using testport does not change needing to manage the resource use for devel/llvm10 lang/rust www/chromium steps on the RPi3B. Nothing will get rid of having to do that management for building on a RPi3B. The only thing that will get rid of needing to the that management is to use something other than a RPi3B that has more resources (especially RAM in proportion to core counts). >> I do not know if there are other ports that you would want >> to build and later install that are not automatically built >> by the above or if you have a list of such in a file that >> can be used with -f . In your context this would probably >> be a list of ports that do not involve huge builds, given >> that you had already done the above bulk runs (and any others >> that might involve more huge builds). >>=20 >=20 > It's clear that by segregating build dependencies from run > dependencies poudriere provides a valuable service. Might > there be a make target in ports that cleans up no-longer-needed > build dependencies during installation of a given port? That > would, I think, have been enough to avoid the python27 conflicts. How many other ports might have the same build dependency? How many other ports might have a run dependency on the same port that is just a build dependency of the port in question? How many other ports would be damaged by the removal of what the specific port has as only a build dependency? Rebuilding each dependency each time a port is built would use massive time and resources (fully independent builds). poudriere manages to reuse built ports in more contexts instead of rebuilding them but keeps things clean anyway. Dependecy management is not a local-to-port thing but a more global thing, unfortunately. After poudriere has everything built for later installation: # pkg delete -a . . . # pkg install chromium . . . will remove all the ports (except pkg) and then install just the ones needed for chromium's operation. > Is there a plain-language description of the logic poudriere follows > for building ports? I found this: > = https://forums.freebsd.org/threads/pkg-package-repository-using-ports-mgmt= -poudriere-with-or-without-zfs.38859/ > but it doesn't really touch on the topics I'm looking for. Something > on the level of a simplified flowchart or (gasp!) PowerPoint, maybe?=20= Out of all the things involved in poudriere's operation I've no clue how to identify just the possibly small subset you may be curious about. I doubt that you want to learn about all aspects of poudriere's operation. (Well, beyond my range of knowledge. I investigate as needed as I go along.) What you sight is (old) how-to-use documentation, not how-does-it-work documentation. So I'm not even sure which you are after. Either way, I'm not aware of anything that is a likely match to whatever you are hoping to see. A lot of your questions are of the nature "how do I side step the available commands for how to use poudriere". "Plain-language" and jails and repositories with transitional updates (all updates completed vs. no updates being the two results, no mixed results) and such do not tend to go together. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Jul 10 21:17:46 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5F98E127DF57 for ; Sat, 10 Jul 2021 21:17:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMjYD36GDz3Fyd for ; Sat, 10 Jul 2021 21:17:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625951870; bh=lADrKYgUd3NMkHtIolA0B8s7r0nAoWGIR0jA8ukT8go=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=StxfB4ALAqP9tvquiglCgLY+xznh5bWTpfTQJougmebPpgkH9FhtHNQZKT26R4yl7NZ1ugUf940owiNf6wCliJoq+m2mjiKLmPszShgsd9NTLlR7QIecfnLG4C6Yy63aMtcmG94thetGl4dUlgnCPRfT5B26cJ3mMGU0PZnOtKYDWFHxRBQJjvNv30CbaAd77x8uWXW2USBzw3SYUCKTPcUjqvhRA0i9YFTFp71Vjs6xSluwrLClZupamAKGd8yeT9YL7TPkESMyFMMQNP5byi3s/EJ5G2Co8tyXQ7NjYCmqA64p9Yt9yx6xbMgB17UAnQDMMfeuxkyDfKgR8fU9PQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625951870; bh=rx17O+yaXhYzMDSqnToSq8NOH5ulXHf9dpvTkLJyBXO=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AKXu1sgUrrcgS3JQ+yiA55zi/COizZpRz0m1cbmrirWQTJkLN4gkozRKz/v1j1en0Q9t796NuFbAzlYzVt2+ZwfAC5/Kwv1De3pzUS3O+gL7OGHlukNte10eVP2FtyMWpMlZGfidzhUCtdsmfrcXG5anvRrXMldY8aEhU2EFs6VhnNHXz0t9XEdQXUag/aqWe9MjtXV9LtKP/ewiUC6OD9G6FNfXGgWO20QHx/Pxypfv1CxHp291gGsv9TZ0ojG4e7jZ9//6mn9VTVbv6YS0ZxBbwIASbx+WW3S+zYgy8oV6RRp4qvYKR5URJqZFyvZrO3BnWhIJ5UJHGES8gw4X9w== X-YMail-OSG: NjyGWGoVM1mXTxGn9dEUDdqVSKzVjVjeusJs.JFIeUsaweGtmEmFSr0FyX7KF.I tD23BRA.3KGgGDUDfjip3.mDK53xyVCQomlzv_BPBExzT7MiVwlIYh..DapEx2Pnkl1SNocCzsVJ isZi3MVHFdyceudZLDBg.8n6WgAJx8QGwDPOdbNW8pjGtswm0.GAb_WBqGoBkaBNtcoEWMg4YWR9 0DDStqmxHyuIHkqnWKqlpLuPNFRZ6hPxrVdKslP_07NFmEMzeQ1mQq1WUy3tZiljMu8DY4qiB6si 1uRF1bPhu.GBS9fYnOOB11Pbfj.yE0dj2O_gGPK9ta7y7IsTfJt75MJOal6Zen7Ib2FlyRh.8fC1 mJE3LURWvl7qg5rJMQo_9NSYcMbjcxQaiPZjj2NhfvEYVu_Y_M.AIyE1K5ByLUR9bkjhd5Uydbk9 vvAMNgUKs2LSeW4xqLpFvRzwlrgmDLQc9vP2GBnd.Cl6zU8vtgwMbMm9UOfAVnrrXymxrLPLfEsW SNBeoO7kVniAFz4lChzKPP9blLYYXZDQlpx8S58p57nyr6RAgXay3WbBcDZiH_yXKyk27LoG5kY. qYsWN0LdsuiaMxUfPnHNd60c73SCsDDYaCQH1QC529ojdxwzhRUEIuWeyP8Mxsrigij_E_9hcN5p SSJhF4NCOlwG1hZj4RKFlnojU1sTE8x7ckbzsoJffSuQsccBXdDmI36dyAIyhosh1Unfkoirb0WT UZMqs9ZDeWL2nkdh5zBe.KYA8NSvxGeu8wc6jbRRrPXZ0K6Vy3YXL.4nF8XH91mnkxTYn3Dz07op DoDXsLLruzAW88cUadMXI7myJ1Ym1PKtf6UoLNuOVHW7B1PXNg1k2pcn9okHbfOoSLJN8NXDSVCE 5OBA8CbsTUXPiu2q7tptuSMA1.IiS5.g7GadnQ2wU58cv9la_G5VIm1mIGNWTb1l8paH3kSqX1AA JPwc_Wv6bTj_6u4CVyVjML2q13ExCIUjhFw5Pko1h8yjAW4so7_EISLWrPnbFiD_fkMxBKykWE_u 501k2EvsbRh4IjE9P3_PcQtYVpZ3eoxRKQfFXYjOhHlJvlmdvsPaC5g8hjIvwmxeFatGP4YSryzl jqBcIs6rqvRuY4E31O5CrHekqUW6s9zlRoGgpJaqsTAijs7.InePhFRyXP3.Ad3mal7hMePWELp9 HqV4C9hCh8ahgqJ3yczWWEmb_7K.zM.9xri7A8EfjW7iow5Df7FTxoqhjyQcn0ljuHmQbI.72gOb sgIV0ww6zy6RR76eNYWptMXPE70en7JnxNKBDg5bg0qVzH0CHDI2bjcqR4KFujaZljNKyRfPwjMm aVD52NFmJpdpZMdUEdryqqs..VPbFjL7cM_7dpus2wFQXIE0oYRY71pKfGIgE9JD8V4qcdWeYeBb BHUz8ubg8pQGEE3Mrol5BZ63r54ZCQRRb7qcGb._ikJJvj5Rr5MpJMonpl_0Ch.NyeIhZTiIh0oS kXdr8_rmAgXswy7ggkPht76ygtsUE71EVQ2_Mw3NSNR0er4vUGPJAx4S0ac0OTO44sE8tJLrPD53 KMBLxIE2bo_aotNPkPFxarzVzcJCmXJPjnv6YOabzfezs_Ewj5dNBVVPB3Ho.vgrHxRp9OTQG.Wi 1ssU3TIvVj_W1GpbAYYuXZ7eihK.Te2PSa7fNJzdkNlibcyRB8zjVgP8XZzv4tf1BUDxZtJ1AbuB 8AybHmxrDwoOe234A5TfuQuX8goT6xj34MJ_Y2VoeTZjQ.vqPCg4ghzHEKb5qa4m_ehNQcTG3nyf 34mZUyhAmF76U7JaERZPKtXdARMNQcyEVzj7mRWXOneAUOBjJbzdAS40kGDpXuISxW1xXlWuxUor hOkrcU64stu0Ev6TisD5MroUzLdjAE19AEMaGPkwR4VlHCVwmKP67HMoUUL1_ceSc.qwx8dPYlSf rV3QQudckZedi3LbIjf5Z6xrJZwMIq5OD9ttXiN8oJhRrjgvpj4KZr1Y_uomDH5TE0QMBH7KRthi LFe6LXBRTOgl7xd_RGJsNf5tWMhL4c6mJueBmepqR2hOThNXh4SW7UDQnLp4xuCUTDEsfStyfzFL cKIPmYw6Bb.gXXsXOrOfduI1unP.SRiyXypC2QeayhrABK1dyKduTPh6xugB_MfXFIYirzCNZeL8 I4TbXPK1i.8XvI4L1cTNzgLwWT9H9wi_RYKoxcO3owQAR_A3zacJBspjvkxRfvZ4PGU9QFiNRJkV qGDJ5921MS4zbwdC1cKGygMnp5aM2gqlohvJZ_bUlmhwCxCWR0J5A09ciUPbxATqhZ7XehVqP2gI qqUrJOLXm_kep6gt_QQCe9YUlKHTPOZckAfrrXMfEDvCXbfFQLugRx.SucO22.26UulRYoCQb9we dnIg8OSJXWoCiV2N5wb9uLa7UMagQfCqPIUmcEBGw7SUKVq0wNefJmkv0sT9mVzeawl0n6peL5UE 9d0udT4K_urQ5O2ueVtHgN4KPrX7IJKKQaQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 10 Jul 2021 21:17:50 +0000 Received: by kubenode518.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6dd48843ad8c84eb7d96bba72af5662f; Sat, 10 Jul 2021 21:17:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: Date: Sat, 10 Jul 2021 14:17:46 -0700 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <66D2ACD1-B70E-4378-9836-9122E7F72782@yahoo.com> References: <044A7E63-2734-41F4-A1A2-AE5096C6A62C@yahoo.com> <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> <6D9BAA86-CB85-42E9-B4FC-6272141CFFDB@yahoo.com> <20210709230738.GA83522@www.zefox.net> <0313838D-C54A-4517-A53B-C70B4EDDE296@yahoo.com> <20210710174010.GA91320@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GMjYD36GDz3Fyd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=StxfB4AL; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.90 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.40)[-0.397]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Your latest build did not run out of swap/paging space. It just hit the time limits that you have set, in this case a 172800 second one: . . . [49:09:17] [ 40% 19569/47953] c++ . . . -o = obj/net/third_party/quiche/quiche/quic_server_initiated_spdy_stream.o [49:09:39] =3D>> Killing timed out build after 172800 seconds [49:09:47] [ 40% 19570/47953] c++ . . .-o = obj/net/third_party/quiche/quiche/quic_server_session_base.o . . . It gave the build a couple of hours before it forced the cleanup activity: [51:20:04] =3D>> Cleaning up wrkdir . . . [51:20:06] =3D=3D=3D> Cleaning for chromium-91.0.4472.114_1 [51:20:07] [ 44% 21217/47953] python . . . --enable-feature is_linux which forced a failure to happen from missing files: [51:20:07] FAILED: gen/ui/events/mojom/event.mojom-module = gen/ui/events/mojom/event_constants.mojom-module = gen/ui/events/mojom/keyboard_codes.mojom-module = gen/ui/events/mojom/scroll_granularity.mojom-module=20 [51:20:07] python ../../mojo/public/tools/mojom/mojom_parser.py = --input-root /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114 = --input-root = /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/ge= n --output-root = /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/ge= n = --mojom-file-list=3D__ui_events_mojom_mojom__parser___build_toolchain_linu= x_clang_arm64__rule..rsp --check-imports = /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/ge= n/ui/events/mojom/mojom.build_metadata --enable-feature is_posix = --enable-feature is_linux [51:20:07] Traceback (most recent call last): [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", line = 456, in [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", line = 448, in Run [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", line = 280, in _ParseMojoms [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", line = 62, in _ResolveRelativeImportPath [51:20:07] ValueError: "mojo/public/mojom/base/time.mojom" does not = exist in any of = ['/wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114', = '/wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/g= en'] [51:20:07] ninja: build stopped: subcommand failed. [51:20:08] *** Error code 1 [51:20:08]=20 [51:20:08] Stop. [51:20:08] make: stopped in /usr/ports/www/chromium [51:24:17] build of www/chromium | chromium-91.0.4472.114_1 ended at Fri = Jul 9 23:39:24 PDT 2021 [51:24:17] build time: 51:24:16 [51:24:17] !!! build failure encountered !!! It looks like, in addition to other aspects of getting a coherent and clean environment going, you will need to increase that 172800 (and possibly other timeout settings). Otherwise there is the swap space use vs. ALLOW_MAKE_JOBS and MAKE_JOBS_NUMBER sorts of tradeoffs for the 1 GiByte RAM RPi3B, even for a coherent/clean build context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Jul 10 22:54:59 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6E3E611E388D for ; Sat, 10 Jul 2021 22:55:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMljM74Fvz3jHv for ; Sat, 10 Jul 2021 22:55:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 16AMsxET093459 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 10 Jul 2021 15:54:59 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 16AMsxkm093458; Sat, 10 Jul 2021 15:54:59 -0700 (PDT) (envelope-from fbsd) Date: Sat, 10 Jul 2021 15:54:59 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-ports@freebsd.org Subject: Re: Too many pythons in poudriere Message-ID: <20210710225459.GB91320@www.zefox.net> References: <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> <6D9BAA86-CB85-42E9-B4FC-6272141CFFDB@yahoo.com> <20210709230738.GA83522@www.zefox.net> <0313838D-C54A-4517-A53B-C70B4EDDE296@yahoo.com> <20210710174010.GA91320@www.zefox.net> <66D2ACD1-B70E-4378-9836-9122E7F72782@yahoo.com> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66D2ACD1-B70E-4378-9836-9122E7F72782@yahoo.com> X-Rspamd-Queue-Id: 4GMljM74Fvz3jHv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Jul 10, 2021 at 02:17:46PM -0700, Mark Millard wrote: > Your latest build did not run out of swap/paging space. > It just hit the time limits that you have set, in this > case a 172800 second one: > > . . . > [49:09:17] [ 40% 19569/47953] c++ . . . -o obj/net/third_party/quiche/quiche/quic_server_initiated_spdy_stream.o > [49:09:39] =>> Killing timed out build after 172800 seconds > [49:09:47] [ 40% 19570/47953] c++ . . .-o obj/net/third_party/quiche/quiche/quic_server_session_base.o > . . . > > It gave the build a couple of hours before it forced the > cleanup activity: > > [51:20:04] =>> Cleaning up wrkdir > . . . > [51:20:06] ===> Cleaning for chromium-91.0.4472.114_1 > [51:20:07] [ 44% 21217/47953] python . . . --enable-feature is_linux > > which forced a failure to happen from missing files: > > [51:20:07] FAILED: gen/ui/events/mojom/event.mojom-module gen/ui/events/mojom/event_constants.mojom-module gen/ui/events/mojom/keyboard_codes.mojom-module gen/ui/events/mojom/scroll_granularity.mojom-module > [51:20:07] python ../../mojo/public/tools/mojom/mojom_parser.py --input-root /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114 --input-root /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/gen --output-root /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/gen --mojom-file-list=__ui_events_mojom_mojom__parser___build_toolchain_linux_clang_arm64__rule..rsp --check-imports /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/gen/ui/events/mojom/mojom.build_metadata --enable-feature is_posix --enable-feature is_linux > [51:20:07] Traceback (most recent call last): > [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", line 456, in > [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", line 448, in Run > [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", line 280, in _ParseMojoms > [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", line 62, in _ResolveRelativeImportPath > [51:20:07] ValueError: "mojo/public/mojom/base/time.mojom" does not exist in any of ['/wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114', '/wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/gen'] > [51:20:07] ninja: build stopped: subcommand failed. > [51:20:08] *** Error code 1 > [51:20:08] > [51:20:08] Stop. > [51:20:08] make: stopped in /usr/ports/www/chromium > [51:24:17] build of www/chromium | chromium-91.0.4472.114_1 ended at Fri Jul 9 23:39:24 PDT 2021 > [51:24:17] build time: 51:24:16 > [51:24:17] !!! build failure encountered !!! > > It looks like, in addition to other aspects of getting a > coherent and clean environment going, you will need to > increase that 172800 (and possibly other timeout settings). > > Otherwise there is the swap space use vs. ALLOW_MAKE_JOBS > and MAKE_JOBS_NUMBER sorts of tradeoffs for the 1 GiByte RAM > RPi3B, even for a coherent/clean build context. > Ahh, I didn't notice that it was a timeout and thought something serious triggered the "subcommand failed" message. As you've guided me through poudriere I'm starting realize it's a textile mill and my goal calls for a needle and thread. Thank you for much patient good counsel! bob prohaska From nobody Sat Jul 10 23:31:24 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6174C12411A4 for ; Sat, 10 Jul 2021 23:31:39 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMmWY70tfz3mZ7 for ; Sat, 10 Jul 2021 23:31:37 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: by mail-ed1-x52f.google.com with SMTP id t3so20407312edc.7 for ; Sat, 10 Jul 2021 16:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OjPXqFnTCaRYSTgcZf4zAFr2/Nb8ndzas9ViMb4Ew0c=; b=Tirf4HpUaUXl7ktz9uBx+Y/rrtJ+C/chHv8pm2FaaBlLPatzTvazuUxzpZlTTLCqtX 4MQIIbT8vWf/68dLLeYY879opPcPuCwRDR+v/ajrChuHjlVvWMKCPr04O4fJcIKVKA9O PtYNNnkKUJcxgZDMkKOnNAT2lfcNXnyKxmYQNeCvP1kUlGX6s23b6rRTASPT930Qukhm CJ1yzt4TeaWyLib3+pIwOkbr8kW6nMqtHS0Xc1QcO9BcW8UF+6uU+6jEf0sD7fgv4IDt bCBmpEVKZ4esFJVX5QkMw7w+2aiMRCRVqZzvr94fCfLb5XoYTrJJY4NbdEB3UI7iVCc8 HEPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OjPXqFnTCaRYSTgcZf4zAFr2/Nb8ndzas9ViMb4Ew0c=; b=to9dF4/1d/C7gTRSbXImrUegDD16TQrrqM3OI1TpVXplJ/jfgJrXY124FX4fQUkikV i7wfDoj/esPmHKkX13qQ++clEdei1JyqWuxZ95VQE3ARLCGgwgz9JdzEnNtVzVIOqPdX 9FzA9y3mN8c12JAhdMatmpoStsWutg36t2hjLsA5oYSdBVMP/Bib3YpV2RXrxjQ+K+Dp XwQMDDM2ftuJDwc1s4JAa+QNnOaq4E7RZuy5fVb5KWoU5jJXhLgz2v8mhD1TK24Ky5dj qrKsB1vt1En+o4U7jkuPcUU92iEUNEYpz6ftgJmmY+6MNvpt0LVX2JkeccVW/tBzkECV ryvQ== X-Gm-Message-State: AOAM533gxw+4LGuK/2TlLljBbTN16HN8Hb7em2p2p56dqhpFDBA6CUkQ CpU9C8iBklkGDUj3E/CC7Lpi6DQwxB8sAAOARTHEPZ38faU= X-Google-Smtp-Source: ABdhPJxRURjk1VC9zeRNgW8BPxRDsVkQKTPudmcvmZSs2UlM1g9yik+3gNNJbmzmdVB2NFqAxkZJVz8MkMkWFXXinho= X-Received: by 2002:a50:ee15:: with SMTP id g21mr3407001eds.334.1625959896099; Sat, 10 Jul 2021 16:31:36 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 From: Kurt Buff Date: Sat, 10 Jul 2021 17:31:24 -0600 Message-ID: Subject: Failing to fetch x11/luit To: freebsd-ports@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GMmWY70tfz3mZ7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Tirf4HpU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kurtbuff@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=kurtbuff@gmail.com X-Spamd-Result: default: False [-2.02 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::52f:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; NEURAL_SPAM_MEDIUM(0.98)[0.979]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::52f:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports] X-ThisMailContainsUnwantedMimeParts: N All, Trying to rebuild my ports using synth and it's failing to fetch this one. I've also tried building manually using 'make install clean', but get the same error. Can someone point me in the right direction for this? Thanks, Kurt From nobody Sun Jul 11 01:56:49 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 742978D2074 for ; Sun, 11 Jul 2021 01:56:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMqlD1Hsyz4XlT for ; Sun, 11 Jul 2021 01:56:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625968614; bh=l1Ayt6k8t2iiU6eLPuGFANcoK9fXdreuVLxb4msQAUI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ehfSvETmawWJhs+QPyld6av6G/dRSfzQZxd19MRYTy1YLvuDefRcwNDywdeFdszPNv22mTkOnZav7gMzIEn+cKbfj/3UJts56S4iEE6hbTZGTo6a5IJlir0VPHodZISyqydulp9/A6mOHDJKw2ZAV69jU+eZ5yrQdVKslS8CD0Ncvil7kuIAvVjBej6hnz4uR8JsiLwIaLtgMf/y4gw0Zw32xTW6juluG3ThkbU1HjVIcQlaEVbn0NGkw3pSipck1Sl0rhosRCF9JlUsY5k/uPzAEG0dZGqYsRuxUwAqZfIXY+Q/uFQI/lo63ejg7fP/QtioXZmprJo2aQWIZyrR0A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625968614; bh=GVtffXpgxSluXqGp0QLBC9ASA0gjMjzvgQiVXI5tLjS=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hK98uFgud4RvoaYpue8+L2mDUTmNnI9EbFLDZ8Q5oM23EtxUI1Urn/S0h29xrsGHdFnWMPHOUVx59XFYq9gy2MjpLzcKF1u7gM/GttZz4nwu/wgHKnm79itquiBONfDGL0qAuBZ4tcTI9nvjnnpNw9HBmg9HUKn2MIuzMjE2HyUv1lxm/e8JTiH+FEskXaPWC64lNMnxAcz498/pUFGYvZFr+CVWKaSluxsKWiqy7S8g4++FAMRFIYd29CGqMa+UOh6LHPeKhRR/01cN8IU6KsGBfWowPdMX0z0i7uecCOEyLnHIxbLt+n86AYCxGeCEuNiG2yksASlLOziEOJMsyg== X-YMail-OSG: 1S65ES0VM1nrIAbhjjagixQEvwaAIXE5PnAm0cH3Gm5W4fresLI71Gu3tybc5XO dp7KJEFjUOCG5dbQ5vKzPV9yv2FC29TecfRr2p9KvGkX9VpkilEsaf_tUjsG0o37TXTFZaCFO3Jm YILQoFhd3CcYEXIjErrZz3TFZyH9xNAy30WSoDNRqeyf8p_iUx6gSgLlGIdr38JXY7FgZVYBW_VM 0EqdRMH3hMSrTfM1eMQ9X6DrIoUcZxmbg_GGKpcHcGbWcYYOu2m16ncKOG0NW21jomAu.p3db0iP 8hfkSvwBySKZEDs9Pa4rcz1.6f19psCM7aiaMaa25GT5M2D.y_jNyiWJt3ASwCfqTr82C9BTjzUO LJNPOSulZyEPKl7NVOJhkNdDgAqQycsdc2FhU4y8wORxjneUDfhiKD2qdO9nXHMQ3lR7d0ck1nKW OJRpDZshJv4XSeNkKuLIqwDEQFUJgNzAuUPvPY_4W6zTxR_c.xZuhYD0z06W6C6kvBFHhSLhyCOG VQNA95uNzn18ata5UcUBvSfk.Dyqd0moxn3wJKJ.jglH4L.Pc048bF7J6r61jpEynTqOT27M_lV5 ABmzTp7bxrwUNU5SMWybPdVu_2Y0xpIo0N6ECr55LFitsWqpyUgQb.sZaKPcbSe5Cib3h04zMFrv 5yWUR05JmPs.xJyzEkHsbef71gDcShGuB_4EuChAVGRQJZyPnP52gIVxN0jcPB6.oCBK_kQZdeur yJnSb0RU7dUmRDT8fNf6fxt_R1ReLB5ndyv.YfWlUqnunDO9hZLTpcV.ufIkLR6FpXfIDpG7u11y ywsxmVyifIz96tMWxL5WWPrTQWbflc59B6RXh0HfKr6h6Y.AhT718QNwD83pe586bx.sujkyX50N .UO4NRaYrWQla5xrWo5k4zSIMNcqIcTtAyOdnoCY3d3LZjf530eBegfxQyNL1jOrF_lt09Av6q9n YnIoXxZF85E_LY5VistS5.CUpKGyf0XQ9Jg8j.E.Spmr_7X3miMekrdTaoFEZDf23AlXzdxAOpvx PSULWhVRAHJtybT_qFa.iwWV_gk8SE86fjFVmnIwoms4_PXi9nQ7TQkGBlNETazZDbm6R5CAnGEc N6IlvM2us2SfahhK_F8upf2ZfT_Rm4_ewVd5MHwiBeN5RbRMgd9BST23JYJ84VEog4YqFtWBR1Hq Q.muHPBWXzfuR8kKLYu8NhtLvhN6TRv4dlWSVHLg5nO1z_NepQQSalJqW.Zoyw2L_86gBApALL1n CCyfW9giaZ8Ge356I5euglXILBxK423sygBCXdG_hHALPJmdaTWkOARVmglhAwMOQdCPg7ptZ3MA F_BFGH4TX03DAJlzuEqDZ4doMmbgGV0vStl5iq6wK78nyusf_D7I31NjYtS63F_4xTmGbgVNYI4g kTbSQfskvPArv8awMi1sO5YLfbk5eoXc0M3ZeVF6VLTgMaekeqaImd8wb7m2Oxk1nRDS3iQwPYXT wDzV4qm1MNM5l7rHwVMz5_pPLZKVwndpKHX7Z2HfMr6k7IyTZmgCFeZ6wxJ7dZe4nFZDVDqdcWWb bd3tvsV7xJGuUC1FIbyoUhfGisbcSmw5LPz4iww_kefDm3bcVzcHa9v83VFxXoe7HbA5ib1f_L8a UZ25bnRQv7nisY.BlT2fgT3eanwhkK4yupnaQ3Lr2Z83Nh.FWrDGMf01X6TQIDhG9gBDeU7VRlax xXDftwlMTAQVKSkRZZcDeXy6qhV0rDYnOMtfSfgKaw73hxRvfC2PdjxSMwPDwn7cknfIiBNseRkM 4WdCR_qSABr_JscvPz0gwVT5iAWvbL8efxxLogKcovNQQvvwcB27JlrP7l5BHgMXuAVzAWxWUmH_ M5lNVqWMWZnjAfAV7N9f5RYBxTNglrVY7e6P_jQvqjBsRWODuMHBidQF3LkiPN11wXA9xU5DBU1a AbhCSW8ubjXRXH0zdokIdKi7SOk.FFPDlSEV2Hb3SBB5CCt8i_MnioTISH_BYKkArc4hph_x5WKT X6Z2InY0Ul4suVTVTQ5TDqpX4Z98rmruPC3ji2pWGY8NCr2ltS7ZyIFbQkzccUlgzPO6jWJJItCq fYI0oJH6FgCNH68zAukv4clTfDlQwBE5Tl7S3vut8w8X3.5mNQEwuqlodBTXYRUOxCIWYGN1w4Rm M.aHFbPxpAo.xnim63cXLbUCLMfBeT6JtnA8V0em7n5VRkbB2Y5HagMKj8UEWZ_5oysyC87Cvyjs Cx6HJHOZQMsuMbhGUc3_MJl1IEqa5gHQBZF68r7jVEJHAbWNqMLixxBHuulvf.wZFQwjKY.qKCv0 dslA3fbyfwQb3L4PYkxgTRpcW5XzwgQCFfzb197rK9v1LA76ef4E.IBgJLKxzxysdYguEf3OYcFV 8GCGXc6s8Pk.QyIZPxZnM5cW9bsaB3oGbehWrfc.A2DGva344nLw67wEilDsap7XvD5MyAaI7ytV ke89sN3p7mCQfQJEqbjBHOmkNG7oPkZJTKHs7WDUdAt8elvgQNgk3tR6xECaJ.HsYFO3onZcGVS2 0of2OxKLenYU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 11 Jul 2021 01:56:54 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8feb2650340ff2f4cc5f4d390798857e; Sun, 11 Jul 2021 01:56:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Too many pythons in poudriere In-Reply-To: <20210710225459.GB91320@www.zefox.net> Date: Sat, 10 Jul 2021 18:56:49 -0700 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5C1DD0A7-8967-4399-BD68-AD3063F0A20D@yahoo.com> References: <20210708154558.GB60914@www.zefox.net> <20210708175436.GA70414@www.zefox.net> <24795168-CEBF-4049-A4BD-D529F70E7F8D@yahoo.com> <6D9BAA86-CB85-42E9-B4FC-6272141CFFDB@yahoo.com> <20210709230738.GA83522@www.zefox.net> <0313838D-C54A-4517-A53B-C70B4EDDE296@yahoo.com> <20210710174010.GA91320@www.zefox.net> <66D2ACD1-B70E-4378-9836-9122E7F72782@yahoo.com> <20210710225459.GB91320@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GMqlD1Hsyz4XlT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-10, at 15:54, bob prohaska wrote: > On Sat, Jul 10, 2021 at 02:17:46PM -0700, Mark Millard wrote: >> Your latest build did not run out of swap/paging space. >> It just hit the time limits that you have set, in this >> case a 172800 second one: >>=20 >> . . . >> [49:09:17] [ 40% 19569/47953] c++ . . . -o = obj/net/third_party/quiche/quiche/quic_server_initiated_spdy_stream.o >> [49:09:39] =3D>> Killing timed out build after 172800 seconds >> [49:09:47] [ 40% 19570/47953] c++ . . .-o = obj/net/third_party/quiche/quiche/quic_server_session_base.o >> . . . >>=20 >> It gave the build a couple of hours before it forced the >> cleanup activity: >>=20 >> [51:20:04] =3D>> Cleaning up wrkdir >> . . . >> [51:20:06] =3D=3D=3D> Cleaning for chromium-91.0.4472.114_1 >> [51:20:07] [ 44% 21217/47953] python . . . --enable-feature is_linux >>=20 >> which forced a failure to happen from missing files: >>=20 >> [51:20:07] FAILED: gen/ui/events/mojom/event.mojom-module = gen/ui/events/mojom/event_constants.mojom-module = gen/ui/events/mojom/keyboard_codes.mojom-module = gen/ui/events/mojom/scroll_granularity.mojom-module=20 >> [51:20:07] python ../../mojo/public/tools/mojom/mojom_parser.py = --input-root /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114 = --input-root = /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/ge= n --output-root = /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/ge= n = --mojom-file-list=3D__ui_events_mojom_mojom__parser___build_toolchain_linu= x_clang_arm64__rule..rsp --check-imports = /wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/ge= n/ui/events/mojom/mojom.build_metadata --enable-feature is_posix = --enable-feature is_linux >> [51:20:07] Traceback (most recent call last): >> [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", = line 456, in >> [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", = line 448, in Run >> [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", = line 280, in _ParseMojoms >> [51:20:07] File "../../mojo/public/tools/mojom/mojom_parser.py", = line 62, in _ResolveRelativeImportPath >> [51:20:07] ValueError: "mojo/public/mojom/base/time.mojom" does not = exist in any of = ['/wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114', = '/wrkdirs/usr/ports/www/chromium/work/chromium-91.0.4472.114/out/Release/g= en'] >> [51:20:07] ninja: build stopped: subcommand failed. >> [51:20:08] *** Error code 1 >> [51:20:08]=20 >> [51:20:08] Stop. >> [51:20:08] make: stopped in /usr/ports/www/chromium >> [51:24:17] build of www/chromium | chromium-91.0.4472.114_1 ended at = Fri Jul 9 23:39:24 PDT 2021 >> [51:24:17] build time: 51:24:16 >> [51:24:17] !!! build failure encountered !!! >>=20 >> It looks like, in addition to other aspects of getting a >> coherent and clean environment going, you will need to >> increase that 172800 (and possibly other timeout settings). >>=20 >> Otherwise there is the swap space use vs. ALLOW_MAKE_JOBS >> and MAKE_JOBS_NUMBER sorts of tradeoffs for the 1 GiByte RAM >> RPi3B, even for a coherent/clean build context. >>=20 >=20 > Ahh, I didn't notice that it was a timeout and thought > something serious triggered the "subcommand failed" message.=20 Where: = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-07-07= _20h08m41s/build.html reports: Phase build/timeout and: Log runaway_process that should indicate that a timeout has occurred and should be able to be found in the log if I understand right. It is possible that there is more than a timeout of interest in the log, even before the timeout. As can be seen by the 2 hr delay in the example, the timeout need not be near the final activity. > As you've guided me through poudriere I'm starting realize > it's a textile mill and my goal calls for a needle and thread.=20 I'd never call building www/chromium and what it depends on as something on the scale of "a needle and thread", even on a machine with lots of resources for the activity --and so with fewer complications to deal with. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jul 11 02:45:46 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 14AF51240472 for ; Sun, 11 Jul 2021 02:45:52 +0000 (UTC) (envelope-from portmaster@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMrqg5L4Fz4dR0 for ; Sun, 11 Jul 2021 02:45:51 +0000 (UTC) (envelope-from portmaster@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 16B2jksC040452; Sat, 10 Jul 2021 19:45:53 -0700 (PDT) (envelope-from portmaster@bsdforge.com) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Sat, 10 Jul 2021 19:45:46 -0700 From: Chris To: Kurt Buff Cc: freebsd-ports@freebsd.org Subject: Re: Failing to fetch x11/luit In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: X-Sender: portmaster@bsdforge.com Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_73d8af606c90916462fd7a93d0adcb96"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4GMrqg5L4Fz4dR0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_73d8af606c90916462fd7a93d0adcb96 Content-Type: multipart/mixed; boundary="=_d640e811eda33b7154337f241437e347" --=_d640e811eda33b7154337f241437e347 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2021-07-10 16:31, Kurt Buff wrote: > All, > > Trying to rebuild my ports using synth and it's failing to fetch this > one. I've also tried building manually using 'make install clean', but > get the same error. > > Can someone point me in the right direction for this? We're going to need a little more information in order to know how to provide the correct answer. What version of FreeBSD are you running? What revision of the ports tree are you working with || port version of x11/luit? > > Thanks, > Kurt --=_d640e811eda33b7154337f241437e347 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_d640e811eda33b7154337f241437e347-- --=_73d8af606c90916462fd7a93d0adcb96 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=488 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDqW1oACgkQGHUefL3k lUCM3ggApMCPykswVz3YeXbcFS35J1hagDfSF5WV9/xjzRRc9+1bRtYxHcy4dBws +owYGfHUbpWn9e3OCDfNyNRJL+ansRu13QYftWJPAAsjXP13u4gEYzs2DD3TkyDe t3HCuuEHufFSy5rQsdNjlALWtPCOjNuwtiM5Igs6FR7gvM7Hd6c6RZDXfuta9u2g 1mYJDc3WgyhytsiNjcBU2Ypgb6WrbcJY2ASDWfkwSCqbzrFm4YsnGr14hqNFlI6M EUdM01CHVu6U6fTkA9YlrzvGyalHDT/e9JyXnhiaAWtE3lFcizxRifKHdG7DcxCn 4Gna8XDpEOsPwrDzX+KOS3lR1GW1yg== =w8Xb -----END PGP SIGNATURE----- --=_73d8af606c90916462fd7a93d0adcb96-- From nobody Sun Jul 11 06:31:10 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 992AC8D15B6 for ; Sun, 11 Jul 2021 06:31:25 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMxqw4rmwz3Hdk for ; Sun, 11 Jul 2021 06:31:24 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: by mail-ej1-x62a.google.com with SMTP id gn32so26270279ejc.2 for ; Sat, 10 Jul 2021 23:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=r1MkgnyF/M7W8Pk0LcO/NqSEzRIb6vTrtS01rb47eE0=; b=IPLeNUnuS0BzIc27n5I5rQjHfzbIDXZS9Dgj8bfezE2BMTdM90gJDmIZyq//Ju8UG0 +ET4GtMB7UF07VCweixRK1sZac/j6jqvYDI3dg5Mn/RPEW+Or+UPl3IjtVbXlKC1LGC6 A1UvitrtMRERkEcARgWq5vtiHMSdP65FVqevd2H/4Szy3ZAS/jC9z9fzs5W1kD4++pD+ EDB2oGh+nGPfD09cjfFkTO9vmmmfzmxdRbDYjP3aP21mlUxbZtk1bgjFSxRZ6XOCKwGB YUSc2qxVM+7w4wOZa/goDXElfUPYF460JKzAVV2Kw0Gszm0uXuIYFap+cOta5XSec4Yu vlUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=r1MkgnyF/M7W8Pk0LcO/NqSEzRIb6vTrtS01rb47eE0=; b=WQyJTymVWeR9zTTQ5Bi+16EZo5B9NyNbr4nJvst0q6ss0Zv+qpZzxihcRKICIn4VOR mFt0S0vAsjgBdh7m3FrR0UeS81JF4K5Kq5anMgiUel5vo4Jz+VokPo5vwiQ7LkdvO+88 csp7nU/Vd1tXTUCGQ+v5poB0/lqCwUpk3F4rwD7t4l9ltXHiYBdm8DDdXlO56CQFMG4n wdglV+3Z94ot37sE9AW+x00dnBEkmOeQWhrikg+ZNqYrEuq8gePqwcyVZRW4vTSqaarD nTVQDpjbhAabGZ/04KqwpxkfSJhEPvLIX0RwGljWdrlEywK7ah8Nb9LZeuFEL47qsKiP XOkg== X-Gm-Message-State: AOAM532jzfBWzNGoZ7b2RMYcaKTxKxTVC2GxYMb2najUo5K/zdT1h1oH FEMnhnBghoQH5uOcdfPTGmtY74jQPiWPg1Yy4EtcjkQKRiA3ZA== X-Google-Smtp-Source: ABdhPJwB5z9I2Kkm1lmUxZEMzJrNuKhOmWtZPYWuTAqIIX/QCaCDCjzLbHt3KAKNjwHHmDDNlRm/Xn/CdQwk8ZdFNcQ= X-Received: by 2002:a17:906:616:: with SMTP id s22mr46956521ejb.210.1625985082322; Sat, 10 Jul 2021 23:31:22 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kurt Buff Date: Sun, 11 Jul 2021 00:31:10 -0600 Message-ID: Subject: Re: Failing to fetch x11/luit To: freebsd-ports@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GMxqw4rmwz3Hdk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=IPLeNUnu; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kurtbuff@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=kurtbuff@gmail.com X-Spamd-Result: default: False [-2.33 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.988]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::62a:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; NEURAL_SPAM_MEDIUM(0.66)[0.659]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62a:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports] X-ThisMailContainsUnwantedMimeParts: N On Sat, Jul 10, 2021 at 8:45 PM Chris wrote: > On 2021-07-10 16:31, Kurt Buff wrote: > > All, > > > > Trying to rebuild my ports using synth and it's failing to fetch this > > one. I've also tried building manually using 'make install clean', but > > get the same error. > > > > Can someone point me in the right direction for this? > > We're going to need a little more information in order to know how > to provide the correct answer. > What version of FreeBSD are you running? freebsd-version says 12.2-RELEASE-p9 > What revision of the ports tree are you working with || port version > of x11/luit? I ran 'gitup ports' today, then 'make index' afterward, so it'll be from some point today. I also ran 'make clean' against the ports tree today. Just now, I ran this, and got the error message show: root@FreeBSD-VM:~ # cd /usr/ports/x11/luit root@FreeBSD-VM:/usr/ports/x11/luit # make fetch ===> License MIT accepted by the user ===> luit-20210218 depends on file: /usr/local/sbin/pkg - found => luit-20210218.tgz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch ftp://ftp.invisible-island.net/luit/luit-20210218.tgz fetch: ftp://ftp.invisible-island.net/luit/luit-20210218.tgz: Operation timed out => Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/luit-20210218.tgz fetch: http://distcache.FreeBSD.org/ports-distfiles/luit-20210218.tgz: Not Found => Couldn't fetch it - please try to retrieve this => port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop. make: stopped in /usr/ports/x11/luit Kurt From nobody Sun Jul 11 08:23:09 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CC1BE1270A52 for ; Sun, 11 Jul 2021 08:23:14 +0000 (UTC) (envelope-from portmaster@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GN0Jy37P5z3lVB for ; Sun, 11 Jul 2021 08:23:14 +0000 (UTC) (envelope-from portmaster@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 16B8NAer099013; Sun, 11 Jul 2021 01:23:16 -0700 (PDT) (envelope-from portmaster@bsdforge.com) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Sun, 11 Jul 2021 01:23:09 -0700 From: Chris To: Kurt Buff Cc: freebsd-ports@freebsd.org Subject: Re: Failing to fetch x11/luit In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <9c857e41410fff06fba89ee036430492@bsdforge.com> X-Sender: portmaster@bsdforge.com Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_1ae2ad49331a7aee558a55c026990c3a"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4GN0Jy37P5z3lVB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_1ae2ad49331a7aee558a55c026990c3a Content-Type: multipart/mixed; boundary="=_afd4e91a6bdadcdac85e30e730c52cb8" --=_afd4e91a6bdadcdac85e30e730c52cb8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2021-07-10 23:31, Kurt Buff wrote: > On Sat, Jul 10, 2021 at 8:45 PM Chris wrote: >> On 2021-07-10 16:31, Kurt Buff wrote: >> > All, >> > >> > Trying to rebuild my ports using synth and it's failing to fetch this >> > one. I've also tried building manually using 'make install clean', but >> > get the same error. >> > >> > Can someone point me in the right direction for this? >> >> We're going to need a little more information in order to know how >> to provide the correct answer. >> What version of FreeBSD are you running? > freebsd-version says 12.2-RELEASE-p9 > >> What revision of the ports tree are you working with || port version >> of x11/luit? > > I ran 'gitup ports' today, then 'make index' afterward, so it'll be > from some point today. I also ran 'make clean' against the ports tree > today. > Thanks for the info. > Just now, I ran this, and got the error message show: > > root@FreeBSD-VM:~ # cd /usr/ports/x11/luit > root@FreeBSD-VM:/usr/ports/x11/luit # make fetch > ===> License MIT accepted by the user > ===> luit-20210218 depends on file: /usr/local/sbin/pkg - found > => luit-20210218.tgz doesn't seem to exist in /usr/ports/distfiles/. > => Attempting to fetch ftp://ftp.invisible-island.net/luit/luit-20210218.tgz > fetch: ftp://ftp.invisible-island.net/luit/luit-20210218.tgz: OK I just attempted to grab the file listed above, and had no trouble retrieving it. So I'm going to guess your system is having difficulty finding the host. Just in case it's an intermittent problem. What happens if you cd to: /usr/ports/x11/luit and perform a make fetch ? If it fails on the first attempt, does issuing the command a couple of more times finally return a success? Do you have any restrictions on the ftp port(s) within your firewall? Assuming your running one of course. HTH --Chris > Operation timed out > => Attempting to fetch > http://distcache.FreeBSD.org/ports-distfiles/luit-20210218.tgz > fetch: http://distcache.FreeBSD.org/ports-distfiles/luit-20210218.tgz: Not > Found > => Couldn't fetch it - please try to retrieve this > => port manually into /usr/ports/distfiles/ and try again. > *** Error code 1 > > Stop. > make: stopped in /usr/ports/x11/luit > > Kurt --=_afd4e91a6bdadcdac85e30e730c52cb8 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_afd4e91a6bdadcdac85e30e730c52cb8-- --=_1ae2ad49331a7aee558a55c026990c3a Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=488 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDqqm4ACgkQGHUefL3k lUDb5wf/fgpG/lPK3QZPQMwOxFD+819VKJCdBA6ho9RKnP3PGz9DvgD3mG51CA3v qvwgUNujWdUvgwPIu+6b4UnicYckkXPcDyqMZWTHVGfArfPMB3F6B5Oj4tx0RMVr 4I6HVZZnsfqklqReSOBsqA4Y6v+i6iRK+yrTTO7NE4wXMPIXcZk74A8YU5oLeYbt MKrOq1c+4h6wTJMWb7+Dfjg2Ug7573DSv4SoR6f7GsTZNriuoancdxphnSUxZoYH GoLfZWpibbiYRgqrar5MG9oeEwrRBEX8pLkn+EQn8FaVyv+aluTMf3bN1UPgSvGd XXRPYxhGpkhmmivUOXy63n0r7NTl+g== =d+b8 -----END PGP SIGNATURE----- --=_1ae2ad49331a7aee558a55c026990c3a-- From nobody Sun Jul 11 09:18:59 2021 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 96F96127998E for ; Sun, 11 Jul 2021 09:19:10 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GN1YT3BzVz3tQj; Sun, 11 Jul 2021 09:19:09 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.16.1/8.16.1) with ESMTPS id 16B9IxfD088612 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 11 Jul 2021 11:18:59 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 16B9Ixeu088611; Sun, 11 Jul 2021 11:18:59 +0200 (CEST) (envelope-from fuz) Date: Sun, 11 Jul 2021 11:18:59 +0200 From: Robert Clausecker To: ports@freebsd.org Cc: portmgr@freebsd.org Subject: No package builds for arm{v6,v7,64} FreeBSD 13 Message-ID: List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4GN1YT3BzVz3tQj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su X-Spamd-Result: default: False [-3.30 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:41d0:8:e508::1:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[fuz.su]; SPAMHAUS_ZRD(0.00)[2001:41d0:8:e508::1:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[ports]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Good morning, I was wondering why no packages for arm64, armv6, and armv7 FreeBSD 13.0 have been built for the main branch in a while. Is there some sort of policy to no longer build packages for these or is there some sort of problem? I would really like to be able to upgrade my FreeBSD 13 arm64 boxen. Yours, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Sun Jul 11 12:17:44 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CEE4D12474C9 for ; Sun, 11 Jul 2021 12:17:55 +0000 (UTC) (envelope-from freebsd@oldach.net) Received: from nuc.oldach.net (hmo.in-vpn.de [IPv6:2001:67c:1407:60::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "nuc.oldach.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GN5Wk5g20z4py8 for ; Sun, 11 Jul 2021 12:17:54 +0000 (UTC) (envelope-from freebsd@oldach.net) Received: from nuc.oldach.net (localhost [127.0.0.1]) by nuc.oldach.net (8.16.1/8.16.1/hmo17dec20) with ESMTPS id 16BCHiQS066675 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 11 Jul 2021 14:17:44 +0200 (CEST) (envelope-from freebsd@oldach.net) Received: (from hmo@localhost) by nuc.oldach.net (8.16.1/8.16.1/Submit) id 16BCHi8e066674 for freebsd-ports@freebsd.org; Sun, 11 Jul 2021 14:17:44 +0200 (CEST) (envelope-from freebsd@oldach.net) Message-Id: <202107111217.16BCHi8e066674@nuc.oldach.net> Subject: Re: Failing to fetch x11/luit In-Reply-To: from Kurt Buff at "11 Jul 2021 00:31:10" To: freebsd-ports@freebsd.org Date: Sun, 11 Jul 2021 14:17:44 +0200 (CEST) From: freebsd@oldach.net (Helge Oldach) X-No-Archive: Yes List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: inspected by milter-greylist-4.6.4 (nuc.oldach.net [0.0.0.0]); Sun, 11 Jul 2021 14:17:45 +0200 (CEST) for IP:127.0.0.1 DOMAIN:localhost HELO:nuc.oldach.net FROM:freebsd@oldach.net RCPT: X-Rspamd-Queue-Id: 4GN5Wk5g20z4py8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@oldach.net designates 2001:67c:1407:60::1 as permitted sender) smtp.mailfrom=freebsd@oldach.net X-Spamd-Result: default: False [-3.27 / 15.00]; RCVD_TLS_ALL(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:67c:1407:60::1:from]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2001:67c:1407:60::1:from:127.0.2.255]; DMARC_NA(0.00)[oldach.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29670, ipnet:2001:67c:1400::/45, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports] X-ThisMailContainsUnwantedMimeParts: N Kurt Buff wrote on Sun, 11 Jul 2021 08:31:10 +0200 (CEST): > root@FreeBSD-VM:/usr/ports/x11/luit # make fetch > ===> License MIT accepted by the user > ===> luit-20210218 depends on file: /usr/local/sbin/pkg - found > => luit-20210218.tgz doesn't seem to exist in /usr/ports/distfiles/. > => Attempting to fetch ftp://ftp.invisible-island.net/luit/luit-20210218.tgz > fetch: ftp://ftp.invisible-island.net/luit/luit-20210218.tgz: > Operation timed out ftp.invisible-islands.net is reachable and responding from here. ftp has become a bit unusual though. Maybe ftp isn't allowed outbound in your firewall? Perhaps --no-passive or tweaking FTP_PASSIVE_MODE will help? > => Attempting to fetch > http://distcache.FreeBSD.org/ports-distfiles/luit-20210218.tgz > fetch: http://distcache.FreeBSD.org/ports-distfiles/luit-20210218.tgz: Not Found Apparently missing on distcache. Kind regards Helge From nobody Sun Jul 11 17:46:28 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8949A8D2392 for ; Sun, 11 Jul 2021 17:46:41 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GNDq46dpNz4cCT for ; Sun, 11 Jul 2021 17:46:40 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: by mail-ej1-x62a.google.com with SMTP id hd33so183780ejc.9 for ; Sun, 11 Jul 2021 10:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4TH9tkRlC1ZQSuduJa6Jj/rV4NQxafeFz9lZBxQJtmY=; b=qjW2LJ3pE3YtxSe4Qx8X6USOAyjTXvvJSnarF8yD4OTy+ycfqKNQciWE7wbsixqeI/ Z5Jd1hIML2/cF65nOWilKmzTjhnPQxpsqRH0CG50HAyybzefYuoTNNSf6sXrMinNZTcI 0Rlzh+G2m6nYJNsDrLIyLPq6RkpULxZLd81rYCN2KviqmjVbLeJoMnKkibc2PHCnWzAe 35xEPa42kiM4lb21tiDfMiJKrzivUARyzB/7gnLPMAL9VLdkqrXbkeyBHUAMoV8331TI 3DJU6KbbHCIUfb/GCvgYdcsDE45feD/H1YGJQIwa37xMXkEch1mpG1qD2MK7k3euGaL+ 0vXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4TH9tkRlC1ZQSuduJa6Jj/rV4NQxafeFz9lZBxQJtmY=; b=RO1nVNJdfcbHh7A2pSaRFGPl/AX9imreaP7990ii9U2L+V77/nlMjVWKcavqDqSTn5 iyzfvHuCPxPWtl9hOh7D1PJWXqy80x6brhUUQk5KE5+vrNWttH9yC2a+7eSum7uY7VGS jW8Twe/k0HLnxBvpdb5mPNSTXfXvwCU0jPsYyvJNtHu+1td6wDxN/kzdkVQhTFR5rhUT IsnCGs5PMaEOWurl/RCdRx+xTZkD+LPAhSRO1K3mT8JY1wAS7pTlDdeSlfz/6Mt9nRix FBFEge04rMNmyCwpn5Opdtj1x1XBUx+bbWbr0MreBOk50nVS2dPGO3YZbkCxJvUapHIj f+Zg== X-Gm-Message-State: AOAM533pgNOcFXQk4mYzQJ3OWL0PXFu+HKpJ/whuRzdisHPoRSh7E32W eorlQ0e+PDWOKAR8d886pId/9Wl2vIRJpm6hFC+JSJxzeNw= X-Google-Smtp-Source: ABdhPJw9BLI6XryqGDf82kIe7dENJzQJ0ReE6JGm6Rk/FAMAFsUZO1re9DOmbGwxTbEhSllSWh2Ghzn+yvsGlRTiXsY= X-Received: by 2002:a17:907:62a5:: with SMTP id nd37mr48309131ejc.148.1626025599577; Sun, 11 Jul 2021 10:46:39 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <9c857e41410fff06fba89ee036430492@bsdforge.com> In-Reply-To: <9c857e41410fff06fba89ee036430492@bsdforge.com> From: Kurt Buff Date: Sun, 11 Jul 2021 11:46:28 -0600 Message-ID: Subject: Re: Failing to fetch x11/luit To: freebsd-ports@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GNDq46dpNz4cCT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=qjW2LJ3p; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kurtbuff@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=kurtbuff@gmail.com X-Spamd-Result: default: False [-2.46 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::62a:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; NEURAL_SPAM_MEDIUM(0.54)[0.540]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62a:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports] X-ThisMailContainsUnwantedMimeParts: N Chris and Helge, It was indeed my firewall. Following your tips, I opened it up for tcp/21, but it still didn't like it - the logs showed it as denied using 'fetch --no-passive blah' - so I might have to tweak the firewall a bit. I also saw once in my logs it try port 80, unsuccessfully. When I just used 'fetch blah', it started using high tcp ports, somewhere above 54000. So I opened tcp ports 50000-60000, and now its working fine. Thanks for pointing me in the right direction. Kurt On Sun, Jul 11, 2021 at 2:23 AM Chris wrote: > > On 2021-07-10 23:31, Kurt Buff wrote: > > On Sat, Jul 10, 2021 at 8:45 PM Chris wrote: > >> On 2021-07-10 16:31, Kurt Buff wrote: > >> > All, > >> > > >> > Trying to rebuild my ports using synth and it's failing to fetch this > >> > one. I've also tried building manually using 'make install clean', but > >> > get the same error. > >> > > >> > Can someone point me in the right direction for this? > >> > >> We're going to need a little more information in order to know how > >> to provide the correct answer. > >> What version of FreeBSD are you running? > > freebsd-version says 12.2-RELEASE-p9 > > > >> What revision of the ports tree are you working with || port version > >> of x11/luit? > > > > I ran 'gitup ports' today, then 'make index' afterward, so it'll be > > from some point today. I also ran 'make clean' against the ports tree > > today. > > > Thanks for the info. > > > Just now, I ran this, and got the error message show: > > > > root@FreeBSD-VM:~ # cd /usr/ports/x11/luit > > root@FreeBSD-VM:/usr/ports/x11/luit # make fetch > > ===> License MIT accepted by the user > > ===> luit-20210218 depends on file: /usr/local/sbin/pkg - found > > => luit-20210218.tgz doesn't seem to exist in /usr/ports/distfiles/. > > => Attempting to fetch ftp://ftp.invisible-island.net/luit/luit-20210218.tgz > > fetch: ftp://ftp.invisible-island.net/luit/luit-20210218.tgz: > OK I just attempted to grab the file listed above, and had no trouble > retrieving > it. So I'm going to guess your system is having difficulty finding the host. > Just in case it's an intermittent problem. What happens if you cd to: > /usr/ports/x11/luit > and perform a make fetch ? If it fails on the first attempt, does issuing the > command a couple of more times finally return a success? Do you have any > restrictions on the ftp port(s) within your firewall? Assuming your running > one > of course. > > HTH > > --Chris > > Operation timed out > > => Attempting to fetch > > http://distcache.FreeBSD.org/ports-distfiles/luit-20210218.tgz > > fetch: http://distcache.FreeBSD.org/ports-distfiles/luit-20210218.tgz: Not > > Found > > => Couldn't fetch it - please try to retrieve this > > => port manually into /usr/ports/distfiles/ and try again. > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/x11/luit > > > > Kurt