Date: Sun, 3 Jul 2022 13:03:55 -0700 From: Mark Millard <marklmi@yahoo.com> To: "Edward Sanford Sutton, III" <mirror176@hotmail.com>, Bryan Drewery <bdrewery@FreeBSD.org> Cc: freebsd-ports@freebsd.org Subject: Re: poudriere pkgclean -jNAME-HERE -a gets complaints/rejections: "Error: Packages stuck in queue (depended on but not in queue)" Message-ID: <6D94564E-5DB5-490D-B249-D1D7A1078416@yahoo.com> In-Reply-To: <DM6PR03MB3674D7FA3E5AAD99B5877B56E6BF9@DM6PR03MB3674.namprd03.prod.outlook.com> References: <452FC476-EAFF-4E56-9529-05D437A9EB49.ref@yahoo.com> <452FC476-EAFF-4E56-9529-05D437A9EB49@yahoo.com> <DM6PR03MB3674D7FA3E5AAD99B5877B56E6BF9@DM6PR03MB3674.namprd03.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >=20 > 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=3D does not build: use of undeclared identifier = 'nilHandle' ONLY_FOR_ARCHS=3D amd64 powerpc64 powerpc64le ONLY_FOR_ARCHS_REASON=3D fails to build: uses x86 asm BROKEN_aarch64=3D Fails to link: missing sbrk BROKEN_riscv64=3D Fails to link: missing sbrk LICENSE_PERMS=3D no-dist-mirror no-pkg-mirror no-auto-accept (I'm guessing at this one being the cause here.) BROKEN_FreeBSD_14=3D network.c:298:19: error: variable has = incomplete type 'struct ifdatareq' .if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) IGNORE=3D because of licensing restrictions, you must fetch the source\ distribution manually.\ Please access = https://www.oracle.com/java/technologies/java-archive-downloads-java-clien= t-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=3D yes BROKEN_RUBY31=3D 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=3D = --enable-application=3Dbrowser \ >> .if ${ARCH} =3D=3D powerpc64 >> MOZ_OPTIONS+=3D --disable-webrtc --without-wasm-sandboxed-libraries >> .else >> -BUILD_DEPENDS+=3D = ${LOCALBASE}/share/wasi-sysroot/lib/wasm32-wasi/libc++abi.a:devel/wasi-lib= cxx \ >> - = ${LOCALBASE}/share/wasi-sysroot/lib/wasm32-wasi/libc.a:devel/wasi-libc \ >> - = ${LOCALBASE}/llvm${LLVM_DEFAULT}/lib/clang/${LLVM_VERSION}/lib/wasi/libcla= ng_rt.builtins-wasm32.a:devel/wasi-compiler-rt${LLVM_DEFAULT} >> -MOZ_OPTIONS+=3D --with-wasi-sysroot=3D${LOCALBASE}/share/wasi-sysroot= >> +#BUILD_DEPENDS+=3D = ${LOCALBASE}/share/wasi-sysroot/lib/wasm32-wasi/libc++abi.a:devel/wasi-lib= cxx \ >> +# = ${LOCALBASE}/share/wasi-sysroot/lib/wasm32-wasi/libc.a:devel/wasi-libc \ >> +# = ${LOCALBASE}/llvm${LLVM_DEFAULT}/lib/clang/${LLVM_VERSION}/lib/wasi/libcla= ng_rt.builtins-wasm32.a:devel/wasi-compiler-rt${LLVM_DEFAULT} >> +#MOZ_OPTIONS+=3D --with-wasi-sysroot=3D${LOCALBASE}/share/wasi-sysroot= >> +MOZ_OPTIONS+=3D --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 . >=20 > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6D94564E-5DB5-490D-B249-D1D7A1078416>