i18n-bugs June 2021

i18n-bugs@lists.fedoraproject.org

2 participants
72 discussions

[Fedora-i18n-bugs] [Bug 1951861] New: switch to using %transfiletriggerin for updating ibus cache
by bugzilla＠redhat.com 17 Jun '21

17 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1951861 Bug ID: 1951861 Summary: switch to using %transfiletriggerin for updating ibus cache Product: Fedora Version: rawhide Status: NEW Component: ibus Assignee: tfujiwar(a)redhat.com Reporter: petersen(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com Target Milestone: --- Classification: Fedora Description of problem: Rather than having each ibus engine update in a dnf transaction running ibus write-cache --system twice (%post and %postun) or once separately in %posttrans, it would be better to do it centrally from ibus.spec using a file trigger on "/usr/share/ibus/component". I think you tested it locally once and I believe it should work well enough. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1690275] When switch Region & Language, the text field of Language is not updated immediately
by bugzilla＠redhat.com 14 Jun '21

14 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1690275 --- Comment #7 from Leslie Satenstein <lsatenstein(a)yahoo.com> --- I am in Québec Canada, and since I use English, some Spanish and much French, my keyboard layout is Canada French. With Gnome, there is no issue, I just go to keyboard and set up the layout, and to region and language, and setup the language and keyboard layout. With many of the Remixes, eg, Deepin, Mate, etc, (my favoured language interface is the default English language, but the Keyboard layout I chose, the Canada French keyboard layout is not listed or the default. The default is American English. To set it up with the Deepin and other Remixes, I had to set the region/language to French, and then I could search and find the French keyboard layout. which now appeared in the list. I chose my Canadian French layout, and exited. I rebooted and on my first logon, everything was in French, (mostly). I used the gnome settings to reset the region/language to Canadian English (favor -->favour, neighbor -->neighbour) and rebooted. Deepin now works in Canadian English with my Canadian French keyboard layout. Mate and the others need the same tender loving care. A good fix would be to have each remix show the entire list of keyboard layouts, irrespective of the chosen "user interface language". -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1526467] Searching for emoji and selecting an emoji should jump to category
by bugzilla＠redhat.com 14 Jun '21

14 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1526467 Mike FABIAN <mfabian(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|33 |34 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1526464] Make it possible to use cursors to select emojis
by bugzilla＠redhat.com 14 Jun '21

14 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1526464 Mike FABIAN <mfabian(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|33 |34 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1526463] Make emoji selectable
by bugzilla＠redhat.com 14 Jun '21

14 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1526463 Mike FABIAN <mfabian(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|33 |34 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1761885] Drop unused .uuid files
by bugzilla＠redhat.com 13 Jun '21

