What happened in the reproducible builds effort between January 17th and January 23rd:

Toolchain fixes James McCoy uploaded subversion/1.9.3-2 which removes -Wdate-time from CPPFLAGS passed to swig enabling several packages to build again. The switch made in binutils/2.25-6 to use deterministic archives by default had the unfortunate effect of breaking a seldom used feature of make. Manoj Srivastava asked on debian-devel the best way to communicate the changes to Debian users. Lunar quickly came up with a patch that displays a warning when Make encounters deterministic archives. Manoj made it available in make/4.1-2 together with a NEWS file advertising the change. Following Guillem Jover's comment on the latest patch to make mtimes of packaged files deterministic, Daniel Kahn Gillmor updated and extended the patch adding the --clamp-mtime option to GNU Tar. Mattia Rizzolo updated texlive-bin in the reproducible experimental repository.

Packages fixed The following packages became reproducible after getting fixed:

• apt-cacher-ng/0.8.9-1 by Eduard Bloch.
• beep/1.3-4 by Rhonda D'Vine, obsolete patch by Chris Lamb.
• clblas/2.10-1~exp1 by Ghislain Antony Vaillant.
• cortado/0.6.0-3 uploaded by Markus Koschany, original patch by Dhole.
• magic/8.0.210-2 uploaded by Roland Stigge, original patch by Chris Lamb.
• mailagent/1:3.1-81-4 by Manoj Srivastava.
• maven-shade-plugin/2.4.3-1 by Emmanuel Bourg.
• nekohtml/1.9.22-1 by Emmanuel Bourg.
• pd-iemguts/0.2-1 by IOhannes m zm lnig.
• pd-mediasettings/0.1.1-1 by IOhannes m zm lnig.
• polymake/3.0-1 uploaded by David Bremner, fixed upstream, original patch by Chris Lamb.
• wyrd/1.4.6-4 by Rhonda D'Vine.

Some uploads fixed some reproducibility issues, but not all of them:

• desktop-profiles/1.4.21 uploaded by Petter Reinholdtsen, original patch by Chris Lamb.
• gradle/2.10-1 by Kai-Chung Yan.

Patches submitted which have not made their way to the archive yet:

• #811285 on strace by Reiner Herrmann: sort symbol list using the C locale.
• #812428 on libgcrypt20 by Lunar: add support for SOURCE_DATE_EPOCH.

reproducible.debian.net Transition from reproducible.debian.net to the more general tests.reproducible-builds.org has started. More visual changes are coming. (h01ger) A plan on how to run tests for F-Droid has been worked out. (hc, mvdan, h01ger) A first step has been made by adding a Jenkins job to setup an F-Droid build environment. (h01ger)

diffoscope development diffoscope 46 has been released on January 19th, followed-up by version 47 made available on January 23rd. Try it online at try.diffoscope.org! The biggest visible change is the improvement to ELF file handling. Comparisons are now done section by section, using the most appropriate tool and options to get meaningful results, thanks to Dhole's work and Mike Hommey's suggestions. Also suggested by Mike, symbols for IP-relative ops are now filtered out to remove clutter. Understanding differences in ELF files belonging to Debian packages should also be much easier as diffoscope will now try to extract debug information from the matching dbgsym package. This means objdump disassembler should output line numbers for packages built with recent debhelper as long as the associated debug package is in the same directory. As diff tends to consume huge amount of memory on large inputs, diffoscope has a limit in place to prevent crashes. diffoscope used to display a difference every time the limit was hit. Because this was confusing in case there were actually no differences, a hash is now internally computed to only report a difference when one exists. Files in archives and other container members are now compared in the original order. This should not matter in most case but overall give more predictable results. Debian .buildinfo files are now supported. Amongst other minor fixes and improvements, diffoscope will now properly compare symlinks in directories. Thanks Tuomas Tynkkynen for reporting the problem.

Package reviews 70 reviews have been removed, 125 added and 33 updated in the previous week, gcc-5 amongst others. 25 FTBFS issues have been filled by Chris Lamb, Daniel Stender, Martin Michlmayr.

Misc. The 16th FOSDEM will happen in Brussels, Belgium on January 30-31st. Several talks will be about reproducible builds: h01ger about the general ecosystem, Fabian Keil about the security oriented ElectroBSD, Baptiste Daroussin about FreeBSD packages, Ludovic Court s about Guix.

I have decided that is high time to declare svn-buildpackage orphaned since many people are replying on it to be useful, but nobody cared enough to answer to the RFH Eduard Bloch made some 3 years ago.

I know it would have been better if I would have asked a request for adoption, but, honestly, the package didn't had a maintainer in the last year and that would have been lying to everybody.

The package is quite important and I would hate to see it leave the official archive since many people do need it and use it regularly (I know for sure the GNOME, Perl and the Debian Games Team use it) and I have enjoyed working on the package while I was motivated.

The code is maintained in SVN and the trunk can be viewed at:

