Archive for the 'Debian' Category

Page 3 of 8

DPL on the developer status proposal

Our DPL has spoken to The Register about the developer status proposal and how we’ll handle it after the release of Lenny.

Too bad he hasn’t told us anything about it on our mailing-lists yet. Maybe The Register could create a Debian category so we can more easily look for what our DPL says?

(If anyone asks, I’m a Reg reader myself)

On Debian, backroom decisions, unilateral decisions and cowards

Over the past four years (since the infamous Vancouver meeting, roughly), it seems it has slowly become an acceptable practice in this project to come up with backroom decisions instead of coming up with ideas and proposals and building a consensus before moving forward.

A number of projects and changes have been brought forward this way since then. No need to make a list, I think everybody remembers the flamewars pretty well.

Fact is that Vancouver and dunc-tank (only to name those two) have changed the Project in some ways. People resigned, others changed their level of involvement, but more than anything else, there’s been a split in the Developer body. Something broke at some point, and the spirit just isn’t there anymore.

So, we’ll never recover to a state comparable to what Debian was before Vancouver.

When you thought things were bad enough already, they just got worse. We now have people coming up with decisions all by themselves. No asking anyone about it, even in backroom meetings, or only to fake it and ignore their opinions on the matter.

It looks bad, and it is. Talk about communication problems. Talk about power-hungry people.

But let’s talk about cowards, too. The cowards that are bitching about what’s happening but won’t raise their voices on the lists because they’re afraid of looking bad if they disagree with the “big boys”.

We are a free software project. Free as in freedom, free as in speech. If you’re not making use of this freedom, you’re just going to lose it; just like in the “real world”. Actually, you’ve lost some of this freedom already.

If you’re not voicing your opinion, why do you have one in the first place?

Digi AccelePort drivers updated to 1.3-14

Digi released a new beta release of the dgap drivers a couple of days ago, notably fixing the build issue (TTY flip buffer) with newer kernels.

They now ship two versions of the driver, one suitable for 2.4 and 2.6 kernels up to and including 2.6.26, and one for kernels 2.6.27+. The appropriate version will be picked up automatically when the module is built, of course.

APT source line, unchanged:

deb http://debian.technologeek.org/ etch non-free

The packages are still built for Etch; Sarge users should stay with 1.3.6 (unless running a newer kernel, but then a rebuild of the userspace tools is required).

Feedback at the usual address.

We release when it’s ready

Answer to anybody asking about the Lenny release.

Testers needed for mt-daapd in experimental

I’ve just taken over the maintenance of mt-daapd and gave the package and code the thorough cleanup it so badly needed.

I’ve fixed everything that was reported againt mt-daapd and a bit more. No miracles though, the code is still not great and there still hasn’t been an official upstream release in … years?

It works for me as well as it did before, so hopefully I’ve fixed bugs and did not introduce new ones in the process. Now that’s up to you, mt-daapd users, to tell me :-)

Go grab mt-daapd 0.9~r1696.dfsg-1 in experimental and enjoy.

aurel32 now a PhD

AurĂ©lien JARNO defended his PhD this morning, and I’m just back from attending his defense.

He did an incredible work designing and implementing a simulator for the MUSE instrument that will equip the VLT in 2012 (“first light”) and is being built now.

People working in the field are very impressed by the work he achieved, and I must add that it’s even more impressive when you know all he did in Debian and various other projects at the same time. Wow.

Congratulations Dr. JARNO!

rEFIt finally updated in Debian

After nearly two years stuck with rEFIt 0.7 in Debian, I’ve uploaded rEFIt 0.11 to unstable today.

There’s been a bit of work done on the package, on rEFIt itself and on the tools that come with rEFIt. I’ve also added some (useful, I hope) documentation.

This version of rEFIt supports all Intel Macs to date.

rEFIt in Debian comes with gptsync, both as a Unix command-line tool and as an EFI application. It’s the only tool shipped in the package. The other tools available in the rEFIt binary distribution by upstream (the EFI Shell and utilities) come from the TianoCore project and aren’t available in Debian. See the README.Debian in rEFIt if you want the full story.

Also rEFIt in Debian lacks the machine shutdown feature for now; this feature is part of the EFI 1.10 spec which isn’t supported by gnu-efi yet, though I have also worked on updating gnu-efi for EFI 1.10 and sent this upstream. Filesystem drivers are also affected by this and, as such, are unavailable too.

If you’re interested in the gory details, see the changelog and patches.

Obligatory loldebian post

Because a lolcat is worth a thousand jokes, here are 3 of them.

Thanks to rominet for coming up with those :-)

Of course it’s far worse. Did I tell otherwise?

Dear Daniel,

It looks like you are referring to my post, though you got my name wrong so that wasn’t immediately obvious.

Of course this is far worse than the 2003 compromise in terms of the direct, known and quantifiable impact it has on our users. I don’t think I stated otherwise, so I hardly see why your post starts with “I disagree”.

Making code valgrind-clean …

NOT.

Also see #363516.

Genius.

Now regenerating every single SSH key, SSL certificate and whatever else I can identify that’s been produced by one of the Valgrind-clean openssl. Also expiring and changing every single password I’ve ever typed in a vulnerable SSH session (be it at login or in the session).

Updating the packages on the machines was fun already.

Worst Debian day ever since the 2003 compromise. And that was a BAD one.

I guess we need a new openssl maintainer, we obviously cannot trust the current one(s).