From nobody Mon Feb 10 12:07:19 2025 X-Original-To: freebsd-pkg@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 4Ys3H852gBz5npBK for ; Mon, 10 Feb 2025 12:07:32 +0000 (UTC) (envelope-from diego@bsd.com.br) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ys3H76zvrz43Hw for ; Mon, 10 Feb 2025 12:07:31 +0000 (UTC) (envelope-from diego@bsd.com.br) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsd.com.br header.s=capeta header.b=PK0PuKYb; spf=pass (mx1.freebsd.org: domain of diego@bsd.com.br designates 2607:f8b0:4864:20::112b as permitted sender) smtp.mailfrom=diego@bsd.com.br; dmarc=none Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-6efe4324f96so36046467b3.1 for ; Mon, 10 Feb 2025 04:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; t=1739189251; x=1739794051; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=hosMiGNj0chtmj5MjSSKhQdP6ZtKeasFBtOy31TFNHw=; b=PK0PuKYb/nv60SdiTWU8X6kJS6s9jGP1j+s4JIaTYM3B+ad03t1Hq5HMgRrtTrQI2e os23hzDpx55u5++jmmjVOI/xkrsvjXHejsFuM8SfNRlN2GI39ena0tlc+xzvh3ep4vWG Nql7HdMmujVTwmYnA8MfxgAx5eMDdP5IWa4ag= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739189251; x=1739794051; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hosMiGNj0chtmj5MjSSKhQdP6ZtKeasFBtOy31TFNHw=; b=B/nomkNr5C0+bFEp4fmcx63MitaAwumvJrFw31qUfUdm36GBU9c+tRgyet2hYQC+Gw W2PpWUhh9eX4E1/ngI/xqAN4E5067vJUQxwAo4IGD3hNV9v3Dqce22mJA2+yEsTkGjR0 lw6dsFmbMYfl/T49fJdGGe3GpAkWGZrUKyGZH/37daBVWfy253GUVHg7gAO0sGCHeGt3 3c3V3l0FlVmhrTj9rsiTrHu4oRtXoKA4nVlyW5AC7ezaKr4jOj+oxlOZM09knUH+L75G As8Q0qdVI2i4H4tk1xvXJVbbKk63bGI260SMj6T4Havno4514p77+z0Tx0VcHgwOx8yx 4FLw== X-Gm-Message-State: AOJu0YwDJ9lyAGbwNLzhCsn3oiQpeIrIGOvkv4vLQgXoW/zCv0E9euuC hM/L3ZSvEQQykylv9NDnP/2FKyvT4sAY695tdQspUnYqWDPj497YfmWS0WlEceGPeb3FhiL3T/v dieZvO800CGRtxZFUshC+VrLXAWIy+DaLubDYW9k7jIop0I0L9Q== X-Gm-Gg: ASbGncuRRYxq4GbJZcLbvz8n/9fKCiQhpdn2jbcnhD/LcZ1YbSd/abnJa6ZwCjf/2zq oSS/2q05vR9x+e3XfIq/Fi/bEZt3C2T+dTWJ75nb6/wUAqgndFg5hci+z2ryd5I9WHPl2MAcVkQ == X-Google-Smtp-Source: AGHT+IFS7DJjcnPb1Z4K2tjBDtjOSQAAnn5583+1zR6NHmWq82ffRz2eETI3Nmh/VXy9tpNcdGy9u0KSft0JZ+KwTm0= X-Received: by 2002:a05:690c:4513:b0:6f9:50aa:b7f0 with SMTP id 00721157ae682-6f9b284423amr124178627b3.11.1739189250852; Mon, 10 Feb 2025 04:07:30 -0800 (PST) List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org MIME-Version: 1.0 From: Diego Linke Date: Mon, 10 Feb 2025 09:07:19 -0300 X-Gm-Features: AWEUYZlNWqNCX1Er_YpO8apQjW2ehzWmpFE5tYU4tRAbJkQfoKC1VZeQ8xqlZ38 Message-ID: Subject: arm64 pkg building is taking longer To: freebsd-pkg@freebsd.org Content-Type: multipart/alternative; boundary="0000000000007ea557062dc88d80" X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEFALL_USER(0.00)[diego]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112b:from]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-pkg@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[bsd.com.br]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pkg@freebsd.org]; DKIM_TRACE(0.00)[bsd.com.br:+] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4Ys3H76zvrz43Hw --0000000000007ea557062dc88d80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I noticed that ARM64 packages take a few days longer to build and become available on the official FreeBSD servers compared to AMD64 and i386. For example, last Monday, Mat committed the Bind 9.2 (dns/bind920) update to 9.20.5 in the quarterly branch, which has two security fixes. This update was available on amd64 and i386 2 days later. It's still not available (after 7 days) for ARM64. Could we prioritize building packages with security updates, especially for the quarterly branch? Is anyone aware of any initiatives to improve this process? PS: I=E2=80=99m aware that I can set up my own package build infrastructure= using Poudriere and am considering it as a fallback option. However, I=E2=80=99d = like to explore whether we can improve the process for everyone. Regards, Diego Linke --0000000000007ea557062dc88d80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I noticed that ARM64 pac= kages take a few days longer to build and become available on the official = FreeBSD servers compared to AMD64 and i386.

For ex= ample, last=C2=A0Monday, Mat committed the Bind 9.2 (dns/bind920) update to= 9.20.5=C2=A0in the quarterly branch, which has two security fixes. This up= date was available=C2=A0on amd64 and i386 2 days later. It's still not = available=C2=A0(after 7 days) for ARM64.

Could we = prioritize building packages with security updates, especially for the quar= terly branch? Is anyone aware of any initiatives to improve this process?
PS: I=E2=80=99m aware that I can set up my own package build infrastr= ucture using Poudriere and am considering it as a fallback option. However,= I=E2=80=99d like to explore whether we can improve the process for everyon= e.

Regards,

