[Bug 1360005] Re: Cyrillic symbols looks strange when using autocompletion
Does the completed filename look different from the output of ls? Can you copy/paste a test-case? I don't know how to type cyrillic characters without busting out gucharmap, but I have no problem pasting mkdir / touch 'some UTF8' into a shell to test it out. e.g. touch cyrillic with spaces echo ./cyr[TAB] = ? ls output -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1360005 Title: Cyrillic symbols looks strange when using autocompletion To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1360005/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1342970] Re: should have a recommends: on gnome-shell
discussion on bugs.debian.org/755023 indicates that the gnome-session may have recently started actually depending on gnome-shell, so the appropriate dependency is Depends, which Debian currently has. ** Summary changed: - should have a recommends: on gnome-shell + should have a recommends: on gnome-shell, or maybe Depends -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-session in Ubuntu. https://bugs.launchpad.net/bugs/1342970 Title: should have a recommends: on gnome-shell, or maybe Depends To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1342970/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1342970] [NEW] should have a recommends: on gnome-shell
Public bug reported: gnome-session 3.9.90-0ubuntu12 Some packages (e.g. gdm) use a dependency on gnome-session as shorthand for that plus a window manager. gnome-session should Recommends: gnome- shell. Otherwise xinit starts it, and then it aborts when gnome-shell isn't present. e.g. xinit has a Recommends on xterm | x-session-manager | x-window-manager | x-terminal-emulator so a session manager is expected to provide everything needed, including a window manager. gdm does similar. Looks like we got into this situation after https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/795191 when a dependency was completely removed, instead of changing to a recommends or suggests. It is apparently possible to have gnome-session start something other than gnome-shell, but that's certainly the default behaviour. I ran into this after cleaning up all the packages I don't use from my system, following an upgrade from 12.04 to 14.04. I use fluxbox, and just start things from bash in screen in gnome-terminal, not a graphical shell at all. I ended up with a graphical login, instead of my usual text console - startx ** Affects: gnome-session (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-session in Ubuntu. https://bugs.launchpad.net/bugs/1342970 Title: should have a recommends: on gnome-shell To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1342970/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 951916] Re: gnome-sudoku crashed with ImportError in /usr/lib/python2.7/dist-packages/gnome_sudoku/main.py: cannot import name LaunchpadIntegration
Installing gir1.2-launchpad-integration-3.0 allows gnome-sudoku to start on Ubuntu 12.04. python-launchpad-integration wasn't sufficient. Even ubuntu-desktop doesn't include gir1.2-launchpad-integration-3.0 in its dependency chain, only a Recommends via software-center. Anyway, either add the dependency or change the patched-in code in main.py to omit that menu item if the library can't be imported. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-games in Ubuntu. https://bugs.launchpad.net/bugs/951916 Title: gnome-sudoku crashed with ImportError in /usr/lib/python2.7/dist- packages/gnome_sudoku/main.py: cannot import name LaunchpadIntegration To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/951916/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 951916] Re: gnome-sudoku missing dependency for patched-in LaunchpadIntegration. Won't run.
** Summary changed: - gnome-sudoku crashed with ImportError in /usr/lib/python2.7/dist-packages/gnome_sudoku/main.py: cannot import name LaunchpadIntegration + gnome-sudoku missing dependency for patched-in LaunchpadIntegration. Won't run. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-games in Ubuntu. https://bugs.launchpad.net/bugs/951916 Title: gnome-sudoku missing dependency for patched-in LaunchpadIntegration. Won't run. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/951916/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 951916] Re: gnome-sudoku missing dependency for patched-in LaunchpadIntegration. Won't run.
The lpi patch is gone from gnome-games's source tree in Saucy, so at some point this bug disappeared. It still affects 12.04 LTS, but won't affect future releases. ** Changed in: gnome-games (Ubuntu) Status: New = Confirmed ** Summary changed: - gnome-sudoku missing dependency for patched-in LaunchpadIntegration. Won't run. + gnome-sudoku missing dependency for patched-in LaunchpadIntegration. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-games in Ubuntu. https://bugs.launchpad.net/bugs/951916 Title: gnome-sudoku missing dependency for patched-in LaunchpadIntegration. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/951916/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 951916] Re: gnome-sudoku missing dependency for patched-in LaunchpadIntegration.
I updated the title again, the won't run part of the bug description is the symptom if you hit this bug, but that only happens when you either install gnome-sudoku on a lean install that doesn't include the recommends: packages of ubuntu-desktop, or if you strip stuff out of a desktop install. A kubuntu-desktop doesn't pull in gir1.2-launchpad-integration-3.0, even with recommends, so installing this on a default kubuntu system would fail. I didn't want to raise undue alarm about it not working out of the box for most people, since it's fixed for later releases anyway. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-games in Ubuntu. https://bugs.launchpad.net/bugs/951916 Title: gnome-sudoku missing dependency for patched-in LaunchpadIntegration. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/951916/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 472948] [NEW] installs a broken man-page symlink
Public bug reported: Binary package hint: gstreamer0.10-tools found with cruft(8): $ find -L $(dpkg -L gstreamer0.10-tools) -maxdepth 0 -type l -ls 31182280 lrwxrwxrwx 1 root root 18 Oct 31 16:11 /usr/share/man/man1/gst-xmlinspect-0.10.1 - gst-inspect-0.10.1 actual target is ...1.gz ii gstreamer0.10-tools 0.10.25-2 Tools for use with GStreamer ** Affects: gstreamer0.10 (Ubuntu) Importance: Undecided Status: New -- installs a broken man-page symlink https://bugs.launchpad.net/bugs/472948 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gstreamer0.10 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 190227] Re: ia32 apps look for libs on the wrong place
Now, am I to undestand that, at least in my case, the error message Gtk-Message: Failed to load module gail: /usr/lib/gtk-2.0/modules/libgail.so: wrong ELF class: ELFCLASS64 was caused by libgail being a 32bit library and not compatible with amd64 architecture? amd64 Linux kernels support ia32 processes running in 32bit compatibility mode. From the point-of-view of the 32bit process, it's pretty much the same as running under a 32bit (i386 architecture) kernel. (This is now called legacy mode on). http://en.wikipedia.org/wiki/Long_mode http://developer.amd.com/pages/123200367.aspx So yeah, when the dynamic linker in a 32bit process tries to load a shared library compiled for a different architecture, it returns an error, because it detected that the library is for a different architecture than the process. Just like if the file was a PowerPC or SPARC library. The kernel knows whether to run a process in 32 or 64 bit mode by looking at the same ELF headers that libraries have, and that file(1) will show you. llama$ file /bin/ls /bin/ls: ELF 32-bit LSB executable, Intel 80386, ... tesla$ file /bin/ls /bin/ls: ELF 64-bit LSB executable, x86-64, ... file works on share libs, too, of course. -- ia32 apps look for libs on the wrong place https://bugs.launchpad.net/bugs/190227 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gtk+2.0 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 328575] Re: Cannot start gnome-terminal because of gconf error
** Description changed: I cannot start gnome-terminal. If I open an xterm and start gnome- terminal from the command line, here is what I get: $ sudo gnome-terminal Failed to contact the GConf daemon; exiting. (original report didn't have sudo in this command, but a later comment by the submitter amended this.) $ ps ax | grep gconf 3956 pts/0R+ 0:00 grep gconf 6643 ?S 0:00 /usr/lib/pulseaudio/pulse/gconf-helper 6647 ?S 0:06 /usr/lib/libgconf2-4/gconfd-2 This is in Jaunty Alpha 4 with all updates current as of 12 Feb. This bug is now understood. Read all the comments (or at least try some text searches) before adding your own, because a lot of things have already been covered. summary of some stuff posted in comments: gnome-terminal on purpose refuses to start if it can't connect to gconfd to get its config settings. gconf clients now find the server using DBUS. Starting gnome-terminal as root doesn't work even when you have all the gnome bits and pieces running under your account, because DBUS is per-user. executive of summary: We know what is going on. Everything that doesn't work is a consequence of the design. Everything is working as designed, although obviously there are problems with this design. Discussion about the design probably belongs on freedesktop-bugs #17970 (link in the remote bug sidebar). - Workarounds: + Workarounds to use until the bugs are fixed: for the gconfd-not-running case: start gconfd. e.g. add /usr/bin/gnome-settings-daemon to your X session startup script, ahead of any gnome-terminal commands. This applies whatever window manager you happen to be using. (except if you're using Ubuntu's default GNOME desktop, which already starts gconfd itself.) multiple tabs over ssh: use screen(1) $ sudo aptitude install screen screen-profiles # if you don't have it already The default config has unhelpful keybindings. I'm used to ^t as the command key, and F11/F12 as next/previous tab (screen calls them windows). I set up my own .screenrc before screen-profiles was packaged, so I don't know if its examples and samples are good or not. If you insist on displaying a GUI over X11 over ssh, there are other terminal emulators with tabs, e.g. the lighter-weight mrxvt. (be careful, though: it doesn't support UTF-8.) You might also investigate ssh -M for connection sharing. As I understand it, this lets you tunnel multiple sessions over one SSH connection, so only one password prompt... You could presumably get a local gnome-terminal going with ssh connections in each tab. root shells: - use sudo inside a gnome terminal that's running under your own account. sudo -s, sudo -i, sudo su, and sudo bash are all variations on getting a shell running as root. If you don't know which to pick, use sudo -s. Or, better, don't start a root shell, and simply use sudo on the one or two commands that need it. e.g. - $ ls - $ less foo.conf - $ sudo editor foo.conf - (or gksudo editor foo.conf, if your editor of choice is opens it's own window instead of running inside the terminal) - $ ls .. - $ sudo mv foo bar - $ sudo # error permission denied - $ echo 10 | sudo tee /proc/sys/vm/swappiness # sudo tee is a way to accomplish echo 10 file with the file-open happening as root. - - Root is dangerous: a typo could break things much more easily than - without sudo. The fewer things running as root, the better. It's not - usually necessary to run a terminal emulator as root, just things that - use that terminal. Even when you're doing a sysadmin thing, you - probably run lots of info-gathering commands that don't need root. Save - sudo for the commands that need it. + You can use sudo inside a gnome terminal that's running under your own account. sudo -s, sudo -i, sudo su, and sudo bash are all variations on getting a shell running as root. If you don't know which to pick, use sudo -s. Or, better, don't start a root shell, and simply use sudo or gksudo on the one or two commands that need it. This bug is partly that gconf requires DBUS, which breaks some remote- GUI situations, and partly that gnome-terminal just refuses to start without gconf, even though some people have found that it actually works if they comment out that part. Armed with this knowledge, this bug shouldn't be more than a minor inconvenience, esp. if you're not dealing with ssh. (GNU screen takes some time to get used to...) I hope it's ok that I turned this bug's description into a guide on how to deal with it. Please correct any inaccuracies. -- Cannot start gnome-terminal because of gconf error https://bugs.launchpad.net/bugs/328575 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com
[Bug 328575] Re: Cannot start gnome-terminal because of gconf error
BlueSky wrote: Lecturing them on the dangerousity of their ways is just an excuse not to fix the bug. I do not mean to attack you personally, but I just hate it when people say why do you do that anyway? or it's much better if you do it the other way when there is a real bug. Thanks for the comments. You're right, I went way overboard with the lectures against running too much as root, when all that was called for in that space was workarounds that would let people do the things they wanted to. I see how that would give the impression that it's actually the user's fault, not a bug (which is not the case.) I've tried to make it more clear that this should be considered a bug. e.g. Workarounds: - Workarounds to use until the bugs are fixed:. Although I did already try to make it clear that this is still a bug, not just simply the new way that GNOME works. OTOH, unless gnome-terminal will just work without gconf, this bug will probably take a long time to get fixed, since it's the result of the design, not just a problem implementing it correctly. That's what I was trying to make clear, and prepare people for a long wait. It's true that my workarounds for root and remote usage cases are what I do anyway, and I do in fact consider them better than actually running gnome-terminal as root, or remote-displaying it. That's what makes them such great workarounds... (esp. since I'm a command line guy, and I always have gnome-terminal open, and usually have a shell already cd'ed to whatever directory I want to do something in... This is not the case for everybody, e.g. the people who want to start a shell from nautilus. That's fine, use your computer however you want, as long as it's not a security disaster that's going to have your computer infected and trying to crack mine and relaying spam.) Without the big lecture, I'm probably less likely to put people off actually trying anything I suggested. running gnome-settings-daemon is not always an acceptable workaround, since it messes up with gtk+ themes, desktop background, etc Isn't it just providing settings that were configured when you still used GNOME? If you had an empty ~/.gnome* and ~/.gconf*, wouldn't you get the same defaults as when gconfd isn't running at all? (try moving those directories aside before deleting them). I guess really you just need gconfd, which is started by gnome-settings-daemon. Does running /usr/lib/libgconf2-4/gconfd-2 change your themes and fonts? Or only g-s-d? If it's ok, then you could update the workaround to suggest just that, instead of g-s-d. -- Cannot start gnome-terminal because of gconf error https://bugs.launchpad.net/bugs/328575 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 328575] Re: Cannot start gnome-terminal because of gconf error
The main purpose of this message is to point out that this is NOT just a su issue. Right, it's an X11-without-gconf issue. See my post, above, for my workaround for fluxbox. Like you, I use fluxbox and gnome-terminal. It's a simple matter of getting gconf running. I do it by running gnome-settings-daemon in my .fluxbox/startup. (startx does start DBUS, so gnome stuff can find itself once started.) BTW, ctrl-alt-f1 is not the simplest way. There are other viable terminal emulators you can start from the menu: Applications-Terminal Emulators-anything but gnome terminal. If you don't have any others installed, aptitude install xterm It's not very nice, but it works well as a failsafe. Or start any other GUI program that lets you run shell commands. e.g. emacs, and M-x shell. (and start gnome-settings-daemon that way.) -- Cannot start gnome-terminal because of gconf error https://bugs.launchpad.net/bugs/328575 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 328575] Re: Cannot start gnome-terminal because of gconf error
** Description changed: I cannot start gnome-terminal. If I open an xterm and start gnome- terminal from the command line, here is what I get: - $ gnome-terminal + $ sudo gnome-terminal Failed to contact the GConf daemon; exiting. + (original report didn't have sudo in this command, but a later comment by the submitter amended this.) $ ps ax | grep gconf 3956 pts/0R+ 0:00 grep gconf 6643 ?S 0:00 /usr/lib/pulseaudio/pulse/gconf-helper 6647 ?S 0:06 /usr/lib/libgconf2-4/gconfd-2 This is in Jaunty Alpha 4 with all updates current as of 12 Feb. + + This bug is now understood. Read all the comments (or at least try + some text searches) before adding your own, because a lot of things have + already been covered. + + summary of some stuff posted in comments: + gnome-terminal on purpose refuses to start if it can't connect to gconfd to get its config settings. + + gconf clients now find the server using DBUS. Starting gnome-terminal + as root doesn't work even when you have all the gnome bits and pieces + running under your account, because DBUS is per-user. + + executive of summary: We know what is going on. Everything that doesn't + work is a consequence of the design. Everything is working as designed, + although obviously there are problems with this design. Discussion + about the design probably belongs on freedesktop-bugs #17970 (link in + the remote bug sidebar). + + Workarounds: + for the gconfd-not-running case: + start gconfd. e.g. add /usr/bin/gnome-settings-daemon to your X session startup script, ahead of any gnome-terminal commands. This applies whatever window manager you happen to be using. (except if you're using Ubuntu's default GNOME desktop, which already starts gconfd itself.) + + multiple tabs over ssh: + use screen(1) + $ sudo aptitude install screen screen-profiles # if you don't have it already + The default config has unhelpful keybindings. I'm used to ^t as the command key, and F11/F12 as next/previous tab (screen calls them windows). I set up my own .screenrc before screen-profiles was packaged, so I don't know if its examples and samples are good or not. + If you insist on displaying a GUI over X11 over ssh, there are other terminal emulators with tabs, e.g. the lighter-weight mrxvt. (be careful, though: it doesn't support UTF-8.) + + You might also investigate ssh -M for connection sharing. As I + understand it, this lets you tunnel multiple sessions over one SSH + connection, so only one password prompt... You could presumably get a + local gnome-terminal going with ssh connections in each tab. + + root shells: + use sudo inside a gnome terminal that's running under your own account. sudo -s, sudo -i, sudo su, and sudo bash are all variations on getting a shell running as root. If you don't know which to pick, use sudo -s. Or, better, don't start a root shell, and simply use sudo on the one or two commands that need it. e.g. + $ ls + $ less foo.conf + $ sudo editor foo.conf + (or gksudo editor foo.conf, if your editor of choice is opens it's own window instead of running inside the terminal) + $ ls .. + $ sudo mv foo bar + $ sudo # error permission denied + $ echo 10 | sudo tee /proc/sys/vm/swappiness # sudo tee is a way to accomplish echo 10 file with the file-open happening as root. + + Root is dangerous: a typo could break things much more easily than + without sudo. The fewer things running as root, the better. It's not + usually necessary to run a terminal emulator as root, just things that + use that terminal. Even when you're doing a sysadmin thing, you + probably run lots of info-gathering commands that don't need root. Save + sudo for the commands that need it. + + This bug is partly that gconf requires DBUS, which breaks some remote- + GUI situations, and partly that gnome-terminal just refuses to start + without gconf, even though some people have found that it actually works + if they comment out that part. + + Armed with this knowledge, this bug shouldn't be more than a minor + inconvenience, esp. if you're not dealing with ssh. (GNU screen takes + some time to get used to...) + + I hope it's ok that I turned this bug's description into a guide on how + to deal with it. Please correct any inaccuracies. -- Cannot start gnome-terminal because of gconf error https://bugs.launchpad.net/bugs/328575 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 328575] Re: Cannot start gnome-terminal bcause of gconf error
Thanks to everyone for confirming that this happens under normal circumstances. No further confirmation is required. Just subscribe to the bug without making a post, unless you have anything new to add. (Correct me if I'm overstepping here, Ubuntu maintainers.) Further posts on this thread should be about what to do about this, or ideas for how the relevant programs and libraries should behave so gnome-terminal can start when gnome-settings-daemon isn't already running. I've always found it kind of messy the way KDE programs start daemons that clutter your terminal with log messages even after the first KDE program (that started them) has exitted. If it wasn't for the messages on stdout or stderr, it wouldn't be so bad. Obviously, you don't want to hide the messages either, so I don't really see any good solution. I guess it's something you get used to as a user, though. I start most of my long-lived GUI stuff from one screen(1) window, so only one window will get clogged with messages if any of them feel like spewing. So it would probably work to start any required daemons when they're needed. I don't see any obvious solution, if there's no way around requiring a daemon. Hmm, possibly if there's no daemon, read settings from a file yourself? Using the same code (in a library) that the daemon uses to get the settings? This might have to be read-only to avoid danger in case the daemon does start while gnome-terminal is running... -- Cannot start gnome-terminal bcause of gconf error https://bugs.launchpad.net/bugs/328575 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 328575] Re: Cannot start gnome-terminal bcause of gconf error
I noticed this problem because my .fluxbox/startup wasn't starting my gnome-terminal anymore. (that's a shell script run by startfluxbox that runs some X clients then execs /usr/bin/fluxbox. I put some of my startup stuff in it.) If I run /usr/bin/gnome-settings-daemon before gnome-terminal, then it works. If I leave that commented out, gnome-terminal refuses to start, with the Failed to contact the GConf daemon; exiting. error message everyone's reporting. Obviously when gnome-terminal is run as root, there's no root-owned gconf daemon for it to talk to. (BTW, why would you want to do that? sudo -s not good enough?) I already had /usr/bin/gnome-settings-daemon in my fluxbox startup, but I used to run it as gnome-terminal --geometry=132x30 --tab-with-profile=default --tab-with-profile=default --tab-with-profile=default (sleep 1 setxkbmap -option ctrl:nocaps xset r rate 195 60 /usr/bin/gnome-settings-daemon ) I use sleep to spread out the disk I/O load of starting X a bit. gnome-terminal used to load, then after gnome-settings-daemon loaded, the font would switch to my configured font. But now my desktop was coming up with no terminal. gnome-terminal would work later, since by then gnome-settings-daemon would be started. So now I do /usr/bin/gnome-settings-daemon (sleep 1 gnome-terminal --geometry=132x30 --tab-with-profile=default --tab-with-profile=default --tab-with-profile=default ) (sleep 1 setxkbmap -option ctrl:nocaps xset r rate 195 60 ) and my X startup script should start everything nicely. If gnome stuff is going to require daemons, they should start them automatically if they're not running. KDE stuff does that. If GNOME can come up with a convincing reason why this is a bad idea, then this is not a bug. Although it had better be documented, and the error message should suggest starting gnome-settings-daemon. So IMHO something has to change before this bug can be closed. -- Cannot start gnome-terminal bcause of gconf error https://bugs.launchpad.net/bugs/328575 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 328575] Re: Cannot start gnome-terminal bcause of gconf error
forgot to say that this is maybe not gconf2's bug, but rather a bug in things that use it. (esp. if the fix is a more useful error message.) -- Cannot start gnome-terminal bcause of gconf error https://bugs.launchpad.net/bugs/328575 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 277988] [NEW] man page not parseable for man -k
Public bug reported: Binary package hint: gucharmap man -k guchar gucharmap (1)- (unknown subject) I couldn't find it when I was looking for it earlier with man -k unicode and man -k character, etc. I don't know nroff so I can't tell what's wrong with the page that makes it not parseable by the indexer, sorry. ** Affects: gucharmap (Ubuntu) Importance: Undecided Status: New -- man page not parseable for man -k https://bugs.launchpad.net/bugs/277988 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gucharmap in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 155655] Re: gnome-terminal does not honor display setting when using xephyr-xserver
I tried to reproduce this, but it works for me on a pre-Intrepid system. I'm going to mark this fix-released, rather than invalid, on the assumption that there was something going on. If anyone can reproduce this, or knows exactly what the submitter meant by only the first gnome-terminal honors the display setting they should re-open this bug. It sounds like Heikki is saying that one of the gnome-terminals opens outside Xephyr, even though DISPLAY=:1. That sounds very unlikely, unless gnome-terminal talks to an already-running gnome-terminal that it found with something other than X, and asked it to open a new window. I tested on a dual-core system with hot caches, and gnome-terminal running outside Xephyr, so there was plenty of chance for any race conditions to happen. Both gnome-terminals appear at opposite corners of the Xephyr window. The combined stdout/stderr of it all is: Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! unrecognised device identifier! (EE) config/hal: NewInputDeviceRequest failed unrecognised device identifier! (EE) config/hal: NewInputDeviceRequest failed unrecognised device identifier! (EE) config/hal: NewInputDeviceRequest failed Failed to retrieve terminal server from activation server ** Changed in: gnome-terminal (Ubuntu) Status: New = Fix Released -- gnome-terminal does not honor display setting when using xephyr-xserver https://bugs.launchpad.net/bugs/155655 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 105538] Re: Setting capslock to control in gnome keyboard preferences leaves capslock stuck on
MountainX, you don't need sudo in /etc/rc.local. It runs as root on bootup, like all init scripts. Are you sure your loadkeys method even works? loadkeys is a totally different way to change your keymap: It changes the Linux kernel keymap. I though X put the kbd in raw mode, and got keycodes which weren't affected by Linux's keymap, but maybe I'm remembering wrong or it's changed in the few years since I've used loadkeys instead of just xkb options. I don't think loadkeys even accepts the same syntax as xmodmap; loadkeys(1) and keymaps(5) don't say anything about add lines. The easiest way to swap ctrl and caps (for X11, doesn't affect the text consoles like loadkeys) is to set the xkb option ctrl:swapcaps. The defaults can be set in xorg.conf, or you could arrange for your X session startup scripts to include setxkbmap -option ctrl:swapcaps. I like having my capslock as an extra control (ctrl:nocaps), since some of muscle memories send my finger to the key labeled Ctrl, but capslock is right there on the home row so it's easier to reach, and where Control is on e.g. Sun and original VT100 keyboards. :) Plus, I find the Caps Lock feature useless and annoying. Section InputDevice Identifier Generic Keyboard Driver kbd # Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout us Option XkbOptionsctrl:nocaps Option Autorepeat200 40 #Ubuntu default: lv3:ralt_switch ISO level 3 shift EndSection Anyway, none of this has anything to do with the bug report, which was that if caps-lock is on _when_ you enable ctrl:nocaps (either with setxkbmap or with gnome), you won't be able to turn caps-lock off again, because you don't have a caps-lock key. This has happened to me, and I had to re-enable capslock, turn off capslock, then re-do the setting. (setxkbmap -option '' clears all options, BTW. Get that into your command history before you try to test this, unless you really like clicking your mouse. setxkbmap -print is interesting...) Strangely, X turns off the capslock LED when you hit capslock while ctrl:nocaps is set. If you hit numlock a couple times, it will sort itself out and eventually display the correct set of LEDs. I was going to say this isn't a gnome-keyboard-preferences bug, since it's the same problem when you use setxkbmap. But then I realized that I couldn't imagine anybody wanting caps-lock to be stuck on, so it would be a nice feature for g-k-p to turn off caps-lock if it's on before applying any setting that leaves the keyboard without a caps-lock key. That would make it more than a straight GUI equivalent of setxkbmap (with persistence, now that that works properly...) The X people probably wouldn't see it as a bug, either. They probably wouldn't be willing to make setting xkb options have side effects, like turning off caps-lock, since you never know what weird things people might want. GNOME should be putting the user-friendly do what almost- everyone-wants wrapping on top of thing, vs. the direct uncooked interface you get with setxkbmap. OTOH, I personally would like it if setxkbmap -option ctrl:nocaps turned off caps-lock, just in case. e.g. maybe put that in a script you can run with a mouse click, if you're using some other window manager. I can't think of any situation where I'd want to cripple a console by leaving it stuck in caps-lock on mode. Although you can hold shift to reverse caps-lock, so you could type setxkbmap, or anything else in lower case, unless that feature was disabled (with another xkb option, I think). BTW, leaving caps-lock on is an easy mistake to make (once, anyway), because turning it on when you wanted ctrl (if that's the layout you're used to) is what might make you run g-k-p in the first place, before you touch the keyboard again. (That's what I did.) -- Setting capslock to control in gnome keyboard preferences leaves capslock stuck on https://bugs.launchpad.net/bugs/105538 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 252174] Re: gvfsd-trash crashed with SIGSEGV in g_main_context_dispatch()
I hit this on a clean boot of the Intrepid alpha5 desktop i386 livecd. (from a USB drive with isoscan/filename=...) It looks identical to Steve's original report, except mine receives the segv in g_main_context_prepare(). I also get segvs in fast-user-switcher-applet whenever I click on it. It looks like https://bugs.launchpad.net/ubuntu/+source/fast-user-switch-applet/+bug/262532 The stack trace is 0x08056366 in ?? () ... (3 more times, with different addresses that I'm not going to type out) 0xb7881cda in g_cclosure_marshal_VOID__OBJECT () from /usr/lib/libgobject-2.0.so.0 g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 -- gvfsd-trash crashed with SIGSEGV in g_main_context_dispatch() https://bugs.launchpad.net/bugs/252174 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is the registrant for gvfs. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 175960] Re: clock appears to be wrong dialog prevents gnome session from starting
It's fixed in Hardy. The time-admin gui runs with root privs, so I can set the clock and then get to the normal gnome desktop. -- clock appears to be wrong dialog prevents gnome session from starting https://bugs.launchpad.net/bugs/175960 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-session in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 251002] [NEW] man page wrong about default text encoding for pdftotext
Public bug reported: The man page for pdftotext(1) says -enc defaults to Latin1, but my testing shows that I get identical output with no -enc and with -enc UTF-8. -enc Latin 1 gives different output. I'm using a French PDF, and viewing the text with less(1). In an LANG=en_CA xterm, the -enc Latin1 text looks right. In a LANG=en_CA.utf8 gnome-terminal, the default/-enc UTF-8 output looks right. When it's mismatched, you see an inverse-video question-mark sort of glyph, or less's highlighting of control characters, depending on what locale less is using. xpdfrc(5) says the default for textEncoding is Latin1. pdftotext(1) says this config option corresponds to -enc. Anyway, UTF-8 output seems to work properly, it's just the documentation that says it's not the default. ** Affects: poppler (Ubuntu) Importance: Undecided Status: New -- man page wrong about default text encoding for pdftotext https://bugs.launchpad.net/bugs/251002 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to poppler in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 190227] Re: ia32 apps look for libs on the wrong place
Mesa in ia32-libs has the same problem. ~/bin32/gears is /usr/lib/xscreensaver/gears from xscreensaver on an ia32 Debian Etch system, IIRC. Any 32bit openGL program, even medibuntu's googleearth package, is affected. $ LIBGL_DEBUG=verbose MESA_DEBUG=1 ~/bin32/gears libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0) libGL: OpenDriver: trying /usr/lib/dri/i965_dri.so libGL error: dlopen /usr/lib/dri/i965_dri.so failed (/usr/lib/dri/i965_dri.so: wrong ELF class: ELFCLASS64) libGL error: unable to load driver: i965_dri.so (runs with software rendering) Fortunately, mesa has an env var for the driver path: $ LIBGL_DEBUG=verbose MESA_DEBUG=1 LIBGL_DRIVERS_PATH=/usr/lib32/dri ~/bin32/gears libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0) libGL: OpenDriver: trying /usr/lib32/dri/i965_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::00:02.0 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable (runs with hardware rendering) -- ia32 apps look for libs on the wrong place https://bugs.launchpad.net/bugs/190227 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gtk+2.0 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 175960] clock appears to be wrong dialog prevents gnome session from starting
Public bug reported: Binary package hint: gnome-control-center I'm not sure this is the right package: maybe gnome-session is really at fault here. I have an old AMD K7 machine with a probably-dead CMOS battery, so it often boots up with the hw clock set to the year 2000. I just put Ubuntu Gutsy (i386) onto it. After logging in through gdm (or booting from the Gutsy live CD), Ubuntu's default desktop session pops up a dialog that reads: The computer clock appears to be wrong ... Ignore / Adjust the Clock. All is well if I select Ignore. However, selecting adjust fails: You get a dialog that says: The configuration could not be loaded You are not allowed to access the system configuration. [close] After closing the dialog, it just sits there doing nothing, with the orange background and a mouse cursor, but _nothing_ else. All I can do is switch to a text console to debug it: gnome-settings-daemon is still running. Neither x-window-manager nor metacity are running. Maybe gnome-session is waiting for gnome-settings to exit... In case it matters, hw is Athlon (original) 650MHz, 256MB RAM, ATI AIW Radeon 7200 (32MB RAM) plugged into a CRT that supports DDC properly, so that's all good. IDE hard drive, XFS root filesystem (yes, I had to install grub manually). An ne2kpci ethernet card is installed, but NetworkManager doesn't even try to bring it up because it can't detect whether there is a link. (This is a separate bug that I'll report...) So the machine has eth0 UP BROADCAST RUNNING MULTICAST, but with no IP. netstat doesn't show any socket activity, so I don't think anything's just waiting for a net timeout. ** Affects: gnome-control-center (Ubuntu) Importance: Undecided Status: New -- clock appears to be wrong dialog prevents gnome session from starting https://bugs.launchpad.net/bugs/175960 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-control-center in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 175960] Re: clock appears to be wrong dialog prevents gnome session from starting
just noticed my .xsession-errors contains: (process:12519): Gtk-WARNING **: This process is currently running setuid or setgid. This is not a supported use of GTK+. You must create a helper program instead. For further details, see: http://www.gtk.org/setuid.html Refusing to initialize GTK+. (process:12523): Gtk-WARNING **: This process is currently running setuid or setgid. This is not a supported use of GTK+. You must create a helper program instead. For further details, see: http://www.gtk.org/setuid.html Refusing to initialize GTK+. /etc/gdm/Xsession: Beginning session setup... SESSION_MANAGER=local/quixote:/tmp/.ICE-unix/12516 processes 12523 and 12519 are not running any more (at the empty screen stage.) -- clock appears to be wrong dialog prevents gnome session from starting https://bugs.launchpad.net/bugs/175960 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-control-center in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 135680] Re: evince chokes on absolute paths that include a #
On Mon, Sep 03, 2007 at 03:09:41PM -, Sebastien Bacher wrote: is that specific to evince? or do you have similar issues with other GNOME softwares? AFAICT, only evince has this problem. bluefish, eog, file-roller, gedit and ghex2 are all fine on symlinks on /net/llama, and don't make copies of things in /tmp. I only have them installed because Ubuntu-desktop depends on them; I'm kind of a crusty command-line curmudgeon, so I use fluxbox on most of my desktops, not metacity+nautilus+... :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BC -- evince chokes on absolute paths that include a # https://bugs.launchpad.net/bugs/135680 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 135680] Re: evince chokes on absolute paths that include a #
Launching from Nautilus shows the same problem for me. You probably need an NFS mount, or maybe even an autofs-mounted NFS mount, to reproduce this. Like I said, it only happens in /net for me. I just tried copying my file to bar.pdf. Then evince /net/llama/home/peter/bar.pdf works. (It makes a copy in /tmp/evince-8626/document-5-bar.pdf). I tried ln -s ACTInc_Quote#1722076.2.pdf foo.pdf, then evince /net/llama/home/peter/foo.pdf fails, with the message Unable to open document Unhandled MIME type: application/octet-stream /tmp/evince-8626 contains lrwxrwxrwx 1 peter peter 26 2007-08-30 16:28 document-6-foo.pdf - ACTInc_Quote#1722076.2.pdf (i.e. it copied the symlink, and the symlink is broken because it is a relative link.) And sorry, I forgot I wasn't using reportbug... I'm running AMD64 feisty (with gutsy's kernel, but I don't think that's relevant.) -- System Information: Debian Release: 4.0 APT prefers feisty-updates APT policy: (980, 'feisty-updates'), (980, 'feisty-security'), (980, 'feisty-proposed'), (980, 'feisty'), (500, 'gutsy'), (500, '... Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-10-generic Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages evince depends on: ii gconf22.18.0.1-0ubuntu1 GNOME configuration database syste ii gs-esp-x 8.15.4.dfsg.1-0ubuntu1 The Ghostscript PostScript interpr ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.18.0-0ubuntu1The ATK accessibility toolkit ii libbonobo2-0 2.18.0-0ubuntu1Bonobo CORBA interfaces library ii libbonoboui2-02.18.0-0ubuntu1The Bonobo UI library ii libc6 2.5-0ubuntu14 GNU C Library: Shared libraries ii libcairo2 1.4.2-0ubuntu1 The Cairo 2D vector graphics libra ii libdbus-1-3 1.0.2-1ubuntu4 simple interprocess messaging syst ii libdbus-glib-1-2 0.73-1 simple interprocess messaging syst ii libdjvulibre153.5.17-3ubuntu2Runtime support for the DjVu image ii libfontconfig12.4.2-1ubuntu1 generic font configuration library ii libfreetype6 2.2.1-5ubuntu1.1 FreeType 2 font engine, shared lib ii libgconf2-4 2.18.0.1-0ubuntu1 GNOME configuration database syste ii libglade2-0 1:2.6.0-3 library to load .glade files at ru ii libglib2.0-0 2.12.11-0ubuntu1 The GLib library of C routines ii libgnome-keyring0 0.8.1-0ubuntu1 GNOME keyring services library ii libgnome2-0 2.18.0-0ubuntu1The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-3ubuntu2A powerful object-oriented display ii libgnomeui-0 2.17.92-0ubuntu1 The GNOME 2 libraries (User Interf ii libgnomevfs2-01:2.18.1-0ubuntu1 GNOME virtual file-system (runtime ii libgtk2.0-0 2.10.11-0ubuntu3 The GTK+ graphical user interface ii libice6 2:1.0.3-1build1X11 Inter-Client Exchange library ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libkpathsea4 3.0-27ubuntu1 path search library for teTeX (run ii liblaunchpad-inte 0.1.13 library for launchpad integration ii libnautilus-exten 1:2.18.1-0ubuntu1 libraries for nautilus components ii liborbit2 1:2.14.7-0ubuntu1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.16.2-0ubuntu1Layout and rendering of internatio ii libpng12-01.2.15~beta5-1ubuntu1 PNG library - runtime ii libpoppler1 0.5.4-0ubuntu8.1 PDF rendering library ii libpoppler1-glib 0.5.4-0ubuntu8.1 PDF rendering library (GLib-based ii libpopt0 1.10-3build1 lib for parsing cmdline parameters ii libsm62:1.0.2-1build1X11 Session Management library ii libstdc++64.1.2-0ubuntu4 The GNU Standard C++ Library v3 ii libtiff4 3.8.2-6Tag Image File Format (TIFF) libra ii libx11-6 2:1.1.1-1ubuntu3 X11 client-side library ii libxcursor1 1:1.1.8-1 X cursor management library ii libxext6 2:1.0.3-1build1X11 miscellaneous extension librar ii libxfixes31:4.0.3-1 X11 miscellaneous 'fixes' extensio ii libxi62:1.1.0-1build1X11 Input extension library ii libxinerama1 2:1.0.1-4build1X11 Xinerama extension library ii libxml2 2.6.27.dfsg-1ubuntu3 GNOME XML library ii libxrandr22:1.2.0-3ubuntu1 X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii zlib1g1:1.2.3-13ubuntu4 compression library - runtime evince recommends no packages. -- evince chokes on absolute paths that include a # https://bugs.launchpad.net/bugs/135680 You received this
[Bug 135680] evince chokes on absolute paths that include a #
Public bug reported: Binary package hint: evince evince './ACTInc_Quote#1722076.2.pdf' works evince '/net/llama/home/peter/ACTInc_Quote#1722076.2.pdf' pops up a dialog that says Unable to open document The local file URI 'file:/tmp/evince-8626/document-0-ACTInc_Quote#1722076.2.pdf' may not include a '#' It has copied the file to file to it's /tmp directory with a changed filename. [EMAIL PROTECTED]:~$ cmp '/net/llama/home/peter/ACTInc_Quote#1722076.2.pdf' /tmp/evince-8626/document-0-ACTInc_Quote [EMAIL PROTECTED]:~$ echo $? 0 The copying seems kind of unnecessary. If I give a program a path in /net, I expect it to access it the same as a path in /home. In this case, my PDF is tiny, so it didn't matter whether it was cached or not. But maybe there should be a URI other than file:/ that means to cache to /tmp. If I wanted files pre-cached, I'd go find a FUSE filesystem that did that, or something. ** Affects: evince (Ubuntu) Importance: Undecided Status: New -- evince chokes on absolute paths that include a # https://bugs.launchpad.net/bugs/135680 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for evince in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 135680] Re: evince chokes on absolute paths that include a #
oh yeah, IIRC once evince is running, use open from the menu and browsing to the /net path works with no problem. And this is mis-titled, because the problem only happens on /net (or maybe any NFS mount). evince /home/peter/... is ok. -- evince chokes on absolute paths that include a # https://bugs.launchpad.net/bugs/135680 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for evince in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 44958] Re: Use p7zip for RAR archives?
I checked out the situation on my new AMD64 Edgy system. unrar-free can't even extract uncompressed files from rar archives created with rar 3.0. 7z can get the uncompressed files (method m0g), but can't extract the compressed files (e.g. method m3g). So it does look like 7z is better. unrar (non-free) is available (now, if it wasn't before) in multiverse, and works even on compressed rar 3.0 files (e.g. v2.9, compression method m3g). [EMAIL PROTECTED]:~$ file /usr/bin/unrar /usr/bin/unrar: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped unrar is non-free, but open source, so it should be available on any arch. Still, using 7z for Free rar support would be an improvement. -- Use p7zip for RAR archives? https://launchpad.net/bugs/44958 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
