Bug#594768: Should xconq be removed?
On 08/29/2010 05:52 AM, Luca Falavigna wrote: Package: xconq Version: 7.4.1-4.1 Severity: serious Tags: sid squeeze xconq seems dead upstream, and requires an obsolete Tcl/Tk version, so it seems a good candidate for removal. If you don't think so, please close this bug report, otherwise I'll convert it into a removal request in a couple of weeks. Yes, please do convert it into a removal. I'd been hoping to package a gtk version that was started, but that's long dead upstream as well. It's sad to see such a great old piece of software get removed, but it's no longer a fit program for distribution in Debian. Thanks for your work! - David -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xconq depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libx11-6 2:1.3.3-3 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxmu6 2:1.0.5-1 X11 miscellaneous utility library ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii tcl8.38.3.5-14 Tcl (the Tool Command Language) v8 ii tk8.3 8.3.5-15 Tk toolkit for Tcl and X11, v8.3 - ii xconq-common 7.4.1-4.1 Common files for Xconq xconq recommends no packages. xconq suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#492888: [xserver-xorg-input-kbd] Can confirm this bug
severity 492888 important thanks Bastien ROUCARIES wrote: severity 492888 grave thanks Package: xserver-xorg-input-kbd Version: 1:1.3.1-1 I can confirm this bug. It is really a boring bug. dmesg is empty, log also. How can I debug this bug ? Are you saying that the /var/log/Xorg.0.log is entirely empty? Or that there's nothing interesting? We'd like it if it has any text at all in it, as well as an xorg.conf if you have one. Also what would be helpful is for you to get an X server backtrace if you have another machine you can use to ssh in to the crashed one. Instructions are here: http://wiki.debian.org/XStrikeForce/XserverDebugging. Raise importance to grave because it completly render keyboard unusable after random time, and destroy completly my X session. Only mouse work, and I need to disconnect using mouse. This is not a grave bug. Please don't inflate bug severities. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515976: xorg-server: Changes to 'debian-unstable'
Julien Cristau wrote: > reopen 515976 > kthxbye > > On Fri, 2009-02-20 at 04:09 +, David Nusinow wrote: >> commit b73bd774ce52c946b2ace622d98f3df584258ec9 >> Author: David Nusinow >> Date: Thu Feb 19 23:06:59 2009 -0500 >> >> Bump x11proto-input-dev build-dep to >= 1.5.0 to fix keyboard layout >> breakage with new libxi built against the same. Closes: #515976 > > Michel and I think this looks like papering over the real bug, so I'll > reopen this until we find out what the underlying issue is. > The version of the protocol headers used to build the server and lib > shouldn't affect compatibility. You're right, it looks like I misread one of the commits, although if the rebuild fixed the problem then a version mismatch of some sort is probably a cause. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515976: libxi6 causes kdm using the wrong keyboard-layout
Celejar wrote: > On Thu, 19 Feb 2009 22:47:34 -0500 > David Nusinow wrote: > > ... > >> I think I've figured out this bug. It looks like the new libxi was built >> against the new input protocol headers, while the server was built >> against the old headers. The mismatch in the protocol could very well be >> causing this bug. I've uploaded a simple rebuild of the xserver to >> alioth. Could you add the following to your sources.list and upgrade >> your server to see if that fixes the bug? >> >> deb http://pkg-xorg.alioth.debian.org/libxi-fix ./ >> >> If it does, I'll sign the packages and make an upload of this build to >> unstable. > > Works for me! Great! Thanks for testing! The upload to unstable is going now. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515976: [Fwd: Re: Bug#515976: libxi6 causes kdm using the wrong keyboard-layout]
--- Begin Message --- On Thu, 19 Feb 2009 22:47:34 -0500 David Nusinow wrote: ... > I think I've figured out this bug. It looks like the new libxi was built > against the new input protocol headers, while the server was built > against the old headers. The mismatch in the protocol could very well be > causing this bug. I've uploaded a simple rebuild of the xserver to > alioth. Could you add the following to your sources.list and upgrade > your server to see if that fixes the bug? > > deb http://pkg-xorg.alioth.debian.org/libxi-fix ./ > > If it does, I'll sign the packages and make an upload of this build to > unstable. Works for me! Celejar -- mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator --- End Message ---
Bug#515976: libxi6 causes kdm using the wrong keyboard-layout
Julien Cristau wrote: > tag 515976 help > kthxbye > > On Wed, 2009-02-18 at 16:54 +0100, Heiko Munz wrote: >> Package: libxi6 >> Version: 2:1.2.0-2 >> Severity: grave >> Justification: renders package unusable >> >> After upgrading libxi6 from the version 1.1.4-1 to 1.2.0-2, the login >> manager (in my case kdm) use the wrong keyboard layout "qwerty" instead >> of the correct "qwertz" layout. It concerns only the login manager (kdm) >> and not any x-session or the console. >> It seems that gdm is also affected, but xdm is not. >> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515734) > > This is pretty weird. The only code change between libXi 1.1.4 and > 1.2.0 is the addition of device properties, which aren't supported by > the X server in sid, so these code paths should never get hit. More > investigation from someone who can reproduce would be welcome... > Changes in x11proto-input might also be relevant, but I don't see > anything suspect there either, and since I'm not affected by the bug > it's hard to figure out what's going wrong. I think I've figured out this bug. It looks like the new libxi was built against the new input protocol headers, while the server was built against the old headers. The mismatch in the protocol could very well be causing this bug. I've uploaded a simple rebuild of the xserver to alioth. Could you add the following to your sources.list and upgrade your server to see if that fixes the bug? deb http://pkg-xorg.alioth.debian.org/libxi-fix ./ If it does, I'll sign the packages and make an upload of this build to unstable. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#464734: topshelf: Does Not Start
On Sun, Feb 10, 2008 at 10:42:53AM -0500, David Nusinow wrote: > On Sun, Feb 10, 2008 at 03:15:52PM +0100, Siegfried-Angel wrote: > > Oops, I mean Python 2.5. > > Ok, I'll try it at work little later (where topshelf is broken), but > topshelf works fine on my home system which does not have 2.5 installed. Sorry it took so long to reply. Yes, I've explicitly tested this with python 2.5 and it works perfectly. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464734: topshelf: Does Not Start
On Sun, Feb 10, 2008 at 03:15:52PM +0100, Siegfried-Angel wrote: > Oops, I mean Python 2.5. Ok, I'll try it at work little later (where topshelf is broken), but topshelf works fine on my home system which does not have 2.5 installed. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464734: topshelf: Does Not Start
On Fri, Feb 08, 2008 at 10:08:06PM +0100, Siegfried-Angel wrote: > I forwarded this upstream: https://bugs.launchpad.net/topshelf/+bug/190295. > > Could you please check if it works with Python 2.4? As you can see from the version of python that reportbug attached to my bug report, I was using python 2.4. Interestingly, this program works on one of my systems but not the other. I don't have any idea why this would be. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464734: topshelf: Does Not Start
Package: topshelf Version: 0.2.1-1 Severity: serious Adding topshelf to my gnome panel fails to load the app. It pops up an error dialog box saying "The panel encountered a problem while loading "OAFIID:Gnome_Panel_TopShelf"." and allows me to delete it from my configuration. If I don't delete it, I get this message every time I log in until I do delete the app. Here's what it prints to ~/.xsession-errors: ** (gnome-panel:4001): WARNING **: panel-applet-frame.c:1278: failed to load applet OAFIID:Gnome_Panel_TopShelf: Failed to resolve, or extend '!prefs_key=/apps/panel/applets/applet_11/prefs;background=none:;orient=up;size=x-small;locked_down=false - David Nusinow -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages topshelf depends on: ii libgnome2-0 2.20.1.1-1 The GNOME 2 library - runtime file ii python2.4.4-6An interactive high-level object-o ii python-gtk2 2.12.1-1 Python bindings for the GTK+ widge Versions of packages topshelf recommends: ii yelp 2.20.0-1 Help browser for GNOME 2 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400632: x11-common should not ship a SUID root binary
On Mon, Feb 04, 2008 at 12:53:35PM -0500, Stephen Frost wrote: > Package: x11-common > Severity: serious > tags 400632 -wontfix > > Greetings, > > The setuid usr/bin/X binary should not be shipped with x11-common > because it's not *needed* for X11 clients. That by itself is a good > enough reason. Put it in xserver-xorg-core or similar, not in > x11-common. > > Additionally, x11-common gets pulled in on server for things like > libgd-xpm, which isn't entirely unreasonable if someone wants to > generate an X pixmap on a server. One could also have, I dunno, > *xterm* installed on a server for clients to use without have an X > server installed on the same server. Unless xterm *requires* > usr/bin/X, it shouldn't be installed as part of something xterm > depends on. The easy and obvious fix is to just ship this with xserver-xorg instead. To be honest, I'm not sure why this ended up in x11-common instead of here. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368560: mesa: material under SGI Free Software License B is not DFSG-free
On Thu, Dec 06, 2007 at 11:30:12PM +0100, Sylvestre Ledru wrote: > Hello, > > Is there any progress on this issue ? > I packaged JOGL for Debian and would like to see it in Debian. > However, JOGL has the same files as mesa (translated to Java) under the > same license (SGI free license B). > Does anyone tried to contact the upstream ? Basically no, there's no real progrss on the issue. I was speaking with Brett Smith[0] from the FSF last night about it though, and they are very interested in seeing the issue resolved. You may want to contact him if you're really interested in working on it. - David Nusinow [0] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452897: /etc/X11/X points to /bin/true on a clean sid install.
On Sun, Nov 25, 2007 at 05:38:33PM +, Diego Escalante Urrelo wrote:
> Package: xserver-xorg
> Version: 1:7.3+6
> Severity: serious
>
> --- Please enter the report below this line. ---
>
> Installing a base Etch system (just the base, no X or fancy stuff),
> migrating to Sid, and then apt-get installing xorg will install X
> succesfully but will make it useless because of /etc/X11/X pointing
> to /bin/true. GDM will fail showing an empty log. X will exit without
> any output ('true' is not really verbose). xinit and startx will fail
> with misterious errors like "server error" or "connection timed out".
>
> Calling Xorg directly on the console works fine. The problem can be
> fixed by linking /etc/X11/X to /usr/bin/Xorg.
Thanks for catching this, I missed it on my clean install tests. I'll be
pushing a fix shortly, and I should be able to upload it tonight.
- David Nusinow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442316: [Pkg-utopia-maintainers] Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Thu, Oct 25, 2007 at 02:08:19AM +0200, Michael Biebl wrote: > David Nusinow schrieb: > > Ok, I missed that somehow. So it should probably be hal that generates this > > and not the xserver? > > The problem with hal generating the fdi file, would be that it could get > out of sync, whenever you run dpkg-reconfigure xserver-xorg. > We would also have to duplicate a lot of logic from xserver-xorgs > postinst in hal. Generating the fdi file from within xserver-xorg seems > to be more straightforward to me. > > If you are going to remove the input device section (generation) > completely from xserver-xorgs postinst and rely completely on hal for > that, then I agree hal should be the one and only place where to > configure the keyboard/input. > Doing the configuration at two places (xserver-xorg->xorg.conf and hal-> > fdi) will really cause headaches imho. Yeah, we'll remove it from the xserver postinst. The only thing I want is to allow the server to respect currently existing xorg.confs. So long as that happens, it's probably better if hal does create the fdi. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Wed, Oct 24, 2007 at 01:53:40PM +0300, Daniel Stone wrote: > On Tue, Oct 23, 2007 at 08:17:10PM -0400, ext David Nusinow wrote: > > On Tue, Oct 23, 2007 at 10:02:35PM +0300, Daniel Stone wrote: > > > On Tue, Oct 23, 2007 at 08:02:31PM +0200, ext Michael Biebl wrote: > > > > Whenever xorg input hotplugging kicks in, the evdev driver is used. The > > > > kbd keyboard settings from xorg.conf are ignored and the en_US keyboard > > > > layout is used. > > > > > > Yes, this should probably be fixed up, I guess. But the long-term fix > > > is to provide an FDI file in /etc that specifies the keyboard layout. > > > > My feeling is the other way around, provided that the X server is the only > > user of this field. People already know how to edit xorg.conf, and they > > expect it. Telling them to edit a relatively obscure file among many other > > fdi's is more painful. There's also userspace tools that exist to help with > > generating a xorg.conf, but nothing friendly to deal with fdi's. > > As I've said before, the X server isn't the only user of the field. :) > Ubuntu were trying to move to cxkb a year or so ago, and the only thing > that stopped them in the end was how huge the XKB codebase was, which > I'm fixing (very slowly) upstream. So yeah, if having this in HAL lets > us finaly unify console and X keymaps ... Ok, I missed that somehow. So it should probably be hal that generates this and not the xserver? > > > > Preferably, the X server should use the keyboard layout specified in > > > > xorg.conf (for the old kbd driver) even when used in xorg hotplugging > > > > mode. > > > > > > Yes, probably. > > > > My sense is that if we're going to do this, then there's no need to > > generate the fdi. Just generate the xorg.conf. We can patch the server to > > use libhal_device_set_property_string to dynamically set the keyboard > > layout at runtime in hal's database, and the server can just draw that > > information from xorg.conf initially. > > Well, you could even have a postinst that scans xorg.conf and generates > the FDI, but yes, the X server should be responsible for checking this > and not breaking existing setups. Yeah, I'm mainly concerned with not breaking existing setups. I feel like we've been doing that a lot lately. Luckly, lenny is a ways away so we have time to break things quite a bit before we get it right. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Tue, Oct 23, 2007 at 10:02:35PM +0300, Daniel Stone wrote: > On Tue, Oct 23, 2007 at 08:02:31PM +0200, ext Michael Biebl wrote: > > Whenever xorg input hotplugging kicks in, the evdev driver is used. The > > kbd keyboard settings from xorg.conf are ignored and the en_US keyboard > > layout is used. > > Yes, this should probably be fixed up, I guess. But the long-term fix > is to provide an FDI file in /etc that specifies the keyboard layout. My feeling is the other way around, provided that the X server is the only user of this field. People already know how to edit xorg.conf, and they expect it. Telling them to edit a relatively obscure file among many other fdi's is more painful. There's also userspace tools that exist to help with generating a xorg.conf, but nothing friendly to deal with fdi's. > > If I understood Daniel correctly, he proposes to set the keyboard layout > > (probably based on the values from xorg.conf) via a generated fdi file. > > I'd like to avoid that, because that would complicate things. > > How would it complicate anything? xorg.conf is a file, so is an FDI. > We're already using FDIs through HAL, anyway ... Generating xorg.conf sucks though and we're trying to get away from that as much as is sensible. Of course, this was the one section I'd planned to keep generating anyway. > > Preferably, the X server should use the keyboard layout specified in > > xorg.conf (for the old kbd driver) even when used in xorg hotplugging mode. > > Yes, probably. My sense is that if we're going to do this, then there's no need to generate the fdi. Just generate the xorg.conf. We can patch the server to use libhal_device_set_property_string to dynamically set the keyboard layout at runtime in hal's database, and the server can just draw that information from xorg.conf initially. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383465: Contains obfuscated source code, DFSG violation?
On Mon, Jul 16, 2007 at 12:14:14PM +0200, Robert Millan [ackstorm] wrote: > On Wed, Nov 29, 2006 at 07:50:51PM -0500, David Nusinow wrote: > > > > The nouveau project is deobfuscating the code as they go. Even if their DRI > > work isn't ready for Lenny, we'll definitely be pulling their deobfuscated > > code. > > Put aside what we do for Lenny, is there any technical problem in terms of > user support if we move this driver to non-free and let vesa and/or vga be > the default for nvidia users? > > Given that the driver is 2D-only anyway, I don't see it as a big loss. With > the vesa option, at least the non-free bits are moved down to firmware, where > it's no longer our responsability (read: if the driver is faulty and we can't > fix it, it would be faulty on all platforms, and I find that highly unlikely > since the card wouldn't work on pristine win32 either). The nv driver does provide additional features over the vesa driver, most notably the recent inclusion of randr 1.2 support. Because of this, I'd rather not push people even further towards the proprietary driver. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402165: [Xcb] Bug#402165: Workarounds for locking assertions in Sun Java 1.5 and 1.6
On Sat, Jun 02, 2007 at 01:14:55PM +0200, Julien Cristau wrote:
> On Sat, Jun 2, 2007 at 11:54:02 +0200, Florian Weimer wrote:
>
> > * Josh Triplett:
> >
> > > Barring that, how about shipping an executable script
> > > /usr/share/doc/sun-java{5,6}-bin/unbreak-my-java ?
> >
> > The license does not allow for anything like that, I'm afraid.
> >
> We could ship that in libx11-6, then. *shrug*
If you want to do it in the packaging scripts, the problem becomes that
when someone installs java after libx11-6 the scripts won't run to make the
change. The user could re-install the package with dpkg -i, but that'd be
annoying. Maybe we could ship a script to make the change that the postinst
runs, and that the user could run manually if they need to?
- David Nusinow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414535: Please Set Workaround Environment Variable
Package: sun-java6-jre Version: 6-00-2 Hello, The XSF is going to be uploading XCB to unstable soon, and we want to see this problem at least be manageable. Novell has a patch that we'll be using[0] that allows XCB to ignore the locking issue if the LIBXCB_SLOPPY_LOCK environment variable is set. If the variable is not set, the error in this bug report will still cause problems. We'll be uploading this patch in the next few days to either experimental or unstable. If you have any additional questions, please cc debian-x@lists.debian.org so we can respond. - David Nusinow [0] Actually, we got a version from Ubuntu that's more permissive, but we want to catch these bugs, so we're shipping the restrictive one from Novell. --- System information. --- Architecture: i386 Kernel: Linux 2.6.18-4-686 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.us.debian.org 500 unstabledodji.flucast.org 1 experimentalftp.debian.org --- Package information. --- Depends (Version) | Installed ==-+- java-common (>= 0.24) | 0.25 locales| 2.3.6.ds1-13 sun-java6-bin (= 6-00-2) | 6-00-2 OR ia32-sun-java6-bin (= 6-00-2) | debconf (>= 0.5) | 1.5.13 OR debconf-2.0| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402658: That is serious
tags 402658 + pending thanks On Wed, Feb 28, 2007 at 02:08:06PM +0100, Lionel Elie Mamane wrote: > found 402658 2:1.1.1-18 > severity 402658 serious > thanks > > If I'm not mistaken, this should be severity serious, as per policy > 7.5.1. I just got that on a partial upgrade on a etch/sid mixed > machine. Thanks for bringing this to my attention. I've fixed this in git, and I'll be uploading it shortly. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405639: Bug#406058: failed to load module kbd
On Mon, Jan 08, 2007 at 11:27:22PM +0100, Julien Cristau wrote: > On Mon, Jan 8, 2007 at 13:21:54 -0800, Steve Langasek wrote: > > > So what should be done with this bug? Should it be merged with bug #405639? > > Do you think it needs to be treated as RC independently of bug #405639? > > (FWIW, I don't; smooth upgrades from unofficial backports are absolutely not > > RC in my book.) > > > I've not been able to reproduce a case where having > Depends: xserver-xorg-input-all | xserver-xorg-input, > xserver-xorg-video-all | xserver-xorg-video-1.0 > Recommends: xserver-xorg-input-all, xserver-xorg-video-all > makes things worse than they currently are, so I would tend towards > doing that. It fixes the issue with tasksel et al., and should ensure > that aptitude tries as hard as possible to install the -all packages on > upgrade and on initial install. > I'd like to have your and/or David's OK before uploading that, though. > > I agree that breaking upgrades from backports of from pre-release etch > is probably not RC, but I'm not sure other upgrade cases aren't broken > right now (like upgrading from xfree86 to xorg using etch's aptitude, > although I haven't tested that yet). Looks good to me. Upload away. Hopefully we can get more testing with that configuration before the release is out. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403818: xserver-xorg: no video or keyboard after upgrading to sarge (deps too loose)
On Wed, Dec 20, 2006 at 02:47:40AM +0100, Steinar H. Gunderson wrote: > On Tue, Dec 19, 2006 at 08:40:26PM -0500, David Nusinow wrote: > > Ouch. This is a bug in aptitude, aiui. It should be choosing the first > > option if nothing is currently installed, and allowing the second to > > substitute. > > Probably something in -all caused a conflict, and the conflict resolution > manager preferred a random choice providing -input instead. I can't imagine what that would be... I'd love to know. Was this on x86? > > Either way, it's probably too late to fix this in aptitude for etch, so a > > workaround is necessary... > > Most upgrades will probably happen with the aptitude from sarge, BTW. Right. I'm retarded :-) > > If I build a package set with this, will you be able to test it to make > > sure it works? > > Unfortunately, no; the machine was just my mother's workstation. However, > I've picked out the dpkg status backup and reconstructed the aptitude lines; > talk to Julien Cristau, he has the data in question. Got it, thank you. I'll take a look. > >> Also, xorg.conf was blank after the upgrade, but I guess that's for > >> another bug, which will be far harder to track down... :-) > > Gyah... did xserver-xorg error out during postinst? I'll have to look for a > > codepath that can cause that beyond errors. > > No, it didn't error out. It just showed the warning debconf template, and > then continued as nothing was wrong. > > Note that due to some conflicts etc., the upgrading line was "aptitude > install gnome" (the full dist-upgrade was not done until later); it _might_ > be that a full dist-upgrade is luckier somehow, but I'm not going to bet on > it. Just giving aptitude the explicit hint that the user would probably like > to have -input-(kbd,mouse) and -video-vesa sounds like the best hint to me, > especially as they're not likely to conflict with anything (so the conflict > resolver accepts that more or less right away). Perhaps for video 'xserver-xorg-video-all | xserver-xorg-video-vesa' in the recommends. This doesn't map to input though, since we'd need both -kbd and -mouse. Simply duplicating the recommendation may be possible though (xserver-xorg-input-all | xserver-xorg-input-kbd, xserver-xorg-input-all | xserver-xorg-input-mouse). - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403818: xserver-xorg: no video or keyboard after upgrading to sarge (deps too loose)
On Tue, Dec 19, 2006 at 11:29:07PM +0100, Steinar H. Gunderson wrote: > Package: xserver-xorg > Version: 1:7.1.0-8 > Severity: serious > Justification: 23:28 < vorlon> Sesse: I'd call it RC, no? Definitely. I'm treating it as grave even if it's not officially so. > After dist-upgrading (using etch's aptitude) from sarge to etch, one > machine here was completely without keyboard or mouse support, and X > refused to work. > > A bit of hunting revealed that aptitude had pulled in > xserver-xorg-input-magictouch and xserver-xorg-video-siliconmotion to > fulfill xserver-xorg's dependencies on "xserver-xorg-video-all | > xserver-xorg-video" and "xserver-xorg-input-all | xserver-xorg-input", > respectively. This is clearly not satisfiable. Ouch. This is a bug in aptitude, aiui. It should be choosing the first option if nothing is currently installed, and allowing the second to substitute. On an upgrade, none of these would be installed, so it would choose the first options in both instances. In this case, that would be xserver-xorg-video-all and xserver-xorg-input-all by default. Is this a misunderstanding? Either way, it's probably too late to fix this in aptitude for etch, so a workaround is necessary... > AFAICS there are two OK ways of solving this: > > 1. Make the depends into "xserver-xorg-video, xserver-xorg-input", and > add Recommends for the -all packages instead. If I build a package set with this, will you be able to test it to make sure it works? > 2. Add xserver-xorg-input-kbd and xserver-xorg-input-mouse explicitly > to the list of depends (or possibly recommends?), which should make > aptitude Do The Right Thing (hopefully). This won't solve the issue > for video, though. I can add xserver-xorg-video-vesa as a depends. At the very least we'd have a fail-safe option. The xserver-xorg xorg.conf creation scripting should work with this too, in theory, although I'll have to check that. > One could use a combination of 1 and 2. Better safe than sorry :-) > Note that the request to "aptitude install xorg", which was given by > debconf, was a no-op, since all the dependencies were already fulfilled. > > Also, xorg.conf was blank after the upgrade, but I guess that's for > another bug, which will be far harder to track down... :-) Gyah... did xserver-xorg error out during postinst? I'll have to look for a codepath that can cause that beyond errors. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383465: Contains obfuscated source code, DFSG violation?
On Tue, Nov 28, 2006 at 08:49:56PM +, Sam Morris wrote: > I found some interesting links about this topic: > > http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/README.RIVATNT.diff?r1=1.1.2.2&r2=1.1.2.3&hideattic=0&only_with_tag=xf-3_3_3 > and > http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/nv3driver.c.diff?r1=1.1.2.5&r2=1.1.2.6&hideattic=0&only_with_tag=xf-3_3_3 > > If nvidia already 'forced' XFree86 to obfuscate their source code, it > doesn't seem unlikely that they require obfuscation of the source for > the 'nv' driver too. They can't actually force obfuscation beause the code is under MIT/X11 (well... most of it. We need to clarify the situation of nv_hw.c badly). The nouveau project is deobfuscating the code as they go. Even if their DRI work isn't ready for Lenny, we'll definitely be pulling their deobfuscated code. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384273: Debian: can #384273 be closed
On Sat, Oct 14, 2006 at 03:49:04PM +0200, Tomas Pospisek wrote: > http://bugs.debian.org/384273 is still open, allthough the maintainer > claims to have uploaded a fixed version. > > Could you verify that this indeed fixes the problem? > > I am asking you, since the reported bug has severity grave and thus is a > bug that is blocking the forthcoming Etch release of Debian. Therefore > it'd be nice to be able to close that bug... I've been giving the submitter two weeks to reply, which is what I've been using as a standard on such issues. That time is up tomorrow, so if he doesn't reply I'll close the bug then. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385078: closed by David Nusinow <[EMAIL PROTECTED]> (Bug#385078: fixed in xorg 1:7.1.0-3)
On Sat, Oct 07, 2006 at 09:34:16PM -0400, David Nusinow wrote: > tags 385078 unreproducible > thanks > > On Fri, Oct 06, 2006 at 02:59:29PM +0200, Mario 'BitKoenig' Holbe wrote: > > package xserver-xorg > > reopen 385078 > > thanks > > > > On Thu, Oct 05, 2006 at 08:19:17PM -0700, Debian Bug Tracking System wrote: > > > #385078: xserver-xorg: impossible mouse configuration other than > > > /dev/input/mice, > > > It has been closed by David Nusinow <[EMAIL PROTECTED]>. > > >* Make /dev/input/mice the default mouse port in the > > > xserver-xorg.templates > > > file. Also provide the devices in this file rather than as a > > > variable in > > > the config script. Closes: #385078 > > > > I cannot confirm that. Neither `dpkg-reconfigure xserver-xorg' nor > > `dpkg-reconfigure -phigh xserver-xorg' nor `dpkg-reconfigure -plow > > xserver-xorg' asks me about the mouse-device. It always fixes it to > > /dev/input/mice. > > Are you sure you're using xserver-xorg version 1:7.1.0-3? It's -3 that > fixes it, and it works here both on my live system and in a chroot. Sorry, I did this before I read your latter mail. Thanks for following up again. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385078: closed by David Nusinow <[EMAIL PROTECTED]> (Bug#385078: fixed in xorg 1:7.1.0-3)
tags 385078 unreproducible thanks On Fri, Oct 06, 2006 at 02:59:29PM +0200, Mario 'BitKoenig' Holbe wrote: > package xserver-xorg > reopen 385078 > thanks > > On Thu, Oct 05, 2006 at 08:19:17PM -0700, Debian Bug Tracking System wrote: > > #385078: xserver-xorg: impossible mouse configuration other than > > /dev/input/mice, > > It has been closed by David Nusinow <[EMAIL PROTECTED]>. > >* Make /dev/input/mice the default mouse port in the > > xserver-xorg.templates > > file. Also provide the devices in this file rather than as a variable > > in > > the config script. Closes: #385078 > > I cannot confirm that. Neither `dpkg-reconfigure xserver-xorg' nor > `dpkg-reconfigure -phigh xserver-xorg' nor `dpkg-reconfigure -plow > xserver-xorg' asks me about the mouse-device. It always fixes it to > /dev/input/mice. Are you sure you're using xserver-xorg version 1:7.1.0-3? It's -3 that fixes it, and it works here both on my live system and in a chroot. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384273: xfonts-base: xorg wont start could not open default cursor font 'cursor
On Wed, Aug 23, 2006 at 01:59:47PM -0400, mlaks wrote: > Subject: xfonts-base: xorg wont start could not open default cursor font > 'cursor' > Package: xfonts-base > Version: 1:1.0.0-3 > Severity: grave > Justification: renders package unusable > > *** Please type your report below this line *** > I did a fresh install of etch using business card disk, installed > desktop packages. > I then upgraded to sid > from etch. I had a working X initially through the point of the > dist-upgrade. > > In fact X continued to work until I did a reboot (I did a reboot because > of a reinstall of linux-image-2.6.16, and system warning reboot > neccessary because of reinstall of same kernel). > > Now after reboot X wont start with error message in X.log > > Fatal server error: > could not open default cursor font 'cursor' > > Now I did a apt-get remove --purge xfont-base > and I get an error message > > warning: /usr/lib/X11/fonts/misc does not exist or is not a directory > warning: /etc/X11/fonts/misc does not exist or is not a directory > warning: /usr/lib/X11/fonts/misc does not exist or is not a directory > > and same sort of message with > apt-get install xfont-base. > > These directories are present on other sid machines I have. > They have files such as > 1) > ls /usr/lib/X11/fonts/misc > fonts.alias fonts.cache-1 > > 2) > ls /etc/X11/fonts/misc > xfonts-base.alias > > This absence seems to be the source of my problems. What can I do to solve > them? > > Is this a bug in xfonts-base? I've just uploaded a new set of xfonts* packages with fixes from Eugene Konev to unstable. They're in incoming.debian.org right now, or you can wait for them to be pushed to your mirror. Could you install those and let us know if this bug can be closed? Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373192: xserver-xorg-video-glint: X does not start due to resource conflicts
Hi Christophe, On Tue, Jun 13, 2006 at 03:26:10PM +0200, Christophe TROESTLER wrote: > Package: xserver-xorg-video-glint > Version: 1:1.0.1.3-3 > Severity: grave Can you try the newest version of the glint driver, 1:1.1.1-3, which is currently in unstable? You'll need the new x server as well. I believe this contains an upstream fix for your problem. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385078: xserver-xorg: impossible mouse configuration other than /dev/input/mice
On Sun, Sep 17, 2006 at 05:54:43PM -0400, José Parrella wrote: > tags 385078 +patch > thank you > > Please try this patch. I'm not a bash (nor debconf!) guru but I think > that it address your concerns regarding the non-interactivity for the > mouse device setting. Please let me know if the patch works for you. > Therefore I'm providing: > > 1) A full, NMU-ready, source package in [1] > 2) i386 binary packages in [1], and > 3) A diff regarding the config.in, which you'll find attached > > Note that this upload does not fix several Lintian warnings that my > build system reports. I will be glad to fix this if the patch works. > Thank you very much for your time and attention to details. Thank you for the patch but I think this is not exactly the right solution. I'll work up a proper fix for this over the coming couple of days. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384256: xserver-xorg-core newer than xserver-xorg-video-all
On Tue, Aug 22, 2006 at 07:57:29PM -0400, Bob Hauck wrote: > Package: xserver-xorg-core > Version: 1:1.1.1-3 > Severity: grave > Justification: renders package unusable > > After doing an apt-get upgrade, X will no longer start and gives an > error message that says the modular driver for "radeon" is using an outdated > ABI. It appears that the version of xserver-xorg-core has been upgraded but > there is no corresponding upgraded version of xserver-xorg-video-ati. > > Reverting to 1.0.2-9 restores a working X setup. Yes, this was caused by a botched upload that was meant for experimental. I'm uploading the fixed 1.0.2-10 to unstable right now, so I'm closing this report. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382988: (no subject)
On Tue, Aug 22, 2006 at 10:36:23PM +0200, Denis Barbier wrote: > reassign 382988 kdebase > thanks > > On Mon, Aug 21, 2006 at 09:58:39PM +, David Nusinow wrote: > > Hi all, > > > >Could someone give me some clue as to what programs in xbase-config are > > segfaulting in this case? I'm digging in to the libxkb* code now, but my > > guess is that this is a server configuration issue, in which case I need > > your xorg.conf. Thanks! > > kxkb has to be updated to look for files in /usr/share/X11/xkb, here is > a patch (untested). Awesome. "Not My Problem" is the best answer I could have hoped for. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382988: (no subject)
Hi all, Could someone give me some clue as to what programs in xbase-config are segfaulting in this case? I'm digging in to the libxkb* code now, but my guess is that this is a server configuration issue, in which case I need your xorg.conf. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383334: xorg-server_1:1.1.1-1(sparc/experimental): FTBFS: "Failed to link Mesa source tree"
tags 383334 +pending thanks On Wed, Aug 16, 2006 at 05:48:49PM +0200, Frank Lichtenheld wrote: > Package: xorg-server > Version: 1:1.1.1-1 > Severity: serious > > Hi, > > your package failed to build from source. Sadly I had no time > investigating yet, why, but it does seem to appear on all architectures. This is due to me not remembering to bump the required version of the mesa packages in the build-depends. It's fixed in svn by Drew and I'll be uploading a fixed version shortly. Thanks for the report! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#371874: x11-common postinst error: trouble with /usr/include/X11
On Sun, Jun 11, 2006 at 10:30:21PM -0400, Joey Hess wrote: > David Nusinow wrote: > > Ok, this is an extremely troubling bug. The previous x11-common's postinst > > gets called when the new x11-common's postinst fails with the /usr/bin/X11 > > switch. > > No the problem is not that the new postinst is failing (nor does dpkg do > any error-unwind involving the old postinst if the new one fails). > The postinst is called to error-unwind if prerm or preinst fails, and > apparently (though policy doesn't seem to document this) when unpacking > fails due to a file conflict, as happens here: > > Unpacking replacement x11-common ... > dpkg: error processing /var/cache/apt/archives/x11-common_1%3a7.0.20_arm.deb > (--unpack): > trying to overwrite `/usr/X11R6/bin', which is also in package xcalibrate > x11-common postinst warning: /usr/include/X11 symbolic link does not exist > > I could be wrong but I think that in an error-unwind situation > dpkg always runs the new package's postinst[1]. Which makes fixing this > kind of bug easier. > > Also, if it's helpful I can reproduce this at will. Unfortunatly the > image I have that can reproduce it is arm. :-) Ok, vorlon managed to pinpoint the bug. I'm on crack. So the preinst was removing the include, share, and lib symlinks during preinst. After that, it was doing the bin removal, which failed in your case. On unwind, the lib, include, and share symlinks were still gone causing the problems. We've moved the bin transition to being the first thing in the preinst, so we fail early, prior to messing with anything else. This should solve the problem. I'll be uploading this to unstable in a few minutes. Thank you for the help! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#371874: x11-common postinst error: trouble with /usr/include/X11
On Wed, Jun 07, 2006 at 10:48:44PM -0400, Joey Hess wrote: > [EMAIL PROTECTED] wrote: > > Package: x11-common > > Version: 1:7.0.20 > > Severity: grave > > X-Debbugs-CC: "Henk Boom" <[EMAIL PROTECTED]> > > > > > > x11-common postinst error: trouble with /usr/include/X11 > > > > > > We get this problem on two different systems -- an etch AMD-64 (installed > > as Debian-AMD64, but upgraded as Debian since a few weeks ago), and etch > > running on a 32-bit Athlon (installed as sarge, subsequently dist-upgraded > > to etch). > > > > We are trying to upgrade our machines from xorg 6.9 to xorg 7.0, and have > > been stymied by the installation behaviour of x11-common, specifically the > > one that appears as /var/cache/apt/archives/x11-common_1%3a7.0.20_amd64.deb > > on the AMD64, and /var/cache/apt/archives/x11-common_1%3a7.0.20_i386.deb > > on the 32-bit system. > > > > The post-install script complains that the symbolic link /usr/include/X11 > > does not exist. > > > > On the AMD-64 we managed to get past this point, but we're not sure exactly > > what we did that did the trick. We tried uninstalling x11-common in order > > to install it again. Forcing uninstallation and installation did not *seem* > > to work, but we are not familiar enough with the behavious of apt-get to > > know > > this for sure. We succeeded on tha AMD-64 only after deleting about a > > hundred packages that directly or indirectly depended on x11-common, then > > uninstalling and reinstalling it. > > > > On the 32-bit machine we are utterly at a standstill, since there are > > far, far too many packages to delete by hand. > > > > In case it's relevant, both machines use nvidia drivers built from the > > Debian nveidia-kernel-source package. > > > > On the 32-bit machine, we took inspiration from someone's advice on the > > net, and tried creating the /usr/include/X11 directory ourselves, since > > although x11-common complains about a missing symbolic link, it is > > apparently > > supposed to end up with a directory. But in this case it complains that > > /usr/include/X11 is not a symbolic link. > > > > If we re-create the symbolic link as it appears on other systems still > > using 6.9, it reports that the symbolic link does not exist, and when we > > check afterwards, the symbolic link has disappeared. > > I ran into this same sort of insanity today with the package. I was > finally able to get past it by: > > * Creating /usr/lib/X11 -> ../X11R6/lib/X11 > * Creating /usr/include/X11 -> ../X11R6/include/X11 > * Making sure that there was no reason for it to complain about > /usr/X11R6/bin, by a) removing or upgrading any package that installed > a file there and b) after all such packages were removed/upgraded, > moving any other files out of that directory. > * Finally, apt-get install xorg-common again. > > My bug reports (#371152 and #371161) have some more detail about why > it's breaking (and how it handles any breakage by hosing the system so > it can't be recovered except through the manual steps above) and transcripts > of some of what happens when trying to upgrade it. Ok, this is an extremely troubling bug. The previous x11-common's postinst gets called when the new x11-common's postinst fails with the /usr/bin/X11 switch. At this point, x11-common isn't shipping those symlinks and the previous x11-common's postinst fails because it requires that they're there. I'm not sure how we get to this situation to begin with, because in my own tests with upgrading x11-common with the /usr/bin/X11 error condition, I didn't hit this bug, so I'm not 100% sure I understand it fully. Now, the way around this that I can see is that the new postinst needs to manually re-create the symlinks prior to exiting during the error condition. This will allow the old version's postinst to complete properly. However, this creates a situation where we need to manually remove those symlinks later, causing more opportunities for problems. I'm trying to come up with a better way to do this, but I can't right now. Would someone be able and willing to test a fix if I can come up with one? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370149: FTBFS: not compatible with FreeType 2.2
On Sat, Jun 10, 2006 at 10:42:17PM +1000, Drew Parsons wrote: > > Yes, a new upstream version of the library was just released dealing with > > this issue. I'll be uploading it to unstable within a day or two hopefully. > > Hate to be a nuisance, but I hope you don't mean 1.1.0. > > This thread upstream makes me nervous... > http://lists.freedesktop.org/archives/xorg/2006-June/015891.html Yeah, I realized after I wrote the above that there was no fix. This is... bad. So I do have a patch that ejka tested a little bit that does build, but is known to cause regressions. I'd like to get this sorted out since no one has been attacking the problem upstream on the X.org side. I haven't checked the freetype side. Xfont currently has no upstream maintainer, so it's not likely to get fixed quite so soon. I may try and tackle it a bit over the next week but I also want to push forward with getting 7.1 in to experimental, as that's been lagging far too much. > Drew, > hoping you know something he doesn't know I wish... - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370149: FTBFS: not compatible with FreeType 2.2
On Sat, Jun 03, 2006 at 07:43:11PM +0200, Martin Michlmayr wrote: > Package: libxfont > Version: 1:1.0.0-4 > Severity: serious > > Your package fails to build in unstable with the following errors. > The changelog from xpdf (which had the same problem) will help you resolve > this issue: Yes, a new upstream version of the library was just released dealing with this issue. I'll be uploading it to unstable within a day or two hopefully. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367058: existing wrong ~/.gnupg/gpg-agent.conf prevents window manager from starting, X still runs
On Thu, Jun 01, 2006 at 02:55:31PM -0700, Steve Langasek wrote: > unmerge 367058 > reopen 367058 > reassign 367058 gnupg-agent > severity 367058 grave > thanks Thanks for doing this. > On Thu, Jun 01, 2006 at 10:50:08PM +0200, Adeodato Sim? wrote: > > severity 367058 wishlist > > reassign 367058 x11-common 6.8.2.dfsg.1-7 > > close 367058 1:7.0.19 > > merge 367058 331553 > > thanks > > > * Robin Haunschild [Sat, 13 May 2006 11:03:48 +0200]: > > > > Package: gnupg > > > Version: 1.4.3-1 > > > Severity: critical > > > Tags: security > > > Justification: breaks unrelated software > > > Hello Robin, > > > > An exsiting file ~/.gnupg/gpg-agent.conf that is syntactically wrong > > > disables the window manager from starting. The display manager and x.org > > > are still running. Even > > > $ startx /usr/bin/startfluxbox -- :1 > > > does not start a working Fluxbox. > > > This happened because the exit status of /etc/X11/Xsession.d/90gpg-agent > > was non-zero, and the script was executed from /etc/X11/Xsession, which > > runs with set -e, thus aborting the X11 startup process. > > > Some months ago, developer Eduard Bloch submitted a wishlist bug against > > x11-common, the package responsible for /etc/X11/Xsession*, asking that > > external scripts under set +e, so that failures to start like the one > > you experienced. > > > The bug was fixed in version 7.0.19 of x11-common (see #331553), so I'm > > merging your report with Eduard's, and marking it as closed, since the > > X11 startup process does not fail anymore even if an incorrect > > gpg-agent.conf is present. > > Well, I don't agree that the change to x11-common was a correct fix; we have > every reason to demand the same high quality of error handling for Xsession > scripts as we do for other scripts in Debian, which is undermined by this > casual use of set +e as a workaround. Isn't it reasonable to expect that I > may *want* a failed Xsession script to cause the session to abort? You may, but I think you're in the minority. I don't think a user who installs some rogue package with a broken script deserves to have the ability to log in to X ripped out from under them. It's the maintainer's job to ensure that the script works, and the user shouldn't have to suffer unnecessarily for mistakes. While I'm all for forcing devices to ensure quality, bringing down all of X because gpg-agent doesn't start is pretty extreme. > Either way, there is still a bug in gnupg-agent here; at most, the > x11-common workaround affects the severity of the gnupg-agent bug, but it's > still a gnupg-agent bug. And it's still a bug that would manifest when > installing gnupg-agent on a sarge system (partial upgrades), so it should > still be fixed. Indeed. If the change that I made is causing maintainers to divest themselves of responsibility for their packages, then I'll revert it, no questions. The goal is to protect users, not maintainers. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367339: fixed in xfonts-encodings 1:1.0.0-4
On Tue, May 16, 2006 at 12:12:08AM -0500, Steve Langasek wrote: > David, > > On Mon, May 15, 2006 at 09:32:09PM -0700, David Nusinow wrote: > >* Conflict with old versions of xfonts-base. Thanks Toni Mueller. > > (closes: #367339) > > Why is this file in the xfonts-encodings package, rather than in xfonts-base > given that all packages requiring the old encodings.dir have a dependency on > xfonts-base? > > If it does need to be in xfonts-encodings for some reason, this should > certainly be a Replaces: instead of a Conflicts:. So these encodings files were originally shipped in xfonts-base. The encodings.dir is just one of the files which would conflict, although with the new location I don't know if we'll actually see the other conflicts directly. I'm not sure why upstream decided to split the encodings out from the fonts, but I'd rather stick with their decision. We already violate this with the rgb database and the bundling of apps, so it's not a huge deal to merge xfonts-encodings back with xfonts-base, but I'm not sure what we'd gain by doing so. I think that the replaces line is probably the best option, so I'll make that change now. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362885: closed by David Nusinow <[EMAIL PROTECTED]> (Re: Bug#362885: x11-common: unable to upgrade, rmdir: /usr/X11R6/bin: Directory not empty)
On Mon, May 15, 2006 at 01:28:50PM +0200, Eduard Bloch wrote: > Indeed. AFAICS that is because the symlink is not part of the x11-common > package and is created on-the-fly. Another reason why the current > solution sucks. Ok, that's fair. Here's what I'll try to implement over the next few days (although real life promises to keep me busy for about another week, so if I don't get to it right away please be patient): 1) Move the /usr/X11R6/bin removal attempt to the preinstall 2) If the removal fails, tell the user via a debconf note and fail to install with an error 3) Ship the symlink as part of the package itself, using x11-common.links to have debhelper create it as it does the other symlinks in the package Are there any other major issues I'm missing? I know this doesn't automagically move user's files around to make this upgrade transparent, but I'd rather not break things out from under their noses if possible. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365875: No Text in Gtk widgets of xmms
On Wed, May 10, 2006 at 06:10:17PM -0700, Steve Langasek wrote: > On Sat, May 06, 2006 at 11:46:45AM +0530, Toufeeq Hussain wrote: > > > On 5/6/06, Steve Langasek <[EMAIL PROTECTED]> wrote: > > >On Fri, May 05, 2006 at 06:42:11PM +0530, Toufeeq Hussain wrote: > > >> >Ok. And do you still have font files installed under > > >> >/usr/X11R6/lib/X11/fonts/ ? Did you edit your xorg.conf by hand when > > >> >upgrading, or was it upgraded for you? > > > >> [EMAIL PROTECTED]:/usr/X11R6/lib/X11/fonts$ ls -al > > >> total 96 > > >> drwxr-xr-x 9 root root 4096 2006-04-19 13:53 . > > >> drwxr-xr-x 4 root root 4096 2006-05-03 11:20 .. > > >> drwxr-xr-x 2 root root 28672 2006-04-24 10:03 100dpi > > >> drwxr-xr-x 2 root root 28672 2006-04-24 10:03 75dpi > > >> drwxr-xr-x 3 root root 4096 2006-04-24 10:03 encodings > > >> -rw-r--r-- 1 root root 123 2006-04-24 05:57 fonts.cache-1 > > >> drwxr-xr-x 2 root root 12288 2006-04-24 10:03 misc > > >> drwxr-xr-x 2 root root 4096 2006-04-24 05:55 Speedo > > >> drwxr-xr-x 2 root root 4096 2006-04-24 15:03 Type1 > > >> drwxr-xr-x 2 root root 4096 2006-04-24 10:03 util > > > >Right, these are directories. I need to know whether you have font files > > >inside of any of them. > > > The directories 100dpi, 75dpi, misc, Speedo don't seem to have files in > > them. > > They only seen to contain the following files. > > > [EMAIL PROTECTED]:/usr/X11R6/lib/X11/fonts/100dpi$ ls > > encodings.dir fonts.alias fonts.cache-1 fonts.dir > > > Type1 however seems to have font files in it which are symlinks to > > /usr/share/fonts/type1. > > OK. I don't know if the Type1 fonts are the ones that your system is > looking for, but we should be able to figure that out as soon as > xserver-xorg 1:7.0.18 is available in unstable. The maintainer said he was > going to upload it two days ago, but there's no sign of it anywhere; cc:ed > to him to see what's going on. Currently waiting in NEW due to the xlibmesa-glu transitional package I added in. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366695: xserver-xorg-video-i810: Depends on unavailable xserver-xorg-core on etch.
reassign 366695 xdm merge 366695 366599 thanks On Wed, May 10, 2006 at 03:12:30PM +0200, Edward Welbourne wrote: > Package: xserver-xorg-video-i810 > Version: 1:1.5.1.0-2 > Severity: grave > Justification: renders package unusable > > > Due to a power outage, I had to re-boot my etch box after some months, > during which I'd updated it, so am now using the modern xserver-xorg-* > package fragments, where I was using a more monolithic xorg when last > I booted. When re-booted, I got no xdm up. > > Initially, this was because /etc/init.d/xdm referred to > /usr/bin/X11/xdm, which no longer exists. When I amended that, I > still got failure, since /etc/X11/default-display-manager had also > survived, and referred to the same xdm. Reverting the prior amend and > inserting a symlink in /usr/X11R6/bin/ solved those problems, so that > xdm at least *tried* to start up. > > It still failed, now saying that it couldn't make sense of the > hardware (I've had a very grim six hours since then, of trying to get > my machine back in an X-compatible state, without success, so don't > remember the exact wording; having now reverted to as close as I can > remember to that state, I lack the /usr/bin/X that xdm wants). Then I > remembered that xorg had recently gone into many-package form, so went > looking for a suitable xserver-xorg-video-* for the hardware reported > to me by lspci: > > :00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL > Express Chipset Family Graphics Controller (rev 04) > > It looks like the package I want is xserver-xorg-video-i810; but, when > I tried to install that, it was broken, because it depends on > xserver-xorg-core, which is not present in etch. So I can't actually > install this package to find out whether it really is what I need. > > There seems little point making a package available to testing when it > depends on a package unavailable to testing. > > Carving up a package into lots of little packages is a cool move, as > long as all hardware set-ups whose support has moved into one of those > packages are still catered to by a set-up on the branch (in this case > testing) on which the big package provided support before its demise. The drivers have been pushed in prematurely to testing without the modular server so as to ease the burden on the release team. Coordinating all this is a big problem, so every little bit helps. In short, what you need to do is remove all traces of the modular packages until the future, when an updated x11-common (after 1:7.0.0) and xserver-xorg-core reach testing. Remove the individual i810 driver package, since the xserver-xorg package in testing includes the driver you want. If it doesn't support your card, then use the vesa driver until a newer version of the driver reaches you properly with all that it needs. Second, the xdm bug is an actual bug in the dependencies that will only affect testing until the rest of X11R7 migrates. For that you'll just have to be patient. Use an alternate *dm or just use startx for the time being. We're working hard on getting all the pieces in to testing, but for now every part of the 6.9 release except for xdm will work just as it always has. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365353: missing debconf template: xserver-xorg/config/inputdevice/mouse/zaxismapping
On Tue, May 02, 2006 at 01:08:21PM +0300, Daniel Stone wrote: > On Mon, May 01, 2006 at 09:08:35PM -0400, David Nusinow wrote: > > On Sun, Apr 30, 2006 at 12:44:01AM -0700, Steve Langasek wrote: > > > On Sun, Apr 30, 2006 at 08:40:03AM +0200, Christian Perrier wrote: > > > > Quoting Adam Borowski ([EMAIL PROTECTED]): > > > > > The debconf question > > > > > xserver-xorg/config/inputdevice/mouse/zaxismapping > > > > > is needed by xserver-xorg's preinst, yet its template is missing. > > > > > Without > > > > > it, installation fails on new installs unless manually preseeded. > > > > > > > I grabbed this template back from the 6.9 branch, along with > > > > translations. > > > > > > > However, I'm not involved in X packages maintenance enough for knowing > > > > whether re-adding it is the way to go. > > > > > > > Please, XSF people, tell me if that is what needs to be done. If so, > > > > I'll apply my pending change. > > > > > > David added some code to the preinst which copes with the absence of the > > > template in question, but it seems to me that the code isn't useful *at > > > all* > > > if we're not going to use the template. Since the purpose of this code is > > > to convert the values for this question, and there are no other uses of > > > this > > > question in the config or postinst scripts, I think the correct solution > > > is > > > to simply drop this block of code from the config script. > > > > Right, I'm not really sure why Daniel removed the template in the ubuntu > > stuff. I'll look in to it and possibly add it back. Removing it will go > > well with my ultimate plan to dismember dexconf though, so that'll be my > > preference if it's something sensible. > > It was removed because the code in current X.Org servers should work > just fine without ZAxisMapping. Sweet! Let's just kill it then. I'll add some code to the postinst to remove the questions all together. Christian, let's just make it dead and give the translators a little rest :-) - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365353: missing debconf template: xserver-xorg/config/inputdevice/mouse/zaxismapping
On Sun, Apr 30, 2006 at 12:44:01AM -0700, Steve Langasek wrote: > On Sun, Apr 30, 2006 at 08:40:03AM +0200, Christian Perrier wrote: > > Quoting Adam Borowski ([EMAIL PROTECTED]): > > > Package: xserver-xorg > > > Version: 1:7.0.15 > > > Severity: grave > > > Justification: renders package uninstallable > > > > The debconf question xserver-xorg/config/inputdevice/mouse/zaxismapping > > > is needed by xserver-xorg's preinst, yet its template is missing. Without > > > it, installation fails on new installs unless manually preseeded. > > > I grabbed this template back from the 6.9 branch, along with > > translations. > > > However, I'm not involved in X packages maintenance enough for knowing > > whether re-adding it is the way to go. > > > Please, XSF people, tell me if that is what needs to be done. If so, > > I'll apply my pending change. > > David added some code to the preinst which copes with the absence of the > template in question, but it seems to me that the code isn't useful *at all* > if we're not going to use the template. Since the purpose of this code is > to convert the values for this question, and there are no other uses of this > question in the config or postinst scripts, I think the correct solution is > to simply drop this block of code from the config script. Right, I'm not really sure why Daniel removed the template in the ubuntu stuff. I'll look in to it and possibly add it back. Removing it will go well with my ultimate plan to dismember dexconf though, so that'll be my preference if it's something sensible. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363302: libx11-6: When migrating to X.Org 7, server says: "_X11TransOpen: Unable to find transport for local"
tags 363303 +unreproducible +moreinfo severity 363302 important thanks On Tue, Apr 18, 2006 at 01:21:02PM +0200, Tobias Diaz wrote: > Package: libx11-6 > Version: 6.9.0.dfsg.1-6 > Severity: grave > Justification: renders package unusable > > > When migrating to X.Org 7 in Debian unstable, X server report this error > and does not create the X-11 Socket. Xdm, kdm, gdm and startx stay frozen and > only a blank screen with X cursor is showed. > > If I install libx11-6 from Debian testing (X.Org 6.9) the problem is > solved. Do you have any sort of highly customized stuff on your system? Maybe an alternate kernel or customized packages? Also, is there any way you could get us a backtrace of this happening with debugging symbols? libx11 has a -dbg package for you to install, and that should be sufficient. It'd be nice to have a window on what's actualy going on, because this is incredibly bizarre. Finally, could you send us your /var/log/Xorg.0.log from when the server tries to start? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363169: x server will not start without xserver-xorg
retitle 363169 xserver-xorg gets removed by x11-common rather than upgraded thanks On Tue, Apr 18, 2006 at 10:36:30PM -0400, Jason Dorje Short wrote: > David Nusinow wrote: > >On Mon, Apr 17, 2006 at 07:39:50PM -0400, Jason Dorje Short wrote: > >>Package: xserver-xorg > >>Version: 1:7.0.14 > >>Severity: grave > >>Justification: renders package unusable > >> > >> > >>After an apt-get dist-upgrade today, the X server would no longer start. > >>Running "startx" gave no output, and when gdm refused to start up it gave > >>no error message. > >> > >>This was apparently solved when I thought to do "apt-get install > >>xserver-xorg". I did this just to make sure the package was up-to-date. > >>But when I ran it I found that xserver-xorg had not been installed at > >>all! After installing it, tthe X server and gdm now seemingly start up > >>correctly. > >> > >>This is probably not a bug in the xserver-xorg package per se. Most > >>likely it is a bug in another package that should, but does not, depend > >>on this package. However I didn't know where else to report it. > > > >What version of X did you have installed before? Did you upgrade from > >sarge? > > I originally installed debian testing on my machine a year ago, and > upgraded it to unstable then. I have been running unstable since. > > >>Also of interest is that when I ran reportbug it reported that my version > >>of xserver-xorg was more recent than that in debian. I'm not sure what > >>this could mean, except for the possibility that an older version has > >>been uploaded since I installed it (mere minutes ago). > > > >What version was installed before? > > How can I find out? Ok, I think I know what went wrong. x11-common conflicted with the xserver-xorg version you had installed, and this caused it to be removed and not reinstalled on upgrade even though the new version was available in the archive for installation. We need a way to ensure that it gets installed afterwards... - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363169: x server will not start without xserver-xorg
On Mon, Apr 17, 2006 at 07:39:50PM -0400, Jason Dorje Short wrote: > Package: xserver-xorg > Version: 1:7.0.14 > Severity: grave > Justification: renders package unusable > > > After an apt-get dist-upgrade today, the X server would no longer start. > Running "startx" gave no output, and when gdm refused to start up it gave > no error message. > > This was apparently solved when I thought to do "apt-get install > xserver-xorg". I did this just to make sure the package was up-to-date. > But when I ran it I found that xserver-xorg had not been installed at > all! After installing it, tthe X server and gdm now seemingly start up > correctly. > > This is probably not a bug in the xserver-xorg package per se. Most likely > it is a bug in another package that should, but does not, depend on this > package. However I didn't know where else to report it. What version of X did you have installed before? Did you upgrade from sarge? > Also of interest is that when I ran reportbug it reported that my version > of xserver-xorg was more recent than that in debian. I'm not sure what > this could mean, except for the possibility that an older version has > been uploaded since I installed it (mere minutes ago). What version was installed before? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362891: xserver-xorg: post-installation script fails during install
On Mon, Apr 17, 2006 at 10:55:27AM +0200, Daniele Venzano wrote: > On Sun, Apr 16, 2006 at 07:31:30PM -0700, Steve Langasek wrote: > > On Mon, Apr 17, 2006 at 03:25:55AM +0100, Stephen Gran wrote: > > > Did discover change behavior recently? > > > > Nope -- but xserver-xorg did, by just changing to accept discover as an > > (apparently untested) alternative to discover1. > > Well, I guess the correct call to discover should be: > > discover --disable-bus=all --enable-bus=pci --format="%V %M\t%S\t%D\n" video > > But that gives me: > > discover: Bus not found. > > and nothing else. The same happens even calling 'discover video', so I > think this is a discover problem and not one related to xorg. > > Installing discover1 solved the problem. I've fixed this problem by porting over the old discover_video function from the 6.9 branch. I didn't realize that it has been altered to remove support for discover2 in Ubuntu, and since I had only discover1 installed on my own system I never saw this error. I'll be uploading this fix shortly. Thanks again everyone. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362524: missing conflict on xearth
On Sun, Apr 16, 2006 at 06:03:15PM -0400, Steve M. Robbins wrote: > Hi David, > > I appreciate your prompt reply. I imagine you and the rest of the > X11-packaging team must be feeling a bit under fire at the moment. > I'd like to let you know that your efforts are greatly appreciated, > nonetheless. Thank you, I really appreciate that. > On Sun, Apr 16, 2006 at 05:47:43PM -0400, David Nusinow wrote: > > > The x11-common package provides a symlink from /usr/X11R6/bin to /usr/bin. > > This should handle your kdm problem. The package probably isn't fully > > installed on your system due to a bug or two that will be fixed pending > > another upload. Thanks for your report and your patience. > > OK. I did actually have x11-common installed. I removed the symlink > and ran dpkg-reconfigure x11-common and the link came back. Thanks > for this. > > By the way, the dpkg-reconfigure spit out the following error > > /var/lib/dpkg/info/x11-common.postinst: line 918: [: too many arguments > > [this is x11-common 7.0.12]. If this isn't part of the "bug or two" > that you are already aware of, you might want to have a look. Yeah, I've fixed that bug in svn and will be uploading it ASAP. Thanks again. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362524: missing conflict on xearth
On Sun, Apr 16, 2006 at 03:59:10PM -0400, Steve M. Robbins wrote: > After an upgrade to xorg 1:7.0.12, I was left with one file in > /usr/X11R6/bin: xearth. I subsequently discovered that xearth is > "non-free". Possibly you missed all the non-free package conflicts? > > > So I removed xearth, and /usr/X11R6/bin went away. X wouldn't start > because nothing could now be found in /usr/X11R6/bin. Kdm's config, > for example, contains the line > >ServerCmd=/usr/X11R6/bin/X -br > > but it isn't the only one. > > I ran "dpkg-reconfigure xorg", thinking it would install the symlink. > It didn't; I had to do so by hand. For the record: what is the proper > way to recover after cleaning out /usr/X11R6/bin? First off thanks for the note about xearth. I've added the conflict line. The x11-common package provides a symlink from /usr/X11R6/bin to /usr/bin. This should handle your kdm problem. The package probably isn't fully installed on your system due to a bug or two that will be fixed pending another upload. Thanks for your report and your patience. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362686: xbase-clients: Have a look at where startx is getting its xinitrc from
On Sun, Apr 16, 2006 at 12:44:31AM +0100, Paul Martin wrote: > Package: xbase-clients > Version: 1:7.0.0-3 > Followup-For: Bug #362686 > > A temporary fix is: > > ln -s /etc/X11/xinit/xinitrc ~/.xinitrc I think I've found the cause of this bug. The package doesn't actually seem to be getting patched, due to not having quilt in the build-depends. I'm making our patch system error out if this build-depends isn't in place and the patch target is called. That, and adding the build-depends to this package should fix the problem. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362524: Have the conflicting packages' maintainers been notified?
On Sat, Apr 15, 2006 at 11:40:38AM -0400, Steve M. Robbins wrote: > Hi, > > Today, "apt-get dselect-upgrade" wants to remove several packages, > e.g. "xfs", presumably due to new conflicts by xorg. > > I checked for a bug report on "xfs" and found none. Have all the > maintainers of newly-uninstallable packages been notified > about this change? > > Or should I file bug reports? If so, what is the fix: is a new > revision sufficient or does some action need to be taken? Not yet, the realization that it was a necessity kind of came on too fast for me. Actually, binNMU's for all the packages should, in theory, be sufficient for a fix. We'll be installing a compatibility symlink in place of /usr/X11R6/bin (to /usr/bin) and packages should be able to install cleanly. We just need to make sure they do so after x11-common sets that symlink up. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362233: xcursor-themes: symlinking default cursors makes xterm fail with BadRequest
On Wed, Apr 12, 2006 at 11:42:24PM +0200, Lukasz Pankowski wrote: > Package: xcursor-themes > Version: 1.0.1-2 > Severity: normal > > Hi, > > In 6.9 I used cursors from gtk2-engines-industrial (automagically). > After switching to Xorg 7.0 from experimental this stopped working and > I selected the cursor theme with one of [1] > > ln -s /usr/share/icons/whiteglass /usr/share/icons/default > ln -s /usr/share/icons/whiteglass ~/.icons/default > > This worked with Xorg 7.0 from experimental but many programs break > with Xorg 7.0 from unstable, xterm gives informative message: > > $ xterm > X Error of failed request: BadRequest (invalid request code or no such > operation) > Major opcode of failed request: 152 (XFIXES) > Minor opcode of failed request: 23 (XFixesSetCursorName) > Serial number of failed request: 27 > Current serial number in output stream: 28 > > Emacs and Gtk2 programs most notably GDM fail to start with a more > cryptic messages. > > The problem disappears after removing the `default' link, but the > curious thing is that it have worked before Xorg from experimental. Hi, could you try this again after the next dinstall? libxrender version 0.9.0.2-3 was uploaded and it should fix the problem. If so, I'd like confirmation so I can close this bug. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362049: libxfixes3: XFixesSetCursorName (no such operation)
On Wed, Apr 12, 2006 at 11:44:48AM +0200, Sven Hartge wrote: > Hi. > > I don't think this to be a bug of gtk-engines-industrial, because the same > error occurs, if you for example use the "whiteglass" theme, which is a > part of xlibs-data. > > The original submitter "fixed" this by removing gtk-engines-industrial, > because then the same thing happens as with my changes to the gconf-tree: > Gnome falls back to the default builtin cursor theme, which works without > problems. > > So to me this indeed looks like a bug somewhere inside X. Agreed. I'll close this when I upload my fix. Sorry about the noise. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362069: xbase-clients: xinit broken - X session doesn't start up
On Wed, Apr 12, 2006 at 02:07:21PM +0200, Florian Cramer wrote: > Am Dienstag, 11. April 2006 um 23:10:34 Uhr (-0400) schrieb David Nusinow: > > > This sounds like your /etc/init.d/x11-common script isn't correctly > > creating the necessary files to allow clients to connect to the server. Can > > you run "/etc/init.d/x11-common restart" and get no errors? > > Yes, thanks a million times - that fixed it, after I already had > purged all x.org-relevant configuration files and > reconfigured/reinstalled x.org from scratch, and still had the error. > [And then find out that I only could start an X session as root.] > > Maybe "/etc/init.d/x11-common restart" needs a run after package > installation in the postinstall script? It does do this, I'm not sure why it didn't for you. I'll investigate further... I'm glad this is the fix though. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362069: xbase-clients: xinit broken - X session doesn't start up
On Wed, Apr 12, 2006 at 03:58:00AM +0200, Florian Cramer wrote: > Package: xbase-clients > Version: 1:7.0.0-2 > Severity: grave > Justification: renders package unusable > > > After the upgrade to x.org 7.0.0 from 6.9.x, "startx" yields a default > grey X11 screen with a mouse pointer, but no window manager gets > started. ~/.xinitrc and /etc/alternatives/x-window-manager are not > honored. After a while, the X server crashes with the message that xinit > could start. > > Apparently, the X server does not permit any clients to run. This is the > tail output of /var/log/Xorg.0.log: > > > AUDIT: Wed Apr 12 03:52:53 2006: 9528 X: client 1 rejected from local > host > Auth name: XDM-AUTHORIZATION-1 ID: -1 > AUDIT: Wed Apr 12 03:52:55 2006: 9528 X: client 1 rejected from local > host > Auth name: XDM-AUTHORIZATION-1 ID: -1 > AUDIT: Wed Apr 12 03:52:57 2006: 9528 X: client 1 rejected from local > host > Auth name: XDM-AUTHORIZATION-1 ID: -1 > AUDIT: Wed Apr 12 03:52:59 2006: 9528 X: client 1 rejected from local > host > Auth name: XDM-AUTHORIZATION-1 ID: -1 > F > > [xdm was not used to start the X session.] This sounds like your /etc/init.d/x11-common script isn't correctly creating the necessary files to allow clients to connect to the server. Can you run "/etc/init.d/x11-common restart" and get no errors? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362049: libxfixes3: XFixesSetCursorName (no such operation)
reassign 362049 gtk-engines-industrial thanks On Tue, Apr 11, 2006 at 06:59:35PM -0400, Nick Lewycky wrote: > Package: libxfixes3 > Version: 1:3.0.1.2-2 > Severity: grave > Justification: renders package unusable > > After upgrading to X.org 7, I can no longer launch most X11 > programs. This includes xterm, xemacs, gnome-terminal, xmms, > etc. > > $ xterm > X Error of failed request: BadRequest (invalid request code or no such > operation) > Major opcode of failed request: 154 (XFIXES) > Minor opcode of failed request: 23 (XFixesSetCursorName) > Serial number of failed request: 24 > Current serial number in output stream: 25 > > xmms gives a different error message from the GDK, but > implicating the same major/minor. Ok, after discussing this bug with the submitter on IRC, he managed to fix it by removing gtk-engines-industrial. He says that the strace shows the apps are all looking for the Inustrial cursor theme. Reassigning the bug there. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358665: xft: Wrong dir for include directory.
On Thu, Mar 23, 2006 at 09:15:48PM +0100, Kurt Roeckx wrote: > On Thu, Mar 23, 2006 at 08:17:30PM +0100, Kurt Roeckx wrote: > > > > It seems you have moved the include files to: > > /usr/X11R6/include/Xft > > > > Which is wrong, and now everything that needs them is failing to > > build. > > > > It should be: > > /usr/X11R6/include/X11/Xft > > I've just NMU'd this, patch is attached. Great, thanks a ton for handling this! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358587: FTBFS on mips: No rule to make target `/usr/include/X11/Xft/Xft.h', needed by `do_text.o'.
On Thu, Mar 23, 2006 at 01:17:03PM +, Martin Michlmayr wrote: > * Michel Dänzer <[EMAIL PROTECTED]> [2006-03-23 13:51]: > > As I pointed out a while ago, I think libxft-dev needs to put the > > headers back into /usr/X11R6/include/ or depend on x11-common from > > experimental. > > Packages in unstable must not depend on packages in experimental. > > But, hey guys, just upload the experimental stuff to unstable. :-P I'd love to, but I want to make sure the current unstable version propagates to testing due to the security fix it contains. I've posted my plan for uploading already, and as soon as testing is more or less secure, I'm going to put the modular packages in unstable. - David Nusinow
Bug#351779: x.org r6 and r7 don't play nice together yet
On Sun, Mar 19, 2006 at 10:11:19PM +0100, Kurt Roeckx wrote: > On Sun, Mar 19, 2006 at 08:51:52PM +0100, Kurt Roeckx wrote: > > Atleast for xtrans-dev 1.0.0-2 this hasn't been fixed yet. Fix uploaded. > So do the following: > x11proto-core-dev I can't find this one. It's got a versioned dep on >= 1:1.0 > libxdmcp-dev Fix uploaded. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350458: Xft.h includes freetype headers, .pc file does not reflect this
On Sun, Feb 05, 2006 at 12:42:25PM -0500, David Nusinow wrote: > On Sun, Feb 05, 2006 at 04:59:25AM -0800, Steve Langasek wrote: > > tags 350458 patch > > thanks > > > > Attached is a patch to add the freetype cflags back into the xft.pc file. > > The previous patch was also apparently not tested for static linking, since > > it depended on variables that weren't defined anywhere in the .pc file... :) > > > > Let me know if you'd like an NMU for this bug. > > I have a fix sitting in svn for this bug which is almost identical. I > didn't add the freetypecflags variables to the .pc.in file because they're > already in xft-config.in, but other than that it's the same fix (courtesy > of Russ Albery). Will that be sufficient or do I need to put the variables > in xft.pc.in as well? > > I put preliminary packages up on people.debian.org/~dnusinow and I'm > waiting for Eric Dorland to confirm that it fixes the build issue with > firefox before I upload. Never mind. I just got confirmation that my fix is incomplete from Eric. I'll upload with your fix in a few minutes. Thanks for the patch! - David Nusinow, who's learning more about pkg-config every day -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350458: Xft.h includes freetype headers, .pc file does not reflect this
On Sun, Feb 05, 2006 at 04:59:25AM -0800, Steve Langasek wrote: > tags 350458 patch > thanks > > Attached is a patch to add the freetype cflags back into the xft.pc file. > The previous patch was also apparently not tested for static linking, since > it depended on variables that weren't defined anywhere in the .pc file... :) > > Let me know if you'd like an NMU for this bug. I have a fix sitting in svn for this bug which is almost identical. I didn't add the freetypecflags variables to the .pc.in file because they're already in xft-config.in, but other than that it's the same fix (courtesy of Russ Albery). Will that be sufficient or do I need to put the variables in xft.pc.in as well? I put preliminary packages up on people.debian.org/~dnusinow and I'm waiting for Eric Dorland to confirm that it fixes the build issue with firefox before I upload. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#211765: xserver-xorg: non-free OpenGL issue over 2 years old - any progress?
On Wed, Feb 01, 2006 at 06:25:19AM +0200, Martin-Éric Racine wrote: > I'm wondering whether there's been any resolution about how to handle > the OpenGL licensing issue? This RC bug, due to the non-DFSG status of > OpenGL, dates back from September 2003 already and it appears to be > the only thing preventing the transition of X.org 6.9 into Testing. None that I'm aware of but I haven't followed up on it myself. I'll see what I can find. fwiw, it'll be *very* unfortunate to not ship a GLX with etch. - David Nusinow
Bug#350066: Tellico FTBS, libkcal.la references libXft.la which does not exist anymore
On Thu, Jan 26, 2006 at 10:34:31PM -0800, Steve Langasek wrote: > On Fri, Jan 27, 2006 at 01:14:14AM +, Regis Boudin wrote: > > Package: kdepim > > Version: 3.5.0-5 > > Severity: grave > > > Trying to build a snapshot of tellico, it FTBS because of a > > missing /usr/lib/libXft.la file. I tried to rebuild the latest version > > of tellico with pbuilder, which also failed with the same error. > > > All the .la files from the kdepim dev packages > > reference /usr/lib/libXft.la, if the build was done with libxft-dev << > > 2.1.8. However, the file was removed last week with xft 2.1.8.2-1, > > making the packages linking against any of the kdepim libs FTBFS, hence > > the grave severity. > > i386 if affected, but some arches are not, such as i64. > > > I tried rebuilding kdepim and installing the generated packages, and I > > could successfully build tellico. > > > > I am not sure if the solution is to rebuild kdepim with the new xft, or > > include libXft.la back, so I CC the xft maintainer, but something needs > > to be done. > > Given that xft also supports pkg-config, AFAICT there's no specific reason > that libxft-dev should need to include libXft.la anymore. The important > thing is to know whether or not it's coming back, or whether we should > requeue kdepim for rebuilding. If it's as simple as a rebuild, then just requeue kdepim for rebuilding. >From what I understand, the .pc files are superior to .la files, although if I'm wrong someone should feel free to correct me. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349678: libxft-dev: pkg-config file says requires xproto that don't exist
tags 349678 + pending thanks On Tue, Jan 24, 2006 at 03:30:32PM +0100, Mike Hommey wrote: > Package: libxft-dev > Version: 2.1.8.2-1 > Severity: critical > Justification: breaks unrelated software > > The file /usr/lib/pkgconfig/xft.pc says xft requires xproto, which is > available in no package, as stated by apt-file. > > Even if it existed, there should be a dependency to the dev package > holding it. > > That breaks all packages that build depend on libxft and rely on > pkg-config to get the compilation and linking flags (such as mozilla, > thunderbird, firefox...). Ok, fixed in svn. I'll upload a new version soon. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347228: libxt6: Missing dependency on libx11-6.
On Mon, Jan 09, 2006 at 12:58:11PM -0800, Russ Allbery wrote: > David Nusinow <[EMAIL PROTECTED]> writes: > > > Cool, same fix. I'll apply and also restore DH_OPTIONS afterwards for > > cleanliness sake. Thank you! > > Restoring DH_OPTIONS afterwards is somewhat pointless given that each line > of a Makefile is run in its own separate shell. Good point, I'd forgotten about that. Eugene's fix as-is then. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347228: libxt6: Missing dependency on libx11-6.
On Mon, Jan 09, 2006 at 08:45:49PM +0100, Daniel Kobras wrote: > On Tue, Jan 10, 2006 at 01:27:52AM +0700, Eugene Konev wrote: > > Yep. Because it looks like dh_shlibdeps ignores -p switch: > > > > sh-3.00# DEBTREEDIR=$(pwd)/debian/tmp dh_shlibdeps -v -a -plibx11-6 > > -l$DEBTREEDI > > R/usr/lib -l$DEBTREEDIR/usr/X11R6/lib -- -Ldebian/libx11-6.shlibs.local > > LD_LIBRARY_PATH=/usr/X11R6/lib > > dpkg-shlibdeps -Tdebian/lbxproxy.substvars > > -Ldebian/libx11-6.shlibs.local debian/lbxproxy/usr/X11R6/bin/lbxproxy > (...) > > Err, no. And it doesn't ignore the -a switch, either, that tells it to > act on all arch-dependent packages. However, it might be that -Nlibdps1 > and -plibdps1 confuse dh_shlibdeps in debian/rules now that libdps1 has > been removed. Haven't done any testing, though. Either way, unsetting the -s and then re-setting it after we do dh_shlibdeps for libx11 can't hurt. If you're correct than I've already fixed the bug inadvertently :-) If Eugene is right, then we'll have that fix too. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347228: libxt6: Missing dependency on libx11-6.
On Tue, Jan 10, 2006 at 03:14:29AM +0700, Eugene Konev wrote: > > Quick hack to fix: > > --- xorg-x11-6.9.0.dfsg.1.orig/debian/rules 2006-01-10 03:11:40.0 > +0700 > +++ xorg-x11-6.9.0.dfsg.1/debian/rules2006-01-10 02:56:37.0 > +0700 > @@ -585,7 +585,7 @@ > chmod ug+s debian/xserver-common/usr/X11R6/bin/X > dh_installdeb > dh_shlibdeps -Nlibx11-6 -l$(DEBTREEDIR)/usr/lib > -l$(DEBTREEDIR)/usr/X11R6/lib --exclude=usr/X11R6/lib/modules > - dh_shlibdeps -plibx11-6 -l$(DEBTREEDIR)/usr/lib > -l$(DEBTREEDIR)/usr/X11R6/lib -- -Ldebian/libx11-6.shlibs.local > + unset DH_OPTIONS; dh_shlibdeps -plibx11-6 -l$(DEBTREEDIR)/usr/lib > -l$(DEBTREEDIR)/usr/X11R6/lib -- -Ldebian/libx11-6.shlibs.local > dh_gencontrol -- -VF:XWSC-Special-Depends=$(XWSC_SPECIAL_DEPENDS) \ >-VF:XWSD-Special-Depends=$(XWSD_SPECIAL_DEPENDS) > dh_md5sums Cool, same fix. I'll apply and also restore DH_OPTIONS afterwards for cleanliness sake. Thank you! - David Nusinow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347228: libxt6: Missing dependency on libx11-6.
On Tue, Jan 10, 2006 at 02:14:39AM +0700, Eugene Konev wrote: > > > Yep. Because it looks like dh_shlibdeps ignores -p switch: > > ... and this is exactly the same issue as the one with -dbg packages: -a > in DH_OPTIONS overrides -p. Ick. Ok, how about hacking around this by re-defining DH_OPTIONS to null prior to calling dh_shlibdeps for libx11, and then re-instating it back to -s after? Note that I can't find where the -a is explicitly set for us, so I'm assuming that -s has essentially the same bug. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347246: xorg-x11_6.9.0.dfsg.1-2(mipsel/unstable): FTBFS on mips and mipsel
On Mon, Jan 09, 2006 at 09:33:35AM -0800, Ryan Murray wrote: > Package: xorg-x11 > Version: 6.9.0.dfsg.1-2 > Severity: serious > > There was an error while trying to autobuild your package: > > > Automatic build of xorg-x11_6.9.0.dfsg.1-2 on mayer by sbuild/mipsel 79 > > Build started at 20060106-0905 > > [...] > > > ** Using build dependencies supplied by package: > > Build-Depends: bison, bsdmainutils, flex, fontconfig, groff, tetex-bin, > > libexpat1-dev | libexpat-dev, libfreetype6-dev, libglide2-dev (>> > > 2001.01.26) [i386], libglide3-dev (>= 2002.04.10-7) [alpha amd64 i386 > > ia64], libncurses5-dev | libncurses-dev, libselinux1-dev [!kfreebsd-i386 > > !hurd-i386], libpam0g-dev | libpam-dev, libpng12-dev | libpng-dev, > > libxcursor-dev, libxft-dev (>> 2.1.2), libxrender-dev (>> > > 1:0.9.0+CVS20050905), render-dev (>> 1:0.9+CVS20050905), zlib1g-dev | > > libz-dev, debhelper (>= 4.1.16), dpkg-dev (>= 1.10.14), > > linux-kernel-headers (>= 2.6.13+0rc3-1.1) [!hurd-i386 !netbsd-i386 > > !kfreebsd-i386], lynx, po-debconf, quilt, gcc-4.0 (>= 4.0.1-3) > > [...] > > > +usr/X11R6/man/man3/XcupGetReservedColormapEntries.3x > > +usr/X11R6/man/man3/XcupQueryVersion.3x > > +usr/X11R6/man/man3/XcupStoreColors.3x > > @@ -2437,0 +2458,5 @@ > > +usr/X11R6/man/man3/XevieEnd.3x > > +usr/X11R6/man/man3/XevieQueryVersion.3x > > +usr/X11R6/man/man3/XevieSelectInput.3x > > +usr/X11R6/man/man3/XevieSendEvent.3x > > +usr/X11R6/man/man3/XevieStart.3x > > @@ -2538,0 +2564 @@ > > +usr/X11R6/man/man3/XtAddWorkProc.3x > > @@ -3382,0 +3409 @@ > > +usr/X11R6/man/man4/sisusb.4x > > MANIFEST check failed; please see debian/README > > make: *** [stampdir/check-manifest] Error 1 > > A full build log can be found at: > http://buildd.debian.org/build.php?arch=mipsel&pkg=xorg-x11&ver=6.9.0.dfsg.1-2 > > manifest checks still fail for mips and mipsel. This causes xbase-clients to > be > uninstallable, so is holding up the KDE 3.5 transition, as kdelibs depends > on xbase-clients... Right, this is already fixed in svn. I'm polishing off the last bits for -3 and planning to upload it tomorrow. Basically #347228 is a last-minute surprise that's causing the holdup. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347228: libxt6: Missing dependency on libx11-6.
On Mon, Jan 09, 2006 at 04:22:04PM +0100, Daniel Kobras wrote: > (libxt-dev correctly depends on libx11-dev, but this bug can still lead to > build failures when dependencies in -dev packages are no longer recursively > expanded. Eg. build-depend on libaudio-dev, and linking with -laudio will > fail due to this problem.) Ok, and why would the dependencies not be recursively expanded? Is this a new change? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347228: libxt6: Missing dependency on libx11-6.
On Mon, Jan 09, 2006 at 04:22:04PM +0100, Daniel Kobras wrote:
> libXt from 6.9.0.dfsg.1-2 was linked with libX11, but this dependency is
> not reflected in the Depends: of the binary package:
>
> % ldd /usr/X11R6/lib/libXt.so.6
> linux-gate.so.1 => (0xe000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7ece000)
> libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7ec6000)
> libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7eaf000)
> libc.so.6 => /lib/tls/libc.so.6 (0xb7d78000)
> libdl.so.2 => /lib/tls/libdl.so.2 (0xb7d74000)
> /lib/ld-linux.so.2 (0x8000)
>
> but:
>
> % dpkg -s libxt6 | grep Depends
> Depends: libc6 (>= 2.3.5-1), libice6, libsm6, debconf (>= 0.5) | debconf-2.0
>
> The required dependency on libx11-6 is missing.
This is odd. Why doesn't ${shlibs:Depends} add this automatically like it
should? All these other deps are added correctly. Any clues from anyone?
- David Nusinow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345929: Problem with xserver-xorg_6.9.0.dfsg.1-1_i386.deb with ATI Technologies IncM22 [Radeon Mobility M300]
severity important thanks On Wed, Jan 04, 2006 at 11:47:32AM +0100, Yannick Beynet wrote: > Package: xserver-xorg > Version: 6.8.2.dfsg.1-11 > Severity: critical > Justification: breaks the whole system > > > > when I install xserver-xorg_6.8.2.dfsg.1-11_i386.deb, X work. So, X *does* work? If not, how does it fail to work? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340443: x11-common: Error in /etc/X11/Xsession - ksh users can't log in from KDM
On Wed, Nov 23, 2005 at 03:15:43PM +0100, January Weiner wrote: > Package: x11-common > Version: 6.8.2.dfsg.1-7 > Severity: grave > Tags: patch > Justification: renders package unusable Thanks for the fix. This is pending in svn and will go in to unstable later this weekend. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338715: xserver-xorg: file conflict with nvidia-glx
On Sat, Nov 12, 2005 at 08:07:12PM -0800, Steve Langasek wrote: > On Sun, Nov 13, 2005 at 11:03:13AM +1100, Daniel Stone wrote: > > libglx is an xorg module. It is originally provided by the XFree86 DDX. > > Some drivers feel the need to provide an alternate version, and that's > > great. But nvidia's is entirely specific to nvidia. xserver-xorg's > > works with all the drivers in xserver-xorg. > > > If xserver-xorg and nvidia-glx Replaces each other, as was the original > > suggestion in this thread, > > No, the suggestion was: > > Please add the necessary conflicts or replaces or whatever happens to be > appropriate in this case. > > I don't claim to know what the appropriate technical solution is. I am only > asserting that the current behavior on the part of xserver-xorg is incorrect, > per Debian policy and the RC bug policy for etch. Ok, I'm going to go with the conflicts line alone, no replaces. The replaces line may well break people's X installations because their xorg.conf will be set up to use the nvidia module rather than the built-in nv one, and thus X will fail to start for them. Simply conflicting will allow them to keep a working server until nvidia-glx is fixed. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337221: xserver-xorg: undefined colors render important apps unusable
severity 337221 normal thanks On Thu, Nov 03, 2005 at 05:48:58AM -0500, Antonio Rodríguez wrote: > Package: xserver-xorg > Version: 6.8.2.dfsg.1-10 > Severity: critical > Justification: breaks unrelated software No. This is not a critical bug, especially because with tons of successful upgrade reports you're the only one to have this problem. > After doing some research following the advice given in > http://lists.debian.org/debian-user/2005/11/msg00170.html > I discovered that the file /etc/X11/rgb.txt didn't exist > ls /etc/X11/rgb.txt > ls: /etc/X11/rgb.txt: No such file or directory > however, there was a symlink pointing to it > ls -l /usr/X11R6/lib/X11/rgb.txt > lrwxrwxrwx 1 root root 16 2005-11-01 20:11 /usr/X11R6/lib/X11/rgb.txt > -> /etc/X11/rgb.txt > > In the thread other people have reported to have the file rgb.txt > http://lists.debian.org/debian-user/2005/11/msg00247.html > > Perhaps the upgrade failed to install it, don't know exactly whats going > on. > > Versions of packages xserver-xorg depends on: > ii debconf [debconf-2.0]1.4.58 Debian configuration management > sy > ii libc62.3.5-7 GNU C Library: Shared libraries > an > ii libgcc1 1:4.0.2-3 GCC support library > ii libxau6 6.8.2.dfsg.1-10 X Authentication library > ii libxdmcp66.8.2.dfsg.1-10 X Display Manager Control > Protocol > ii xserver-common 6.8.2.dfsg.1-10 files and utilities common to > all > ii zlib1g 1:1.2.3-6 compression library - runtime > > Versions of packages xserver-xorg recommends: > ii discover11.7.15 hardware identification system > ii laptop-detect0.12.1 attempt to detect a laptop > ii mdetect 0.5.2.1 mouse device autodetection tool > ii xlibs6.8.2.dfsg.1-10 X Window System client libraries > m You *really* need to install x11-common, just like I told you the first time you asked us this question. I don't know why it wasn't installed for you, since it seems to have worked fine for everyone else. I assume that your libx11 wasn't upgraded either, since it depends on x11-common, but I have no idea why. Did you hold back any of the X libs or simply never upgrade them when going to sid? Do you still have sarge sources in your sources.list? Are you pinned incorrectly? There's a number of things that could have gone wrong here and I'm at a loss to figure them out, since this should have worked transparently. - David Nusinow
Bug#319298: Xorg segfaults on alpha due to unhandled relocations
On Wed, Jul 20, 2005 at 06:25:36PM -0700, Steve Langasek wrote: > The attached patch, which comes from upstream by way of Jay Estabrook > at HP, adds the necessary handling for the additional relocation type on > Alpha, fixing the latest segfault. As per the name, it should slip > right into the patches directory at #305; if you want to move it down to > #203 next to the other alpha reloc fix that it depends on, you'll have > to fix up the offsets in patch 303_arm_cache_flush.diff as well. Thanks, I will slip it in at #203 as soon as I can get all the patches fixed. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318218: Thoughts :-)
On Fri, Jul 15, 2005 at 02:13:35AM -0400, Nathanael Nerode wrote:
> This can probably be fixed by changing the following stanza from
> xc/programs/Xserver/hw/xfree86/common/compiler.h:
>
> # else /* !__alpha__ && !__powerpc__ && !__sparc__ */
>
> # define MMIO_IN8(base, offset) \
> *(volatile CARD8 *)(((CARD8*)(base)) + (offset))
> # define MMIO_IN16(base, offset) \
> *(volatile CARD16 *)(void *)(((CARD8*)(base)) + (offset))
> # define MMIO_IN32(base, offset) \
> *(volatile CARD32 *)(void *)(((CARD8*)(base)) + (offset))
> # define MMIO_OUT8(base, offset, val) \
> *(volatile CARD8 *)(((CARD8*)(base)) + (offset)) = (val)
> # define MMIO_OUT16(base, offset, val) \
> *(volatile CARD16 *)(void *)(((CARD8*)(base)) + (offset)) = (val)
> # define MMIO_OUT32(base, offset, val) \
> *(volatile CARD32 *)(void *)(((CARD8*)(base)) + (offset)) = (val)
>
> OK. The problem with this is that the cast to volatile CARD8* (et al)
> doesn't
> create a volatile object from the point of view of GCC4. (GCC4 may be wrong
> here.) However, code like the following, if I'm not mistaken, *does* create
> a volatile object, and GCC4 notices:
>
> static inline unsigned char
> xorgReadMmio8(volatile void * base, const unsigned long offset)
> {
> volatile CARD8 * tmp;
> tmp = (CARD8*)base + offset;
> return *tmp;
> }
> #define MMIO_IN8(base, offset) xorgReadMmio8(base, offset)
>
> (Based on a little testing of simplified code, GCC is smart enough to
> optimize
> away nearly everything in this, leaving nicely optimized assembly which still
> does the memory read, even when the resulting data is never accessed.)
>
> So a consistent replacement along these lines should do the trick.
> Shall I whip up a patch?
To be honest, I'd rather not mess with this file unless we have to. The
simple fix in Redhat's bugzilla looks a lot less invasive, and it seems to
fix all the reported problems so far, so I'd rather go with that unless
upstream says otherwise.
I'm making a patch for us right now.
- David Nusinow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316487: debian-installer-manual: Missing copyright credit: Karsten M. Self for section C.4
On Fri, Jul 01, 2005 at 12:36:14PM -0700, Karsten M. Self wrote: > This bug concerns appropriate copyright notice in the Debian Installer > Guide which adapts substantial material originally written by me. > > My license allows use under DFSG compliant guidelines, but requests > attribution. I initially requested attribution in May, 2003, a DIG > author admitted to using my work in writing this section of the DIG, but > requested I submit a patch (I'm not familiar with Debian's document > system and patches -- I'm not a DD). Ok, change committed. You are now attributed in the administrivia section. Thanks for the great doc. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
