However, that patch isn't even in the mainline kernel yet either. This puts a strain on the ubuntu kernel team having to maintain a separate out of tree patch. However, I'll leave this decision to them. For now, I'll tag this as 'hardy-kernel-candidate' so that we retarget this report against the upcoming Hardy kenrel release. However, against linux-source-2.6.20 this bug does not meet the criteria for a stable release update and is being marked as Won't Fix. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates . Thanks!

I've opened a new task against the actively developed kernel which is currently the Hardy Heron kernel. However, please remember as I noted before that it is a lot of extra work for the Ubuntu kernel team to maintain out of tree patches. As such they usually require evidence of upstream submission before considering to maintain community patches locally. Thanks.

This is a huge invasive patch that touches core block layer, core scsi, core libata and core ide subsystems. That's way too scary for us to consider maintaining ourselves. The fact that the patch has been floating around through several kernel releases also concerns me (why isn't it upstream?).

Declining on this basis. I suggest working to get this patch upstream.

Evgeni Golov (the package maintainer) wrote:
> not a bug in hdapsd, needs support in the kernel

That's fine, but until the situation changes, with either the kernel providing support or hdapsd no longer needing it, please consider either removing the hdapsd package from Ubuntu, or otherwise modify it to make it clear to unsuspecting users that the package is only usable by people maintaining their own kernels. At the moment, the presence of hdapsd seems at best misleading, as the code is useless without kernel support, as indicated by the package maintainer.

Well, exactly this hint is written in /usr/share/doc/hdapsd/README.Deabian, which should be the first place to read if some app does not work out of the box, but I could add a hint to that file on startup though.

About removal: Uh, I didn't upload the package to Ubuntu, I don't know anything about removal from it either - can you give me a pointer here?

> this hint is written in /usr/share/doc/hdapsd/README.Deabian, which should
> be the first place to read if some app does not work out of the box

Ubuntu is trying to deliver linux to a larger population of users. A typical problem throughout the Open Source world is recognizing and coping with a transition from a small population of computer-skilled participants able to dig for information to a larger unskilled population that expects everything to just work. No one outside of the cognoscenti is going to go digging under /usr/share/doc, unless explicitly told to look there. Nor should most users look there, given the nature of the material generally present (changelogs, TODO files, copyright notices). At best, we'll train users to read man pages.

In any event, don't worry about removing the package. If you "add a hint to that file on startup", and to the package description, that should indicate to most users that the feature won't be present, and point the rare few (a tiny fraction of a percent) who can handle the patch to what they have to do. And we can hope that someday either the kernel support will be mainline, or the daemon won't need it.

> Ubuntu is trying to deliver linux to a larger population of users. A
> typical problem throughout the Open Source world is recognizing and
> coping with a transition from a small population of computer-skilled
> participants able to dig for information to a larger unskilled
> population that expects everything to just work. No one outside of the
> cognoscenti is going to go digging under /usr/share/doc, unless
> explicitly told to look there.

Hum, should we remove /u/s/doc then ;)

> Nor should most users look there, given
> the nature of the material generally present (changelogs, TODO files,
> copyright notices). At best, we'll train users to read man pages.
>
> In any event, don't worry about removing the package. If you "add a
> hint to that file on startup", and to the package description, that
> should indicate to most users that the feature won't be present, and
> point the rare few (a tiny fraction of a percent) who can handle the
> patch to what they have to do. And we can hope that someday either the
> kernel support will be mainline, or the daemon won't need it.

I think adding a hint to the init script only should be enough.
IMHO hdaps is something "advanced" even when the kernel would have the
UNLOAD support, as the vanilla kernel has many problems with newer
hdaps chips (this is solved by tp-smapi (not in Ubuntu)) and thus hdapsd
might not work correctly sometimes.

However, I'm trying to get multidisk support for hdapsd and will then
upload a version with a louder "RTFM ;-)" in the init script.

Could you forward this upstream? It would be great to have, it saved all my data on my Thinkpad before when I dropped it. Also, more and more Laptops have similar technology. While I do not know whether e.g. the Apple system works the same, it might be easy to implement.

According to http://www.thinkwiki.org/wiki/HDAPS#Kernel_patch, the current kernel will hang with the best-currently-known hdaps patch. But, also, someone seems to be working on getting hdaps into the mainline kernel. When that happens, Ubuntu will have it.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.