On 2025-01-26 23:49:42 [+1000], Sam Pinkus wrote: > Presumably these commits are taking some upstream release archive and > extracting it over main branch of > https://salsa.debian.org/debian/xz-utils.git? > > git log --pretty=format:'%h%x09%an%x09%ad%x09%s' --grep "New upstream > version" > 2e006444 Sebastian Andrzej Siewior Sun Oct 6 10:46:41 2024 > +0200 New upstream version 5.6.3 … This is the import of the orig tarball into git.
> I note the upstream maintainer is now signing release archives, but we still > have to trust whatever process the maintainer used to generate the release. correct. > Wouldn't it be more transparent if maintainer's version was 1to1 with > upstream except for debian and do autogen in the dh rules if possible? This > is probably naive but simply adding this seems to work (at least doesn't > fail): I plan to switch to cmake at some point. Then we don't have to worry about autoconf magic. > override_dh_update_autotools_config: > ./autogen.sh How is this different from the current autoreconf step that is already as part of dh? Note that problem back then was that the shipped archived contained m4 files so the autogen step did not "help". > It would also make https://salsa.debian.org/debian/xz-utils.git less > confusing. I mean if extracting a release archive then committing it the > approach to syncing with upstream why does it share large tree of commit > history with upstream at all? gbp does this. > P.S. I also not 5.2.4 didn't have autogen assets in the maintainer repo, but > on the other hand they are in the source package orig.tar.xz somehow - which > is probably even less good in terms on transparency. I don't know what you want me to do here. Other than adding ./autogen.sh as part of the build process which is already handled. Sebastian
