Re: Neverending Story Part 2: LSB and woody
Martin Schulze wrote:
[Matt Taggart]
So the older versions of the 1.3 test suite didn't test for the
OpenI18N stuff but newer versions do. If we don't want to deal
with these patches for a woody point release then we might be able
to run the older version of the test suite. However the clock is
ticking as that version will expire at some point now that the new
one is out. Details at
http://www.opengroup.org/lsb/cert/docs/testsuites.html
It's my understanding that these older test suites have expired.
. If a different upstream kernel version is required than there is
currently in woody, for any architecture, this poses a threat and
cannot be fulfilled. In such a case we need to announce
people.debian..org/~ajt/lsb/ as additional resource if people want
to run an LSB certified system.
I would imagine this will only be a practical problem for archs with a
kernel version less than 2.4.18. We might want to test some of the
other potentially certifiable archs to make sure my patch didn't miss
something. I would only anticipate missing something in the kernel;
glibc is also a possibility, but it's remote.
. http://hackers.progeny.com/~licquia/lsb/tjreport-woody.200311032211.txt
assumes that only one test really failed.
As I mentioned, that test is a bit weird; it doesn't fail consistently.
It seems that running the test on a fast machine mostly takes care of
the problem, which makes me suspect a race condition somewhere.
My proposal: Packages may go into woody all together or not at all,
they won't go in partially. All patches need to be present in the
sid version as well.
alien: Ok, unstable ok
bash: Ok, unstable ok
cpio: Ok, unstable ??
Sarge and sid cpio pass. Since the sum total of the change is a call to
setlocale(), and since omitting that change would make cpio fail, I can
only conclude that the patch is in sarge/sid.
glibc: Ok, unstable ok
grep: Nah, this patch is way too long. Is this the only patch
required for Li18n or is it not required for Li18n tests but
only LSB 1.3? This also breaks translations of grep
partially, if existing. unstable ??
Sid and sarge grep pass the LSB.
I may be able to work over the patch to make it more acceptable, but I
wouldn't want to invest the time if there's no hope.
kernel: Ok, but would have to be applied to all kernels *sigh*,
unstable ok due to v>=2.4.20
pax: Ok, unstable ok
sed: Not ok, need a cleaner patch to review, unstable ok
I will work on cleaning up the patch.
Also: sed and grep mention openi18n in the changelog. Are these
the only changes required to pass the Openi18n tests? Are these
changes not required for the normal LSB 1.3 test suite?
The changes are required for openi18n, and the two utilities pass the
LSB after the changes are applied. To my knowledge, the only problems
with grep and sed are related to openi18n.
Open questions:
1. Are grep and sed required for LSB 1.3?
Yes. With a few exceptions, the openi18n stuff is now required by the LSB.
2. Are grep and sed required for Openi18n?
Yes.
3. Are there no more packages that need to be fixed for Openi18n?
Technically, yes, but we have been granted a waiver for the other
utilities. My test results should list the other utilities with problems.
4. Need a fix for grep translations (easy)
5. Is the cpio adjustment present in unstable?
Yes, as cpio in sid/sarge passes, which it would not if setlocale() were
not called.
6. Which architectures are covered by LSB and need an adjusted
kernel?
I think Mats answered that question. As I mentioned before, my patch
should fix any architectures with 2.4.18, and no patch should be needed
for 2.4.19 and later.
Conclusion:
Assuming that cpio is ok, sed and grep are either not used or will
be ok, it seems that that we can make woody LSB compliant ***IF***
all relevant kernels for all relevant architectures and all kernel
source pacakges will be adjusted.
This is a large if, since it took me more than a whole month to
get the kernel fixed security wise. I will not pester the people
again just for an LSB adjustment. And I will also run amok and
hunt down the first person who uploads an LSD adjusted kernel
package that overwrites a security update.
There are benefits to LSB certification even if not all architectures
can be covered. If some architectures look to be too much trouble, is
this a show-stopper for all archs?
As I said before, either all packages go in together or not at
all. This means that some staging area is required. For this,
concentrate on kernel packages. Assuming alien, bash, grep, cpio,
pax and sed will be built in time by the buildd network, they can
be added late. It's also unlikely that they contain security
updates so that their update would interfere with security. It's
totally different for the kernel, looking at CAN-2003-0681,
CAN-2003-0985 and CAN-2004-0077.
My repository is still available for initial staging of the non-kernel
work, or we can move everything somewhere else if preferred. If the
latter, I can make my updates to grep and sed available there when
they're ready.
Also please note that we cannot update the kernels in stable due
to broken modules dependencies and binary incompatibility introduced
by the ptrace fix. This does mainly affect i386 since no other
architecture makes heavy use of modules.
I'm a bit confused by this. Does that mean that my kernel patch is out
for i386, or just that we can't move to 2.4.19+?
PS: [1] Jeff, I hope you don't mind quoting your personal mail on this
subject publically.
Not at all.
Reply to: