[SRU] pymodbus 3.6.9-1 from 24.10 (to 24.04)

[Mikael Arguedas]

Pymodbus 3.6.9 has Python 3.12 support and is available in oracular. Is it possible to have a release of pymodbus in noble ?

---

[Impact]

 * There is no pymodbus available in 24.04, its useful for many projects to have it and given that 24.04 is an LTS it seems justified to backport the 24.10 version of pymodbus to 24.04.

 * Community members as well as commercial partners have asked to get pymodbus back in 24.04.

[Test Plan]

 * Make sure autopkgtests passes
 * Package needs to be tested for certain use cases on real hardware, we will be able to test it with AMD/Xilinx Kria devices

[Where problems could occur]

 * Package was present in jammy so for the users upgraded from jammy to noble
   they may still have the version of this package in Jammy, and this is a major
   version change which is highly likely for the users of this package to
   introduce breaking changes

[Other Info]

 * pymodbus is available in focal/jammy as well as in oracular/plucky

 * pymodbus jumps from 2.x to 3.x between 22.04 to 24.04 which means some API changes. But I guess that is better than having no pymodbus at all.

 * getting pymodbus back into 24.04 will probably also help to avoid distortion
   and some confusion for users who upgrade from earlier versions,
   where the package is still available (focal/jammy),
   but not getting it for 24.04 anymore,
   but again with oracular (and newer).

[Mikael Arguedas (mikael-arguedas)]

Friendly ping here, any news on this topic ?
It would be really great to have this package available in Ubuntu 24.04 like it is for the other distributions.

Cheers!

[Michael Vogt (mvo)]