Diego Linke
<= /div>
--0000000000007ea557062dc88d80-- From nobody Mon Feb 10 21:48:07 2025 X-Original-To: freebsd-pkg@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 4YsJ9R3pC5z5mr2L for ; Mon, 10 Feb 2025 21:48:27 +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.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4YsJ9P3Mnfz3PLF for ; Mon, 10 Feb 2025 21:48:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Kujmn15r; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739224103; bh=Zl3Dj3AwrzAlXQXPPTqaEz9j8q8PABttugP4KqITLPM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Kujmn15rvFhU0b+yzaOdGdv1jajkwiMPdW2yalzhM8Dt0yknbV9cNR3w88JRdFjgVlME/hcj6HGeMt01vVf7q7OPY1QJw1MYlm/0DdX/HhiwXPo+n5o+ONRbWnftGlbHRuwK1UoJghrWveE9yYp7TgljQl4YJPrfvvSpfQuLTrertBN1Mmd5BPu0mH69snJbU3Arb3/51Mlukhodaos9WuPANBwJhe/BFrT9/Lla6z8MVnKPsSH9RDp1AU1fpFZ1AW33+DoYKYZT8wfdv7hrGnAoSeRbkPTbO4ZOazQzU3q8+2i+fZdmp6Tt33L587yxnF+vhGc7HJ9XijYvxJ4nkQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739224103; bh=zc4pSW6IE0bnAsAgjTY2wljMa1FWJl2slYIvAP3a8j4=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=gTjwNXM3IWRYypsSBu4H/YP/vqGE2DG9yHfEPPpHPMnlmGto+RpMo1qfxgOwY4KssGXVBGnnDm7E6/csMxvU1lDzEWzMfWMJLQs48ckoYykpBjpoynOOZEtsbneeRJxZuHLMV3fe5wAJjTZ2shQvRoIYUAENA0MdXwN6r6y+ywTbcrQChF0BgmBLet/Ra2VGpYLO6fmh6+5ylImfCyx92L5eiWjVw3SfL/4qBe/m9RYwrv10ooNSYFOHHqCIHFFaf79yjR2gA5J5jZpwnhH56QmpiUIXOtb60ZSWEKXdsF/LL/r6X/2ZYun3r4InCM0aMaT54/cshtv7HhYGUyyPSQ== X-YMail-OSG: g3UGRTUVM1mSukhjX3GmQy3uDPJFLTpMCEUNK5_zalKYoslTkyvwce.IjotA1x1 8uoXes64PN4iVmx_iawVGsDhzmT2qFwUsoExGyGD_b0JirE06xsAAA0G_Q89cVALcSafKb1J4A0P YyqtfglHKWnGLT9b98KrTmQcHkGuDwl5eS5T0ytPefUwo7a7Uh9VNCcZt5Erpmn4DMFsdf2DsOHV fboSPJuwMuT7q7feSblTPj_uyscShQpq7tLWJVYWsWWIa9XJ091HxTzN4hDDTp90_VSohi8USNci F8WRtd6UMpPjZ.IjkPbg2TwkPi_DlufxhjGw.SozzHAsgQUxz1gUT6j74roGa2QPzb_JDgDTB0K1 1834BAKX2bTs_ljeOXxhqsbFR8hrpMJyS2GHsFquUz12IIbpQCyWtOllTmg6ilb1UXyvNaC8RL50 kDK2EtM0t9qwqfao.9zNISELjg4GJ70ZqhqbBP7MDUt.co3E8SYUjvsI2bf1QpHyso_bnNjTkSM_ EnddNltOjdiP9rmVQK9oVWsSjzl1vYHLV5owaLqtortM7OX3EwmmRgWiS39GAd0hFrePB0BHs.Ga y.jS5FE6ypx1lnQjFKLlOO137csZS68zWfAFynjFNyXcUbPn1cqhXZF3knrVJOzq8io92G43nwTy yliFH4VQx7Om5kzo5fBnvwurKQMl2Oa6VCOjfnUwflZO4VohZ6vN2uxfJbrJFoPm_cfWkvpQGN05 e2aagPAZ8KiiPA4DVOlyilURRZ0HoeodtEtt.fzxkTtle96sZ0bNTvQYaTwqKn14N0CTS5PfySPB yZ3CZcFUTn4.ncamvgIVluUO5bo_.yKIQc6_wgo2qd30oisKsE7e_oMwXJxZwiSRgusLGH5uQsYU m5zU.JI_bM.VM0gyfbruqcORJSEL3kwKxGZVBcaQYUJtb0orGPe9h1wScM_qEVuOJ4is3W9rYBjf v1qEhjVHyzwRn45JOZY8Czrb6KVStJ42GFhdL3TKMazybYgVPwKGjEtccWvrlOn9bOMhs.jFJSWn q4g0d5my4cb6bbP7ULnFTa40lAj1QNAEQbsCw3rD9IdKRhFkXXERdL4.knSGKx2RGKsH.8oWHnPY gyvfyddztzo_pLkb.BwwGlh.LOOtL51ZtR6RsUs77oy3.xskzKuuLz3oVCZeITr9uAM8RvzBiuJL Bmgq6qODzh5QD5llNPNpB2grBkZ_7qPWzU_.F4C33.xOaJIKfobEWPLuYHyJow4kXdlJ3op01cQb mDsdO7XNNqKS3iUKM4h6ifFaaNHdxAtD15or08y_51qxq.L7.WFiQklCYocw3VW4Tiu6qvXuFFDJ _MiUjie0_yThbuxFHlzdnHBELehm_xL3ZEIsvkz.0G.e69KOslC5hPrqb0hx8632gJS68__jLGHv mvo1BRkhyhAxYqIqLFliQkx15HKdZISi7OC6urlyAw0Z8.4qj_i3XNktaNgM7fo3kea0aGV7fMja 6gYDYXNXwgNptA27aq5lKAL2tHLSGAummsvbYZilCWUvJKaAT2w5p2EVRik.Wyara1h9KCpFxNg. mD3jGgOG9HK6uPd46gPHW2gRaz0xAZmphT1naPH0dVrRzLSrAer27i.9taApLPwxbzjT_ARJAmKh Qvf5Mfd7C5c_3ebGldF4c4DXc23cPXkZ53lc4LGz5pA8_0SqR.mrndQCTaLXbZW7JwtnfACP.Hcm TOf.sfNhgX7EegqAbCgGkKlinXTSEOpVvdM2dd4pWiFS7Fn6Qk6A2dV7VfDGRds_ULOZTpXUJvpr 7QBASHmICAo9C7uZJoME4VzVHMXoD54VWroJlAZ0HXO3cJzWktEDghj4fVONUkzAzIxC74DBPyo7 OS.3muYejxdhp_zEPGrkxFJO.9p77hM4aYw5M4B0Aoa7754HpoYWKX07HrgO6.ljhcwuVk13ftpd ZGX2XHNL.n4mb.sx1J5bWO5eLsdeo34z0erMYOUnmMoG_c2n5C_SDzvjoLsiyHCQqNHoFj0P0bap cHaACsx7S6jb3Oo7GCcTze7nxKhlEM9RA6GtqXyI.XRSdZsFU30IpugcsD2vd7sQ3gT_G6b8bqRD g_HsYNopDGHQjnL4OX5Kf8Ff0KMh.95YKyH.zJF7w9855sCCwUcpeD4YkRxwMURa.Zjfqy94WCMe PXNVk.2s8mue5FYRmSTJgvhWIrAnA7Matnyu9.sKCl50K5g6sflYEiB9b80cu_8CnDe.ArntIW3e owrD_BSWdm5HFllwWpy73s0YXIGhoXaHpvB3qyE7LTGvagpjluuKaSsZXZbnm6LMOz6aYI3HY_H_ iGZg- X-Sonic-MF: X-Sonic-ID: 92829447-4856-49a3-b8cd-b9fa84319dd8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Feb 2025 21:48:23 +0000 Received: by hermes--production-gq1-5dd4b47f46-9j75b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e8338ccc225cb57bbb1c2aa933de4fe0; Mon, 10 Feb 2025 21:48:19 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: RE: arm64 pkg building is taking longer Message-Id: <566D4C18-A850-4394-A717-4E61FF0EA129@yahoo.com> Date: Mon, 10 Feb 2025 13:48:07 -0800 To: diego@bsd.com.br, FreeBSD-pkg@freebsd.org X-Mailer: Apple Mail (2.3826.400.131.1.6) References: <566D4C18-A850-4394-A717-4E61FF0EA129.ref@yahoo.com> X-Spamd-Result: default: False [-3.37 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.83:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_SHORT(0.13)[0.126]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[FreeBSD-pkg@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4YsJ9P3Mnfz3PLF Diego Linke wrote on Date: Mon, 10 Feb 2025 12:07:19 UTC : > I noticed that ARM64 packages take a few days longer to build and = become > available on the official FreeBSD servers compared to AMD64 and i386. The amd64 systems are generally faster and there are a lot more of them used as package builders. There are only 3 aarch64 build systems: ampere[1-3]. By contrast, there are 10 amd64 build systems, 3 being fairly modern and vastly faster than the ampere*'s (far more hardware threads, for example). ampere1 cycles through building and distributing: 141arm64-quarterly 141releng-armv7-quarterly 1341arm64-quarterly 134releng-armv7-quarterly amd64 systems do not build that many variations on the same machine: in fact each normally only builds one variation, no waiting for other cycle members to finish. As each takes longer, the next time it gets back to the same type of build, it is likely that far more packages that need to be built (compared to the analogous amd64 context). It is not as extreme for quarterly as it is for default (a.k.a. latest). ampere3 is similar (default here is a.k.a. latest): 141arm64-default 141releng-armv7-default 1341arm64-default 134releng-armv7-default ampere3 likely builds the most per poudriere bulk run compared to ampere1 above, taking the largest to get back to the next build of the same member of the cycle. ampere2 has only 2 cycle members (as stands, main is 15.0): main-arm64-default main-armv7-default So that makes 10 separate variations overall, spread over the 3 ampere*'s. amd64/i386 has 10 separate variations as well, but 1 per amd64 system that does the type build. 141amd64-quarterly , 141amd64-default , and 141i386-default are what get the fastest 3 builder machines. > For example, last Monday, Mat committed the Bind 9.2 (dns/bind920) = update > to 9.20.5 in the quarterly branch, which has two security fixes. This > update was available on amd64 and i386 2 days later. It's still not > available (after 7 days) for ARM64. Expected sort of result, given the resources available to put to use. > Could we prioritize building packages with security updates, = especially for > the quarterly branch? Already done: The more and bigger "default" builds do not complete for the machine time on ampere1. Mixed on the same machine the "default" builds would further delay the quarterly builds. > Is anyone aware of any initiatives to improve this > process? Unless the aarch64/armv7 system resources are considered as part of the "process": it is not basically a process problem. (I'm not intending to imply that "no optimization is possible", just that such is not likely to lead to a large change of scale for how long things take in order to reach similar times to amd64 now takes.) > PS: I=E2=80=99m aware that I can set up my own package build = infrastructure using > Poudriere and am considering it as a fallback option. However, I=E2=80=99= d like to > explore whether we can improve the process for everyone. That last note repeats here: it is not basically a process problem for what is the major constraint. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Feb 10 22:22:17 2025 X-Original-To: freebsd-pkg@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 4YsJwk0LMcz5mtVb for ; Mon, 10 Feb 2025 22:22:30 +0000 (UTC) (envelope-from diego@bsd.com.br) Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YsJwj5bvrz3fc9 for ; Mon, 10 Feb 2025 22:22:29 +0000 (UTC) (envelope-from diego@bsd.com.br) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-6f666c94285so43669477b3.3 for ; Mon, 10 Feb 2025 14:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; t=1739226148; x=1739830948; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j1iYiMZ9VrBRjnM0CkmQf+O3Csr4e96U4QT7oCJXZvs=; b=Hxt9qWxebJENPAmdgafhpC+XYq7hNxGtAr/dEweqoFRuywUMh/SCW6tWBdT40OLg9k 0BSh9RcKh89DoRgoBaeD3b1ce+mbMrxTeV2474dB3xqt9rbxOxNB8mW2ns1LFO2+Ng5g OzUnGicMxp6JBnzrfDwUBDd0BzIx+hY4ciLc0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739226148; x=1739830948; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j1iYiMZ9VrBRjnM0CkmQf+O3Csr4e96U4QT7oCJXZvs=; b=dFkOepMe1h53DeCygKhSR4CODRwPPBseFKawDPfYM3zdV9oR6sH0Eu0SaOqu3GrkEJ JHhuzWaGcDJ0JGwVCSQ2iicq/c9ECD2DCnO5B+pR4I8mAsCwI34hXTP25/WYKTEv1G52 lVPaDCFR0f08MezJzyduhNjzh7kXhIJZgvAlJez0WhbFkYKXheHgAPYrMtLgg5KFaL5p WKQgsUFz6wBfySl/4K7qYn3gSRn4keqPzRH4CF7hDkYhzKTx0iNiKQsXaRq7OdCg7sNt AnbaKg+j25Twf4c4ZZUvmUQCBidmFWEp3oepslT7tuQQnMd5LRWJDmMYQinLZbMeXFKg yMYg== X-Gm-Message-State: AOJu0Yz2X/h6AIhldeBA0SFKE73wQmYXEZvvF4J7bJIH2/C3Wu/oWEiD RCkirhJWe/yQT0FWWJIGMJzWAyl9zxULK+NHEUp5pStuuNEGARlX05oAMKbVT+rIG0PB8Nl6BDK 4Ko18+8GieWM9GHdRmGcQkgWH122sWMTpMjta X-Gm-Gg: ASbGnct3u6ndUUYLldyjWd0E3fwxjIw5xZlZ6m00L6rqrvfSP2IrWuanB80VwNmJmP2 h4XlMo8MY1iNt4nUsqIuFyXb6LmIn5ZWPLcWoEb5dpaX/u48AmTs4cFtKAicpdO/B2o/98RMd X-Google-Smtp-Source: AGHT+IF8nyDvAlxyjv8tgpHkr8uNQfWi+ef0YQ+j/KTR0yDf+asixdg290wdyY4hheEJioAUkNdUvSFdxPrsu1jQbHk= X-Received: by 2002:a05:690c:c14:b0:6ef:9dbe:9f82 with SMTP id 00721157ae682-6f9b2981af4mr140008717b3.29.1739226148184; Mon, 10 Feb 2025 14:22:28 -0800 (PST) List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org MIME-Version: 1.0 References: <566D4C18-A850-4394-A717-4E61FF0EA129.ref@yahoo.com> <566D4C18-A850-4394-A717-4E61FF0EA129@yahoo.com> In-Reply-To: <566D4C18-A850-4394-A717-4E61FF0EA129@yahoo.com> From: Diego Linke Date: Mon, 10 Feb 2025 19:22:17 -0300 X-Gm-Features: AWEUYZk7e-cMT0LHQOrDI2jXBckzsL5WkVpOhm5HpDaNWjpU-92r0vbaa2enIag Message-ID: Subject: Re: arm64 pkg building is taking longer To: Mark Millard Cc: FreeBSD-pkg@freebsd.org Content-Type: multipart/alternative; boundary="000000000000bf48f3062dd12456" X-Rspamd-Queue-Id: 4YsJwj5bvrz3fc9 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000bf48f3062dd12456 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mark, Thank you very much for the detailed explanation. I appreciate the insights into the differences in build resources and the constraints affecting ARM64. I also appreciate that security updates are already prioritized within the available resources. Regards, Diego Linke On Mon, Feb 10, 2025 at 6:48=E2=80=AFPM Mark Millard wr= ote: > Diego Linke wrote on > Date: Mon, 10 Feb 2025 12:07:19 UTC : > > > I noticed that ARM64 packages take a few days longer to build and becom= e > > available on the official FreeBSD servers compared to AMD64 and i386. > > The amd64 systems are generally faster and there are > a lot more of them used as package builders. > > There are only 3 aarch64 build systems: ampere[1-3]. > > By contrast, there are 10 amd64 build systems, 3 being > fairly modern and vastly faster than the ampere*'s > (far more hardware threads, for example). > > ampere1 cycles through building and distributing: > 141arm64-quarterly > 141releng-armv7-quarterly > 1341arm64-quarterly > 134releng-armv7-quarterly > > amd64 systems do not build that many variations on the > same machine: in fact each normally only builds one > variation, no waiting for other cycle members to > finish. > > As each takes longer, the next time it gets back to the > same type of build, it is likely that far more packages > that need to be built (compared to the analogous amd64 > context). It is not as extreme for quarterly as it is > for default (a.k.a. latest). > > ampere3 is similar (default here is a.k.a. latest): > 141arm64-default > 141releng-armv7-default > 1341arm64-default > 134releng-armv7-default > > ampere3 likely builds the most per poudriere bulk run > compared to ampere1 above, taking the largest to get > back to the next build of the same member of the cycle. > > ampere2 has only 2 cycle members (as stands, main is 15.0): > main-arm64-default > main-armv7-default > > So that makes 10 separate variations overall, spread > over the 3 ampere*'s. > > amd64/i386 has 10 separate variations as well, but > 1 per amd64 system that does the type build. > 141amd64-quarterly , 141amd64-default , and > 141i386-default are what get the fastest 3 builder > machines. > > > For example, last Monday, Mat committed the Bind 9.2 (dns/bind920) upda= te > > to 9.20.5 in the quarterly branch, which has two security fixes. This > > update was available on amd64 and i386 2 days later. It's still not > > available (after 7 days) for ARM64. > > Expected sort of result, given the resources available to put > to use. > > > Could we prioritize building packages with security updates, especially > for > > the quarterly branch? > > Already done: The more and bigger "default" builds do not > complete for the machine time on ampere1. Mixed on the > same machine the "default" builds would further delay the > quarterly builds. > > > Is anyone aware of any initiatives to improve this > > process? > > Unless the aarch64/armv7 system resources are considered > as part of the "process": it is not basically a process > problem. (I'm not intending to imply that "no optimization > is possible", just that such is not likely to lead to > a large change of scale for how long things take in > order to reach similar times to amd64 now takes.) > > > PS: I=E2=80=99m aware that I can set up my own package build infrastruc= ture using > > Poudriere and am considering it as a fallback option. However, I=E2=80= =99d like > to > > explore whether we can improve the process for everyone. > > That last note repeats here: it is not basically a process > problem for what is the major constraint. > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --000000000000bf48f3062dd12456 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

