From nobody Wed Aug 5 19:05:04 2026 X-Original-To: questions@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 4hFfxZ2VtDz6n11H for ; Wed, 05 Aug 2026 19:05:22 +0000 (UTC) (envelope-from mirror176@hotmail.com) Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazolkn19010019.outbound.protection.outlook.com [52.103.20.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protection.outlook.com", Issuer "DigiCert SHA2 Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hFfxY0nhyz3wCd for ; Wed, 05 Aug 2026 19:05:21 +0000 (UTC) (envelope-from mirror176@hotmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hotmail.com header.s=selector1 header.b=RjQfrdvs; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (mx1.freebsd.org: domain of mirror176@hotmail.com designates 52.103.20.19 as permitted sender) smtp.mailfrom=mirror176@hotmail.com; dmarc=pass (policy=none) header.from=hotmail.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DT1Hy1L5Pojr42XFspSMgGsEx33ZP04N+xVZu3gjGF3I880nco1NSyQbkZUlK1lDJxwzJwvEqcSGqze5NA51OxBByvh1LVcHFkDi33c5SkIv/IBkfASD4mjIHHJ5zSSOE9hSJrFbJ9+wHl9aKNhqpfWAnNC+mkVKFXfl+h6AC2q3CW41S129XL6ulixt1qbg5+BUGs/PCpyW3yjsPOncKU9vPj1RKSp+vOKvLlMNO4uSWK8mEF199jfN57t4LpCe44W9WUHZN9wAHFpkdjP452gx/jmXV9XfhlIEVHFX4AUNLvlwPC2GA8KhQtU3rFxlnANsgh8hQ3cO5iM2EBe6Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cep2GRh6XFB6B/WhWdcqojW1Mj07sdfqzqI+U6hV7VA=; b=ama8oELZ4m+YjLlIGYy7HWk6tKmnXsDB7n259lgaHIJEHqG/oD4fGNyG/WzkAZYllTF6yUobx8gpGXRhRQiBdQ9T8jY44d233Kw48xjBdOSPh2m5rsqBEQE4yAR8KGUXRNQO3qriGBLugSQm039rRDnbNP4HWJO0+MZGYIry1hGunfASBCv5qthCTIJL+w2HdL1IYDaArjPVIgsu3ePh9x17J/IL7rRtdKLj8xCu+DeDOPtpil66ccmKlPmb6xQm0ykidKNSTo2PyuY980nFXUAY2O5v+8C8CohVDVHggtXyE07SIlHUS/RDzj5p/jlA43hiiZqRF6Q6q/mU+xPysA== 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=cep2GRh6XFB6B/WhWdcqojW1Mj07sdfqzqI+U6hV7VA=; b=RjQfrdvsLmJo5GcOrFWBhbzD4Ql/ie8jnkX7HXa9rLOo+YpzLJBhM/V3uZ6YYjCge63ZHYxMo85LiAbxlwrWdKblExhQRlDzfaomGWctOdaLizUmO7ESuQ4U3dg8YuXWFQ6MTb3Cwl5FfV34aIyU9QlDXkkTvyFPI0hahwcy3nFxOEyBl4NTQCA01yOwnYV4Fr2K1ytnSSE/Kq/ug3PwVCScua7Na0BMLCcIgjcYpJ4pKgE/MkOYwzD+OW7kUgyhJGGajXi8GNT2QxvjxFe8G8xbDAxd8YkVrV5RBcKwJWGQWIiOT+OrALE5QkXoo0kgRpmC++EXC+3+adOCLXk6mw== Received: from SA1PR11MB8811.namprd11.prod.outlook.com (2603:10b6:806:467::18) by SA1PR11MB887662.namprd11.prod.outlook.com (2603:10b6:806:520::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Wed, 5 Aug 2026 19:05:18 +0000 Received: from SA1PR11MB8811.namprd11.prod.outlook.com ([fe80::5fae:75f1:3548:9369]) by SA1PR11MB8811.namprd11.prod.outlook.com ([fe80::5fae:75f1:3548:9369%3]) with mapi id 15.21.0270.012; Wed, 5 Aug 2026 19:05:18 +0000 Message-ID: Date: Wed, 5 Aug 2026 12:05:04 -0700 User-Agent: Mozilla Thunderbird Subject: Re: Chromium availability. To: questions@freebsd.org References: <4cc52e97-de21-47e2-baac-275d12aed1b5@palaceofretention.ca> <418ae9091e90abaf0f9ea6dbf70b72f45068000f.camel@telaman.net.au> <20260805092829.GA3425@jmk1.org> <564e15e8-cca9-4c4b-818b-e19319fcedf0@palaceofretention.ca> Content-Language: en-US From: "Edward Sanford Sutton, III" In-Reply-To: <564e15e8-cca9-4c4b-818b-e19319fcedf0@palaceofretention.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: BL0PR05CA0023.namprd05.prod.outlook.com (2603:10b6:208:91::33) To SA1PR11MB8811.namprd11.prod.outlook.com (2603:10b6:806:467::18) X-Microsoft-Original-Message-ID: <7c6671ef-68c8-45f5-a7cc-ae74962139ed@hotmail.com> List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-questions@freebsd.org Sender: owner-freebsd-questions@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA1PR11MB8811:EE_|SA1PR11MB887662:EE_ X-MS-Office365-Filtering-Correlation-Id: 844e2bf3-e8cf-4c79-2f10-08def3247cf4 X-Microsoft-Antispam: BCL:0;ARA:14566002|22091999003|24071999003|25031999004|23021999003|6090799003|5072599009|24121999003|4140399003|39105399006|15080799012|25010399006|12121999013|20031999006|24021099003|41001999006|8060799015|19110799012|440099028|3412199025|40105399003|2607281247196008|25131999003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UWdzV2JKVW9rNHJjcXgrSWRIemZwSmZLOEp4WE9IWklHUEhXQkhFMnk3elRL?= =?utf-8?B?ZmlZa2g5WGNBOHg3QS9nMjlNRTVXS2p6WlZUWStKY2h4MUlRenBvMW1SbnZX?= =?utf-8?B?SVcvR2lOMytrQ0J2V2xzZGFsRGdHZVJtempTcHFhSmRMUW9ibW0zQzNPdndm?= =?utf-8?B?ZElLdHprL0h0cFBNT3R1RmlTSy80QjlBc1I2RWl1aGFZZi92ZWVFVGdkdFBz?= =?utf-8?B?MTJFOVh2THdOdjdpNHpkdDFCQUF0ZTJyQXNvTnhBbkNobFRBZmhDTVh6WmYr?= =?utf-8?B?ZjZVZ09ReEZQTGNOSjhvVTY5Qmo2WUhsNVFObWIwcmxHbzhTdStCRmkwbTlM?= =?utf-8?B?Mi9MRS9xaEY4SGh5Q2dzMCt5MmRpMnB1OVZuQU44Rk9raXNwc3ZJZVVnWmdL?= =?utf-8?B?QWhBN2FrbkVDREJtNU1tclNZQm5TcHhXeVNUdWNURjlnSWh6RUNNYWVPWEUw?= =?utf-8?B?bEE5ZTlQWDAwcDJWNFE5cFVvTVRIcmU0UFB3Q2REZHArQkNhK282RG1BajQ0?= =?utf-8?B?V2dRSVgvbnJXY0xuT1FwSTIvRS9ZNmc0Qy9GZTU2VHRPVXFsOTlMSmpLZ2hP?= =?utf-8?B?YzBMQ0JUQTdNL3l2SWtJYmpVc0l2RU1ianVEWWFLeWVEU1JkSlRhcE0vTnlr?= =?utf-8?B?M2RhcHdmWkFxT2FnbFV4UVFaTjk5VXUwdmJmNlIrZEtObFlLd2h3R1NvWkdp?= =?utf-8?B?c2NqSWZmc2c1ZnQxYktxQytmS1VHcnlLWnNTcWo5b2ZUaXo3a2FIMDZPYlpv?= =?utf-8?B?aW5MNjRXOXBGV1h6Um4xY3N6ZCtvOWt1UlU1RXdqQ1hOQWpXNTFlU0toL3dm?= =?utf-8?B?Um1ZaDhsTFM1dWk4SFVCdUVBdDdLODFPTjNadjdvb3NVazloc1BkdWYwaG1W?= =?utf-8?B?REcvMEdsVkJsK3NIZVNuMmk0Ym11N3Q3SWgzYWNCTFBpT2RqdWlJRk1zeFVl?= =?utf-8?B?b2U5SVp0TGpiZjhTai9ITUJ3Q2RYKzhValQwc1YybVpVY05oSzRhYUJ2akJz?= =?utf-8?B?ZW9FeVQ4TVdkaTNyNFZRWVhpT3NHaENXVXB3WDJQenkwa3RueVNSYUZwMG5N?= =?utf-8?B?OTV0UWF2bm90MDd6QmxQaitDNHhITjdKUm9QK2tHdCtyeDlBSnMyVmZXYjZk?= =?utf-8?B?UmtsYUl6TVp3czd3UExuR0FVQU5SSW5VUVVuRWpPRXNVWlZvL0RKanNLNVg2?= =?utf-8?B?NWRVWVd1dGo2MEZKTXhTd2d0eWtVNmx3RlpYM1d0bWlaZXV3RVRmS0Q5eU1K?= =?utf-8?B?QkJsUHBQMmNiOGtLWHNPZ3VKODFRclp3STdwbWh0bXVyMkVOS1JxbTR2MVg5?= =?utf-8?B?bnVRcGNEYnBiRllQb3gzd3VXNXNEWTUxWUpDOEVTWVFUcldCUWxONTdwZ20x?= =?utf-8?B?dXZZVnUrMW92b3lxdHk0WE5FVzN2S2JZcnBzYkN4VTVtR1hnak91ZTVhSTFG?= =?utf-8?B?TEFjbmFSU1lneDRjeEZFb3NiZ1FIN2I0dnlxb0lBcHgvWGVzR0FNK1M4U0Uy?= =?utf-8?B?aHRSRmJDMEo3Ty9TbEU5WFNrWm53OUt5YzhBeEJ6TmF0RTVNa1p0R0hCNDlJ?= =?utf-8?B?TDNXQmNML3BDL2oyRDRHOUF2dlZ3MnFaYVczTVZuSmE5Z2hRMWZibmF4d253?= =?utf-8?B?V09LeTVSalBsUzFJamtmcVp0VFRCRlE9PQ==?= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WGxJT0FYUUtiSUpLZlNUejBadFY4RmRoWmVsc2JQZ1FnMi9vWkpNSlNVcWtK?= =?utf-8?B?bnNwUFpyZnRyNnB4c1hmM3RwUW1ObUFxRDRMSWNuNmVPSHRsaWtLZ3dYU01a?= =?utf-8?B?MGFsTEY1VkpOQldtd2N2b0c5bDZZYWdIS1lOem1PdWJtNHNmZmt6OUhmdHJD?= =?utf-8?B?RytpbGtQNUxnVVFRMG1qbGk5Nmg3NkUyQ2VqQkN3eThIcUxQVFQ1bWVEWVhn?= =?utf-8?B?VEw1ak1OL2RUVTRSK25wV08yL2VOWUNsUEJxWnlJdy9KSFZhZkhUUzVOcUkw?= =?utf-8?B?TnBUSzF0a3dRcnozSTQxTzhIcmFNY2NHWmw2OFNCYzZUZUh4ajFmYkUzT1FM?= =?utf-8?B?QjRSTHB6RDVtSmRuTG9YVDRRQTdXZ21JVUtNaDRrb2Fwbk11OFdCdlFwU3kz?= =?utf-8?B?MGI4UGovTW1uVXM3ZGY2TjlYQU5RTWFSSlhGdEx2Y3lvSDdYdGg5Z1hlS3ho?= =?utf-8?B?QXVMYUdFOWU2Z0QzS0FtMDhxTVNIM3E4MDNhY2JOMmtwczMxRm5mcVJwcVJW?= =?utf-8?B?anhWajB5OUZ6RVZhUzFnWDd5QXdQTEVVQWZ3NVZuWUtsSUVCVWt4eUVnaWJ5?= =?utf-8?B?bkcycFFKR3N6NVcyaHdUUEtUZndrMEdCMHNIejVQcEVpbWhKYUVWL1l6dHBQ?= =?utf-8?B?YUkvYUZxcnJ2SjlNT2xvUTRjNDk1VEZTZFVaMlpkVEJPc2x0OVBZb3F4RlRt?= =?utf-8?B?WGk1S2d4WG0wbzQ4M3J2M2ZJK3NLTnViM0JxNVR2d1VEMTZlaFk3Tjdqd3gz?= =?utf-8?B?eSs3cFc1eTNQdXdZdUZaaHJ2bnlXMDFsNEc3bm9Ma01ucHExY3VqZloyQkI5?= =?utf-8?B?clRiY1IzT05VRnNCNzhaNzR4NXlQcGVYb3FrVVU2d0ZCckJHc1p0T1Urc3Fx?= =?utf-8?B?a3VJY0wrS2tSNTlqK2M1SXlNNit1cDl5czN1bnRRSXkvNmVObHdYSCtSM3JU?= =?utf-8?B?ZHRqdVl1OFdwV3g0eWV2TE1FSUlJVWNMUWNYaW1jVFNvVC8zZ055L3pTVDI1?= =?utf-8?B?K0taemo3dTJmL2VRd0prSGNNbGRUU3ZRMDA1a2tGM1dibmJVZEhlaFFjMDk5?= =?utf-8?B?ZkdXbU1ZWWN6N1pveENmazk0MFYrYThNQTdkeUdReWMyUnA3eWRBOUhMVmdY?= =?utf-8?B?QjVwM2hTa3hNZ2o3dFgxOGd3MytBeTlvRFg3ZVJ4YnVyOEhidUZOdW9VK2ZO?= =?utf-8?B?SHVQVFpvbGdiRTc3WEZnK0ZGb3hJdDF1d014bjNWcjNTRVdUSUtINnloUWdB?= =?utf-8?B?TGFPb1VVME0zNmZCak1YNHgxM0FHSTh5TGtxNzYwV1lZeTFFMDZrZjUrK1dt?= =?utf-8?B?MWtzNGg5MUI2NDUrWVB3VTV0dkhqYnBJMW1vaWxGWEpmZHc1MjBDOFlQQjNT?= =?utf-8?B?U2hRYjdGV1pZMSsweTNTajczdE5LQTVVanlTeHgrVkxkZVFESkZaZDVmaFda?= =?utf-8?B?WEZiR05WUHhySGpnZnU4NTJDeWZBVmt4R0R5c2pXM3VsdzNhZ0JnVDVmRGpa?= =?utf-8?B?UEVnNkFDNXlFTXhscVhLa3Z5eUNJNkhNRjFyZDFsZXpGYTZsL0g4N2NCeDZk?= =?utf-8?B?OUpZRjJhWHkyc0tEbnVsQ2U2RUVoaEFDSEcwME1saXoweWEycG0rcEt1TnIr?= =?utf-8?B?eVg4L3BWNXIxem9QdFRHRmRKeUk2ZUZ0OFJQSHNDeTlaTDM3WmRBeVE5bnU4?= =?utf-8?B?eGVPdEZIR2YyOHltSkN4NkNiRU9NQVNmY1paK21iamIvaXU2VzNYWllmYURj?= =?utf-8?B?L3Z5bDJ5L3FFZVpTRld0cjlRSlNka2ZadFE3UzQzREVNM05ZN3FFKzJJakFM?= =?utf-8?B?eEZveGVBTVd0T1daMW8wQldmUVZ6M2FKOEZBTFhGVFN1TW5TM3VKZGloeHdO?= =?utf-8?Q?H5L7tLcoMWDet?= X-OriginatorOrg: sct-15-20-9412-4-msonline-outlook-a6b68.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 844e2bf3-e8cf-4c79-2f10-08def3247cf4 X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB8811.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 19:05:17.9460 (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: SA1PR11MB887662 X-Spamd-Result: default: False [-1.58 / 15.00]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector10001:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none]; R_SPF_ALLOW(-0.20)[+ip4:52.103.0.0/17]; R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.08)[-0.081]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[hotmail.com]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; RCVD_IN_DNSWL_NONE(0.00)[52.103.20.19:from]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RWL_MAILSPIKE_POSSIBLE(0.00)[52.103.20.19:from]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[questions@freebsd.org]; DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]; DKIM_TRACE(0.00)[hotmail.com:+] X-Rspamd-Queue-Id: 4hFfxY0nhyz3wCd X-Spamd-Bar: - On 8/5/26 06:08, Mark G. wrote: > On 8/5/26 02:28, Johannes-Maria Kaltenbach wrote: >> Hello, >> >> just for your information: >> >> On Tue, Aug 04, 2026 at 07:59:17PM -0700, Mark G. wrote: >>> On 8/4/26 19:35, David wrote: >>>> On Tue, 2026-08-04 at 19:31 -0700, Mark G. wrote: >>>>> On 8/4/26 19:26, David wrote: >>>>>> On Tue, 2026-08-04 at 18:56 -0700, Mark G. wrote: >>>>>>> On 8/4/26 18:51, David wrote: >> ... >>> I am running 14.4-RELEASE-p8, on another system and see >>> that chromium is missing from "latest" and "quarterly" >>> (I am just showing quarterly below, switching to latest >>> gives the same results): >> >> same version here. >> On 14 I was never able to install chromium; it always ended >> in a timeout (after 24 hours). >> Perhaps that's why it isn't in the repository? >> >> from the poudriere log: >> >> [00:01:08] [01] [00:00:00] Building www/chromium | chromium-148.0.7778.96 >> [00:01:08] [01] [00:00:00] Status   www/chromium | >> chromium-148.0.7778.96: check-sanity >> [00:01:18] [01] [00:00:10] Status   www/chromium | >> chromium-148.0.7778.96: pkg-depends >> [00:01:19] [01] [00:00:11] Status   www/chromium | >> chromium-148.0.7778.96: fetch-depends >> [00:01:19] [01] [00:00:11] Status   www/chromium | >> chromium-148.0.7778.96: fetch >> [00:01:55] [01] [00:00:47] Status   www/chromium | >> chromium-148.0.7778.96: checksum >> [00:02:00] [01] [00:00:52] Status   www/chromium | >> chromium-148.0.7778.96: extract-depends >> [00:02:00] [01] [00:00:52] Status   www/chromium | >> chromium-148.0.7778.96: extract >> [00:03:00] [01] [00:01:52] Status   www/chromium | >> chromium-148.0.7778.96: patch-depends >> [00:03:01] [01] [00:01:53] Status   www/chromium | >> chromium-148.0.7778.96: patch >> [00:03:03] [01] [00:01:55] Status   www/chromium | >> chromium-148.0.7778.96: build-depends >> [00:06:12] [01] [00:05:04] Status   www/chromium | >> chromium-148.0.7778.96: lib-depends >> [00:06:53] [01] [00:05:45] Status   www/chromium | >> chromium-148.0.7778.96: configure >> [00:07:27] [01] [00:06:19] Status   www/chromium | >> chromium-148.0.7778.96: build >> [1D:00:07:42] [01] [1D:00:06:34] Status   www/chromium | >> chromium-148.0.7778.96: timeout >> [1D:00:44:46] [01] [1D:00:43:38] Finished www/chromium | >> chromium-148.0.7778.96: Failed: build/timeout >> >> >> I don't depend on chromium, so I ignored it. >> Is there a built-in timeout in poudriere? >> > > > There are indeed a couple of knobs that need setting in: > > /usr/local/etc/poudriere.conf > > In no particular order (I had some file limit fails, so bumped this up): > > # How many file descriptors to limit each jail process to (default: 1024) > # This can also be set per PKGBASE, such as MAX_FILES_RStudio=2048. > # Package names with hyphens (-) should be replaced with underscores (_). > MAX_FILES=4096 > > > The one you're looking for (I set to 10 days, and chromium finishes): > > # This defines the max time (in seconds) that a command may run for a build > # before it is killed for taking too long. Default: 86400 > MAX_EXECUTION_TIME=864000 > > > I also lowered PARALLEL_JOBS from the max (32 in my case) to less, > so I would have CPUs available for other things than the builder. > > # parallel build support. > # > # By default poudriere uses hw.ncpu to determine the number of builders. > # You can override this default by changing PARALLEL_JOBS here, or > # by specifying the -J flag to bulk/testport. > # > # Example to define PARALLEL_JOBS to one single job > PARALLEL_JOBS=28 > > > I also disabled the use of TMPFS (and some failures stopped): > > # Use tmpfs(5) > # This can be a space-separated list of options: > # wrkdir    - Use tmpfs(5) for port building WRKDIRPREFIX > # data      - Use tmpfs(5) for poudriere cache/temp build data > # localbase - Use tmpfs(5) for LOCALBASE (installing ports for > packaging/testing) > # all       - Run the entire build in memory, including builder jails. > # yes       - Enables tmpfs(5) for wrkdir and data > # no        - Disable use of tmpfs(5) > # EXAMPLE: USE_TMPFS="wrkdir data" > > # Disable 20240916 see if build problems go away > USE_TMPFS=no Consider adjusting USE_TMPFS if your builds don't fit in memory. Going to swap slows down the build but it may still be faster than doing filesystem partially or fully on disk. Reducing PARALLEL_JOBS also helps as multiple ports being built = multiple extracted directories which adds up to using RAM faster than some people will expect. Once you have decreased PARALLEL_JOBS, you have decreased how many work directories are simultaneously extracted which with TMPFS can have a very large impact on the needed RAM as you get into larger builds. I find mathematical factors of the CPU count and set PARALLEL_JOBS to one of them and /usr/local/etc/poudriere.d/make.conf:MAKE_JOBS to the other to try to create an approximate limit of how many cores are used to equal those available. I will decrease it for better system responsiveness and increase it to try to guarantee full core saturation. I usually favor fewer PARALLEL and more MAKE + keep TMPFS set to get a more efficient run; seeing that rust requires >32GB of RAM and I only have 32GB I should make exceptions but for now I just let it force some swap for a bit which is still nothing like the havoc that occurs with swap from running Firefox for a while. Fewer PARALLEL_JOBS + more MAKE_JOBS means each port will finish faster and in the case of something like chromium it takes a very long time on modern processors when you give it the default of MAKE_JOBS=1 since you run only one, generally single threaded, command at a time. Unless all other PARALLEL_JOBS were active throughout the time you were building Chromium, you likely just increased package building throughput. Some ports do not properly respect MAKE_JOBS and will exceed the number, usually going up to a value of MAKE_JOBS*MAKE_JOBS. The problem seems to be a result of mixing build systems and having the outer build system + inner build system both launch MAKE_JOBS number of processes. The reverse is also going to happen as there are times where a port does not have as many tasks that can be worked on as MAKE_JOBS is set to and I assume there are still a few that consider multiple jobs as unsafe (which poudriere doesn't account for). Once you apply MAKE_JOBS, you can likely significantly reduce per-build timeouts. Applying the PARALLEL_JOBS+MAKE_JOBS adjustment to the official build servers would likely help if nothing else has changed as I thought I recall seeing amd64 reach at least 98% of swap space use reported during a build. Repeat runs that failed may complete the next time if there are less parallel jobs competing for resources and if you use ccache then the previously compiled results will be read much faster so without adjusting the timeout it will get much further along if it doesn't complete. Ports are normally extracted to a version dependent path so upgrades of the port's upstream version number will often invalidate ccache results on that next run. I'd assume ccache settings should be altered to disregard the path of input files as long as debug is off and won't have any symbols packaged as subpackages (whenever that becomes a thing). For a change that port maintainers are directly responsible for, the workspaces are further unnecessarily bloated by most ports extracting everything from their downloads when some things can be filtered out. When we use other ports instead of bundled copies of dependencies then the bundled copies don't need to be extracted. Conditional extract excludes like skipping NLS language files when NLS is off saves a little bit. Some ports extract some unused files like windows and macos specific files we don't touch in the build process and text documents that aren't installed nor used in the build. A few port maintainers have recognized this and added `rm` steps sometime after extract and before install (where it happens varies port to port) but that means we still get wasted I/O, wasted storage space, and for filesystems like ZFS we get further flagmentation to how data is laid out and accessed. a more appropriate solution is something like (adjusted to target directories/files relevant to the port): #EXTRACT_AFTER_ARGS+= --exclude ${WRKSRC}/*.ods --exclude '*.pdf'\ --exclude '*.doc' --exclude '*.xls*' --exclude '*.xcf'\ --exclude '*.blend' --exclude '*.blend1'\ --exclude '*.yml' --exclude '*.vcproj' NLS_VARS_OFF= EXTRACT_AFTER_ARGS+="--exclude *.po --exclude *.gmo" but we also need the following to avoid overwriting default extract args that will not be set if we define EXTRACT_AFTER_ARGS: EXTRACT_AFTER_ARGS+="--no-same-owner --no-same-permissions" I seem to recall exclude syntax was not working as documented; think it was not working with paths but maybe it was path+wildcard or path without filename that was not working as I expected. If implementing, you should test that it really did what you expected. I think the default should go into an always-appended variable of its own so it can be directly overridden if needed but will be otherwise be included by default and not require the port maintainers each re-include those values since those defaults seemed to be an advised security adjustment. The ports framework can be designed to apply things like NLS defined excludes once NLS becomes involved but should be easy to override if any conflicts are found. It would be good if there was a general EXTRACT_EXCLUDES syntax that maintainers could use which could take a list of directories, files, wildcard expressions and build the proper syntax of exclude commands to auto-append to the extractor. Its been a while since I last tested it but I previously found some extract steps were slowed down by adding excludes; I would consider that a bug that should be addressed separately rather than working around it with an extract+delete.