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

Neverending Story Part 2: LSB and woody

I've read older mails on this issue and here's the outcome.[1]

LSB Compliance Requirements

Modified packages:
    alien, glibc, kernel, pax

    bash, cpio, glib, grep, kernel, lsb, pax, sed


  ajt: The alien changes have been in testing and unstable for a
    similar amount of time.

  Matt: Yeah these are probably fine.

  Jeff: Woody alien has several bugs in its handling of permissions
    and scripts when converting RPMs, which make it impossible to
    properly install the test suite RPM.  This results in many test
    failures.  These bugs are fixed in alien 8.36, and the test
    results I've been generating have been from the test RPM as
    installed by alien 8.36 on woody.  No rebuilding or other
    modifications have been necessary to get the alien package as
    currently available in sarge to install on woody.

    There may be good reason to use alien 8.37 from unstable, as it
    fixes a bug I've noticed in testing sarge.  But the results I've
    been generating have been with 8.36, so I think that can be used
    as a minimum.


  Jeff: Bash 2.05a does not support the [[:hyphen:]] glob, which
    causes one test to fail.  Because the changes between 2.05a and
    2.05b are too great, I felt that a custom patch to just add the
    support was the best option.  This is the only patch I have
    written, although support for the glob does appear to be in 2.05b.


  Jeff: This is a very large patch, but the actual change is minimal.
    Nearly all of the patch amounts to changes in configure caused by
    a single configure.in change to check for a single additional
    header file.

    The actual code in the patch only adds a call to setlocale() at
    the beginning of main(); the configure changes are only necessary
    to make sure that setlocale() is supported.  If we were to make
    our patch assume the presence of setlocale() and thus not require
    the autoconf change, the patch could be made extremely small and


  ajt: The glibc changes are in unstable and upstream CVS, and have
    already been tested in released versions of Red Hat, SuSE and
    probably other distributions.

  Matt: Again there may need to be additional changes for the new test

  Jeff: The patch was written by Anthony Towns, and is adapted from a
    patch from SuSE.  The patch has been around for quite a while, and
    has been released as part of at least one production distribution
    (SuSE).  The largest portion of the patch involves a test case
    added to the test suite.

    The bugs fixed all relate to incorrect error handling.  Most are
    improper errno values, although one relates to an incorrect return


  Jeff: This patch adds wide character support to grep.

    It is a large patch.  Most of the changes have been accepted
    upstream; the ones that still haven't are available at
    Any LSB 1.3 certified distribution will have incorporated this
    patch.  As such, it should be well-tested.  Additionally, it
    passes the LSB tests.  Finally, I have run the test suite in the
    grep source; while it does not pass, the original source doesn't
    pass either, and the results of the patched source are identical
    to the results of the source currently in woody.


  ajt: The kernel changes have been tested everywhere that runs

  Matt: Is the kernel going to be updated for the next woody point
    release?  Some of the tests only pass with 2.4.20+ IIRC

  Jeff: Only the latest patch file is needed
    (lsb-kernel-patch-2003-10-28).  This kernel patch fixes LSB
    compliance issues with 2.4.18 that are also fixed in later
    kernels.  I believe all issues are fixed in 2.4.19; they are
    definitely fixed in 2.4.20.

    Thus, we could release 2.4.19 kernels (or later) to woody in lieu
    of this patch.  There are several benefits to this approach,
    especially considering that it would not trigger a kernel update
    for those people who don't care about the LSB issues.  I have
    heard, however, some reluctance to release newer kernels into
    woody, which prompted the creation of this patch.


  ajt: The pax changes are straightforward and have been tested in
    both testing and unstable for a couple of months.

  Jeff: This patch backports a fix from sarge's pax to woody.  The bug
    number is 139943.  Again, this is a well-tested fix, having been
    released in a number of distributions, and having been a part of
    Debian sid for over a year.

    Since pax is mostly used for compliance with POSIX/LSB anyway, not
    having a compliant pax is tantamount to not having pax in the
    distribution at all.


  Jeff: Large portions of this patch are the result of autoconf and
    automake, where the real changes are actually quite small.  In
    addition, some of the code changes amount to whitespace changes,
    and in one case a .orig file generated by patch was included in
    the patch.  If patch size is a concern here, please let me know; I
    will be working on removing as many unnecessary changes as I can

    The patch has been integrated into sed as of 4.0.1.  It has also
    been integrated into several shipping distributions; any LSB 1.3
    certified distribution will have needed either this patch or sed
    4.0.1 to pass certification.  It also passes the LSB test suite
    and its own internal test suite (which is required for the package
    to build at all).  This should serve as evidence that the patch
    has been well-tested.


  ajt: Also, the nice() issue -- which does have the potential to
    break things -- is irrelevant: we don't need to make that change
    for LSB compliance.

  Matt Taggart: These are a year old so should probably be reviewed to
    make sure they are still relevant or don't need additional
    updating for LSB 1.3.(As you mention below)

    The lsb package was also just updated for 1.3, which adds a couple
    archs , a missing dependency on pax, and some other stuff.

    The separate OpenI18N standard was merged into the LSB at 1.3 so
    there are additional requirements that are being tested for
    now. These are mostly requirements on the commands provided by the
    LSB and _will_ require patches to fix. I haven't yet file bugs
    against these packages but will ASAP. I know Red Hat and SuSE have
    been adding these patches to their in development releases in the
    last few weeks. I do not know if the patches have been accepted
    upstream yet. There's a rumor that they affect performance.

    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 [lsb package] doesn't need to be installed on the system by the
    default install, the certification process will optionally install
    it with instructions from the submitter on how to do so. I
    recommend that the new version be available in woody but it
    doesn't need to be installed by default.

    We also need updates of the lsb, lsb-release, lsb-rpm packages.
    These should be easy to backport but needs to be done.

  Jeff Licquia: lsb-rpm is a sarge innovation.  As I recall, it was
    made necessary by changes in rpm that happened after woody
    released.  Would the rpm from woody, therefore, be sufficient?

    lsb depends on python 2.3.  Is there any reason why python 2.2
    wouldn't work?


 . kernel changes need to be applied to all kernels in woody,
   especially to those distributed in woody not to those not
   distributed in woody.

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

 . http://hackers.progeny.com/~licquia/lsb/tjreport-woody.200311032211.txt
   assumes that only one test really failed.

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

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

    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

    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?

Open questions:

   1. Are grep and sed required for LSB 1.3?

   2. Are grep and sed required for Openi18n?

   3. Are there no more packages that need to be fixed for Openi18n?

   4. Need a fix for grep translations (easy)

   5. Is the cpio adjustment present in unstable?

   6. Which architectures are covered by LSB and need an adjusted


    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.

    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.

    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.


    Also, if the above still won't/can't happen, an apt-get repository
    with backports and stuff would be appropriate.



PS: [1] Jeff, I hope you don't mind quoting your personal mail on this
    subject publically.

PS: http://people.debian.org/~joey/3.0r3/ has been updated.

The good thing about standards is that there are so many to choose from.
		-- Andrew S. Tanenbaum

Please always Cc to me when replying to me on the lists.

Reply to: