[sru] sos upstream 4.7.0

Bug #2054395 reported by Arif Ali
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Pro
Status tracked in 18.04
18.04
New
Medium
Unassigned
sosreport (Ubuntu)
Status tracked in Oracular
Focal
In Progress
Medium
Arif Ali
Jammy
In Progress
Medium
Arif Ali
Mantic
In Progress
Medium
Arif Ali
Noble
Incomplete
Medium
Arif Ali
Oracular
Fix Released
Medium
Arif Ali

Bug Description

[ Impact ]

* A new sosreport version is available upstream, and following the https://wiki.ubuntu.com/SosreportUpdates policy for stable release exception we will now SRU the sosreport 4.7.0 upstream release.

* This release introduces a couple of new plugins as well as bugfixes done between the previous Ubuntu 4.5.6 sosreport version and the new 4.7.0.

[ Test Plan ]

 * The detailed test plan can be found on https://wiki.ubuntu.com/SosreportUpdates and should be tested by a couple of users.

[ Where problems could occur ]

* Some plugins might stop working, and this will show when running sosreport.

* Uploading to S3 needs the python3-boto3 dependency installed.

* If there is an issue with a plugin that is causing instability to the system, this can be disabled by running 'sosreport -n <plugin_name>'.

* Currently running sos collect with Juju 3 is -not- working, even for the current 4.5.6 Ubuntu version, we are working upstream on a fix here: https://github.com/sosreport/sos/pull/3422 this is not part of the core functionality of sos, and one can still run sos report manually on the nodes.

[ Other Info ]

* Useful plugins that are now part of 4.7.0 and could do some testing:

* runtime/lxd We have added an LXD runtime so that we can gather data directly from LXD, same with what one would do with k8s.
* plugins/canonical_livepatch_onprem.py will gather data from livepatch-server
* plugins/ceph.py add Reef release commands and gather microceph data
* plugins/coredump.py will capture coredump info from coredumpctl
* plugins/infinidat.py will gather data from servers that make use if the Infinidat storage solution
* plugins/kubernetes.py will now gather container information from microk8s
* plugins/mellanox_firmware.py will gather data from mellanox devices
* plugins/openstack_masakari.py will gather data from openstack masakari
* plugins/openstack_masakarimonitors.py will gather data from openstack masakari monitors
* plugins/vectordev.py will gather the config from vectordev (cos-proxy)

Arif Ali (arif-ali)
tags: added: sts
tags: added: se
description: updated
description: updated
Arif Ali (arif-ali)
tags: added: sts-sru-needed
Revision history for this message
Arif Ali (arif-ali) wrote :

The above debdiffs have been added, and ready for verification

We are waiting for the 4.4 main patch for bionic in #2038648 to be uploaded before we crack on with the Pro update for bionic for 4.7.0

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "noble-sosreport.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Revision history for this message
Lucas Kanashiro (lucaskanashiro) wrote :

@Arif are the attached debdiffs ready to be uploaded? I do not know if I get it right, but the bug you mentioned is not yet fixed:

https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/2038648

If this is ready for ~ubuntu-sponsors, please state so. If not, please unsubscribe ~ubuntu-sponsors and subscribe again once it is ready.

Revision history for this message
Arif Ali (arif-ali) wrote (last edit ):

@Lucas, it is ready.

We were planning to resolve that bug as part of the whole SRU of 4.7.0.

When n/m/j/f are done, we'll get the bionic one done too, and that will be 4.7.0 as well, I hope that makes sense.

Or, would you prefer us to fix the current version there first, and then do the SRU for 4.7.0?

EDIT: in-fact I already uploaded a debdiff on that LP, so that is ready for SRU for that fix too

