I've read older mails on this issue and here's the outcome.[1]
LSB Compliance Requirements Modified packages: http://people.debian.org/~ajt/lsb/dists/woody/lsb/main/binary-i386/ alien, glibc, kernel, pax http://hackers.progeny.com/~licquia/lsb/tjreport-woody.200311032211.txt http://hackers.progeny.com/~licquia/lsb/apt/ http://hackers.progeny.com/~licquia/lsb/patches/woody/ bash, cpio, glib, grep, kernel, lsb, pax, sed alien 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. bash 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. cpio 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 minor. glibc 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 suites. 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 value. grep 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 http://www.openi18n.org/subgroups/utildev/patch/grep-2.5.1-i18n-0.1.patch.gz. 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. kernel ajt: The kernel changes have been tested everywhere that runs 2.4.19. 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. pax 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. sed 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 today. 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. Comments: 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 http://www.opengroup.org/lsb/cert/docs/testsuites.html 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? Problems: . 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 kernel? 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. 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: This WILL NOT HAPPEN FOR THE r3 UPDATE Also, if the above still won't/can't happen, an apt-get repository with backports and stuff would be appropriate. Regards, Joey 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.
