"Querying installed files" process on start-up takes abnormally long (~20minutes)

[Set Hallstrom]

When starting font-manager it queries the installed font files. Until 16.04 this process has been fairly fast. Since 16.04 it takes up to 20 minutes, and looks like the app died: loading bar gets stuck and switching the window back from the background shows an empty window.

2 ways to reproduce:

a)
- launch font-manager
expected result: font-manager loads quickly and is ready for operation
result: font-manager faints a crash but is in fact alright after 20 minutes querying the installed font files

b)
- once launched, install new fonts
- press "reload now" when prompted
expected result: font-manager loads quickly and is ready for operation
result: font-manager faints a crash but is in fact alright after 20 minutes querying the installed font files

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: font-manager 0.5.7-4
ProcVersionSignature: Ubuntu 4.4.0-22.39-lowlatency 4.4.8
Uname: Linux 4.4.0-22-lowlatency x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: XFCE
Date: Sun May 8 17:59:17 2016
InstallationDate: Installed on 2016-04-21 (17 days ago)
InstallationMedia: Ubuntu-Studio 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: font-manager
UpgradeStatus: No upgrade log present (probably fresh install)

[Set Hallstrom (sakrecoer)]

It appears that the version in ubuntu is very old:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796817

[Jerry Casiano (jerrycasiano)]

Yes, the version in Ubuntu has been deprecated for years now.

Please see https://fontmanager.github.io for more details including instructions for adding the PPA

[Jerry Casiano (jerrycasiano)]

Also, make sure to have look at https://raw.githubusercontent.com/FontManager/master/master/README

As the rewrite is not complete, certainly usable, but far from done.

[Launchpad Janitor (janitor)]

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

[Gunnar Hjalmarsson (gunnarhj)]

The question at <http://askubuntu.com/q/763075> called my attention to this. The explanation why the version in the Ubuntu/Debian archives stopped working in 16.04 is that it's not compatible with the new Chinese fonts provided by the fonts-noto-cjk package, which is installed by default in all Ubuntu flavors (see <https://bugs.debian.org/814433>).

So either it should be upgraded or dropped from the yakkety and xenial archives.

[Jerry Casiano (jerrycasiano)]

> So either it should be upgraded or dropped from the yakkety and xenial archives

Agreed.

Shipping an ancient, broken version is worse than not shipping it at all.

Sad part is, that packaging work is mostly done, there is a debian folder in git that is used for PPA builds, it may need minor cleanup but it's not like starting from scratch.

[Gunnar Hjalmarsson (gunnarhj)]

@Jerry: Given what you just said, what's blocking you from uploading to Debian?

[Jerry Casiano (jerrycasiano)]

@Gunnar

Time, mostly but also that I don't normally use Debian.

The PPA builds are automated, and I provide a COPR for Fedora users who want to use testing. 0.7 series is in the normal repos there.

If someone wants to go through the process of maintaining the Debian

[Jerry Casiano (jerrycasiano)]

Package, I'd be glad to help, accept changes, whatever.

[Gunnar Hjalmarsson (gunnarhj)]

@Jerry: Is there any chance you can spot a specific commit in the source which would fix the problem in version 0.5.7 wrt dealing with Noto Sans? In that case we could patch it in Xenity. The archive admins are typically disinclined to accept a new version in a stable release update.

