On 24/05/17 09:58 -0500, Jorge Gallegos wrote: > On Wed, May 24, 2017 at 04:19:05PM +0200, Jan Pokorný wrote: >> today, I've accidentally attested there are no stability guarantees >> with the on-demand archives from common git hosting sites when preparing >> a new pacemaker update, redownloading "spectool -s 0 pacemaker.spec" >> of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the > > Are you pointing to a _tag_ (or as github likes to call them: release) ? > As far as I know tags can be re-created, isn't that what is happening > here? Nope, the point is that nothing has changed in the codebase or, for that matter, tags. It must have been GitHub that changed how its equivalent of "git archive" behaves. >> hashes, which (surprisingly to me) didn't match (they were at any similar >> test in the past). Then I looked at the adiff output: >> >>> diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac >>> --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 >>> +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 >>> @@ -1159,7 +1159,7 @@ >>> AC_PATH_PROGS(GIT, git false) >>> AC_MSG_CHECKING(build version) >>> >>> -BUILD_VERSION=0459f40 >>> +BUILD_VERSION=0459f40958 >>> if test != ":%h$"; then >>> AC_MSG_RESULT(archive hash: ) >> >> for configure.ac that indeed has export-subst git attribute set >> and the change itself arises from "$Format:%h$" substitution. >> This likely means GitHub was internally updated to use equivalent >> of git 2.11 feature of abbreviation length autoscaling within >> last 14 days. > > This is the other bit that makes me think it was actually the > maintainers hand that moved this, I don't believe github does anything > special to the code once it's stored there. There is no way for github > to alter code afaik? Once more, see "git help archive", ATTRIBUTES section, export-subst in particular. That exactly stands for the varying part, which is implementation-specific, and GH implementation has apparently changed, leading to changed contents of numerous archives to be downloaded from that very point. Is/will the pagure.io be immune to this sort of retroactive changes once/if such tarball extraction is implemented (see https://pagure.io/pagure/issue/861)? > This would suggest to me the maintainer: > > a) Modified the code (either via script or otherwise) > b) Deleted the tag (and thus, the github "release") > c) Submitted a new tag (and created a new gh release) > > Of course if the .spec is pointing to an archive url pointing to a git > SHA my theory is busted. > >> >> Hope this will be useful for some (e.g. fedora-review tool >> has a check to redownload and diff sources against SRPM content, >> IIRC). -- Poki
Attachment:
pgpqBMkD2j_dW.pgp
Description: PGP signature
_______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
