>>> Source compiled. >>> Test phase [not enabled]: net-misc/rclone-1.60.1 >>> Install net-misc/rclone-1.60.1 into /var/tmp/portage/net-misc/rclone-1.60.1/image /var/tmp/portage/net-misc/rclone-1.60.1/temp/environment: line 1478: 37 Segmentation fault ./rclone genautocomplete bash ${PN}.bash * ERROR: net-misc/rclone-1.60.1::gentoo failed (install phase): * (no error message) ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_systemd-j4-20221202-050005 ------------------------------------------------------------------- GNUMAKEFLAGS="$GNUMAKEFLAGS --shuffle" gcc-config -l: [1] x86_64-pc-linux-gnu-12 * clang/llvm (if any): Python 3.10.8 Available Rust versions: [1] rust-bin-1.65.0 * The Glorious Glasgow Haskell Compilation System, version 9.0.2 php cli (if any): [1] php8.1 * HEAD of ::gentoo commit 422e0a78cc4b137d86b076b860d13237524029fd Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Fri Dec 2 09:46:48 2022 +0000 2022-12-02 09:46:47 UTC emerge -qpvO net-misc/rclone [ebuild N ] net-misc/rclone-1.60.1
Created attachment 839013 [details] emerge-info.txt
Created attachment 839015 [details] emerge-history.txt
Created attachment 839017 [details] environment
Created attachment 839019 [details] etc.portage.tar.bz2
Created attachment 839021 [details] logs.tar.bz2
Created attachment 839023 [details] net-misc:rclone-1.60.1:20221202-102145.log.bz2
The file size of ./files/temp.tar.bz2 is too big (68M) for an upload. For about 8 weeks the link http://tinderbox.zwiebeltoralf.de:31560/17.1_systemd-j4-20221202-050005/var/tmp/tb/issues/20221202-102233-net-misc_rclone-1.60.1/files/temp.tar.bz2 is valid.
or is this the reproducer for bug 879313 ?
Looks like bug 879313, can you reproduce it? I wonder what are the conditions to get hit this bug.
(In reply to Piotr Karbowski from comment #9) > Looks like bug 879313, can you reproduce it? I wonder what are the > conditions to get hit this bug. Seems it is a reproducer. The condition should be given in etc.portage.tar.bz2 but honestly - no idea which USE flag combo it is.
Though the rclone has no USE flags at all, and it's just a golang project that hardly has any dependency on other things beside golang itself. It does not use any system library. Can you get me the particular binary that crash on you? Like keep the build dir and mail me the binary itself.
GNUMAKEFLAGS="$GNUMAKEFLAGS --shuffle" is IMO the answer
b/c even at that image it is not reproduceable
I would highly doubt that since go build do not use GNU Make, I am most interested if it is runtime thing. If you could grab the actual binary that failed for you, and re-execute it manually, that would give us something, answer whatever the binary is broken, or if it's random failure during runtime and this very binary works sometimes.
Toralf ping! Can you please check the previous comment? I continue to be unable to reproduce it.
The problem is that /var/tmp/portage/ is a tmpfs here at the tinderboxes and therefore the failing exe is gone asap. I could change the tinderbox for this special purpose but would need to know what exactly you'd like to achieve. So shall I in case of an future failure archive the whole emerge dir and make that archive available for you?
What I am after is to determinate whatever we get a broken binary that fails every single time, or we do have a binary that might fail depending on some external factors. For 2nd one it will be worth to investigate how it is built, and for 2nd one, only following it up with upstream would make sense. For me this is a phantom bug that you seems started to hit recently but is not 100% reproducible. I have no idea how to move forward with it otherwise. Open for suggestions. FWIW the golang binary will be static regardless so perhaps a hook in your scripts to copy the particular build directory out of portage TMPDIR on failure if PN == rclone would be enough? I do not want to inconvenience you, looking for simplest way to get the binary in question.
not a big deal (https://github.com/toralf/tinderbox/commit/e4e0cf635b2c77fffb0e78923f2c3ab7c1c522df) - will see, what happened
Hey, let me know if you have the affected binary around that you could share with me, or just confirm yourself if the binary that failed during portage run, fails when you re-run it manually
Friendly reminder, let me know if you can supply me with the failing binary. I continue to be unable to reproduce this.
(In reply to Piotr Karbowski from comment #20) > Friendly reminder, let me know if you can supply me with the failing binary. > I continue to be unable to reproduce this. Hi Piotr - I do have the logic to keep those files still in place - but cannot reproduce that issue with current images :-/
In this case lets do the following. I will close this one as cannot reproduce and in case you will hit it again in future please reopen this bug and share the saved artifact. Thanks for adding the logic to keep the artifacts regardless.
