during the ongoing avalanche of posts on Planet and on Debian mailing lists where you ask everyone to be friendly and considerate, you have so far:

• deliberately framed the discussion in a gender-oriented fashion to throw away unjustified accusations of sexism;
• inflated a 85-post long mudslinging thread with my name in the topic (which is the Google version of publicly throwing stones at people);
• vomited on people on an IT news site and helped the site spreading misinformation about the Project;
• shown your own frustration by trying to find hidden sexual references in messages you find offensive;
• and I m probably missing a lot since I m not reading all that crap.

Pretty please. What you mean is Go fuck yourself , but the way you are saying it is no more friendly and actually much more rude. If you meant Go fuck yourself , why not just say it?

• I would have felt better since it s much less insulting.
• You would have felt better since it s really a relief to say it frankly.
• Everyone else would have felt better since this would have ended the discussion instead of polluting the lists with useless wanking.

You are just lying to yourselves if you think your contributions to a flamewar are more friendly than others. As for those starting discussions on the community and on the code of conduct: do you want a community like Ubuntu where everyone can be scornful and prepare lousy tricks, but always preserving the appearances (thanks to a mandatory broomstick), or a community like the Linux kernel, where people say frankly what they think, even if what they think is I hope you were on crack while writing that ? I know which one I choose. I may disagree with their technical development model, but at least they know that a software community is not a group of friends. And that is a sign of maturity.

Now you know what to do.

Hint: it starts with Further and ends with Discussion .

There is again some ongoing debate about Ruy gems and how to integrate them cleanly into the operating system. Let s put aside the fact such tools are useful on Windows and MacOS which don t have decent packaging systems. This is not a reason to dictate stupid requirements for other operating systems. Still, even without that, gems, eggs and the like are great tools for development; tools that developers can t work without today. They allow to easily setup a development environment with everything needed, at the latest versions. However they were not meant for integration and production environments, and will never be suitable for them. We re living in another world indeed: a world where servers must be up 24/7, where security issues flood your inbox every day, where you need dozens of servers running the very same software. This world is the Earth. Python eggs and Ruby gems were designed for the same target audience and with similar requirements; as such, they share the same deficiencies when it comes to other audiences:

1. They replace the operating system s packaging tool. This is very nice to not wait for the packagers when you want the latest development version, but you lose track of what is actually installed. In production, you need to know exactly what s installed and at what version. You also need to know what you will need to update in case of a security issue.
2. They install packages automatically on the system. This is really the biggest WTF; there are some reasons to do that to begin with, but they are all wrong.
3. They use a specific file format. This requirement comes mostly from the Windows world, and it really makes no sense on Unix. It makes it much harder to integrate complex applications using components in different languages.
4. They ship all files at the same place, happily violating the FHS and making it even harder to integrate with other things.

Python tools (setuptools and easy_install) have shifted their philosophy and brought a few small improvements which allow us to easily work around issues 1-3. These tools now include all you need to build a development environment in any directory that will not have an impact on the system packaging, making a clear distinction between the two targets. Furthermore, the metadata is shipped separately and can safely be included in a distribution package. Similarly, modules will not be installed automatically on your system. I have yet to see such a move from Ruby developers. However, what we are still missing is something along the lines of dh_make_perl: starting from a CPAN module, it will generate a clean and working Debian package in a few minutes. There have been some similar attempts for Python, but nothing as efficient. And I am certainly guilty of not having done something in this area, as one of the most knowledgeable of issues we encounter while packaging Python modules. As a note, I should add the underlying issue behind all of this is still the same: the NIH syndrome. Developers are reinventing the wheel, engine and transmission. Which is not that bad per se, but by not looking at existing solutions for the problem of making a car move, they are inventing a square wheel, a steam-powered engine and a superconductor-powered magnetic transmission. For example, while trying to fix the 4th of items listed earlier and they are really willing to fix it and several more general issues, setuptools developers forgot to look at the existing solutions:

• API versioning in /usr/include/package-X.Y
• ABI versioning of libraries
• Build/install-time requirements gathering using an extensible format with pkg-config
• Automated generation of config.h containing all system-specific macros (including paths), with autoconf
• The Mono Global assembly cache which solves some of the specific issues of interpreted languages

