Created attachment 379288 [details] build.log I'm unable to emerge webkit-gtk since Ruby 2.0 segfaults in Source/JavaScriptCore/offlineasm/settings.rb during the compilation phase (backtrace available in attached build.log). I don't know why webkit-gtk is trying to use Ruby 2.0 rather than system's Ruby 1.9 that could be a workaround: emeric@longspeak ~ $ eselect ruby list Available Ruby profiles: [1] ruby19 (with Rubygems) * [2] ruby20 (with Rubygems)
emerge --info output: Portage 2.2.8-r1 (default/linux/ia64/13.0/desktop/gnome/systemd, gcc-4.7.3, glibc-2.17, 3.12.13-gentoo ia64) ================================================================= System uname: Linux-3.12.13-gentoo-ia64-Madison-with-gentoo-2.2 KiB Mem: 24989024 total, 22023424 free KiB Swap: 524272 total, 524272 free Timestamp of tree: Thu, 19 Jun 2014 22:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.2 app-shells/bash: 4.2_p45 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.6, 3.3.3 dev-util/cmake: 2.8.12.2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.13.4 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.7.3-r1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.13 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo my_ebuilds ACCEPT_KEYWORDS="ia64" ACCEPT_LICENSE="* -@EULA" CBUILD="ia64-unknown-linux-gnu" CFLAGS="-mtune=itanium2 -O2 -pipe" CHOST="ia64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-mtune=itanium2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://mirrors.linuxant.fr/distfiles.gentoo.org/" LANG="fr_FR.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/my_ebuilds" USE="X a52 aac acl acpi alsa berkdb branding bzip2 cairo cdda cdr cli colord cracklib crypt cups cxx dbus dri dts dvdr eds encode evo exif fam firefox flac fortran gdbm gif gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk ia64 iconv introspection ipv6 jpeg lcms ldap libnotify libsecret mad mng modules mp3 mp4 mpeg nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support qt4 readline sdl session socialweb spell ssl startup-notification svg systemd tcpd tiff truetype udev udisks unicode upower usb vorbis wxwidgets xcb xml xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
emerge -pqv output: [ebuild U ] net-libs/webkit-gtk-2.4.3 [2.2.6] USE="X%* egl geoloc gstreamer introspection libsecret opengl spell webgl (-aqua) -coverage -debug -gles2 (-jit) {-test} (-wayland)"
Created attachment 379290 [details] environment
Well, maybe there are two issues here: one ruby crashing and the other one that we should check if we are using ruby properly while building :S
See also https://bugs.gentoo.org/show_bug.cgi?id=444828
The usage of newer ruby is due to: if has_version "virtual/rubygems[ruby_targets_ruby21]"; then myconf="${myconf} RUBY=$(type -P ruby21)" elif has_version "virtual/rubygems[ruby_targets_ruby20]"; then myconf="${myconf} RUBY=$(type -P ruby20)" else myconf="${myconf} RUBY=$(type -P ruby19)" fi But I don't know what should we use alternatively to that :S
The option that looks better to me is to rely on /usr/bin/ruby instead of concrete version and rely on a pkg_pretend test for the ruby link if some day we need to skip a ruby version. That should make the ebuild a bit cleaner and also comply eselect setting. @gnome, @ruby, what do you think about that approach?
I see the same thing because my ruby21 and ruby22 are messed up (I only installed them for testing). Using the eselected version seems like a good idea to me. If we ever need a newer version, we can depend on what we need to prevent a situation where e.g. (my case) I have ruby21 installed but no 2.1 copy of rubygems.
The ruby team has introduced ruby-single.eclass to help with this situation. Please see https://devmanual.gentoo.org/eclass-reference/ruby-single.eclass/index.html for documentation and let us know if there are any questions about it.
*** Bug 504886 has been marked as a duplicate of this bug. ***
I don't know how to use ruby-single.eclass to help us with this logic in configure phase: local ruby_interpreter="" if has_version "virtual/rubygems[ruby_targets_ruby22]"; then ruby_interpreter="-DRUBY_EXECUTABLE=$(type -P ruby22)" elif has_version "virtual/rubygems[ruby_targets_ruby21]"; then ruby_interpreter="-DRUBY_EXECUTABLE=$(type -P ruby21)" elif has_version "virtual/rubygems[ruby_targets_ruby20]"; then ruby_interpreter="-DRUBY_EXECUTABLE=$(type -P ruby20)" else ruby_interpreter="-DRUBY_EXECUTABLE=$(type -P ruby19)" fi That is for passing to configure scripts the right ruby version
About the crash in Source/JavaScriptCore/offlineasm/settings.rb that I was initially reporting when compiling webkit-gtk with Ruby 2.0 in attachment #379288 [details], I ran git bisect on Ruby source code to find the offending commit. Well, it took me a considerable amount of time as many commits simply don't compile or segfaults so a lot of skips were necessary. In the end, one of the 3 following commits may be the first bad one: - 9d6dd89400847790875e7a60085530817dfb5541: merge revision(s) r44549: [Backport 9387] - 954b8281834fa095d53279a7effb1352aedc7f8c: merge revision(s) r40830,r40848: [Backport #8425] - 886142e8eecec4956b4f5d1d3fa8761dba1cd7d1: merge revision(s) r43942,r43957,r43975: [Backport #9187] It's worth forwarding them to Gentoo Ruby Team nevertheless as (i) it may remind something useful to someone with the knowledge to help fix the Ruby crash in settings.rb and (ii) there's little chance that a regression goes out on its own. And no, I still can't try with anything else than Ruby 1.9~2.0 at the moment, as Ruby 2.1 simply fails to emerge (see bug #561780). This is next on my to-do-list... If needed, complete git bisect log follows: git bisect start # bad: [c60c15f371a6d2f2e024ebd75ee9b3fefa7d7118] add tag v2_0_0_647 git bisect bad c60c15f371a6d2f2e024ebd75ee9b3fefa7d7118 # good: [a61ae804fe213c046c24b68a8994e000f8cb4c79] add tag v1_9_3_551 git bisect good a61ae804fe213c046c24b68a8994e000f8cb4c79 # skip: [99f8f14d89308c17d8e9e53e03dd5ead6984e7fc] * ext/bigdecimal/bigdecimal.c (rmpd_power_by_big_decimal): fix precision treatment errors. * test/bigdecimal/test_bigdecimal.rb: add tests for the above change. fix precision treatment errors. * ext/bigdecimal/bigdecimal.c (BigDecimal_power): precision argument should be optional for its compatibility. git bisect skip 99f8f14d89308c17d8e9e53e03dd5ead6984e7fc # skip: [64b7aa9e2f17b2f226dd1759bc99e8c273120a8c] * 2012-07-19 git bisect skip 64b7aa9e2f17b2f226dd1759bc99e8c273120a8c # good: [c12f69cbb6d8111d4ad0bb5bf70eb709ebb12c0a] * backport r39410 from trunk git bisect good c12f69cbb6d8111d4ad0bb5bf70eb709ebb12c0a # good: [4c2f2ffc02c9a8bff5750d754c5a6e8502ae3a64] merge revision(s) 42782,42799: [Backport #8902] git bisect good 4c2f2ffc02c9a8bff5750d754c5a6e8502ae3a64 # skip: [9bececb77cc14b5e3c4a2767d2d7e704ccc8127e] merge revision(s) 45015: [Backport #9657] git bisect skip 9bececb77cc14b5e3c4a2767d2d7e704ccc8127e # skip: [322b26795583a0b854e7b195e7f766bd479c0404] merge revision(s) 45979: [Backport #9847] git bisect skip 322b26795583a0b854e7b195e7f766bd479c0404 # bad: [cc9b047c9079ba90d34ae732a79b262b2dfb2754] * test/rexml/test_document.rb: fix typo (patch mistake). reported and patched by Jeremy Evans at [Bug #10439] git bisect bad cc9b047c9079ba90d34ae732a79b262b2dfb2754 # skip: [48b30d96281f83934d0de6d0449335fc7f855d6f] merge revision(s) r45101: git bisect skip 48b30d96281f83934d0de6d0449335fc7f855d6f # bad: [7e344b0b7b877fcf203ab29f56e417993fb4cb11] * regcomp.c, regexec.c: Optimization should be disabled not only for /(?<=x).*/ but also for /(?!x).*/. (merge r47598 partially. [Bug #9728]) git bisect bad 7e344b0b7b877fcf203ab29f56e417993fb4cb11 # skip: [2583078951f14a2df251ba7c27310f62e69269ad] merge revision(s) r45084: [Backport #9547] git bisect skip 2583078951f14a2df251ba7c27310f62e69269ad # good: [099f6676a1f896b1ab0eda1ba9cf3534952fe7d0] merge revision(s) r44878,r44879: [Backport #9483] git bisect good 099f6676a1f896b1ab0eda1ba9cf3534952fe7d0 # skip: [516f8f355e94dd716ac187e86a9bef2e26f1550b] merge revision(s) 45793: [Backport #9608] git bisect skip 516f8f355e94dd716ac187e86a9bef2e26f1550b # skip: [091c0753d7317c1d0d4047381ae955600f9d185f] revert r46667 and r46669 because they introduced SEGV on CentOS. see [Bug #9454] [Bug #9945] git bisect skip 091c0753d7317c1d0d4047381ae955600f9d185f # skip: [f38ceeacd6e5ed29fa50e2713c395d3a7732b564] merge revision(s) r44720: [Backport #9455] git bisect skip f38ceeacd6e5ed29fa50e2713c395d3a7732b564 # skip: [cfdeb2ef10d20347040af4ce42d858d7a25f7a83] merge revision(s) 45637: [Backport #9726] git bisect skip cfdeb2ef10d20347040af4ce42d858d7a25f7a83 # skip: [cd171e481ffaf1a5ebfe9b3e1c13ec12afbb6216] merge revision(s) 47153: [Backport #10127] git bisect skip cd171e481ffaf1a5ebfe9b3e1c13ec12afbb6216 # skip: [c339f208c4b304199ebed24cf9963e8d13eefa1f] merge revision(s) 45287:45290: [Backport #9600] git bisect skip c339f208c4b304199ebed24cf9963e8d13eefa1f # skip: [98e5eb6f394562b7bdae830424eda43f6b5f22f7] merge revision(s) 47090: [Backport #10114] git bisect skip 98e5eb6f394562b7bdae830424eda43f6b5f22f7 # skip: [712da8a819a417a3b3ae68154eef8a3e054de363] merge revision(s) 44474,44538,44539,44890,44896,45954: [Backport #8358] git bisect skip 712da8a819a417a3b3ae68154eef8a3e054de363 # skip: [c6816d074b89131797e842a312f302037bcfbb9c] merge revision(s) r41598,r45181: git bisect skip c6816d074b89131797e842a312f302037bcfbb9c # skip: [08e698d4df6f7147708e025ca25f48cb6b1c333d] merge revision(s) 46243,46244: [Backport #9882] [Backport #9883] git bisect skip 08e698d4df6f7147708e025ca25f48cb6b1c333d # bad: [47264c4e1ffbc34fdd83b8bada241990433d9ee3] merge revision(s) 46151,46165: [Backport #9865] git bisect bad 47264c4e1ffbc34fdd83b8bada241990433d9ee3 # skip: [4f3f77b9f23ef288640d8faa5edb870a55b28937] merge revision(s) 45529: [Backport #8182] git bisect skip 4f3f77b9f23ef288640d8faa5edb870a55b28937 # skip: [f8f3d6a49ec734d6ea3db4b02de84ed14cc5db1d] merge revision(s) r45220: git bisect skip f8f3d6a49ec734d6ea3db4b02de84ed14cc5db1d # skip: [05ebc662fb6e5fc95046714c6c638ffc0016023e] merge revision(s) 45562: [Backport #9727] git bisect skip 05ebc662fb6e5fc95046714c6c638ffc0016023e # skip: [854db4e8654717b86d3f455d6e874cd5ad6fd39d] * thread_pthread.c: fixed compile error on linux. git bisect skip 854db4e8654717b86d3f455d6e874cd5ad6fd39d # skip: [2a83260a3932f584b5cd3fccd879e562ab4c6737] fixed previous commit mistake. git bisect skip 2a83260a3932f584b5cd3fccd879e562ab4c6737 # skip: [750e2a7db7bf61b6e28c1472b106112f07048df4] merge revision(s) 44712,44715,44716,44722,44725,44726,44753: [Backport #9454] [Backport #9945] git bisect skip 750e2a7db7bf61b6e28c1472b106112f07048df4 # skip: [6eda5562f012483853bb409f0a6804be10f4b3b9] merge revision(s) 45520: [Backport #9706] git bisect skip 6eda5562f012483853bb409f0a6804be10f4b3b9 # skip: [6491028d5b64da1e0a27d9017ca00b4da8ce94a8] merge revision(s) 46233: [Backport #9878] git bisect skip 6491028d5b64da1e0a27d9017ca00b4da8ce94a8 # skip: [77443b2882081392f63bffa2be0f65aac21c2a8d] merge revision(s) 45534: [Backport #9709] git bisect skip 77443b2882081392f63bffa2be0f65aac21c2a8d # bad: [4e057b91576ce7be07c9f76ac9ab51b6e0b1fb15] merge revision(s) 46098: [Backport #9861] git bisect bad 4e057b91576ce7be07c9f76ac9ab51b6e0b1fb15 # skip: [0cc54369d76631b77cded2f5491cdaeb30d33ef0] merge revision(s) r45271: [Backport #9592] [Backport #9670] git bisect skip 0cc54369d76631b77cded2f5491cdaeb30d33ef0 # good: [257ec8c9afd3cfc6e191a582d42390ce83f53c1e] merge revision(s) r44696: [Backport #9429] git bisect good 257ec8c9afd3cfc6e191a582d42390ce83f53c1e # skip: [3041f2156eae5dbcbe14562b6eef9389c9c50bdd] merge revision(s) r42230,r42231: [Backport #9651] git bisect skip 3041f2156eae5dbcbe14562b6eef9389c9c50bdd # skip: [674b2526650f317a5a836130631651dbdb019913] merge revision(s) 45863,45871: [Backport #9750] git bisect skip 674b2526650f317a5a836130631651dbdb019913 # skip: [da20411b5127108f83188dbb7ca7a150687010c0] merge revision(s) 45518: [Backport #9702] git bisect skip da20411b5127108f83188dbb7ca7a150687010c0 # good: [89424b13b077e3c88d618f253f07607aecbaecc5] merge revision(s) 44772: [Backport #9430] git bisect good 89424b13b077e3c88d618f253f07607aecbaecc5 # skip: [5d53e5b7db12f7f82fbd7dcd3f9e83b7809cd690] merge revision(s) r45374: [Backport #8405] git bisect skip 5d53e5b7db12f7f82fbd7dcd3f9e83b7809cd690 # bad: [1e14391978ea5da3f86d58b664ce91f86fc0694d] merge revision(s) r40833: git bisect bad 1e14391978ea5da3f86d58b664ce91f86fc0694d # skip: [886142e8eecec4956b4f5d1d3fa8761dba1cd7d1] merge revision(s) r43942,r43957,r43975: [Backport #9187] git bisect skip 886142e8eecec4956b4f5d1d3fa8761dba1cd7d1 # good: [bdcadb8c440f16e132d34addfa83fb4d956cb48d] merge revision(s) r44514: [Backport #9374] git bisect good bdcadb8c440f16e132d34addfa83fb4d956cb48d # skip: [954b8281834fa095d53279a7effb1352aedc7f8c] merge revision(s) r40830,r40848: [Backport #8425] git bisect skip 954b8281834fa095d53279a7effb1352aedc7f8c # bad: [9d6dd89400847790875e7a60085530817dfb5541] merge revision(s) r44549: [Backport #9387] git bisect bad 9d6dd89400847790875e7a60085530817dfb5541 # good: [37e3fd88020a7259ddc027b22bbad0e91c67ed65] merge revision(s) r44628: [Backport #9413] git bisect good 37e3fd88020a7259ddc027b22bbad0e91c67ed65 # only skipped commits left to test # possible first bad commit: [9d6dd89400847790875e7a60085530817dfb5541] merge revision(s) r44549: [Backport #9387] # possible first bad commit: [954b8281834fa095d53279a7effb1352aedc7f8c] merge revision(s) r40830,r40848: [Backport #8425] # possible first bad commit: [886142e8eecec4956b4f5d1d3fa8761dba1cd7d1] merge revision(s) r43942,r43957,r43975: [Backport #9187] Émeric
I think this can be closed now. Ruby 2.0 is masked and webkit-gtk uses ruby-single.eclass.
(In reply to James Le Cuirot from comment #13) > I think this can be closed now. Ruby 2.0 is masked and webkit-gtk uses > ruby-single.eclass. The bug's still there. The ebuild loops through a list of implementations, trying them in order: local ruby_interpreter="" if has_version "virtual/rubygems[ruby_targets_ruby23]"; then ruby_interpreter="RUBY=$(type -P ruby23)" elif has_version "virtual/rubygems[ruby_targets_ruby22]"; then ruby_interpreter="RUBY=$(type -P ruby22)" elif has_version "virtual/rubygems[ruby_targets_ruby21]"; then ruby_interpreter="RUBY=$(type -P ruby21)" else ruby_interpreter="RUBY=$(type -P ruby20)" fi If anything, it should try them in the same order as RUBY_TARGETS_PREFERENCE, omitting those that are not in USE_RUBY. Otherwise the ruby-single eclass might add a dependency on ruby21 while webkit-gtk gets the absolute path to ruby23. However, does webkit-gtk even care which ruby interpreter you're using? If not, just point it at /usr/bin/ruby, and then let the eclass pull in some supported version of ruby.
We only need ruby at buildtime, and ruby-json and ruby-highline additionally for test suite. Or at least whatever these debian packages happen to install over there (rubygem-json and rubygem-highline in case of fedora for the testsuite). It's doing some sort of preprocessing with ruby during the build or something.
Created attachment 460496 [details, diff] Patch that iterates over RUBY_TARGETS_PREFERENCE (In reply to Michael Orlitzky from comment #14) > (In reply to James Le Cuirot from comment #13) > > I think this can be closed now. Ruby 2.0 is masked and webkit-gtk uses > > ruby-single.eclass. > > The bug's still there. The ebuild loops through a list of implementations, > trying them in order: Ah! That explains why I couldn't get Ruby 2.4 to work. I was looking so closely at CMake that I didn't notice what was in the ebuild. D'oh. > If anything, it should try them in the same order as > RUBY_TARGETS_PREFERENCE, omitting those that are not in USE_RUBY. Otherwise > the ruby-single eclass might add a dependency on ruby21 while webkit-gtk > gets the absolute path to ruby23. The order doesn't matter as any variant given in USE_RUBY should work. USE_RUBY may end up containing variants that are no longer supported though (like ruby20) and we should probably avoid those. How about this patch? It's not against all the ebuilds but it includes the autotools and CMake versions. > However, does webkit-gtk even care which ruby interpreter you're using? If > not, just point it at /usr/bin/ruby, and then let the eclass pull in some > supported version of ruby. /usr/bin/ruby could point to JRuby or Rubinius. These may work but I doubt anyone wants to keep testing that.
(In reply to James Le Cuirot from comment #16) > > > If anything, it should try them in the same order as > > RUBY_TARGETS_PREFERENCE, omitting those that are not in USE_RUBY. Otherwise > > the ruby-single eclass might add a dependency on ruby21 while webkit-gtk > > gets the absolute path to ruby23. > > The order doesn't matter as any variant given in USE_RUBY should work. > USE_RUBY may end up containing variants that are no longer supported though > (like ruby20) and we should probably avoid those. How about this patch? It's > not against all the ebuilds but it includes the autotools and CMake versions. > There used to be a fallback case, else ruby_interpreter="-DRUBY_EXECUTABLE=$(type -P ruby20)" that gets accepted regardless of whether or not you have virtual/rubygems[ruby_targets_ruby20] installed. What happens now? For example, virtual/rubygems now has ruby24 support. If I set RUBY_TARGETS=ruby24 and install virtual/rubygems, then the "virtual/rubygems" dependency added by ruby-single.eclass will be satisfied. However, if I try to emerge webkit-gtk, it will loop through ruby20 through ruby23 looking for virtual/rubygems[ruby_targets_$ruby]. It won't find one, because ruby24 isn't in the list, and nothing in DEPEND requires it to be there. As a result the ebuild won't choose ANY ruby interpreter. You could set a default interpreter, for example local ruby_interpreter=/usr/bin/ruby21 but then you don't know that virtual/rubygems[ruby_targets_ruby21] will be there, because it isn't in DEPEND. Your patch is an improvement, but this ebuild still ain't right. It all might be a lot simpler without the ruby eclasses involved. What it's trying to accomplish isn't that complicated. All we need is -- at build time -- some ruby interpreter and virtual/rubygems built with support for it. You can do that with a big "or" clause in DEPEND: || ( (ruby 2.0 and rubygems with 2.0 support) (ruby 2.1 and rubygems with 2.1 support) ... Then when you're looping through the list and searching for an interpreter that will work, you're guaranteed to find one.
(In reply to Michael Orlitzky from comment #17) > (In reply to James Le Cuirot from comment #16) > > > > > If anything, it should try them in the same order as > > > RUBY_TARGETS_PREFERENCE, omitting those that are not in USE_RUBY. Otherwise > > > the ruby-single eclass might add a dependency on ruby21 while webkit-gtk > > > gets the absolute path to ruby23. > > > > The order doesn't matter as any variant given in USE_RUBY should work. > > USE_RUBY may end up containing variants that are no longer supported though > > (like ruby20) and we should probably avoid those. How about this patch? It's > > not against all the ebuilds but it includes the autotools and CMake versions. > > > > There used to be a fallback case, > > else > ruby_interpreter="-DRUBY_EXECUTABLE=$(type -P ruby20)" > > that gets accepted regardless of whether or not you have > virtual/rubygems[ruby_targets_ruby20] installed. What happens now? This was bad because chances are you wouldn't have ruby20. It would pass -DRUBY_EXECUTABLE= and CMake's check would fail. Now it just won't pass this argument at all, falling back to CMake's own detection. This isn't great either but at least it has a chance of working. What else can you do? With my patch now using USE_RUBY, this shouldn't happen anyway unless the system is in some weird state. > For example, virtual/rubygems now has ruby24 support. If I set > RUBY_TARGETS=ruby24... RUBY_TARGETS isn't used by ruby-single. If you meant RUBY_TARGETS_PREFERENCE then this isn't a user variable. It is always reset by ruby-utils.
(In reply to James Le Cuirot from comment #18) > > > For example, virtual/rubygems now has ruby24 support. If I set > > RUBY_TARGETS=ruby24... > > RUBY_TARGETS isn't used by ruby-single. If you meant RUBY_TARGETS_PREFERENCE > then this isn't a user variable. It is always reset by ruby-utils. The clear example that I wanted to give was if I emerged virtual/rubygems without support for *any* ruby interpreter, but that doesn't work because of a REQUIRED_USE constraint. So setting RUBY_TARGETS=ruby24 is just my way to get a useless rubygems installed -- one that will still satisfy the dependency in ruby-single.eclass. I still think your patch is an improvement, but it would be better to have exactly what is needed in DEPEND. The whole point of that ruby24 example was that DEPEND is wrong for webkit-gtk, so you can find a way to trip it up even after the patch. I haven't tested this, but here's what I would try. First, drop ruby-single.eclass and the USE_RUBY and RUBY_DEPS variables. Then set DEPEND to what we actually want it to be: # Require any ruby implementation, and then a rubygems built with # support for that implementation. We rely on the fact that, for # example, ruby:2.1 is an RDEPEND of virtual/rubygems[ruby_targets_ruby21] # to simplify this a bit and omit the dev-lang/ruby deps. DEPEND+="|| (" for rubyimpl in ${RUBY_TARGETS_PREFERENCE}; do DEPEND+=" virtual/rubygems[ruby_targets_$rubyimpl]" done DEPEND+=" )" unset rubyimpl Then in src_configure(), use your loop: local ruby_interpreter="" # If rubygems is built with support for a particular interpreter, # that interpreter should be there. for rubyimpl in ${RUBY_TARGETS_PREFERENCE}; do if has_version "virtual/rubygems[ruby_targets_${rubyimpl}]"; then ruby_interpreter="-DRUBY_EXECUTABLE=/usr/bin/$rubyimpl" break fi done [[ -z "$ruby_interpreter" ]] && die "no working ruby interpreter found"
(In reply to Michael Orlitzky from comment #19) > (In reply to James Le Cuirot from comment #18) > > > > > For example, virtual/rubygems now has ruby24 support. If I set > > > RUBY_TARGETS=ruby24... > > > > RUBY_TARGETS isn't used by ruby-single. If you meant RUBY_TARGETS_PREFERENCE > > then this isn't a user variable. It is always reset by ruby-utils. > > The clear example that I wanted to give was if I emerged virtual/rubygems > without support for *any* ruby interpreter, but that doesn't work because of > a REQUIRED_USE constraint. So setting RUBY_TARGETS=ruby24 is just my way to > get a useless rubygems installed -- one that will still satisfy the > dependency in ruby-single.eclass. Okay, I think I get you now but it's still not stacking up. The various dev-lang/ruby SLOTs are added to DEPEND. Each of these have a PDEPEND on virtual/rubygems[ruby_targets_rubyXX] so it's not possible to have a Ruby version installed that satisfies USE_RUBY without a corresponding virtual/rubygems. Have you actually seen this break? > I still think your patch is an improvement, but it would be better to have > exactly what is needed in DEPEND. The whole point of that ruby24 example was > that DEPEND is wrong for webkit-gtk, so you can find a way to trip it up > even after the patch. Even if it is broken, I think the right thing to do would be to fix to DEPEND string added by ruby-single so that it looks something like this. If it's not broken then we should leave it as it is. || ( ( dev-lang/ruby:2.1 virtual/rubygems[ruby_targets_ruby21] ) ( dev-lang/ruby:2.2 virtual/rubygems[ruby_targets_ruby22] ) ( dev-lang/ruby:2.3 virtual/rubygems[ruby_targets_ruby23] ) )
(In reply to James Le Cuirot from comment #20) > (In reply to Michael Orlitzky from comment #19) > > (In reply to James Le Cuirot from comment #18) > > > > > > > For example, virtual/rubygems now has ruby24 support. If I set > > > > RUBY_TARGETS=ruby24... > > > > > > RUBY_TARGETS isn't used by ruby-single. If you meant RUBY_TARGETS_PREFERENCE > > > then this isn't a user variable. It is always reset by ruby-utils. > > > > The clear example that I wanted to give was if I emerged virtual/rubygems > > without support for *any* ruby interpreter, but that doesn't work because of > > a REQUIRED_USE constraint. So setting RUBY_TARGETS=ruby24 is just my way to > > get a useless rubygems installed -- one that will still satisfy the > > dependency in ruby-single.eclass. > > Okay, I think I get you now but it's still not stacking up. The various > dev-lang/ruby SLOTs are added to DEPEND. Each of these have a PDEPEND on > virtual/rubygems[ruby_targets_rubyXX] so it's not possible to have a Ruby > version installed that satisfies USE_RUBY without a corresponding > virtual/rubygems. Have you actually seen this break? Hmm, I may need to take that back. I'm surprised that Portage doesn't complain below or at least uninstall 2.4. It only complains if you add dev-lang/ruby or dev-lang/ruby:2.4 to the list. Do we need to support such odd system states though? I don't know how likely this is to happen in practise. $ RUBY_TARGETS="ruby23" emerge -p virtual/rubygems These are the packages that would be merged, in order: Calculating dependencies ... ... done! [ebuild NS ] dev-lang/ruby-2.3.3-r1 [2.4.0] USE="berkdb gdbm ipv6 ncurses readline ssl -debug -doc -examples -jemalloc -libressl -rdoc -rubytests -socks5 -tk -xemacs" [ebuild R ] dev-ruby/rubygems-2.6.8 RUBY_TARGETS="ruby23* -ruby24*" [ebuild R ] virtual/rubygems-12 RUBY_TARGETS="ruby23* -ruby24*" [ebuild NS ] dev-ruby/did_you_mean-1.0.2 [1.1.0] USE="{-test}" RUBY_TARGETS="ruby23" [ebuild R ] dev-ruby/power_assert-0.4.1 RUBY_TARGETS="ruby23* -ruby24*" [ebuild R ] dev-ruby/rake-12.0.0 RUBY_TARGETS="ruby23* -ruby24*" [ebuild R ] dev-ruby/test-unit-3.2.3 RUBY_TARGETS="ruby23* -ruby24*" [ebuild R ] dev-ruby/minitest-5.10.1 RUBY_TARGETS="ruby23* -ruby24*" [ebuild R ] dev-ruby/json-2.0.3 RUBY_TARGETS="ruby23* -ruby24*" [ebuild R ] dev-ruby/net-telnet-0.1.1-r1 RUBY_TARGETS="ruby23* -ruby24*"
(In reply to James Le Cuirot from comment #20) > > > > The clear example that I wanted to give was if I emerged virtual/rubygems > > without support for *any* ruby interpreter, but that doesn't work because of > > a REQUIRED_USE constraint. So setting RUBY_TARGETS=ruby24 is just my way to > > get a useless rubygems installed -- one that will still satisfy the > > dependency in ruby-single.eclass. > > Okay, I think I get you now but it's still not stacking up. The various > dev-lang/ruby SLOTs are added to DEPEND. Each of these have a PDEPEND on > virtual/rubygems[ruby_targets_rubyXX] so it's not possible to have a Ruby > version installed that satisfies USE_RUBY without a corresponding > virtual/rubygems. Have you actually seen this break? I haven't actually tried *any* of this stuff =P I didn't see the PDEPEND, but the PDEPENDs of dev-lang/ruby don't have to be installed before webkit-gtk if dev-lang/ruby gets pulled in by webkit-gtk. Suppose I have ruby:2.4 and virtual/rubygems[ruby_targets_ruby24] installed. I go to install webkit-gtk, and it pulls in (say) dev-lang/ruby:2.1 as the preferred version. I have virtual/rubygems already, so the eclass RUBY_DEPS are satisfied, but virtual/rubygems[ruby_targets_ruby21] only gets installed at some later point before the "batch of installs" has finished. Quite possibly (and more important, legally) after we attempt to install webkit-gtk. In that case webkit-gtk won't find a working ruby interpreter. > Even if it is broken, I think the right thing to do would be to fix to > DEPEND string added by ruby-single You're on to something there, but fixing the eclass requires a new eclass revision and however many new ebuild revisions whereas fixing webkit-gtk requires only a single ebuild revision =)
(In reply to James Le Cuirot from comment #21) > > Hmm, I may need to take that back. I'm surprised that Portage doesn't > complain below or at least uninstall 2.4. It only complains if you add > dev-lang/ruby or dev-lang/ruby:2.4 to the list. Do we need to support such > odd system states though? I don't know how likely this is to happen in > practise. > Problems are rare now, but we have a lot of users, and we attract people who do weird stuff. It isn't too cumbersome to add the correct deps in DEPEND, so why not just add them and not have to worry? (I support the idea of changing the eclass deps if that makes sense to the ruby team, but that's more of a summer project than a quick fix.)
(In reply to Michael Orlitzky from comment #22) > You're on to something there, but fixing the eclass requires a new eclass > revision and however many new ebuild revisions whereas fixing webkit-gtk > requires only a single ebuild revision =) There are only 19 ebuilds across 12 packages in the main repository using ruby-single, plus 1 more in the Ruby overlay. Even then, I question whether this really warrants an eclass bump. I'm vaguely familiar with the rule. In this case, we're not removing a dependency, so nothing will be held back from --depclean. Packages already installed may be currently broken at runtime but they will probably work again as soon as any one package pulls in the correct rubygems flags. In short, changing this without an eclass bump isn't going to break anything that isn't already broken.
Just in case, I'm restating what we, the webkit-gtk maintainers, would like to see: some ruby eclass that provides us what python-any-r1 does. We just need a ruby installation with some select components that must work at build time in a specified list of slots. I sort of remember that ruby:1.8 got unusable at some point in time to build webkit-gtk or maybe the build system was not ruby:2.1 ready, but the important thing to remember is that forward or backward compatibility is not guaranteed and we cannot just use whatever happens to be currently /usr/bin/ruby, just like build systems using python. If we could avoid writing that logic in the ebuild, that would be nice.
(In reply to Gilles Dartiguelongue from comment #25) > Just in case, I'm restating what we, the webkit-gtk maintainers, would like > to see: some ruby eclass that provides us what python-any-r1 does. The ruby-single eclass is almost what you want, but it can't be changed without a) affecting the stable ebuilds using it and b) changing metadata that's not allowed to change without a revision bump, so you're waiting on a new eclass revision if anything. But, you're pulling in two eclasses for like three lines of code. You need the loop that checks for interpreters anyway, so all you're really getting is the RUBY_DEPS which, when it comes down to it, is constructed entirely from your USE_RUBY and not from anything in the eclass. You don't even need ruby-utils.eclass, just list the ruby implementations you use in order of preference: DEPEND+=$(echo "|| (" virtual/rubygems[ruby_targets_ruby2{1,2,3}] ")") Then when you're checking for interpreters, do them in the same order: for rubyimpl in ruby2{1,2,3}; etc. Same number of lines, two fewer eclasses, and best of all: it actually works =)
Created attachment 461282 [details, diff] Patch that adds and uses ruby_single_implementation_command helper Here's my new suggestion for an eclass helper called ruby_single_implementation_command. This makes the ebuilds here and potentially others dead simple. I have simplified the dependency string to just virtual/rubygems[ruby_targets_rubyXX] as that is what we're really interested in. It gives the same result but won't tax Portage as much. Michael, you seem to have quite strong opinions about the bumping of eclasses. If we're aware of what the rules are and why they're in place then we can afford to be pragmatic. It wasn't that long ago that most developers were blissfully unaware of these issues but the sky didn't fall. :) If it's stable ebuilds you're concerned about then I'll gladly test all 7 of them. If you still insist on bumping then we may as well start as we mean to go on. We'll have to revbump the older webkit-gtk SLOTs to use the new helper either way. Ruby team should really have the final say though.
I'm not in a position to insist on anything. I don't maintain webkit-gtk or the ruby eclass, and in order of preference, * I would like things to be fixed perfectly * I would like things to be fixed which sometimes means I have to settle for the second option, given that everyone is working on what they want when they want and for free. The council ruled (20151011) that you shouldn't change dependencies without a revision. If you do, the recorded dependencies in /var/db/pkg won't agree with the ones in the tree, and it can break dependency resolution. It can also trick developers into doing things that aren't safe, because they don't see the deps that were there for years before being silently changed. Perhaps most importantly, it can waste both user and developer time trying to debug problems that are impossible to track down; for example if the user and I have different dependencies listed in /var/db/pkg but don't know it. Those sorts of problems are only fixed by emerge -e @world, and that wastes more of somebody's time. The council decision basically says that you can't break things if the package manager were to use the deps listed in /var/db/pkg. For webkit-gtk, it doesn't matter too much because the dependency is at build-time. But if any of the other consumers of ruby-single.eclass use RUBY_DEPS in RDEPEND, then by making the change without a revision bump, you deprive them of the corresponding update to /var/db/pkg.
I took a stab at the issue at https://github.com/gentoo/gentoo/pull/9271 , mostly inspired by mjo's comment #19. I use USE_RUBY instead of RUBY_TARGETS_PREFERENCES so that we only loop through ruby implementations explicitly supported by webkit-gtk rather than implementations supported by the system. What do you think?
(In reply to Virgil Dupras from comment #29) > I took a stab at the issue at https://github.com/gentoo/gentoo/pull/9271 , > mostly inspired by mjo's comment #19. I use USE_RUBY instead of > RUBY_TARGETS_PREFERENCES so that we only loop through ruby implementations > explicitly supported by webkit-gtk rather than implementations supported by > the system. You can honour both variables, which is what my implementation does. Having a helper for this makes for simpler ebuilds all round, it's just a question of whether there is an eclass bump of not.
Re-assigning to ruby@, as we will until any ruby eclass updates have our own solution in ebuild, so nothing for us to do. There is another bug open for supporting ruby25, which will be fixed very soon. To re-iterate - for webkit-gtk we just need any (compatible) ruby version in build depends, AND in src_configure know what it actually picked. As we don't have that, we just roll our own code to just has_version check the best version available and then use that (path from type -P, which is probably not ideal) to pass to the build system as we need. Personally I'm not convinced "eclass ruby" should be affecting what the package manager uses. And if it does, it should only be doing that if that version is even in supported ruby versions for the given ebuild.
(In reply to Mart Raudsepp from comment #31) > Personally I'm not convinced "eclass ruby" should be affecting Err, I of course meant "eselect ruby". (In reply to Hans de Graaff from comment #9) > The ruby team has introduced ruby-single.eclass to help with this situation. > Please see > https://devmanual.gentoo.org/eclass-reference/ruby-single.eclass/index.html > for documentation and let us know if there are any questions about it. No, ruby-single.eclass alone is not sufficient here at all. It does not handle the aspect of running things at all, like python-single-r1 does via $EPYTHON and co. We are already using it for getting the DEPEND, though. ruby@ - some comments on the topic please.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5721aab07bc4778c8667ca9ff8a330eae5d41b2c commit 5721aab07bc4778c8667ca9ff8a330eae5d41b2c Author: Virgil Dupras <vdupras@gentoo.org> AuthorDate: 2018-07-18 13:05:47 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2018-07-23 22:23:37 +0000 net-libs/webkit-gtk: add support for ruby25 Also, improve ruby interpreter detection logic. Closes: https://bugs.gentoo.org/659130 Bug: https://bugs.gentoo.org/513888 Package-Manager: Portage-2.3.40, Repoman-2.3.9 net-libs/webkit-gtk/webkit-gtk-2.20.3.ebuild | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
Essentially we seem to want the equivalent of python-any-r1.eclass (which gives us $EPYTHON that we can use to pick or force a given version)
Any fixes on this eons old bug?
*** Bug 554560 has been marked as a duplicate of this bug. ***
