Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1
I have just pushed some meta-data updates, and also a change that fixes CVE-2023-4237 in this package. See the commit logs here: https://salsa.debian.org/python-team/packages/ansible/-/commits/debian/bookworm-proposed/
Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1
On Fri, 26 Apr 2024 15:05:00 +0200 Lee Garrett wrote:
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ansi...@packages.debian.org, deb...@rocketjump.eu
Control: affects -1 + src:ansible
Hi,
I'm requesting to bump the version of the ansible package ("ansible-community
collection") to the last minor semantic version of the v7 series in bookworm.
This version has previously spent ~10 months in testing/unstable, so I'm fairly
confident that any potential regressions would have been caught (so far none).
[ Reason ]
This incorporates the latest bugfixes from the v7 series, which update all
modules in the collection. These contain updates to handle:
- distro releases that have been released since
- web API changes that ansible can run against
- various bugfixes
- deprecation warnings that will be useful for users before they upgrade to
bookworm + 1
Most importantly due to semantic versioning, there is no user-visible change.
Any previous playbooks will continue to work without changes.
I intend to use the 7.7.0 release as a basis for security support until bookworm
LTS EOL.
[ Impact ]
(What is the impact for the user if the update isn't approved?)
If the update is not approved, users will likely report errors that have already
been fixed in the latest minor release, and I'd have to cherrypick those
changes, add roundtrip time to the process.
[ Tests ]
autopkgtests have been widely expanded from the previous 7.3.0 release, covering
more unit tests than before.
[ Risks ]
There is a small risk of regressions, but I believe the risk to be minimal as no
such regressions have been reported in the 10 months in testing/unstable.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
- upstream update to 7.7.0
Forgot to add the link with the high-level upstream changes:
https://salsa.debian.org/debian/ansible/-/blob/debian/bookworm-proposed/CHANGELOG-v7.rst
- fixes to the libvirt connection plugin that bit me
- updates to the package metadata
- widely expanded autopkgtests for more coverage
[ Other info ]
This is my first s-p-u process, let me know what I can do better for any
following s-p-u.
Bug#1032460: unblock: thinkfan/1.3.1-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: think...@packages.debian.org, deb...@rocketjump.eu
Control: affects -1 + src:thinkfan
Hello release team,
Please unblock package thinkfan. It is a tool to control the fans of Thinkpad
laptops. zcfan is a similar tool that also handles fan control on Thinkpads. To
prevent hardware damage, only one should be installed at the same time
(#1032310).
[ Reason ]
It fixes an RC bug (#1032310).
[ Impact ]
Users could accidentally install both zcfan and thinkfan at the same time during
triage, causing unpredictable fan speed, and at worst cause hardware damage.
[ Tests ]
I have manually tested that the added "Conflicts: zcfan" works as intended.
[ Risks ]
Both thinkfan and zcfan are leaf packages. There is no risk as this change just
adds a "Conflicts" between those packages.
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
$ debdiff thinkfan_1.3.1-3_amd64.deb thinkfan_1.3.1-4_amd64.deb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
{+Conflicts: zcfan+}
Depends: libatasmart4 (>= 0.13), libc6 (>= [-2.30),-] {+2.34),+} libgcc-s1 (>=
3.0), libstdc++6 (>= [-5.2), libyaml-cpp0.6-] {+11), libyaml-cpp0.7+} (>=
[-0.6.2)-] {+0.7.0)+}
Installed-Size: [-464-] {+472+}
Version: [-1.3.1-3-] {+1.3.1-4+}
[ Other info ]
(Anything else the release team should know.)
unblock thinkfan/1.3.1-4
Bug#1003121: RM: ansible-base/2.10.5+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: deb...@rocketjump.eu deprecated; package superseded by ansible-core
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
Hi Bas, On 31/03/2021 20:20, Sebastiaan Couwenberg wrote: > On 3/31/21 7:30 PM, Lee Garrett wrote: >> Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried >> getting the unit tests from 2.9.16 to work with python 3.9, but I had to give >> up. I don't feel comfortable with maintaining such a large package over the >> lifecycle of bullseye without unit tests, official py3.9 support, and >> security >> support running out in a few months, so please remove ansible from bullseye. > > Shipping bullseye without ansible is going to make many users unhappy. > > Will you actively maintain the package in bullseye-backports instead? Up until now Pierre-Elliott Bécue has provided versions for backports, and I'm happy to regulary upload ansible to backports, too. However, ansible has a somewhat active deprecation cycle for modules/features, meaning that backports users will be forced to adapt their playbooks and roles with every feature release to avoid breakage. Adding to this, there have been times where ansible in testing/unstable was broken for a while due to moving python packages (the month long breakage due to jinja2 which broke templating in many ansible modules comes to mind). So I don't think those users who have previously depended on ansible from stable will be happy with using ansible from backports. I can only say that I screwed up the migration process due to making a few wrong assumptions about the finer details of the freeze process, and I'm somewhat embarrassed about causing the release team additional work. I had been working on packaging ansible 2.10 since December, and my intention was to get ansible 2.10 into bullseye. Had I known what I know now, I would have set my personal deadline differently, or raised the issue with the release team earlier. Those things said, I agree with Raphaël that ansible 2.10 is a good fit for bullseye, and I'd maintain it over the life cycle of our next release if the release team chooses to unblock it. Kind regards, Lee
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: deb...@rocketjump.eu Hi, Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried getting the unit tests from 2.9.16 to work with python 3.9, but I had to give up. I don't feel comfortable with maintaining such a large package over the lifecycle of bullseye without unit tests, official py3.9 support, and security support running out in a few months, so please remove ansible from bullseye. Thanks in advance, Lee
Bug#984557: unblock: ansible-base/2.10.5+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: deb...@rocketjump.eu, hlieber...@setec.io Please unblock package ansible-base [ Reason ] Due to missing upload ACLs I unfortunately missed the soft freeze by a few days. With 2.10, upstream ansible is split into two parts, "ansible-base" and "ansible". This split is also reflected in the two source/binary packages of the same name in Debian. ansible-base is a hard-dep for ansible. I've personally been using the split packages for over two months now, and I've tested upgrades and of course used the package extensively. The packages have also been in experimental for about 6 weeks, and have been tested by several volunteers. 2.10 comes with support for ansible collections, which is the new format with which 3rd party modules/plugins are be shipped. With 2.9 currently in testing users won't be able to use those (as collection support is incomplete in 2.9). The next 2.10 upload will also come with autopkgtests which I have been working on for the last month. [ Impact ] If the unblock is not granted, I will have to upload an epoch version 2:2.9.16-1 to revert the ansible package in unstable, and ansible will ship with an older version. Backporting security fixes will be more difficult, as I'd have to correlate the changes of 2.10+ with the pre-split code of 2.9 after upstream security support runs out. Ansible-base 2.10 will also have about 12 months longer upstream security support than ansible 2.9, depending on the release schedule of 2.11+. [ Tests ] Automated tests is piuparts currently, which runs through fine. Manual tests involve running my personal playbook against my server fleet. With the next 2.10 upload there will be working autopkgtests that I've been working on for the last month. [ Risks ] ansible/ansible-base are leaf packages, with only ansible-lint and ansible-mitogen depending on those. ansible-lint works fine without changes. ansible-mitogen will need an update that's already packaged in experimental. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing -> doesn't apply as currently not included in testing. [ Other info ] (Anything else the release team should know.) unblock ansible-base/2.10.5+dfsg-1
