The difference is based on using differently configured
poudriere-jail world builds:
) poudriere-jail world based on WITHOUT_MALLOC_PRODUCTION and
WITH_LLVM_ASSERTIONS for building for main-amd64: 157 Hrs,
building 35456 packages. (An official PkgBase based jail.)
vs.
) poudriere-jail world
[dotnet8 does not have this problem.]
The overall suggestion here is to possibly improve dotnet's
wkrdir-using activity to clean up after itself better,
avoiding leaving processes running that have files under
the jail's /wkrdir/ in use.
Context:
# tail -2
/usr/local/poudriere/data
25-07-29 09:34, Mark Millard wrote:
>>>>> On Jul 26, 2025, at 11:46, Mark Millard wrote:
>>>>>
>>>>>> The other builders in the "bulk -Ca" run till are operating.
>>>>>>
>>>>>> # poudriere versi
6, Mark Millard wrote:
>>>>
>>>>> The other builders in the "bulk -Ca" run till are operating.
>>>>>
>>>>> # poudriere version
>>>>> poudriere-git-3.4.99.20250601
>>>>>
>>>>> Extractio
ders in the "bulk -Ca" run till are operating.
>>>>
>>>> # poudriere version
>>>> poudriere-git-3.4.99.20250601
>>>>
>>>> Extractions of appearently related information follow . . .
>>>>
>>>> # poudriere status -b
&
Naram Qashat wrote on
Date: Tue, 29 Jul 2025 14:14:56 UTC :
> On 2025-07-29 09:34, Mark Millard wrote:
> > On Jul 26, 2025, at 11:46, Mark Millard wrote:
> >
> >> The other builders in the "bulk -Ca" run till are operating.
> >>
> >> #
On 2025-07-29 09:34, Mark Millard wrote:
On Jul 26, 2025, at 11:46, Mark Millard wrote:
The other builders in the "bulk -Ca" run till are operating.
# poudriere version
poudriere-git-3.4.99.20250601
Extractions of appearently related information follow . . .
# poudriere status -b
On Jul 26, 2025, at 11:46, Mark Millard wrote:
> The other builders in the "bulk -Ca" run till are operating.
>
> # poudriere version
> poudriere-git-3.4.99.20250601
>
> Extractions of appearently related information follow . . .
>
> # poudriere status -b
>
I've use a amd64 system with 192 GiBytes of RAM and 512 GiBytes of
SWAP, so 704 GiBytes of RAM+SWAP. 32 FreeBSD cpus. USE_TMPFS=all
with a TMPFS_BLACKLIST . (The other builders that I have access to
have less resources.)
When graphics/sdl2_gpu is built with USE_TMPFS=all on this system,
this syste
The other builders in the "bulk -Ca" run till are operating.
# poudriere version
poudriere-git-3.4.99.20250601
Extractions of appearently related information follow . . .
# poudriere status -b
=>> [main-ZNV4-bulk_a-alt] [2025-07-24_17h17m32s] [parallel_build] Time:
1D:14:
/001345.html
--
Is it the same issue discussed here?
https://github.com/freebsd/poudriere/pull/1228
I don't think so. On this 14-stable system, I first commented out the kmod
lines in /etc/pkg/FreeBSD.conf, then ran pkg update -f, then ran poudriere
with the lines enabling -b in poudriere
On Tue, Jul 8, 2025, at 5:59 AM, void wrote:
> On Mon, Jul 07, 2025 at 11:21:25AM +0100, Nuno Teixeira wrote:
>>Hello,
>>
>>On 14.3R jail poudriere fails to fetch packages (-b latest). I works OK on
>>14.2R and 13.5R.
>>
>>Anyone having same issue?
&
On Mon, Jul 07, 2025 at 11:21:25AM +0100, Nuno Teixeira wrote:
Hello,
On 14.3R jail poudriere fails to fetch packages (-b latest). I works OK on
14.2R and 13.5R.
Anyone having same issue?
Hi,
Yes, in my example 14-stable:
https://lists.freebsd.org/archives/freebsd-pkg/2025-July/001345.html
--
Hello,
Thanks for PR link.
Cheers
Vincent Miller escreveu (segunda, 7/07/2025 à(s)
17:23):
> See https://github.com/freebsd/poudriere/pull/1228 for prospective patch
>
> On Mon, Jul 7, 2025 at 6:21 AM Nuno Teixeira wrote:
>
>> Hello,
>>
>> On 14.3R jail poudrie
See https://github.com/freebsd/poudriere/pull/1228 for prospective patch
On Mon, Jul 7, 2025 at 6:21 AM Nuno Teixeira wrote:
> Hello,
>
> On 14.3R jail poudriere fails to fetch packages (-b latest). I works OK on
> 14.2R and 13.5R.
>
> Anyone having same issue?
>
> `
Hi Nuno,
On 7/7/25 04:21AM, Nuno Teixeira wrote:
Hello,
On 14.3R jail poudriere fails to fetch packages (-b latest). I works
OK on 14.2R and 13.5R.
Anyone having same issue?
```
[00:00:00] Starting jail 143amd64-main
Updating /var/run/os-release done.
[00:00:00] Will build as nobody:nobody
Hello,
On 14.3R jail poudriere fails to fetch packages (-b latest). I works OK on
14.2R and 13.5R.
Anyone having same issue?
```
[00:00:00] Starting jail 143amd64-main
Updating /var/run/os-release done.
[00:00:00] Will build as nobody:nobody (65534:65534)
[00:00:00] Ports supports: FLAVORS
On 4 Jul, Mark Millard wrote:
> Using MAKE_JOBS_UNSAFE=yes avoided:
>
> # grep error:
> /usr/local/poudriere/data/logs/bulk/release-i386-default/2025-07-04_14h42m01s/logs/errors/curl-8.14.1.log
> ld: error: undefined symbol: curl_url
> ld: error: undefined symbol: curl_u
On Jul 4, 2025, at 19:10, Mark Millard wrote:
> My attempt to use poudriere bulk with -i got:
>
> ===
> [00:00:02] Installing packages
> [ZNV4optb_ZFS] Installing pkg-2.2.1...
> [ZNV4optb_ZFS] Extracting pkg-2.2.1: 100%
> [00:
My attempt to use poudriere bulk with -i got:
===
[00:00:02] Installing packages
[ZNV4optb_ZFS] Installing pkg-2.2.1...
[ZNV4optb_ZFS] Extracting pkg-2.2.1: 100%
[00:00:02] Installing run-depends for ports-mgmt/pkg | pkg-2.2.1
[00:00:02] Installing
Using MAKE_JOBS_UNSAFE=yes avoided:
# grep error:
/usr/local/poudriere/data/logs/bulk/release-i386-default/2025-07-04_14h42m01s/logs/errors/curl-8.14.1.log
ld: error: undefined symbol: curl_url
ld: error: undefined symbol: curl_url_set
ld: error: undefined symbol: curl_url_get
ld: error
Hi,
In the meantime the maintainer of the port added a comment to the issue that he
is looking into it.
Regards,
Ronald.
Â
Van: "Einar Bjarni Halldórsson"
Datum: vrijdag, 4 juli 2025 12:06
Aan: ports@freebsd.org
Onderwerp: databases/mongosh fails in poudriere
Hi,
I op
Hello Baptiste,
I've spoted that net/gitup is suffering same issue for at least 2 weeks:
[00:00:35] [01] [00:00:00] Inspecting net/gitup | gitup-1.0: determining
shlib requirements
[00:00:35] [01] [00:00:00] Building net/gitup | gitup-1.0: missed shlib
PORTREVISION chase
Thinking if it is corr
On Jun 7, 2025, at 01:15, Mark Millard wrote:
> On Jun 7, 2025, at 00:03, Dag-Erling Smørgrav wrote:
>
>> Mark Millard writes:
>>> # poudriere jail -c -jrelease-aarch64 -aaarch64 -U
>>> https://pkg.freebsd.org -mpkgbase=base_release_3 -v 14 -X
>>
>>
On Jun 7, 2025, at 00:03, Dag-Erling Smørgrav wrote:
> Mark Millard writes:
>> # poudriere jail -c -jrelease-aarch64 -aaarch64 -U
>> https://pkg.freebsd.org -mpkgbase=base_release_3 -v 14 -X
>
> How do you expect poudriere to interpret `-v 14`?
>
-v 14.3-RELEASE doe
Mark Millard writes:
> # poudriere jail -c -jrelease-aarch64 -aaarch64 -U
> https://pkg.freebsd.org -mpkgbase=base_release_3 -v 14 -X
How do you expect poudriere to interpret `-v 14`?
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Mark Millard writes:
> # poudriere jail -l
> JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP
>PATH
> release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase 2025-06-06 21:19:04
> /usr/local/poudriere/jails/release-aarch64
>
> NOTE: updates withi
Context: FreeBSD main [so: 15] having a 14.*-STABLE poudriere(-devel) jail
being upgraded.
# poudriere jail -l
JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP PATH
official-amd64 14.2-STABLEamd64 pkgbase 2025-05-18 19:37:11
/usr/local/poudriere/jails
On a FreeBSD main [so: 15] system:
# poudriere jail -d -jrelease-aarch64 # Prior 14.2-RELEASE-p* based content
being deleted
# poudriere jail -c -jrelease-aarch64 -aaarch64 -U https://pkg.freebsd.org
-mpkgbase=base_release_3 -v 14 -X
. . .
pkg: Setting ABI requires setting OSVERSION, guessing
Given:
# poudriere jail -l
JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP
PATH
release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase 2025-06-06
21:19:04 /usr/local/poudriere/jails/release-aarch64
NOTE: updates within 14.2-RELEASE-p* did not
poudriere(-devel) is showing:
[06] 03:44:12 graphics/blender | blender-4.2.0_8
build 03:29:40 5.42 GiB
[07] 14:32:22 science/paraview | paraview-5.13.3_1
build 14:05:30 6.53 GiB
But note the lack of [06
[I'll note that my 14.2-RELEASE poudriere jail and 14.2-STABLE
armv7 poudriere jails had no such problems. Nor did any of the
3 aarch64 jails.]
I was unable to do the usual update to my main-armv7 poudriere jail:
# poudriere jail -j main-armv7 -u
[00:00:00] Upgrading using pkgbase
pkg: Se
John W wrote on
Date: Wed, 07 May 2025 23:05:42 UTC :
> . . .
>
> As far as I am able to tell, the behavior I described *is* a bug with that
> port.
The Makefile is correct for poudriere(-devel)
use. ${FLAVOR} in OPTIONS_FILE does expand to
the likes of py311 for that typ
Hello!
> > [sysmirror-default-job-02] Installing libxslt-1.1.42...
> > [sysmirror-default-job-02] `-- Installing libgcrypt-1.11.0...
> > [sysmirror-default-job-02] | `-- Installing libgpg-error-1.54...
> > [sysmirror-default-job-02] | `-- Extracting libgpg-error-1.54: ..
> > done
> >
Hi,
> On 25 Apr 2025, at 13:03, Lev Serebryakov wrote:
>
>
> I'm using poudriere-git-3.4.2 on FreeBSD 13.5-STABLE, and even with port
> tree from last hour (25 of April, 14:00+0200), ports like `devel/py-lxml` and
> `security/vuxml` cannot be built, as `pkg-2.1.2` i
Le 17 avril 2025 16:55:19 GMT+02:00, Mark Millard a écrit :
>On Apr 16, 2025, at 13:24, Mark Millard wrote:
>
>>
>>
>> ===> Installing existing package /packages/All/glib-bootstrap-2.84.1,2.pkg
>> [aarch64PBase] Installing glib-bootstrap-2.84.1,2...
>> [aarch64PBase] `-- Installing libiconv-1
On Apr 16, 2025, at 13:24, Mark Millard wrote:
>
>
> ===> Installing existing package /packages/All/glib-bootstrap-2.84.1,2.pkg
> [aarch64PBase] Installing glib-bootstrap-2.84.1,2...
> [aarch64PBase] `-- Installing libiconv-1.17_1...
> [aarch64PBase] `-- Extracting libiconv-1.17_1: ..
cleaning
all packages... done
. . .
[01:52:51] [release-aarch64-alt] [2025-04-17_12h27m16s] [committing] Time:
01:52:41
Queued: 1252 Inspected: 0 Ignored: 0 Built: 1252 Failed: 0 Skipped:
0 Fetched: 0 Remaining: 0
[01:52:51] Logs:
/usr/local/poudriere/data/logs/bulk/release-aarch64-alt
. done
>> [aarch64PBase] `-- Installing py311-packaging-24.2...
>> [aarch64PBase] `-- Extracting py311-packaging-24.2: .. done
>> [aarch64PBase] `-- Installing glib-bootstrap-2.84.1,2...
>> [aarch64PBase] | `-- Installing glib-bootstrap-2.84.1,2...
>
trap-2.84.1,2...
> [aarch64PBase] | | `-- Installing glib-bootstrap-2.84.1,2...
> . . .
> pkg-static:
> archive_read_open_filename(/packages/All/glib-bootstrap-2.84.1,2.pkg): Failed
> to open '/packages/All/glib-bootstrap-2.84.1,2.pkg'
>
> Failed to install the fol
On Wed 16 Apr 22:39, Baptiste Daroussin wrote:
> On Wed 16 Apr 13:24, Mark Millard wrote:
> >
> >
> > ===> Installing existing package /packages/All/glib-bootstrap-2.84.1,2.pkg
> > [aarch64PBase] Installing glib-bootstrap-2.84.1,2...
> > [aarch64PBase] `-- Installing libiconv-1.17_1...
> > [aar
On Wed 16 Apr 13:24, Mark Millard wrote:
>
>
> ===> Installing existing package /packages/All/glib-bootstrap-2.84.1,2.pkg
> [aarch64PBase] Installing glib-bootstrap-2.84.1,2...
> [aarch64PBase] `-- Installing libiconv-1.17_1...
> [aarch64PBase] `-- Extracting libiconv-1.17_1: .. done
>
===> Installing existing package /packages/All/glib-bootstrap-2.84.1,2.pkg
[aarch64PBase] Installing glib-bootstrap-2.84.1,2...
[aarch64PBase] `-- Installing libiconv-1.17_1...
[aarch64PBase] `-- Extracting libiconv-1.17_1: .. done
[aarch64PBase] `-- Installing libinotify-20240724...
[
ed in /wrkdirs/usr/ports/graphics/blender/work/.build
1 error
make: stopped in /wrkdirs/usr/ports/graphics/blender/work/.build
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
Stop.
make: stopped in /u
An example is the 8711 MiBytes shown in:
# du -xsAm
/usr/local/poudriere/data/.m/main-CA76-bulk_a-default/01/portdistfiles/*
8711
/usr/local/poudriere/data/.m/main-CA76-bulk_a-default/01/portdistfiles/electron
That is a large contribution to the 9891 in:
# df -m | grep ^tmpfs | sort -k6,6
Note the variability in the ARCH columns naming conventions:
# poudriere jail -l
JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP
PATH
release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase 2025-03-12
21:11:39 /usr/local/poudriere/jails/release
12 mars 2025 à 16:01 "Nuno Teixeira" mailto:edua...@freebsd.org?to=%22Nuno%20Teixeira%22%20%3Ceduardo%40freebsd.org%3E
> a écrit:
>
> >
> > This is expected, the nvidia-driver is shipping some 32bit library which are
> > linked to an hypothetical libx11.so.6:32, so either use the same trick as
> This is expected, the nvidia-driver is shipping some 32bit library which
> are
> linked to an hypothetical libx11.so.6:32, so either use the same trick as
> the
> one I use with golang and make pkg ignore this libx11.so.6:32 lib or stop
> shipping a binary which will be anyway unusable because th
(...)
pkg-2.0.6 + poudriere-devel-3.4.99.20250209 + ports main 20250312
poudriere bulk x11/nvidia-driver (default options):
Warning: nvidia-driver-550.127.05.1500034 will be rebuilt as it misses
libX11.so.6:32
In my ports collection of about 800 ports, the above "loop" is the only
On Wed 12 Mar 14:23, Nuno Teixeira wrote:
> (...)
>
> pkg-2.0.6 + poudriere-devel-3.4.99.20250209 + ports main 20250312
>
> poudriere bulk x11/nvidia-driver (default options):
> Warning: nvidia-driver-550.127.05.1500034 will be rebuilt as it misses
> libX11.so.6:32
This is
g for why the builders used notable tmpfs space
>>> even when only one builder was left that was active,
>>> I discovered that, for example, each builder ends up
>>> with its own copy of /usr/local/poudriere/data/.m/*/*/usr/
>>> (and more) that does not end up bein
>> with its own copy of /usr/local/poudriere/data/.m/*/*/usr/
>> (and more) that does not end up being cleared out while
>> the builder is inactive. This looked to be a systematic
>> contribution to the tmpfs usage during times when various
>> builders are inactive.
On Mar 9, 2025, at 01:02, Mark Millard wrote:
> In looking for why the builders used notable tmpfs space
> even when only one builder was left that was active,
> I discovered that, for example, each builder ends up
> with its own copy of /usr/local/poudriere/data/.m/*/*/usr/
>
In looking for why the builders used notable tmpfs space
even when only one builder was left that was active,
I discovered that, for example, each builder ends up
with its own copy of /usr/local/poudriere/data/.m/*/*/usr/
(and more) that does not end up being cleared out while
the builder is
Same with pkg-2.0.99.5 and poudriere-devel-3.4.99.20250209:
> testport 2 times on net/speedtest-go
[00:00:06] [01] [00:00:00] Inspecting ports-mgmt/pkg-devel | pkg-2.0.99.5:
determining shlib requirements
[00:00:06] [01] [00:00:00] Inspecting lang/go121 | go121-1.21.13_1:
determining sh
this to upstream.
Thanks,
Dag-Erling Smørgrav escreveu (quarta, 11/12/2024 à(s)
09:37):
> Nuno Teixeira writes:
> > I'm trying to find why there is no /etc/localtime in poudriere jails
> > and I need to create manually a symlink for some R-cran tests inside
> > inter
On Feb 17, 2025, at 16:47, Mark Millard wrote:
>
> I was doing a experimental poudriere(-devel) bulk -a style run
> with TMPFS_BLACKLIST= use that included specifying electron*
> in the list (and something like 900+ other names or patterns).
> I got an spike in the RAM+SWAP use
I was doing a experimental poudriere(-devel) bulk -a style run
with TMPFS_BLACKLIST= use that included specifying electron*
in the list (and something like 900+ other names or patterns).
I got an spike in the RAM+SWAP used when builders worked on
the 3 electron* (with somewhat under 2700 packages
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
configuration, also TMPFS_BLACKLIST_DIR is set. I am using ZFS. It
happens on at least lang/rust and devel/llvm15.
Thanks in advance.
yusuf@hale
On Thu, Feb 13, 2025 at 5:07 PM Baptiste Daroussin wrote:
>
> 32bit version of libx11 which the ports tree will
> never be able to provide
I just recently added the @i386 flavor for devel/epoll-shim. It might
be arguable if FLAVORS are an appropriate mechanism for this, but
anyways it is pretty s
I tried to start a poudriere(-devel) bulk -ac experiment but got:
[00:00:38] Error: generate_queue_pkg failed to lookup pkgname for
devel/libclc@llvm processing package clover-24.1.7_1 from lang/clover -- Is
SUBDIR+=libclc missing in devel/Makefile? And does the port provide the 'llvm
On Thu 13 Feb 13:55, Nuno Teixeira wrote:
> Maybe we can open a go PR demonstrating this results and a link to
> https://github.com/freebsd/poudriere/pull/1204
>
> Maybe go team understand the problem?
>
> Cheers
No, I do understand the issue, for nvidia-driver, this is the po
Maybe we can open a go PR demonstrating this results and a link to
https://github.com/freebsd/poudriere/pull/1204
Maybe go team understand the problem?
Cheers
Guido Falsi escreveu (quinta, 13/02/2025 à(s) 07:18):
>
>
> On 11/02/25 21:53, Nuno Teixeira wrote:
> > (...)
&g
On 11/02/25 21:53, Nuno Teixeira wrote:
(...)
pkg 2.0.6 doesn't solve issue with go:
testport 2 times on net/speedtest-go
[00:00:03] [01] [00:00:00] Inspecting ports-mgmt/pkg | pkg-2.0.6:
determining shlib requirements
[00:00:03] [01] [00:00:00] Inspecting lang/go121 | go121-1.21.13_1:
de
[I've now tried my UFS context as well.]
On Feb 12, 2025, at 18:24, Mark Millard wrote:
> I use pkg and poudriere-devel in areas that I've chroot'ed into. (This
> may be unusual and so is noted just in case it turns out to be involved.
> I've been doing that for
I use pkg and poudriere-devel in areas that I've chroot'ed into. (This
may be unusual and so is noted just in case it turns out to be involved.
I've been doing that for years. Also, when I tried the same without being
chroot'd things behaved normally and worked fine.)
] [01] [00:00:00] Warning: go121-1.21.13_1 will be rebuilt as it
misses libc.so.6:32
[00:00:03] [01] [00:00:00] Building lang/go121 | go121-1.21.13_1: missed
shlib PORTREVISION chase
Nuno Teixeira escreveu (segunda, 10/02/2025 à(s)
07:59):
>
> poudriere-devel-3.4.99.20250209 main
>>
> poudriere-devel-3.4.99.20250209 main
>
> Using bulk on *existing* repo it loops on both go121 and 123 and also
> nvidia.
> Repeat process and same.
>
> Since that repo was build *without* PKG_NO_VERSION_FOR_DEPS=yes, I cleaned
> (pkgclean -A) it and I'm building
poudriere-devel-3.4.99.20250209 main
Using bulk on *existing* repo it loops on both go121 and 123 and also
nvidia.
Repeat process and same.
Since that repo was build *without* PKG_NO_VERSION_FOR_DEPS=yes, I cleaned
(pkgclean -A) it and I'm building it from scratch at the moment.
When it&#x
unnecessarily lengthy rebuilds I took a look.
I have posted a pull request for poudriere [1] with a fix/workaround that
works for me and allows me to have a functional build machine.
I'm not sure if this fix is completely correct, but maybe it can be useful
to other people as a work around.
[1]
y on the pkg updates.
>>>>>>
>>>>>> Yes it is. I'm CC'ing bapt@.
>>>>>
>>>>> Since this issue was pestering me while testing multiple ports with
>>>>> unnecessarily lengthy rebuilds I took a look.
>&g
n do about my head jail which I build
> from source, and do also use to generate pkgbase packages for my
> desktops/laptop etc.
If I interpret Bapt's notes correctly:
) It is poudriere-devel that needs to be updated to make
PKG_NO_VERSION_FOR_DEPS=yes work with pkg v2.0 (while
st
involved? After all, he has
> worked intensively on the pkg updates.
Yes it is. I'm CC'ing bapt@.
Since this issue was pestering me while testing multiple ports with
unnecessarily lengthy rebuilds I took a look.
I have posted a pull request for poudriere [1] with a fix/workaround
;t this be the right time to get Bapt@ involved? After all, he
> > > > has
> > > > > worked intensively on the pkg updates.
> > > >
> > > > Yes it is. I'm CC'ing bapt@.
> > >
> > > Since this issue was pestering me whi
t; has
> > > > worked intensively on the pkg updates.
> > >
> > > Yes it is. I'm CC'ing bapt@.
> >
> > Since this issue was pestering me while testing multiple ports with
> > unnecessarily lengthy rebuilds I took a look.
> >
&
mv7 (aarch32). So aarch64 might not have this
>>> problem being visible as stands.
>>>
>>> I confirm that aarch64 doesn't have this problem.
>> This suggests the test of trying to use poudriere-devel with
>> PKG_NO_VERSION_FOR_DEPS=yes to build, say, gcc13 with MU
this problem.
This suggests the test of trying to use poudriere-devel with
PKG_NO_VERSION_FOR_DEPS=yes to build, say, gcc13 with MULTILIB
disabled for the target architecture(s) that would otherwise
have it enabled --in order to see if things then work overall,
absent the 32-bit support being
roblem.
This suggests the test of trying to use poudriere-devel with
PKG_NO_VERSION_FOR_DEPS=yes to build, say, gcc13 with MULTILIB
disabled for the target architecture(s) that would otherwise
have it enabled --in order to see if things then work overall,
absent the 32-bit support being b
Hello Mark!
Note: I do not know why, but aarch64 does not get MULTILIB to
> also span armv7 (aarch32). So aarch64 might not have this
> problem being visible as stands.
I confirm that aarch64 doesn't have this problem.
main-n275011-dbedcc169f70
poudriere-devel
PKG_NO_VERSION_FOR_DEP
dn't this be the right time to get Bapt@ involved? After all, he has
> >>> > worked intensively on the pkg updates.
> >>>
> >>> Yes it is. I'm CC'ing bapt@.
> >>
> >> Since this issue was pestering me while testing multip
27;m CC'ing bapt@.
Since this issue was pestering me while testing multiple ports with
unnecessarily lengthy rebuilds I took a look.
I have posted a pull request for poudriere [1] with a fix/workaround that
works for me and allows me to have a functional build machine.
I'm not sure if this
it is. I'm CC'ing bapt@.
>
> Since this issue was pestering me while testing multiple ports with
> unnecessarily lengthy rebuilds I took a look.
>
> I have posted a pull request for poudriere [1] with a fix/workaround that
> works for me and allows me to have a functional
unnecessarily lengthy rebuilds I took a look.
I have posted a pull request for poudriere [1] with a fix/workaround
that works for me and allows me to have a functional build machine.
I'm not sure if this fix is completely correct, but maybe it can be
useful to other people as a
to:
>>>>>
>>>>> https://pkg-status.freebsd.org/ampere1/data/141releng-armv7-quarterly/93a86df99a36/logs/
>>>>>
>>>>> and to the the (here) empty:
>>>>>
>>>>> https://pkg-status.freebsd.org/ampere1/data/141rele
Hello Rainer,
> Wouldn't this be the right time to get Bapt@ involved? After all, he has
> worked intensively on the pkg updates.
Yes it is. I'm CC'ing bapt@.
Resuming on how to reproduce:
--
# cd /usr/src
# make buildworld-jobs buildkernel-jobs
# poudriere jail -c -j 15
Am 26.01.25 um 19:12 schrieb Nuno Teixeira:
I've got same pkg issue like yours.
My case is happening with poudriere builds on llvm19 since I have it
default.
So, every pkg that depends on it, I'll get a rebuild of llvm19.
Later on I will try to bump llvm19 portrevision and thus be
FREEBSD_HOST=https://download.FreeBSD.org
59c59
< USE_TMPFS=yes
---
> USE_TMPFS=no
192c192
< # PARALLEL_JOBS=1
---
> PARALLEL_JOBS=2
226c226
< # ALLOW_MAKE_JOBS=yes
---
> ALLOW_MAKE_JOBS=yes
Cheers,
Nuno Teixeira escreveu (domingo, 26/01/2025 à(s)
21:25):
> I use poudrier
>
> I use poudriere-devel and some time ago, me and other people "complaint"
> about so much rust rebuilds because of curl dependency.
> In that time, we start using poudriere.conf PKG_NO_VERSION_FOR_DEPS=yes to
> avoid that rebuilds.
>
I can confirm t
So something happened since tomorrow that breaks this?
Do you have a fix in mind?
Thanks,
Tatsuki Makino escreveu (domingo, 26/01/2025
à(s) 20:39):
> Hello.
>
> My environment is that :), but I have llvm19 installed, so I will write
> about what I did a little research.
>
> In llvm19, a file t
Hello.
My environment is that :), but I have llvm19 installed, so I will write about
what I did a little research.
In llvm19, a file that seems to have 32-bit libc++ linked.
The command looks like this.
find /usr/local/ -exec sh -c 'readelf -d -- ${1} 2> /dev/null | grep -e
libc++\\.so\\.1' a
I'm building and rebuilding llvm19 since morning... Now I'm feeling less
stressed by knowing that more people get to it.
I use poudriere-devel and some time ago, me and other people "complaint"
about so much rust rebuilds because of curl dependency.
In that time, we start
00:00] Building devel/llvm19@default |
llvm19-19.1.7: missed shlib PORTREVISION chase
Looks like an issue in poudriere shlib checks, but could be induced by
something else.
Unluckily I have no idea how the 32bit library checks work.
--
Guido Falsi
/01/2025 à(s)
18:12):
> I've got same pkg issue like yours.
>
> My case is happening with poudriere builds on llvm19 since I have it
> default.
> So, every pkg that depends on it, I'll get a rebuild of llvm19.
>
> Later on I will try to bump llvm19 portrevision and thu
I've got same pkg issue like yours.
My case is happening with poudriere builds on llvm19 since I have it
default.
So, every pkg that depends on it, I'll get a rebuild of llvm19.
Later on I will try to bump llvm19 portrevision and thus be the hacker of
year is by this it is solved :)
Am 26.01.25 um 16:36 schrieb Nuno Teixeira:
(...)
poudriere-devel-3.4.99.20250115
poudriere.conf:
+ PKG_NO_VERSION_FOR_DEPS=yes
EDIT: pkg 2.0.4 doesn't fixed issue
Hmm. Maybe it's because of pkg, which was recently updated to 2.x?
On my box, outside of Poudriere, I've been
(...)
poudriere-devel-3.4.99.20250115
poudriere.conf:
+ PKG_NO_VERSION_FOR_DEPS=yes
EDIT: pkg 2.0.4 doesn't fixed issue
Nuno Teixeira escreveu (domingo, 26/01/2025 à(s)
15:21):
> Ok, I can reproduce this on a new jail:
>
> # cd /usr/src
> # make buildworld-jobs buildkernel-j
Ok, I can reproduce this on a new jail:
# cd /usr/src
# make buildworld-jobs buildkernel-jobs
# poudriere jail -c -j 15amd64_newjail -m src=/usr/src
# poudriere testport -j 15amd64_newjail -p main games/rocksndiamonds
repeat testport command:
# Warning: llvm19-19.1.7 will be rebuilt as it misses
(...)
Also I delete all pkg in new jail everytime I upgrade:
> # make buildworld-jobs buildkernel-jobs
> # ./tools/build/beinstall.sh
> # reboot
# poudriere pkgclean -A -j 15amd64 -p main
> # poudriere jail -u -j 15amd64
# poudriere bulk -j 15amd64 -p main -f /path/to/list.ports
N
% doas poudriere jail -s -j 15amd64 -p main
% doas jexec 15amd64-main
# ls -l /usr/lib32/libc++.so.1
-r--r--r-- 1 root wheel 957764 Jan 25 23:50 /usr/lib32/libc++.so.1
(My rolled BE is Jan 11 and somehow inside jail is showing Jan 25)
Should I try delete jail and install a new one instead of
Does your jail have /usr/lib32/libc++.so.1?
-Dimitry
> On 26 Jan 2025, at 13:18, Nuno Teixeira wrote:
>
>
> As usual everytime I upgrade:
>
> # make buildworld-jobs buildkernel-jobs
> # ./tools/build/beinstall.sh
> # reboot
>
> # poudriere jail -u -j 15
1 - 100 of 639 matches
Mail list logo
