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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544902: libdrm2 : /dev/dri not created
reassign 544902 fglrx-driver thanks Matt Olson wrote: Package: libdrm2 Version : 2.4.12-1 O.S. : Debian Testing Kernel : 2.6.30-1-amd64 After upgrading libdrm2 from version 2.3.1-2 to version 2.4.12-1, udev does not create /dev/dri. I am using ATI's Catalyst 9.8 driver for linux AMD64 (which gets loaded). (II) LoadModule: fglrx (II) Loading /usr/lib/xorg/modules/drivers//fglrx_drv.so (II) Module fglrx: vendor=FireGL - ATI Technologies Inc. compiled for 7.1.0, module version = 8.64.3 Module class: X.Org Video Driver The dri module also loads : Loading /usr/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor=X.Org Foundation compiled for 7.1.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading extension XFree86-DRI Reverting to libdrm2 2.3.1-2 fixes the problem. Thank you, Matt Olson We can't support closed-source drivers. Reassigning to the right package. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544969: dh_clean: Manpage clarification
Package: debhelper Version: 7.4.0 Severity: minor The dh_prep manpage description section doesn't really specify where it should be used in the rules file. Specifically, it says that acts to prepare for building a package. This could be interpreted as being prior to building the software, and thus should be run in the configure target, or prior to building the deb, in which case it belongs in the install target. Clarifying this would be helpful. - David Nusinow -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) 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 debhelper depends on: ii binutils 2.19.51.20090827-1 The GNU assembler, linker and bina ii dpkg-dev 1.15.3.1 Debian package development tools ii file 5.03-1 Determines file type using magic ii html2text 1.3.2a-14 advanced HTML to text converter ii man-db2.5.6-1on-line manual pager ii perl 5.10.0-25 Larry Wall's Practical Extraction ii perl-base 5.10.0-25 minimal Perl system ii po-debconf1.0.16 tool for managing templates file t debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 0.48 tool that converts source archives -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531295: libx11-6: warning: obsolete option '--print-installation-architecture'
fixed 531295 2:1.2.2-1 thanks Kurt Roeckx wrote: Package: libx11-6 Version: 2:1.2.1-1 Hi, I'm seeing this: Unpacking libx11-6 (from .../libx11-6_2%3a1.2.1-1_amd64.deb) ... dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead. I'm seeing this in almost every build log, and sbuild is sending me a separate mail with those warnings. So I would like it that that this gets fixed soon. This was fixed with the xsfbs merge in the last upload. Thanks for reporting it. - David Nusinow Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527920: please break circular dependency
Holger Levsen wrote: I'd be nice if you'd either given the number or even better, merged yourself. But thats bts-usage nitpicking and hardly worth saying :-) What's worth saying is, that you didnt give a reason for 396613 being marked wontfix here and that there is none in 396613. You dont even give a reason why there is this circular dependency which causes real problems for existing tools. Can you please explain?! Because these two packages do actually depend on each other to function. That's a hard dependency and there's no way around it. Ian Jackson has argued strenuously that circular dependencies are not a bad thing, and that dpkg handles them fine, and I'm in agreement with him. That said, the reason why xserver-xorg was split from xserver-xorg-core was to separate the very large and rapidly changing server config scripts from the server itself, allowing us to make rapid improvements to them with minimal stress to ourselves and our users. Now that those scripts are essentially gone, it's time to start thinking earnestly about reuniting them as xserver-xorg, and letting -core go away. This is *not* the same thing as removing the circular dependency, which is necessary and correct so long as these two packages exist despite whatever buggy tools. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524340: Reproducible GUI lockups
Hi Ray, J.H.M. Dassen (Ray) wrote: (==) intel(0): Using EXA for acceleration Could you try upgrading to kernel 2.6.29 and seeing if that helps? This should enable UXA rather than EXA by default, which has been reported to fix issues for some people, particularly with this new version. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524340: Reproducible GUI lockups
Sorry, in my last mail I forgot to mention that you have to enable KMS. You should be able to do that by adding i915.modeset=1 on the kernel command line. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524340: Reproducible GUI lockups
J.H.M. Dassen (Ray) wrote: Hello David, On Thu, Apr 16, 2009 at 10:40:14 -0400, David Nusinow wrote: J.H.M. Dassen (Ray) wrote: (==) intel(0): Using EXA for acceleration Could you try upgrading to kernel 2.6.29 and seeing if that helps? Actually, this was with 2.6.29.1 already. I'm building from source, with CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y Ok, great! On Thu, Apr 16, 2009 at 11:14:27 -0400, David Nusinow wrote: Sorry, in my last mail I forgot to mention that you have to enable KMS. You should be able to do that by adding i915.modeset=1 on the kernel command line. This doesn't seem to work: # dmesg | grep 915 Command line: root=/dev/mapper/Debsys-Root ro i915.modeset=1 Kernel command line: root=/dev/mapper/Debsys-Root ro i915.modeset=1 Unknown boot option `i915.modeset=1': ignoring [drm] Initialized i915 1.6.0 20080730 on minor 0 # egrep -i '(uxa|exa)' /var/log/Xorg.log (==) intel(0): Using EXA for acceleration (II) intel(0): Using exact sizes for initial modes (II) Loading sub module exa (II) LoadModule: exa (II) Loading /usr/lib/xorg/modules//libexa.so (II) Module exa: vendor=X.Org Foundation (WW) intel(0): DRI2 requires UXA (II) EXA(0): Offscreen pixmap area of 41287680 bytes (II) EXA(0): Driver registered support for the following operations: (II) intel(0): 0x0d8a-0x0fff: exa offscreen (40320 kB) That's a surprise. Could you try forcing UXA by adding 'option AccelMethod uxa' to the device section of your xorg.conf? - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513545: same problem
Ritesh Raj Sarraf wrote: Hi, I just upgraded to the new xserver in unstable and I have the same problem. Tapping and scrolling doesn't work. r...@champaran:~$ dpkg -l | grep xserver-xorg-input-synaptics ii xserver-xorg-input-synaptics 1.1.0-1 Synaptics TouchPad driver for X.Org server This bug report has 2 workarounds mentioned. One is about modifying the config file. I think that would not be recommended as X is supposed to move to a default config less setup. How about the 2nd one ? The hal fdi ? Should that be packaged ? How will this bug be fixed ? X is only supposed to move to a setup without config by default. If you need to customize it, as by enabling tapping, editing xorg.conf is a perfectly acceptable way to do it. If there wasn't supposed to be support for xorg.conf, we would have ripped out the code to handle it a long time ago. There isn't really a bug to be fixed here, just a changed default that people will have to configure by one method or another. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515214: Bug#523960: equivs is surely not the solution to this problem. Recommends: is.
Axel Beckert wrote: I really can't understand how someone can suggest to fake packages using equivs instead of using the Recommends: header as it's thought. The Policy says in 7.2 very clearly in all but unusual installations, so nobody can't use users who just want it work as argument. Debian's default is btw. to install recommended packages anyway. Another reason why users who just want it work are _no_ argument against using Recommends: header. Thank you so much for repeating exactly what other people have said. Given that the XSF must be collectively illterate, we didn't understand them the first dozen or so emails stating this, so the above was clearly necessary. X.org not only runs on fat workstations but also on embedded device where you as less abstraction layers and diskspace used as possible. Debian always claims to be the _universal_ operating system and it should also package X.org to be universal. Debian is not (a desktop focussed) Ubuntu. Note that this is the direction that upstream is heading in. The design is conceptually quite simple. The X server asks the system, in this case via hal, to enumerate input devices are present and gets them enumerated back. It then utilizes that hardware via the kernel rather than driving them itself with its own drivers. Note that this system was designed and implemented by a Nokia employee for an embedded system. It brings an enormous simplification to the overall operating system by putting things like keymaps in one place, and only having the kernel driving the hardware rather than both the kernel and the X server. It also makes it flexible with system changes, allowing hotplugging. Most importantly to Debian and the XSF, it means that we don't have to carry around a gigantic horrible bunch of shell script just to configure the system. All of this is a good thing. If you object to having the X server depend on external software, you're going to have to learn to like it, because the goal has been to decrease the amount of OS code that the server needs to duplicate in order to do its job. It no longer scans the PCI bus itself, but instead relies on libpciaccess to query the OS. It no longer carries its own build system, but relies on autotools. All of the video drivers are moving significant portions of themselves in to the kernel as well. If you can't deal with hal, then you'll have to write a replacement for it that allows the server to query the system in a transparent way, and also allows one to easily configure device-specific properties. This is something that hal currently does very well and the X server can not do otherwise. All of that said, it's very likely that we will downgrade the depends to recommends, just not right now. We have actual important bugs like totally broken installs that we want to deal with first. I herewith vote for demoting hal (#515214) and console-setup (#523960) to recommends. The BTS is not a voting system. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497523: NEWS?
Brice Goglin wrote: David actually wrote a NEWS entry about this yesterday: http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-synaptics.git;a=commitdiff;h=598ae3fe8592f80e97f58a1c54822754dcd5378e If anybody knows how to enable tapping at runtime with hal or xinput, we can add it as well. Additionally, if people who actually have and use synaptics could check the example in that entry and confirm that it works, I'd very much appreciate it. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497523: NEWS?
Nelson A. de Oliveira wrote: Hi! On Sun, Apr 12, 2009 at 9:42 AM, David Nusinow dnusi...@debian.org wrote: Brice Goglin wrote: David actually wrote a NEWS entry about this yesterday: http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-synaptics.git;a=commitdiff;h=598ae3fe8592f80e97f58a1c54822754dcd5378e If anybody knows how to enable tapping at runtime with hal or xinput, we can add it as well. Additionally, if people who actually have and use synaptics could check the example in that entry and confirm that it works, I'd very much appreciate it. Using Option TouchpadOff 2 didn't work here. I had to use this however: Option TapButton11 Option TapButton22 Option TapButton33 If there is something that I can do to help (sending logs, etc), please, just ask. Thank you! This is perfect, I've just updated the NEWS entry accordingly. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523834: RFP: naev -- 2d action/rpg space game
Package: wnpp Severity: wishlist * Package name: naev Version : 0.3.8 Upstream Author : Numerous. See AUTHORS in their tarball * URL : http://code.google.com/p/naev/ * License : GPL v3 Programming Lang: C, Lua Description : 2d action/rpg space game This builds just fine from the packages in unstable, and it appears to be a solid playable game even at this early version number. The data pack is published separately on their website, although it all appears to be available in the upstream git repository located at http://github.com/bobbens/naev/tree/master so the licensing and whatnot should be in order. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515214: [PATCH] hal depends - recommends
Here's a slight variant on the patch with much stronger wording in the
NEWS entry, and some more detail in debian/changelog. We want to be very
clear that we want people to use hal. I didn't go so far as to say that
not using hal won't be supported in the future, but I did try to get
across that the user is entirely responsible for their input
configuration if they choose not to use hal.
- David Nusinow
From 9e594116533cedccf273b216ccdce6585c9696bb Mon Sep 17 00:00:00 2001
From: David Nusinow dnusi...@debian.org
Date: Sun, 12 Apr 2009 19:31:26 -0400
Subject: [PATCH] Demote hal Depends: to Recommends:.
For that add a NEWS.Debian entry that people have to be careful on upgrades
to not lose their input devices (without hal it needs a config option).
Thanks Joerg Jaspert.
Require that this config option be set when hal is absent during postinst
---
debian/changelog|6 ++
debian/control |3 +--
debian/xserver-xorg.NEWS| 21 +
debian/xserver-xorg.postinst.in |4
4 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index bc0a3b5..5d4287e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,12 @@ xorg (1:7.4+2) UNRELEASED; urgency=low
* Don't discuss removal of xserver-xorg in its description.
It remains tied to -core at this point. (closes: #523630).
+
+ * Demote hal Depends: to Recommends:. For that add a NEWS.Debian entry
+that people have to be careful on upgrades to not lose their input
+devices (without hal it needs a config option). Thanks Joerg Jaspert.
++ Require that this config option be set when hal is absent during
+ postinst
-- Julien Cristau jcris...@debian.org Fri, 10 Apr 2009 14:12:51 +0100
diff --git a/debian/control b/debian/control
index 350ebb1..cc2b023 100644
--- a/debian/control
+++ b/debian/control
@@ -86,13 +86,12 @@ Depends:
xserver-xorg-input-evdev [alpha amd64 arm armeb armel hppa i386 ia64 lpia m32r m68k mips mipsel powerpc sparc],
xserver-xorg-video-all | xserver-xorg-video-5,
xserver-xorg-input-all | xserver-xorg-input-4,
- hal (= 0.5.12~git20090406),
console-setup (= 1.29),
${shlibs:Depends},
${misc:Depends},
xkb-data (= 1.4),
x11-xkb-utils
-Recommends: libgl1-mesa-dri, udev
+Recommends: libgl1-mesa-dri, udev, hal (= 0.5.12~git20090406)
Description: the X.Org X server
This package depends on the full suite of the server and drivers for the
X.Org X server, as well as providing a configuration infrastructure to manage
diff --git a/debian/xserver-xorg.NEWS b/debian/xserver-xorg.NEWS
index 6987bec..2221c53 100644
--- a/debian/xserver-xorg.NEWS
+++ b/debian/xserver-xorg.NEWS
@@ -1,3 +1,24 @@
+xserver-xorg (1:7.4+2) unstable; urgency=low
+
+ Starting with this release, hal is a recommended rather than
+ depended-upon package. This is because, although the X server
+ remains capable of configuring input devices without hal, it is
+ strongly recommended that you use this method unless there is a good
+ reason otherwise. Using hal provides the X server with the ability
+ to dynamically and correctly configure input devices while running,
+ and as a result it will be the best supported and most easily
+ maintained method of handling input devices for the forseeable
+ future.
+
+ If you choose to run your system without hal, you will have to take
+ all responsibility for manually configuring your input devices via
+ xorg.conf. To ensure working input devices for your X server when
+ hal is absent, add 'Option AutoAddDevices off' in the
+ ServerLayout section of your /etc/X11/xorg.conf (without the outer
+ '') and configure input devices as you did in the past.
+
+ -- David Nusinow dnusi...@debian.org Sun, 12 Apr 2009 19:24:09 -0400
+
xserver-xorg (1:7.4+1) unstable; urgency=low
Starting from this version, input devices are no longer configured
diff --git a/debian/xserver-xorg.postinst.in b/debian/xserver-xorg.postinst.in
index 7f75de2..be31457 100644
--- a/debian/xserver-xorg.postinst.in
+++ b/debian/xserver-xorg.postinst.in
@@ -270,6 +270,10 @@ fi
debug_echo Configuring $THIS_PACKAGE.
+if ! [ -x /usr/sbin/hald ] ! grep -q AutoAddDevices ${XORGCONFIG}; then
+bomb Please either install hal or configure your xorg.conf to work without, see NEWS entry for xserver-xorg version 1:7.4+2
+fi
+
if [ -n $FIRSTINST ] || [ -n $RECONFIGURE ]; then
# BusID
PRIORITY=low
--
1.6.2.2
Bug#523685: RM: xserver-xorg-video-cyrix -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal Hello, The xserver-xorg-video-cyrix is abandoned upstream and is considered dead. Please remove it from the archive for the next release. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523683: RM: xserver-xorg-video-imstt -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal Hello, The xserver-xorg-video-imstt driver is abaonded upstream and is considered dead. Please remove it from the archive for the next release. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523687: RM: xserver-xorg-video-vga -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal Hello, The xserver-xorg-video-vga driver is abandoned upstream and is considered supersceded by the -vesa driver. Please remove it from the archive. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444707: Working with upstream
Hello, I'm currently working alongside upstream on getting an updated parrot in to Debian. There's a pkg-parrot project on alioth that's a central point for this that I've recently been added to. Since Florian seems to have abandoned this package for some time now I also plan to take up maintainership of it. Florian, if this isn't Ok, please let me know and we'll work something out. As for the status of the Package, upstream (Allison Randal) has been hard at work on the packaging for Debian and Ubuntu. Currently there's a few lintian errors, most notably setting rpath in the binary, that need to be addressed prior to upload. There's also a number of missing manpages that need to be written, but those can probably wait until after the initial upload. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518295: GL_LINE_LOOP not rendered correctly
Brice Goglin wrote: reassign 518295 libgl1-mesa-dri 7.0.3-7 retitle 518295 GL_LINE_LOOP not rendered correctly on Radeon VE 7000 QY thank BALLABIO GERARDO wrote: Package: libgl1-mesa-glx Version: 7.0.3-7 After upgrading my home computer to Lenny I am observing a misbehavior of OpenGL programs, namely, whenever they should draw a GL_LINE_LOOP, the first and last segments of the line aren't drawn. I'm attaching a simple test program (compile with -lglut). The correct behavior would be to draw two nested white squares on a black background. Instead the outer square (drawn as a GL_LINE_STRIP with the start/end point repeated) is rendered correctly, but of the inner square (drawn as a GL_LINE_LOOP) only two segments are drawn. This problem seems to be specific of my hardware configuration, because I tried the same test program on another computer (with a Lenny live cd) and there it worked correctly. It is definitely a regression from Etch where it used to work also on my computer. My graphics card is rather old, it is a Radeon 7000. I'm using no proprietary drivers or nonstandard configurations, everything comes from the stock Lenny installation. I'm attaching the /var/log/Xorg.0.log file where I suppose you should find all the needed information. If you need more, please ask. I can't reproduce this with a Radeon X300 (rv370) so this is indeed probably a bug in the specific driver for your board (hence reassigning to libgl1-mesa-dri). Now it would be nice to try with mesa 7.3 (currently in experimental). I tried to reproduce this with a Radeon 9200 either (RV280). I am running mesa from experimental though, so this may have the necessary fix if my card is close enough to the 7000. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-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 dnusi...@debian.org 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-dist-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]
---BeginMessage--- On Thu, 19 Feb 2009 22:47:34 -0500 David Nusinow da...@gravitypulls.net 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#491629: tk8.5-dev: Package should depend on libxss-dev
Package: tk8.5-dev Version: 8.5.3-2 Severity: normal Hello, While converting one of my packages to tk8.5 and building in a chroot I got an FTBFS because libXss couldn't be found. This turned out to be included indirectly via tk8.5-dev's tkConfig.sh script located in /usr/share/tcltk/tk8.5. This is apparently a new addition with 8.5, because I can't find this inclusion in previous versions installed here. Could you please either add libxss-dev to the package's depends or remove the linking to libXss if it's inappropriate? My own package doesn't use Xss at all, so I don't know why the script exports this linker flag, and it may be ultimately useless. Thank you! - David Nusinow -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23-1-686 (SMP w/2 CPU cores) 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 tk8.5-dev depends on: ii libx11-dev2:1.1.4-2 X11 client-side library (developme ii tcl8.5-dev8.5.3-2Tcl (the Tool Command Language) v8 ii tk8.5 8.5.3-2Tk toolkit for Tcl and X11, v8.5 - ii x11proto-core-dev 7.0.12-1 X11 core wire protocol and auxilia tk8.5-dev recommends no packages. Versions of packages tk8.5-dev suggests: pn tk8.5-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476856: gnu-smalltalk-doc: Please include HTML documentation
Package: gnu-smalltalk-doc Version: 3.0.2-4 Severity: wishlist Hello, It would be nice if there were an HTML class reference available for gst. I personally like to have several tabs open when browsing documentation, and info makes this more annoying than a web browser. Since gst-blox isn't at the level of Omnibrowser in squeak, it's also not really as easy to deal with as a web browser. I don't know if including the html in this package or a separate one is the way to go, but I'd definitely appreciate having it available. Thanks for your work on gst! - David Nusinow -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23-1-686 (SMP w/2 CPU cores) 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 gnu-smalltalk-doc depends on: ii info [info-browser] 4.11.dfsg.1-4 Standalone GNU Info documentation ii konqueror [info-brow 4:3.5.9.dfsg.1-2+b1 KDE's advanced file manager, web b ii pinfo [info-browser] 0.6.9-2 An alternative info-file viewer gnu-smalltalk-doc recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468553: setting package to xdm, tagging 468553
# Automatically generated email from bts, devscripts version 2.10.18.1 # # xdm (1:1.1.6-5) UNRELEASED; urgency=low # # * Add Finnish translation, courtesy of Esko Arajärvi. closes: #468553 package xdm tags 468553 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468823: ITP: lxsession -- a lightweight X11 session manager
Hi, On Sun, Mar 02, 2008 at 01:19:50AM +0800, Andrew Lee wrote: Package: wnpp Severity: wishlist Owner: Andrew Lee [EMAIL PROTECTED] * Package name: lxsession Version : 0.3 Upstream Author : Hong Jen Yee(PCMan) [EMAIL PROTECTED] * URL : http://www.example.org/ * License : (GPL) Programming Lang: (C) Description : a lightweight X11 session manager LXSession is a lightweight X11 session manager with fewer dependencies, designed for use with the LXDE(Lightweight X11 Desktop Environment). . It's desktop-independent and can be used with any window manager. . As session manager it remembers the applications in use when you logout, and restart the applications when you log back in. What's the difference between this and xsm? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468823: ITP: lxsession -- a lightweight X11 session manager
On Sun, Mar 02, 2008 at 02:10:36AM +0800, Andrew Lee wrote: David Nusinow wrote: What's the difference between this and xsm? It well-integrated with LXDE and other modern desktop environments, the difference between this and xsm are: * Removed the session dialog from xsm. * Use better configuration. * Provide a nice logout-dialog with the ability to shutdown/reboot/suspend/hibernate via HAL or gdm, and more Even though it's based on xsm, but they are quite different. Make a diff between xsm and lxsession for detail, if there is any doubt. Coolness. The HAL stuff in particular sounds really awesome. Would you mind putting some (or all) of this in the description for the package when you upload it? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375460: Upgrade to linux kernel 2.6.17 makes Xserver crasing on startup
On Thu, Feb 28, 2008 at 01:55:16PM +0100, Julien Cristau wrote: found 375460 1:1.0.2-8 retitle 375460 server crash when the device configured as core pointer is a keyboard kthxbye On Fri, Jun 30, 2006 at 13:34:20 +0200, Marcel Sebek wrote: On Fri, Jun 30, 2006 at 12:44:45PM +0200, Michel Dänzer wrote: The backtrace looks input related, and indeed, looking at the log file, it looks like /dev/input/event1 no longer represents a mouse but a keyboard, so the X server ends up running without a core pointer and probably chokes on that. Yes, exactly. event1/2 is switched in the new kernel. The same happened to me once in the past, but IIRC the xserver printed some reasonable warning about missing core pointer, so I found that easily. I've created a simple udev rule and now have mouse on /dev/input/psmouse. I should have done it when I started using evdev interface. Should we consider this a configuration issue? It looks like input-hotplug, or using persistent device names, would prevent this kind of problems. It shouldn't be a configuration issue if it brings down the server. We should try and revisit this when we move the input-hotplug though, if that's what'll really fix it. - 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 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 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
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
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#462761: xorg-server: [INTL:ja] Update po-debconf template translation (ja.po)
tag 462761 +pending thanks On Sun, Jan 27, 2008 at 08:20:09PM +0900, Hideki Yamane (Debian-JP) wrote: Package: xorg-server Version: 2:1.4.1~git20080118-1 Severity: wishlist Tags: patch l10n -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear xorg-server maintainers, Here's updated Japanese po-debconf template (ja.po) file. Could you apply it, please? Done. It'll be in the next upload of the xserver. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458916: critical graphical bug during execution of tasksel
On Mon, Jan 07, 2008 at 04:39:22PM +0100, Frans Pop wrote: unmerge 449055 clone 449055 -1 reassign -1 xresprobe reassign 458916 xresprobe forcemerge 430545 -1 458916 retitle 449055 cdebconf: display corruption after running xresprobe (during pkgsel) block 449055 by 430545 thanks On Friday 04 January 2008, Colin Watson wrote: This looks like an extremely interesting variation on #449055. I'm merging your report with that one. Err, how so? Surely this is #430545 (xresprobe breaks display at the middle of installation). Additional testing has shown that both bugs are related to #430545, therefore reassigning appropriately. For the X Strike force: two more cases where running xresprobe during installation causes display corruption. Remi: could you provide some details of the system you saw this on? The output of 'lspci -nn' would be a good start. It shouldn't matter actually. We've just cut xresprobe out of the xserver postinst scripts, so this shouldn't be an issue. If it is an issue, he should file a bug against his specific driver. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454304: Transparency
On Sun, Jan 06, 2008 at 07:10:23PM +0100, Ties wrote: Ties wrote: Also, everything that's supposed to be transparent is now opaque. I hope I'm not double-posting this, but making sure the extmod module was loaded helped both my issues. For some reason dpkg-reconfigure xserver-xorg didn't generate a module section. Yeah, dpkg-reconfigure won't generate that section again for the forseeable future. So extmod wasn't loaded for you before? It should be loaded by default every time. What version of xserver-xorg-core are you running? Can you attach your /var/log/Xorg.0.log file? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411639: x11-common: Variables don't work outside of shells
On Mon, Dec 31, 2007 at 12:07:38PM +0100, Andre Colomb wrote: Package: x11-common Version: 1:7.3+9 Followup-For: Bug #411639 Hey, this is a very good idea. I've been trying to figure out a clean way to do this for quite some time. However, with the current solution, I'm stuck: I updated the package, created my .xsessionrc and put export LC_TIME=en_DK in there to have ISO 8601-dates everywhere. (German people still haven't realized that this is the new standard for over 10 years now, and Ulrich Drepper from Redhat apparently doesn't want to change the de_DE locale accordingly... whatever!) Anyway, I checked from inside an xterm shell (bash) if the variable was actually set, and there it was. Starting e.g. Icedove from the shell gave me the expected date format. Starting Icedove from the Xfce Panel, however, still has the old date format (en_US or C, whatever I set as system default). Is there maybe an incompatibility with the xfce4-session script or am I missing something else? Yeah, my guess is that this is some sort of weird xfce issue. Running an app from a launcher on the gnome panel shows that my test env variable is present. You may want to ask the xfce folks. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456955: laptops don't have keypads
On Tue, Dec 25, 2007 at 04:04:04AM +0800, [EMAIL PROTECTED] wrote: I also note Larry likes his laptop in 800x600 mode has now become an impossible task in Debian. And apparently one day when it becomes possible, it will only be via tortuous cut and paste of dangerous (to the heath of one's monitor, if the numbers get garbled) xrandr output into one's xorg.conf. Or one could use xrandr in ~/.xsession, adding more wear and tear to the monitor. Also then the user must pick a MHz choice. I picked 75 hoping that it won't wear out my monitor or my eyes but I am just guessing. I recall in the old days one could just dpkg-reconfigure and pick one's favorite resolution. Please stop trolling. We have a bug and we're working on transitioning to a new model of dealing with things. The work is incomplete, but then again so is Lenny. We're working on various solutions to make this far better than the old dpkg-reconfigure scripts, but you'll have to bear with it for a while. If you can't handle running software in development, please don't run unstable and save us all the hassle. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456798: gnumeric: Some failures when doing t-tests
On Wed, Dec 19, 2007 at 11:12:03AM +0100, J.H.M. Dassen (Ray) wrote: tags 456798 + pending thanks Hi David, On Mon, Dec 17, 2007 at 18:49:21 -0500, David Nusinow wrote: I've attached a patch that fixes this problem for the Observed Mean Difference when doing the paired t-test. I basically copied the way that the Pearson Correlation calculation was done. This issue has now been addressed upstream through http://svn.gnome.org/viewvc/gnumeric?view=revisionrevision=16244 which should make it into the forthcoming 1.8.0 release. Should you have further concerns or feedback regarding this issue, please use http://bugzilla.gnome.org/show_bug.cgi?id=504256 to communicate with upstream directly. As I'm not a statistics expert, I have little to add here. Wonderful, I applied the patch locally and was able to finish my work with it. Thanks to you and the gnumeric upstream for the quick response! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456955: laptops don't have keypads
On Thu, Dec 20, 2007 at 04:09:13AM +0800, [EMAIL PROTECTED] wrote: David, perhaps the difficulty I am having in bug #456955 is related to the below. Or maybe I just don't know how to write xorg.conf anymore. Thanks. [ David Nusinow ] * Don't write the default depth to xorg.conf any more. The drivers should choose the appropriate depth by default now. * Don't bother with resolutions in xorg.conf We now rely on the server and drivers to do the right thing. No, I believe these changes should not have an effect given your driver. Please use the xrandr utility or a suitable frontend to set your mode. In order to make this permanent, please use the PreferredMode stanza in your xorg.conf. See the xorg.conf manpage for details. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456955: laptops don't have keypads
On Mon, Dec 24, 2007 at 05:03:30AM +0800, [EMAIL PROTECTED] wrote: OK, the following indeed gets as I see logged e.g., (**) intel(0): Option PreferredMode 800x600 etc. but still I end up in 1024x768. Ok, that's broken and should be fixed. I'll try and take a look at it over the next couple of days... - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422085: Better terminal emulator patch
Hi Bastian, On Tue, Dec 18, 2007 at 12:47:39AM +0100, Bastian Venthur wrote: David Nusinow wrote: Hi Bastian, On Sun, Dec 16, 2007 at 11:39:03PM +0100, Bastian Venthur wrote: Hi David, thanks for your effort and the patches. Personally, I don't like the idea of a terminal popping up asking the user questions when a user uses a GUI application. Because the scripts can be interactive, I see no other way. Since the output of the bugscripts stuff is AFAIK still not mandatory for bugreports, I ask you do not upload this patch as NMU. May I ask why not? This is a really important feature for many developers and we'd like to see it in ASAP. - David Nusinow Since I received a terrifying amount insults(!) via mail for not implementing this feature request after my last blog entry, where I asked for help developing rng, I'd like to make my position about this issue clear. Why was I opposed to implement this. 1. I *personally* hated that some packages sent a *huge* amount of unrelated info with every bugreport for this package, even if it's not meaningful for this bugreport. I made a quick check against my favorite package with a very long output and thought (and still think) that this info is not even relevant for the majority of bugreports of this package. So I thought it was not too much to ask, to write the reporter a friendly mail to post the output of this script, if it's really needed. It is a great deal to ask when you've got a lot to do. You yourself are busy with real life, so much so that you're asking for help with rng. Well, the rest of us are plenty busy too, and these scripts can be a significant time saver for all of us, both developers and users. Refusing to support them is simply callous. Furthermore, your implementation allows the user to trivially delete all this information in their email client if they're annoyed by it, so this is a non-issue in rng. 2. I *personally* was very annoyed by packages with very long presubj text, which I doubt anyone reads anyway. Since I don't want rng to be annoying to the users, I decided to leave that feature away. An implementation of this feature would mean to pop up a window with some text the user should read before continuing to report the bug. I don't like popups and don't want rng to make use of them. I haven't implemented presubj text in my patch, so this is a non-issue for that specifically. 3. I'm definitely opposed to a feature which will pop up a *terminal* where a user has to do something before he can proceed reporting a bug. Sorry, but this won't happen in rng. I might consider such a thing if it could be scripted to use QT or even GTK but a terminal popping up in a GUI application is a no-go for me, sorry. For any script that is non-interactive the terminal will appear and then disappear once the script is done running. On my system it's barely noticeable. One thing that I'd be open to is modifying the standard so that scripts put something like #BUG_INTERACTIVE in the interactive scripts. We could trivially grep for this phrase, launch a terminal in this one case, or just run the script and get the output directly if this comment is absent. I don't know of any interactive bug scripts that currently exist, so this should be a fairly simple thing to require if people are willing (I've CC'ed -devel for opinions on this). 4. I was *personally* very annoyed by some of the reactions on this bugreport. Since we're all volunteers and stuff and this feature is maybe a nice-to-have but definitely not a must-have, I decided to put this issue very low on my to do list. However, I agree that the stuff in /usr/share/bug isn't completely useless. The opposite is true, it makes the life of maintainers easier and rng should make use of it where possible. So what can we do now? Maybe we can start all over and discuss this issue in a more friendly and constructive way? Here's my offer: rng will support bugscripts, but it will not feature a terminal popping up asking a user questions. I'm developing a GUI application and a popping up terminal is not very GUI'ish for me. What can we do about this? Is there a way to implement this? I've offered a partial solution for the terminal above. I think that neutering the interactive scripts is a horrific idea though. Users who can report bugs can handle having a terminal ask them a question or two. One alternate method is to require interactive scripts to use debconf, which should be a good middle ground because they've already used it during the install. We could check what frontend debconf is using, and if it requires a terminal we pop one up and if not then just let the gtk frontend do its thing. Again, this would be something other developers would have to agree to, but I think this is actually a better way to handle these sorts of scripts now that debconf is our standard for interaction. Supporting presubj might
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#422085: Patch
tags 422085 + patch thanks Package: reportbug-ng Version: 0.2007.10.31 Patch attached for this issue. Since reportbug-ng is now being pimped on planet Ubuntu I'd appreciate a quick upload with this patch before we get flooded with bugs from novice users.. If not, I'd appreciate a go-ahead to NMU it myself. Thanks! - David Nusinow --- System information. --- Architecture: i386 Kernel: Linux 2.6.21-1-686 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableuqm.debian.net 500 unstableftp.us.debian.org 500 stable apt.tt-solutions.com 1 experimentalftp.debian.org --- Package information. --- Depends (Version) | Installed =-+-=== python| 2.4.4-6 python-central (= 0.5.8) | 0.5.15 python-qt3| 3.17.3-3 python-soappy | 0.12.0-2 xdg-utils | 1.0.1-2 Index: reportbug-ng-0.2007.10.30/src/lib/ReportbugNG.py === --- reportbug-ng-0.2007.10.30.orig/src/lib/ReportbugNG.py 2007-12-08 16:30:51.0 -0500 +++ reportbug-ng-0.2007.10.30/src/lib/ReportbugNG.py 2007-12-08 16:30:58.0 -0500 @@ -87,6 +87,7 @@ s += getSystemInfo() + \n s += getDebianReleaseInfo() + \n s += getPackageInfo(package) + \n +s += getPackageScriptOutput(package) + \n return s @@ -311,6 +312,17 @@ return debinfo +def getPackageScriptOutput(package): +Runs the package's script in /usr/share/bug/packagename/script and + returns the output. +output = '' +path = /usr/share/bug/ + str(package) + /script +cmd = path + 31 +if os.path.exists(path): +output += --- Output from package bug script ---\n +output += commands.getoutput(cmd) +return output + def callBrowser(url): Calls an external Browser to upen the URL. @@ -334,4 +346,4 @@ status, output = commands.getstatusoutput(command) logger.debug(After the MUA call) - \ No newline at end of file +
Bug#452803: please add conflicts to new xorg
On Tue, Dec 04, 2007 at 04:51:32PM +0100, Julien Cristau wrote: On Mon, Dec 3, 2007 at 21:37:07 -0500, David Nusinow wrote: On Fri, Nov 30, 2007 at 04:01:43PM +0100, Holger Levsen wrote: Hi, On Friday 30 November 2007 13:28, Julien Cristau wrote: I don't understand what conflicting with xorg would achieve. IMO 915resolution should just be removed. right. So it's the other way round: xorg could conflict with it, so that users will notice. And 915resolution can be removed from unstable now. I'll leave it to the mainatiner to file a bug report requesting its removal or retitle and reassign this one. I've added a conflicts to the intel driver package, so this bug will close with the next upload of the driver. Thanks for letting us know. I'm not sure I get the point of the conflict. Keeping 915resolution installed does no harm, afaik. Users can notice they have an outdated package on upgrade and remove it whenever they want. Right, that's why I didn't add the conflict way back when, but we've seen our share of people who still think 915resolution is actually useful even when they're using -intel. I think a good, hard conflicts will disabuse them of that notion. I'm also thinking about adding a NEWS.Debian entry just to make it clear, and point them to the various online pages (intel's, Brice's blog, etc) that document how to cope with the change. With all the changes flying around lately we should probably be more proactive in telling people how to deal with them, and also helping them get there. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454263: xserver-xorg-input-vmmouse: vmmouse not used if specified in xorg.conf
On Tue, Dec 04, 2007 at 08:55:48PM +0100, Joerg Platte wrote: Am Dienstag, 4. Dezember 2007 schrieb Philipp Kolmann: Hi, I just installed a plain new Debian Sid in a vmware and wanted to change the mouse to vmmouse. But since the new X Server is in Sid, it doesn't take the vmmouse anymore. Section InputDevice Identifier Configured Mouse Driver vmmouse EndSection Try to add: Option CorePointer But then most likely your mouse pointer will not move... I just hit this bug myself today. I'll try to take a look at it this weekend. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452803: please add conflicts to new xorg
On Fri, Nov 30, 2007 at 04:01:43PM +0100, Holger Levsen wrote: Hi, On Friday 30 November 2007 13:28, Julien Cristau wrote: I don't understand what conflicting with xorg would achieve. IMO 915resolution should just be removed. right. So it's the other way round: xorg could conflict with it, so that users will notice. And 915resolution can be removed from unstable now. I'll leave it to the mainatiner to file a bug report requesting its removal or retitle and reassign this one. I've added a conflicts to the intel driver package, so this bug will close with the next upload of the driver. Thanks for letting us know. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430545: Corrupt display when installing packages
On Thu, Nov 29, 2007 at 10:25:28AM -0800, Bryce Harrington wrote: Hi David, We ran into this bug on Ubuntu (e.g. LP# 127008). The xprobe.sh script fails on Intel laptop hardware during configure when using the -intel driver. This cropped up after -intel driver support was added. I also fixed a number of other issues in xresprobe you might be interested in, although I know the goal is to get rid of xresprobe entirely. The two patches that fixed this for us are: http://people.ubuntu.com/~bryce/Testing/xresprobe/xresprobe_0.4.24ubuntu5.debdiff http://people.ubuntu.com/~bryce/Testing/xresprobe/xresprobe_0.4.24ubuntu8.debdiff Basically, we avoid using xprobe.sh for -intel. doddc probe seems to work adequately, and where it doesn't we just let the postinst ask the user (this is better than corrupting out the display). Cool, thanks. This pretty much makes sense, given that with -intel there's been the move away from asking the BIOS for the modes, which is what xresprobe seems to do if I'm reading it right. I'm trying to figure out if we can just dump xresprobe all together at this point. From my readings of the various bits that manage modesetting (and there's a lot, so I may well have missed some very important parts) the drivers will be doing their own ddc probe, which seems to make xresprobe redundant. I don't fully understand how DDC, VBE, and EDID all interact yet though, which may be a source of misunderstanding, but I can't see anything that xresprobe does that the drivers don't do themselves through the services that the server exposes. Randr1.2 drivers are even better of couse, especially because we can use the quirks to deal with issues that xresprobe would have been used for in the past. If I don't end up ripping out our reliance on xresprobe I'll definitely grab your fix, but hopefully we can just dump a whole lot of shell script instead. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452485: ITA: fetchyahoo
retitle 452485 ITA: fetchyahoo -- Retrieve mail from Yahoo!'s webmail service thanks Hi, I use fetchyahoo daily. I'll adopt it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448845: dpkg-reconfigure xserver-xorg fails
On Tue, Nov 27, 2007 at 10:14:14AM +, Philip Armstrong wrote: On Tue, Nov 27, 2007 at 09:48:54AM +, Philip Armstrong wrote: On Tue, Nov 27, 2007 at 08:44:47AM +0100, Brice Goglin wrote: Do you still have this problem with latest xserver-xorg? (1:7.3+6 is in unstable, 1:7.3+7 just got uploaded there too). Problem still exists with 1:7.3+6 : dexconf: error: cannot generate configuration file; xserver-xorg/config/device/driver not set. Aborting. Reconfigure the X server with dpkg-reconfigure to correct this problem. Also, the dpkg-reconfigure xserver-xorg process fails to detect my monitor (A Samsung Syncmaster 710T). Or at least I presume that it fails to do so: after the attempt at autodetection I end up being asked to give the full monitor specs regardless. The Xserver detects the monitor just fine as far as I can see from the logs. Should I file a separate bug? Looks like not all of 1:7.3+7 has arrived yet. I'll try it when it becomes available. OK, just done an update dragged in 1:7.3+7. Problem still exists. Just to test things, I tried removing the debconf config.dat cache file, so as to get all the defaults from the new package, but it didn't make any difference. Oh wait: I've found the problem! I didn't have discover installed (it was doing annoying things to my machine in the past) and this wasn't being picked up anywhere. Installing discover fixes the problem. Looks like the configuration needs to be aware of whether discover is installed or not, since it's currently a 'recommends' not a 'depends'. My main goal right now is getting rid of our reliance on discover in the postinst, so the fix for this bug will be to eventually remove all that code rather than a tighter dependency on discover. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453121: grandr: New Upstream Version
reassign 453121 gnome-randr-applet thanks On Wed, Nov 28, 2007 at 01:47:00AM +1100, James Healy wrote: Package: grandr Version: 0.1-2 Severity: wishlist It looks like there's a new upstream version of this applet (v0.4) @ http://dekorte.homeip.net/download/grandr-applet/ This is a different program, packaged as gnome-randr-applet. grandr appears to be dead upstream unfortunately. - David Nusinow -- 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#437528: should be able to have an xorg.conf with no ServerLayout, Device, or Screen
On Sun, Nov 18, 2007 at 06:42:40PM +0100, Brice Goglin wrote: If there is no xorg.conf at all, X automatically deduces default settings that work in a lot of cases (including my own). However, if there *is* an xorg.conf, but it does not contain ServerLayout, Device, or Screen sections, X refuses to start. It would be nice if, in this circumstance, the same defaults would be used that are currently used if there is no xorg.conf at all. Also, if I specify a Device or Screen section with the same name as one of the built-in sections that get dumped to Xorg.0.log but different contents, that should silently override *just that piece* of the built-in defaults. Hey David, Is the above possible now that you have merged a lot of stuff in the server autodetection code? Yes, I'd forgotten about this bug. This is fixed with ajax's work in 1.4, so it can be closed. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451876: xserver-xorg-core: screen mode selection error
On Mon, Nov 19, 2007 at 03:43:05AM +0100, Brice Goglin wrote: ale wrote: Package: xserver-xorg-core Version: 2:1.4.1~git20071117-1 Severity: normal Hello, I have a custom modeline 1400x1050 in my xorg.conf. However, after the last upgrade of xorg, this mode stopped working and even doesn't show up in xrandr. It seems the relevant portions of xorg.conf are not even read. I was just debugging a similar issue on IRC. The problem probably comes from: (**) |--Screen Default Screen (0) (**) | |--Monitor default monitor (==) No device specified for screen Default Screen. Using the first device section listed. (**) | |--Device Generic Video Card (==) No monitor specified for screen Default Screen. Using a default monitor configuration. This is wrong. There is no reason for these to appear when your config contains: Section Screen Identifier Default Screen Device Generic Video Card Monitor Generic Monitor You might be able to work around the problem by adding Option Monitor-VGA-0 Generic Monitor to your Device section (or Monitor-DVI-0 if the monitor is plugged on DVI). But this only works for RandR 1.2 drivers. I feel like all non-RandR 1.2 drivers are going to be broken (ignore the monitor section). We need David's input here since he added some patches for autoconfiguration. I'd like to push this bug upstream as soon as possible, but I'd rather be sure it's not our fault first :) Yeah, I think I know what the bug is. It's something I fixed upstream but forgot to bring back to Debian. I'll fix it tomorrow night. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451537: xserver-xorg: Can no longer scroll up/down with edge of touchpad
On Fri, Nov 16, 2007 at 06:06:58PM +, Sam Morris wrote: Package: xserver-xorg Version: 1:7.3+6 Severity: important After upgrading to xserver-xorg 7.3+6 and reconfiguring the package, I can no longer use the edge of my touchpad to send mouse wheel scroll events. Also the feel of the mouse acceleration has changed... it feels more slippery... but it is hard to quantify. :) snip Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc105 Option XkbLayout gb EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option Emulate3Buttons true EndSection Ok, this is most likely a result of not writing the synaptics section to your xorg.conf any more. We need to get input-hotplug working properly to detect this so it just works for you. I'll try and spend some time on this over the next week. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449089: xserver-xorg: Auto detection fails on Thinkpad X31
On Sun, Nov 04, 2007 at 07:03:39PM +0100, Moritz Muehlenhoff wrote: David Nusinow wrote: I've tested the auto detection code David asked for and ran into a bug: When I start X.org with the auto-generated config (I use startx, since I work on framebuffer console most of the time, on my notebook X11 is really just a slim layer beyond MPlayer) the screen remains black and the system doesn't take anymore input. (I can't switch to tty2 e.g.) The generated xorg.conf is included by the reportbug script, my previous one can be found on http://www.inutil.org/jmm/xorg.conf Please let me know if now need further information. snip Section Device Identifier ATI Technologies Inc Radeon Mobility M6 LY Driver ati BusID PCI:1:0:0 Option UseFBDev true EndSection It looks like in this config file you enabled fbdev while in the old one you didn't have this option set. Does the autogenerated config work when you remove that option or just say no to the question during dpkg-reocnfigure? Indeed, the auto-generated xorg.conf works if UseFBdev is not enabled. Does this indicate a bug in radeonfb, shall I report it to Linux kernel bugzilla? I don't remember if fbdev mode switches used to work in the past. Sorry it took me so long to get back to. You a quick glance at the code, this is most likely an xserver driver problem rather than a kernel problem. I'll double check to make sure, but I think the bug probably should remain here for now, possibly being forwarded upstream. Michel probably has a lot more insight to this bug than anyone else though. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308073: vim-vimoutliner: Additional Info
Package: vim-vimoutliner Version: 0.3.4-8 Followup-For: Bug #308073 Hi Martin, This bug can sort of be closed, as the menu items are in place in gvim. However, they're not working right now although the fix is simple. In the ftplugin/vo_base.vim file, it tries to call otl2html.py, although this script is shipped without the .py suffix. Just edit vo_base.vim to not have the .py and it works great. With that, this bug should be closed. - David Nusinow -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-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 vim-vimoutliner depends on: ii libpalm-perl 1.3.0-6 Perl 5 modules for manipulating pd ii libxml-writer-perl 0.603-1 Perl module for writing XML docume ii perl 5.8.8-11.1 Larry Wall's Practical Extraction ii python 2.4.4-6 An interactive high-level object-o ii vim 1:7.1-138+1 Vi IMproved - enhanced vi editor ii vim-gnome [gvim] 1:7.1-138+1 Vi IMproved - enhanced vi editor - ii vim-gtk [gvim] 1:7.1-138+1 Vi IMproved - enhanced vi editor - ii vim-python [gvim]1:7.1-138+1 Vi IMproved - enhanced vi editor ( ii vim-ruby [gvim] 1:7.1-138+1 Vi IMproved - enhanced vi editor ( vim-vimoutliner recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450584: xserver-xorg: This package forces all video drivers, pointless on laptops
On Thu, Nov 08, 2007 at 12:15:35PM +0100, Helge Hafting wrote: I have a laptop, so I don't want to have every video driver on it. The card won't change. But xserver-xorg depends on xserver-xorg-video-all which brings in all drivers. The obvious solution is to get rid of xserver-xorg, but this is strongly discouraged according to apt-cache show xserver-xorg. To follow up, the server depends on xserver-xorg-all | xserver-xorg-video(-2). Any packaged driver from Debian will fulfill the latter requirement, allowing you to install the server with just a single driver. The -all package is the default though to ensure that everyone has the right driver if we can provide it. If you want to work on getting just the individual driver necessary for the machine installed, it's something I'm interested in working on, so feel free to help out there if this is something you want to see happen. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448944: xserver-xorg: does not generate xorg.conf file suitable for dual head
On Thu, Nov 01, 2007 at 08:44:14PM +0100, Marc Haber wrote: Package: xserver-xorg Version: 1:7.3+3 Severity: minor Hi, the procedure outlined by David in http://gravityboy.livejournal.com/38665.html does not result in a configuration that is suitable for dual head use: I get both screens cloned, and my usual xrandr gymnastics[1] to get them both alongside each other does not work. Yeah, the debconfage never supported creating dual monitors and there's no plans to make this happen. What will ideally work in the end is to not have any sort of configuration for this setup in your xorg.conf, and just let the server detect it and set it up for you. I don't believe the current code does this though, but I may be able to make it happen in the future. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449160: Does not support X1300
On Fri, Nov 02, 2007 at 10:13:21AM -0700, Matt Kraai wrote: Package: xserver-xorg-video-radeonhd Version: 0.0.1+git20071006-1 Tags: fixed-upstream In http://lists.opensuse.org/radeonhd/2007-11/msg00017.html Benoit Plessis reports that the Debian version of the radeonhd driver does not support the X1300, but the latest upstream version does. I actually tried to build git head on Thursday night or so for this exact reason, but it ftbfs for some reason that I couldn't really determine at the time. I'll try again in a few days when I've got some time. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449089: xserver-xorg: Auto detection fails on Thinkpad X31
Hi Moritz, On Fri, Nov 02, 2007 at 11:17:32PM +0100, Moritz Muehlenhoff wrote: Package: xserver-xorg Version: 1:7.3+3 Severity: important I've tested the auto detection code David asked for and ran into a bug: When I start X.org with the auto-generated config (I use startx, since I work on framebuffer console most of the time, on my notebook X11 is really just a slim layer beyond MPlayer) the screen remains black and the system doesn't take anymore input. (I can't switch to tty2 e.g.) The generated xorg.conf is included by the reportbug script, my previous one can be found on http://www.inutil.org/jmm/xorg.conf Please let me know if now need further information. snip Section Device Identifier ATI Technologies Inc Radeon Mobility M6 LY Driver ati BusID PCI:1:0:0 Option UseFBDev true EndSection It looks like in this config file you enabled fbdev while in the old one you didn't have this option set. Does the autogenerated config work when you remove that option or just say no to the question during dpkg-reocnfigure? - 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#446441: xserver-xorg: The problem is in regexp
On Fri, Oct 19, 2007 at 09:44:03AM +0900, Michal Čihař wrote: Package: xserver-xorg Version: 1:7.3+2 Followup-For: Bug #446441 The fix for this is simple: Just add underscore to grepping for radeon in acquiring DRIVER_LIST. So doing s/|radeon|/|radeon_|/ in postints fixes this issue. This part of the debconfage is going away when I get a chance to figure out what to do about sparc. In the future, you won't even bother to write this section to your xorg.conf unless you want to override the default, as it'll just load the right driver by default. The server and drivers in unstable can already do this. I did add a patch for some pci id's to radeonhd to do this too, although I don't think it's complete. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446851: xserver-xorg-core: please copy (and improve) x11-input.fdi to /etc/hal/fdi/policy/
reassign 446851 hal retitle 446851 Please package new upstream version which includes x11-input.fdi thanks On Thu, Oct 18, 2007 at 09:45:11AM +0200, Michel Dänzer wrote: On Wed, 2007-10-17 at 19:16 -0400, David Nusinow wrote: On Wed, Oct 17, 2007 at 09:46:54AM -0700, Warren Turkal wrote: On 10/17/07, Daniel Stone [EMAIL PROTECTED] wrote: Because it's not clearly in the domain of Xorg. x11-input makes sense, but then again, it's largely a system decision. OTOH, XKB can be used in the console, not just in X (hence why it's namespaced input.xkb and not input.x11.xkb or so), so that's why. Okay...so it's the domain of xkb? Even in that case, it seems there is a more appropriate place for it than hal. Also, as Michel mentions, everything else is already in hal-info, so eh. The latest release includes it, AIUI. Well, I really don't care where it comes from, as long as it's included. I think including it in our package until HAL gets it is probably the right move. More package churn on the server is probably going to be a fact of life for a while anyway. The reason I haven't really put much work in to input hotplug is because I've been focused on getting output autodetection in better shape. Once that's done, I'll get to this if no one else beats me to it. I think it would be better to listen to upstream and reassign this to hal-info... Ok, Daniel's message didn't hit my inbox for some reason, so I just saw the bit about it being in the new hal version. I'm reassigning this to hal since it looks like all the .fdi files that hal itself ships belong to that package, and x11-input.fdi is in that category. Sjoerd can reassign it if I got it wrong. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446441: xserver-xorg: The problem is in regexp
On Fri, Oct 19, 2007 at 10:54:54AM +0900, Michal Čihař wrote: Hi On Thu, 18 Oct 2007 21:19:02 -0400 David Nusinow [EMAIL PROTECTED] wrote: This part of the debconfage is going away when I get a chance to figure out what to do about sparc. In the future, you won't even bother to write this section to your xorg.conf unless you want to override the default, as it'll just load the right driver by default. The server and drivers in unstable can already do this. I did add a patch for some pci id's to radeonhd to do this too, although I don't think it's complete. You're right, it seems to work without specifying driver in config (I had to rebuild radeonhd from git anyway...). However as long as the debconf code is there, it should list all drivers. (I have no idea when you except to drop this debconf code, but it is far away, I think it should be fixed). Well, basically I'm telling you that the right fix at this point is to drop it. Again, sparc is really the only thing holding it back. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446851: xserver-xorg-core: please copy (and improve) x11-input.fdi to /etc/hal/fdi/policy/
On Wed, Oct 17, 2007 at 09:46:54AM -0700, Warren Turkal wrote: On 10/17/07, Daniel Stone [EMAIL PROTECTED] wrote: Because it's not clearly in the domain of Xorg. x11-input makes sense, but then again, it's largely a system decision. OTOH, XKB can be used in the console, not just in X (hence why it's namespaced input.xkb and not input.x11.xkb or so), so that's why. Okay...so it's the domain of xkb? Even in that case, it seems there is a more appropriate place for it than hal. Also, as Michel mentions, everything else is already in hal-info, so eh. The latest release includes it, AIUI. Well, I really don't care where it comes from, as long as it's included. I think including it in our package until HAL gets it is probably the right move. More package churn on the server is probably going to be a fact of life for a while anyway. The reason I haven't really put much work in to input hotplug is because I've been focused on getting output autodetection in better shape. Once that's done, I'll get to this if no one else beats me to it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446851: xserver-xorg-core: please copy (and improve) x11-input.fdi to /etc/hal/fdi/policy/
On Wed, Oct 17, 2007 at 04:45:20PM -0700, Warren Turkal wrote: On 10/17/07, David Nusinow [EMAIL PROTECTED] wrote: I think including it in our package until HAL gets it is probably the right move. More package churn on the server is probably going to be a fact of life for a while anyway. The reason I haven't really put much work in to input hotplug is because I've been focused on getting output autodetection in better shape. Once that's done, I'll get to this if no one else beats me to it. Output hotplug on Intel 915 is pretty terrible right now. It doesn't appear to probe the connected monitor for the supported modes. However, starting Xorg with the monitor attached works like a charm. If you could open that as another bug, that'd be much preferrable to discussing it in this one. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445331: quodlibet: Broken cover files break the cover scan in album browser
Package: quodlibet Version: 1.0-1 Severity: minor Hello, Using quodlibet with the album view I found that only a fraction of the album covers would display in the sidebar. The covers had no trouble displaying in the upper right corner when the song played though. It turned out that I had some directories where the .folder.jpg file was a broken symlink to central cover image. The broken symlink caused quodlibet to stop scanning and loading the cover images. Removing these broken symlinks fixed the problem. The app should be able to simply skip over these broken cover images and load the remainder. - David Nusinow -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/2 CPU cores) 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 quodlibet depends on: ii exfalso 1.0-1 audio tag editor for GTK+ ii gstreamer0.10-plugins-base0.10.14-4 GStreamer plugins from the base ii gstreamer0.10-plugins-good0.10.6-3 GStreamer plugins from the good ii gstreamer0.10-plugins-ugly0.10.6-2 GStreamer plugins from the ugly ii python2.4.4-6An interactive high-level object-o ii python-central0.5.15 register and build utility for Pyt ii python-gst0.100.10.8-1 generic media-playing framework (P Versions of packages quodlibet recommends: ii gstreamer0.10-alsa0.10.14-4 GStreamer plugin for ALSA ii gstreamer0.10-gnomevfs0.10.14-4 GStreamer plugin for GnomeVFS pn python-feedparser none (no description available) ii quodlibet-ext 1.0-1 extensions for the Quod Libet audi -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444788: xserver-xorg-dev: Does not install DESIGN document
Package: xserver-xorg-dev Version: 2:1.4-3 Severity: minor We should really be installing the DESIGN document in hw/xfree86/doc/sgml, as well as any other docs in hw/xfree86/doc that aren't being installed. - David Nusinow -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/2 CPU cores) 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 xserver-xorg-dev depends on: ii libpixman-1-dev 0.9.5-2pixel-manipulation library for X a ii x11proto-core-dev 7.0.11-1 X11 core wire protocol and auxilia ii x11proto-fonts-dev2.0.2-5X11 font extension wire protocol ii x11proto-input-dev1.4.2-1X11 Input extension wire protocol ii x11proto-randr-dev1.2.1-2X11 RandR extension wire protocol ii x11proto-render-dev 2:0.9.3-2 X11 Render extension wire protocol ii x11proto-video-dev2.2.2-4X11 Video extension wire protocol ii x11proto-xext-dev 7.0.2-5X11 various extension wire protoco xserver-xorg-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444203: xserver-xorg-core: EXA greedy mode is broken on 2:1.4-2 is broken
On Wed, Sep 26, 2007 at 11:00:37PM +0200, Brice Goglin wrote: forwarded 444203 https://bugs.freedesktop.org/show_bug.cgi?id=12520 thank you matthieu castet wrote: when using EXA greedy mode, there corruption on mozilla (see attached screenshot). I am wondering: IIRC, greedy isn't the default, what's the point of using it instead of the default? (II) NOUVEAU driver Date: Thu Sep 20 08:29:43 2007 +1000 So nouveau really works? Great. (II) Loading sub module dri (II) LoadModule: dri (II) Reloading /usr/lib/xorg/modules/extensions//libdri.so (II) NOUVEAU(0): Loaded DRI module drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) NOUVEAU(0): [dri] Found DRI library version 1.3.0 and kernel module version 0.0.10 And you really get DRI? We should really package this driver... It's almost finished on my machine. Maybe tonight... - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442892: dpkg-reconfigure xserver-xorg is useless without discover installed
On Mon, Sep 17, 2007 at 07:36:18PM +0200, Mike Hommey wrote: Package: xserver-xorg Version: 1:7.3+2 Severity: important Hi, I recently upgraded my x.org server in sid, and, after upgrade, the X server would not work. But this is another issue I will try to understand at another time. Anyways, the thing is, since my conf was not working, I wanted to try to dpkg-reconfigure xserver-xorg, which I would assume to work, but didn't in my case, because discover was not installed. Here is the message I get after reconfiguring when discover is not installed: xserver-xorg postinst warning: overwriting possibly-customised configuration file; backup in /etc/X11/xorg.conf.20070917193443 dexconf: error: cannot generate configuration file; xserver-xorg/config/device/driver not set. Aborting. Reconfigure the X server with dpkg-reconfigure xserver-xorg to correct this problem. xserver-xorg postinst warning: error while preparing new Xorg X server configuration file in /etc/X11/xorg.conf.dpkg-new; not attempting to update existing configuration Note that /etc/X11/xorg.conf.dpkg-new doesn't even exist after this, and that I never get asked what driver to use. After installing discover, everything works fine. Discover is going away from the scripts very soon. The updates from yesterday are what will finally permit that. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438578: xorg-server: [INTL:sk] Slovak po-debconf translation
On Sun, Aug 26, 2007 at 11:42:45AM +0200, Christian Perrier wrote: Quoting helix84 ([EMAIL PROTECTED]): Package: xorg-server Version: 2:3a1.3.0.0.dfsg-12 Priority: wishlist Tags: l10n patch .po attached I'd be happy to commit this somewhere but I indeed have no idea of what branch I should checkout for the xorg-server package. Right now, debian-experimental would be the right branch. I'm pretty sure we're done with debian-unstable until after the 7.3 release. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438578: xorg-server: [INTL:sk] Slovak po-debconf translation
On Sun, Aug 26, 2007 at 08:19:23PM +0200, Christian Perrier wrote: .po attached I'd be happy to commit this somewhere but I indeed have no idea of what branch I should checkout for the xorg-server package. Right now, debian-experimental would be the right branch. I'm pretty sure we're done with debian-unstable until after the 7.3 release. Ah, well, Julien gave me the opposite advice and I committed to debian-unstable, I'm afraid. Actually, when it comes to debconf l10n, I'd prefer not having to jump from one branch to another. If that's needed, it would be preferrable, then, that someone else does the commits (Julien can, I just want to save as much developer's valuable time as possible by doing all these nasty little l10n thingies myself, indeed..:-).. Ok that's fine. It doesn't really matter, since it's easy to merge things back. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436488: xserver-xorg: Addscreen/screeninit failed for driver 0
On Wed, Aug 08, 2007 at 08:12:52AM -0500, Lukasz Szybalski wrote: On 8/7/07, Brice Goglin [EMAIL PROTECTED] wrote: reassign 436488 xserver-xorg-video-i810 found 436488 2:1.7.2-4 severity 436488 normal thank you Lucas S wrote: I have installed the debian etch from a netinstall cd. Stable40r0. The gui mode of installation has worked but after selecting to install desktop and standard installtion the xserver is not able to start. Your board might not be supported by the i810 driver in Etch. You should upgrade to Debian testing (xserver-xorg-core 2:1.3.0.0.dfsg-11 and xserver-xorg-video-intel 2:2.1.0-1). Unfortunately this will be a production server in 48h so I am not able to use testing. (EE) GARTInit: Unable to open /dev/agpgart (No such file or directory) (WW) I810(0): /dev/agpgart is either not available, or no memory is available Either the kernel agpgart and intel_agp modules are not loaded or they do not support your board. (II) I810(0): Initial framebuffer allocation size: 7680 kByte (EE) I810(0): Failed to allocate framebuffer. Is your VideoRAM set too low ?? This should be fixed in testing. Are there any plans to include these two version of the program into stable anytime soon? There are plans to release a sort of etch-and-a-half in several months time. This should include updates for both the kernel and intel driver. While we're not planning to have DRI working for this scheme, you should be able to run 2d graphics at a normal speed. In the meanwhile, you'll need to use the vesa driver though. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430545: Display goes off at the mid of installation
On Fri, Aug 10, 2007 at 08:19:18AM +0200, Brice Goglin wrote: As explained by Matthew earlier, this problem is probably caused by xresprobe probing available video modes. There is no easy way to fix it for now apart from not probing at all but that might generate buggy xorg.conf. However, we expect xresprobe to be dropped in the long term thanks to the server autoconfiguration features. I'm not sure that the xserver's autoprobing is going to be a whole lot better than what xresprobe is doing. We may have to keep in mind what sort of broken hardware can cause the probe to fail like this and possibly work around it in the server if it doesn't already. - 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#429941: ITP: grandr -- gtk interface to xrandr
Package: wnpp Severity: wishlist Owner: David Nusinow [EMAIL PROTECTED] Package name: grandr Version : 0.1 Upstream Author : Intel Corporation, hosted at X.org URL : http://www.x.org/ License : MIT/X11 Programming Lang: C Description : gtk interface to xrandr A simple gtk interface to the X Resize And Roate (XRandR) extension. This allows you change the resolution and frequency of your monitor dynamically using a simple interface. For drivers that support it, it can also configure the relative positioning of multiple monitors. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429495: Option NoDRI is not used
On Mon, Jun 18, 2007 at 01:58:02PM +0100, Joachim Breitner wrote: Package: xserver-xorg-video-ati Version: 1:6.6.3-2 Severity: normal Hi, I can not disable DRI. Attached is the xorg config and the log file. Also filed here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207614 In the meantime, you can use 'Disable dri' if you're running unstable, or if you're running stable comment out the 'Load dri' line in the modules section of your xorg.conf. hth in the meanwhile. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427850: ITP: libhpricot-ruby -- A fast, flexible HTML parser for Ruby
On Thu, Jun 07, 2007 at 06:52:37AM +0900, Daigo Moriwaki wrote: Package: wnpp Severity: wishlist Owner: Daigo Moriwaki [EMAIL PROTECTED] * Package name: libhpricot-ruby Version : 0.5.140 Upstream Author : why the lucky stiff [EMAIL PROTECTED] * URL : http://code.whytheluckystiff.net/hpricot/ * License : BSD Programming Lang: Ruby Description : A fast, flexible HTML parser for Ruby Hpricot is a fast, flexible HTML parser written in Ruby's C extension. It is designed to be very accommodating and to have a very helpful library. Also, Hpricot can be handy for reading broken XML files. If a quote is missing, Hpricot tries to figure it out. If tags overlap, Hpricot works on sorting them out. apt-cache show libhpricot-ruby Package: libhpricot-ruby Priority: extra Section: libs Installed-Size: 40 Maintainer: Ari Pollak [EMAIL PROTECTED] Architecture: all Version: 0.5-2 Depends: libhpricot-ruby1.8 Filename: pool/main/libh/libhpricot-ruby/libhpricot-ruby_0.5-2_all.deb Size: 7268 MD5sum: 343eeb5de7305477e56cc0c1dbec0567 SHA1: 5485d4a298ea1fc48bf584b8a12e1bd089a27846 SHA256: 60705d6b64bbd5afecea19e6f61c787673e74592f6b5c34f7b226b2738042f17 Description: A fast, enjoyable HTML parser Hpricot is a fast, flexible HTML parser written in C. It's designed to be very accomodating (like Tanaka Akira's HTree) and to have a very helpful library (like some JavaScript libs -- JQuery, Prototype -- give you.) . Also, Hpricot can be handy for reading broken XML files, since many of the same principles are used. If a quote is missing, Hpricot tries to figure it out. If tags overlap, Hpricot works on sorting them out. . Homepage: http://code.whytheluckystiff.net/hpricot/ . This is a dependency package which depends on Debian's default Ruby version (currently 1.8). Tag: devel::lang:ruby Maybe I'm missing something? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389864: rgb text database replaced by static table
On Sun, Jun 03, 2007 at 10:22:22PM +0200, Brice Goglin wrote: Hi Giacomo, I guess this problem with the RGB database being replaced by a static table still occurs wth latest xserver-xorg-core 1.3, right? For the record, it looks like we could revert to the old behavior by defining USE_RGB_BUILTIN to 0 during the build (see os/oscolor.c). However, I am not sure it is worth doing it. I don't think that's really the method we want. Ideally, the server will use the built-in table unless we explicitly point it to an external file using xorg.conf. That way it just works in every situation and no one loses. I don't really know why you want a custom file in this day and age, but but I guess there's at least some small call for it. - 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#422948: RM: pwm - dead upstream, hostile upstream
Package: ftp.debian.org Severity: normal Hello, Please remove the pwm package from the archive. This window manager is the predecessor to ion, and is written by the same author. This program is dead upstream, and while the author has not contacted me, he has been actively hostile to both the Debian ion maintainer and that of other distros. I believe that pwm should be removed from Debian as a result. - David Nusinow -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311843: RM: debsig-verify
Package: ftp.debian.org Severity: normal Please remove debsig-verify from testing until #311843 is resolved. By default, it will hose the package system. Whether or not it is a bug in debsig-verify or dpkg doesn't matter, as its installation will seriously break a system unless it's configured. I also believe that it should be removed from the stable release as well for the same reason. - David Nusinow --- 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 1 experimentalftp.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== | -- 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#414031: google-earth doesn't work with current version of xserver-xorg-video-i810
tags 414031 + fixed-upstream thanks On Tue, Mar 13, 2007 at 12:29:41PM +0100, Michel Dänzer wrote: On Mon, 2007-03-12 at 15:15 +0100, Hermann Kraus wrote: On Mon, 12 Mar 2007 09:39:51 +0100, Michel Dänzer [EMAIL PROTECTED] wrote: We should keep it open for now as it might be a genuine bug in xserver-xorg-video-i810. Can you try rebuilding it with the attached patch to see if that helps with the new kernel? Please try both versions of libgl1-mesa-dri, as I suspect this might fix the old version but regress the new one, requiring another fix for the latter. You are right. This works with the old lib but not with new one. However it depends on the kernel version again: Kernel 2.6.19: -old lib: works -new lib: works but prints this error message: - do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset. - Kernel 2.6.20: -old lib: works -new lib: fails (error message + unusable slow) Where's the difference between kernel versions? :) Anyway, since the current upstream versions don't exhibit this problem together and fixing xf86-video-intel for old Mesa would break current Mesa, I don't intend to do anything about this upstream. Also, since no version of Debian ships the problematic combination of kernel, xf86-video-intel and Mesa, I'm not sure it's even worth doing anything about it in Debian packages. XSF, what do you think? I agree with you on this one. We'll have to remember to close this bug when we get the next upstream release in to the archive. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Wed, Feb 28, 2007 at 10:39:13AM +0100, Robert Millan [ackstorm] wrote: On Tue, Feb 27, 2007 at 06:25:51PM -0500, David Nusinow wrote: On Tue, Feb 27, 2007 at 10:26:09AM +0100, Robert Millan [ackstorm] wrote: On Mon, Feb 26, 2007 at 11:02:02PM -0500, David Nusinow wrote: I haven't decided if enabling composite by default is a wise move yet. No one in Debian has done a real analysis as to what the downsides of such a decision are. While compiz and beryl may be very sexy, I don't want to break or degrade performance on systems not running them simply for the convenience of not having to modify xorg.conf. It's not out of the question, but I don't want to blindly enable options in our default settings for the bling of it. Than can we conditionalise it? We could add a question with priority 'normal' that most users won't see. Then in the post-etch era, the Beryl community can add a reconfigure xserver-xorg and enable beryl settings step in their how-tos. If we were to do that, I suppose we would prefer to have XAANoOffscreenPixmaps and AddARGBGLXVisuals as well. I'd be fine with that. You'll have to ask the translation team for permission on this one though. I've cc'ed Christian in case he's not reading this report. Can I assume that, since you agreed to Composite by default in the other sub-thread, we're only discussing XAANoOffscreenPixmaps and AddARGBGLXVisuals here ? Exactly. I don't think composite needs a debconf question. - David Nusinow -- 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#412069: patch for beryl support
On Tue, Feb 27, 2007 at 10:26:09AM +0100, Robert Millan [ackstorm] wrote: On Mon, Feb 26, 2007 at 11:02:02PM -0500, David Nusinow wrote: I haven't decided if enabling composite by default is a wise move yet. No one in Debian has done a real analysis as to what the downsides of such a decision are. While compiz and beryl may be very sexy, I don't want to break or degrade performance on systems not running them simply for the convenience of not having to modify xorg.conf. It's not out of the question, but I don't want to blindly enable options in our default settings for the bling of it. Than can we conditionalise it? We could add a question with priority 'normal' that most users won't see. Then in the post-etch era, the Beryl community can add a reconfigure xserver-xorg and enable beryl settings step in their how-tos. If we were to do that, I suppose we would prefer to have XAANoOffscreenPixmaps and AddARGBGLXVisuals as well. I'd be fine with that. You'll have to ask the translation team for permission on this one though. I've cc'ed Christian in case he's not reading this report. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Tue, Feb 27, 2007 at 11:33:12AM +0100, Robert Millan [ackstorm] wrote: On Tue, Feb 27, 2007 at 10:55:55AM +0100, Michel Dänzer wrote: My point is that if we don't figure that out satisfactorily in time, we could just enable the Composite extension, which sounds fairly safe, and seems to be enough for Intel cards. And Intel happens to be the card brand we have the best driver support for (compared to a RE'd driver for ATI and nothing for nVidia), so focusing on it makes sense to me. Yes, that should be mostly safe at this point. The only exception that comes to mind offhand is that fglrx disables the DRI when Composite is enabled. If we have to choose between optimizing for free drivers that work sanely (either intel or radeon) and non-free drivers that are partly broken, I think it's clear what is better. Ok with enabling Composite by default then? Yeah, I'm fine with that, although I think the better method is to enable it directly in the server by default. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Fri, Feb 23, 2007 at 12:18:06PM +0100, Robert Millan [ackstorm] wrote: Package: xserver-xorg Severity: wishlist Tags: patch I know it's too late for Beryl to make it into etch, but can we at least ship an xorg.conf that is frendly to Beryl ? With this patch, only installing the beryl packages will be enough to get it working with no further setup (provided that OpenGL is working fine). Also note that having these extra lines in your xorg.conf is harmless for non-Beryl users (at least it didn't produce any new warnings or errors in /var/log/Xorg.log for me), so I propose to add them unconditionaly. Please, can this make it into etch? This kind of eye-candy is _awesome_ to attract new users. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ diff -ur xorg-7.1.0.old/debian/local/dexconf xorg-7.1.0/debian/local/dexconf --- xorg-7.1.0.old/debian/local/dexconf 2007-02-13 11:02:09.0 +0100 +++ xorg-7.1.0/debian/local/dexconf 2007-02-23 12:07:45.0 +0100 @@ -351,6 +351,11 @@ if [ $DEVICE_USE_FBDEV = true ]; then printf \tOption\t\t\UseFBDev\\t\t\$DEVICE_USE_FBDEV\\n 4 fi +cat 4 SECTION + # needed for beryl + Option XAANoOffscreenPixmaps true + Option AddARGBGLXVisuals On These aren't generally necessary, and I don't believe it's a good idea to set them as default when they're not needed. The latter may be harmless, but I don't know enough about the former, since it only appears to be useful on some ati hardware. There's a reason why upstream hasn't enabled it by default in the driver. +SECTION printf EndSection\n 4 ### MONITOR @@ -428,6 +433,15 @@ EndSection SECTION +### Extensions +exec 4$DEXCONFTMPDIR/Extensions +cat 4 SECTION +Section Extensions + # needed for beryl + Option Composite Enable +EndSection +SECTION I haven't decided if enabling composite by default is a wise move yet. No one in Debian has done a real analysis as to what the downsides of such a decision are. While compiz and beryl may be very sexy, I don't want to break or degrade performance on systems not running them simply for the convenience of not having to modify xorg.conf. It's not out of the question, but I don't want to blindly enable options in our default settings for the bling of it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412275: no display and system freezes after adjusting time with KDE clock on 945GM graphic chip
On Mon, Feb 26, 2007 at 05:16:58AM +0100, David Martínez Moreno wrote: El domingo, 25 de febrero de 2007, Brice Goglin escribió: Ralph Plawetzki wrote: When the system freezes, I have to turn off the laptop. When it's rebooted, I can reproduce the error by changing the time again. Just to be sure, can you try changing the time with the 'date' command instead of the KDE applet? Brice, I keep having this problem with ntpdate, for example. It is not related to KDE, I think. If I dare to synchronize my local time over NTP and it happens that I am in the future, bang! The X server crashes inmediately. I think that it was reported repeteadly to upstream, but I did not search for a solution since some weeks ago. Indeed, this soudns exactly like another bug that was reported at least once a few months back. I applied a patch that was supposed to help with the problem, but apparently it wasn't the fix that we'd hoped for. Sorry, I don't have time to track down the original bug numbers right now, but I can try and fetch them if people want. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410879: xserver-xorg-core: Dual-screen problem
On Tue, Feb 20, 2007 at 09:58:40AM +0100, Benjamin Gufler wrote: Hi Julien, On 2007-02-20 07:35, Julien Cristau wrote: uh, read the bug, please, this is a regression introduced by the int10 patch in 2:1.1.1-17, so we might want to fix it. Benjamin, could you try commenting this line in your xorg.conf: Option UseInt10ModuleTrue and tell us whether that fixes it? thanks for this suggestion. If I remove that line, I'm able to start the X server using xserver-xorg-core 2:1.1.1-18, but not with 2:2.1.0-3. However, what I get is not one screen next to the other as before, but a cloned output (except for the mouse pointer, which is visible only on one of the screens). Can you add the linke 'Load vm86' to your modules section and let us know if that works? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411206: git-buildpackage: Please allow use of an external .orig.tar.gz
Package: git-buildpackage Version: 0.2.25 Severity: wishlist Hello, I'd like to make use of pre-existing .orig.tar.gz's. I have a large of these lying around for more stable parts of xorg, and I'd like to just have git-buildpackage use them rather than import them in to the repository. I think this is the last issue that's keeping me from using git-buildpackage for managing the xorg packages for Debian. Thank you and keep up the great work! - David Nusinow -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages git-buildpackage depends on: ii devscripts 2.9.27 Scripts to make the life of a Debi ii git-core 1:1.4.4.4-1 content addressable filesystem ii git-load-dirs1.0.35 Import upstream archives into git ii python 2.4.4-2 An interactive high-level object-o ii python-support 0.5.6 automated rebuilding support for p git-buildpackage recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405714: How would the trivial implementation violate policy?
On Sun, Feb 04, 2007 at 08:14:44PM -0500, Philippe Cloutier wrote: Hi David, suppose this would be implemented trivially, by identifying a line in xorg.conf where the needed line can be added and adding the needed line there. How would this violate policy? This is the relevant section: http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.4 - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406608: libsm6: ICE socket disappears after a suspend-to-ram, delay when starting session-aware apps
On Fri, Jan 12, 2007 at 11:08:45AM +0100, Alexis Sukrieh wrote:
Package: libsm6
Version: 1:1.0.1-3
Severity: important
Hello, first of all forgive me if libsm6 is not responsible of this bug,
I had trouble to figure out which is the real buggy package there.
If you want to reassign the bug the a more appropriate package, feel
free.
I have a Debian etch laptop and use oftenly the suspend-to-ram thing,
with hibernate (using the sysfs way: echo mem /sys/power/state).
When I power the laptop back from suspending, the ICE socket is no more:
$ env | grep -i ice
SESSION_MANAGER=local/heracles:/tmp/.ICE-unix/11483
$ ls /tmp/.ICE-unix/11483
ls: /tmp/.ICE-unix/11483: No such file or directory
This makes quite all my apps under X to start with a ~10 seconds-delay.
If I strace xterm for instance, I got the following output:
connect(4, {sa_family=AF_FILE, path=/tmp/.ICE-unix/11483}, 22) = -1
ENOENT (No such file or directory)
close(4)= 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0}) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 4
uname({sys=Linux, node=heracles, ...}) = 0
Any help/hint/advice is welcome, I'm willing to help fixing that bug
before etch is released (hopefully).
Tell me if I can provide more useful information.
Is every file and directory in your /tmp wiped ont when you suspend and
resume? If so, it really shouldn't be doing that.
- David Nusinow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323262: reopen 323262, still found in 7.1.0-9
On Thu, Jan 11, 2007 at 10:15:59AM +0200, Damyan Ivanov wrote: found 323262 7.1.0-9 thanks Hi, It appears that bug 323262 is still present in xserver-xorg/7.1.0-9. Is there a reason not to apply the patch to 7.1 or was this simply an oversight? It's an oversight. I think I missed it in the transition to the 7.x series. Unfortunately, we're so late in to the release process that I don't think I can get an acception to this one, or else I'd upload a fix now. I'm sorry. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406306: Processed: Re: Bug#406306: [INTL:ta] Tamil xserver - xorg templates translation
On Wed, Jan 10, 2007 at 07:17:55PM +0100, Christian Perrier wrote: Quoting Debian Bug Tracking System ([EMAIL PROTECTED]): Processing commands for [EMAIL PROTECTED]: reassign 406306 xserver-xorg Bug#406306: [INTL:ta] Tamil xserver - xorg templates translation OK, X folks, where should I commit this? Are SVN commits still OK ? Yep, they are. We'll announce it, and I'll let you know, when they're not. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323262: reopen 323262, still found in 7.1.0-9
On Mon, Jan 15, 2007 at 12:43:37AM +0200, Damyan Ivanov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -=| David Nusinow, 15.01.2007 00:40 |=- On Thu, Jan 11, 2007 at 10:15:59AM +0200, Damyan Ivanov wrote: It appears that bug 323262 is still present in xserver-xorg/7.1.0-9. Is there a reason not to apply the patch to 7.1 or was this simply an oversight? It's an oversight. I think I missed it in the transition to the 7.x series. Unfortunately, we're so late in to the release process that I don't think I can get an acception to this one, or else I'd upload a fix now. I'm sorry. No big deal, ltsp packages have a workaround in them, so no high urgency. Anyway, I hope reopening of this bug will make it harder to miss the patch on the next upload :) Actually, Julien just noticed that the big issue (the new debconf template) is a hidden one, so we're actually be uploading this fix shortly. Thanks for noticing the regression. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