(The problem might be related to the OTC format, which is used in fonts-noto-cjk to save space. But this is just a guess - I haven't tested if replacing the OTC files with OTF would make a difference.)

[Jerry Casiano (jerrycasiano)]

No.

The current version isn't even written in the same language. And both are
basically prototyping, throwaway code, on the way to 1.0, so I'm certainly
not digging into something I deprecated years ago. I barely have time for
the project as it is.

I tried contacting the maintainers to work with them years ago. And as you
know others have filed bugs.

So as far I'm concerned, Ubuntu users can simply use the PPA, Debian users
can build from source or build a Debian package from git.

git clone https://github.com/FontManager/master.git
cd master/build-aux
make deb

That's about all the work I'm willing to do to support users of a
distribution which chooses to ship outdated/broken shit in the name of
stability.

On Aug 25, 2016 7:35 PM, "Gunnar Hjalmarsson" <email address hidden>
wrote:

> @Jerry: Is there any chance you can spot a specific commit in the source
> which would fix the problem in version 0.5.7 wrt dealing with Noto Sans?
> In that case we could patch it in Xenity. The archive admins are
> typically disinclined to accept a new version in a stable release
> update.
>
> (The problem might be related to the OTC format, which is used in fonts-
> noto-cjk to save space. But this is just a guess - I haven't tested if
> replacing the OTC files with OTF would make a difference.)
>
> --
> You received this bug notification because you are subscribed to font-
> manager in Ubuntu.
> https://bugs.launchpad.net/bugs/1579536
>
> Title:
> "Querying installed files" process on start-up takes abnormally long
> (~20minutes)
>
> Status in font-manager package in Ubuntu:
> Confirmed
>
> Bug description:
> When starting font-manager it queries the installed font files. Until
> 16.04 this process has been fairly fast. Since 16.04 it takes up to 20
> minutes, and looks like the app died: loading bar gets stuck and
> switching the window back from the background shows an empty window.
>
> 2 ways to reproduce:
>
> a)
> - launch font-manager
> expected result: font-manager loads quickly and is ready for operation
> result: font-manager faints a crash but is in fact alright after 20
> minutes querying the installed font files
>
> b)
> - once launched, install new fonts
> - press "reload now" when prompted
> expected result: font-manager loads quickly and is ready for operation
> result: font-manager faints a crash but is in fact alright after 20
> minutes querying the installed font files
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: font-manager 0.5.7-4
> ProcVersionSignature: Ubuntu 4.4.0-22.39-lowlatency 4.4.8
> Uname: Linux 4.4.0-22-lowlatency x86_64
> ApportVersion: 2.20.1-0ubuntu2
> Architecture: amd64
> CurrentDesktop: XFCE
> Date: Sun May 8 17:59:17 2016
> InstallationDate: Installed on 2016-04-21 (17 days ago)
> InstallationMedia: Ubuntu-Studio 16.04 LTS "Xenial Xerus" - Release
> amd64 (20160420.1)
> SourcePackage: font-manager
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/font-manager/+
> bug/1579536/+subscriptions
>

[Gunnar Hjalmarsson (gunnarhj)]

Well, as far as Ubuntu is concerned, the package is in "universe", so it's up to the community to find someone who keeps the package up-to-date in Debian/Ubuntu. font-manager is shipped by default in Ubuntu Studio only:

$ apt-cache rdepends font-manager
font-manager
Reverse Depends:
  ubuntustudio-publishing
$

@Set: Looks like the ball is back in your court. As regards Xenial you may want to point out to the SRU team that an exception from the normal SRU criteria would be motivated in this case.

https://wiki.ubuntu.com/StableReleaseUpdates

[Set Hallstrom (sakrecoer)]

Hi guys!
Thanks for looking into this. when i tested it yesterday in yakkety beta 1, i noticed it worked considerably better. That is; at a normal speed, considering the rather large collection of font we ship by default in Ubuntu Studio. However this doesn't justify shipping an old semi-broken version when there have been considerable improvements made upstream. For my own work i use the PPA and the energy that has been placed into making font-manager better is amazing, (thank you Jerry and your team for that!)

The Ubuntu Studio team is very small, but i'll see if i can find someone willing to package/maintain it in debian and i will certainly reach out to the SRU-team. This piece of software is too precious in a graphic-design workflow to be left out. But i agree that we should not ship a broken version. That would just become a bug-tracker nightmare.

I'll be in touch!

[Jerry Casiano (jerrycasiano)]

Is it against policy for a spin to ship with a PPA enabled?

Seems like that would be the easiest solution.

It's probably just my impression, from watching it happen in the past, but
even trying to take over an obviously orphaned package can turn into an
ordeal with Debian.

[Set Hallstrom (sakrecoer)]

hi,
I reached out to the debian maintainer who acted super quickly, hence the latest version is now in debian. I will do my best to arrange an SRU and ask for a ppos-FF to land it in yakkety.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796817

[Set Hallstrom (sakrecoer)]

s/ppos-FF/post-FF
sorry for the noise, typing from my phone.

[Iain Lane (laney)]

+1 to the FFe.

[Iain Lane (laney)]

(I think this is a sync request - subscribed sponsors)

[Jeremy Bícha (jbicha)]

This bug was fixed in the package font-manager - 0.7.2-1
Sponsored for Set Hallstrom (sakrecoer)

