On Wed, 2005-09-28 at 15:21 -0700, Matt Taggart wrote: > I propose that our etch goal be LSB 3.x. There are still some issues to fix > but we're as close to implementing 3.0 as we are any other version. There's a > 3.1 in plan for later this year, it mostly bug fixes and other stuff that > shouldn't affect our compliance so we should be able to target it.
I concur with this. AJ: > > I think it's pretty telling that in spite of their PR position on staying > > 100% Debian and contributing all enhancements to Debian, that Progeny's > > working on making their product support LSB 3.0, while leaving Debian > > to stick with LSB 1.3 due to lack of interest. Slight aside: It was my understanding that Debian would prefer that the proposed LSB updates for sarge be well-tested and actually able to bestow compliance on sarge before considering them for inclusion. Perhaps I was mistaken on that front. Of course, uploading a broken dynamic linker hack to stable-proposed-updates and then adding a fixed one to DCC would not be considered fodder for conspiracy theories either, I suppose. :-) > It's not clear if such an approach would be appropriate for a sarge point > release. I *think* it would be OK as it doesn't change any existing system > ABI. About the only objection I can think of is that it would require > changing > the lsb package in order to add in the new linker hack. That would change > existing behavior, but since it's changing it to fix compliance I think that > could be considered a critical bug fix worthy for a stable update. What do > you > think? This was my expectation. For what it's worth, the dynamic linker hack libraries do not affect the rest of the packages shipped by Debian; these would continue to use ld-linux.so.2, and thus the standard libraries they use now. The lsb-core package would have to be changed to not create the dynamic linker symlinks if they already exist, and a dependency on the proper LSB libraries would have to be added somewhere. > As to the people suggesting that we "steal the patches" that Progeny is using > to implement the fixes (to their special packages, but are still relevant for > unstable), yes. But the issue hasn't been about the patches, those have been > obtainable from the other LSB implementors for a while now, Jeff just did the > job of gather them all in one place and making them consumable for Debian > (good work, we _should_ use it). The issue has been that Debian was unwilling > to accept some of the patches because upstream had refused them. This has > been > an ongoing battle between various Debian maintainers, their upstreams, and > the > LSB project. The primary problem with sarge and the LSB has to do with glibc issues. These issues are the reason I did the dynamic linker hack. Basically, the "solution" to the glibc problems is to upgrade to glibc 2.3.4 or later. I doubt that's going to be acceptable for a stable point release. There are two other problems, which I discuss below. All other test failures in sarge have been waived. > The LSB's charter is to document existing practice. If an interface change > isn't acceptable to the maintainer of the canonical implemantion, then the > LSB > should drop it. We need to push back on these sorts of things. (It hasn't > helped that other distros just accepted the patches and effectively forked, > making Debian the only one willing to do the right thing) Pushback has already been done on the primary example of this (the i18n patches to diff and coreutils), and those issues are waived for LSB 3.0. I am told that they will continue to be waived until the LSB gets its patches accepted upstream. > Jeff, > Do you have a nice collection of patches used posted somewhere that we could > review and either accept in the upstream package or push back and get removed > from upstream/LSB? Sarge has precisely three LSB problems at this time: - glibc (already discussed) - a bug in pam_unix (see bug 323982, already fixed in sid) - a typo in the XFree86 headers misdefining an i18n character There is also a problem that does not affect LSB status, but does affect testing: the xvfb in XFree86 dies during the running of the vsw4 test suite. I have it on good authority, however, that we do not need to use the shipping xvfb to run the tests, since the specification does not require xvfb; thus, the x.org xvfb (with a one-line patch to fix a new bug) can be used to certify sarge. The other XFree86 bug also affected x.org; a pointer to the problem and how to solve it is in x.org's BTS: https://bugs.freedesktop.org/show_bug.cgi?id=658 Here's the patch I'm using for pam: --- pam-lsb-0.76.orig/Linux-PAM/modules/pam_unix/pam_unix_sess.c +++ pam-lsb-0.76/Linux-PAM/modules/pam_unix/pam_unix_sess.c @@ -1,5 +1,5 @@ /* - * $Id: pam_unix_sess.c,v 1.1.1.1 2001/04/29 04:17:39 hartmans Exp $ + * $Id: pam_unix_sess.c,v 1.1 2001/04/29 04:17:39 hartmans Exp $ * * Copyright Alexander O. Yuriev, 1996. All rights reserved. * Copyright Jan R<EA>korajski, 1999. All rights reserved. @@ -44,6 +44,7 @@ #include <unistd.h> #include <syslog.h> #include <fcntl.h> +#include <ctype.h> #include <sys/types.h> #include <sys/stat.h> @@ -77,7 +78,7 @@ ctrl = _set_ctrl(pamh, flags, NULL, argc, argv); retval = pam_get_item(pamh, PAM_USER, (void *) &user_name); - if (user_name == NULL || retval != PAM_SUCCESS) { + if (user_name == NULL || !isalnum(*user_name) || retval != PAM_SUCCESS) { _log_err(LOG_CRIT, pamh, "open_session - error recovering username"); return PAM_SESSION_ERR; /* How did we get authenticated with @@ -108,7 +109,7 @@ ctrl = _set_ctrl(pamh, flags, NULL, argc, argv); retval = pam_get_item(pamh, PAM_USER, (void *) &user_name); - if (user_name == NULL || retval != PAM_SUCCESS) { + if (user_name == NULL || !isalnum(*user_name) || retval != PAM_SUCCESS) { _log_err(LOG_CRIT, pamh, "close_session - error recovering username"); return PAM_SESSION_ERR; /* How did we get authenticated with -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
