Re: Bug#385976: strange (and annoying) delay on startup
On Mon, Sep 11, 2006 at 10:18:03PM +0200, Robert Millan wrote: > Thanks for the ellaboration. This sounds like a strange race, though. It > would require the user to launch the client before the server has finished its > startup, which AFAICT can only be done from a shell that doesn't belong to > this server session. Er, the server doesn't provide ICE functionality, that's purely a client-side adventure. So yes, it's entirely possible -- and plausible. Cheers, Daniel signature.asc Description: Digital signature
Bug#387133: libx11: FTBFS: floating point exception
Package: libx11
Version: 2:1.0.0-8
Severity: serious
Justification: no longer builds from source
Hi, when I try to build libx11 under etch or sid I get the following error:
make[3]: Leaving directory
`/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src/util'
../src/util/makekeys < /usr/include/X11/keysymdef.h > ks_tables_h
/bin/sh: line 1: 27372 Floating point exception../src/util/makekeys
ks_tables_h
make[2]: *** [ks_tables.h] Error 136
make[2]: Leaving directory
`/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src'
Full debuild log for sid is attached.
MfG
Goswin
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-frosties-2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
fakeroot debian/rules clean
rm -f stampdir/genscripts
rm -f debian/*.config \
debian/*.postinst \
debian/*.postrm \
debian/*.preinst \
debian/*.prerm
rm -f stampdir/patch
Unapplying patches...nothing to do.
dh_testdir
rm -f .pc patches
rm -rf stampdir build-tree
rm -rf imports
dh_clean debian/shlibs.local \
debian/MANIFEST.amd64 debian/MANIFEST.amd64.new \
debian/po/pothead
dh_testdir
dh_testroot
rm -f build-stamp
rm -f config.cache config.log config.status
rm -f */config.cache */config.log */config.status
rm -f conftest* */conftest*
rm -rf autom4te.cache */autom4te.cache
rm -rf obj-*
dh_clean
debian/rules build
mkdir stampdir
>stampdir/stampdir
for FILE in debian/*.config.in \
debian/*.postinst.in \
debian/*.postrm.in \
debian/*.preinst.in \
debian/*.prerm.in; do \
if [ -e "$FILE" ]; then \
MAINTSCRIPT=$(echo $FILE | sed 's/.in$//'); \
sed -n '1,/^#INCLUDE_SHELL_LIB#$/p' <$FILE \
| sed -e '/^#INCLUDE_SHELL_LIB#$/d' >$MAINTSCRIPT.tmp; \
cat debian/xsfbs/xsfbs.sh >>$MAINTSCRIPT.tmp; \
sed -n '/^#INCLUDE_SHELL_LIB#$/,$p' <$FILE \
| sed -e '/^#INCLUDE_SHELL_LIB#$/d' >>$MAINTSCRIPT.tmp; \
sed -e 's/@SOURCE_VERSION@/2:1.0.0-8/' \
-e 's/@OFFICIAL_BUILD@/yes/' \
-e 's/@DEFAULT_DCRESOLUTIONS@//' \
<$MAINTSCRIPT.tmp >$MAINTSCRIPT; \
rm $MAINTSCRIPT.tmp; \
fi; \
done
# Validate syntax of generated shell scripts.
#sh debian/scripts/validate-posix-sh debian/*.config \
#debian/*.postinst \
#debian/*.postrm \
#debian/*.preinst \
#debian/*.prerm
>stampdir/genscripts
if [ ! -e stampdir/patches ]; then \
mkdir stampdir/patches; \
ln -s stampdir/patches .pc; \
echo 2 >stampdir/patches/.version; \
fi; \
if [ ! -e stampdir/log ]; then \
mkdir stampdir/log; \
fi; \
if [ ! -e patches ]; then \
ln -s debian/patches patches; \
fi; \
>stampdir/prepare
if ! [ `which quilt` ]; then \
echo "Couldn't find quilt. Please install it or add it to the
build-depends for this package."; \
exit 1; \
fi; \
if quilt next; then \
echo -n "Applying patches..."; \
if quilt push -a -v >stampdir/log/patch 2>&1; then \
echo "successful."; \
else \
echo "failed! (check stampdir/log/patch for details)"; \
exit 1; \
fi; \
else \
echo "No patches to apply"; \
fi; \
>stampdir/patch
001_no_xkb_in_pc_file.diff
Applying patches...successful.
dh_testdir
test -d obj-x86_64-linux-gnu || mkdir obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu && \
../configure --prefix=/usr --mandir=\${prefix}/share/man \
--infodir=\${prefix}/share/info --build=x86_64-linux-gnu
--enable-man-pages=3 --enable-loadable-i18n \
CFLAGS="-Wall -g -O2 -DLIBXCURSOR=\\\"libXcursor.so.1\\\""
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are
Bug#387145: xorg-server: Should build-depend on x11proto-fixes-dev (>= 4.0)
Package: xorg-server Version: 2:1.1.1-5 Severity: normal The configure script in xorg-server barfs if x11proto-fixes-dev is less than version 4.0 anyway, so might as well enforce it with versioned build-depends... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (950, 'unstable'), (900, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-powerpc Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpqi8Yw7qQRj.pgp Description: PGP signature
Bug#387133: libx11: FTBFS: floating point exception
On Tue, Sep 12, 2006 at 02:01:59PM +0200, Goswin von Brederlow wrote: > Package: libx11 > Version: 2:1.0.0-8 > Severity: serious > Justification: no longer builds from source > > Hi, when I try to build libx11 under etch or sid I get the following error: > > make[3]: Leaving directory > `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src/util' > ../src/util/makekeys < /usr/include/X11/keysymdef.h > ks_tables_h > /bin/sh: line 1: 27372 Floating point exception../src/util/makekeys > ks_tables_h > make[2]: *** [ks_tables.h] Error 136 > make[2]: Leaving directory > `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src' > > Full debuild log for sid is attached. Yes, unfortunately x11proto-core 7.0.3 or above (or something) breaks the build of libx11 << 1.0.1. signature.asc Description: Digital signature
Bug#387146: xserver-xorg-input-keyboard: Should build-depend on xserver-xorg-dev (>= 2:1.0.99.901)
Package: xserver-xorg-input-keyboard Version: 1:1.1.0-1 Severity: normal The configure script in xserver-xorg-input-keyboard barfs if xserver-xorg-dev is less than version 1.0.99.901 anyway, so might as well enforce it with versioned build-depends... I imagine this sort of build-dependancy exists throughout the modules of the 7.1 modular release... I presume they haven't shown up on the autobuilders before since the 7.0 release was compatible with the 6.9 release, and before that we had a renaming instead... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (950, 'unstable'), (900, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-powerpc Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpnrtv2rnmmz.pgp Description: PGP signature
Bug#387133: libx11: FTBFS: floating point exception
Daniel Stone <[EMAIL PROTECTED]> writes: > On Tue, Sep 12, 2006 at 02:01:59PM +0200, Goswin von Brederlow wrote: >> Package: libx11 >> Version: 2:1.0.0-8 >> Severity: serious >> Justification: no longer builds from source >> >> Hi, when I try to build libx11 under etch or sid I get the following error: >> >> make[3]: Leaving directory >> `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src/util' >> ../src/util/makekeys < /usr/include/X11/keysymdef.h > ks_tables_h >> /bin/sh: line 1: 27372 Floating point exception../src/util/makekeys >> ks_tables_h >> make[2]: *** [ks_tables.h] Error 136 >> make[2]: Leaving directory >> `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src' >> >> Full debuild log for sid is attached. > > Yes, unfortunately x11proto-core 7.0.3 or above (or something) breaks > the build of libx11 << 1.0.1. Meanwhile Tollef Fog Heen told me to try the Ubuntu version (1.0.3) which worked. So I just added the makekeys.c from it to 1.0.0 and then it compiled fine. If updating to 1.0.1+ is too much change then maybe this quick fix would do. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385976: strange (and annoying) delay on startup
On Mon, Sep 11, 2006, Robert Millan wrote: > Thanks for the ellaboration. This sounds like a strange race, though. It > would require the user to launch the client before the server has finished its > startup, which AFAICT can only be done from a shell that doesn't belong to > this server session. I think the race is possible, otherwise there wouldn't be a special case for it in the code. But perhaps it's possible to avoid the race at a higher level. > Is this hack required for the initial X client? If this is so, waiting 5s is > not a good solution to workaround lack of syncronisation anyway. The 5 second wait is coded in a generic fashion when the underlying transport said connection is to be retried. The problem is not the 5 second wait, but the fact that the transport said to retry, while it's clear that the socket isn't there -- and won't appear. It's hard to tell whether the socket might appear, but I think this question is for higher level stacks. My opinion is that whoever creates the environment variable which lists the socket should make sure the socket is available before spreading the news, and we should return to a hard failure when the socket doesn't exist. I think Xtrans preserves errno appropriately to the higher level stacks, so it might be enough to check whether errno == ENOENT at a higher level. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385976: strange (and annoying) delay on startup
On Tue, Sep 12, 2006 at 10:23:15AM +0200, Loïc Minier wrote: > On Mon, Sep 11, 2006, Robert Millan wrote: > > Thanks for the ellaboration. This sounds like a strange race, though. It > > would require the user to launch the client before the server has finished > > its > > startup, which AFAICT can only be done from a shell that doesn't belong to > > this server session. > > I think the race is possible, otherwise there wouldn't be a special > case for it in the code. But perhaps it's possible to avoid the race > at a higher level. > > > Is this hack required for the initial X client? If this is so, waiting 5s > > is > > not a good solution to workaround lack of syncronisation anyway. > > The 5 second wait is coded in a generic fashion when the underlying > transport said connection is to be retried. The problem is not the 5 > second wait, but the fact that the transport said to retry, while it's > clear that the socket isn't there -- and won't appear. It's hard to > tell whether the socket might appear, but I think this question is for > higher level stacks. > > My opinion is that whoever creates the environment variable which lists > the socket should make sure the socket is available before spreading > the news, It did, and at that time the socket was present. It's just that the socket is not there anymore. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITA/ITP compiz
Title: ITA/ITP compiz I would like to take maintainership of compiz seeing the big progress we've made wrt AIGLX and Mesa. I am working with the debian mentors to get the requirements delt with. However, I would like to have the package remain (as mentioned by David) with the Debian X Strike Force team (thus I'd be joing it). Thanks, -- Shawn Starr Software Developer, Open Source Grid Development Center (OSGDC) Platform Computing 3760 14th Avenue Markham, ON L3R3T7 direct: 905.948.4229 http://www.platform.com
Re: Bug#385976: strange (and annoying) delay on startup
On Tue, Sep 12, 2006 at 07:09:36PM +0200, Loïc Minier wrote: > On Tue, Sep 12, 2006, Robert Millan wrote: > > > My opinion is that whoever creates the environment variable which lists > > > the socket should make sure the socket is available before spreading > > > the news, > > It did, and at that time the socket was present. It's just that the socket > > is not there anymore. > > If everyone would have done so, the current code wouldn't have to > special case the absence of the socket as a "try again" error. My > suggestion is to return a hard error instead and fix the applications > to wait for the socket to exist before they publish the environement > variable. I don't know about Desktop Env applications, but why would a shell care? It's agnostic about what the env variables mean (well, mostly). -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385976: Proposed patch
reassign 385976 xtrans tag 385976 + patch stop Hi, Please find a proposed patch attached (both the patch for the Debian package and the actual patch file are attached). (Reassigning to xtrans because it's what the patch is against.) Bye, -- Loïc Minier <[EMAIL PROTECTED]> diff -urN xtrans-1.0.1.orig/Xtranssock.c xtrans-1.0.1/Xtranssock.c --- xtrans-1.0.1.orig/Xtranssock.c 2006-06-16 00:53:55.0 +0200 +++ xtrans-1.0.1/Xtranssock.c 2006-09-12 19:14:13.0 +0200 @@ -2041,8 +2041,13 @@ errno = olderrno; /* -* If the error was ENOENT, the server may be starting up -* and we should try again. +* If the error was ENOENT, the server may be starting up; we used +* to suggest to try again in this case with +* TRANS_TRY_CONNECT_AGAIN, but this introduced problems for +* processes still referencing stale sockets in their environment. +* Hence, we now return a hard error, TRANS_CONNECT_FAILED, and it +* is suggested that higher level stacks handle retries on their +* level when they face a slow starting server. * * If the error was EWOULDBLOCK or EINPROGRESS then the socket * was non-blocking and we should poll using select @@ -2051,7 +2056,9 @@ * should try again. */ - if (olderrno == ENOENT || olderrno == EINTR) + if (olderrno == ENOENT) + return TRANS_CONNECT_FAILED; + else if (olderrno == EINTR) return TRANS_TRY_CONNECT_AGAIN; else if (olderrno == EWOULDBLOCK || olderrno == EINPROGRESS) return TRANS_IN_PROGRESS; --- xtrans-1.0.1/debian/patches/series +++ xtrans-1.0.1/debian/patches/series @@ -2,0 +3 @@ +03_unix-sock-fail-fast.diff -p1 --- xtrans-1.0.1/debian/changelog +++ xtrans-1.0.1/debian/changelog @@ -1,3 +1,11 @@ +xtrans (1.0.1-3) unstable; urgency=low + + * New patch, 03_unix-sock-fail-fast, to fail immediately in case a UNIX +socket doesn't exist; higher level stacks should retry the connection with +the server if they face slow starting servers. (Closes: #385976) + + -- Loic Minier <[EMAIL PROTECTED]> Tue, 12 Sep 2006 19:14:20 +0200 + xtrans (1.0.1-2) unstable; urgency=low [ Andres Salomon ] --- xtrans-1.0.1.orig/Xtranssock.c +++ xtrans-1.0.1/Xtranssock.c @@ -2041,8 +2041,13 @@ errno = olderrno; /* -* If the error was ENOENT, the server may be starting up -* and we should try again. +* If the error was ENOENT, the server may be starting up; we used +* to suggest to try again in this case with +* TRANS_TRY_CONNECT_AGAIN, but this introduced problems for +* processes still referencing stale sockets in their environment. +* Hence, we now return a hard error, TRANS_CONNECT_FAILED, and it +* is suggested that higher level stacks handle retries on their +* level when they face a slow starting server. * * If the error was EWOULDBLOCK or EINPROGRESS then the socket * was non-blocking and we should poll using select @@ -2051,7 +2056,9 @@ * should try again. */ - if (olderrno == ENOENT || olderrno == EINTR) + if (olderrno == ENOENT) + return TRANS_CONNECT_FAILED; + else if (olderrno == EINTR) return TRANS_TRY_CONNECT_AGAIN; else if (olderrno == EWOULDBLOCK || olderrno == EINPROGRESS) return TRANS_IN_PROGRESS; --- xtrans-1.0.1.orig/debian/patches/03_unix-sock-fail-fast.diff +++ xtrans-1.0.1/debian/patches/03_unix-sock-fail-fast.diff @@ -0,0 +1,30 @@ +diff -urN xtrans-1.0.1.orig/Xtranssock.c xtrans-1.0.1/Xtranssock.c +--- xtrans-1.0.1.orig/Xtranssock.c 2006-06-16 00:53:55.0 +0200 xtrans-1.0.1/Xtranssock.c 2006-09-12 19:14:13.0 +0200 +@@ -2041,8 +2041,13 @@ + errno = olderrno; + + /* +- * If the error was ENOENT, the server may be starting up +- * and we should try again. ++ * If the error was ENOENT, the server may be starting up; we used ++ * to suggest to try again in this case with ++ * TRANS_TRY_CONNECT_AGAIN, but this introduced problems for ++ * processes still referencing stale sockets in their environment. ++ * Hence, we now return a hard error, TRANS_CONNECT_FAILED, and it ++ * is suggested that higher level stacks handle retries on their ++ * level when they face a slow starting server. +* +* If the error was EWOULDBLOCK or EINPROGRESS then the socket +* was non-blocking and we should poll using select +@@ -2051,7 +2056,9 @@ +* should try again. +*/ + +-
Bug#385976: strange (and annoying) delay on startup
On Tue, Sep 12, 2006, Robert Millan wrote: > > My opinion is that whoever creates the environment variable which lists > > the socket should make sure the socket is available before spreading > > the news, > It did, and at that time the socket was present. It's just that the socket > is not there anymore. If everyone would have done so, the current code wouldn't have to special case the absence of the socket as a "try again" error. My suggestion is to return a hard error instead and fix the applications to wait for the socket to exist before they publish the environement variable. -- Loïc Minier <[EMAIL PROTECTED]>
Processed: Proposed patch
Processing commands for [EMAIL PROTECTED]: > reassign 385976 xtrans Bug#385976: SocketUNIXConnect shouldn't return TRANS_TRY_CONNECT_AGAIN when the socket file doesn't exist Bug reassigned from package `libice6' to `xtrans'. > tag 385976 + patch Bug#385976: SocketUNIXConnect shouldn't return TRANS_TRY_CONNECT_AGAIN when the socket file doesn't exist There were no tags set. Tags added: patch > stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#387133: libx11: FTBFS: floating point exception
On Tue, Sep 12, 2006 at 03:50:04PM +0300, Daniel Stone wrote: > On Tue, Sep 12, 2006 at 02:01:59PM +0200, Goswin von Brederlow wrote: > > Package: libx11 > > Version: 2:1.0.0-8 > > Severity: serious > > Justification: no longer builds from source > > Hi, when I try to build libx11 under etch or sid I get the following error: > > make[3]: Leaving directory > > `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src/util' > > ../src/util/makekeys < /usr/include/X11/keysymdef.h > ks_tables_h > > /bin/sh: line 1: 27372 Floating point exception../src/util/makekeys > > ks_tables_h > > make[2]: *** [ks_tables.h] Error 136 > > make[2]: Leaving directory > > `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src' > > Full debuild log for sid is attached. > Yes, unfortunately x11proto-core 7.0.3 or above (or something) breaks > the build of libx11 << 1.0.1. Then we have a problem, given that David says the new libx11 is not targetted for etch and the new x11proto-core is already there. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#387133: libx11: FTBFS: floating point exception
On Tue, Sep 12, 2006 at 01:23:52PM -0700, Steve Langasek wrote: > On Tue, Sep 12, 2006 at 03:50:04PM +0300, Daniel Stone wrote: > > On Tue, Sep 12, 2006 at 02:01:59PM +0200, Goswin von Brederlow wrote: > > > Hi, when I try to build libx11 under etch or sid I get the following > > > error: > > > > make[3]: Leaving directory > > > `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src/util' > > > ../src/util/makekeys < /usr/include/X11/keysymdef.h > ks_tables_h > > > /bin/sh: line 1: 27372 Floating point exception../src/util/makekeys > > > ks_tables_h > > > make[2]: *** [ks_tables.h] Error 136 > > > make[2]: Leaving directory > > > `/scratch/build/amd64/etch-biarch/xorg/libx11/libx11-1.0.0/obj-x86_64-linux-gnu/src' > > > > Full debuild log for sid is attached. > > > Yes, unfortunately x11proto-core 7.0.3 or above (or something) breaks > > the build of libx11 << 1.0.1. > > Then we have a problem, given that David says the new libx11 is not > targetted for etch and the new x11proto-core is already there. So backport the makekeys.c fix. Problem solved. signature.asc Description: Digital signature
Bug#387205: xdm password length limit
Package: xdm
Version: 4.3.0.dfsg.1-1
Severity: important
xdm has a password length limit of 32, as seen in
xc/programs/xdm/greeter/Login.h
Note that I'm not sure about the version, since I run some backports stuff,
but the source was from sarge, not backports.
And don't say "nobody needs passwords that long", because that's wrong for
several reasons.
-
typedef struct me_s {
char name[] = { "Thomas Habets" };
char email[] = { "[EMAIL PROTECTED]" };
char kernel[]= { "Linux" };
char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; };
char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" };
char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386385: xkb-data: Wrong codes for Greek polytonic breathing signs
On Fri, 2006-09-08 at 16:23 +0200, Jan Willem Stumpel wrote: > Hmm.. this is a keyboard thing, not a display thing, so how could > a URL help? xev can be used to verify the fix, of course. > > The bug itself has been reported already in Ubuntu and SuSE, > though not in Debian, e.g. > > http://www.mail-archive.com/desktop-bugs@lists.ubuntu.com/msg06568.html > Ah ok. Thanks for the clarification. Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Debbugs-fu is weak...
Processing commands for [EMAIL PROTECTED]: > # Crap, I checked for this sort of thing more than once, > # must have been looking in the wrong place... > # I blame the querybts script in reportbug... ^_^ > merge 383778 387145 Bug#383778: xorg-server: x11proto-fixes-dev build-depends is too weak Bug#387145: xorg-server: Should build-depend on x11proto-fixes-dev (>= 4.0) Merged 383778 387145. > Thankyou Mr Bug Control Robot Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