Arif Ali (arif-ali)
Changed in sosreport (Ubuntu Focal):
importance: Undecided → Medium
Changed in sosreport (Ubuntu Jammy):
importance: Undecided → Medium
Changed in sosreport (Ubuntu Mantic):
importance: Undecided → Medium
Changed in sosreport (Ubuntu Noble):
importance: Undecided → Medium
Changed in sosreport (Ubuntu Focal):
assignee: nobody → Arif Ali (arif-ali)
Changed in sosreport (Ubuntu Jammy):
assignee: nobody → Arif Ali (arif-ali)
Changed in sosreport (Ubuntu Mantic):
assignee: nobody → Arif Ali (arif-ali)
Changed in sosreport (Ubuntu Noble):
assignee: nobody → Arif Ali (arif-ali)
Changed in sosreport (Ubuntu Focal):
status: New → In Progress
Changed in sosreport (Ubuntu Jammy):
status: New → In Progress
Changed in sosreport (Ubuntu Mantic):
status: New → In Progress
Changed in sosreport (Ubuntu Noble):
status: New → In Progress
Revision history for this message
Arif Ali (arif-ali) wrote :

new debdiff with new oracular being the version, and building on top of the 2 versions that were not there previously

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I pushed the oracular debdiff to a git repo at
https://code.launchpad.net/~ahasenack/ubuntu/+source/sosreport/+git/sosreport/+ref/oracular-patch-pilot-sosreport-update-2054395

I'm slightly concerned with the d/copyright changes. We seem to be removing attributions from others:

diff -Nru sosreport-4.5.6/debian/copyright sosreport-4.7.0/debian/copyright
--- sosreport-4.5.6/debian/copyright 2024-04-14 22:45:27.000000000 +0100
+++ sosreport-4.7.0/debian/copyright 2024-05-01 07:51:23.000000000 +0100
@@ -1,36 +1,8 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: sosreport
-Upstream-Contact: Bryn M. Reeves <email address hidden>
+Upstream-Contact: Jake Hunsaker <email address hidden>
 Source: https://github.com/sosreport/sos

