some text became unreadable during a distribution upgrade

This isn't a problem with ubuntu-release-upgrader but rather something with the desktop environment during the upgrade process so I've opened an ubuntu-meta task.

This is a longstanding bug in our font stack. Things can go very bad when a font in use is upgraded.

See for instance https://launchpad.net/bugs/1600160

It's not been noticed more recently because the Ubuntu font hasn't been updated in a while. (And there is no longer an Ubuntu GNOME shipping the Cantarell font by default.)

What about this idea for a workaround: have the upgrader temporarily switch the UI font to a font that hasn't been changed since Jammy?

I'm attaching a screenshot from an upgrade I did from Lunar to Mantic on July 18.

Status changed to 'Confirmed' because the bug affects multiple users.

> What about this idea for a workaround: have the upgrader temporarily switch the UI font to a font that hasn't been changed since Jammy?

That sounds as a reasonable idea. Maybe it would be sufficient to drop the Ubuntu font as the first choice and simply let fontconfig deal with it for everyone.

Gunnar Hjalmarsson wrote:
> Maybe it would be sufficient to drop the Ubuntu font as the first choice and
> simply let fontconfig deal with it for everyone.

I tested that approach. On an updated lunar I run this command:

gsettings set org.gnome.desktop.interface font-name 'Sans 11'

before doing "update-manager -d". The upgrade completed successfully without font rendering issues.

So as a workaround I'm thinking that an equivalent of that command could be added to the beginning of the main function in DistUpgradeViewGtk3.py file (before the first "Gtk.main()" call), while the equivalent of this command:

gsettings reset org.gnome.desktop.interface font-name

could be executed right before the computer is restarted.

Or maybe just a wrapper.

Here's a screenshot from today, upgrading Ubuntu Desktop 23.04 to 23.10. This is the screen where the upgrader asks to remove no longer needed packages. It makes me very uncomfortable to have this screen be unreadable.

Without my workaround, I didn't even get that far, but it hanged before the "Cleaning up" phase. I could reboot manually, though.

With the workaround, the upgrade completed including "Cleaning up".

The attached script is an attempt to express my idea in python code. I don't know where exactly I'd put those commands, though, so that's why I abstain from a merge request.

I think we'd want to put it in a "quirk" and those are found in DistUpgradeQuirks.py:

https://git.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/tree/DistUpgrade/DistUpgradeQuirks.py?h=ubuntu/mantic

I think a "StartUpgrade" quirk is likely the best time for this but there should be a check to ensure that we are using the gtk frontend or some other check to ensure that we really need to modify the font.

Gunnar, one concern raised is that 'Sans 11' may be a different font size than is used for the current interface font, so setting this may cause legibility problems for users who have intentionally configured larger fonts. Can you suggest a workaround that's font-size-neutral?

@Steve: I made such a change to the MR.

I recall this bug was reported around last cycle too. But I wonder; is it specific to Nvidia desktops like bug 1876632?

On 2023-09-25 03:15, Daniel van Vugt wrote:
> is it specific to Nvidia desktops like bug 1876632?

No.

@Daniel: Maybe I answered a bit hasty. I see this issue over and over again without any Nvidia driver. But I do have a Nvidia card, if that may be related.

Not sure about the root cause of this bug. We know that it happens with the Ubuntu font and that that font was changed in the mantic cycle. But is the font change to blame, or is it maybe some inability in Gtk/Pango/whatever to deal with a font change smoothly? Or is it a limitation in fontconfig? Would the issue show up if some other font in use had been changed, even if it was not set via the font-name dconf value?

Those are thoughts in my head.

Hopefully an ubuntu-release-upgrader workaround will be in place soon.

But in a sense this is an ubuntu-meta matter as well. The code in my merge proposal sets the "Sans" font temporarily, which in lunar means that either DejaVu Sans or Noto Sans will be used in the UI during the upgrade (unless the user has configured fontconfig to use some other font...). And that is fine in lunar, since DejaVu Sans is always present, and neither DejaVu Sans nor Noto Sans were changed during the mantic cycle.

But one of the changes in mantic is that no font is safely present (i.e. the default ones are "Recommends:" only). So later, when people will upgrade from 23.10 to 24.04, just using "Sans" temporarily may not be the best option. And changing it to a specific font family is tricky, since we don't know if the user has uninstalled some of the default font packages.

So my thought is: Can this be a reason to let desktop-common depend on, and not only recommend, some font package after all? And if so, which package would be suitable for the purpose?

