Re: [Reproducible-builds] repro-test (was: Re: Projects and mentors wanted for our participation in upcoming outreach programmes)
Hi, On Donnerstag, 18. Februar 2016, Johannes Schauer wrote: > - I also totally was reading this as re-protest initially and wondered why > I would want to protest again, so I concur with Esa's observation and > conclusion > > - on a second thought, maybe this was intentional :D bingo! :-) > - it seems that the software is meant to be distribution agnostic. Would > it still fit as a Debian SoC project? I'm not saying this wouldn't be > useful for Debian but I think for Debian specifically a tool which lets > developers directly test whether a given .dsc is reproducible would be > more useful for Debian. I guess thats totally fine. Also, diffoscope was debbindiff once too, and then grew. Likewise the focus of the GSOC project could be "just" creating that tool "within the Debian universe" (eg by implementing .deb based stuff, but designing with rpms and tars and foo in mind)… > - the README linked to above seems to implement its own backends (the > --runner argument) I'd like to draw your attention to the adt-virt-* > programs which abstract several backends behind a common interface. That > way, sbuild in experimental recently gained support for lxc, qemu and ssh > backends without carrying its own code for each. Maybe using that would > avoid code duplication in this tool as well? oh wow. That made me curious and it seems piuparts supports adt-virt as well. Sadly that patch was merged without documentation… Thanks a lot for this pointer. cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] repro-test (was: Re: Projects and mentors wanted for our participation in upcoming outreach programmes)
Hi, Quoting Holger Levsen (2016-02-17 11:57:03) > And then I was thinking to add another project, "develop reprotest tool", > what > other ideas do you have? I have some more random thoughts about this: - unfortunately I failed to take part in that discussion in Athens but I assume you are talking about: https://reproducible-builds.org/events/athens2015/reprotest/ ? - I also totally was reading this as re-protest initially and wondered why I would want to protest again, so I concur with Esa's observation and conclusion - on a second thought, maybe this was intentional :D - it seems that the software is meant to be distribution agnostic. Would it still fit as a Debian SoC project? I'm not saying this wouldn't be useful for Debian but I think for Debian specifically a tool which lets developers directly test whether a given .dsc is reproducible would be more useful for Debian. - on the other hand, the linked README mentioned buildinfo files which are currently Debian specific - Can the now distribution-agnostic reproducible builds project not apply for their own slots with Google or outreachy? Since reproducibility benefits Debian as well, we would then overall have more slots :) - the README linked to above seems to implement its own backends (the --runner argument) I'd like to draw your attention to the adt-virt-* programs which abstract several backends behind a common interface. That way, sbuild in experimental recently gained support for lxc, qemu and ssh backends without carrying its own code for each. Maybe using that would avoid code duplication in this tool as well? - tool seems to check if a package can be built reproducibly (by building twice in differing environments) as well as whether an existing Debian package can be reproduced (according to the information in its buildinfo). As for the latter, prospective students might want to have a look at code from #774415. Thanks! cheers, josch signature.asc Description: signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds