how was rust-src-1:1.84.1-1 built?

Description:

sha1sum rust-src-1:1.84.1-1-x86_64.pkg.tar.zst
64094c1b1fea3f904e5a653506f02e1673e09044  rust-src-1:1.84.1-1-x86_64.pkg.tar.zst

but

zstdcat rust-src-1:1.84.1-1-x86_64.pkg.tar.zst | zstd -c -T0 --ultra -20 - | sha1sum
4aa18e6c72b1889641a0f8abed9476cbc1a60a63  -

there has not been a recent release of zstd so i am a bit confused on how this happened. according to the .BUILDINFO i have the exact same version of zstd installed locally.

also sidenote: rust-src should probably be a -any package.

added priority3-normal severity4-low statusunconfirmed labels

assigned to @freswa, @toolybird, and @gromit

changed the description

All the rust pkgs from the same pkgbase are affected. It seems to have started with 07c29d3b, which makes sense when you see that COMPRESSZST+=(--long) was added inside the PKGBUILD...

sidenote: rust-src should probably be a -any package

Not possible (I think?)... due to limitation of the repo dbscripts with split pkgs...

added scopequestion statusconfirmed labels and removed statusunconfirmed label

assigned to @demize and @heftig and unassigned @freswa, @toolybird, and @gromit

closed

added resolutioncompleted label

Thanks for the response, yeah that seems to be it. wish that was not the case as a tool i am building relies on being able to easily reproduce bit identical compressed packages to get the signature to match.

edit: just checked, difference is 647 bytes. may i request that change to be undone?

may i request that change to be undone?

Sure. But there's nothing inherently wrong with the change AFAICT. You might have to adjust your code...

while i agree that the change is probably not inherently wrong, adjusting my code would be a huge additional complexity, as the information is not contained in the package at all. basically means i would need to clone each packages git repo and parse pkgbuilds.

(i am bringing delta upgrades back)

I think messing with compression settings from within the PKGBUILD is not usual to do, at the same time the usecase you have is not something that we support Arch just aims for reproducibility of archives themses and not the archive contents .

If you're implementing delta packages I think you should give up on attempting to reproduce our signatures. Rather, have a delta package format that checks uncompressed hashes for input and output and has its own signature.

Recompression is an extremely expensive step of delta application that you should avoid if at all possible. It was a very ugly wart on the xdelta3-based system.

i have been using it for a year now and this is the 2nd time an issue occurred so reproducing your signatures is quite successful, though i agree that the compression is wasted.

i put quite a bit of effort to avoid being a trusted party, in fact it does not even require root permissions. using the official arch signatures instead of rolling my own signing infrastructure is part of that.

tbh my hope is to convince the arch developers to publish signatures for the uncompressed packages in addition to the compressed ones, once the project is shown to be useful.

this is getting slightly off topic though. i will release the project in the next week, if you like i can link it here at that point.

reopened

removed resolutioncompleted label

The only supported way of reproducing our packages is makerepropkg.

closed

added resolutioncompleted label