Bug#111264: Fixed in unstable
Just checked: in 4.3.0.dfsg.1-5 truetype rendering works fine via both freetype and xtt. -- Alexander Kotelnikov Saint-Petersburg, Russia
Bug#256863: This bug can probably be closed
Branden Robinson [EMAIL PROTECTED] writes: [...] Well, I think what the code does is make buttons that were formerly numbered 6 and 7 numbered 4 and 5 instead. Ah, that sounds right. How recently did you notice this change in scroll wheel behavior? What version of the xfree86 packages were you running previously? Very recently (in the last couple of weeks). So September 2003 doesn't seem possible. I've been running unstable for about a year, (updating most days) so I've presumably been running 4.2.1-12 and later for a long time. You didn't happen to have your X server up for a good 8--10 months, did you? No, that can't be it. I was running X from an experimental source for a while, so I guess it's possible that I somehow missed it before. It doesn't feel likely, but these things happen. Anyway, everything's working now with the mouse. [...]
Re: X Strike Force XSF toolbox SVN commit: r3 - trunk/bin
On Sat, 10 Jul 2004, X Strike Force SVN Repository Admin wrote: Author: branden Date: 2004-07-10 18:04:56 -0500 (Sat, 10 Jul 2004) New Revision: 3 Added: trunk/bin/markpending Log: Add markpending script. Branden, what is the path to access this repository? Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
X Strike Force XFree86 SVN commit: r1623 - people/fabbione/trunk/debian
Author: fabbione Date: 2004-07-11 06:38:50 -0500 (Sun, 11 Jul 2004) New Revision: 1623 Added: people/fabbione/trunk/debian/CHANGESET Log: Add CHANGESET to track branch activity. Added: people/fabbione/trunk/debian/CHANGESET === --- people/fabbione/trunk/debian/CHANGESET 2004-07-10 21:38:26 UTC (rev 1622) +++ people/fabbione/trunk/debian/CHANGESET 2004-07-11 11:38:50 UTC (rev 1623) @@ -0,0 +1,18 @@ +Changeset Log += + +$Id$ + +This file identifies trunk revisions that should be handled (e.g., merged) as a +unit. Standalone updates to the TODO or CHANGESETS files are not recorded here. +(It should always be safe to merge the latest version of TODO or CHANGESETS +files anywhere.) + +Add support for dynamic MANIFEST files. +1362 + +Do not build fonts when binary-indep rule is not going to be made (should +speed up builds using dpkg-buildpackage -B or the like, as all buildds do). +1320 + +vim:set ai et sts=4 sw=4 tw=80: Property changes on: people/fabbione/trunk/debian/CHANGESET ___ Name: svn:keywords + Id
X Strike Force XFree86 SVN commit: r1624 - in trunk/debian: . local
Author: branden Date: 2004-07-11 13:31:43 -0500 (Sun, 11 Jul 2004) New Revision: 1624 Modified: trunk/debian/CHANGESETS trunk/debian/local/FAQ.xhtml Log: (cosmetic) Add XHTML markup to a FAQ entry. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-07-11 11:38:50 UTC (rev 1623) +++ trunk/debian/CHANGESETS 2004-07-11 18:31:43 UTC (rev 1624) @@ -13,7 +13,7 @@ 1606 Miscellaneous cosmetic fixes. -1607, 1608 +1607, 1608, 1624 Grab latest version of XTerm (#191) from Thomas Dickey's website. 1609 Modified: trunk/debian/local/FAQ.xhtml === --- trunk/debian/local/FAQ.xhtml2004-07-11 11:38:50 UTC (rev 1623) +++ trunk/debian/local/FAQ.xhtml2004-07-11 18:31:43 UTC (rev 1624) @@ -1847,7 +1847,8 @@ p(Especially heard from KDE users with large monitors, many workspaces, and a different picture in the root window of each workspace.)/p -pAnswer courtesy of Mark Vojkovich of the XFree86 Project, Inc.:/p +pAnswer courtesy of Mark Vojkovich of a href=http://www.xfree86.org/;The +XFree86 Project, Inc./a:/p blockquote pThe X Window System is a client-server window system. The memory for pixmap @@ -1861,22 +1862,26 @@ instead, people would be complaining about KDE memory usage./p /blockquote -pAdditionally, Sean McGlynn of the KDE Project offered assistance:/p +pAdditionally, Sean McGlynn of the a href=http://www.kde.org/;KDE +Project/a offered assistance:/p blockquote - pPlease direct such users over to KDE's mailing lists mdash; - http://www.kde.org/mailinglists.html mdash; and we can try and - investigate/resolve their issues fully./p + pPlease direct such users over to a + href=http://www.kde.org/mailinglists.html;KDE's mailing lists/a mdash; + code class=otherhttp://www.kde.org/mailinglists.html/code mdash; and we + can try and investigate/resolve their issues fully./p /blockquote -pDavid B. Harris of Debian also has these remarks:/p +pDavid B. Harris of a href=http://www.debian.org/;Debian/a also has these +remarks:/p blockquote - pSomething worth noting is also the concept of leaking. This will be a term - familiar to some and unknown to others. Basically, as processes run they - may dynamically allocate memory for some purpose or other. If they allocate - some memory, but never *de-allocate* it, even after they're done using it, - then over time the memory used by that process will increase./p + pSomething worth noting is also the concept of emleaking/em. This will + be a term familiar to some and unknown to others. Basically, as processes run + they may dynamically allocate memory for some purpose or other. If they + allocate some memory, but never emde-allocate/em it, even after they're + done using it, then over time the memory used by that process will + increase./p pSince hardware/video drivers in XFree86 are responsible for some of this allocation and de-allocation, a badly-written driver can increase the memory @@ -1891,7 +1896,8 @@ all) due to these drivers./p /blockquote -pFinally, Mike A. Harris of Red Hat Software offers the following advice:/p +pFinally, Mike A. Harris of a href=http://www.redhat.com/;Red Hat +Software/a offers the following advice:/p blockquote pI'd like to add to that another frequently reported problem of XFree86 @@ -1899,15 +1905,16 @@ can't see any reason why it should. They blame X for being bloated, etc./p pDigging into it more however, 99 times out of 100, they are using the - output of top or procps or similar utility do show how much memory XFree86 is - consuming. Unfortunately, the memory reported as used in top/ps output is - interpreted solely as being system RAM and/or swap, and that is very + output of code class=commandtop/code or code + class=commandprocps/code or similar utility do show how much memory + XFree86 is consuming. Unfortunately, the memory reported as used in top/ps + output is interpreted solely as being system RAM and/or swap, and that is very misleading as it is not true./p - pThe memory shown by top, which users are misled into believing is memory - used up by X, is an amalgamation of the video card's own memory, and memory - mapped I/O regions, as well as the actual memory used by the X server, - pixmaps, and various other things./p + pThe memory shown by code class=commandtop/code, which users are + misled into believing is memory used up by X, is an amalgamation of the video + card's own memory, and memory mapped I/O regions, as well as the actual memory + used by the X server, pixmaps, and various other things./p pIt is not at all uncommon for a modern 64Mb video card, to have X's memory usage appear to be 100Mb or more, when in reality, 64Mb of that is video RAM,
Bug#257062: Please include the new intel driver
On Sat, 2004-07-10 at 18:26 -0500, Branden Robinson wrote: tag 257062 + help thanks On Fri, Jul 09, 2004 at 11:55:40AM +0100, Pedro Corte-Real wrote: On Thu, 2004-07-08 at 18:48 -0500, Branden Robinson wrote: On Wed, Jun 30, 2004 at 10:17:40PM +0100, Pedro Corte-Real wrote: Keith Whitwell created a new driver for the intel graphics cards from the i830 to the new i915. This driver supports more cards than the existing one and according to the developers supports using the second monitor (the external monitor on a laptop) as a different screen. Could you please include this driver in the package? We need to know if any part of it uses the new XFree86 1.1 license. If so, we cannot include it. [...] I'll ask the developer, but since this is developed in the dri tree it should be alright. Driver is at: http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/src/mesa/drivers/dri/i915/ So it's even in freedesktop.org so should be alright. Okay. I looked around there and you appear to be right. I'll await word back from the upstream developer via you, though. I haven't got an answer from the developer yet. But if it's in freedesktop.org... Would someone on the debian-x list who actually owns i915 box like to undertake this? How about someone with any other Intel video chipset, at least see if any regressions are caused? There's probably no one that owns a i915 yet because the motherboards with it are just coming out. OTOH anyone with a board that uses the i810/i830 driver should be able to use this and this driver should be better than the old one. Pedro. signature.asc Description: This is a digitally signed message part
Bug#257302: xfree86: general complaint about XFree86 on Dell Latitude D400
On Saturday 10 July 2004 19:23, Branden Robinson wrote: Doesn't d-i install mdetect to autodetect the mouse? D-i does install both read-edid and mdetect during first stage installation. However, they are both _uninstalled_ somewhere during base-config. (See also #250422) I have noticed myself that if read-edid and mdetect are installed at the same time as xfree-xserver86 (e.g. by selecting them from the suggests list), they may not be used during X configuration (as they are not yet set up at that time). Cheers, FJP
Bug#257302: xfree86: general complaint about XFree86 on Dell Latitude D400
Frans Pop wrote: On Saturday 10 July 2004 19:23, Branden Robinson wrote: Doesn't d-i install mdetect to autodetect the mouse? D-i does install both read-edid and mdetect during first stage installation. However, they are both _uninstalled_ somewhere during base-config. (See also #250422) No, read-edid and mdetect are installed by base-config (but see bug #258690), prior to package installation. They are later removed, iff X was not installed. I have noticed myself that if read-edid and mdetect are installed at the same time as xfree-xserver86 (e.g. by selecting them from the suggests list), they may not be used during X configuration (as they are not yet set up at that time). Since X doesn't declare a dependency on them, selecting them for install at the same time as X does not even guarantee they'll be _unpacked_ when X is conigured. And they will certianly not be available when it's preconfigured. This is why base-config is complicated with the need to mess with read-edid and mdetect itself, and why I'm left with bugs such as #250422 which I cannot fix. There are other, better ways this could be done, but they all require reorganising how X's configuration is done. -- see shy jo signature.asc Description: Digital signature
Bug#258164: xdm: crashed when clicking things in mozilla
Crashed again even after leaving mozilla for another window. However: Odd, it only happened that one day -- the first day in a week of no power due to the typhoon, with 1.5 meter of rain. So maybe it was hardware related. If I don't reply in a month, you can close this bug.
Bug#258874: xbase-clients: startx hangs on startup with configured network which isn'tconnected
Package: xbase-clients Version: 4.3.0.dfsg.1-6 Severity: normal When starting X (startx or wdm) with a configured network but no network cable pluged in then X hands on a network timeout. (running tcpdump shows arp requests looking for the nameserver/gateway). This started on the upgrade from dfsg.1-5 to dfsg.1-6 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.27-pre3-s2 Locale: LANG=he_IL, LC_CTYPE=he_IL Versions of packages xbase-clients depends on: ii cpp 4:3.3.4-1The GNU C preprocessor (cpp) ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libdps1 4.3.0.dfsg.1-6 Display PostScript (DPS) client li ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig1 2.2.2-2 generic font configuration library ii libfreetype62.1.7-2.1FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-6 Inter-Client Exchange library ii libncurses5 5.4-4Shared libraries for terminal hand ii libpng12-0 1.2.5.0-6PNG library - runtime ii libsm6 4.3.0.dfsg.1-6 X Window System Session Management ii libstdc++5 1:3.3.4-3The GNU Standard C++ Library v3 ii libxaw7 4.3.0.dfsg.1-6 X Athena widget set library ii libxcursor1 1.1.3-1 X cursor management library ii libxext64.3.0.dfsg.1-6 X Window System miscellaneous exte ii libxft2 2.1.2-6 FreeType-based font drawing librar ii libxi6 4.3.0.dfsg.1-6 X Window System Input extension li ii libxmu6 4.3.0.dfsg.1-6 X Window System miscellaneous util ii libxmuu14.3.0.dfsg.1-6 lightweight X Window System miscel ii libxpm4 4.3.0.dfsg.1-6 X pixmap library ii libxrandr2 4.3.0.dfsg.1-6 X Window System Resize, Rotate and ii libxrender1 0.8.3-7 X Rendering Extension client libra ii libxt6 4.3.0.dfsg.1-6 X Toolkit Intrinsics ii libxtrap6 4.3.0.dfsg.1-6 X Window System protocol-trapping ii libxtst64.3.0.dfsg.1-6 X Window System event recording an ii libxv1 4.3.0.dfsg.1-6 X Window System video extension li ii xlibmesa-gl1-dri-ma 4.3.0.cvs.20040114-1 Mesa 3D graphics library [DRI mach ii xlibmesa-glu [libgl 4.3.0.dfsg.1-6 Mesa OpenGL utility library [XFree ii xlibs 4.3.0.dfsg.1-6 X Window System client libraries m ii xlibs-data 4.3.0.dfsg.1-6 X Window System client data ii zlib1g 1:1.2.1.1-3 compression library - runtime -- no debconf information
hurd-i386 updates
Hello, I've brought the hurd-i386 port of xfree86 back on track. The hurd port had some 4.1 packages and later on some 4.3.0-0pre1 or something packages from before the xlibs-split. Both of them were not available on ftp.debian.org due to extra hacking required. Initially, I took the xfree86-4.3.0.dfsg.1-4 source package and the k*BSD patch from http://glibc-bsd.alioth.debian.org/patches/xfree86_4.3.0.dfsg.1-4.diff I needed to tweak a couple of .install files to .install.hurd-i386 and fix a parse error in xc/programs/xterm/xterm_io.h or similar introduced in the k*BSD patch but that was it. The resulting packages are up at the ftp.gnuab.org repository and they work well on my Radeon7500 with the ati driver. However, the k*BSD patches are pretty big and Robert Millan apparently wants to get them applied upstream, which seems works quite well. On the other hand, the hurd-i386 needs updated xfree86 packages on ftp.debian.org ASAP to continue the development effort. Thus, I've just updated the 80* series of patches to make xfree86 build and install on hurd-i386. The attached file xfree86_gnu_patches.diff contains those. In order to have a clear look at the differences between linux.cf and gnu.cf, I shuffled gnu.cf around and reformatted some parts, in order to sync the two and make the diff somewhat easy to read. The main questions are the following defines, which were missing in gnu.cf (diff from linux.cf to gnu.cf): -# define StaticNeedsPicForShared NO -# define KernelVersionInBannerYES Should we have those? What is the default for the first? I did not add them for now. -# define BuildRenderLibrary NO -# define HasRenderLibrary YES -# define BuildXcursorLibrary NO -# define HasXcursorLibraryYES -#ifndef HasLibpng -#define HasLibpng YES -#ifndef HasGroff -#define HasGroff YES As hurd-i386 has those libraries/programs now, I added those. -# define FontLibSharedFreeType NO This one causes a build failure even with the current trunk, as xc/lib/font/libXFont apparently does not get built on Linux and xc/lib/font/Freetype/fcfuncs.c needs to be updated for current libfreetype6. I added the #define to gnu.cf as well, is that reasonable? The addition of the xcursor stuff and the definition of Groff resulted in a changed MANIFEST.hurd-i386, which I updated. Those changes are attached in xfree86_hurd-i386.diff. Please tell me whether the changes are good or whether I should proceed differently. I tested them against subversion trunk (revision 1623) as well as revision -6 of 4.3.0.dfsg.1 and they applied (after a bit of fussing around) and worked (as in built and ran) fine. However, I did no test build on GNU/Linux, so if you feel this is required let me know. I doubt it should break something, though. It would be nice if hurd-i386 could be back on line with the next upload. cheers, Michael diff -Naur debian.orig/MANIFEST.hurd-i386 debian/MANIFEST.hurd-i386 --- debian.orig/MANIFEST.hurd-i386 2004-07-11 19:38:16.0 +0200 +++ debian/MANIFEST.hurd-i386 2004-07-11 19:38:30.0 +0200 @@ -505,6 +505,7 @@ usr/X11R6/bin/xclock usr/X11R6/bin/xcmsdb usr/X11R6/bin/xconsole +usr/X11R6/bin/xcursorgen usr/X11R6/bin/xcutsel usr/X11R6/bin/xditview usr/X11R6/bin/xdm @@ -1193,6 +1194,49 @@ usr/X11R6/lib/X11/doc/evi.txt usr/X11R6/lib/X11/doc/fontlib.txt usr/X11R6/lib/X11/doc/fsproto.txt +usr/X11R6/lib/X11/doc/html/DPMS.html +usr/X11R6/lib/X11/doc/html/DPMSLib.html +usr/X11R6/lib/X11/doc/html/ICElib.html +usr/X11R6/lib/X11/doc/html/LocaleDB.html +usr/X11R6/lib/X11/doc/html/SMlib.html +usr/X11R6/lib/X11/doc/html/XIMTransport.html +usr/X11R6/lib/X11/doc/html/XiLib.html +usr/X11R6/lib/X11/doc/html/XiPorting.html +usr/X11R6/lib/X11/doc/html/XiProtocol.html +usr/X11R6/lib/X11/doc/html/Xtrans.html +usr/X11R6/lib/X11/doc/html/appgroup.html +usr/X11R6/lib/X11/doc/html/bdf.html +usr/X11R6/lib/X11/doc/html/bigreq.html +usr/X11R6/lib/X11/doc/html/buffer.html +usr/X11R6/lib/X11/doc/html/ctext.html +usr/X11R6/lib/X11/doc/html/ctlseqs.html +usr/X11R6/lib/X11/doc/html/ddx.html +usr/X11R6/lib/X11/doc/html/evi.html +usr/X11R6/lib/X11/doc/html/fontlib.html +usr/X11R6/lib/X11/doc/html/fsproto.html +usr/X11R6/lib/X11/doc/html/i18nFramework.html +usr/X11R6/lib/X11/doc/html/icccm.html +usr/X11R6/lib/X11/doc/html/ice.html +usr/X11R6/lib/X11/doc/html/intrinsics.html +usr/X11R6/lib/X11/doc/html/mit-shm.html +usr/X11R6/lib/X11/doc/html/proto.html +usr/X11R6/lib/X11/doc/html/record.html +usr/X11R6/lib/X11/doc/html/recordlib.html +usr/X11R6/lib/X11/doc/html/rstart.html +usr/X11R6/lib/X11/doc/html/shape.html +usr/X11R6/lib/X11/doc/html/shapelib.html +usr/X11R6/lib/X11/doc/html/tog-cup.html +usr/X11R6/lib/X11/doc/html/widgets.html +usr/X11R6/lib/X11/doc/html/xc-misc.html +usr/X11R6/lib/X11/doc/html/xdmcp.html +usr/X11R6/lib/X11/doc/html/xfs-design.html +usr/X11R6/lib/X11/doc/html/xim.html
Processed: Re: Bug#254288: xserver-xfree86: [ati] Drops blue bit at depth 24-bit
Processing commands for [EMAIL PROTECTED]: tag 254288 = upstream Bug#254288: xserver-xfree86: [ati/atimisc] blue bit dropped at depth 24 on 264VT [Mach64 VT] rev 64 Tags were: moreinfo Tags set to: upstream retitle 254288 xserver-xfree86: [ati/atimisc] poor support for color depths 16 and 24 on 264VT [Mach64 VT] rev 64 Bug#254288: xserver-xfree86: [ati/atimisc] blue bit dropped at depth 24 on 264VT [Mach64 VT] rev 64 Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#254288: xserver-xfree86: [ati] Drops blue bit at depth 24-bit
tag 254288 = upstream retitle 254288 xserver-xfree86: [ati/atimisc] poor support for color depths 16 and 24 on 264VT [Mach64 VT] rev 64 thanks On Sat, Jul 10, 2004 at 12:23:53PM +1000, Peter Dey wrote: There's more than one bit of blue at depth 24; there are 8 bits of blue (and 8 bits of green, and 8 bits of red). Do you mean that the entire blue channel is missing at depth 24? Yes, that's correct. The entire blue channel is missing. [...] Can you elaborate? What do solid red, blue, and green look like? % xlogo -fg red -bg black % xlogo -fg green -bg black % xlogo -fg blue -bg black At 24-bit: -fg red Red -fg green Green -fg blue Red White (e.g. the background of google) looks like Yellow. At 16-bit: -fg red swirly pink, black and blue? -fg green swirly pink, black and green? -fg blue swirly blue, green and black? However, White is still white And black (e.g. background of a term window) is still black Thanks for following up. This sounds pretty definitively like an upstream driver bug. I'm tweaking the bug parameters accordingly. In the meantime I can only advise that you stick to color depth 8 (though depth 15 might be worth a try). I know that sucks. :( -- G. Branden Robinson| The Bible is probably the most Debian GNU/Linux | genocidal book ever written. [EMAIL PROTECTED] | -- Noam Chomsky http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Processed: Re: Bug#257190: Kicker hangs up after zooming OpenGL program, other programs run perfectly?
Processing commands for [EMAIL PROTECTED]: reassign 257190 xlibmesa-dri Bug#257190: xlibmesa-gl: kicker hangs after zooming OpenGL program Bug reassigned from package `xlibmesa-gl' to `xlibmesa-dri'. retitle 257190 xlibmesa-dri: [radeon_dri] kicker hangs after zooming OpenGL program Bug#257190: xlibmesa-gl: kicker hangs after zooming OpenGL program Changed Bug title. On Sat, Jul 10, 2004 at 10:55:47PM +0200, MichaÅ J. Gajda wrote: Unknown command or malformed arguments to command. W liÅcie z sob, 10-07-2004, godz. 18:55, Branden Robinson pisze: Unknown command or malformed arguments to command. Mr. Gajda, Unknown command or malformed arguments to command. Unknown command or malformed arguments to command. It's been a week since Mr. Dänzer requested more information from you; Unknown command or malformed arguments to command. Too many unknown commands, stopping here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#257302: Processed: reassign 257302 to xserver-xfree86
On Sun, Jul 11, 2004 at 02:30:30AM +0800, Uwe Heinz Rudi Dippel wrote: Now the question goes like this: shall we close this and consider the trouble based on a bad machine ? On the other hand, I'd like to help Debian to get better. Therefore: shall I still send you the info as requested further down ? [...] $ /usr/share/bug/xserver-xfree86 /tmp/output 31 $ mailx -s Re: Bug#257302 [EMAIL PROTECTED] /tmp/output Yes, please. I'd like to have a look at it before I give up all hope. -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#258130: Make X applications depends on x-window-system-core
On Sun, Jul 11, 2004 at 12:33:44AM +0200, Michelle Konzack wrote: tasksel installs the same quantity like RedHat and SuSe or Mandrake After the baseinstallation and reboot, a newbie can type apt-get install mozilla and he/she will get a working system wit a x-window-system Curently it does not work (POTATO, WOODY and SARGE) and newbies do not know, that there is a Meta-Package x-window-system(-core) same for a windowmanager. In my view part of the Debian philosophy is to accomodate newbies where possible, but to refuse sacrificing the experts to them. I suggest you start using tasksel, then. It installt too much I simply do not agree with your proposed remedy for this problem. I suggest you begin a discussion thread on the debian-devel mailing list with a description of the problem, and solicit solutions to it. I suspect most of my fellow developers will agree with me that making all X clients depend on the entire X Window System sample implementation is not a good idea. -- G. Branden Robinson| Software engineering: that part of Debian GNU/Linux | computer science which is too [EMAIL PROTECTED] | difficult for the computer http://people.debian.org/~branden/ | scientist. signature.asc Description: Digital signature
Bug#256442: iBook G4 British keymap
On Sat, Jul 10, 2004 at 07:06:13PM +0100, Sam Halliday wrote: Branden Robinson wrote: Well, does the keyboard look exactly like this[1]?: http://bugs.debian.org/cgi-bin/bugreport.cgi/Apple%20Pro%20Keyboard%20(GB)%20M7803.JPG?bug=201737msg=34att=1 i think your URI got broken in transit... thats a duff link Not for me. Did you remember to quote it to prevent the shell from trying to interpret some of the characters within it? (In any event, you can find it within the logs of Debian Bug #201737.) -- G. Branden Robinson| The key to being a Southern Debian GNU/Linux | Baptist: It ain't a sin if you [EMAIL PROTECTED] | don't get caught. http://people.debian.org/~branden/ | -- Anthony Davidson signature.asc Description: Digital signature
Bug#257190: Kicker hangs up after zooming OpenGL program, other programs run perfectly?
reassign 257190 xlibmesa-dri retitle 257190 xlibmesa-dri: [radeon_dri] kicker hangs after zooming OpenGL program On Sat, Jul 10, 2004 at 10:55:47PM +0200, Michał J. Gajda wrote: W liście z sob, 10-07-2004, godz. 18:55, Branden Robinson pisze: Mr. Gajda, It's been a week since Mr. Dänzer requested more information from you; could you supply it, please? Here it is: --- Hmmm, with just LIBGL_SOFTWARE_RENDERING=yes kicker does not crash, Xserver eats 100% processor time indefinitely (even when 3D image does not move). With all env vars =no, computer crashes for ATI Radeon 16MB. I'll check tomorrow for other system. [...] And kicker hangs, but other apps continue to run? Yes, perfectly :-). (I tried konsole, Mozilla Firefox. Thanks for following up. The above tells us it's almost certainly a problem either in xlibmesa-dri, or in the DRM kernel modules. Please run the following commands from a shell prompt to gather and deliver some more information to us: $ /usr/share/bug/xlibmesa-dri /tmp/output 31 $ mailx -s Re: Bug#257190 [EMAIL PROTECTED] /tmp/output If you do not have a mailx command on your system, you can get by installing the mailx Debian package; for example, with the aptitude install mailx or apt-get install mailx commands as root. Alternatively, you can also use a mail command that is compatible with mailx's command-line syntax, such as mutt. Thanks again! -- G. Branden Robinson| Debian GNU/Linux | If existence exists, [EMAIL PROTECTED] | why create a creator? http://people.debian.org/~branden/ | signature.asc Description: Digital signature
