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

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

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?


   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

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.


    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: