Given the recent articles or blog posts that may lead some people to think that dunc bank made people work against Debian, maybe some explanations are needed.

Dunc-bank is a single web page that some humourless people may find unfunny, YMMV, but that is nothing else than satirical. There was no conspiracy, undermining work, or power games. People claiming the contrary are just making complete fools of themselves. Really. The people that contributed to dunc-bank, meaning that did report most of the RC bugs in the last month are for some, even disgruntled when it comes to dunc-bank (I'm thinking e.g. of Lucas Nussbaum that did a full archive rebuild and reported many bugs).

No, dunc-bank is not the evil masonery club that some depict. The sole thing I think really happened, is that people are nowadays really concerned about QA, and that there is a whole lot of issues that can be tracked automatically, at home (a good ADSL line and a GHz grade CPU is largely enough to do an archive rebuild in a week nowadays). What is really a shame in fact, is that those checks are not performed by Debian for any package, and on a regular basis. The other factor is that I think many people had concerns with etch quality, as many discussions in the past month may have let think that its quality could suffer from the announced release date. Now that this bad joke is now officially a dead-line, I think this is less and less a concern.

That said, Yes, I do think some people that usually did good work in debian diminished their work considerably, and that it hurt the release. We lost some developpers (our locales + X-keyboard expert and that's a huge loss), some orphaned a lot of packages, and recent events do show that you can't improvise beeing the libpng maintainer a month before the release, and so on. Yes it's true that recent events and surroundings in Debian^[1] have led people to feel they are strangers to what Debian is becoming. And blaming them for not beeing supportive is very distateful and shocking. When you do pursue actions, that will lead to big changes in the community, then blaming the community members for those changes is a shame.

So no, you can't blame the people behaviours (that have been reduced to dunc-bank supporters because that's so easy) for etch beeing late, because you can't blame the direct consequences of an action for beeing the cause of its failure.

Here is how I have a (mostly^[1]) working flash in a 64bit browser:

1. take the rpm's (both) from ndpluginwrapper home page
2. alien -d them
3. dpkg -i nspluginwrapper*.deb
4. apt-get install linux32 ia32-libs-gtk gsfonts-x11
5. get flashplugin-nonfree_9.0.21.78.3_i386.deb from an i386 mirror
6. dpkg -i --force-architecture flashplugin-nonfree_9.0.21.78.3_i386.deb
7. dpkg -L flashplugin-nonfree|grep so | xargs rm -f
   yes it caused me some problems, so I'm not sure it's needed but it won't hurt

and then as a user (system-wide installation of the flash plugin does not work for me at all but quite well as a user) :

1. mkdir -p ~/.mozilla/plugins
2. nspluginwrapper -i /usr/lib/flashplugin-nonfree/libflashplayer.so
3. and then go to about:plugins, you should see flash appear here.

It works for many flashes here, except, as said, for the parts that link to an external content.

I've read in many places that the flashplayer 7.0 works better than the 9 one, but the method should globally not vary a lot.

Note: to make it work for konqueror I had to restrict the places where it looks for plugins to /usr/lib/firefox/plugins + /my/home/.mozilla/plugins, and as said, it crashes quite often and randomly.

Edit: to be fair to the GCC crew, it seems the guy who closed me the bug to the face was not very representative of'em. Thanks to them to their very good compilation suite btw !

a bit of history

I've been bitten today by a problem due to the fact that I use the gcc __attribute__((nonull(...))) as a hint in my C headers to say to the programmer that it's up to him to check if what it pass to my function is NULL, or not. I had written (erouneously) that bit of code:

/* in the .h */
__attribute__((nonnull(1)))
char *m_strrtrim(char *s);

/* in the .c */
char *m_strrtrim(char *s)
{
    ssize_t len = s ? strlen(s) : 0;
    while (len > 1 && isspace((unsigned char)s[len - 1]))
        len--;
    return s + len;
}

I've added the __attribute__((nonnull)) by mistake, and indeed sometimes used m_strrtrim on strings that I knew to be NULL. The point is, gcc is able to use the nonnull attribute to optimize code, and that's very legitimate. In my case, it optimized the s ? strlen(s) : 0 into strlen(s). And without surprise, it caused segfaults.

I had a hard time finding that bug, because I've never thought that it could come from the header. As it could not come from the m_strrtrim function, I've looked very hard for stack overwrite and so on in the caller, but even valgrind did not catched anything interesting (except an invalid read size of 1 in strlen). It's when (in order to see if it was a gcc optimization bug) I've generated the preprocessed source that I saw the damn prototype in the preprocessor output, and that was suddently obvious to me why it segfaulted.

the wishlist bug

Since it was quite an unusual problem, that can make you loose a lot of time, because the bug lies very far from where it's revealed, I've opened a wishlist bug in gcc to ask for a warning when you test some pointer against NULL that you should already know to be non-NULL. like the warning about always true (or always false) comparisons for e.g.:

size_t len;
// ...
if (len >= 0) { ... // always true
if (len < 0) { ... // always false

That's gcc bug#30043. Or I should say was. My bugreport has indeed be closed a first time as INVALID, because the reader thought I said the gcc optimization was not legitimate (*sigh*). I reopened it explaining more precisely that I only begged for a warning, not for anything else, and that YES I DID READ THE DOC.

The bug has just been closed as WONTFIX this time, with an explanation that still makes me stare at it with a blank look:

I don't think a warning is the right thing in this case because the developer should have read the documention […]

WTF !?

If reading the documentation can make you a perfect programmer that never do any mistake, then god, I must be a super-mega-coder that always write perfect code ! Sadly, reading the doc do not prevent you to avoid cuts (aka segfaults) when you juggle with razorblades (aka code in C).

I can understand that it's hard to do in the present state of GCC, and that's it's not an urgent feature, given how peculiar that request is. But I'm completely stunned to see that a guy that is in the compiler business just consider that a warning is useless, and that the documentation is the key answer. I use an over-long compilation line in my projects ^{[1] [2]} especially because a compiler is really better than me to catch many kind of errors. And it's vital to do so.

I've seen too many people that only compile with gcc -g -O2 and optionnally with -Wall when they don't forget it. But from a guy in the compiler business, well, that's just yet-another-illusion that collapses.