Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
Control: severity -1 serious Justification: this package depends on ruby 2.7, gone from bookworm. See below. On 2022-04-14 10:12:25, Gabriel Filion wrote: > in current debian testing, ruby has been transitioned to 3.0 and judging > from the release history, puppet has not added support for ruby 3.0 > until 7.8.0: > > https://puppet.com/docs/puppet/7/release_notes_puppet.html#enhancements_puppet_x-7-8-0-pup-11076 > > and also, as was noted in #1009643 the puppet tests fail on 3.0 which > seems to indicate that supporting puppet 5.5 in debian testing will be > quite difficult. > > Because of that information I think we should aim for removing puppet 5 > from testing and then move on to the discussion of packaging future > versions. > > that same argument about ruby 3.0 support would lead me to believe that > aiming for puppet 6 would be a mistake (that and the EOL date for puppet > 6 which will be very close to a debian release). Agreed. Let's remove it for now. When we land a Puppet agent 7 here, this bug can be closed and the package will migrate down to bookworm again. > in the #puppet channel on chat.libera.net, a couple poeple told me that > since puppet 4.x the differences in terms of manifests are mostly > additive and don't see many breakage at all between major versions, and > that would be true until at least puppet 7. so it should be possible for > users to jump from 5 to 7 directly I proposed as much in the "policy" thread, so I think that would really make a lot of sense. Worst case, this fails and we *also* need to package Puppet server 6 in fasttrack. Thanks for the heads up. a. -- Le péché est né avant la vertu, comme le moteur avant le frein. - Jean-Paul Sartre
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
Hi there, I'm just chiming in to add yet another object on the scale: in current debian testing, ruby has been transitioned to 3.0 and judging from the release history, puppet has not added support for ruby 3.0 until 7.8.0: https://puppet.com/docs/puppet/7/release_notes_puppet.html#enhancements_puppet_x-7-8-0-pup-11076 and also, as was noted in #1009643 the puppet tests fail on 3.0 which seems to indicate that supporting puppet 5.5 in debian testing will be quite difficult. Because of that information I think we should aim for removing puppet 5 from testing and then move on to the discussion of packaging future versions. that same argument about ruby 3.0 support would lead me to believe that aiming for puppet 6 would be a mistake (that and the EOL date for puppet 6 which will be very close to a debian release). in the #puppet channel on chat.libera.net, a couple poeple told me that since puppet 4.x the differences in terms of manifests are mostly additive and don't see many breakage at all between major versions, and that would be true until at least puppet 7. so it should be possible for users to jump from 5 to 7 directly On Thu, 31 Mar 2022 11:24:34 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= wrote: On 2022-03-31 17:05:19, Thomas Goirand wrote: > On 3/29/22 21:08, Antoine Beaupré wrote: >> On 2020-02-02 13:06:42, Thomas Goirand wrote: >> >> [...] >> >>> FYI, I packaged and uploaded the first 2 so far, but can't push to Git. >>> Please set me as maintainer or owner, so I can do that. >>> >>> Note that I'm doing a git based workflow, packaging upstream tags, >>> rather than using pristine-tar. If this bothers anyone, please let me >>> know (but please only complain about the workflow if you really have the >>> intention to contribute to the packaging, otherwise you're just getting >>> on my way to be efficient for no reason). >> >> Not sure I'm picking the right message to reply to here, but here we go. >> >> I see that you uploaded 6.16.0-1 to experimental back in December 2020: >> >> https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/ >> >> Is that package in any shape to ship with bookworm? It would be great to >> start this transition to get the package down into testing soon... > > Uploading it will break current puppet-master. Unless we have a solution > to replace it, I don't want to do that... I understand that, but my perspective is that we *want* to break the current, 5.5 puppet master. We do *not* want to ship that in bookworm. So breaking it is acceptable in that sense, to me. But I guess it's pointless to keep arguing that same point. :) -- The survival of humans and other species on planet Earth in my view can only be guaranteed via a timely transition towards a stationary state, a world economy without growth. - Peter Custers
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
On 2022-03-31 17:05:19, Thomas Goirand wrote: > On 3/29/22 21:08, Antoine Beaupré wrote: >> On 2020-02-02 13:06:42, Thomas Goirand wrote: >> >> [...] >> >>> FYI, I packaged and uploaded the first 2 so far, but can't push to Git. >>> Please set me as maintainer or owner, so I can do that. >>> >>> Note that I'm doing a git based workflow, packaging upstream tags, >>> rather than using pristine-tar. If this bothers anyone, please let me >>> know (but please only complain about the workflow if you really have the >>> intention to contribute to the packaging, otherwise you're just getting >>> on my way to be efficient for no reason). >> >> Not sure I'm picking the right message to reply to here, but here we go. >> >> I see that you uploaded 6.16.0-1 to experimental back in December 2020: >> >> https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/ >> >> Is that package in any shape to ship with bookworm? It would be great to >> start this transition to get the package down into testing soon... > > Uploading it will break current puppet-master. Unless we have a solution > to replace it, I don't want to do that... I understand that, but my perspective is that we *want* to break the current, 5.5 puppet master. We do *not* want to ship that in bookworm. So breaking it is acceptable in that sense, to me. But I guess it's pointless to keep arguing that same point. :) -- The survival of humans and other species on planet Earth in my view can only be guaranteed via a timely transition towards a stationary state, a world economy without growth. - Peter Custers
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
On 3/29/22 21:08, Antoine Beaupré wrote: On 2020-02-02 13:06:42, Thomas Goirand wrote: [...] FYI, I packaged and uploaded the first 2 so far, but can't push to Git. Please set me as maintainer or owner, so I can do that. Note that I'm doing a git based workflow, packaging upstream tags, rather than using pristine-tar. If this bothers anyone, please let me know (but please only complain about the workflow if you really have the intention to contribute to the packaging, otherwise you're just getting on my way to be efficient for no reason). Not sure I'm picking the right message to reply to here, but here we go. I see that you uploaded 6.16.0-1 to experimental back in December 2020: https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/ Is that package in any shape to ship with bookworm? It would be great to start this transition to get the package down into testing soon... Uploading it will break current puppet-master. Unless we have a solution to replace it, I don't want to do that... Cheers, Thomas Goirand (zigo)
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
On 2020-02-02 13:06:42, Thomas Goirand wrote: [...] > FYI, I packaged and uploaded the first 2 so far, but can't push to Git. > Please set me as maintainer or owner, so I can do that. > > Note that I'm doing a git based workflow, packaging upstream tags, > rather than using pristine-tar. If this bothers anyone, please let me > know (but please only complain about the workflow if you really have the > intention to contribute to the packaging, otherwise you're just getting > on my way to be efficient for no reason). Not sure I'm picking the right message to reply to here, but here we go. I see that you uploaded 6.16.0-1 to experimental back in December 2020: https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/ Is that package in any shape to ship with bookworm? It would be great to start this transition to get the package down into testing soon... Note that we're likely to miss the February 2023 deadline for the Puppet 6 EOL anyways: https://puppet.com/docs/puppet/6/platform_lifecycle.html ... so maybe we don't even want to do that? or maybe we should focus on packaging Puppet 7? I was hoping for a moment we could ship bookworm with the Puppet 6 agent which would allow us work with a puppetserver 7, but it seems even that won't keep us from shipping an EOL component (puppet agent 6)... a. -- La mer, cette grande unificatrice, est l'unique espoir de l'homme. Aujourd'hui plus que jamais auparavant, ce vieux dicton dit littéralement ceci: nous sommes tous dans le même bateau. - Jacques Yves Cousteau - Océanographe
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
Thomas Goirand writes: > Note that I'm doing a git based workflow, packaging upstream tags, > rather than using pristine-tar. If this bothers anyone, please let me > know (but please only complain about the workflow if you really have > the intention to contribute to the packaging, otherwise you're just > getting on my way to be efficient for no reason). I'm moving from pristine-tar to git based workflows for my own things, and getting more and more impressed with dgit, so I won't complain. :) -- Stig Sandbeck Mathisen Debian Developer
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
On 2/1/20 10:51 AM, Stig Sandbeck Mathisen wrote: > Thomas Goirand writes: > >> Could you list them? I'd be ok to do that work within the team, if >> someone else is working on Puppet itself. > >>From the "puppet-agent" repository, at > https://github.com/puppetlabs/puppet-agent/blob/6.4.x/configs/projects/puppet-agent.rb#L116 > > puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core > puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core > puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core > puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core > puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core > puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core > puppetlabs-yumrepo_core https://forge.puppet.com/puppetlabs/yumrepo_core > puppetlabs-zfs_core https://forge.puppet.com/puppetlabs/zfs_core > puppetlabs-zone_core https://forge.puppet.com/puppetlabs/zone_core > puppetlabs-scheduled_task https://forge.puppet.com/puppetlabs/scheduled_task > >>> From a user point of view, the missing modules mainly shows up when >>> doing rspec module testing. >> >> So, we're talking about Ruby stuff? > > The resource types and provides are written in ruby, but distributed as > puppet modules. > > When testing puppet modules, and your code use the "cron", "host", > "mount" (from the list above) resource types, they need to be present. > > The resource types are present in the puppet 5 source repository, while > in puppet 6, they are maintained as separate puppet modules in their own > repositories, and we would need to add them as packaged dependencies. > > -- > Stig Sandbeck Mathisen > Debian Developer > FYI, I packaged and uploaded the first 2 so far, but can't push to Git. Please set me as maintainer or owner, so I can do that. Note that I'm doing a git based workflow, packaging upstream tags, rather than using pristine-tar. If this bothers anyone, please let me know (but please only complain about the workflow if you really have the intention to contribute to the packaging, otherwise you're just getting on my way to be efficient for no reason). Cheers, Thomas Goirand (zigo)
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
Thomas Goirand writes: > Could you list them? I'd be ok to do that work within the team, if > someone else is working on Puppet itself. >From the "puppet-agent" repository, at https://github.com/puppetlabs/puppet-agent/blob/6.4.x/configs/projects/puppet-agent.rb#L116 puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core puppetlabs-yumrepo_core https://forge.puppet.com/puppetlabs/yumrepo_core puppetlabs-zfs_core https://forge.puppet.com/puppetlabs/zfs_core puppetlabs-zone_core https://forge.puppet.com/puppetlabs/zone_core puppetlabs-scheduled_task https://forge.puppet.com/puppetlabs/scheduled_task >> From a user point of view, the missing modules mainly shows up when >> doing rspec module testing. > > So, we're talking about Ruby stuff? The resource types and provides are written in ruby, but distributed as puppet modules. When testing puppet modules, and your code use the "cron", "host", "mount" (from the list above) resource types, they need to be present. The resource types are present in the puppet 5 source repository, while in puppet 6, they are maintained as separate puppet modules in their own repositories, and we would need to add them as packaged dependencies. -- Stig Sandbeck Mathisen Debian Developer