Certainly, the existing tools are everything but perfect, and not necessarily suitable for Ruby and Python, but some of the design ideas behind them are clearly the good solutions to some of the issues of software development and integration. Adapting these ideas to radically different languages is going to take more time than just throwing other layers of symlink farms.

While a few developers have the chance to be paid for their job on Debian, most of us are doing it on our spare time, for fun. Yes, we are making the best operating system out there, for fun. Yet a large number of developers are taking this project way too seriously. To say it in other words, they have a carrot up the ass. I happen to prefer the French expression though, since it conveys better the rigidity of their attitude: they have a broomstick up the ass. Recently, when I launched the idea of the Bug Sprint, someone wrote to me to propose, instead of rewarding people with cookies, to send them money. This is the best example of broomstick behavior: taking the fun out of people by bringing back rampantly the very idea that almost split the project in two the last time it was introduced. The very same person, when faced with a sarcastic email sent to an announcement mailing list, immediately rushed in to send a ban request to list masters (a totally useless one, since I don t have the habit to make the same joke twice). That person happens to be the project leader. So it seems the only thing the DPL has to do, at a time when we d rather need people to fix RC bugs, is to protect the project from seditious members who don t share their love for broomsticks. When someone makes a bad-taste joke, you are not forced to laugh. But you are not forced to impose your rigid and moralist views either. And on top of that, throwing random accusations of sexism without any kind of justification does not improve the mood. This is even very close to defamation, but since I don t have a broomstick in the ass myself, I prefer to just laugh at them with the help of some fellow developers. I will go on shocking these people. And they won t like it more than in the past. Every time one of them climbs on her high horse to take a pathetic and patronizing stance while totally missing the point, it will bring a bit of fun. Bonus #1: as for the promised statistics, we are, at the time of writing, at 493 599 unique IPs who clicked on the trap. Quite a good investment for someone who d want to make money from smelly geeks. Bonus #2: here is a sexist picture.

There have been 470 mails during the last month in the DFSG violations threads on -vote@, but only 10 posters have contributed more than 10 mails so far:

85 Robert Millan
51 Manoj Srivastava
18 Pierre Habouzit
18 Josselin Mouette
16 Thomas Bushnell BSG
14 Stephen Gran
13 Frans Pop
13 Ean Schuessler
13 Adeodato Simo
12 Russ Allbery

Is someone working on a summary of the discussions? I would really hate it if we were asked to vote on this, with a “for details, see the -vote@ archives” footnote. (Robert Millan sounds like a perfect candidate for this task :-) )

---

A couple of minutes ago I received an email notification about #479427 being closed:

#479427: epiphany-gecko: please reduce the number of dependencies by avoiding linking to some libs
...
* Pass --as-needed to LDFLAGS. Closes: #479427.
+ Introduce 99_ltmain_as-needed.patch.

Being very interested on the subject I went to incoming.d.o and downloaded the -gecko and -webkit versions of epiphany, which were both listed in my packages with most dependencies top 20.

$ countPkgsDeps.pl epiphany-*_2.24.1-1_amd64/control
epiphany-webkit:27
epiphany-gecko:32

So yes, the number of dependencies dropped from 55 and 58 to 27 and 32, accordingly :)

Should dropping the number of useless dependencies be a RG for squeeze? we'll see.

Note: I'll update the post as soon as the i386 packages are built, because the number of package dependencies of my previous blog post were calculated from i386's Packages, not amd64's.

Oh, and of course many thanks to Josselin Mouette for working on the issue.

Hey Romain, you d be impressed by the number of upstreams whose knowledge of security measures is similarly close to the absolute zero. Since bad guys are always digging through commits for suspicious things, hiding the relevant commits is the best thing you can do to help them. Given things like this exist, It s likely that they have even automated tools to do this search for them. This way, distributors and security engineers have to do the same job, hoping to never miss a change that was actually a security fix. Unfortunately, two small scale projects that we happen to use have exactly the policy Romain described regarding security updates. I m amazed by the fantastic job the distributions security teams manage to achieve in these conditions.

