The llvm-18.1.8-r1 ebuild (the current stable llvm 18) fails to unpack: $ emerge -v llvm ... * Unpacking from llvm-project-18.1.8.src.tar.xz ... [ ok ] >>> Unpacking llvm-project-18.1.8.src.tar.xz.sig to /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work unpack llvm-project-18.1.8.src.tar.xz.sig: file format not recognized. Ignoring. >>> Unpacking llvm-18.1.0-manpages.tar.bz2 to /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work >>> Unpacking llvm-gentoo-patchset-18.1.8.tar.xz to /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work * ERROR: sys-devel/llvm-18.1.8-r1::gentoo failed (unpack phase): * No patches in the patchset apply to the package 18.1.8-r4 uses a different patchset and does unpack: $ ebuild /mnt/scratch/repos/gentoo/sys-devel/llvm/llvm-18.1.8-r4.ebuild unpack ... * Unpacking from llvm-project-18.1.8.src.tar.xz ... [ ok ] >>> Unpacking llvm-project-18.1.8.src.tar.xz.sig to /mnt/scratch/portage/sys-devel/llvm-18.1.8-r4/work unpack llvm-project-18.1.8.src.tar.xz.sig: file format not recognized. Ignoring. >>> Unpacking llvm-18.1.0-manpages.tar.bz2 to /mnt/scratch/portage/sys-devel/llvm-18.1.8-r4/work >>> Unpacking llvm-gentoo-patchset-18.1.8-r4.tar.xz to /mnt/scratch/portage/sys-devel/llvm-18.1.8-r4/work >>> Source unpacked in /mnt/scratch/portage/sys-devel/llvm-18.1.8-r4/work It would be good to get -r4 into stable ASAP as the current llvm build doesn't work (and is the default for emerge llvm) Reproducible: Always Steps to Reproduce: 1. emerge -v llvm 2. 3. Actual Results: Patchset fails to unpack Expected Results: Patches unpack and build proceeds. Portage 3.0.63 (python 3.11.9-final-0, default/linux/amd64/17.1/systemd/merged-usr, gcc-13, glibc-2.36-r5, 5.10.52-gentoo.hex x86_64) ================================================================= System uname: Linux-5.10.52-gentoo.hex-x86_64-AMD_Ryzen_9_3900X_12-Core_Processor-with-glibc2.36 KiB Mem: 65829608 total, 614376 free KiB Swap: 124999672 total, 124997344 free Timestamp of repository gentoo: Fri, 30 Aug 2024 06:30:00 +0000 Head commit of repository gentoo: 70ec535f008906a6ef7c5ca8f1e14010a47226c2 sh bash 5.1_p16-r2 ld GNU ld (Gentoo 2.40 p5) 2.40.0 app-misc/pax-utils: 1.3.7::gentoo app-shells/bash: 5.1_p16-r2::gentoo dev-build/autoconf: 2.13-r7::gentoo, 2.69-r9::gentoo, 2.71-r6::gentoo dev-build/automake: 1.16.5::gentoo dev-build/cmake: 3.28.3::gentoo dev-build/libtool: 2.4.7-r3::gentoo dev-build/make: 4.4.1-r1::gentoo dev-build/meson: 1.3.2::gentoo dev-java/java-config: 2.3.3-r1::gentoo dev-lang/perl: 5.38.2-r3::gentoo dev-lang/python: 3.10.14_p1-r1::gentoo, 3.11.9-r1::gentoo, 3.12.3-r1::gentoo dev-lang/rust: 1.77.1::gentoo sys-apps/baselayout: 2.15::gentoo sys-apps/sandbox: 2.29::gentoo sys-apps/systemd: 255.7-r1::gentoo sys-devel/binutils: 2.38-r2::gentoo, 2.40-r5::gentoo sys-devel/binutils-config: 5.3.2::gentoo sys-devel/clang: 15.0.7-r1::gentoo, 16.0.6::gentoo, 17.0.6::gentoo sys-devel/gcc: 11.3.1_p20230427::gentoo, 12.3.1_p20230526::gentoo, 13.2.1_p20240210::gentoo sys-devel/gcc-config: 2.11::gentoo sys-devel/lld: 15.0.7::gentoo, 17.0.6::gentoo sys-devel/llvm: 14.0.6-r2::gentoo, 15.0.7::gentoo, 16.0.6::gentoo, 17.0.6::gentoo sys-kernel/linux-headers: 6.6::gentoo (virtual/os-headers) sys-libs/glibc: 2.36-r5::gentoo Repositories: gentoo location: /mnt/scratch/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 volatile: True sync-rsync-verify-max-age: 24 sync-rsync-extra-opts: sync-rsync-verify-metamanifest: yes sync-rsync-verify-jobs: 1
If you add the category and package name to the title the package will get assigned automatically.
consider syncing and trying again; cannot reproduce locally. unrelated but it is past time to migrate to 23.0 profile
Please attach the full build.log so we can see the involved USE.
(In reply to Paul Zander from comment #1) > If you add the category and package name to the title the package will get > assigned automatically. Yeah, sorry, out of practice.
(In reply to Greg Kubaryk from comment #2) > consider syncing and trying again; cannot reproduce locally. I have it set to sync every morning and waited 24 hours before reporting this. I'm still seeing the same after this morning's sync as well. As I say, -r1 is broken (the amd64 version) but -r4 works. I haven't checked the changes between those revisions. Was it something patch-related that was broken? It's visible just by running the unpack stage using ebuild. > unrelated but > it is past time to migrate to 23.0 profile That's what I'm working on but it's non-trivial. It doesn't help that packages start pulling in the new llvm :-)
(In reply to Andrew John Hughes from comment #5) > (In reply to Greg Kubaryk from comment #2) > > consider syncing and trying again; cannot reproduce locally. > > I have it set to sync every morning and waited 24 hours before reporting > this. I'm still seeing the same after this morning's sync as well. > > As I say, -r1 is broken (the amd64 version) but -r4 works. I haven't checked > the changes between those revisions. Was it something patch-related that was > broken? > > It's visible just by running the unpack stage using ebuild. > Not for me it isn't, that's why I asked... ``` $ e llvm-18.1.8-r1.ebuild clean prepare Appending /home/sam/git/gentoo to PORTDIR_OVERLAY... * llvm-project-18.1.8.src.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] * llvm-project-18.1.8.src.tar.xz.sig BLAKE2B SHA512 size ;-) ... [ ok ] * llvm-18.1.0-manpages.tar.bz2 BLAKE2B SHA512 size ;-) ... [ ok ] >>> Downloading 'https://www.mirrorservice.org/sites/distfiles.gentoo.org/distfiles/95/llvm-gentoo-patchset-18.1.8.tar.xz' --2024-09-04 15:24:08-- https://www.mirrorservice.org/sites/distfiles.gentoo.org/distfiles/95/llvm-gentoo-patchset-18.1.8.tar.xz Resolving www.mirrorservice.org... 212.219.56.184, 2001:630:341:12::184 Connecting to www.mirrorservice.org|212.219.56.184|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 7444 (7.3K) [application/x-xz] Saving to: ‘/var/cache/distfiles/llvm-gentoo-patchset-18.1.8.tar.xz.__download__’ /var/cache/distfiles/llvm-gentoo-patchset-18.1 100%[==================================================================================================>] 7.27K --.-KB/s in 0s 2024-09-04 15:24:08 (1.76 GB/s) - ‘/var/cache/distfiles/llvm-gentoo-patchset-18.1.8.tar.xz.__download__’ saved [7444/7444] * llvm-gentoo-patchset-18.1.8.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] * Checking whether python3_13 is suitable ... * dev-lang/python:3.13 ... [ ok ] * python_check_deps ... [ ok ] * Using python3.13 to build (via PYTHON_COMPAT iteration) >>> Unpacking source... * Verifying llvm-project-18.1.8.src.tar.xz ... INFO File /var/tmp/portage/sys-devel/llvm-18.1.8-r1/distdir/llvm-project-18.1.8.src.tar.xz verified successfully against the signature in /var/tmp/portage/sys-devel/llvm-18.1.8-r1/distdir/llvm-project-18.1.8.src.tar.xz.sig: INFO - status: OpenPGPSignatureStatus.GOOD INFO - valid: True, trusted: True INFO - primary key: 474E22316ABF4785A88C6E8EA2C794A986419D8A INFO - subkey: 474E22316ABF4785A88C6E8EA2C794A986419D8A INFO - timestamp: 2024-06-21 20:50:22 UTC * Unpacking from llvm-project-18.1.8.src.tar.xz ... [ ok ] >>> Unpacking llvm-project-18.1.8.src.tar.xz.sig to /var/tmp/portage/sys-devel/llvm-18.1.8-r1/work >>> Unpacking llvm-18.1.0-manpages.tar.bz2 to /var/tmp/portage/sys-devel/llvm-18.1.8-r1/work >>> Unpacking llvm-gentoo-patchset-18.1.8.tar.xz to /var/tmp/portage/sys-devel/llvm-18.1.8-r1/work >>> Source unpacked in /var/tmp/portage/sys-devel/llvm-18.1.8-r1/work >>> Preparing source in /var/tmp/portage/sys-devel/llvm-18.1.8-r1/work/llvm ... * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/sys-devel/llvm-18.1.8-r1/work/llvm" * Build directory (BUILD_DIR): "/var/tmp/portage/sys-devel/llvm-18.1.8-r1/work/llvm_build" * Applying patches from /var/tmp/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8 ... * 0001-InstSimplify-Fix-simplifyAndOrWithICmpEq-with-undef-.patch ... [ ok ] * 0002-ConstantFold-Fix-result-type-when-folding-powi.f16-9.patch ... [ ok ] * 0003-Fix-assertion-failure-in-PR98681-98860.patch ... [ ok ] * 0004-SDAG-Intersect-poison-generating-flags-after-CSE-974.patch ... [ ok ] * 0005-InstCombine-Guard-noundef-for-transformation-from-xo.patch ... [ ok ] * 0006-ARM-Fix-arm32be-softfp-mode-miscompilation-for-neon-.patch ... [ ok ] * 0007-AArch64-Avoid-overflow-when-using-shl-lower-mul-9714.patch ... [ ok ] >>> Source prepared. ``` build.log please.
The eclass check is: ``` if [[ -n ${LLVM_PATCHSET} ]]; then local nocomp=$(grep -r -L "^Gentoo-Component:" \ "${WORKDIR}/llvm-gentoo-patchset-${LLVM_PATCHSET}") if [[ -n ${nocomp} ]]; then die "Patches lacking Gentoo-Component found: ${nocomp}" fi # strip patches that don't match current components local IFS='|' grep -E -r -L "^Gentoo-Component:.*(${components[*]})" \ "${WORKDIR}/llvm-gentoo-patchset-${LLVM_PATCHSET}" | xargs -r rm local status=( "${PIPESTATUS[@]}" ) [[ ${status[1]} -ne 0 ]] && die "rm failed" [[ ${status[0]} -ne 0 ]] && die "No patches in the patchset apply to the package" fi ``` Please add set -x/set +x to see why this is failing for you.
> Please attach the full build.log so we can see the involved USE. There's not really much more than I already posted, but I can attach it. emerge -pv is as follows: [ebuild UD ] sys-devel/llvm-18.1.8-r1:18/18.1::gentoo [18.1.8-r4:18/18.1::gentoo] USE="binutils-plugin debuginfod libffi ncurses verify-sig xml z3 zstd -debug -doc -exegesis -libedit -test" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="(AArch64) (AMDGPU) (ARM) (AVR) (BPF) (Hexagon) (Lanai) (LoongArch) (MSP430) (Mips) (NVPTX) (PowerPC) (RISCV) (Sparc) (SystemZ) (VE) (WebAssembly) (X86) (XCore) -ARC -CSKY -DirectX -M68k -SPIRV -Xtensa" 0 KiB To clarify, this isn't blocking me; I've keyworded -r4 and built that successfully (as you can see above). I just wanted to make you aware that the stable version seems to be broken at present and getting -r4 stabilised ASAP would be good.
Created attachment 902070 [details] Build log of sys-devel/llvm-18.1.8-r1
You're not understanding me. I'm saying that stabilisation would be a workaround and that there's something else wrong on your machine. It is better for both sides if we can debug what's actually wrong, not paper over it.
(In reply to Sam James from comment #7) > The eclass check is: > ``` > if [[ -n ${LLVM_PATCHSET} ]]; then > local nocomp=$(grep -r -L "^Gentoo-Component:" \ > "${WORKDIR}/llvm-gentoo-patchset-${LLVM_PATCHSET}") > if [[ -n ${nocomp} ]]; then > die "Patches lacking Gentoo-Component found: > ${nocomp}" > fi > > # strip patches that don't match current components > local IFS='|' > grep -E -r -L "^Gentoo-Component:.*(${components[*]})" \ > "${WORKDIR}/llvm-gentoo-patchset-${LLVM_PATCHSET}" | > xargs -r rm > local status=( "${PIPESTATUS[@]}" ) > [[ ${status[1]} -ne 0 ]] && die "rm failed" > [[ ${status[0]} -ne 0 ]] && > die "No patches in the patchset apply to the package" > fi > ``` > > Please add set -x/set +x to see why this is failing for you. >>> Unpacking llvm-gentoo-patchset-18.1.8.tar.xz to /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work + [[ -n 18.1.8 ]] ++ grep -r -L '^Gentoo-Component:' /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8 + local nocomp= + [[ -n '' ]] + local 'IFS=|' + grep -E -r -L '^Gentoo-Component:.*(llvm|cmake|third-party)' /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8 + xargs -r rm + status=('1' '0') + local status + [[ 0 -ne 0 ]] + [[ 1 -ne 0 ]] + die 'No patches in the patchset apply to the package' + [[ -n '' ]] + set +x * ERROR: sys-devel/llvm-18.1.8-r1::gentoo failed (unpack phase):
(In reply to Sam James from comment #10) > You're not understanding me. I'm saying that stabilisation would be a > workaround and that there's something else wrong on your machine. It is > better for both sides if we can debug what's actually wrong, not paper over > it. I get that. I was trying to reply before your latest replies and we keep hitting collisions :)
So the grep is causing the failure. Without the -L: # grep -E -r '^Gentoo-Component:.*(llvm|cmake|third-party)' /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8 /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8/0001-InstSimplify-Fix-simplifyAndOrWithICmpEq-with-undef-.patch:Gentoo-Component: llvm /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8/0002-ConstantFold-Fix-result-type-when-folding-powi.f16-9.patch:Gentoo-Component: llvm /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8/0003-Fix-assertion-failure-in-PR98681-98860.patch:Gentoo-Component: llvm /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8/0004-SDAG-Intersect-poison-generating-flags-after-CSE-974.patch:Gentoo-Component: llvm /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8/0005-InstCombine-Guard-noundef-for-transformation-from-xo.patch:Gentoo-Component: llvm /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8/0006-ARM-Fix-arm32be-softfp-mode-miscompilation-for-neon-.patch:Gentoo-Component: llvm /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8/0007-AArch64-Avoid-overflow-when-using-shl-lower-mul-9714.patch:Gentoo-Component: llvm
run: > IFS='|' grep -E -r -L "^Gentoo-Component:.*(${components[*]})" llvm-gentoo-patchset-18.1.8 | xargs -r rm -v please. The IFS is important.
(In reply to Paul Zander from comment #14) > run: > > IFS='|' grep -E -r -L "^Gentoo-Component:.*(${components[*]})" llvm-gentoo-patchset-18.1.8 | xargs -r rm -v > please. The IFS is important. For expanding the components array into llvm|cmake|third-party. But this is already done in the line I posted, and components wouldn't be defined on the command line.
Please run the command.
or > IFS='|' grep -E -r -L "^Gentoo-Component:.*(llvm|cmake|third-party)" llvm-gentoo-patchset-18.1.8 | xargs -r rm -v if that makes you happier
I have. It produces the same result as expected: # IFS='|' grep -E -r -L "^Gentoo-Component:.*(llvm|cmake|third-party)" /mnt/scratch/portage/sys-devel/llvm-18.1.8-r1/work/llvm-gentoo-patchset-18.1.8 | xargs -r rm -v # echo ${PIPESTATUS[@]} 1 0
-r4 finds two files to delete and both status values are 0: >>> Unpacking llvm-gentoo-patchset-18.1.8-r4.tar.xz to /mnt/scratch/portage/sys-devel/llvm-18.1.8-r4/work + [[ -n 18.1.8-r4 ]] ++ grep -r -L '^Gentoo-Component:' /mnt/scratch/portage/sys-devel/llvm-18.1.8-r4/work/llvm-gentoo-patchset-18.1.8-r4 + local nocomp= + [[ -n '' ]] + local 'IFS=|' + grep -E -r -L '^Gentoo-Component:.*(llvm|cmake|third-party)' /mnt/scratch/portage/sys-devel/llvm-18.1.8-r4/work/llvm-gentoo-patchset-18.1.8-r4 + xargs -r rm -v removed '/mnt/scratch/portage/sys-devel/llvm-18.1.8-r4/work/llvm-gentoo-patchset-18.1.8-r4/0017-Sanitizers-Avoid-overload-ambiguity-for-interceptors.patch' removed '/mnt/scratch/portage/sys-devel/llvm-18.1.8-r4/work/llvm-gentoo-patchset-18.1.8-r4/0018-asan-test-Disable-_FORTIFY_SOURCE-test-incompatible-.patch' + status=('0' '0') + local status + [[ 0 -ne 0 ]] + [[ 0 -ne 0 ]] + set +x It seems to only fail if there is nothing to delete. Neither of the deleted patches are in the -r1 patchset.
$ grep --version plz
# grep --version grep (GNU grep) 3.3 Going through the release notes, this smells like: " The --files-without-match (-L) option has reverted to its behavior in grep 3.1 and earlier. That is, grep -L again succeeds when a line is selected, not when a file is listed. The behavior in grep 3.2 through 3.4 was causing compatibility problems." https://savannah.gnu.org/news/?id=9784 grep -L is producing a status of 1 when it doesn't print any unmatched patch files, rather than a status of 0 from matching some patch files Should I try upgrading and see if this fixes the bug?
There are no versions of grep in the gentoo repo older than 3.11, and there hasn't been a 3.3 since 2020.
(In reply to Greg Kubaryk from comment #22) > There are no versions of grep in the gentoo repo older than 3.11, and there > hasn't been a 3.3 since 2020. I didn't say there was. In fact, the reason I wanted to make sure I should upgrade to 3.11 is because it would be difficult to get back to 3.3 after doing so.
Confirmed fixed with grep 3.11. Thanks for the help diagnosing this.
