09 October, 2006


New Upstream Mondo Rescue Packages

I have just uploaded mindi and mondo 2.20 (version numbers are now the same for mindi and mondo).

This release marks a bit of a milestone in that we can ship the pristine upstream source in Debian for the first time because the busybox binaries were removed upstream. This together with the numerous bug fixes and stability improvements and combined with the fact that there are no revolutionary new features (despite the version number jump) made me decide to try and push the new upstream version into etch.

'Try' because although I've tested things quite thoroughly on both amd64 and i386, there is always a residual risk (one of my favourite alliterations ;-) ) of something bad slipping through. I think that taking this risk is justified, though, because 2.20 should be a definite improvement over 2.09. Bruno and I worked really hard to get this released in time for etch (Thank you, Bruno, for making my priority your priority!).

While testing, I found #389931, #389729 and #390653 (Thanks for your great help, Russ!). I've also found that archiving to tape doesn't work for me (still gathering more information, so no bug report yet), but it also fails with 2.09, i.e. there is no regression.

Main testing was performed on:
Oh, and this also contains the fix for RC bug #391127.

People seem to be using Mondo Rescue on 'vintage' versions of Debian which is presumably due to Mondo Rescue being disaster recovery software. So, I've made a change to post-nuke suggested by Augustin Amann (Thank you, Augustin!) to make people using the latest packages on sarge happier. I'm still in two minds about adding versioned depends on grep and binutils to make the life of woody (!) users a bit easier as well.

08 October, 2006


Freedom vs. Engineering, Part II

Ingo: What you describe is still an engineering problem, not one of freedom. If you can't do it yourself, you could find someone to do it for you. The point is that all the bits and pieces are freely accessible.
If you truly believe that the dependencies on tmpfs and udev should only be recommends, then I think you should file bug reports against the affected packages.

PS: I've had trouble with package dependencies as a user myself. I've also had a bug filed against one of my packages where I did reduce a depends to a recommends. So, I think I understand where you are coming from and generally agree that dependencies can be a chore. My point is merely that this is not about freedom but about engineering.

PPS: Seems like the PS turned out as long as the post. ;-)


RE: Being forced into non-freeness of choice by Debian packages

Ingo: Maybe I am a bit over-sensitive here, but whilst I feel your pain, your complaint is a pure engineering issue and has nothing to do with (software) freedom. You have all the freedom to take the software packages you mention and change them so you don't have to use udev or tmpfs.


Debian Voting Galore

I've crawled out from underneath my Mondo Rescue stone and looked in bewilderment at the various vote messages in my inbox. (It's not quite as bad, I've followed things to some detail passively on private and planet.)

The main questions seem to be:
Here is how I've voted and why:

[ 1 ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
[ 2 ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
[ ] Choice 3: Further discussion

[ ] Choice 1: Recall the project leader
[ 1 ] Choice 2: Further discussion

I think AJ is trying to improve things in Debian and that Dunc Tank is one attempt to do so. I believe it is a worthwhile attempt and can understand that he wants to be involved. While I also understand the concerns raised by other people, I believe that only time will tell whether Dunc Tank is in fact good or bad for Debian (I hope it's good). As far as the conflict of interest issue goes, I think it's less than ideal but the smaller evil to keep AJ as DPL whilst he's involved with Dunc Tank. I don't think AJ should run again if he stays involved in Dunc Tank as he is at the moment. I think that we need to consider integrating Dunc Tank into Debian if it is still alive and kicking in 12 months time. (Or to set up something similar as part of the project.)

[ 1 ] Choice 1: Release Etch even with kernel firmware issues
[ 2 ] Choice 2: Special exception to DFSG2 for firmware as long as required [3:1]
[ ] Choice 3: Further discussion

[ ] Choice 1: DFSG #2 applies to all programmatic works
[ 1 ] Choice 2: Further discussion

I believe that we should indeed release Etch as planned even if that means shipping a number of firmware blobs. I do not think that an ongoing exception is appropriate here. If this is still not resolved by the time we want to release Etch+1, let's have an other GR.

I am not sure what "program" really means in DFSG #2 - I've always taken it to mean the software, documentation, fonts and artwork that we ship as part of Debian. It likely has to comprise more than that, but I am convinced there have to be some exceptions:
I believe that these are just two examples of potentially many where 'free' versus 'non-free' are inadequate categories to think in.

Finally, the DFSG are part of the Social Contract and not the other way round. I like this because I value doing the best for our users higher than some rules. The DFSG exist to empower our users - I don't believe that removing firmware blobs from the kernel serves this purpose. That said, we should by all means strive towards free firmware, but I view this as more of an incremental, ongoing task of convincing vendors over time.

* I believe for example that the dispute over Firefox would be best resolved by Debian using the Firefox logo (and name) and the Mozilla folks dropping there requirement for patch review.

This page is powered by Blogger. Isn't yours?