The Debian bug sprint has started! 27 players registered in the hope to win cookies. The list of players and their assignments can be viewed at the usual place. Good luck to everyone. NB: for those who wonder, the assigned bugs were chosen as the 27 oldest RC bugs without a patch and randomized with shuf.

Only one day left for registration ! Register now and win cookies !

Sometimes, I m becoming really pestered by the number of issues, especially hardware issues, that remain prominent in the Linux system after so many years. And I m convinced that one of the root causes is the kernel development model. While far to be the only one, you understand a lot when you have a look at it. The stable API nonsense To explain the development model, the kernel documentation contains a document written by Greg Kroah-Hartman called stable_api_nonsense.txt. I think this document gets one thing very right: advertising it is complete nonsense. Many things in this document can get you a good laugh if you are used to software development, unfortunately they are not funny given how much they affect us as users and developers. Let s start with the executive summary:

You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.

What it should say instead is:

You know you want a stable kernel interface, but you don't have it, and we will never provide it. You want stable interfaces to focus on fixing bugs in your driver instead of updating it for interface changes, and to make integration of your driver in the main kernel tree easy. You would get a lot of good benefits if your driver was in the main kernel tree, but it won't make it unless you adapt to our bizarre processes, all of which have made the Linux kernel into a constantly moving target which is the reason many hardware vendors don't want to support it in the first place.

Our compiler does not have the same ABI as yours This is what happens when the only thing that interests people in charge is to code. Writing this means that these developers have no interest in making the system usable. This becomes more unbearable when such technically sharp people make up false technical arguments:

Depending on the version of the C compiler you use, different kernel data structures will contain different alignment of structures, and possibly include different functions in different ways (putting functions inline or not.)

Really, I wonder how the Microsoft developers, the GNOME guys, the glibc guys, and basically all library developers who know what they are talking about, manage to have stable ABIs despite the compiler changing all the time. One of the incredibly complicated techniques they use is to only rely on guaranteed functionality of the C specification, instead of doing many clever and funky hacks. For things more related to development itself, there are also incredibly complicated techniques like opaque structures, which save a lot of ABI breakage. Actually the only thing you need, if you design your ABI properly, is to be rigorous.

Depending on what kernel build options you select, a wide range of different things can be assumed by the kernel

This statement of a problem also contains the solution: stop making available build options no one cares about (remember, people install binary packages from their distributions) to guarantee stability instead. Instead of implementing the solution, kernel developers deliberately choose to deal with this insanity in the worst possible way: by encouraging it. Only lame developers need stable APIs But the nonsense doesn't stop to the ABI, which after all is merely a problem for distributors. To be more annoying to developers themselves, let s make up reasons to break the API all the time:

Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things.

Explained this way, it looks like a good thing. If you've done serious development or integration, you know that actually it is a problem. If you never slow down to look at what you've done, you're only going to add new bugs while you're trying to fix the others.

When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly.

Everything is said. In the Linux kernel, changes are not done in a continuous way. Every non-minor change is going to have an impact on hundreds of different modules. The amount of work needed to accomplish these changes is absolutely insane. When a project like GNOME decides to phase-out an API, it takes several years before being actually replaced. In the kernel, it can simply happen between two minor releases, together with a rewrite of the whole ATA stack. The lolution Of course, Greg KH has a simple solution for you, in the What to do section.

So, if you have a Linux kernel driver that is not in the main kernel tree, what are you, a developer, supposed to do? Releasing a binary driver for every different kernel version for every distribution is a nightmare, and trying to keep up with an ever changing kernel interface is also a rough job.

No shit !

Simple, get your kernel driver into the main kernel tree.

