Bug#233702: xserver-xfree86: same problem with different video card
I have this problem with a different video card: 01:00.0 VGA compatible controller: S3 Inc. VT8636A [ProSavage KN133] AGP4X VGA Controller (TwisterK) (rev 01) (prog-if 00 [VGA]) in my laptop. Any tip to find where the problem is?
Bug#233702: xserver-xfree86: no VT switch problems with KDE
It seems the problem is caused by gnome because I tried to switch VTs in KDE and there where no problems. I'm using unstable. Could you try switching VTs in KDE? If you find no problem, close this bug.
Processed: Must be a bug in apt
Processing commands for [EMAIL PROTECTED]: reassign 234772 apt Bug#234772: problems linking with libICE Bug reassigned from package `libice-dev' to `apt'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#180531: xlibmesa-gl-dev: Typo in glTexImage[123]D
Package: xlibmesa-gl-dev Version: 4.3.0-2 Severity: normal Followup-For: Bug #180531 The width, height and depth for textures are specified as having to be 2n, 2m and 2k (+2 for border). This is incorrect, the correct one is 2^n, 2^m and 2^k. Seems the ^ fell out somewhere. (Or if these things are ported straight from SGI, they align the n,m,k on a line of itself above the 2. Like this: n 2 + 2(Border) Me, I prefer 2^n instead. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.2 Locale: LANG=en_GB, LC_CTYPE=en_GB Versions of packages xlibmesa-gl-dev depends on: ii libc6-dev [libc-dev]2.3.2.ds1-11 GNU C Library: Development Librari ii libx11-dev 4.3.0-2 X Window System protocol client li ii libxext-dev 4.3.0-2 X Window System miscellaneous exte ii x-dev 4.3.0-2 X protocol development files ii xlibmesa-gl 4.3.0-2 Mesa 3D graphics library [XFree86] -- no debconf information
Bug#234057: xlibs-data: cursor themes don't work on sparc
On Wed, 2004-02-25 at 00:35, Michel Dänzer wrote: The requirements for cursor themes to work are: * libx11-6 = 4.3.0-1 * libxcursor1 * running X server = 4.3.0 Do you meet all of these? Name Version Description +++--- ii libx11-6 4.3.0-2 X Window System protocol client library ii libxcursor1 1.0.2-4 X Cursor management library ii xserver-xfree86 4.3.0-2 the XFree86 X server Daniel van Eeden [EMAIL PROTECTED]
Bug#233582: Patch seems to work fine
Thanks for the patch, it works fine. In case somebody wants to test binaries, you can get it from http://www.cihar.com/xfree86/ (probably only http://www.cihar.com/xfree86/xlibmesa-gl_4.3.0-2.1_i386.deb is needed, but I'm too lazy to check it more deeply :-). -- Regards Michal Čihař http://cihar.com
Re: server fails to recognize hardware
On Thu, Feb 19, 2004 at 09:59:13AM +0100, Michel Dänzer wrote: On Thu, 2004-02-19 at 08:49, Matt Taggart wrote: (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found (--) Chipset ATI Radeon 9200 5961 (AGP) found This shows that it recognizes your chip fine; PCI:1:0:1 is the second function of the graphics chip PCI device, which the driver doesn't need and can be ignored. If there's a real problem, please provide more information. BTW, i also have encountered reports of this message, and i don't know where this second function does come from. The cards appear to be normal Radeon 9200, without any exotic stuff. Matt, maybe you could tell us more about this, maybe giving an lspci output too or something. Friendly, Sven Luther
Re: server fails to recognize hardware
On Wed, Feb 25, 2004 at 01:50:36PM -0800, Matt Taggart wrote: Michel =?ISO-8859-1?Q?D=E4nzer?= writes... Is the DVI connected on bootup? If not, does that make a difference? I finally got a chance to try this and it didn't help to have it connected at boot up. Yes, i remember now. The DVI is the primary head, and the driver or cards bios or whatever has problems when only the secondary head is used. This was fixed when using a dvi-vga converter and using the main head only. Friendly, Sven Luther
Re: server fails to recognize hardware
Sven Luther writes... On Thu, Feb 19, 2004 at 09:59:13AM +0100, Michel Dänzer wrote: On Thu, 2004-02-19 at 08:49, Matt Taggart wrote: (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) fo und (--) Chipset ATI Radeon 9200 5961 (AGP) found This shows that it recognizes your chip fine; PCI:1:0:1 is the second function of the graphics chip PCI device, which the driver doesn't need and can be ignored. If there's a real problem, please provide more information. BTW, i also have encountered reports of this message, and i don't know where this second function does come from. The cards appear to be normal Radeon 9200, without any exotic stuff. Matt, maybe you could tell us more about this, maybe giving an lspci output too or something. Gigabyte model#GV-R92128VH Radeon 9200 128mb, 1 DVI, 1 VGA d-sub, and one VIVO connector, which provides video in/out both RCA and s-video via a dongle(so vivo-2 RCA,2 s-video). Came with a DVI-dsub adapter that I could try if needed too. Product page http://www.gigabyte.com.tw/VGA/Products/Products_GV-R92128VH.htm [EMAIL PROTECTED]:~ $ date Thu Feb 26 03:41:00 PST 2004 [EMAIL PROTECTED]:~ $ update-pciids --03:39:13-- http://pciids.sourceforge.net/pci.ids.bz2 = `/usr/share/misc/pci.ids.new' Resolving pciids.sourceforge.net... 66.35.250.209 Connecting to pciids.sourceforge.net[66.35.250.209]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 72,272 [text/plain] 100%[] 72,272 258.20K/s 03:39:13 (258.11 KB/s) - `/usr/share/misc/pci.ids.new' saved [72272/72272] Done. [EMAIL PROTECTED]:~ $ lspci -vv -s 1:0.0 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) (prog-if 00 [VGA]) Subsystem: Giga-byte Technology: Unknown device 4018 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 32 (2000ns min), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 16 Region 0: Memory at d000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 9000 [size=256] Region 2: Memory at e500 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [58] AGP version 3.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 6 4bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=n one Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot -,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- [EMAIL PROTECTED]:~ $ lspci -vv -s 1:0.1 01:00.1 Display controller: ATI Technologies Inc RV280 Ya [Radeon 9200LE] (Secon dary) (rev 01) Subsystem: Giga-byte Technology: Unknown device 4019 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 32 (2000ns min), Cache Line Size: 0x08 (32 bytes) Region 0: Memory at d800 (32-bit, prefetchable) [size=128M] Region 1: Memory at e501 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot -,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Hopefully that's enough. Let me know if you need anything else or want me to test something(I haven't had a chance to try Michel's debs yet, maybe this weekend). Thanks, -- Matt Taggart [EMAIL PROTECTED]
Re: Question on X and new license...
On Sun, Feb 22, 2004 at 11:43:24PM -0500, Branden Robinson wrote: * David Dawes, President of The XFree86 Project, Inc., claims that a a decision to apply the X-Oz license to any client side library code shipped by that organization has been deferred.[1] This statement is a lot weaker than a guarantee that it never will happen. Yeah, but i believe this is more politicking than anything else. Branden, do you know the real story behind this whole stuff anyway ? * Code that forms part of the XFree86 SDK, a driver development kit (which there has been some work to package for Debian) *is* under the X-Oz license, and would prohibit the development of GPL-licensed drivers for the XFree86 X server. Mmm, i would like to look into this, and see if i can manage to get those files changed if needed. Also, you only would need to dual-licence those drivers under the GPL and the X-Oz licence, which would not be an all that bad thing politically. * I have argued to the debian-x mailing list that the X-Oz license is actually not even a Free Software license, because, at the least, it fails clause 9 of the Debian Free Software Guidelines in two distinct ways. If you're interested, you may wish to read my message[2] to that list. (It is worth noting that the debian-legal subscribers have not formed a strong consensus one way or the other regarding the DFSG-freeness of the X-Oz license; the matter is still pending.) Your main argument seems to be that this is failing DFSG 9, because it places restriction on other software on the same media. I believe that XFree86 interpretation of this, as expressed in their legal FAQ which should accompany the licence, clearly state that this is not the case, that it will only apply to derived works, and that providing credit to XFree86, inside the Release notes document for example, should be enough. Friendly, Sven Luther
Re: Question on X and new license...
On Wed, Feb 25, 2004 at 03:35:50AM -0500, Russell Neches wrote: Clearly, XFree86 is a bit more complicated. Nevertheless, shouldn't we be talking about how to work with the XFree86 Project to resolve the issues (whatever they are), instead of talking about forking the whole project? Or is forking/re-implementing/replacing XFree86 the hot new thing? This sounds reasonable, but the whole issue is plagued by year long personal relationship problems, and power play over the actual control of the XFree86 project. I am only a minor contributor to XFree86, and have missed most of it, but then, it seems to me that all players in this have severly misbehaved in the past, and that these tensions and problems are resulting in the problems we are seing. The licence change is only the tip of the iceberg, and probably a not so clever move on the XFree86 part. This is probably this whole stuff is not really making sense to the non-initiated observers. Friendly, Sven Luther
Re: server fails to recognize hardware
On Thu, Feb 26, 2004 at 03:54:21AM -0800, Matt Taggart wrote: Sven Luther writes... On Thu, Feb 19, 2004 at 09:59:13AM +0100, Michel Dänzer wrote: On Thu, 2004-02-19 at 08:49, Matt Taggart wrote: (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) fo und (--) Chipset ATI Radeon 9200 5961 (AGP) found This shows that it recognizes your chip fine; PCI:1:0:1 is the second function of the graphics chip PCI device, which the driver doesn't need and can be ignored. If there's a real problem, please provide more information. BTW, i also have encountered reports of this message, and i don't know where this second function does come from. The cards appear to be normal Radeon 9200, without any exotic stuff. Matt, maybe you could tell us more about this, maybe giving an lspci output too or something. Gigabyte model#GV-R92128VH Radeon 9200 128mb, 1 DVI, 1 VGA d-sub, and one VIVO connector, which provides video in/out both RCA and s-video via a dongle(so vivo-2 RCA,2 s-video). Came with a DVI-dsub adapter that I could try if needed too. Ah, the VIVO stuff may be this additional function, i don't think it is used though. Yeah, as said in another mail, you problem will probably be solved using the DVI-dsub converter. The problem seems to be linked to initializing the card without the primary connector being used. Friendly, Sven Luther
xdm strange behaviour
Hi @all I have noticed a strange behaviour of your 4.3.0-2 version of xdm: tcp0 0 0.0.0.0:49775 0.0.0.0:* LISTEN 7319/xdm As far as I suspect (after reading man xdm) I suspect that the xdm chooser was activated but I do not think that I did it as I did not change my config... /etc/X11/xdm/Xaccess: has all lines commented out /etc/X11/xdm/Xresources: Chooser*geometry: 700x500+300+200 Chooser*allowShellResize: false Chooser*viewport.forceBars: true Chooser*label.font: *-new century schoolbook-bold-i-normal-*-240-* Chooser*label.label:XDMCP Host Menu from CLIENTHOST Chooser*list.font: -*-*-medium-r-normal-*-*-230-*-*-c-*-iso8859-1 Chooser*Command.font: *-new century schoolbook-bold-r-normal-*-180-* /etc/X11/xdm/Xservers: :0 local /usr/X11R6/bin/X vt7 -dpi 100 -nolisten tcp /etc/X11/xdm/xdm-config: DisplayManager.requestPort: 0 Only strange thing in logfile: Wed Feb 25 15:34:34 2004 xdm error (pid 20035): can't execute /usr/X11R6/lib/X11/xdm/Xsetup (err 2) This behaviour occured on three machines, two were downgraded, the last remains in this state Do you see anything which is not correct in here? Have I made a mistake or is this really a bug? Hope I did not waste your time Sincerely Harald Jenny -- Lord, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to hide the bodies of the people I had to kill because they pissed me off.
Bug#234772: Must be a bug in apt
reassign 234772 libice-dev thanks Thomas Hood [EMAIL PROTECTED] writes: reassign 234772 apt thanks a) DON'T ABUSE -QUIET. b) don't randomly reassign bugs if you don't know what you're talking about. This is NOT a bug in apt. It's (the indirect result) of a bug in the postrm of the X lib* packages in 4.3.0-2. -- James
Processed: Re: Bug#234772: Must be a bug in apt
Processing commands for [EMAIL PROTECTED]: reassign 234772 libice-dev Bug#234772: problems linking with libICE Bug reassigned from package `apt' to `libice-dev'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#234772: Must be a bug in apt
On Thu, 2004-02-26 at 14:28, James Troup wrote: b) don't randomly reassign bugs if you don't know what you're talking about. Unfortunately, not everyone is omniscient. This is NOT a bug in apt. It's (the indirect result) of a bug in the postrm of the X lib* packages in 4.3.0-2. Thanks for the explanation. -- Thomas Hood [EMAIL PROTECTED]
Bug#234903: xfree86: [INTL:fr] French debconf templates translation
Package: xfree86 Version: N/A Severity: wishlist Tags: patch l10n Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (400, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.1 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (ignored: LC_ALL set to fr_FR.UTF-8) # xfree86 debconf template strings # Copyright (C) 2000--2003 Branden Robinson # This file is distributed under the same license as the xfree86 package. # Branden Robinson [EMAIL PROTECTED], 2000. # # # # #. 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.2.1-10\n POT-Creation-Date: 2004-01-21 13:41-0500\n PO-Revision-Date: 2004-02-26 15:12+0100\n Last-Translator: Christian Perrier [EMAIL PROTECTED]\n Language-Team: Debiand french translation team debian-l10n-french@lists.debian.org\n MIME-Version: 1.0\n Content-Type: text/plain; charset=ISO-8859-15\n Content-Transfer-Encoding: 8bit\n # Type: select # Description #: ../xdm.templates:4 msgid Select the desired default display manager. msgstr Choisissez le gestionnaire graphique de session par défaut #. Type: select #. Description #: ../xdm.templates:4 msgid A display manager is a program that provides graphical login capabilities for the X Window System. msgstr Un gestionnaire graphique de session est un programme qui permet de se connecter à la machine depuis le système X Window. #. 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 Un seul gestionnaire graphique de session peut s'occuper d'un serveur X donné, bien que plusieurs gestionnaires puissent être installés simultanément. Veuillez choisir celui qui sera utilisé par défaut. #. 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 Plusieurs gestionnaires graphiques peuvent être lancés en même temps, s'ils gèrent des serveurs X différents ; pour cela, configurez correctement chacun des gestionnaires graphiques, modifiez leurs scripts de lancement dans /etc/init.d, et désactivvez le test de gestionnaire graphique par défaut. #. Type: string #. Description #: ../xdm.templates:26 msgid Do you wish to stop the xdm daemon? msgstr Souhaitez-vous arrêter le démon xdm ? #. 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 Le gestionnaire de sessions X (xdm) est généralement arrêté lors de la mise à jour ou de la suppression du paquet. Cependant, il semble qu'il gère actuellement encore au moins une session X. Si xdm est arrêté maintenant, toutes les sessions X qu'il gère seront terminées. Une autre possibilité est de laisser fonctionner xdm, la nouvelle version ne devenant active qu'au prochain redémarrage du démon. #. Type: note #. Description #: ../xfree86-common.templates:3 msgid experimental version of XFree86 packages msgstr Version expérimentale des paquets XFree86 #. 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 Vous utilisez une version expérimentale des paquets XFree86 pour Debian. Veuillez éviter d'envoyer des rapports de bogues au système de gestion des bogues Debian pour cette version des paquets. En effet, ces paquets n'ont pas encore été intégrés dans la distribution Debian. #. 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. You can read more about
Bug#233702: xserver-xfree86: no VT switch problems with KDE
On Thu, 2004-02-26 at 09:52, ROBERTOJIMENOCA wrote: It seems the problem is caused by gnome because I tried to switch VTs in KDE and there where no problems. Were any XKB or otherwise keyboard related programs or applets running with GNOME? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#234556: xlibs: many clients get BadLength error from X_ChangeProperty request
Hi all,
I also have a transmeta Crusoe processor with an ATI Radeon Mobility M6
LY (Vaio C1-MZX). Of course, I am experimenting the exact same bug as
described previously. As it is getting on my nerves I decided to
investigate a little bit by myself where does it comes from. I first
compiled xlogo with the debugging informations and ran gdb on
it. I got this output:
===
[EMAIL PROTECTED] xlogo]$ gdb ./xlogo
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-linux...
(gdb) run -synchronous
Starting program:
/home/fleury/devel/xfree_bug/src/xc/programs/xlogo/xlogo -synchronous
X Error of failed request: BadLength (poly request too large or
internal Xlib length error)
Major opcode of failed request: 18 (X_ChangeProperty)
Serial number of failed request: 29
Current serial number in output stream: 30
Program exited with code 01.
(gdb) break main
Note: breakpoint 1 also set at pc 0x8049327.
Breakpoint 2 at 0x8049327: file xlogo.c, line 117.
(gdb) run -synchronous
Starting program:
/home/fleury/devel/xfree_bug/src/xc/programs/xlogo/xlogo -synchronous
Breakpoint 1, main (argc=2, argv=0xb8b4) at xlogo.c:117
117 toplevel = XtOpenApplication(app_con, XLogo,
(gdb) s
121 if (argc != 1)
(gdb)
124 XtAddCallback(toplevel, XtNsaveCallback, save, NULL);
(gdb)
125 XtAddCallback(toplevel, XtNdieCallback, die, NULL);
(gdb)
126 XtAppAddActions
(gdb)
128 XtOverrideTranslations
(gdb)
130 XtCreateManagedWidget(xlogo, logoWidgetClass, toplevel,
NULL, ZERO);
(gdb)
131 XtRealizeWidget(toplevel);
(gdb)
X Error of failed request: BadLength (poly request too large or
internal Xlib length error)
Major opcode of failed request: 18 (X_ChangeProperty)
Serial number of failed request: 29
Current serial number in output stream: 30
Program exited with code 01.
===
That was obviously not totally satisfactory because I was stuck at the
level of the X server and there was no way t get deeper. So, I compiled
the whole XFree86-4.3.0 with the -g option.
I manage to get closer to the problem, but I'm still stuck and I don't
know really why I can't go deeper (I might have done something wrong as
well). Here is the log that I get:
===
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-linux...
(gdb) break Color.c:99
Breakpoint 1 at 0x808c406: file Color.c, line 99.
(gdb) run :6
Starting program:
/home/fleury/devel/xfree_bug/src/xc/programs/Xserver/Xnest :6
Breakpoint 1, xnestCreateColormap (pCmap=0x83b7310) at Color.c:99
99 XQueryColors(xnestDisplay, xnestColormap(pCmap), colors,
ncolors);
(gdb) break QuColors.c:55
Breakpoint 2 at 0x4009cf44: file QuColors.c, line 55.
(gdb) c
Continuing.
Breakpoint 2, XQueryColors (dpy=0x83b0750, cmap=65535, defs=0x83b6218,
ncolors=64) at QuColors.c:55
55 if (_XReply(dpy, (xReply *) rep, 0, xFalse) != 0) {
(gdb) s
_XReply (dpy=0x83b0750, rep=0xb4f0, extra=0, discard=0) at
XlibInt.c:1642
1642unsigned long cur_request = dpy-request;
(gdb)
1647if (dpy-flags XlibDisplayIOError)
(gdb)
1652cvl = QueueReplyReaderLock(dpy);
(gdb)
1653if (cvl) {
(gdb)
_XFlushInt (dpy=0x83b0750, cv=0x0) at XlibInt.c:589
589 if (dpy-flags XlibDisplayIOError)
(gdb)
597 while (dpy-flags XlibDisplayWriting) {
(gdb)
605 size = todo = dpy-bufptr - dpy-buffer;
(gdb)
606 if (!size) return;
(gdb)
605 size = todo = dpy-bufptr - dpy-buffer;
(gdb)
606 if (!size) return;
(gdb)
612 for (ext = dpy-flushes; ext; ext = ext-next_flush)
(gdb)
608 dpy-flags |= XlibDisplayWriting;
(gdb)
610 dpy-bufptr = dpy-bufmax;
(gdb)
608 dpy-flags |= XlibDisplayWriting;
(gdb)
612 for (ext = dpy-flushes; ext; ext = ext-next_flush)
(gdb)
610 dpy-bufptr = dpy-bufmax;
(gdb)
612 for (ext = dpy-flushes; ext; ext = ext-next_flush)
(gdb)
620 while (size) {
(gdb)
614 bufindex = dpy-buffer;
(gdb)
620 while (size) {
(gdb)
621 ESET(0);
(gdb)
622 write_stat = _X11TransWrite(dpy-trans_conn,
(gdb)
Bug#118856: xbase-clients: xconsole: loses messages (possible buffer overrun?)
Branden Robinson writes: On Fri, Nov 09, 2001 at 10:51:05AM -0500, Jeff Sheinberg wrote: I have noticed this strange output in the xconsole window whenever I boot up my computer, Nov 9 08:28:55 eden-hda7 Nov 9 08:28:55 eden-hda7 Nov 9 08:28:55 Nov 9 09:52:31 eden-hda7 PAM_unix[793]: (login) session opened for user jsroot by jeff(uid=1001) ie, the three Nov 9 08:28:55 entries at the end of the window. Yes, I've seen this behavior myself for as long as I've been using xconsole on Linux, which has been a few years. I looked over the xconsole code recently in conjuntion with a separate issue, but cannot think of a reason why this may be happening. Hi Branden, I think I finally realize what is happening here, due to a kind person explaining to me (unfortunately, off list, and I have lost their email), regarding this bug against syslog-ng, Bug#192054: syslog-ng: STATS: dropped 71 So, if you agree with my explanation, which follows, then please reassign this bug to the sysklogd package, which is the syslog deamon that I had installed when the bug was first reported. Basically, the problem is that the syslog daemon has to communicate the errlog messages to the xconsole program through a named pipe, but until xconsole is actually running, any writes to the named pipe will be rejected (via SIGPIPE signal and/or EPIPE error return) because the named pipe has not yet been opened for reading. Of course, the syslog deamon just ignores these errors, and buffers the rejected messages internally, but eventually, the syslog daemon's buffers will become full, resulting in lost/truncated messages eventually being delivered to xconsole when the named piped does become opened for reading. I think that the syslog daemon should handle a buffer full condition for a destination that is a pipe (perhaps any destination that is not a local file) in a way that the the oldest messages are deleted to make room for newer messages, rather than the other way around, as is currently being done. Thanks, -- Jeff Sheinberg
X Strike Force XFree86 SVN commit: r1107 - /
Author: branden Date: 2004-02-26 11:14:26 -0500 (Thu, 26 Feb 2004) New Revision: 1107 Modified: NEWS.xhtml Log: Add news items announcing upgrade of Subversion to 1.0 on necrotic. Modified: NEWS.xhtml === --- NEWS.xhtml 2004-02-24 08:52:34 UTC (rev 1106) +++ NEWS.xhtml 2004-02-26 16:14:26 UTC (rev 1107) @@ -73,6 +73,10 @@ h2 id=newsNews and announcements/h2 +p[26 February] strongThe X Strike Force Subversion installation has been upgraded to Subversion 1.0./strong +To my knowledge, there are no compatibility issues between Subversion 0.37 and Subversion 1.0. Nevertheless, I +encourage users of the XSF Subversion repositories to upgrade./p + p[18 February] strongXFree86 4.3.0-2 has been accepted into Debian unstable./strong (XFree86 4.3.0-1 is identical except for a changelog entry -- I had forgotten to change the distribution to unstable from experimental.) My deepest thanks to everyone whose hard work and assistance made this long-awaited release happen,
X Strike Force XFree86 SVN commit: r1108 - /
Author: branden Date: 2004-02-26 11:22:20 -0500 (Thu, 26 Feb 2004) New Revision: 1108 Modified: NEWS.xhtml Log: Add links to trunk's debian/changelog and debian/TODO. Modified: NEWS.xhtml === --- NEWS.xhtml 2004-02-26 16:14:26 UTC (rev 1107) +++ NEWS.xhtml 2004-02-26 16:22:20 UTC (rev 1108) @@ -50,9 +50,6 @@ lia href=trunk/debian/local/FAQThe Debian X FAQ/a/li !-- - lia href=/cgi-bin/viewcvs.cgi/branches/4.3.0/sid/debian/TODOXFree86 4.3.0-1 (a.k.a. upload to unstable) - TODO file, via ViewCVS/a/li - lia href=/cgi-bin/viewcvs.cgi/X Strike Force Subversion repository (ViewCVS)/a/li -- @@ -63,8 +60,14 @@ lia href=#whatisWhat is the X Strike Force?/a/li + !-- change the debian/changelog and debian/TODO links to use ViewCVS when it is working again -- + lia href=/xsf/XFree86/trunk/debian/changelogChanges pending in next codexfree86/code package release to + Debian unstable/a/li + + lia href=/xsf/XFree86/trunk/debian/TODOTODO list for future releases of codexfree86/code package to + Debian unstable/a/li + lia href=#bugsThe XFree86 bug list/a/li - !-- lia href=#todoLooking ahead/a/li -- lia href=#linksUseful Links/a/li /ul @@ -73,6 +76,10 @@ h2 id=newsNews and announcements/h2 +p[26 February] strongLinks to the changelog for the forthcoming package release to Debian unstable -- and the +TODO file identifying important work to be done -- have been added to the navigation links above./strong +addressbranden/address/p + p[26 February] strongThe X Strike Force Subversion installation has been upgraded to Subversion 1.0./strong To my knowledge, there are no compatibility issues between Subversion 0.37 and Subversion 1.0. Nevertheless, I encourage users of the XSF Subversion repositories to upgrade./p
X Strike Force XFree86 SVN commit: r1109 - /
Author: branden Date: 2004-02-26 11:26:13 -0500 (Thu, 26 Feb 2004) New Revision: 1109 Modified: NEWS.xhtml Log: Identify myself as author of Subversion 1.0 item. Modified: NEWS.xhtml === --- NEWS.xhtml 2004-02-26 16:22:20 UTC (rev 1108) +++ NEWS.xhtml 2004-02-26 16:26:13 UTC (rev 1109) @@ -82,7 +82,7 @@ p[26 February] strongThe X Strike Force Subversion installation has been upgraded to Subversion 1.0./strong To my knowledge, there are no compatibility issues between Subversion 0.37 and Subversion 1.0. Nevertheless, I -encourage users of the XSF Subversion repositories to upgrade./p +encourage users of the XSF Subversion repositories to upgrade. addressbranden/address/p p[18 February] strongXFree86 4.3.0-2 has been accepted into Debian unstable./strong (XFree86 4.3.0-1 is identical except for a changelog entry -- I had forgotten to change the distribution to unstable from
Bug#226430: [christian.guggenberger@physik.uni-regensburg.de: latest upstream seems to fix problems with i865G chipsets]
tag 226430 + patch
thanks
Thank you very much for looking into this, Mr. Guggenberger!
I am forwarding your patch to the first of the merged bugs and tagging
it accordingly.
--
G. Branden Robinson| Men are born ignorant, not stupid.
Debian GNU/Linux | They are made stupid by education.
[EMAIL PROTECTED] | -- Bertrand Russell
http://people.debian.org/~branden/ |
---BeginMessage---
[ this applies to bugs #226430 #233684 #233951 ]
Dear Branden,
I spent some hours with fiddling latest changes of UPSTREAM's i830.h and
i830_driver.c into xfree86-4.3.0-2 to get some machines with Intel's
865G chip working again.
Well, it seems I've succeeded.
Basically, what i've done is merge all changes from upstream into
debian's source. (I've reverted
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c.diff?r1=1.36r2=1.37
because I got a build error I could not workaround with my little knowledge)
I will attach both patches (the first brings i830.h in shape, the other
one i830_driver.c)
I have succesfully (short...) tested the resulting .debs on i845G and
i865G hardware, X is working again on 865g now.
If you'd (or any other patchmaster here on the list) find some time to
review the patches and pull the nessessary changes into your svn
repository - that would be nice.
thanks
- Christian
--- xc/programs/Xserver/hw/xfree86/drivers/i810/i830.h.orig Wed Feb 25 19:13:29 2004
+++ xc/programs/Xserver/hw/xfree86/drivers/i810/i830.h Wed Feb 25 19:21:15 2004
@@ -27,7 +27,7 @@
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
**/
-/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/i810/i830.h,v 1.7.2.1 2003/10/21 02:22:38 dawes Exp $ */
+/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/i810/i830.h,v 1.13 2004/02/20 00:06:00 alanh Exp $ */
/*
* Authors:
@@ -302,6 +302,8 @@
int yoffset;
int SaveGeneration;
+ Bool vbeRestoreWorkaround;
+ Bool displayInfo;
} I830Rec;
#define I830PTR(p) ((I830Ptr)((p)-driverPrivate))
--- xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c.orig Wed Feb 25 21:29:49 2004
+++ xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c Wed Feb 25 21:37:30 2004
@@ -1,4 +1,4 @@
-/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c,v 1.27.2.3 2003/12/19 23:41:32 dawes Exp $ */
+/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c,v 1.51 2004/02/25 12:53:14 eich Exp $ */
/**
Copyright 2001 VA Linux Systems Inc., Fremont, California.
@@ -154,7 +154,7 @@
#include micmap.h
#include fb.h
-#include miscstruct.h
+#include regionstr.h
#include xf86xv.h
#include Xv.h
#include vbe.h
@@ -202,8 +202,8 @@
OPTION_XVIDEO,
OPTION_VIDEO_KEY,
OPTION_COLOR_KEY,
- OPTION_STRETCH,
- OPTION_CENTER
+ OPTION_VBE_RESTORE,
+ OPTION_DISPLAY_INFO
} I830Opts;
static OptionInfoRec I830BIOSOptions[] = {
@@ -215,8 +215,8 @@
{OPTION_XVIDEO, XVideo, OPTV_BOOLEAN, {0}, TRUE},
{OPTION_COLOR_KEY, ColorKey, OPTV_INTEGER, {0}, FALSE},
{OPTION_VIDEO_KEY, VideoKey, OPTV_INTEGER, {0}, FALSE},
- {OPTION_STRETCH, Stretch, OPTV_BOOLEAN, {0}, FALSE},
- {OPTION_CENTER, Center, OPTV_BOOLEAN, {0}, FALSE},
+ {OPTION_VBE_RESTORE, VBERestore, OPTV_BOOLEAN, {0}, FALSE},
+ {OPTION_DISPLAY_INFO,DisplayInfo, OPTV_BOOLEAN, {0}, FALSE},
{-1, NULL, OPTV_NONE, {0}, FALSE}
};
/* *INDENT-ON* */
@@ -790,18 +790,26 @@
I830Ptr pI830 = I830PTR(pScrn);
int pipe, n;
DisplayType i;
-
- for (i = 0; i NumKnownDisplayTypes; i++) {
- if (GetDisplayInfo(pScrn, 1 i, pI830-displayAttached[i],
+
+ /* This seems to lockup some Dell BIOS'. So it's on option to turn on */
+ if (pI830-displayInfo) {
+ xf86DrvMsg(pScrn-scrnIndex, X_INFO,
+ Broken BIOSes cause the system to hang here.\n
+ \t If you encounter this problem please add \n
+ \t\t Option \DisplayInfo\ \FALSE\\n
+ \t to the Device section of your XF86Config file.\n);
+ for (i = 0; i NumKnownDisplayTypes; i++) {
+ if (GetDisplayInfo(pScrn, 1 i, pI830-displayAttached[i],
pI830-displayPresent[i],
pI830-displaySize[i].x2,
pI830-displaySize[i].y2)) {
- xf86DrvMsg(pScrn-scrnIndex, X_INFO,
+ xf86DrvMsg(pScrn-scrnIndex, X_INFO,
Display Info: %s: attached: %s, present: %s, size:
(%d,%d)\n, displayDevices[i],
BOOLTOSTRING(pI830-displayAttached[i]),
BOOLTOSTRING(pI830-displayPresent[i]),
pI830-displaySize[i].x2, pI830-displaySize[i].y2);
+ }
}
}
@@ -1183,7 +1191,7 @@
SetBIOSMemSize(ScrnInfoPtr pScrn, int newSize)
{
I830Ptr pI830 = I830PTR(pScrn);
- CARD32 swf1;
+ unsigned long swf1;
Bool mapped;
DPRINTF(PFX, SetBIOSMemSize: %d kB\n, newSize / 1024);
@@ -1199,7 +1207,7 @@
#endif
if
Processed: [christian.guggenberger@physik.uni-regensburg.de: latest upstream seems to fix problems with i865G chipsets]
Processing commands for [EMAIL PROTECTED]: tag 226430 + patch Bug#226430: xserver-xfree86: [i810,ddc] SEGV when loading ddc module on 865G Chipset Graphics Controller rev 2 Tags were: upstream sid Bug#233684: xserver-xfree86: [i810,ddc] SEGV when loading ddc module on 865G Chipset Graphics Controller rev 2 Bug#233951: xserver-xfree86: [i810,ddc] SEGV when loading ddc module on 865G Chipset Graphics Controller rev 2 Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: This isn't new
Processing commands for [EMAIL PROTECTED]: tag 234788 sid sarge woody upstream Bug#234788: Major data loss because of .xsession-errors There were no tags set. Tags added: sid, sarge, woody, upstream thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#233768: xlibs: Too many extraneous depends
On Wed, Feb 25, 2004 at 10:00:14AM +0100, David Martínez Moreno wrote: Don't worry :-) xlibs now has become a transient package (i.e., a fake package that is intended to make the transition to the new packages as smooth as possible). Not quite true. It is transitional, but it is not fake, and it *does* contain important files. - From the description of xlibs: X Window System client libraries metapackage and XKB data This package smooths upgrades from Debian 3.0 by depending on the individual library packages into which each shared object formerly contained in this package has been split. This package is only depended upon by packages that haven't yet been compiled against the new shared library packages. Eventually, if you run deborphan, you should be able to remove xlibs and whatever other graphical libraries dependencies you have, as the new xlibs design is far more modular than 4.2.1 one. What I mean is that you are seeing only what xlibs contained in 4.2.1 but only now is splitted in. xlibs will have to live on dpkg is capable of migrating conffiles from one package to another. Some users of earlier experimental 4.3.0 packages saw what happens when the XKB data migrates; they 60 or 70 spurius changed-conffile prompts. In my opinion, it is not reasonable by any stretch of the imagination to subject our users to this behavior. When dpkg is fixed, the XKB data can move to xlibs-data, and xlibs-data can Pre-Depend (I think) on dpkg (= whatever-version-fixed-it). -- G. Branden Robinson| The power of accurate observation Debian GNU/Linux | is frequently called cynicism by [EMAIL PROTECTED] | those who don't have it. http://people.debian.org/~branden/ | -- George Bernard Shaw signature.asc Description: Digital signature
who is the author of the Linux evdev patch to lnx_kbd.c?
The evdev patch to lnx_kbd.c (attached) in XFree86 4.3.0 is fairly
large, and contains no author information.
Furthermore, the changes are substantial enough that copyright probably
resides in them.
Can either of you guys shed some light on who wrote this code?
--
G. Branden Robinson| There's something wrong if you're
Debian GNU/Linux | always right.
[EMAIL PROTECTED] | -- Glasow's Law
http://people.debian.org/~branden/ |
$Id: 055_lnx_evdev_keyboard.diff 1044 2004-02-16 17:40:33Z branden $
diff -u xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c~
xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c~ 2003-12-24
13:15:17.0 -0500
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c 2003-12-24
13:15:21.0 -0500
@@ -22,6 +22,7 @@
#include xf86OSKbd.h
#include atKeynames.h
#include lnx_kbd.h
+#include lnx_evdev.h
#define KBC_TIMEOUT 250/* Timeout in ms for sending to keyboard
controller */
@@ -500,8 +501,8 @@
return TRUE;
}
-Bool
-xf86OSKbdPreInit(InputInfoPtr pInfo)
+static Bool
+stdKbdPreInit(InputInfoPtr pInfo, char *protocol)
{
KbdDevPtr pKbd = pInfo-private;
@@ -540,3 +541,381 @@
#endif
return TRUE;
}
+
+typedef struct _evdevKbdRec {
+int packetSize;
+char *buffer;
+evdevDriver evdev;
+} evdevKbdRec, *evdevKbdPtr;
+
+static void
+evdevKbdReadInput(InputInfoPtr pInfo)
+{
+KbdDevPtr pKbd;
+evdevKbdPtr evdevKbd;
+struct input_event *ev;
+int n;
+int code;
+
+pKbd = (KbdDevPtr) pInfo-private;
+evdevKbd = pKbd-private;
+ev = (struct input_event *) evdevKbd-buffer;
+
+if (pInfo-fd == -1)
+ return;
+
+do {
+ n = read(pInfo-fd, ev, sizeof(struct input_event));
+ if (n == -1) {
+ xf86Msg(X_ERROR, %s: Error in reading! (%s) Disabiling.\n,
+ pInfo-name, strerror(errno));
+ RemoveEnabledDevice(pInfo-fd);
+ close (pInfo-fd);
+ pInfo-dev-public.on = FALSE;
+ pInfo-fd = -1;
+ return;
+ }
+ if (n != sizeof(struct input_event)) {
+ xf86Msg(X_WARNING, %s: incomplete packet, size %d\n, pInfo-name,
n);
+ return;
+ }
+
+ switch (ev-type) {
+ case EV_KEY:
+ if ((ev-code = EV_KEY_RESERVED)||(ev-code = EV_KEY_UNKNOWN))
+ break;
+ switch (ev-code) {
+ case EV_KEY_103RD:
+ case EV_KEY_102ND:
+ case EV_KEY_LINEFEED:
+ case EV_KEY_MACRO:
+ case EV_KEY_MUTE:
+ case EV_KEY_VOLUMEDOWN:
+ case EV_KEY_VOLUMEUP:
+ case EV_KEY_POWER:
+ case EV_KEY_KPPLUSMINUS:
+ case EV_KEY_F18:
+ case EV_KEY_F19:
+ case EV_KEY_F20:
+ case EV_KEY_F21:
+ case EV_KEY_F22:
+ case EV_KEY_F23:
+ case EV_KEY_F24:
+ case EV_KEY_KPCOMMA:
+ case EV_KEY_COMPOSE:
+ code = KEY_UNKNOWN;
+ break;
+ case EV_KEY_F13:
+ code = KEY_F13;
+ break;
+ case EV_KEY_F14:
+ code = KEY_F14;
+ break;
+ case EV_KEY_F15:
+ code = KEY_F15;
+ break;
+ case EV_KEY_F16:
+ code = KEY_F16;
+ break;
+ case EV_KEY_F17:
+ code = KEY_F17;
+ break;
+ case EV_KEY_KPENTER:
+ code = KEY_KP_Enter;
+ break;
+ case EV_KEY_RIGHTCTRL:
+ code = KEY_RCtrl;
+ break;
+ case EV_KEY_KPSLASH:
+ code = KEY_KP_Divide;
+ break;
+ case EV_KEY_SYSRQ:
+ code = KEY_SysReqest;
+ break;
+ case EV_KEY_RIGHTALT:
+ code = KEY_AltLang;
+ break;
+ case EV_KEY_HOME:
+ code = KEY_Home;
+ break;
+ case EV_KEY_UP:
+ code = KEY_Up;
+ break;
+ case EV_KEY_PAGEUP:
+ code = KEY_PgUp;
+ break;
+ case EV_KEY_LEFT:
+ code = KEY_Left;
+ break;
+ case EV_KEY_RIGHT:
+ code = KEY_Right;
+ break;
+
Re: Question on X and new license...
On Thu, Feb 26, 2004 at 12:59:19PM +0100, Sven Luther wrote: On Sun, Feb 22, 2004 at 11:43:24PM -0500, Branden Robinson wrote: * David Dawes, President of The XFree86 Project, Inc., claims that a a decision to apply the X-Oz license to any client side library code shipped by that organization has been deferred.[1] This statement is a lot weaker than a guarantee that it never will happen. Yeah, but i believe this is more politicking than anything else. Branden, do you know the real story behind this whole stuff anyway ? No. I suspect there's only one person who does, and he appears to be adamant that there's nothing more to know. * Code that forms part of the XFree86 SDK, a driver development kit (which there has been some work to package for Debian) *is* under the X-Oz license, and would prohibit the development of GPL-licensed drivers for the XFree86 X server. Mmm, i would like to look into this, and see if i can manage to get those files changed if needed. Also, you only would need to dual-licence those drivers under the GPL and the X-Oz licence, which would not be an all that bad thing politically. If you could: 1) identify all files shipped by the SDK affected by the relicensing; and 2) a) get them relicensed under the previous license; or b) get them dual-licensed under the GNU GPL; and 3) get a statement from the XFree86 Project, Inc., that any file shipped as part of the SDK in the future will be handled the same as the ones that are part of it today ...then I'd be very appreciative! I think many people in the community would be as well. * I have argued to the debian-x mailing list that the X-Oz license is actually not even a Free Software license, because, at the least, it fails clause 9 of the Debian Free Software Guidelines in two distinct ways. If you're interested, you may wish to read my message[2] to that list. (It is worth noting that the debian-legal subscribers have not formed a strong consensus one way or the other regarding the DFSG-freeness of the X-Oz license; the matter is still pending.) Your main argument seems to be that this is failing DFSG 9, because it places restriction on other software on the same media. I believe that XFree86 interpretation of this, as expressed in their legal FAQ which should accompany the licence, clearly state that this is not the case, that it will only apply to derived works, and that providing credit to XFree86, inside the Release notes document for example, should be enough. I tried to follow a link to the FAQ from here: http://www.xfree86.org/xnews/#license But it didn't work. Not Found The requested URL /xnews/legal/licenses.html was not found on this server. -- G. Branden Robinson| Suffer before God and ye shall be Debian GNU/Linux | redeemed. God loves us, so He [EMAIL PROTECTED] | makes us suffer Christianity. http://people.debian.org/~branden/ | -- Aaron Dunsmore signature.asc Description: Digital signature
Re: Changed library interface causing FTBFS of cernlib?
On Wed, Feb 25, 2004 at 12:37:10PM -0500, Kevin B. McCarty wrote: On Mon, 23 Feb 2004, Branden Robinson wrote: On Mon, Feb 23, 2004 at 06:24:31AM -0500, Kevin B. McCarty wrote: [...] Presumably there was some reason that earlier, these extra libs were only required on powerpc? I don't think that is a valid premise. I think they probably were. Sorry, I should have been clearer. In my understanding, as of X 4.2.1, the extra libraries like libICE.so and libSM.so needed to be explicitly linked (via the arguments to gcc) only on powerpc; This is the first I've heard of this. If it is true, I have no idea why. on other arches the linker was able to figure out to link them in automatically via the lib dependencies of libXm.so (Lesstif). I didn't think the linker worked this way; I thought you always had to provide explicit linkage for every object you required, static or dynamic; direct or transitive dependency. That is, on any arch other than powerpc, the linker flags would look like -lXm ... -lX11 and on powerpc, they needed to look like -lXm ... -lX11 -lSM -lICE. If that understanding is wrong (I wouldn't be surprised if it is, as it was derived from the cernlib upstream lib dependency script), please correct me again. I don't know if it's right, but I'd be surprised if it were. Then again, I'm not a toolchain wizard, and toolchain wizards are subtle and quick to anger, so I will not speculate too much. From what James Troup said in a followup, it looks like the weird errors were due not to a new requirement that libSM and libICE be explicitly linked in, but rather due to a problem that left apt or dpkg thinking libice6 was installed even though it was actually not. So I guess the -lSM -lICE flags are still not explicitly required, and my question becomes, is it _better_ to include those flags even if not explicitly required? As I understand the way you're supposed to handle linkage, yes. The only library that is implicitly linked is the C library. Yes, given the above linkage, you need to Build-Depend on: libxp-dev, libxt-dev, libxext-dev, libxpm-dev, libx11-dev, libsm-dev, libice-dev. Cernlib depends upon libXp, libXext, libXpm, libSM and libICE only through Lesstif, not explicitly. In days past, libXm also depended on libXt. If ldd says that is no longer true, though, then I won't contradict it. So I presume that I should Build-Depend upon: lesstif2-dev|lesstif-dev, x-dev|xlibs-dev, libx11-dev|xlibs-dev, libxt-dev|xlibs-dev (where in each case the alternative is for woody back-portability); does that seem correct? Almost. You should version each of the xlibs-dev dependencies to ( 4.3.0). Also, you should put spaces on each side of your pipe characters. :) -- G. Branden Robinson|Damnit, we're all going to die; Debian GNU/Linux |let's die doing something *useful*! [EMAIL PROTECTED] |-- Hal Clement, on comments that http://people.debian.org/~branden/ | space exploration is dangerous signature.asc Description: Digital signature
Re: Bug#234388: xserver-xfree86: [tdfx] X server refuses to use DRI at 1280x960 resolution
On Thu, 2004-02-26 at 20:17, Branden Robinson wrote: On Wed, Feb 25, 2004 at 11:27:47PM +0100, Rieker Flaik wrote: Claudio Martins wrote: (WW) TDFX(0):Tondri] To use DRI, with a 16Mb Voodoo 3 or Banshee card, you must invoke the server using a maximum resolution of 1024x768 or lower. Yes, I have the same errormessage. So I changed back to 1024x768 and in /var/log/XFree86.0.log it's said that DRI has been loaded. (II) Loading extension XFree86-DRI (II) TDFX(0): [DRI] installation complete (==) TDFX(0): Direct rendering enabled (==) RandR enabled But when I tried to play Descent2 with OpenGL there was no Hardwareacceleration. $ glxinfo direct rendering: No You're probably seeing Debian Bug #229984 (plus 6 duplicate bugs). So how do I get back my good old ability to run 3d-Hardwareaccelerated games? Downgrade to xlibmesa-dri 4.3.0-0pre1v5, or wait for xlibmesa-dri 4.3.0-3 (well, probably -- no i386 user has yet reported to me that the fix actually works). okay, let me be the first to do so: Yes, the fix (000_stolen_from_Mesa_CVS.diff ) does indeed work! thanks. Christian
Bug#234113: I have the same bug, XF86Config-4 included
On Tue, Feb 24, 2004 at 11:06:38PM +0100, Markus Meissner wrote: On Tuesday 24 February 2004 21:52, Branden Robinson wrote: Please send you /var/log/XFree86.0.log file so we can see if there were any errors from the X server while attempting to compile your keyboard definition. The log is attached. Thanks. Also, have you modified any of the XKB conffiles in /etc/X11/xkb? No, to be honest I didn't noticed those conffiles before you ask me =) On my iBook, I use the XkbModel macintosh. Perhaps that will help? -- G. Branden Robinson|Men use thought only to justify Debian GNU/Linux |their wrong doings, and speech only [EMAIL PROTECTED] |to conceal their thoughts. http://people.debian.org/~branden/ |-- Voltaire signature.asc Description: Digital signature
Bug#234355: xlibs: .../locale/en_US.UTF-8/Compose: dead_diaeresis space produces a diaeresis
[...] No, I said something completely different, you didn't read anything I wrote, did you? :) I did read it, but I mostly saw a lot of frustration in an area that I don't have a lot of familiarity with, and which is -- in the absence of standardization -- a matter of preference. Anyway, forget about the issue. I see you don't have time to think about it and would rather follow blindly a standard or upstream. If I don't have enough information about, or experience with, a subject to make an informed decision, then I don't make one. If I am going to break with a standard, or with upstream, I need a damn good reason. Frankly, you weren't offering one. You were just angry and impatient. (You appear to still be the latter.) I thought I was giving four good reasons :). The first one, about rendering us_intl unable to produce a quotedbl maybe even merited a serious bug by itself. You don't seem to question upstream modifications to config files, but seeing the CVS logs, I don't see them being too careful when commiting changes. You had the bad luck of picking up the file between the blunder and the correction :). See, I was angry and impatient because the changes to /etc/X11/xkb/* broke my keyboard configuration. They changed rules/xfree86 and I couldn't configure correctly the keyboard, until, after much struggle, I learned to use the keycodes/types/symbol system and bypassed the rules/layout/variant one. And then, when I finally managed to build a good configuration, saw that dead_diaresis space was broken too... :) You don't want to break with standards or upstream, but what about breaking with your users? Changes in configuration files, should, IMHO, be carefully thought and justified... I think you will have a lot of bug reports related to the keyboard as more people upgrade. [...] I suppose it will be more productive for me to report further bugs directly to upstream, and then wait some months for you to pick the patches, is that right? You can do whichever you like; if you can work productively with the Debian package maintainers, make a good case for including a patch, and that patch doesn't cause problems, you may find it gets applied. Ok, I'll try to be clear and cool when reporting further bugs :). Thanks for your explanatory response. Bye.
Bug#234496: xserver-xfree86: xserver freeze all input devices randomely
On Tue, Feb 24, 2004 at 08:27:40AM +0100, Klaus Ethgen wrote: I have a radeon card. But this bug seams to be in other driver. The system freeze the mouse and the keyboard (together) randomely. All other like opening windows (remotely) or the normal displayfunktionality works on. I only have no control over it. I can also not switch to a console so I have to login from remote and kill the xserver with loosing all open windows. [...] Section InputDevice Identifier Stift 1 Driver wacom Option Device/dev/input/event0 Option Type stylus Option Mode absolute Option USB on Option Tilt on Option ResolutionX 1270 Option ResolutionY 1270 EndSection Section InputDevice Identifier Stift 2 Driver wacom Option Device/dev/input/event0 Option Type stylus Option Mode absolute Option USB on Option Tilt on EndSection Section InputDevice Identifier Radierer 1 Driver wacom Option Device/dev/input/event0 Option Type eraser Option Mode absolute Option USB on Option Tilt on Option ResolutionX 1270 Option ResolutionY 1270 EndSection Section InputDevice Identifier Radierer 2 Driver wacom Option Device/dev/input/event0 Option Type eraser Option Mode absolute Option USB on Option Tilt on EndSection Section InputDevice Identifier Maus 1 Driver wacom Option SendCoreEventstrue Option Device/dev/input/event0 Option Type cursor Option Mode relative Option USB on EndSection [...] Section ServerLayout Identifier Default Layout Screen 0 Interner LCD InputDevice Keyboard InputDevice Trackpoint #InputDeviceUSB Mouse InputDevice Stift 1 #InputDeviceStift 2 InputDevice Radierer 1 #InputDeviceRadierer 2 InputDevice Maus 1 EndSection Section ServerLayout Identifier Beamer Screen 0 Interner LCD Screen 1 Beamer Above Interner LCD InputDevice Keyboard InputDevice Trackpoint InputDevice USB Mouse EndSection Section ServerLayout Identifier Wacom Screen 0 Interner LCD InputDevice Keyboard InputDevice Trackpoint InputDevice Stift 1 #InputDeviceStift 2 InputDevice Radierer 1 #InputDeviceRadierer 2 InputDevice Maus 1 EndSection On Wed, Feb 25, 2004 at 12:39:41AM +0100, Michel Dänzer wrote: On Tue, 2004-02-24 at 08:27, Klaus Ethgen wrote: The system freeze the mouse and the keyboard (together) randomely. All other like opening windows (remotely) or the normal displayfunktionality works on. I only have no control over it. I can also not switch to a console so I have to login from remote and kill the xserver with loosing all open windows. [...] (EE) xf86OpenSerial: Cannot open device /dev/input/event0 No such device. I wonder if it's related to these errors about /dev/input/event0? I agree. Mr. Ethgen, your input device configuration looks pathological to me. I am not sure it is reasonable to load 5 instances of the wacom driver, each with a different configuration, point them all at the same port, and expect things to work. -- G. Branden Robinson|I must despise the world which does Debian GNU/Linux |not know that music is a higher [EMAIL PROTECTED] |revelation than all wisdom and http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven signature.asc Description: Digital signature
[peter@chocky.org: Bug#234808: xserver-xfree86: XFree86 fixes for ARM]
Joey,
Would you approve a change of this nature for a stable update to woody?
- Forwarded message from Peter Naulls [EMAIL PROTECTED] -
From: Peter Naulls [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: Bug#234808: xserver-xfree86: XFree86 fixes for ARM
Date: Wed, 25 Feb 2004 22:11:08 +
Message-Id: [EMAIL PROTECTED]
X-Mailing-List: debian-x@lists.debian.org archive/latest/14800
X-Mailer: reportbug 1.50
X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no
version=2.60-bugs.debian.org_2004_02_22
Package: xserver-xfree86
Version: 4.1.0-16woody3
Severity: important
Tags: patch
This is a expanded version of bug #223567, which was not applied to 4.1
These patches allow XFree86 4.1 to work on ARM. In particular, to allow
non-framebuffer devices to work. There is one change worthy of note. The
open() call for ARM to access DEV_MEM includes O_SYNC i lnx_video.c. This
is absolutely required to ensure that memory access to card registers and other
device
memory is not cached. I didn't put a comment in, because it conflicts with
the ia64 comment, and I suggest something suitable is done here.
Similar, if not identical, patches are required for 4.2 and 4.3.
-- System Information
Debian Release: 3.0
Architecture: arm
Kernel: Linux puffin 2.4.22-iyonix #9 Thu Feb 19 16:31:32 GMT 2004 armv5l
Locale: LANG=C, LC_CTYPE=C
Versions of packages xserver-xfree86 depends on:
ii debconf1.2.35Debian configuration management sy
ii libc6 2.2.5-11.5GNU C Library: Shared libraries an
ii xserver-common 4.1.0-16woody3files and utilities common to all
ii zlib1g 1:1.1.4-1.0woody0 compression library - runtime
--- hw/xfree86/common/xf86Bus.c.old Wed Feb 25 16:05:30 2004
+++ hw/xfree86/common/xf86Bus.c Wed Feb 25 16:06:38 2004
@@ -3123,7 +3123,7 @@
static void
CheckGenericGA()
{
-#if !defined(__sparc__) !defined(__powerpc__) !defined(__mips__) /*
FIXME ?? */
+#if !defined(__sparc__) !defined(__powerpc__) !defined(__mips__)
!defined(__arm__) /* FIXME ?? */
CARD16 GenericIOBase = VGAHW_GET_IOBASE();
CARD8 CurrentValue, TestValue;
--- hw/xfree86/os-support/linux/lnx_video.c.old Wed Feb 25 15:43:32 2004
+++ hw/xfree86/os-support/linux/lnx_video.c Wed Feb 25 15:55:28 2004
@@ -436,7 +436,7 @@
mapflags |= MAP_NONCACHED;
#endif
-#if defined(__ia64__)
+#if defined(__ia64__) || defined(__arm__)
/* this will disappear when people upgrade their kernels */
if ((fd = open(DEV_MEM, O_RDWR|O_SYNC)) 0)
#else
@@ -519,7 +519,7 @@
#endif
}
close(fd);
-#elif !defined(__mc68000__) !defined(__sparc__) !defined(__mips__)
!defined(__hppa__)
+#elif !defined(__mc68000__) !defined(__sparc__) !defined(__mips__)
!defined(__hppa__) !defined(__arm__)
if (ioperm(0, 1024, 1) || iopl(3)) {
if (errno == ENODEV)
ErrorF(xf86EnableIOPorts: no I/O ports found\n);
@@ -544,7 +544,7 @@
#if defined(__powerpc__)
munmap(ioBase, 0x2);
ioBase = NULL;
-#elif !defined(__mc68000__) !defined(__sparc__) !defined(__mips__)
!defined(__hppa__)
+#elif !defined(__mc68000__) !defined(__sparc__) !defined(__mips__)
!defined(__hppa__) !defined(__arm__)
iopl(0);
ioperm(0, 1024, 0);
#endif
@@ -562,11 +562,11 @@
xf86DisableInterrupts()
{
if (!ExtendedEnabled)
-#if !defined(__mc68000__) !defined(__powerpc__) !defined(__sparc__)
!defined(__mips__) !defined(__hppa__)
+#if !defined(__mc68000__) !defined(__powerpc__) !defined(__sparc__)
!defined(__mips__) !defined(__hppa__) !defined(__arm__)
if (iopl(3) || ioperm(0, 1024, 1))
return (FALSE);
#endif
-#if defined(__alpha__) || defined(__mc68000__) || defined(__powerpc__) ||
defined(__sparc__) || defined(__mips__) || defined(__arm__) || defined(__hppa__)
+#if defined(__alpha__) || defined(__mc68000__) || defined(__powerpc__) ||
defined(__sparc__) || defined(__mips__) || defined(__arm__) ||
defined(__hppa__) || defined(__arm__)
#else
#ifdef __GNUC__
#if defined(__ia64__)
@@ -580,7 +580,7 @@
asm(cli);
#endif
#endif
-#if !defined(__mc68000__) !defined(__powerpc__) !defined(__sparc__)
!defined(__mips__) !defined(__hppa__)
+#if !defined(__mc68000__) !defined(__powerpc__) !defined(__sparc__)
!defined(__mips__) !defined(__hppa__) !defined(__arm__)
if (!ExtendedEnabled) {
iopl(0);
ioperm(0, 1024, 0);
@@ -594,11 +594,11 @@
xf86EnableInterrupts()
{
if (!ExtendedEnabled)
-#if !defined(__mc68000__) !defined(__powerpc__) !defined(__sparc__)
!defined(__mips__) !defined(__hppa__)
+#if !defined(__mc68000__) !defined(__powerpc__) !defined(__sparc__)
!defined(__mips__) !defined(__hppa__) !defined(__arm__)
if (iopl(3) || ioperm(0, 1024, 1))
return;
#endif
-#if defined(__alpha__) || defined(__mc68000__) || defined(__powerpc__) ||
defined(__sparc__) || defined(__mips__) || defined(__arm__) || defined(__hppa__)
+#if
Bug#234788: Major data loss because of .xsession-errors
severity 234788 wishlist retitle 234788 xfree86: change design of Unix I/O stream handling tag 234788 + wontfix thanks On Wed, Feb 25, 2004 at 09:00:12PM +0100, Tomasz Wegrzanowski wrote: Package: xserver-xfree86 Version: 4.3.0-2 Severity: critical Today .xsession-errors grew over 1.5 gigabyte, filling all free space on /home partition. Because of that, other programs couldn't save their data, and some very important data was lost. It's not the first time I lost data because of sudden explossion of .xsession-errors, so I'm filling a bug report with this severity. I have no idea which program caused so many errors. At the moment it's just 5kB. But that's not really relevant. The problem is that the .xsession-errors is misdesigned and must be fixed - I don't care how - by setting reasonable limits on its size, limiting kind of errors that have to be logged, removing it altogether, or some other way. But the current situation is not acceptable. Hi, .xsession-error's design is simple. It is a Unix file to which the Unix standard output and standard error streams get redirected. I am probably not qualified to architect a replacement for something as venerable as Unix file I/O; I suggest you get in touch with Ken Thompson and Dennis Ritchie. In the meantime, I have a workaround to recommend: $ ln -sf /dev/null $HOME/.xsession-errors Thank you for your report, and if you should happen to visit Dennis or Ken, don't forget to get their autographs. -- G. Branden Robinson|To Republicans, limited government Debian GNU/Linux |means not assisting people they [EMAIL PROTECTED] |would sooner see shoveled into mass http://people.debian.org/~branden/ |graves. -- Kenneth R. Kahn signature.asc Description: Digital signature
Re: Question on X and new license...
On Thu, Feb 26, 2004 at 12:59:19PM +0100, Sven Luther wrote: On Sun, Feb 22, 2004 at 11:43:24PM -0500, Branden Robinson wrote: * David Dawes, President of The XFree86 Project, Inc., claims that a a decision to apply the X-Oz license to any client side library code shipped by that organization has been deferred.[1] This statement is a lot weaker than a guarantee that it never will happen. Changing the license on the server at this late date has its own (albeit much smaller) problems. It's going to blind-side a lot of people who don't follow the gossip channels and could well lead to a lot of inadvertent license violating by people who were previously in full compliance with all the license requirements. This, I think, is the essence of the BSD-folks' objections to the new license. (Speaking of inadvertent license violating, does anyone even know the complete list of people that must be credited in advertisements of Debian-based systems due to 4-clause BSD licenses? The OpenSSL project, Eric Young [EMAIL PROTECTED] and...? Do we still need to credit the UC Regents?) * Code that forms part of the XFree86 SDK, a driver development kit (which there has been some work to package for Debian) *is* under the X-Oz license, and would prohibit the development of GPL-licensed drivers for the XFree86 X server. Mmm, i would like to look into this, and see if i can manage to get those files changed if needed. Also, you only would need to dual-licence those drivers under the GPL and the X-Oz licence, which would not be an all that bad thing politically. Dual-licensing would defeat the purpose of GPLing the drivers, i.e. it would open them up to proprietary exploitation by others. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#234812: xserver-xfree86: preconfigure script hangs while runing discovery
tag 234812 + moreinfo retitle 234812 xserver-xfree86: configure script hangs thanks You did not include a description of your problem in the body of your bug report. Are you saying that the discover command hangs? If so, does it hang from the command-line? Please try the following command: $ discover ...and reply to this bug [EMAIL PROTECTED], advising as to the result. -- G. Branden Robinson|Kissing girls is a goodness. It is Debian GNU/Linux |a growing closer. It beats the [EMAIL PROTECTED] |hell out of card games. http://people.debian.org/~branden/ |-- Robert Heinlein signature.asc Description: Digital signature
Processed: Re: Bug#234788: Major data loss because of .xsession-errors
Processing commands for [EMAIL PROTECTED]: severity 234788 wishlist Bug#234788: Major data loss because of .xsession-errors Severity set to `wishlist'. retitle 234788 xfree86: change design of Unix I/O stream handling Bug#234788: Major data loss because of .xsession-errors Changed Bug title. tag 234788 + wontfix Bug#234788: xfree86: change design of Unix I/O stream handling Tags were: upstream woody sarge sid Tags added: wontfix thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#233582: Patch seems to work fine
On Thu, Feb 26, 2004 at 11:50:14AM +0100, Michal Čihař wrote: Thanks for the patch, it works fine. In case somebody wants to test binaries, you can get it from http://www.cihar.com/xfree86/ (probably only http://www.cihar.com/xfree86/xlibmesa-gl_4.3.0-2.1_i386.deb is needed, but I'm too lazy to check it more deeply :-). Please don't version unofficial packages that way, as they will only cause confusion (and collision) in the event that xfree86 4.3.0-2 is NMUed. I suggest something like: 4.3.0-2.cihar.1 ...where the last number can be incremented as many times as you please. -- G. Branden Robinson| When dogma enters the brain, all Debian GNU/Linux | intellectual activity ceases. [EMAIL PROTECTED] | -- Robert Anton Wilson http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Processed: Re: Bug#234812: xserver-xfree86: preconfigure script hangs while runing discovery
Processing commands for [EMAIL PROTECTED]: tag 234812 + moreinfo Bug#234812: xserver-xfree86: preconfigure script hangs while runing discovery There were no tags set. Tags added: moreinfo retitle 234812 xserver-xfree86: configure script hangs Bug#234812: xserver-xfree86: preconfigure script hangs while runing discovery Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: who is the author of the Linux evdev patch to lnx_kbd.c?
On Thu, Feb 26, 2004 at 01:55:40PM -0500, Branden Robinson wrote: The evdev patch to lnx_kbd.c (attached) in XFree86 4.3.0 is fairly large, and contains no author information. Furthermore, the changes are substantial enough that copyright probably resides in them. Can either of you guys shed some light on who wrote this code? warp did, IIRC. -- Daniel Stone [EMAIL PROTECTED] The programs are documented fully by _The Rise and Fall of a Fooish Bar_, available by the Info system. -- debian/manpage.sgml.ex, dh_make template pgpHIHpNUUmH5.pgp Description: PGP signature
Bug#234556: xlibs: many clients get BadLength error from X_ChangeProperty request
Can somebody explain to me the meaning of Address 0x30c out of bounds
in gdb
I think I get two of these nice babies in the code:
When writing to the socket:
On Thu, 2004-02-26 at 16:50, Emmanuel Fleury wrote:
(gdb)
_X11TransWrite (ciptr=0x83b0cf0, buf=0x83b0cf0 @[EMAIL PROTECTED],
size=138087664) at Xtrans.c:843
843 return ciptr-transptr-Write (ciptr, buf, size);
(gdb)
_X11TransSocketWrite (ciptr=0x83b0db0, buf=0x83b0db0 \001\002,
size=138087856) at Xtranssock.c:1750
1750 return write (ciptr-fd, buf, size);
(gdb)
1744 {
(gdb)
1750 return write (ciptr-fd, buf, size);
(gdb)
1752 }
(gdb)
_X11TransWrite (ciptr=0x30c, buf=0x30c Address 0x30c out of bounds,
size=780)
at Xtrans.c:844
844 }
And then, when reading from the socket (which seems to be normal as we
put it into the socket like this, I guess...):
_X11TransSocketRead (ciptr=0xb4f0, buf=0xb4f0
[EMAIL PROTECTED], size=-1073744656) at Xtranssock.c:1736
1736 return read (ciptr-fd, buf, size);
(gdb)
1730 {
(gdb)
1736 return read (ciptr-fd, buf, size);
(gdb)
1738 }
(gdb)
_X11TransRead (ciptr=0x20, buf=0x20 Address 0x20 out of bounds,
size=32)
at Xtrans.c:837
837 }
(gdb)
My guess is that it is the cause of the error message (I had hard time
to get through all these functions... ^_^). But I might be wrong of
course.
Now, what is puzzling me is:
What is the cause of this address out of bounds ???
At least, it is highly reproducible once I get my laptop stuck in this
strange mode... I hope I'm getting closer !
Regards
--
Emmanuel Fleury
Computer Science Department, | Office: B1-201
Aalborg University, | Phone: +45 96 35 72 23
Fredriks Bajersvej 7E, | Fax:+45 98 15 98 89
9220 Aalborg East, Denmark | Email: [EMAIL PROTECTED]
X Strike Force XFree86 SVN commit: r1110 - in trunk/debian: . po
Author: branden Date: 2004-02-26 15:34:20 -0500 (Thu, 26 Feb 2004) New Revision: 1110 Modified: trunk/debian/changelog trunk/debian/po/fr.po Log: Update French translations (thanks, Christian Perrier and debian-l10n-french!). (Closes: #234903) Re-run debconf-updatepo. Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-02-26 16:26:13 UTC (rev 1109) +++ trunk/debian/changelog 2004-02-26 20:34:20 UTC (rev 1110) @@ -136,8 +136,12 @@ - debian/patches/202_alpha_elfloader_support_R_ALPHA_SREL32.diff: new file - debian/patches/303_arm_cache_flush.diff: resynced - -- Branden Robinson [EMAIL PROTECTED] Tue, 24 Feb 2004 03:49:00 -0500 + * Update French translations (thanks, Christian Perrier and +debian-l10n-french!). Re-run debconf-updatepo. (Closes: #234903) +- debian/po/fr.po + -- Branden Robinson [EMAIL PROTECTED] Thu, 26 Feb 2004 15:31:48 -0500 + xfree86 (4.3.0-2) unstable; urgency=low * The It's like I have a shotgun in my mouth, I've got my finger on the Modified: trunk/debian/po/fr.po === --- trunk/debian/po/fr.po 2004-02-26 16:26:13 UTC (rev 1109) +++ trunk/debian/po/fr.po 2004-02-26 20:34:20 UTC (rev 1110) @@ -1,7 +1,10 @@ # xfree86 debconf template strings -# Copyright (C) 2000--2003 Branden Robinson +# French translations +# +# Copyright Branden Robinson [EMAIL PROTECTED], 2000--2003. +# Copyright Christian Perrier and others, 2001-2004. +# # This file is distributed under the same license as the xfree86 package. -# Branden Robinson [EMAIL PROTECTED], 2000. # #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to @@ -14,13 +17,12 @@ # 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.2.1-10\n Report-Msgid-Bugs-To: \n POT-Creation-Date: 2004-02-20 18:32-0500\n -PO-Revision-Date: 2003-08-24 09:57+0100\n +PO-Revision-Date: 2004-02-26 15:12+0100\n Last-Translator: Christian Perrier [EMAIL PROTECTED]\n Language-Team: Debiand french translation team [EMAIL PROTECTED] debian.org\n @@ -403,7 +405,6 @@ #. Type: multiselect #. Description #: ../xserver-xfree86.templates:66 -#, fuzzy msgid It is possible to customize (or completely omit) the list of modules that the X server loads by default. This option is for advanced users. In most @@ -411,8 +412,8 @@ msgstr Il est possible de personnaliser (ou de vider compl�tement) la liste des modules charg�s par d�faut par le serveur X. Cette option est destin�e aux -utilisateurs exp�riment�s. Dans la plupart des cas, tous ces modules sauf -��xtt�� devraient �tre s�lectionn�s. +utilisateurs exp�riment�s. Dans la plupart des cas, tous ces modules +devraient �tre s�lectionn�s. #. Type: multiselect #. Description @@ -485,6 +486,8 @@ The bitmap, freetype, speedo, type1, and xtt modules are all font rasterizers. msgstr +Les modules bitmap, freetype, speedo, type1 et xtt sont tous des modules +d'affichage de polices. #. Type: multiselect #. Description @@ -499,18 +502,16 @@ #. Type: multiselect #. Description #: ../xserver-xfree86.templates:66 -#, fuzzy msgid If you unsure what to do, leave all of the modules enabled. Advanced users may wish to disable all modules -- in which case no Modules section will be written to the X server configuration file -- and add their own Modules section to the file manually. msgstr -Si vous n'�tes pas certain du bon choix, activez tous les modules sauf -��xtt��. Les utilisateurs exp�riment�s peuvent pr�f�rer d�sactiver tous les -modules (dans ce cas, aucune section ��Modules�� ne sera cr��e dans le -fichier de configuration de X) et peuvent alors cr�er manuellement la -section ��Modules��. +Si vous n'�tes pas certain du bon choix, activez tous les modules. Les +utilisateurs exp�riment�s peuvent pr�f�rer d�sactiver tous les modules (dans +ce cas, aucune section ��Modules�� ne sera cr��e dans le fichier de +configuration de X) et peuvent alors cr�er eux-m�mes la section ��Modules��. #. Type: note #. Description @@ -1688,19 +1689,3 @@ #~ msgstr #~ Les types ��pc102�� et ��pc105�� sont les versions des mod�les ��pc101�� #~ et ��pc104�� respectivement, que l'on trouve fr�quemment en Europe. - -#~ msgid -#~ The bitmap, freetype, speedo, type1, and xtt modules are all font -#~ rasterizers. The freetype and xtt modules should not be enabled at the -#~ same time, as they are incompatible. The freetype module should be used -#~ for Western languages and anti-aliased font support; the xtt module -#~ should be used for East Asian character set support (specifically, for -#~ CID-keyed fonts). -#~ msgstr -#~ Les modules ��bitmap��, ��freetype��,
X Strike Force XFree86 SVN property change: propchange - r1097 svn:log
Author: branden Revision: 1097 Property Name: svn:log New Property Value: Update Brazilian Portuguese translations (thanks, Andr?\195?\169 Lu?\195?\173s Lopes). (Closes: #234060) Re-run debconf-updatepo.
Bug#234903: xfree86: [INTL:fr] French debconf templates translation
On Thu, Feb 26, 2004 at 03:13:28PM +0100, Christian Perrier wrote: Package: xfree86 Version: N/A Severity: wishlist Tags: patch l10n Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. Thank you! I'll be checking this in to SVN shortly. There is one fuzzy template (probably a false positive due to a missing-word typo fix in English), and one untranslated template. #. Type: multiselect #. Description #: ../xserver-xfree86.templates:66 #, fuzzy msgid The vbe and ddc modules enable support for VESA BIOS Extensions and Data Display Channel, respectively. These modules are used to query monitor capabilties via the video card. The int10 module is a real-mode x86 emulator that is used to softboot secondary VGA cards. Note that the vbe module depends on the int10 module, so if you wish to enable vbe, enable int10 as well. msgstr Les modules « vbe » et « ddc » permettent respectivement la compatibilité avec les extensions « VESA BIOS » et « Data Display Channel ». Ces modules sont utilisés pour obtenir les caractéristiques de l'écran via la carte vidéo. Le module « int10 » est un émulateur x86 en mode réel qui permet d'amorcer les cartes VGA secondaires. Notez que le module « vbe » dépend du module « int10 » ; si vous souhaitez l'utiliser, il faut donc également utiliser « int10 ». #. Type: string #. Description #: ../xserver-xfree86.templates:214 msgid The \pc102\ and \pc105\ models are versions of the pc101 and pc104 keyboards, respectively, often found in Europe. If your keyboard has a \ \ key (a single key engraved with both the less-than and greater-than symbols), you likely have a \pc102\ or \pc105\ model; if you choose \pc101\ or \pc104\ instead, your \ \ key might not work. msgstr #~ msgid #~ The \pc102\ and \pc105\ models are versions of the pc101 and pc104 #~ keyboards, respectively, often found in Europe. #~ msgstr #~ Les types « pc102 » et « pc105 » sont les versions des modèles « pc101 » #~ et « pc104 » respectivement, que l'on trouve fréquemment en Europe. The complete file as it will be checked in to SVN is MIME-attached. If you can provide another update, that would be great; otherwise, don't worry about it. -- G. Branden Robinson|I just wanted to see what it looked Debian GNU/Linux |like in a spotlight. [EMAIL PROTECTED] |-- Jim Morrison http://people.debian.org/~branden/ | # xfree86 debconf template strings # French translations # # Copyright Branden Robinson [EMAIL PROTECTED], 2000--2003. # Copyright Christian Perrier and others, 2001-2004. # # This file is distributed under the same license as the xfree86 package. # #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.2.1-10\n Report-Msgid-Bugs-To: \n POT-Creation-Date: 2004-02-20 18:32-0500\n PO-Revision-Date: 2004-02-26 15:12+0100\n Last-Translator: Christian Perrier [EMAIL PROTECTED]\n Language-Team: Debiand french translation team [EMAIL PROTECTED] debian.org\n MIME-Version: 1.0\n Content-Type: text/plain; charset=ISO-8859-15\n Content-Transfer-Encoding: 8bit\n #. Type: select #. Description #: ../xdm.templates:4 msgid Select the desired default display manager. msgstr Choisissez le gestionnaire graphique de session par d�faut #. Type: select #. Description #: ../xdm.templates:4 msgid A display manager is a program that provides graphical login capabilities for the X Window System. msgstr Un gestionnaire graphique de session est un programme qui permet de se connecter � la machine depuis le syst�me X Window. #. 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 Un seul gestionnaire graphique de session peut s'occuper d'un serveur X donn�, bien que plusieurs gestionnaires puissent �tre install�s simultan�ment. Veuillez choisir celui qui sera utilis� par d�faut. #. 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 Plusieurs gestionnaires graphiques peuvent �tre lanc�s en m�me temps, s'ils g�rent des serveurs X
X Strike Force XFree86 SVN commit: r1111 - trunk/debian
Author: branden Date: 2004-02-26 15:36:30 -0500 (Thu, 26 Feb 2004) New Revision: Modified: trunk/debian/changelog Log: Use imperative mood in changelog entries. (Just like that!) Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-02-26 20:34:20 UTC (rev 1110) +++ trunk/debian/changelog 2004-02-26 20:36:30 UTC (rev ) @@ -101,7 +101,7 @@ Re-run debconf-updatepo. (Closes: #234049) - debian/po/ja.po - * Updated Brazilian Portuguese translations (thanks, André Luís Lopes). + * Update Brazilian Portuguese translations (thanks, André Luís Lopes). Re-run debconf-updatepo. (Closes: #234060) - debian/po/pt_BR.po
Bug#234113: I have the same bug, XF86Config-4 included
On Thu, Feb 26, 2004 at 09:58:06PM +0100, Markus Meissner wrote: On Thursday 26 February 2004 20:23, Branden Robinson wrote: On Tue, Feb 24, 2004 at 11:06:38PM +0100, Markus Meissner wrote: On Tuesday 24 February 2004 21:52, Branden Robinson wrote: Also, have you modified any of the XKB conffiles in /etc/X11/xkb? No, to be honest I didn't noticed those conffiles before you ask me =) On my iBook, I use the XkbModel macintosh. Perhaps that will help? Thanks for the hint but no, that doesn't make a difference, at least no difference for the tilde. FWIW someone reported on debian-user-french a problem with his Shift key, and it turned out that for unknown reasons (disk full?) some files were missing under /etc/X11/xkb. Maybe you could try to reinstall xlibs? Denis
Bug#56179: (no subject)
Received: from 46.160.16.184 by 200.90.215.175; Thu, 26 Feb 2004 17:35:37 -0700 Message-ID: [EMAIL PROTECTED] From: Gus Larson [EMAIL PROTECTED] Reply-To: Gus Larson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: a friend did this to you IC 42 Date: Thu, 26 Feb 2004 18:37:37 -0600 (EST) X-Mailer: Atlas Mailer 2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=--0479055821365684 X-Priority: 3 X-MSMail-Priority: Normal 0479055821365684 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A friend has set you up on a blind date with another friend. Confirm or Reschedule here: http://stupidlovelife.com/confirm/?oc=52212223 no thx http://stupidlovelife.com/remove/?oc=52217551 whatsoever champhoofmarkdiophantine connecticut 0479055821365684--
Re: Question on X and new license...
On Thu, Feb 26, 2004 at 02:03:47PM -0500, Branden Robinson wrote: On Thu, Feb 26, 2004 at 12:59:19PM +0100, Sven Luther wrote: On Sun, Feb 22, 2004 at 11:43:24PM -0500, Branden Robinson wrote: * David Dawes, President of The XFree86 Project, Inc., claims that a a decision to apply the X-Oz license to any client side library code shipped by that organization has been deferred.[1] This statement is a lot weaker than a guarantee that it never will happen. Yeah, but i believe this is more politicking than anything else. Branden, do you know the real story behind this whole stuff anyway ? No. I suspect there's only one person who does, and he appears to be adamant that there's nothing more to know. Yeah, i suspect there is more than one though. * Code that forms part of the XFree86 SDK, a driver development kit (which there has been some work to package for Debian) *is* under the X-Oz license, and would prohibit the development of GPL-licensed drivers for the XFree86 X server. Mmm, i would like to look into this, and see if i can manage to get those files changed if needed. Also, you only would need to dual-licence those drivers under the GPL and the X-Oz licence, which would not be an all that bad thing politically. If you could: 1) identify all files shipped by the SDK affected by the relicensing; and 2) a) get them relicensed under the previous license; or b) get them dual-licensed under the GNU GPL; and 3) get a statement from the XFree86 Project, Inc., that any file shipped as part of the SDK in the future will be handled the same as the ones that are part of it today ...then I'd be very appreciative! I think many people in the community would be as well. Yeah, will look at this, but am a bit doubtful i will achieve this. * I have argued to the debian-x mailing list that the X-Oz license is actually not even a Free Software license, because, at the least, it fails clause 9 of the Debian Free Software Guidelines in two distinct ways. If you're interested, you may wish to read my message[2] to that list. (It is worth noting that the debian-legal subscribers have not formed a strong consensus one way or the other regarding the DFSG-freeness of the X-Oz license; the matter is still pending.) Your main argument seems to be that this is failing DFSG 9, because it places restriction on other software on the same media. I believe that XFree86 interpretation of this, as expressed in their legal FAQ which should accompany the licence, clearly state that this is not the case, that it will only apply to derived works, and that providing credit to XFree86, inside the Release notes document for example, should be enough. I tried to follow a link to the FAQ from here: http://www.xfree86.org/xnews/#license But it didn't work. Not Found The requested URL /xnews/legal/licenses.html was not found on this server. It is here : http://www.xfree86.org/legal/licenses.html I guess the xnews part is oo much. Friendly, Sven Luther
Re: Question on X and new license...
On Thu, Feb 26, 2004 at 11:57:44AM -0800, Chris Waters wrote: * Code that forms part of the XFree86 SDK, a driver development kit (which there has been some work to package for Debian) *is* under the X-Oz license, and would prohibit the development of GPL-licensed drivers for the XFree86 X server. Mmm, i would like to look into this, and see if i can manage to get those files changed if needed. Also, you only would need to dual-licence those drivers under the GPL and the X-Oz licence, which would not be an all that bad thing politically. Dual-licensing would defeat the purpose of GPLing the drivers, i.e. it would open them up to proprietary exploitation by others. Well, if you are going to write drivers which cannot be used by the XFree86 project, it is understandable that they won't go to an effort to make you writing them easy. Friendly, Sven Luther
Bug#234812: 234812 xserver-xfree86: configure script hangs
In reply to: - tag 234812 + moreinfo retitle 234812 xserver-xfree86: configure script hangs thanks You did not include a description of your problem in the body of your bug report. Are you saying that the discover command hangs? If so, does it hang from the command-line? - Yes, it does. When I run 'apt-get install' processing stops with 'discover --format=... video' process hanged. When I run gdb on this discover process, it looks like it hangs in libc close() function, called from close_serial_port() (libdiscover.so.1). If I enter 'c(ontinue)' discover continues and prints correct video card description. So it looks as a discover bug (I will report it), but why does discover scans for serial ports? I have 'disable serial' in my /etc/discover.conf. Pawel Palucha
Bug#45291: picture yourself impressing the ladies
The results were really better, trust me as a doctor. I'd recommend it to anybody who has erection troubles. P.S.: By the way, you can mix Cialis with alcohol without any harm! read on here http://herbsbusiness.com/sv/index.php?pid=eph2145 http://medspro.net/sv/applepie.php
Bug#24192: what you gonna do guys
The results were really better, trust me as a doctor. I'd recommend it to anybody who has erection troubles. P.S.: By the way, you can mix Cialis with alcohol without any harm! read on here http://herbsbusiness.com/sv/index.php?pid=eph2145 http://medspro.net/sv/applepie.php
Bug#126519: im showing off to the girls now
The results were really better, trust me as a doctor. I'd recommend it to anybody who has erection troubles. P.S.: By the way, you can mix Cialis with alcohol without any harm! read on here http://herbsbusiness.com/sv/index.php?pid=eph2145 http://medspro.net/sv/applepie.php
Bug#22506: are you having issues with your man hood
The results were really better, trust me as a doctor. I'd recommend it to anybody who has erection troubles. P.S.: By the way, you can mix Cialis with alcohol without any harm! read on here http://herbsbusiness.com/sv/index.php?pid=eph2145 http://medspro.net/sv/applepie.php
Bug#24192: gentian osha bivariate kombu darlene petroleum augustus anarchy capita sail disembowel an ellipse pilate will sse creedal vision arcsine tremble zealand dilemma bloodline quarrel cram combinator anharmonic nadia husbandmen eduardo baffle oslo debtor
fabuklous! I took the only one pijll of Cialgs and that was such a GREAT weekend! All the girls at the party were just punch-drungk with my potentiagl I have fgcked all of them THREE times but my dgck WAS able to do some more! Cgalis - it`s COOL!!! The best weekend stuff I've ever trgied! Haven`t you tgried yet? DO IT at http://waytosucess.com/sv/index.php?pid=evaph4124 able boy quick cough agway backstage counterpart incendiary incompatible florid inject
Bug#116507: (no subject)
Bug#234113: I have the same bug, XF86Config-4 included
On Thursday 26 February 2004 22:24, Denis Barbier wrote: FWIW someone reported on debian-user-french a problem with his Shift key, and it turned out that for unknown reasons (disk full?) some files were missing under /etc/X11/xkb. Maybe you could try to reinstall xlibs? Thanks again for the hint but no, that doesn't solve the problem, sorry. -- Beste Gruesse / Best regards Markus Meissner
Re: who is the author of the Linux evdev patch to lnx_kbd.c?
On Thu, Feb 26, 2004 at 01:55:40PM -0500, Branden Robinson wrote: The evdev patch to lnx_kbd.c (attached) in XFree86 4.3.0 is fairly large, and contains no author information. Furthermore, the changes are substantial enough that copyright probably resides in them. Can either of you guys shed some light on who wrote this code? Copyright 2003 Zephaniah E. Hull. Under the old X license. (Or did I do most of that work in 2002?) -- 1024D/E65A7801 Zephaniah E. Hull [EMAIL PROTECTED] 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. I would rather spend 10 hours reading someone else's source code than 10 minutes listening to Musak waiting for technical support which isn't. (By Dr. Greg Wettstein, Roger Maris Cancer Center) signature.asc Description: Digital signature
Bug#235039: libxpm4 postinst runs bad 'grep' instance and stalls
Package: libxpm4 Version: 4.3.0-2 Severity: important Hey there libxpm4 appears to have a bad 'fgrep' in the postinst. Here's what it's actually running: root 17552 0.0 0.4 1540 404 pts/1S03:52 0:00 grep -F -qsvx /usr/X11R6/lib It looks like 581 of libxpm4.postinst is the culprit, with the following grep invocation: fgrep -qsvx $dir $ldsoconf.dpkg-tmp I'm not entirely sure what it's supposed to be doing, so I'll refrain from suggesting any solutions. I will note though, in case it isn't really obvious, that there is no second non-option argument to grep - it's likely waiting on STDIN, looking for the term $dir expands to. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.25-linode23-1um Locale: LANG=C, LC_CTYPE=C Versions of packages libxpm4 depends on: ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an -- no debconf information
Bug#24192: doc said ya you can try it out
All that problems affected my selxual activity, my wife was not as happy as before with me. read more http://newherbs.com/sv/index.php?pid=eph2145 http://medspro.net/sv/applepie.php
