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:
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.
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:
- sid, amd64, linux-image-2.6.18-1-amd64 (2.6.18-2), with NFS & AFS mounts, LVM, RAID1 & RAID5, onto NFS
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. ;-)
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:
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.)
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:
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.
The main questions seem to be:
- Is it good or bad to collect money to pay people for getting specific tasks done in Debian? Does involvement of the DPL in such an initiative constitute a conflict of interest?
- What is more important to the project, freedom of the content or hardware compatibility of the system shipped with Etch?
a65763d3-b1e2-4530-8ff8-aa5915274eb4
[ 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
49a98df6-2bd4-40c8-a559-7e15212dbd26
[ ] 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.)
c2d43675-9efa-4809-a4aa-af042b62786e
[ 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
22fc4edd-1f6c-454f-b204-6aa0bad0ce1d
[ ] 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:
- It defeats the purpose and very nature to modify licence texts. If people can change a licence at will, there is not much point having one in the first place.
- It equally defeats the purpose to modify logos (and thus their representations as files of whatever format). Logos allow users to recognise more easily what content is available. It does not make sense to allow modification or use in a different context of such a logo as it would then be more confusing than helpful.*
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.
