Re: poudriere pkgclean -jNAME-HERE -a gets complaints/rejections: "Error: Packages stuck in queue (depended on but not in queue)"

On 7/2/22 18:46, Mark Millard wrote:
> # poudriere version
> poudriere-git-3.3.99.20220617
> 
> 
> An amd64 example:
> 
> [00:01:12] Error: Packages stuck in queue (depended on but not in queue): IPA-1.08_2
> SoPlex-6.0.0_1
> bennugd-core-svn20130912_1
> cdcl-5.4.8_1
> deforaos-panel-0.3.6_1
> gnumail-1.3.0_1
> husky-hpt-1.9.20191207
> husky-htick-1.9.20191207
> ja-jishyo-0.1_11
> ja-onew-2.2.10_2
> jinput-2.0.10,1
> jmf-2.1.1e_3
> libhandy0-0.0.13
> linux-oracle-jdk18-8.291
> linux-ut-436_5,1
> logitechmediaserver-7.9.2.g2018.12.10
> mcollective-2.12.5
> oracle8-client-0.2.0_2
> ospray-2.10.0
> p5-Authen-Smb-0.91_1
> p5-OpenCA-OpenSSL-2.0.29_2
> p5-OpenGL-0.66_7
> puppet6-6.26.0
> py39-libtorrent-rasterbar-1.2.16,2
> py39-ocp-7.4.r2_3
> py39-pystan-2.19.0.0_1
> schroedinger-1.0.11_4
> svmlight-6.02_1
> trellis-g20190422_3
> wyrmgus-5.3.5
> zxid-1.42_1
> [00:01:12] Cleaning up
> [00:01:13] Unmounting file systems
> Exiting with status 1

I presumed https://github.com/freebsd/poudriere/issues/931 applies but 
not really sure as the 'leaving open' was a little bit vague at the end. 
Its the closest I found when I looked into in the past. I had to remove 
all packages to be able to run poudriere pkgclean which after a full 
rebuild of my usual packages didn't see the error right away but have 
seen it again since. Not sure if my output fully matches as I have a 
build currently running but recall starting with IPA, and I think 
schroedinger, in its output.

> I'll note that I had to modify www/firefox/Makefile to avoid
> the following in my environment that has llvm14 as the default:
> 
> [00:00:05] Warning: (www/firefox): Error: www/firefox depends on nonexistent origin 'devel/wasi-compiler-rt14'; Please contact maintainer of the port to fix this.
> [00:00:05] Error: Fatal errors encountered gathering ports metadata
> 
> Avoided via:
> 
> # git -C /usr/ports/ diff www/firefox
> diff --git a/www/firefox/Makefile b/www/firefox/Makefile
> index 9b67fb57e928..c236af69782c 100644
> --- a/www/firefox/Makefile
> +++ b/www/firefox/Makefile
> @@ -52,10 +52,11 @@ MOZ_OPTIONS=        --enable-application=browser \
>   .if ${ARCH} == powerpc64
>   MOZ_OPTIONS+=  --disable-webrtc --without-wasm-sandboxed-libraries
>   .else
> -BUILD_DEPENDS+=        ${LOCALBASE}/share/wasi-sysroot/lib/wasm32-wasi/libc++abi.a:devel/wasi-libcxx \
> -               ${LOCALBASE}/share/wasi-sysroot/lib/wasm32-wasi/libc.a:devel/wasi-libc \
> -               ${LOCALBASE}/llvm${LLVM_DEFAULT}/lib/clang/${LLVM_VERSION}/lib/wasi/libclang_rt.builtins-wasm32.a:devel/wasi-compiler-rt${LLVM_DEFAULT}
> -MOZ_OPTIONS+=  --with-wasi-sysroot=${LOCALBASE}/share/wasi-sysroot
> +#BUILD_DEPENDS+=       ${LOCALBASE}/share/wasi-sysroot/lib/wasm32-wasi/libc++abi.a:devel/wasi-libcxx \
> +#              ${LOCALBASE}/share/wasi-sysroot/lib/wasm32-wasi/libc.a:devel/wasi-libc \
> +#              ${LOCALBASE}/llvm${LLVM_DEFAULT}/lib/clang/${LLVM_VERSION}/lib/wasi/libclang_rt.builtins-wasm32.a:devel/wasi-compiler-rt${LLVM_DEFAULT}
> +#MOZ_OPTIONS+= --with-wasi-sysroot=${LOCALBASE}/share/wasi-sysroot
> +MOZ_OPTIONS+=  --disable-webrtc --without-wasm-sandboxed-libraries
>   .endif
>   
>   post-patch:
> 
> 
> NOTE: I do not build firefox except for very rare experiments
> with "bulk -a -c". Even then, I do not use firefox .

I think they were aware of an llvm14+rust issue. If this is different, 
hope this doesn't get lost without a formal PR to at least draw 
attention to the current compile issue existing. If your changes are 
disabling wasm, I presume it can impact performance of both the browser 
and some addons that use it.