Bug#1023495: transition: ruby3.1
On 2022-11-30 09:14:55 -0300, Antonio Terceiro wrote: > On Wed, Nov 23, 2022 at 05:35:18PM +0100, Sebastian Ramacher wrote: > > Hi Antonio > > > > On 2022-11-23 13:13:37 -0300, Antonio Terceiro wrote: > > > On Tue, Nov 22, 2022 at 11:00:57PM +0100, Sebastian Ramacher wrote: > > > > On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > > > > > Hi Lucas, > > > > > > > > > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > > > > > After discussing with Antonio, since our deadline to finish the > > > > > > transition is approaching, we decided to already enable ruby3.1 as > > > > > > the > > > > > > default and remove ruby3.0 in a single step. > > > > > > > > > > I may be remembering wrong (it's a bit late), but isn't the change of > > > > > the > > > > > default a forward rebuild, while removal is a backward rebuild (I > > > > > mean in > > > > > the dependency tree)? If that's true, I think doing it in two steps is > > > > > easier to manage, as packages can then migrate on their own and don't > > > > > need a > > > > > lock step migration. > > > > > > > > That's correct. I'd prefer to handle this with two trackers. > > > > > > Fair enough. I will update ruby-defaults accordingly. Is it OK for us to > > > start the transition in unstable? > > > > I'd like protobuf to migrate first which is currently doing its own > > transition. Afer that, we can go ahead with the switch to 3.1 as > > default. > > protobuf migrate a few days ago, so I just uploaded ruby-defaults. > Please binNMU these packages: > > epic5 > graphviz > ignition-math > kamailio > klayout > kross-interpreters > libprelude > marisa > ngraph-gtk > notmuch > obexftp > redland-bindings > subtle > subversion > vim-command-t > weechat > xapian-bindings binNMUs scheduled Cheers -- Sebastian Ramacher
Bug#1023495: transition: ruby3.1
On Wed, Nov 23, 2022 at 05:35:18PM +0100, Sebastian Ramacher wrote: > Hi Antonio > > On 2022-11-23 13:13:37 -0300, Antonio Terceiro wrote: > > On Tue, Nov 22, 2022 at 11:00:57PM +0100, Sebastian Ramacher wrote: > > > On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > > > > Hi Lucas, > > > > > > > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > > > > After discussing with Antonio, since our deadline to finish the > > > > > transition is approaching, we decided to already enable ruby3.1 as the > > > > > default and remove ruby3.0 in a single step. > > > > > > > > I may be remembering wrong (it's a bit late), but isn't the change of > > > > the > > > > default a forward rebuild, while removal is a backward rebuild (I mean > > > > in > > > > the dependency tree)? If that's true, I think doing it in two steps is > > > > easier to manage, as packages can then migrate on their own and don't > > > > need a > > > > lock step migration. > > > > > > That's correct. I'd prefer to handle this with two trackers. > > > > Fair enough. I will update ruby-defaults accordingly. Is it OK for us to > > start the transition in unstable? > > I'd like protobuf to migrate first which is currently doing its own > transition. Afer that, we can go ahead with the switch to 3.1 as > default. protobuf migrate a few days ago, so I just uploaded ruby-defaults. Please binNMU these packages: epic5 graphviz ignition-math kamailio klayout kross-interpreters libprelude marisa ngraph-gtk notmuch obexftp redland-bindings subtle subversion vim-command-t weechat xapian-bindings signature.asc Description: PGP signature
Bug#1023495: transition: ruby3.1
Hi Antonio On 2022-11-23 13:13:37 -0300, Antonio Terceiro wrote: > On Tue, Nov 22, 2022 at 11:00:57PM +0100, Sebastian Ramacher wrote: > > On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > > > Hi Lucas, > > > > > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > > > After discussing with Antonio, since our deadline to finish the > > > > transition is approaching, we decided to already enable ruby3.1 as the > > > > default and remove ruby3.0 in a single step. > > > > > > I may be remembering wrong (it's a bit late), but isn't the change of the > > > default a forward rebuild, while removal is a backward rebuild (I mean in > > > the dependency tree)? If that's true, I think doing it in two steps is > > > easier to manage, as packages can then migrate on their own and don't > > > need a > > > lock step migration. > > > > That's correct. I'd prefer to handle this with two trackers. > > Fair enough. I will update ruby-defaults accordingly. Is it OK for us to > start the transition in unstable? I'd like protobuf to migrate first which is currently doing its own transition. Afer that, we can go ahead with the switch to 3.1 as default. Cheers -- Sebastian Ramacher
Bug#1023495: transition: ruby3.1
On Tue, Nov 22, 2022 at 11:00:57PM +0100, Sebastian Ramacher wrote: > On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > > Hi Lucas, > > > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > > After discussing with Antonio, since our deadline to finish the > > > transition is approaching, we decided to already enable ruby3.1 as the > > > default and remove ruby3.0 in a single step. > > > > I may be remembering wrong (it's a bit late), but isn't the change of the > > default a forward rebuild, while removal is a backward rebuild (I mean in > > the dependency tree)? If that's true, I think doing it in two steps is > > easier to manage, as packages can then migrate on their own and don't need a > > lock step migration. > > That's correct. I'd prefer to handle this with two trackers. Fair enough. I will update ruby-defaults accordingly. Is it OK for us to start the transition in unstable? signature.asc Description: PGP signature
Bug#1023495: transition: ruby3.1
On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > Hi Lucas, > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > After discussing with Antonio, since our deadline to finish the > > transition is approaching, we decided to already enable ruby3.1 as the > > default and remove ruby3.0 in a single step. > > I may be remembering wrong (it's a bit late), but isn't the change of the > default a forward rebuild, while removal is a backward rebuild (I mean in > the dependency tree)? If that's true, I think doing it in two steps is > easier to manage, as packages can then migrate on their own and don't need a > lock step migration. That's correct. I'd prefer to handle this with two trackers. Cheers -- Sebastian Ramacher
Bug#1023495: transition: ruby3.1
Hi Lucas, On 22-11-2022 17:03, Lucas Kanashiro wrote: After discussing with Antonio, since our deadline to finish the transition is approaching, we decided to already enable ruby3.1 as the default and remove ruby3.0 in a single step. I may be remembering wrong (it's a bit late), but isn't the change of the default a forward rebuild, while removal is a backward rebuild (I mean in the dependency tree)? If that's true, I think doing it in two steps is easier to manage, as packages can then migrate on their own and don't need a lock step migration. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1023495: transition: ruby3.1
After discussing with Antonio, since our deadline to finish the transition is approaching, we decided to already enable ruby3.1 as the default and remove ruby3.0 in a single step. We would like to ask the release team to also update the transition tracker with the following ben file (I hope it works out, any suggestion is welcome :) : title = "ruby3.1-default-ruby3.0-rm"; is_affected = (.depends ~ "ruby" | .depends ~ "libruby") & !.source ~ /^(ruby3.0|ruby3.1|ruby-defaults)$/; is_good =|(.depends ~ "ruby3.1" | .depends ~ "libruby3.1") & ! (.depends ~ "ruby3.0" | .depends ~ "libruby3.0");| is_bad = .depends ~ "ruby3.0" | .depends ~ "libruby3.0"; -- Lucas Kanashiro
Bug#1023495: transition: ruby3.1
Hi, We have been performing the rebuilds and fixing packages for a while, you can see the results of our last test rebuild (from the beginning of this month) here: https://people.debian.org/~kanashiro/ruby3.1 Some package listed as build failures were actually fixed already. From the list we have in the transition tracker: https://release.debian.org/transitions/html/ruby3.1-default.html Apart from the packages not in testing, only 2 packages are failing to build in the first dependency level: - dislocker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024589 . This one seems unrelated to this transition. - uwsgi: this needs a trivial patch in d/control to replace 3.0 with 3.1 in the uwsgi-plugin-rack-ruby3.0 binary name. This will be done once ruby3.1 becomes the default in unstable. All the others seem good to go. With that in mind, we would like to ask the Release Team if we can start the transition in unstable and change the default to 3.1. TIA! -- Lucas Kanashiro
Processed: Re: Bug#1023495: transition: ruby3.1
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/ruby3.1-default.html Bug #1023495 [release.debian.org] transition: ruby3.1 Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/ruby3.1-default.html'. -- 1023495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023495 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023495: transition: ruby3.1
Control: forwarded -1 https://release.debian.org/transitions/html/ruby3.1-default.html On 2022-11-05 09:23:03 -0300, Antonio Terceiro wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, I would like to plan the ruby 3.1 transition. As soon as we have the > tracker I will perform all the test rebuilds necessary and report any > bugs. > > Ben file: > > title = "ruby3.1 as default"; > is_affected = (.depends ~ /ruby3.0/ | .depends ~ /ruby3.1/) & !.source ~ > /^(ruby3.0|ruby3.1|ruby-defaults)$/; > is_good = .depends ~ "ruby3.1" | .depends ~ "libruby3.1" | ! (.depends ~ > "ruby3.0" | .depends ~ "libruby3.0"); > is_bad = ! (.depends ~ "ruby3.1" | .depends ~ "libruby3.1") & (.depends ~ > "ruby3.0" | .depends ~ "libruby3.0"); The tracker is available at https://release.debian.org/transitions/html/ruby3.1-default.html Cheers -- Sebastian Ramacher
Bug#1023495: transition: ruby3.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to plan the ruby 3.1 transition. As soon as we have the tracker I will perform all the test rebuilds necessary and report any bugs. Ben file: title = "ruby3.1 as default"; is_affected = (.depends ~ /ruby3.0/ | .depends ~ /ruby3.1/) & !.source ~ /^(ruby3.0|ruby3.1|ruby-defaults)$/; is_good = .depends ~ "ruby3.1" | .depends ~ "libruby3.1" | ! (.depends ~ "ruby3.0" | .depends ~ "libruby3.0"); is_bad = ! (.depends ~ "ruby3.1" | .depends ~ "libruby3.1") & (.depends ~ "ruby3.0" | .depends ~ "libruby3.0"); signature.asc Description: PGP signature
