[Bug 789333] Re: users-admin crashes on start because of mixed GTK2 and 3 symbols
@pitti: Are you sure that all flavours of Ubuntu (Ubuntu, Kubuntu, Xubuntu and Lubuntu) include the new accountsservice/gnome-control- center in Oneiric? Would their doing so noticeably increase disk or memory footprint by requiring other depedencies also be installed by default? If in fact any of the official-but-non-default flavours of Ubuntu still need to use gnome-system-tools, then I submit that this *is* in fact a release critical bug for those flavours and should be accorded appropriately high priority and upgraded back to High. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-system-tools in Ubuntu. https://bugs.launchpad.net/bugs/789333 Title: users-admin crashes on start because of mixed GTK2 and 3 symbols To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/789333/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 821812] Re: time-admin crashed with signal 5 in g_option_context_parse()
** Visibility changed to: Public -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-system-tools in Ubuntu. https://bugs.launchpad.net/bugs/821812 Title: time-admin crashed with signal 5 in g_option_context_parse() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/821812/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 706436] Re: Safely remove drive is not safe for SD card readers
@Anakin Starkiller: I tested with the latest available kernel for Ubuntu 10.04.1 LTS. This is a supported release until April 2013 according to https://wiki.ubuntu.com/Releases . (1) How would a newer kernel know that a device is lying about whether it is removable or not? (2) Is there reason to believe it is fixed in 2.6.32-28-generic ? (3) Are you aware of a newer kernel I should be using with this release of Ubuntu, that may solve this issue? I'm not eager to upgrade a stable working machine just to test this, but I'm interested to know where any such "newer kernel" might be found. Thanks. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in ubuntu. https://bugs.launchpad.net/bugs/706436 Title: Safely remove drive is not safe for SD card readers -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 504440] Re: sd card "safely remove drive" kills reader device
David Tombs wrote: > how about opening up a new bug for the text change? > Trying to transform this bug into a UI change might create too much > confusion. :) OK. There is also bug #404185 which seems highly relevant to all of this. I'm a little concerned about having too many bugs all related to the same underlying issue, that of internal devices which appear to the OS as external, and so can be "safely removed" in Nautilus -- which is not in fact safe, and kills them! >From a user perspective, this is one issue. How we address it (kernel, UI, documentation, all three, ...) does not change that. Anyway, bug #706436 now exists, against nautilus, let's see what happens :) -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gvfs in ubuntu. https://bugs.launchpad.net/bugs/504440 Title: sd card "safely remove drive" kills reader device -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 706436] Re: Safely remove drive is not safe for SD card readers
-- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in ubuntu. https://bugs.launchpad.net/bugs/706436 Title: Safely remove drive is not safe for SD card readers -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 706436] [NEW] Safely remove drive is not safe for SD card readers
Public bug reported: Binary package hint: nautilus RELEASE OF UBUNTU: Description: Ubuntu 10.04.1 LTS Release: 10.04 VERSION OF PACKAGE: nautilus: Installed: 1:2.30.1-0ubuntu1.1 Candidate: 1:2.30.1-0ubuntu1.1 Version table: *** 1:2.30.1-0ubuntu1.1 0 500 http://mirrors.us.kernel.org/ubuntu/ lucid-updates/main Packages 100 /var/lib/dpkg/status 1:2.30.0-0ubuntu4 0 500 http://mirrors.us.kernel.org/ubuntu/ lucid/main Packages STEPS TO REPRODUCE: (1) Insert SD card (2) In nautilus, right click on the card and click on "Safely remove drive". (3) Remove and then re-insert SD card. WHAT I EXPECTED TO HAPPEN: SD card should be prepared for removal, but inserting it or another SD card after that should work. WHAT HAPPENED INSTEAD: SD card reader is left powered down and not on the USB bus, so new SDcard insertions are not seen by the system at all. DESCRIPTION: USB connected SD card readers and similar devices appear to the OS as being "external" or "removable" devices. This causes Nautilus to provide a right-click context menu item currently named "Safely remove drive". Using that item triggers a call to DriveDetatch() which powers down the device and removes it from the USB bus. At this point, there is no way to use the device again until a reboot. Attempts to handle this at lower technical kernel/gvfs layers have been only partially successful, in that users continue to follow Windows- derived "right-click, Safely remove" UI actions and so accidentally disable their devices. Since clearly, in this situation, clicking on "Safely remove drive" is not at all safe (!), it would seem appropriate to rename this menu item to something less likely to be used accidentally by novice users who expect it to be safe. SUGGESTED WORDING CHANGE: One possible wording might be "Power down external device". This is unlikely to be mentally associated with the Windows "Safely remove" wording, and also makes it clear that this is intended for use with an *external* device, so hopefully fewer users will try it on a device that is in fact internal to their machine. HISTORY: This new bug report was triggered by discussion in bug #504440 and created at the suggestion of David Tombs. ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: nautilus 1:2.30.1-0ubuntu1.1 ProcVersionSignature: Ubuntu 2.6.32-27.49-generic 2.6.32.26+drm33.12 Uname: Linux 2.6.32-27-generic x86_64 NonfreeKernelModules: fglrx Architecture: amd64 Date: Sat Jan 22 14:35:28 2011 ProcEnviron: LANGUAGE=en_US:en PATH=(custom, user) LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: nautilus ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug lucid -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in ubuntu. https://bugs.launchpad.net/bugs/706436 Title: Safely remove drive is not safe for SD card readers -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 504440] Re: sd card "safely remove drive" kills reader device
Two ideas: (1) Is there any way to implement a "reconnect device" option, as suggested in comment #7 some months ago? While less than ideal, this would be one way to help people who make this mistake to recover from it themselves. (2) Alternatively, a language change to the context menu, so the item concerned does not say "Safely remove drive", but instead says something closer to "Power down external device" might help, since it then (a) sounds a bit scarier and (b) does not look so similar to the Windows message people are apparently confusing it with. "Won't fix" seems inappropriate to me. If I can't be "fixed" at a deeply technical kernel level, fine, let's come up with a way to minimize the issue at a UI level instead. Not just ignore the problem. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gvfs in ubuntu. https://bugs.launchpad.net/bugs/504440 Title: sd card "safely remove drive" kills reader device -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 223281] Re: locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() )
Per https://wiki.ubuntu.com/SponsorshipProcess I am setting this to be assigned to noone and subscribing ubuntu-main-sponsors . ** Changed in: python2.6 (Ubuntu) Assignee: Ubuntu Desktop Bugs (desktop-bugs) => (unassigned) -- locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() ) https://bugs.launchpad.net/bugs/223281 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 223281] Re: locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() )
Apparently for an SRU we need to get this change accepted into Lucid. So, here is a debdiff for the Lucid version. ** Attachment added: "debdiff for Lucid version of python2.6" http://launchpadlibrarian.net/36106160/python2.6_2.6.4-1ubuntu2.debdiff ** Changed in: python2.6 (Ubuntu) Status: In Progress => Confirmed ** Changed in: ubuntu-translations Status: In Progress => Confirmed -- locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() ) https://bugs.launchpad.net/bugs/223281 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 223281] Re: locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() )
> If you think the fix is ready for release, it might be worth considering it for a stable release update (SRU). > Do you (or anyone else) think you could follow the > https://wiki.ubuntu.com/StableReleaseUpdates > procedure so that this fix can be considered for Karmic? OK. I'll give it a go, possibly working on it over this coming weekend. Because the affected package is an interpreter (Python), I think the standards for what it takes to get an SRU included are very high (a mistake in a Python package would affect many users of many different Python applications!). But I'll follow the process and see what feedback we get. -- locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() ) https://bugs.launchpad.net/bugs/223281 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 223281] Re: locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() )
> Don't know if it's important, but all the version numbers in the debdiff are > 2.6.2 (Jaunty's version), > and the current vesrion in Karmic is 2.6.4. Yes, here is a separate debdiff for the Karmic version. This one is building in my PPA now. Jonathan ** Attachment added: "debdiff for Karmic version" http://launchpadlibrarian.net/35395053/python2.6_2.6.4-0ubuntu2.debdiff -- locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() ) https://bugs.launchpad.net/bugs/223281 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 223281] Re: locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() )
Attached is my initial attempt at a debdiff for the Jaunty python2.6 package. This will hopefully build in my PPA at https://launchpad.net/~jmarsden/+archive/ppa/ overnight. Brave souls who want to download and test the updated Python packages from there are very much welcome to do so. Jonathan ** Attachment added: "Initial attempt at Jaunty debdiff for python2.6" http://launchpadlibrarian.net/35357579/python2.6_2.6.2-0ubuntu2%7Eppa2.debdiff -- locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() ) https://bugs.launchpad.net/bugs/223281 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 223281] Re: locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() )
The upstream patch to locale.py suggested by nicsabacovic does solve the problem when applied to locale.py, at least in Ubuntu 9.10 Karmic. After applying it (by hand, since it is for python 3.x and does not apply to 2.6 using patch), alacarte runs in the sr...@latin and sr_RS locales. debdiff (and packages in my PPA for brave people to test!) will follow shortly, for Jaunty and Karmic, I hope. Jonathan ** Changed in: python2.6 (Ubuntu) Status: Confirmed => In Progress -- locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() ) https://bugs.launchpad.net/bugs/223281 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 306591] Re: Locale settings in shell initialization not used by GNOME session
I am not a GNOME i18n expert, at all. But I do know that if you use GNOME the way it was intended, i18n generally "just works" and you do not need to mess with manually setting locale variables in .bashrc or .dmrc or anywhere else. Set a language at the gdm screen, and when prompted, tell it to make this new language/locale the default for your user, and it adds information to that effect to your ~/.dmrc Then, next time that user logs in, they get that chosen language/locale. Such a user will find that their shell locale is correct, too, when they open up a terminal window. Job done. User does not need to care where the info is stored or how it works. User never edits a ~/.anything file! It just works. I think you are trying to "mess with" the guts of how GNOME does things, and (lacking detailed info on exactly how it works) that attempt is apparently confusing you. Since your end users are unlikely to do this kind of thing, your testing should probably do it the way your users will, for maximum fidelity. For one-time quick tests during development, you can of course always do LC_ALL=whatever LC_TIME=foobar gnomesword & type of things, this sets the locale vars for that one process (and its subprocesses) only. The shell has allowed this for many years, probably decades, and this is not GNOME or Ubuntu specific in any way. If you want to test GNOME menus, then I think you need to be starting GNOME the way end users will, not trying to manually tweak it, if you want the tests to be valid for real life users. Do you really truly need more that this? Is there really a bug here? If so, what exactly is the bug? I'd suggest closing this as NOTABUG at this point. But that's just my opinion. If you have a question (as opposed to a bug), then you could try using LaunchPad "Answers" to ask it, and see if you get a solid answer to it there. It might be good to phrase the question in terms of the user requirement "how do I achieve result X", rather than in terms of the method "how do I get GNOME to read locale settings from shell initialization file Y", for best results. Jonathan -- Locale settings in shell initialization not used by GNOME session https://bugs.launchpad.net/bugs/306591 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to meta-gnome2 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 306591] Re: Locale settings not used by GNOME session
Changing status to incomplete: unclear if this is really a bug, and earlier confirmation from refdoc turned out to be a different issue. ** Changed in: meta-gnome2 (Ubuntu) Status: Confirmed => Incomplete -- Locale settings not used by GNOME session https://bugs.launchpad.net/bugs/306591 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to meta-gnome2 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 306591] Re: Locale settings not used by GNOME session
Andrew: > Jonathan, do you have any idea what may be at fault here? > I'm interested in filing this upstream but I'm not sure which Gnome package > to target. The more I look at this, the more I think there may well be no real bug here at all. My change to the summary line was trying (apparently inadequately, since you undid it!) to suggest that the issue is not really "locale settings not respected by Gnome". Locale settings most definitely *are* respected by Gnome, when they are set in /etc/environment, or when set from the gdm login screen. I have multiple languages installed on this machine (English, French, German and Spanish), and I can log in using any one of them, and get appropriate menus, and clock date/time format, spell checking, etc. Locales *are* being respected. Unlike English, French, German and Spanish, I don't speak any Egyptian Arabic, so I've not tried logging in in that language :) Rephrasing a bit: the issue being reported is (as I understand it, and now we are clear that refdoc's locale issue is clearly not a part of this specific issue): Gnome does not use locale settings which are set in the user's shell initialization file. The question then becomes: Should Gnome in fact examine and use such settings, since Gnome does not itself necessarily use any per-session shell at all! Why would Gnome be expected to look in a user's shell initialization file? Is there documentation out there that says it should or will do so? Especially since Ubuntu 8.10 has the "fast session switching" capability, allowing one to have multiple sessions open (logged in as different users) in different locales, I am not sure there is really much of a case for saying that Gnome *should* be parsing shell initialization files to look for locale settings -- is there? I'm open to hearing the argument that it should really do that, but trying to look at this from the user's viewpoint, I don't (yet?) see why it should. The shell respects the locale settings set in the global environment and its initialization file(s); Gnome respects the locale settings in the global environment and it is own initialization files. (For example, have you considered setting locale-related variables in ~/.xsession, if you want to explore this kind of thing? Maybe in ~/.dmrc ??) Logically, if you are using a GUI, then you set its locale at GUI session startup, just as you would set a shell's locale at shell startup. Each has a different way to specify its initial settings (though of course both respect the global environment). Does this make sense? Jonathan -- Locale settings not used by GNOME session https://bugs.launchpad.net/bugs/306591 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to meta-gnome2 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 306591] Re: Locale settings in ~/.bashrc not used by GNOME session
** Summary changed: - Locale settings not respected in GNOME session + Locale settings in ~/.bashrc not used by GNOME session -- Locale settings in ~/.bashrc not used by GNOME session https://bugs.launchpad.net/bugs/306591 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to meta-gnome2 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 306591] Re: Locale settings not respected in GNOME session
refdoc: Your locale list includes ar_EG.utf8, but not ar_EG. These are two different locales. Please try: # Create and install the ar_EG locale sudo locale-gen ar_EG # Test it LC_ALL=ar_EG locale I think this will fix your issue, which is not the bug described by the submitter, but something else. Jonathan -- Locale settings not respected in GNOME session https://bugs.launchpad.net/bugs/306591 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to meta-gnome2 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 306591] Re: Locale settings not respected in GNOME session
refdoc writes: > export LC_ALL=ar_EG; gnomesword > Error message : (gnomesword:15597): Gtk-WARNING **: Locale not supported by C > library. > Using the fallback 'C' locale. Well, I'd expect that result if the ar_EG locale is in fact not fully and correctly installed on your machine (and that's not exactly a common locale, you must admit). Question #1) Does the shell command locale -a output a list of locales that includes ar_EG ? Question #2) How exactly did you add this locale data (for ar_EG) to your system? I would have expected sudo locale-gen ar_EG but please confirm/correct me on this! I am unable to confirm the issue with the ar_EG locale at all: sudo locale-gen ar_EG LC_ALL=ar_EG locale works for me. At this point, my suspicion is that the bug as originally reported may be related to how early GNOME stuff is started up, and that the corrupted locale issue is some sort of installation issue or problem with the process by which the ar_EG locale was installed onto your system. Jonathan -- Locale settings not respected in GNOME session https://bugs.launchpad.net/bugs/306591 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to meta-gnome2 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 237130] Re: Swahili support broken
It seems that the language-pack-sw* packages (in Hardy at least) simply do not contain Swahili locale data. The file /var/lib/locales/supported.d/sw is an empty file (zero bytes long), unlike all the other files in that directory. So, the locales package and the locale-gen program can't compile a Swahili locale. And by design, you can't persuade gdm to let you select a locale you don't have on your system, so the menus don't include it as a language choice. It might be worth mailing [EMAIL PROTECTED] to see if the language pack maintenance team as a whole has any advice or suggestions? Perhaps the folks you are sending out with a Ubuntu machine can actually help create the missing locale data themselves, and contribute it back to Ubuntu! Jonathan -- Swahili support broken https://bugs.launchpad.net/bugs/237130 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
