Re: Backporting ruby 2.7 for gitlab
On Sun, Jul 5, 2020 at 00:27, Pirate Praveen wrote: On Sat, Jul 4, 2020 at 00:22, Pirate Praveen wrote: On Tue, Jun 30, 2020 at 10:47, Antonio Terceiro wrote: On Tue, Jun 30, 2020 at 06:06:56PM +0530, Pirate Praveen wrote: I don't really care if you include it in fasttrack. As people started reporting more bugs, I decided to add ruby 2.7 to fasttrack. Some issues that popped up, ruby-msgpack needs gem2deb >= 1.0 to build with ruby 2.7 (possibly true for all native gems). Should I add this minimum version in the master branch? While building node-bootstrap, I found this error, /usr/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': can't find gem bundler (= 2.1.4) with executable bundle (Gem::GemNotFoundException) So it looks to me ruby2.7 should have a tightened Depends on ruby-bundler here. rdoc is failing for 3 packages in the same way with error, rdoc --op rdoc --main README.rdoc --title "pg: The Ruby Interface to PostgreSQL" lib/ ext/*.c README.rdoc /usr/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': can't find gem rdoc (>= 0.a) with executable rdoc (Gem::GemNotFoundException) from /usr/lib/ruby/2.7.0/rubygems.rb:294:in `activate_bin_path' from /usr/bin/rdoc:23:in `' https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/166 has the current status missing bundler and rdoc erros were fixed by updating rubygems-intergration
Re: Backporting ruby 2.7 for gitlab
On Sat, Jul 4, 2020 at 00:22, Pirate Praveen wrote: On Tue, Jun 30, 2020 at 10:47, Antonio Terceiro wrote: On Tue, Jun 30, 2020 at 06:06:56PM +0530, Pirate Praveen wrote: I don't really care if you include it in fasttrack. As people started reporting more bugs, I decided to add ruby 2.7 to fasttrack. Some issues that popped up, ruby-msgpack needs gem2deb >= 1.0 to build with ruby 2.7 (possibly true for all native gems). Should I add this minimum version in the master branch? While building node-bootstrap, I found this error, /usr/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': can't find gem bundler (= 2.1.4) with executable bundle (Gem::GemNotFoundException) So it looks to me ruby2.7 should have a tightened Depends on ruby-bundler here. rdoc is failing for 3 packages in the same way with error, rdoc --op rdoc --main README.rdoc --title "pg: The Ruby Interface to PostgreSQL" lib/ ext/*.c README.rdoc /usr/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': can't find gem rdoc (>= 0.a) with executable rdoc (Gem::GemNotFoundException) from /usr/lib/ruby/2.7.0/rubygems.rb:294:in `activate_bin_path' from /usr/bin/rdoc:23:in `' https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/166 has the current status
Re: Backporting ruby 2.7 for gitlab
On Tue, Jun 30, 2020 at 10:47, Antonio Terceiro wrote: On Tue, Jun 30, 2020 at 06:06:56PM +0530, Pirate Praveen wrote: I don't really care if you include it in fasttrack. As people started reporting more bugs, I decided to add ruby 2.7 to fasttrack. Some issues that popped up, ruby-msgpack needs gem2deb >= 1.0 to build with ruby 2.7 (possibly true for all native gems). Should I add this minimum version in the master branch? While building node-bootstrap, I found this error, /usr/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': can't find gem bundler (= 2.1.4) with executable bundle (Gem::GemNotFoundException) So it looks to me ruby2.7 should have a tightened Depends on ruby-bundler here.
Re: Backporting ruby 2.7 for gitlab
Hi, On 20-06-30 10:47:53, Antonio Terceiro wrote: > To be clear: my opinion is that such backport should not be uploaded > to Debian Backports, at all. I agree, for the reasons outlined, and personally, I'm not able to support such an effort. Cheers, Georg
Re: Backporting ruby 2.7 for gitlab
On Tue, Jun 30, 2020 at 06:06:56PM +0530, Pirate Praveen wrote: > > > On Tue, Jun 30, 2020 at 09:26, Antonio Terceiro wrote: > > On Tue, Jun 30, 2020 at 05:21:53PM +0530, Pirate Praveen wrote: > > > Hi, > > > > > > gitlab stopped working with ruby 2.5 (they officially dropped > > > support long > > > ago, but it was working fine till now). See > > > https://gitlab.com/gitlab-org/gitlab/-/issues/225251 for details. > > > In last > > > stable release we were lucky things worked with ruby 2.3 even > > > though it was > > > not officially supported. > > > > > > Option 1. Backport ruby 2.7 > > > > > > I could upload it to fasttrack as well, but I'd prefer more people > > > benefit > > > it by having it in backports since I'm doing the backport work > > > anyway. > > > > > > On a gitlab installation, > > > $ ls /usr/share/rubygems-integration/2.5.0/specifications/ -1 |wc -l > > > 47 > > > > > > So we will have to backport at least these many modules as well. > > > > > > Option 2. Patch gitlab to work with ruby 2.5 > > > We can also try to fix issues with ruby 2.5 as and when we notice > > > it as > > > well, but if there not many takers for it, I don't think that can > > > work well. > > > > > > Option 1 requires only packaging knowledge but Option 2 requires > > > ruby > > > knowledge. > > > > For such a backport to work for gitlab, you would need to either a) > > backport ruby-defaults as well to make /usr/bin/ruby by ruby2.7 or b) > > change all binaries in gitlab to use /usr/bin/ruby2.7 explicitly. > > > > a) is very risky as none of the other Ruby software in stable has been > > tested with ruby2.7. This will cause random stuff to break and I don't > > want to be involved in supporting that. > > > > Thanks for your input. Though only someone explicitly installing ruby from > backports will get ruby 2.7 so it is not correct to say it is going to > regular stable. And all gitlab dependencies are already tested with ruby 2.7 > in unstable. People regularly install stuff from backports regardless of specifically needing it. Any users that get such new ruby from backports, either because of gitlab, or just because they can, will be susceptible to having other Ruby software from stable randomly break. An example: IIRC both chef and puppet needed fixes for ruby2.7; this means that gitlab users with this new ruby will be unable to manage their servers with either chef or puppet, unless you also fix those in stable and/or provide backports. > > b) requires changing gitlab somehow anyway, so you might as well fix the > > actual issues with ruby2.5 instead. FWIW I don't think it's realistic to > > maintain a fast-moving, enormous beast such as gitlab for stable and > > expect to not need to get your hands dirty in its code. > > Like I said, it is about what expertise you need. For backporting, I can use > the expertise I already have in backporting and depend on upstream for ruby > specific help if I stay close to what they officially support (if the issue > is reproducible in their ci). I'd have to get into ruby code often, but if > some of it can be avoided, by even having to do some extra work, I'd prefer > to. > > Anyway this specific issue is resolved and I will consider this again > if/when we get such issues in future. Thanks for the patch. > > I'd still like to know if anyone else in the team would be interested in > maintaining such a backport. If no one volunteers, I can still have it in > fasttrack, which will affect only gitlab users (for now, no other software > in there yet). To be clear: my opinion is that such backport should not be uploaded to Debian Backports, at all. I don't really care if you include it in fasttrack. signature.asc Description: PGP signature
Re: Backporting ruby 2.7 for gitlab
On Tue, Jun 30, 2020 at 09:26, Antonio Terceiro wrote: On Tue, Jun 30, 2020 at 05:21:53PM +0530, Pirate Praveen wrote: Hi, gitlab stopped working with ruby 2.5 (they officially dropped support long ago, but it was working fine till now). See https://gitlab.com/gitlab-org/gitlab/-/issues/225251 for details. In last stable release we were lucky things worked with ruby 2.3 even though it was not officially supported. Option 1. Backport ruby 2.7 I could upload it to fasttrack as well, but I'd prefer more people benefit it by having it in backports since I'm doing the backport work anyway. On a gitlab installation, $ ls /usr/share/rubygems-integration/2.5.0/specifications/ -1 |wc -l 47 So we will have to backport at least these many modules as well. Option 2. Patch gitlab to work with ruby 2.5 We can also try to fix issues with ruby 2.5 as and when we notice it as well, but if there not many takers for it, I don't think that can work well. Option 1 requires only packaging knowledge but Option 2 requires ruby knowledge. For such a backport to work for gitlab, you would need to either a) backport ruby-defaults as well to make /usr/bin/ruby by ruby2.7 or b) change all binaries in gitlab to use /usr/bin/ruby2.7 explicitly. a) is very risky as none of the other Ruby software in stable has been tested with ruby2.7. This will cause random stuff to break and I don't want to be involved in supporting that. Thanks for your input. Though only someone explicitly installing ruby from backports will get ruby 2.7 so it is not correct to say it is going to regular stable. And all gitlab dependencies are already tested with ruby 2.7 in unstable. b) requires changing gitlab somehow anyway, so you might as well fix the actual issues with ruby2.5 instead. FWIW I don't think it's realistic to maintain a fast-moving, enormous beast such as gitlab for stable and expect to not need to get your hands dirty in its code. Like I said, it is about what expertise you need. For backporting, I can use the expertise I already have in backporting and depend on upstream for ruby specific help if I stay close to what they officially support (if the issue is reproducible in their ci). I'd have to get into ruby code often, but if some of it can be avoided, by even having to do some extra work, I'd prefer to. Anyway this specific issue is resolved and I will consider this again if/when we get such issues in future. Thanks for the patch. I'd still like to know if anyone else in the team would be interested in maintaining such a backport. If no one volunteers, I can still have it in fasttrack, which will affect only gitlab users (for now, no other software in there yet).
Re: Backporting ruby 2.7 for gitlab
On Tue, Jun 30, 2020 at 05:21:53PM +0530, Pirate Praveen wrote: > Hi, > > gitlab stopped working with ruby 2.5 (they officially dropped support long > ago, but it was working fine till now). See > https://gitlab.com/gitlab-org/gitlab/-/issues/225251 for details. In last > stable release we were lucky things worked with ruby 2.3 even though it was > not officially supported. > > Option 1. Backport ruby 2.7 > > I could upload it to fasttrack as well, but I'd prefer more people benefit > it by having it in backports since I'm doing the backport work anyway. > > On a gitlab installation, > $ ls /usr/share/rubygems-integration/2.5.0/specifications/ -1 |wc -l > 47 > > So we will have to backport at least these many modules as well. > > Option 2. Patch gitlab to work with ruby 2.5 > We can also try to fix issues with ruby 2.5 as and when we notice it as > well, but if there not many takers for it, I don't think that can work well. > > Option 1 requires only packaging knowledge but Option 2 requires ruby > knowledge. For such a backport to work for gitlab, you would need to either a) backport ruby-defaults as well to make /usr/bin/ruby by ruby2.7 or b) change all binaries in gitlab to use /usr/bin/ruby2.7 explicitly. a) is very risky as none of the other Ruby software in stable has been tested with ruby2.7. This will cause random stuff to break and I don't want to be involved in supporting that. b) requires changing gitlab somehow anyway, so you might as well fix the actual issues with ruby2.5 instead. FWIW I don't think it's realistic to maintain a fast-moving, enormous beast such as gitlab for stable and expect to not need to get your hands dirty in its code. signature.asc Description: PGP signature
Backporting ruby 2.7 for gitlab
Hi, gitlab stopped working with ruby 2.5 (they officially dropped support long ago, but it was working fine till now). See https://gitlab.com/gitlab-org/gitlab/-/issues/225251 for details. In last stable release we were lucky things worked with ruby 2.3 even though it was not officially supported. Option 1. Backport ruby 2.7 I could upload it to fasttrack as well, but I'd prefer more people benefit it by having it in backports since I'm doing the backport work anyway. On a gitlab installation, $ ls /usr/share/rubygems-integration/2.5.0/specifications/ -1 |wc -l 47 So we will have to backport at least these many modules as well. Option 2. Patch gitlab to work with ruby 2.5 We can also try to fix issues with ruby 2.5 as and when we notice it as well, but if there not many takers for it, I don't think that can work well. Option 1 requires only packaging knowledge but Option 2 requires ruby knowledge. Thanks Praveen
