© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
So I'm looking at this, and here are my concerns:
a) complex delta
These patches look like they will be hard to carry forward. Even though we are unlikely to see big changes in noble SRUs, and there they should be more maintainable, this is delta that will be hard to maintain post-noble.
b) we are making a big change to a package
Ed25519 was announced by upstream as part of the 1.20230630 release. Except, in Ubuntu, it's not. configure-like and other version checks might be assuming that after this version, Ed25519 support is there for granted. But not in Ubuntu. In other words, we are deviating quite harshly from upstream and removing a feature they added more than a year ago. Granted, most good such checks will look for the actual feature being present, and not just a version number, but still.
c) there is no guarantee that we will benefit from this work
For this to be complete, we still need the MIR LP: #2023971 to be complete. It's currently in the security review queue, and it might come out from there as a +1 or a -1.
We currently have these versions in noble:
libmail-dkim-perl | 1.20230212-1 | noble | source
libmail-dkim-perl | 1.20240124-1 | noble-proposed | source
The upstream change that added Ed25519 support is in 1.20230630, which mean it's *NOT* in noble release at the moment, only noble-proposed.
I propose that we kick out 1.20240124-1 from noble-proposed, and keep the one in noble-release. We can either add this package to the sync-blocklist[1], or upload a no-change rebuild with an ubuntu suffix to block it from syncing that way. I seem to remember there was a discussion on a suitable suffix for such changes, something like adding "maysync" or similar. We can find that, I think it was used recently in an MP in the server team even, for dns root data?
Yes:
dns-root-data | 2023112702~
But maybe for now, just before FF, we should add a block to it, just to be safe. Although, if we do nothing, it will just stay in proposed without migrating...
Now, if there is something in newer libmail-dkim-perl that we want, maybe the plan above doesn't work so well. Or we could cherry-pick what we want that is in newer versions only.
So, what do you think?
1. https:/