Bug 1619530 - Replacement character shown in Georgian (ქართული) on the “Welcome to Fedora 29” page
Summary: Replacement character shown in Georgian (ქართული) on the “Welcome to Fedora 2...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bpg-fonts
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-21 06:52 UTC by Mike FABIAN
Modified: 2020-10-03 00:56 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-03 00:56:00 UTC
Type: Bug


Attachments (Terms of Use)
fedora-29-welcome-georgian-replacement-character.png (144.33 KB, image/png)
2018-08-21 06:52 UTC, Mike FABIAN
no flags Details
Fedora 29 Screenshot (51.61 KB, image/png)
2018-10-23 14:11 UTC, A S Alam
no flags Details
F32 Live Screenshot (106.30 KB, image/png)
2019-11-12 11:49 UTC, Vendula Poncova
no flags Details

Description Mike FABIAN 2018-08-21 06:52:04 UTC
Created attachment 1477421 [details]
fedora-29-welcome-georgian-replacement-character.png

When installing:

Fedora-Workstation-netinst-x86_64-29-20180820.n.1.iso

in qemu, on the welcome page I see:

    Ქართული Georgian

i.e. the first character of the word “Georgian” in Georgian language
seems to be shown as a replacement box showing only the code point
U+1CA5.

1CA5;GEORGIAN MTAVRULI CAPITAL LETTER KHAR;Lu;0;L;;;;;N;;;;10E5;

Maybe there is no suitable font?

Comment 1 Mike FABIAN 2018-08-21 06:58:41 UTC
This character seems to be new in Unicode 11.0.0

Comment 2 Mike FABIAN 2018-08-21 07:05:04 UTC
$ fc-list :charset=1CA5

lists nothing for me on my Fedora 29 system.
(It lists all fonts I have installed supporting that character).

Comment 3 A S Alam 2018-10-23 14:11:49 UTC
Created attachment 1496705 [details]
Fedora 29 Screenshot

Comment 4 A S Alam 2018-10-23 14:14:50 UTC
it may be related to #1530086 kind of issue.
Once you selected Georgian, then you are able to see Right Top corner with missing glyphs too with Unicode: 1C98, 1CA1, 1CA9 1C90 1C93 1C92, 1C9B etc. Fonts were good on other screen.

Tested with ISO: Fedora-Workstation-Live-x86_64-29-20181021.n.0.iso

