Public bug reported:
Binary package hint: gnome-settings-daemon
When the user runs gnome-keyboard-properties and some of his settings
cause xkbcomp to fail, the user gets a general error message about
"Error activating XKB configuration" and some obscure hints as to where
the cause might lie. The
> Getting a better error message for the Gnome UI is a GNOME issue
obviously, not xkeyboard-config's duty, and really ought to be filed
separately against the appropriate GNOME component.
I agree, just filed bug #328980 for this. It's a bit tricky, as it
involves multiple packages.
> As to the se
I have the feeling that this bug here might be a collection of several
distinct issues, which all look the same due to lack of precise error
messages. I filed bug #328980 asking for error messages to be displayed
to the user.
Until then, you might use the attached script to learn more about this
k
I just confirmed that the stderr of the xkbcomp invocation is redirected
to /dev/null, so error messages are indeed completely lost.
A fist step towards sensible error messages would probably be to
redirect stderr in libxklavier in such a way that it can be directed
into the syslog. This would inv
** Bug watch added: GNOME Bug Tracker #588607
http://bugzilla.gnome.org/show_bug.cgi?id=588607
** Also affects: gnome-settings-daemon via
http://bugzilla.gnome.org/show_bug.cgi?id=588607
Importance: Unknown
Status: Unknown
--
xkbcomp errors should be displayed
https://bugs.launch
Starting with Jaunty, error messages from xkbcomp end up in ~/.xsession-
errors where they can be inspected by the technically inclined user.
This is probably due to the following change in gnome-settings-daemon:
http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=015e92a82c6bd19b4d3fcbcbe6
Starting with Jaunty, people seeing this "Error activating XKB
configuration" dialog might have a look at the .xsession-errors file in
their home directory. Error messages from xkbcomp will end up there, and
others might as well. Maybe the information from these files can be used
to differentiate t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
raketenman wrote:
> Error:No Symbols named "de_mac" in the include file
> "macintosh_vndr/ch"
Same as my bug #327963, I guess.
You can either have a Macintosh Swiss keyboard model with a German
layout, or you can have a generic keyboard
RedVivi schrieb:
> I encountered the same problem with my integrated MacBookPro keyboard.
What version of Ubuntu? Have you tried with Karmic?
Have you had a look at your ~/.xsession-errors file, to check whether
there are any messages there related to keyboard layout configuration?
--
"Error ac
Sennaista, you might want to have a look at ~/.xsession-errors, see if
there is an error message in there that might be related to your
keyboard layout configuration.
--
"Error activating XKB configuration." - Requires manual xorg.conf editing
https://bugs.launchpad.net/bugs/67188
You received th
spbrereton, if what you experience is in fact bug #327963, then I
believe that you should set the MODEL to something mac (e.g.
"macintosh_vndr/ch") and the LAYOUT to a variant not mentioning mac
(e.g. "de", not "de_mac").
The reason is that the layout files for mac models simply don't mention
any
So let me get this right: you're now working with a USB keyboard plugged into
your MacBook Pro?
Is it a Mac keyboard, or some other, more PCish keybord? If the latter, then
"Generic" is most definitely the way to go, I'd say.
When you claim that a Generic 102 keyboard was the "only way", have you
OK, now gladly disregarding VB and your external keyboard. My advice is to
1. change keyboard layout from "USA Mac" to "USA" and
2. change keyboard model from "Generic" to "Apple/MacBook/MacBook Pro".
Order is relevant if you want to avoid error messages in between.
If that works for you, then bug
Public bug reported:
Binary package hint: gnome-settings-daemon
As mentioned in bug #328980 comment #5, it would be a good idea to have
users include their ~/.xsession-errors when reporting errors with their
keybord konfiguration. This is because errors from xkbcomp end up in
that file. These wou
OK, this patch does implement the request as outlined above.
I even adjusted the message files, except for the Azerbaijani (az) one,
as that uses different wording for the two existing lines, and I have no
clue why that's the case. Some other languages were changed from fixed
command strings to %s
I'll take the two months without reply from the ubuntu maintainers of
gnome-settings-daemon as a "No" to my question wherther they'd take it
from here. So I just filed a separate request, bug #430705, about
mentioning ~/.xsession-errors in the error message after a failed xkb
activation. Let's hope
apport would make sense, yes. Should I file another report for this, or
shall we mark this one here as affecting apport?
--
Ask for .xsession-errors in gsd-keyboard-xkb.c function activation_error
https://bugs.launchpad.net/bugs/430705
You received this bug notification because you are a member o
I personally would wish for the error message to be displayed to the
user in a dialog window, not only logged in some obscure file. So my
original request hasn't been dealt with in full.
However, I believe that taking the lack of manpower into account, a
solution at the distro level is at the mome
The new one I opened requests that users be told to include their
.xsession-errors in bug reports, which is a first step. So if a user
encounters some xkbcomp error, and wants to report a bug about it, then
he will include a portion of that error log file, and the resulting bug
report will be more
So you say that an error message containing some technical information
is worse than one with almost no information at all? I'm sure I disagree
for myself, as I find an error message like 'No Symbols named
"mac_nodeadkeys" in the include file "macintosh_vndr/de"' (from bug
#327963) to be both under
Bug #431807 in its current form doesn't help with the situation I'm
concerned with here. The errors I have in mind come from the xkbcomp
executable, and don't match the format of glib errors. I just updated to
Karmic Beta and made sure that the relevant lines are still missing from
the report. Matc
> could you describe a way to trigger the error?
I hit this in bug #327963. So a way to reproduce is this:
1. set keyboard layout to "Germany Macintosh, no dead keys"
2. set keyboard model to "MacBook / MacBook Pro (Intl)"
This might only work until someone fixes #327963, though. After that,
you
22 matches
Mail list logo