I think it would be nice to have this backported, I attached the (trivial) debdiff and if someone from the backports team could ACK it, I can upload as well (but would love to have a small review/ack as I'm a bit rusty with the processes and may have made a mistake or overlooked something).

[Mattia Rizzolo (mapreri)]

I'd say ACK, this fits the scope of backports perfectly.

@mvo: note that the process from backports changed, so you are supposed to do the upload and eventually maintain it, see the page http://wiki.ubuntu.com/UbuntuBackports

[Michael Vogt (mvo)]

Thanks @Mattia - I tried to upload this but it seems I no longer have the required permissions. This is unfortunate, I used to be ubuntu-core-dev but for some reason that seems to have been removed. Well, the debdiff is here, this will now need sponsoring. Sorry for that.

[Mattia Rizzolo (mapreri)]

You probably expired, since those needs to be renewed yearly (by clicking
on the LP renewal email).

See
https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Accidental_Expiry
if you wish to reapply.

On Sun, 5 Jan 2025, 10:00 am Michael Vogt, <email address hidden>
wrote:

> Thanks @Mattia - I tried to upload this but it seems I no longer have
> the required permissions. This is unfortunate, I used to be ubuntu-core-
> dev but for some reason that seems to have been removed. Well, the
> debdiff is here, this will now need sponsoring. Sorry for that.
>
> --
> You received this bug notification because you are a member of Ubuntu
> Backporters, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/2083908
>
> Title:
> [BPO] No python3-pymodbus available on ubuntu 24.04
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/pymodbus/+bug/2083908/+subscriptions
>
>
> --
> ubuntu-backports mailing list
> <email address hidden>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
>

[Mattia Rizzolo (mapreri)]

I'm subscribing ~ubuntu-sponsors and "starting the timeout"

[Andreas Hasenack (ahasenack)]

pymodbus was removed from noble due to debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061817

Do you have evidence that this version works in noble? That it builds, and that autopkgtests pass?

I think a PPA is in order, showing the package with the debdiff applied, building, and with DEP8 tests run with it.

[Talha Can Havadar (tchavadar)]

Hello Andreas,

I see that this back port request parked for some time. I did upload the package to ppa (https://launchpad.net/~tchavadar/+archive/ubuntu/lp2083908-test) and triggered the autopkgtests see below.

Do we need something else for this back port to continue?

```
* Results:
  - pymodbus: noble/pymodbus/3.6.9-1~bpo24.04.1 [amd64]
    + ✅ pymodbus on noble for amd64 @ 04.03.25 23:25:39
      • Log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-tchavadar-lp2083908-test/noble/amd64/p/pymodbus/20250304_232539_504e8@/log.gz
    + ✅ pymodbus on noble for amd64 @ 04.03.25 23:29:12
      • Log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-tchavadar-lp2083908-test/noble/amd64/p/pymodbus/20250304_232912_e8e4d@/log.gz
  - pymodbus: noble/pymodbus/3.6.9-1~bpo24.04.1 [arm64]
    + ✅ pymodbus on noble for arm64 @ 04.03.25 23:24:03
      • Log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-tchavadar-lp2083908-test/noble/arm64/p/pymodbus/20250304_232403_ec3d6@/log.gz
  - pymodbus: noble/pymodbus/3.6.9-1~bpo24.04.1 [armhf]
    + ✅ pymodbus on noble for armhf @ 04.03.25 23:29:20
      • Log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-tchavadar-lp2083908-test/noble/armhf/p/pymodbus/20250304_232920_d1587@/log.gz
  - pymodbus: noble/pymodbus/3.6.9-1~bpo24.04.1 [i386]
    + ✅ pymodbus on noble for i386 @ 04.03.25 23:24:41
      • Log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-tchavadar-lp2083908-test/noble/i386/p/pymodbus/20250304_232441_53a35@/log.gz
  - pymodbus: noble/pymodbus/3.6.9-1~bpo24.04.1 [ppc64el]
    + ✅ pymodbus on noble for ppc64el @ 04.03.25 23:24:41
      • Log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-tchavadar-lp2083908-test/noble/ppc64el/p/pymodbus/20250304_232441_e75c5@/log.gz
    + ✅ pymodbus on noble for ppc64el @ 04.03.25 23:29:15
      • Log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-tchavadar-lp2083908-test/noble/ppc64el/p/pymodbus/20250304_232915_c0564@/log.gz
  - pymodbus: noble/pymodbus/3.6.9-1~bpo24.04.1 [s390x]
    + ✅ pymodbus on noble for s390x @ 04.03.25 23:27:32
      • Log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-tchavadar-lp2083908-test/noble/s390x/p/pymodbus/20250304_232732_66f94@/log.gz
    + ✅ pymodbus on noble for s390x @ 04.03.25 23:30:11
      • Log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-tchavadar-lp2083908-test/noble/s390x/p/pymodbus/20250304_233011_8c3bc@/log.gz

```

[Thomas Ward (teward)]

This requires someone with upload privileges to upload but also requires someone dedicated to maintain this in Backports. That includes addressing bug reports and such in Backports.

There has been no movement since Michael Vogt replied, so this needs someone with upload privileges willing to back the package and keep it updated and uploaded for inclusion in -backports

[Talha Can Havadar (tchavadar)]

Hello Thomas,

This package will be maintained by Canonical Partner Engineering Team's AMD Squad (https://launchpad.net/~canonical-partner-eng), I can update the bug description to indicate this as well if that is needed.

So for the next steps, how should we proceed?

[Frank Heimes (fheimes)]

Since it's a universe package, I can volunteer to get it uploaded.
So we have a proper debdiff, a PPA build, proper autopkgtest results and a maintenance stmt.

I suggest to run the update-maintainer script to get the Maintainer field in d/control as:
Ubuntu Developers <email address hidden>
since people, department and team names may change,
and the stmt in #10 here can always be found via the LP bug reference in d/changelog.

And the version would probably get an XubuntuY suffix, and in d/changelog a reference to this LP bug is needed.

Unless you Thomas or Andreas will tell me otherwise (esp. about the maintainer field).

[Frank Heimes (fheimes)]

I've updated the justification / BPO template in the bug description a bit.

[Andreas Hasenack (ahasenack)]

So remaining steps are:
- run update-maintainer
- if trivial, try to fix d/watch (and then fix it in plucky too):
$ uscan --download-current-version
uscan warn: In debian/watch no matching hrefs for version 3.6.9 in watch line
  https://github.com/pymodbus-dev/pymodbus/tags .*/v?(\d\S*)\.tar\.gz

I noted that its only reverse dependency, pdudaemon[1], was also removed from noble at the same time. Just in case that is also desired to have back in noble.

Now, thinking about this bug, and noticing the "hole" we have in noble:
$ rmadison -asource pymodbus
 pymodbus | 1.2.0-2 | trusty/universe | source
 pymodbus | 1.2.0+git20151013-1 | xenial/universe | source
 pymodbus | 1.3.2-1 | bionic/universe | source
 pymodbus | 2.1.0+dfsg-2 | focal/universe | source
 pymodbus | 2.1.0+dfsg-2 | jammy/universe | source
 pymodbus | 3.6.9-1 | oracular/universe | source
 pymodbus | 3.6.9-1 | plucky/universe | source

I'm wondering if ubuntu users wouldn't be best served by an actual SRU that brings this package back? That is doable, but has a bit more requirements:
- a test plan
- a maintenance commitment (which we have)
- rdeps must keep working for real (I'm only aware of pdudaemon, which was also removed from noble, but I haven't investigated too deeply beyond running "reverse-depends python3-pymodbus")
- it would have to go through NEW review by an archive admin, and issues could be found there (which would likely have to be fixed in oracular/noble/plucky as well, depending on what they are, or in the next devel release).
- the same commitment from comment #10 would have to be extended for the devel release, and stable releases

This SRU would also take longer, whereas the backport seems to be around the corner.

Thoughts?

[Talha Can Havadar (tchavadar)]

Hello Andreas,

I would also prefer SRU for this. Should we create a new bug for it or is it ok to update description of this bug accordingly.

In case of SRU request, do we also need to SRU pdudaemon? There is no specific request for it (at least didn't come any to us), for testing side of things I believe we can get support from our partner to validate package is working as expected but it will be definitely hard to be sure that we covered all use cases.

[Andreas Hasenack (ahasenack)]

Same bug is fine, just retitle, change description, change subscribers (remove bpo), etc.

No need to SRU pdudaemon.

For testing, remember an SRU that reintroduces a package is a long-term commitment. It's not just this upload here: it's from here onwards. Any future SRUs, any future devel series, etc. An autopkgtest would be much appreciated as well.

[Mattia Rizzolo (mapreri)]

(just a small note that also a backport is a commitment, and you aren't supposed to one-shot the upload... although I suppose one could see it as a smaller commitment than an SRU given the smaller impact.)

[Andreas Hasenack (ahasenack)]

Correct, I didn't mean to downplay the backport effort, just that you can do things in backports that you cannot do in SRUs.

[Talha Can Havadar (tchavadar)]

Uploaded SRU proposal version of the package ( pymodbus (3.6.9-1ubuntu0.24.04.1) ) in https://launchpad.net/~tchavadar/+archive/ubuntu/lp2083908-test2

Will trigger the autopkgtests when the package is ready, and ask partner to test the package in this ppa. Meanwhile can you please check if the package is good enough in packaging perspective? I updated the maintainer and fixed the debian/watch issue

[Talha Can Havadar (tchavadar)]

Uploaded pymodbus (3.6.9-1ubuntu1.ppa1) plucky; in https://launchpad.net/~tchavadar/+archive/ubuntu/lp2083908-test2 which has fix for watch file

[Talha Can Havadar (tchavadar)]

And Andreas, I am not able to remove backporters from subscribers of this bug (probably because I didn't add it but not sure how LP works in this case)

[Andreas Hasenack (ahasenack)]

I also cannot remove backporters

[Thomas Ward (teward)]

But I can.

Removed backporters.

[Zixing Liu (liushuyu-011)]

Do we want to proceed with this as a backport or a normal SRU?

> Will trigger the autopkgtests when the package is ready, and ask partner to test the package in this ppa. Meanwhile can you please check if the package is good enough in packaging perspective? I updated the maintainer and fixed the debian/watch issue

I think the packaging looks good. Is this ready for upload?