Bug#432435: Keith has fixes in upstream git
forwarded 432435 https://bugs.freedesktop.org/show_bug.cgi?id=11606 thanks I filed this upstream before noticing the Debian bugs about it. Apparently he has fixes in the upstream git. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Bug#360538: Logging into Gnome session exits immediately
* Brice Goglin ([EMAIL PROTECTED]) wrote: > Hi, > > About a year ago, you reported (or replied to) a bug in the Debian BTS > regarding logging into Gnome exiting immediately. Did any of you guys > reproduce this problem recently? With Xorg/Etch? With latest > xserver-xorg-core and drivers? If not, I will close this bug in the next > weeks. Haven't seen it in forever, feel free to close. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Bug#350458: Upgrading severity
severity 350458 serious thanks I'm raising the severity since it's causing Firefox (at least) to FTBFS. And as the submitter points out, it's not clear how this should be resolved. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Bug#344110: xserver locks up and uses almost all cpu (99%)
reopen 344110 merge 344110 347167 thanks I see this too with a Radeon 9500 using the radeon driver. Don't have a good way of reproducing it. May be related to load. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Bug#345509: workaround
I was able to workaround this problem by switching from Xinerama to MergedFB. See randeon(4x) for details. This actually seems to be superior to Xinerama. I had to disable DRI for stability though. Attached is my xorg.conf as a reference. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- # 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/CID" FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/CID" FontPath"/usr/lib/X11/fonts/Speedo" FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" # Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"speedo" Load"type1" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/psaux" Option "Protocol" "ImPS/2" Option "Buttons" "7" 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 "Radeon 9500 DVI" Driver "radeon" BusID "PCI:1:0:0" Option "MonitorLayout" "TMDS,CRT" Option "MergedFB" "true" Option "MetaModes" "1280x1024-1280x1024" Option "MergedXineramaCRT2IsScreen0" "false" Option "CRT2Position" "LeftOf" EndSection Section "Device" Identifier "Radeon 9500 VGA" Driver "radeon" BusID "PCI:1:0:0" Screen 1 EndSection Section "Monitor" Identifier "SyncMaster 950p" HorizSync 30-96 VertRefresh 50-160 #Option "DPMS" EndSection Section "Monitor"
Bug#345509: AOL
I'm seeing this too. The interesting part might be the line: (WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode disabled Not sure if that's the problem though. It may also have been reported upstream as https://bugs.freedesktop.org/show_bug.cgi?id=5178. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: libXau in xlibs-pic?
* Branden Robinson ([EMAIL PROTECTED]) wrote: > On Tue, Jun 17, 2003 at 10:20:44PM -0400, Eric Dorland wrote: > > I've packaged XCB <http://xcb.wiki.cs.pdx.edu/>, but I was in > > violation of policy because the shared libraries were not compiled > > with -fPIC. I fixed that but unfortunately the lib uses libXau which > > only comes in a static non-pic flavor. Is there any way to get a pic > > version of libXau in xlibs-pic for the next version? > > If by "next version" you mean the 4.3.0 packages, yes. > > If you have urgent needs and if there is a 4.2.1-9 release, it should be > feasible to get libXau into xlibs-pic. Please let us know if this is > the case (that is, that you have urgent needs). Well it makes my package unbuildable on a variety of architectures so there is a somewhat urgent need for it I suppose. So if there is a 4.2.1-9 and you could get that change in that would be great. Otherwise I'm perfectly content to wait for 4.3.0. > > Oh a related note, why aren't all the static libs compiled with pic > > versions? Is libXau not to be used, or replaced by something else? > > The answer to your second question can be found in the package > description of xlibs-pic. > > I've been adding static libraries to xlibs-pic on an as-needed basis. > But since upstream decided to enable PIC symbols on all static libraries > prior to the release of 4.3.0, that conservatism is no longer warranted. Ah, thanks for the answer. Go team X Strike Force! :) -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- pgpPllYisSaBW.pgp Description: PGP signature
Re: libXau in xlibs-pic?
* Branden Robinson ([EMAIL PROTECTED]) wrote: > On Tue, Jun 17, 2003 at 10:20:44PM -0400, Eric Dorland wrote: > > I've packaged XCB <http://xcb.wiki.cs.pdx.edu/>, but I was in > > violation of policy because the shared libraries were not compiled > > with -fPIC. I fixed that but unfortunately the lib uses libXau which > > only comes in a static non-pic flavor. Is there any way to get a pic > > version of libXau in xlibs-pic for the next version? > > If by "next version" you mean the 4.3.0 packages, yes. > > If you have urgent needs and if there is a 4.2.1-9 release, it should be > feasible to get libXau into xlibs-pic. Please let us know if this is > the case (that is, that you have urgent needs). Well it makes my package unbuildable on a variety of architectures so there is a somewhat urgent need for it I suppose. So if there is a 4.2.1-9 and you could get that change in that would be great. Otherwise I'm perfectly content to wait for 4.3.0. > > Oh a related note, why aren't all the static libs compiled with pic > > versions? Is libXau not to be used, or replaced by something else? > > The answer to your second question can be found in the package > description of xlibs-pic. > > I've been adding static libraries to xlibs-pic on an as-needed basis. > But since upstream decided to enable PIC symbols on all static libraries > prior to the release of 4.3.0, that conservatism is no longer warranted. Ah, thanks for the answer. Go team X Strike Force! :) -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- pgp0.pgp Description: PGP signature
libXau in xlibs-pic?
I've packaged XCB <http://xcb.wiki.cs.pdx.edu/>, but I was in violation of policy because the shared libraries were not compiled with -fPIC. I fixed that but unfortunately the lib uses libXau which only comes in a static non-pic flavor. Is there any way to get a pic version of libXau in xlibs-pic for the next version? Oh a related note, why aren't all the static libs compiled with pic versions? Is libXau not to be used, or replaced by something else? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- pgpFr18azOcmq.pgp Description: PGP signature
libXau in xlibs-pic?
I've packaged XCB <http://xcb.wiki.cs.pdx.edu/>, but I was in violation of policy because the shared libraries were not compiled with -fPIC. I fixed that but unfortunately the lib uses libXau which only comes in a static non-pic flavor. Is there any way to get a pic version of libXau in xlibs-pic for the next version? Oh a related note, why aren't all the static libs compiled with pic versions? Is libXau not to be used, or replaced by something else? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- pgp0.pgp Description: PGP signature
Bug#174589: libXrender API change, shlibs needs updating
Package: xlibs Version: 4.2.1-4 Severity: normal Tags: sid Between xfree 4.1 and 4.2 these symbols were added to libXrender (at least): XRenderCompositeText8 XRenderCompositeText16 XRenderCompositeText32 but the shlibs file still lists the dependency on 4.1.0. It should be: libXrender 1 xlibs (>> 4.2.0) libxft2 uses these calls, so although it claims to depend on xlibs (>> 4.1.0) it will fail to load if xlibs 4.1.x is installed. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux apocalypse 2.4.20 #1 Fri Dec 20 18:08:05 EST 2002 i686 Locale: LANG=en_US, LC_CTYPE=en_US Versions of packages xlibs depends on: ii libc6 2.3.1-8GNU C Library: Shared libraries an ii libfreetype6 2.1.3-4FreeType 2 font engine, shared lib ii xfree86-common4.2.1-4X Window System (XFree86) infrastr -- no debconf information
Bug#174589: libXrender API change, shlibs needs updating
Package: xlibs Version: 4.2.1-4 Severity: normal Tags: sid Between xfree 4.1 and 4.2 these symbols were added to libXrender (at least): XRenderCompositeText8 XRenderCompositeText16 XRenderCompositeText32 but the shlibs file still lists the dependency on 4.1.0. It should be: libXrender 1 xlibs (>> 4.2.0) libxft2 uses these calls, so although it claims to depend on xlibs (>> 4.1.0) it will fail to load if xlibs 4.1.x is installed. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux apocalypse 2.4.20 #1 Fri Dec 20 18:08:05 EST 2002 i686 Locale: LANG=en_US, LC_CTYPE=en_US Versions of packages xlibs depends on: ii libc6 2.3.1-8GNU C Library: Shared libraries an ii libfreetype6 2.1.3-4FreeType 2 font engine, shared lib ii xfree86-common4.2.1-4X Window System (XFree86) infrastr -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86, Mesa, Debian, and libGLU revisited
see below. On Wed, 20 Sep 2000, Brian Paul wrote: > > > Branden Robinson wrote: > > > > On Mon, Sep 18, 2000 at 09:54:03AM +0200, Harald Dunkel wrote: > > > > However, a consensus has formed of late among the XFree86 developers, in > > > > conjunction with Brian Paul (the mastermind of the Mesa project), that > > > > libGLU should be shipped, built and installed with the rest of Mesa as > > > > part > > > > of the XFree86 distribution. I've corresponded with Brian on this > > > > point, > > > > and he suggests that the 3 libraries, libGL, libGLU, and libOSMesa, be > > > > shipped in one package. I see no compelling reason to do otherwise. > > > > > > What is Debian's policy regarding OpenGL libraries provided by > > > the hardware vendor (NVidia, for example)? Don't we get a > > > packaging conflict here? > > > > No. Debian has a virtual package called "libgl1" which any package > > providing a compliant GL library can "Provide" in the package management > > sense. > > > > However, I'm concerned that not every one of these implementations that > > ships libGL will also ship libGLU and (especially) libOSMesa. Brian, do > > you still think it is a good idea to keep all 3 of these libraries > > together? But then how do you handle binary drivers like nvidia's? or someone writes a gl library for hardware x, he has to distribute everything instead of just his new libgl? I don't understand what the advantage is having one big package is over smaller, more flexible packages. > > Yes. And libGLW.a. > > > > What set of GL libraries can any reasonable GL implementation be > > expected to provide? Only that and no more needs to be handled with this > > mechanism. > > Someone else already mentioned the Linux/OpenGL standard base website. > > -Brian >
Re: XFree86, Mesa, Debian, and libGLU revisited
see below. On Wed, 20 Sep 2000, Brian Paul wrote: > > > Branden Robinson wrote: > > > > On Mon, Sep 18, 2000 at 09:54:03AM +0200, Harald Dunkel wrote: > > > > However, a consensus has formed of late among the XFree86 developers, in > > > > conjunction with Brian Paul (the mastermind of the Mesa project), that > > > > libGLU should be shipped, built and installed with the rest of Mesa as part > > > > of the XFree86 distribution. I've corresponded with Brian on this point, > > > > and he suggests that the 3 libraries, libGL, libGLU, and libOSMesa, be > > > > shipped in one package. I see no compelling reason to do otherwise. > > > > > > What is Debian's policy regarding OpenGL libraries provided by > > > the hardware vendor (NVidia, for example)? Don't we get a > > > packaging conflict here? > > > > No. Debian has a virtual package called "libgl1" which any package > > providing a compliant GL library can "Provide" in the package management > > sense. > > > > However, I'm concerned that not every one of these implementations that > > ships libGL will also ship libGLU and (especially) libOSMesa. Brian, do > > you still think it is a good idea to keep all 3 of these libraries > > together? But then how do you handle binary drivers like nvidia's? or someone writes a gl library for hardware x, he has to distribute everything instead of just his new libgl? I don't understand what the advantage is having one big package is over smaller, more flexible packages. > > Yes. And libGLW.a. > > > > What set of GL libraries can any reasonable GL implementation be > > expected to provide? Only that and no more needs to be handled with this > > mechanism. > > Someone else already mentioned the Linux/OpenGL standard base website. > > -Brian > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
