Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 01:31:24PM +1100, Daniel Stone wrote: > Branden already answered you, and so did I. The significance lies in > the major version. It's obviously meaningful to Mesa, if they > continue to bump *major* versions, it must mean they're doing > something pretty ... well, major, right? Internal rewrites with no visible changes to the developer and (hopefully) visible changes to the end-user. -- Marcelo
Re: xlibmesa naming and relationships
Branden Robinson <[EMAIL PROTECTED]> wrote:
>
> I do not personally feel that the major version number used by a
> software project is a meaningless detail. At least not in the case of
> Mesa, where they bump the major version number to reflect major new
> developments, like texture and lighting acceleration support.
I appreciate your respect for the upstream authors, but I don't think
the package name is an appropriate forum to express that.
Shared library packages carry part of the soname in their names so that
multiple versions can be installed simultaneously. This does not seem
to be the case here as 3 is not related to the soname. In the event that
the mesa version number is bumped without the ABI changing, you risk
either being inconsistent or changing the package name gratuitously.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
Package: xserver-xfree86 Version: 4.2.1-5 Severity: important X server crashes with SEGV, sometimes interactively but more often when left running xlock. -- Package-specific info: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] 01:05.0 Class 0300: 1002:5157 ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the "### BEGIN DEBCONF SECTION" line above, and/or after the # "### END DEBCONF SECTION" line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see "How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz. Section "Files" FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/Speedo" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"speedo" Load"type1" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "gb" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/psaux" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" Identifier "Generic Mouse" Driver "mouse" Option "SendCoreEvents""true" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" Option "ZAxisMapping" "4 5" EndSection Section "Device" Identifier "Generic Video Card" Driver "radeon" EndSection Section "Monitor" Identifier "Generic Monitor" HorizSync 30-94 VertRefresh 50-75 Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "Generic Video Card" Monitor "Generic Monitor" DefaultDepth24 SubSection "Display" Depth 1 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 4 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 8 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 15 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 24 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Generic Keyboard" InputDevice "Configured Mouse" InputDevice "Generic Mouse" EndSection Section "DRI" Mode0666 EndSection ### END DEBCONF SECTIO
Re: /usr/lib/libGLU.so.1
On Fre, 2003-02-07 at 06:04, chris horn. wrote: > > 1. I don't know whether this is the proper forum, so please inform me > if I'm in the wrong place. > 2. I believe I have a bug, but don't know where to report it (tips on > how to find which package a file is a part of would be greatly helpful). dpkg -S -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re: xlibmesa naming and relationships
On Fre, 2003-02-07 at 03:31, Daniel Stone wrote: > On Thu, Feb 06, 2003 at 03:02:34PM +0100, Michel D?nzer scrawled: > > > > Anyway, we're discussing the xlibmesa packages here, and you're still > > dodging the question how it's meaningful for those. > > Branden already answered you, and so did I. The significance lies in > the major version. It's obviously meaningful to Mesa, if they continue > to bump *major* versions, it must mean they're doing something pretty > ... well, major, right? Sure, major for _Mesa_. Not for users of the xlibmesa package. I'm not going to rehash the explanations Marcelo has given in this thread. > > > > Well, I am trying to get work done, with packages that have a > > > > relationship to those in question, and I think it's unnecessarily > > > > hard, for no good reason. > > > > > > What's hard about it? > > > > It breaks every time the name changes. > > So depend on the virtual libgl1/libglu1. I have explained why that doesn't fit my needs. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Processed: Re: Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
Processing commands for [EMAIL PROTECTED]: > tag 180107 + moreinfo Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock There were no tags set. Tags added: moreinfo > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: xlibmesa naming and relationships
On Thu, Feb 06, 2003 at 06:51:52PM +0100, Michel D?nzer wrote: > > How is a major version number relevant for anything? For example, how > > is it relevant for XFree86? > > It isn't, hence no other packages built from the xfree86 source package > bear a version number in their name. What's your point? The major version number used by Mesa is not the same as the one used by XFree86, except by coincidence. -- G. Branden Robinson| That's the saving grace of humor: Debian GNU/Linux | if you fail, no one is laughing at [EMAIL PROTECTED] | you. http://people.debian.org/~branden/ | -- A. Whitney Brown pgpyl1VWlj10n.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 08:29:36AM +0100, Marcelo E. Magallon wrote: > On Fri, Feb 07, 2003 at 01:31:24PM +1100, Daniel Stone wrote: > > > Branden already answered you, and so did I. The significance lies in > > the major version. It's obviously meaningful to Mesa, if they > > continue to bump *major* versions, it must mean they're doing > > something pretty ... well, major, right? > > Internal rewrites with no visible changes to the developer and > (hopefully) visible changes to the end-user. If they don't want people to interpret that as "major", they shouldn't bump the major version number when they do it. :) -- G. Branden Robinson| Debian GNU/Linux | If existence exists, [EMAIL PROTECTED] | why create a creator? http://people.debian.org/~branden/ | pgp23W3UGDxjl.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 01:44:16PM +0100, Michel D?nzer wrote: > > So depend on the virtual libgl1/libglu1. > > I have explained why that doesn't fit my needs. I must have missed it. Message-ID? -- G. Branden Robinson|It was a typical net.exercise -- a Debian GNU/Linux |screaming mob pounding on a greasy [EMAIL PROTECTED] |spot on the pavement, where used to http://people.debian.org/~branden/ |lie the carcass of a dead horse. pgpwhGLef54aU.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 07:50:11PM +1100, Herbert Xu wrote: > Shared library packages carry part of the soname in their names so that > multiple versions can be installed simultaneously. This does not seem > to be the case here as 3 is not related to the soname. In the event that > the mesa version number is bumped without the ABI changing, you risk > either being inconsistent or changing the package name gratuitously. Hmm, that's the most persuasive argument I've heard yet. (Michel will probably said that he's made it already; maybe you were just more efficient in expressing it.) :) -- G. Branden Robinson| I suspect Linus wrote that in a Debian GNU/Linux | complicated way only to be able to [EMAIL PROTECTED] | have that comment in there. http://people.debian.org/~branden/ | -- Lars Wirzenius pgprX2pzEG2II.pgp Description: PGP signature
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
tag 180107 + moreinfo thanks On Fri, Feb 07, 2003 at 09:03:46AM +, Markus Laker wrote: > Package: xserver-xfree86 > Version: 4.2.1-5 > Severity: important > > X server crashes with SEGV, sometimes interactively but more often when left > running xlock. This usually happens because one of the modes of xlock (or xscreensaver) manages to tickle a bug in the video driver. Are you using xlock with a particular mode, or just -mode random? -- G. Branden Robinson|America is at that awkward stage. Debian GNU/Linux |It's too late to work within the [EMAIL PROTECTED] |system, but too early to shoot the http://people.debian.org/~branden/ |bastards. -- Claire Wolfe pgpHRX69RpWjO.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fre, 2003-02-07 at 16:55, Branden Robinson wrote: > On Fri, Feb 07, 2003 at 07:50:11PM +1100, Herbert Xu wrote: > > Shared library packages carry part of the soname in their names so that > > multiple versions can be installed simultaneously. This does not seem > > to be the case here as 3 is not related to the soname. In the event that > > the mesa version number is bumped without the ABI changing, you risk > > either being inconsistent or changing the package name gratuitously. > > Hmm, that's the most persuasive argument I've heard yet. > > (Michel will probably said that he's made it already; maybe you were > just more efficient in expressing it.) :) Indeed, this is a good summary of some of the most important points I've been trying to make. :/ Thanks, Herbert. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re: xlibmesa naming and relationships
On Fre, 2003-02-07 at 16:53, Branden Robinson wrote: > On Thu, Feb 06, 2003 at 06:51:52PM +0100, Michel D?nzer wrote: > > > How is a major version number relevant for anything? For example, how > > > is it relevant for XFree86? > > > > It isn't, hence no other packages built from the xfree86 source package > > bear a version number in their name. What's your point? > > The major version number used by Mesa is not the same as the one used by > XFree86, except by coincidence. So the Mesa version needs to be engraved in the package name, no matter how irrelevant it is? Why don't you add the versions of gcc, glibc, ... then? ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re: xlibmesa naming and relationships
On Fre, 2003-02-07 at 16:54, Branden Robinson wrote: > On Fri, Feb 07, 2003 at 01:44:16PM +0100, Michel D?nzer wrote: > > > So depend on the virtual libgl1/libglu1. > > > > I have explained why that doesn't fit my needs. > > I must have missed it. Message-ID? <[EMAIL PROTECTED]>, for example. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
Hi, Branden, Thanks for the quick response. > Are you using xlock with a particular mode, or just -mode random? I'm using -mode random. If you'd like me to try limiting it to any particular mode, or avoiding it completely, please let me know. Best regards, Markus * This e-mail and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient(s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to [EMAIL PROTECTED] *
Bug#180156: xutils: xon calls program hostname in wrong way
Package: xutils Version: 4.2.1-5 Severity: normal Hello, The "xon" calls "hostname --version". The mistake is that xon does not anticipate that "hostname --version" prints its information to stderr (instead of stdout). May I also suggest a bit more error handling? e.g. when someone uses "xon -debug hostname cmd" Regards, Erwin -- System Information Debian Release: testing/unstable Kernel Version: Linux haddock 2.4.20-686 #1 Mon Jan 13 22:22:30 EST 2003 i686 unknown unknown GNU/Linux Versions of the packages xutils depends on: ii libc6 2.3.1-10 GNU C Library: Shared libraries and Timezone ii libncurses55.3.20021109-2 Shared libraries for terminal handling ii xfree86-common 4.2.1-5X Window System (XFree86) infrastructure ii zlib1g 1.1.4-9compression library - runtime
Bug#180157: xserver-xfree86: Apparent bug in glx/DRI driver with glPushAttrib/glPopAttrib
Package: xserver-xfree86
Version: 4.2.1-5
Severity: normal
Hi,
I'm working on implementing and testing Scheme OpenGL bindings. Today
I encountered a puzzling bug in some new code; after some confusion, I
traced it back to what appears to be a bug in the XFree86 implementation
of GL.
The background is that I had just implemented support for
glPushAttrib/glPopAttrib, and was testing and using this support in
various contexts. In one piece of code, I wanted to push the current
texture state before drawing a billboarded sprite:
(with-attribs-pushed ('texture-bit)
(gl-enable 'texture-2d)
(gl-bind-texture 'texture-2d texture)
(gl-tex-env 'texture-env 'texture-env-mode env-mode)
(gl-command 'quads
(gl-tex-coord 0 0)
(gl-vertex left-x top-y)
(gl-tex-coord 0 texture-max-y)
(gl-vertex left-x bottom-y)
(gl-tex-coord texture-max-x texture-max-y)
(gl-vertex right-x bottom-y)
(gl-tex-coord texture-max-x 0)
(gl-vertex right-x top-y)))
This is equivalent to the following C code:
glPushAttrib(GL_TEXTURE_BIT);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, texture);
glTexEnv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, env_mode);
glBegin(GL_QUADS);
/* obvious glTexCoord/glVertex calls */
glEnd();
glPopAttrib();
When I replaced the previous situation (manually unbinding the texture
on exit from the code block) with this, the graphical display of my
program suddenly became extremely strange. After experimenting a bit, I
concluded that it was behaving as if the call to
glPushAttrib/glPopAttrib was not present: the texture binding was
persisting outside the code block.
Changing the push command to push *all* attribute bits produced the
expected result -- the texture state was restored. This seemed even
stranger, so I decided to check whether I had somehow screwed up in the
binding and was pushing the wrong bit. Exhaustive checking of all
possible arguments to glPushAttrib() revealed that if I pushed
GL_LIGHTING_BIT, I saw the correct behavior. However, I checked in the
C half of my code, and glPushAttrib() was being called with the correct
constants in each case. GL_LIGHTING_BIT is 0x40, while GL_TEXTURE_BIT
is 0x4; I don't see an obvious byte-swap or anything there (maybe
more analysis would reveal a pattern)
Finally, I tried disabling DRI acceleration -- and the program worked
as expected! Specifically: the texture settings were restored by the
glPopAttrib() call, and if I removed the push and pop entirely, I saw
the same behavior I was seeing with DRI acceleration.
My conclusion is that glPushAttrib and glPopAttrib in the MGA DRI
driver are somehow pushing the wrong attributes for *at least*
GL_TEXTURE_BIT and GL_LIGHTING_BIT; however, I would expect that
probably more of the bits have problems.
(and..sorry, but I don't have any other hardware to test on just now.
I might be able to check with i810 at some point)
Further note: I downloaded the source and poked around a bit. The
glPushAttrib code seems to be driver-independent, so I guess this
probably affects more than just MGA (subject changed accordingly). I
don't completely understand why this doesn't happen when hardware
acceleration is disabled, actually.
Daniel
-- Package-specific info:
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)
01:00.0 Class 0300: 102b:0525 (rev 04)
### BEGIN DEBCONF SECTION
# XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type "man XF86Config-4" at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make changes
# before the "### BEGIN DEBCONF SECTION" line above, and/or after the
# "### END DEBCONF SECTION" line below.
#
# To change things within the debconf section, run the command:
# dpkg-reconfigure xserver-xfree86
# as root. Also see "How do I add custom sections to a dexconf-generated
# XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz.
Section "Files"
FontPath"unix/:7100"# local font server
# if the local font server has problems, we can fall back on these
FontPath"/usr/lib/X11/fonts/misc"
FontPath"/usr/lib/X11/fonts/cyrillic"
FontPath"/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath"/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath"/usr/lib/X11/fonts/Type1"
FontPath"/usr/lib/X11/fonts/Speedo"
FontPath"/usr/lib/X11/fonts/100dpi"
FontPath"/usr/lib/X11/fonts/75dpi"
EndSection
Section "Module"
Load"GLcore"
Load"bitm
Bug#180187: xserver-xfree86: Server crashes on Radeon during xscreensaver
Package: xserver-xfree86 Version: 4.2.1-5 Severity: normal Tags: sid The X server crashes when I am away from the computer. The problem is likely something in xscreensaver, but I have never personally seen it happen. The symptom is I leave my desk after work, and when I come back later, gdm has restarted the server. The (useless) log message is: /var/log/syslog.0:Feb 6 14:15:02 noodles gdm[18846]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 /var/log/syslog.0:Feb 7 05:27:24 noodles gdm[13806]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Please advise how to collect better crash information. -jwb -- Package-specific info: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon R100 QD [Radeon 64 DDR] 01:05.0 Class 0300: 1002:5144 ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the "### BEGIN DEBCONF SECTION" line above, and/or after the # "### END DEBCONF SECTION" line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. # Also see "How do I add custom sections to a dexconf-generated XF86Config or # XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz. Section "Files" # FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" # FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/Speedo" # FontPath"/usr/lib/X11/fonts/100dpi" # FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"speedo" Load"type1" Load"vbe" Load"xie" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/ttyS0" Option "Protocol" "Microsoft" Option "Emulate3Buttons" "true" EndSection Section "InputDevice" Identifier "Generic Mouse" Driver "mouse" Option "SendCoreEvents""true" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" EndSection Section "Device" Identifier "ATI Radeon All-in-Wonder" Driver "ati" EndSection Section "Monitor" Identifier "Samsung SyncMaster 210T" HorizSync 30-81 VertRefresh 60 DisplaySize 432 324 Option "DPMS" # ModeLine"1600x1200" 129.4 1600 1630 1680 1760 1200 1201 1204 1225 +hsync +vsync EndSection Section "Screen" Identifier "Default Screen" Device "ATI Radeon All-in-Wonder" Monitor "Samsung SyncMaster 210T" DefaultDepth24 Option "XaaNoOffscreenPixmaps" SubSection "Display" Depth 1 Modes "1600x1200" EndSubSection SubSection "Display" Depth 4 Modes "1600x1200" EndSubSection SubSection "Display" Depth 8 Modes "1600x1200" EndSubSection SubSection "Display" Depth 15 Modes "1600x1200" EndSubSection SubSection "Display" Depth 16 Modes "1600x1200" EndSubSection SubSection "Display" Depth 24 Modes "1600x1200" "1280x960" EndSubSection EndSection Section "ServerLayout"
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 05:29:15PM +0100, Michel D?nzer scrawled: > On Fre, 2003-02-07 at 16:53, Branden Robinson wrote: > > On Thu, Feb 06, 2003 at 06:51:52PM +0100, Michel D?nzer wrote: > > > > How is a major version number relevant for anything? For example, how > > > > is it relevant for XFree86? > > > > > > It isn't, hence no other packages built from the xfree86 source package > > > bear a version number in their name. What's your point? > > > > The major version number used by Mesa is not the same as the one used by > > XFree86, except by coincidence. > > So the Mesa version needs to be engraved in the package name, no matter > how irrelevant it is? Why don't you add the versions of gcc, glibc, ... > then? ;) Yeah, so we'll change the package names to gcc2.72, gcc2.95, gcc3.0 and gcc3.2! Hey, wait a minute ... -- Daniel Stone <[EMAIL PROTECTED]> Developer, Trinity College, University of Melbourne pgp8V88xVqlds.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Sam, 2003-02-08 at 00:57, Daniel Stone wrote: > On Fri, Feb 07, 2003 at 05:29:15PM +0100, Michel D?nzer scrawled: > > On Fre, 2003-02-07 at 16:53, Branden Robinson wrote: > > > On Thu, Feb 06, 2003 at 06:51:52PM +0100, Michel D?nzer wrote: > > > > > How is a major version number relevant for anything? For example, how > > > > > is it relevant for XFree86? > > > > > > > > It isn't, hence no other packages built from the xfree86 source package > > > > bear a version number in their name. What's your point? > > > > > > The major version number used by Mesa is not the same as the one used by > > > XFree86, except by coincidence. > > > > So the Mesa version needs to be engraved in the package name, no matter > > how irrelevant it is? Why don't you add the versions of gcc, glibc, ... > > then? ;) > > Yeah, so we'll change the package names to gcc2.72, gcc2.95, gcc3.0 and > gcc3.2! > > Hey, wait a minute ... Duh, gcc obviously needs _its own_ version in the package name. I was talking about xserver3.2-xfree86 (built with gcc 3.2), xlibs2.3.1 (built against glibc 2.3.1), ... because those version numbers are about as relevant to those packages as the Mesa version number is to xlibmesa. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
On Fri, Feb 07, 2003 at 10:40:11AM -0500, Branden Robinson scrawled: > On Fri, Feb 07, 2003 at 09:03:46AM +, Markus Laker wrote: > > Package: xserver-xfree86 > > Version: 4.2.1-5 > > Severity: important > > > > X server crashes with SEGV, sometimes interactively but more often when left > > running xlock. > > This usually happens because one of the modes of xlock (or xscreensaver) > manages to tickle a bug in the video driver. > > Are you using xlock with a particular mode, or just -mode random? Wonder if it's a GL screensaver. -- Daniel Stone <[EMAIL PROTECTED]> Developer, Trinity College, University of Melbourne pgpl9Xmkp4HQS.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Sat, Feb 08, 2003 at 01:04:18AM +0100, Michel D?nzer scrawled: > Duh, gcc obviously needs _its own_ version in the package name. I was > talking about xserver3.2-xfree86 (built with gcc 3.2), xlibs2.3.1 (built > against glibc 2.3.1), ... because those version numbers are about as > relevant to those packages as the Mesa version number is to xlibmesa. I agree entirely with Branden: if the changes are irrelevant, why does upstream keep bumping the *major* revision number? -- Daniel Stone <[EMAIL PROTECTED]> Developer, Trinity College, University of Melbourne pgpMKnZTCMj7P.pgp Description: PGP signature
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
On Sat, Feb 08, 2003 at 10:58:46AM +1100, Daniel Stone wrote: > On Fri, Feb 07, 2003 at 10:40:11AM -0500, Branden Robinson scrawled: > > On Fri, Feb 07, 2003 at 09:03:46AM +, Markus Laker wrote: > > > Package: xserver-xfree86 > > > Version: 4.2.1-5 > > > Severity: important > > > > > > X server crashes with SEGV, sometimes interactively but more often when > > > left > > > running xlock. > > > > This usually happens because one of the modes of xlock (or xscreensaver) > > manages to tickle a bug in the video driver. > > > > Are you using xlock with a particular mode, or just -mode random? > > Wonder if it's a GL screensaver. Seems I have something similar, or maybe not. Version 4.1.0-16, it's a notebook with ATI Technologies Inc Radeon Mobility M6 LY, but I am using the vesa driver, since I could not get ati nor radeon to work, and it crashed after I used xlock with atlantis, my favourite screensaver. But then mplayer makes X crash too... Or maybe its my kernel, I still have sound problems, maybe acpi and whatnot, got the notebook only yesterday. Christian
Bug#126519: Lonely but Married people are waiting to meet someone 1799YRQh9--9
come and see marriedbutalwayslonely! How have you been? You would not believe what I found but it is true. There is a site for people to talk, chat, see each others pictures, and even meet each other as close as next door that I found.But that's not the best part, here is why it's so unbelievable, not all the people are single, in fact, a lot of them are even married, looking to satisfy their hungriest desires. come and see marriedbutalwayslonely! You would not believe what is going on and what people are saying about this site, check this out! www.marriedbutalwayslonely.com p p p p p p p p p p p p p p p come and see marriedbutalwayslonely!for no more offers write [EMAIL PROTECTED] 9523CNnU6-981fBDa6323yoDY8-051HXCI4228dHfD5-272Tcsl47
Bug#126519: Married and Lonely people are hoping for someone to save them 4006omjs9-064I-13
"Married and Lonely people are hoping for someone to save them" How have you been? You would not believe what I found but it is true. There is a site for people to talk, chat, see each others pictures, and even meet each other as close as next door that I found.But that's not the best part, here is why it's so unbelievable, not all the people are single, in fact, a lot of them are even married, looking to satisfy their hungriest desires. "Married and Lonely people are hoping for someone to save them" You would not believe what is going on and what people are saying about this site, check this out! www.marriedbutalwayslonely.com p p p p p p p p p p p p p p p "Married and Lonely people are hoping for someone to save them"for no more offers write [EMAIL PROTECTED] 8319APQm9-506BpXw6016Ynxe7-440xNAc3447ixIN9-530TJbC9399WenY8-344oDdf555l67
Bug#180195: Wrong link in XFree86(1)
Package: xserver-xfree86 Version: 4.2.1 Severity: minor XFree86(1) mentions in the "SEE ALSO" section "XF86Config(5x)" which doesn't exist. It's XF86Config-4(5x). -- bli
Bug#180187: 180187 and 180107 both same crash on Radeon
severity 180187 important merge 180187 180107 thanks Severity of the former changed in order to merge with the latter. Cheers, jwb
Processed: tagging 180157
Processing commands for [EMAIL PROTECTED]: > tag 180157 + upstream Bug#180157: xserver-xfree86: Apparent bug in glx/DRI driver with glPushAttrib/glPopAttrib There were no tags set. Tags added: upstream > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: tagging 180195
Processing commands for [EMAIL PROTECTED]: > tag 180195 + pending Bug#180195: Wrong link in XFree86(1) There were no tags set. Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 05:29:15PM +0100, Michel D?nzer wrote: > On Fre, 2003-02-07 at 16:53, Branden Robinson wrote: > > The major version number used by Mesa is not the same as the one used by > > XFree86, except by coincidence. > > So the Mesa version needs to be engraved in the package name, no matter > how irrelevant it is? What's irrelevant about it? XFree86 has its versioning system and Mesa has its. The XFree86 encapsulates Mesa doesn't mean one should be left in ignorance as to what version of Mesa was so encapsulated. XFree86 doesn't encapsulate the toolchain. -- 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 pgpZ185I7OpiO.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 05:32:32PM +0100, Michel D?nzer wrote: > On Fre, 2003-02-07 at 16:54, Branden Robinson wrote: > > On Fri, Feb 07, 2003 at 01:44:16PM +0100, Michel D?nzer wrote: > > > > So depend on the virtual libgl1/libglu1. > > > > > > I have explained why that doesn't fit my needs. > > > > I must have missed it. Message-ID? > > <[EMAIL PROTECTED]>, for example. Wherever that message is, it wasn't posted to this list. -- G. Branden Robinson| There's nothing an agnostic can't Debian GNU/Linux | do if he doesn't know whether he [EMAIL PROTECTED] | believes in it or not. http://people.debian.org/~branden/ | -- Graham Chapman pgpOThrYMIAlr.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Sat, Feb 08, 2003 at 11:17:06AM +1100, Daniel Stone wrote: > On Sat, Feb 08, 2003 at 01:04:18AM +0100, Michel D?nzer scrawled: > > Duh, gcc obviously needs _its own_ version in the package name. I was > > talking about xserver3.2-xfree86 (built with gcc 3.2), xlibs2.3.1 (built > > against glibc 2.3.1), ... because those version numbers are about as > > relevant to those packages as the Mesa version number is to xlibmesa. > > I agree entirely with Branden: if the changes are irrelevant, why does > upstream keep bumping the *major* revision number? Er, I did not assert that Mesa had no business bumping their major version number. -- G. Branden Robinson|If you make people think they're Debian GNU/Linux |thinking, they'll love you; but if [EMAIL PROTECTED] |you really make them think, they'll http://people.debian.org/~branden/ |hate you. pgpwJMy2IJHsU.pgp Description: PGP signature
Processed: tagging 180156
Processing commands for [EMAIL PROTECTED]: > tag 180156 + upstream Bug#180156: xutils: xon calls program hostname in wrong way There were no tags set. Tags added: upstream > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: xlibmesa naming and relationships
Branden Robinson <[EMAIL PROTECTED]> wrote:
>
> I do not personally feel that the major version number used by a
> software project is a meaningless detail. At least not in the case of
> Mesa, where they bump the major version number to reflect major new
> developments, like texture and lighting acceleration support.
I appreciate your respect for the upstream authors, but I don't think
the package name is an appropriate forum to express that.
Shared library packages carry part of the soname in their names so that
multiple versions can be installed simultaneously. This does not seem
to be the case here as 3 is not related to the soname. In the event that
the mesa version number is bumped without the ABI changing, you risk
either being inconsistent or changing the package name gratuitously.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
Package: xserver-xfree86 Version: 4.2.1-5 Severity: important X server crashes with SEGV, sometimes interactively but more often when left running xlock. -- Package-specific info: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] 01:05.0 Class 0300: 1002:5157 ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the "### BEGIN DEBCONF SECTION" line above, and/or after the # "### END DEBCONF SECTION" line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see "How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz. Section "Files" FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/Speedo" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"speedo" Load"type1" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "gb" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/psaux" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" Identifier "Generic Mouse" Driver "mouse" Option "SendCoreEvents""true" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" Option "ZAxisMapping" "4 5" EndSection Section "Device" Identifier "Generic Video Card" Driver "radeon" EndSection Section "Monitor" Identifier "Generic Monitor" HorizSync 30-94 VertRefresh 50-75 Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "Generic Video Card" Monitor "Generic Monitor" DefaultDepth24 SubSection "Display" Depth 1 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 4 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 8 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 15 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 24 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Generic Keyboard" InputDevice "Configured Mouse" InputDevice "Generic Mouse" EndSection Section "DRI" Mode0666 EndSection ### END DEBCONF SECTION
Re: /usr/lib/libGLU.so.1
On Fre, 2003-02-07 at 06:04, chris horn. wrote: > > 1. I don't know whether this is the proper forum, so please inform me > if I'm in the wrong place. > 2. I believe I have a bug, but don't know where to report it (tips on > how to find which package a file is a part of would be greatly helpful). dpkg -S -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xlibmesa naming and relationships
On Fre, 2003-02-07 at 03:31, Daniel Stone wrote: > On Thu, Feb 06, 2003 at 03:02:34PM +0100, Michel D?nzer scrawled: > > > > Anyway, we're discussing the xlibmesa packages here, and you're still > > dodging the question how it's meaningful for those. > > Branden already answered you, and so did I. The significance lies in > the major version. It's obviously meaningful to Mesa, if they continue > to bump *major* versions, it must mean they're doing something pretty > ... well, major, right? Sure, major for _Mesa_. Not for users of the xlibmesa package. I'm not going to rehash the explanations Marcelo has given in this thread. > > > > Well, I am trying to get work done, with packages that have a > > > > relationship to those in question, and I think it's unnecessarily > > > > hard, for no good reason. > > > > > > What's hard about it? > > > > It breaks every time the name changes. > > So depend on the virtual libgl1/libglu1. I have explained why that doesn't fit my needs. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
Processing commands for [EMAIL PROTECTED]: > tag 180107 + moreinfo Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock There were no tags set. Tags added: moreinfo > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xlibmesa naming and relationships
On Thu, Feb 06, 2003 at 06:51:52PM +0100, Michel D?nzer wrote: > > How is a major version number relevant for anything? For example, how > > is it relevant for XFree86? > > It isn't, hence no other packages built from the xfree86 source package > bear a version number in their name. What's your point? The major version number used by Mesa is not the same as the one used by XFree86, except by coincidence. -- G. Branden Robinson| That's the saving grace of humor: Debian GNU/Linux | if you fail, no one is laughing at [EMAIL PROTECTED] | you. http://people.debian.org/~branden/ | -- A. Whitney Brown msg05721/pgp0.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 08:29:36AM +0100, Marcelo E. Magallon wrote: > On Fri, Feb 07, 2003 at 01:31:24PM +1100, Daniel Stone wrote: > > > Branden already answered you, and so did I. The significance lies in > > the major version. It's obviously meaningful to Mesa, if they > > continue to bump *major* versions, it must mean they're doing > > something pretty ... well, major, right? > > Internal rewrites with no visible changes to the developer and > (hopefully) visible changes to the end-user. If they don't want people to interpret that as "major", they shouldn't bump the major version number when they do it. :) -- G. Branden Robinson| Debian GNU/Linux | If existence exists, [EMAIL PROTECTED] | why create a creator? http://people.debian.org/~branden/ | msg05722/pgp0.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 01:44:16PM +0100, Michel D?nzer wrote: > > So depend on the virtual libgl1/libglu1. > > I have explained why that doesn't fit my needs. I must have missed it. Message-ID? -- G. Branden Robinson|It was a typical net.exercise -- a Debian GNU/Linux |screaming mob pounding on a greasy [EMAIL PROTECTED] |spot on the pavement, where used to http://people.debian.org/~branden/ |lie the carcass of a dead horse. msg05723/pgp0.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 07:50:11PM +1100, Herbert Xu wrote: > Shared library packages carry part of the soname in their names so that > multiple versions can be installed simultaneously. This does not seem > to be the case here as 3 is not related to the soname. In the event that > the mesa version number is bumped without the ABI changing, you risk > either being inconsistent or changing the package name gratuitously. Hmm, that's the most persuasive argument I've heard yet. (Michel will probably said that he's made it already; maybe you were just more efficient in expressing it.) :) -- G. Branden Robinson| I suspect Linus wrote that in a Debian GNU/Linux | complicated way only to be able to [EMAIL PROTECTED] | have that comment in there. http://people.debian.org/~branden/ | -- Lars Wirzenius msg05724/pgp0.pgp Description: PGP signature
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
tag 180107 + moreinfo thanks On Fri, Feb 07, 2003 at 09:03:46AM +, Markus Laker wrote: > Package: xserver-xfree86 > Version: 4.2.1-5 > Severity: important > > X server crashes with SEGV, sometimes interactively but more often when left > running xlock. This usually happens because one of the modes of xlock (or xscreensaver) manages to tickle a bug in the video driver. Are you using xlock with a particular mode, or just -mode random? -- G. Branden Robinson|America is at that awkward stage. Debian GNU/Linux |It's too late to work within the [EMAIL PROTECTED] |system, but too early to shoot the http://people.debian.org/~branden/ |bastards. -- Claire Wolfe msg05725/pgp0.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fre, 2003-02-07 at 16:55, Branden Robinson wrote: > On Fri, Feb 07, 2003 at 07:50:11PM +1100, Herbert Xu wrote: > > Shared library packages carry part of the soname in their names so that > > multiple versions can be installed simultaneously. This does not seem > > to be the case here as 3 is not related to the soname. In the event that > > the mesa version number is bumped without the ABI changing, you risk > > either being inconsistent or changing the package name gratuitously. > > Hmm, that's the most persuasive argument I've heard yet. > > (Michel will probably said that he's made it already; maybe you were > just more efficient in expressing it.) :) Indeed, this is a good summary of some of the most important points I've been trying to make. :/ Thanks, Herbert. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xlibmesa naming and relationships
On Fre, 2003-02-07 at 16:53, Branden Robinson wrote: > On Thu, Feb 06, 2003 at 06:51:52PM +0100, Michel D?nzer wrote: > > > How is a major version number relevant for anything? For example, how > > > is it relevant for XFree86? > > > > It isn't, hence no other packages built from the xfree86 source package > > bear a version number in their name. What's your point? > > The major version number used by Mesa is not the same as the one used by > XFree86, except by coincidence. So the Mesa version needs to be engraved in the package name, no matter how irrelevant it is? Why don't you add the versions of gcc, glibc, ... then? ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xlibmesa naming and relationships
On Fre, 2003-02-07 at 16:54, Branden Robinson wrote: > On Fri, Feb 07, 2003 at 01:44:16PM +0100, Michel D?nzer wrote: > > > So depend on the virtual libgl1/libglu1. > > > > I have explained why that doesn't fit my needs. > > I must have missed it. Message-ID? <1044553668.1137.14.camel@thor>, for example. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
Hi, Branden, Thanks for the quick response. > Are you using xlock with a particular mode, or just -mode random? I'm using -mode random. If you'd like me to try limiting it to any particular mode, or avoiding it completely, please let me know. Best regards, Markus * This e-mail and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient(s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to [EMAIL PROTECTED] * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#180156: xutils: xon calls program hostname in wrong way
Package: xutils Version: 4.2.1-5 Severity: normal Hello, The "xon" calls "hostname --version". The mistake is that xon does not anticipate that "hostname --version" prints its information to stderr (instead of stdout). May I also suggest a bit more error handling? e.g. when someone uses "xon -debug hostname cmd" Regards, Erwin -- System Information Debian Release: testing/unstable Kernel Version: Linux haddock 2.4.20-686 #1 Mon Jan 13 22:22:30 EST 2003 i686 unknown unknown GNU/Linux Versions of the packages xutils depends on: ii libc6 2.3.1-10 GNU C Library: Shared libraries and Timezone ii libncurses55.3.20021109-2 Shared libraries for terminal handling ii xfree86-common 4.2.1-5X Window System (XFree86) infrastructure ii zlib1g 1.1.4-9compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#180157: xserver-xfree86: Apparent bug in glx/DRI driver with glPushAttrib/glPopAttrib
Package: xserver-xfree86
Version: 4.2.1-5
Severity: normal
Hi,
I'm working on implementing and testing Scheme OpenGL bindings. Today
I encountered a puzzling bug in some new code; after some confusion, I
traced it back to what appears to be a bug in the XFree86 implementation
of GL.
The background is that I had just implemented support for
glPushAttrib/glPopAttrib, and was testing and using this support in
various contexts. In one piece of code, I wanted to push the current
texture state before drawing a billboarded sprite:
(with-attribs-pushed ('texture-bit)
(gl-enable 'texture-2d)
(gl-bind-texture 'texture-2d texture)
(gl-tex-env 'texture-env 'texture-env-mode env-mode)
(gl-command 'quads
(gl-tex-coord 0 0)
(gl-vertex left-x top-y)
(gl-tex-coord 0 texture-max-y)
(gl-vertex left-x bottom-y)
(gl-tex-coord texture-max-x texture-max-y)
(gl-vertex right-x bottom-y)
(gl-tex-coord texture-max-x 0)
(gl-vertex right-x top-y)))
This is equivalent to the following C code:
glPushAttrib(GL_TEXTURE_BIT);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, texture);
glTexEnv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, env_mode);
glBegin(GL_QUADS);
/* obvious glTexCoord/glVertex calls */
glEnd();
glPopAttrib();
When I replaced the previous situation (manually unbinding the texture
on exit from the code block) with this, the graphical display of my
program suddenly became extremely strange. After experimenting a bit, I
concluded that it was behaving as if the call to
glPushAttrib/glPopAttrib was not present: the texture binding was
persisting outside the code block.
Changing the push command to push *all* attribute bits produced the
expected result -- the texture state was restored. This seemed even
stranger, so I decided to check whether I had somehow screwed up in the
binding and was pushing the wrong bit. Exhaustive checking of all
possible arguments to glPushAttrib() revealed that if I pushed
GL_LIGHTING_BIT, I saw the correct behavior. However, I checked in the
C half of my code, and glPushAttrib() was being called with the correct
constants in each case. GL_LIGHTING_BIT is 0x40, while GL_TEXTURE_BIT
is 0x4; I don't see an obvious byte-swap or anything there (maybe
more analysis would reveal a pattern)
Finally, I tried disabling DRI acceleration -- and the program worked
as expected! Specifically: the texture settings were restored by the
glPopAttrib() call, and if I removed the push and pop entirely, I saw
the same behavior I was seeing with DRI acceleration.
My conclusion is that glPushAttrib and glPopAttrib in the MGA DRI
driver are somehow pushing the wrong attributes for *at least*
GL_TEXTURE_BIT and GL_LIGHTING_BIT; however, I would expect that
probably more of the bits have problems.
(and..sorry, but I don't have any other hardware to test on just now.
I might be able to check with i810 at some point)
Further note: I downloaded the source and poked around a bit. The
glPushAttrib code seems to be driver-independent, so I guess this
probably affects more than just MGA (subject changed accordingly). I
don't completely understand why this doesn't happen when hardware
acceleration is disabled, actually.
Daniel
-- Package-specific info:
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)
01:00.0 Class 0300: 102b:0525 (rev 04)
### BEGIN DEBCONF SECTION
# XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type "man XF86Config-4" at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make changes
# before the "### BEGIN DEBCONF SECTION" line above, and/or after the
# "### END DEBCONF SECTION" line below.
#
# To change things within the debconf section, run the command:
# dpkg-reconfigure xserver-xfree86
# as root. Also see "How do I add custom sections to a dexconf-generated
# XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz.
Section "Files"
FontPath"unix/:7100"# local font server
# if the local font server has problems, we can fall back on these
FontPath"/usr/lib/X11/fonts/misc"
FontPath"/usr/lib/X11/fonts/cyrillic"
FontPath"/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath"/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath"/usr/lib/X11/fonts/Type1"
FontPath"/usr/lib/X11/fonts/Speedo"
FontPath"/usr/lib/X11/fonts/100dpi"
FontPath"/usr/lib/X11/fonts/75dpi"
EndSection
Section "Module"
Load"GLcore"
Load"bitm
Bug#180187: xserver-xfree86: Server crashes on Radeon during xscreensaver
Package: xserver-xfree86 Version: 4.2.1-5 Severity: normal Tags: sid The X server crashes when I am away from the computer. The problem is likely something in xscreensaver, but I have never personally seen it happen. The symptom is I leave my desk after work, and when I come back later, gdm has restarted the server. The (useless) log message is: /var/log/syslog.0:Feb 6 14:15:02 noodles gdm[18846]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 /var/log/syslog.0:Feb 7 05:27:24 noodles gdm[13806]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Please advise how to collect better crash information. -jwb -- Package-specific info: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon R100 QD [Radeon 64 DDR] 01:05.0 Class 0300: 1002:5144 ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the "### BEGIN DEBCONF SECTION" line above, and/or after the # "### END DEBCONF SECTION" line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. # Also see "How do I add custom sections to a dexconf-generated XF86Config or # XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz. Section "Files" # FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" # FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/Speedo" # FontPath"/usr/lib/X11/fonts/100dpi" # FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"speedo" Load"type1" Load"vbe" Load"xie" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/ttyS0" Option "Protocol" "Microsoft" Option "Emulate3Buttons" "true" EndSection Section "InputDevice" Identifier "Generic Mouse" Driver "mouse" Option "SendCoreEvents""true" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" EndSection Section "Device" Identifier "ATI Radeon All-in-Wonder" Driver "ati" EndSection Section "Monitor" Identifier "Samsung SyncMaster 210T" HorizSync 30-81 VertRefresh 60 DisplaySize 432 324 Option "DPMS" # ModeLine"1600x1200" 129.4 1600 1630 1680 1760 1200 1201 1204 1225 +hsync +vsync EndSection Section "Screen" Identifier "Default Screen" Device "ATI Radeon All-in-Wonder" Monitor "Samsung SyncMaster 210T" DefaultDepth24 Option "XaaNoOffscreenPixmaps" SubSection "Display" Depth 1 Modes "1600x1200" EndSubSection SubSection "Display" Depth 4 Modes "1600x1200" EndSubSection SubSection "Display" Depth 8 Modes "1600x1200" EndSubSection SubSection "Display" Depth 15 Modes "1600x1200" EndSubSection SubSection "Display" Depth 16 Modes "1600x1200" EndSubSection SubSection "Display" Depth 24 Modes "1600x1200" "1280x960" EndSubSection EndSection Section "ServerLayout"
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 05:29:15PM +0100, Michel D?nzer scrawled: > On Fre, 2003-02-07 at 16:53, Branden Robinson wrote: > > On Thu, Feb 06, 2003 at 06:51:52PM +0100, Michel D?nzer wrote: > > > > How is a major version number relevant for anything? For example, how > > > > is it relevant for XFree86? > > > > > > It isn't, hence no other packages built from the xfree86 source package > > > bear a version number in their name. What's your point? > > > > The major version number used by Mesa is not the same as the one used by > > XFree86, except by coincidence. > > So the Mesa version needs to be engraved in the package name, no matter > how irrelevant it is? Why don't you add the versions of gcc, glibc, ... > then? ;) Yeah, so we'll change the package names to gcc2.72, gcc2.95, gcc3.0 and gcc3.2! Hey, wait a minute ... -- Daniel Stone <[EMAIL PROTECTED]> Developer, Trinity College, University of Melbourne msg05733/pgp0.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Sam, 2003-02-08 at 00:57, Daniel Stone wrote: > On Fri, Feb 07, 2003 at 05:29:15PM +0100, Michel D?nzer scrawled: > > On Fre, 2003-02-07 at 16:53, Branden Robinson wrote: > > > On Thu, Feb 06, 2003 at 06:51:52PM +0100, Michel D?nzer wrote: > > > > > How is a major version number relevant for anything? For example, how > > > > > is it relevant for XFree86? > > > > > > > > It isn't, hence no other packages built from the xfree86 source package > > > > bear a version number in their name. What's your point? > > > > > > The major version number used by Mesa is not the same as the one used by > > > XFree86, except by coincidence. > > > > So the Mesa version needs to be engraved in the package name, no matter > > how irrelevant it is? Why don't you add the versions of gcc, glibc, ... > > then? ;) > > Yeah, so we'll change the package names to gcc2.72, gcc2.95, gcc3.0 and > gcc3.2! > > Hey, wait a minute ... Duh, gcc obviously needs _its own_ version in the package name. I was talking about xserver3.2-xfree86 (built with gcc 3.2), xlibs2.3.1 (built against glibc 2.3.1), ... because those version numbers are about as relevant to those packages as the Mesa version number is to xlibmesa. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
On Fri, Feb 07, 2003 at 10:40:11AM -0500, Branden Robinson scrawled: > On Fri, Feb 07, 2003 at 09:03:46AM +, Markus Laker wrote: > > Package: xserver-xfree86 > > Version: 4.2.1-5 > > Severity: important > > > > X server crashes with SEGV, sometimes interactively but more often when left > > running xlock. > > This usually happens because one of the modes of xlock (or xscreensaver) > manages to tickle a bug in the video driver. > > Are you using xlock with a particular mode, or just -mode random? Wonder if it's a GL screensaver. -- Daniel Stone <[EMAIL PROTECTED]> Developer, Trinity College, University of Melbourne msg05735/pgp0.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Sat, Feb 08, 2003 at 01:04:18AM +0100, Michel D?nzer scrawled: > Duh, gcc obviously needs _its own_ version in the package name. I was > talking about xserver3.2-xfree86 (built with gcc 3.2), xlibs2.3.1 (built > against glibc 2.3.1), ... because those version numbers are about as > relevant to those packages as the Mesa version number is to xlibmesa. I agree entirely with Branden: if the changes are irrelevant, why does upstream keep bumping the *major* revision number? -- Daniel Stone <[EMAIL PROTECTED]> Developer, Trinity College, University of Melbourne msg05736/pgp0.pgp Description: PGP signature
Bug#180107: xserver-xfree86: ATI Radeon 7500: SEGV at random times, esp in xlock
On Sat, Feb 08, 2003 at 10:58:46AM +1100, Daniel Stone wrote: > On Fri, Feb 07, 2003 at 10:40:11AM -0500, Branden Robinson scrawled: > > On Fri, Feb 07, 2003 at 09:03:46AM +, Markus Laker wrote: > > > Package: xserver-xfree86 > > > Version: 4.2.1-5 > > > Severity: important > > > > > > X server crashes with SEGV, sometimes interactively but more often when left > > > running xlock. > > > > This usually happens because one of the modes of xlock (or xscreensaver) > > manages to tickle a bug in the video driver. > > > > Are you using xlock with a particular mode, or just -mode random? > > Wonder if it's a GL screensaver. Seems I have something similar, or maybe not. Version 4.1.0-16, it's a notebook with ATI Technologies Inc Radeon Mobility M6 LY, but I am using the vesa driver, since I could not get ati nor radeon to work, and it crashed after I used xlock with atlantis, my favourite screensaver. But then mplayer makes X crash too... Or maybe its my kernel, I still have sound problems, maybe acpi and whatnot, got the notebook only yesterday. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#126519: Lonely but Married people are waiting to meet someone 1799YRQh9--9
come and see marriedbutalwayslonely! How have you been? You would not believe what I found but it is true. There is a site for people to talk, chat, see each others pictures, and even meet each other as close as next door that I found.But that's not the best part, here is why it's so unbelievable, not all the people are single, in fact, a lot of them are even married, looking to satisfy their hungriest desires. come and see marriedbutalwayslonely! You would not believe what is going on and what people are saying about this site, check this out! www.marriedbutalwayslonely.com p p p p p p p p p p p p p p p come and see marriedbutalwayslonely!for no more offers write [EMAIL PROTECTED] 9523CNnU6-981fBDa6323yoDY8-051HXCI4228dHfD5-272Tcsl47 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#126519: Married and Lonely people are hoping for someone to save them 4006omjs9-064I-13
"Married and Lonely people are hoping for someone to save them" How have you been? You would not believe what I found but it is true. There is a site for people to talk, chat, see each others pictures, and even meet each other as close as next door that I found.But that's not the best part, here is why it's so unbelievable, not all the people are single, in fact, a lot of them are even married, looking to satisfy their hungriest desires. "Married and Lonely people are hoping for someone to save them" You would not believe what is going on and what people are saying about this site, check this out! www.marriedbutalwayslonely.com p p p p p p p p p p p p p p p "Married and Lonely people are hoping for someone to save them"for no more offers write [EMAIL PROTECTED] 8319APQm9-506BpXw6016Ynxe7-440xNAc3447ixIN9-530TJbC9399WenY8-344oDdf555l67 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#180195: Wrong link in XFree86(1)
Package: xserver-xfree86 Version: 4.2.1 Severity: minor XFree86(1) mentions in the "SEE ALSO" section "XF86Config(5x)" which doesn't exist. It's XF86Config-4(5x). -- bli -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#180187: 180187 and 180107 both same crash on Radeon
severity 180187 important merge 180187 180107 thanks Severity of the former changed in order to merge with the latter. Cheers, jwb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 180157
Processing commands for [EMAIL PROTECTED]: > tag 180157 + upstream Bug#180157: xserver-xfree86: Apparent bug in glx/DRI driver with glPushAttrib/glPopAttrib There were no tags set. Tags added: upstream > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 180195
Processing commands for [EMAIL PROTECTED]: > tag 180195 + pending Bug#180195: Wrong link in XFree86(1) There were no tags set. Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 05:29:15PM +0100, Michel D?nzer wrote: > On Fre, 2003-02-07 at 16:53, Branden Robinson wrote: > > The major version number used by Mesa is not the same as the one used by > > XFree86, except by coincidence. > > So the Mesa version needs to be engraved in the package name, no matter > how irrelevant it is? What's irrelevant about it? XFree86 has its versioning system and Mesa has its. The XFree86 encapsulates Mesa doesn't mean one should be left in ignorance as to what version of Mesa was so encapsulated. XFree86 doesn't encapsulate the toolchain. -- 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 msg05744/pgp0.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 05:32:32PM +0100, Michel D?nzer wrote: > On Fre, 2003-02-07 at 16:54, Branden Robinson wrote: > > On Fri, Feb 07, 2003 at 01:44:16PM +0100, Michel D?nzer wrote: > > > > So depend on the virtual libgl1/libglu1. > > > > > > I have explained why that doesn't fit my needs. > > > > I must have missed it. Message-ID? > > <1044553668.1137.14.camel@thor>, for example. Wherever that message is, it wasn't posted to this list. -- G. Branden Robinson| There's nothing an agnostic can't Debian GNU/Linux | do if he doesn't know whether he [EMAIL PROTECTED] | believes in it or not. http://people.debian.org/~branden/ | -- Graham Chapman msg05745/pgp0.pgp Description: PGP signature
Re: xlibmesa naming and relationships
On Sat, Feb 08, 2003 at 11:17:06AM +1100, Daniel Stone wrote: > On Sat, Feb 08, 2003 at 01:04:18AM +0100, Michel D?nzer scrawled: > > Duh, gcc obviously needs _its own_ version in the package name. I was > > talking about xserver3.2-xfree86 (built with gcc 3.2), xlibs2.3.1 (built > > against glibc 2.3.1), ... because those version numbers are about as > > relevant to those packages as the Mesa version number is to xlibmesa. > > I agree entirely with Branden: if the changes are irrelevant, why does > upstream keep bumping the *major* revision number? Er, I did not assert that Mesa had no business bumping their major version number. -- G. Branden Robinson|If you make people think they're Debian GNU/Linux |thinking, they'll love you; but if [EMAIL PROTECTED] |you really make them think, they'll http://people.debian.org/~branden/ |hate you. msg05746/pgp0.pgp Description: PGP signature
Processed: tagging 180156
Processing commands for [EMAIL PROTECTED]: > tag 180156 + upstream Bug#180156: xutils: xon calls program hostname in wrong way There were no tags set. Tags added: upstream > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xlibmesa naming and relationships
On Fri, Feb 07, 2003 at 11:37:04PM -0500, Branden Robinson scrawled: > On Sat, Feb 08, 2003 at 11:17:06AM +1100, Daniel Stone wrote: > > On Sat, Feb 08, 2003 at 01:04:18AM +0100, Michel D?nzer scrawled: > > > Duh, gcc obviously needs _its own_ version in the package name. I was > > > talking about xserver3.2-xfree86 (built with gcc 3.2), xlibs2.3.1 (built > > > against glibc 2.3.1), ... because those version numbers are about as > > > relevant to those packages as the Mesa version number is to xlibmesa. > > > > I agree entirely with Branden: if the changes are irrelevant, why does > > upstream keep bumping the *major* revision number? > > Er, I did not assert that Mesa had no business bumping their major > version number. Man, you missed a rhetorical question. You must be really tired. I wasn't inferring that you thought that Mesa had no business bumping their major version number. Also, that colon should've been a semi-colon, inferring that I was agreeing with you, and suggesting that Mesa probably bumped their major revision number for a reason. Have another drink. :) d -- Daniel Stone <[EMAIL PROTECTED]> Developer, Trinity College, University of Melbourne msg05748/pgp0.pgp Description: PGP signature
