Re: [Tails-dev] tails binary and source packages lists URLh…

Delete this message

Reply to this message
Autor: intrigeri
Data:  
A: Reproducible Builds discussion list
CC: tails-dev
Assumptes nous: Re: [Tails-dev] [Reproducible-builds] tails binary and source packages lists URL has changed…
Assumpte: Re: [Tails-dev] tails binary and source packages lists URLhas changed…
Hi,

Holger Levsen wrote (11 May 2016 10:22:11 GMT) :
> once again these two URLs have changed:


> http://nightly.tails.boum.org/build_Tails_ISO_feature-stretch/lastSuccessful/archive/latest.iso.binpkgs
> http://nightly.tails.boum.org/build_Tails_ISO_feature-stretch/lastSuccessful/archive/latest.iso.srcpkg


The ISO build from our feature/stretch branch, that generates these
files, has been broken for a while, and after some weeks our Jenkins
set up deletes artifacts it considers to be obsolete… so these files
have indeed disappeared. Sorry for the inconvenience, and thanks for
the heads up: I didn't consciously realize that such breakage would
impact you folks :/

I'm working on it and hope to fix it today.

> We need to them to create the package lists for:


> https://tests.reproducible-builds.org/unstable/amd64/pkg_set_tails.html
> https://tests.reproducible-builds.org/unstable/amd64/pkg_set_tails_build-depends.html


Right, it's lovely that we have these, thank you! :)

And by the way, once the above is fixed, I want to quickly switch our
pkgset generation process from our (very hackish and inaccurate)
.binpkgs/.srcpkgs files, to our new (accurate) .build-manifest one.

I've prepared a branch that does this switch and adjusts
bin/reproducible_create_meta_pkg_sets.sh accordingly:

* repo: https://git-tails.immerda.ch/jenkins.debian.net.git
* branch: support-tails-build-manifest

I'll notify you once the above has been fixed and this can be merged
and deployed to production, but IMO this branch is ready for a code
review. Note that:

* I used explicit argument passing to the function this branch
introduces, instead of global variables; if you prefer, I can of
course adjust this to use global variables, to match the current
code's style more closely, regardless of whatever my personal taste
in such matters is.

* I really didn't want to parse YAML by hand, hence the inline Python
script. I've seen a Perl one in the same file already, so I've
assumed it would be OK. If you prefer I can certainly move that
function into its own, dedicated script.

Cheers,
--
intrigeri