Simple, isn't it? Unfortunately this is not going to happen while you are too busy adapting it for the constantly moving interfaces. This is quite feasible if you are writing a driver for an Ethernet network adapter, but for a video card this is another story, and for a virtualization layer? Well, the Xen developers have been struggling for years to integrate their technology in the kernel, and it is still far from done. No wonder why you get good drivers only for ethernet cards and not for 3D cards or even wifi chips. This doesn t go without other, worse consequences for users and distributors. Not everyone can afford to run Ubuntu, Debian unstable or Fedora, especially if they have simple requirements like not changing the whole system every 6 months. Corporate users using Debian stable, RHEL, SLES or Ubuntu LTS need a stable kernel that doesn t move, and that doesn t break everything when upgraded. The introduction of projects like DKMS to distribute drivers in a sourceful way while keeping them easily installable is a step in the good direction, despite being a workaround for a broken situation underneath. However these efforts are ruined by the constantly changing APIs that will go on requiring changes to the sources as well as the binaries. Why it can still work In fact, with such processes, you can wonder how it is possible that the system is actually usable. The answer is simple: while being smaller than many other projects, the Linux kernel has much, much more developers. A rough estimation shows that Linux has 2000 developers, many of which are paid full-time to work on it, to work on a 15 Mloc codebase. You can compare it with X.org, which has a few dozens of developers for 3 Mloc. Or with GNOME, 400 developers for 20 Mloc. With OOo, 150 developers for 10 Mloc. Yes, you need 10 times as many people to maintain the kernel code than for another comparable project. That's of course what happens when you keep them busy with a permanent refactoring of the code. This development method, while certainly having the advantage of bringing lots of innovation and fast integration of new features, is also driving away a very large portion of the open source community to work on rewriting Firewire stacks every 6 months. And as long as they are busy with this, they are not writing correct X drivers nor fixing bugs in the applications.

After Lennart posted his summary of Linux sound APIs, the debate heated up again between ALSA and OSS zealots. Both ALSA and OSS developers think their API is the definitive interface for sound support in Unix and like to bash each other, and tell how the other API sucks and how the others are spreading FUD. This is not only a sterile debate, but it is completely irrelevant. Do you know why? Because neither of them is a suitable sound API. Technical constraints, functional requirements and history make the ideal sound stack on Linux look like the following:

• a sound driver, consisting of a kernel module and if necessary a low-level library
• if configured so, a sound daemon which brings software mixing and network support PulseAudio finally kicking out all crappy alternatives
• a high-level programming API for use by developers.

Only the last bit should be of interest to application developers. Everything else is plumbing. When you develop a multimedia application or a mixer controller, why would you care of the insanely complex ALSA library or to make ioctls somewhere in /dev when GStreamer and Phonon provide you with high-level functions that can do it in a snap? When you want to insert sounds in your game or application, why would you care of those bits when, with SDL_Mixer or libcanberra, a single line of code is enough to decode and play the sound? If we want to see sound working properly under Linux, we need to keep the stack simple and to clearly separate the roles. In the end, this boils down to very simple things:

• Application developers must stop using ALSA and OSS. Both of them are completely unsuitable for the task, and it only serves the purpose of letting ALSA and OSS developers troll. Whichever application you are writing, there is one of the high-level frameworks SDL, GStreamer, Phonon, libcanberra, KNotify, JACK that is better.
• OSS and ALSA should stop trying to be application-level APIs. Instead of trolling about which API is better, they need to write drivers so that sound fucking works instead of asking users to use Windows to see their brand new computer output some sound.
• The plumbing layers (backends for the high-level APIs and PulseAudio) need excellent support for both ALSA and OSS. In the end, what matters is to have a driver for your sound card and to have it usable by all applications. Keeping the driver layer independent from the sound API is the only reliable way to keep things working over time. If someone else starts writing yet another driver framework, we will be able to make applications use it, instead of adding yet another ton of compatibility stacks.
• In the end, compatibility layers that cross layers in the stack must disappear. ALSA emulation for PulseAudio? OSS emulation with a LD_PRELOAD hack? Seriously, WTF? Applications should not have used them as a sound API, and we need to trash this crap eventually.

Please, guys, hold off a minute. You are developing drivers and you must be praised for that. Keep doing that well, and stop trying to invade applications. There are people who may not know how to develop a driver, but who obviously know better what a sound API should look like.

Computer security is generally defined as the following:

1. The data should remain available to those who need it.
2. The data should not be available to those who don t have the right to.

