"Could not find any font:" error on Solus & Fedora

snapcraft
#1

Our latest release has been having some font trouble on Solus. Our snapcraft.yaml file hasn’t changed between releases so I’m wondering if it’s something to do with the integration. We’re seeing the following error which causes the app to fail to launch. Noto Sans is a Google web font we include in our Electron app.

[3821:1219/085127.455085:FATAL:platform_font_linux.cc(63)] Check failed: typeface. Could not find any font: Noto Sans, sans
    #0 0x000001f8d157 <unknown>
    #1 0x000001fa130b <unknown>
    #2 0x000001beee0f <unknown>
    #3 0x000001beea4f <unknown>
    #4 0x000001bef776 <unknown>
    #5 0x000001bd7ad9 <unknown>
    #6 0x000000cdd5b0 <unknown>
    #7 0x000000f79ea3 <unknown>
    #8 0x000003ee819d atom::api::WebContents::InitWithSessionAndOptions()
    #9 0x000003ee89af atom::api::WebContents::WebContents()
    #10 0x000003ef4196 atom::api::WebContents::Create()
    #11 0x000003f061fa atom::api::Window::Window()
    #12 0x000003f07dfc atom::api::Window::New()
    #13 0x000003ea7ef0 mate::internal::InvokeNew<>()
    #14 0x000003ea8080 mate::internal::Dispatcher<>::DispatchToCallback()
    #15 0x7fdb394e4df9 <unknown>
    #16 0x7fdb3994d51c <unknown>
    #17 0x7fdb3994cf56 <unknown>
    #18 0x130603b8437d <unknown>

I’ve also tested on Ubuntu and there’s no such error there. A little bit of Googling reveals that another project has had similar issues more info. Their suggestion was to include the desktop plug, however when we tried this we ended up with no fonts rendering whatsoever.

Any help would be much appriciated! Thanks

#2

have you tried installing the basic fonts from elsewhere ?

#3

It’s not that the core fonts aren’t available. The Noto Sans font is bundled in the app and loaded via a stylesheet in the same way you would a font in the browser.

#4

This issue also seems to affect Fedora 27

#5

Can you share your snapcraft.yaml or at least the snap itself? If it’s in the store then just it’s name is sufficient to satisfy sharing the snap… preferably we’d like to see the yaml and even better to see the electron source too.

1 Like
#6

It’s Wavebox in the store

#7

Looking at your wavebox snap, I don’t actually see the Noto font:

  • in usr/share/fonts, I see the DejaVu, Liberation, and Ubuntu font families (which should all be locatable by fontconfig).
  • in resources/app/bin/fonts you have FontAwesome, MaterialIcons, and OpenSans fonts (which probably won’t be visible by fontconfig).

I don’t see any of the Noto fonts. It doesn’t look like any of the fontconfig configuration in etc/fonts would remap requests for Noto to any of the other fonts either.

I see from the error it also lists sans as a fallback. That should map to the DejaVu font you’ve included, so maybe that’s the one that’s being used on systems where your snap works?

I’m not sure why Fedora/Solus would look any different in this respect though: while we have added the ability to access host system fonts through the desktop interface, you’re not plugging it. So that’s one fewer areas of difference.

#8

Thanks @jamesh. You’re right we’re not including the Noto font anywhere - I think it might be required by a library we’re using. Either way it should fall back to sans, or failing that any available font as it does without snap packaging. The package does work as it should on all the versions of Ubuntu we’ve tested with, it just seems to be Fedora and Solus at the moment that has this problem.

We did try using the desktop plug, but found this stopped all fonts working. No error was thrown, all text would just fail to render. A little bit more digging on this revealed that the sandboxing was blocking requests for fonts on the machine - even when they were included locally in the Snap package (e.g. Lato). It was my understanding on-machine font support with the desktop plug is due to land with 2.30 - but correct me if I’m wrong with that.

Here’s the list of plugs and stage packages we’ve been using…

  • home
  • camera
  • x11
  • unity7
  • browser-support
  • network
  • network-bind
  • gsettings
  • pulseaudio
  • opengl

…and stage packages…

  • libnss3
  • libnotify4
  • libappindicator1
  • libxtst6
  • libxss1
  • fontconfig-config
  • gconf2
  • libasound2
  • pulseaudio
  • libgconf-2-4
  • fonts-liberation
  • ttf-dejavu-core
#9

So, from the Ubuntu side. Using snap run --shell wavebox, applying the environment changes from command-wavebox.wrapper and then running desktop-launch fc-match "Noto Sans, sans" seemed to get a match (DejaVu Sans).

It seems you’re not alone with font issues with Electron apps, as seen in this bug report:

So maybe it is down to something Electron specific. I’ll continue trying to identify the cause.

#10

As a follow-up on what we discovered elsewhere, the problem is almost certainly down to your application having the executable stack flag set:

$ execstack -q /snap/wavebox/current/Wavebox 
X /snap/wavebox/current/Wavebox

As discussed in Snap and executable stacks, when Linux encounters executables with this flag, it automatically treats requests to map files for read access as requests for read and execute access. This can fall foul of the AppArmor policies that restrict the locations of files that can be mapped as code.

Fontconfig uses mmap to load fonts and caches, but AppArmor may deny creating executable mappings depending on location (which it should: fonts are data).

Some Electron apps seem to work fine when you manually strip the executable stack flag from the binary, using something like the following:

https://github.com/snapcrafters/wordpress-desktop/commit/024661cff94c84c3a1ccd574ef51ef8405161366

Maybe give that a try for your snap? If your snapcraft.yaml actually builds the app, you’ll probably want the install scriptlet instead of prepare, and modify the executable under $SNAPCRAFT_PART_INSTALL.

As for why this happens, the toolchain only generally adds the executable stack flag if it sees code patterns that require it. So unless it is a false positive, presumably there is some code path that will malfunction without an executable stack. I’m just not sure what it is, given that most Electron apps seem to function with the flag removed.

#11

Thanks for the update on this. I’ve tried running execstack --clear-execstack on the binary and then bundling it up into a snap. Confirmed by running…

$ execstack -q /snap/wavebox/current/Wavebox
- /snap/wavebox/current/Wavebox

…but I still get the same result.

I started to wonder if it was down to some libraries we’ve been including etc, so setup the most bare-bones project I can think of, based off electron-quick-start. This sees exactly the same behaviour. Works fine on Ubuntu, not Fedora/Solus.

If it helps with debugging, here are the instructiosn to give it a try…

Grab the snapcraft.yaml and sntest.desktop from here

git clone https://github.com/electron/electron-quick-start
cd electron-quick-start
npm install
npm start
npm install electron-packager -g
electron-packager . SNTest
mkdir snap
mkdir snap/gui
cd snap

>> copy attached sntest.destkop to ./gui/sntest.desktop
>> copy attached snapcraft.yaml to ./snapcraft.yaml
>> modify desktop path in snapcraft.yaml (couldn't figure out the relative path, so just dropped the full one in)

snapcraft snap --target-arch=amd64 -o 'SNTest.snap'
snap install SNTest.snap --dangerous

What’s the best way to go from here? Could it be some of the plugs or packages used? Is it worth running through them one-by-one to see if removing one stops the error?

Thanks again for your help!

#12

Oh hold on, it looks like by adding the desktop plug and stripping the flags it starts to work.

Before looking further into this, it’s worth looking at then as fonts on the machine should come through. I’ll post an update when I’ve done some more testing…