Thank you very much= for the detailed explanation.=C2=A0

I appreciate = the insights into the differences in build resources and the constraints af= fecting ARM64. I also appreciate that security updates are already prioriti= zed within the available resources.=C2=A0

Regards,
=

Diego L= inke


On Mon, Feb 10, 2025 at 6:48=E2=80=AFPM Mark Millard <marklmi@yahoo.com> wrote:
Diego Linke <diego_at_bsd.com.br<= /a>> wrote on
Date: Mon, 10 Feb 2025 12:07:19 UTC :

> I noticed that ARM64 packages take a few days longer to build and beco= me
> available on the official FreeBSD servers compared to AMD64 and i386.<= br>
The amd64 systems are generally faster and there are
a lot more of them used as package builders.

There are only 3 aarch64 build systems: ampere[1-3].

By contrast, there are 10 amd64 build systems, 3 being
fairly modern and vastly faster than the ampere*'s
(far more hardware threads, for example).

ampere1 cycles through building and distributing:
141arm64-quarterly
141releng-armv7-quarterly
1341arm64-quarterly
134releng-armv7-quarterly

amd64 systems do not build that many variations on the
same machine: in fact each normally only builds one
variation, no waiting for other cycle members to
finish.

As each takes longer, the next time it gets back to the
same type of build, it is likely that far more packages
that need to be built (compared to the analogous amd64
context). It is not as extreme for quarterly as it is
for default (a.k.a. latest).

ampere3 is similar (default here is a.k.a. latest):
141arm64-default
141releng-armv7-default
1341arm64-default
134releng-armv7-default

ampere3 likely builds the most per poudriere bulk run
compared to ampere1 above, taking the largest to get
back to the next build of the same member of the cycle.

ampere2 has only 2 cycle members (as stands, main is 15.0):
main-arm64-default
main-armv7-default

So that makes 10 separate variations overall, spread
over the 3 ampere*'s.

amd64/i386 has 10 separate variations as well, but
1 per amd64 system that does the type build.
141amd64-quarterly , 141amd64-default , and
141i386-default are what get the fastest 3 builder
machines.

> For example, last Monday, Mat committed the Bind 9.2 (dns/bind920) upd= ate
> to 9.20.5 in the quarterly branch, which has two security fixes. This<= br> > update was available on amd64 and i386 2 days later. It's still no= t
> available (after 7 days) for ARM64.

Expected sort of result, given the resources available to put
to use.

> Could we prioritize building packages with security updates, especiall= y for
> the quarterly branch?

Already done: The more and bigger "default" builds do not
complete for the machine time on ampere1. Mixed on the
same machine the "default" builds would further delay the
quarterly builds.

> Is anyone aware of any initiatives to improve this
> process?

Unless the aarch64/armv7 system resources are considered
as part of the "process": it is not basically a process
problem. (I'm not intending to imply that "no optimization
is possible", just that such is not likely to lead to
a large change of scale for how long things take in
order to reach similar times to amd64 now takes.)

> PS: I=E2=80=99m aware that I can set up my own package build infrastru= cture using
> Poudriere and am considering it as a fallback option. However, I=E2=80= =99d like to
> explore whether we can improve the process for everyone.

