Search Results: "Eduard Bloch"

24 January 2016

Lunar: Reproducible builds: week 39 in Stretch cycle

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: Some uploads fixed some reproducibility issues, but not all of them: Patches submitted which have not made their way to the archive yet: Transition from to the more general 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! 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.

15 May 2009

Eddy Petrișor: svn-buildpackage is now orphaned

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:

and can be checked out with any of these commands:

# read-only copy
svn co svn:// svn-buildpackage

# read write, if you have an account on

svn co svn+ssh://

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:

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.

17 September 2007

Eddy Petrișor: svn-buildpackage:development, RFH

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 co svn://

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

16 August 2007

Eddy Petrișor: too much to do, too little time

Short update:
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

6 January 2007

Eduard Bloch: Just orphan by force

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.

12 March 2006

Mirco Bauer: Mono, Gtk# 2.3.91, MonoDoc 1.1.9 and mono-tools 1.1.9

I uploaded last night Mono, Gtk# 2.3.91, MonoDoc 1.1.9 and mono-tools 1.1.9 to Debian/Unstable and 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.

11 March 2006

Eduard Bloch: MD5 break risk really that high?

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.

8 March 2006

Eduard Bloch: Rewritting apt-cacher

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: 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.

16 October 2005

Eduard Bloch: BTS mailbox cleanup

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