Bug#633343: Bug#633441: Lost keyboard - workaround found -- calling udevadm trigger

2011-07-12 Thread Marco d'Itri
On Jul 12, Helge Kreutzmann deb...@helgefjell.de wrote: I did. I could not find anything specific. I tried booting into single user mode as described but given that I use lvm, this is non trivial (I ended up in a kernel panic because no further partition could be found). If you boot with

Bug#633343: xserver-xorg-core: No keyboard after fresh install

2011-07-10 Thread Marco d'Itri
On Jul 10, Helge Kreutzmann deb...@helgefjell.de wrote: a fresh install from the daily netinstimage from Friday, but as soon as X starts the keyboard is dead (i.e. even Num Lock does not lit up Looks like your system is broken in some way and udev is not running or failed for some reason. You

Bug#633343: Bug#633441: Lost keyboard - workaround found -- calling udevadm trigger

2011-07-10 Thread Marco d'Itri
On Jul 10, Helge Kreutzmann deb...@helgefjell.de wrote: Could that be because I have EFI (AFAIK) and not a traditional BIOS? No. This probably happens because the udev init script failed. Again, you need to find out why. Watch closely the boot process. Also, read README.Debian. -- ciao, Marco

Bug#614297: the keyboard configuration is reset by hotplug events

2011-02-20 Thread Marco d'Itri
Package: xserver-xorg-core Version: 2:1.9.4-3 Severity: normal An input uevent (e.g. un/plugging a mouse, which does not trigger the rule in 64-xorg-xkb.rules) resets my custom user-configured keyboard configuration. I have a mildly complex xkb configuration in ~/.xkb/ which I load with:

Re: Bug#583609: some database entries are cut off on non-ASCII chars

2010-06-06 Thread Marco d'Itri
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 reassign 583609 xterm thanks On Jun 06, Harald Dunkel ha...@afaics.de wrote: It seems that this is a bug in xterm. Using gnome-terminal or I/O redirection into a file whois works as expected. I will create a new bug report. Many thanx anyway

Re: loading kernel mode setting drivers

2010-01-11 Thread Marco d'Itri
On Jan 12, Julien Cristau jcris...@debian.org wrote: Marco, what do you think of switching to this, or at least using its fb part? I do not mind explicitly blacklisting each fb driver, but I would like to have a way to semi-automatically generate the list. Is there any? BTW, I am not sure why

Bug#472081: the X server may crash when a program switches to full screen mode

2008-03-21 Thread Marco d'Itri
Package: xserver-xorg-video-intel Version: 2:2.2.1-1 Severity: important On my system (Dell D620) since the last (maybe second-last, but probably not) upgrade of xserver-xorg-video-intel the X server randomly crashes when a program switches to full screen mode. It's not 100% reproducible, but it

Bug#383465: Contains obfuscated source code, DFSG violation?

2006-08-29 Thread Marco d'Itri
On Aug 29, Daniel Stone [EMAIL PROTECTED] wrote: According to -legal, everything must be provided with its pure, original source -- the head of the coder that hand-wrote some firmware, the instruments used to record any particular Ogg Vorbis track, et al. Let's be accurate here: according to

Bug#347680: Xorg breaks acpid

2006-01-22 Thread Marco d'Itri
On Jan 12, Mattia Dongili [EMAIL PROTECTED] wrote: No. That's the kernel only supporting a single reader for /proc/acpi/event. I'm cooking a patch to support multiple readers (based on an old and never applied patch) but I doubt it will be accepted mainline. /proc/acpi/event contention has

Bug#347680: Xorg breaks acpid

2006-01-22 Thread Marco d'Itri
On Jan 23, Mattia Dongili [EMAIL PROTECTED] wrote: to be fixed in X (I suggest by retrying to open the socket if it worked the first time). this is exactely what the patch I submitted here does. But it does only once, so if the socket is not there on the first retry it'll steal

Bug#242865: drivers containing firmware blobs

2004-04-14 Thread Marco d'Itri
On Apr 13, Branden Robinson [EMAIL PROTECTED] wrote: Please paste the licensing info (if any) from each of these files and specifically explain why they fail the DFSG. These files contain executable code, but there is no source for them. Anyway, the release manager will probably tag this bug

Bug#242865: drivers containing firmware blobs

2004-04-09 Thread Marco d'Itri
Package: xfree86 Severity: serious Tags: sarge, sid The following files contain binary firmwares, and distributing them appears to be a DFSG violation. (See #239952) ./programs/Xserver/hw/xfree86/drivers/mga/mga_ucode.h * GLX Hardware Device Driver for Matrox G200/G400

Bug#242865: drivers containing firmware blobs

2004-04-09 Thread Marco d'Itri
On Apr 09, Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2004-04-09 at 12:38, Marco d'Itri wrote: /* r128_cce.c -- ATI Rage 128 driver -*- linux-c -*- ./programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_cce.c /* radeon_cp.c -- CP support for Radeon -*- linux-c

Bug#216896: xserver-xfree86: [ati/radeon] patch needed for radeon 9200SE support

2003-10-21 Thread Marco d'Itri
Package: xserver-xfree86 Version: 4.3.0-0pre1v3 Severity: wishlist Tags: patch upstream http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg12830.html Also see: http://sourceforge.net/mailarchive/message.php?msg_id=6146896 01:00.0 VGA compatible controller: ATI Technologies Inc:

Bug#210651: libdps1: library not correctly linked

2003-09-12 Thread Marco d'Itri
Package: libdps1 Version: 4.2.1-11 Severity: serious [This is a standard text.] This bug has serious severity because it is a policy violation and is an item in aj's list of release showstoppers. One or more libraries in this package are buggy. All libraries need to be linked against other

Bug#210651: libdps1: library not correctly linked

2003-09-12 Thread Marco d'Itri
Package: libdps1 Version: 4.2.1-11 Severity: serious [This is a standard text.] This bug has serious severity because it is a policy violation and is an item in aj's list of release showstoppers. One or more libraries in this package are buggy. All libraries need to be linked against other

Bug#187365: xlibmesa3-glu: libraries not correctly linked

2003-04-03 Thread Marco d'Itri
On Apr 03, Daniel Stone [EMAIL PROTECTED] wrote: On Thu, Apr 03, 2003 at 12:12:09AM +0200, Marco d'Itri scrawled: /usr/X11R6/lib/libGLU.so.1 -lGL Hold on, doesn't this render the entire -gl/-glu fix moot? [EMAIL PROTECTED] xlibmesa3/xlibmesa4 went to xlibmesa4-gl and xlibmesa4

Bug#187365: xlibmesa3-glu: libraries not correctly linked

2003-04-03 Thread Marco d'Itri
On Apr 03, Michel Dänzer [EMAIL PROTECTED] wrote: No, why? libGLU depends on libGL (which isn't reflected in the xlibmesa*-glu dependencies due to this bug), I guess the rationale Yes, I concluded this too. Anyway, why not simply drop xlibmesa*-glu, seeing as they are the same thing as

Bug#187365: xlibmesa3-glu: libraries not correctly linked

2003-04-03 Thread Marco d'Itri
On Apr 03, Daniel Stone [EMAIL PROTECTED] wrote: On Thu, Apr 03, 2003 at 12:12:09AM +0200, Marco d'Itri scrawled: /usr/X11R6/lib/libGLU.so.1 -lGL Hold on, doesn't this render the entire -gl/-glu fix moot? [EMAIL PROTECTED] xlibmesa3/xlibmesa4 went to xlibmesa4-gl and xlibmesa4

Bug#187365: xlibmesa3-glu: libraries not correctly linked

2003-04-03 Thread Marco d'Itri
On Apr 03, Michel Dänzer [EMAIL PROTECTED] wrote: No, why? libGLU depends on libGL (which isn't reflected in the xlibmesa*-glu dependencies due to this bug), I guess the rationale Yes, I concluded this too. Anyway, why not simply drop xlibmesa*-glu, seeing as they are the same thing as

Bug#187365: xlibmesa3-glu: libraries not correctly linked

2003-04-02 Thread Marco d'Itri
Package: xlibmesa3-glu Version: 4.2.1-6 Severity: normal [This is a standard text.] One or more libraries in this package are buggy. All libraries need to be linked against other libraries which they reference. You can check this by running this command: LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1

Bug#187374: xlibs: libraries not correctly linked

2003-04-02 Thread Marco d'Itri
Package: xlibs Version: 4.2.1-6 Severity: normal [This is a standard text.] One or more libraries in this package are buggy. All libraries need to be linked against other libraries which they reference. You can check this by running this command: LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1

Bug#187365: xlibmesa3-glu: libraries not correctly linked

2003-04-02 Thread Marco d'Itri
Package: xlibmesa3-glu Version: 4.2.1-6 Severity: normal [This is a standard text.] One or more libraries in this package are buggy. All libraries need to be linked against other libraries which they reference. You can check this by running this command: LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1

Bug#187374: xlibs: libraries not correctly linked

2003-04-02 Thread Marco d'Itri
Package: xlibs Version: 4.2.1-6 Severity: normal [This is a standard text.] One or more libraries in this package are buggy. All libraries need to be linked against other libraries which they reference. You can check this by running this command: LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1

EuroSign and UTF-8.

2003-01-17 Thread Marco d'Itri
Any idea? Md does anybody know why suddenly X started generating the Euro symbol in UTF-8 instead of latin-9? Md I use xmodmap and keycode 26 = e E EuroSign asuffield how about a non-utf xterm in the relevant locale? Md asuffield: it still does not work asuffield any output, or just ignores

EuroSign and UTF-8.

2003-01-17 Thread Marco d'Itri
Any idea? Md does anybody know why suddenly X started generating the Euro symbol in UTF-8 instead of latin-9? Md I use xmodmap and keycode 26 = e E EuroSign asuffield how about a non-utf xterm in the relevant locale? Md asuffield: it still does not work asuffield any output, or just ignores

Bug#175074: Bug#175077: libdv2: libraries not compiled with -fPIC

2003-01-09 Thread Marco d'Itri
On Jan 09, Daniel Kobras [EMAIL PROTECTED] wrote: You can check with: objdump --all-headers /usr/lib/libdv.so.2 It shows a TEXTREL section, so it's not position independent[1]. I do not know why this happens even if the code is compiled with -fPIC (libGL shows the same problem, #175074), I'm

Bug#175074: Bug#175077: libdv2: libraries not compiled with -fPIC

2003-01-09 Thread Marco d'Itri
On Jan 10, Jakub Jelinek [EMAIL PROTECTED] wrote: Normally libGL in XFree86 is compiled without -fPIC (I have a patch to change that, but need to update it and test whether libGL is at least as fast as before). If you made sure all libGL.so .c files are compiled with -fpic/-fPIC and the

Bug#175074: xlibmesa3: libraries not compiled with -fPIC

2003-01-09 Thread Marco d'Itri
tag 175074 - unreproducible moreinfo severity 175074 normal retitle 175074 xlibmesa3: contains non-PIC code thanks On Jan 10, Branden Robinson [EMAIL PROTECTED] wrote: WRONG. My shared libraries, including those in xlibmesa3, are compiled with -fPIC, and the static ones are not, as my build

Bug#175074: Bug#175077: libdv2: libraries not compiled with -fPIC

2003-01-09 Thread Marco d'Itri
On Jan 09, Daniel Kobras [EMAIL PROTECTED] wrote: You can check with: objdump --all-headers /usr/lib/libdv.so.2 It shows a TEXTREL section, so it's not position independent[1]. I do not know why this happens even if the code is compiled with -fPIC (libGL shows the same problem, #175074), I'm

Bug#175074: Bug#175077: libdv2: libraries not compiled with -fPIC

2003-01-09 Thread Marco d'Itri
On Jan 10, Jakub Jelinek [EMAIL PROTECTED] wrote: Normally libGL in XFree86 is compiled without -fPIC (I have a patch to change that, but need to update it and test whether libGL is at least as fast as before). If you made sure all libGL.so .c files are compiled with -fpic/-fPIC and the

Bug#175074: xlibmesa3: libraries not compiled with -fPIC

2003-01-09 Thread Marco d'Itri
tag 175074 - unreproducible moreinfo severity 175074 normal retitle 175074 xlibmesa3: contains non-PIC code thanks On Jan 10, Branden Robinson [EMAIL PROTECTED] wrote: WRONG. My shared libraries, including those in xlibmesa3, are compiled with -fPIC, and the static ones are not, as my build

Bug#175074: xlibmesa3: libraries not compiled with -fPIC

2003-01-02 Thread Marco d'Itri
Package: xlibmesa3 Version: 4.2.1-4 Severity: important [This is a standard text.] One or more shared libraries in this package are buggy. By policy, all shared libraries MUST be compiled with -fPIC. The broken libraries are: /usr/X11R6/lib/libGL.so.1 -- To UNSUBSCRIBE, email to [EMAIL

Bug#175074: xlibmesa3: libraries not compiled with -fPIC

2003-01-02 Thread Marco d'Itri
Package: xlibmesa3 Version: 4.2.1-4 Severity: important [This is a standard text.] One or more shared libraries in this package are buggy. By policy, all shared libraries MUST be compiled with -fPIC. The broken libraries are: /usr/X11R6/lib/libGL.so.1

Re: status on the donated blue white G3

2000-12-11 Thread Marco d'Itri
On Dec 11, Branden Robinson [EMAIL PROTECTED] wrote: Dan, are you *sure* we don't need an autobuilder? Not even for some subsection of the archive? How about contrib? :) If needed, I can set up an autobuilder on the B50 I'm installing and which will become the new {ftp,http}.it.debian.org.

Re: status on the donated blue white G3

2000-12-11 Thread Marco d'Itri
On Dec 11, Branden Robinson [EMAIL PROTECTED] wrote: Dan, are you *sure* we don't need an autobuilder? Not even for some subsection of the archive? How about contrib? :) If needed, I can set up an autobuilder on the B50 I'm installing and which will become the new {ftp,http}.it.debian.org.