http://svn.debian.org/wsvn/collab-maint/deb-maint/svn-buildpackage/trunk/

and can be checked out with any of these commands:

# read-only copy
svn co svn://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk svn-buildpackage

# read write, if you have an account on alioth.debian.org:

svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk


Also, note that the package has several features which the new maintainer(s) should be aware of and must make sure they all work when changing the code. Also, there are some things to remember:

• there is support for native and non-native packages
• non-native packages' repo can be a complete repo (with an upstream branch) or an incomplete repo (just the differences from the upstream - most times the debian directory, but not always)
• there is an interactive and a non-interactive mode, both have to work properly
• the packages can be stored in the repo under 2 different layouts and both have to work since they are both used; support for an arbitary layout would be great and I have a few ideas about how to implement that, so please contact me if you want to work on that
• team maintainance workflow MUST be supprted and should be one of the highest concerns for the maintainer; this means that being able to work on a new package without issuing more than one command to have all necessary stuff for the build, package upgrades to be done is the target to reach for (currently the situation is a lot better than it was in the past)
• there is on misfeature from the past that should be finally dealt with - something that was supposed to work as a cache ended up working like an override; meanwhile the effect for new packages/checkout has been minimised, but the code could do better at dealing with old checkouts affected but this (drop the old file name for the overrides, use a new one and scream when the old file name is encountered)
• 0.6.24 is waiting for an upload
• a test frame is missing and would be most welcome; I already started working on this based on the git test frame, but didn't managed to have a good-enough-to-publish code
  

These being said, I am really hoping svn-buildpackage will find a new maintainer since it deserves a lot more attention than I am providing. Don't forget, 0.6.24 is wating for an upload already.

---

Update: Neil Williams answered and agreed to take over maintenance, but he doesn't usually use svn-inject and svn-upgrade, so somebody taking care of those would be needed. Ironically, those two scripts are the ones in the worst shape of the three main scripts.

Although slow, development on svn-buildpackage still continues. Sorry for the delays, but both myself and Eduard Bloch have been unable to assign more time to svn-buildpackage development in the last few months.

From the changelog of the trunk package (unreleased 0.6.22):

  [ Eddy Petri or ]
