Re: Delegation for trademark negotiatons with the DCCA
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
Reply to: