mindi-2.21~r1021-2 and mondo-2.21~r1021-2 are now on http://people.debian.org/~andree/packages/ with the following changes:

• petris works again during restore (self-inflicted, oh well).
• Restore of ISO images and friends should now work when gzip (i.e. '-G') is used.
• The network interfaces should be fine now when booting into a restored system for the first time.

Other than that:

• The crash in mondorestore when nuking from tape has disappeared. I have no idea what caused it or why it went away again, though...
  
• Kernel 2.6.18-3-k7 hangs when 'acpi=off' is specified (which is the default as per mindi's ADDITIONAL_BOOT_PARAMS, so restore fails with this kernel). I have filed bug #406809 which may or may not be related to #389931.
• The issue with booting a (NTFS) Windows partition failing after a restore appears to be normal as per the ntfsclone manpage:

  Usually, Windows will not be able to boot, unless you copy, move or restore NTFS to the same partition which starts at the same sector on the same type of disk having the same BIOS legacy cylinder setting as the original partition and disk had.

• I have tried a few things playing with parted and ntfsresize, but so far the only thing that works reliably in order to get Windows to boot is resizing the partition using gparted. I still have to figure out what it is that gparted does differently. (If you know, please tell me!)
  

Off to bed now so that I'm fine and dandy when I pick up Bruno from the airport in the morning for lca2007. :-)

Preliminary Debian packages for Mondo Rescue 2.2.1 are available at the usual place: http://people.debian.org/~andree/packages/. (r1021 is the SVN revision of the actual 2.2.1 release.)

The new version comes with quite an impressive list of fixes and enhancements as can be seen on the Mondo Rescue website. The new '-G' option which allows for using gzip as the compressor is my personal favourite as it really speeds things up! Also, I've finally gotten around to fixing #222065 and there is no more unsolicited creation of directories in /var/cache anymore (neither submitted upstream yet).

Unfortunately, there are a few issues:

• Links in directories that actually are links themselves are not resolved correctly (fixed in the Debian package.).
• nuke restore from tape makes mondorestore crash (at least on amd64). The workaround is to use automatic or interactive mode.
• Windows 2000 does not boot after a restore (at least on amd64). The data is restored but there is something wrong with how fdisk creates the partition (I believe). This actually also happens with 2.2.0 as well, so it is not a regression. I have to look into this more. The workaround is to use gparted (or similar) and resize the windows partition/filesystem by a few MB.
  
• petris doesn't start when restoring (again at least on amd64). Surely the most minor issue I noticed so far...
  

Anyway, apart from the above, things seem to be ok. Give it a try if you like! If you do find more issues, let us know via the mailing list and - even better - send a patch. ;-)

Other than that, (belated) Happy New Year to everyone! :-)

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. ;-)

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.

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:

• 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?

Here is how I've voted and why:

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.*
  

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.

Bug #385790 prompted me to set up an AFS client on my sid installation. This is something I hadn't done since I left uni almost nine years ago. Back then it was a bit fiddly to get the Transarc AFS client for Linux to work if I remember correctly.

Things have quite obviously improved since then. The following is all that was required (with some helpful information provided by the submitter - thanks, Kevin!):

• install packages openafs-modules-source and module-assistant
  
• follow the instructions in /usr/share/doc/openafs-modules-source/README.modules, i.e:
• module-assistant prepare openafs-modules
• module-assistant auto-build openafs-modules
• dpkg -i /usr/src/openafs-modules-.deb
  
• install package openafs-client and configure like this:
• leave AFS cell of workstation at default, i.e. local domain
  
• leave cache at 50000 kb
• leave DB server host for home cell blank
• answer 'Yes' to 'Run Openafs client now and at boot?'
• if this doesn't work, run dpkg-reconfigure openafs-client like this:
• leave AFS cell of workstation at default, i.e. local domain
• leave cache at 50000 kb
• answer 'Yes' to 'Run Openafs client now and at boot?'
• answer 'Yes' to 'Look up AFS cells in DNS?'
• answer 'Yes' to 'Encrypt authenticated traffic with AFS fileserver?'
• answer 'Yes' to 'Dynamically generate the contents of /afs?'
• answer 'Yes' to 'Use fakestat to avoid hangs when listing /afs?'
• leave DB server host for home cell blank
• answer 'Yes' to 'Run Openafs client now and at boot?' (again)
  
• ...and restart openafs-client afterwards

(The need to reconfigure may be a bug, not sure.)

In summary, OpenAFS and Sam Hartman's packaging effort make AFS a breeze to install on Debian!

Now all I have to do is find the time to fix the bug. ;-)

