People who see those standing to their principles as childish have a strange perception of what being an adult means. Or maybe it's just politics. After all, we've seen this coming: Well, Dunc-tank failed, but this was because of childish people working actively against it.

I don't know whether statically linking ffmpeg into packages brings any speed improvement, but it can at least help spending some mirror space and bandwidth. With static linking:

-rwxr-xr-x 1 joss joss  13M 2006-12-12 22:44 libgstffmpeg.so*
-rwxr-xr-x 1 joss joss 9,8M 2006-12-12 22:45 libgstpostproc.so*

With dynamic linking:

-rwxr-xr-x 1 joss joss 571K 2006-12-12 22:38 libgstffmpeg.so*
-rwxr-xr-x 1 joss joss  70K 2006-12-12 22:38 libgstpostproc.so*

Over the last few weeks, I have been very busy at work, and therefore hadn't have much time for Debian. Especially, I haven't been able to help the Dunc-bank project as much as I wanted to. However, it recently became obvious that I brought my contribution to the project's impressive success (despite being not too dramatic). That was, orphaning libpng. The one thing to know about libpng is that upstream developers like to break their software at every single release. Given the number of packages depending on it, it is not reasonable to upload new versions less than 6 months before the release; this is the reason why I carefully kept the working 1.2.8 version. However, despite being warned, the new maintainer decided to upload two new upstream versions with a high urgency to fix two security issues, instead of backporting them. Looking at the rest of the changelog is eloquent :

• removal of the libpng3 package despite my explanations of why not to do so - a change reverted later;
• moving development examples to the shared library package - I'm sure the 91% of users having libpng12-0 installed, according to popularity-contest, will be glad to have them;
• last but not least, removal of a patch that was introduced to not export some useless symbols - of course, this was done without bumping the shlibs, just like the two new upstream releases.

The result is now, according to the unofficial RC bug list, no less than six libpng-related release-critical bugs:

• broken on amd64;
• incorrect dependency information;
• new bug introduced upstream;
• pngcrush broken.

Before anyone asks me: no, I'm not volunteering to fix these bugs. Maintaining libpng is a tedious and time-consuming task that requires more motivation than I currently have. It is way too late in the release process, and my advice for a short-term solution (suitable for a release in two months) would be to revert completely to 1.2.8 and backport the security fixes. The medium-term solution involves even more work, but I think there is no more choice: the library needs to be split in two, one private library with an unstable ABI for software like pngcrush and optipng, and one public library with a very strictly fixed ABI (probably following closely the LSB). Good luck to anyone implementing this. The long term solution is more appealing: rewrite everything from scratch. The PNG specification is much clearer than the libpng code, and calls for a clean reimplementation using modern programming techniques. For a completely unrelated, but more entertaining moment, I recommend the reading of this Bjarne Soustrup interview, where he tries to defend C++ against all common sense. The introduction really made my day: C++ remains the archetypal "high level" computer language (that is, one that preserves the features of natural, human language). Something to meditate on.

Welcome to this 5th issue of the DeFuBu contest, the monthly championship of the funniest bug reported to the Debian BTS. The challengers

• Pierre Habouzit with #395522 (whitelister terminates immediately)
• Josselin Mouette with #396247 (sound-juicer: weird playback if disk is ejected)
• Christian Perrier with #396223 (gnome-applets-data: Colorado Springs listed as "Colourado Springs" in British English)
• Joey Hess with #393846 (wave at a webcam to overwrite file)
• Michael Ablassmeier with #397646 (exim4-config: reportbug mail issue)

How the vote has been done Four Debian related people voted for these bugs, Philipp Kern, Julien Louis, Cyril Brulebois and David Pashley. Full ranking Bugs

• #393846 (wave at a webcam to overwrite file) (with 12 points)
• #396223 (gnome-applets-data: Colorado Springs listed as "Colourado Springs" in British English) (with 10 points)
• #396247 (sound-juicer: weird playback if disk is ejected) (with 9 points)
• #397646 (exim4-config: reportbug mail issue) (with 9 points)
• #395522 (whitelister terminates immediately) (with 3 points)

