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
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 fla
nk 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 testi
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 i
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
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
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 wan
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
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 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 thoug
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 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:
&g
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
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
> >
>
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
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
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
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
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 f
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.
>
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
> >
Package: ostree
Version: 2018.4-1
Can you please backport this:
https://github.com/ostreedev/ostree/commit/28c7bc6d0e153a0b07bdb82d25473a490765067f
It fixes an issue that makes flatpak not work in some setups.
See https://github.com/ostreedev/ostree/pull/1524 for some details
On mån, 2016-12-12 at 16:11 +, Simon McVittie wrote:
> On Wed, 07 Dec 2016 at 10:16:53 +0100, Alexander Larsson wrote:
> >
> > On tis, 2016-12-06 at 20:07 +, Simon McVittie wrote:
> > >
> > > Can you point me to a concrete example of building the f
On tis, 2016-12-06 at 20:07 +, Simon McVittie wrote:
> On Tue, 06 Dec 2016 at 14:49:35 +0100, Alexander Larsson wrote:
> >
> > The flatpak package has versioned build-deps on ostree, but the
> > actual
> > package-deps (i.e. flatpak -> libostree) are not.
>
ree.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a scarfaced bohemian vagrant whom everyone believes is mad. She's a
hard-bitten foul-mouthed angel with someone else's memor
.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a globe-trotting soccer-playing messiah who knows the secret of the
alien invasion. She's
Package: flatpak
Ubuntu supports unprivileged user namespaces by default, so there is
no particular reason to use setuid there. The current debian packages
unconditionally uses setuid though. Maybe this could be avoided on
ubuntu?
I've added code to docker to handle / being shared, since fedora works like
that. It works by detecting a shared / and the starting lxc-start in its
own namespace where we've mounted / as rslave. See the code here:
https://github.com/dotcloud/docker/blob/master/container.go#L673
This works out
33 matches
Mail list logo
