Re: Future of X packages in Debian
On Fri, 18 Jun 2004, Matt Zimmerman wrote: > On Fri, Jun 18, 2004 at 10:34:09AM -0700, Keith Packard wrote: > > > I'd also like to see the fonts moved to arch any, I got side tracked > > attempting to switch from .pcf.gz to .ttf format, but there's no reason we > > can't simply compile to .pcf.gz on i386 and ship them from there -- every > > arch can load that format and the overhead is minimal (bitswapping on > > big-endian boxes). When upstream moves to .ttf, we will be ready. > > Point of Debian order here; what you (and I) want is arch "all" (build once > for all arches), rather than "any" (built for any one arch). > > This has been a long-standing wishlist request, which was languished because > (as I understand it), nobody wanted to futz with the imake build system > enough to make it possible, and I can't blame anyone for that. If the X.Org > build system makes this possible, then that's great. I have been working on this issue already. It is possible to build fonts as arch "all" with a small hack, but it still requires a bit of magic for a few Imake that gives life to man pages for scripts that are font related [0][1]. It is also in the TODO list for one of the next X uploads [2]. Fabio [0] http://lists.debian.org/debian-x/2004/04/msg01058.html [1] http://lists.debian.org/debian-x/2004/04/msg01060.html [2] http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/TODO -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Future of X packages in Debian
On Fri, 18 Jun 2004, Matt Zimmerman wrote: > I don't think that Fabio's message was an invitation to complain about X, > but a request for input on maintaining Debian's X packages in the future. Of course it was not an invitation to complain but, since 90% of the people did not even bother to read all the mail before replying, I don't see any point in spending my time on taking care of complains. Thanks Matt Fabio PS sorry for the cross post but i want to make my point clear from the beginning. If you want to rant to do it in a proper way. You have all the tools required for it. reportbug, apt-get source xfree86 and diff. -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Future of X packages in Debian
On Fri, Jun 18, 2004 at 04:31:58PM -0700, Matt Zimmerman wrote: > On Fri, Jun 18, 2004 at 09:49:44PM +0200, Wouter Verhelst wrote: > > On Fri, Jun 18, 2004 at 09:02:50AM +0200, Fabio Massimo Di Nitto wrote: > > > Our questions to the community are: > > > > > > * What kinds of X packages would you like to see in the future? > > > > Working ones. With as few (upstream and debian-specific) bugs as > > possible. > > > > Case at hand: I have yet to see the first XFree86 (server|module) and > > graphics board combination that > > * supports the full potential of the board > > * does not reproducably receive SIGSEGV > > * is free > > > > This is, of course, not the fault of the Debian X strike force, but it's > > painful none the less. > > I don't think that Fabio's message was an invitation to complain about X, > but a request for input on maintaining Debian's X packages in the future. I know, and I gave input. The above was an example to explain my point, not a complaint (if I thought I had to complain, I'd have done so a long time ago). The point was that I think if there's two competing X implementations, the X strike force should choose the one with the highest quality, not the one with the most features. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Bug#254632: xterm update results in worse thread view in mutt running inside a GNU screen
On Sat, Jun 19, 2004 at 03:28:22AM +0200, Adrian Bunk wrote: > > Is screen linked with termcap or curses? screen prefers the curses > > library (though that shouldn't make much difference). > > It's linked with the NetBSD curses library (recompiling screen with > GNU ncurses doesn't make a difference). That's a little useful to know: Inspecting the termcap, I didn't notice much except that the enacs terminfo string was missing. Reading screen's code, I see that it has some logic for inferring things related to enacs. (But I don't read it often, so I'm not familiar with the logic). > > Normally (using only the information in the termcap), once line-drawing > > has been done in the given window, it'll be initialized as it was before > > the bug-fix. From the information so far, I'm not sure whether it's > > not getting the initialization string, or if something is using direct > > escape sequences to turn the graphcs set off. > > Is there any way I can help to trace the problem down? What I generally do to get some insight is to run 'script' around the whole session and analyze the 'typescript' file. That would at least answer the question of whether screen or ssh was sending some string that turned line-drawing off, or whether none of them turned it on properly. (How that will help me reproduce the problem, I'm not sure). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpqSOSWaHydZ.pgp Description: PGP signature
Bug#255184: xfree86: Updated Danish debconf-po translation
Package: xfree86 Severity: normal Tags: patch l10n Please use the attached updated Danish debconf-po translation (debian/po/da.po) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: LANG=da_DK, LC_CTYPE=da_DK # debconf templates for xfree86 package # Danish translation # # $Id: da.po 1535 2004-06-15 17:03:25Z branden $ # # Copyrights: # Branden Robinson, 2000--2004 # Dennis Haney, 2002 # Morten Brix Pedersen <[EMAIL PROTECTED]>, 2003 # Claus Hindsgaul <[EMAIL PROTECTED]>, 2004 # # This file is distributed under the same license as the xfree86 package. # Please see debian/copyright. # #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # #Developers do not need to manually edit POT or PO files. # msgid "" msgstr "" "Project-Id-Version: xfree86_4.3.0-3_da\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2004-06-06 10:41-0500\n" "PO-Revision-Date: 2004-03-02 21:22+0100\n" "Last-Translator: Claus Hindsgaul <[EMAIL PROTECTED]>\n" "Language-Team: Danish <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=ISO-8859-1\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.0.2\n" #. Type: select #. Description #: ../xdm.templates:4 msgid "Select the desired default display manager." msgstr "Vælg den ønskede logindhåndtering." #. Type: select #. Description #: ../xdm.templates:4 msgid "" "A display manager is a program that provides graphical login capabilities " "for the X Window System." msgstr "" "En logindhåndtering er et program der giver et grafisk logind til X Window-" "systemet." #. Type: select #. Description #: ../xdm.templates:4 msgid "" "Only one display manager can manage a given X server, but multiple display " "manager packages are installed. Please select which display manager should " "run by default." msgstr "" "Der kan kun køre én logindhåndtering for hver X-server, men der er " "installeret flere logindhåndteringer Vælg hvilken logindhåndtering der skal " "benyttes som standard." #. Type: select #. Description #: ../xdm.templates:4 msgid "" "(Multiple display managers can run simultaneously if they are configured to " "manage different servers; to achieve this, configure the display managers " "accordingly, edit each of their init scripts in /etc/init.d, and disable the " "check for a default display manager.)" msgstr "" "(Flere logindhåndteringer kan køre samtidig. hvis de er sat op til at " "håndtere forskellige servere. For at få dette til at fungere, skal " "logindhåndteringenerne sættes op til det. Det gør du ved at fjerne tjekket " "for standard logindhåndtering i deres initialiseringsskripter i /etc/init.d.)" #. Type: string #. Description #: ../xdm.templates:26 msgid "Do you wish to stop the xdm daemon?" msgstr "Vil du stoppe xdm-dæmonen?" #. Type: string #. Description #: ../xdm.templates:26 msgid "" "The X display manager (xdm) daemon is typically stopped on package upgrade " "and removal, but it appears to be managing at least one running X session. " "If xdm is stopped now, any X sessions it manages will be terminated. " "Otherwise you may leave xdm running, and the new version will take effect " "the next time the daemon is restarted." msgstr "" "X-logindhåndteringsdæmonen (xdm) stoppes typisk under opgradering eller " "fjernelse af pakken, men det ser ud til at der allerede kører mindst én X-" "session. Hvis xdm bliver stoppet nu, vil alle de X-sessioner, den håndterer, " "blive afbrudt. Ellers kan du lade xdm køre, så den nye version først bliver " "taget i brug næste gang dæmonen bliver genstartet." #. Type: note #. Description #: ../xfree86-common.templates:3 msgid "experimental version of XFree86 packages" msgstr "eksperimentel version af XFree86-pakkerne" #. Type: note #. Description #: ../xfree86-common.templates:3 msgid "" "You are using an experimental version of XFree86 packages for Debian. " "Please do not file bugs with the Debian Bug Tracking System against this " "version of the packages, since they have not been released to the Debian " "distribution yet." msgstr "" "Du bruger en eksperimentel version af Debians XFree86-pakker. Du bedes " "undlade at rapportere fejl imod Debian fejlrapporteringssystemet, når du " "bruger denne version af pakkerne, da de ikke er blevet udgivet til Debian-" "distributionen endnu." #. Type: note #. Description #: ../xfree86-common.templates:3 msgid "" "If you experience problems with these packages or would like to submit " "patches, please send mail to the Debian X mailing list.
Re: Future of X packages in Debian
>> * What kinds of X packages would you like to see in the future? I hope to realize (upstream) source level separation for each libraries, X server, drivers, x basic clients, fonts, misc data and so on. To maintain monolithic, large source tree (likes current xfree86 package) is too hard. >> * Should we regard X.Org or FreeDesktop.Org as our upstream source? Yes, I think so. fd.o's modualized X libraries and servers is one of the answer to realize small (upstream level) separated X packages. >> * Should we go our own way starting from the "sanitized" XFree86 CVS >> snapshot we've prepared? Yes and No (this answer is related next question.) >> * Should we ensure that multiple implementations of the X Window System >> are packaged, or standardize on just one? If we can separate upstream source tree, I think... - We should have only one implemantation for each X client-side libraries, perhaps it is based on X.org's or fd.o's implementation. - We can have multiple X server implemantations for a various purposes, fd.o kdriver base, debrix base and so on. If someone want to use XFree86 based X server, he(they) will be able to continue to work for XFree86 based X server. >> * If we standardize on just one, which one should it be? I think fd.o's modualized implemantation is the best solution. -- ISHIKAWA Mutsumi <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Bug#255192: Alt-Tab switching broken in dfsg.1-5
Subject: Alt-Tab switching broken in dfsg.1-5 Package: xlibs Version: 4.3.0.dfsg.1-5 Severity: important Tags: sid Hi, when upgrading x from dfsg.1-4 to -5, the handy Alt-Tab "Task switching" ceases to function on a KDE machine as well as on a Gnome/metacity machine. One has r128, the other has a radeon. Downgrading only the xlibs package to dfsg.1-4 and restarting X cures it. The systems are both otherwise sid. Detailed behavior / steps to reproduce: * Hold alt, press tab -> Task selector appears, OK * repeatedly press tab -> switches between windows as usual * release tab -> focus leaves current window, so far OK, but -> focus does not hit selected window. same behavior when omitting the second step. I cannot see any entry in the Debian changelog that looks like it could have anything to do with this bug. Is there any kind of further testing (xev) that you would like me to perform? Is there any other information I can gather for you? Thanks anyway for the fine work so far. brgds Kevin -- Package-specific info: Keyboard-related contents of XFree86 X server log file /var/log/XFree86.0.log: (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Default Layout" (**) |-->Screen "Screen" (0) (**) | |-->Monitor "F700P" (**) | |-->Device "Rage 128" (**) |-->Input Device "Keyboard" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "de" (**) XKB: layout: "de" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Mouse" (WW) `fonts.dir' not found (or not valid) in "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID". Entry deleted from font path. (Run 'mkfontdir' on "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID"). (WW) The directory "/usr/lib/X11/fonts/CID" does not exist. -- (II) R128(0): Direct rendering disabled (==) RandR enabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension LBX (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Keyboard "Keyboard" handled by legacy driver (**) Option "Protocol" "ImPs/2" (**) Mouse: Protocol: "ImPs/2" (**) Option "CorePointer" (**) Mouse: Core Pointer (**) Option "Device" "/dev/psaux" Keyboard-related contents of XFree86 X server log file /var/log/XFree86.20.log: (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Default Layout" (**) |-->Screen "Screen" (0) (**) | |-->Monitor "Monitor" (**) | |-->Device "Device" (**) |-->Input Device "Keyboard" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "de" (**) XKB: layout: "de" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Mouse" (WW) The directory "/usr/lib/X11/fonts/CID" does not exist. Entry deleted from font path. (WW) The directory "/usr/lib/X11/fonts/cyrillic" does not exist. Entry deleted from font path. -- (II) R128(0): Direct rendering disabled (II) Setting vga for screen 0. (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension LBX (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Keyboard "Keyboard" handled by legacy driver (**) Option "Protocol" "ImPs/2" (**) Mouse: Protocol: "ImPs/2" (**) Option "CorePointer" (**) Mouse: Core Pointer (**) Option "Device" "/dev/psaux" Keyboard-related contents of XFree86 X server log file /var/log/XFree86.8.log: (==) ServerLayout "XFree86 Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Keyboard: CustomKeycode disabled (WW) The directory "/usr/X11R6/lib/X11/fonts/CID/" does not exist. Entry deleted from font path. (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (**) ModulePath set to "/usr/X11R6/lib/modules" -- (II) R128(0): Direct rendering disabled (==) RandR enabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initia
debian-x@lists.debian.org
Package: xterm Version: 4.3.0.dfsg.1-5 Severity: normal Tags: l10n -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.6-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages xterm depends on: ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig12.2.2-2generic font configuration library ii libfreetype6 2.1.7-2.1 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-5 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsm64.3.0.dfsg.1-5 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-5 X Athena widget set library ii libxext6 4.3.0.dfsg.1-5 X Window System miscellaneous exte ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-5 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-5 X pixmap library ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxt64.3.0.dfsg.1-5 X Toolkit Intrinsics ii xlibs 4.3.0.dfsg.1-5 X Window System client libraries m ii xlibs-data4.3.0.dfsg.1-5 X Window System client data -- debconf information excluded
Re: Future of X packages in Debian
* Keith Packard <[EMAIL PROTECTED]> [2004-06-18 10:34]: > > * Should we regard X.Org or FreeDesktop.Org as our upstream source? > > I'd like to consider X.Org as upstream for libraries and headers; however, > I'd also like to wait until X.Org has managed to switch to a modular build > system so that the monolithic release problem can be solved easily. I thought X.Org was the monolithic while FreeDesktop.Org the modular release. Since you mention X.Org and the monolithic release, I guess this is not correct. Can you explain the difference between X.Org and FreeDesktop.Org? -- Martin Michlmayr [EMAIL PROTECTED]
Bug#255197: euh... to make it clear!
Apologize for the messy bug report (not even capable of using reportbug correctly!! :'( ) The exact problem come from /usr/bin/uxterm during the locale checking: case $value in *.utf8|*.UTF8|*.utf-8|*.UTF-8) found=yes ;; this does not include "@euro" extension. so maybe: case $value in *.utf8*|*.UTF-8*|*.utf-8*|*.UTF-8*) found=yes ;; (or something considered clean, i'm not at all a developer...) Sorry again for the awful submit i've made... Matthieu Lagouge
Re: Future of X packages in Debian
* Fabio Massimo Di Nitto <[EMAIL PROTECTED]> [2004-06-18 09:02]: > * Should we regard X.Org or FreeDesktop.Org as our upstream source? Yes, I'd go with one of them. Keith Packard is also in the NM queue and interested in helping out. > * Should we go our own way starting from the "sanitized" XFree86 CVS > snapshot we've prepared? I think this would be a really bad idea. I think it would be much better to try to get all of our patches integrated upstream, and I hear that the new upstream people (X.Org/FreeDesktop.Org) are much more interested in integrating porting patches than XFree86 was. Since Keith Packard is also on our lists, I hope that he'll help with forwarding patches upstream and getting them integrated. -- Martin Michlmayr [EMAIL PROTECTED]
Bug#255197: uxterm doesn't consider utf-8@euro
The uxterm script detect "*.[utf|UTF]-8"... and not "*.[utf|[EMAIL PROTECTED]". So applications say "locale not supported" Reply-To: In-Reply-To: <[EMAIL PROTECTED]> On Sat, Jun 19, 2004 at 03:30:14PM +0200, Matthieu Lagouge wrote: > Package: xterm > Version: 4.3.0.dfsg.1-5 > Severity: normal > Tags: l10n hmm - I have 4.3.0.dfsg.1-4 installed, as well as a [EMAIL PROTECTED] locale for testing - that seems to work (and afaik uxterm hasn't been patched). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpW0AfAZpTFh.pgp Description: PGP signature
Re: Future of X packages in Debian
On Sat, Jun 19, 2004 at 02:15:26PM +0100, Martin Michlmayr wrote: > * Keith Packard <[EMAIL PROTECTED]> [2004-06-18 10:34]: > > > * Should we regard X.Org or FreeDesktop.Org as our upstream source? > > > > I'd like to consider X.Org as upstream for libraries and headers; however, > > I'd also like to wait until X.Org has managed to switch to a modular build > > system so that the monolithic release problem can be solved easily. > > I thought X.Org was the monolithic while FreeDesktop.Org the modular > release. Since you mention X.Org and the monolithic release, I guess > this is not correct. Can you explain the difference between X.Org and > FreeDesktop.Org? Well, X.Org currently only has X11R6.7, which is forked from XFree86 4.4RC2, but with some SI-tree changes (mainly from Sun merged), but there is a fork of that tree[0] called 'debrix', which is an all-modular build, but builds the same server, but with a completely incompatible driver loader (libdl), and all drivers built out-of-tree. freedesktop.org has the 'xserver' tree, which contains KDrive (usually referred to as 'the fd.o xserver'), but it is also capable of building XWin (Cygwin/X), and Xizzle DDXes - Xizzle being a fork of the Xorg DDX (xc/programs/Xserver/hw/xfree86, as opposed to all of xc/programs/Xserver), that builds modularly, but using the xserver/KDrive DIX. Unfortunately this didn't work out too well, so Xizzle is deprecated in favour of Debrix, despite having a cooler name. Geddit? [0]: Well, two; you'll see later. -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: Future of X packages in Debian
On Fri, Jun 18, 2004 at 09:02:50AM +0200, Fabio Massimo Di Nitto wrote: > As you might have seen from the messages on debian-devel-changes, > 4.3.0.dfsg.1-5 has been accepted into unstable. > > As XSF release manager, I have no objections to the TODO list for -6 [0], > but there is one item that we consider extremely important and that, in > our opinion, requires the community attention, since it is a *hot* > argument that many other distributions have already faced [1][2] or are > facing now. > > (reason for the cross posting and set your follow-up to debian-x please) > > * Add FAQ entry describing Debian's plans in the X department. > > We all know by now that due to several licensing-related issues we cannot > keep using XFree86 as our primary upstream source for an X Window System > distribution [3]. But we need a clear plan before we can add a FAQ entry > describing our plans. Some XSF memebers have already expressed their > opinion on what the future of X in Debian should be. > > Our questions to the community are: I've put a couple of short answers below, with a longer spiel under that. > * What kinds of X packages would you like to see in the future? Modular, but that's not achievable now. > * Should we regard X.Org or FreeDesktop.Org as our upstream source? Both. > * Should we go our own way starting from the "sanitized" XFree86 CVS > snapshot we've prepared? No. > * Should we ensure that multiple implementations of the X Window System > are packaged, or standardize on just one? If there's merit, sure. If it's unnecessary and will just cause pain, no. Make it optional, but don't do it just for the sake of it. > * If we standardize on just one, which one should it be? An X server approximating the one from X11R6.7, no matter which build system. Let's start out with an unemotional dissection of the facts: * XFree86 has a licence we cannot work with. * The monloithic tree is very, very large; updating to major releases is a great deal of effort, and you must be careful about what you upload. Needing to maintain a platform's details in imake makes things difficult - it duplicates work. Ditto the MetroLink loader; this goes for both XFree86 and Xorg. * The modular tree, as it stands, is not quite ready for adoption yet[0]. We have not yet worked out how to achieve XFree86-ELF<->libdl binary compatibility (or not really tried, either way), and porting of extensions is still not finalised. However, the libraries are fine. * KDrive does not offer the maturity and driver support Debian needs; it also doesn't do stuff like DRI yet. I think we can all agree here; I hope, anyway. I personally have an affinity for the modular tree, as it solves many problems; my bias here being that I'm a (currently, paid) developer on it. Here are the possibilities: Libs: * fd.o - needs libX11 merged, and a couple more client-side libs. Other than that, fine. Uses autotools; one module per library/extension. * X.Org - monolithic tree with imake. IPv6 support. * XFree86 - monolithic tree with imake. Server: * X.Org - monolithic tree with imake. IPv6 support. DRI tree merged in CVS. * XFree86 - monolithic tree with imake. * debrix - modular tree with autotools, comes from X.Org tree. No GL support as yet (that part of the world is particularly nasty WRT imake hackage). Apps: * X.Org/XFree86 - monolithic tree with imake. * fd.o - modular tree with autotools; not that many apps merged yet. Fonts: * X.Org/XFree86 - monolithic tree with imake. Docs: * X.Org/XFree86 - monolithic tree with imake. As can be seen here, the operational word for modular is 'not there yet'. The libX11 changes made in X.Org in the run-up to R6.7 still need to be merged (I'm hoping to get to that this weekend), and it still needs a few libs, such as libXvMC, but is rounding out very quickly. Most libs are relatively trivial to add. Fonts and docs are a clear decision: the monolithic tree is the only provider of these. Despite best intentions (and efforts), most apps are still only available in the monolithic tree. The server arena is where it gets interesting - it's where we have the most to gain, but the most to lose. debrix is a quite ambitious proof-of-concept, aiming to prove three concepts: a) modular builds for servers work (proved), b) dlloader works/can be made to work (proved), c) out-of-tree builds for drivers work (proved). Right now it builds a working ATI driver (out-of-tree) with working acceleration, but there are a couple of unavoidable ABI (and API) changes[1], which means no nvidia_drv.o, and no fglrx. It also hasn't had most of the drivers ported over to the new modular infrastructure, so strike on that count. No DRI, either. It's pre
Bug#255197: uxterm doesn't consider utf-8@euro
Le sam 19/06/2004 à 16:13, Thomas Dickey a écrit : > The uxterm script detect "*.[utf|UTF]-8"... and not > "*.[utf|[EMAIL PROTECTED]". So applications say "locale not supported" > Reply-To: > In-Reply-To: <[EMAIL PROTECTED]> > > On Sat, Jun 19, 2004 at 03:30:14PM +0200, Matthieu Lagouge wrote: > > Package: xterm > > Version: 4.3.0.dfsg.1-5 > > Severity: normal > > Tags: l10n > > hmm - I have 4.3.0.dfsg.1-4 installed, as well as a [EMAIL PROTECTED] locale > for testing - that seems to work (and afaik uxterm hasn't been patched). I've got it! On my system, fr_FR.UTF-8 is NOT supported (i've suppressed it while 'dpkg-reconfigure locale' don't ask me why i've done that now, i still wonder...). The uxterm script fall back to fr_FR.UTF-8 because [EMAIL PROTECTED] doesn't match the verification expression, so the system complains. Here are my experiments: with original unpatched uxterm: $ export LC_ALL=fr_FR.UTF-8 $ uxterm Warning: locale not supported by C library, locale unchanged In the uxterm window, locale show LC_ALL=fr_FR.UTF-8. $ export [EMAIL PROTECTED] $ uxterm Warning: locale not supported by C library, locale unchanged In the uxterm window, locale show LC_ALL=fr_FR.UTF-8 again!! Now, editing /usr/X11R6/bin/uxterm replacing *.UTF-8 with *.UTF-8* $ export LC_ALL=fr_FR.UTF-8 $ uxterm Warning: locale not supported by C library, locale unchanged that's ok according to my system $ export [EMAIL PROTECTED] $ uxterm No error message, in the uxterm window, now [EMAIL PROTECTED] !!
Bug#255224: xlibs-data: Patch for bug of ct_encoding sequence in zh_CN.gbk locale
Package: xlibs-data Version: 4.3.0-7 Severity: normal Tags: patch It has been fixed in official XFree86, see http://bugs.xfree86.org/show_bug.cgi?id=1362 for more detail. Thanks. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.2-1-k7 Locale: LANG=zh_CN, LC_CTYPE=zh_CN (ignored: LC_ALL set to zh_CN.GBK) -- no debconf information -- SU Yong cd /tmp/xfree86-4.3.0.dfsg.1/build-tree/xc/nls/XLC_LOCALE/ diff -c /tmp/xfree86-4.3.0.dfsg.1/build-tree/xc/nls/XLC_LOCALE/zh_CN.gbk /tmp/xfree86-4.3.0.dfsg.1/build-tree/xc/nls/XLC_LOCALE/zh_CN.gbk.orig *** /tmp/xfree86-4.3.0.dfsg.1/build-tree/xc/nls/XLC_LOCALE/zh_CN.gbk 2004-06-19 23:58:58.0 +0800 --- /tmp/xfree86-4.3.0.dfsg.1/build-tree/xc/nls/XLC_LOCALE/zh_CN.gbk.orig 2004-06-19 23:55:44.0 +0800 *** *** 62,68 byte2 \x40,\x7e;\x80,\xfe wc_encoding \x8000 ! ct_encoding GBK-0:GLGR:\x1b\x25\x2f\x32 mb_conversion [\x8140,\xfefe]->\x0140 ct_conversion [\x0140,\x7efe]->\x8140 --- 62,68 byte2 \x40,\x7e;\x80,\xfe wc_encoding \x8000 ! ct_encoding GBK-0:GLGR:\x1b\x25\x2f\x32\x80\x88\x47\x42\x4b\x2d\x30\x02 mb_conversion [\x8140,\xfefe]->\x0140 ct_conversion [\x0140,\x7efe]->\x8140 Diff finished at Sun Jun 20 00:06:42
Bug#233001: xserver-xfree86: [tseng] ET4000/W32p only works with vesa or vga
Branden, Please find attached my revision 1373 /var/log/XFree86.0.log. Same problem :-( On Fri, May 14, 2004 at 05:22:05PM -0500, Branden Robinson wrote: [snip] > > > You appear to have a motherboard that the PCI bus handling code in > > > XFree86 4.3.0 doesn't deal with well; a lot of "phantom" buses show up, > > > and this *may* be confusing the X server into not knowing where to find > > > your video card. > > > > My mainboard is a Gigabyte GA-5AA and CPU is AMD-K6-3/450. > > /proc/pci has the video card OK: > > > > Bus 0, device 8, function 0: > > VGA compatible controller: Tseng Labs Inc ET4000/W32p rev C (rev 0). > > IRQ 11. > > Non-prefetchable 32 bit memory at 0xef00 [0xefff]. > > > > Works OK with xfree86 3.3.6. > > Yeah, the PCI bus logic was extensively overhauled in 4.x. > > > I have not built xfree86 before. I read your instructions and I think > > I should be able to follow them sometime in June. > > Since I last mailed you, I have committed the following to the Debian > XFree86 SVN trunk: > > r1373 | branden | 2004-05-10 13:39:21 -0500 (Mon, 10 May 2004) | 17 lines > > Update (from XFree86 CVS, 2003-12-18) the XFree86 X server's PCI bus > handling code and device recognition databases from CVS. Resync patch > #452. Delete superseded patch #453. > + Simplify internal interfaces in the PCI code and remove the Xserver's > interference with normal PCMCIA operation (Marc La France). > + Fixed typo in getPciBiosTypes() (Bugzilla #382, Jakub Bogusz). > + Change DEVID macro to work around glitch in SCO's C compiler (Marc La > France). > + Fixed support for 64bit PCI bus on 32bit systems (Egbert Eich). > + Be a little more precise about differentiating between active and > inactive non-video PCI resources (Marc La France). > + Fix bug in detection of multi-function PCI devices (Marc La France, in > partial resolution of Bugzilla #574). > + Rip out incorrect limits on the number of PCI buses an ix86 chipset can > handle and implement an improved solution for avoiding "phantom" PCI > buses (Marc La France, Bugzilla #604). > > That last item may hold out some hope for your motherboard. > > -- > G. Branden Robinson|Imagination was given man to > Debian GNU/Linux |compensate for what he is not, and > [EMAIL PROTECTED] |a sense of humor to console him for > http://people.debian.org/~branden/ |what he is. -- Regards, Ian Maclaine-cross <[EMAIL PROTECTED]> GnuPG key fingerprint = 5F7A 7539 EA0D F4B4 95D3 0D22 A8BB B366 1D1D FB53 This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender and are not necessarily the views of UNSW. This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-1+SVO 20040619043245 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.26-1-686 i686 [ELF] Build Date: 19 June 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.4.26-1-k6 ([EMAIL PROTECTED]) (gcc version 3.3.3 (Debian 20040401)) #1 Sat May 1 20:32:03 EST 2004 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Sun Jun 20 01:55:31 2004 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Generic Monitor" (**) | |-->Device "ViewTop_BP-ET4" (**) |-->Input Device "Generic Keyboard" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc104" (**) XKB: model: "pc104" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Configured Mouse" (**) |-->Input Device "Generic Mouse" (WW) The directory "/usr/lib/X11/fonts/cyrillic" does not exist. Entry deleted from font path. (WW) The directory "/usr/lib/X11/fonts/CID" does not exist. Entry deleted from font path. (**) FontPath set to "unix/:7100,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath
Bug#255197: uxterm doesn't consider utf-8@euro
On Sat, Jun 19, 2004 at 05:53:02PM +0200, Matthieu Lagouge wrote: > Le sam 19/06/2004 ? 16:13, Thomas Dickey a ?crit : > > The uxterm script detect "*.[utf|UTF]-8"... and not > > "*.[utf|[EMAIL PROTECTED]". So applications say "locale not supported" > > Reply-To: > > In-Reply-To: <[EMAIL PROTECTED]> > > > > On Sat, Jun 19, 2004 at 03:30:14PM +0200, Matthieu Lagouge wrote: > > > Package: xterm > > > Version: 4.3.0.dfsg.1-5 > > > Severity: normal > > > Tags: l10n > > > > hmm - I have 4.3.0.dfsg.1-4 installed, as well as a [EMAIL PROTECTED] locale > > for testing - that seems to work (and afaik uxterm hasn't been patched). > > I've got it! > > On my system, fr_FR.UTF-8 is NOT supported (i've suppressed it while > 'dpkg-reconfigure locale' don't ask me why i've done that now, i still > wonder...). > The uxterm script fall back to fr_FR.UTF-8 because [EMAIL PROTECTED] > doesn't match the verification expression, so the system complains. thanks - I recall the original request for handling @euro was to strip it off (looks like it isn't necessarily what's needed). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpjafcO5klwQ.pgp Description: PGP signature
Re: Future of X packages in Debian
Around 14 o'clock on Jun 19, Martin Michlmayr wrote: > I thought X.Org was the monolithic while FreeDesktop.Org the modular > release. Since you mention X.Org and the monolithic release, I guess > this is not correct. Can you explain the difference between X.Org and > FreeDesktop.Org? The current X.Org release (6.7) is monolithic. And, it may be that the next release (6.7.1? 6.8?) will be monolithic as well. There are many people interested in seeing X.Org move to a modular structure, as well as a few dinosaurs interested in preserving their existing world views. Unfortunately, the most vociferous dinosaur, Egbert Eich, is also a very important maintainer. The biggest migration issue is the transition from imake to autotools; imake just can't handle a modular environment and so must either be radically altered or replaced. I don't know of anyone seriously interested in spending the effort needed to make 'imake' do this, and I know of many people (myself included) who would like to rid the world of it forever. If autotools were really dramatically better, this would be a no-brainer, alas they are only differently disabled, making transition from imake something of a learning experience for all involved. The projects I started at freedesktop before X.Org decided to do their own release were (originally) strictly for my own research efforts. Of course I made them work the way I wanted using autotools and a very modular environment. Many other people have joined in to help efforts in this tree. A few have started exploring how to build the XFree86-based modular driver architecture within the X server, including replacing the custom ELF/COFF loader with dlopen. That work is now actually making progress; things seem to be coming together and you can run that server with at least two of the drivers. So, the big question is how to get everyone back into a single tree. Ideally, Egbert would let us just ditch the imake build system and move X.Org to autotools in one big jump; we have almost all of the build infrastructure ready and waiting in my 'research' trees. Alternatively, we would slowly modify the X.Org tree imake build infrastructure so that we could lay a modular autotools build system alongside and build either way. That's the current plan, but no-one has gotten started doing the work; I was going to look into it, but I really have other things I think I should be working on instead. One thing is clear -- the disagreements among the participants are amiable and there is a strong desire to make the build system work for everyone with a minimum of pain, and an absolute resolve to get to a single tree that is DFSG free as well as GPL compatible. -keith pgpIkcvynJQJh.pgp Description: PGP signature
Re: Future of X packages in Debian
On Sat, Jun 19, 2004 at 10:28:20AM -0700, Keith Packard wrote: > Many other people have joined in to help efforts in this tree. A few > have started exploring how to build the XFree86-based modular driver > architecture within the X server, including replacing the custom ELF/COFF > loader with dlopen. That work is now actually making progress; things > seem to be coming together and you can run that server with at least two > of the drivers. This was debrix, as I mentioned before - Adam Jackson helped with the loader stuff, but it's all been blocking on me, mostly. Which kind of sucks. Packaging gets done when I'm not working upstream, and vice versa. I'm stuck in the middle of dragging over DRI right now. > So, the big question is how to get everyone back into a single tree. > Ideally, Egbert would let us just ditch the imake build system and move > X.Org to autotools in one big jump; we have almost all of the build > infrastructure ready and waiting in my 'research' trees. > > Alternatively, we would slowly modify the X.Org tree imake build > infrastructure so that we could lay a modular autotools build system > alongside and build either way. That's the current plan, but no-one has > gotten started doing the work; I was going to look into it, but I really > have other things I think I should be working on instead. I'm honestly not sure how well that would work in practice, given the complex interdependencies. -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
X Strike Force XFree86 SVN commit: r1554 - in trunk/debian: . po
Author: branden Date: 2004-06-19 16:59:19 -0500 (Sat, 19 Jun 2004) New Revision: 1554 Modified: trunk/debian/CHANGESETS trunk/debian/changelog trunk/debian/po/da.po Log: Update Danish debconf template translations (thanks, Claus Hindsgaul). (Closes: #255184) Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-06-19 02:41:35 UTC (rev 1553) +++ trunk/debian/CHANGESETS 2004-06-19 21:59:19 UTC (rev 1554) @@ -32,4 +32,8 @@ information accordingly. 1543 +Update Danish debconf template translations (thanks, Claus Hindsgaul). +(Closes: #255184) +1554 + vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-06-19 02:41:35 UTC (rev 1553) +++ trunk/debian/changelog 2004-06-19 21:59:19 UTC (rev 1554) @@ -20,8 +20,11 @@ /usr/share/doc/xterm/xterm.faq.text.gz. Update xterm's doc-base information accordingly. - -- Branden Robinson <[EMAIL PROTECTED]> Tue, 15 Jun 2004 16:31:22 -0500 + * Update Danish debconf template translations (thanks, Claus Hindsgaul). +(Closes: #255184) + -- Branden Robinson <[EMAIL PROTECTED]> Sat, 19 Jun 2004 16:57:06 -0500 + xfree86 (4.3.0.dfsg.1-5) unstable; urgency=low Changes by Branden Robinson: Modified: trunk/debian/po/da.po === --- trunk/debian/po/da.po 2004-06-19 02:41:35 UTC (rev 1553) +++ trunk/debian/po/da.po 2004-06-19 21:59:19 UTC (rev 1554) @@ -614,20 +614,20 @@ #. Type: string #. Description #: ../xserver-xfree86.templates:147 -#, fuzzy msgid "" "Users of PowerPC machines, and users of any computer with multiple video " "devices, should specify the BusID of the video card in an accepted bus-" "specific format." msgstr "" "Brugere af PowerPC-maskiner og brugere af enhver computer med flere " -"grafikkort skal angive grafikkortets bus-ID med f�lgende format:" +"grafikkort skal angive grafikkortets BusID i et accepteret busspecifikt " +"format." #. Type: string #. Description #: ../xserver-xfree86.templates:147 msgid "Examples:" -msgstr "" +msgstr "Eksempler:" #. Type: string #. Description @@ -637,6 +637,9 @@ " PCI:0:16:0\n" " SBUS:/[EMAIL PROTECTED],1000/[EMAIL PROTECTED],10001000/SUNW,[EMAIL PROTECTED],80" msgstr "" +" ISA:1\n" +" PCI:0:16:0\n" +" SBUS:/[EMAIL PROTECTED],1000/[EMAIL PROTECTED],10001000/SUNW,[EMAIL PROTECTED],80" #. Type: string #. Description @@ -658,6 +661,9 @@ "supported, should specify simply \"1\" here. (This is not guaranteed to " "work.)" msgstr "" +"Brugere af SGI Indigo2 XL-maskiner eller maskiner med andre busser, der " +"endnu ikke underst�ttes fuldt ud, skal blot skive \"1\" her. (Det er ingen " +"garanti for at det vil virke.)" #. Type: string #. Description @@ -684,13 +690,12 @@ #. Type: string #. Description #: ../xserver-xfree86.templates:147 -#, fuzzy msgid "" "Users of machines other than PowerPCs or SGI Indigo2 XLs with only one video " "card should leave this entry blank." msgstr "" -"Brugere af ikke-PowerPC maskiner med kun et grafikkort skal ikke skrive " -"noget her." +"Brugere af andre maskiner end PowerPC og SGI Indigo2 XL'er med kun �t " +"grafikkort skal ikke skrive noget her." #. Type: note #. Description @@ -702,7 +707,7 @@ #. Description #: ../xserver-xfree86.templates:178 msgid "The BusID entered was not in a recognized format." -msgstr "" +msgstr "Den angivne BusID er ikke i et genkendeligt format." #. Type: string #. Description @@ -1588,29 +1593,3 @@ #: ../xserver-xfree86.templates:531 msgid "Characters other than digits are not allowed in the entry." msgstr "Andre tegn end cifre er ikke tilladt her." - -#~ msgid "PCI:nn:nn:nn" -#~ msgstr "PCI:nn:nn:nn" - -#~ msgid "" -#~ "(where each nn is a decimal number referring to the card's bus, device, " -#~ "and function number, respectively)." -#~ msgstr "" -#~ "(Hvor nn er heltal der refererer til hhv. kortets bus-, enheds- og " -#~ "funktionsnumre)" - -#~ msgid "The BusID should be a string in the following format:" -#~ msgstr "Bus-ID'er skal v�re en streng i f�lgende format:" - -#~ msgid "bustype:bus:device:function" -#~ msgstr "bustype:bus:enhed:funktion" - -#~ msgid "" -#~ "Where \"bustype\" is \"PCI\" for PCI and AGP video cards, and each of " -#~ "\"bus\", \"device\", and \"function\" is a decimal (not hexadecimal) " -#~ "value. For example, \"PCI:0:16:0\" is valid input (without the double-" -#~ "quotes)." -#~ msgstr "" -#~ "Hvor \"bustype\" er \"PCI\" for PCI- og AGP-grafikkort, og \"bus\", " -#~ "\"enhed\" og \"funktion\" er heltal (ikke hexadecimalt). F.eks. er" -#~ "\"PCI:0:16:0\" gyldigt (uden g�se�jnene)."
Bug#255270: xfree86: libglide3 has now ia64 and amd64 support
Package: xfree86 Version: 4.3.0.dfsg.1-5 Severity: wishlist Tags: patch Hi, I've ported libglide3 to amd64 and ia64. So now xfree86 can Build-Depend on libglide3-dev on those arches. Attached the patch (against branches/4.3.0/sid) that enables those. regards, guillem Index: debian/control === --- debian/control (revision 1553) +++ debian/control (working copy) @@ -4,7 +4,7 @@ Maintainer: Debian X Strike Force Uploaders: Branden Robinson <[EMAIL PROTECTED]>, Fabio M. Di Nitto <[EMAIL PROTECTED]> Standards-Version: 3.6.1 -Build-Depends: dpkg (>= 1.7.0), flex, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (>= 4.1.16), html2text, libglide2-dev (>> 2001.01.26) [i386], libglide3-dev (>= 2002.04.10-3) [alpha i386], linux-kernel-headers [alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sh], linux-kernel-headers (>= 2.5.999-test7-bk-15) [sparc], libpng12-dev | libpng-dev, libexpat1-dev, libfontconfig1-dev, fontconfig, bzip2, libxft-dev (>= 2.1.2), libxrender-dev (>= 0.8.3), libxcursor-dev, dbs, m4 +Build-Depends: dpkg (>= 1.7.0), flex, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (>= 4.1.16), html2text, libglide2-dev (>> 2001.01.26) [i386], libglide3-dev (>= 2002.04.10-7) [alpha i386 ia64 amd64], linux-kernel-headers [alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sh], linux-kernel-headers (>= 2.5.999-test7-bk-15) [sparc], libpng12-dev | libpng-dev, libexpat1-dev, libfontconfig1-dev, fontconfig, bzip2, libxft-dev (>= 2.1.2), libxrender-dev (>= 0.8.3), libxcursor-dev, dbs, m4 Build-Conflicts: cpp-3.3 (<< 1:3.3.3-0pre1) Package: lbxproxy
Processed: tagging 255184
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.7.95.1 > # fixed in Debian X Strike Force XFree86 repository; to view, run "svn diff > -r 1553:1554 svn://necrotic.deadbeast.net/xfree86" > tags 255184 + pending Bug#255184: xfree86: Updated Danish debconf-po translation Tags were: l10n patch Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#255282: xserver-xfree86: [libGLcore.a] Skipping -- No symbols found
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-5 Severity: normal I'm working on Mesa, specificaly getting DRI to work on this mach64. I have an i386 box with a simular chip and it workes well. I don't think that has anything todo with DRI, I think it's only for glx(remote/indirect) clients. (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_clip.o": No symbols found Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_norm.o": No symbols found Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_xform.o": No symbols found Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_vertex.o": No symbols found (II) Module GLcore: vendor="The XFree86 Project" -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx1 root root 20 Dec 25 18:47 /etc/X11/X -> /usr/bin/X11/XFree86 -rwxr-xr-x1 root root 1783088 Jun 16 19:53 /usr/bin/X11/XFree86 Contents of /var/lib/xfree86/XF86Config-4.roster: xserver-xfree86 VGA-compatible devices on PCI bus: :01:02.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) :01:02.0 Class 0300: 1002:4750 (rev 5c) /etc/X11/XF86Config-4 does not match checksum in /var/lib/xfree86/XF86Config-4.md5sum. XFree86 X server configuration file status: -rw-r--r--1 root root 3809 Jun 19 19:26 /etc/X11/XF86Config-4 Contents of /etc/X11/XF86Config-4: # XF86Config-4 (XFree86 X server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 > /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section "Files" FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/CID" FontPath"/usr/lib/X11/fonts/Speedo" FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"speedo" Load"type1" Load"vbe" # Load"xtt" EndSection #Section "InputDevice" # Identifier "Configured Keyboard" # Driver "keyboard" ## Option "CoreKeyboard" # Option "XkbRules" "xfree86" # Option "XkbModel" "pc101" # Option "XkbLayout" "us" #EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "sun" Option "XkbModel" "type5_unix" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "SendCoreEvents""true" Option "Device""/dev/sunmouse" Option "Protocol" "BusMouse" Option "Emulate3Button""False" EndSection Section "InputDevice" Identifier "Generic Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Button""False" EndSection Section "Device" Identifier "Mach64" Driver "ati" # BusID "PCI:01:02:00" # VideoRam4096 Option "UseFBDev" "True" EndSection Section "Monitor" Identifier "Nokia" HorizSync 30-70 VertRefresh 50-160 DisplaySize 300 225 Option "DPMS" ModeLine"1280x1024" 108.00 1280 1328 1440 1688 1024 1081 1084 1102
Bug#255192: me too
I should note that I'm seeing this behavior under openbox & -5 as well. I hadn't made the correlation between the new version of X and the problem, I originally thought it was just an openbox problem. It seems that Alt-tab works fine when only pressing it once, but holding down Alt and pressing Tab multiple time results in a very weird focus state.
