Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main
On Wed, May 06, 2015 at 12:53:51AM +0200, Cyril Brulebois wrote: Reproducible builds folks reproducible-builds@lists.alioth.debian.org (2015-02-13): Bug filing with patches === We have started to propose patches to make packages build reproducibly and tagged them with appropriate usertags and the user reproducible-builds@lists.alioth.debian.org [BUGS]. And the number [GRAPH] got quite high quite fast. As more than 400 have already been sent, please consider this email as an overdue announcement for the mass bug filing. This is all \o/. Might be worth getting those added on UDD's bug search page to make it easier for people to have a look at the big picture? http://udd.debian.org/bugs/ The bugs submitted by us have the usertag reproducible-builds@lists.alioth.debian.org. You can find them with UDD here: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.debian.org Regards. Reiner ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main
Reproducible builds folks reproducible-builds@lists.alioth.debian.org (2015-02-13): Bug filing with patches === We have started to propose patches to make packages build reproducibly and tagged them with appropriate usertags and the user reproducible-builds@lists.alioth.debian.org [BUGS]. And the number [GRAPH] got quite high quite fast. As more than 400 have already been sent, please consider this email as an overdue announcement for the mass bug filing. This is all \o/. Might be worth getting those added on UDD's bug search page to make it easier for people to have a look at the big picture? http://udd.debian.org/bugs/ Mraw, KiBi. PS: Please cc me, not subscribed. signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main
Daniel Kahn Gillmor writes (Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main): However, for packages that don't use a framework we can fix, or which use a tool that has no plans to adopt these kinds of modes upstream, I think that if tool upstreams reject (or stall) our requests for reproducible-compatible modes of operation, we should apply such patches ourselves. But I hope this will be very rare. Certainly we should be willing to backport patches from upstreams' development versions to testing (when testing isn't frozen). Your concerns about bit-rot are legitimate, though; if a piece of the toolchain is where a proper fix belongs, and all the dependent packages are working around it now, perhaps we could (a) make sure that the proper fix bug report is filed in the bts against the piece of the toolchain, and that it is marked as affects: with all the packages that are currently working around it. I would generally very much prefer to fix things at the root. That is less effort overall. It may mean that this specific goal is achieved less quickly, but if we spend less effort achieving this goal we can spend that effort on other goals that are also important. We ought to be able in any case to get very far within a single Debian release cycle. Basically, i think the BTS has the semantics to support keeping track of these dependent issues so that we end up with clean long-term fixes, while we can use our packager's discretion to implement the shorter-term workarounds, annoying though they may be. what do you think? Also, less involvement with annoying workarounds means less annoyance and therefore more fun and therefore more work and faster progress. This does depend of course on the interactions between different maintainers on these subjects also being fun and constructive. If they aren't then a workaround may be better. (IMO such maintainers ought to be replaced. We have too many who are hard to work with. But the only sensible way to get rid of them, or even just to get a needed patch accepted, is to ask the Technical Committee; and the TC has shown itself to be extremely reluctant to intervene.) Ian. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main
Hi, I applaud this initiative. On 13-02-15 18:28, Reproducible builds folks wrote: If you want to help, a first step is to check the reproducibility of your packages [DDLIST]. Feel free to ask for help on the reproducible-builds@lists.alioth.debian.org mailing list or in #debian-reproducible on irc.debian.org. It would help me if you would have mentioned here what you expect people to do when their package is not reproducible, but when this is the result of other packages that they use during building. I am not going to fix my packages if e.g. the timestamp in the documentation is inserted by the use of formatXtoFormatY, we should then rather focus on fixing formatXtoFormatY. I believe you agree. If people all start fixing such issues inside their own package than in some time we have all kind of solutions, which may (or may not) bit-rot and may not be needed if we fix formatXtoFormatY. I remember that I implemented something along these lines to allow multiarch libraries where there was also some documentation that wasn't worth splitting off. I would be glad if I remember that when the formatXtoFormatY in question is fixed. Paul signature.asc Description: OpenPGP digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
