gnome-terminal font settings show only italic version of ubuntu mono

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

Thank you for your bug report, could you perhaps report it upstream on https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues

the behaviour changed due to https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/0760f28a

could be due to https://gitlab.gnome.org/GNOME/pango/-/issues/483 or similar but if pango is buggy then perhaps using that feature isn't wanted...

@seb128 done https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/308

upstream has closed the issue on gnome-terminal, saying
"gnome-terminal only shows fonts that are monospace, as reported by pango. So if this font doesn't show up correctly, it's a problem in the font (or pango), not gnome-terminal."
i've poked the https://gitlab.gnome.org/GNOME/pango/-/issues/483 issue

Thanks for upstream it, it was not unexpected they would close it, indeed the issue is probably in pango, still they use a feature which isn't correctly working and it's reflecting negatively on the application so they could have decided to revert the filter until the api behavior is corrected...

this is just going in circles. i don't understand the details but it seems that:
* it's quite ok to have a monospace filter built into the gnome-terminal font selector
* this job is really delegated to the pango lib, which uses the first fc result to determine the spacing for the *whole* family
* for the ubuntu font the first fc result isn't the regular type, which has the spacing property, but some other variant which doesn't have it

last point hints at the urgency that this is fixed in the fonts themselves.

it's a great pity one cannot enjoy the ubuntu font in the gnome-terminal in the latest ubuntu distros.

Now we know from the upstream pango issue which commit caused this bug:

https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/e5c0b4f5

I confirmed that reversing that commit fixes it:

https://launchpad.net/~gunnarhj/+archive/ubuntu/gnome-terminal

Is that what we want to do?

On 2020-10-30 02:29, Gunnar Hjalmarsson wrote:
> Is that what we want to do?

Probably not.

https://gitlab.gnome.org/GNOME/pango/-/issues/483#note_949138

Matthias' gtk commits seem to fix it.

Thank you for providing fix for this! This is a bit of a tricky fix for SRUing, because generally this is a very low-profile bug. Generally, by principle, we usually SRU high-impact bug fixes (or other cases, as per [1]). The main reason for this is that every change introduces risk of new regressions, so by 'risking' the release of a high-impact fix, we generally can gain more than we can lose. Second thing is - all users will be getting this update, having to download it from the archives, so we'd like it to be 'worth it'.

So I'm not saying this is an instant 'no'. It's just rather unfortunate that we don't have other fixes staged along with this one for SRUing, since releasing more fixes in a batch is generally better practice.

I'm willing to include this anyway (under the "Other safe cases" section), but for this to be possible I would need a bit more information in the Regression Potential field. It's good to know the fix has been written with this particular bug in mind, but I'd like someone to look at the changes and try to analyze where things could 'blow up' if something goes wrong, if the fix has a bug. Basically we'd like to know where to look for any obvious new regressions that could be introduced by the bugfix code changes.

Thanks!

[1] https://wiki.ubuntu.com/StableReleaseUpdates#When

Hi Łukasz,

As regards other concurrent fixes, I first asked Iain Lane if there is such a plan for groovy, but the most likely SRU in pipeline would be a focal update to 3.24.23, so he gave me a 'green light' for this groovy one.

The bug is an annoying one. Maybe the importance was set too low...

The story is summarized on this upstream issue:

https://gitlab.gnome.org/GNOME/pango/-/issues/483

It was closed by Matthias C. since he first thought it was an issue with the Ubuntu font. When he realized that the incorrect gnome-terminal behavior was caused by an issue in gtk3's font chooser, he instantly submitted that commit. Please note that the only affected file is gtk/gtkfontchooserwidget.c, so the scope is very limited which in itself ought to limit the regression risk. Also, Matthias is an experienced GNOME developer, and usually knows what he is doing.

I have confirmed in advance that the change fixes the gnome-terminal issue.

Ok, I think I have enough information to give a green light for this change (especially that the Iain was +1 on getting it in as a single fix).

Hello Darko, or anyone else affected,

Accepted gtk+3.0 into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gtk+3.0/3.24.23-1ubuntu1.1 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-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. 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 it after installing libgtk-3-0 libgtk-3-common from proposed. i can confirm that the gnome-terminal settings custom font now shows only "ubuntu mono" when "ubuntu" is typed into the search box and therefore solves the issue.

nevertheless, note that this is still different than what we see in focal, namely typing "ubuntu" into the search shows ubuntu mono {regular, italics, bold, bold-italics}. it's probably fine to allow selecting only the regular font since italics is useless as a terminal font and bold is used for emphasis anyway...

packages installed: libgtk-3-common (3.24.23-1ubuntu1.1) over (3.24.23-1ubuntu1), libgtk-3-0:amd64 (3.24.23-1ubuntu1.1) over (3.24.23-1ubuntu1)

@Darko: Yeah, it's indeed different compared to focal. But as was stated on the upstream issue, it's an intentional design change, and probably better for most use cases given this gtk fix.

Thanks for verifying!

Thanks for the speedy work! I'm afraid I'm registering problems with the update, however.

I just got gir1.2-gtk-3.0 through -proposed, and whereas it works as intended in so far as I can now choose Ubuntu Mono in Gnome Terminal and get the regular font face, it seemingly introduces a bug where gnome-terminal crashes, when I try to select certain typefaces.

