triage January 2010

triage@lists.fedoraproject.org

1 participants
50 discussions

[Bug 246325] need LANGUAGE settings for translation fallbacks
by Red Hat Bugzilla 24 Jan '10

24 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=246325 fujiwara <tfujiwar(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tfujiwar(a)redhat.com --- Comment #12 from fujiwara <tfujiwar(a)redhat.com> 2010-01-24 21:11:15 EST --- If you set LANGUAGE in /etc/sysconfig/i18n, GDM loads the system locale. Probably my suggestion is, if $HOME/.i18n exists and $HOME/.dmrc doesn't exist, to load .i18n file. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 246325] need LANGUAGE settings for translation fallbacks
by Red Hat Bugzilla 24 Jan '10

24 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=246325 Jens Petersen <petersen(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |FutureFeature, MoveUpstream Version|12 |rawhide --- Comment #11 from Jens Petersen <petersen(a)redhat.com> 2010-01-24 20:27:00 EST --- (In reply to comment #10) > The LANGUAGE variable can be set in ~/.profile and it would override the LANG > variable gdm sets Right > However I can imagine a user friendly interface for this. During the session > startup GDM reads from ~/.dmrc clauses like: > > LanguageFallback[zu] = xh:af:en_ZA:en > LanguageFallback[ua] = ru We need a table of defaults but not in "~/.dmrc". Of course if users what to override those in "~/.i18n" or "~/.dmrc" that is fine. > And if the current Language preference matches any fallback clause the > corresponding LANGUAGE variable is set up. Though this certainly should be > configured with some gnome utility, not through the GDM welcome screen. > Reasonable defaults (as /etc/skel/.dmrc) are welcome. I think a config tool is a separate issue: the first thing is to setup LANGUAGE currently for the different locales and that could be done by a table in gdm for now anyway and would be a valuable i18n UX improvement. > I think this should be considered as a feature request to upstream. Yep -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 246325] need LANGUAGE settings for translation fallbacks
by Red Hat Bugzilla 24 Jan '10

24 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=246325 Sergey Rudchenko <sergey.rudchenko(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sergey.rudchenko(a)gmail.com --- Comment #10 from Sergey Rudchenko <sergey.rudchenko(a)gmail.com> 2010-01-24 04:03:04 EST --- The LANGUAGE variable can be set in ~/.profile and it would override the LANG variable gdm sets (http://www.gnu.org/software/hello/manual/gettext/The-LANGUAGE-variable.html…) However I can imagine a user friendly interface for this. During the session startup GDM reads from ~/.dmrc clauses like: LanguageFallback[zu] = xh:af:en_ZA:en LanguageFallback[ua] = ru And if the current Language preference matches any fallback clause the corresponding LANGUAGE variable is set up. Though this certainly should be configured with some gnome utility, not through the GDM welcome screen. Reasonable defaults (as /etc/skel/.dmrc) are welcome. Finally a user has a way to set up a fallback list for locale languages. I think this should be considered as a feature request to upstream. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 192868] multiple issues with nVidia MCP51 HDA sound card on Gigabyte GA-K8N51GMF-9 mainboard
by Red Hat Bugzilla 23 Jan '10

23 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=192868 Clinton Work <clinton(a)scripty.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clinton(a)scripty.com --- Comment #24 from Clinton Work <clinton(a)scripty.com> 2010-01-23 18:33:41 EST --- My MCP51 (ALC880) sound was working until one of the last kernel updates in F10. I just upgraded to F12 and the max headphone volume is really low. I tried every setting under preferences sound with no increased volume. lspci -v Definition Audio (rev a2) Subsystem: Micro-Star International Co., Ltd. K8NGM2 series Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at fead0000 (32-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel I have a MSI K8NGM2 motherboard with the integrated ALC880 sound chip. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 247616] gnupg2: gpg-agent autostart, ssh support (RFE)
by Red Hat Bugzilla 23 Jan '10

23 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=247616 --- Comment #24 from Patrick C. F. Ernzer <pcfe(a)redhat.com> 2010-01-23 16:18:27 EST --- (In reply to comment #20) > Created an attachment (id=324470) --> (https://bugzilla.redhat.com/attachment.cgi?id=324470) [details] > Spec file for gpg-agent-startup packages It seems that in F12, gnome, Presession and Postsession have been renamed to mixed caps (/etc/gdm/PostSession and /etc/gdm/PreSession) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 247616] gnupg2: gpg-agent autostart, ssh support (RFE)
by Red Hat Bugzilla 23 Jan '10

23 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=247616 Patrick C. F. Ernzer <pcfe(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pcfe(a)redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 191506] i82875p_edac spitting EDAC errors
by Red Hat Bugzilla 23 Jan '10

23 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=191506 --- Comment #50 from Matthew Marlowe <matt(a)deploylinux.net> 2010-01-23 04:50:49 EST --- It is possible that we are not seeing errors within RHEL5.4 because the kernel 2.6.18-164.11.1.el5PAE appears not to have a module for the i82975. Manually modprobing EDAC_MC provides no real information and I can not see any other mdac modules automatically loaded. If there is a hardware issue, I'd certainly like to know about it, although I suspect we are just seeing a spurious error resulting somehow by the brain deadness of the legacy asus motherboard here. I suspect to boot the fedora 12 live cd, I'll need to find the right option to pass to grub boot prompt to disable the edac module(s). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 191506] i82875p_edac spitting EDAC errors
by Red Hat Bugzilla 23 Jan '10

23 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=191506 Matthew Marlowe <matt(a)deploylinux.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matt(a)deploylinux.net --- Comment #49 from Matthew Marlowe <matt(a)deploylinux.net> 2010-01-23 04:10:27 EST --- Hello, I currently have RHEL5.4 WS running stable on an Asus P5WDG2-WS motherboard. Attempting to boot to a Fedora 12 Live CD generates a constant stream of EDAC errors such that the system becomes unresponsive. Rebooting back to RHEL5.4 and all is fine. The memory tests fine in memtest86 and is workstation class (Kingston ECC w/ Thermal Monitor). No memory errors are reported within RHEL 5.4. Regards, M. Marlowe -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 186527] Startup hangs at "starting system message bus" if ldaps authentication enabled in firstboot
by Red Hat Bugzilla 22 Jan '10

22 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=186527 --- Comment #67 from Andrew McNabb <amcnabb(a)mcnabbs.org> 2010-01-22 17:47:52 EST --- As far as I can tell, having rtkit and pulse in the nss_initgroups_ignoreusers doesn't seem to help. In Fedora 12, it looks like a lot of services are hanging, not just messagebus. I ended up coming up with a great workaround. I created the file /etc/chkconfig.d/slapd with the single line "# chkconfig: - 11 89". This makes slapd start up just after network (before messagebus and a slew of other services). I haven't seen any negative effects yet; is there any reason that this ordering couldn't be the default? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 243541] default encoding is ascii, should be UTF-8, produces exceptions for i18n applications
by Red Hat Bugzilla 22 Jan '10

22 Jan '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=243541 Dave Malcolm <dmalcolm(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |CANTFIX --- Comment #7 from Dave Malcolm <dmalcolm(a)redhat.com> 2010-01-22 11:15:20 EST --- I raised this on the upstream mailing list (python-dev), and a patch to change the tty/non-tty variation (http://bugs.python.org/issue7745) Upstream strongly requested that I not make this change, and I'm going to honor that request; I've withdrawn the feature request mentioned in comment #6. An (over) simplified summary is that the situation is what it is, and that consistency of behavior between different downstream distributions is more important than making changes at this point in the lifecycle of Python 2. Upstream feel that attempting to print a <unicode> instance containing code points > U+007F to a standard stream can be wrong when that stream isn't a terminal, and would prefer that application code was explicit about the encoding to be used and thus fail (I'm not sure I agree with this, but I don't want to diverge from upstream). Unfortunately, this can lead to hidden bugs. One way of ensuring better consistency between the tty/non-tty development/deployment cases is to use the PYTHONIOENCODING environment variable. This value overrides the default encoding of sys.std[in|out|err]; in pseudocode: if PYTHONIOENCODING set: encoding = PYTHONIOENCODING else: if tty: encoding = locale # UTF-8 else: encoding = ascii so that it uses the supplied value in both cases without having this tty/non-tty inconsistency. By setting PYTHONIOENCODING=ascii in the environment, you force Python to use ascii for the encoding of the standard streams, and thus any errors that might occur when deploying the script as a daemon/cronjob will fail immediately during development, rather than during deployment. (Alternatively, you could set PYTHONIOENCODING=UTF-8 during both development and deployment, but that assumption needs to be clearly stated in the appliation's documentation; I haven't tested this latter approach). Closing CANTFIX. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

triage January 2010