-Files: *
-Copyright: 2012-2013 Bryn M. Reeves
- 2007-2013 Red Hat, Inc.
-License: GPL-2+
-
-Files: sos/report/plugins/kernelrt.py
-Copyright: 2012 Red Hat, Inc.
-License: GPL-2
-
-Files: debian/*
-Copyright: 2013 Adam Stokes <email address hidden>
-License: GPL-2+
-
-License: GPL-2
- This program is free software; you can redistribute it and/or
- modify it under the terms of the GNU General Public License
- as published by the Free Software Foundation; version 2.
- .
- This application is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
- .
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301,
- USA.
-
 License: GPL-2+
  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by

For example, the plugin sos/report/plugins/kernelrt.py is still shipped, and has the Red Hat Inc copyright text in it.

I know this change was done in the upstream git repo[1], but one of the authors is the same one pushing the change here. Previously all debian/* files were removed[2], but what was restored in [1] is not the same d/copyright.

1. https://github.com/sosreport/sos/commit/314cc502ac862494973712537bf7a7a0c34f96d8
2. https://github.com/sosreport/sos/commit/098d19684456eceb6bc2cea094b30effa19c37fc

Revision history for this message
Arif Ali (arif-ali) wrote :

Hi Andreas,

This was discussed in the PR [1], let me see if I can answer your questions

* All the files that need a copyright have the copyright at the top of the files, and hence not therefore require here. If we started to add all the copyright stuff, then this file would be considerably long
* The upstream core maintainer changed a few years ago, and Bryn is still one of the old maintainers, and he didn't have any issues with the change.
* I can change the debian/* back again, if that needs to change to have Adam the related copyright.

One of the main reasons of up-streaming the debian folder was to improve the CI testing, especially with some of the tests we had failed as part of SRU previously. The key thing was to be consistent upstream and downstream.

Happy to discuss the best course of action moving forward on this

[1] https://github.com/sosreport/sos/pull/3409#discussion_r1387216668

Revision history for this message
Andreas Hasenack (ahasenack) wrote (last edit ):

Looking at [1], it states:

  Similarly, plain text files which include their own copyright information and are installed into
  the binary package unmodified need not have that copyright information copied into
  /usr/share/doc/PACKAGE/copyright

So in principle it's ok to drop the specific entry for the kernelrt.py plugin.

The debian/* entry I don't know, I see many packages have an entry like that, while others don't. The files in debian/* themselves don't have any copyright note on them, and not all are part of the final binary installation. On the other hand, removing this stanza from d/copyright means we also lose the information on who did the original packaging.

But another change is removing GPL-2+ for "Files: *". I'm not sure it was even correct before, as the LICENSE file in the source tree is clearly just "GPL-2" (no +). So we would have to track that one down.

See how this can get complicated very quickly? Changes to d/copyright need to be meticulously verified. I would prefer they are not done here, unless such careful verification and cross-checking with the debian policy is done, and also coordination with the same package in debian.

So if you want to change d/copyright, my recommendation would be to:
- do that in a branch of its own
- coordinate with debian, so both debian and ubuntu have the same file. Might need to update the version of the package in debian first, though (which would also benefit us both)

1. https://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright

Revision history for this message
Arif Ali (arif-ali) wrote :

Sounds good to me, I'll revert the copyright change and upload new debdiffs for all. We can tackle the copyright file in a later SRU.

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

Thanks, Arif, the changes LGTM. I have a couple of questions:

- The maintainer field in d/control was reset. Was this on purpose?
- Version 4.7.1 is out since 2024-04-08; I understand this was first prepared prior that date. Still, I should ask: would you rather prepare 4.7.1 here to avoid SRUing a minor version shortly after this one lands?

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

Oh, there is one additional issue:

debdiff-apply failis with

File man/en/sosreport.1 is not a regular file -- refusing to patch
2 out of 2 hunks ignored

...

Traceback (most recent call last):
  File "/usr/bin/debdiff-apply", line 382, in <module>
    sys.exit(main(sys.argv[1:]))
             ^^^^^^^^^^^^^^^^^^
  File "/usr/bin/debdiff-apply", line 331, in main
    debdiff_apply(patch, patch_name, args)
  File "/usr/bin/debdiff-apply", line 207, in debdiff_apply
    call_patch(patch_str, "--dry-run", "-f")
  File "/usr/bin/debdiff-apply", line 139, in call_patch
    return subprocess.run(
           ^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/subprocess.py", line 571, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['patch', '-p1', '--dry-run', '-f']' returned non-zero exit status 1.

I can still apply it with `patch`, but it would be nice to check that (it seems it is trying to patch that symlink). How are you generating the debdiff?

Revision history for this message
Erich Eickmeyer (eeickmeyer) wrote :

@athos-ribeiro

A debdiff should most certainly not be trying to patch a symlink. I'd recommend trying it with `patch -p1 < {debdiff}` and build the source package to see if it works. If it complains about changes to the source that aren't reflected, then yes, there's a problem with the debdiff, but that's usually overcome by extracting the source.

Revision history for this message
Arif Ali (arif-ali) wrote :

@athos-ribeiro @eeickmeyer

I created the debdiff by comparing the 2 .dsc files, and indeed it include the file, as well it's symbolic linked file to be changed. I have re-ran the debdiff locally again this morning, and I can see the same thing. I can remove the offending section, and have been able to do a debdiff-apply; I can upload this debdiff if required.

The maintainer was originally changed by Julian on version 4.5.6-0ubuntu3 when a rebuild was done, not sure why, and this is for the case for only noble and oracular; the others are still the old maintainer. We are changing the maintainer soon, but we need to change a few things internally for that and hence were going to leave it as is.

The upstream project minor releases are created as a requirement for RedHat, and hence the primary maintainer that is RH does those releases. The core release cadence is 6 months, February and August. We plan to stick to that release process and potentially one intermediate. We have an internal testing criteria that can take some time to get our releases out, and hence the SRU was started a month after release, and you can see the release numbers in my PPA https://launchpad.net/~arif-ali/+archive/ubuntu/sosreport-dev.

Happy to amend anything that is required and get this moving forward.

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

Thanks for the reply, Arif.

Regarding the new upstream version: I understand it is not practical to go for 4.7.1 now given your explanation. Let's go with 4.7.0 then.

As for the bogus debdiffs, please, fix them and make them apply cleanly with debdiff-apply. This will at least slightly reduce the burden on the sponsors, given that in the current state, they will either need to make the changes themselves or pay attention to the patch reject file generated in the process.

Finally, for the maintainer field in d/control, please go through https://wiki.ubuntu.com/DebianMaintainerField so you understand why Julian did change that field in the past. However, dpkg also carries a change due to LP: #1951988, making dpkg-source also accept @canonical.com addresses. This is fair based on the reasoning discussed in the wikipage linked here. Hence, the change should be OK, and we should most likely update that wiki page.

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

Thanks, Arif.

Thanks for fixing the typo in the focal changelog.

For oracular, I see 2 new patches for cirrus (I see one of them is also present for noble). Why are we patching that file at all? AFAIU, it is a file parsed by the CI, and it is not even sipped in the package.

Revision history for this message
Arif Ali (arif-ali) wrote (last edit ):

The new patch that was added at the end was about the msr module loading and was also present in the CI testing we found upstream and hence added it on.

In the original patch that is in noble it was == 24.04 and now it's >=24.04 this will ensure it covers any series that is noble and above, I hope that makes sense.

The second patch depends on the change of the first patch based on the git history. In essence the work was combined upstream to fix the issue when I added oracular to the testing. These patches have been directly imported from upstream and no extra modification is done. If you prefer that I remove the CI bits, I can do so, but that would mean dissecting the patch and won't be a direct import

When and if we ship 4.7.3 or 4.8.0 later in the year, these would be already included, including the CI bits

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

I see.

So, patch debian/patches/0006-cirrus-Update-images-add-noble-to-supported-list.patch is not needed here then, right?

And the changes in patch .cirrus.yml in patch debian/patches/0007-cirrus-Start-testing-on-new-devel-ubuntu-daily.patch are also not needed, right?

If my assumptions above are correct, you can

- remove patch 0006;
- remove the changes for the .cirrus.yml file from patch 0007, this way patch 0006 will no longer be needed;
- rename patch 0007 to a more meaningful name (this is not only about testing, right?).

Revision history for this message
Arif Ali (arif-ali) wrote :

Updated debdiff as suggested

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

Thanks, Arif.

The contents are correct as per the upstream release.

For the `X-Python3-Version: >= 3.6` entry in d/control, I kept wondering if it is this needed in anything other than bionic and I wonder how the SRU team will look at that. Unless we are supporting upgrade paths that would skip a release, e.g., upgrading directly from xenial to focal, jammy, or noble, this would have no effect at all in all but a bionic debdiff. No need to remove the entry though, I am just leaving this comment as a note for the SRU review later (let the SRU team decide on this one). Still, if you want to keep it, you will need to file the SRU template paperwork in the related bug (LP: #2038648).

In oracular, the last patch added is now a variation of an upstream commit so it applies correctly to the current version. In that case, you can keep the original patch file with just that hunk that did not apply removed. The Origin DEP3 header can be set to "backport, GITHUB_COMMIT_URL".

I also have a nitpick for d/patches:
on the "Origin" DEP3 header field entries, would you mind pointing to commits instead of PRs? this would make it clearer to whoever looks at the patch that the change was already accepted upstream without the need to open the URLs to verify if that is the case.
      e.g., instead of
      Origin: upstream, https://github.com/sosreport/sos/pull/3545
      use
      Origin: upstream, https://github.com/sosreport/sos/commit/7e81246fcfd35e17a69bc3d40400cd123e8ca7bf
      etc.

The mantic's debian/changelog file is missing entries for python3-packaging and python3-yaml. I did not review jammy and focal assuming they will also have similar instances of the cases listed above. Let's get oracular in a "ready to upload" shape, then we can go back fixing the SRUs, WDYT?

Revision history for this message
Arif Ali (arif-ali) wrote :
Revision history for this message
Arif Ali (arif-ali) wrote :
Revision history for this message
Arif Ali (arif-ali) wrote :
Revision history for this message
Arif Ali (arif-ali) wrote :
Revision history for this message
Arif Ali (arif-ali) wrote :
Revision history for this message
Arif Ali (arif-ali) wrote :

Thanks for your comments, and the amendments that you have asked for. The relevant Origin + Bugs for DEP3 have all been updated on all the debdiffs. I have also updated mantic changelog, and focal to be consistent.

To answer your question on the `X-Python3-Version: >= 3.6`, this is explicitly showing that this sosreport package supports 3.6 and above, and we therefore ensure it as part of the packaging process.

This ensures that when upstream decide to move on from 3.6, i.e. 3.8 later in the year, we'll bump this as part of one of the SRUs. This is explained in comment 35 [1].

I hope that makes sense, and let me know if there is anything else. I am hoping we can now get this over the line

[1] https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/2038648/comments/35

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

Thanks for the changes, Arif.

I am reviewing the oracular changes only for now so we can get everyhing right in that one and then we can proceed to checking the SRU candidates.

- The changes still correctly match the upstream changes
- The patches introduced correctly match their upstream references in the DEP3 headers.

- The 0006* patch "Origin:" DEP3 header was set as "origin:" (no capital O). No need to fix this. I can change this one before uploading.

- Now, for the "X-Python3-Version: >= 3.6" change:

As I mentioned, I will leave this for the SRU team to decide whether this is an acceptable change for all series or not.

Do note that the bug that this solves is only present in bionic. These changes are not targeting bionic at all, i.e., LP: #2038648 is not being fixed by these changes.

This means that even if I upload this to the stable series, there is a chance that the SRU team will reject it and you will need to re-work things, find an uploader/sponsor again an go through this process once more.

However, this is definitely OK to push to oracular, no objections here.

Finally, note that the changelog entry is mentioning a bug (LP: #2038648) that is not being fixed here (since the bug only affects bionic). Hence, I will remove the ":" in the LP reference to the python3-version bug above so it will not be parsed by any launchpad automation (given there is no target to close).

If you agree with the 2 minor changes I am proposing (the capital O in the patch, and changing (LP: #2038648) to (LP #2038648), I will go ahead and upload this to oracular.

- Do you agree with the 2 minor changes + upload to oracular?
- Do you want me to go ahead and proceed with reviewing (and possibly uploading everything to) the stable branch debdiffs or would you like to review that python3 dependency bug/change?

Revision history for this message
Arif Ali (arif-ali) wrote (last edit ):

Hi Athos,

point 1: sounds good to me in terms of the minor changes, and uploading to oracular

point 2: Yes , please go ahead with reviewing the rest as well. I appreciate that the colon for the LP for the Version may need to removed.

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

Hi Arif,

sounds good. I applied the changes below and uploaded it for all series.

oracular: I removed the ':' in the changelog entry as mentioned before, fixed the capital DEP3 header I also mentioned, and uploaded.

noble: Removed the ':' as above, fixed the version in the changelog to 4.7.0-0ubuntu1~24.04.1, and uploaded.

mantic: applied the same changes as the ones in noble (adapting the version string), fixed a few cosmetic issues in d/changelog, and uploaded.

jammy: same changes as the one in noble (adapting the version string) some cosmetic issues in d/changelog, and uploaded.

focal: same changes as in noble and uploaded.

Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

Be aware that, if/when those packages land, they do not fix LP: #2038648 (but that could be closed since bionic has reached EOSS anyway).

Revision history for this message
Mauricio Faria de Oliveira (mfo) wrote :

Autopkgtests for oracular/cockpit/s390x passed with a retry,
that should unblock the oracular-proposed migration shortly.

316-1build1 sosreport/4.7.0-0ubuntu1 2024-05-22 15:19:06 UTC 0h 04m 29s mfo pass 1bc3dca3-467e-430b-b336-fe8c1f19b6d5

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package sosreport - 4.7.0-0ubuntu1

---------------
sosreport (4.7.0-0ubuntu1) oracular; urgency=medium

  * New 4.7.0 upstream release. (LP: #2054395)

  * For more details, full release note is available here:
    - https://github.com/sosreport/sos/releases/tag/4.7.0

  * d/control:
    - Add 'python3-packaging' as part of the runtime depends.
    - Add 'python3-packaging' as part of the build depends.
    - Add 'python3-yaml' as part of the build depends.
    - Add 'X-Python3-Version: >= 3.6' to ensure we use the python
      revision that is supported. (LP #2038648)
    - Add 'python3-boto3' to Suggests

  * Former patches, now fixed:
    - d/p/0002-obfuscate-netplan-ssid-password.patch
    - d/p/0003-removed-assertEquals-fix.patch

  * Remaining patches:
    - d/p/0001-debian-change-tmp-dir-location.patch

  * New patches:
    - d/p/0002-collect-refactor-_format_version.patch
    - d/p/0003-pacemaker-Use-pep440-formatted-version-on-comparison.patch
    - d/p/0004-cirrus-Run-tests-on-latest-daily-builds-for-ubuntu.patch
    - d/p/0005-processor-handle-msr-module-loading-via-predicate.patch
    - d/p/0006-fix-msr-load-issue-in-oracular.patch

 -- Arif Ali <email address hidden> Wed, 01 May 2024 07:51:23 +0100

Changed in sosreport (Ubuntu Oracular):
status: In Progress → Fix Released
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

It's my understanding all uploads were done, including stable releases, where they landed in the unapproved queue. Therefore there is nothing else to sponsor here, so I'm removing that subscription, as it's now in the hands of the SRU team for their normal queue processing.

Revision history for this message
Steve Langasek (vorlon) wrote :

+ * New patches:
+ - d/p/0002-collect-refactor-_format_version.patch
+ - d/p/0003-pacemaker-Use-pep440-formatted-version-on-comparison.patch
+ - d/p/0004-cirrus-Run-tests-on-latest-daily-builds-for-ubuntu.patch
+ - d/p/0005-processor-handle-msr-module-loading-via-predicate.patch

Why, when this is an upstream release for which Canonical is the upstream, are there local Debian patches included here?

+ * d/control:
+ - Add 'python3-packaging' as part of the runtime depends.
+ - Add 'python3-packaging' as part of the build depends.
+ - Add 'python3-yaml' as part of the build depends.

When making such packaging changes in an SRU, it should be documented in the changelog why they are necessary and justified. I can infer a reason for the python3-packaging addition from the debdiff, but shouldn't have to: the rationale should be documented so that there is no misunderstanding.

And it is not at all obvious from the debdiff why python3-yaml is added to the build-dependencies: it was already listed in setup.py before as a requirement but apparently didn't cause a build failure. So explanation is needed here.

+ - Add 'X-Python3-Version: >= 3.6' to ensure we use the python
+ revision that is supported. (LP #2038648)

Well this is pointless, since python3 is >= 3.6 in all releases after bionic and we don't do SRUs for bionic anymore.

+ - Add 'python3-boto3' to Suggests

This is also pretty pointless as nothing installs package Suggests: by default and users almost never look at this.

Changed in sosreport (Ubuntu Noble):
status: In Progress → Incomplete
Revision history for this message
Arif Ali (arif-ali) wrote :

> Why, when this is an upstream release for which Canonical is the upstream, are there local Debian patches included here?

Good point, we started the SRU process after 4.7.0 was released, but the time it took us to test the PPA and then the beginning of the patch pilot the noble released a minor version was released. We can do the new release, if that is preferred, but there were still patches that needed to be added for both noble and oracular due to the fact we only started testing dev release recently, and we discovered the issues, and the corresponding fixes. So, we'll see 2 patches for oracular and 1 for noble. If that is ok, then I can re-issue a new debdiff.

Alternatively, 4.7.2 is due to be released soon, which will have the relevant fixes included.

On the changelog items, I was following the previous maintainers, and didn't add the extra details. But, I am more than happy to change this here moving forward.

The "X-Python3-Versiom: >= 3.6" was added, as that is the version of python sos supports, and hence wanted to make that as a soft requirement. This would then change later in the year. But, if you think this is better added for the relevant series that we need to do this, like bionic, then happy to change it in that manner. We do plan to SRU for bionic, as that has caused a corner case of upgrade from xenial to bionic in the corresponding LP

Thanks for the "Suggests: python3-boto3" comment, happy to remove that, if it's pointless, was not 100% sure on. On noble, we now going to add that to Depends as this package is in main. I can add that on, and the reasoning.

Revision history for this message
Robie Basak (racb) wrote :

Further to discussion in #ubuntu-devel just now[1], we'll aim for a 4.7.3 release that will eliminate the need for the distro patches and with Steve's other comments above addressed. For now then I'll reject the current uploads from the queue.

[1]: https://irclogs.ubuntu.com/2024/06/03/%23ubuntu-devel.html#t11:37

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.