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

In reply to: Edward Sanford Sutton, III: "Re: poudriere pkgclean -jNAME-HERE -a gets complaints/rejections: "Error: Packages stuck in queue (depended on but not in queue)""
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 03 Jul 2022 20:03:55 UTC
On 2022-Jul-3, at 05:19, Edward Sanford Sutton, III <mirror176@hotmail.com> wrote:

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

Well, "pkgclean -a" is somewhat different.

Turns out that the reported ports seem to have things like
(I cover some aarch64 examples that you cut from your reply):

BROKEN=         does not build: use of undeclared identifier 'nilHandle'

ONLY_FOR_ARCHS= amd64 powerpc64 powerpc64le
ONLY_FOR_ARCHS_REASON=  fails to build: uses x86 asm

BROKEN_aarch64= Fails to link: missing sbrk
BROKEN_riscv64= Fails to link: missing sbrk

LICENSE_PERMS=  no-dist-mirror no-pkg-mirror no-auto-accept
(I'm guessing at this one being the cause here.)

BROKEN_FreeBSD_14=      network.c:298:19: error: variable has incomplete type 'struct ifdatareq'

.if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX})
IGNORE= because of licensing restrictions, you must fetch the source\
distribution manually.\
Please access https://www.oracle.com/java/technologies/java-archive-downloads-java-client-downloads.html \
with a web browser and follow the "Java Media Framework (JMF) ${PORTVERSION}" link.\
Select download format: cross-platform format.  Please place this file in\
${DISTDIR}
.endif

BROKEN_RUBY30=  yes
BROKEN_RUBY31=  yes

I'll stop with that. Generally: something is present
that means the port would be avoied in a bulk run.

As stands, "pkgclean -a" seems to be a way to find examples
of such ports for a context of interest.

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

I'm not so much worried about building firefox as the
lack of a dependency for one port preventing the overall
"pkgclean -a" activity which was not specific to the
firefox example at all. More of a possible poudriere
error handling issue.

(But I've not thought through if such a handling is required
to avoid some potential consequences that could be
important sometimes. Or if nicer error handling might just
be too complicated to produce.)

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

Again, I was not building firefox at all --or building any
ports. "poudriere pkgclean -a" does not build ports. My
changes were only for my context, not to be used by others.
I was only enabling "poudriere pkgclean -a" in my context.

===
Mark Millard
marklmi at yahoo.com