Comment 5 Mike FABIAN 2018-10-31 20:23:58 UTC
(In reply to A S Alam from comment #4)
> it may be related to #1530086 kind of issue.
> Once you selected Georgian, then you are able to see Right Top corner with
> missing glyphs too with Unicode: 1C98, 1CA1, 1CA9 1C90 1C93 1C92, 1C9B etc.
> Fonts were good on other screen.
> 
> Tested with ISO: Fedora-Workstation-Live-x86_64-29-20181021.n.0.iso

We might not have a font supporting U+1CA5 in Fedora at all.

Comment 6 Jens Petersen 2019-07-16 07:20:08 UTC
It is surprising then that neither bpg-sans-fonts or google-noto-sans-georgian-fonts cover the glyph(s).

Comment 7 Jiri Konecny 2019-07-16 09:23:11 UTC
Could we please reassign this to something else. If the fonts are not part of the Fedora now then Anaconda is not the correct component to handle that.

Comment 8 Alan 2019-08-26 08:34:23 UTC
The Georgian script became bicameral in Unicode 11, but the problem is that the new letters are NOT used in title case. The Mtavruli capitals were introduced for all caps emphasis styling, so the auto capitalization function should not be used for Georgian texts.
See https://www.unicode.org/reports/tr44/#Change_History (under UnicodeData.txt for Unicode 11).

(In reply to Jens Petersen from comment #6)
> It is surprising then that neither bpg-sans-fonts or
> google-noto-sans-georgian-fonts cover the glyph(s).

There is a work around for Noto fonts: https://github.com/googlefonts/noto-fonts/issues/1261
Here you can get bpg-fonts that support Mtavruli: https://bpgfonts.wordpress.com/2018/09/07/gnu-gpl-license-grant-to-linux-distributors/

Comment 9 Mike FABIAN 2019-09-17 06:20:04 UTC
So anaconda should make an exception for Georgian not to automatically capitalize the first letter.

Comment 10 Jens Petersen 2019-11-06 15:31:46 UTC
(In reply to Mike FABIAN from comment #9)
> So anaconda should make an exception for Georgian not to automatically
> capitalize the first letter.

Shouldn't that be handled elsewhere?

Comment 11 Tom "spot" Callaway 2019-11-06 16:50:54 UTC
bpg-fonts-20120413-14.fc32 just built in rawhide, it includes the newer bpg versions of DejaVu indicated in Comment #8.

If I need to also build this for stable branches, please let me know.

Comment 12 Mike FABIAN 2019-11-12 06:49:32 UTC
(In reply to Jens Petersen from comment #10)
> (In reply to Mike FABIAN from comment #9)
> > So anaconda should make an exception for Georgian not to automatically
> > capitalize the first letter.
> 
> Shouldn't that be handled elsewhere?

I guess this code does it:

https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/localization.py#L315

def get_native_name(locale):
    """
    Function returning native name for the given locale.
    :param locale: locale to return native name for
    :type locale: str
    :return: english name for the locale or empty string if unknown
    :rtype: st
    :raise InvalidLocaleSpec: if an invalid locale is given (see LANGCODE_RE)
    """

    parts = parse_langcode(locale)
    if "language" not in parts:
        raise InvalidLocaleSpec("'%s' is not a valid locale" % locale)

    name = langtable.language_name(languageId=parts["language"],
                                   territoryId=parts.get("territory", ""),
                                   scriptId=parts.get("script", ""),
                                   languageIdQuery=parts["language"],
                                   territoryIdQuery=parts.get("territory", ""),
                                   scriptIdQuery=parts.get("script", ""))

    return upcase_first_letter(name)

So it upper cases the first letter of the language name. For almost all languages, this is what we want if the name appears isolated in a list, it is sort of like at the start of a sentence then. For languages which don’t have uppercase letters (like Japanese for example), the uppercasing changes nothing. Georgian seems special in that uppercase letters are available, but apparently they are not supposed to be used in title case.

Comment 13 Mike FABIAN 2019-11-12 06:54:25 UTC
So it looks like we need something like this:

$ git diff 
diff --git a/pyanaconda/localization.py b/pyanaconda/localization.py
index 59a58d51f..e642cb5db 100644
--- a/pyanaconda/localization.py
+++ b/pyanaconda/localization.py
@@ -335,6 +335,8 @@ def get_native_name(locale):
                                    territoryIdQuery=parts.get("territory", ""),
                                    scriptIdQuery=parts.get("script", ""))
 
+    if parts["language"].startswith("ka"):
+        return name
     return upcase_first_letter(name)
 
 def get_available_translations(localedir=None):
lines 1-13/13 (END)

which looks crazy, but what else could one do?

Comment 14 Jiri Konecny 2019-11-12 10:15:10 UTC
The question is if we should use other fonts which would work or to change Anaconda code. Honestly the first variant seems like a less hacky to me...

Comment 15 Vendula Poncova 2019-11-12 11:49:48 UTC
Created attachment 1635300 [details]
F32 Live Screenshot

Comment 16 Vendula Poncova 2019-11-12 11:56:32 UTC
When I install bpg-dejavu-sans-fonts in Live OS, the issue seems to be fixed (see the attachment F32 Live Screenshot). Could someone confirm that this is the expected output? If yes, we need to make sure that the font is installed in the boot.iso (handled by lorax) and Live images (handled by spin-kickstarts). Anaconda doesn't install any fonts.

Comment 17 Nicolas Mailhot 2019-11-12 13:13:01 UTC
(In reply to Jiri Konecny from comment #14)
> The question is if we should use other fonts which would work or to change
> Anaconda code. Honestly the first variant seems like a less hacky to me...

The first option is a short-term workaround. The way Georgian has been standardized Unicode-side is not expected to change. So if anaconda does not handle it properly, the issue will come back in a few releases when the Fedora font set gets updated.

Comment 18 Jiri Konecny 2019-11-12 13:45:01 UTC
(In reply to Nicolas Mailhot from comment #17)
> (In reply to Jiri Konecny from comment #14)
> > The question is if we should use other fonts which would work or to change
> > Anaconda code. Honestly the first variant seems like a less hacky to me...
> 
> The first option is a short-term workaround. The way Georgian has been
> standardized Unicode-side is not expected to change. So if anaconda does not
> handle it properly, the issue will come back in a few releases when the
> Fedora font set gets updated.

Don't you think that this problem is bigger than Anaconda? Anaconda is just one of the projects but all the projects supporting Georgian may experience the same issue. I don't think it's reasonable to fix one case instead of fixing the root cause here.

Comment 19 Nicolas Mailhot 2019-11-12 14:04:15 UTC
Yes, sure, it’s bigger than a font or Anaconda, it’s how Georgian is expected to behave, and how it got standardised

Comment 20 Alan 2019-11-14 23:27:59 UTC
(In reply to Vendula Poncova from comment #16)
> When I install bpg-dejavu-sans-fonts in Live OS, the issue seems to be fixed
> (see the attachment F32 Live Screenshot). Could someone confirm that this is
> the expected output? If yes, we need to make sure that the font is installed
> in the boot.iso (handled by lorax) and Live images (handled by
> spin-kickstarts). Anaconda doesn't install any fonts.

The text on the right top corner (Fedora's installation) is correctly shown in Georgian, as long as it's all caps. But the word "Georgian" in the language menu is inaccurate, because titlecasing is not expected in modern Georgian.

(In reply to Mike FABIAN from comment #9)
> So anaconda should make an exception for Georgian not to automatically
> capitalize the first letter.
Yes, automatic capitalization just should not be applied to Georgian text. A localizer can decide, whether or not to use uppercase for emphasis.

> (In reply to Jens Petersen from comment #6)
> > It is surprising then that neither bpg-sans-fonts or
> > google-noto-sans-georgian-fonts cover the glyph(s).
> 
> There is a work around for Noto fonts:
> https://github.com/googlefonts/noto-fonts/issues/1261
> Here you can get bpg-fonts that support Mtavruli:
> https://bpgfonts.wordpress.com/2018/09/07/gnu-gpl-license-grant-to-linux-
> distributors/
Now Google Noto fonts also include Mtavruli characters (updated 2 months ago):
https://github.com/googlefonts/noto-fonts/tree/master/hinted/NotoSansGeorgian

Comment 21 Mike FABIAN 2020-04-07 06:28:23 UTC
Problem still exists on F32.

Comment 22 Jens Petersen 2020-05-21 09:17:08 UTC
Is there a python library that provides an appropriate title case function?

Comment 23 Jens Petersen 2020-05-21 13:44:03 UTC
Will making bpg-dejavu-sans-fonts default in the @fonts group cause any problems?

Comment 24 Nicolas Mailhot 2020-05-21 13:53:42 UTC
No, because bpg-dejavu-sans-fonts is not a complete fork of dejavu, it is missing other parts.

Also, bpg-dejavu-sans-fonts is quite shaky legal-wise, the Georgian dev is completely clueless about licensing, I’m not sure its GPL use is compatible with the licensing in the other parts of dejavu, and even if it is, there are good reason we are not using the GPL for font files (it would make documents, that embed font parts, such as ODF or PDF, GPL, which is definitely not what our users need).

We really need someone to revive the upstream dejavu project and restart merging fixes and enhancements, since the original authors lost the drive. (Can’t really blame them when downstreams like Fedora Workstation removed DejaVu as default font just because it was steady and “boring”).

Comment 25 Jens Petersen 2020-05-22 14:21:30 UTC
(In reply to Nicolas Mailhot from comment #24)
> No, because bpg-dejavu-sans-fonts is not a complete fork of dejavu, it is
> missing other parts.
> 
> Also, bpg-dejavu-sans-fonts is quite shaky legal-wise, the Georgian dev is
> completely clueless about licensing, I’m not sure its GPL use is compatible
> with the licensing in the other parts of dejavu, and even if it is, there
> are good reason we are not using the GPL for font files (it would make
> documents, that embed font parts, such as ODF or PDF, GPL, which is
> definitely not what our users need).

Sounds like Noto Georgian may be a better bet then.
Not to mention the BPG family names typos.

> We really need someone to revive the upstream dejavu project and restart
> merging fixes and enhancements, since the original authors lost the drive.

That would be great indeed.

> (Can’t really blame them when downstreams like Fedora Workstation removed
> DejaVu as default font just because it was steady and “boring”).

That is not completely accurate, Dejavu is still default, just not for Gnome UI chrome.
(And that was encouraged by Gnome, not particularly Fedora Workstation.)

Comment 26 George Machitidze 2020-05-22 16:54:44 UTC
Hello,

One thing I can tell - we don't have a case in Georgian alphabet, some fonts include uppercase characters, some don't, but they are not really uppercase, they're just another set of glyphs or fonts inserted in the collection. They never should be mixed - we don't do that.
Georgian devs are not clueless about licensing, we've been in quite long strict discussions about it since 2004. I have direct contact with all original font developers (Including mentioned BPG), so, I can check anything we need. Dejavu family includes fonts originally created by BPG, and Georgian LUG members were quite careful when we've asked him to include his works and release them as GPL licensed so we could include it in Linux distributions. Same applies to the keyboard layouts - that was done at the same time...
What exactly is the case? How can I help?

Comment 27 George Machitidze 2020-05-22 16:57:17 UTC
direct answer to this issue is to have all characters in lowercase, because this is how Georgian language works - WE DON"T HAVE UPPERCASE characters, don't use them.

Comment 28 Alan 2020-05-22 20:17:59 UTC
It's a good idea to switched to Google Noto as a default font for Georgian, or use it as an alternative to BPG.

P.S. We use Mtavruli characters almost everywhere and we definitely need them. 
You can see a lot of examples at the end of this document:
https://www.unicode.org/L2/L2016/16034-n4707-georgian.pdf
See also this Q&A:
https://www.unicode.org/L2/L2017/17045-georgian-resp.pdf

In modern Georgian, Mtavruli is not used for mixed/title casing, only with the All Caps function, but it does NOT mean, that we don't have uppercase or they are not capital letters.

Comment 29 George Machitidze 2020-05-23 05:25:12 UTC
Not that we just don't use them, WE DON'T HAVE THEM, therefore, we don't have mixed casing at all. There are no capital letters.
"Mtavruli" is just a representation, it's not a case or capitalization.
You can read it in attached document "Mtavruli-style letters are never used as “capitals”; a word is always entirely presented in mtavruli or not"

Comment 30 George Machitidze 2020-05-23 05:43:13 UTC
+ Georgian glyphs in Google Noto are terrible and inadequately large when compared to other fonts containing Georgian glyphs and VERY large compared to glyphs written in Latin with the same Google Noto. Probably, that's the reason why nobody uses it here :)

Comment 31 Nicolas Mailhot 2020-05-23 08:17:56 UTC
@George Machitidze 

### Legal aspects

Much as I love the GPL and use it for my own projects it does not translate well to font files.

From a legal point of view, software is derived into other software, so a license that propagates to derived works like the GPL does, works well. It’s software both parts of the equation.

However, fonts can be derived into documents due to how document formats embed fonts (fully or via subsetting). Therefore, the GPL and software licenses in general are completely inadequate for font files. Most people do not want their documents GPLed just because they used a Free and Open font in them.

Because the GPL is inadequate, there was quite a lot of experimenting at the start of the century to find a working license for Free and Open fonts. Some proposed font-specific GPL legal extensions. Others wrote brand new experimental licenses. In the end most everyone agreed to use the OFL, which is the font license of most Google fonts today, and the font license Fedora recommends for new font projects.

DejaVu antedates all of this however. It is a direct derivative of Bitstream Vera, which was released under one of licenses people experimented with before settling on the OFL. Vera/DejaVu licensing is unlikely to change today because that would require Bitstream cooperation and probably quite a lot of money to motivate the Bistream legal department to look at it.

When adding to or modifying Vera or DejaVu, you should strive to keep things simple and integrate the original Vera/DejaVu legal framework. DejaVu licensing is complex and one-of-a-kind due to the inadequacies of the original experimental Bitstream licensing. It’s not as simple as using vanilla GPL for software or the OFL for new font projects.

https://github.com/dejavu-fonts/dejavu-fonts/blob/master/LICENSE

When the DejaVu project was active it served as legal clearing house and made sure contributors understood and and agreed with those legal clauses. Now it is dormant, people that release DejaVu derivatives must do this work themselves.


### Font coverage aspect

From a font file point of view the only thing we can do is try to integrate fonts with correct opentype metadata and correct unicode coverage.

It is no use, as you wrote, to remove coverage from font files. Software that wants to use specific code-points will just fall back to fonts that include this coverage. If you want to prevent those fallbacks the only reliable way is to integrate good coverage in your font file so the fallback need not happen.

If things still do not work after a font with good unicode coverage was deployed, then that means:

1. some piece or text rendering is making mistakes when applying the unicode standard. No use work-arrounding the standard by using incomplete or non-compliant font files here, you need to identify which part is misapplying the standard and get it fixed

2. the Unicode standard is wrong. Well, I sort of doubt this is the case here, but human creations are imperfect by nature. If the standard is wrong then you need to get it fixed because software implementers are applying the standard and do not have time to waste sifting through all the pseudo-standards people keep inventing all over the world. That’s the sole reason people use Unicode today. It is horribly complex, and not ideal, but having to deal with multiple conflicting encoding rules would be way worse. Chinese/Japanese/Korean people yelled for a decade Unicode made the wrong decisions for their scripts. They are using Unicode like everyone else today anyway, because the alternative to Unicode, are way worse from a software interoperability point of view.

Comment 32 Alan 2020-05-23 10:32:39 UTC
@George Machitidze 

> You can read it in attached document "Mtavruli-style letters are never used as “capitals”; a word is always entirely presented in mtavruli or not"
And you can also read the answer:
> This statement was not correct. A number of documents from the late 19th century and early 20thcentury make use of mtavruli
> characters in initial position in sentences, lines of verse, and for propernames and place-names.
For example:
https://ka.wikipedia.org/wiki/%E1%83%A5%E1%83%90%E1%83%A0%E1%83%97%E1%83%A3%E1%83%9A%E1%83%98_%E1%83%93%E1%83%90%E1%83%9B%E1%83%AC%E1%83%94%E1%83%A0%E1%83%9A%E1%83%9D%E1%83%91%E1%83%90#/media/%E1%83%A4%E1%83%90%E1%83%98%E1%83%9A%E1%83%98:Deda_Ena_1876_cover.jpg

Google Noto fonts are used as default for Georgian in Android and Arch-based distributions. They look nice.
You can read here what Besarion thinks about Mtavruli (or ask him, if you have a direct communication)
https://bpgfonts.wordpress.com/2016/02/24/mtavruli-for-perfection/

Comment 33 George Machitidze 2020-05-23 13:17:17 UTC
@Nicolas Mailhot 

Thanks for details
1. If we should ditch DejaVu for legal issues - definitely, it must be done
2. Easy way - so far, only non-DejaVU font I can recommend to be GPL licensed (verified author and font) are from BPG family (https://bpgfonts.wordpress.com/2009/02/03/gpl-gnu-license-bpg-fonts/), If we need any clarification on that - I can contact him.
3. Long way - I can ask all major designers to create a font for us so we can include it somewhere, one of them already responded to my FB post regarding this issue (we have a discussion there). We can request any legal document if there is a concern - they can sign it.
4. I am not really sure about Google Noto - we don't know who is the author, but fonts are terrible and oversized (that's clearly visible)

@ALAN
I am Georgian, I've founded Georgian linux user group with my friends, I work on localization projects since 2004 (Ministry of Education and Science of Georgia), I am not a Fedora ambassador right now, just because I'm busy and lazy. I know what I am talking about, I'm not arguing. We've faced all these issues in 2004 and the result our work is:
0. Established relation with each-other, which was pretty hard because of different countries authors live (Georgia, Finland), differences in interests (Linux, Mac, Windows fans), difference in directions (RH fans, Canonical fans, KDE fans, GNOME fans), age gap (18 to 60 yo). We've all sat and decided to do the job the right way, usually we fight
1. Created new Georgian keyboard (MESS), included with other four keyboards in OSS XKB etc 
2. BPG published fonts in GPL, while other his fonts and fonts from other people (including GEO series from Gia Shervashidze and fonts from Reno Siradze) are also available for free and virtually without limitations
3. Localization of KDE, GNOME, Fedora, Ubuntu, Windows

Regarding Google Noto:
Google NEVER asked anyone anything, they've even included Keyboard only few years ago, they don't know whom to ask and what to do - they've never reached us or government. Same applies to all their products and all l10n/i18n parts. We've tried, but they don't care. Same applies to Apple and both are now under heavy criticism from users as we are hardly to reading the texts and glyphs. Virtual keyboards also look ugly and are not proportional. We get no response - tried to push issues though representative officials, via government, via Georgian Mac's User Group (some of us are founding members there too) - nothing works. We were able to solve issues only with OSS software and M$.

These Google fonts look REALLY BAD. It's hard to see whole picture if you haven't studied Georgian, but one thing you can easily find out - Georgian glyphs in Google Noto are HUGE. proportions are inadequate. Try to write few letters in latin Goto and then the same with Georgian, size is about 1.5 bigger. 

It's elementary and offensive. Who else are we looking for?

If I will ask something like that to Besarioni, definitely, he'll laugh at me and never talk again (he's a man of character).

Comment 34 Alan 2020-05-23 15:48:35 UTC
@George Machitidze 

The author of Google Noto Georgian is Akaki Razmadze.
More info - https://www.marketer.ge/akaki-razmadze-ios13-android-10/
He also designed FiraGO Georgian, which is publicly available under FOSS license.
So, I think, you can feel free to contact him.

It's a modern-style typeface. Please see Besarion's post on FB 
https://www.facebook.com/groups/geotypography/permalink/1499502893517216/?comment_id=1500283223439183&comment_tracking=%7B%22tn%22%3A%22R%22%7D
Yes, I know who you are (from Tbilisi forum), I am Georgian too.

Comment 35 George Machitidze 2020-05-23 19:29:36 UTC
Good, that's Akaki

But font is large:
https://drive.google.com/file/d/1rUsmuLRyLCqfenjFMsc73SPe-ZBfSv-C/view?usp=sharing

Comment 37 Fedora Admin user for bugzilla script actions 2020-06-03 02:47:23 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 38 Ben Cotton 2020-08-11 13:05:18 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 39 Mike FABIAN 2020-09-07 07:59:51 UTC
Yes, it still exists in Fedora-Everything-netinst-x86_64-33-20200906.n.0.iso

Comment 40 Vendula Poncova 2020-09-10 14:43:25 UTC
I have proposed a fix for the installer in the pull request: https://github.com/rhinstaller/anaconda/pull/2837

Comment 41 Fedora Update System 2020-09-29 17:25:34 UTC
FEDORA-2020-384ff75a01 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-384ff75a01

Comment 42 Fedora Update System 2020-09-30 01:11:35 UTC
FEDORA-2020-384ff75a01 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-384ff75a01`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-384ff75a01

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 43 Fedora Update System 2020-10-01 16:39:38 UTC
FEDORA-2020-384ff75a01 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-384ff75a01

Comment 44 Fedora Update System 2020-10-02 01:46:13 UTC
FEDORA-2020-384ff75a01 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-384ff75a01`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-384ff75a01

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 45 Fedora Update System 2020-10-03 00:56:00 UTC
FEDORA-2020-384ff75a01 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.