For instance, when I open up Preferences of go to the font selection box, as soon as I click on e.g. "DejaVu Sans Mono", gnome-terminal just closes. When I open it again, it's still using the previously set font. The problem also occurs with "Inconsolata", but seemingly not with any other fonts I have installed, whether fonts that ship with Ubuntu or fonts I've installed on my own.

indeed, i get a crash if i click on the following fonts: Bitstream Vera Sans Mono, DejaVu Sans Mono, Inconsolata, MathJax_Vector-Bold, and Terminus.

note that in the font chooser these font names appear to be rendered not in their particular typeface but with the default system font so is seems there is the bug still lingering somewhere.

Good catch, @Rasmus. I see the same thing, and posted my theory about what causes it here:

https://gitlab.gnome.org/GNOME/pango/-/issues/483#note_953154

Hmm.. I'm afraid this can be called a regression. Even if the wrong styles were shown previously, selecting any of those at least didn't cause gnome-terminal to crash.

@Łukasz: What do you think? Myself can't help thinking (again) about the alternative solution we discussed shortly, i.e. replacing this gtk change in groovy with a simple gnome-terminal patch which would give us the focal behavior back.

All autopkgtests for the newly accepted gtk+3.0 (3.24.23-1ubuntu1.1) for groovy have finished running.
The following regressions have been reported in tests triggered by the package:

firefox/82.0+build2-0ubuntu0.20.10.1 (amd64)
gyoto/1.4.4-3build1 (amd64)
firefox/unknown (armhf)
libreoffice/1:7.0.2-0ubuntu1 (armhf)
awesome/4.3-5 (armhf)
aptdaemon/1.1.1+bzr982-0ubuntu34 (armhf)
isenkram/0.44 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/groovy/update_excuses.html#gtk+3.0

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

This is getting too complicated to handle as an SRU considering that it's a not-so-important issue after all. So I think we should simply revert the problematic gnome-terminal commit in groovy only, and hope that upstream sorts it out for hirsute. So I would like to upload this fix to groovy:

https://launchpad.net/~gunnarhj/+archive/ubuntu/gnome-terminal

But I can't do that until the version in hirsute is bumped somehow...

@Gunnar, if you want to go with a revert it shouldn't need to block on hirsute since we aren't going to go that way in the new serie but rather cherrypick the new pango fix (we could do that now in Debian and sync over, let know if you need help with an upload)

The version of gtk+3.0 in the proposed pocket of Groovy that was purported to fix this bug report has been removed because one or more bugs that were to be fixed by the upload have failed verification and been in this state for more than 10 days.

Current status of this bug:

The gnome-terminal fix for groovy has been pushed to the VCS repo. I'm waiting for a sponsor to upload it.

As regards hirsute: We have identified three upstream pango commits which together with the gtk fix in hirsute-proposed fix the issue the 'right' way. The pango PPA now contains all the three commits:

https://launchpad.net/~gunnarhj/+archive/ubuntu/pango1.0

Hello Darko, or anyone else affected,

Accepted gnome-terminal into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnome-terminal/3.38.0-1ubuntu1.1 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-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. 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.

Verified the test case using version 3.38.0-1ubuntu1.1 of gnome-terminal, gnome-terminal-data and nautilus-extension-gnome-terminal from groovy-proposed.

Yep, works like a charm with 3.38.0-1ubuntu1.1 from groovy-proposed here as well.

pango fix uploaded to Debian

This bug was fixed in the package gnome-terminal - 3.38.0-1ubuntu1.1

---------------
gnome-terminal (3.38.0-1ubuntu1.1) groovy; urgency=medium

  * debian/patches/show-font-weight-and-style-in-profile-editor.patch:
    - Reverses upstream commit e5c0b4f5 for now (LP: #1900729)

 -- Gunnar Hjalmarsson <email address hidden> Fri, 06 Nov 2020 15:58:37 +0100

The verification of the Stable Release Update for gnome-terminal 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.

gtk and pango are both blocked by glib before they can migrate. In addition to that there are a few other autopkgtest regressions blocking pango.

This bug was fixed in the package gtk+3.0 - 3.24.23-1ubuntu2

---------------
gtk+3.0 (3.24.23-1ubuntu2) hirsute; urgency=medium

  * debian/patches/fontchooser_Fix_family-only_mode.patch:
    - Show regular monospace fonts in gnome-terminal's profile editor
      and not arbitrary font styles (LP: #1900729)

 -- Gunnar Hjalmarsson <email address hidden> Mon, 02 Nov 2020 10:45:57 +0100

This bug was fixed in the package pango1.0 - 1.46.2-3

---------------
pango1.0 (1.46.2-3) unstable; urgency=medium

  * Team upload
  * d/p/fc_Sort-faces-of-a-family.patch,
    d/p/fontconfig_Try-harder-to-return-a-default-face.patch:
    - Show regular monospace fonts in gnome-terminal's profile editor
      and not arbitrary font styles (LP: #1900729)

  [ Simon McVittie ]
  * d/gbp.conf: Use upstream/1.46.x branch

 -- Gunnar Hjalmarsson <email address hidden> Tue, 10 Nov 2020 21:41:00 +0100