13 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1761885 Jens Petersen <petersen(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(tagoh(a)redhat.com) --- Comment #9 from Jens Petersen <petersen(a)redhat.com> --- I am not seeing this on my Fedora 34 systems? What am I missing? Because no fonts updated yet? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1699211] Recommend Google Noto Serif fonts in langpacks
by bugzilla＠redhat.com 13 Jun '21

13 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1699211 Jens Petersen <petersen(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |FutureFeature Version|33 |rawhide -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1967541] New: zinnia fails to build in Fedora 35+: Broken RPATH will fail rpmbuild
by bugzilla＠redhat.com 11 Jun '21

11 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1967541 Bug ID: 1967541 Summary: zinnia fails to build in Fedora 35+: Broken RPATH will fail rpmbuild Product: Fedora Version: rawhide Status: NEW Component: zinnia Assignee: liangsuilong(a)gmail.com Reporter: thrnciar(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: i18n-bugs(a)lists.fedoraproject.org, liangsuilong(a)gmail.com, mhroncok(a)redhat.com, petersen(a)redhat.com, pwu(a)redhat.com, thrnciar(a)redhat.com Blocks: 1890881 (PYTHON3.10) Target Milestone: --- Classification: Fedora zinnia fails to build in Fedora 35+ https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild Related section in packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath + /usr/lib/rpm/check-rpaths ******************************************************************************* * * WARNING: 'check-rpaths' detected a broken RPATH OR RUNPATH and will cause * 'rpmbuild' to fail. To ignore these errors, you can set the * '$QA_RPATHS' environment variable which is a bitmask allowing the * values below. The current value of QA_RPATHS is 0x0000. * * 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor * issue but are introducing redundant searchpaths without * providing a benefit. They can also cause errors in multilib * environments. * 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute * nor relative filenames and can therefore be a SECURITY risk * 0x0004 ... insecure RPATHs; these are relative RPATHs which are a * SECURITY risk * 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other * RPATHs; this is just a minor issue but usually unwanted * 0x0010 ... the RPATH is empty; there is no reason for such RPATHs * and they cause unneeded work while loading libraries * 0x0020 ... an RPATH references '..' of an absolute path; this will break * the functionality when the path before '..' is a symlink * * * Examples: * - to ignore standard and empty RPATHs, execute 'rpmbuild' like * $ QA_RPATHS=$(( 0x0001|0x0010 )) rpmbuild my-package.src.rpm * - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like * $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths * ******************************************************************************* ERROR 0001: file '/usr/bin/zinnia_convert' contains a standard runpath '/usr/lib64' in [/usr/lib64] ERROR 0001: file '/usr/bin/zinnia_learn' contains a standard runpath '/usr/lib64' in [/usr/lib64] ERROR 0001: file '/usr/bin/zinnia' contains a standard runpath '/usr/lib64' in [/usr/lib64] For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-r… For all our attempts to build zinnia with Python 3.10, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/zinnia/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.10: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/ Let us know here if you have any questions. Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1890881 [Bug 1890881] Python 3.10 tracker -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1833858] Droid Hangul Jamo is separated and printed respectively
by bugzilla＠redhat.com 04 Jun '21

04 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1833858 --- Comment #23 from Luke Hutchison <luke.hutch(a)gmail.com> --- PS Droid Sans Fallback is often selected as the sans fallback font by Chrome on Fedora, and since the droid-sans-fonts package is default on Fedora (or at least a dependency of many other packages), this font frequently breaks Web browsing in Korean on Fedora -- so it's a pretty visible bug. Even within a single sentence, some words (words starting with 가) fall back to Droid Sans Fallback, and some fall back to Noto Sans CJK. See a depiction of this pattern here: https://github.com/harfbuzz/harfbuzz/issues/3003 The reason for this is probably that 가 is the pronunciation of the first jamo in the Korean alphabet, so it is used when spelling out bullet points etc. (equivalent to A, B, C, ...), and I'm guessing that Droid Sans Fallback contains the phonetic spelling of each jamo such as 가. So the fallback decision is made based on the first character in each word (at least in Google Docs, which probably calls the font measuring API for each word in a sentence, triggering a fallback decision for each word). This indicates that the fallback logic can be improved. Currently the fallback determination seems to be being made based on the first Unicode codepoint in a span of text submitted for shaping. Is that a correct assumption? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1833858] Droid Hangul Jamo is separated and printed respectively
by bugzilla＠redhat.com 04 Jun '21

04 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1833858 Luke Hutchison <luke.hutch(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |luke.hutch(a)gmail.com --- Comment #22 from Luke Hutchison <luke.hutch(a)gmail.com> --- Korean text renders fine in Droid Sans, but not with Droid Sans Fallback. Does Droid Sans contain fully-composed Korean characters, or is it falling back to a font like Noto rather than Droid Sans Fallback? The google-droid-sans-fonts package is depended upon by many packages on Fedora, so removing the entire package is often simply not an option. What is the best fix? 1. Removing DroidSansFallbackFull.ttf from the google-droid-sans-fonts package 2. Removing the jamo from DroidSansFallbackFull.ttf 3. Copying the fully-composed Korean characters from Droid Sans (or whatever font it is falling back to, e.g. Noto) into DroidSansFallbackFull.ttf 4. Copying any useful fallback characters in DroidSansFallbackFull.ttf into DroidSans.ttf Broader questions: Why does font rendering fall back to a font that doesn't even contain the required fully-composed Korean characters? Is the font determined valid for fallback simply because it contains jamo, even though it doesn't contain fully-composed Korean characters? What library makes the font fallback decisions these days, based on the required glyphs -- is it HarfBuzz or FontConfig or something else? Surely if Korean font rendering is required, a font that contains jamo but not full characters should only be selected if it is the only font on the system that has any sort of Korean characters at all. -- 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

i18n-bugs June 2021