Challengers

• Joey Hess (12 points with 1 bug)
• Christian Perrier (10 points with 1 bug)
• Michael Ablassmeier (9 points with 1 bug) and Josselin Mouette (9 points with 1 bug)
• Pierre Habouzit (3 points with 1 bug)

The winners

• Bug: #393846 (wave at a webcam to overwrite file) (with 12 points)
• Challenger: Joey Hess
• Bug reporter: Joey Hess
• Voter: David Pashley with the nearest ordered tierc : #393846, #396223 and #397646.

Congratulations to Joey Hess, two victories in a row :-) Notes To participate, simply drop me an email with a bug number. About DeFuBu

Pointed at the issues by Josselin Mouette’s post, I got aware of a list of issues posted by JP Rosevear, which is a reply to Mark Shuttleworths post to the opensuse mailinglist. Note especially point 2, which is: “Preventing the Debian GNOME maintainer from updating GNOME packages until after Ubuntu LSO had shipped because you had hired him.” If this issue is true, it’s the worst thing I ever heard of regarding Canonical. I mean it’s bad enough that points 1 (“Having a stated policy of not funding any significant new software development because the Return on Investment is not good enough”) and 3 (“Not releasing any source code for launchpad/rosetta/malone to maintain a competitive advantage”) certainly are true (even though I can’t prove and therefor don’t 100% believe the second part of #3). But unless there is a very good reason to delay the submission of the patches developed to “upstream”, Debian.
It’s bad enough that Canonical hired the most active Debian Developers, depriving Debian of much of their time, while not really supporting Debian (i.e. while not actively submitting patches to Debian). It would have been better for the community if Canonical had hired less active DDs (or even non-DDs). Sure it would have been harder to select some sufficiently qualified people for the jobs, but the total outcome whould have been better IMHO (getting time from previously uninvolved people, while keeping the existing contributors). Anyway, I really would like to know wether the mentioned point #2 is true, and if so wether any valid reason for doing so could be given before I set my opinion about this issue in stone. One thing is sure however, I’m becoming more and more critical regarding Ubuntu and Canonical over time while I once hoped that the opposite would become true for those criticizing Canonical at that time. Actually I still hope so (and thus I hope reason to become less sceptical again).
Another thing is also sure: If Canonical wants to use Debian as a base for much longer, it should make damned sure to work with Debian more actively instead of seemingly working against it (more or less openly). Update: As also pointed out in a comment below, a post by Scott James Remnant proves point 1 from the the aforementioned list and gives a further hint that point 3 might be true. More precisely it says “we have a policy of not doing our own software development, but only packaging what others have developed”, which probably means “not doing our own major software development”, since - as a comment to that post also says - Canonical did some software development, like launchpad/rosetta/malone and some other relatively small projects.

Last Friday, Mark Shuttleworth posted a big troll he also sent to the OpenSuSE mailing list. While the Novell/Microsoft deal has raised many legitimate concerns, I really think the Canonical leader should take the mote (in France, that would be a beam) out of his own eye first. As expected, the reactions from OpenSuSE developers were strong. But I was really shocked by two of them. According to JP Rosevear, Mark Shuttleworth is, among other things, preventing the Debian GNOME maintainer from updating GNOME packages until after Ubuntu LSO had shipped because [he has] hired him, and trying to simultaneously supplant Debian's community with "Ubuntu" while relying heavily on the Debian community to be successful. According to David Canar, Ubuntu's anti-community practices are well-known. Yes, I was shocked to see these reactions. Not because of their strength, as they are perfectly justified. I was shocked to see that developers in the OpenSuSE community seem to be better informed than Debian developers about Canonical's dealings. When talking with random fellow developers, I see many of them who truly believe Mark Shuttleworth when he says he's just doing the best for Debian, despite everyday's proof of the opposite in Canonical's employees actions. Shouldn't we be concerned at all about Ubuntu sucking the blood out of the Debian project? It strikes me that OpenSuSE developers care more about it than ourselves.

While preparing a new upload of python-support containing a workaround for #396840 (python2.3 inadvertently removed from all pyversions calls), I noticed a very nice side effect: it enables support for python2.5 for all modules using python-support. Extensions are still not built, but it means python 2.5 in etch will have at least a few add-on modules.

It is currently rumored that, despite great efforts from the release managers and the dunc-tank board, the etch release will not make it on time. Some say this is because of Developers being upset by some random and obscure experiment. Some others think this is because there are too many RC bugs and that we won't be able to fix them on time. Some might say this is because of a surrealist conflict with the Mozilla corporation. Guys. You're all wrong. The main reason for the delay will be the same as that of the woody release. Developers will be too busy testing the brand new Frozen-bubble 2.0.0 release extensively. Instead of hacking, they will spend their nights fighting with each other in up to five players LAN and internet games, enjoying the shining new graphics. Debian unstable packages are available in incoming and tonight on your favorite mirror.

(For the non-french readers, yes, there is an obvious grammatical error in the title of this post. This is a reference to a news story that happened years ago. Bubulle is Christian Perrier’s nickname, btw.) So, here it is, I am rethinking my involvement in the Debian Project. And it’s all Bubulle’s fault. I am not leaving the Project, because Debian is far more important to me than some rude bashing from Bubulle. It is a fact that Bubulle and me have agreed to disagree on a number of topics, it’s also a fact that we are both committed to Debian. In the past few weeks, a number of things happened, and we both said things we probably regret (at least I do). I do not like this paternalistic tone he sometimes demonstrate in mailing-list postings. I totally hate that, to be frank. But I can pretty much deal with it as long as it’s not aimed at me. He tagged one of his debconf-notes-are-evil-and-useless-crap-please-remove-it filed against one of my packages as “not-fixed” even when I explained that it is not a bug and the note really is what I want. It implies that I am not fixing bugs, which is something I cannot accept. Debian bug reports tend to have the very first priority in my todo list. So far, I can deal with that. But what I cannot deal with, is this mail from Christian to Paul Rouget (the moron who first posted the photos of the Firefox/Iceweasel posters from the JDLL last saturday, vomitting on us, and the comments were even worse). Sorry, the mail is in french, I don’t know how well Google Translate performs on this one but you should give it a try. This is purely insulting. Christian did not even contact me, he did not even try to get the facts straight, and it looks like my last post, in which I explain what happened during the JDLL, was totally useless. So, congratulations Christian. I’m perhaps not the most active DD, but I’m quite active nonetheless. Well, that is, I was quite active and reactive. This is likely to change starting today. I’m not going to drop any packages. I’m not going to disappear. I’m not going to let Debian France down. I’m not going to let my packages rot in the archive. But I’m going to be noticeably less active and reactive. Next time you talk to me, it’d better be to apologize for this mail you sent to Paul Rouget. I /quit from both Freenode and OFTC on monday evening. I probably won’t come back. I feel way better already without being on these two networks, without reading Rapha l Hertzog blatantly lie about dunc-tank, without reading a whole lot of other crap. I’m taking a much-needed break. Fuck you. Pierre Habouzit, Josselin Mouette, Denis Barbier, Sam Hocevar, and others (you all know who you are): thank you, you guys rock. And GO GO GO dunc-bank !

Directed by jd & adn Genre: Action / Adventure / Sci-Fi / Thriller / Horror / Drama / Humor
Runtime: several weeks
Country: A lot
Language: English
Color: Color (Technicolor, QT, GTK and ncurses) Tagline: They stole their project, now they want it back. Plot Outline: In September 2006, a group of developpers from the Debian planet rise against the corruption leading the government.
User Comments: Great action, great suspense, great cultural satire, and a great mind-bender. Awards: Waiting for nomination. Quotes:

• Bah, if you don't want to read me, just don't , Sven Luther
• Oh my. , Clint Adams
• Or maybe I'm withdrawing my support because I'm busy with my chainsaw. , Josselin Mouette
• "I'm withdrawing my support because the developers might agree with AJ rather than me"? Come on. , Matthew Garett
• OH NO YOU DON'T. This thread is _not_ about you, it is _not_ about Frans Pop, and it is _not_ about debian-installer. , Peter Samuelson

Cast overview

	Anthony Towns (aj), as the Debian Project Leader		Denis Barbier (bouz), as The Recaller
	Aurelien Jarno (aurel32), as one Seconder		Clint Adams (schizo), as one Seconder
	MJ Ray (mjr), as one Seconder		Pierre Habouzit (madcoder), as one Seconder
	Martin Schulze (joey), as one Seconder		Marc Dequ nes (duck), as one Seconder

This is my current feeling after seeing the GR results. Any more comments are superfluous.

At the Journ es du logiciel libre near Lyon, the Debian stand happened to face the Mozilla one. The Debian developers present there had prepared some Iceweasel propaganda:



However it seems Daniel Glazman didn't understand all the fun of this situation, and just found these developers to be total morons or bloody fanatic assholes. "Moron" is also reserved for anyone trying to post comments disagreeing with him on his blog, which can also be simply deleted.

It seems some people need to take things less seriously.

Of course, as the epiphany maintainer, I can only be happy of this situation which will lead to more people using this great browser.

The kernel team, or should I say, Sven Luther, as the rest of the kernel team hasn't been remotely as visible as him on this topic, is now trying to spam debian-devel-announce, assuming the average Debian developer isn't able to read the proposals. Fortunately, the mail was redirected to debian-devel thanks to clever filtering.

I still think, for the moment, that Choice 2 of the proposal currently being voted (Special exception to DFSG2 for firmware as long as required) is still the best of all proposed choices, and I'll try to explain why.

1. This proposal doesn't only address firmware issues. It clarifies DFSG 2 for other works often found without source, acknowledging current practice for fonts or pictures.
2. Granting an exception only for etch is dishonest. The real reason behind the exception is that we don't yet have any means to ship these firmwares in a way that complies with our principles. We're violating them in the testing and unstable distributions as well, and that has nothing to do with a release.
3. Granting an exception for etch may not be sufficient. I don't want to see these endless discussions again for the next release, and this is what is probably going to happen if an etch-only exception is granted.
4. The proposal frees the hands of people working on stripping the firmwares out. Their patches would have to be accepted straight away, not two months before the release when someone says "Hey! there are non-free firmwares in the kernel!".
5. By principle. I'm fed up with people splitting hair on debian-vote for weeks, to end up reaching a formulation that's close to the one I wrote in a few minutes a month ago.

Everyone should make up his own opinion. You're welcome to read the proposals themselves rather than the propaganda I'm writing, but I hope I've made clearer the rationale of Choice 2.

A couple of comments on the ongoing votes. The DFSG/firmware issue is a complicated one. For the votes that we’ve currently got open, I’m voting for futher discussion in favour of the DFSG#2 clarification – not because I disagree with requiring source code for all works in principle, but because I think we should be making sure we can make Debian work with full source for everything first, before issuing position statements about it; and I’m voting for “release etch even with kernel firmware issues” above further discussion and “special exception to DFSG#2 for firmware” below further discussion, because I don’t think we can handle the broader issue before etch, and I don’t think it’s a good idea to try to tie the exception to the non-existance of technical measures directly. I’m not really sure that’s a good enough reason to vote that option below further discussion, so I might change my vote on that yet. There have been quite a few other proposals on the topic, including one from me that didn’t get sufficient seconds to be voted on, another from Frans Pop that was withdrawn due to procedural issues, a couple more from Sven Luther, and a new proposal from Sven and supported by the kernel team that’s a further refinement on the “release etch even with firmware issues” resolution currently being voted on. I personally think we should spend some time after etch thinking a bit more deeply about this stuff. Personally, I think we should insist on source for everything, but that also means we need to have a clear explanation on why it’s good – even for firmware and font files and music and artwork – and it means we’re going to need to make sure we have a reasonable way of distributing it, and it means we’re going to have to make sure that we have a good way of distributing stuff that doesn’t meet our standards but that users still need or want; whether that’s drivers they need to do installation or get good graphics performance, documentation for their software, or whatever else. There’s a lot of real improvements we could make there – both in making the core of Debian more free and more useful, and making it easier for users who want to make compromises to choose what they want to compromise on and what they don’t want to compromise on. I really hope that once etch is done and dusted quite a few of those sorts of improvements will get done, both in technical improvements in Debian, and in good advocacy from Debian and other groups towards people who aren’t already making things as free as they potentially could be. One the recall issue, I would have preferred to vote “re-affirm”, then “recall”, then “further discussion”, to say “I don’t think this creates a conflict of interest that can’t be handled, but I’ve no objection if other people think it does”. But since that isn’t what the ballot(s) turned out to be, I’ve voted “re-affirm” above further discussion on that ballot, and “recall” below further discussion on the other ballot. I’ve voted the “wish success” option above “don’t endorse/support” option for two reasons – first, because the “wish success” resolution actually refers to “projects funding Debian or helping towards the release of Etch” in general, while the “don’t endorse/support” proposal specifically talks about projects I’m involved in (including non-Dunc-Tank projects) which seems kind of personal. There’s also the fact that I’d rather see more success and mutual support in the Debian community, even for projects I don’t personally like, than less. I originally voted the “don’t endorse/support” option below further discussion for those reasons, but then decided that that was silly – just as I would have been happy to vote for the recall above further discussion, it’s not really that big a deal either way, and fundamentally I think both options are essentially the same anyway: that any potential conflict of interest can be dealt with, and Debian and Dunc-Tank are fundamentally different projects. I was probably influenced in that a fair bit by the “not endorse/support” option being proposed and seconded mostly by people who actively oppose the idea, including Josselin Mouette, Samuel Hocevar, Pierre Habouzit and Aurélien Jarno. But in the end, the outcome’s fine any which way – some people will continue disagreeing with the concept, others will agree with it, and everyone can keep contributing to Debian in whatever way they think’s best whatever the outcome. And like I said when running for DPL this year, while you are a lot more visible as DPL, it’s not actually that necessary to be DPL to get things done in Debian.

This message is dedicated to Sven Luther.

Welcome to this 3rd issue of the DeFuBu contest, the monthly championship of the funniest bug reported to the Debian BTS. The challengers

• Benjamin E. Seidenberg with #330031 (cogito is too much fun)
• Josselin Mouette with #385063 (python-gtk2: inconsistent use of tabs and spaces in indentation in pygtk.py and __init__.py) and #256039 ('nicotine' in 'top' makes me want to smoke)
• Cl ment Stenac with #385561 (konsole crashed after my cat jumped on the mouse)
• Gregory Colpart with #313492 (xscreensaver/GLSnake has sexually inappropriate imagery)
• Julien Louis with #387832 (init: no have idea :/ error on system)

How the vote has been done Four Debian related people voted for these bugs: Pierre Machard, Pierre Habouzit, Florent Bayle and Mohammed Adn ne Trojette.
Samuel Hocevar did not vote because he was not paid for it. Full ranking Bugs

• #385561 (konsole crashed after my cat jumped on the mouse) (17 points)
• #256039 ('nicotine' in 'top' makes me want to smoke) (15 points)
• #330031 (cogito is too much fun) (10 points)
• #387832 (init: no have idea :/ error on system) (9 points)
• #313492 (xscreensaver/GLSnake has sexually inappropriate imagery) (7 points)
• #385063 (python-gtk2: inconsistent use of tabs and spaces in indentation in pygtk.py and __init__.py) (2 points)

Challengers

• Cl ment Stenac (17 points in one bug)
• Josselin Mouette (17 points in two bugs)
• Benjamin E. Seidenberg (10 points)
• Julien Louis (9 points)
• Gregory Colpart (7 points)

The winners

• Bug: #385561 (konsole crashed after my cat jumped on the mouse) (17 points)
• Challenger: Cl ment Stenac
• Bug reporter: Nicolas Caval
• Voter: Florent Bayle with the nearest non-ordered tierc : #385561, #330031, #256039

Notes To participate, simply drop me an email with a bug number. About DeFuBu

With the ever increasing number of trolls, the average developer has no more time to maintain his packages. Motivating him to work on his packages instead of reading debian-vote is a hard challenge.

Here comes BAD-tank, which is the way to:

• motivate developers to work on their packages in the best interest of users;


• motivate users to get interest in what developers do;


• find a way for possible sponsors to spend their money in a useful manner.

BAD stands for Bribe Assisted Development. The idea is to add a new field, named XC-Bribe, to the control file. The field must contain the amount of money the maintainer requires for an upload, with a ISO-4217 currency code. For example, the maintainer might add:

XC-Bribe: EUR 50.00

to require 50 to get the package uploaded.

Then, the package shall be uploaded to the BAD-tank FTP queue. The related sources and binaries will be automatically put into a private area, while the .changes remains public. Users can then read the .changes and decide whether they want to contribute to this upload. BAD-tank accepts Visa, Mastercard, AmEx and PayPal. When the amount of the bribe is reached, the package is automatically uploaded to the Debian ftp-master queue, and the developer is credited with the bribe.

<peterS> stew: hmmmm. I keep forgetting to do that. I wonder, if I posted a message supporting aj against the recall resolution, whether aj would remind people that they don't have to listen to me (:

After seeing several developer comments implying that they won't package python software because this has become too complicated, I was hit by the fact python-support had drifted away from its original goal: make the developer's life easier. The initial idea was to simplify dh_python and make it use something that could automatically handle byte-compilation, without the maintainer even noticing it.

Therefore, with the help of Manoj Srivastava's priceless work to clarify the policy and of Pierre Habouzit's background work on supervising the transition, I have improved dh_pysupport to be able to generate correct dependencies. I have also finally added the last missing piece of functionality: private modules needing a specific python version.

This is a necessary step for Joey Hess' plan to remove dh_python from debhelper. But the more important thing is, for most packages, dh_pysupport can now be a drop-in replacement for the old dh_python. This means that many remaining packages for the transition can be updated with s/dh_python/dh_pysupport/ and a new build-depend.

And, for anyone who's afraid of maintaining a python package because it is too complicated, let me show how to make a simple package using python:

• use the upstream installation system;


• add a build-dependency on python-support 0.4;


• call dh_pysupport in the binary targets.

Yes, that's all. You mean, just like with the old dh_python, the one that used to work without having to understand anything? Yes, just like this one. Don't add a XS-Python-Version field, it's not needed. Don't add a XB-Python-Version field, it's useless. Don't add a debian/pycompat file, it's deprecated. You can add a debian/pyversions file if the package has requirements on the python version, but it's not needed for many packages.

Of course, packages with binary extensions should build them for all available python versions, but dh_pysupport handles both cases. Of course, I don't claim it's free from bugs, but bugs can be fixed now there is a good design.

So finally, I can say it again: python packaging is simple. You shouldn't be afraid of it.

As the hdf5 maintainer, I already knew upstream developers are able to imagine really innovative ways of writing broken autoconf scripts, but this one made my day.

After my first package build on my fresh amd64 system, I noticed lintian complained about a rpath:

W: gconf2: binary-or-shlib-defines-rpath ./usr/bin/gconftool-2 /usr/lib64

I found soon that this was caused by /usr/lib64 being mentioned in the libpopt.la file. The popt build system is, well, interesting. Or funny, if it doesn't affect you.

In configure.ac:

dnl XXX Choose /usr/lib or /usr/lib64 for library installs.
MARK64=
case "$ target_cpu " in
x86_64* powerpc64* ppc64* sparc64* s390x*)        MARK64=64 ;;
esac
AC_SUBST(MARK64)

And in Makefile.am:

usrlibdir = $(libdir)@MARK64@

This is subtly breaking a large number of packages on amd64, as libtool, not knowing it is a symbolic link to /usr/lib, introduces a rpath for this directory it doesn't know about. This was already reported as #374797.