Trying to think in terms of robust general solutions to this problem, what
if update-manager were to notice when fonts were upgraded, and when they
are, shut down the GUI connection and reinitialize it? This might require
saving a bit of state information in update-manager in order to be able to
restore it.

Similiar in principle would be for the font libraries to notice when the
fonts have changed on disk and react accordingly, but since this obviously
hasn't been done yet and this problem has existed for years, we maybe
shouldn't count on solving that in the near term.

On 2023-09-26 22:52, Steve Langasek wrote:
> Trying to think in terms of robust general solutions to this problem,
> what if update-manager were to notice when fonts were upgraded, and
> when they are, shut down the GUI connection and reinitialize it?
> This might require saving a bit of state information in
> update-manager in order to be able to restore it.

If I was in a nitpicking mode I would mention that the unreadable character problem also affects the desktop itself and possible open programs (even if the latter is advised against). So it's not obvious to me that the approach you mention would be better.

On Tue, Sep 26, 2023 at 09:38:21PM -0000, Gunnar Hjalmarsson wrote:
> If I was in a nitpicking mode I would mention that the unreadable
> character problem also affects the desktop itself and possible open
> programs (even if the latter is advised against). So it's not obvious to
> me that the approach you mention would be better.

It does, which is why improved robustness in the font libraries is
preferred. But without an improvement there, the most we can hope for is to
ensure the upgrader itself remains usable to let the upgrade complete and
allow the user to reboot to the updated system.

For the near term, I am working on adapting Gunnar's existing work in a way that we restore the font on the next boot after the upgrade.

@Nick: That would be an improvement indeed. Guess you abandon /tmp then. ;)

On 2023-09-26 22:32, Gunnar Hjalmarsson wrote:
> But one of the changes in mantic is that no font is safely present
> (i.e. the default ones are "Recommends:" only). So later, when people
> will upgrade from 23.10 to 24.04, just using "Sans" temporarily may
> not be the best option. And changing it to a specific font family is
> tricky, since we don't know if the user has uninstalled some of the
> default font packages.
>
> So my thought is: Can this be a reason to let desktop-common depend
> on, and not only recommend, some font package after all? And if so,
> which package would be suitable for the purpose?

To make it easier to keep 'the temporary font' approach in 24.04 — if that is what we want by then — I added a hard dependency on fonts-dejavu-core to desktop-common. No upstream changes to the DejaVu fonts have been made the last 6 years, so it's more or less unmaintained, which in this context is an advantage.

I have uploaded the fix. I am adding block-proposed so that I can do another test, i.e. do-release-upgrade -d -p, just because the manual way of testing differs slightly.

This bug was fixed in the package ubuntu-meta - 1.523

