By the way, it would be great if you would add a check for that in the xorg
packages postinst scripts...
otherwise we risk to have many people with a non-working X when the stable
upgrade Lenny->Squeeze comes...
:)
Regards, Ariel
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.deb
Hi,
> > But X somehow still gets or uses those settings, no clue if they are
> > default or where they do come from: (Full log attached)
>
> That's not enough to remove the values from the udev db, easiest is to
> reboot.
well, that is starting to look like windows then ;-)
I guess udevadm trig
> This is configured in /etc/default/keyboard nowadays.
Well, "nowadays" gives the impression i'm using a 5 years old
configuration... that laptop was installed from scratch 6 months ago...
But no, it still doesn't work: i've now commented out
#XKBMODEL="pc105"
#XKBLAYOUT="en"
#XKBVARIANT="
> You failed to notice the one important difference, which is that your
> xkb configuration is screwed up. There's no "en" layout or "qwerty"
> variant.
sorry, but you should have read my bug-report also... ;-)
I am reporting that X is not able to make the keyboard work
WITHOUT any xorg.conf c
Hi,
ok, sorry folks :-) i've submitted another bug as you suggested.
I am sure it is a real issue, which could even seriously affect the
usability of a fresh installation if that misdetection happens there.
It is bug #571636: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571636
Best regards
Package: xserver-xorg
Version: 1:7.5+3
Severity: grave
Justification: renders X unusable without extra configuration
After the following package upgrades, the keyboard stopped working in X,
but still works fine in the console:
xserver-common 2:1.6.5-1 --> 2:1.7.4-2
xserver
Same issue here, didn't reboot my laptop for 20+ days, but somewhen in between
things broke... :-(
For sure it is not a firmware issue (same self-compiled kernel since longer).
Also udev and libudev are both version 150-2
Keyboard works fine in the console.
Arch x86_64
Upgraded packages (releva
Hi,
i can reproduce it, exactly the same behaviour and strace as in the initial
report. Didn't try to recompile though.
Strange: when calling the program without parameters it segfaults.
When calling it
universalindentgui MyFile.cpp # existing or not, same result
or even
universalin
Same here, but solved thanks to Olivier's remark, the dependency in
python-support seems to be wrong, it only states
Depends: python (>= 2.3), python-support
whereas updating to py-support 1.0.2 in unstable solves the problem
apt-get -s install python-support/unstable
--
To UNSUBSCR
Package: etoken-pro-support
Version: 0.0.5
Severity: grave
--- Please enter the report below this line. ---
The README.Debian file
/usr/share/doc/etoken-pro-support/README.Debian
points the user to download the required (proprietary) drivers from
http://www.aladdin.ru/upload/iblock/179/eToken_
Package: scribus-ng
Version: 1.3.4.dfsg-1
Severity: serious
--- Please enter the report below this line. ---
Scribus crashes while editing the textstyles, with the following output:
ASSERT: "di != -1"
in
/home/malex/debian/scribus/unstable/1.3.4/scribus-ng-1.3.4.dfsg/scribus/smtextstylewidgets.
11 matches
Mail list logo