Tails

#2 Updated by intrigeri 2017-03-13 15:59:13

In a VM on a quite loaded system:

• dpkg-reconfigure fontconfig took 27 seconds
• Updating certificates in /etc/ssl/certs took 13 seconds

In practice, I think this added ~20 seconds to the total boot time after apparmor.service stopped blocking.

#3 Updated by Anonymous 2017-03-13 17:02:31

concerning config/2050-fontconfig

A solution might be to not have font cache at all. But I wonder if that would result in longer loading times for libreoffice for example.

#4 Updated by Anonymous 2017-03-13 21:31:02

I booted a test ISO and everything seems to work fine. I opened LibreOffice, a PDF, Inkscape and could successfully change and read different fonts as well as have a font list. However, I’m in no position to judge if booting is faster than usual nor if running a program using system fonts is slower than usual.

This has been done in tails:tails/feature/11971+fontconfig.
ISO is here: https://nightly.tails.boum.org/build_Tails_ISO_feature-11971-fontconfig/

#5 Updated by anonym 2017-03-14 00:28:03

u wrote:
> This has been done in tails:tails/feature/11971+fontconfig.
> ISO is here: https://nightly.tails.boum.org/build_Tails_ISO_feature-11971-fontconfig/

I see only unrelated failures in the automated test suite run: https://jenkins.tails.boum.org/job/test_Tails_ISO_feature-11971-fontconfig/1/

#6 Updated by intrigeri 2017-03-14 10:19:44

I’ll look into the CA cert updates, while waiting for mksquashfs to crunch numbers. Likely it’s a good candidate to move to a dedicated systemd unit file.

#7 Updated by Anonymous 2017-03-14 10:24:09

Ok, i’ve tested manually in a VM, comparing the latest feature/56300 with the fontconfig ISO mentioned in my previous comment. The VM had 2GB RAM and used 3 cores of an i5.

with fontconfig cache generated at boot time

• boot until Greeter started = 78 secs
• login from greeter = 10 secs
• start libreoffice once = 6.5 secs
• start libreoffice second time = 2 secs
• start inkscape = 6.5 secs
• memory used = 596MB
• memory used while running libreoffice = 675MB
• top (after tor has started and tails-iuk and tails-upgrader were run:)
  KiB Mem : 2052372 total, 297868 free, 595472 used, 1159032 buff/cache

without fontconfig cache

• boot until Greeter started = 68 secs
• login from greeter = 21 secs
• start libreoffice once = 6.5 secs
• start libreoffice second time = 1.8 secs
• start inkscape = 6.5 secs
• memory used = 523MB
• memory used while running libreoffice = 594MB
• top (after tor has started and tails-iuk and tails-upgrader were run:)
  KiB Mem : 2052372 total, 379516 free, 513800 used, 1159056 buff/cache

tails 3.0 beta2 fontconfig cache in the ISO

• boot until Greeter started = 67 secs
• login from greeter = 16 secs
• start libreoffice once = 15 secs
• start libreoffice second time = 1.8 secs
• start inkscape = 9 secs
• memory used = 580MB
• memory used while running libreoffice = 652MB
• top (after tor has started and tails-iuk and tails-upgrader were run:)
  KiB Mem : 2052372 total, 579476 free, 580344 used, 892552 buff/cache

#10 Updated by Anonymous 2017-03-14 12:30:56

Same test again on bare metal (i3 processor, 16 Gigs of RAM):

with fontconfig cache generated at boot time

• boot until Greeter started = 84 secs
• login from greeter = 10 secs
• start libreoffice once = 7 secs
• memory used = 551MB
• memory used while running libreoffice = 617MB
• top: KiB Mem : 16349932 total, 14860230 free 551400 used, 1195460 buff/cache

without fontconfig cache

• boot until Greeter started = 73 secs
• login from greeter = 19 secs
• start libreoffice once = 6.5 secs
• memory used = 591MB
• memory used while running libreoffice = 653MB
• top: KiB Mem : 16349932 total, 14563116 free 590912 used, 1195840 buff/cache
  After running LibreOffice the last value changes to 1359180 buff/cache.

tails 3.0 beta2 fontconfig cache in the ISO

• boot until Greeter started = 85 secs
• login from greeter = 18 secs
• start libreoffice once = 20 secs
• memory used = 566MB
• memory used while running libreoffice = 615MB
• top: KiB Mem : 16349936 total, 14876420 free 549528 used, 925292 buff/cache

#11 Updated by Anonymous 2017-03-14 12:38:44

Basically, it looks to me like boot until the greeter is faster with fontconfig not generated at build time. However, the login to Xserver is longer.
Starting up libreoffice seems unaffected between fontcache and nofontcache.
What seems weird is that more memory is used on baremetal when fontcache is not generated at build and less memory is used on a VM.

#15 Updated by Anonymous 2017-03-14 16:25:57

Using a build from the latest branch, which does invoke fontconfig over systemd, I think we’ve solved our problem:

Test on bare metal (i3 processor, 16 Gigs of RAM):

• boot until Greeter started = 68 secs
• login from greeter = 11 secs
• start libreoffice once = 7 secs
• memory used = 568MB
• memory used while running libreoffice = 638MB
• top: KiB Mem : 16349936 total, 14584664 free 568484 used, 1195472 buff/cache

#17 Updated by intrigeri 2017-03-14 17:10:10

Yay!

I’ll fetch an ISO and will give it a try.

#25 Updated by Anonymous 2017-04-27 08:31:10

