[Bug 246325] need LANGUAGE settings for translation fallbacks
by Red Hat Bugzilla
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.
14 years, 3 months
[Bug 246325] need LANGUAGE settings for translation fallbacks
by Red Hat Bugzilla
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.
14 years, 3 months
[Bug 246325] need LANGUAGE settings for translation fallbacks
by Red Hat Bugzilla
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.ht...).
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.
14 years, 3 months
[Bug 192868] multiple issues with nVidia MCP51 HDA sound card on Gigabyte GA-K8N51GMF-9 mainboard
by Red Hat Bugzilla
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.
14 years, 3 months
[Bug 191506] i82875p_edac spitting EDAC errors
by Red Hat Bugzilla
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.
14 years, 3 months
[Bug 191506] i82875p_edac spitting EDAC errors
by Red Hat Bugzilla
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.
14 years, 3 months
[Bug 186527] Startup hangs at "starting system message bus" if ldaps authentication enabled in firstboot
by Red Hat Bugzilla
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.
14 years, 3 months
[Bug 243541] default encoding is ascii, should be UTF-8, produces exceptions for i18n applications
by Red Hat Bugzilla
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.
14 years, 3 months