Hi, On Mon, Mar 11, 2024 at 05:55:31PM +0100, Sebastian Andrzej Siewior wrote: > On 2024-03-11 00:05:54 [+0000], Amin Bandali wrote: > > Hi Sebastian, all, > Hi, > > > Will this fix be enough for addressing all cases, though? > > I think so. Do you have a test case for me to check?
Not about pristine-xz specifically; I meant more in the context of other devel tools like gbp et al. > > I'm thinking specifically of cases where tarball repacking > > is involved, for example when using git-buildpackage's > > "gbp import-orig --uscan" where uscan is used to download and > > repack the upstream tarball, because the package at hand has > > a Files-Excluded field in its debian/copyright header stanza. > > As far as I can tell, Devscripts::Compression would need to be > > updated to specify -T1 for xz compressions. > > > > I believe there are also some cases where git-buildpackage > > itself does repacking, so we'd probably want to update its > > gbp.pkg.compressor's Opts to pass in -T1 for xz. > > Who is handling the compression in the first place here? In the case of "gbp import-orig --uscan", gbp invokes uscan, part of the devscripts package which has several perl modules including Devscripts::Compression which is a sort of a wrapper around dpkg's Dpkg::Compression, which will ultimately run the 'xz' executable. In some other cases like "gbp import-orig --filter" mentioned by Andrey, gbp does the compression itself. Which is why I suggested that 'Opts' in gbp.pkg.compressor may need to be updated to add '-T1' for calls to 'xz'. > The idea is to pass -T1 to xz if nothing was recorded in pristine-tar's > delta information. If the -T argument then everything keeps working > as-is. If you use gbp to repack the tar archive then I would recommend > to no pass -T1 and to use multi-threaded compression. pristine-tar > will recongnise this and record this information. Sorry I don't think I fully understood this bit. Could you please explain again, perhaps a bit more verbosely? To clarify, the use-cases described earlier involving gbp and devscripts aren't necessarily related to pristine-xz, used for regenerating pristine xz files; rather, about the generation or repacking of xz files *before* they are handed to pristine-xz for processing and storage in the repo. I was trying to imply that similarly to how you sent patches for pristine-tar to adapt it for changes in xz-utils, that similar patches are probably also needed for gbp and devscripts. Does that make sense? > Sebastian > Thanks, -amin