[Update] Important detail I forgot to mention: Open port 7001 on your firewall for UDP.
[Update] Added what to answer, i.e. 'Yes'. Doh.

I have some hopes that mindi 1.20 and mondo 2.20 will be released sufficiently early for the freeze (i.e. soon ;-) ). To help ensuring that things are indeed in good shape at release time, I thought, I make some pre-release packages available.

Please test and send feedback - good or bad!

I've done some testing myself on amd64/DVD and i386/NFS with good results apart from the missing fixes for #320152 and #379966 - they will be in upstream or the final package versions though.

Just noticed the new native 2.04~rc2 OpenOffice packages for amd64 in unstable. My first impression is: Wow, I've never seen writer starting up so fast! (Way under a second.)

Congratulations to the Debian OpenOffice.org Team!

...is what Mike Connor appears to be suggesting here. As far as I can tell, this has already happened - the way I interpret #8 of the DFSG, it is not just about Debian and derivatives but absolutely everyone including Osama Bin Laden and George Walker Bush and even John Howard. ;-)

Seriously, though, I perfectly understand that Mozilla needs to protect its brand and they certainly have every right to do so. And we have every right to change the name and modify the code without asking anyone for approval. A right that we will have to exercise by the looks of it. How about 'freefox' (probably too close) or the 'browser otherwise known as firefox', short 'bokaf' (anyone?).

I believe that Mozilla is doing the free software movement a disservice when they are as hard-nosed about their brand as it appears they are. They certainly need to put mechanisms in place to protect themselves from the Dr. Evils of the world. Debian most definitely does not belong into this category (neither do Redhat nor Suse nor any other Linux distribution I can think of). So why not just let sleeping dogs lie?

Eric Dorland and Steve Langasek are my heroes for remaining calm and on topic in the discussion.

I've finally uploaded mondo-2.09-3 packages which contain the changes to get Mondo Rescue working with AFS to fix #385790. I should have communicated better with Bruno because he has done some work in parallel on this. We have come largely to the same conclusions, though, which is always reassuring.

2.09-3 also has some more changes done in the post-nuke arena. I felt that because it is now an integral part of the Debian package it needed some more love. Changes are:

• Log the fact that no post-nuke script was found during restore.
• Perform after nuke steps even if we dropped back to interactive mode because of issue with mount list.
• Ask user after nuke to wait until s/he is returned to command prompt before rebooting.
• Use run_program_and_log_output() instead of system() to get output of post-nuke logged.
• Output screen messages about post-nuke.

With these changes added, post-nuke behaviour is still not perfect but probably good enough for now. Hopefully, Bruno agrees and accepts the changes upstream.

Finally, I've managed to get hold of a VXA-1a tape streamer. It's IDE which sucks because Debian removed ide-scsi from the standard kernels a while back, so the vxaTool doesn't work (yes, I know how to compile kernels, but I like to run a standard environment so that I can pick up on and reproduce issues). Then again, it's just for testing anyway and I can report that I've successfully done test runs with Mondo Rescue using it.

Speaking of testing, mondo-2.09-3 was tested:

• on sid amd64
• running kernel 2.6.17-2-amd64 (2.6.17-9)
• using DVD and tape (!!) as backup media (NFS is still stuffed)

(mindi-2.09-2 which I uploaded a few days ago was basically tested the same.)

SAP has supported Linux for many years. Debian, though, is not one of the supported distributions which I find unfortunate because I am an SAP consultant and a Debian developer. ;-)

I have manually installed an SAP Testdrive system on Debian from RPM packages years ago which was very painful. Gregor Wolf's instructions on SDN make things look much less daunting for a regular install. Hopefully, I'll have a chance to try this in the next couple of months...

Mark's take on what Debian's strengths and weaknesses are makes for an interesting read. The way I interpret it, he wants us to be the plateau that other parties can put their spikes on top of (to use his symbolism). He mentions etch towards the end as one of those spikes, but essentially suggests we focus pretty much all our energy on sid because this is what we are good at and where our passion lies.

I beg to differ.

I firmly believe that Debian must remain relevant as an end-user distribution. Not only because essentially this is what our Social Contract is all about but also because without (relevant) releases I very much doubt we'd be able to keep the momentum and attract (or even keep) good people as (new) developers.

From Mark's point of view, his line of argumentation certainly makes sense: The better sid, the better a derivative like Ubuntu. From our point of view I believe it doesn't.

And by the way, I do run sarge on my machine as "production" environment and I am thus much looking forward to the release of etch.

That said, I do think that Ubuntu is better than Debian in some ways (but certainly not all), so on this I agree with Mark. I am just not sure that this really has to stay this way. Competition is good. ;-)