Failure/Error: require 'bundler/setup' # Set up gems listed in the Gemfile.

Bundler::GemNotFound:
  Could not find racc-1.4.16 in any of the sources

or

/usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/definition.rb:496:in `materialize':
  Could not find rexml-3.2.3.1 in any of the sources (Bundler::GemNotFound)

Both bugs #996207 and #996302 are incarnations of this issue. The fix is as easy as making sure that the .lock files are removed before each run. This can be done in e.g. debian/ruby-tests.rake as very first task:

File.delete("Gemfile.lock") if File.exist?("Gemfile.lock")

In another case the .lock file is created by the tests in gemfiles/. While the first examples could actually be solved by gem2deb removing Gemfile.lock on its own, I’m not quite sure how to handle the last case using packaging tools.

The interesting part is that we will unlikely be confronted with this issue anytime soon again. It seems very specific to the Ruby 3.0 transition.

Update

After talking to Antonio he added some code to gem2deb-test-runner to moving Gemfile.lock files out of the way. The tool already did this in an autopkgtest environment. In the upcoming 1.7 release it will do it in general and this will fix some more FTBFSes, e.g. #998497 and #996141 - originally reported against ruby-voight-kampff and ruby-bootsnap.

During the Ruby 3.0 transition there are essentially two different Ruby versions with two different binaries available, /usr/bin/ruby2.7 and /usr/bin/ruby3.0, while /usr/bin/ruby points to the current default version, which is Ruby 2.7.

In some cases the tests shipped by the source packages will use shell commands to run scripts or Ruby code. It is imparative that in these cases the Ruby executable is not invoked by /usr/bin/ruby or ruby, because this will point to Ruby 2.7 only and fail if the tests are invoked with Ruby version 3.

The fix is to rely on RbConfig.ruby which will point to the absolute pathname of the ruby command for the current Ruby environment, e.g.

cmd = "#{RbConfig.ruby} ..."

This issue appeard for example in ruby-byebug and ruby-backports.

As a result:

• We will examine ways to find leaf packages.
• We plan to organize another sprint next year right before the release freeze, probably again about FOSDEM time. We tend to have it in Berlin but will explore the locations available and the costs.
• We will have monthly IRC meetings.

We think the sprint was a success. Some stuff got (intentionally and less intentionally) broken on the way. And also a lot of stuff got fixed. Eventually we made our step towards a successful Ruby 2.7 transition.

So we want to thank

• the Debian project and our DPL Sam for sponsoring the event,
• Offensive Security for sponsoring the event too,
• Sorbonne Université and LPSM for hosting us,
• Cédric Boutillier for organizing the sprint and kindly hosting us,
• and really everyone who attended, making this a success: Antonio, Abhijith, Georg, Utkarsh, Balu, Praveen, Sruthi, Marc, Lucas, Cédric, Sebastien, Deivid, Daniel.

In the evening we finally closed the venue which hosted us for 5 days, cleaned up, and went for a last beer together (at least for now). Some of us will stay in Paris a few days longer and finally get to see the city.

Goodbye Paris and save travels to everyone. It was a pleasure.

We are proud to report, that updating and/or uploading the Kali packages is almost done. Most are in NEW or have already been accepted.

The Release team was contacted to start the Ruby 2.7 transition and we already have a transition page. However, the Python 3.8 one is ongoing (almost finished) and the Release team does not want overlaps. So hopefully we can upload ruby-defaults to Debian Unstable soon.

In the evening we got together for a well earned collective drink at Brewberry Bar and dinner, joined by local Debian colleague Nicolas Dandrimont (olasd).

The evening ended at Paris’ famous (but heavily damaged) Notre-Dame cathedral.

Regarding Salsa, Antonio was able to fix gem2deb so our extension packages finally build reprodicibly (Yeah!). The decision to disable the piuparts job on Salsa was discussed again. The tool provides a major functionality in question of preventing “toxic” uploads. But these issues usually occur on quite rare occasions. We think the decision to enable the piuparts job only for critical packages or on a case-by-case base is a sensible approach. But we would of course prefer to not have to make this decision just to go easy on Salsa’s resources.

Regarding the complex packaging situation of gitlab and the high likability to break it by uploading new major releases we decided to upload new major versions to Experimental only and enable a subset of gitlab’s tests to discover breakages more easily.

Some leaf packages have been found during our Sprint days. This led to the question how to identify candidates for an archive removal. It seems there is no tool to check the whole archive for packages without any reverse-dependencies (Depends, Suggests, Recommends, and Build-Depends). The reverse-depends tool can do this for one package and would need to be run against all team packages. Also we would like to identify packages, which have low popcon values, few reverse dependencies, and could be replaced by more recent packages, actively maintained by an upstream. We decided to pick up this question again on our last days’ discussion.

As a result of Day Two we achieved the following:

Ruby 2.7 transition

Most key arch:any packages are now fixed or being worked on. The next step will be to rebuild all arch:all packages to find build failures.

Rails 6 transition

The latest version has been uploaded to Debian Experimental. The wiki informs about the packages required to be updated and/or fixed.

Improving/optimizing our usage of the Salsa CI pipeline

We tend to disable the blhc, reprotest, and piuparts jobs of the Salsa CI pipeline by default for all group projects. For C-extension packages bhlc and reprotest will be re-enabled by default. piuparts could be enabled for some critical packages.

We first thought about setting the relevant pipeline variables (SALSA_CI_DISABLE_*) to zero via group variables and let maintainers decide on a case-by-case base to re-enable them via project variables. But it seems more convenient and apparent to instead create our own pipeline file (include the Salsa CI pipeline and set variables there) and include it from all our projects.

Maintainers can still temporarily enable or disable jobs by running a pipeline using the web-interface or API passing the variables along.

New items on our TODO list for next days

• Start bug triage and fixing for gem2deb.
• Productize team tools.
• Fix reprotest failing for all our C-extensions (culprit found).
• Finish the Kali Ruby packages.
• Complete source-only uploads for all accepted packages from NEW.

Package uploads and bugs fixed

The number is hard to track as members of the group worked all day and even late in the evening. It is safe to say that it is again a two digit number.

Day One consisted of setting up at the venue, Campus 4 of the Sorbonne University, as well as collecting and discussing our tasks for the next days, and starting the work. The main goals so far for the sprint are:

• Update packages in preparation for the Ruby 2.7 transition
• Update packages for the Rails 6 transition
• Fix several testing migration issues
• Improve the team’s tools and workflow
  • Optimize usage of Salsa CI and reduce workload for Salsa service
  • Prevent breakages by minor transitions
• Fix team specific issues
  • Remove the interpreter dependency from libraries
  • Handle rubygems integration warnings (working together with Deivid Rodríguez, upstream rubygems maintainer, who kindly agreed to join the sprint).
  • Optimize and improve installed gemspecs
• Reduce the differences for Ruby packages on Kali Linux

There are more items on the list which will be discussed during the following days.

At the end of Day One there is already a two digit number of both packages uploaded and bugs approached and fixed, and we managed to go through half of the topics that required discussion.

We hope to be able to keep up the good work and finish on Friday with a lot of our goals to be reached, taking a big step ahead.

Only fastercsv, reverse_markup, behance and unidecode must be packaged as (runtime dependencies).

Using jekyll-import right now with bundler

If you are in need of these importers you can use this Gemfile:

source "https://rubygems.org"
ruby RUBY_VERSION

gem "jekyll-import"

then set GEM_HOME to somewhere you are allowed to write to (e.g. $HOME/.gem/) and run bundle install on the Gemfile:

$ export GEM_HOME=$HOME/.gem/
$ bundle install

Then write your importer (mine) and run it with ruby.

Using jekyll-import right now mixing Debian packages and bundler

If you want to minimize the installation of non-Debian provided gems you probably want to run this on Debian Sid:

$ apt-get install ruby-public-suffix ruby-concurrent ruby-eventmachine \
                  ruby-ffi ruby-rb-inotify ruby-listen ruby-nokogiri \
                  ruby-bundler ruby-concurrent ruby-http-parser.rb ruby-sass \
                  ruby-forwardable-extended jekyll

This installs all the necessary ruby packages. Then run bundle install on the following Gemfile:

source "https://rubygems.org"
ruby RUBY_VERSION

# This will help ensure the proper Jekyll version is running.
gem "jekyll", "~> 3.8.3.0"

# This will ensure we use the ruby packages in Sid.
gem "concurrent-ruby", "~> 1.0.5.0"
gem "eventmachine", "~> 1.0.7.0"
gem "ffi", "~> 1.9.10.0"
gem "listen", "~> 3.1.5.0"
gem "nokogiri", "~> 1.10.4.0"
gem "pathutil", "~> 0.16.1.0"
gem "public_suffix", "~> 3.0.3.0"
gem "rb-inotify", "~> 0.9.10.0"

# This will install jekyll-import.
gem "jekyll-import"