That last note repeats here: it is not basically a process
problem for what is the major constraint.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--000000000000bf48f3062dd12456-- From nobody Wed Feb 12 21:46:00 2025 X-Original-To: freebsd-pkg@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 4YtX292vzSz5nPsC for ; Wed, 12 Feb 2025 21:46:25 +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.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4YtX2866mQz3Q0B for ; Wed, 12 Feb 2025 21:46:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=C1ojho0f; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739396783; bh=a+ZtGFFDa8ncq3+EBhnWlxbTed6bwNNQVY/KwzYQBgc=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=C1ojho0fKTUi3s0pTyL34vob+FM2RdZ7ljFvwJ1P3A5jdoJGCMZmehBvbZ+E/tkhilKPmyUIBuukP3oZswIpAtk07tCoWSUZyqU9UZt+oxXB7LLM6o18+ncAbwMwd4JAjXaaspwYBXw9IJ4VjIY5EqwiyG/lCOg0IsexUNMoi12ttKjOb2JScvQ92qKWQwbzriYMyx2dKYmg2qjswtQOcSCgCO1k2bWBegrDHYy97dAWZkW1FRCgZqzDFIQ5+xB89vK5TcdC0F8jAPmzZus76AVUw7+Fv5/9sDMYeX3RtyyKzrx/eFyjkvUE5o+1LkjVf+yqDMwcbZal9hyDl0Todg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739396783; bh=/iNQUc4MQss9isA8U5DynFs0vCcgLBewRxu2xU3m4GL=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=uNynxOc9d265HEU4h1QHnPNCXCFEPYBeMYERiv/OjXu6Cz9Kduo+AmR920ResmoUZxbVMGeUCra2ye53h/iAHC9+Ac67p77MP9INNUu03LV0CVXmzqPKsrDSWQjdRA98ac8WNWW9nMEijpofX+Hcsc4kn0SqEDkDXoOZrQVXL/65lnCghSHCsFhCDpNgxMlBiudn2GW4UQZHq13BYJgUxC/bOXybed+Q6b/40dXy+VUn4W5P3HPbJYY8Fsalw8NW8J35Selq4dehjCPxLe3PwSHMIFKPOelwrUOqOp39eeBzSPhwN2mOi3uDixRJNJLfVTavRdeozYWenzk6YfDmdQ== X-YMail-OSG: xdWjQC0VM1nx4pMBmG2233TCzKEXfxBtqzW1QaFl1yU9k.xJq3IS_9UIfJOAgzz ZXKMUUU6X5XEED3kx3V7yLKGHGsSyFG_dtXhn3_mlREUyTwbIGxdwt3ub522vSW8YuA2e3aAgHD9 nu2ov68UF1au2N21HIlQKqPIE3hLyMz8fPgRpoBR5S6T40KPnA4EUKeW5c7yf0b.EWQ7llFMi1FA 4w.jzb95KXrG6rI4AdttZHL3bXKfpHYIvHU3sbOe6FIVEo7eh3.3jMGcWBCMziQeWq43rbxe7IIl 0SWeSU6XvJL912m0R8GzUVPpcZKDlY2tSiXNs0uvrmIq6SEKyF2tM_gE7nyFZR45RoPMzCwZSu13 b3ZhdeNXZYpmPlTPXOmrYCWiujxzWpvfHuwrEXXvibhpn7KN..hooaLA3DazGlsoUHWpp9bPy.yo cttN6GBi1.Lzk7wRHF3_gwtIxvigsGTzZR6K0G0LAf6joddJX90ieQZ7eqBdVabGH2KT1DKnnloS WZiQ1wACPBnS7EhpD3JGPn8CK7SAraUy6v5wIH9XzW3gV7HZN.a6pzWcj4anJy3mb4OH4hWKkWh6 1._zYvZTQJoUv6KXNvGAHLuZZnu1aRPulyP8kfPK.lFIBAzcMgmZ5uJ_QYxAd8DCAo.QDpBu_qM9 dEC5xaO9qc3D6OiwJpBaHONpDYCDamC9U__brc5zIF6Ng5Z6kgJMPO3oL_qWvySZO3LCCEBeuDVF KXWzC_1xr8cwgDPSyWO2CPVhuuIiV8hEYxJo.SYrXb_UMZnCMCVKPPhEV7CDYk4ZBnjN1GFeQgeX RjWFeCvKRycp7_2bpdJQkmK6zQOX9d4x_FNX.gmStdxMYvMcmr_pGQHQD8_XJmI1jHV8.QsKCpW5 LP3F8_1vdtxVQA7DfGcybC7c87k_xCpmU_iq22Ux44Hs52dT9IC7GAUvXeFUiqNO9g8vCrtWP8FD wuKTmWCUIk.0zxkA6NhRlJ05VLT9pR0FkLNShkIG3Gx94Z9NPoEyua0AVilSiARrB.O_lBQ4SluG GkeUvD6J5h9BnX8wZTQikt0gmXywVJ0zIFI1TeLYYYN8PHbl61luroGutkcvl5gge_V7cA_9mI_g 6J20LhXOhp7HJs1hKiJXdMAP210gJjgw.oeuf.VHySoxtbTdgTckb895N0sEFv900XQ7AtTeYktQ RU8nCZgElWmxnzDC86hX1hO7DC9JXjyhKh4XJvZDlOJcg6um12dU.C0j4SNtmeDfgvHnB3hGha.F m.dfuJul9udTc9nCvl9BAUXtYzq9zg4NhXA6cncDdg7SGr7_iDTs0O7YCTtv9hx3hxUBDAUI4qOH 5Bm8dHJidYN_7_g2GscNPLOvQRPzsrReN3LPCar43_oGmFvqHhfgth5V_CfVhXtQl4_3aZUgr2cN IG5iPsBVy8XO.g.uHbSbLMJoWNx6mlQ3YfdhIgR9IWA2.yDoIBxqxbgE_Wli9MUegQuXuiOAmSCa .S5wz6FuvGOu_giqvMfPdtv_eH1ONDPiqDY_jI4GoqYE3sdkDufhm1vF6MkidZeEQdWMSd.imYSG Ez8HcfeNXkyulqjQ.tGCULQzUMh0tsM6MXtDep60t9sy7nSJ9iP3zwnaBt3QzgL0XRF9USuJWjt5 jPQGxr9rjj54e1BSwoS_ETEMOY7MEE02bmDgrWUwedSzE.z.5RT7Z0hyXHbjzcYTyxcz2tVjEQEb WZwfphUVXlcNHaZZVftgu5Z56ChNVYNH_ZEGY42uBmU2BlX3VekdF.d_GrEl3lELP8ZSL2mZsWrA ENsoplDJqhipYuU2AjUO2TIHcI40KpB9sivdzHgq6awWjxVs0Qv5wsNh88_rDqPjAykVjv3fotRk wW0TbJNUIQ0wL44Ufj.vegauZhpcx_Cd0vmei9rEBEQhq90P2dojX735CRioGoDi.zWFdoPmvGK2 YJdEu_tcBP.XDUWUBRF7pYOrikm4hePGqEAVpmVZn9CkUkzYWSHHK.25KIWWOhCq2YOWnWSqxxv. SWYCswELqYviSIUdrICUUkysVTSuAt.UnPA0IlHciFGYbi1FXuKwqXMcYAA_Gz92ZdeVuWtgzO5. TRUlqYcjUh1Qyw1MnAf0L46r55ZwV4Ntu_Y9myKwKdnFz_w_ZRkJnIZdNTG0IaM9Wt8P71HvxEwr X7zzKYETCD2leH3OR5S_fGe.MbR0vfNqPnZTU37wxjIs8MVDlpXYkFIBsG5h66ty_TcMcMDLAT9o hprNXaFrJISsCpi4WnFnlpHlo4.tS40U.Ky6hPi6j8FxiwCTlqItoQhotfUL9hapYJMdrpBPEKTm eIg-- X-Sonic-MF: X-Sonic-ID: e845787c-bebc-41d0-95be-a9be5ec797f4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Feb 2025 21:46:23 +0000 Received: by hermes--production-gq1-5dd4b47f46-wrqn7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a34d6c9a6b13dd34e90a33b48f475dbd; Wed, 12 Feb 2025 21:46:11 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: pkg vs. checking for the likes of /usr/lib32/libc.so.7 : a Question related to some aarch64 systems not supporting armv7 code Date: Wed, 12 Feb 2025 13:46:00 -0800 References: <4D4302E2-804E-4487-826F-AFBC57D57390@yahoo.com> To: "bapt@freebsd.org" , freebsd-arm , FreeBSD-pkg@freebsd.org In-Reply-To: <4D4302E2-804E-4487-826F-AFBC57D57390@yahoo.com> Message-Id: <432358E1-4B48-417C-AFD5-AE610AC6A870@yahoo.com> X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Spamd-Result: default: False [-3.67 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.31:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_SHORT(-0.17)[-0.170]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[FreeBSD-pkg@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4YtX2866mQz3Q0B Just a resend, this time including FreeBSD-pkg@freebsd.org = --as originally intended. On Feb 12, 2025, at 13:40, Mark Millard wrote: > Quoting from a recent commit: >=20 >> ports-mgmt/pkg-devel: 2.0.99.4 >>=20 >> Changes from 2.0.99.3 to 2.0.99.4 >> - sort list in manifest for reproducibility >> - limite shlibs_requires to file starting with "lib" >> - on !pkgbase ignore lib32 compat if the lib32 set is not installed >=20 > I use an aarch64 boot/operation media on each of, for example: >=20 > ) MacBook Pro M4 MAX (via FreeBSD under Parallels on macOS) > ) Windows Dev Kit 2023 > ) RPi5B >=20 > moving the media between the machines (so: only one media, > not 3). The M4 MAX does not support armv7 code: >=20 > # /usr/obj/DESTDIRs/main-CA7-chroot-ports-local/bin/sh > /bin/sh: /usr/obj/DESTDIRs/main-CA7-chroot-ports-local/bin/sh: Exec = format error >=20 > but the other 2 do and do not get that error. As the > same media is moved around among those machines, tests > like, for example, >=20 > .if exists(/usr/lib32/libc.so.7) >=20 > will find the file, even on a system for which it can > not be put to use natively. >=20 > Does this mean that there will be pkg and/or poudiere(-devel) > problems for my from source package builds and installs? Are > there extra rules or steps or such that I'll need to follow > to avoid running into problems? >=20 > Note: armv7 poudriere jails would not be used on the M4 MAX > system. But aarch64 poudreire jails would be. >=20 >> - update: be functionnal again with less than 300MB of memory = available >> - small performances improvements in package loading and checksum = validation >> - sqlite: update to 3.49.0 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 14 20:37:25 2025 X-Original-To: freebsd-pkg@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 4YvkPn3nBwz5nd2V for ; Fri, 14 Feb 2025 20:37:33 +0000 (UTC) (envelope-from nxjoseph@protonmail.com) Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch [185.70.43.167]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YvkPm1f8wz3rCf for ; Fri, 14 Feb 2025 20:37:32 +0000 (UTC) (envelope-from nxjoseph@protonmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=hvAe4eKZ; spf=pass (mx1.freebsd.org: domain of nxjoseph@protonmail.com designates 185.70.43.167 as permitted sender) smtp.mailfrom=nxjoseph@protonmail.com; dmarc=pass (policy=quarantine) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739565449; x=1739824649; bh=glc2guLy8Jn/XgaYEidCdDt82Cir1efrHfoVcw59sQw=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=hvAe4eKZKBkDNwUIQs1LBmABu7/lmQETqEUh+eN8peBgZfMRPReSjLbmuASM/30lQ yGU0xkdFVxseEN2xqFmQY4Sheevwe3BhyTf3nRG0xSO9bebZcTT2lq3dbG8bbI0o3m wrQz1e2+IGDoFD+0P5CEjlNGgyZE4L0TExym7BubvqXcearcpBx4MZFwHiRkYIpxVj DRq/D2Z8WmBNOrDUuhUFdL+QQj3YmCokFidUsUlMe7cawIoOKAu3ISP+Xdh3BVdsI4 ldemwRE3DbW3jVwiWqbVVbD1jF61q+/uMEh46QtOoNavNQzfizQDv7tDZGgOSkQxKJ g8LFzhQBheXcg== Date: Fri, 14 Feb 2025 20:37:25 +0000 To: freebsd-pkg@freebsd.org From: Yusuf Yaman Subject: Fwd: Poudriere insists on using tmpfs for packages listed in TMPFS_BLACKLIST Message-ID: <78cd193e-e60c-4e65-b75b-3848d582fc9d@protonmail.com> In-Reply-To: <2e040ffc-f587-40a2-9ad1-9edf80b1862f@protonmail.com> References: <2e040ffc-f587-40a2-9ad1-9edf80b1862f@protonmail.com> Feedback-ID: 21989843:user:proton X-Pm-Message-ID: e6e0794bc0d44d06af5745f239ba947a1be66d5d List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_xUIzDvucv2kJgeUQ4M0cXJxEhg6wD5bNJHfnCiAFE" X-Spamd-Result: default: False [-4.00 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[185.70.43.167:from]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail3]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24:c]; RWL_MAILSPIKE_GOOD(-0.10)[185.70.43.167:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; FREEMAIL_FROM(0.00)[protonmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; MLMMJ_DEST(0.00)[freebsd-pkg@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; RCVD_COUNT_ZERO(0.00)[0]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.70.43.167:from] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4YvkPm1f8wz3rCf --b1=_xUIzDvucv2kJgeUQ4M0cXJxEhg6wD5bNJHfnCiAFE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 cm9vdEBoYWxlOn4gIyBwa2cgaW5mbyAteCBwb3VkcmllcmUKcG91ZHJpZXJlLTMuNC4yCnJvb3RA aGFsZTp+ICMgdW5hbWUgLWEKRnJlZUJTRCBoYWxlLmhvbWUuYXJwYSAxNC4yLVJFTEVBU0UtcDEg RnJlZUJTRCAxNC4yLVJFTEVBU0UtcDEgR0VORVJJQyBhbWQ2NAoKLS0tLS0tLS0gRm9yd2FyZGVk IE1lc3NhZ2UgLS0tLS0tLS0KU3ViamVjdDoJUG91ZHJpZXJlIGluc2lzdHMgb24gdXNpbmcgdG1w ZnMgZm9yIHBhY2thZ2VzIGxpc3RlZCBpbiBUTVBGU19CTEFDS0xJU1QKRGF0ZToJRnJpLCAxNCBG ZWIgMjAyNSAyMDowNzozMyArMDMwMApGcm9tOglZdXN1ZiBZYW1hbiBbPG54am9zZXBoQHByb3Rv bm1haWwuY29tPl0obWFpbHRvOm54am9zZXBoQHByb3Rvbm1haWwuY29tKQpUbzoJRnJlZUJTRCBQ b3J0cyBNTCBbPGZyZWVic2QtcG9ydHNAZnJlZWJzZC5vcmc+XShtYWlsdG86ZnJlZWJzZC1wb3J0 c0BmcmVlYnNkLm9yZykKCkhpLAoKSSBhbSBoYXZpbmcgYSBwcm9ibGVtIHdoZXJlIFBvdWRyaWVy ZSAoZXZlbiAtZGV2ZWwpIGRvZXMgaW5zaXN0IG9uIHVzaW5nIHRtcGZzIGZvciBiaWcgcGFja2Fn ZXMgdGhhdCBpIGxpc3RlZCBpbiBUTVBGU19CTEFDS0xJU1QgbGlzdCBpbiBjb25maWd1cmF0aW9u LCBhbHNvIFRNUEZTX0JMQUNLTElTVF9ESVIgaXMgc2V0LiBJIGFtIHVzaW5nIFpGUy4gSXQgaGFw cGVucyBvbiBhdCBsZWFzdCBsYW5nL3J1c3QgYW5kIGRldmVsL2xsdm0xNS4KClRoYW5rcyBpbiBh ZHZhbmNlLgoKeXVzdWZAaGFsZSB+ICUgbW91bnQgLXYgfCBncmVwIGxsdm0KeXVzdWZAaGFsZSB+ ICUgbW91bnQgLXYgfCBncmVwIHRtcGZzCnRtcGZzIG9uIC9wb3VkcmllcmUvZGF0YS8ubS8xNDJ4 ODYtZGVmYXVsdC9yZWYvLnAgKHRtcGZzLCBsb2NhbCwgdm5vZGVzOiBjb3VudCAzNiApCnRtcGZz IG9uIC9wb3VkcmllcmUvZGF0YS8ubS8xNDJ4ODYtZGVmYXVsdC9yZWYvd3JrZGlycyAodG1wZnMs IGxvY2FsLCB2bm9kZXM6IGNvdW50IDIgKQp0bXBmcyBvbiAvcG91ZHJpZXJlL2RhdGEvLm0vMTQy eDg2LWRlZmF1bHQvcmVmL3Zhci9kYi9wb3J0cyAodG1wZnMsIGxvY2FsLCB2bm9kZXM6IGNvdW50 IDQgKQp0bXBmcyBvbiAvcG91ZHJpZXJlL2RhdGEvLm0vMTQyeDg2LWRlZmF1bHQvMDEvLnAgKHRt cGZzLCBsb2NhbCwgdm5vZGVzOiBjb3VudCA3ICkKdG1wZnMgb24gL3BvdWRyaWVyZS9kYXRhLy5t LzE0Mng4Ni1kZWZhdWx0LzAxL3dya2RpcnMgKHRtcGZzLCBsb2NhbCwgdm5vZGVzOiBjb3VudCAx MzUwMjQgKQp5dXN1ZkBoYWxlIH4gJQoKUXVldWVkOiAxIEluc3BlY3RlZDogMCBJZ25vcmVkOiAw IEJ1aWx0OiAwIEZhaWxlZDogMCBTa2lwcGVkOiAwIEZldGNoZWQ6IDAgUmVtYWluaW5nOiAxCklE IFRPVEFMIE9SSUdJTiBQS0dOQU1FIFBIQVNFIFRJTUUgVE1QRlMgQ1BVJSBNRU0lClswMV0gMDA6 MDQ6MDEgZGV2ZWwvbGx2bTE1QGRlZmF1bHQgfCBsbHZtMTUtMTUuMC43XzEwIGJ1aWxkIDAwOjAz OjAzIDEuNTUgR2lCIDk5LjklIDUl --b1=_xUIzDvucv2kJgeUQ4M0cXJxEhg6wD5bNJHfnCiAFE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCiAgPGhlYWQ+DQoNCiAgICA8bWV0YSBodHRwLWVxdWl2 PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+DQogIDwv aGVhZD4NCiAgPGJvZHk+DQogICAgPHA+cm9vdEBoYWxlOn4gIyBwa2cgaW5mbyAteCBwb3Vkcmll cmU8YnI+DQogICAgICBwb3VkcmllcmUtMy40LjI8YnI+DQogICAgICByb290QGhhbGU6fiAjIHVu YW1lIC1hPGJyPg0KICAgICAgRnJlZUJTRCBoYWxlLmhvbWUuYXJwYSAxNC4yLVJFTEVBU0UtcDEg RnJlZUJTRCAxNC4yLVJFTEVBU0UtcDENCiAgICAgIEdFTkVSSUMgYW1kNjQ8YnI+DQogICAgPC9w Pg0KICAgIDxkaXYgY2xhc3M9Im1vei1mb3J3YXJkLWNvbnRhaW5lciI+PGJyPg0KICAgICAgLS0t LS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCiAgICAgIDx0YWJsZSBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjAiIGJvcmRlcj0iMCINCiAgICAgICAgY2xhc3M9Im1vei1lbWFp bC1oZWFkZXJzLXRhYmxlIj4NCiAgICAgICAgPHRib2R5Pg0KICAgICAgICAgIDx0cj4NCiAgICAg ICAgICAgIDx0aCB2YWxpZ249IkJBU0VMSU5FIiBhbGlnbj0iUklHSFQiIG5vd3JhcD0ibm93cmFw Ij5TdWJqZWN0Og0KICAgICAgICAgICAgPC90aD4NCiAgICAgICAgICAgIDx0ZD5Qb3VkcmllcmUg aW5zaXN0cyBvbiB1c2luZyB0bXBmcyBmb3IgcGFja2FnZXMgbGlzdGVkIGluDQogICAgICAgICAg ICAgIFRNUEZTX0JMQUNLTElTVDwvdGQ+DQogICAgICAgICAgPC90cj4NCiAgICAgICAgICA8dHI+ DQogICAgICAgICAgICA8dGggdmFsaWduPSJCQVNFTElORSIgYWxpZ249IlJJR0hUIiBub3dyYXA9 Im5vd3JhcCI+RGF0ZTogPC90aD4NCiAgICAgICAgICAgIDx0ZD5GcmksIDE0IEZlYiAyMDI1IDIw OjA3OjMzICswMzAwPC90ZD4NCiAgICAgICAgICA8L3RyPg0KICAgICAgICAgIDx0cj4NCiAgICAg ICAgICAgIDx0aCB2YWxpZ249IkJBU0VMSU5FIiBhbGlnbj0iUklHSFQiIG5vd3JhcD0ibm93cmFw Ij5Gcm9tOiA8L3RoPg0KICAgICAgICAgICAgPHRkPll1c3VmIFlhbWFuIDxhIGNsYXNzPSJtb3ot dHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpueGpvc2VwaEBwcm90b25tYWlsLmNvbSI+ Jmx0O254am9zZXBoQHByb3Rvbm1haWwuY29tJmd0OzwvYT48L3RkPg0KICAgICAgICAgIDwvdHI+ DQogICAgICAgICAgPHRyPg0KICAgICAgICAgICAgPHRoIHZhbGlnbj0iQkFTRUxJTkUiIGFsaWdu PSJSSUdIVCIgbm93cmFwPSJub3dyYXAiPlRvOiA8L3RoPg0KICAgICAgICAgICAgPHRkPkZyZWVC U0QgUG9ydHMgTUwgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRv OmZyZWVic2QtcG9ydHNAZnJlZWJzZC5vcmciPiZsdDtmcmVlYnNkLXBvcnRzQGZyZWVic2Qub3Jn Jmd0OzwvYT48L3RkPg0KICAgICAgICAgIDwvdHI+DQogICAgICAgIDwvdGJvZHk+DQogICAgICA8 L3RhYmxlPg0KICAgICAgPGJyPg0KICAgICAgPGJyPg0KICAgICAgSGksPGJyPg0KICAgICAgPGJy Pg0KICAgICAgSSBhbSBoYXZpbmcgYSBwcm9ibGVtIHdoZXJlIFBvdWRyaWVyZSAoZXZlbiAtZGV2 ZWwpIGRvZXMgaW5zaXN0IG9uDQogICAgICB1c2luZyB0bXBmcyBmb3IgYmlnIHBhY2thZ2VzIHRo YXQgaSBsaXN0ZWQgaW4gVE1QRlNfQkxBQ0tMSVNUIGxpc3QNCiAgICAgIGluIGNvbmZpZ3VyYXRp b24sIGFsc28gVE1QRlNfQkxBQ0tMSVNUX0RJUiBpcyBzZXQuIEkgYW0gdXNpbmcgWkZTLg0KICAg ICAgSXQgaGFwcGVucyBvbiBhdCBsZWFzdCBsYW5nL3J1c3QgYW5kIGRldmVsL2xsdm0xNS48YnI+ DQogICAgICA8YnI+DQogICAgICBUaGFua3MgaW4gYWR2YW5jZS48YnI+DQogICAgICA8YnI+DQog ICAgICB5dXN1ZkBoYWxlIH4gJSBtb3VudCAtdiB8IGdyZXAgbGx2bTxicj4NCiAgICAgIHl1c3Vm QGhhbGUgfiAlIG1vdW50IC12IHwgZ3JlcCB0bXBmczxicj4NCiAgICAgIHRtcGZzIG9uIC9wb3Vk cmllcmUvZGF0YS8ubS8xNDJ4ODYtZGVmYXVsdC9yZWYvLnAgKHRtcGZzLCBsb2NhbCwNCiAgICAg IHZub2RlczogY291bnQgMzYgKTxicj4NCiAgICAgIHRtcGZzIG9uIC9wb3VkcmllcmUvZGF0YS8u bS8xNDJ4ODYtZGVmYXVsdC9yZWYvd3JrZGlycyAodG1wZnMsDQogICAgICBsb2NhbCwgdm5vZGVz OiBjb3VudCAyICk8YnI+DQogICAgICB0bXBmcyBvbiAvcG91ZHJpZXJlL2RhdGEvLm0vMTQyeDg2 LWRlZmF1bHQvcmVmL3Zhci9kYi9wb3J0cw0KICAgICAgKHRtcGZzLCBsb2NhbCwgdm5vZGVzOiBj b3VudCA0ICk8YnI+DQogICAgICB0bXBmcyBvbiAvcG91ZHJpZXJlL2RhdGEvLm0vMTQyeDg2LWRl ZmF1bHQvMDEvLnAgKHRtcGZzLCBsb2NhbCwNCiAgICAgIHZub2RlczogY291bnQgNyApPGJyPg0K ICAgICAgdG1wZnMgb24gL3BvdWRyaWVyZS9kYXRhLy5tLzE0Mng4Ni1kZWZhdWx0LzAxL3dya2Rp cnMgKHRtcGZzLA0KICAgICAgbG9jYWwsIHZub2RlczogY291bnQgMTM1MDI0ICk8YnI+DQogICAg ICB5dXN1ZkBoYWxlIH4gJTxicj4NCiAgICAgIDxicj4NCiAgICAgIFF1ZXVlZDogMSBJbnNwZWN0 ZWQ6IDAgSWdub3JlZDogMCBCdWlsdDogMCBGYWlsZWQ6IDAgU2tpcHBlZDogMA0KICAgICAgRmV0 Y2hlZDogMCBSZW1haW5pbmc6IDE8YnI+DQogICAgICDCoElEwqAgVE9UQUzCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIE9SSUdJTsKgwqAgUEtHTkFNRcKgwqDCoMKgwqDCoMKgwqDC oCBQSEFTRQ0KICAgICAgVElNRcKgwqDCoMKgIFRNUEZTwqDCoMKgwqAgQ1BVJSBNRU0lPGJyPg0K ICAgICAgWzAxXSAwMDowNDowMSBkZXZlbC9sbHZtMTVAZGVmYXVsdCB8IGxsdm0xNS0xNS4wLjdf MTAgYnVpbGQNCiAgICAgIDAwOjAzOjAzIDEuNTUgR2lCIDk5LjklwqDCoCA1JTxicj4NCiAgICAg IDxicj4NCiAgICAgIDxicj4NCiAgICA8L2Rpdj4NCiAgPC9ib2R5Pg0KPC9odG1sPg0K --b1=_xUIzDvucv2kJgeUQ4M0cXJxEhg6wD5bNJHfnCiAFE-- From nobody Fri Feb 14 21:35:00 2025 X-Original-To: freebsd-pkg@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 4YvlhR2W0Sz5nhQ9 for ; Fri, 14 Feb 2025 21:35:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YvlhQ34qTz3Yc3 for ; Fri, 14 Feb 2025 21:35:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739568916; bh=+WNE0MQoxYTkspK2GgnPp6KospxAwEBw/WkHHLdGGcI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZcW2zWBb1plMAVJg48Rp0deMer5XV1r/o3aTdjMLcCDm1ALgrPMMjX5rHxL+V7rwr1YiraCbbU4IfuIrQrghX76oXEwe2rjixWMrBWY2hCFg0M1K/afyGmpvfgmz8bWz3mqTngscHvK1R5UlC6mA+WXDBAxiA7UE+ohJ9yUNJG3XueqDjdZ4/nqOHnefoPWsAuMSWoJqlRbuiJpCSmXugWn3Gz1Tz8wliC/iL6MTdS016DSccZYjehN6P/K4ZfmxMdgWc/0sSx5tTbw1YTx0RKeKDZFLpA9Hj2+IJgqoNrh48UqOejA2UcTaux8BMUKz57uhgCcSCuh4h1ZOSoMcJg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739568916; bh=PLy7x6xh7/LGCTlt2fTRAlXJ7Io9C0bvJ4h8z4WSkli=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jyEHSORH7oxsTunp+mR4cgWQFiXgcJNrfw7dKH1PFFxwa3v0gCTzHQug2miK8KBKefuJdYU2Zl+mIW5UZ8ZkBE9yRdt4INcW343VGwy9+QvTSt2MO8qnfNM03xc3zQlj13ED2IWg8DD7IujjVp3sLOlpFCHzAHOJf8v1UfTvjdr0IjooKd7YCOf1JEA/Q0tjVIwaDhog09IAZLZvnGgKoxlbWgDovR7x6GFbdlyi+wQ6dx1e2f4/xDrm0S5vFRK1v14ac0JJoKk9aJ84tTyaI5a2hS95DK5EvtBZVn+WsmUboIJWPE2Hcy3J0WR8CXvEA6Ug2rYiBAb3VNah1HzKdg== X-YMail-OSG: Soa4Vz8VM1mqylUp0s7A7XdPCgk53pcWv8_nMSoGDSw0W.l0IK25sW349vz0bP9 5Dh31ztIgAz_HNOkpqn3W1IkL0yC7TXcQ47ymAsCYIJmAWp96qKjg1o3vZY7eZuuILKQZYm9WgjY oYkj2FTkpLEmKyvmmSr58KQWd8HovqXBWTppe0XKQcoOSZQ0dKLrdPE0c70UWRDk7ooEwf0_zHkn BoJY0Zl77EhYCzz8Oe2tNly72O7qfSnp31s.qoNinvs_8WsT9YoP3t8OU5EWEHQ._J4m3buR.Vvo 74Yetm55CvpYw4CUgkcUbfEdI8OzX6wQZWuktwBzl09fnuX7CAWIKGB3hR2JHkViAKu9igUpfI_U __MzOOlO6ZbuGKfefZaLiGPazHf8WxXEYio4mcs4990W1N1HFg2C0NFiuMkK3RdGGALTplfVAfoc 8GrxBiRAMSsvtzn1SzyXpSyOlEGT2TUrlWVaZ8Vr9lVBaljne1zvVxklXaO3FQMMH2icFYlf2R6m D686qfBYZsdwADPMr4GrvN36fE6WFTUlRiJ7BycbxkPTA6On6k1vSf0kaQBparbif6sGA61QnlsH 2UJ.SJaW_VbtFP8ud19aHnZYzC_FmRQmfzU50hn1Scl4L4SNXQ6GzCEo1g2VvF9CPWVsVePxPTGH 9zTKA2xeANLhR9dxIoJ2C.vSzP.kSiDj1U5X0HMeezGR97Q2PUBeMYQsl3iVMMQuAHlzslvFzcL7 YMORdljKlPsr9To7_uUyy855pedQjl7D.KhAWwiLof885GSreCSbzRkUDoQ5PTnRLe2O5uOogKdn vjaMsDEbTp._C19q83xuQ7aFhxk3CT4Excoa2QKKPC3nh3sxoyaaW97gwRm2zcc3nWrZ6qzCGyd3 63N49yHyM4cP8ew84WlAyJu0ijUtXuiACFW_aEiFXunv_HoCyUqBws1XY.towK.eNi3pnuCOT7u9 v9w5Is.fWvJjECQgGv1LvfLB2d446FU0SzddYFrn2gLCCUMAu03i.cnUNNqbhqVFs54FdwxRATw2 sudUTzQh9Z.3rXaFk2bhrZQTt.8e8bBBqBbFld0icoGYG0QXYQQog5DJx1dYz2jeeXb1JAEJh8VV 1XmMHNMruTGAMMBdti4cVh_2ZsGX5D11yXPQbwwu6VxL9W387zxkWfkkWwG7sTlPFzghkQTKQBf8 74JO.LRHfgPrHRzT4l9MN_r9qYBKTOW6W6NlDA2Sz5S87i1IbOSDHEmayZ55RsKrl_h6ZtG8voGD M2yATtAvLEnEvBilF3tlL0DuNSKBoii6WMY1dIyevJTivJKvGqSJL8iqazOIioaFwofDklvJG2TU 4CirasFB7dDf1ETNkbqbzvSKLRV90tvVcpJKMXZPA9ZtphFkLuWRwIpuE3Sguen4ei9i1SzPbENy _NzTYj1t4WOTxSzZ0AirPi1X7s1DNOAt_TTrxpqEEKqFNfZPUugw9OJBmIrMF0s1Vt.sJipRufX2 k5KK2oXdiVXs4WY57UNA33V8PfVsqOXCH524EFur6Fb0nrLc0qcCIaYcPVloLuxJaOoVjEgQ4svT VzCpXkNUpCdBFH56fpyKg306vyv65FrLpCVKSvfYXEI3VTfqmebkg8H5E1Hy_021pXXQGTQNhCEu vjzX0dDJj1Ljv1nb8FLuSUyvEnYwPHV1U1vYDweRkXPnQL5gZUfEZSo1mGCQXqsKU8yUgrRh7IO2 DL_qL0tGkRbuZlDbBfLeA7it1mxO9MEZW4v60vdvEZaiDEIpKDglB2pI7hmRCexTgc213rnQGm3w W8aQCun3kq9UeOxyGRQfXQGhs.MqdXSorcirjgbZb.U5vHYN5fVB3s_WLAeYHO3AdNjf0pshKZFQ osPvmGgBfNXl2.5PBT9NqvVa8Y8BY6n1SrWOp5N8Isr25qXPMsujdMJ.Dar3SrU8aXpajhpxBeUh m0FrVVk09KyUsn2HlgpdJqcUn0qpv881slcYJ9AetdFuveTgNFFwVv6X28bSi55sh0YttjiGXX4i x7fML_iWBJEVvh6NjYGiiHs.xZM7nmSkRJ5SoL3NWGjD1I2PqTY8.jWVqsZu5Nu_k1lVZNeA0Xyb Amjee_AJQtHvkFAd0MuOhMgOo2i0r_JOo1Tlqg3OHsW96RCqyZh9ZqL7jMEO7H0KlebbacIu3qTN cCIbl24DfxqyjVaSCMD6X8aH4XBWu4pwkdm1sWw0.WA1oMIHjhcquk8JwOHVjVQOJf5Olnjov4fB fGB5_zOqSaLDMH9E2wC4xru.HpAaWBA1fUL98DRaqbHOmOPnPYvK0VlcGWCE5R7hlzt29FiZ9IQJ TVvM- X-Sonic-MF: X-Sonic-ID: ab1b45f6-2686-4564-8cc8-07f75391869f Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Feb 2025 21:35:16 +0000 Received: by hermes--production-gq1-5dd4b47f46-5qmz7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 249a5762f8875e1ffdd38e939cc16b9f; Fri, 14 Feb 2025 21:35:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: Poudriere insists on using tmpfs for packages listed in TMPFS_BLACKLIST From: Mark Millard In-Reply-To: <78cd193e-e60c-4e65-b75b-3848d582fc9d@protonmail.com> Date: Fri, 14 Feb 2025 13:35:00 -0800 Cc: freebsd-pkg@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2e040ffc-f587-40a2-9ad1-9edf80b1862f@protonmail.com> <78cd193e-e60c-4e65-b75b-3848d582fc9d@protonmail.com> To: Yusuf Yaman X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Rspamd-Queue-Id: 4YvlhQ34qTz3Yc3 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Feb 14, 2025, at 12:37, Yusuf Yaman wrote: > root@hale:~ # pkg info -x poudriere > poudriere-3.4.2 > root@hale:~ # uname -a > FreeBSD hale.home.arpa 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC = amd64 >=20 > -------- Forwarded Message -------- Subject: Poudriere insists on = using tmpfs for packages listed in TMPFS_BLACKLIST Date: Fri, 14 Feb = 2025 20:07:33 +0300 From: Yusuf Yaman To: = FreeBSD Ports ML =20 >=20 > Hi, >=20 > I am having a problem where Poudriere (even -devel) does insist on = using tmpfs for big packages that i listed in TMPFS_BLACKLIST list in = configuration, also TMPFS_BLACKLIST_DIR is set. I am using ZFS. It = happens on at least lang/rust and devel/llvm15. The likes of lang/rust and devel/llvm* use large amounts of file system space (compared to, say, just 2 GiBytes) it is the larger areas that are redirected into where you have TMPFS_BLACKLIST_DIR point, avoiding that also being a tmpfs area. These can be like 17+ GiByte, 25+ GiByte, or more for just one builder in the TMPFS_BLACKLIST_DIR area. These can be larger than the RAM that some might have, making having a huge RAM+SWAP be important absent the TMPFS_BLACKLIST entry, especially if multiple such builders happen to run in parallel. (There is also a hook for avoiding any of a list of packages from building in parallel.) TMPFS_BLACKLIST is not intended to eliminate all tmpfs use by a a builder, just what most likely potentially grows to be huge/massive compared to normal: wrkdirs For reference: # grep -r TMPFS_BLACKLIST_TMPDIR /usr/local/share/poudriere/ /usr/local/share/poudriere/common.sh: case = "${TMPFS_BLACKLIST_TMPDIR:+set}" in /usr/local/share/poudriere/common.sh: if [ -d = "${TMPFS_BLACKLIST_TMPDIR:?}/wrkdirs" ] && /usr/local/share/poudriere/common.sh: ! rm -rf = "${TMPFS_BLACKLIST_TMPDIR:?}/wrkdirs/"*; then /usr/local/share/poudriere/common.sh: = "${TMPFS_BLACKLIST_TMPDIR:?}/wrkdirs"/* || : /usr/local/share/poudriere/common.sh: rm -rf = "${TMPFS_BLACKLIST_TMPDIR:?}/wrkdirs"/* || /usr/local/share/poudriere/common.sh: mkdir -p = "${TMPFS_BLACKLIST_TMPDIR:?}/wrkdirs" /usr/local/share/poudriere/common.sh: = TMPDIR=3D"${TMPFS_BLACKLIST_TMPDIR:?}/wrkdirs" \ An example of normal/small is ports-mgmt/portmaster ends up using under 2.5 GiBytes of tmpfs for USE_TMPFS=3Dall . >=20 > Thanks in advance. >=20 > yusuf@hale ~ % mount -v | grep llvm > yusuf@hale ~ % mount -v | grep tmpfs > tmpfs on /poudriere/data/.m/142x86-default/ref/.p (tmpfs, local, = vnodes: count 36 ) > tmpfs on /poudriere/data/.m/142x86-default/ref/wrkdirs (tmpfs, local, = vnodes: count 2 ) > tmpfs on /poudriere/data/.m/142x86-default/ref/var/db/ports (tmpfs, = local, vnodes: count 4 ) > tmpfs on /poudriere/data/.m/142x86-default/01/.p (tmpfs, local, = vnodes: count 7 ) > tmpfs on /poudriere/data/.m/142x86-default/01/wrkdirs (tmpfs, local, = vnodes: count 135024 ) > yusuf@hale ~ % I'll note that the (unused): /poudriere/data/.m/142x86-default/01/wrkdirs=20 is still present when: ${TMPFS_BLACKLIST_TMPDIR:?}/wrkdirs is used instead. The: /poudriere/data/.m/142x86-default/01/wrkdirs is not deleted and recreated for each builder to use slot 01 , just avoided for TMPFS_BLACKLIST usage and emptied before starting a new builder in the slot. > Queued: 1 Inspected: 0 Ignored: 0 Built: 0 Failed: 0 Skipped: 0 = Fetched: 0 Remaining: 1 > ID TOTAL ORIGIN PKGNAME PHASE TIME = TMPFS CPU% MEM% > [01] 00:04:01 devel/llvm15@default | llvm15-15.0.7_10 build 00:03:03 = 1.55 GiB 99.9% 5% 1.55 GiB indicates that the large amount of file system space was not placed in TMPFS. The 1.55 GiB appears to have been in/under: /poudriere/data/.m/142x86-default/01/.p instead. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 14 21:47:19 2025 X-Original-To: freebsd-pkg@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 4YvlyP35zVz5njNM for ; Fri, 14 Feb 2025 21:47:25 +0000 (UTC) (envelope-from nxjoseph@protonmail.com) Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YvlyP0pLGz3hMW for ; Fri, 14 Feb 2025 21:47:25 +0000 (UTC) (envelope-from nxjoseph@protonmail.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739569643; x=1739828843; bh=xDAoJNrSoz2T/tdAIAonODTKDPQSf8WWF8W/5eQw3a4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=qtkY4CvfCv2SI8kSSZ5GbQtQ5ikA9zKAJLAH6ezc+GrFerMhQkaKRlFp/CuCP77SS No3WjiK8A9197qOjoVHCZGbIgqt2Fm3h6ne94bA+9w0ysSFifn3DeodQoSmZM4nA8/ XoTExmfGltg1l6RbkYehQPrFiVC1mLzOSGqpzXXLiSZhdixAYLHl6cFn9PsESrOQlD uuQePxlx6WKT6CNjPWwm9/9qRLGqY1osdR/V9myWfxY3yQwCYeZGyn2mAIjHBuY+LJ Zc8c+b0FbNWBCscoD4nnr1zm5qNjOXYqUVUON7qHVIu941wHivfX3J/aBKENZahxmH yjWSA/HZYJy4w== Date: Fri, 14 Feb 2025 21:47:19 +0000 To: Mark Millard From: Yusuf Yaman Cc: freebsd-pkg@freebsd.org Subject: Re: Poudriere insists on using tmpfs for packages listed in TMPFS_BLACKLIST Message-ID: In-Reply-To: References: <2e040ffc-f587-40a2-9ad1-9edf80b1862f@protonmail.com> <78cd193e-e60c-4e65-b75b-3848d582fc9d@protonmail.com> Feedback-ID: 21989843:user:proton X-Pm-Message-ID: 838d2b12131fc71c3227e531e36a45d8431504f6 List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YvlyP0pLGz3hMW X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] Thanks for explaining, I got it now. Have a good one. On 2/15/25 00:35, Mark Millard wrote: > On Feb 14, 2025, at 12:37, Yusuf Yaman wrote: > >> root@hale:~ # pkg info -x poudriere >> poudriere-3.4.2 >> root@hale:~ # uname -a >> FreeBSD hale.home.arpa 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC a= md64 >> >> -------- Forwarded Message -------- Subject: Poudriere insists on using = tmpfs for packages listed in TMPFS_BLACKLIST Date: Fri, 14 Feb 2025 20:07:3= 3 +0300 From: Yusuf Yaman To: FreeBSD Ports ML >> >> Hi, >> >> I am having a problem where Poudriere (even -devel) does insist on using= tmpfs for big packages that i listed in TMPFS_BLACKLIST list in configurat= ion, also TMPFS_BLACKLIST_DIR is set. I am using ZFS. It happens on at leas= t lang/rust and devel/llvm15. > The likes of lang/rust and devel/llvm* use large amounts of file > system space (compared to, say, just 2 GiBytes) it is the larger > areas that are redirected into where you have TMPFS_BLACKLIST_DIR > point, avoiding that also being a tmpfs area. These can be like > 17+ GiByte, 25+ GiByte, or more for just one builder in the > TMPFS_BLACKLIST_DIR area. These can be larger than the RAM that > some might have, making having a huge RAM+SWAP be important > absent the TMPFS_BLACKLIST entry, especially if multiple such > builders happen to run in parallel. (There is also a hook for > avoiding any of a list of packages from building in parallel.) > > TMPFS_BLACKLIST is not intended to eliminate all tmpfs use by a > a builder, just what most likely potentially grows to be > huge/massive compared to normal: wrkdirs > > For reference: > > # grep -r TMPFS_BLACKLIST_TMPDIR /usr/local/share/poudriere/ > /usr/local/share/poudriere/common.sh: case "${TMPFS_BLACKLIST_TMPDIR:+set= }" in > /usr/local/share/poudriere/common.sh: if [ -d "${TMPFS_BLACKLIST_TMPDIR:?= }/wrkdirs" ] && > /usr/local/share/poudriere/common.sh: ! rm -rf "${TMPFS_BLACKLIST_TMP= DIR:?}/wrkdirs/"*; then > /usr/local/share/poudriere/common.sh: "${TMPFS_BLACKLIST_TMPDIR:?}/wr= kdirs"/* || : > /usr/local/share/poudriere/common.sh: rm -rf "${TMPFS_BLACKLIST_TMPDIR:?}= /wrkdirs"/* || > /usr/local/share/poudriere/common.sh: mkdir -p "${TMPFS_BLACKLIST_TMPDIR:= ?}/wrkdirs" > /usr/local/share/poudriere/common.sh: TMPDIR=3D"${TMPFS_BLACKLIST_TMPDIR:= ?}/wrkdirs" \ > > An example of normal/small is ports-mgmt/portmaster ends up using > under 2.5 GiBytes of tmpfs for USE_TMPFS=3Dall . > >> Thanks in advance. >> >> yusuf@hale ~ % mount -v | grep llvm >> yusuf@hale ~ % mount -v | grep tmpfs >> tmpfs on /poudriere/data/.m/142x86-default/ref/.p (tmpfs, local, vnodes:= count 36 ) >> tmpfs on /poudriere/data/.m/142x86-default/ref/wrkdirs (tmpfs, local, vn= odes: count 2 ) >> tmpfs on /poudriere/data/.m/142x86-default/ref/var/db/ports (tmpfs, loca= l, vnodes: count 4 ) >> tmpfs on /poudriere/data/.m/142x86-default/01/.p (tmpfs, local, vnodes: = count 7 ) >> tmpfs on /poudriere/data/.m/142x86-default/01/wrkdirs (tmpfs, local, vno= des: count 135024 ) >> yusuf@hale ~ % > I'll note that the (unused): > > /poudriere/data/.m/142x86-default/01/wrkdirs > > is still present when: > > ${TMPFS_BLACKLIST_TMPDIR:?}/wrkdirs > > is used instead. The: > > /poudriere/data/.m/142x86-default/01/wrkdirs > > is not deleted and recreated for each builder > to use slot 01 , just avoided for TMPFS_BLACKLIST > usage and emptied before starting a new builder > in the slot. > >> Queued: 1 Inspected: 0 Ignored: 0 Built: 0 Failed: 0 Skipped: 0 Fetched:= 0 Remaining: 1 >> ID TOTAL ORIGIN PKGNAME PHASE TIME TM= PFS CPU% MEM% >> [01] 00:04:01 devel/llvm15@default | llvm15-15.0.7_10 build 00:03:03 1.5= 5 GiB 99.9% 5% > 1.55 GiB indicates that the large amount of file system space was > not placed in TMPFS. The 1.55 GiB appears to have been in/under: > /poudriere/data/.m/142x86-default/01/.p instead. > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > From nobody Sun Feb 16 21:00:32 2025 X-Original-To: pkg@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 4YwyqP4zXKz5nwLk for ; Sun, 16 Feb 2025 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YwyqN6njlz3CZb for ; Sun, 16 Feb 2025 21:00:32 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1739739632; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Bz1VDrVpGc+5l9ezrgFRJiWU0JgS8u1Ta4WZCtLT/Vc=; b=wnG7AAYY42KXbyHm8rk6q9BdSXMfvRHT+XJ2NHRhv+IMjMWM4OEpgpgKsore5877Df5CeJ RMDdZsorZqkLLMrmgqKYqGviMbex7RTA2SXmCeGOrslv/WkMphnNtb690OdahBcstB/EHR Zft1PTBtmbJDQPACc73VRt5HO0RmcfrZjEFLY0r1dejCFEvMm2Bwmlt7i4NZdbIglV8iLX D8UWEKdMwxuLLLAh73+FTHRqFKlDGixiF/RzL5zM9lxmGBNrxBHksPqx/9LuFMtjIiz0cs 0sv+So6OZ7iLMq5BkR8mTE9cZIMfjHh71UukYffHba5xPIhCIk/u5R0UItDRew== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1739739633; a=rsa-sha256; cv=none; b=lSZcROk0xJxobMHhS65YzaUayaL8yBaGl/J9iHVvRrEpzuiIop116u9Xki7IzGPNKuYGnl wl0fJq9MUZG1T2p768HLS9VSo8V1c14XSlMCv3GHAG46+GVDJl28ehUTFhcx9xMW4cH8bj DhxnhIcqxmSthaORwzcv+xxlc/FA7wL4i+v8Jdpfd97vcHsY1uwMlwMo6DJhCBTG5OGSD6 lFxFxfMySD3asABD7mdSReFCAPX9dbcpbT4bMKzfe9w9EoHw3E/V8q5xokrNjF3vHlRF12 +S1eA1Gc2Z/WiRjJ6mgZaQhReXIlAeObqMt6TBv2BPtJJ/pCI6f5JcVY8Vgs6A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1739739633; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Bz1VDrVpGc+5l9ezrgFRJiWU0JgS8u1Ta4WZCtLT/Vc=; b=n1FmvIpmMeMUDErbcn3q6HQ9NGpedZa+YeYERRYVsBExYpxCqo86kd23dsPHX52vLRPBd9 jhN/FoxbdRBHJQhzOSytlbsN8P7l74VVG7EhnT9FNE1KzdgIS37Zmcn+QWZ7ml025gbvmP QO/miBBtn2RCij8LngTUwKh7hnzun21EAwqGGvWNuT/tAk4g4uWsKQtDGAc3cSXgpPz2pB 5Tt9tTxkgVrpD7fiXYr8bmKN7gck5mKI2Gx4oRAXVbybwD0xJLK3b5gtdeGCDaF/mr0MTr wMthjI2QoYbXN+0tatM14SHlzKW1cQXt4MXQmLYTHVCOEBRsTziIcy0K3Rwurg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 4YwyqN6MlWz13Fh for ; Sun, 16 Feb 2025 21:00:32 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 51GL0WaT028765 for ; Sun, 16 Feb 2025 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 51GL0WFL028764 for pkg@FreeBSD.org; Sun, 16 Feb 2025 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202502162100.51GL0WFL028764@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: pkg@FreeBSD.org Subject: Problem reports for pkg@FreeBSD.org that need special attention Date: Sun, 16 Feb 2025 21:00:32 +0000 List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17397396328.dc1C6bbD.25559" Content-Transfer-Encoding: 7bit --17397396328.dc1C6bbD.25559 Date: Sun, 16 Feb 2025 21:00:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 220049 | ports-mgmt/pkg installs unneeded packages Open | 219036 | ports-mgmt/pkg: pkg confused, installs older ver New | 284263 | ports-mgmt/pkg: [1.21.3] --raw-format is broken w Open | 268296 | ports-mgmt/pkg: pip-audit regularly shows vulnera Open | 264962 | ports-mgmt/pkg 1.18.2: 'pkg-static: pkg_checksum_ 5 problems total for which you should take action. --17397396328.dc1C6bbD.25559 Date: Sun, 16 Feb 2025 21:00:32 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    220049 | ports-mgmt/pkg installs unneeded packages
Open        |    219036 | ports-mgmt/pkg:  pkg confused, installs older ver
New         |    284263 | ports-mgmt/pkg: [1.21.3] --raw-format is broken w
Open        |    268296 | ports-mgmt/pkg: pip-audit regularly shows vulnera
Open        |    264962 | ports-mgmt/pkg 1.18.2: 'pkg-static: pkg_checksum_

5 problems total for which you should take action.
--17397396328.dc1C6bbD.25559--