Re: Next steps for a reproducible Fontconfig?
"Keith Packard" <[email protected]> Sun, 13 Jan 2019 10:21:01 -0800
| Newsgroups | gmane.comp.fonts.fontconfig |
|---|---|
| Message-ID | <[email protected]> |
Alexander Larsson <[email protected]> writes: > Ugh. Sorry about that! Thanks. Bugs happen, fortunately I was able to track this one down and fix it (we all love free software!) > Yes:ish. It should not *normally* happen. But you may run into it in > uncommon situations like e.g. chrome using a statically linked version > of fontconfig that has a different fontconfig cache format. Hrm. I don't get the sense that we've got a solution to this problem yet. Given that the contents of the flatpak cannot change on the fly, would it be sufficient to generate a new 'salt' value for the flatpak each time it is changed? It might be sufficient to use the name of the flatpak including a version as this salt (that has the advantage of making the flatpak reproducible, which you probably want to encourage). > I agree with this, but the point was that we can't just modify the > fontconfig to be dynamic always. We need to design it such that > whatever flatpak generates is optional for the runtime to pick up when > it is able to handle it. Sounds like being able to handle an arbitrary host fonts directory mounted as /run/host/fonts will really help avoid future issues. And that needs to be in the fontconfig used inside the flatpak, which means we can't wait for a system which has fonts in a different place and plan on fixing it in the host. > Yeah, there will be two files. One static in the runtime > (/etc/fonts/conf.d/50-flatpak.xml), and one generated by flatpak > (/run/host/fontconf.xml). Sounds like we've got a plan for this part -- fix my mapping code to use config bits separate from the <dir> elements, then add a 'salt' mechanism in the config bits that stirs in some random data when generating the cache keys for specific directory trees. Let's figure out how we should handle the stale flatpak fonts cache issue. Once we've settled that, we can go implement the whole mess and get a new fontconfig release made in time for debian freeze. -- -keith _______________________________________________ Fontconfig mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/fontconfig
signature.asc
(application/pgp-signature, 832 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlw7gY0ACgkQ2yIaaQAA ABHtHg/8DD/vm+yrQAeLB3c0eQ7xBwDAHMUzaS/ypoGKDialpgY0CaqBgXHlVjL/ cpvY//aidVCtGNkyQeJ+MIKhZwBxGGKgJ3Li3zlnAwVNWTj3z6kKez8k0Wqx0YcW lPZw9F7GjJdxY2+ovQ7SP6fNtGO0DDxYSsxjdRR8ZLR8LAkziTnIRnHrZ4V90gQY YSH5F5MMCwuviggrQhDIfEy4pXb3YFhQklAhA2ysu//qMnw8IK3SvzhHlRT481tS K1JHef9aiAlfL8Sv5tAcdhCBM7pYFPJZ2JAvda44azgJe2qiVBBVDjN01/YbEMYr 2C/o/QqrgyKz15Kbex5LB8QKhcvYYWHOaHH3wGX+Cu+965dTcdnqEB8CtXdT8AjF xslYsuKW43yvEfjJ7893bo9o6gID03Y9bGlu9rvZUQfPmkFEiBD6oQn1b1gmAQZc b3XOQP9W9nz8tdEp1Tokpf9B1jGOoSl3np7aDq7UhwFiCmJpZNq8rB0FnZaKWhLz O9SctitKF4qrzVMKBsC4BRpi3g3G2npSe61KSEtslF1iJ8Z9IL4Q/n5vRg61zhk+ TR0gF6rLivCwQlgCYHRqHbGfuitsTpeTXM0+7AcjhAym3ouH+1HZRDGNmRTg6ev7 M7rNRrPd0pKeyd5BIf+tUSXmmL8bLwbk44UBrCignhbJ6vJIL2g= =wz0x -----END PGP SIGNATURE-----