---------------
font-manager (0.7.2-1) unstable; urgency=medium

  * Imported Upstream version 0.7.2 (Closes: #796817)
  * Update homepage (Closes: #830858)
  * Update debian/watch
  * debian/gbp.conf: set compression to gz
  * Update debian/copyright
  * Update patchset, add patch to avoid checking for
    the presence of file-roller at build time
  * Refresh build-dependencies
  * Refresh debian/rules
  * Refresh debian/docs
  * Remove debian/menu control file
  * Get rid of obsolete links file
  * Enable nautilus extension
  * Update Depends and Suggests fields
  * Fix Vcs fields
  * Add Vito Mulo to Uploaders field
  * Bump debhelper compat
  * Bump Standards

 -- Alessio Treglia <email address hidden> Tue, 30 Aug 2016 22:11:42 +0100

[Jerry Casiano (jerrycasiano)]

Nice.

But from a quick glance there seem to be some issues with this update or maybe it's just me.

It seems to install an outdated manual page even though an up to date one is available and installed?
Seems to be compiled without file-roller support but still suggests it? Or maybe I misunderstand.
There's still a suggestion for python-reportlab for a feature that isn't available at this time.

[Jerry Casiano (jerrycasiano)]

Nevermind, maybe I'm looking at an old version.
That makes sense, I feel silly now.
Sorry for the noise.
Not familiar with the infrastructure...

On Aug 31, 2016 10:30 PM, "Jerry Casiano" <email address hidden>
wrote:

Nice.

But from a quick glance there seem to be some issues with this update or
maybe it's just me.

It seems to install an outdated manual page even though an up to date one
is available and installed?
Seems to be compiled without file-roller support but still suggests it? Or
maybe I misunderstand.
There's still a suggestion for python-reportlab for a feature that isn't
available at this time.

--
You received this bug notification because you are subscribed to font-
manager in Ubuntu.
https://bugs.launchpad.net/bugs/1579536

Title:
  [FFe] "Querying installed files" process on start-up takes abnormally
  long (~20minutes)

Status in font-manager package in Ubuntu:
  Fix Released
Status in font-manager source package in Xenial:
  Triaged
Status in font-manager package in Debian:
  Unknown

Bug description:
  When starting font-manager it queries the installed font files. Until
  16.04 this process has been fairly fast. Since 16.04 it takes up to 20
  minutes, and looks like the app died: loading bar gets stuck and
  switching the window back from the background shows an empty window.

  2 ways to reproduce:

  a)
  - launch font-manager
  expected result: font-manager loads quickly and is ready for operation
  result: font-manager faints a crash but is in fact alright after 20
minutes querying the installed font files

  b)
  - once launched, install new fonts
  - press "reload now" when prompted
  expected result: font-manager loads quickly and is ready for operation
  result: font-manager faints a crash but is in fact alright after 20
minutes querying the installed font files

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: font-manager 0.5.7-4
  ProcVersionSignature: Ubuntu 4.4.0-22.39-lowlatency 4.4.8
  Uname: Linux 4.4.0-22-lowlatency x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Sun May 8 17:59:17 2016
  InstallationDate: Installed on 2016-04-21 (17 days ago)
  InstallationMedia: Ubuntu-Studio 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
  SourcePackage: font-manager
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/font-manager/+
bug/1579536/+subscriptions

[Jerry Casiano (jerrycasiano)]

Nevermind, maybe I'm looking at an old version.
That makes sense, I feel silly now.
Sorry for the noise.
Not familiar with the infrastructure...

[Set Hallstrom (sakrecoer)]

Thank you very much, Gunnar, Iain Lane, Jeremy Bicha and everyone involved!! \o/
An SRU would be in place; looking at how to request that.

[Gunnar Hjalmarsson (gunnarhj)]

On 2016-09-01 12:32, Set Hallstrom wrote:
> An SRU would be in place; looking at how to request that.

https://wiki.ubuntu.com/StableReleaseUpdates

One compulsory step is to make the bug description 'SRU compliant' (see linked page). I'd advice you to explain why a backport of the yakkety version is necessary in this case to fix the issue.

[Mattia Rizzolo (mapreri)]

I don't see anything to sponsor left; there is an open task for xenial, but no SRU patch (nor the description is ok).

I'm unsubscribing ubuntu-sponsors; feel free to subscribe again if anybody provides a SRU.