* IMPORTANT: changed default behaviour of saving the configuration in
.svn/deb-layout by default to avoid stale data to override the
configuration options that were updated in the repository.
(Closes: #414581)
As a consequence, a new option --svn-savecfg was added to allow a
mechanism for easily overriding options locally

BTW, did you know that svn-buildpackage is maintained in collab-maint and welcomes contributions and committers/reviewers (especially those)?

In case you want to help, this is the place to start from:

svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk

or

svn co svn://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk

If you don't have commit access to collab-maint yet (just make a request on the alioth tracker and that will be fixed ;-) ).

Short update:

• I had no time to do hacking lately
• there are too many mails on -boot; I wish they changed their minds and made a -boot-dev list, the BTS mails are incredibly annoying (yes, I made a filter, but is not that efficient); I am thinking seriousely about unsubscribing from that list
  
• I would like to retreat from supporting the ppp-udeb package of ppp since I have no more interest in it; I already unsubcribed from part of the mails related to it
• I have a new HDD from my router and is really silent :-) (some good news, at last)
• glest-data contains some unclearly licensed stuff; imagine how nice is that when upstream is unresponsive (although not dead - adds new messages on the upstream forum, but never answers other's posts)
  
• sorry for not having time to work on svn-buildpackage, glest, naughtysvn, wormux and oolite; I would really like NMU work on the debian packages (but I don't know what to say about svn-buildpackage since Eduard Bloch is the lead developer)
• real life is taking is share back
• I am thinking of upgrading to lenny in an attempt to motivate myself back into coding
• aspell-ro with support for the correct diacritics should be uploaded soon in sid; cedilla support is dropped; minor obstructions in the way of the uplaod
  
• LVM rules
• RPM still sucks big time not because of itself, but because of the pure lack of tools for it
• scons can't cross build
• the freetype cross building bug (reported and found in gentoo) has a working patch; they claim they sent the patch
• I got 2 cool presents for my birthday (27 now): an ASUS wl-500g Premium wireless router and a Fujitsu USB HDD
  
• chroot-ing in armel from arm isn't possible (for me?):

ritter:/home/eddy# chroot /data/chroots/armel-root-fs/
Illegal instruction
ritter:/home/eddy# uname -a
Linux ritter 2.6.18-4-ixp4xx #1 Sun Aug 5 19:53:40 EEST 2007 armv5tel GNU/Linux

• I no longer have this on my belly (it washed away):
  

• the vacation was really great
• I have too many interests in and outside of Debian, I'll have to cut back on some of them
• Ross Burton rules because he wrote tasks and he maintains it properly
  

Yes Mark, your rant expresses well what I think. And also what I have said before but apparently not many people do care. I still think that we need a strong DPL or a special delegate with powers of orphaning packages by force, since sometimes getting a new maintainer is a step ahead no matter how much experience the new maintainer needs to have. Skills can be learned. But skills in the hands of an inactive maintainer is simply dead potential. Doing something somehow is sometimes better than not doing anything. A such hypothetical delegate would need to have the right nose to detect such cases and orphan such packages. No matter how important this package is - bugs are bugs are bugs and they need to be fixed in a timely manner, ie. without unacceptable/long delays, no matter which RL problems of the particular maintainer do hinder him/her.

I uploaded last night Mono 1.1.9.1, Gtk# 2.3.91, MonoDoc 1.1.9 and mono-tools 1.1.9 to Debian/Unstable and debian.meebey.net. mono-tools for Debian/Unstable is now in the NEW queue though, so it will take some days before it hits the Debian archive. Gnunit and the famous monodoc-browser package is part of mono-tools now.
Warning about Gtk# 2.3.91, it breaks ABI means all Gtk# 2 applications must be recompiled against Gtk# 2.3.91 in order to work again, for example f-spot and muine. MonoDevelop 0.7 is already recompiled and uploaded too, f-spot and muine will follow tonight. The package dependencies will force a removal of f-spot and muine when Gtk# 2 will be upgraded, so nothing will break silently. Thanks to Eduard Bloch (aka Zomb) and Ingo Saitz (aka Salz) for sponsoring the uploads of the packages to the Debian archive.

Jurij, I would not get panicky just because somebody claims MD5 can be "broken" really, really, really quickly. They do not reveal many details but reading their attack scenario you can get a slight idea of what they did to "weaken" MD5. In this case the attacker have control on both documents, the original and the forged one. I assume their method relies on getting a signature on exactly the same document that they created - without any modification and also on having a way to insert hidden, redundant data. And the signing party must be sufficiently stupid to sign things that it has no control about. Applying this in a real-world scenario should become a bit more complicated. In most formats you can discover manipulations based on adding additional data. And in stronger watermarking technologies it would become much more complicated to add random data without violating the watermarking quality criteria (or even breaking the cover format). All that just speculation, of course. I am looking forward to reading their paper.

Something in apt-cacher did always suck... I adopted the package short before the Sarge release and tried to make it work better. At that time the package was not in the best state, too many changes have done without big design (or any design?) in mind. I made some changes on the cache structure to make it easier maintainable, introduced a basic signaling mechanism and consistency checks, so it should not get stuck or deliver wrong data any longer. However, there was the one big flaw, and Bug 354925 brought it to daylight. Storing all files in a flat directory was a very cheap way to merge multiple mirror contents and allow users choosing just any valid mirror. But it had also some costs: file collisions on identical names, happening more often since Ubuntu's is out there. The more I looked trough the code to find a good solution, the more I realized a need for a complete overhaul of the internal structure. For example, the simpliest change would be just putting the files into a nested directory structure. Great. But you will have duplicated files everywhere. They can still be re-unified using hardlinks, but that should be done offline since lookups with checksummng cause too much delay. And there was still the problem with persistent connections and forks, LWP does not allow connection reusing in forked clients so you get too many server connections. And the logging has been done synchronously and required flock'ing. Acceptable and not very memory-expensive but causes delays on filesystems with some load. So, the final software architecture for apt-cacher that I came up can be described with few characteristics:

• using perl threads (separate threads for logging, connection dispatcher, connection handlers, download agents)
• not spawning too many threads, putting agent threads into a pool of available threads. That would even reuse the connection if the next apt-get client tries to access the same server
• no direct access via CGI or stdin/stdout (inetd) anymore. Instead, connection can be done via Unix Domain Sockets, so small wrappers will provide access to the daemon. That should be even more efficient.
• the problem with file duplicates will be solved with sqlite3 - apt-cacher will extract the data from Packages/Sources/Index files and track the paths/filesizes/checksums. When a client requests a file and a stored one (with the same size/basename/checksum) exits, it will be returned instead.
• the bunch of "header", "complete" and "notify" files will disappear too. They just eat space and inodes and are not needed anymore. The header files will be replaced with self-generated ones, using file data from the database. .complete and .notify existed basically for IPC and storage of origin download path and will be replaced with internal thread communication and directory path.
• integration of pdiff files - if the package index files are processesed in a background thread anyway, the more fresh pdiff files can be used to rebuild the index files in an efficient way. Trigering this rebuild action periodicaly would also allow old apt-get clients to use the benefits of the patch transport.

But first I need to get past my exams period :-( And I hope the final implementation will not become a memory monster, I didn't have the impression that Perl threads are really memory-efficient in the few first tests.

So, after beeing hit by JoeyH's boot-floppies bug closing orgy and beeing bothered by all the old stuff in my BTS stuff mailbox, I wrote a simple script (derivate of grepmail) to remove all the messages related to closed bugs. Result on
http://rootfs.net/soft/bts-mbox-clean.pl.