I'm interesting in updating Ubuntu's packages to fix some security issues in pcre2 affecting stable Ubuntu releases. I know 3.0 (quilt) is not mandatory in Debian, but I think it is considered best practice for most packages where Debian is not also the upstream. It makes it quite a bit cleaner for another packager like me to easily see what changes Debian is making to the upstream source. So please consider switching. Thanks, Jeremy Bicha
severity 862425 wishlist quit Hi, I'm using dgit to package pcre, so the easiest thing is probably for you to dgit clone the package. Regards, Matthew
Could you at least push your git repo publicly and point to it with the Vcs- fields in debian/control ? Thanks, Jeremy Bicha
The source package is pcre2 - if you do "dgit clone pcre2" then that will work. Regards, Matthew
control: retitle -1 pcre2: Please switch to 3.0 (quilt) or use dgit-maint-merge(7) Hello Matthew, I just had a look at the dgit history of pcre2, and it looks like you're using a pure git merge-based workflow. I'd like to encourage you to explicitly follow the workflow described in dgit-maint-merge(7), which is essentially a cleaned-up version of what you're already doing. In particular, that manpage provides sample text for debian/source/patch-header which would have given Jeremy a way in, and perhaps avoided the filing of this bug.
Hi, That's correct. Thanks for the pointer - I don't think that document existed when I started on pcre2 in dgit. Right. I will endeavour to migrate to this approach (and update the patch-header) when I make the next pcre2 upload (which I expect to be after the stretch release at this point, mod. any security updates in the mean time). Regards, Matthew
Hi, it's been several months. I still strongly urge you to switch to the popular 3.0 (quilt) source format. Maybe the dgit-maint-gbp workflow would work for this. I don't know. I touch a very large number of Debian/Ubuntu packages and git-buildpackage is far more popular than dgit in my experience. Frankly, this bug has given me an excuse to not bother working on trying to backport security patches to older Ubuntu releases, so in my opinion, I would probably classify this bug as Severity: important. Thanks, Jeremy Bicha
Hi, Thanks for the reminder. I've created README.source which explains the packaging workflow I'm using, and will be uploading a version with this change shortly. Regards, Matthew
We believe that the bug you reported is fixed in the latest version of pcre2, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 862425@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Matthew Vernon <matthew@debian.org> (supplier of updated pcre2 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Thu, 30 Nov 2017 14:17:39 +0000 Source: pcre2 Binary: libpcre2-8-0 libpcre2-16-0 libpcre2-32-0 libpcre2-posix0 libpcre2-dev libpcre2-dbg pcre2-utils Architecture: i386 source Version: 10.22-4 Distribution: unstable Urgency: low Maintainer: Matthew Vernon <matthew@debian.org> Changed-By: Matthew Vernon <matthew@debian.org> Closes: 862425 Description: libpcre2-16-0 - New Perl Compatible Regular Expression Library - 16 bit runtime f libpcre2-32-0 - New Perl Compatible Regular Expression Library - 32 bit runtime f libpcre2-8-0 - New Perl Compatible Regular Expression Library- 8 bit runtime fil libpcre2-dbg - New Perl Compatible Regular Expression Library - debug symbols libpcre2-dev - New Perl Compatible Regular Expression Library - development file libpcre2-posix0 - New Perl Compatible Regular Expression Library - posix-compatible pcre2-utils - New Perl Compatible Regular Expression Library - utilities Changes: pcre2 (10.22-4) unstable; urgency=low . * Add README.source explaining packaging workflow (Closes: #862425) Checksums-Sha1: ccc616f4c510d24cd8952f0aad84b3e0a0b94ed3 2131 pcre2_10.22-4.dsc 4a3677d2f003c36f080164f8d9fe86a75995246b 5242 pcre2_10.22-4.diff.gz 27f059cd6df2e06af5ffdb6934029b5e2cf26dd9 5638 pcre2_10.22-4_source.buildinfo be50453e5d2bc8682fa19451dbfcaf22735f6055 173924 libpcre2-16-0_10.22-4_i386.deb 590b35d4499d4e22a104d41fdeb2bb2c046989cd 163704 libpcre2-32-0_10.22-4_i386.deb 4192cfe290603818567a3f1543052a46d8b396b1 184092 libpcre2-8-0_10.22-4_i386.deb 4f11ed24796681e1d910350965c2ad8779f98883 1099000 libpcre2-dbg_10.22-4_i386.deb 0702d6c9385610f6ccd2048b5df36f0ecd4394ba 608196 libpcre2-dev_10.22-4_i386.deb 53d6388e2e82b4d262a307ec8b3bf3eb980389ee 22268 libpcre2-posix0_10.22-4_i386.deb a3f0cb8a4ee4a704e42c0939dd87bf3a22c1cbdd 109700 pcre2-utils_10.22-4_i386.deb a7bad140a07e304bdf955e649112f9b7c67a3f82 5731 pcre2_10.22-4_i386.buildinfo Checksums-Sha256: afddebe639f14c83bce49f2b05f8773817e7ec848453d080cd9c89edf984d78b 2131 pcre2_10.22-4.dsc 0009a9b94379e9e1fe24e0d60ea7bdcc4ec40ca42833b433a60627ab270f4de1 5242 pcre2_10.22-4.diff.gz cf40530c48c791e68facee67f380b3d9116ea328f57293559386bacf6fbc6458 5638 pcre2_10.22-4_source.buildinfo 1bcaea460ecab1cdc7c8ce427f9546c4575505f635b6399aec774b788634929e 173924 libpcre2-16-0_10.22-4_i386.deb 801852c60bed37f03274e6ba13cc1db28e3bd2cf70db1a7f6053b28f62369d75 163704 libpcre2-32-0_10.22-4_i386.deb 25c5a3d89b495eb0f6f059b5049329eb3e178323a7950e3818d0331b9df0b2dd 184092 libpcre2-8-0_10.22-4_i386.deb 4e6e1e4d79ac831df31b8c6e99b3bb8e5201d7eb8776feb252826dfae1c3a1e7 1099000 libpcre2-dbg_10.22-4_i386.deb 4ee8abc96f456b27c5f563c17032ebe6726ec19cef24b79cadf8be7ade75009a 608196 libpcre2-dev_10.22-4_i386.deb 6ae6404ea9828c411f1ed8cc77ee754bf0c25da10790f0f8c271359a3bde8e5b 22268 libpcre2-posix0_10.22-4_i386.deb 2cc2757bb35d8bcdc5e461650d31528ed33be7f75e0b9ab89430fb43e5d8066c 109700 pcre2-utils_10.22-4_i386.deb 0a68d59914e6274d35e3babe953ff602a2c25904aece226af1930d4f58346009 5731 pcre2_10.22-4_i386.buildinfo Files: 5e5034d0beef971a58cd27420b066064 2131 libs optional pcre2_10.22-4.dsc afc9fafeb6503f2b550fc3353af6f37a 5242 libs optional pcre2_10.22-4.diff.gz 95521c90b8960cbe2a55d497a53f9e30 5638 libs optional pcre2_10.22-4_source.buildinfo a7e6e8ed6278d43b702bd71f913c19d8 173924 libs optional libpcre2-16-0_10.22-4_i386.deb 2d54d05147e1b937299767d203f18959 163704 libs optional libpcre2-32-0_10.22-4_i386.deb 608aced3a6f0ad2dfcf9920d93dd6419 184092 libs optional libpcre2-8-0_10.22-4_i386.deb 17afb1b4b0c96a362db2267b728ceb28 1099000 debug extra libpcre2-dbg_10.22-4_i386.deb a62c05cd358ba294a10913d614eccdf6 608196 libdevel optional libpcre2-dev_10.22-4_i386.deb 40eb8a2492c360ef22f457a34b75cec6 22268 libs optional libpcre2-posix0_10.22-4_i386.deb 7ddbc95871f636158f8df920423169bd 109700 utils optional pcre2-utils_10.22-4_i386.deb 62e668b97a30c743867610167d22bff4 5731 libs optional pcre2_10.22-4_i386.buildinfo -----BEGIN PGP SIGNATURE----- iQJHBAEBCgAxFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAlogGNgTHG1hdHRoZXdA ZGViaWFuLm9yZwAKCRAS9NIcj2pjyAQbD/4lvyaUVfuDf5jcmuTFglsm/IxYwKxp keV5GCeR+PF8SOl4HvIFmW0sfwVuSMhDudHSPw2xHmFK8sG3BbYMMz44Kta09+ZN Mpq6k3DGnKB7bTulwFsCkLZseIaWsA/2I0/0ibuHVFHOS+E0+WbGjvUW7V/f9rc8 Z0qrKOtIUaouCvQoSkedWEn4XKZYRv76rwhZlXoKuxBdom4XLkTvL3DQxwbVPQbs v7Rgm3TvR8I6qkE1bIOuiYT/QIn938uGUzox3dR4pk0YownfiiVISBEothotgrrm 1wVnxSTBi3bwVQAlO+mxIDAbKPN970d6+UTqRGbMVxQScfgT1L+e9aZRl06UKKyQ j9dQDf+iYV1jBAryM1rj303zKpDgiVR/U5AhQ7IbVeKovVrtDBB4wZnsRLNtfY4H 2XCy4bYfwn5pf+5aqwrewIAgy8F3QlhWnSPS3wG0K1wE8b8LgWGHTTBc/ASLiHz1 1pjvs1/xYj+xDMF9WqIQEWrncQSIRhNHk84WW209NH2r5OA+tw5gU8pRIExUmaM+ jX36QKA5uD9PXGxM44KMYOF5Hy+LMcu0lkG3IeEKI/qZbATw6hStYn79FmM4UD6S b+GjGbhlGpVYQGPV6Qczl32RqfA3W8VFsXeCxapWoipr2J10GxLyL0eM8/HkFuYI vKwp94icPoiaoA== =gIEX -----END PGP SIGNATURE-----
Hello Jeremy, Yes, dgit-maint-gbp(7) works fine with 3.0 (quilt).
I filed https://bugs.debian.org/862425 which has now been closed. I kinda feel like my bug was hijacked by a dgit supporter. pcre2 is the first package I've noticed where dgit is used and to put it bluntly, it hasn't left a good impression. I'm sure I'm coming across as upset but I waited almost 6 months and the only improvement we got is a minimal README. Please switch to a standard 3.0 (quilt) workflow. I assume that dgit-maint-gbp will work fine. That way you can keep using dgit since apparently you like it. And the packaging is actually maintained in a way that will allow for Ubuntu developers to easily backport security fixes. Otherwise, I feel like Ubuntu is more or less forced to "fork" the packaging in Ubuntu to switch to 3.0 (quilt) to have a normal, modern workflow. Secondly, please add Vcs fields to your debian/control . That way someone doesn't have to find and read a README first. The Vcs fields have nice integration on pages like https://tracker.debian.org/pkg/mdadm Thanks, Jeremy Bicha
Dear Jeremy, I think that your assessment of how I responded to #862425 is unfair. It was quite reasonable for you to request that Matthew change the source format. But it was also quite acceptable for him to deny that request. That's the decision-making structure in Debian: the package maintainer gets to decide things like that. When I was made aware of the bug, I chimed in with a suggestion to document the decision that Matthew had taken in a standardised way. I don't see how this could be hijacking. Matthew had already decided to use his workflow long before either of us got involved. Seems like this should be a separate bug.
Hi, Let me deal with this first. I've just uploaded a new package which has Vcs-Git and Vcs-Browser headers. I'm sorry you don't like dgit, and I am happy to try and make your life easier, but fundamentally I think it's a good workflow. I'm adjusting my workflow to more closely match that outlined in dgit-maint-merge(7), which should help. To expand on that a little - I like using git for my packaging, and dgit makes that quite a natural process. From that point of view, a convenient and powerful git workflow is more important to me than what exactly the Debian source package looks like. Quilt is a pain when working with git - it's like a separate bit of awkward versioning in the middle of your vcs tree. Given both of these things, it doesn't make sense for me to prioritise quilt over a neater git workflow. dgit is quite new, so I don't think describing it as not a modern workflow is very fair. Regards, Matthew
The problem is that there is important metadata stored as git commits (information about why this line in this source file was changed) that is completely missing from the source package. That makes it very difficult for a downstream like Ubuntu to be able to process security updates and pcre2 is a security-sensitive package. of Debian packages use 3.0 (quilt) except if they are a Debian native package. [2] I don't think I have a big issue with dgit except that it encourages you to use non-standard packaging. Have you tried using gbp pq (git-buildpackage's patch-queue) feature? [3] It works pretty well for converting ordinary git commits into a 3.0 (quilt) format. git-buildpackage is far more popular in Debian than dgit so it would encourage other contributors to submit fixes to you. (dgit is 4 years old which means it's not particularly new any more, it's just not been interesting enough to Debian Developers.) Because Debian Policy does not currently absolutely require using 3.0 (quilt), you as the package maintainer have the right to use a "native" source format. I also have the right to complain when your decision causes more work downstream. [1] https://lintian.debian.org/tags/missing-debian-source-format.html [2] https://lintian.debian.org/tags/direct-changes-in-diff-but-no-patch-system.html [3] https://manpages.debian.org/unstable/gbp-pq For completeness, here's one more minor bug in your package: https://lintian.debian.org/tags/no-homepage-field.html Thanks, Jeremy Bicha
I appreciate that it uses Vcs headers now. But my original bug report is still unsolved. pcre2 not using 3.0 (quilt) creates extra burden for doing security updates in Ubuntu. That burden has been enough for me to not invest the time in doing those security updates (especially since I have no real responsibility to do so for a package neither I nor most Ubuntu users use yet). Could you investigate switching to the dgit-maint-gbp workflow? Thanks, Jeremy Bicha
Hi, I've uploaded an updated pcre2 package (2 actually), which now points vcs-* to salsa. I think this fixes this bug, so would like to close it, if that's OK? My expectation is that anyone who wants to inspect the packaging of pcre2 would do so using git/dgit For instance, you pointed out that I needed a Homepage section in debian/control, so if you clone the published repo or browse it at https://salsa.debian.org/debian/pcre2 you can see when that line was changed (today) and why (the commit message credits you): https://salsa.debian.org/debian/pcre2/commit/f7e2cb2fdc3d57156f9390675814bd8d5c6ab504 Regards, Matthew
How so? Is there some difficulty with "git cherry-pick" or similar that I'm missing? I have considered it, and I don't think it's appropriate for pcre2. I think the primarily git-based workflow dgit-maint-merge provides is the most natural way to manage the package in Debian. Regards, Matthew
It is a problem for anyone who expects for Debian packaging to be complete in the files provided in the Debian archives ( http://ftp.debian.org/debian/pool/main/p/pcre2/ ) If I have 5 patches to apply to a particular version, the debdiff and the .diff.gz provided make it very difficult for a Stable Release Team member (or anyone) to understand those changes since they are not logically split out. The release teams use debdiffs, not git repos, to review and approve packaging updates. gbp with 3.0 (quillt) is far more popular. The packaging workflow you are using here is rare in Debian. I don't use dgit, but I think the gbp workflow might actually be just about as smooth for you when packaging new versions as the maint-merge workflow. If so, it would allow your packaging to be more useful to the rest of the Debian community. After several months, I think we're repeating the same arguments and not really making any progress. So if you're unwilling to change, I suppose it's fine for this bug to be closed or wontfixed. Thanks, Jeremy Bicha
Hello, The next release of dgit will contain a tool called git-debrebase and a workflow dgit-maint-rebase(7) which /might/ satisfy both of you. So perhaps hold off closing the bug until Matthew has an opportunity to evaluate that tool.
I am sorry to necrobump this "wontfix" bug but I just want to drop the note that pcre2 is now the last package in the standard installation that has the 1.0 format. Maybe that is worth a reconsideration.