intrigeri wrote:
> # build a custom package based on the one from Stretch, with Chris’ patch applied, and upload it to the suite corresponding to the new topic branch in our custom APT repo

Why wouldn’t we use the package from experimental instead? seems that this one contains the patch already.

#26 Updated by intrigeri 2017-04-27 10:17:12

> why wouldn’t we use the package from experimental instead? seems that this one contains the patch already.

• If we do that, then we have to track fontconfig 2.12+ for the entire Tails 3.x series; this will probably work smoothly for a while, but at some point I bet the packages won’t be installable on Stretch anymore (e.g. they’ll get a dependency on a newer libc6 or something) and then we’ll have to maintain backports until Tails 4.x, which will likely require much more work than maintaining a tiny delta against the Stretch package.
• fontconfig has been poorly maintained in Debian for ages; the last maintainer upload is 3 years old; the upload to experimental was a NMU done by someone who had never uploaded the package before, and I have no idea what’s their plan to transition unstable to 2.12 / to maintain the package in experimental; I’d rather not rely on this upload and its future maintenance.
• libfontconfig1-dev has many reverse-build-dependencies, so a proper transition (with binNMUs) may be required to have other packages work fine with libfontconfig1 2.12+.
• It’s very unlikely that fontconfig 2.12 has been tested much on Debian systems; even Ubuntu doesn’t ship 2.12 yet (they’ve diverged from Debian many years ago, and apparently they nowadays ship some snapshot taken somewhere between fontconfig 2.11 and 2.12). So the impact of upgrading from 2.11 to this new upstream release is unknown: it may very well break stuff. I’d rather not Tails users be the ones who discover such breakage first.
• There’s no security support for packages in experimental, so if we use them we (for some value of “we” :) needs to take responsibility for tracking their security status. One security upload was done during the Jessie lifetime already, so this is not a theoretical concern.

⇒ all in all, pulling these packages from experimental saves a little bit of work up-front, but feels risky (QA-wise) and adds lots more work on our shoulders for the next 2 years. I don’t think the tiny short-term benefits are worth the short and long-term drawbacks.

#27 Updated by Anonymous 2017-05-15 16:47:23

intrigeri wrote:
> Hold on, we might be able to move the fontconfig cache generation back to ISO build time: https://bugs.debian.org/857892. I’m in favour of trying this first, i.e.:
>
> # fork a topic branch dedicated to test this, based on feature/5630-deterministic-builds
> # build a custom package based on the one from Stretch, with Chris’ patch applied, and upload it to the suite corresponding to the new topic branch in our custom APT repo

Interestingly, the line deleted by Chris’s patch is not present in the version he talks about?
I double checked:

wget http://httpredir.debian.org/debian/pool/main/f/fontconfig/fontconfig_2.11.0-6.7.dsc
then see in src/fpat.c
search for “memset (p, 0, sizeof (FcPattern));”
this should be located right at the beginning of the file, line 6.
But it’s not.

#28 Updated by intrigeri 2017-05-16 12:27:53

> Interestingly, the line deleted by Chris’s patch is not present in the version he talks about?

Chris’ patch adds a line, it doesn’t delete any.

#29 Updated by Anonymous 2017-05-16 13:25:42

intrigeri wrote:
> > Interestingly, the line deleted by Chris’s patch is not present in the version he talks about?
>
> Chris’ patch adds a line, it doesn’t delete any.

Haha, I had no idea how tired my eyes are sometimes.

This is probably due to the fact that the fontconfig package does not use version control (!§$%@!) and so this got mixed up in quilt, making me think that I removed the line, but it was simply the other way round.

#30 Updated by intrigeri 2017-05-16 16:52:02

What’s your ETA? If later than Wednesday night, I’ll probably reassign to me (as said a couple months ago) as this blocks merging the reproducible builds branch, which I want to merge in time for 3.0~rc1.

#33 Updated by intrigeri 2017-05-18 13:00:39

Patched fontconfig package uploaded to the bugfix-11971-fontconfig-cache-in-iso APT suite.

#34 Updated by intrigeri 2017-05-18 13:03:33

Prepared branch that includes the fontconfig cache, will built & test locally before pushing.

#35 Updated by intrigeri 2017-05-19 07:27:43

Fixed some reproducibility issues (initrd differs due to initramfs-tools in testing having superseded our patched package + forgot about forcecleanup). Building twice again to make sure the fontconfig cache itself doesn’t introduce reproducibility problems.

#39 Updated by intrigeri 2017-05-19 10:56:37

Actually, anonym and I want this branch in 3.0~rc1, even if it means that release won’t be reproducible: robustness feels more important than reproducibility at this point. So we’ll evaluate this branch with the test suite, merge it, and I’ll file another ticket about making the fontconfig cache reproducible, that anonym or I will try to get help from Chris about.

#42 Updated by Anonymous 2017-05-19 16:20:10

intrigeri wrote:
> What’s your ETA? If later than Wednesday night, I’ll probably reassign to me (as said a couple months ago) as this blocks merging the reproducible builds branch, which I want to merge in time for 3.0~rc1.

I had only had time to start building the package, but I did not pursue the initial plan to build and compare the ISOs. Fine with me that you took over and sorry to see that the patch does not function as intended.

#45 Updated by intrigeri 2017-05-20 08:42:38

Merged into the branch for Feature #5630 and reverted “Ship the fontconfig cache in the ISO again”, to try and have that branch build ISOs reproducibly until Bug #12567 is solved.