The critical software component to the first item is your well-known nightmare: the backup software. Backups are easy! In many corporate environments, here is how you ensure you have backups:

• you install the backup agent,
• you call/mail the backup guy, telling him the IP of the machine and what to backup,
• you wait for his call/mail telling you it s ok.

Isn t that cool? So little work to have all your data completely safe! Wait if you look more closely, there is something wrong here. Nowhere in this process did you specify credentials to the backup guy, nor did you add anything to identify the backup server. Or to say it otherwise, once you have installed the backup agent, the backup server has full access to your data. But you didn t even specify anywhere the IP of the backup server. So this means that anyone on the network has full access to your data. Which, while trying to make your data secure, actually brings a gaping security issue on your system. Security by nullity When you install a well-designed backup agent, like Bacula, you have to specify a password for each client and make this password known to the backup server. A simple authentication protocol ensures that only the backup server is able to backup your data. However, when you install, for example, the HP Data protector agent, it starts listening on a TCP socket and (no kidding!) binds it to a restricted shell which has access to a small list of commands. The backup server only needs to connect to this TCP socket and issue commands. While this has the great advantage of simplifying the development process of the backup server, such a software has a name: a rootkit. Several other proprietary backup software have different implementations, like RPC-based or proprietary protocols, but the basis remains the same: you connect to the TCP port, and you have a way to read absolutely any file on the system. Of course, there are so-called security options, that you can buy besides the disk agent or the nifty web interface. Yes, when you buy software that is critical for your security, the very lowest level of security that you d expect from any software not turning your box into a self-service is a paying option. In the end, what prevents your data from being available to anyone on the intarweb is the ultimate solution to everything(tm): the firewall. As people are not stupid enough to use the same backup system in the DMZ, you can t simply bounce from it after having used a hole in the lousy PHP code that is never updated. (Well, that will still work in many cases since people actually are stupid enough.) No, what makes it very fun is the backup network. The hackup network A tape library is expensive hardware, therefore you only want to buy one. However, when you have several departments or, in outsourced environments, several clients, you can t simply access to the backup agents on all these servers, because of all these evil routers and firewalls that are blocking you. The solution is trivial: use the second network card on all servers to connect to a backup network. The backup network is entirely managed by backup people who have no idea of network security, and is routed all the way down to the backup server. If you are lucky, some ACLs set up by the network guy who plugged the switch will prevent some parts of the network to access some others. In all cases, it s very likely that many people in the company (or from other companies!) have full IP access to all your private servers where sensitive data is stored. That includes access to your databases setup without a password, and of course to your highly secure backup agent. That generally also includes full IP access to the lousy maintained backup server, on which security updates are never installed. But don t worry. Your data is safe. Note: no, this is not a worst-case scenario. Such badly-designed software is widespread. Such practice is widespread in several companies I know.

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• J r my Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matth i
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

Russel, GUI front-ends to GnuPG, at least the default one in the GNOME installation, can of course store passphrases and other sensitive information in a secure manner. Or, to be more precise, they could if the trivial fix to #472629 was applied by the PAM maintainers.

Instead of trying to set a world record in the most stupid world record ever category, finally bringing software development to the same level as sausages, you can do something useful for your computer: download the latest epiphany package in unstable. Thanks to glandium s work, it fixes two notable regressions introduced by gecko 1.9, including the removal of the incredibly unusable certificate error page, also known as I want to be as cryptic as IE. As a side note, after spending a whole sunday trying to fix #393837, without anything remotely looking like success, I m very happy that the Epiphany developers decided to abandon Gecko. Maybe we will finally have a browser that is usable without needing a herd of maniac cultists to fix a bug. Something they won t do anyway they re too busy downloading the longest sausage in the world.

hadess asks:

You are in a mall when zombies attack. You have:

1. One weapon
2. One song blasting on the speakers
3. One famous person to fight along side you.

Rock and roll :

1. A chainsaw babe!
2. Disturbed Get down with the sickness
3. Denise Richards

There are obviously some things we need to remind if we don t want something like the OpenSSL debacle to happen again. It doesn t mean we need to throw stones nor to rush into changing our processes without thinking. However, there are already some things that should be obvious but unfortunately are not.

