Archive for the 'Debian' Category

Page 2 of 8

d-i SCM FAIL

From the Bits from the Debian Installer team mail to d-d-a:

It has been decided that, in order to not slow down the development processes, D-I SVN should be branched when the work on preparing a release starts. Even if SVN doesn’t make the process very easy, changing the VCS we use is currently not an option we prefer.

SVN, branching, d-i. There’s no word to describe how painful it is to work on d-i using SVN. d-i is big, SVN is slow in about everything it does. Now add branches to the mix.

That mail left me very disappointed; first because I thought switching to git was sort-of planned for after the release of Lenny, and now it’s off the table, second because some things in this mail are just wrong.

Oh well. No d-i for me, I guess, then.

mt-daapd EPIC WIN

I’ve been doing some code lately, fixing things here and there, and over the last few days gave mt-daapd some attention.

First, I was reported a segfault of mt-daapd when reloading web pages too fast. Surprisingly, it turned out to be a stupid omission in a simple routine and it is hard to hit without disabling the cache in the browser.

Now, I just fixed something that’s been bugging me for a while: mt-daapd did not handle Avahi daemon restarts, leading to mt-daapd becoming invisible to clients relying on mDNS until you restarted it.

And, wow, that went a bit further than expected. As I expected, the simple piece of code needed to handle that wasn’t there. But still it did not work, as it turns out the event loop for the Avahi polling wasn’t being run. Replace stupid code reinventing the wheel by the Avahi-provided wheel and there, it works. But not when run as a daemon (aka foreground only). Well yes, starting the thread before daemonizing isn’t going to work well, so fix that. EPIC WIN \o/

As mt-daapd’s upstream is not active anymore I’m accumulating fixes for mt-daapd in the Debian package, to the point I’m starting to consider setting up a git repository somewhere with those fixes and possibly some more code rework if I feel like it.

This project should remain open and openminded

David,

I’m not saying it lightly: the end goal is censorship, no matter how nicely you try to put it.

The goal is to discourage people from posting. They call it “peer pressure”, which is nothing else but the politically correct equivalent expression for “intimidation”. The end result is censorship.

The idea of censoring the mailing lists has actually been mentioned very clearly in the recent discussions on -devel, and I never thought it would go past that, but it’s actually happening. By the way, this could actually morph into a shitty karma system that wouldn’t let you post past your monthly allowance and “credit” “earned”. How’s that for you?

You refer to those +1/-1 mails; I find them silly, annoying, useless and a waste of bandwidth and CPU time. That used to be called a “me too” and generally despised and frowned upon.

If you actually want to score posts or posters, get a decent MUA and set up its scoring system the way you like. But keep that to yourself.

As Aigars told, there are mail to web forum “gateways” (more like rendering engines for a mail archive, actually) that will present mails to a list in a crappy web forum of some sort that will come with all kind of crap like scoring, karma and whatever.

There’s an essential difference between web forums and our mailing lists, though: forums of this kind use nicknames all over the place, our mailing lists use real names. There are privacy issues involved, and I’m not giving up on that, either.

You want to stop flamewars? Stop replying, especially to tell how intolerable it is and other shit. Just let the damn thing die already. Funny how the well-meaning people are feeling “harassed” on the mailing lists when they, themselves, are harassing people they disagree with.

We don’t all have the same views, culture etc. We’re not all friends, and we probably never will be. Guess what? It’s OK! Get over it and work with each other, because that is what we are here for. If you (general) can’t get over it, I’m afraid this Project is not the appropriate place for you.

Imposing a monoculture of politically correct crap is not an answer to the perceived “problems”.

Free software yes, free speech no thanks.

This proposal leaves me speechless. The replies even more. The sole fact that there are positive replies kills me.

I’m really starting to think that this Project could do a lot better without some people. Now if you’ll excuse me for a sec, I have a urgent need to vomit.

Reality check, people. Get back on the ground.

On the firmwares/Lenny vote

Christian notes, and rightly so, how much this vote sucks, for various reasons.

There are too many viable options (as far as releasing Lenny is concerned) and that makes it tricky to vote in a useful way. And Christian got bitten by it: do not vote by ranking all options 1 to 7, or this vote will end up being our most EPIC FAIL to date. With that many options, the votes will end up diluted and who knows what the result will be.

For this vote to succeed and be meaningful, it’s pretty much required to rank several options equally. That is, and provided it matches your views, ranking the “Let’s release Lenny and give the finger to the zealots” options at the same level.

Be careful when voting on this one. IT’S A TRAP.

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.