Re: Rationalizing X and console keymaps and configuration (was Re: Fedora 18 issues with translations and keymaps)
On Thu, 2013-01-03 at 19:58 +0100, Till Maas wrote: > On Thu, Jan 03, 2013 at 09:59:52AM -0800, Adam Williamson wrote: > > > Oh sure. I guess I need to draw a distinction between what I see as two > > different cases. Which I'm sure you understand but I'm having trouble > > describing clearly. I guess what I'm saying is, if > > there's /etc/keyboard.conf specifying 'KEYBOARD=foo', I should never > > have to pass 'KEYBOARD=foo' as a cmdline to make foo my keyboard layout > > in some case. As things stand I believe I do, for passphrase entry > > during dracut. > > It should also be made the other way round, i.e. if a keyboard layout is > specified at the kernel command line, it should not be necessary to > specify one in a local config file. Then if everything should use the > same keyboard layout, there is only one place to set this instead of > several ones that might diverge unintended. Yeah, in general I think what we really want is the kind of standard nix-y type model where it's really a single configuration item that can be set at various levels which override each other: user & desktop-specific config (e.g. gsettings) overrides... user config (e.g. ~/.config/keyboard.conf) overrides... systemwide config (e.g. /etc/keyboard.conf) overrides... kernel parameter (e.g. keyboard=foo) and all the levels are 'speaking the same language' - using the same layout database and the same config format as far as possible. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rationalizing X and console keymaps and configuration (was Re: Fedora 18 issues with translations and keymaps)
On Thu, Jan 03, 2013 at 09:59:52AM -0800, Adam Williamson wrote: > Oh sure. I guess I need to draw a distinction between what I see as two > different cases. Which I'm sure you understand but I'm having trouble > describing clearly. I guess what I'm saying is, if > there's /etc/keyboard.conf specifying 'KEYBOARD=foo', I should never > have to pass 'KEYBOARD=foo' as a cmdline to make foo my keyboard layout > in some case. As things stand I believe I do, for passphrase entry > during dracut. It should also be made the other way round, i.e. if a keyboard layout is specified at the kernel command line, it should not be necessary to specify one in a local config file. Then if everything should use the same keyboard layout, there is only one place to set this instead of several ones that might diverge unintended. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
Adam Williamson (awill...@redhat.com) said: > In addition to those bugs, we have fairly significant regressions in the > completeness of anaconda translations between Fedora 16 and Fedora 18 > (the numbers for F17 for some languages are weird - a lot of languages > show 55% completion for F17 but 90-100% for F16, which seems bogus, as > I'm sure things didn't change that much between F16 and F17, so I'm just > using the F16 numbers. I assume there's some weirdness that explains the > odd 55% numbers for F17, but if not, hey, F17 was kinda boned too...): > > Language F16 F18 > Finnish 93% 75% > Indonesian100%33% > Kannada 94% 33% > Oriya 94% 27% > Telugu94% 32% > Bengali (India) 93% 33% > Portuguese100%36% > Persian 95% 27% > Malayalam 78% 20% > NorwegianBokmal 92% 55% > Bengali 93% 33% > Sinhala 93% 27% > Serbian 81% 23% > Serbian(Latin)81% 23% > Hebrew83% 22% > Catalan 68% (98% F17) 25% > Latvian 88% 20% > Greek 68% 21% > Turkish 79% 21% > Maithili 67% 18% > Asturian 85% 24% > > (from https://fedora.transifex.com/projects/p/anaconda/ ) When we approved the anaconda bits in FESCo, full translation was marked as an item that was scheduled for F19. We can go back on that now, but the knowledge that things were not fully translated (and weren't going to be) was something that was known at the time. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
- Original Message - > On Thu, 2013-01-03 at 10:09 -0500, Jaroslav Reznik wrote: > > > > * https://bugzilla.redhat.com/show_bug.cgi?id=891487 - anaconda > > > doesn't > > > seem to manage to offer all the keyboard layouts it could do, and > > > some > > > of the ones it's missing are somewhat important > > > > Already accepted as NTH, Vratislav does not have idea why some > > layouts > > > Already accepted as NTH, partial patch available. For the rest - > > Neither is accepted. They are both proposed. (Yes, using > 'F18-accepted' > as the alias for the NTH blocker bug and 'accepted' as the word we > use > to describe an 'approved' blocker or NTH was a really bad idea. I > know. :>) Ops, for 1000th time I got trapped... Sorry - let's take a look on this ones then soon. Jaroslav > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > test mailing list > t...@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rationalizing X and console keymaps and configuration (was Re: Fedora 18 issues with translations and keymaps)
On Thu, 2013-01-03 at 10:26 -0800, John Reiser wrote: > On 01/03/2013 09:59 AM, Adam Williamson wrote: > > if > > there's /etc/keyboard.conf specifying 'KEYBOARD=foo', [then] I should never > > have to pass 'KEYBOARD=foo' as a cmdline to make foo my keyboard layout > > in some case. As things stand I believe I do, for passphrase entry > > during dracut. > > The dracut emergency shell can be activated before achieving visibility > of /etc/keyboard.conf from the intended root filesystem. Thus a kernel > boot parameter "KEYBOARD=foo" might be "necessary" if the global default > (or in the value specified in the initramfs) is not appropriate. true, yeah. It should at least read the config from the root filesystem if it _is_ available, though, if it doesn't already. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, 2013-01-03 at 10:09 -0500, Jaroslav Reznik wrote: > > * https://bugzilla.redhat.com/show_bug.cgi?id=891487 - anaconda > > doesn't > > seem to manage to offer all the keyboard layouts it could do, and > > some > > of the ones it's missing are somewhat important > > Already accepted as NTH, Vratislav does not have idea why some layouts > Already accepted as NTH, partial patch available. For the rest - Neither is accepted. They are both proposed. (Yes, using 'F18-accepted' as the alias for the NTH blocker bug and 'accepted' as the word we use to describe an 'approved' blocker or NTH was a really bad idea. I know. :>) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rationalizing X and console keymaps and configuration (was Re: Fedora 18 issues with translations and keymaps)
On 01/03/2013 09:59 AM, Adam Williamson wrote: > if > there's /etc/keyboard.conf specifying 'KEYBOARD=foo', [then] I should never > have to pass 'KEYBOARD=foo' as a cmdline to make foo my keyboard layout > in some case. As things stand I believe I do, for passphrase entry > during dracut. The dracut emergency shell can be activated before achieving visibility of /etc/keyboard.conf from the intended root filesystem. Thus a kernel boot parameter "KEYBOARD=foo" might be "necessary" if the global default (or in the value specified in the initramfs) is not appropriate. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rationalizing X and console keymaps and configuration (was Re: Fedora 18 issues with translations and keymaps)
On Thu, 2013-01-03 at 18:53 +0100, Lennart Poettering wrote: > On Thu, 03.01.13 09:38, Adam Williamson (awill...@redhat.com) wrote: > > > If we have such a tool, can we make the whole area of keymap > > configuration much less insane? Right now we appear to have at least the > > following: > > Well, we still will allow configuration of per-boot, per-system and > per-user keymaps, but at least only one for each (i.e. only X11), not > two (i.e. X11+console). > > > systemd tries to keep /etc/vconsole.conf and the X config in line, but > > there's lots of room for things to go wonky there. And I don't think > > that GNOME's config tool, at least, has any mechanism to propagate its > > configuration 'down the stack' like it does for other settings. > > We'd drop the console keymap specific bits in /etc/vconsole.conf. It > would stick around only for the font setting after that. > > > It seems like ideally we should just have two configurations: > > > > * system-wide default keymap > > * user-specific current keymap > > Well, certainly, but I think ther is benefit in allowing this to be > overriden at boot on the kernel command line. Oh sure. I guess I need to draw a distinction between what I see as two different cases. Which I'm sure you understand but I'm having trouble describing clearly. I guess what I'm saying is, if there's /etc/keyboard.conf specifying 'KEYBOARD=foo', I should never have to pass 'KEYBOARD=foo' as a cmdline to make foo my keyboard layout in some case. As things stand I believe I do, for passphrase entry during dracut. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rationalizing X and console keymaps and configuration (was Re: Fedora 18 issues with translations and keymaps)
On Thu, 03.01.13 09:38, Adam Williamson (awill...@redhat.com) wrote: > If we have such a tool, can we make the whole area of keymap > configuration much less insane? Right now we appear to have at least the > following: Well, we still will allow configuration of per-boot, per-system and per-user keymaps, but at least only one for each (i.e. only X11), not two (i.e. X11+console). > systemd tries to keep /etc/vconsole.conf and the X config in line, but > there's lots of room for things to go wonky there. And I don't think > that GNOME's config tool, at least, has any mechanism to propagate its > configuration 'down the stack' like it does for other settings. We'd drop the console keymap specific bits in /etc/vconsole.conf. It would stick around only for the font setting after that. > It seems like ideally we should just have two configurations: > > * system-wide default keymap > * user-specific current keymap Well, certainly, but I think ther is benefit in allowing this to be overriden at boot on the kernel command line. ennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rationalizing X and console keymaps and configuration (was Re: Fedora 18 issues with translations and keymaps)
On Thu, 2013-01-03 at 15:43 +0100, Lennart Poettering wrote: > On Thu, 03.01.13 00:03, Adam Williamson (awill...@redhat.com) wrote: > > > * https://bugzilla.redhat.com/show_bug.cgi?id=889562 - systemd > > conversion from xkb to console layouts fails probably more than it > > succeeds, when it does, you wind up with U.S. English as your console > > layout, not whatever you picked during installation > > Here's how I think we should proceed on this one specific issue > (i.e. the only one I am directly involved with): > > I believe X11 keymaps on the console are the (long term) > future. Unfortunately we have no tool that would currently fit the bill > nicely, since Debian's existing tool pulls in Perl and is just a giant hack > around loadkeys. Ideally we'd have a nice simple tool that replaces > loadkeys and is capable of uploading X11 keymaps directly into the > kernel's console driver, and preferably written in C. > > However, console hacking is not particularly sexy as it appears, and so > far nobody volunteered working on that. That said, if such a tool > existed I'd be happy to hook it up with systemd in no time. > > In the meantime, until somebody wants to spend the time on writing this > tool I think the best is to update the keyboard mapping table that > systemd ships. I am more than happy to apply patches to that and it's no > issue at all updating this table in F18 at any time, including after the > release. > > I don't think it is worth delaying F18 for that. Thanks. Branching off for this post-F18 discussion: Given the impact of the bug I think we definitely need such a tool for Fedora 19 onwards. If that means RH gets someone to do it, so be it, but we need one. The current situation is not long-term viable. If we have such a tool, can we make the whole area of keymap configuration much less insane? Right now we appear to have at least the following: * Keymap passed in on the cmdline (for dracut env?) * Console keymap configured in /etc/vconsole.conf * System-wide X11 keymap configured in /etc/X11/xorg.conf.d/00-whatever.conf (s-c-k, anaconda, and systemd all seem to read and write *differently named* 00-whatever.conf's, for bonus points) * User-specific input configuration for each desktop (GNOME keeps its as a gsettings entry, haven't looked at other desktops) systemd tries to keep /etc/vconsole.conf and the X config in line, but there's lots of room for things to go wonky there. And I don't think that GNOME's config tool, at least, has any mechanism to propagate its configuration 'down the stack' like it does for other settings. It seems like ideally we should just have two configurations: * system-wide default keymap * user-specific current keymap which can be read and written by all the involved tools, right? It'd be nice if the desktops could co-ordinate on this too. Anyway, grand plans... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, 2013-01-03 at 14:19 +0100, Jiri Eischmann wrote: > "Jóhann B. Guðmundsson" píše v Čt 03. 01. 2013 v 12:40 +: > > On 01/03/2013 10:37 AM, Jiri Eischmann wrote: > > > So yes, these issues are serious, but IMHO rather a long-term problem we > > > should focus on after releasing F18. > > > > I disagree I think we need to fix those things first. > > > > Ask yourself this, If the roles where reversed and US keymaps and > > translation was broken and on that list, we would ship? > > I'm using the Czech layout (and I'm even so weird that I'm using QWERTZ) > and Czech translations primarily and I haven't found any serious > problems for weeks of using Fedora 18. The bug that I reported " that > you remove the English keyboard completely in Anaconda and it's still > there as a second option in GNOME after installation" is IMHO just a > minor problem. Note I included that bug to represent the 'Bambara' problem, as it was suggested in another bug that the Bambara thing was somehow a part of your bug. But I should probably just separate it out to avoid confusion. No-one seems to have given any serious consideration to the Bambara thing, which is unfortunate. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, Jan 3, 2013 at 9:03 AM, Adam Williamson wrote: > 3. In the longer term, how can we get anaconda, i18n, systemd, GNOME etc > folks all pointed in the same direction and working so that there's far > less suckage and far more smooth interaction going on here? Should we > try and run some sort of session at FUDCon? It seems to me similar problems occur increasingly frequently; and it's often not "pointing projects into the same direction" (AFAICS even here it's not the case that we have various projects that want conflicting things), but "not losing the features and ideas from the past". In many aspects of Linux, there is no available record of the design decisions - no documentation of what problems need solving, how they were solved, what is the purpose of each individual thing. The original authors probably know all of these things, or at least know where to find them in some project-specific documentation, but they may not be around to help, and even if they are around, it's not obvious who to ask. So, with an increasing frequency, somebody new encounters the problem space, has no idea why the things look like it does (or even does not know about some of the components), and we end up with regressions and rediscovering things. (This is not an anaconda/i18n/systemd/GNOME thing, this happens even in the "core UNIX": about a month ago it turned out that we don't know what the precise intended semantics of the "tty" group are; it seems not to be documented anywhere directly, and the indirect documentation in the man-pages package is contradictory.) I'm not sure how to solve this well... Fedora isn't a great place to document such things (although better than no place, certainly), and finding informed volunteers to create such documentation won't be easy. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On 01/03/2013 04:01 PM, "Jóhann B. Guðmundsson" wrote: I assume you are not using encrypted partition I do. Given that we are already that far behind the schedule few more months hardly matter or at least delay the release up to the point this issues are fixed. Yes it does. Many already upgraded to F18, and would like to see normal operation of F18 updates repositories. What is not right here while the distribution has significantly increased in size the release cycle has not been extended to accommodate for that ( amongst other growth pain we suffer from ) Numbers? Has critpath really increased that much? On 01/03/2013 03:50 PM, drago01 wrote: > After the release does not help people that upgraded on release day > and found themselves unable to unlock there harddrive or log in. Oh come on, fedup doesn't delete the old kernel, you can still boot with the F17 kernel and fix up the keyboard mess. I've upgraded quite a few machines already, all with non-US locales/keymaps, and while slightly annoying, it was easy enough to fix up afterwards. Just document what to do eg. on the fedup wiki page (you need to read this page anyway, I doubt anyone will be able to use fedup without consulting the instructions there, and there are already instructions on how to fix up grub after the upgrade). I have _never_ been able to upgrade a single fedora release without some minor manual fixing afterwards, and I do that since fc1. I find that acceptable. Though I value hints on prominent places, such as FAQ wiki pages, etc. My impression is though that it's gotten a lot better in the recent couple of releases. There are other annoying problems, like broken upgrade path for kdelibs, which should be solved magically by finally releasing fc18. So +1 (or more) from me for - releasing fc18 soon - document workarounds for keyboard issues - continue working on long-term solutions for keyboard layout setting, like the one Lennart outlined. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On 01/03/2013 04:01 PM, "Jóhann B. Guðmundsson" wrote: What is not right here while the distribution has significantly increased in size the release cycle has not been extended to accommodate for that ( amongst other growth pain we suffer from ) The number of packages might have increased, but it would be news to me, if the number of the "release critical packages" has increased significantly. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
- Original Message - > ad 1) OK, feel free to ignore this, I don't really have time to go > through all the bugs in last 4 fedora releases, since it won't (most > probably) change your opinion. > ad 2) https://fedoraproject.org/wiki/Common_F16_bugs Thanks for the link https://fedoraproject.org/wiki/Common_F16_bugs#Disk_encryption_with_national_keymap_often_doesn.27t_work > ad 3) You clearly misunderstood. My email is not meant to discuss > approved blocker bugs (or even the blocker bug process), and I > thought that it should be obvious from the thread topic, if nothing > else. My bad. But most of the bugs adamw pointed out in his email > are _IMHO not_ show stoppers. And the IMHO most important one > (encrypted disks) can be dealt with via common bugs. > > Joza > > > - Original Message - > > From: "drago01" > > To: "For testing and quality assurance of Fedora releases" > > > > Sent: Thursday, January 3, 2013 4:15:29 PM > > Subject: Re: Fedora 18 issues with translations and keymaps > > > > On Thu, Jan 3, 2013 at 3:09 PM, Josef Skladanka > > > > wrote: > > > I'm absolutely +1 with jeischmann and jreznik on this matter. > > > Keyboard layouts are broken almost every other (if not every one) > > > Fedora release. > > > > [citation needed] > > > > > The same exact encrypt-prompt issue was (at least) in F16, and we > > > released it anyway. > > > > [citation needed] > > > > > I'm not saying that we should just blindly say "it's late, let's > > > ship it", > > > > You are actually doing that or iow this sentence contradicts the > > rest > > you wrote. > > -- > > test mailing list > > t...@lists.fedoraproject.org > > To unsubscribe: > > https://admin.fedoraproject.org/mailman/listinfo/test > -- > test mailing list > t...@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
- Original Message - > Hey, folks. I'm not really sure how to frame it, but the result of > all > my poking about at keyboard layout bugs and related stuff recently is > that I'm pretty sad at the state of support for > anything-but-U.S.-English in Fedora 18. > > Here's the tally: > > * https://bugzilla.redhat.com/show_bug.cgi?id=889562 - systemd > conversion from xkb to console layouts fails probably more than it > succeeds, when it does, you wind up with U.S. English as your console > layout, not whatever you picked during installation Lennart already commented this one. The real solution is long term one, possibility of keymap updates. > * https://bugzilla.redhat.com/show_bug.cgi?id=891487 - anaconda > doesn't > seem to manage to offer all the keyboard layouts it could do, and > some > of the ones it's missing are somewhat important Already accepted as NTH, Vratislav does not have idea why some layouts are missing, asking him to take a closer look. > * https://bugzilla.redhat.com/show_bug.cgi?id=891489 - anaconda's > mapping of 'native' layouts to user's chosen install language doesn't > work in all cases Already accepted as NTH, partial patch available. For the rest - mapping from languages is not supported - long term solution is to prepare such table and to have someone who would maintain it (i18n guys?) as it's not directly related to Anaconda and requires know-how the team does not have (and should not have). > * https://bugzilla.redhat.com/show_bug.cgi?id=878433 (?) - GNOME has > a > weird predilection for coming up with the obscure 'Bambara' layout in > user sessions after an install in a non-English language, but not the > correct layout for that language > > * https://bugzilla.redhat.com/show_bug.cgi?id=881624 - X and GNOME > keyboard layouts revert to U.S. English on upgrade to F18 > > * https://bugzilla.redhat.com/show_bug.cgi?id=854557 - the 'layout > testing' in the keyboard spoke doesn't work at all how you'd expect > it > to The patch is available but breaks string freeze. I'm going to ask Translation team on today's Readiness meeting if they would be willing to grant exception for this one. > * https://bugzilla.redhat.com/show_bug.cgi?id=882440 - in fact, > people > have various problems interacting with and understanding the keyboard > spoke at all, really. Several of the issues discussed in this bug are > 'greatest hits', especially the lack of a default layout switch > command, > the fact that anaconda doesn't automatically start using a layout you > promote to the top of the list, and the lack of any kind of indicator > in > anaconda as to what layout is in use This is more an usability problem. Usability testing is planned, this task should be added to test coverage. Targets F19. > > * https://bugzilla.redhat.com/show_bug.cgi?id=859641 - we're picking > the > wrong default keyboard for Dutch, apparently > > * https://bugzilla.redhat.com/show_bug.cgi?id=867110 - ...and German > (Switzerland) > > * https://bugzilla.redhat.com/show_bug.cgi?id=885345 - ...and Dutch > (Belgian) We are back to mapping table maintenance, see above -> probably long term ones, not low hanging fruits as I thought originally. As Josef pointed out - we were hitting similar/same bugs in previous releases - there's no clear regression as far as I read it, not saying it's ideal and to hide our eyes problem does not exist. There are potential quick fixes available to make the user experience better, accepted as NTHs with patches available (but with some dependencies we can try to sort out). > (there's a few more along those lines which I won't bore anyone with) > > In addition to those bugs, we have fairly significant regressions in > the > completeness of anaconda translations between Fedora 16 and Fedora 18 > (the numbers for F17 for some languages are weird - a lot of > languages > show 55% completion for F17 but 90-100% for F16, which seems bogus, > as > I'm sure things didn't change that much between F16 and F17, so I'm > just > using the F16 numbers. I assume there's some weirdness that explains > the > odd 55% numbers for F17, but if not, hey, F17 was kinda boned > too...): > > Language F16 F18 > Finnish 93% 75% > Indonesian100%33% > Kannada 94% 33% > Oriya 94% 27% > Telugu94% 32% > Bengali (India) 93% 33% > Portuguese100%36% > Persian 95% 27% > Malayalam 78% 20% > NorwegianBokmal 92% 55% > Bengali 93% 33% > Sinhala 93% 27% > Serbian 81% 23% > Serbian(Latin)81% 23% > Hebrew83% 22% > Catalan
Re: Fedora 18 issues with translations and keymaps
On 01/03/2013 01:57 PM, Jiri Eischmann wrote: drago01 píše v Čt 03. 01. 2013 v 14:43 +0100: On Thu, Jan 3, 2013 at 2:27 PM, Jiri Eischmann wrote: drago01 píše v Čt 03. 01. 2013 v 14:13 +0100: On Thu, Jan 3, 2013 at 12:06 PM, Fabian Deutsch wrote: Jiri Eischmann wrote: Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: … 2. If not, do we want to engage in some Messaging around the F18 release to emphasize that we know there are all these issues and we'll try to smooth things out for F19? … So yes, these issues are serious, but IMHO rather a long-term problem we should focus on after releasing F18. +1 Let's point out the issues we are seeing with F18 amd get the release out of the door so we focus on fixing the stuff for F19. With all the drawbacks this solution has (e.g. unpleasant surprise for users with LUKS when they can't unlock their partition because of the changed layout ...) There is no point in releasing if we know that it is broken period. We delayed the release already for a very long period why should we rush and ship a broken release now? And those issues are rather serious and affect a lot of users. Well, happy F18 Final release in 2053! Because that's the year by which we might fix completely all bugs in Fedora because if there is a bug it's broken period ;) No, I didn't miss it. I just don't agree with it. For example the bug reported by me, which is on the list, too, is not serious at all. And many other bugs are not even regressions in Fedora 18. They're caused by problems that have been in Fedora for some time and our current final releases suffer from them, too. So when the release is almost out of the door we suddenly wake up and decide to solve long-term problems that we were fine with in F17,... I assume you are not using encrypted partition especially in the situation when we're already 2 months behind the schedule. Given that we are already that far behind the schedule few more months hardly matter or at least delay the release up to the point this issues are fixed. It just doesn't feel right to me, that's all. What is not right here while the distribution has significantly increased in size the release cycle has not been extended to accommodate for that ( amongst other growth pain we suffer from ) Btw Fedora has not been the "first" for sometime now encase people have not noticed ( just compare Fedora and Arch for example )... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, Jan 3, 2013 at 3:43 PM, Lennart Poettering wrote: > In the meantime, until somebody wants to spend the time on writing this > tool I think the best is to update the keyboard mapping table that > systemd ships. I am more than happy to apply patches to that and it's no > issue at all updating this table in F18 at any time, including after the > release. > > I don't think it is worth delaying F18 for that. After the release does not help people that upgraded on release day and found themselves unable to unlock there harddrive or log in. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, 03.01.13 00:03, Adam Williamson (awill...@redhat.com) wrote: > * https://bugzilla.redhat.com/show_bug.cgi?id=889562 - systemd > conversion from xkb to console layouts fails probably more than it > succeeds, when it does, you wind up with U.S. English as your console > layout, not whatever you picked during installation Here's how I think we should proceed on this one specific issue (i.e. the only one I am directly involved with): I believe X11 keymaps on the console are the (long term) future. Unfortunately we have no tool that would currently fit the bill nicely, since Debian's existing tool pulls in Perl and is just a giant hack around loadkeys. Ideally we'd have a nice simple tool that replaces loadkeys and is capable of uploading X11 keymaps directly into the kernel's console driver, and preferably written in C. However, console hacking is not particularly sexy as it appears, and so far nobody volunteered working on that. That said, if such a tool existed I'd be happy to hook it up with systemd in no time. In the meantime, until somebody wants to spend the time on writing this tool I think the best is to update the keyboard mapping table that systemd ships. I am more than happy to apply patches to that and it's no issue at all updating this table in F18 at any time, including after the release. I don't think it is worth delaying F18 for that. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
drago01 píše v Čt 03. 01. 2013 v 14:43 +0100: > On Thu, Jan 3, 2013 at 2:27 PM, Jiri Eischmann wrote: > > drago01 píše v Čt 03. 01. 2013 v 14:13 +0100: > >> On Thu, Jan 3, 2013 at 12:06 PM, Fabian Deutsch > >> wrote: > >> > Jiri Eischmann wrote: > >> >> Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: > >> > > >> > … > >> > > >> >> > 2. If not, do we want to engage in some Messaging around the F18 > >> >> > release > >> >> > to emphasize that we know there are all these issues and we'll try to > >> >> > smooth things out for F19? > >> >> > > >> > > >> > … > >> > > >> >> So yes, these issues are serious, but IMHO rather a long-term problem we > >> >> should focus on after releasing F18. > >> > > >> > +1 > >> > > >> > Let's point out the issues we are seeing with F18 amd get the release > >> > out of > >> > the door so we focus on fixing the stuff for F19. With all the drawbacks > >> > this > >> > solution has (e.g. unpleasant surprise for users with LUKS when they > >> > can't > >> > unlock their partition because of the changed layout ...) > >> > >> There is no point in releasing if we know that it is broken period. > >> We delayed the release already for a very long period why should we > >> rush and ship a broken release now? > >> And those issues are rather serious and affect a lot of users. > > > > Well, happy F18 Final release in 2053! Because that's the year by which > > we might fix completely all bugs in Fedora because if there is a bug > > it's broken period ;) No, I didn't miss it. I just don't agree with it. For example the bug reported by me, which is on the list, too, is not serious at all. And many other bugs are not even regressions in Fedora 18. They're caused by problems that have been in Fedora for some time and our current final releases suffer from them, too. So when the release is almost out of the door we suddenly wake up and decide to solve long-term problems that we were fine with in F17,... especially in the situation when we're already 2 months behind the schedule. It just doesn't feel right to me, that's all. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, Jan 3, 2013 at 2:27 PM, Jiri Eischmann wrote: > drago01 píše v Čt 03. 01. 2013 v 14:13 +0100: >> On Thu, Jan 3, 2013 at 12:06 PM, Fabian Deutsch >> wrote: >> > Jiri Eischmann wrote: >> >> Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: >> > >> > … >> > >> >> > 2. If not, do we want to engage in some Messaging around the F18 release >> >> > to emphasize that we know there are all these issues and we'll try to >> >> > smooth things out for F19? >> >> > >> > >> > … >> > >> >> So yes, these issues are serious, but IMHO rather a long-term problem we >> >> should focus on after releasing F18. >> > >> > +1 >> > >> > Let's point out the issues we are seeing with F18 amd get the release out >> > of >> > the door so we focus on fixing the stuff for F19. With all the drawbacks >> > this >> > solution has (e.g. unpleasant surprise for users with LUKS when they can't >> > unlock their partition because of the changed layout ...) >> >> There is no point in releasing if we know that it is broken period. >> We delayed the release already for a very long period why should we >> rush and ship a broken release now? >> And those issues are rather serious and affect a lot of users. > > Well, happy F18 Final release in 2053! Because that's the year by which > we might fix completely all bugs in Fedora because if there is a bug > it's broken period ;) You seem to somehow have missed the last sentence of my mail ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
drago01 píše v Čt 03. 01. 2013 v 14:13 +0100: > On Thu, Jan 3, 2013 at 12:06 PM, Fabian Deutsch wrote: > > Jiri Eischmann wrote: > >> Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: > > > > … > > > >> > 2. If not, do we want to engage in some Messaging around the F18 release > >> > to emphasize that we know there are all these issues and we'll try to > >> > smooth things out for F19? > >> > > > > > … > > > >> So yes, these issues are serious, but IMHO rather a long-term problem we > >> should focus on after releasing F18. > > > > +1 > > > > Let's point out the issues we are seeing with F18 amd get the release out of > > the door so we focus on fixing the stuff for F19. With all the drawbacks > > this > > solution has (e.g. unpleasant surprise for users with LUKS when they can't > > unlock their partition because of the changed layout ...) > > There is no point in releasing if we know that it is broken period. > We delayed the release already for a very long period why should we > rush and ship a broken release now? > And those issues are rather serious and affect a lot of users. Well, happy F18 Final release in 2053! Because that's the year by which we might fix completely all bugs in Fedora because if there is a bug it's broken period ;) Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
"Jóhann B. Guðmundsson" píše v Čt 03. 01. 2013 v 12:40 +: > On 01/03/2013 10:37 AM, Jiri Eischmann wrote: > > So yes, these issues are serious, but IMHO rather a long-term problem we > > should focus on after releasing F18. > > I disagree I think we need to fix those things first. > > Ask yourself this, If the roles where reversed and US keymaps and > translation was broken and on that list, we would ship? I'm using the Czech layout (and I'm even so weird that I'm using QWERTZ) and Czech translations primarily and I haven't found any serious problems for weeks of using Fedora 18. The bug that I reported " that you remove the English keyboard completely in Anaconda and it's still there as a second option in GNOME after installation" is IMHO just a minor problem. And I haven't had any other problem with translations or layouts. Neither has my mother who is an average user and has been using F18 with Czech layout and translations even longer than me. No software will ever be perfect. OSes with a 6-month release cycle are in fact far from perfect. You always find tons of bugs when you dig in. It's about compromises. I always supported more quality in Fedora, but we have to take in account our time frame which is 6 months and we're already way behind it. And if you think that it's OK that a distro, that should be release every 6 months and has "First" as one of its 4 foundations, is released after 12 months, then I think it's not OK. And we also should take into account how much the problems affect people and how many of them. I follow a lot of user forums and discussions and people, who have tried Fedora 18, they're mostly satisfied with it (except for the partitioning in the installer). Look at the retrace server stats. The number of reports from F18 is already almost 1/3 of F17. I really don't want to end up delaying the final release again and again while most users are using it anyway. Still, we're not working for the sake of fixing bugs, we're working for users. > In anycase Adam has provided the necessary info on how utterly broken > these things are which should be sufficiant information for fesco to > take from there and decide if and then when we should release. Yeah, it's up to FESCo to decide. Neither me nor you can make the decision. But we can express our opinions ;) Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, Jan 3, 2013 at 12:06 PM, Fabian Deutsch wrote: > Jiri Eischmann wrote: >> Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: > > … > >> > 2. If not, do we want to engage in some Messaging around the F18 release >> > to emphasize that we know there are all these issues and we'll try to >> > smooth things out for F19? >> > > > … > >> So yes, these issues are serious, but IMHO rather a long-term problem we >> should focus on after releasing F18. > > +1 > > Let's point out the issues we are seeing with F18 amd get the release out of > the door so we focus on fixing the stuff for F19. With all the drawbacks this > solution has (e.g. unpleasant surprise for users with LUKS when they can't > unlock their partition because of the changed layout ...) There is no point in releasing if we know that it is broken period. We delayed the release already for a very long period why should we rush and ship a broken release now? And those issues are rather serious and affect a lot of users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
- Original Message - > Hey, folks. I'm not really sure how to frame it, but the result of > all > my poking about at keyboard layout bugs and related stuff recently is > that I'm pretty sad at the state of support for > anything-but-U.S.-English in Fedora 18. > > Here's the tally: > > * https://bugzilla.redhat.com/show_bug.cgi?id=889562 - systemd > conversion from xkb to console layouts fails probably more than it > succeeds, when it does, you wind up with U.S. English as your console > layout, not whatever you picked during installation > > * https://bugzilla.redhat.com/show_bug.cgi?id=891487 - anaconda > doesn't > seem to manage to offer all the keyboard layouts it could do, and > some > of the ones it's missing are somewhat important > > * https://bugzilla.redhat.com/show_bug.cgi?id=891489 - anaconda's > mapping of 'native' layouts to user's chosen install language doesn't > work in all cases > > * https://bugzilla.redhat.com/show_bug.cgi?id=878433 (?) - GNOME has > a > weird predilection for coming up with the obscure 'Bambara' layout in > user sessions after an install in a non-English language, but not the > correct layout for that language > > * https://bugzilla.redhat.com/show_bug.cgi?id=881624 - X and GNOME > keyboard layouts revert to U.S. English on upgrade to F18 > > * https://bugzilla.redhat.com/show_bug.cgi?id=854557 - the 'layout > testing' in the keyboard spoke doesn't work at all how you'd expect > it > to > > * https://bugzilla.redhat.com/show_bug.cgi?id=882440 - in fact, > people > have various problems interacting with and understanding the keyboard > spoke at all, really. Several of the issues discussed in this bug are > 'greatest hits', especially the lack of a default layout switch > command, > the fact that anaconda doesn't automatically start using a layout you > promote to the top of the list, and the lack of any kind of indicator > in > anaconda as to what layout is in use > > * https://bugzilla.redhat.com/show_bug.cgi?id=859641 - we're picking > the > wrong default keyboard for Dutch, apparently > > * https://bugzilla.redhat.com/show_bug.cgi?id=867110 - ...and German > (Switzerland) > > * https://bugzilla.redhat.com/show_bug.cgi?id=885345 - ...and Dutch > (Belgian) > > (there's a few more along those lines which I won't bore anyone with) > > In addition to those bugs, we have fairly significant regressions in > the > completeness of anaconda translations between Fedora 16 and Fedora 18 > (the numbers for F17 for some languages are weird - a lot of > languages > show 55% completion for F17 but 90-100% for F16, which seems bogus, > as > I'm sure things didn't change that much between F16 and F17, so I'm > just > using the F16 numbers. I assume there's some weirdness that explains > the > odd 55% numbers for F17, but if not, hey, F17 was kinda boned > too...): > > Language F16 F18 > Finnish 93% 75% > Indonesian100%33% > Kannada 94% 33% > Oriya 94% 27% > Telugu94% 32% > Bengali (India) 93% 33% > Portuguese100%36% > Persian 95% 27% > Malayalam 78% 20% > NorwegianBokmal 92% 55% > Bengali 93% 33% > Sinhala 93% 27% > Serbian 81% 23% > Serbian(Latin)81% 23% > Hebrew83% 22% > Catalan 68% (98% F17) 25% > Latvian 88% 20% > Greek 68% 21% > Turkish 79% 21% > Maithili 67% 18% > Asturian 85% 24% > > (from https://fedora.transifex.com/projects/p/anaconda/ ) > > There are several others around the 50-70% complete mark for F16, > too, I > just cut off at 67%. It's a fairly long list of languages for which > we > previously had tolerably complete translation coverage, but we now > have > a level which isn't really usable: basically these languages have > gone > from 'covered' in at least F16 (probably F17 too) to 'not covered' in > F18. I want to stress I'm not blaming anyone for this: I don't see > how > it could be otherwise, the problem is the huge amount of string churn > caused by newUI, I'm actually more amazed at how many languages _do_ > have close-to-100% translations for F18 than how many _don't_, given > the > conditions. It's just an unfortunate thing. > > anaconda does not list every available translation for the user to > choose from, but I cannot figure out for the life of me how the > decision > about which to display is made: it's not that very incomplete > translations are left out, as plenty of very incomplete transl
Re: Fedora 18 issues with translations and keymaps
On 01/03/2013 10:37 AM, Jiri Eischmann wrote: So yes, these issues are serious, but IMHO rather a long-term problem we should focus on after releasing F18. I disagree I think we need to fix those things first. Ask yourself this, If the roles where reversed and US keymaps and translation was broken and on that list, we would ship? In anycase Adam has provided the necessary info on how utterly broken these things are which should be sufficiant information for fesco to take from there and decide if and then when we should release. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
Jiri Eischmann wrote: > Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: … > > 2. If not, do we want to engage in some Messaging around the F18 release > > to emphasize that we know there are all these issues and we'll try to > > smooth things out for F19? > > … > So yes, these issues are serious, but IMHO rather a long-term problem we > should focus on after releasing F18. +1 Let's point out the issues we are seeing with F18 amd get the release out of the door so we focus on fixing the stuff for F19. With all the drawbacks this solution has (e.g. unpleasant surprise for users with LUKS when they can't unlock their partition because of the changed layout ...) - fabian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
Dne 3.1.2013 11:34, Adam Williamson napsal(a): On Thu, 2013-01-03 at 11:31 +0100, Vít Ondruch wrote: Dne 3.1.2013 10:51, Adam Williamson napsal(a): On Thu, 2013-01-03 at 20:17 +1030, William Brown wrote: On Thu, 2013-01-03 at 01:42 -0800, Adam Williamson wrote: On Thu, 2013-01-03 at 09:23 +, "Jóhann B. Guðmundsson" wrote: On 01/03/2013 08:03 AM, Adam Williamson wrote: Hey, folks. I'm not really sure how to frame it, but the result of all my poking about at keyboard layout bugs and related stuff recently is that I'm pretty sad at the state of support for anything-but-U.S.-English in Fedora 18. ... I really didn't want this to turn into a release philosophy thread, the question was limited strictly to a 'how bad do we really think these keymap issues are' thing. I think they are quite an issue still. Even basic things like a non-us qwerty keymap (IE dvorak) still has issues from anaconda (Is still qwerty in tty). Oh, yeah, that's another issue I didn't call out - setting a keymap within anaconda doesn't necessarily set it on the console. (Though did that work in F17?) And apparently the console layout you get when picking Czech is a bad one, that needs its own bug. Considering you cannot easily switch input method in Gnome 3.6 [1] and that is not going to change in 3.6, I consider every other keyboard layout issue as insignificant and F18 should be released as it is now, because it will not be better. That's really overplaying the issue. Just a bit :) You can configure a perfectly reasonable shortcut in gnome-tweak-tool. And that issue is pretty orthogonal to many of the ones I listed. So I'll try to put it differently. I installed F18 Beta TC7 and since that time I am using it for my daily work. I selected Czech localization with Czech layout as my primary one during installation and English as a secondary. I did not noticed any issue with layout except that Gnome thing which is the most annoying issue I could discover (and would love to see it fixed, but it realistically, it will not be). Comparing to F17, when I did the same steps, the only difference is that Plymouth is using Czech layout when asking for LUKS password while it used English in F17. This could be probably considered improvement considering that Czech layout have been always my primary layout. If there is any other issue, I was not personally affected by it and therefore I'd love to see F18 released as it is now, possible issues documented and fixed in F19 Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: > Hey, folks. I'm not really sure how to frame it, but the result of all > my poking about at keyboard layout bugs and related stuff recently is > that I'm pretty sad at the state of support for > anything-but-U.S.-English in Fedora 18. > > Here's the tally: > > * https://bugzilla.redhat.com/show_bug.cgi?id=889562 - systemd > conversion from xkb to console layouts fails probably more than it > succeeds, when it does, you wind up with U.S. English as your console > layout, not whatever you picked during installation > > * https://bugzilla.redhat.com/show_bug.cgi?id=891487 - anaconda doesn't > seem to manage to offer all the keyboard layouts it could do, and some > of the ones it's missing are somewhat important > > * https://bugzilla.redhat.com/show_bug.cgi?id=891489 - anaconda's > mapping of 'native' layouts to user's chosen install language doesn't > work in all cases > > * https://bugzilla.redhat.com/show_bug.cgi?id=878433 (?) - GNOME has a > weird predilection for coming up with the obscure 'Bambara' layout in > user sessions after an install in a non-English language, but not the > correct layout for that language > > * https://bugzilla.redhat.com/show_bug.cgi?id=881624 - X and GNOME > keyboard layouts revert to U.S. English on upgrade to F18 > > * https://bugzilla.redhat.com/show_bug.cgi?id=854557 - the 'layout > testing' in the keyboard spoke doesn't work at all how you'd expect it > to > > * https://bugzilla.redhat.com/show_bug.cgi?id=882440 - in fact, people > have various problems interacting with and understanding the keyboard > spoke at all, really. Several of the issues discussed in this bug are > 'greatest hits', especially the lack of a default layout switch command, > the fact that anaconda doesn't automatically start using a layout you > promote to the top of the list, and the lack of any kind of indicator in > anaconda as to what layout is in use > > * https://bugzilla.redhat.com/show_bug.cgi?id=859641 - we're picking the > wrong default keyboard for Dutch, apparently > > * https://bugzilla.redhat.com/show_bug.cgi?id=867110 - ...and German > (Switzerland) > > * https://bugzilla.redhat.com/show_bug.cgi?id=885345 - ...and Dutch > (Belgian) > > (there's a few more along those lines which I won't bore anyone with) > > In addition to those bugs, we have fairly significant regressions in the > completeness of anaconda translations between Fedora 16 and Fedora 18 > (the numbers for F17 for some languages are weird - a lot of languages > show 55% completion for F17 but 90-100% for F16, which seems bogus, as > I'm sure things didn't change that much between F16 and F17, so I'm just > using the F16 numbers. I assume there's some weirdness that explains the > odd 55% numbers for F17, but if not, hey, F17 was kinda boned too...): > > Language F16 F18 > Finnish 93% 75% > Indonesian100%33% > Kannada 94% 33% > Oriya 94% 27% > Telugu94% 32% > Bengali (India) 93% 33% > Portuguese100%36% > Persian 95% 27% > Malayalam 78% 20% > NorwegianBokmal 92% 55% > Bengali 93% 33% > Sinhala 93% 27% > Serbian 81% 23% > Serbian(Latin)81% 23% > Hebrew83% 22% > Catalan 68% (98% F17) 25% > Latvian 88% 20% > Greek 68% 21% > Turkish 79% 21% > Maithili 67% 18% > Asturian 85% 24% > > (from https://fedora.transifex.com/projects/p/anaconda/ ) > > There are several others around the 50-70% complete mark for F16, too, I > just cut off at 67%. It's a fairly long list of languages for which we > previously had tolerably complete translation coverage, but we now have > a level which isn't really usable: basically these languages have gone > from 'covered' in at least F16 (probably F17 too) to 'not covered' in > F18. I want to stress I'm not blaming anyone for this: I don't see how > it could be otherwise, the problem is the huge amount of string churn > caused by newUI, I'm actually more amazed at how many languages _do_ > have close-to-100% translations for F18 than how many _don't_, given the > conditions. It's just an unfortunate thing. > > anaconda does not list every available translation for the user to > choose from, but I cannot figure out for the life of me how the decision > about which to display is made: it's not that very incomplete > translations are left out, as plenty of very incomplete translations > (including
Re: Fedora 18 issues with translations and keymaps
On Thu, 2013-01-03 at 11:31 +0100, Vít Ondruch wrote: > Dne 3.1.2013 10:51, Adam Williamson napsal(a): > > On Thu, 2013-01-03 at 20:17 +1030, William Brown wrote: > >> On Thu, 2013-01-03 at 01:42 -0800, Adam Williamson wrote: > >>> On Thu, 2013-01-03 at 09:23 +, "Jóhann B. Guðmundsson" wrote: > On 01/03/2013 08:03 AM, Adam Williamson wrote: > > Hey, folks. I'm not really sure how to frame it, but the result of all > > my poking about at keyboard layout bugs and related stuff recently is > > that I'm pretty sad at the state of support for > > anything-but-U.S.-English in Fedora 18. > ... > >>> I really didn't want this to turn into a release philosophy thread, the > >>> question was limited strictly to a 'how bad do we really think these > >>> keymap issues are' thing. > >> > >> I think they are quite an issue still. Even basic things like a non-us > >> qwerty keymap (IE dvorak) still has issues from anaconda (Is still > >> qwerty in tty). > > Oh, yeah, that's another issue I didn't call out - setting a keymap > > within anaconda doesn't necessarily set it on the console. (Though did > > that work in F17?) And apparently the console layout you get when > > picking Czech is a bad one, that needs its own bug. > > Considering you cannot easily switch input method in Gnome 3.6 [1] and > that is not going to change in 3.6, I consider every other keyboard > layout issue as insignificant and F18 should be released as it is now, > because it will not be better. That's really overplaying the issue. You can configure a perfectly reasonable shortcut in gnome-tweak-tool. And that issue is pretty orthogonal to many of the ones I listed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
Dne 3.1.2013 10:51, Adam Williamson napsal(a): On Thu, 2013-01-03 at 20:17 +1030, William Brown wrote: On Thu, 2013-01-03 at 01:42 -0800, Adam Williamson wrote: On Thu, 2013-01-03 at 09:23 +, "Jóhann B. Guðmundsson" wrote: On 01/03/2013 08:03 AM, Adam Williamson wrote: Hey, folks. I'm not really sure how to frame it, but the result of all my poking about at keyboard layout bugs and related stuff recently is that I'm pretty sad at the state of support for anything-but-U.S.-English in Fedora 18. ... I really didn't want this to turn into a release philosophy thread, the question was limited strictly to a 'how bad do we really think these keymap issues are' thing. I think they are quite an issue still. Even basic things like a non-us qwerty keymap (IE dvorak) still has issues from anaconda (Is still qwerty in tty). Oh, yeah, that's another issue I didn't call out - setting a keymap within anaconda doesn't necessarily set it on the console. (Though did that work in F17?) And apparently the console layout you get when picking Czech is a bad one, that needs its own bug. Considering you cannot easily switch input method in Gnome 3.6 [1] and that is not going to change in 3.6, I consider every other keyboard layout issue as insignificant and F18 should be released as it is now, because it will not be better. Vít [1] https://bugzilla.gnome.org/show_bug.cgi?id=684210 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On 01/03/2013 09:42 AM, Adam Williamson wrote: I really didn't want this to turn into a release philosophy thread, the question was limited strictly to a 'how bad do we really think these keymap issues are' thing. Yes and I think they are bad enough that we should delay the release for them and then we find ourselves again in the same hole as we did earlier in the release cycle and this becomes question how long the delay should be which in turns will affect the F19 cycle etc... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, 2013-01-03 at 20:17 +1030, William Brown wrote: > On Thu, 2013-01-03 at 01:42 -0800, Adam Williamson wrote: > > On Thu, 2013-01-03 at 09:23 +, "Jóhann B. Guðmundsson" wrote: > > > On 01/03/2013 08:03 AM, Adam Williamson wrote: > > > > Hey, folks. I'm not really sure how to frame it, but the result of all > > > > my poking about at keyboard layout bugs and related stuff recently is > > > > that I'm pretty sad at the state of support for > > > > anything-but-U.S.-English in Fedora 18. > > > ... > > > > > I really didn't want this to turn into a release philosophy thread, the > > question was limited strictly to a 'how bad do we really think these > > keymap issues are' thing. > > > I think they are quite an issue still. Even basic things like a non-us > qwerty keymap (IE dvorak) still has issues from anaconda (Is still > qwerty in tty). Oh, yeah, that's another issue I didn't call out - setting a keymap within anaconda doesn't necessarily set it on the console. (Though did that work in F17?) And apparently the console layout you get when picking Czech is a bad one, that needs its own bug. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, 2013-01-03 at 01:42 -0800, Adam Williamson wrote: > On Thu, 2013-01-03 at 09:23 +, "Jóhann B. Guðmundsson" wrote: > > On 01/03/2013 08:03 AM, Adam Williamson wrote: > > > Hey, folks. I'm not really sure how to frame it, but the result of all > > > my poking about at keyboard layout bugs and related stuff recently is > > > that I'm pretty sad at the state of support for > > > anything-but-U.S.-English in Fedora 18. > > ... > > I really didn't want this to turn into a release philosophy thread, the > question was limited strictly to a 'how bad do we really think these > keymap issues are' thing. I think they are quite an issue still. Even basic things like a non-us qwerty keymap (IE dvorak) still has issues from anaconda (Is still qwerty in tty). -- Sincerely, William Brown pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On Thu, 2013-01-03 at 09:23 +, "Jóhann B. Guðmundsson" wrote: > On 01/03/2013 08:03 AM, Adam Williamson wrote: > > Hey, folks. I'm not really sure how to frame it, but the result of all > > my poking about at keyboard layout bugs and related stuff recently is > > that I'm pretty sad at the state of support for > > anything-but-U.S.-English in Fedora 18. > ... > > > > I don't really know where we need to go with this, exactly, but a few > > questions arise naturally: > > > > 1. In the short term, is the combination of all these factors enough for > > us to want to delay F18 further to try and make things suck less? > > > > 2. If not, do we want to engage in some Messaging around the F18 release > > to emphasize that we know there are all these issues and we'll try to > > smooth things out for F19? > > > > 3. In the longer term, how can we get anaconda, i18n, systemd, GNOME etc > > folks all pointed in the same direction and working so that there's far > > less suckage and far more smooth interaction going on here? Should we > > try and run some sort of session at FUDCon? > > > > Thanks, folks! > > Given that Fesco aggreed upon and thinks releasing F19 with shorter > cycle is a great idea while I along with others in the community are on > the opposite side and think we need longer release cycle. > > Our package collection has been growing larger over the years not > shorter which to me requires more time and resources to manage thus we > longer release cycle not shorter one. > > Based on our sad state in F18 I think we should just cut our losses and > "restart" the release cycle for F18 and use the release cycle Fesco > agreed upon for F19 as in F18 becomes an end-of-May release with an > end-of-February branch date. I really didn't want this to turn into a release philosophy thread, the question was limited strictly to a 'how bad do we really think these keymap issues are' thing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
On 01/03/2013 08:03 AM, Adam Williamson wrote: Hey, folks. I'm not really sure how to frame it, but the result of all my poking about at keyboard layout bugs and related stuff recently is that I'm pretty sad at the state of support for anything-but-U.S.-English in Fedora 18. ... I don't really know where we need to go with this, exactly, but a few questions arise naturally: 1. In the short term, is the combination of all these factors enough for us to want to delay F18 further to try and make things suck less? 2. If not, do we want to engage in some Messaging around the F18 release to emphasize that we know there are all these issues and we'll try to smooth things out for F19? 3. In the longer term, how can we get anaconda, i18n, systemd, GNOME etc folks all pointed in the same direction and working so that there's far less suckage and far more smooth interaction going on here? Should we try and run some sort of session at FUDCon? Thanks, folks! Given that Fesco aggreed upon and thinks releasing F19 with shorter cycle is a great idea while I along with others in the community are on the opposite side and think we need longer release cycle. Our package collection has been growing larger over the years not shorter which to me requires more time and resources to manage thus we longer release cycle not shorter one. Based on our sad state in F18 I think we should just cut our losses and "restart" the release cycle for F18 and use the release cycle Fesco agreed upon for F19 as in F18 becomes an end-of-May release with an end-of-February branch date. JBG, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
Il 03/01/2013 09:03, Adam Williamson ha scritto: > 1. In the short term, is the combination of all these factors enough for > us to want to delay F18 further to try and make things suck less? I was waiting for an e-mail like yours, and I am happy to see someone speaking about a delay of F18 release. I always thought that if there are some quite big problems like we are having, a delay would be good to preserve Fedora reputation. My question is: knowing by many weeks that: 1. so many translations lacked; 2. keyboard layouts on fedup-dracut, anaconda, etc. have troubles (expecially with LUKS. The bugzilla is full of this kind of bugreports) why the community did not seriously take in consideration another procrastination of F18 release? I have read people saying "let's skip directly from F17 to F19" but why? Okay, people already spent a huge amount of virtual ink discussing about when and how Fedora releases should be released, but my simple thought is: let's wait for these annoying bugs get fixed and don't worry about F19. They affect a very large area of Fedora users, they are not limited to a little part of them, so I 100% agree to the point number one of your letter.I think also that is quite easy to fix them (I am speaking about keyboard layouts trouble), so maybe that it will require only a few days to do the work I hope not to have been too banal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 18 issues with translations and keymaps
Hey, folks. I'm not really sure how to frame it, but the result of all my poking about at keyboard layout bugs and related stuff recently is that I'm pretty sad at the state of support for anything-but-U.S.-English in Fedora 18. Here's the tally: * https://bugzilla.redhat.com/show_bug.cgi?id=889562 - systemd conversion from xkb to console layouts fails probably more than it succeeds, when it does, you wind up with U.S. English as your console layout, not whatever you picked during installation * https://bugzilla.redhat.com/show_bug.cgi?id=891487 - anaconda doesn't seem to manage to offer all the keyboard layouts it could do, and some of the ones it's missing are somewhat important * https://bugzilla.redhat.com/show_bug.cgi?id=891489 - anaconda's mapping of 'native' layouts to user's chosen install language doesn't work in all cases * https://bugzilla.redhat.com/show_bug.cgi?id=878433 (?) - GNOME has a weird predilection for coming up with the obscure 'Bambara' layout in user sessions after an install in a non-English language, but not the correct layout for that language * https://bugzilla.redhat.com/show_bug.cgi?id=881624 - X and GNOME keyboard layouts revert to U.S. English on upgrade to F18 * https://bugzilla.redhat.com/show_bug.cgi?id=854557 - the 'layout testing' in the keyboard spoke doesn't work at all how you'd expect it to * https://bugzilla.redhat.com/show_bug.cgi?id=882440 - in fact, people have various problems interacting with and understanding the keyboard spoke at all, really. Several of the issues discussed in this bug are 'greatest hits', especially the lack of a default layout switch command, the fact that anaconda doesn't automatically start using a layout you promote to the top of the list, and the lack of any kind of indicator in anaconda as to what layout is in use * https://bugzilla.redhat.com/show_bug.cgi?id=859641 - we're picking the wrong default keyboard for Dutch, apparently * https://bugzilla.redhat.com/show_bug.cgi?id=867110 - ...and German (Switzerland) * https://bugzilla.redhat.com/show_bug.cgi?id=885345 - ...and Dutch (Belgian) (there's a few more along those lines which I won't bore anyone with) In addition to those bugs, we have fairly significant regressions in the completeness of anaconda translations between Fedora 16 and Fedora 18 (the numbers for F17 for some languages are weird - a lot of languages show 55% completion for F17 but 90-100% for F16, which seems bogus, as I'm sure things didn't change that much between F16 and F17, so I'm just using the F16 numbers. I assume there's some weirdness that explains the odd 55% numbers for F17, but if not, hey, F17 was kinda boned too...): LanguageF16 F18 Finnish 93% 75% Indonesian 100%33% Kannada 94% 33% Oriya 94% 27% Telugu 94% 32% Bengali (India) 93% 33% Portuguese 100%36% Persian 95% 27% Malayalam 78% 20% NorwegianBokmal 92% 55% Bengali 93% 33% Sinhala 93% 27% Serbian 81% 23% Serbian(Latin) 81% 23% Hebrew 83% 22% Catalan 68% (98% F17) 25% Latvian 88% 20% Greek 68% 21% Turkish 79% 21% Maithili67% 18% Asturian85% 24% (from https://fedora.transifex.com/projects/p/anaconda/ ) There are several others around the 50-70% complete mark for F16, too, I just cut off at 67%. It's a fairly long list of languages for which we previously had tolerably complete translation coverage, but we now have a level which isn't really usable: basically these languages have gone from 'covered' in at least F16 (probably F17 too) to 'not covered' in F18. I want to stress I'm not blaming anyone for this: I don't see how it could be otherwise, the problem is the huge amount of string churn caused by newUI, I'm actually more amazed at how many languages _do_ have close-to-100% translations for F18 than how many _don't_, given the conditions. It's just an unfortunate thing. anaconda does not list every available translation for the user to choose from, but I cannot figure out for the life of me how the decision about which to display is made: it's not that very incomplete translations are left out, as plenty of very incomplete translations (including most of the above) are shown. If we filtered out very incomplete translations we might at least look a bit less silly, but we don't seem to be doing that. Our language selection screen is definitely writing checks that our translations can't cash :) I don't really know where we need to go with this, exactly, but a few
