Comment 24 for bug 1975567

Honestly it's my bad, Daniel's answer fell through the cracks.

As he correctly identified, the next step would be to change the bug description to match the SRU template. Anyone can edit a bug description. Meanwhile I targeted the bug to the correct series.

Regarding the patch itself, it's customary to provide a full debdiff including the proper changelog entry. The benefits for the submitter are that they are marked as the "uploader" for the version, which is useful when applying for MOTU or Core Dev privileges.

The changelog entry must contain a reference to the bug in the form of 'LP: #1975567', and the new version number needs some care. I usually follow these guidelines for it:

https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging

The individual patch files added to debian/patches/ should follow the DEP-3 guidelines https://dep-team.pages.debian.net/deps/dep3/
A quick way to generate them is to use a full Git patch using git format-patch, and add a couple of fields. In particular here I'd like the Bug and Bug-Ubuntu fields to be added. Another way to get a Git patch from a GH repository is simply to add '.patch' at the end of a GH commit URL, for instance:

https://github.com/proftpd/proftpd/commit/8aa39b27d8fd6ada556b51c4547a504956474078.patch

When asking to sponsor a package, it's usually a good idea to include a link to a PPA where the package has been built. It shows prospective sponsors that you did due diligence, and it allows bystanders to quickly get unblocked while the SRU process move along.

I *think* that's about all the advice I have? :-)