[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Looking for advice on openafs for sarge



Hello folks,

The version of OpenAFS in testing has an annoying init script issue that
can also cause it to fail to start under some circumstances, and I'm
seriously considering a testing-proposed-updates upload to fix that:

  * Handle modules named either with or without the .mp extension on SMP
    hosts.  (Closes: #305389, #307280, #307797)

Judging from the bug reports, it caused a fair amount of confusion and one
problem at the important severity level because it can hit people during
upgrades.  See the log for #305389 for most of the analysis.

However, I'm not quite sure what to do about the problems the version in
testing has with newer 2.6 kernels (#303495) or with 2.6 preempt kernels
(#308399, #304040).  (See below for discussion on the severity and tagging
of #308399.)  These bugs are fixed in upstream 1.3.82, but the diff
between that and 1.3.81 is, er, extensive.  I took a look at pulling
specific deltas from upstream just for these problems, but I'm not sure
I'm correctly identifying which ones I'd need and the diff is still likely
to be sizeable.

So far as I can tell, these bugs do not affect the 2.6 kernel supplied by
Debian in sarge.  I'm not sure, however, if the preempt problems might
affect the sarge kernel if built with preempt.  These problems will cause
serious difficulties for anyone using a newer 2.6 kernel.

#308399 is severity grave at the moment.  I tagged it sid, which is sort
of true and sort of not -- the bug is present in the package in sarge, but
is not triggered by the sarge kernel.  It only affects preempt kernels,
but certainly the system not shutting down and unmounting file systems
cleanly is a serious problem if one happens to run into it.

Given this, should I consider a backport of 1.3.82 for sarge?  Or try to
pull individual deltas (in which case, testing is going to be *very*
important to make sure that I didn't miss some code dependency when
cherry-picking patches) and still end up with a fairly sizeable diff?

Any advice on this would be welcome.

Regardless, 1.3.82-1 will get uploaded to sid, which will provide some
testing for upstream.  The sid version of the package is not suitable for
sarge due to extensive packaging fixes, but those were almost entirely
contained in the debian/ directory and shouldn't affect the merits or
flaws in the 1.3.82 code itself.

If I do prepare a testing-proposed-updates upload for sarge, with or
without trying to backport 1.3.82 fixes, I'll probably also include:

  * README.modules: Add documentation for module-assistant and recommend
    it when using Debian kernels.  Mention divergences from upstream in
    module naming.  (Closes: #253168)  Emphasize that the kernel source
    tree used for make-kpkg must be identically configured to the kernel
    the module will be used with.

  * README.Debian: Document that the client cache partition must be ext2
    or ext3 and that XFS and ReiserFS will not work.  upserver and
    upclient are now provided.  Provide some information about why
    kaserver is not provided.  (Closes: #249315)

as documentation fixes; I expect that will be uncontroversial.

Thanks in advance for any advice.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>



Reply to: