Created attachment 227498 [details] Patch ruby-gems 3.0.2 -> 3.2.26 The attached patch updates devel/ruby-gems to 3.2.26 (Latest available as of 2021-08-27). This obviates 256080 (the port will no longer be broken). I'm running gem installed from this port at work with Ruby 3.0, and on my personal box with Ruby 3.7 - seems to be working. Needs QA - in particular: The staging installed under /usr/local/bin/gem instead of /usr/local/bin/gem/${RUBY_VER_SHORT} I hacked the Makefile to move and symlink it so it behaves "properly" (the way it previously did) but I feel like I'm missing something stupidly obvious that's causing it to misbehave in the first place. The 3.2.26 install includes Bundler and bunch of Bundler-related "stuff" - I ripped that out of the packing list since we have sysutils/rubygem-bundler for this. It doesn't appear to break anything with gem's functionality and sysutils/rubygem-bundler installs cleanly with this updated port so I think my packing list is clean, but please sanity check me here.
...and re: my first QA note - I uploaded an old patch with "mv" instead of "${MV}" because I forgot to re-stage the Makefile :/ If my hack isn't necessary that line should be removed from the patch anyway.
This patch does not apply cleanly: [dvl@ava-pkg-02prd:/usr/dvl/ports-head/devel/ruby-gems] $ patch < ~/tmp/patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- b/devel/ruby-gems/Makefile |+++ b/devel/ruby-gems/Makefile -------------------------- Patching file Makefile using Plan A... Hunk #1 succeeded at 1. Hunk #2 failed at 19. 1 out of 2 hunks failed--saving rejects to Makefile.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- b/devel/ruby-gems/distinfo |+++ b/devel/ruby-gems/distinfo -------------------------- Patching file distinfo using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- b/devel/ruby-gems/pkg-plist |+++ b/devel/ruby-gems/pkg-plist -------------------------- Patching file pkg-plist using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 46. Hunk #3 succeeded at 69. Hunk #4 succeeded at 83. Hunk #5 succeeded at 105. Hunk #6 succeeded at 167. Hunk #7 failed at 186. 1 out of 7 hunks failed--saving rejects to pkg-plist.rej done
Hmm.... not sure if I cut a bad patch or head moved, but probably the former because I'm usually the one who screwed up when the computer yells. Updated patch (2021100501) incoming (also fixes my mv -> ${MV} as noted previously) - looks clean on my end with a pull from git about 5 minutes ago: $ patch < ~/rubygems-patch-2021100501 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/devel/ruby-gems/Makefile b/devel/ruby-gems/Makefile |index 8f6eceea3a04..278c7421e29d 100644 |--- a/devel/ruby-gems/Makefile |+++ b/devel/ruby-gems/Makefile -------------------------- Patching file devel/ruby-gems/Makefile using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 19. Hunk #3 succeeded at 58. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/devel/ruby-gems/distinfo b/devel/ruby-gems/distinfo |index b39eec5b0356..6d133abd58c2 100644 |--- a/devel/ruby-gems/distinfo |+++ b/devel/ruby-gems/distinfo -------------------------- Patching file devel/ruby-gems/distinfo using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/devel/ruby-gems/pkg-plist b/devel/ruby-gems/pkg-plist |index 3e04be24e353..fcae759bfae0 100644 |--- a/devel/ruby-gems/pkg-plist |+++ b/devel/ruby-gems/pkg-plist -------------------------- Patching file devel/ruby-gems/pkg-plist using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 46. Hunk #3 succeeded at 69. Hunk #4 succeeded at 83. Hunk #5 succeeded at 105. Hunk #6 succeeded at 167. Hunk #7 succeeded at 186. done
Created attachment 228469 [details] Patch ruby-gems 3.0.2 -> 3.2.26
Created attachment 228480 [details] list of orphans detected via poudriere testport (In reply to mikeg from comment #4) The new patch applies cleanly. There are a large amount of orphans detected during poudriere testport.
The crazy long list of bundler orphans are expected(ish) per my second QA note - I pulled these from the package in favor of the current status quo of "If you want bundler install sysutils/rubygem-bundler." since that was more current that what's packaged with gem. (The stuff it's staging under /wrkdir is also an artifact of building Bundler.) If you think it makes sense to install the Bundler that comes with gems instead to quiet the poudriere I can re-patch to pack Bundler and mark the two ports as conflicting - that might need a dependencies audit though. I could also have the Makefile clean all of this up in a post-install if you think that's sensible, seemed dirty to me though. If I could get it to stop building Bundler entirely it should be a clean packing list.
I agree with you, since we have rubygem-bundle, let's not use that. At persent, the port does not do that. Happy to test again.
If we try to update this port to 3.1 or later, we face two problems. The first one is that since 3.1 setup.rb doesn't check if DONT_USE_BUNDLER_FOR_GEMDEPS environment variable is set. It means we can't install RubyGems without installing bundler any more. But fortunately RubyGems and bundler are released in sync since RubyGems 3.2.0 and bundler 2.2.0. So we can avoid this problem by unifying devel/ruby-gems and sysutils/rubygem-bundler. The second one is that since 3.1 --destdir option of setup.rb has been broken. There are two report about it on upstream repository in GitHub. https://github.com/rubygems/rubygems/pull/2768 https://github.com/rubygems/rubygems/issues/3604 To make --destdir option work correctly both need to be fixed. Since the former is pull request, there is proposed patch to fix the problem. On the other hand, the latter is just issue report, and currently no patch is provided to fix it.
Created attachment 228666 [details] update to 3.2.29 Hello, I hope I'm not overstepping, but I'm currently looking into RubyGems 3.2 update too. I tried with version 3.2.29, with the original approach of removing bundler, but with as few manual changes as I could (since as noted, we cannot rely on `USE_BUNDLER_FOR_GEMDEPS' anymore). My detailed notes are in the patch, at the top. I usually test patches (such as this one) for weeks/months before submitting or publishing, but given that current RubyGems port is old, and that Ruby 3.1 will be out soon, I hoped that sharing this work could help. I have only tested a few dozens gems (half written by me), with `lang/ruby27' and `lang/ruby30' for now, but will continue testing over the next days. The most annoying issue from my point of view, is the new `%%GEMS_BASE_DIR%%/plugins' directory created when installing gem via the port system (during FreeBSD package build), I don't know how to handle this (gems ported with RubyGems 3.0.8 will generate a different package once `devel/ruby-gems' is updated to 3.2.29).
Created attachment 228667 [details] Workaround broken --destdir with bundler (In reply to Yasuhiro Kimura from comment #8) > The second one is that since 3.1 --destdir option of setup.rb has been broken. \ There are two report about it on upstream repository in GitHub. >· > https://github.com/rubygems/rubygems/pull/2768 > https://github.com/rubygems/rubygems/issues/3604 >· > To make --destdir option work correctly both need to be fixed. I looked into it, but only for a very short time. If I recall correctly, the new attached patch fix the "duplicated" dest dir in one of the paths, but there was a third dest dir issue in addition to those two already reported. Also, I'm worried that even if it get fixed, it will break shortly after (it happened multiple times in the past already, still for `--destdir' option. Some people (myself included) trying to fix it upstream in the past seems to have given up and now prefer to patch their port directly (especially because they don't have to support Windows too in this case).
(In reply to Thibault Jouan from comment #9) I tried your patch but it causes plist error as following if I build rubygem ports. ---------------------------------------------------------------------- =========================================================================== ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist Error: Orphaned: @dir %%GEMS_BASE_DIR%%/plugins ===> Checking for items in pkg-plist which are not in STAGEDIR ===> Error: Plist issues found. *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/rubygem-bundler =>> Error: check-plist failures detected ---------------------------------------------------------------------- Full build log of some rubygem ports. devel/rubygem-racc: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/130amd64-default/2021-10-14_14h31m09s/logs/rubygem-racc-1.5.2.log devel/rubygem-rdoc: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/130amd64-default/2021-10-14_14h28m43s/logs/rubygem-rdoc-6.3.2.log sysutils/rubygem-bundler: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/130amd64-default/2021-10-14_14h16m27s/logs/rubygem-bundler-2.2.28,1.log
(In reply to mikeg from comment #0) > The staging installed under /usr/local/bin/gem instead of /usr/local/bin/gem/${RUBY_VER_SHORT} > I hacked the Makefile to move and symlink it so it behaves "properly" (the way it previously did) but I feel like I'm missing something stupidly obvious that's causing it to misbehave in the first place. It's because of the new `--format-executable' option flag. This behavior was previously hard-coded, now it is configurable but it has the opposite behavior as before. The same thing happened in the past when `--regenerate-binstubs' was introduced, and now with `--regenerate-plugins' too. I didn't understood this part of your comment during my first read, and later I forgot about it when posting my patch, sorry about that.
Created attachment 228695 [details] update to 3.2.29 - with new plugins system handling (In reply to Yasuhiro Kimura from comment #11) > I tried your patch but it causes plist error as following if I build > rubygem ports. Thank you for testing the patch and your feedback. With that version of the patch, this error is expected. I didn't fully understand the issue at the time, but I worked on it and made progress. Here are my notes (full notes in the patch) about this specific issue: RubyGems reworked the plugins system (see upstream 27d786e8). There isn't a lot of info, but by looking at upstream change f5bd2fe0 we can guess that the idea is to generate wrappers in the new "global" plugins directory (${GEMS_BASE_DIR}/plugins) with code to require the actual plugin in the gem own directory. For example with the `yard' gem (`textproc/rubygem-yard' port): % cat /usr/local/lib/ruby/gems/2.7/plugins/yard_plugin.rb require_relative '../gems/yard-0.9.26/lib/rubygems_plugin.rb' We handle plugins like extensions: if the gem has no plugin, we remove the empty directory at the end of `do-install' target; if the gem has a plugin, we add it to the plist at the end of `gem-autoplist' target. Regarding the last part, in `gem-autoplist' target of `Mk/Uses/gem.mk' file, I kept the usage of find but there is only *one* file to find, maybe the path can be derived from the port name: with port `yard' path is `plugins/yard_plugin.rb'. But I'd need to check for special cases. With the new attached patch, the "new" plugin wrapper is automatically included in the plist, gets in the package built from the port, and RubyGems loads it successfully (I only tested with yard however for now).
(In reply to Thibault Jouan from comment #13) Thanks for quick fix. I confirmed build of rubygem ports succeeds with latest patch. Since updating this ports affects all rubygem ports in ports tree, It should be tested exp-run before committing.
I would like to ask for exp-run with attachment #228695 [details].
All ruby gems that have patches are failing.
(In reply to Antoine Brodin from comment #16) Thanks for exp-run. Would you please provide some build failure logs?
http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-minitar-cli-0.8_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-dm-types-1.2.2_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-shellplay-0.1.9_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-activesupport4-4.2.11.3.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-astrolabe-1.3.1_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-cf-uaa-lib-3.13.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-chef-provisioning-2.7.6_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-chronic_duration-0.10.6.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-cucumber-messages4-4.0.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-dynflow-1.6.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-faraday_middleware-aws-signers-v4-0.2.0.b_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-flipper-ui017-0.17.2_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-gettext-setup-0.34_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-gitlab-pygments.rb-0.5.4_3.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-kafo-6.4.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-mongo-2.15.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-ms_rest-0.7.6.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-opt_parse_validator-1.9.3_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-pleaserun-0.0.32.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-pry-byebug-3.9.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-rash-0.4.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-rubygems-mirror-1.3.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-ruport-1.7.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-sidekiq5-5.2.9.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-sidetiq-0.7.2_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-spring-watcher-listen-2.0.1_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-terrapin-0.6.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-tilt1-1.4.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-travis-1.10.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-tty-0.10.0_10.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-turn-0.9.7_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-fission-0.5.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-lolcat-100.0.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-gitlab_emoji-0.3.1_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-goocanvas-2.2.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-net-imap-0.2.2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-net-pop-0.1.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-net-smtp-0.2.2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-vmail-2.9.8_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-lita-4.8.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-oxidized-0.28.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-riemann-client-0.2.6_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-riemann-dash-0.2.14.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-amqp-utils-0.5.1_5.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-grpc130-1.30.2_3.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-twitter-7.0.0_3.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-twitter-stream-0.1.16_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-chef-16.14.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-chef15-15.15.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-choria-mcorpc-support-2.25.2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-fluentd-1.14.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-specinfra-2.82.16.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-gitlab-grit-2.8.3.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-nokogiri-1.11.7.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-nokogiri18-1.8.5.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-addressable25-2.5.2_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-em-websocket-0.5.2_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-gollum-rugged_adapter-0.4.4_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-http3-3.3.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-platform-api-3.3.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-redis-rack1-1.6.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-rest-client-2.1.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-16_18h20m53s/logs/rubygem-tumblr_client-0.8.5_4.log
Thanks for the exp-run and logs. I will check all of them later, but the few I could check now fail because of a small output change in gem specification generation by RubyGem (the same which affected `gemdeps()' function in `Mk/Scripts/qa.sh'). That's "expected" but I missed it. As an example, mail/rubygem-net-smtp has 3 runtimes dependencies. To make example short, I kept only 1 on 3 (digest). With RubyGems 3.0.8: if s.respond_to? :specification_version then s.specification_version = 4 if Gem::Version.new(Gem::VERSION) >= Gem::Version.new('1.2.0') then s.add_runtime_dependency(%q<digest>.freeze, [">= 0"]) else s.add_dependency(%q<digest>.freeze, [">= 0"]) end else s.add_dependency(%q<digest>.freeze, [">= 0"]) end And now with RubyGems 3.2.29: if s.respond_to? :specification_version then s.specification_version = 4 end if s.respond_to? :add_runtime_dependency then s.add_runtime_dependency(%q<digest>.freeze, [">= 0"]) else s.add_dependency(%q<digest>.freeze, [">= 0"]) end Most of our patches want to adapt, or sometimes remove the first `s.add_runtime_dependency' call, and as you can see both the context and indentation changed. I'm not sure why we patch the "generated" gem specification at install and not the one provided in the gem, but there must be good reasons (maybe it's considered more "stable", in a way). I see two options: 1. Patch the gem specification generation output to restore a format suitable for patches, so that they apply cleanly again; 2. Redo all the patches in failing gem ports. In my view, 2 is better because the upstream change is beneficial and also because it avoids maintaining a new patch in RubyGems port. However I don't know if it acceptable to submit new patch with both the RubyGems update and also the changes to all the gems ports (it would be same "logical" change, but affects many ports at once).
Nice to see that there is finally progress to get ruby3 with gems on FreeBSD. A bit unfortunate that i see this after finally getting my patch to work :D Basically found more or less the same stuff as in this patch minus the plugins stuff but with a different (same as fedora) patch to disable bundler. (see https://gist.github.com/fliiiix/be69eb8e56ef6aac273167f469aecb26#file-0003-devel-ruby-gems-update-3-0-8-3-2-29-patch) And because of that i found the same problem with the patches and update at least the ports i need see here https://gist.github.com/fliiiix/9f92644e1eb54c0db64a034541f0d8ae I also think here option 2 to update the patches is the better approach. And can help with that if needed. Question for me is if it makes sense to make a commit/patch per port or one big commit/patch for all affected ports.
Created attachment 229025 [details] ports failing to build with rubygems 3.2 I looked into the Fedora solution (setup command monkey-patch), but it was written for an old RubyGems version (3.1.3 I guess). It doesn't work anymore with RubyGems 3.2 because in addition to not calling `#install_default_bundler_gem', we'd have to monkey-patch `#install_lib' which now also does something related to bundler (but we'd still need to execute it without the bundler thing), and maybe rewrite `#remove_old_lib_files' too. I started working on the update of the patches that were causing build failures with RubyGems 3.2.29. I think since it's a single "logical" change, it should be one patch/commit, in my opinion easier to maintain or revert. But I'm not yet familiar with FreeBSD ports specifics. I can split the change in multiple ones later if needed. I'm attaching a list of those failing ports (it helped me).
Created attachment 229026 [details] update to 3.2.29 - with updates to gemspec patches in rubygems ports This new patch should fix the build errors reported in the exp-run. I only checked the patching aspect for now, as I don't know how to use and check runtime behavior for most of those gems. I updated notes in the patch itself, but here are two important ones: devel/rubygem-mongo: this patch isn't about changing gem dependencies (as most do), but about removing files from the gem if I'm correct, I should investigate more to check maybe. net-mgmt/rubygem-riemann-dash: this one fails stage-qa step with poudriere testport, I'm not sure if it's related to the patch yet.
Some new failure logs: http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-fpm-1.11.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-azure-storage-common-2.0.2_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-azure_sdk-0.73.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-errand-0.8.1_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-gitlab-labkit-0.21.1_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-gitlab_git-10.7.0_3,1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-jeweler-2.3.9.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-pdk-2.3.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-cogbot-0.1.13_8.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-av-0.9.0_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-termtter-2.2.9_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-tinder-1.10.1_3.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-oxidized-web-0.13.1_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-riemann-tools-0.2.14.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-activestorage613-6.1.3.2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-fog-google19-1.9.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-fog-vsphere-3.5.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-t-3.1.0_3.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-train-3.8.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-tweetstream-2.6.1_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-devise-two-factor30-rails52-3.0.3.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-devise-two-factor30-rails60-3.0.0.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-doorkeeper-openid_connect-1.7.5_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-rhc-1.32.2_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-chef-dk-4.13.3_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-r10k-3.12.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-html2text-0.3.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-actioncable5-5.1.7.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-actionpack4-4.2.11.3.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-actionpack50-5.0.7.2_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-gitlab-gollum-lib-4.2.7.10.gitlab.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-gollum-lib-4.2.10.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-jekyll-4.2.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-jekyll3-3.9.1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2021-10-25_15h37m24s/logs/rubygem-kensa-3.1.0.log
Thanks for the new build errors logs. I will look into fixing them as soon as I can. RubyGems 3.2.30 was released yesterday, so I will update this part of the patch for 3.2.30 instead of 3.2.29 too.
Created attachment 229073 [details] update to 3.2.30 RubyGems 3.2.30 --------------- Patch now updates devel/ruby-gems to 3.2.30 instead of 3.2.29. New file added to pkg-plist: %%RUBY_SITELIBDIR%%/rubygems/resolver/molinillo/LICENSE. There are other small changes, but not impacting any patch for now. Obsolete gem ports failing to build ----------------------------------- We can now ignore fixes for 5 gem ports: build failures from comment #18: sysutils/rubygem-chef15 renamed to sysutils/rubygem-chef devel/rubygem-chef-provisioning 2021-10-25 Chef Provisioning is EoL'd on August 31, 2019 graphics/rubygem-goocanvas 2021-10-25 Deprecated by upstream. Unmaintained since October 12, 2014 build failure from comment #23: sysutils/rubygem-chef-dk 2021-10-25 ChefDK is EoL'd on December 31, 2020 www/rubygem-kensa 2021-10-25 Kensa is deprecated in favor of the addons-admin Heroku CLI plugin since December 14, 2018 New/updated gem ports failing to build -------------------------------------- devel/rubygem-mongo I unfortunately removed the change that was in previous patch: * what I did to update the patch in version 2.15.1 of the gem does not seem to work anymore with 2.16.0 (gem port was updated yesterday); * I still don't know how to check if the patch is behaving how it should anyway; * This change alone was bigger than all others and made the patch really huge. net-mgmt/rubygem-riemann-tools I fixed the gem specification patching issue, but there is a new one: =======================<phase: package >================== ===> Building package for rubygem-riemann-tools-0.2.14 pkg-static: Unable to access file /wrkdirs/usr/ports/net-mgmt/rubygem-riemann-tools/work/stage/usr/local/share/doc/riemann-tools/README.markdown:No such file or directory *** Error code 1 All other gem ports reported in comment #23 should build now.
I have 2 errors applying the patch: error: devel/rubygem-gitlab-labkit/files/patch-gitlab-labkit.gemspec: No such file or directory error: net/rubygem-activestorage613/files/patch-activestorage.gemspec: No such file or directory
Created attachment 229114 [details] update to 3.2.30 I updated the patch. Both errors are about removed gemspec patches in ports. devel/rubygem-gitlab-labkit: updated from 0.21.1 to 0.21.2, gemspec patch removed net/rubygem-activestorage613: port removed, looks like it was for gitlab, which now use 6.1.4 instead of 6.1.3 So both errors can be ignored or new attached patch can be used.
New failure logs: http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-fog-2.2.0_1.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-mongo-2.16.0.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-rails-i18n-4-4.0.9_1.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-visage-app-2.1.0_4.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-bolt-3.19.0.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-license_scout-2.6.2.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-actioncable50-5.0.7.2.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-gollum-4.1.4_1.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-octopress-3.0.11_2.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-rails4-4.2.11.3.log http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/rubygem-rails60-6.0.4.1.log Unrelated gem failure: http://package22.nyi.freebsd.org/data/130amd64-default-foo/2021-10-29_09h20m05s/logs/errors/rubygem-rails60-6.0.4.1.log
Created attachment 229210 [details] update to 3.2.30 Thank you for the logs, I updated the patch which should fix those 11 new build failures. In this list was devel/rubygem-mongo, and the change for its gemspec patch is back (removed in comment #25 following an update). Should maintainers of gems affected by this patch be contacted or review those changes in any way? I'm asking, since I realize there was at least one error in the patch I wrote. Maybe reviews happens after at least one successful exp-run? I also added three new changes for ports I would have expected to fail to patch in next exp-run, as they were skipped in last one: devel/rubygem-omnibus sysutils/rubygem-bosh-gen sysutils/rubygem-backup I looked into issues I reported earlier: net-mgmt/rubygem-riemann-dash port I had introduced an error in the gemspec file when updating its patch since the beginning: ====> Running Q/A tests (stage-qa) Error: RubyGem dependency webrick ~> 1.3.1 is not satisfied. I missed this dependency removal, which I fixed in attached patch. I also slightly changed the original patch which removed "dead code" in addition to the important change (at the difference of most other gem ports gemspec patch). In my opinion this will make it easier to change the patch now, but since this is opinionated I can avoid doing that in a next patch if I shouldn't have. net-mgmt/rubygem-riemann-tools port It fails to build with `DOCS' option: ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) […] ===> Checking for items in pkg-plist which are not in STAGEDIR Error: Missing: %%DOCSDIR%%/README.markdown I have the same issue with RubyGems 3.0.8 (current version in ports) and the update to 3.2.30.
Hello! I want to make things easier for you in the future, so: * I merged https://github.com/rubygems/rubygems/pull/2768. * I created https://github.com/rubygems/rubygems/pull/5051 and https://github.com/rubygems/rubygems/pull/5052 to fix more `--destdir` issues. * I will try to create a CI check that make the default gem home unwritable, and then runs `ruby setup --destdir <folder>` to a writable folder, to make sure nothing tries to write to the default gem home. Feel free to try my patches and leave feedback <3
Quick update, I merged https://github.com/rubygems/rubygems/pull/5051 and created yet one more patch with another fix: https://github.com/rubygems/rubygems/pull/5053.
Upstream patches have now either landed or been included with https://github.com/rubygems/rubygems/pull/5053, and Yasuhiro Kimura has tried them and they seem to be working!
Exp-run looks fine
@ruby Now that latest patch passed exp-run, would you please approve to commit it?
Thanks for the last exp-run and changes to RubyGems upstream, that's great news. I noticed the patch fails to apply again following two ports updates: sysutils/rubygem-bolt/files/patch-bolt.gemspec sysutils/rubygem-r10k/files/patch-r10k.gemspec Should I update the patch now, or wait for approval of the patch currently attached to the PR?
Thank you, I understand that upstream fixes are only useful for future updates, not for this one which is mainly done. Correct? Anyways, I'm still waiting to merge the last PR since I found some more issues which I want to fix there, but I hope it will make it into a release soon.
When I send fixes upstream, I also implement them in the port until upstream issues a new release which contains those fixes. Is there anything holding us up now? I'd love to get this into the tree. I have developers at $WORK who would love to test it. I tried the current patch and it stops patching here. Is there anything I can do to help please? .... Patching file www/rubygem-addressable25/files/patch-gemspec using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- www/rubygem-em-websocket/files/patch-gemspec |+++ www/rubygem-em-websocket/files/patch-gemspec -------------------------- File to patch:
For what it's worth, I decided to go with the current version of the fix, since it fixes most of the issues with `--destdir` and I don't want to block it on the little issue that I found because fixing it requires a bigger refactoring that I'm not sure when I'll attempt. I hope to release it in the next few days with rubygems 3.2.33. For completeness, the little issue with the current patch is that binstub regeneration inside the DESTDIR only works properly for gems that are also installed globally. So if I have `rake` installed globally, this works: ``` $ gem list rake *** LOCAL GEMS *** rake (13.0.6) $ rm -rf /tmp/foo && gem install rake --install-dir /tmp/foo && (echo "foo" > /tmp/foo/bin/rake) && ruby -Ilib setup.rb --destdir /tmp/foo --prefix / && head -1 /tmp/foo/bin/rake Fetching rake-13.0.6.gem Successfully installed rake-13.0.6 1 gem installed Successfully built RubyGem Name: bundler Version: 2.3.0.dev File: bundler-2.3.0.dev.gem Bundler 2.3.0.dev installed RubyGems 3.3.0.dev installed Regenerating binstubs Regenerating plugins ------------------------------------------------------------------------------ RubyGems installed the following executables: /tmp/foo/bin/gem /tmp/foo/bin/bundle /tmp/foo/bin/bundler #!/Users/deivid/.rbenv/versions/3.0.3/bin/ruby ``` But if I remove the globally installed rake, the `rake` binstub in the DESTDIR is no longer regenerated properly: ``` $ gem uninstall rake --executables --force Removing rake Successfully uninstalled rake-13.0.6 $ rm -rf /tmp/foo && gem install rake --install-dir /tmp/foo && (echo "foo" > /tmp/foo/bin/rake) && ruby -Ilib setup.rb --destdir /tmp/foo --prefix / && head -1 /tmp/foo/bin/rake Fetching rake-13.0.6.gem Successfully installed rake-13.0.6 1 gem installed Successfully built RubyGem Name: bundler Version: 2.3.0.dev File: bundler-2.3.0.dev.gem Bundler 2.3.0.dev installed RubyGems 3.3.0.dev installed Regenerating binstubs Regenerating plugins ------------------------------------------------------------------------------ RubyGems installed the following executables: /tmp/foo/bin/gem /tmp/foo/bin/bundle /tmp/foo/bin/bundler foo ```
Happy to try an updated patch.
About updating/committing a patch: The issue here as I understand, is that once a patch is attached we have to check it with exp-run, then wait for review, approval and commit it (Comment #34). But understandably, the exp-run and adjustments on the patch take some time, reviewing it too, and by this time some gem ports affected by the patch have been updated. I'm happy to update the patch as many time as needed but: * I don't want to give unnecessary work to people (Antoine Brodin for exp-run for example); * I don't have a workstation with the availability and build power to rebuild *all* ports depending on RubyGems fast enough before the gem ports get updated (I mean trying to do exp-run on my machine is not really possible event if I limit ports to the ones depending on RubyGems). Anyway I will make a new update, but not before one or two days at least. In the meantime, if you don't use any of the gems where the FreeBSD port patched the gem specification file, then you can ignore the failure and keep the version currently in the port tree. It won't affect devel/ruby-gems itself, nor any gem installed with `gem install ...`. This is slightly unrelated, but a thing that could help is to get rid of those gem specification patches. Just an idea but ideally, maintainers of the FreeBSD port could convince gem author to fix version specifications in dependencies, so that we wouldn't need patches in the port (I'm pretty sure it was done, but don't know to which extent). I also know that a dedicated feature for this was discussed upstream (to avoid patching), but IIRC wasn't very popular (because ideally gems should be fixed directly). About RubyGems setup command `--destdir' and `--no-regenerate-binstubs' options (Comment #36 and Comment #38): The original issue regarding executable wrappers in combination with `--destdir' is from RubyGems 2.7.0 if I'm correct (909b5fb8). I reported it by mail with a possible fix to the author, but got a rude answer at the time. It was later possible to workaround this with 4619f13a, we have to pass `--no-regenerate-binstubs' explicitly. This is similar to the more recent `--no-regenerate-plugins' and `--format-executable' which we must now pass explicitly to the setup command for success. One of the places where this was discussed later is here: https://github.com/rubygems/rubygems/issues/2370 With a normal installation of RubyGems, there cannot be any executable wrapper to rewrite (or any plugin wrapper) since we need RubyGems to install gems, so it happens before we could have a gem installed. The kind of manual update that was explained in the GitHub issue, or shown with rake gem in Comment #38 only affects some RubyGems developers and maintainers if I understand correctly, and only when "experimentally" installing RubyGems manually over an existing installation. End users should never encounter this scenario. I only noticed it (years ago) because of the behavior being the default, while attempting to update the port, because the name of the environment variable to enable bundler changed, and because the build system was warning about things not installed where they should be. The conditions to trigger it are very specific. IMO all people maintaining RubyGems ports introduced `--no-regenerate-binstubs' in their build at the time, and wont use the code path where that last remaining bug may be. What would help is if following similar features were "opt-in" instead of "opt-out" (I guess we cannot change actual ones in 3.x again, to avoid breakage).
Thanks for your comment. I'll reply to what concerns me. > The original issue regarding executable wrappers in combination with > `--destdir' is from RubyGems 2.7.0 if I'm correct (909b5fb8). I > reported it by mail with a possible fix to the author, but got a rude > answer at the time. It was later possible to workaround this with > 4619f13a, we have to pass `--no-regenerate-binstubs' explicitly. This > is similar to the more recent `--no-regenerate-plugins' and > `--format-executable' which we must now pass explicitly to the setup > command for success. One of the places where this was discussed later > is here: https://github.com/rubygems/rubygems/issues/2370 I'm sorry someone replied to an email to you rudely at the time. Anyways, I'm trying to help out now so let's move on, yeah? The issue you linked to and a few others have been fixed by the different patches merged recently, and rubygems should no longer try to write outside of `--destdir` if it's passed (both during normal operation or binstub/plugin regeneration). > With a normal installation of RubyGems, there cannot be any > executable wrapper to rewrite (or any plugin wrapper) since we need > RubyGems to install gems, so it happens before we could have a gem > installed. The kind of manual update that was explained in the GitHub > issue, or shown with rake gem in Comment #38 only affects some > RubyGems developers and maintainers if I understand correctly, and > only when "experimentally" installing RubyGems manually over an > existing installation. End users should never encounter this scenario. They absolutely do! In fact, binstub regeneration is an important feature of rubygems upgrader. We sometimes need to tweak the binstubs that rubygems generates. Having rubygems upgrader automatically upgrade all binstubs to the new format a new rubygems version needs and generates is really nice. Even when first installing rubygems, I could imagine situations where upgrading binstubs in an exisiting gem path could be handy. In any case, it's great that you don't need that yourselves, I'm happy I merged the main fix and reticketed that little issue for later. > What would help is if following similar features > were "opt-in" instead of "opt-out" (I guess we cannot change actual > ones in 3.x again, to avoid breakage). I'm sorry the introduction of those flags broke things for you. That doesn't mean the flags themselves are backwards incompatible, actually quite the opposite, they were introduced to fix backwards compatibility issues with new rubygems versions. Unfortunately in this case, their introduction was buggy since they didn't play well with `--destdir`. So I think a more reasonable request would be: don't introduce new bugs with new features or bug fixes xD. That's our goal but you know, shit happens. Anyways, when I make changes that I think could possibly affect/break packagers I usually ping at least Debian & Fedora packagers to gather opinions. I'm happy to add someone from FreeBSD to my "rubygems packagers ping list" if you wish. I'm aware you're not happy about past upstream maintenance, and that upstream has never paid too much attention to packagers (they are a minority of our users, and upstream could barely deal with the rest of our community), but I'm trying to help more now, so let's move on and not talk about the past, specially since I wasn't really involved back then. Ok?
(In reply to deivid.rodriguez from comment #41) I thought it would help to know about the difficulties encountered when updating the port, and also to help anyone reading the PR know what would be relevant to the attached patch or not (also to avoid delay like a potential reviewer thinking that the issue discussed was related to the patch). This was my intention at least, but I probably gave too much context. I wrote earlier that I was thankful for your work and this is still true :-)
Created attachment 229958 [details] update to 3.2.30 (In reply to Dan Langille from comment #39) I fixed the patch and it should now apply cleanly. I made changes for 4 gem ports: net/rubygem-grpc130: gemspec patch changed since last patch sysutils/rubygem-bolt: gemspec patch changed since last patch sysutils/rubygem-r10k: gemspec patch changed since last patch www/rubygem-em-websocket: gemspec patch was removed I also tried to look for other modified or added gem ports since the previous patch I made, ports that would have a change in `files' subdirectory since then: devel/rubygem-gitlab-labkit devel/rubygem-rugged net/rubygem-gitaly net/rubygem-grpc142 net/rubygem-kas-grpc net/rubygem-spamcheck Unfortunately some have many dependencies and I cannot wait for the build right now. In one or two days I will identify those which may include a gemspec patch that require fixing. I used an ugly command to find them, so maybe there are other, with zsh: for f ($(git grep -l ^USES=.\*gem \*/\*/Makefile | cut -d / -f 1-2)) \ git diff bccba76b... --quiet -- $f/files || echo $f Note: I didn't update to RubyGems 3.2.32 yet, because it looks like 3.2.31 vendors more libraries, for example `optparse' from Ruby but with some modifications like renaming the class from `OptionParser' to `Gem::OptionParser'. I'll have to reread porter handbook to know if this should be "unvendored".
The patch applies cleanly here. Building against FreeBSD 13 and head on the ports tree, I get this build error. sudo poudriere testport -i -p dvl -j 130R -z REDACTED devel/ruby-gems ... ===> Returning to build of ruby27-gems-3.2.30 ===> ruby27-gems-3.2.30 depends on file: /usr/local/bin/ruby27 - found =========================================================================== =>> Recording filesystem state for prestage... done =======================<phase: stage >============================ ===> Staging for ruby27-gems-3.2.30 ===> ruby27-gems-3.2.30 depends on package: ca_root_nss>=0 - found ===> ruby27-gems-3.2.30 depends on file: /usr/local/bin/ruby27 - found ===> Generating temporary packing list /bin/mkdir -p /wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7 /bin/mkdir -p /wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7/build_info /bin/mkdir -p /wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7/plugins /bin/mkdir -p /wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7/cache /bin/mkdir -p /wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7/doc /bin/mkdir -p /wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7/extensions /bin/mkdir -p /wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7/gems /bin/mkdir -p /wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7/specifications cd /wrkdirs/usr/ports/devel/ruby-gems/work/rubygems-3.2.30/ && /usr/bin/env GEM_HOME=/wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7 /usr/local/bin/ruby27 setup.rb --destdir=/wrkdirs/usr/ports/devel/ruby-gems/work/stage --no-regenerate-binstubs --no-regenerate-plugins --format-executable ERROR: While executing gem ... (Errno::ENOENT) No such file or directory @ dir_chdir - bundler/lib *** Error code 1
> I thought it would help to know about the difficulties encountered > when updating the port, and also to help anyone reading the PR know > what would be relevant to the attached patch or not (also to avoid > delay like a potential reviewer thinking that the issue discussed was > related to the patch). This was my intention at least, but I probably > gave too much context. I wrote earlier that I was thankful for your > work and this is still true :-) It's alright, the context is indeed useful, sorry if I sounded harsh and thanks for your kind words :) I released rubygems 3.2.33 with the last patch. > Note: I didn't update to RubyGems 3.2.32 yet, because it looks like > 3.2.31 vendors more libraries, for example `optparse' from Ruby but > with some modifications like renaming the class from `OptionParser' to > `Gem::OptionParser'. I'll have to reread porter handbook to know if > this should be "unvendored". Yeah, unfortunately, as more standard libraries that we use internally get converted into gems, we need to vendor them, because we can't have any dependencies ourselves because otherwise we would restrict user's choice of the dependency to the version that we use internally.
(In reply to Dan Langille from comment #44) > sudo poudriere testport -i -p dvl -j 130R -z REDACTED devel/ruby-gems […] > cd /wrkdirs/usr/ports/devel/ruby-gems/work/rubygems-3.2.30/ && /usr/bin/env GEM_HOME=/wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7 /usr/local/bin/ruby27 setup.rb --destdir=/wrkdirs/usr/ports/devel/ruby-gems/work/stage --no-regenerate-binstubs --no-regenerate-plugins --format-executable > ERROR: While executing gem ... (Errno::ENOENT) > No such file or directory @ dir_chdir - bundler/lib > *** Error code 1 This is new to me. I'm surprised because I didn't change anything in the patch for `devel/ruby-gems', and multiple previous patch passed the exp-run for this port. I did my patch on d624c6c0fba3880074ca8fd7455bef3aa7a8298a in port tree (not so old). I use FreeBSD 12.2 RELEASE, and have `DEFAULT_VERSIONS= ruby=2.7' too. "No such file or directory @ dir_chdir - bundler/lib": that this directory does not exist is expected (`post-extract' target in the Makefile), the code triggering this is not. Thank you for the very fast test and report, unfortunately I will need more time to look into it.
Created attachment 229977 [details] potential fix for patching issue (In reply to Dan Langille from comment #44) > ERROR: While executing gem ... (Errno::ENOENT) > No such file or directory @ dir_chdir - bundler/lib > *** Error code 1 I think that the patch for devel/ruby-gems (which is included in the patch for the update) did not apply. The only issue I see is that I made this patch with git, not with `make makepatch`. If I `rm devel/ruby-gems/files/patch-bundler-remove.patch`, I get the same error output. My guess is that the error is from following chdir: class Gem::Commands::SetupCommand < Gem::Command […] def install_lib(lib_dir) libs = { 'RubyGems' => 'lib' } libs['Bundler'] = 'bundler/lib' # patch should remove this line libs.each do |tool, path| […] Dir.chdir path do […] end end end end It can be checked by modifying `RUBY_SETUP_OPTIONS' in `devel/ruby-gems/Makefile' by adding two arguments: --backtrace --verbose ERROR: While executing gem ... (Errno::ENOENT) No such file or directory @ dir_chdir - bundler/lib /wrkdirs/usr/ports/devel/ruby-gems/work/rubygems-3.2.30/lib/rubygems/commands/setup_command.rb:490:in `chdir' […] /wrkdirs/usr/ports/devel/ruby-gems/work/rubygems-3.2.30/lib/rubygems/commands/setup_command.rb:321:in `install_lib' While I can obtain the same error, I don't know how to fully reproduce it (if the patch embedded in the patch does not apply, I don't know why). I'd be interested to see the `patch' target in poudriere testport output. In the meantime, I'm attaching a patch that convert the "git" patch to a `make makepatch` one. It need to be applied after the "main" patch (to avoid being huge).
I suspect I'm using the diff, not the attachment. Let me try again and provide full details. [dvl@ava-pkg-02prd:/usr/dvl/main] $ git reset --hard HEAD is now at d624c6c0fba3 japanese/font-plemoljp{,-hs,-nf}: Update to 1.2.2. [dvl@ava-pkg-02prd:/usr/dvl/main] $ rm patch-bundler-remove.patch [dvl@ava-pkg-02prd:/usr/dvl/main] $ fetch -o ~/tmp/patch.gem "https://bz-attachments.freebsd.org/attachment.cgi?id=229958" /home/dvl/tmp/patch.gem 347 kB 377 kBps 01s [dvl@ava-pkg-02prd:/usr/dvl/main] $ patch < ~/tmp/patch.gem output not shown - see https://gist.github.com/dlangille/3cdbab365865c736ed3372b3bc224f69 instead For me: patch-bundler-remove.patch gets created in the top level directory (see `git status` output in the first comment of the above mentioned gist. [dvl@ava-pkg-02prd:/usr/dvl/main] $ mkdir devel/ruby-gems/files [dvl@ava-pkg-02prd:/usr/dvl/main] $ mv patch-bundler-remove.patch devel/ruby-gems/files/patch-bundler-remove.patch Now it builds.
Comment on attachment 229977 [details] potential fix for patching issue Interesting, I didn't notice the issue because I do already have `devel/ruby-gems/files' directory existing, because of other custom patches. Creating the directory before running patch with no arguments solves the issue. Not creating the directory and running patch with `-p0' works too. mkdir devel/ruby-gems/files && patch < ~/tmp/patch.gem patch -p0 < ~/tmp/patch.gem
(In reply to Thibault Jouan from comment #49) The new patch applies and builds cleanly for me.
Created attachment 230305 [details] Updated patch file Chase update of ports tree. Some rubygem ports are removed.
(In reply to Yasuhiro Kimura from comment #51) ruby27-gems: 3.2.30 builds for me here. What is the next step?
3.2.33 and 3.3.3 are now the latest versions.
happy new year to all ruby users in the bug report.
Anything I can so to help test?
Created attachment 231355 [details] update to 3.3.6 Patch updated: * Update to 3.3.6 instead of 3.2.30 * Remove changes because of gemspec patch removal in some ports: - devel/rubygem-azure-storage-common - devel/rubygem-dynflow - mail/rubygem-net-imap - mail/rubygem-net-pop - mail/rubygem-net-smtp * Remove changes temporarily because of pending gemspec changes: - www/rubygem-gollum-lib - www/rubygem-gollum-rugged_adapter - www/rubygem-gollum (see bug #260207) * Remove unnecessary info from commit messages * Add notes for notable changes between RubyGems 3.2.30 and 3.3.6: * Remove `.document' files in vendored libraries (See upstream 2d7cd652). RubyGems now bundles tsort library (d3268809) and optparse one (47c4d12e). We chose not to unbundle those, because they were moved into `Gem' namespace (renamed as `Gem::TSort' and `Gem::OptionParser') which would require an invasive and complex patch. * The server command has been moved to the rubygems-server gem. I choose to remove those `.document' files because it seemed strange to have them in the release tarball, and previously vendored library didn't have them. Also, patch in bug #260780 remove them too. Please let me know if you have issues with this new patch. Now if someone has extra free time and build power to test building ports that depends on devel/ruby-gems *and* have a gemspec patch, I'd be happy to know about any build error related to the patch. Since the last exp-run, I've been doing manual, incomplete, inefficient checks with this ugly command: for f ($(git grep -l ^USES=.\*gem \*/\*/Makefile | cut -d / -f 1-2)) \ git diff ${COMMIT}... --quiet -- $f/files || echo $f >> ~/gem_ports_list (zsh) Where ${COMMIT} is the original commit my last version of the patch was based on. Then I poudriere testport the suspicious ones, but probably missed a lot. Test building *all* ports that depend on devel/ruby-gems is better and simpler, but takes lot of time.
(In reply to Thibault Jouan from comment #56) That patch applies cleanly and builds here. Thank you.
If someone gives me a list of ports for test builds, I can do that on a powerful system.
(In reply to Dan Langille from comment #58) Thank you for the very fast feedback. Here is a list of ports: http://vault.a13.fr/media/rg-test_build-ports_list.txt I don't even need the build logs. Only the list of port "origin" (like in my list) that fail to build. Then I investigate the failing ones, if there are, 99% should be about gem spec patches conflicts and I will redo them. This way IMO we should catch most errors as in an exp-run, but with less ports to build (2600 gem ports… and probably substantially more for dependencies). If this is still too much, we could decrease the list by keeping only ports which have a gemspec patch.
(In reply to Thibault Jouan from comment #59) That list hightlighted that I was testing on an older ports tree. After a git pull, I have patch issues: Patching file textproc/rubygem-html2text/files/patch-gemspec using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git textproc/rubygem-nokogiri/files/patch-gemspec textproc/rubygem-nokogiri/files/patch-gemspec |index 43f56f9a0877..f4885e236892 100644 |--- textproc/rubygem-nokogiri/files/patch-gemspec |+++ textproc/rubygem-nokogiri/files/patch-gemspec -------------------------- File to patch: That is the only issue.
(In reply to Dan Langille from comment #60) Yes sorry about that, my own port tree always lag one or two days behind because I do those updates on a "desktop" computer, and when some ports are updated (say rust for example), I need a whole night or more to rebuild all. And I want to work on the RubyGems update with up to date ports to be sure it's correct. My last patch is based on 2e1fdc173831debc50f2c25b86e202c0a4967334 (Mon Jan 24 17:41:06 2022 -0600). textproc/rubygem-nokogiri was updated few hours ago (Wed Jan 26 11:43:00 2022 +0100). Thankfully, this last update is the gemspec patch removal, which is great news: you can safely ignore failure to apply for this specific file (but only this one), and it will also simplify next patch update. Hopefully I submit an updated patch tomorrow (if I can rebuild my ports next night).
(In reply to Thibault Jouan from comment #61) These results are based on 807e6fc0e4c03c8cbe25f91a0e15be3e3a8a727b 2748 ports queued, 2361 built, 12 failed (see below), 375 skipped failures: textproc/rubygem-nokogiri databases/rubygem-mysql devel/rubygem-mongo science/cdcl www/rubygem-gollum-rugged_adapter textproc/rubygem-nokogiri111 devel/rubygem-xdg5 net/rubygem-spamcheck devel/rubygem-xdg net/rubygem-kas-grpc mail/rubygem-tmail graphics/rubygem-objectdetect
I am now trying with the same version of the tree as your patch.
When testing against your ports tree release, these fail: science/cdcl mail/rubygem-tmail devel/rubygem-xdg devel/rubygem-mongo devel/rubygem-xdg5 www/rubygem-gollum-rugged_adapter net/rubygem-kas-grpc net/rubygem-spamcheck www/rubygem-gollum-lib devel/rubygem-gitlab-labki databases/rubygem-mysq graphics/rubygem-objectdetect
Created attachment 231387 [details] update to 3.3.6 Thank you for the builds and list of failing ports. I was wrong in comment #60, change on textproc/rubygem-nokogiri is a recent patch addition, not removal. Anyway I adapted my patch for it, and other ports: devel/rubygem-gitlab-labkit fixed with nokogiri gemspec patch change devel/rubygem-mongo RubyGems version was in gemspec patch, fixed manually net/rubygem-kas-grpc gemspec patch fix net/rubygem-spamcheck gemspec patch fix textproc/rubygem-nokogiri new gemspec patch textproc/rubygem-nokogiri111 new port, needed gemspec patch Those ports seem to fail for reasons unrelated to RubyGems port patch: devel/rubygem-xdg port requires Ruby ~> 3.1 (marked broken otherwise) graphics/rubygem-objectdetect port maked broken mail/rubygem-tmail port marked broken science/cdcl port marked broken, unfetchable Those ports I ignore on purpose for now (comment #56 and bug #260207): www/rubygem-gollum-lib www/rubygem-gollum-rugged_adapter And now about databases/rubygem-mysql, it builds OK in my poudriere with Ruby 2.7 and default port options for the port. If you have time, take a look at the build log and guess if it's related to RubyGems. If something is worrying related to RubyGems, I'm interested to see the log. Last, can someone with the permission update the PR title with 3.3.6 instead of 3.2.30?
(In reply to Thibault Jouan from comment #65) I can't analyze the databases/rubygem-mysql failure just not, but I can copy/paste it to: https://gist.github.com/dlangille/3a22bc234bd90d637a752dbd4030d97e
(In reply to Dan Langille from comment #66) I took a quick look at it, I don't think it's related to the patch, thank you for the log. I could reproduce the build error with MySQL 8, in make.conf: DEFAULT_VERSIONS= mysql=8.0 With default MySQL (5.7) there are no issue. It seems that the gem itself is not compatible with MySQL 8: https://github.com/luislavena/mysql-gem/issues/35#issuecomment-399764286 (build error is similar) https://github.com/luislavena/mysql-gem "As January 1st, 2015, this project has become unmaintained" So in my opinion, we can ignore that build error in the context of this PR.
(In reply to Thibault Jouan from comment #67) Testing with the recently added patch (2022-01-27 11:30 UTC), only 9 failures against the ports tree as of 2bde8a83e68d522b09ad38199bab5419dc19f200 (Wed Jan 26 15:59:20 2022 +0100). * devel/rubygem-xdg * devel/rubygem-xdg5 * graphics/rubygem-objectdetect * mail/rubygem-tmail * science/cdcl * www/rubygem-gitlab-gollum-lib * www/rubygem-gollum-lib * www/rubygem-gollum-rugged_adapter Next I will run against 2564716ea1ef7424132779e3b74261c101955c6d
(In reply to Dan Langille from comment #68) That additional run has the same failures. Nothing new to add here.
I'm now tracking bug #261637 instead of bug #260207 for `www/rubygem-gollum-lib' port. There is a patch attached in the PR. If/when it's commited, I'll update `devel/ruby-gems' one. No new version of Ruby Gems was released since 3.3.6. I went to #rubyports IRC channel (EFnet) a few days ago, asking for help and/or advice in the process of commiting this patch, but no activity there so far.
(In reply to Thibault Jouan from comment #70) I'm there on IRC now too.
Worst case: we wait two weeks for maintainer timeout? Then I commit.
So sorry for the additional work, i try to get bug #261637 merged. Because i would love to get this one as well as it unblocks ruby 3.0. Let me know if i can do anything else.
(In reply to Dan Langille from comment #72) I'm happy to learn that it's possible. Of course I would wait for the last gemspec patch to be patched, verify again the patch one last time, and probably make a new list of ports that we could test build (in case there was new gemspec patches added to the tree since then). Then my last concern would probably be about reviewing it, my hope is that some people in this PR reviewed it, maybe some are using it, and they had no issue so didn't report anything.
(In reply to Sir l33tname from comment #73) No worry here, it's only one in many other ports having gemspec patches, for reasons outside our control anyway. By noticing your original PR and reading the comments I saw an opportunity to be lazy and save some work, after guessing that the gemspec patch would change soon. I mentioned it for information, I hope it didn't lead to some pressure :-)
Hello! Forgive me if this is not the right place, but I wanted to ask whether you faced an issue similar to https://github.com/rubygems/rubygems/issues/5326 while packaging the latest RubyGems. One of the upstream maintainers uses FreeBSD and run into that issue while running our tests on here system. Thanks!
(In reply to deivid.rodriguez from comment #76) I don't know enough ruby to answer.
Well, thanks for your reply nevertheless!
With 261637 closed, is there anything preventing this PR from progressing?
I'm taking this PR after conversation with zi@
Patching against head, I get failures on these files: * devel/rubygem-azure-storage-common/files/patch-gemspec * devel/rubygem-dynflow/files/patch-gemspec * mail/rubygem-net-imap/files/patch-gemspec * mail/rubygem-net-pop/files/patch-gemspec * mail/rubygem-net-smtp/files/patch-gemspec * sysutils/rubygem-fluentd/files/patch-gemspec * www/rubygem-gollum-lib/files/patch-gemspec - I removed that via 261637 * www/rubygem-gollum-rugged_adapter/files/patch-gollum-rugged__adapter.gemspec I suspect the patches for these bits have been overtaken by events.
(In reply to Dan Langille from comment #81) I used the wrong patch above. Using the latest patch, the list is: * sysutils/rubygem-fluentd/files/patch-gemspec * textproc/rubygem-nokogiri/files/patch-nokogiri.gemspec
Error on building against head: cd /wrkdirs/usr/ports/devel/ruby-gems/work/rubygems-3.3.6/ && /usr/bin/env GEM_HOME=/wrkdirs/usr/ports/devel/ruby-gems/work/stage/usr/local/lib/ruby/gems/2.7 /usr/local/bin/ruby27 setup.rb --destdir=/wrkdirs/usr/ports/devel/ruby-gems/work/stage --no-regenerate-binstubs --no-regenerate-plugins --format-executable ERROR: While executing gem ... (Errno::ENOENT) No such file or directory @ dir_chdir - bundler/lib *** Error code 1
Created attachment 231896 [details] update to 3.3.7 Patch updated for RubyGems 3.3.7 (instead of 3.3.6), and to update changes in gem ports having gemspec patches: devel/rubygem-pdk gemspec patch updated (deeaa184 changed line endings) sysutils/rubygem-fluentd gemspec patch removed (35a8361d) sysutils/rubygem-r10k gemspec patch updated (fb2191e8 updated the port) www/rubygem-gollum-lib patch reintroduced (see comment #65) www/rubygem-gollum-rugged_adapter patch reintroduced (see comment #65) I did the update with port tree at change 57815a47 (few hours ago), then rebased my change on 3fcb3729 (few minutes ago). I updated the list of gem ports from comment #59: http://vault.a13.fr/media/rg-test_build-ports_list.txt (In reply to Dan Langille from comment #83) > Error on building against head: […] > No such file or directory @ dir_chdir - bundler/lib I suspect the patch did not apply cleanly like in comment #44. Comments #46 to #49 might have the solution, which I guess is creating `devel/ruby-gems/files' directory or using `patch -p0'. I guess applying with git would work too. (In reply to deivid.rodriguez from comment #76) […] > an issue similar to https://github.com/rubygems/rubygems/issues/5326 while packaging the latest RubyGems. It looks like the issue is running the test suite with `rake test` with version "3.3.0.dev", and it would not pass. I can't reproduce right now but observe a few things: * 3.3.0.dev has no corresponding released archive: https://rubygems.org/rubygems/rubygems-3.3.0.dev.tgz is 403 * The Rakefile is not included in the releases, so they don't use the FreeBSD port, but probably directly the sources from the repository * They don't use the lang/ruby{27,30,31} FreeBSD ports but a custom user install, I hope the issue still happens with a normal Ruby install. At first view it does not seem related to the FreeBSD port (since they don't use it, and probably same for Ruby). I'll try to look into it, but the test suite now depends on bundler if I'm correct (test/rubygems/helper.rb for example). In the mean time I can send various patches by private mail, patches I'm using to workaround some issues. Maybe they'll provide a hint, I see one of them refer to change 91a96d01 in upstream repository, I'm not sure if it could be related. Last thing I can write is that the FreeBSD port does not use yet the "operating system defaults" feature (I'll look into it after we commit current update).
(In reply to Thibault Jouan from comment #84) Patch applies cleanly here against head via: patch -p0 Builds cleanly against 13.0 and 12.3 My next task: build againt the list of ports which depend upon devel/ruby-gems If that succeeds, do we agree to commit? I have approval from ruby@ (via zi) to proceed after clean compiles.
(In reply to Dan Langille from comment #85) failed ports are: www/rubygem-gitlab-gollum-lib:patch science/cdcl:fetch devel/rubygem-xdg5:stage devel/rubygem-xdg:stage mail/rubygem-tmail:stage www/rubygem-gollum:patch graphics/rubygem-objectdetect:stage I am looking at the gollum stuff first.
Noticed this: [dvl@ava-pkg-02prd:/usr/dvl/main] $ find . -name '*.rej' ./Oops.rej ./textproc/rubygem-nokogiri/files/patch-gemspec.rej ./sysutils/rubygem-r10k/files/patch-r10k.gemspec.rej ./sysutils/rubygem-chef/files/patch-gemspec.rej ./www/rubygem-gollum/files/patch-gemspec.rej ./devel/rubygem-pdk/files/patch-pdk.gemspec.rej
I have given up for today. I don't know.
Created attachment 231942 [details] update to 3.3.7 I have updated the patch. (In reply to Dan Langille from comment #86) Those are expected failure, not related to the patch: devel/rubygem-xdg5: requires Ruby 3.0 devel/rubygem-xdg: requires Ruby 3.1 graphics/rubygem-objectdetect: port explicitly marked broken mail/rubygem-tmail: port explicitly marked broken science/cdcl: marked broken, unfetchable Those I updated their gemspec patches, they should build now: www/rubygem-gitlab-gollum-lib: gemspec patch updated www/rubygem-gollum: gemspec patch updated (In reply to Dan Langille from comment #87) *.rej files I suspect they are leftovers after the application of an outdated patch, and that they were still there after application of a more recent patch.
Patch applied. Now waiting on build of 2600+ ports I confirmed the .rej issue by applying the patch into a different working copy of the ports treet.
My first build attempt results in the expected 5 failures. sudo poudriere bulk -p dvl-FreeBSD -j 130R -f /tmp/ruby-gems-buildlist.sorted Good. Now I'm building them all from scratch: sudo poudriere bulk -p dvl-FreeBSD -j 130R -C -f /tmp/ruby-gems-buildlist.sorted
The buildlist: https://gist.github.com/dlangille/a7f05fa277727ba0604355bb41e6df09
[00:48:08] Failed ports: science/cdcl:fetch devel/rubygem-xdg5:stage devel/rubygem-xdg:stage mail/rubygem-tmail:stage graphics/rubygem-objectdetect:stage [00:48:08] Skipped ports: science/rubygem-ruby-dcl (because of cdcl-5.4.8_1) [130R-dvl-FreeBSD] [2022-02-19_15h07m14s] [committing:] Queued: 2644 Built: 2638 Failed: 5 Skipped: 1 Ignored: 0 Tobuild: 0 Time: 00:48:08 I think we are good to commit. Do you agree?
(In reply to Dan Langille from comment #93) I agree to commit. If possible, can we keep most of the notes from my original commit (in the patch too) as context, for the git history? So that if there are any issue, and I'm not available to look into it, at least people will know choices I made and why.
I made a build today on 10120efedc79c6caf872a32f65e241631af3919e with this patch and everything i build for my local setup is building successfully and a quick sanity check looks good to me. So let's get this done!
(In reply to Sir l33tname from comment #95) Working on this now.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=7b279c9e09e1d27a385b7400842622b03a60c5bb commit 7b279c9e09e1d27a385b7400842622b03a60c5bb Author: Dan Langille <dvl@FreeBSD.org> AuthorDate: 2022-02-20 12:13:41 +0000 Commit: Dan Langille <dvl@FreeBSD.org> CommitDate: 2022-02-20 13:06:12 +0000 devel/ruby-gems: Update to 3.3.7 These are fixes Ruby 3.0 Changes were compiled against all dependencies of devel/ruby-gems and they all built cleanly. There are five known build failures, all prexisting: * devel/rubygem-xdg5: requires Ruby 3.0 * devel/rubygem-xdg: requires Ruby 3.1 * graphics/rubygem-objectdetect: port explicitly marked broken * mail/rubygem-tmail: port explicitly marked broken * science/cdcl: marked broken, unfetchable Plus, science/rubygem-ruby-dcl gets skipped because of science/cdcl PR: 258108 Approved by: ruby (zi@) Mk/Scripts/qa.sh | 2 +- Mk/Uses/gem.mk | 7 + archivers/rubygem-fpm/files/patch-gemspec | 36 +-- archivers/rubygem-minitar-cli/files/patch-gemspec | 18 +- databases/rubygem-dm-types/files/patch-gemspec | 20 +- deskutils/rubygem-shellplay/files/patch-gemspec | 18 +- devel/ruby-gems/Makefile | 17 +- devel/ruby-gems/distinfo | 6 +- .../files/patch-bundler-remove.patch (new) | 42 ++++ devel/ruby-gems/pkg-plist | 35 ++- devel/rubygem-activesupport4/files/patch-gemspec | 18 +- devel/rubygem-astrolabe/files/patch-gemspec | 18 +- devel/rubygem-azure_sdk/files/patch-gemspec | 20 +- devel/rubygem-cf-uaa-lib/files/patch-gemspec | 16 +- .../files/patch-chronic__duration.gemspec | 18 +- .../rubygem-cucumber-messages4/files/patch-gemspec | 18 +- devel/rubygem-errand/files/patch-gemspec | 16 +- devel/rubygem-fog/files/patch-gemspec | 32 +-- devel/rubygem-gettext-setup/files/patch-gemspec | 22 +- devel/rubygem-github_api/files/patch-gemspec | 18 +- .../rubygem-gitlab-pygments.rb/files/patch-gemspec | 18 +- devel/rubygem-gitlab_git/files/patch-gemspec | 24 +- devel/rubygem-jeweler/files/patch-gemspec | 20 +- devel/rubygem-kafo/files/patch-gemspec | 20 +- devel/rubygem-mongo/files/patch-gemspec | 6 +- devel/rubygem-ms_rest/files/patch-gemspec | 20 +- devel/rubygem-omnibus/files/patch-gemspec | 20 +- .../files/patch-gemspec | 18 +- devel/rubygem-pdk/files/patch-pdk.gemspec | 88 ++----- devel/rubygem-pleaserun/files/patch-gemspec | 20 +- devel/rubygem-pry-byebug/files/patch-gemspec | 18 +- devel/rubygem-rash/files/patch-gemspec | 18 +- devel/rubygem-rubygems-mirror/files/patch-gemspec | 18 +- devel/rubygem-ruport/files/patch-gemspec | 22 +- devel/rubygem-sidetiq/files/patch-gemspec | 20 +- .../files/patch-gemspec | 20 +- devel/rubygem-terrapin/files/patch-gemspec | 18 +- devel/rubygem-tilt1/files/patch-gemspec | 28 +-- devel/rubygem-travis/files/patch-gemspec | 20 +- devel/rubygem-tty/files/patch-gemspec | 84 +++---- devel/rubygem-turn/files/patch-gemspec | 18 +- emulators/rubygem-fission/files/patch-gemspec | 16 +- graphics/rubygem-gitlab_emoji/files/patch-gemspec | 18 +- irc/rubygem-cogbot/files/patch-gemspec | 46 ++-- mail/rubygem-vmail/files/patch-gemspec | 20 +- multimedia/rubygem-av/files/patch-av.gemspec | 20 +- net-im/rubygem-lita/files/patch-gemspec | 18 +- net-im/rubygem-termtter/files/patch-gemspec | 26 +- net-im/rubygem-tinder/files/patch-gemspec | 18 +- net-mgmt/rubygem-oxidized-web/files/patch-gemspec | 51 ++-- .../rubygem-oxidized/files/patch-oxidized.gemspec | 20 +- .../files/patch-riemann-client.gemspec | 33 +-- .../files/patch-riemann-dash.gemspec | 39 +-- .../files/patch-riemann-tools.gemspec | 25 +- net-mgmt/rubygem-visage-app/files/patch-gemspec | 32 +-- net/rubygem-amqp-utils/files/patch-gemspec | 34 +-- net/rubygem-fog-vsphere/files/patch-gemspec | 18 +- net/rubygem-kas-grpc/files/patch-kas-grpc.gemspec | 21 +- .../files/patch-spamcheck.gemspec | 21 +- net/rubygem-t/files/patch-gemspec | 23 +- net/rubygem-train/files/patch-gemspec | 24 +- net/rubygem-tweetstream/files/patch-gemspec | 20 +- net/rubygem-twitter-stream/files/patch-gemspec | 24 +- net/rubygem-twitter/files/patch-gemspec | 28 +-- .../files/patch-doorkeeper-openid__connect.gemspec | 18 +- sysutils/rhc/files/patch-gemspec | 20 +- sysutils/rubygem-backup/files/patch-gemspec | 268 ++++++++++----------- sysutils/rubygem-bolt/files/patch-bolt.gemspec | 74 ++---- sysutils/rubygem-bosh-gen/files/patch-gemspec | 20 +- sysutils/rubygem-chef/files/patch-gemspec | 20 +- .../files/patch-choria-mcorpc-support.gemspec | 23 +- sysutils/rubygem-license_scout/files/patch-gemspec | 28 +-- sysutils/rubygem-r10k/files/patch-r10k.gemspec | 75 ++---- sysutils/rubygem-specinfra/files/patch-gemspec | 41 +--- textproc/rubygem-gitlab-grit/files/patch-gemspec | 20 +- textproc/rubygem-html2text/files/patch-gemspec | 18 +- textproc/rubygem-nokogiri/files/patch-gemspec | 16 +- textproc/rubygem-nokogiri111/files/patch-gemspec | 16 +- www/rubygem-actioncable5/files/patch-gemspec | 20 +- www/rubygem-actioncable50/files/patch-gemspec | 20 +- www/rubygem-actionpack4/files/patch-gemspec | 20 +- www/rubygem-actionpack50/files/patch-gemspec | 20 +- .../files/patch-gitlab-gollum-lib.gemspec | 20 +- .../files/patch-gollum-lib.gemspec | 20 +- .../files/patch-gemspec | 24 +- www/rubygem-gollum/files/patch-gemspec | 34 +-- www/rubygem-http3/files/patch-gemspec | 18 +- www/rubygem-jekyll/files/patch-gemspec | 20 +- www/rubygem-jekyll3/files/patch-gemspec | 30 +-- www/rubygem-octopress/files/patch-gemspec | 18 +- www/rubygem-platform-api/files/patch-gemspec | 20 +- www/rubygem-rails4/files/patch-gemspec | 20 +- www/rubygem-rest-client/files/patch-gemspec | 20 +- www/rubygem-tumblr_client/files/patch-gemspec | 22 +- 94 files changed, 1191 insertions(+), 1342 deletions(-)
Thank you all for your help. Much appreciated.
*** Bug 260780 has been marked as a duplicate of this bug. ***
*** Bug 259491 has been marked as a duplicate of this bug. ***