Ports such as llvm15 are sometimes queued, then not. Hurrah!

[grahamperrin]

Two runs:

• 2023-05-27_18h08m07s
• 2023-05-27_19h52m33s

llvm15-15.0.7_3 was queued (reason: devel/boost-libs). I chose to cancel the first run before build began, with a suspicion that llvm15 would disappear.

The second run confirmed my suspicion: llvm15-15.0.7_3 was not queued.

The two, in retrospect:

It's a great time-saver, and I'm not sure when I first observed this type of thing (maybe a few weeks ago), however:

• I don't understand how it can happen.

The command

poudriere bulk -j main -J 8 -Ctv emulators/virtualbox-ose emulators/virtualbox-ose-kmod

• with one file patched according to https://reviews.freebsd.org/D40254?id=122409.

Environment

% pkg iinfo poudriere
poudriere-devel-3.3.99.20220831
% poudriere jail -i -j main
Jail name:         main
Jail version:      14.0-CURRENT 1400089
Jail arch:         amd64
Jail method:       src=/usr/src
Jail mount:        /usr/local/poudriere/jails/main
Jail fs:           august/poudriere/jails/main
Jail updated:      2023-05-27 04:17:21
Jail pkgbase:      disabled
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #41 main-n263189-c2c9ac88c2bb-dirty: Sat May 27 16:55:26 BST 2023     grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400089 1400089
% 

Log folders available on request.

[MirLach]

I saw it many times (with PACKAGE_FETCH_BRANCH=quarterly if this matters). If I am correct it is caused by upgrade of dependencies causing deletion of llvm (or gcc or other large ports). For example update of Python caused deletion of LLVM and forcing Poudriere to rebuild LLVM from sources instead of using fetched package. If you stop poudriere bulk before LLVM build but after Python was built and then start poudriere bulk again, it will use existing / fetched LLVM instead of building it from source.
Current behavior makes PACKAGE_FETCH_BRANCH almost useless because even a minor update (security patch level update of Python) causes deletion and rebuild of tens or hundreds of packages taking 3 - 7 hours in my case instead of few minutes of CPU time really required.

[grahamperrin]

Thank you,

… If you stop poudriere bulk before LLVM build but after Python was built and then start poudriere bulk again, it will use existing / fetched LLVM instead of building it from source. …

No python in this case.

Re: the run pictured in the first screenshot – main-default/2023-05-27_18h08m07s, here's what was built:

• at-spi2-core-2.48.0
• avahi-app-0.8_1
• binutils-2.40_4,1
• cairo-1.17.4_2,3
• cups-2.4.2_1
• curl-8.1.1
• dbus-1.14.6,1
• dbus-glib-0.112
• glib-2.76.3,2
• gnutls-3.7.9
• gobject-introspection-1.76.1,1
• harfbuzz-7.3.0
• harfbuzz-icu-7.3.0
• lcms2-2.15_1
• libgd-2.3.3_5,1
• libGLU-9.0.2_2
• libglvnd-1.6.0
• libgudev-234
• libIDL-0.8.14_5
• libinput-1.23.0
• libuv-1.45.0
• libwacom-1.5
• libX11-1.7.2,1
• libXaw-1.0.14,2
• libxcb-1.15_1
• libXcursor-1.2.0
• libXdmcp-1.1.3
• libXext-1.3.4,1
• libXfixes-6.0.0
• libXi-1.8,1
• libXinerama-1.1.4_2,1
• libxkbcommon-1.5.0
• libXmu-1.1.3,1
• libXpm-3.5.15
• libXrandr-1.5.2
• libXrender-0.9.10_2
• libXt-1.2.1,1
• libXtst-1.2.3_2
• meson-1.1.1
• p11-kit-0.24.1_2
• py39-certifi-2023.5.7
• py39-flit-3.8.0_2
• py39-recommonmark-0.5.0_2
• py39-requests-2.30.0
• py39-sphinx-5.3.0_1,1
• py39-urllib3-1.26.15,1
• sdl-1.2.15_15,2
• t1lib-5.1.2_5,1
• tiff-4.4.0_1
• webp-1.3.0
• xcb-util-0.4.0_2,1
• xcb-util-image-0.4.0_1
• xcb-util-keysyms-0.4.0_1
• xcb-util-renderutil-0.3.9_1
• xcb-util-wm-0.4.1_3
• xdg-utils-1.1.3_2
• xorgproto-2022.1_1
• xpdfopen-0.86_2
• xprop-1.2.6
• xset-1.2.5
• zstd-1.5.5

[grahamperrin]

Almost certainly overcome by events.