>>> Source unpacked in /var/tmp/portage/sys-fs/zerofree-1.0.4/work >>> Preparing source in /var/tmp/portage/sys-fs/zerofree-1.0.4/work/zerofree-1.0.4 ... sed: -e expression #1, char 104: unknown option to `s' * ERROR: sys-fs/zerofree-1.0.4::gentoo failed (prepare phase): * Failed to sed the Makefile * ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_developer-20200221-171645 ------------------------------------------------------------------- Please see the tracker bug for details. gcc-config -l: [1] x86_64-pc-linux-gnu-9.2.0 * clang: clang version 9.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/9/bin llvm: 9.0.1 Available Python interpreters, in order of preference: [1] python3.8 [2] python3.7 [3] python3.6 [4] python2.7 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) * Available Rust versions: [1] rust-1.41.0 * java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.14.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm ghc: The Glorious Glasgow Haskell Compilation System, version 8.0.2 repository: ==> /var/db/repos/gentoo/metadata/timestamp.chk <== Tue, 25 Feb 2020 03:07:18 +0000 emerge -qpvO sys-fs/zerofree [ebuild N ] sys-fs/zerofree-1.0.4
Created attachment 615828 [details] emerge-info.txt
Created attachment 615830 [details] emerge-history.txt
Created attachment 615832 [details] environment
Created attachment 615834 [details] etc.portage.tbz2
Created attachment 615836 [details] sys-fs:zerofree-1.0.4:20200225-045942.log
Created attachment 615838 [details] temp.tbz2
Seems to work for me: # ebuild /usr/portage/sys-fs/zerofree/zerofree-1.0.4.ebuild clean unpack prepare * zerofree-1.0.4.tgz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking zerofree-1.0.4.tgz to /ramfs/portage/sys-fs/zerofree-1.0.4/work >>> Source unpacked in /ramfs/portage/sys-fs/zerofree-1.0.4/work >>> Checking zerofree-1.0.4.tgz's mtime... >>> WORKDIR is up-to-date, keeping... >>> It appears that 'pretend' has already executed for 'zerofree-1.0.4'; skipping. >>> Remove '/ramfs/portage/sys-fs/zerofree-1.0.4/.pretended' to force pretend. >>> It appears that 'setup' has already executed for 'zerofree-1.0.4'; skipping. >>> Remove '/ramfs/portage/sys-fs/zerofree-1.0.4/.setuped' to force setup. >>> It appears that 'unpack' has already executed for 'zerofree-1.0.4'; skipping. >>> Remove '/ramfs/portage/sys-fs/zerofree-1.0.4/.unpacked' to force unpack. >>> Preparing source in /ramfs/portage/sys-fs/zerofree-1.0.4/work/zerofree-1.0.4 ... >>> Source prepared. What version is your `sed'? I have: # sed --version sed (GNU sed) 4.8 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
(In reply to Joshua Kinard from comment #7) > What version is your `sed'? I have: > # sed --version > sed (GNU sed) 4.8 nothing special here: mr-fox ~ # sed --version sed (GNU sed) 4.8 Copyright (C) 2020 Free Software Foundation, Inc. Maybe USE flags related?
(In reply to Toralf Förster from comment #8) > (In reply to Joshua Kinard from comment #7) > > What version is your `sed'? I have: > > # sed --version > > sed (GNU sed) 4.8 > > nothing special here: > > mr-fox ~ # sed --version > sed (GNU sed) 4.8 > Copyright (C) 2020 Free Software Foundation, Inc. > > > Maybe USE flags related? From your environemnt: declare -x USE="abi_x86_64 amd64 elibc_glibc kernel_linux split-usr userland_GNU" From my amd64 machine: declare -x USE="abi_x86_64 amd64 elibc_glibc kernel_linux split-usr userland_GNU" So nope, not USE related. I even tried symlinking /bin/sed to /bin/busybox to see if that was the sed that failed, but it, too, runs src_prepare() just fine. I'll add an ebuild for zerofree-1.1.1 tonight. Can you try again with that? Also maybe try running the ebuild phases manually outside of the tinderbox environment?
(In reply to Joshua Kinard from comment #9) > (In reply to Toralf Förster from comment #8) > > (In reply to Joshua Kinard from comment #7) > > > What version is your `sed'? I have: > > > # sed --version > > > sed (GNU sed) 4.8 > > > > nothing special here: > > > > mr-fox ~ # sed --version > > sed (GNU sed) 4.8 > > Copyright (C) 2020 Free Software Foundation, Inc. > > > > > > Maybe USE flags related? > > From your environemnt: > declare -x USE="abi_x86_64 amd64 elibc_glibc kernel_linux split-usr > userland_GNU" > > From my amd64 machine: > declare -x USE="abi_x86_64 amd64 elibc_glibc kernel_linux split-usr > userland_GNU" > > So nope, not USE related. I even tried symlinking /bin/sed to /bin/busybox > to see if that was the sed that failed, but it, too, runs src_prepare() just > fine. > > I'll add an ebuild for zerofree-1.1.1 tonight. Can you try again with that? > Also maybe try running the ebuild phases manually outside of the tinderbox > environment? Okay, I figured it out. I didn't realize this bug was a blocker to the "colon-in-gcc" bug. I don't use the CFLAG "-falign-functions=32:25:16". Thus my attempts were working fine. If I add that CFLAG, *then* I can reproduce the breakage.
(In reply to Joshua Kinard from comment #10) > > Okay, I figured it out. I didn't realize this bug was a blocker to the > "colon-in-gcc" bug. I don't use the CFLAG "-falign-functions=32:25:16". > Thus my attempts were working fine. If I add that CFLAG, *then* I can > reproduce the breakage. So the colon-as-delimiter may need to be reconciled with this bit from the devmanual: Note: When using sed with CFLAGS or LDFLAGS, it is not safe to use a comma or a slash as a delimiter. The recommended character is a colon. https://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building/index.html For now, it looks like using a pipe character as the sed delimiter works.
Pushed a fix to the tree. Wish I knew how to get Larry the Git Cow to handle the bug closing, but this should be fixed now. Reopen if it isn't. Thanks!
