Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 12:03:03AM -0600, Chris Cheney wrote: BTW - If you have a bug which you believe deserves to be marked RC you can always just tag it is sarge and sid as well to have it effectively ignored for migration purposes. That's not technically true at the moment, although it'll probably become true fairly soon. It's not a particularly good idea though; if you've got an RC bug, you need to fix it, not find ways to get it ignored. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Bug#143825: pending meaning change
tags 97671 - pending tags 143825 - pending tags 155374 - pending tags 169264 - pending tags 169413 - pending tags 170820 - pending tags 188877 - pending tags 189832 - pending tags 190592 - pending tags 196234 - pending tags 198337 - pending thanks The definition of the pending tag has been changed to: ] pending ] A solution to this bug has been found and an upload will be ] made soon. The (release critical) bugs above have been tagged pending for over a month, so by the new definition the tag appears to not apply to the above bugs. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#143825: pending meaning change
tags 97671 - pending tags 143825 - pending tags 155374 - pending tags 169264 - pending tags 169413 - pending tags 170820 - pending tags 188877 - pending tags 189832 - pending tags 190592 - pending tags 196234 - pending tags 198337 - pending thanks The definition of the pending tag has been changed to: ] pending ] A solution to this bug has been found and an upload will be ] made soon. The (release critical) bugs above have been tagged pending for over a month, so by the new definition the tag appears to not apply to the above bugs. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?''
Re: xfree86 4.2.1-6 build on alpha
severity 184057 serious
severity 187417 serious
merge 187417 184057
thanks
On Thu, Apr 03, 2003 at 11:07:16AM +0200, Falk Hueffner wrote:
Ah, the gzip killer bug. Works with -3, fails with -4 - where the
--rsyncable patch was introduced. However, StevenK claimed he couldn't
reproduce it, so I didn't file a bug about it.
Bug needs to be filed on gzip about the 'gzip killer' .bdf.
Already reported 3 weeks ago as #184057.
So, here's the deal. On alpha, this bug is reproducible when compiled
with gcc-3.2 at any optimisation, but not reproducible with gcc-2.95
at -O2. When -DDEBUG is enabled, the assertion is triggered on alpha
with gcc-2.95 and gcc-3.2. With -DDEBUG enabled, the assertion is also
triggered on powerpc.
The problem appears to be that the checks in deflate_fast() and deflate(),
namely:
if (hash_head != NIL strstart - hash_head = MAX_DIST) {
and
if (hash_head != NIL prev_length max_lazy_match
strstart - hash_head = MAX_DIST) {
preceeding calls to longest_match() do not actually ensure that the assertion:
Assert(strstart = window_size-MIN_LOOKAHEAD, insufficient lookahead);
in longest_match() actually passes. I don't really understand what's going
on exactly, but the thoughtless solution of adding the extra check from
the assertion explicitly seems to work (and, afaics, should work).
The two tests (strstart = window_size - MIN_LOOKAHEAD, and strstart -
hash_head = MAX_DIST) are equivalent when hash_head WSIZE, but there's
no particular reason for that to be true, that I can see. I don't think this
can result in corrupted data, and while a buffer is overflown I think it's
only by reading, so apart from the segfault I don't _think_ there are any
problems caused by this bug. I'm not really sure though.
The patch looks like:
--- gzip-1.3.5/deflate.c2003-04-03 21:51:36.0 +1000
+++ gzip-1.3.5-aj/deflate.c 2003-04-03 21:56:38.0 +1000
@@ -643,7 +643,8 @@
/* Find the longest match, discarding those = prev_length.
* At this point we have always match_length MIN_MATCH
*/
-if (hash_head != NIL strstart - hash_head = MAX_DIST) {
+if (hash_head != NIL strstart - hash_head = MAX_DIST
+strstart = window_size - MIN_LOOKAHEAD) {
/* To simplify the code, we prevent matches with the string
* of window index 0 (in particular we have to avoid a match
* of the string with itself at the start of the input file).
@@ -737,7 +738,8 @@
match_length = MIN_MATCH-1;
if (hash_head != NIL prev_length max_lazy_match
-strstart - hash_head = MAX_DIST) {
+strstart - hash_head = MAX_DIST
+strstart = window_size - MIN_LOOKAHEAD) {
/* To simplify the code, we prevent matches with the string
* of window index 0 (in particular we have to avoid a match
* of the string with itself at the start of the input file).
As it stands, this patch decreases the effectiveness of gzip's deflate
implementation by, I guess, up to 258 bytes per file. For comparison:
$ echo `gzip X | wc -c` `gzip X | md5sum | cut -d\ -f1`
11912 4d02d6c8ee27d64a2cb773ad5cf9a086
$ echo `./gzip X | wc -c` `./gzip X | md5sum | cut -d\ -f1`
11981 499f30e71926490dd5404f9d38efeacd
Both files decompresses correctly, of course.
For files not affected by this bug, the output is exactly the same:
$ echo `gzip /etc/motd | wc -c` `gzip /etc/motd | md5sum | cut -d\ -f1`
277 e73b4f30720cf2a29c2b774078237ea4
$ echo `./gzip /etc/motd | wc -c` `./gzip /etc/motd | md5sum | cut -d\ -f1`
277 e73b4f30720cf2a29c2b774078237ea4
Note that i386 has an assembly implementation of longest_match() which
may or may not have the bug.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xfree86 4.2.1-6 build on alpha
Hello, xfree86 4.2.1-6 fails to build on alpha due to: ... LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/bdftopcf -t lutBS08. bdf | gzip lutBS08.pcf.gz make[6]: *** [lutBS08.pcf.gz] Error 139 See http://buildd.debian.org/build.php?arch=alphapkg=xfree86ver=4.2.1-6 Can this be looked into, please? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!''
Re: xfree86 4.2.1-6 build on alpha
severity 184057 serious
severity 187417 serious
merge 187417 184057
thanks
On Thu, Apr 03, 2003 at 11:07:16AM +0200, Falk Hueffner wrote:
Ah, the gzip killer bug. Works with -3, fails with -4 - where the
--rsyncable patch was introduced. However, StevenK claimed he couldn't
reproduce it, so I didn't file a bug about it.
Bug needs to be filed on gzip about the 'gzip killer' .bdf.
Already reported 3 weeks ago as #184057.
So, here's the deal. On alpha, this bug is reproducible when compiled
with gcc-3.2 at any optimisation, but not reproducible with gcc-2.95
at -O2. When -DDEBUG is enabled, the assertion is triggered on alpha
with gcc-2.95 and gcc-3.2. With -DDEBUG enabled, the assertion is also
triggered on powerpc.
The problem appears to be that the checks in deflate_fast() and deflate(),
namely:
if (hash_head != NIL strstart - hash_head = MAX_DIST) {
and
if (hash_head != NIL prev_length max_lazy_match
strstart - hash_head = MAX_DIST) {
preceeding calls to longest_match() do not actually ensure that the assertion:
Assert(strstart = window_size-MIN_LOOKAHEAD, insufficient lookahead);
in longest_match() actually passes. I don't really understand what's going
on exactly, but the thoughtless solution of adding the extra check from
the assertion explicitly seems to work (and, afaics, should work).
The two tests (strstart = window_size - MIN_LOOKAHEAD, and strstart -
hash_head = MAX_DIST) are equivalent when hash_head WSIZE, but there's
no particular reason for that to be true, that I can see. I don't think this
can result in corrupted data, and while a buffer is overflown I think it's
only by reading, so apart from the segfault I don't _think_ there are any
problems caused by this bug. I'm not really sure though.
The patch looks like:
--- gzip-1.3.5/deflate.c2003-04-03 21:51:36.0 +1000
+++ gzip-1.3.5-aj/deflate.c 2003-04-03 21:56:38.0 +1000
@@ -643,7 +643,8 @@
/* Find the longest match, discarding those = prev_length.
* At this point we have always match_length MIN_MATCH
*/
-if (hash_head != NIL strstart - hash_head = MAX_DIST) {
+if (hash_head != NIL strstart - hash_head = MAX_DIST
+strstart = window_size - MIN_LOOKAHEAD) {
/* To simplify the code, we prevent matches with the string
* of window index 0 (in particular we have to avoid a match
* of the string with itself at the start of the input file).
@@ -737,7 +738,8 @@
match_length = MIN_MATCH-1;
if (hash_head != NIL prev_length max_lazy_match
-strstart - hash_head = MAX_DIST) {
+strstart - hash_head = MAX_DIST
+strstart = window_size - MIN_LOOKAHEAD) {
/* To simplify the code, we prevent matches with the string
* of window index 0 (in particular we have to avoid a match
* of the string with itself at the start of the input file).
As it stands, this patch decreases the effectiveness of gzip's deflate
implementation by, I guess, up to 258 bytes per file. For comparison:
$ echo `gzip X | wc -c` `gzip X | md5sum | cut -d\ -f1`
11912 4d02d6c8ee27d64a2cb773ad5cf9a086
$ echo `./gzip X | wc -c` `./gzip X | md5sum | cut -d\ -f1`
11981 499f30e71926490dd5404f9d38efeacd
Both files decompresses correctly, of course.
For files not affected by this bug, the output is exactly the same:
$ echo `gzip /etc/motd | wc -c` `gzip /etc/motd | md5sum | cut -d\ -f1`
277 e73b4f30720cf2a29c2b774078237ea4
$ echo `./gzip /etc/motd | wc -c` `./gzip /etc/motd | md5sum | cut -d\ -f1`
277 e73b4f30720cf2a29c2b774078237ea4
Note that i386 has an assembly implementation of longest_match() which
may or may not have the bug.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
xfree86 4.2.1-6 build on alpha
Hello, xfree86 4.2.1-6 fails to build on alpha due to: ... LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/bdftopcf -t lutBS08. bdf | gzip lutBS08.pcf.gz make[6]: *** [lutBS08.pcf.gz] Error 139 See http://buildd.debian.org/build.php?arch=alphapkg=xfree86ver=4.2.1-6 Can this be looked into, please? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#128101: reassign to xserver-xfree86
reassign 128101 xserver-xfree86 thanks The lockup occurs under the following condition: the frame buffer device (atyfb) is loaded and used by console. Start a second X-server from an xterm on the first X-server. If I start a second X-server from the console, even a fb-enabled console, there is no lockup. Conclusion: this is not a gdm bug... reassign to xserver-xfree86? Or to kernel-source-2.4.xx. Seems to be some sort of a locking problem between the two. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#128101: reassign to xserver-xfree86
reassign 128101 xserver-xfree86 thanks The lockup occurs under the following condition: the frame buffer device (atyfb) is loaded and used by console. Start a second X-server from an xterm on the first X-server. If I start a second X-server from the console, even a fb-enabled console, there is no lockup. Conclusion: this is not a gdm bug... reassign to xserver-xfree86? Or to kernel-source-2.4.xx. Seems to be some sort of a locking problem between the two.
Re: Processed: round and round we go
On Mon, Nov 04, 2002 at 12:46:00AM -0500, Branden Robinson wrote: [Anthony, are you subscribed to debian-x? I thought for sure you weren't.] I'm not, but it looks like mutt's group reply isn't clever enough to add me to the Mail-Followup-To field without debian-x being explicitly listed as a mailing list. On Sun, Nov 03, 2002 at 09:10:13AM +1000, Anthony Towns wrote: I'd marked that bug as applying to the version in testing way back before woody was released. So either no or it was already special cased. Oh ah. Is that marking visible in any publicly-readable file? auric:/org/ftp.debian.org/testing/data/testing/Bugs The relevant line is xutils 1 -- ie, xutils in testing has 1 RC bug. Those numbers are rough and inaccurate, and shouldn't be relied upon too heavily. You downgraded that bug on the 27th, at which point xfree86 would've been uploaded for about eight days -- so it would've been too young to be a valid candidate. I had the impression -- perhaps mistaken -- that valid candidate wouldn't have shown up anyway. Yup, it was mistaken. Maintainer: Branden Robinson, 14 days old (needed 10 days), Depends: foo bar and baz (source, i386) is (less) buggy! are all examples of lines that'll show up in update_excuses without preventing the package from being considered as a valid candidate. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgptbPLJ6Lqft.pgp Description: PGP signature
Re: Processed: round and round we go
On Mon, Nov 04, 2002 at 12:46:00AM -0500, Branden Robinson wrote: [Anthony, are you subscribed to debian-x? I thought for sure you weren't.] I'm not, but it looks like mutt's group reply isn't clever enough to add me to the Mail-Followup-To field without debian-x being explicitly listed as a mailing list. On Sun, Nov 03, 2002 at 09:10:13AM +1000, Anthony Towns wrote: I'd marked that bug as applying to the version in testing way back before woody was released. So either no or it was already special cased. Oh ah. Is that marking visible in any publicly-readable file? auric:/org/ftp.debian.org/testing/data/testing/Bugs The relevant line is xutils 1 -- ie, xutils in testing has 1 RC bug. Those numbers are rough and inaccurate, and shouldn't be relied upon too heavily. You downgraded that bug on the 27th, at which point xfree86 would've been uploaded for about eight days -- so it would've been too young to be a valid candidate. I had the impression -- perhaps mistaken -- that valid candidate wouldn't have shown up anyway. Yup, it was mistaken. Maintainer: Branden Robinson, 14 days old (needed 10 days), Depends: foo bar and baz (source, i386) is (less) buggy! are all examples of lines that'll show up in update_excuses without preventing the package from being considered as a valid candidate. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg04568/pgp0.pgp Description: PGP signature
Re: Processed: round and round we go
On Sat, Nov 02, 2002 at 02:53:41PM -0500, Branden Robinson wrote: On Sat, Nov 02, 2002 at 12:33:12PM -0600, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: severity 143825 serious Bug#143825: xutils: why is rstart.real a conffile? Severity set to `serious'. Is it your intention not to let XFree86 4.2.1-3 propagate into testing until I fix this bug? Huh? When update_excuses says, eg: + libcrypt-ssleay-perl (alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc) is (less) buggy! (1 = 1) it's doesn't block the package from being considered. That was the case for xutils until you downgraded the bug. And in any event it already went in today, along with pam. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg04537/pgp0.pgp Description: PGP signature
Re: Processed: round and round we go
On Sat, Nov 02, 2002 at 04:24:46PM -0500, Branden Robinson wrote: Yes, someone else pointed this out to me. So you didn't have to special case it, and wouldn't have needed to even if I hadn't downgraded the bug? I'd marked that bug as applying to the version in testing way back before woody was released. So either no or it was already special cased. 1) why such things are reported as excuses for a package not being considered when they won't stop a package from being considered; Because it's helpful to have the fact that there're RC bugs in the unstable version coveniently available, whether they affect the move into testing or not. 2) why valid candidate wasn't appearing in the output; I interpreted the absence of valid candidate to mean that the package would not be moving to testing You downgraded that bug on the 27th, at which point xfree86 would've been uploaded for about eight days -- so it would've been too young to be a valid candidate. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg04540/pgp0.pgp Description: PGP signature
Re: Processed: round and round we go
On Sat, Nov 02, 2002 at 02:53:41PM -0500, Branden Robinson wrote: On Sat, Nov 02, 2002 at 12:33:12PM -0600, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: severity 143825 serious Bug#143825: xutils: why is rstart.real a conffile? Severity set to `serious'. Is it your intention not to let XFree86 4.2.1-3 propagate into testing until I fix this bug? Huh? When update_excuses says, eg: + libcrypt-ssleay-perl (alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc) is (less) buggy! (1 = 1) it's doesn't block the package from being considered. That was the case for xutils until you downgraded the bug. And in any event it already went in today, along with pam. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' pgpPIuE6LhMI3.pgp Description: PGP signature
Re: X4 testing/woody
On Thu, Jan 18, 2001 at 04:48:58AM -0500, Anthony Towns wrote: X4 hasn't gone into woody yet; somehow or other it's breaking the testing update scripts --- blowing out the runtime from 20 minutes in total to more like 10 or 20 hours (I haven't let it run to see exactly). Okay, so X4 is in woody now (on ftp-master anyway; should hit the mirrors tomorrow). The xpm4g stuff was causing one set of problems; the freetype stuff was causing another. I've gone ahead and forced all the things that depended on xpm4g out of testing: hopefully they'll make it back in from unstable soon. I've also gone ahead and forced the freetype and freetype1 packages into testing. This has a slight problem in that freetype1 depends on a later version of glibc than is in testing atm, but that should be fixed soon. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) PGP signature
Re: X4 testing/woody
On Thu, Jan 18, 2001 at 04:48:58AM -0500, Anthony Towns wrote: X4 hasn't gone into woody yet; somehow or other it's breaking the testing update scripts --- blowing out the runtime from 20 minutes in total to more like 10 or 20 hours (I haven't let it run to see exactly). Okay, so X4 is in woody now (on ftp-master anyway; should hit the mirrors tomorrow). The xpm4g stuff was causing one set of problems; the freetype stuff was causing another. I've gone ahead and forced all the things that depended on xpm4g out of testing: hopefully they'll make it back in from unstable soon. I've also gone ahead and forced the freetype and freetype1 packages into testing. This has a slight problem in that freetype1 depends on a later version of glibc than is in testing atm, but that should be fixed soon. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpAAQfgKYBC8.pgp Description: PGP signature
X4 testing/woody
Hi all, X4 hasn't gone into woody yet; somehow or other it's breaking the testing update scripts --- blowing out the runtime from 20 minutes in total to more like 10 or 20 hours (I haven't let it run to see exactly). I'll poke around a bit more to try and fix this, but my net access is a little nonexistant at the moment... In the meantime, feel free to upload new source/binary packages to unstable: I'll just override any version inconsistency checks for X4 when I work out what's going on. X4 seems to make around 100 packages per architecture uninstallable that are fine at the moment. I'm not sure why as of yet, I'll see if I can find out... Anyway, so there you know... Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
X4 testing/woody
Hi all, X4 hasn't gone into woody yet; somehow or other it's breaking the testing update scripts --- blowing out the runtime from 20 minutes in total to more like 10 or 20 hours (I haven't let it run to see exactly). I'll poke around a bit more to try and fix this, but my net access is a little nonexistant at the moment... In the meantime, feel free to upload new source/binary packages to unstable: I'll just override any version inconsistency checks for X4 when I work out what's going on. X4 seems to make around 100 packages per architecture uninstallable that are fine at the moment. I'm not sure why as of yet, I'll see if I can find out... Anyway, so there you know... Cheers, aj
Re: XFree86 4.0.2 status
On Fri, Jan 12, 2001 at 10:18:53PM +0100, Christian T. Steigies wrote: It seems to work with the following packages installed (don't ask me in which order to install them, I downgraded from 4.0.2 to 3.3.6 until it worked): ii xfonts-75dpi 3.3.6-275 dpi fonts for X ii xfonts-base3.3.6-2standard fonts for X ii xfonts-scalabl 3.3.6-2scalable fonts for X These are all arch: all packages, so they have to be either 3.3.6-2 or 4.0.2-1 on all architectures or on none. I guess that's probably not a problem though? Actually, hmm. Did you also manage to get xutils to build? The X4 versions of the fonts seem to depend on that package. ii xlib6 3.3.6-11potato shared libraries required by libc5 X clients ii xserver-common 3.3.6-11potato files and utilities common to all X servers iF xserver-fbdev 3.3.6-11potato X server for framebuffer-based graphics driv xlib6 (the libc5 version of xlib6g) is apparently now a part of xfree86v3; so at somepoint before release either that package will need to be built for arm, or the few things that depend on it will need to be rebuilt with xlib6g, I guess. But anyway, I can keep all these around in woody for m68k (since they're all arch: any packages), even while upgrading all of: ii libxaw64.0.2-1X Athena widget set library (version 6) ii libxaw74.0.2-1X Athena widget set library ii xbase-clients 4.0.2-1miscellaneous X clients ii xdm4.0.2-1X display manager ii xfree86-common 4.0.2-1X Window System (XFree86) infrastructure ii xfs4.0.2-1X font server ii xlib6g 4.0.2-1pseudopackage providing X libraries ii xlibmesa3 4.0.2-1XFree86 version of Mesa 3D graphics library ii xlibs 4.0.2-1X Window System client libraries ii xnest 4.0.2-1nested X server ii xterm 4.0.2-1X terminal emulator It'll be a bit hacky, but it should work okay. So I can upload all but xserver-[common|fbdev] and nobody should get hurt? I think so. Branden? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 PGP signature
Re: XFree86 4.0.2 status
On Fri, Jan 12, 2001 at 10:18:53PM +0100, Christian T. Steigies wrote: It seems to work with the following packages installed (don't ask me in which order to install them, I downgraded from 4.0.2 to 3.3.6 until it worked): ii xfonts-75dpi 3.3.6-275 dpi fonts for X ii xfonts-base3.3.6-2standard fonts for X ii xfonts-scalabl 3.3.6-2scalable fonts for X These are all arch: all packages, so they have to be either 3.3.6-2 or 4.0.2-1 on all architectures or on none. I guess that's probably not a problem though? Actually, hmm. Did you also manage to get xutils to build? The X4 versions of the fonts seem to depend on that package. ii xlib6 3.3.6-11potato shared libraries required by libc5 X clients ii xserver-common 3.3.6-11potato files and utilities common to all X servers iF xserver-fbdev 3.3.6-11potato X server for framebuffer-based graphics driv xlib6 (the libc5 version of xlib6g) is apparently now a part of xfree86v3; so at somepoint before release either that package will need to be built for arm, or the few things that depend on it will need to be rebuilt with xlib6g, I guess. But anyway, I can keep all these around in woody for m68k (since they're all arch: any packages), even while upgrading all of: ii libxaw64.0.2-1X Athena widget set library (version 6) ii libxaw74.0.2-1X Athena widget set library ii xbase-clients 4.0.2-1miscellaneous X clients ii xdm4.0.2-1X display manager ii xfree86-common 4.0.2-1X Window System (XFree86) infrastructure ii xfs4.0.2-1X font server ii xlib6g 4.0.2-1pseudopackage providing X libraries ii xlibmesa3 4.0.2-1XFree86 version of Mesa 3D graphics library ii xlibs 4.0.2-1X Window System client libraries ii xnest 4.0.2-1nested X server ii xterm 4.0.2-1X terminal emulator It'll be a bit hacky, but it should work okay. So I can upload all but xserver-[common|fbdev] and nobody should get hurt? I think so. Branden? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 pgpmgN3oIy1pe.pgp Description: PGP signature
Re: XFree86 4.0.2 status
On Fri, Jan 12, 2001 at 05:22:13PM +0100, Christian T. Steigies wrote: On Fri, Jan 12, 2001 at 05:20:51PM +1000, Anthony Towns wrote: For reference: m68k is the only released architecture that doesn't have X4 uploaded yet. I know that. I figured. :) It was the bit after that I thought might be helpful :) At a guess, it's probably worthwhile uploading just the X client side of X4 for m68k, which should at least mean that if X4 is added to testing (woody), the only thing that'll be broken is the X server, rather than a thousand otherwise innocent packages... What is "the client side"? Everything but xserver-*? Should I just remove them from the changelog? Just a broken X server means you can not run X on m68k, right? I don't think thats too desirable. But after all the feedback from the m68k users on X4.0 was not very high, so maybe X4 in testing is worth mor ethan a broken X on m68k. Well, the X client libraries and the X server are separate. I'm by no means an X expert, but at worst I'd imagine it'd be possible to just maintain the old m68k xserver-fbdev package as part of xfree86v3. If necessary, I think I can hack around things and arrange to keep xserver-fbdev in woody until someone tells me otherwise, if that's helpful (it's part of the old xfree86-1 package as is the old xlib6g; keeping around one part of it and not another will probably turn out to be a bit awkward, but for the short term, it shouldn't be a problem). You'd have to check with Branden about any technicalities though, I've no idea. And naturally, having a working xserver-xfree86 would be a much simpler and better result in all counts... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 PGP signature
Re: XFree86 4.0.2 status
On Thu, Jan 11, 2001 at 03:04:54PM +0100, Christian T. Steigies wrote: And if the problem does not show up I will have a working X4.0 on m68k! So I hope you are right... but it seems I have to do a fresh build, or is there a way to regenerate the makefiles from the imakefiles easily? I can not start that before tomorrow, building glibc2.2 now, gcc-2.95.3 is next... For reference: m68k is the only released architecture that doesn't have X4 uploaded yet. X4 can't be added to any architectures until it's ready to be added to all architectures, because: * Installing xfree86.dsc into testing/i386 means installing the new xlib6g package from X4 which is binary-all. * Install a binary-all package into any architecture in a suite installs it into all architectures in that suite. * Installing X4's xlib6g on m68k means everything that depends on xlib6g is uninstallable (since xlib6g depends on xlibs which hasn't been uploaded for m68k) which amounts to 1000 odd packages. . At a guess, it's probably worthwhile uploading just the X client side of X4 for m68k, which should at least mean that if X4 is added to testing (woody), the only thing that'll be broken is the X server, rather than a thousand otherwise innocent packages... At the moment, btw, all the pre-tests for xfree86 are disabled (ie, RC bugs, how old it is, whether some of the binaries on some architectures are out of date compared to the source). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 pgpjvbmRFavSf.pgp Description: PGP signature
Re: XFree86 4.0.2 status
On Fri, Jan 12, 2001 at 05:22:13PM +0100, Christian T. Steigies wrote: On Fri, Jan 12, 2001 at 05:20:51PM +1000, Anthony Towns wrote: For reference: m68k is the only released architecture that doesn't have X4 uploaded yet. I know that. I figured. :) It was the bit after that I thought might be helpful :) At a guess, it's probably worthwhile uploading just the X client side of X4 for m68k, which should at least mean that if X4 is added to testing (woody), the only thing that'll be broken is the X server, rather than a thousand otherwise innocent packages... What is the client side? Everything but xserver-*? Should I just remove them from the changelog? Just a broken X server means you can not run X on m68k, right? I don't think thats too desirable. But after all the feedback from the m68k users on X4.0 was not very high, so maybe X4 in testing is worth mor ethan a broken X on m68k. Well, the X client libraries and the X server are separate. I'm by no means an X expert, but at worst I'd imagine it'd be possible to just maintain the old m68k xserver-fbdev package as part of xfree86v3. If necessary, I think I can hack around things and arrange to keep xserver-fbdev in woody until someone tells me otherwise, if that's helpful (it's part of the old xfree86-1 package as is the old xlib6g; keeping around one part of it and not another will probably turn out to be a bit awkward, but for the short term, it shouldn't be a problem). You'd have to check with Branden about any technicalities though, I've no idea. And naturally, having a working xserver-xfree86 would be a much simpler and better result in all counts... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 pgpWngeIsweMm.pgp Description: PGP signature
Re: XFree86 4.0.2 status
On Thu, Jan 11, 2001 at 03:04:54PM +0100, Christian T. Steigies wrote: And if the problem does not show up I will have a working X4.0 on m68k! So I hope you are right... but it seems I have to do a fresh build, or is there a way to regenerate the makefiles from the imakefiles easily? I can not start that before tomorrow, building glibc2.2 now, gcc-2.95.3 is next... For reference: m68k is the only released architecture that doesn't have X4 uploaded yet. X4 can't be added to any architectures until it's ready to be added to all architectures, because: * Installing xfree86.dsc into testing/i386 means installing the new xlib6g package from X4 which is binary-all. * Install a binary-all package into any architecture in a suite installs it into all architectures in that suite. * Installing X4's xlib6g on m68k means everything that depends on xlib6g is uninstallable (since xlib6g depends on xlibs which hasn't been uploaded for m68k) which amounts to 1000 odd packages. . At a guess, it's probably worthwhile uploading just the X client side of X4 for m68k, which should at least mean that if X4 is added to testing (woody), the only thing that'll be broken is the X server, rather than a thousand otherwise innocent packages... At the moment, btw, all the pre-tests for xfree86 are disabled (ie, RC bugs, how old it is, whether some of the binaries on some architectures are out of date compared to the source). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 PGP signature
Package pools, testing, 2.2r2
Hello world, debian-cd folk: 2.2r1 is final, even if that'll make some of the powerpc and security folk (justifiably) unhappy. If you'd like to update the potato CD images, that'd probably be a good thing. All who're interested: katie (ie, the new dinstall, ie package pools) will be rolled out when James has enough time to cope with any unforseen problems. Hopefully in the next week or two. testing will be rolled out shortly afterwards, in all probability. debian-cd folk: when katie is rolled out, the debian-cd scripts will probably break [0], it'd be very helpful if this can be fixed ASAP, otherwise we won't be able to provide official CDs for 2.2r2... Porters, X folks, etc: 2.2r2 is likely to come out relatively quickly. Please consider this as your notification, and upload any ports or security fixes or new versions that should make it into r2 sooner rather than later. For those who're interested: we'll see about handling 2.2r2 in a more transparent manner. I'll try to keep auric:~ajt/which-updates as an up to date list of which will get accepted and why others will get rejected, and have it posted automatically to -release once a week. Comments etc should go to -release. Cheers, aj [0] Since the Packages files will start referencing packages and sources in the pool, rather than under dists/potato/... This is actually unavoidable, but we'll try to make sure there are at least symlinks from dists/potato to the pool for anything missing, FWIW. The Packages/Sources files may or may not end up pointing at the symlinks rather than the pool. This will probably first happen sometime after the changeover, but will definitely happen during 2.2r2. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgpV51YoPdJPK.pgp Description: PGP signature
X4 xserver-xfree86 dependency information
Hello world, xfree86-xserver only has an unversioned dependency on xserver-common, but includes binaries linked to the new glibc. Presumably there's a shlib:Depends missing somewhere or something. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark PGP signature
X4 xserver-xfree86 dependency information
Hello world, xfree86-xserver only has an unversioned dependency on xserver-common, but includes binaries linked to the new glibc. Presumably there's a shlib:Depends missing somewhere or something. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark pgp62iEOveIK8.pgp Description: PGP signature
