On Wed, Apr 10, 2019 at 12:00 AM Alexander Larsson
wrote:
>
> On Tue, Apr 9, 2019 at 4:57 PM Alexander Larsson
> wrote:
> >
> > On Thu, Apr 4, 2019 at 1:09 PM Akira TAGOH wrote:
> > >
> > > Yes. done. hope that works well.
> >
> > Yes, this now seems to work well. I think this is good to go!
>
On Tue, Apr 9, 2019 at 4:57 PM Alexander Larsson
wrote:
>
> On Thu, Apr 4, 2019 at 1:09 PM Akira TAGOH wrote:
> >
> > Yes. done. hope that works well.
>
> Yes, this now seems to work well. I think this is good to go!
Oh, and once this lands, any chance we could have a minimal backport
of the
On Thu, Apr 4, 2019 at 1:09 PM Akira TAGOH wrote:
>
> On Thu, Apr 4, 2019 at 5:46 PM Alexander Larsson
> wrote:
> > There are still some issues though:
> > * Only flatpak 1.2.0 and later generates the dir-remapping fontconfig
> > file, so earlier versions of flatpak will regenerate caches for
>
On Thu, Apr 4, 2019 at 5:46 PM Alexander Larsson
wrote:
> There are still some issues though:
> * Only flatpak 1.2.0 and later generates the dir-remapping fontconfig
> file, so earlier versions of flatpak will regenerate caches for
> /run/host/fonts.
> * On current distros, with the uuid file
Ok, this seems to work well with the latest version of the branch and
my test case:
https://gist.github.com/alexlarsson/8912637dd6173591a8dec7c043cfa01d
However, I had to fix an issue in flatpak-builder:
https://github.com/flatpak/flatpak-builder/pull/277
Because fc-cache was picking up the
Ah, thank you for catching this up. I fixed similar case before but
missed the case for sub directories. fixed.
On Wed, Apr 3, 2019 at 10:01 PM Alexander Larsson
wrote:
>
> On Tue, Apr 2, 2019 at 2:35 PM Akira TAGOH wrote:
> >
> > Thanks for testing, Alex.
>
> Doing some more testing, and I
Fixed. thanks.
On Wed, Apr 3, 2019 at 9:38 PM Alexander Larsson
wrote:
>
> I noticed this in the FC_DEBUG=16 output:
>/run/host/fonts -> /usr/share/fonts (salt: (null))
>
> Printf NULL like this is fine in glibc, but can crash in other OSes,
> so might be nice to fix.
--
Akira TAGOH
On Tue, Apr 2, 2019 at 2:35 PM Akira TAGOH wrote:
>
> Thanks for testing, Alex.
Doing some more testing, and I think I have found an issue.
On the host i regenerate caches with your branch, getting FC_DEBUG=16
output (among other output):
cache: /6ba42aef58711b5caaf10d690066-le64.cache-7
I noticed this in the FC_DEBUG=16 output:
/run/host/fonts -> /usr/share/fonts (salt: (null))
Printf NULL like this is fine in glibc, but can crash in other OSes,
so might be nice to fix.
On Tue, Apr 2, 2019 at 2:35 PM Akira TAGOH wrote:
>
> Thanks for testing, Alex.
>
> On Mon, Apr 1, 2019 at 11:35 PM Alexander Larsson
> wrote:
> > I don't understand why its generating cache files with the same
> > filenames, even though the salt for /usr/share/fonts is different.
>
> I've added
There are another problem that salt can't be overwritten by another
dir elements coming later. which looks intuitive to me. so I'll fix
it.
On Tue, Apr 2, 2019 at 9:35 PM Akira TAGOH wrote:
>
> Thanks for testing, Alex.
>
> On Mon, Apr 1, 2019 at 11:35 PM Alexander Larsson
> wrote:
> > I don't
Thanks for testing, Alex.
On Mon, Apr 1, 2019 at 11:35 PM Alexander Larsson
wrote:
> I don't understand why its generating cache files with the same
> filenames, even though the salt for /usr/share/fonts is different.
I've added some debugging output (try FC_DEBUG=16 if you want to see
more) to
On Tue, Mar 26, 2019 at 9:09 AM Alexander Larsson
wrote:
>
> On Tue, Mar 26, 2019 at 7:15 AM Akira TAGOH wrote:
> >
> > Hi Alex,
> >
> > Have you tried new implementation yet? I believe it should be
> > reflected our discussion though, I want to see some comment from you
> > because flatpak is
On Tue, Mar 26, 2019 at 7:15 AM Akira TAGOH wrote:
>
> Hi Alex,
>
> Have you tried new implementation yet? I believe it should be
> reflected our discussion though, I want to see some comment from you
> because flatpak is only customer for salt thing so far. if it works, I
> can commit it to
Hi Alex,
Have you tried new implementation yet? I believe it should be
reflected our discussion though, I want to see some comment from you
because flatpak is only customer for salt thing so far. if it works, I
can commit it to master and make a release for them.
TIA,
On Fri, Feb 8, 2019 at
No comments on this (yet) so just opened a merge request here:
https://gitlab.freedesktop.org/fontconfig/fontconfig/merge_requests/30
If anyone can review, that would be appreciated.
On Thu, Jan 31, 2019 at 7:36 PM Akira TAGOH wrote:
>
> I've done implementation for salt:
>
Alexander Larsson writes:
> Yeah, assuming there is no global default salt that messes this up.
It sounds like having 'salt' values in dir and remap-dir elements is what
we want then -- no need for separate salt elements.
--
-keith
signature.asc
Description: PGP signature
I've done implementation for salt:
https://gitlab.freedesktop.org/tagoh/fontconfig/commits/flatpak-rework
That should works as expected.
For summary to support this on flatpak side, All of flatpaks needs to have:
/usr/share/fonts
and more if there are any fonts directories on sandbox where
On Thu, Jan 31, 2019 at 9:54 AM Akira TAGOH wrote:
>
> Also if host dirs are available as is on sandbox like Alex concerned,
> we could simply have:
>
> /opt/fonts
Yeah, assuming there is no global default salt that messes this up.
On Thu, Jan 31, 2019 at 9:40 AM Keith Packard wrote:
>
> Alexander Larsson writes:
>
> > We don't want a global salt for everything in the container.
>
> I guess I wonder why not? Salt + dir inside the container will always be
> unique. The place where you want to have different salt is for
>
On Thu, Jan 31, 2019 at 5:35 PM Keith Packard wrote:
>
> Alexander Larsson writes:
>
> > As I said in an earlier email, it needs to be in the individual dir
> > elements, because a global salt is not right.
>
> Do you want it in the elements directly? That would be more
> straightforward in
Alexander Larsson writes:
> We don't want a global salt for everything in the container.
I guess I wonder why not? Salt + dir inside the container will always be
unique. The place where you want to have different salt is for
directories mapped from the host; I think those will always be in
Alexander Larsson writes:
> As I said in an earlier email, it needs to be in the individual dir
> elements, because a global salt is not right.
Do you want it in the elements directly? That would be more
straightforward in many ways and could avoid troubles with separate salt
declarations that
On Thu, Jan 31, 2019 at 7:14 AM Akira TAGOH wrote:
>
> On Thu, Jan 31, 2019 at 8:07 AM Keith Packard wrote:
>
> > > This would avoid collision between one and origins. and assuming that
> > > flatpaks can load config from host too, we could have:
> > >
> > > 10-salt.conf (from host):
> > >
> >
On Wed, Jan 30, 2019 at 10:33 AM Akira TAGOH wrote:
>
> On Wed, Jan 30, 2019 at 5:02 AM Keith Packard wrote:
> > Yes, that was the plan. Alexander suggested the following syntax:
> >
> > /usr/share/fonts
> >
> > I think this will work, although it seems a bit fragile. In particular,
> > if
On Tue, Jan 29, 2019 at 9:02 PM Keith Packard wrote:
>
> Akira TAGOH writes:
> Do we need to process the 'salt' elements and 'remap-dir' elements in
> order and remap old salt elements as remap-dir elements get loaded? That
> also seems fragile to me.
>
> Perhaps some command that the flatpak
Akira TAGOH writes:
> Yep, that looks good to me.
I don't time this week to hack on the code, and it looks like you're
doing great anyways; let me know if you need help in any way with the
implementation work.
--
-keith
signature.asc
Description: PGP signature
On Thu, Jan 31, 2019 at 8:07 AM Keith Packard wrote:
> We may want a command line tool that extracts data from the config
> for use by flatpak in building the dynamic configuration, including
> things like salt values per directory. Yeah, that might be made to
> work with flatpak essentially
Akira TAGOH writes:
> Hm, to deal with more complicated cases, I guess we may need to have
> one global salt to affect everything and a path-specific salt for
> remapped path.
Or, more likely, no salt at all for the outermost layer as it doesn't
really add anything here.
> for flatpak case,
Le 2019-01-30 11:23, Nicolas Mailhot a écrit :
Le 2019-01-30 10:32, Akira TAGOH a écrit :
This would avoid collision between one and origins. and assuming that
flatpaks can load config from host too, we could have:
10-salt.conf (from host):
Note that the "id" attribute has special meaning
Le 2019-01-30 10:32, Akira TAGOH a écrit :
This would avoid collision between one and origins. and assuming that
flatpaks can load config from host too, we could have:
10-salt.conf (from host):
Note that the "id" attribute has special meaning and constrains in xml.
I'm not saying it
On Wed, Jan 30, 2019 at 5:02 AM Keith Packard wrote:
> Yes, that was the plan. Alexander suggested the following syntax:
>
> /usr/share/fonts
>
> I think this will work, although it seems a bit fragile. In particular,
> if the host has salt for some directories, those will be defined
>
Akira TAGOH writes:
> Hi,
>
> We are still missing a piece of a salt to deal with a directory name
> separately where possibly have different fonts in sandbox etc. my tree
> based on Keith's previous implementation works and passed test cases
> except this salt thing:
>
>
Hi,
We are still missing a piece of a salt to deal with a directory name
separately where possibly have different fonts in sandbox etc. my tree
based on Keith's previous implementation works and passed test cases
except this salt thing:
Akira TAGOH writes:
> Sure. I started to implement it based on Keith's branch.
Awesome. I'll be back home "tomorrow" and able to spend some time on
this next week.
--
-keith
signature.asc
Description: PGP signature
On Fri, Jan 25, 2019 at 4:35 PM Alexander Larsson
wrote:
>
> On Fri, Jan 25, 2019 at 5:07 AM Akira TAGOH wrote:
> >
> >
> > >
> > > as-path=... ?
> >
> > That sounds good to me.
>
> This sounds good to me to. I updated the PR:
>
On Fri, Jan 25, 2019 at 5:07 AM Akira TAGOH wrote:
>
>
> >
> > as-path=... ?
>
> That sounds good to me.
This sounds good to me to. I updated the PR:
https://github.com/flatpak/flatpak/pull/2635#issuecomment-457482239
Can I get an ack on this format?
On Thu, Jan 24, 2019 at 9:43 PM Alexander Larsson
wrote:
>
> On Thu, Jan 24, 2019 at 1:18 PM Akira TAGOH wrote:
> >
> > On Thu, Jan 24, 2019 at 8:55 PM Alexander Larsson
> > wrote:
> > > I agree that cache path is wrong as we have something else by that name.
> > >
> > > host-path kinda
On Thu, Jan 24, 2019 at 1:18 PM Akira TAGOH wrote:
>
> On Thu, Jan 24, 2019 at 8:55 PM Alexander Larsson
> wrote:
> > I agree that cache path is wrong as we have something else by that name.
> >
> > host-path kinda hardcodes the sandbox case for rewriting though. Maybe
> > "remapped-path"?
>
>
On Thu, Jan 24, 2019 at 8:55 PM Alexander Larsson
wrote:
> I agree that cache path is wrong as we have something else by that name.
>
> host-path kinda hardcodes the sandbox case for rewriting though. Maybe
> "remapped-path"?
"remap" looks redundant to the element name. simply "to" or "as" as
On Thu, Jan 24, 2019 at 12:20 PM Akira TAGOH wrote:
>
> On Thu, Jan 24, 2019 at 7:54 PM Keith Packard wrote:
> > I think we might bike-shed on the names here a bit -- 'real-path' is
> > pretty ambiguous as both paths are 'real', one is just the file system
> > path and the other is the cache
On Thu, Jan 24, 2019 at 8:20 PM Akira TAGOH wrote:
> Hmm, that looks not intuitive to me. in fact both are also a font
> path. "cache path" are the sort of /var/cache/fontconfig or so. how
> about "host-path"? although one can see it is remapping a path to
> somewhere but still missing how this
On Thu, Jan 24, 2019 at 7:54 PM Keith Packard wrote:
> I think we might bike-shed on the names here a bit -- 'real-path' is
> pretty ambiguous as both paths are 'real', one is just the file system
> path and the other is the cache path. I like using the file system path
> as the contents of the
On Thu, Jan 24, 2019 at 12:02 PM Alexander Larsson
wrote:
>
> On Thu, Jan 24, 2019 at 11:59 AM Alexander Larsson
> wrote:
> >
> > On Thu, Jan 24, 2019 at 11:54 AM Keith Packard wrote:
> > >
> > > Alexander Larsson writes:
> > >
> > > $ cat /run/host/font-dirs.xml
> > > >
> > > >
> > > >
> >
On Thu, Jan 24, 2019 at 11:59 AM Alexander Larsson
wrote:
>
> On Thu, Jan 24, 2019 at 11:54 AM Keith Packard wrote:
> >
> > Alexander Larsson writes:
> >
> > $ cat /run/host/font-dirs.xml
> > >
> > >
> > >
> > > /run/host/fonts
> > > > >
On Thu, Jan 24, 2019 at 11:54 AM Keith Packard wrote:
>
> Alexander Larsson writes:
>
> $ cat /run/host/font-dirs.xml
> >
> >
> >
> > /run/host/fonts
> > > real-path="/home/alex/.fonts">/run/host/user-fonts
> >
> >
> > Is this format acceptable? Its mostly about naming the nodes and
Alexander Larsson writes:
$ cat /run/host/font-dirs.xml
>
>
>
> /run/host/fonts
> /run/host/user-fonts
>
>
> Is this format acceptable? Its mostly about naming the nodes and the
> attributes, so its basically trivial. If you want i can rename things
> or change orders, but I'd really
On Wed, Jan 23, 2019 at 9:49 PM Keith Packard wrote:
>
> Akira TAGOH writes:
>
> > Keith,
> >
> > I'm fine with it. do you have a time to work on it? or already started
> > working?
> > If not, please let me know.
>
> I've been at a conference all week, but hope to have time next
> week. Would
Akira TAGOH writes:
> Keith,
>
> I'm fine with it. do you have a time to work on it? or already started
> working?
> If not, please let me know.
I've been at a conference all week, but hope to have time next
week. Would be happy to see others get this started, or collaborate in
any way. If I
Keith,
I'm fine with it. do you have a time to work on it? or already started working?
If not, please let me know.
On Tue, Jan 22, 2019 at 12:33 AM Alexander Larsson
wrote:
>
> On Sun, Jan 13, 2019 at 7:21 PM Keith Packard wrote:
> >
> > Alexander Larsson writes:
>
> > > Yeah, there will be
On Sun, Jan 13, 2019 at 7:21 PM Keith Packard wrote:
>
> Alexander Larsson writes:
> > 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 --
On Sun, Jan 13, 2019 at 8:53 PM Alexander Larsson
wrote:
> 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.
>
> > > However, flatpak will
On Sun, Jan 13, 2019 at 7:21 PM Keith Packard wrote:
> > 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
Alexander Larsson 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
On Fri, Jan 11, 2019 at 11:07 PM Keith Packard wrote:
>
> Alexander Larsson writes:
>
> A .uuid file was added and removed to every directory in the font tree
> which contained no fonts or sub-directories; (a) the directory mtime was
> changed, causing the system to re-scan the fonts and then
>
Alexander Larsson writes:
>> I also fought with fontconfig for about a week when the release
>> including them was installed on my machine as firefox would spin
>> whenever it found a directory with no fonts. At the time, I felt injured
>> by this change.
>
> Hmm, why was it doing that though?
On Fri, Jan 11, 2019 at 7:06 PM Alexander Larsson
wrote:
> We would have to turn that into a dynamic snippet. But that would be a
> problem for pre-existing flatpak binaries which doesn't do this.
> Could we instead have a way to modify a previously added dir element?
> Or maybe it could handle
On Fri, Jan 11, 2019 at 12:17 PM Akira TAGOH wrote:
>
> On Thu, Jan 10, 2019 at 7:54 PM Alexander Larsson
> wrote:
> > Here is my proposal:
> >
> > Make the uuid *generation* optional and manual. Then, when we create
> > the flatpak runtime we run fc-cache --make-uuid (or something) to
> >
On Thu, Jan 10, 2019 at 7:54 PM Alexander Larsson
wrote:
> Here is my proposal:
>
> Make the uuid *generation* optional and manual. Then, when we create
> the flatpak runtime we run fc-cache --make-uuid (or something) to
> generate the uuid files. Then fontconfig would never confuse the
>
On Thu, Jan 10, 2019 at 9:41 PM Keith Packard wrote:
>
> Alexander Larsson writes:
>
> > I'd like to repeat that this is not really flatpak specific as such.
> > The issue can happen in multiple cases like nfs mounts, multi-boot
> > systems, docker containers, etc.
>
> Sure, any place where path
Alexander Larsson writes:
> I'd like to repeat that this is not really flatpak specific as such.
> The issue can happen in multiple cases like nfs mounts, multi-boot
> systems, docker containers, etc.
Sure, any place where path names are not the same would cause the same
issue. I think your
Akira TAGOH writes:
> Indeed, that would be able to accomplish both with the minimal efforts
> for us at least. though they might came up with this but they didn't
> do it that way. so there might be some reason why they didn't do so.
> packaging issue perhaps?
flatpak appears to change many
On Wed, Jan 9, 2019 at 8:29 PM Keith Packard wrote:
>
> Akira TAGOH writes:
>
> > As of the discussion on the list, Keith's changes doesn't address the
> > original purpose - allow sharing caches on bind-mounts in flatpaks.
> > particularly for the case where flatpaks uses same location in
> >
On Thu, Jan 10, 2019 at 4:29 AM Keith Packard wrote:
> I'm probably forgetting a bunch of context here, but I think the problem
> was that flatpaks have /run/host/fonts pointing to the "real"
> /usr/share/fonts and then a separate /usr/share/fonts of their own with
> a small set of fonts, and so
Akira TAGOH writes:
> As of the discussion on the list, Keith's changes doesn't address the
> original purpose - allow sharing caches on bind-mounts in flatpaks.
> particularly for the case where flatpaks uses same location in
> sandbox.
I'm probably forgetting a bunch of context here, but I
Thank you for reminding and sorry for late response on this. I was on
long holidays.
On Fri, Jan 4, 2019 at 9:29 PM Chris Lamb wrote:
> Since then, I don't believe there has been any review of this
> branch both in the sense of the code itself but also in terms of
> the architectural changes
66 matches
Mail list logo