1. Shipping a giant diff.gz that contains all changes in one, putting security fixes, policy fixes, bug fixes, cosmetic changes and autotools files at the same level, is not something we should accept anymore. Improvements in the dpkg-source format are much welcome in this direction, but they are useless if maintainers don t use them. Neither a VCS nor a build tool will be able to know which line of the changes is related to which bug. Only the maintainer can.
2. Core packages should all have co-maintainers. This is pretty much stating the obvious, and is much easier said than done. The OpenSSL case is one of the best examples here: Kurt is not one of those who refuses help, but frankly, would you want to maintain that package? Having already maintained packages with messy code, upstreams not understanding at all the needs of a distributor, avalanches of security alerts and randomly-changing ABIs, I can tell you this is no fun like it can be to hack on a desktop environment or a device driver. The only sane reason to do this is that you need the package to work. The only visible result you get from your work is that programs are not randomly crashing.
   I have no magic recipe to propose so that more people help with such packages, and that s where we need to be really innovative. Cross-distribution teams, mandatory co-maintainership on a core package for each DD these (and all ideas I have not heard of) are the experiments we should start now.
3. Patching bad code leads to unpredictable results. What maintainer of a complex package has not introduced a new bug while trying to fix another one? Even when a piece of code is maintained by uncooperative developers, is not commented, uses arcane variable names or is impossible to understand without having contributed 3 winning entries to the IOCCC, it needs to evolve. And in these cases, it is only a matter of time until such things happen.
   Don t get me wrong: I m not trying to put the blame on upstream here. They have contributed very valuable code to the community and their work helped in the considerable widespread of cryptography. It s just that their code is not enough for our needs. If we can t patch it safely (and I m now convinced we can t), maybe we need to focus on alternatives and help them getting used by crypto-related packages. The code in GnuTLS and NSS is not necessarily better, but most (if not all) patches Debian needs to apply to them are build and portability fixes.
4. Unless Debian-specific, 1 patch = 1 bug in the upstream tracker. This should be obvious, but given the number of patches that are never forwarded, it doesn t seem so. You should not only give a chance for upstreams to review the patch, but you need them to track it, and you must give them the chance to review it anytime someone else stomps on a similar issue. If upstream does not have a bug tracker, they probably think their software has no bugs. Which means they are not trustworthy, and we go back to point 3.
5. We need to give more priority to security. Issues in the security team seem now fixed for good and they have been doing an awesome work. There isn t much left to do so that packages are all built with security-hardening features, but it still needs to be done. And there is much more to do so that we can provide out of the box a decent SELinux setup, or, if it turns out unrealistic to do, a decent system hardening setup using another framework. I know the SELinux zealots will jump on their high horses to explain that their framework is better, but the current situation where it is impossible for the average system engineer to setup a Debian-based MAC system is much worse than having a suboptimal setup that already works.

All in all, this incident has a great impact on Debian s image. If we don t react accordingly, adapting our processes and our system to match what our users expect from us and they expect the best they will turn away from us. With very good reasons to do so. Update : It seems OpenSSL does have a bug tracker. Thanks Kurt for pointing me to it.

Yesterday I stumbled about files and dead symlinks left in /usr/lib/python2.3/site-packages/ on my Sid box. These files/symlinks seem to have been shipped/created(?) by:

python-ldap python-cairo python-crypto kiki python-foomatic python-mysqldb
python-logilab-common python-egenix-mxtools python-numarray python-pygresql
python-imaging-sane python-imaging python-xml python-reportlab

Deleting /usr/lib/python2.3 (dpkg -S didn’t show any package relationship nor did I find something in /var/lib/dpkg/info/) and reinstalling the above mentioned packages did not recreate the files/symlinks. So it seems the directory can be safely removed. Maybe I missed some announcement or one (or more) packages need to be fixed. No time to examine it atm. Update This is known as Debian bug #409390. Thanks to Josselin Mouette for the information.

$ sudo dpkg --set-selections
[sudo] password for joss: 
dpkg hold