---------------
ubuntu-meta (1.523) mantic; urgency=medium

  * Refreshed dependencies
  * Added fonts-dejavu-core to desktop, desktop-minimal, desktop-raspi
    (LP: #2034986)
  * Removed fonts-dejavu-mono from desktop-minimal-recommends,
    desktop-raspi-recommends, desktop-recommends

 -- Gunnar Hjalmarsson <email address hidden> Fri, 29 Sep 2023 12:53:17 +0200

This bug was fixed in the package ubuntu-release-upgrader - 1:23.10.7

---------------
ubuntu-release-upgrader (1:23.10.7) mantic; urgency=medium

  * DistUpgradeQuirks: Use generic font temporarily at upgrade
    (LP: #2034986)
  * DistUpgradeQuirks: Switch snap channels instead of refresh
    (LP: #2036765)
  * DistUpgradeController: Ensure security archive is used for security pocket
    (LP: #2036679)
  * Run pre-build.sh: updating mirrors and demotions.

 -- Nick Rosbrook <email address hidden> Fri, 29 Sep 2023 14:44:34 -0400

I'm re-opening this bug as it seems as though it's not fixed per LP: #2038726, which I've marked as a duplicate here.

Erich, maybe a separate bug is appropriate here.

The original issue, upgrading Ubuntu Desktop from 23.04 to 23.10, works for me now.

To the extent I participated in the resolution of this bug, I had standard Ubuntu in mind, where the default desktop font can be accessed like this:

gsettings get org.gnome.desktop.interface font-name

And that's the key whose value is temporarily changed when upgrading to 23.10. But on MATE that does not help, since MATE uses its own schema:

gsettings get org.mate.interface font-name

And since MATE uses the Ubuntu font by default, the issue is identical to the issue in standard Ubuntu. I think the fix in ubuntu-release-upgrader can be adjusted so it interacts with the schema which is actually in use in MATE.

But this makes me wonder if there is a need to special case other flavors besides MATE.

I submitted a MP to make the fix apply to MATE. It's not without issues, though (see the linked MP), and I think we need involvement from the MATE developers.

Gunnar asked

> But this makes me wonder if there is a need to special case other flavors besides MATE.

I've noted a number of users report 'garbled' or 'unreadable' text on discord (testing-cycles) & Ubuntu-MATE discourse (#1) but one of those reports led us back here, alas I'm not aware of any beyond Jim Markus who've actually followed up with an actual bug report, and I can't provide any useful info.

I have run a test looking for this issue specifically with Lubuntu (lunar -> mantic) and did NOT experience an issue on a virtualbox VM.

Links shouldn't be necessary; but included anyway

#1: https://ubuntu-mate.community/t/ubuntu-mate-23-10-testing/26876/11
#2: http://iso.qa.ubuntu.com/qatracker/milestones/446/builds/282097/testcases/1310/results

Thanks Chris! Possibly no other flavor is affected by this issue, at least not in this cycle.

I filed the Lubuntu equivalent of this bug as https://launchpad.net/bugs/2038946 Minor issue, didn't affect the upgrade itself or most apps. Easy workaround for Firefox.

I just ran an errand, and thought about that font workaround. The MATE issue makes me doubt about running the code for all the flavors.

We know that the root cause is changes to the Ubuntu font. That font is explicitly used for desktop in standard Ubuntu and MATE. But is it used for desktop by any other flavor?

I fear that we for other flavors mess with their settings unnecessarily. If the reset succeeds, it doesn't matter much, but maybe more flavors have not enabled the required systemd integration, and then our 'temporary' change gets persistent. Which may or may not matter in practice.

So maybe it would be better to only run the code for flavors where we know that it makes a difference. Something like:

        is_mate = False
        desktops = os.getenv('XDG_CURRENT_DESKTOP', '').split(':')
        if 'MATE' in desktops:
            schema = 'org.mate.interface'
            is_mate = True
        else if 'GNOME' in desktops:
            schema = 'org.gnome.desktop.interface'
        else if 'xxx' in desktops:
            schema = 'yyy'
        else:
            return

Sorry for the noise about Lubuntu. There is a very minor issue seen during the upgrade if Firefox is running (regardless of whether the desktop is Lubuntu). It's recommended to not run other apps during the upgrade. In this case, restarting Firefox is usually enough to fix the issue. If not, restarting after the upgrade completes does fix the issue.

Besides the very minor Firefox issue, I didn't see any font issues when I tested 23.04 -> 23.10 basic upgrades today of

- Ubuntu Desktop
- Ubuntu Budgie
- Kubuntu
- Lubuntu
- Xubuntu

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
https://iso.qa.ubuntu.com/qatracker/reports/bugs/2034986

just attaching a screen shot

@Ethan: MATE is about to be fixed. Once ubuntu-release-upgrader 1:23.10.10 has made it to mantic-release, you shouldn't be able to reproduce that. Let us know otherwise.

This bug was fixed in the package ubuntu-release-upgrader - 1:23.10.10

---------------
ubuntu-release-upgrader (1:23.10.10) mantic; urgency=medium

  * Fix failing autopkgtest due to PEP8 line to long issue.
  * Run pre-build.sh: updating po files, mirrors, and demotions.

ubuntu-release-upgrader (1:23.10.9) mantic; urgency=medium

  [ Tim Andersson ]
  * fix: stop TypeError traceback in DistUpgradeQuirks:_set_generic_font
    (LP: #2038900)

  [ Brian Murray ]
  * Run pre-build.sh: updating po files, mirrors, and demotions.

  [ Gunnar Hjalmarsson ]
  * Temporary font for Ubuntu MATE (LP: #2034986)

 -- Brian Murray <email address hidden> Wed, 11 Oct 2023 04:48:13 -0700

Hello Brian, or anyone else affected,

Accepted ubuntu-release-upgrader into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:23.04.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hmm.. The XDG_CURRENT_DESKTOP variable keeps being present when you use sudo, which is the reason why we successfully tested the MATE specific code. Apparently the pkexec environment differs.

I've tested an upgrade of Ubuntu MATE (running Lunar) with -proposed enabled with version 1:23.04.7 installed and the fonts in the body of the ubuntu-release-upgrader were legible, however the title bar was corrupted but that's fine.

On 2023-10-12 18:39, Brian Murray wrote:
> however the title bar was corrupted but that's fine.

Yeah, that's expected. I didn't think it was motivated to play with multiple dconf keys only for MATE.

Status changed to 'Confirmed' because the bug affects multiple users.

Hello Brian, or anyone else affected,

Accepted ubuntu-release-upgrader into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:22.04.18 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

I tested a lunar -> mantic desktop upgrade last night and did not encounter the bug described here.

I just did this with vanilla ubuntu with the ubuntu-release-upgrader version from proposed and everything was fine - no wild font changes.

I'm investigating the flavors in this respect more systematically, and just found that a 23.04 -> 23.10 upgrade of Ubuntu Cinnamon is still hit by this issue (they use the schema org.cinnamon.desktop.interface ...). So adding the Cinnamon project for now.

I will soon come up with a proposal for mantic to deal with some details including the Cinnamon issue.

Hello Brian, or anyone else affected,

Accepted ubuntu-release-upgrader into mantic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:23.10.11 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-mantic to verification-done-mantic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-mantic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Gunnar, I tested these desktop flavors successfully (23.04 to 23.10):
- Ubuntu Desktop
- Ubuntu Budgie
- Ubuntu Kylin
- Kubuntu
- Lubuntu
- Xubuntu

That means I also missed Ubuntu Unity.

On 2023-10-13 22:10, Jeremy Bícha wrote:
> Gunnar, I tested these desktop flavors successfully (23.04 to 23.10):
> - Ubuntu Desktop
> - Ubuntu Budgie
> - Ubuntu Kylin
> - Kubuntu
> - Lubuntu
> - Xubuntu

Thanks for reporting that. I have not found otherwise.

But in most of those cases (not Ubuntu Desktop) the text keeps being readable simply because they use a font (read: Noto Sans) which hasn't changed during the cycle.

> That means I also missed Ubuntu Unity.

I think the fix already in place applies to Unity too.

I'll explain more when posting about my next MP. :/

Since I propose yet another SRU, I created bug #2039356. This bug report is quite noisy already...

My examination of the flavors with respect to this issue focused on two questions:

1. Does the u-r-u model effectively prevent 'the unreadable text issue' when the desktop font in use — whether default or set by the user — has changed during the cycle?

After the changes proposed via bug #2039356 I would say "yes" for:

 Ubuntu Desktop
 Ubunu Budgie
 Ubuntu Cinnamon
 Ubuntu Kylin
 Ubuntu MATE
 Ubuntu Unity

while the model (i.e. temporarily changing a dconf value which represents the desktop font) is not effective for:

 Kubuntu
 Lubuntu
 Xubuntu

In case of Kubuntu and Lubuntu the Qt way of dealing with fonts seems to require something else, and the Xfce way applied in Xubuntu means similar difficulties. Fortunately all those flavors use a desktop font by default (Noto Sans) which was not changed during the cycle, so this does not need to be addressed for mantic.

But if you like, you can trigger the 23.04 -> 23.10 upgrade issue in for instance Xubuntu: Go to Settings -> Appearance -> Fonts and change the "Default Font" from Noto Sans to Ubuntu. Doing so will be reflected both in the ~/.config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml file and in dconf (gsettings get org.gnome.desktop.interface font-name), but changing the font-name dconf value only to something else during upgrade (as we do) won't change the effective desktop font in Xubuntu, which results in 'the unreadable text issue'.

2. Is the temporary desktop font dconf value properly reset at next login after reboot?

Yes it is, after the changes proposed via bug #2039356.

Since this bug fix cannot be properly verified for Mantic until the archive is open for the next release, I have temporarily reverted this change in my last upload so that we can proceed with the fix in bug 2039356 for now.

Edit: By "this change", I mean the most recent change related to this bug which was uploaded in 1:23.10.11.

Just now upgrading ubuntu-mate 23.04 to 23.10 and encountered the corrupt text issues. Screenshot attached.

@Michael: Then you hadn't installed version version 1:23.04.7 of ubuntu-release-upgrader first, right? Please compare comment #44.

The verification of the Stable Release Update for ubuntu-release-upgrader has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package ubuntu-release-upgrader - 1:23.04.7

---------------
ubuntu-release-upgrader (1:23.04.7) lunar; urgency=medium

  * do-release-upgrade: pass XDG_CURRENT_DESKTOP env var (LP: #2034986)
  * Run pre-build.sh: updating po files, mirrors, and demotions.

 -- Nick Rosbrook <email address hidden> Thu, 12 Oct 2023 10:52:01 -0400