bunlder/setup
and trying
to run the tests for Ruby 2.7 and 3.0. The problem is that the first tests will
create Gemfile.lock
(or gemfile/gemfile-*.lock
) using Ruby 2.7 and the next
run for Ruby 3 will report e.g.:
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.
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
.
gem2deb
bug reports. We uploaded the
last missing Kali Ruby package. And we had our last discussion, covering the
future of the team and an evaluation of the sprint:
As a result:
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
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.
]]>ruby-faraday 1.0
or the
upload of bundler 2.1
featuring the (first) contributions by bundler’s
upstream Deivid (yeah!). Further Red Hat’s (and Debian’s)
Marc Dequènes (Duck) joined us.
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.
]]>caff
and the current situation of keyservers, specifically
keys.openpgp.org
and hockeypuck
. (The traditional
SKS network plans to migrate to this software within this year.)
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:
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.
The latest version has been uploaded to Debian Experimental. The wiki informs about the packages required to be updated and/or fixed.
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.
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:
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).
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
.
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"