Created attachment 893685 [details] build.log Hi, on default/linux/amd64/23.0/split-usr profile, dev-ruby/msgpack fails during the install phase with the message: make: Entering directory '/tmp/portage/dev-ruby/msgpack-1.7.2/work/ruby31/msgpack-ruby-1.7.2/ext/msgpack' /usr/bin/mkdir -p . /tmp/portage/dev-ruby/msgpack-1.7.2/image/usr/lib64/ruby/gems/3.1.0/extensions/x86_64-linux/3.1.0/msgpack-1.7.2/msgpack make: /usr/bin/mkdir: No such file or directory And indeed, mkdir is found at /bin/mkdir and not at /usr/bin/mkdir. I had this same issue yesterday with other ruby packages but can’t remember which ones and since then some binary packages were released for them and they installed just fine that way.
Created attachment 893686 [details] emerge --info '=dev-ruby/msgpack-1.7.2::gentoo'
Created attachment 893687 [details] emerge -pqv '=dev-ruby/msgpack-1.7.2::gentoo'
Did you move between merged-usr and split-usr profiles? You mention binary packages, where they created on a system with /usr/bin/mkdir? As far as I can tell this path is recorded in /usr/lib64/ruby/3.1.0/x86_64-linux/rbconfig.rb and it should match what is found during configuration.
I did not move between merged-usr and split-usr profiles. I am using the binary packages advertised here[1]. I was using 17.1 profiles back then, and it may be possible that during the switch to 23.0 the process for building these packages switched from split-usr (the default for 17.1 profiles) to merged-usr (the default for 23.0 profiles). [1]: https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html
The binpkgs are built on a 23.0 merged-usr/default machine (by the official builder), but they should work on a split-usr 23.0 system. We might have to fix some Ruby stuff to hardcode /bin/mkdir instead of relying on a discovered path. We had to do this in a handful of other places.
Something like this seems to work (in line with the same mechanism for openbsd above it) but I'm sure this can be done more elegantly. :-) Suggestions welcome. --- a/configure.ac 2024-05-30 02:23:11.000000000 +0200 +++ b/configure.ac 2024-06-01 10:10:07.602924940 +0200 @@ -519,6 +519,10 @@ ac_cv_path_mkdir="mkdir" ]) +AS_CASE(["$target_os"],[*],[ + ac_cv_path_mkdir="mkdir" +]) + RUBY_PROG_MAKEDIRS AC_CHECK_PROG([DTRACE], [${ac_tool_prefix}dtrace], [${ac_tool_prefix}dtrace])
*** Bug 933224 has been marked as a duplicate of this bug. ***
(In reply to Hans de Graaff from comment #6) We could export it as a cache var in the ebuild instead (if it respects that). Otherwise, LGTM.
*** Bug 934123 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b44b0fcafd19906606035ec71f4f7498e0140999 commit b44b0fcafd19906606035ec71f4f7498e0140999 Author: Hans de Graaff <graaff@gentoo.org> AuthorDate: 2024-06-16 09:05:50 +0000 Commit: Hans de Graaff <graaff@gentoo.org> CommitDate: 2024-06-16 09:06:37 +0000 dev-lang/ruby: add 3.3.3 Also avoid a hard-coded path to mkdir in RbConfig. Bug: https://bugs.gentoo.org/932386 Signed-off-by: Hans de Graaff <graaff@gentoo.org> dev-lang/ruby/Manifest | 1 + dev-lang/ruby/files/3.3/012-mkdir-path.patch | 13 ++ dev-lang/ruby/ruby-3.3.3.ebuild | 294 +++++++++++++++++++++++++++ 3 files changed, 308 insertions(+)
*** Bug 935712 has been marked as a duplicate of this bug. ***
(In reply to Sam James from comment #8) > (In reply to Hans de Graaff from comment #6) > > We could export it as a cache var in the ebuild instead (if it respects > that). Otherwise, LGTM. I've now taken this approach in 3.3.4 and will backport this to the other slots. I'll leave the bug open until this is fixed in a stable version.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d2c53a72889d581e8cce9fee46d2534cca18bfe6 commit d2c53a72889d581e8cce9fee46d2534cca18bfe6 Author: Hans de Graaff <graaff@gentoo.org> AuthorDate: 2024-07-10 07:33:57 +0000 Commit: Hans de Graaff <graaff@gentoo.org> CommitDate: 2024-07-10 07:36:24 +0000 dev-lang/ruby: avoid hard-coded mkdir path Bug: https://bugs.gentoo.org/932386 Signed-off-by: Hans de Graaff <graaff@gentoo.org> dev-lang/ruby/ruby-3.1.6-r1.ebuild | 288 +++++++++++++++++++++++++++++++++++ dev-lang/ruby/ruby-3.2.4-r1.ebuild | 300 +++++++++++++++++++++++++++++++++++++ 2 files changed, 588 insertions(+)
For the record: I encountered the exact same bug with the package: dev-ruby/ffi also as was previously reported in the forums: https://forums.gentoo.org/viewtopic-t-1169620.html With package.accept_keywords as follows: =dev-lang/ruby-3.1.6-r1 ~amd64 =dev-lang/ruby-3.2.4-r1 ~amd64 I confirm that the commit mentioned in the previous comment fixes it. dev-ruby/ffi emerges properly. Thank you very much.
*** Bug 936544 has been marked as a duplicate of this bug. ***
I experience the same problem with dev-ruby/ffi and dev-ruby/sassc. Ruby version is 3.2.4 Works with dev-lang/ruby-3.2.4-r1
*** Bug 937951 has been marked as a duplicate of this bug. ***
Unfortunately putting =dev-lang/ruby-3.1.6-r1 ~amd64 =dev-lang/ruby-3.2.4-r1 ~amd64 in /etc/portage/package.accept_keywords/ruby did not the trick on my machine. It looks like there is still an old ruby31 installed: /usr/bin/ruby31 --version ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [x86_64-linux] Any ideas how I could update ruby31? An emerge -uDN dev-lang/ruby will only update ruby32
bug 936656 should be done soon which will sort it. In the meantime, you can try: emerge -v1 "dev-lang/ruby:3.1"?
Thanks - that did it :-) And now all packages could be updated. I didn't know this -v1 flag and even could not find it in the man pages - thanks for sharing it!
(In reply to Stephan Litterst from comment #20) > Thanks - that did it :-) Thanks for the confirmation. > I didn't know this -v1 flag and even could not find it in the man pages - > thanks for sharing it! That's shorthand for --oneshot --verbose. Explicitly adding the slot is what made this work.
