: SUCCESS * Waiting for unfinished parallel jobs ... [ ok ] * chmod +x ./bin/nim * ./bin/nim compile -d:release koch * ./koch boot -d:nimUseLinenoise -d:release --skipParentCfg:off /var/tmp/portage/dev-lang/nim-2.2.0/temp/environment: line 701: ./koch: No such file or directory * ERROR: dev-lang/nim-2.2.0::gentoo failed (compile phase): * Failed to run command: ./koch boot -d:nimUseLinenoise -d:release --skipParentCfg:off ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_desktop_gnome-20241006-183956 UNMASKED: /etc/portage/package.unmask/60gcc:<sys-devel/gcc-15.0.9999:15 Requested by sam Issues involving opaque types / incomplete typedefs should block bug 930805 /etc/portage/package.unmask/50unstable:>=sys-libs/ncurses-6.5 Block bug #351559 if this looks like a parallel build issue. The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- GNUMAKEFLAGS="$GNUMAKEFLAGS --shuffle" gcc-config -l: [1] x86_64-pc-linux-gnu-15 * clang/llvm (if any): clang version 19.1.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/19/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/19 19.1.1 Python 3.12.7 Available Ruby profiles: [1] ruby32 (with Rubygems) [2] ruby33 (with Rubygems) * Available Rust versions: [1] rust-bin-1.81.0 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 11.0.24_p8 [openjdk-bin-11] 2) Eclipse Temurin JDK 17.0.12_p7 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.4_p7 [openjdk-bin-21] 4) Eclipse Temurin JDK 8.422_p05 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-11 [3] openjdk-bin-17 [4] openjdk-bin-21 system-vm The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): [1] php8.3 * go version go1.23.1 linux/amd64 HEAD of ::gentoo commit a469c3faac9a3f2e6da8bcb9e9309e9eedf426a6 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sun Oct 13 13:48:20 2024 +0000 2024-10-13 13:48:19 UTC emerge -qpvO =dev-lang/nim-2.2.0 [ebuild N ] dev-lang/nim-2.2.0 USE="test-js -test"
Created attachment 905672 [details] emerge-info.txt
Created attachment 905673 [details] dev-lang:nim-2.2.0:20241013-143527.log
Created attachment 905674 [details] emerge-history.txt
Created attachment 905675 [details] environment
Created attachment 905676 [details] etc.clang.tar.xz
Created attachment 905677 [details] etc.portage.tar.xz
Created attachment 905678 [details] qlist-info.txt.xz
The file size of ./files/temp.tar.xz is too big (1.4M) for an upload. For few weeks the link http://tinderbox.zwiebeltoralf.de:31560/23.0_desktop_gnome-20241006-183956/var/tmp/tb/issues/20241013-143638-dev-lang_nim-2.2.0/files/temp.tar.xz is valid.
The nim-2.2.0-r100 ebuild from my repository does not have this problem. Maybe the maintainer can copy it fully, this time, instead of assuming he knows better: https://github.com/stefantalpalaru/gentoo-overlay
(In reply to Ștefan Talpalaru from comment #9) > The nim-2.2.0-r100 ebuild from my repository does not have this problem. > Maybe the maintainer can copy it fully, this time, instead of assuming he > knows better: https://github.com/stefantalpalaru/gentoo-overlay why so passive passive-aggressive? 1st of all this bug is impossible to reproduce for me. I have never encountered this issue. Ștefan, have you been able to reproduce this? > Maybe the maintainer can copy it fully Differences between YOUR ebuild impl and the one in ::gentoo are big they need a careful review. Since I can not repro this bug I will never know that MAGIC you did that it would have started to work on the Gentoo CI.
> why so passive passive-aggressive? "This ebuild is a slightly regreshed version written by Stefan Talpalaru." - https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8c46ca63853a3da95a58f5488130294ee0f1c8a0 > Ștefan, have you been able to reproduce this? No, since I only use my own Nim ebuilds. > Differences between YOUR ebuild impl and the one in ::gentoo are big they need a careful review. Or you can just do as I say and copy it fully, this time. I have intimate knowledge of Nim's build system, after working with it for years.
(In reply to Ștefan Talpalaru from comment #11) > > why so passive passive-aggressive? > > "This ebuild is a slightly regreshed version written by Stefan Talpalaru." - > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=8c46ca63853a3da95a58f5488130294ee0f1c8a0 Well, this is awkward, there has been a big misunderstanding. I have never seen this commit as the one who committed this was not me :). The history of Nim in Gentoo is such that it got abandoned (by the "committer") and then picked up by a (other) proxy-maint joined some time after by me (when I was interested with Nim). Later I was left alone with the Nim Project to take care of. So, please excuse me for not having had any knowledge of this commit. > I have intimate knowledge of Nim's build system, after working with it for years. So could you say what is happening here. This bug looks to me like a issue with GNU use of parallel.
> This bug looks to me like a issue with GNU use of parallel. Of course it's GNU Parallel. You're trusting a generated script to run "sem --wait" for you - a strategy which clearly fails, since you have "sleep" in your ebuild to wait for "unfinished parallel jobs" that should not exist in the first place. Don't do that! Ideally, you should not execute "build.sh" at all (the makefile is more reliable), but if you insist on using it, drop "--parallel ...".
> Ideally, you should not execute "build.sh" at all (the makefile is more > reliable), but if you insist on using it, drop "--parallel ...". What about boot and tools below emake using --parallel? Im currently experimenting with switching from ./build.sh to (e)make. Yes, this is "based" from your ebuild which indeed uses the "emake" but you set CC=gcc which is NOT a thing we can do in the ::gentoo repo unless absolutely necessary. Second: you use sed when using patch is less error-prone. What im saying here is that this can be a joined cooperative work :). As I said, incorporating YOUR changes needs a in-depth review (mostly to conform with configuration changes we require in Gentoo official repo). Thus, i will NOT just copy your ebuild. Please, You can either submit a PR on Github to the Gentoo repo with your changes (and ping me) and we can review it together or we can review current ::gentoo ebuild and yours on either public (Gentoo's) nim project mailing list or private. Whichever you prefer. Lastly, thanks for letting me know about your repo and that you are into Nim ecosystem as you would have guessed I had no idea (since the commit you brought up I saw for the 1st time).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d08bff831f01ecab100ad13b25968915854db95f commit d08bff831f01ecab100ad13b25968915854db95f Author: Maciej Barć <xgqt@gentoo.org> AuthorDate: 2024-10-13 18:38:11 +0000 Commit: Maciej Barć <xgqt@gentoo.org> CommitDate: 2024-10-13 19:23:14 +0000 dev-lang/nim: use the makefile for initial compilation Closes: https://bugs.gentoo.org/941480 Closes: https://bugs.gentoo.org/940306 Signed-off-by: Maciej Barć <xgqt@gentoo.org> dev-lang/nim/files/nim-2.2.0-makefile.patch | 11 +++++++++++ dev-lang/nim/nim-2.0.8.ebuild | 27 +++++++++++++-------------- dev-lang/nim/nim-2.2.0.ebuild | 27 +++++++++++++-------------- 3 files changed, 37 insertions(+), 28 deletions(-)
