Re: Trial git-based task list
On Mon, Oct 24, 2016 at 07:54:00PM +, Ximin Luo wrote: > Hey all, I prepared a basic issue tracker here: > https://anonscm.debian.org/cgit/reproducible/tasks.git > You can clone it, install taskwarrior, then done… > work with it like > > $ git pull > $ ./task add "Some stuff" > $ ./task add priority:H "Some more important stuff" > $ git push matrix:~/Projects/reproducible$ git clone ssh://git.debian.org/git/reproducible/tasks.git Cloning into 'tasks'... Host key fingerprint is d7:0b:26:5c:7a:5d:56:40:a9:e0:5d:f4:e1:70:88:bf remote: Counting objects: 30, done. remote: Compressing objects: 100% (24/24), done. remote: Total 30 (delta 9), reused 0 (delta 0) Receiving objects: 100% (30/30), done. Resolving deltas: 100% (9/9), done. Checking connectivity... done. matrix:~/Projects/reproducible/tasks$ ./task help Submodule 'task-history-git' (https://github.com/8ware/task-history-git) registered for path 'task-history-git' Cloning into 'task-history-git'... remote: Counting objects: 52, done. remote: Total 52 (delta 0), reused 0 (delta 0), pack-reused 52 Unpacking objects: 100% (52/52), done. Checking connectivity... done. Submodule path 'task-history-git': checked out '8e90196dca5c8f5efbeee1426db689fba01197f7' ln: unrecognized option '--git-path hooks/post-merge' Try 'ln --help' for more information. matrix:~/Projects/reproducible/tasks$ ./task list ln: unrecognized option '--git-path hooks/post-merge' Try 'ln --help' for more information. matrix:~/Projects/reproducible/tasks$ ./task add "test" ln: unrecognized option '--git-path hooks/post-merge' Try 'ln --help' for more information. what now? (this is on jessie) > More docs are available in README also: where are the tasks stored and how can I view them? -- cheers, Holger 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: [PATCH] submit signed .buildinfo files to buildinfo.debian.net
On Fri, Oct 28, 2016 at 12:57:12PM +0100, Chris Lamb wrote: > For now, please just remove them. please update your patch :) > Whilst buildinfo.debian.net is in flux, lets keep the existing .buildinfo > files just as they are (ie. unsigned for the time being) makes sense, thanks! -- cheers, Holger 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: [PATCH] submit signed .buildinfo files to buildinfo.debian.net
Hi, On Fri, Oct 28, 2016 at 12:30:55PM +0100, Chris Lamb wrote: > Attached is the following: > > commit 97857695251a979b31bcf1e6c021c948f206db47 > reproducible Debian: Use our log_info method instead of manual echo > calls. nice catch, thanks! (+merged…) > commit b6194456546c300e939b0bfb7c2e0e85a3fd7501 > reproducible Debian: submit signed .buildinfo files to > buildinfo.debian.net very nice. however, there's no code to deal with removing the $BUILDINFO.asc files again… I'm also not sure whether to just remove them after sending them to b.d.n or whether we should rename them to $BUILDINFO and thus keep them. Thoughs? > You can also merge from the "sign-buildinfo-submissions-with-gpg-key" branch > of > https://github.com/lamby/jenkins.debian.net if that is more convenient. thanks. git log -p $NR_OF_COMMITS $BRANCHNAME Is indeed nice to do. feel free to just use the master branch too… (or not…) > Note that I haven't managed to directly test this, but the various "parts" of > it work. ack. -- cheers, Holger 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
Bug#842250: diffoscope: crashes on NetBSD's base.tgz
Package: diffoscope Version: 61 Severity: normal Hi, from https://jenkins.debian.net/job/reproducible_netbsd/120/console Thu 27 Oct 04:48:55 UTC 2016 - diffoscope 61 found issues, please investigate amd64/binary/sets/base.tgz E: Caught signal ‘Terminated’: terminating immediately Exception ignored in: ./usr/share/man/man3/strerror.3>> Traceback (most recent call last): File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 118, in __del__ self.cleanup() File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils.py", line 262, in cleanup super().cleanup() File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 114, in cleanup if hasattr(self, '_as_container'): File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 266, in sigterm_handler sys.exit(2) SystemExit: 2 Please fix! :-) If it would help, I guess I could fetch the artifacts from the jenkins job… (but it's a bit of work, so I havent done this yet and will only do so if needed.) btw, looking at this console log you can also see: Thu 27 Oct 05:18:56 UTC 2016 - diffoscope 61 produced no output for amd64/binary/sets/comp.tgz and was killed after running into timeout after 30m... Thu 27 Oct 05:49:11 UTC 2016 - diffoscope 61 produced no output for amd64/installation/cdrom/boot-com.iso and was killed after running into timeout after 30m... Thu 27 Oct 06:19:11 UTC 2016 - diffoscope 61 produced no output for amd64/installation/cdrom/boot.iso and was killed after running into timeout after 30m... which surprise me a bit, as comp.tgz is only 125 M in size and boot(-com).iso's are only 197 M… -- cheers, Holger 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: [PATCH] Set a maximum time for curl(1) to upload to buildinfo.debian.net
On Sun, Oct 23, 2016 at 08:51:54AM +0100, Chris Lamb wrote: > commit 2789d4f8b81d8132e8bc0549601ed2770240363d > reproducible Debian: Set a maximum time for curl(1) to upload to > buildinfo.debian.net > commit 85f9cb1a86dc0afe83097e1f3647b20ef6f97e36 > reproducible Debian: Update my email address in reference to > buildinfo.debian.net. thanks, merged, increased the timeout to 120 & deployed! -- cheers, Holger 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: [PATCH] reproducible Debian: submit .buildinfo files to buildinfo.debian.net
Hi, On Sat, Oct 22, 2016 at 02:56:55PM +0100, Chris Lamb wrote: > commit a7951081247f47e8dc4abfd87b48fc7eac7e400e thanks, merged & deployed! > reproducible Debian: submit .buildinfo files to buildinfo.debian.net very nice! next: an apt hook which complains if the to be installed hash doesnt match the one from there? ;) -- cheers, Holger 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: Repeated entries in Installed-Build-Depends .buildinfo section
On Tue, Oct 18, 2016 at 05:05:18AM +0200, Guillem Jover wrote: > Right, this seems due to a missing dependency simplification step. > I've pushed an untested patch now: cl, thanks! > will try to test tomorrow, but if some of you can do that, that'd be > much appreciated. ;) if someone would do a new dpkg upload with this patch to our reproducible-builds repo, it could easily get tested… ;-) -- cheers, Holger 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: broken DDPO by not-so-broken reproducible-tracker.json
On Wed, Oct 19, 2016 at 03:38:29PM +0100, Chris Lamb wrote: > (Just out of interest, are the same infrastucture, etc. filters used for > the opt-in "reproducible → unreproducible" emails we send out?) no. there the assumption is: the maintainers wants to be notified about changes. we just send out such mails once a day, so if a package ftbfs due to some jenkins hickup and then builds fine again, (often, not always…) no mail is sent. -- cheers, Holger 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: broken DDPO by not-so-broken reproducible-tracker.json
On Wed, Oct 19, 2016 at 09:51:24AM +0100, Chris Lamb wrote: > That, combined with my preference for simplicity, would actually make me > advocate for no filtering whatsoever (!) I'm strongly against pushing _noise_ to 25% of our package maintainers. -- cheers, Holger 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: Please review draft for week 77's blog post
Hi Ximin, On Mon, Oct 17, 2016 at 07:24:00PM +, Ximin Luo wrote: > https://reproducible.alioth.debian.org/blog/drafts/77/ nice! > There is one FIXME for holger :) I see several ;-) Regarding the OpenWrt slides I was told that they would be published today or latest tomorrow… > I will publish this in 24 hours. cool! thanks for your work on this (and all the other posts!) -- cheers, Holger 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: please try again with some packages
Hi Wolfgang, On Fri, Oct 14, 2016 at 07:03:24PM +0200, W. Martin Borgert wrote: > (I write in English, just in case you need to forward this email.) reproducible-builds@lists.alioth.debian.org would probably have had a faster response time indeed… > Some packages failed with > > dh_installxmlcatalogs: Unexpected debhelper version format > > This was a bug in xml-core, which lead many packages to FTBFS. > > It is solved since some time and all packages that have the line > above in their log should be tried again. > > Example: docbook2x. I was about to ask you for a list of packages on certain specified archs (which is usually better) but then realized that we already re-schedule all packages in state ftbfs, with no bugs usertagged reproducible-builds after 3 days automatically and that those 3 days have already past since your mail. but then, for unrelated reasons and just since a few hours and for hopefully less time than that, the automatic scheduler is currently broken, so I took the liberty to reschedule all ftbfs packages on all archs/suites instead :) (also because I noticed ftbfs bumps for sid on i386+armhf…) -- cheers, Holger 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: [PATCH] Use popcon.source_package now that it's available in jessie-backports
Hi Ximin, On Tue, Oct 11, 2016 at 01:00:00PM +, Ximin Luo wrote: > https://anonscm.debian.org/cgit/users/infinity0/jenkins.debian.net.git/commit/?id=213ad324ff76b842628a79c29262e54ebca48742 > This should fix linux from being displayed as "popcon: 6" in the issues page. thanks, merged & deployed! -- cheers, Holger 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: opi2a back! init system variations?
On Mon, Oct 10, 2016 at 06:46:50PM +, Holger Levsen wrote: > and now also been added back to the build network, with 3 new builder > jobs for a total of 60 (running on a total of 20 armhf boards). ^ 22 armhf board is correct :) (+sorry for the noise.) -- cheers, Holger 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: opi2a back! init system variations?
Hey, On Wed, Oct 05, 2016 at 08:42:17PM -0700, Vagrant Cascadian wrote: > opi2a is back! and now also been added back to the build network, with 3 new builder jobs for a total of 60 (running on a total of 20 armhf boards). Not sure how to rearrange build jobs off the top of my > For some reason, systemd wasn't starting consistantly, hanging on > systemd-logind. Oddly, it worked well enough to still run build jobs, > but restarting daemons and upgrading some packages would hang. > > With some effort, I switched to sysvinit from a debug shell, finished > some pending upgrades, of which were several systemd related. After the > upgrade, it's been working consistantly using systemd ever since... So > I don't *really* know why it's working now... but it is. Best guess is > it crashed in the middle of a upgrade (maybe disk full?) at some point > and corrupted some relevent file(s)? hehe, nice workaround! > The whole ordeal did trigger a thought about adding init system > variations to the builds... at least could do systemd and sysvinit at > the moment without a *huge* amount of trouble, unless we're relying on > some init-specific features for the builders? well, we ideally want deterministic (and easy to spot) variations, to ease debugging of unreproducible issues. For the "easy to spot" part, the armhf network is sadly not really suited. With our amd64+i386 nodes (due to their low number) it's trivial to guarantee that exactly one of the two builds will be done on a host with a variation, while the other build is not. On our armhf nodes, it's impossible (for this kind of variation). On Fri, Oct 07, 2016 at 01:59:29PM -0400, Daniel Kahn Gillmor wrote: > fwiw, i imagine that the choice of what is pid 1 (much like the choice > of what is /bin/sh) could be a significant factor in some builds. I'd > be happy to see this variation added to the list of things we'd like to > eventually test. sadly I tend to agree and have added this to our TODO list… -- cheers, Holger 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: [PATCH] Correct "all sources packages" -> "all source packages" typo.
On Mon, Oct 10, 2016 at 12:28:07PM +0100, Chris Lamb wrote: > commit c55acc53bbb8daaf8730d252ab7de9653a930ab0 > Correct "all sources packages" -> "all source packages" typo. thanks for spotting this & providing a patch! merged & deployed. > You can also merge from the "all-sources-packages" branch of > https://github.com/lamby/jenkins.debian.net if that is more convenient. it is, thanks! -- cheers, Holger 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: Moving IRC status notifications to #debian-reproducible-changes
Hi,
On Fri, Sep 30, 2016 at 10:03:21PM +, Mattia Rizzolo wrote:
> This evening we held a meeting in #debian-reproducible. One of the
> point in the agenda was the bot noise in the main team channel
> #debian-reproducible that sometimes makes regular talk hard.
>
> Therefore we decided to move _some_ of the notifications (especially,
> the reproducibility status changes that regularly occur) to a different
> channel, #debian-reproducible-changes.
which others? ("some" implies there are others…)
I'd be in favor of dropping the "diffoscope crashed and here are the
artifacts it crashed on"-notifications and instead link them on
https://tests.reproducible-builds.org/debian/index_breakages.html
These notifications occur pretty reguluariy and don't add anything new
ever. We know there are ~140 source packages diffoscope crashes on.
These don't really change.
> I'm going to ask the KGB admins to set up a project and have the bots
> join that channel sometime tomorrow evening or Sunday, and then move
> those notifications over there.
thanks!
--
cheers,
Holger
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: [rb-general] Scheduling a regular time for IRC meetings
Hi, Thanks for pushing this! I'm very happy to see regular irc meetings being tried! (I'll just repeat my comments from irc here.) On Sat, Oct 01, 2016 at 12:01:26PM +0100, Chris Lamb wrote: > Thanks to everyone who attended the trial IRC meeting yesterday — really > nice to see so many folks present. yay! > The consensus was that we want to try a regularly-scheduled meeting every > two weeks, so this mail is to determine the best time for that. I think a schedule with 2 regular dates in every month works much better than every 2 weeks, because we have those months with 5 weeks and thus it becomes confusing on which $day_of_the_week the meeting is, plus it will eventually clash with other dates which are "every tuesday in the Xth week of the month." > I will close this poll in one week from today and then send out a mail > scheduling the first one. please do it with at least a week advanced warning this time ;-) About the suggested dates: I don't like that it only contains European evening dates. (Because that's night for Asia and also because it's evening for Europeans.) - I've voted accordingly, that is, with pretty low availability. > Meetings would be held on #reproducible-builds on OFTC, will start promptly > at the specified time and will last no longer than 1 hour. Agenda/reminders > will be sent out in plenty of time before each meeting. Yay! Meetings should also use meetbot, so we get linkable logs with actionable items etc for free. (And which are pretty good to be linked from the weekly reports!) -- cheers, Holger 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: [PATCH] New reproducible website location
On Fri, Sep 09, 2016 at 11:11:19AM +, Holger Levsen wrote: > ah, it needs a jenkins job to build the website first then… and then we > need to trigger this job… I've created that jenkins job now, so that every commit pushed to the master branch of git://git.debian.org/git/reproducible/reproducible-website.git will update https://reproducible-builds.org/ Thanks for your patience, Chris & for pushing this, too! -- cheers, Holger 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
Bug#836784: diffoscope: Several "Too much input for diff" on debian packages from unstable/amd64
On Sat, Sep 24, 2016 at 02:50:12PM +, Mattia Rizzolo wrote: > It is, with commit 83593ea75709ff82bb01cd3c8970636a4f5dd31b in master, > already released with v60. thanks, cool. -- cheers, Holger 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: package uploaded to our repo
Hi, Mattia, thanks a lot for this great description what you did why! Really awesome. On Wed, Sep 21, 2016 at 01:35:27PM +, Mattia Rizzolo wrote: > well, why, considering a single-archive world, is Source+Version fields > in .buildinfo not enough to link the binaries to the source? well, if this reproducible builds effort is also ment to improve the security of Debian, it's very proper not only to record what the label says it should contain (src pkg + version) but also something so it's later possible to check whether "your src pkg + version" is the same "I" later build… ;) (IOW: to not only record the label but also a hash of the contents.) -- cheers, Holger 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: [dpkg] 08/08: document 1.18.10.0~reproducible1
On Wed, Sep 21, 2016 at 09:44:57AM +, Mattia Rizzolo wrote: > > shall we switch and use --buildinfo-id on jenkins? > yes, patch incoming. :) > That's the option guillem prefer, so I see no real reason to differ. > I only added that code to support the currently used > --buildinfo-identifier as a migration helper, to avoid a (for how short > it could be) timestpam where builds would fail. cool! & thanks too! -- cheers, Holger 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: [dpkg] 08/08: document 1.18.10.0~reproducible1
Hi, On Tue, Sep 20, 2016 at 10:36:17PM +, Mattia Rizzolo wrote: > +dpkg (1.18.10.0~reproducible1) UNRELEASED; urgency=medium > + * Continue to support --buildinfo-identifier as an override for > +--buildinfo-id, as jenkins is using it atm. shall we switch and use --buildinfo-id on jenkins? -- cheers, Holger 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: New armhf node (Jetson-TK1)
On Wed, Sep 07, 2016 at 02:03:43PM -0700, Vagrant Cascadian wrote: > New armhf board up and ready for configuration. [...] > Once it's fully configured and ready for builds, please reallocate > opi2a's jobs to jtk1a done. & sorry for the delay. jtk1a is building it's first packages now \o/ Thanks to everyone involved! -- cheers, Holger 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: [PATCH] New reproducible website location
On Mon, Sep 19, 2016 at 10:09:08AM +0100, Chris Lamb wrote: > Apologies, I had assumed it was just a case of changing a few specific > lines in the Jenkins config file to point to new locations. no. we need a job then to build the stuff etc. see my previous reply to this thread… currently we have git hook which builds the website. as we move the git repo on another host we need something new. -- cheers, Holger 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: [PATCH] New reproducible website location
On Mon, Sep 19, 2016 at 10:01:05AM +0100, Chris Lamb wrote: > Any update on the below? :) no. let's look at it together in Salzburg… -- cheers, Holger 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
Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)
On Thu, Sep 15, 2016 at 04:38:00PM +, HW42 wrote: > > 3.16.0-4-amd64 is the kernel (so jessie standard), and the host this is > > running on is a profitbricks VM, so running on kvm. > I assume you have this kernel only installed on the VM not the chroot. > So try installing linux-image-amd64 _inside_ the chroot. the problem is, that this is a sid chroot, so linux-image would have version 4.7.2, while the host has 3.16… -- cheers, Holger 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
Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)
On Thu, Sep 15, 2016 at 02:58:00PM +, HW42 wrote: > It fails to find a kernel for the VM image it creates on the fly: ah, wow. > diffoscope-qubes-debug: > > supermin: failed to find a suitable kernel (host_cpu=x86_64). > > > > I looked for kernels in /boot and modules in /lib/modules. > > > > If this is a Xen guest, and you only have Xen domU kernels > > installed, try installing a fullvirt kernel (only for > > supermin use, you shouldn't boot the Xen guest with it). > > libguestfs: trace: launch = -1 (error) > > 1473930826.096060ERROR guestfs can't be launched > > On what kind of VM is this run, and what kernels are installed? 3.16.0-4-amd64 is the kernel (so jessie standard), and the host this is running on is a profitbricks VM, so running on kvm. -- cheers, Holger 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
Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)
Hi, these qubes ISO image files are (temporarily) now also available for download at https://jenkins.debian.net/userContent/qubes/ -- cheers, Holger 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
Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)
On Thu, Sep 15, 2016 at 09:26:38AM +, Holger Levsen wrote: > just now I enabled debugging like this: > > export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 I've now also tried with LIBGUESTFS_MEMSIZE=2048 just in case it needs more memory. the result is again attached :) -- cheers, Holger root@profitbricks-build3-amd64:~# schroot --directory /tmp -c source:jenkins-reproducible-unstable-diffoscope bash (jenkins-reproducible-unstable-diffoscope)root@profitbricks-build3-amd64:/tmp# export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 (jenkins-reproducible-unstable-diffoscope)root@profitbricks-build3-amd64:/tmp# export LIBGUESTFS_MEMSIZE=2048 (jenkins-reproducible-unstable-diffoscope)root@profitbricks-build3-amd64:/tmp# diffoscope --html /tmp/q.html --text /tmp/q.txt /tmp/q1 /tmp/q2 libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: set_memsize 2048 libguestfs: trace: set_memsize = 0 libguestfs: create: flags = 0, handle = 0x29e7360, program = python3 libguestfs: trace: set_program "diffoscope" libguestfs: trace: set_program = 0 libguestfs: trace: add_drive "/tmp/tmpm1zmy0hl_diffoscope/LiveOS/rootfs.img" "readonly:true" "format:raw" libguestfs: creating COW overlay to protect original drive content libguestfs: trace: get_tmpdir libguestfs: trace: get_tmpdir = "/tmp" libguestfs: trace: disk_create "/tmp/libguestfsKpH1nW/overlay1" "qcow2" -1 "backingfile:/tmp/tmpm1zmy0hl_diffoscope/LiveOS/rootfs.img" "backingformat:raw" libguestfs: command: run: qemu-img libguestfs: command: run: \ create libguestfs: command: run: \ -f qcow2 libguestfs: command: run: \ -o backing_file=/tmp/tmpm1zmy0hl_diffoscope/LiveOS/rootfs.img,backing_fmt=raw libguestfs: command: run: \ /tmp/libguestfsKpH1nW/overlay1 Formatting '/tmp/libguestfsKpH1nW/overlay1', fmt=qcow2 size=2147483648 backing_file=/tmp/tmpm1zmy0hl_diffoscope/LiveOS/rootfs.img backing_fmt=raw encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 libguestfs: trace: disk_create = 0 libguestfs: trace: add_drive = 0 libguestfs: trace: launch libguestfs: trace: version libguestfs: trace: version = libguestfs: trace: get_backend libguestfs: trace: get_backend = "direct" libguestfs: launch: program=diffoscope libguestfs: launch: version=1.32.7 libguestfs: launch: backend registered: unix libguestfs: launch: backend registered: uml libguestfs: launch: backend registered: libvirt libguestfs: launch: backend registered: direct libguestfs: launch: backend=direct libguestfs: launch: tmpdir=/tmp/libguestfsKpH1nW libguestfs: launch: umask=0022 libguestfs: launch: euid=0 libguestfs: trace: get_backend_setting "force_tcg" libguestfs: trace: get_backend_setting = NULL (error) libguestfs: trace: get_cachedir libguestfs: trace: get_cachedir = "/var/tmp" libguestfs: [7ms] begin building supermin appliance libguestfs: [7ms] run supermin libguestfs: command: run: /usr/bin/supermin libguestfs: command: run: \ --build libguestfs: command: run: \ --verbose libguestfs: command: run: \ --if-newer libguestfs: command: run: \ --lock /var/tmp/.guestfs-0/lock libguestfs: command: run: \ --copy-kernel libguestfs: command: run: \ -f ext2 libguestfs: command: run: \ --host-cpu x86_64 libguestfs: command: run: \ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d supermin: version: 5.1.16 supermin: package handler: debian/dpkg supermin: acquiring lock on /var/tmp/.guestfs-0/lock supermin: build: /usr/lib/x86_64-linux-gnu/guestfs/supermin.d supermin: reading the supermin appliance supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz type gzip base image (tar) supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/daemon.tar.gz type gzip base image (tar) supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/excludefiles type uncompressed excludefiles supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/hostfiles type uncompressed hostfiles supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/init.tar.gz type gzip base image (tar) supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages type uncompressed packages supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-hfsplus type uncompressed packages supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-reiserfs type uncompressed packages supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-xfs type uncompressed packages supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/udev-rules.tar.gz type gzip base image (tar) supermin: mapping package names to installed packages supermin: resolving full list of package dependencies supermin: build: 171 packages
Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)
On Tue, Sep 13, 2016 at 03:35:58PM +0200, Holger Levsen wrote: > so I build an Qubes ISO, twice and ran diffoscope against it: just now I enabled debugging like this: > To see full error messages you may need to enable debugging. > Do: > export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 the result is attached. -- cheers, Holger root@profitbricks-build3-amd64:~# schroot --directory /tmp -c source:jenkins-reproducible-unstable-diffoscope bash (jenkins-reproducible-unstable-diffoscope)root@profitbricks-build3-amd64:/tmp# export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 (jenkins-reproducible-unstable-diffoscope)root@profitbricks-build3-amd64:/tmp# diffoscope --html /tmp/q.html --text /tmp/q.txt /tmp/q1 /tmp/q2 libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: create: flags = 0, handle = 0x1d8e170, program = python3 libguestfs: trace: set_program "diffoscope" libguestfs: trace: set_program = 0 libguestfs: trace: add_drive "/tmp/tmpglu0svm4_diffoscope/LiveOS/rootfs.img" "readonly:true" "format:raw" libguestfs: creating COW overlay to protect original drive content libguestfs: trace: get_tmpdir libguestfs: trace: get_tmpdir = "/tmp" libguestfs: trace: disk_create "/tmp/libguestfsKt1Kw6/overlay1" "qcow2" -1 "backingfile:/tmp/tmpglu0svm4_diffoscope/LiveOS/rootfs.img" "backingformat:raw" libguestfs: command: run: qemu-img libguestfs: command: run: \ create libguestfs: command: run: \ -f qcow2 libguestfs: command: run: \ -o backing_file=/tmp/tmpglu0svm4_diffoscope/LiveOS/rootfs.img,backing_fmt=raw libguestfs: command: run: \ /tmp/libguestfsKt1Kw6/overlay1 Formatting '/tmp/libguestfsKt1Kw6/overlay1', fmt=qcow2 size=2147483648 backing_file=/tmp/tmpglu0svm4_diffoscope/LiveOS/rootfs.img backing_fmt=raw encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 libguestfs: trace: disk_create = 0 libguestfs: trace: add_drive = 0 libguestfs: trace: launch libguestfs: trace: version libguestfs: trace: version = libguestfs: trace: get_backend libguestfs: trace: get_backend = "direct" libguestfs: launch: program=diffoscope libguestfs: launch: version=1.32.7 libguestfs: launch: backend registered: unix libguestfs: launch: backend registered: uml libguestfs: launch: backend registered: libvirt libguestfs: launch: backend registered: direct libguestfs: launch: backend=direct libguestfs: launch: tmpdir=/tmp/libguestfsKt1Kw6 libguestfs: launch: umask=0022 libguestfs: launch: euid=0 libguestfs: trace: get_backend_setting "force_tcg" libguestfs: trace: get_backend_setting = NULL (error) libguestfs: trace: get_cachedir libguestfs: trace: get_cachedir = "/var/tmp" libguestfs: [7ms] begin building supermin appliance libguestfs: [7ms] run supermin libguestfs: command: run: /usr/bin/supermin libguestfs: command: run: \ --build libguestfs: command: run: \ --verbose libguestfs: command: run: \ --if-newer libguestfs: command: run: \ --lock /var/tmp/.guestfs-0/lock libguestfs: command: run: \ --copy-kernel libguestfs: command: run: \ -f ext2 libguestfs: command: run: \ --host-cpu x86_64 libguestfs: command: run: \ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d supermin: version: 5.1.16 supermin: package handler: debian/dpkg supermin: acquiring lock on /var/tmp/.guestfs-0/lock supermin: build: /usr/lib/x86_64-linux-gnu/guestfs/supermin.d supermin: reading the supermin appliance supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz type gzip base image (tar) supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/daemon.tar.gz type gzip base image (tar) supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/excludefiles type uncompressed excludefiles supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/hostfiles type uncompressed hostfiles supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/init.tar.gz type gzip base image (tar) supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages type uncompressed packages supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-hfsplus type uncompressed packages supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-reiserfs type uncompressed packages supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-xfs type uncompressed packages supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/udev-rules.tar.gz type gzip base image (tar) supermin: mapping package names to installed packages supermin: resolving full list of package dependencies supermin: build: 171 packages, including dependencies supermin: build: 7471 files supermin: build: 3612 files, after matching excludefiles supermin: build: 3614 files, after add
Re: buildinfo of old packages
On Tue, Sep 13, 2016 at 08:14:32AM +0200, Linus Gasser wrote: > we’re doing a project where we need to build old package-versions. care to explain more? > We found the buildinfo-files on tests.reproducible-builds.org, but only for > the most recent version of the packages. Is there a way to get these > buildinfo-files for older package-versions, too? if you want to rebuild old versions, go to snapshot.debian.org :-) Having .buildinfo files from tests.reproducible-builds.org will not gain you anything, unless you want to reproduce our *QA* builds, which are nowhere to be seen in the wild… (plus we dont have old versions atm as Mattia said.) -- cheers, Holger 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
Bug#837681: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs
On Tue, Sep 13, 2016 at 02:08:00PM +, HW42 wrote: > Since guestfs works by running a modified kernel in an VM to parse the > file system, I think it fails to start the VM (nested virt disabled, > OOM, ...). > > So I think you should first try if guestfs works at all (without > diffoscope) and/or enable the debug loggin like suggested in the error > message. a.) I should definitly retry with debug logging… b.) guestfs works on jenkins.d.n which is the same hardware (kvm…) and the same software (jessie) -- cheers, Holger 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
Bug#837681: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs
On Tue, Sep 13, 2016 at 04:22:29PM +, Mattia Rizzolo wrote: > I wanted to quickly try myself, but you already deleted the files. > Could you please save them somewhere (I suppose they are too big to be > attached to the bug?) they are in /home/holger/q(1|2) on pb3, please help yourself! :-) > guestfs is not called directly, but through > ISTR the consensuos was in diffoscope printing an > error but continuing nonetheless (proposing an e.g. binary diff). > > And reading the code suggest that it should do (it's catching > RuntimeError and returning back safely), but it is doing that only in > open_archive, not in e.g. close_archive which seems to be where the > actual crash is: [...] > If you want to compare it right now you might want to uninstall > python3-guestfs so it falls back to binary comparison, but that's > probably not that much helpful.. thanks but no thanks. :) -- cheers, Holger, who still prefers old fashioned error messages over 50 lines of traceback in the users face 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
Bug#837681: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs
Package: diffoscope Version: 60 Severity: normal Hi, so I build an Qubes ISO, twice and ran diffoscope against it: holger@profitbricks-build3-amd64:~$ sudo schroot --directory /tmp -c source:jenkins-reproducible-unstable-diffoscope diffoscope -- --html /tmp/q.html --text /tmp/q.txt /tmp/q1 /tmp/q2 1473773034.873399ERROR guestfs can't be launched Traceback (most recent call last): File "/usr/lib/python3/dist-packages/diffoscope/comparators/fsimage.py", line 43, in open_archive self.g.launch() File "/usr/lib/python3/dist-packages/guestfs.py", line 5398, in launch r = libguestfsmod.launch (self._o) RuntimeError: /usr/bin/supermin exited with error status 1. To see full error messages you may need to enable debugging. Do: export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 and run the command again. For further information, read: http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs You can also run 'libguestfs-test-tool' and post the *complete* output into a bug report or message to the libguestfs mailing list. 1473773034.929533ERROR If memory is too tight for 512 MiB, try running with LIBGUESTFS_MEMSIZE=256 or lower. 1473773035.369462ERROR guestfs can't be launched Traceback (most recent call last): File "/usr/lib/python3/dist-packages/diffoscope/comparators/fsimage.py", line 43, in open_archive self.g.launch() File "/usr/lib/python3/dist-packages/guestfs.py", line 5398, in launch r = libguestfsmod.launch (self._o) RuntimeError: /usr/bin/supermin exited with error status 1. To see full error messages you may need to enable debugging. Do: export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 and run the command again. For further information, read: http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs You can also run 'libguestfs-test-tool' and post the *complete* output into a bug report or message to the libguestfs mailing list. 1473773035.373510ERROR If memory is too tight for 512 MiB, try running with LIBGUESTFS_MEMSIZE=256 or lower. Traceback (most recent call last): File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 246, in main sys.exit(run_diffoscope(parsed_args)) File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 217, in run_diffoscope parsed_args.path1, parsed_args.path2) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 124, in compare_root_paths return compare_directories(path1, path2) File "/usr/lib/python3/dist-packages/diffoscope/comparators/directory.py", line 105, in compare_directories return FilesystemDirectory(path1).compare(FilesystemDirectory(path2)) File "/usr/lib/python3/dist-packages/diffoscope/comparators/directory.py", line 158, in compare my_file, other_file, source=name) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 144, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 213, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 183, in _compare_using_details details.extend(filter(None, self.as_container.compare(other.as_container))) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 147, in compare_commented_files difference = compare_files(file1, file2, source=source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 144, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 213, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 183, in _compare_using_details details.extend(filter(None, self.as_container.compare(other.as_container))) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 147, in compare_commented_files difference = compare_files(file1, file2, source=source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 144, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 213, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 183, in _compare_using_details details.extend(filter(None, self.as_container.compare(other.as_container))) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 147, in compare_commented_files difference = compare_files(file1, file2, source=source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 133, in compare_files if file1.has_same_content_as(file2): File "/usr/lib/python3/dist-packages/diffoscope/__init__.py", line
Re: Draft of blog post for week 72 in blog.git
On Mon, Sep 12, 2016 at 04:39:17PM +0100, Chris Lamb wrote: > > you published on Monday, I dont think there is any need to apologize for > > it. I believe publishing on Monday or Tuesday is totally fine > Regular is rationally and irrationally good for both reader and writer :) if "regular" is the most important criteria, I would vote for aiming for releasing on Tuesdays then :-D rationale: weekends should be off. one day for review. -- cheers, Holger 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: Draft of blog post for week 72 in blog.git
On Mon, Sep 12, 2016 at 08:52:09AM +0100, Chris Lamb wrote: > Well, I would never publish without any review - just would prefer to > have given more! :) me too, indeed. > I regrettably ended up delaying further and have just published. Apologies > this wasn't live until now. you published on Monday, I dont think there is any need to apologize for it. I believe publishing on Monday or Tuesday is totally fine, Sunday rocks, but then there is maybe less time for reviews… :-) -- cheers, Holger 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: Draft of blog post for week 72 in blog.git
Hi Chris, On Sun, Sep 11, 2016 at 08:33:40PM +0100, Chris Lamb wrote: > Apologies for the delay but I mismanaged my time this morning so have > only just managed to push the draft for week 72s report to blog.git. > I plan to publish it: > - http://time.is/compare/2345_11_Sept_2016_in_London looks nice & thanks for giving some time to review! (I've added two bits about t.r-b.o.) -- cheers, Holger 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: [PATCH] New reproducible website location
On Fri, Sep 09, 2016 at 12:07:12PM +0100, Chris Lamb wrote: > I don't know enough about how to poke our Jenkins from Git alas. Did you not > set up many before for diffoscope, etc.? ah, it needs a jenkins job to build the website first then… and then we need to trigger this job… -- cheers, Holger 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] [PATCH] New reproducible website location
Hi Chris, sorry for the delay on this one…! On Tue, Aug 23, 2016 at 02:42:24PM +0100, Chris Lamb wrote: > We will also need to make post-update. Here is the current one: > > https://gist.github.com/lamby/0dcd68abe113ef58de0b2bfe9f4af022/raw > > Obviously, this won't work on alioth; we need to have a new Jenkins > trigger. can you come up with one? else I'd rather not break the existing update mechanism… > Please also merge from the "reproducible-website-location" branch of > https://github.com/lamby/jenkins.debian.net: > > commit 991cedd0ae1aa55102d01c3c6e7f2ade1476fd7d > Author: Chris Lamb > Date: Tue Aug 23 14:37:21 2016 +0100 > Don't expose website.git anymore on reproducible-builds.org anymore. once we have a working update hook / jenkins job, I'll gladly merge this one… > commit 63cda84b8a33652d334ca854037f1b3dec3e83a3 > Author: Chris Lamb > Date: Tue Aug 23 14:37:34 2016 +0100 > Add a redirect to the new website location. I think I don't want this one, but rather tell the very few people who have a clone to switch to the new location… -- cheers, Holger 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: New armhf node (Jetson-TK1)
On Wed, Sep 07, 2016 at 02:03:43PM -0700, Vagrant Cascadian wrote: > New armhf board up and ready for configuration. > > Thanks to Nvidia for the donation, and to Martin Michlmayr and Eric > Brower for making the arrangements! yay, very cool! thanks indeed to Nvidia, Eric & Martin! (And you, Vagrant!) (i'm just not sure if I'll get around to set it up today or tomorrow or on the weekend only…) > Once it's fully configured and ready for builds, please reallocate > opi2a's jobs to jtk1a, so I can take opi2a offline to troubleshoot some > ongoing issues. Might still be a net gain in performance, as the > cortex-a15 CPUs and native SATA *should* be faster. cool! > Nvidia also donated another Jetson-TK1 board, but I'll be using that for > linux, u-boot and debian-installer testing/troubleshooting for the near > future to try and make sure it's well supported for Debian Stretch. hehe, very nice! -- cheers, Holger 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
Bug#836784: diffoscope: Several "Too much input for diff" on debian packages from unstable/amd64
Hi Ximin, On Mon, Sep 05, 2016 at 05:32:00PM +, Ximin Luo wrote: > Hi Emanuel, try setting the --max-diff-input-lines flag to a higher value. In > the next version we'll let "0" mean "unlimited" as well as having a --no-max > value to disable all such limits. Emmanuel is experiencing this with jenkins.debian.net, so *we* need to set --max-diff-input-lines to some higher value. Which value would you suggest, the machine has lots of RAM… ;-) (58G) -- cheers, Holger 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] Minimising work needed for this build-path issue
On Mon, Sep 05, 2016 at 11:26:00PM +, HW42 wrote: > Sorry I have currently no link handy. But the process for C is not very > complex: [great example] very nice, thanks for this writeup, HW42! -- cheers, Holger 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: [notes] 01/01: Tag 9 total packages with user_hostname_manually_added_requiring_further_investigation
Hi Emanuel, On Sun, Sep 04, 2016 at 09:22:28PM +0100, Chris Lamb wrote: > Just want to jump in here to say I think you're doing sterling > work here. likewise, many thanks for joining our efforts and contributing so nicely! (just please also tell your email client to not (only) send HTML mails… ;) -- cheers, Holger 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] arm64 reproducible build network
On Fri, Sep 02, 2016 at 02:59:54PM -0700, Martin Michlmayr wrote: > LeMaker sent out an update a few weeks ago saying that there is some > PCIE problem they are still debugging before mass production can > start. thanks for the update, Martin! Still looking forward to use those boards! :-) -- cheers, Holger 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: Bug#836377: build system terminal locale not inherited by build programs
control: reassign -1 dput control: severity -1 serious # failing to build on the buildds is RC by definition thanks Hi Ben, On Fri, Sep 02, 2016 at 10:40:17PM +1000, Ben Finney wrote: > The bug also appears on the normal buildd hosts. Should we remove > from the loop? then I suppose this is an RC bug in dput :-D > It could. Should that not be changed to ‘LANG=C.UTF-8’, since there > does not seem any good reason to avoid a Unicode locale? we actually do this variation on purpose, to catch problems with non-UTF8 locales :-) -- cheers, Holger 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] Deprecating plain dpkg-buildpackage
On Sat, Aug 27, 2016 at 07:29:13AM +, Mattia Rizzolo wrote: > > It could be argued that "We are mainly interested in the > > reproducibility issue, the FTBFS bugs are just a side effect". > > Indeed. > I'm fully open to such tests, but imho they would need to be on a > different project. > Besides, atm we don't really have spare resources around… That. -- cheers, Holger 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] Please drop " " prefix from mailing list subject
On Sat, Aug 27, 2016 at 06:57:11AM +, Mattia Rizzolo wrote: > alright, I removed the prefix from the lists now. > While on it, I also added my address to the list of administrators. Thanks, Mattia! -- cheers, Holger 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] Please drop " " prefix from mailing list subject
On Fri, Aug 26, 2016 at 11:48:05AM +0100, Chris Lamb wrote: > I could get no further than *that* page; ie. I don't know the password… do you want to know it? -- cheers, Holger 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] [PATCH] Give details elems "cursor: pointer" to highlight they are clickable.
On Fri, Aug 26, 2016 at 09:56:20AM +0100, Chris Lamb wrote: > commit 3cb6d4fd7a8fdb480ed983b81c6abb8a9a1b883e > Give details elems "cursor: pointer" to highlight they are clickable. thanks, merged & deployed. -- cheers, Holger 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] [PATCH] reproducible Debian: Drop trailing underlined whitespace after package set link.
On Fri, Aug 26, 2016 at 10:01:31AM +0100, Chris Lamb wrote: > commit ae8c4d471c6fe6629c8c5cf17b60307caeda8516 > reproducible Debian: Drop trailing underlined whitespace after package > set link. thanks, merged! -- cheers, Holger 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] [PATCH] New reproducible website location
On Fri, Aug 26, 2016 at 11:24:11AM +0100, Chris Lamb wrote: > Apologies for the top-posting, but ping on the below: pong… I haven't forgotten about this, just had no time to get around to do it. Will get there :) -- cheers, Holger 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] automated diffoscope for parallel build bugs
On Fri, Aug 19, 2016 at 01:10:53PM +0100, Chris Lamb wrote: > Only from me asking: > | So, just to be 100% clear, simply varying DEB_BUILD_OPTIONS="parallel=X" > | would not have discovered this gedit bug? > Where — in context — varying meant 17 vs. 18 instead of 1 vs. 18. it wasn't clear to me that the resulting gedit package would be reproducible. in fact, gedit with non parallel build currently still aint reproducible on i386+armhf, maybe thats why. > (Besides, we've seen enough strange packages to think that anything is > possible…) right. "so rare that's it's hardly worth testing and adding complexity…" -- cheers, Holger 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] automated diffoscope for parallel build bugs
On Fri, Aug 19, 2016 at 12:32:13PM +0100, Chris Lamb wrote: > > yes, I cannot imagine there's something which is reproducible if build > > in parallel but not if not. > This entire email chain was prompted by such a case. what makes you think so? this wasn't and isn't clear for me, neither from the mails nor from https://bugzilla.gnome.org/show_bug.cgi?id=770100 -- cheers, Holger 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] automated diffoscope for parallel build bugs
Hi, On Fri, Aug 19, 2016 at 12:58:24AM +0100, Chris Lamb wrote: > > I understand that building with parallel disabled takes much longer > > for many packages so I don't know if this is just a lack of resources > It's more that we have two builds and I think (?) we would prefer to do > different values of N > 1. So a different kind of resource problem. this and there are more issues: - quite a lot of packages force parallel builds in some way or another in their build systems, so these wouldnt be tested in this regard - this aint a real world scenario for our use case, which is testing and working on reproducible builds. IOW: this is just another area of QA work, which I agree should probably be done, but it's out of scope for our project and doing it would draw "human ressources". - actual tests would run a *a lot* slower, thus we would see the results were are interested in, at a later time, even more disconnected from the actual upload - the overall results would become older > It wouldn't be too much work to run such an test yourself or to use > our infrastructure. it's actually rather easy to build all packages in a loop… seriously, I mean: cd $path_to_svn for i in $(find * -type d) ; do cd $i && debuild && cd .. done now you will have a lot of debs :) copy them away, apply whatever means to enable or disable parallelism and run that loop again. now do another loop, diff each pair of debs and if they are the same, delete them. investigate the rest using diffoscope :) > The problem is all about how you use the results; in the case where a > package differed between builds you would not know whether this was > due to the parallelism that was introduced or whether the package > is inherently non-deterministic. yup, but https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_gnome.html suggests most of the core gnome packages are actually reproducible today… > > Building everything in pkg-gnome svn individually with and without > > parallel and then running diffoscope by hand to compare every binary > > package is not much fun. > > Right, so make all the pkg-gnome packages build reproducibly without > paralellism enabled (which you should do anyway) and then simply > build with parallel enabled. yes, I cannot imagine there's something which is reproducible if build in parallel but not if not. So indeed, making packages build reproducible when build in parallel will fix your original issue as well! :) -- cheers, Holger 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
[Reproducible-builds] enable build path variation when testing unstable & experimental?
Hi, so, the question is simple: shall we enable build path variation for unstable and experimental for all tested archs now? and disable it again for testing/i386 (and the other testing archs), so that we can show how a ~90% reproducible stretch could be achieved, while we would see in unstable how far away we are with varying build pathes… (75-80% reproducible packages I would guesstimate…) Or shall we wait til testing/i386 has been built once fully with build path variation so we *know* the number I currently guesstimate as 75-80%?? Or shall we forget about build path variation? I think regarding Debian releases, I'd recommend that we aim for partially reproducible packages given known build paths and for buster we'll see :) -- cheers, Holger 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 patches for libisoburn and libisofs
On Mon, Aug 15, 2016 at 02:43:49PM +0200, Thomas Schmitt wrote: > Control via environment is unpopular on my side because it would be > a novelty in the user interface of xorriso. are you sure? I mean, usually stuff like locales and language settings are already taken from the environment… SOURCE_DATE_EPOCH is quite special, and the general expectation is that it's used if it's set. (And it will never be set if it's not ment to be used.) -- cheers, Holger 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
[Reproducible-builds] Bug#834315: reference for likely causes of this bug
Hi, for future reference: please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735377#44 and followups to learn how this happened and how to prevent it. -- cheers, Holger 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
[Reproducible-builds] Bug#834315: diffoscope: 57+58 both ftbfs
Package: diffoscope Version: 58 Severity: serious Hi, as discussed on irc. diffoscope ftbfs because test files are missing in the uploaded source package. see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735377#44 for why this might have happened. -- cheers, Holger 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] [PATCH] Ensure that we can always get back to "home" of a package
On Thu, Aug 11, 2016 at 08:50:15PM +0100, Chris Lamb wrote: > commit 84c553778481026734785eddfe3011cc0f5201e4 > reproducible Debian: Ensure that we can always get back to "home" of > this package > I forget what it's called in "Don't Make Me Think" but I keep trying to > click this to get back to the "homepage" for this suite/arch/pkg combo. > commit 8925a069f7c3ff7b563088df5839f2753a35b22a > reproducible Debian: Prefer .format over concatentation. merged & deployed yesterday, thanks Chris! -- cheers, Holger 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
[Reproducible-builds] Bug#833603: Bug#833603: src:strip-nondeterminism: Please provide a process to remove unused handlers over time
On Sun, Aug 07, 2016 at 12:06:14AM +0200, Chris Lamb wrote:
> Whilst I really like hacking on strip-nondeterminsm I feel it might
> hold back the Reproducible Builds effort in general by hiding the full
> impact of issues.
I don't think so, as I see it, Debian is one of the very few (the only?)
project not normalizing large parts of the environment, so we often
see+fix more reproducibile issues than projects will hit.
(eg locale, timezone, username, shell, etc are normalized in most other
distros and in the bsd world.)
(and surely that doesnt invalid three things: a.) that strip-nondetermism
hides/fixes problems and b.) that other projects should use it c.) that
we should try to fix everything on the core and thus make strip-nondetermism
obsolete and until then, it should explain what it has hidden.)
> Its certainly not a Debian-specific tool per se but I feel like it could
> be fairly labelled as such in an informal context ("Debian run this tool",
> etc.) which isn't excellent marketing for widespread adoption.
we just haven't figured how to run it elsewhere, but this is certainly
my goal. (and has been.)
> It also mean that any distribution that (for whatever reason) cannot use
> it will be exposed to a whole bunch of issues that we are not working on
> because they are "fixed" by strip-nondeterminism.
at least coreboot manages quite well without it ;-)
--
cheers,
Holger
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] [PATCH] reproducible debian: Explicitly log that build was successful
On Mon, Aug 08, 2016 at 04:55:22PM +0200, Chris Lamb wrote: > commit bc484123204e37d678b2455331d87db5a2ed59cc > reproducible debian: Explicitly log that build was successful thanks, merged + deployed everyhwere! -- cheers, Holger 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] [Popcon-developers] Bug#833695: popularity-contest: http://popcon.debian.org/all-popcon-results.txt.gz containso
reopen 833695 severity 833695 important clone 833695 -1 reassign -1 python-popcon severity -1 normal retitle -1 python-popcon must not crash on invalid data thanks On Mon, Aug 08, 2016 at 11:34:43AM +0200, Chris Lamb wrote: > > Please reassign to python-popcon. > > Well, there are perhaps two bugs here, so simply reassigning won't be > sufficient: > > Firstly, all-popcon-results.txt.gz contains invalid data. I agree that > the client should not be removed from testing but I could not find a > suitable pseudo-package for the popcon "web" service. > > (The code that generates this file appears to be in the popularity-contest > source package, hence why I filed it here) Bill, following this I have reopened the bug and downgraded the severity. > Where should this issue be raised? I don't care about the severity, more > that it gets fixed. How can I help? :) I also disagree with merely tracking an issue which breaks Debian infrastrcuture on a mailinglist instead of a proper bug tracker. Bill, if you really insist #833695 should not be assigned at popularity-contest then please reassign it to qa.debian.org pseudo-package. > Secondly, src:python-popcon assumes valid data. Perhaps. But it would > still have to raise an error if it could not parse the file so there's > not much it could reasonably do. It *could* print a nicer exception so > its easier to track down the problem, but that's purely aesthetic.. agreed, but that still would be nice, thus the cloned bug. -- cheers, Holger 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] Bug#833697: diffoscope: libarchive.exception.ArchiveError when running on two dmg files
On Mon, Aug 08, 2016 at 12:23:08PM +0200, Chris Lamb wrote: > This is, alas, done inconsistently. Some do it in ``recognizes` (returning > False) and some do it in ``compare_details`` but returning ``[]`` this is annoying and should be fixed. > However, most appear to not catch useful errors. :) I will look into > this and come up with something cleaner. wonderful! -- cheers, Holger 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] Bug#833340: mini-buildd: please make the build reproducible
user Reproducible-builds@lists.alioth.debian.org usertag 833340 + Environment Hi, On Wed, Aug 03, 2016 at 05:20:47PM +0800, Boyuan Yang wrote: > Source: mini-buildd > Version: 1.0.16 > Severity: wishlist > Tags: patch thanks for filing this bug with patch! If you plan to file further such bugs in future, please also usertag them when filing those, as this will make sure they turn up on our radar automatically, also they will be included in our weekly blog posts. https://wiki.debian.org/ReproducibleBuilds/Contribute#How_to_report_bugs explain how to use usertags for reproducible builds. and really: thanks for filing this bug at all! :) -- cheers, Holger 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] [PATCH] Improve log note error messages
On Mon, Aug 01, 2016 at 05:14:09PM +0200, Chris Lamb wrote: > > Attached is the following: > Updated patch attached - I accidentally a verb. Thanks mattia! merged and deployed, thanks! -- cheers, Holger 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
[Reproducible-builds] Bug#832962: Bug#832962: reprotest fails to build properly on jessie
On Sat, Jul 30, 2016 at 02:15:58AM -0400, Holger Levsen wrote: > reprotest 0.2 fails to build properly on jessie, that is, it builds but > the .deb only contains the changelog.gz and copyright. changing the line X-Python3-Version: >= 3.5 in debian/control into X-Python3-Version: >= 3.4 makes it build a non-empty package, but when trying to use it I get this: $ reprotest Traceback (most recent call last): File "/usr/bin/reprotest", line 5, in from pkg_resources import load_entry_point File "/usr/lib/python3/dist-packages/pkg_resources.py", line 2876, in working_set = WorkingSet._build_master() File "/usr/lib/python3/dist-packages/pkg_resources.py", line 449, in _build_master ws.require(__requires__) File "/usr/lib/python3/dist-packages/pkg_resources.py", line 745, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3/dist-packages/pkg_resources.py", line 639, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: python-magic python3-magic is installed. -- cheers, Holger 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] Remaining reprotest variations
On Wed, Jul 27, 2016 at 04:58:28PM -0400, Ceridwen wrote: > > Using "setarch uname26" on non-x86 architectures may cause issues > > with recent versions of glibc, too: > All the variations can be disabled at the command line or with a config > file, so anyone using reprotest can disable `kernel` to work around > this kind of bug. It would be much nicer if reprotest would workaround this by itself, especially as it doesn't look like #806911 will be fixed at all… IOW: please disable 'kernel' on 32bit non-x86 archs by default. -- cheers, Holger 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
[Reproducible-builds] Bug#832962: reprotest fails to build properly on jessie
Package: reprotest Version: 0.2 Severity: normal Hi, reprotest 0.2 fails to build properly on jessie, that is, it builds but the .deb only contains the changelog.gz and copyright. On sid it builds fine. I suppose some build depends must be adjusted, eg some versioned depends increased and some versions from jessie-backports might be required… -- cheers, Holger 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
[Reproducible-builds] Bug#832961: reprotest: please add support for building simultaneously
Package: reprotest Severity: wishlist Hi Ceridwen, while reading the very interesting thread about variations for reprotest (=congrats, nice work!), it occurred to me that it would be nice if reprotest could do both tests simultaneously, either - on two different hosts -b1node foo -b1port 4222 -b2node baz -b2port 22 or maybe even also on one host with --simultaneously and a --delay 60 to start the second build 60s after the first. And probably default to 60. Given enough RAM and CPU building twice in parallel should be faster than sequentially…! :) Thanks a lot for your work on reprotest, it seems to be pretty impressive already in this short time! :-) I admit I haven't run it yet, but now I have tried and have an excuse: I build 0.2 under jessie and the package is empty except for changelog and copyright… W: reprotest: latest-debian-changelog-entry-without-new-date W: reprotest: empty-binary-package latest-debian-changelog-entry-without-new-date seems like you have used "dch" from the devscript package to edit the changelog :-) Will file another bug about empty-binary-package (under jessie, it builds fine in sid) too. -- cheers, Holger 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] Bug#787980: status: normalize file permissions when creating control.tar ?
Hi Guillem, (sorry for the late reply…) On Thu, Jul 07, 2016 at 12:20:44AM +0200, Guillem Jover wrote: > > could you please comment briefly on > > your take on this bug and it's status? > > I've had my qualms about the need for this patch, but in any > case the provided patch has not been correct now for a while as > I pointed out on IRC some time ago. Which is why Mattia reworked > it temporarily so that the dpkg in the reproducible repo works and > does not mess with the data.tar files. > > As I also mentioned on IRC, I'm planning on coming up with something > for this for the next upload. And left it out as it's certainly not > in the critical path to reproducible binaries, as the control member > has a more controlled environment. thanks for this information and your work on this. (I agree with your assessment its not that critical…) > > It's in the BTS since 13 months without a maintainer comment. > So it's certainly true that the bug report has had no comment for > that long, and I should have probably updated it for the benefit > of others, but I was actually quite surprised by this mail from you > given that I've been keeping at least Mattia and others on the IRC > channel informed of the progress and bugs status, which I had the > impression were getting relayed to the reproducible IRC channel, > and which he confirms he has been doing all along… so claiming no > maintainer comment seems a bit unfair TBH. right. what I ment indeed where "maintainer comments in the BTS" as comments on IRC (or mailinglists or RL) get lost/forgotten/cannot be found… which is precisely what had happened here: I was really lost at the status of this bug, the patch was in our repo since a long time yet I had no idea whether you considered it ready, useless or in need of some work. (I'm not on the #debian-dpkg IRC channel and while I do read dpkg's bugs I wouldn't say that I follow it's development closely.) so long story short: I ment comments in the BTS & I'm sorry to have given the impression I think you don't care about dpkg's bugs. That's definitly the opposite of what I think! :) -- cheers, Holger 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] [PATCH] reproducible Debian: misc cosmetic improvements to logging
On Thu, Jul 14, 2016 at 09:08:29AM +, Holger Levsen wrote: > On Thu, Jul 14, 2016 at 09:15:52AM +0200, Chris Lamb wrote: > > Please merge from the "misc-logging-improvements" branch of > > https://github.com/lamby/jenkins.debian.net: > thanks, merging and deploying… and reverted as it caused build failures with /tmp/jenkins-script-hfnc6BVm: line 503: log_msg: command not found -- cheers, Holger 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] [PATCH] reproducible Debian: misc cosmetic improvements to logging
On Thu, Jul 14, 2016 at 09:15:52AM +0200, Chris Lamb wrote: > Please merge from the "misc-logging-improvements" branch of > https://github.com/lamby/jenkins.debian.net: thanks, merging and deploying… -- cheers, Holger 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] [PATCH] Abstract log functions
On Wed, Jul 13, 2016 at 09:35:12AM +0200, Chris Lamb wrote: > commit 6997ba002f9bf867d542b58cb00456976e997080 > Author: Chris Lamb > Date: Wed Jul 13 09:34:45 2016 +0200 > > Abstract log functions great, thanks, merged & deployed. -- cheers, Holger 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] [PATCH] Abstract log functions
On Wed, Jul 13, 2016 at 09:35:12AM +0200, Chris Lamb wrote: > Please merge from the "log-functions" branch of > https://github.com/lamby/jenkins.debian.net: > > commit 6997ba002f9bf867d542b58cb00456976e997080 seems you forgot to push? -- cheers, Holger 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] [PATCH] Correct references to RBUILDLOG
Hi Chris, On Wed, Jul 13, 2016 at 08:50:22AM +0200, Chris Lamb wrote: > Please merge from the "buildlog-rbuildlog" branch of > https://github.com/lamby/jenkins.debian.net. However, not sure > this is correct (is $BUILDLOG supplied by Jenkins? Google suggests > BUILD_LOG is "it's" variable, so assuming these are typos?) wow, thanks, typos indeed! merged + deployed! -- cheers, Holger 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] [PATCH] Rename prospects -> potential
Hi Chris, On Fri, Jul 01, 2016 at 10:55:46PM +0200, Chris Lamb wrote: > commit 047ce047a33ae136d4c3f947f0871bbe9ceee129 > potential -> prospects much better indeed, thanks! (merged+deployed) -- cheers, Holger 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
[Reproducible-builds] status: normalize file permissions when creating control.tar ?
Hi, Guillem, (kudos and thanks for the recent dpkg upload(s)! Glad to see progress with reproducible bits!) could you please comment briefly on your take on this bug and it's status? It's in the BTS since 13 months without a maintainer comment. Thanks! ;-) -- cheers, Holger 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] [tex-k] SORCE_DATE_EPOCH_TEX_PRIMITIVES
On Tue, Jun 14, 2016 at 02:52:39PM +0900, Norbert Preining wrote: > > no hurry. (but please do upload "soon", just not with hurry :) > Uploaded and accepted. > Please report any strangeties you might see. yay, thanks & will do! our plan is also now to build the archive with that texlive-bin version and *not* to update our version in our repo, so we can see how this will behave archive wide… -- cheers, Holger 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] [tex-k] SORCE_DATE_EPOCH_TEX_PRIMITIVES
On Mon, Jun 13, 2016 at 10:05:34PM +0900, Norbert Preining wrote: > Debian git is already updated, I'll upload sooner or later Are we in > hurry? no hurry. (but please do upload "soon", just not with hurry :) -- cheers, Holger 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] [tex-k] SORCE_DATE_EPOCH_TEX_PRIMITIVES
On Sun, Jun 12, 2016 at 06:19:58PM +, Karl Berry wrote: >SOURCE_DATE_EPOCH_TEX_PRIMITIVES -> FORCE_SOURCE_DATE > I changed the sources in the pdftex and tex live repositories for this. > (Thanks Norbert.) -k yay!! thanks! -- cheers, Holger (for reproducible-builds.org) 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] ff2b and opi2c back online
On Sat, Jun 11, 2016 at 09:15:22PM -0700, Vagrant Cascadian wrote: > > This shall give us some more time+ease while deciding if/when to remove > > all ff2b and opi2c related jobs… > Both should be back online now! So no need to rearrange the jobs > anymore. Whew. wheeehoo indeed! Thanks for caring for the hardware! -- cheers, Holger 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] Question about build environments used for i386
Hi Gert, On Thu, May 26, 2016 at 01:16:03PM +0200, Gert Wollny wrote: > Sure, I've attached three screen shots of the side frame: [...] > Proposal to reorder for simple top-down navigation [...] > The "I want ice cream" version: [...] > hope that gives you an idea of what I meant. thanks, it does and it's roughly the same I thought already :) Val is working on improving tests.r-b.o this summer and she has improving the navigation on her todo-list, so I suppose your suggestions will be useful eventuelly…! :) -- cheers, Holger 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] [PATCH] Have index_issues also show total popcon scores of each issue
On Sat, Jun 11, 2016 at 01:11:28PM +0200, Ximin Luo wrote: > >> Oh I forgot to mention, you'll need to install python3-popcon on the > >> machine running jenkins for it to work. > Uploaded: https://packages.debian.org/jessie-backports/python-popcon cool, pushed and deployed your patch too and triggered the notes job. Thanks! -- cheers, Holger 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] [PATCH] Reassign jobs for ff2b-armhf-rb to other nodes
On Fri, Jun 10, 2016 at 09:18:40AM -0700, Vagrant Cascadian wrote: > > thanks for the patch, before I apply something similar I have a > > question: does that mean ff2b is gone *forever*? > > Not 100% sure just yet; it still turns on, but doesn't boot. The > recovery process doesn't work, and *sometimes* I can get it into MaskRom > mode, but not always... > > http://wiki.t-firefly.com/index.php/Firefly-RK3288/Boot_mode/en > http://wiki.t-firefly.com/index.php/Firefly-RK3288/MaskRom/en > > So, it's not quite bricked... but close. given the recent issues with opi2c I just implemented code, to check whether both build nodes are up, before starting a build. That way we can keep jobs enabled, without wasting builds where the 2nd build will fail anyway… See 96bc627..43f0571 in the git master branch of jenkins.d.n.git if you interested. This shall give us some more time+ease while deciding if/when to remove all ff2b and opi2c related jobs… -- cheers, Holger 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] [PATCH] Reassign jobs for ff2b-armhf-rb to other nodes
On Thu, Jun 09, 2016 at 01:31:39PM -0700, Vagrant Cascadian wrote: > Reassign jobs for ff2b-armhf-rb to other nodes, as it is down for the > forseeable future. thanks for the patch, before I apply something similar I have a question: does that mean ff2b is gone *forever*? if so, README and THANKS also need to get updated and the maintence jobs removed… -- cheers, Holger 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] u-boot locale variations with it_*.UTF-8
On Thu, Jun 09, 2016 at 04:33:00AM +0200, HW42 wrote: > We found out the reason is [0] because: > GNU ld (GNU Binutils for Debian) 2.26 > GNU ld (GNU Binutils for Debian) 2.26 > ld di GNU (GNU Binutils for Debian) 2.26 wow. > While debugging this I noticed that this Makefile resets LC_ALL [1]. So this > variation was only detected because we also set LANG. So I think we > should set all LC_* variables. I agree & patches much welcome! :-) -- cheers, Holger 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] ftbfs_build-indep_not_build_on_armhf, and add bochs to it
Hi Santiago, thanks for bringing this up…! On Fri, Jun 03, 2016 at 09:13:29PM +, Santiago Vila wrote: > > +- ftbfs_build-indep_not_build_on_armhf [...] > Sometimes, packages generating "Arch: all" binary packages have good > reasons to require that those packages are built only under certain > architectures. sure. (though I'm not convinced failing to debuild is a good outcome, though not failing and building different things on different archs is also not a good outcome…) > In the case of "bochs", there are some hints about the reasons in > Bug #481147 (which I closed recently because, well, it seemed "as > fixed as it can be" to me). > > A similar case also happens with the "aboot" package, which generates an > "Arch: all" package which apparently may only be generated under the > alpha architecture (see Bug #805988). > > > An "issue" suggests to me "something which has eventually to be fixed", > but frankly, I don't think we should really require that those > packages generate their "Arch: all" binary packages from any other > architecture. I think I shall improve the issue description to make it very clear that this is just a meta-issue used to track that we currently get expected FTBFS failures. > So, instead of "this package needs to be fixed", those packages would > maybe deserve a "this package should not be built on such architecture > because it is simply not supposed to work". the point of the issue was precicely to remove the "ftbfs in reproducible builds tests" from tracker.d.o, so the maintainers arent told there is something wrong. > Do you think it would be possible to achieve the same result with a > "banned packages" list which is architecture-specific instead of this > funny issue? yes, we could probably create another category of not-for-us or such, but that will need quite some code changes, while adding this new issue was very easy to do. > (Or maybe your plan was to make the autobuilder to be aware of packages > having this issue precisely to avoid the build?) yeah, maybe they shouldnt be marked "ftbfs" on our pages neither. but then its the correct result for how we build… btw, yes, we could also rename this issue to ftbfs_build-indep_not_build_some_archs or add new issues ftbfs_build-indep_not_build_on_amd64 and ftbfs_build-indep_not_build_on_i386, I'm undecided what's best. -- cheers, Holger 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] diskspace probs on opi3c (was Re: New armhf build nodes (Odroid-U3, Cubietruck, OrangePI Plus2)
On Thu, Jun 02, 2016 at 03:18:19PM -0700, Vagrant Cascadian wrote: > Sorry about that; forgot to set up a separate /srv partition. > Should be fixed now! cool, thanks! +deployed now, https://tests.reproducible-builds.org/index_armhf_scheduled.html should (in general) show 57 builders now… -- cheers, Holger 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
[Reproducible-builds] diskspace probs on opi3c (was Re: New armhf build nodes (Odroid-U3, Cubietruck, OrangePI Plus2)
Hi, opi2c already has too little diskspace, from https://jenkins.debian.net/view/reproducible/view/Debian_setup_armhf/job/reproducible_setup_schroot_experimental_armhf_opi2c/1/console tee: /tmp/schroot-create-8VxOVXtl: No space left on device -- cheers, Holger 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] New armhf build nodes (Odroid-U3, Cubietruck, OrangePI Plus2)
Hi, the nodes are set up now, exist in jenkins and have maintenance and setup jobs configured. Next is to runs those setup jobs and then add build jobs… -- cheers, Holger 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] New armhf build nodes (Odroid-U3, Cubietruck, OrangePI Plus2)
On Thu, Jun 02, 2016 at 10:59:58AM -0700, Vagrant Cascadian wrote: > Apparently had crashed and rebooted to the on-board OS. Hrmpf. Thought I > disabled that, but I'll need to disable it harder, apparently... > > Should be up now! thanks, I could login now and will now continue the setup of those three new nodes. -- cheers, Holger 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] New armhf build nodes (Odroid-U3, Cubietruck, OrangePI Plus2)
Hi Vagrant, On Sun, May 29, 2016 at 09:13:20AM -0700, Vagrant Cascadian wrote: > odu3a-armhf-rb.debian.net: > cb3a-armhf-rb.debian.net: those I can reach nicely… > opi2c-armhf-rb.debian.net: > ssh port: 2245 but not this one: debug1: Connecting to opi2c-armhf-rb.debian.net [71.214.90.150] port 2245. debug1: connect to address 71.214.90.150 port 2245: No route to host ssh: connect to host opi2c-armhf-rb.debian.net port 2245: No route to host -- cheers, Holger 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] dropping texlive from our archive
Hi Mattia, thanks for "picking up texlive-bin"…! On Tue, May 31, 2016 at 09:52:43PM +, Mattia Rizzolo wrote: > 1+2 were already tried, with very poor results, with both upstream and > debian maintainer not interested at all at even listening to us. I think this summary is too harsh. > I think that before going to make a choice on it (even if that choice is > "prod upstream some more") we should try to move aside the patched > texlive-bin package from our archive and see how many packages are > actually affected by this. I think that's reasonable indeed. -- cheers, Holger 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] [buildd-tools-devel] Bug#825991: sbuild: /etc/sbuild/sbuild.conf leaks the user home path
user Reproducible-builds@lists.alioth.debian.org usertag 825991 toolchain environment thanks -- cheers, Holger 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] arm64 reproducible build network
Hi Martin, On Wed, May 25, 2016 at 11:51:45AM -0700, Martin Michlmayr wrote: > Right. We (HPE) placed an order for some boards and they will be > shipped to ETH Zurich. It's 4 Cello boards for reproducible builds > and some more boards for other use cases (maybe ci.debian.net). looking much forward to those :) > The LeMaker Cello web site still says "shipping in Q2". I'll let you > know when that changes. thanks! > Note that these are bare boards. We'll also need (at least) RAM and > SSDs. I'll check if HPE can provide that. If not, maybe you can > request funds from Debian. thanks for checking with HPE! I'll happily approach the DPL if that wont work out… -- cheers, Holger 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] locale woes
On Sat, May 28, 2016 at 08:01:13AM -0700, Scarlett Clark wrote: > I need the locale settings for both builders please. https://tests.reproducible-builds.org/index_variations.html -- cheers, Holger 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] kde package sets incomplete/insufficient?
Hi, On Sat, May 28, 2016 at 05:54:20AM -0700, Scarlett Clark wrote: > I am not sure why kapptemplate is not there, I thought that was shipped > with applications. > > Choqok is under collab-maint ( whatever that even means, I do not know ) > And kdevelop falls under kde-extras > > I am afraid I do not know the Debian structure of all the KDE packages. > Everything outside of regular release ( what KDE referred to as extragear) > seems to be all over the place. > I think kde-extras would be best to put all of these into. I am more than > happy to hunt down the names or update some list or whatever you would like > for me to do :) the kde pkg set is currently defined in line 290 of bin/reproducible_create_meta_pkg_sets.sh in git.debian.org/git/qa/jenkins.debian.net.git and the definition is just "everything that kde-full depends on". Which doesnt even include all depends of kde-standard, I'm fixing this now. And then we should probably also add these packages: https://qa.debian.org/developer.php?email=debian-qt-kde%40lists.debian.org https://qa.debian.org/developer.php?email=pkg-kde-extras%40lists.alioth.debian.org IMHO having one KDE pkg set (well, plus KDE build depends…) is enough. What do you think? -- cheers, Holger 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
[Reproducible-builds] kde package sets incomplete/insufficient?
Hi Scarlett, after reading http://scarlettgatelyclark.com/2016/debian-outreachy-debian-reproducible-builds-week-1-progress-report/ I checked https://tests.reproducible-builds.org/unstable/amd64/pkg_set_kde.html and https://tests.reproducible-builds.org/unstable/amd64/pkg_set_kde_build-depends.html and in neither I found kapptemplate, choqok nor kdevplatform, so I'm wondering, are these package sets incomplete or could we use another package set, kde-universe, or whatever we call? -- cheers, Holger 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] Question about build environments used for i386
Hi Gert, thanks for reaching out to us! (And thanks Mattia for explaining the reproducibility issues!) On Thu, May 26, 2016 at 10:42:51AM +0200, Gert Wollny wrote: > > For i386 there are both logs for build builds done on i386. > Okay, now I've found them, the interface is a bit irritating though, > because when opening the reproducible builds page amd64 is the default, > and it eluded me that when clicking on one of the i386 builds the > details in the pane above change. It would probably be better to have > the archs first listed and the according (changing) details below. I don't really understand your suggestion (and I'm blind to flaws in the UI as I spent to much time using+designing it…), could you maybe describe this again, in other words, "ascii screenshots" or using gimp'ed screenshots? -- cheers, Holger 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] Question about build environments used for i386
On Thu, May 26, 2016 at 10:42:51AM +0200, Gert Wollny wrote: > Hi, > > Am Donnerstag, den 26.05.2016, 08:27 + schrieb Mattia Rizzolo: > > On Thu, May 26, 2016 at 08:08:07AM +0200, Gert Wollny wrote: > > > > > > looking at the non-reproducibility of dcmtk [1], I found that for > > > some reason on i386 in one build cmake obtains "x86_64" as system > > > processor versus "i686" the in other build. > > That's because for i386 one build is done with a i386 kernel, and the > > other with a amd64 kernel, but both with a i386 userland. > I see. > > > > CMake supposedly uses "uname -p" to obtain this information and now > > > I'm wondering about the build environment of the first build? > > `uname -p` sounds like an ugly choice, also considering this: > > mattia@chase ~ % uname -p > > unknown > Yeah, I've seen the same in my setup, so I will report a bug for cmake > upstream. > > > > Unfortunately, the provided logs are only for amd64. > > Not sure what are you referring to here. > > For i386 there are both logs for build builds done on i386. > Okay, now I've found them, the interface is a bit irritating though, > because when opening the reproducible builds page amd64 is the default, > and it eluded me that when clicking on one of the i386 builds the > details in the pane above change. It would probably be better to have > the archs first listed and the according (changing) details below. > > Thanks, > Gert > > > ___ > Reproducible-builds mailing list > Reproducible-builds@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds -- cheers, Holger 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
