Launchpad has imported 11 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=103652.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2017-11-09T15:28:49+00:00 Laurent Bigonville wrote: Hi, The following bug has been reported in debian: === Dear Maintainer, fontconfig now requires nano second mtime precision on files in order to validate their freshness. squashfs does not seem to support nano second mtime precision causing any Desktop ISO's made with live-build to regenrate the font cache at the desktop startup leading to a very slow time to desktop. === https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880574 Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/0 ------------------------------------------------------------------------ On 2017-11-10T03:37:29+00:00 Akiro wrote: Hmm, what does "not seem to support" really mean here? are you generating a cache on non-squashfs and using it on squashfs then? Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/1 ------------------------------------------------------------------------ On 2017-11-10T08:40:51+00:00 Laurent Bigonville wrote: I believe that what bug reporter means is that the cache is added to the squashfs during the build of the livecd and at boot when FC tries to check the freshness of the cache it decides that it needs to be updated and then write a fresh one to the unionfs (I suppose) Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/2 ------------------------------------------------------------------------ On 2017-11-10T09:39:56+00:00 Akiro wrote: Can you give me a log of FC_DEBUG=16 fc-cache prior to boot the desktop? Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/3 ------------------------------------------------------------------------ On 2018-04-04T10:40:22+00:00 Jean-Baptiste Lallement wrote: Created attachment 138574 output of FC_DEBUG=16 fc-cache I attached the output of FC_DEBUG=16 fc-cache before booting to an Ubuntu Desktop Live Session. This is a follow-up of the issue reported in LP (https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1754836) where, according to latest comments), the font cache is regenerated when the user session starts. Let me know if you need more information. Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/9 ------------------------------------------------------------------------ On 2018-04-04T13:15:41+00:00 Iain Lane wrote: Created attachment 138578 cache: If nsec is zero, don't use it for comparisons I made a (stupid?) patch. Is this a reliable way to go about falling back from nsec to non-nsec? I couldn't find a way to actually ask the question of the system directly. We're particularly interested because this is a big cause of live image boot slowness on Ubuntu. This patch works as intended; the cache isn't regenerated on live system boot any more. Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/13 ------------------------------------------------------------------------ On 2018-04-04T21:33:55+00:00 Alistair Buxton wrote: The problem as I understand it: 1. You have /usr/share/fonts/* on ext4 or similar FS with nanos. 2. /usr/share/fonts has a timestamp like 1522818676.601423551. 3. You run fontconfig and it stores the timestamp in the cache file. 4. You build a squashfs from the FS. Squashfs does not support nanos. 5. The timestamp of /usr/share/fonts inside the squashfs becomes 1522818676.0. 6. Installer boots and fontconfig sees the mismatched time stamps so rebuilds the cache in the live user's home directory - which is wiped at reboot. 7. During install the squashfs is copied back to an ext4 FS. 8. User reboots and logs in. 9. /usr/share/fonts is now on a filesystem which supports nanos, but the original time stamp nanos has been lost. 10. Fontconfig decides the cache is out of date and rebuilds it again, in the new user's home directory. This happens each time a newly created user logs in, until such time as a postinst script rebuilds the system font cache. Note steps 9 and 10 only happen on Xubuntu and maybe some other flavours, but not Ubuntu. This means that even if you could ask the system whether the filesystem supports nanos, that wouldn't be enough. It is possible for the timestamp information to be lost/mutated through squashfs, and then copied back to a filesystem with nanos, and then there is no way to determine whether that has happened or not. Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/15 ------------------------------------------------------------------------ On 2018-04-05T10:16:04+00:00 Jean-Baptiste Lallement wrote: Your analysis is correct. point 9 doesn't happen on Ubuntu (and maybe other flavours) because at the end of te installation process, some packages are removed from the target filesystem that triggers the fontconfig trigger (which runs the postinst script that regenerate the cache) So on next boot the timestamps won't have nanoseconfs but will match. Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/16 ------------------------------------------------------------------------ On 2018-04-05T12:17:04+00:00 Iain Lane wrote: Aren't this: (In reply to Alistair Buxton from comment #6) > 5. The timestamp of /usr/share/fonts inside the squashfs becomes > 1522818676.0. > 6. Installer boots and fontconfig sees the mismatched time stamps so > rebuilds the cache in the live user's home directory - which is wiped at > reboot. > 7. During install the squashfs is copied back to an ext4 FS. and this: > 8. User reboots and logs in. > 9. /usr/share/fonts is now on a filesystem which supports nanos, but the > original time stamp nanos has been lost. > 10. Fontconfig decides the cache is out of date and rebuilds it again, in > the new user's home directory. This happens each time a newly created user > logs in, until such time as a postinst script rebuilds the system font cache. actually the same thing happening twice? The nanosecond portion of the timestamp is lost when the squashfs is built, and it's still not there when it's copied to the target system, but the fontconfig cache has nanos in it. In that case, my proposed fix fixes this. I tried with a modified Xubuntu ISO, and after installation: laney@bionic:~$ ls -l .cache total 24 -rw-rw-r-- 1 laney laney 5 Apr 5 12:52 blueman-applet-1000 drwxr-xr-x 2 laney laney 4096 Apr 5 12:52 gstreamer-1.0 -rw-r--r-- 1 laney laney 0 Apr 5 13:05 motd.legal-displayed drwx------ 2 laney laney 4096 Apr 5 12:53 obexd drwx------ 2 laney laney 4096 Apr 5 12:52 sessions drwxrwxr-x 2 laney laney 4096 Apr 5 13:01 update-manager-core -rw-rw-r-- 1 laney laney 381 Apr 5 12:52 xfce4-indicator-plugin.log (laney@bionic:~$ stat /usr/share/fonts ... Modify: 2018-04-04 06:44:44.000000000 +0100 laney@bionic:~$ FC_DEBUG=16 fc-cache FC_DEBUG=16 FcCacheTimeValid dir "/usr/share/fonts" cache checksum 1522820684.549609025 dir checksum 1522820684.0 tv_nsec == 0, ignoring nanoseconds) Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/17 ------------------------------------------------------------------------ On 2018-04-05T13:16:13+00:00 Alistair Buxton wrote: Yes, your current patch handles both cases. My point was that if you "improve" the patch to check whether the filesystem supports nanos it would no longer handle the second case. Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/18 ------------------------------------------------------------------------ On 2018-08-20T21:46:11+00:00 Gitlab-migration wrote: -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/44. Reply at: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1749546/comments/22 ** Changed in: fontconfig Status: Confirmed => Unknown ** Bug watch added: Debian Bug tracker #880574 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880574 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to fontconfig in Ubuntu. https://bugs.launchpad.net/bugs/1749546 Title: Booting a live session is slow - fontconfig regenerates its font cache Status in Fontconfig: Unknown Status in fontconfig package in Ubuntu: Fix Released Status in fontconfig source package in Bionic: Fix Released Bug description: On Bionic Ubuntu Desktop booting to a live session is slow. It takes roughly 2 min on my test machine to boot from the "Try or Install Ubuntu" boot menu to a usable session. It also takes 1 minute to logout and 17s to log in again. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: casper 1.388 ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13 Uname: Linux 4.13.0-32-generic x86_64 ApportVersion: 2.20.8-0ubuntu10 Architecture: amd64 CasperVersion: 1.388 CurrentDesktop: ubuntu:GNOME Date: Wed Feb 14 16:43:19 2018 LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: casper UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/1749546/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
