Re: With poudriere how does one create a jail of a slightly older RELEASE ? [github related notes]

On 2025-05-27 10:09, Mark Millard wrote: > Alastair Hogge wrote on > Date: Mon, 26 May 2025 22:58:38 UTC : > >> . . . >> >> GitHub is another Walled Garden. You need an account to read code on >> it's platform, > > I'm right now using an old iPad with FireFox looking at the > recent upstream er

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On Mon, 26 May 2025 10:14:12 -0400 Dennis Clarke wrote: > On 5/26/25 09:14, Michael Gmelin wrote: > > > > > > On Mon, 26 May 2025 08:25:50 -0400 > > Dennis Clarke wrote: > > > > >> I have no idea what "MFC" is supposed to mean. > >> I guess it is a code change that happened somewhere. >

Re: With poudriere how does one create a jail of a slightly older RELEASE ? [github related notes]

On 2025-05-26 19:09, Mark Millard wrote: Alastair Hogge wrote on Date: Mon, 26 May 2025 22:58:38 UTC : . . . GitHub is another Walled Garden. You need an account to read code on it's platform, I'm right now using an old iPad with FireFox looking at the recent upstream error about fopen("tmp

Re: With poudriere how does one create a jail of a slightly older RELEASE ? [github related notes]

Alastair Hogge wrote on Date: Mon, 26 May 2025 22:58:38 UTC : > . . . > > GitHub is another Walled Garden. You need an account to read code on > it's platform, I'm right now using an old iPad with FireFox looking at the recent upstream error about fopen("tmp/pkg_add_cache","w") still being in u

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On Mon, May 26, 2025 at 7:36 AM Warner Losh wrote: > > On Mon, May 26, 2025 at 8:14 AM Dennis Clarke wrote: > > > > On 5/26/25 09:14, Michael Gmelin wrote: > > > > > > > > > On Mon, 26 May 2025 08:25:50 -0400 > > > Dennis Clarke wrote: > > > > > > > >> I have no idea what "MFC" is supposed to me

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On 2025-05-27 00:17, Tomoaki AOKI wrote: > On Mon, 26 May 2025 08:36:05 -0600 > Warner Losh wrote: > >> On Mon, May 26, 2025 at 8:14 AM Dennis Clarke wrote: >> > >> > On 5/26/25 09:14, Michael Gmelin wrote: >> > > >> > > >> > > On Mon, 26 May 2025 08:25:50 -0400 >> > > Dennis Clarke wrote: >> >

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On Mon, 26 May 2025 08:36:05 -0600 Warner Losh wrote: > On Mon, May 26, 2025 at 8:14 AM Dennis Clarke wrote: > > > > On 5/26/25 09:14, Michael Gmelin wrote: > > > > > > > > > On Mon, 26 May 2025 08:25:50 -0400 > > > Dennis Clarke wrote: > > > > > > > >> I have no idea what "MFC" is supposed to

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

[I managed to not send the original to the list.] On May 26, 2025, at 07:14, Mark Millard wrote: > > Dennis Clarke wrote on > Date: Mon, 26 May 2025 12:25:50 UTC : > >> On 5/24/25 21:47, Mark Millard wrote: >>> Dennis Clarke wrote on >>> Date: Sat, 24 May 2025 22:46:18 UTC : >>> wow ...

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On 5/26/25 10:48, Mark Millard wrote: [I managed to not send the original to the list.] On May 26, 2025, at 07:14, Mark Millard wrote: Dennis Clarke wrote on Date: Mon, 26 May 2025 12:25:50 UTC : On 5/24/25 21:47, Mark Millard wrote: Dennis Clarke wrote on Date: Sat, 24 May 2025 22:46:18

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On Mon, May 26, 2025 at 8:14 AM Dennis Clarke wrote: > > On 5/26/25 09:14, Michael Gmelin wrote: > > > > > > On Mon, 26 May 2025 08:25:50 -0400 > > Dennis Clarke wrote: > > > > >> I have no idea what "MFC" is supposed to mean. > >> I guess it is a code change that happened somewhere. > >> > > > >

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On 5/26/25 09:14, Michael Gmelin wrote: On Mon, 26 May 2025 08:25:50 -0400 Dennis Clarke wrote: I have no idea what "MFC" is supposed to mean. I guess it is a code change that happened somewhere. Merge From Current = Merging or back-porting a base commit from CURRENT (main/base/HEAD) to

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On 5/24/25 21:47, Mark Millard wrote: > Dennis Clarke wrote on > Date: Sat, 24 May 2025 22:46:18 UTC : > >> wow ... archive ? Well why not and yes I will give that a whirl. >> >> Still doesn't clear up why I can not build from source but that is a >> whole other matter. > > MFC's do not go back t

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On Mon, 26 May 2025 08:25:50 -0400 Dennis Clarke wrote: > On 5/24/25 21:47, Mark Millard wrote: > > Dennis Clarke wrote on > > Date: Sat, 24 May 2025 22:46:18 UTC : > > > >> wow ... archive ? Well why not and yes I will give that a whirl. > >> > >> Still doesn't clear up why I can not

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On Sat, 24 May 2025 18:46:18 -0400 Dennis Clarke wrote: > On 5/24/25 18:40, Michael Gmelin wrote: > > > > >> That makes perfect sense. > >> > > > > This works: > > > > poudriere jail -c -j 132amd64 -v 13.2-RELEASE \ > &

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

in circa 2020 for *some reason*). To be able to deploy a clean version of a critical piece of software, I maintained our own poudriere farm, just in case. To cover my butt in all edge cases (and just for retrocomputing fun, to be able to pull up systems to see when things had changed or how far b

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

Dennis Clarke wrote on Date: Sat, 24 May 2025 22:46:18 UTC : > On 5/24/25 18:40, Michael Gmelin wrote: > > > > >> That makes perfect sense. > >> > > > > This works: > > > > poudriere jail -c -j 132amd64 -v 13.2-RELEASE \ > > -m url

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On 5/24/25 18:40, Michael Gmelin wrote: That makes perfect sense. This works: poudriere jail -c -j 132amd64 -v 13.2-RELEASE \ -m url=https://archive.freebsd.org/old-releases/amd64/13.2-RELEASE/ Cheers Michael wow ... archive ? Well why not and yes I will give that a whirl

Re: With poudriere how does one create a jail of a slightly older RELEASE ?

On Sat, 24 May 2025 17:37:06 -0400 Dennis Clarke wrote: > This may seem trivial but trying to create a jail for a release > from just a few years ago is not working well : > > t# poudriere jails -c -a amd64 -j 132amd64 -v 13.2-RELEASE > [00:00:00] Creating 132amd64 fs at >

Re: Is there a way to tell poudriere to allocate more memory to a pkg build?

Hello, On Fri, 23 May 2025, at 18:45, Dennis Clarke wrote: > I have been watching qt6-webengine-6.8.3 fail over and over and over > for some days now and it takes with it a pile of other stuff. I'm using a dual xenon @3GHz with 512GB ram for amd64 poudriere builds. This has hyperthrea

Re: Is there a way to tell poudriere to allocate more memory to a pkg build?

> PARALLEL_JOBS=3 # this appears to help avoid conflicts, and gives > appreciable speedups. > ALLOW_MAKE_JOBS=yes > MAX_FILES=8192 > > MUTUALLY_EXCLUSIVE_BUILD_PACKAGES="irid* llvm* rust* gcc* electr* > libre* firef* npm* node* nerd* qt* ghc webkit*" # this also helps avoid > conflicts > > TMPFS

Re: Is there a way to tell poudriere to allocate more memory to a pkg build?

do nothing at all. For now. > > We ( myself and others ) have already found that the problem was > me. No big surprise. > > USE_TMPFS=yes > TMPFS_LIMIT=32 > MAX_MEMORY=32 > # MAX_FILES=1024 > MAX_EXECUTION_TIME=172800 > PARALLEL_JOBS=64 > PREPARE_PARALLEL_JOBS=

Re: Is there a way to tell poudriere to allocate more memory to a pkg build?

2 MAX_MEMORY=32 # MAX_FILES=1024 MAX_EXECUTION_TIME=172800 PARALLEL_JOBS=64 PREPARE_PARALLEL_JOBS=64 That was the problem in the poudriere config. I commented out the MAX_MEMORY and TMPFS_LIMIT and then watched as www/qt6-webengine built just fine. Guess the jail needed more than 32G eh? I assume th

RE: Is there a way to tell poudriere to allocate more memory to a pkg build?

Dennis Clarke wrote on Date: Fri, 23 May 2025 17:45:17 UTC : > I have been watching qt6-webengine-6.8.3 fail over and over and over > for some days now and it takes with it a pile of other stuff. > > In the log I see this unscripted trash of a message : > > [00:05:03] FAILED: v8_context_snapsho

poudriere-devel based "bulk -a" has stuck builder slot because of "umount: unmount of . . ./01/wrkdirs failed: Device busy"

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

Re: Creating poudriere jail fails with libmd.so.6 not found

El día lunes, marzo 03, 2025 a las 12:06:41p. m. +0100, Robert Clausecker escribió: > The simplest solution is to clear the object directory and do a fresh world > build. > libmd.so.6 was turned into libmd.so.7 as part of a recent API change. It > should > also work to link libmd.so.7 to libmd

Re: Creating poudriere jail fails with libmd.so.6 not found

Robert Clausecker Date: Mon, 03 Mar 2025 11:06:41 UTC Hi Matthias, > Am Mon, Mar 03, 2025 at 08:05:04AM +0100 schrieb Matthias Apitz: > > I tried to create a new jail in my CURRENT from March 1 > > This fails with: > > > > # poudriere jail -c -j 150-CURRENT -m src=

Re: Creating poudriere jail fails with libmd.so.6 not found

Hi Matthias, Am Mon, Mar 03, 2025 at 08:05:04AM +0100 schrieb Matthias Apitz: > I tried to create a new jail in my CURRENT from March 1 > This fails with: > > # poudriere jail -c -j 150-CURRENT -m src=/usr/src > > [00:00:00] Creating 150-CURRENT fs at > /usr/local/poudri

Creating poudriere jail fails with libmd.so.6 not found

I tried to create a new jail in my CURRENT from March 1 This fails with: # poudriere jail -c -j 150-CURRENT -m src=/usr/src [00:00:00] Creating 150-CURRENT fs at /usr/local/poudriere/jails/150-CURRENT... done [00:00:01] Copying /usr/src to /usr/local/poudriere/jails/150-CURRENT/usr/src... done

Re: Fairly Modern poudriere-devel on fairly modern main gets "mount_nullfs: /usr/local/poudriere/data/.m/NAME/ref/packages: Resource deadlock avoided" when operated in a chroot context.

[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

Fairly Modern poudriere-devel on fairly modern main gets "mount_nullfs: /usr/local/poudriere/data/.m/NAME/ref/packages: Resource deadlock avoided" when operated in a chroot context.

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.)

Re: poudriere and the user ... is it mostly a lost idea?

Paul Mather wrote on Date: Fri, 17 Jan 2025 19:35:32 UTC : On Jan 17, 2025, at 1:30 pm, Dennis Clarke wrote: > I have plenty of logs. Piles of them. Perhaps the problem is that I > am building on a 15-CURRENT machine which has poudriere jails like so : > > titan# poudri

Re: poudriere and the user ... is it mostly a lost idea?

if I notice any patterns to the failures. (If anyone one else would look, I've no idea.) No time frame promises. Another question is if you have also been getting console log notices, such as OOM kills and the like. Logs from inside builders may be necessary context but not sufficient cont

Re: poudriere and the user ... is it mostly a lost idea?

On Jan 17, 2025, at 1:30 pm, Dennis Clarke wrote: >I have plenty of logs. Piles of them. Perhaps the problem is that I > am building on a 15-CURRENT machine which has poudriere jails like so : > > titan# poudriere jails -l > JAILNAME VERSION

Re: poudriere and the user ... is it mostly a lost idea?

am building on a 15-CURRENT machine which has poudriere jails like so : titan# poudriere jails -l JAILNAME VERSION ARCH METHOD TIMESTAMP PATH 134amd64 13.4-RELEASE-p2 1304000 3f40d5821eca amd64 git+https 2025-01-10 10:42:08 /poudriere/jails/134a

RE: poudriere and the user ... is it mostly a lost idea?

Dennis Clarke wrote on Date: Wed, 15 Jan 2025 15:16:58 UTC : > Over the past month or so I see endless fails in builds for the big > three user facing window manager things. This means that a simple user > type person can not get a desktop. Really? Yes really. For at least a > month or more you c

Re: poudriere and the user ... is it mostly a lost idea?

such reports in the mailing list archives > (https://lists.freebsd.org/archives/freebsd-xfce/). You can even view the > results of the project’s package build system (which also uses poudriere) by > following the instructions here: > https://people.freebsd.org/~grahamperrin/pkg-status/ >

Re: poudriere and the user ... is it mostly a lost idea?

t use whatever packages are being provided by some > magic server somewhere in a fluffy cloud with coloured unicorns that > dance on the rainbows. > > >Failed: ?? > >Poudriere lately always says fail. > >Every day. > > > Every time. F

Re: poudriere and the user ... is it mostly a lost idea?

On 1/15/25 11:14, Gleb Popov wrote: On Wed, Jan 15, 2025 at 6:17 PM Dennis Clarke wrote: The whole desktop user experience is broken and has been for a long time. I have the logs. I see the fails. Over and over. It is the usual boring process. If something's not working for you - creat

Re: poudriere and the user ... is it mostly a lost idea?

On Wed, Jan 15, 2025 at 6:17 PM Dennis Clarke wrote: > > The whole desktop user experience is broken and has been for a long > time. I have the logs. I see the fails. Over and over. It is the usual boring process. If something's not working for you - create a Bugzilla issue, share your logs.

poudriere and the user ... is it mostly a lost idea?

cloud with coloured unicorns that dance on the rainbows. Failed: ?? Poudriere lately always says fail. Every day. Every time. For the last month or more and I suspect more if I drag the logs out. I do not want to do that. I just am curious and perhaps misled with a silly

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

"Sean C. Farley" writes: > I ran all of the tmpfs*.sh tests from HEAD which all pass except for > tmpfs24.sh. > > $ ./all.sh -o tmpfs24.sh > 20241128 22:33:38 all: tmpfs24.sh > Min hole size is 4096, file size is 524288000. > data #1 @ 0, size=4096) > hole #2 @ 4096, size=4096 > data #3 @ 8192, si

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On Thu, 28 Nov 2024, Mark Millard wrote: On Nov 28, 2024, at 19:54, Sean C. Farley wrote: On Thu, 28 Nov 2024, Mark Millard wrote: . . . System setup: - FreeBSD 14.2-STABLE The context that I investigated --and what was fixed by a commit only applies to-- main [so; 15 as stands], not s

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On 26/11/24 18:29, Doug Moore wrote: I think @kib has found the source of the problem.  I've attached an attempt to fix it. Thanks for your work! I have noticed this is already in base and upgraded successfully, issue is now solved for me. Sorry for the delay in reporting this. -- Guido Fa

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On Nov 28, 2024, at 19:54, Sean C. Farley wrote: > On Thu, 28 Nov 2024, Mark Millard wrote: > >> . . . > >>> System setup: >>> - FreeBSD 14.2-STABLE >> >> The context that I investigated --and what was fixed by a commit only >> applies to-- main [so; 15 as stands], not stable/14 . >> >> stabl

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

context . . . For folks new to the discoveries: the context here is poudriere bulk builds, for USE_TMPFS=all vs. USE_TMPFS=no . My test context is amd64 on a 7950X3D system with 192 GiBytes of RAM. Others have other contexts, including an Intel system. *snip* System setup: - FreeBSD 14.2

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

trol the behavior in my > >> context . . . > > > > For folks new to the discoveries: the context here > > is poudriere bulk builds, for USE_TMPFS=all vs. > > USE_TMPFS=no . My test context is amd64 on a > > 7950X3D system with 192 GiBytes of RAM. Others have > > oth

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On Mon, 25 Nov 2024, Mark Millard wrote: On Nov 25, 2024, at 18:05, Mark Millard wrote: Top posting going in a different direction that established a way to control the behavior in my context . . . For folks new to the discoveries: the context here is poudriere bulk builds, for USE_TMPFS

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On Nov 28, 2024, at 04:19, Andriy Gapon wrote: > On 28/11/2024 13:42, Dag-Erling Smørgrav wrote: >> Andriy Gapon writes: >>> FWIW, I am not sure if it's relevant but I am seeing a similar pattern >>> of corruption on tmpfs although in a different context, on FreeBSD >>> 13.3. >> Not relevant at

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On 28/11/2024 13:42, Dag-Erling Smørgrav wrote: Andriy Gapon writes: FWIW, I am not sure if it's relevant but I am seeing a similar pattern of corruption on tmpfs although in a different context, on FreeBSD 13.3. Not relevant at all. In this case the file is not actually corrupted but `insta

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

Andriy Gapon writes: > FWIW, I am not sure if it's relevant but I am seeing a similar pattern > of corruption on tmpfs although in a different context, on FreeBSD > 13.3. Not relevant at all. In this case the file is not actually corrupted but `install(1)` skips over some of it when copying beca

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On 26/11/2024 17:52, Mark Millard wrote: libsass.so.1.0.0 still has .got.plt starting with (this time): 2bed60 2bed70 2bed80 2

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

I've been running and rebooted into: >> >> # uname -apKU >> FreeBSD 7950X3D-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #152 >> main-n273696-43e045c1733d-dirty: Tue Nov 26 07:21:27 PST 2024 >> root@7950X3D-ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

1 Annotations: FreeBSD_version: 1500027 build_timestamp: 2024-11-26T15:32:33+ built_by : poudriere-git-3.4.99.20240811 . . . libsass.so.1.0.0 still has .got.plt starting with (this time): 2bed60 2bed70 000

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

om 2024-Nov-18 . I then built libsass : [00:00:02] [01] [00:00:00] Building textproc/libsass | libsass-3.6.6 [00:00:20] [01] [00:00:18] Finished textproc/libsass | libsass-3.6.6: Success ending TMPFS: 3.42 GiB I then installed it, resulting in: # pkg info libsass libsass-3.6.6 Name

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On Tue, Nov 26, 2024 at 01:58:19PM +0100, Dimitry Andric wrote: > On 26 Nov 2024, at 13:32, Dimitry Andric wrote: > > > > On 26 Nov 2024, at 11:19, Dag-Erling Smørgrav wrote: > >> > >> Mark Millard writes: > >>> From inside a bulk -i where I did a manual make command > >>> after it built and i

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On Nov 26, 2024, at 04:58, Dimitry Andric wrote: > On 26 Nov 2024, at 13:32, Dimitry Andric wrote: >> >> On 26 Nov 2024, at 11:19, Dag-Erling Smørgrav wrote: >>> >>> Mark Millard writes: From inside a bulk -i where I did a manual make command after it built and installed libsass

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On 26 Nov 2024, at 13:32, Dimitry Andric wrote: > > On 26 Nov 2024, at 11:19, Dag-Erling Smørgrav wrote: >> >> Mark Millard writes: >>> From inside a bulk -i where I did a manual make command >>> after it built and installed libsass.so.1.0.0 . The >>> manual make produced a /wrkdirs/ : >>> [..

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On 26 Nov 2024, at 11:19, Dag-Erling Smørgrav wrote: > > Mark Millard writes: >> From inside a bulk -i where I did a manual make command >> after it built and installed libsass.so.1.0.0 . The >> manual make produced a /wrkdirs/ : >> [...] >> So the original creation looks okay. But . . . >> [...

Re: port binary dumping core on recent head in poudriere

W dniu 26.11.2024 o 08:59, Guido Falsi pisze: On 26/11/24 03:05, Mark Millard wrote: Top posting going in a different direction that established a way to control the behavior in my context . . . I changed USE_TMPFS=all to USE_TMPFS=no : USE_TMPFS=all gets the failure vs. USE_TMPFS=no works ju

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

Mark Millard writes: > From inside a bulk -i where I did a manual make command > after it built and installed libsass.so.1.0.0 . The > manual make produced a /wrkdirs/ : > [...] > So the original creation looks okay. But . . . > [...] > So: The later, staged copy is a bad copy. Both are in the > t

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On Nov 25, 2024, at 22:10, Mark Millard wrote: > On Nov 25, 2024, at 18:05, Mark Millard wrote: > >> Top posting going in a different direction that >> established a way to control the behavior in my >> context . . . > > For folks new to the discoveries: the co

Re: port binary dumping core on recent head in poudriere

On 26/11/24 03:05, Mark Millard wrote: Top posting going in a different direction that established a way to control the behavior in my context . . . I changed USE_TMPFS=all to USE_TMPFS=no : USE_TMPFS=all gets the failure vs. USE_TMPFS=no works just fine So it is a FreeBSD system error associa

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On Nov 25, 2024, at 18:05, Mark Millard wrote: > Top posting going in a different direction that > established a way to control the behavior in my > context . . . For folks new to the discoveries: the context here is poudriere bulk builds, for USE_TMPFS=all vs. USE_TMPFS=no . My test c

Re: port binary dumping core on recent head in poudriere

r used ccache or analogous and get the libsass.so.1.0.0 >>>>>>>> .got.plt corruption that I've reported on the lists anyway. >>>>>>> I don't use ccache or optimizations. Here's an example of sassc >>>>>>> segfaulting

Re: port binary dumping core on recent head in poudriere

>>>>> I'm also using ccache, but that does not look relevant. >>>>>>> I've never used ccache or analogous and get the libsass.so.1.0.0 >>>>>>> .got.plt corruption that I've reported on the lists anyway. >>>>>> I don&#x

Re: port binary dumping core on recent head in poudriere

From: Dimitry Andric Subject: Re: port binary dumping core on recent head in poudriere Date: Mon, 25 Nov 2024 23:15:20 +0100 > On 25 Nov 2024, at 23:12, Mark Millard wrote: >> >> On Nov 25, 2024, at 13:27, Guido Falsi wrote: >> >>> On 25/11/24 22:18, Dag-Er

Re: port binary dumping core on recent head in poudriere

e or analogous and get the libsass.so.1.0.0 >>>>>> .got.plt corruption that I've reported on the lists anyway. >>>>> I don't use ccache or optimizations. Here's an example of sassc >>>>> segfaulting in a 14.1-RELEASE-p6 jail: >>&

Re: port binary dumping core on recent head in poudriere

xited on signal 11 (core dumped) The poudriere host is a bhyve VM with 48 cores and 192 GB RAM on a 32c/64t AMD EPYC 7502P with 256 GB RAM. I sincerely hope this is not relevant but my CPU is also AMD: AMD Ryzen 5 5600G The amd64 system type that I have access to and used for my testing: AMD 79

Re: port binary dumping core on recent head in poudriere

lting in a 14.1-RELEASE-p6 jail: >>> >>> https://pkg.des.dev/logs/data/14amd64-default/2024-11-24_19h29m04s/logs/errors/plasma5-breeze-gtk-5.27.11.log >>> which matches the following entry from `/var/log/messages`: >>> Nov 24 21:23:06 pkg kernel: pid 71277

Re: port binary dumping core on recent head in poudriere

logs/errors/plasma5-breeze-gtk-5.27.11.log >> which matches the following entry from `/var/log/messages`: >> Nov 24 21:23:06 pkg kernel: pid 71277 (sassc), jid 253, uid 65534: exited >> on signal 11 (core dumped) >> The poudriere host is a bhyve VM with 48 cores and 192 GB RAM

Re: port binary dumping core on recent head in poudriere

errors/plasma5-breeze-gtk-5.27.11.log which matches the following entry from `/var/log/messages`: Nov 24 21:23:06 pkg kernel: pid 71277 (sassc), jid 253, uid 65534: exited on signal 11 (core dumped) The poudriere host is a bhyve VM with 48 cores and 192 GB RAM on a 32c/64t AMD EPYC 7502P with 256 G

Re: port binary dumping core on recent head in poudriere

/pkg.des.dev/logs/data/14amd64-default/2024-11-24_19h29m04s/logs/errors/plasma5-breeze-gtk-5.27.11.log which matches the following entry from `/var/log/messages`: Nov 24 21:23:06 pkg kernel: pid 71277 (sassc), jid 253, uid 65534: exited on signal 11 (core dumped) The poudriere host is a bhyve

Re: port binary dumping core on recent head in poudriere

gh. > > I'm not sure I can provide a strict procedure to reproduce this, except > suggesting building in poudriere, with a recent head both in host and in the > jails. > > I'm also using ccache, but that does not look relevant. FYI: I've never used ccache or

Re: port binary dumping core on recent head in poudriere

everything is working for me in 14.1. BTW removing optimizations (CPUTYPE) for only the affected ports made guile2 work again. Did not solve the issue with sassc though. I'm not sure I can provide a strict procedure to reproduce this, except suggesting building in poudriere, with a recent

Re: port binary dumping core on recent head in poudriere

0 main-645f8bcba9c: Mon Nov 18 17:39:08 UTC 2024 r...@pkg.des.dev:/usr/obj/poudriere/jails/15amd64/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 % poudriere jail -l JAILNAME VERSION ARCH METHODTIMESTAMP PATH 1

Re: port binary dumping core on recent head in poudriere

On Nov 24, 2024, at 14:59, Mark Millard wrote: > Dimitry Andric wrote on > Date: Sun, 24 Nov 2024 17:18:51 UTC : > >> On 24 Nov 2024, at 18:07, Guido Falsi wrote: >>> >>> . . . >> >> Probably best to create a bugzilla ticket, but as I said before, I cannot >> reproduce this. So you would ha

Re: port binary dumping core on recent head in poudriere

Dimitry Andric wrote on Date: Sun, 24 Nov 2024 17:18:51 UTC : > On 24 Nov 2024, at 18:07, Guido Falsi wrote: > > > > . . . > > Probably best to create a bugzilla ticket, but as I said before, I cannot > reproduce this. So you would have to come up with some scenario on why it is > reproducib

Re: port binary dumping core on recent head in poudriere

: On 20/11/24 23:50, Guido Falsi wrote: On 20/11/24 22:14, Dimitry Andric wrote: On 20 Nov 2024, at 18:32, Guido Falsi wrote: I've noticed that recently some ports are dumping core during builds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing while

Re: port binary dumping core on recent head in poudriere

, Guido Falsi wrote: >>>>>> >>>>>> On 20/11/24 23:50, Guido Falsi wrote: >>>>>>> On 20/11/24 22:14, Dimitry Andric wrote: >>>>>>>> On 20 Nov 2024, at 18:32, Guido Falsi wrote: >>>>>>>>> I&

Re: port binary dumping core on recent head in poudriere

2024, at 18:32, Guido Falsi wrote: I've noticed that recently some ports are dumping core during builds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing while trying to build x11-themes/greybird-theme. My first suspect was the llvm upgrade in

Re: port binary dumping core on recent head in poudriere [WRONG: 1500026 libsass.so.1.0.0 vs. 1500027 one]

I finally looked in a better place for finding a significant difference: The good /usr/local/lib/libsass.so.1.0.0 in my context (the one in the PkgBase based chroot area) has: Contents of section .got.plt: 2bed60 78ba2b00 x.+. 2bed70 86a

Re: port binary dumping core on recent head in poudriere

: I've noticed that recently some ports are dumping core during builds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing while trying to build x11-themes/greybird-theme. My first suspect was the llvm upgrade in head, but forcing sassc and libsass to

Re: port binary dumping core on recent head in poudriere

s are dumping core during builds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing while trying to build x11-themes/greybird-theme. My first suspect was the llvm upgrade in head, but forcing sassc and libsass to build with older clang via USES=llvm:max

Re: port binary dumping core on recent head in poudriere [WRONG: 1500026 libsass.so.1.0.0 vs. 1500027 one]

> On Nov 21, 2024, at 13:15, Mark Millard wrote: > > Summary: > > Turns out in my context: libsass.so <http://libsass.so/>.1.0.0 built for > 1500026 fails and built for 1500027 works, at least > when used via a 1500027 world. So much for that idea: updating the p

Re: port binary dumping core on recent head in poudriere [1500026 libsass.so.1.0.0 vs. 1500027 one]

Summary: Turns out in my context: libsass.so .1.0.0 built for 1500026 fails and built for 1500027 works, at least when used via a 1500027 world. # file /usr/local/lib/libsass.so.1.0.0* /usr/local/lib/libsass.so.1.0.0: ELF 64-bit LSB shared object, x86-64, versio

Re: port binary dumping core on recent head in poudriere

ds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing while trying to build x11-themes/greybird-theme. My first suspect was the llvm upgrade in head, but forcing sassc and libsass to build with older clang via USES=llvm:max=18 is not helping. I did recompile the

Re: port binary dumping core on recent head in poudriere

t; >>>> I've noticed that recently some ports are dumping core during builds of > >>>> dependencies in head in poudriere. > >>>> > >>>> I'm seeing this for example with sassc crashing while trying to build > >>>> x11-t

Re: port binary dumping core on recent head in poudriere

uilds of >>>> dependencies in head in poudriere. >>>> >>>> I'm seeing this for example with sassc crashing while trying to build >>>> x11-themes/greybird-theme. >>>> >>>> My first suspect was the llvm upgrade in head, but forcin

Re: port binary dumping core on recent head in poudriere

On 20/11/24 23:50, Guido Falsi wrote: On 20/11/24 22:14, Dimitry Andric wrote: On 20 Nov 2024, at 18:32, Guido Falsi wrote: I've noticed that recently some ports are dumping core during builds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing wh

Re: port binary dumping core on recent head in poudriere

[Just resending, including the original-sender's listing of freebsd=ports.] On Nov 21, 2024, at 02:22, Mark Millard wrote: > I've noticed that recently some ports are dumping core during builds of > dependencies in head in poudriere. > > I'm seeing this for exampl

Re: port binary dumping core on recent head in poudriere

On 20/11/24 22:14, Dimitry Andric wrote: On 20 Nov 2024, at 18:32, Guido Falsi wrote: I've noticed that recently some ports are dumping core during builds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing while trying to build x11-themes/grey

Re: port binary dumping core on recent head in poudriere

On 20 Nov 2024, at 18:32, Guido Falsi wrote: > I've noticed that recently some ports are dumping core during builds of > dependencies in head in poudriere. > > I'm seeing this for example with sassc crashing while trying to build > x11-themes/greybird-theme. > >

port binary dumping core on recent head in poudriere

Hi, I've noticed that recently some ports are dumping core during builds of dependencies in head in poudriere. I'm seeing this for example with sassc crashing while trying to build x11-themes/greybird-theme. My first suspect was the llvm upgrade in head, but forcing sassc and

ufs / tmpfs _vn_lock order reversal during poudriere unmount activity: ufs (ufs, lockmgr) @ . . ./vfs_mount.c:2260 vs. tmpfs (tmpfs, lockmgr) @ . . ./vfs_subr.c:4172

[I CC'd Bryan D. in case this is related to the failed rm activity tied to disamounts that are not happening first. I had reported on an example.] I got the following from poudriere-devel activity on a system running a pkgbase main debug kernel. Note that nullfs_unmount and null_lock are

Re: main [so: 15] amd64: Rare poudriere bulk builder "stuck in umtxq_sleep" condition (race failure?) during high-load-average "poudriere bulk -c -a" runs

On May 4, 2024, at 09:59, Mark Millard wrote: > I recently did some of my rare "poudriere bulk -c -a" high-load-average > style experiments, here on a 7950X3D (amd64) system and I ended up with > a couple of stuck builders (one per bulk run of 2 runs). Contexts: > >

main [so: 15] amd64: Rare poudriere bulk builder "stuck in umtxq_sleep" condition (race failure?) during high-load-average "poudriere bulk -c -a" runs

I recently did some of my rare "poudriere bulk -c -a" high-load-average style experiments, here on a 7950X3D (amd64) system and I ended up with a couple of stuck builders (one per bulk run of 2 runs). Contexts: # uname -apKU FreeBSD 7950X3D-UFS 15.0-CURRENT FreeBSD 15.0-CURRENT #142 ma

FYI: main-n268827-75464941dc17 GENERIC-NODEBUG UFS-based poudriere bulk context got 4 "swap_pager: cannot allocate bio"

Context: I'm deliberately testing building example poudriere-devel configurations with only 2 GiBytes of RAM and RAM+SWAP == 8.5 GiBytes, SWAP on a partition of its own. # tail -3 /var/log/messages Mar 23 16:39:38 aarch64-main-pkgs kernel: pid 37137 (conftest), jid 11, uid 0: exited on sign

main aarch64: poudriere-devel [UFS context] cpdup stuck in pgnslp state

0 root 680 15728Ki3552Ki wait 0 0:00 0.00% sh: poudriere[main-CA7-default][02]: build_pkg (gcc13-13.2.0_4) (sh) 30174 0 root 680 15728Ki3564Ki select 3 0:00 0.00% sh: poudriere[main-CA7-default][02]: build_pkg (gcc13-13.2.0_4) (sh) 26338

Re: poudriere: swap_pager: out of swap space

On Jan 15, 2024, at 00:07, Lexi Winter wrote: > Mark Millard: >> You seem to be under the impression that "Inact" means "page is not >> dirty" and so can be freed without being written out to the swap >> space. > > indeed, i was, because this is how sysutils/htop displays memory usage: > > top(

Re: poudriere: swap_pager: out of swap space

Mark Millard: > You seem to be under the impression that "Inact" means "page is not > dirty" and so can be freed without being written out to the swap > space. indeed, i was, because this is how sysutils/htop displays memory usage: top(1) Mem: 8502M Active, 15G Inact, 1568M Laundry, 5518M Wired,

  1   2   3   4   5   >