[05:15] <mborzecki> morning
[06:01] <zyga> Hi
[06:15] <mborzecki> zyga: hey
[06:52] <mborzecki> rebooting, brb
[06:55] <mborzecki> re
[07:05] <pstolowski> morning
[07:05] <mborzecki> pstolowski: hey
[07:05] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6939 ? got +1 from pedronis, needs a 2nd review
[07:06] <pstolowski> k
[07:06] <mborzecki> pstolowski: thanks!
[07:18] <zyga> Hey Pawel
[07:18]  * zyga goes for breakfast
[08:05] <zyga> re
[08:22] <Chipaca> zyga: in NewAtomicFile there isn't a 'no chmmod' because there is no chmmod, there is a mode for the mode to create the file with
[08:23] <Chipaca> which is the 0644 in the code you commented on
[08:24] <mborzecki> hm foobar seems to be getting some attention in the forums
[08:25] <Chipaca> mborzecki: you mean two posts by the same person? :-)
[08:26] <mborzecki> Chipaca: yeah :/
[08:27] <mborzecki> Chipaca: 2 posts and i still don't know what the actual problem is
[08:28] <Chipaca> mborzecki: in the first one, the fonts are too small (not picking up hidpi)
[08:28] <Chipaca> mborzecki: in the second one, it's the WRONG VERSION
[08:28] <Chipaca> mborzecki: completely UNUSABLE what is even the POINT
[08:31] <mborzecki> Chipaca: basically like any other windows app running under wine
[08:31] <Chipaca> mborzecki: is that what it is?
[08:35] <mborzecki> Chipaca: foobar2000? it's a windows app
[08:35] <Chipaca> ¯\_(ツ)_/¯  ok :-)
[08:35] <Chipaca> step 1. get a proper music player
[08:35] <Chipaca> step 2. quit yer complainin'
[08:36] <mborzecki> Chipaca: foobar2000 is an opinionated music player ;) superior sound quality on them crapphy on-board DACs
[08:36]  * Chipaca hugs his onboard DACs to his chest and screams like a banshee
[08:37] <Chipaca> mborzecki: do you recognise the distro / wm they're using?
[08:38] <mborzecki> Chipaca: is that mint?
[08:38] <Chipaca> je ne sais pas
[08:38] <Chipaca> (je ne sais rien, aussi)
[08:38]  * Chipaca runs out of french
[08:39] <mborzecki> Chipaca: the icon looks similar https://linuxmint.com/
[08:39] <Chipaca> mborzecki: indeed
[08:39] <Chipaca> mborzecki: if you had told me it was limewire I would've believed you also
[08:49] <mborzecki> Chipaca: looks like crap on 4k https://i.imgur.com/JM5gapb.png
[08:49] <Chipaca> mborzecki: and clementine?
[08:50] <Chipaca> I'll be getting 4k sometime soon (there's a queue of big-ticket things... :)
[08:51] <pedronis> mborzecki: hi, does my comment about symmetry of call patterns make sense, or do we need to chat about it?
[08:52] <mborzecki> pedronis: yup it's clear, i missed that in your previous review, i'll be pushing out patches soon
[08:53] <pedronis> mborzecki: basically, except that they are kind of like push pop, I would expect to see calls to those *Prefix helpers in roughly the same place/numbers in the rollback and backup flows
[08:59] <mborzecki> Chipaca: https://i.imgur.com/rQsOcCm.png window in the left is clementine from the snap, right one is distro packages, also snap version seems to use qt 4.8 (?)
[09:00] <Chipaca> hmm, ok
[09:20] <mborzecki> pstolowski: updated https://github.com/snapcore/snapd/pull/6939 please take a look
[09:21] <pstolowski> ok
[09:23] <pstolowski> +1
[09:23] <mborzecki> pstolowski: yay ;) will land it once it's green
[09:32] <Chipaca> I'm going to take a break, take a couple of pills and see if I feel better
[09:32]  * Chipaca feeling blagh
[09:32]  * Chipaca will bbl
[09:33] <zyga> take care Chipaca!
[09:33]  * zyga goes to do reviews
[09:44] <pstolowski> mborzecki: can you take another look at #7052? needs 2nd review
[09:45] <mborzecki> pstolowski: sure
[10:49] <jamesh> zyga: re. https://github.com/snapcore/snapd/pull/6959, do you have any feedback on my responses to your earlier review?
[10:49] <zyga> jamesh: hey
[10:49] <zyga> jamesh: let me look
[10:50] <jamesh> zyga: I agree that it would be good to do something about "directories matching the glob pattern".  I'm just not sure exactly what that should look like
[10:51] <zyga> jamesh: I think we should not just execute the logic as is
[10:51] <zyga> jamesh: and instead error or panic
[10:51] <zyga> jamesh: I think this one is also actionable: https://github.com/snapcore/snapd/pull/6959#discussion_r296584872
[10:52] <jamesh> zyga: the problem is that the directory blacklist glob is not the same as the glob for files we want to update
[10:54] <jamesh> the first needs to be a glob that will match any other globs that might be used for this directory
[10:56] <zyga> jamesh: what is the use case of the function?
[10:56]  * zyga re-reads that fragment
[10:57] <jamesh> consider the case that I call EnsureTreeState with a glob of "snap.foo.*", asking to put a create a file "snap.foo.file" in a directory "snap.bar.dir"
[10:57] <jamesh> the passed in glob won't have any problem with the directory, but it will cause a problem for a second EnsureTreeState call with a glob of "snap.bar.*"
[10:58] <jamesh> zyga: the use case is allowing a snap to export icon theme icons
[10:59] <jamesh> essentially we want to create a merged /usr/share/icons style tree with data from multiple snaps by only letting the snaps create icons prefixed with the snap name
[10:59] <zyga> jamesh: what's the rough structure there?
[11:00] <jamesh> zyga: the first level of directories is the icon theme name.  Directories after that is "whatever is defined in the index.theme file"
[11:01] <zyga> so /usr/share/icons/$theme/$anything?
[11:01] <jamesh> we don't let snaps install an index.theme: they'd need to match the layout of the icon theme they're providing an icon for
[11:01] <jamesh> yes.  We're installing icons to /var/lib/snapd/desktop/icons though
[11:02] <jamesh> it all gets merged via $XDG_DATA_DIRS
[11:02] <zyga> I see
[11:02] <jamesh> so the directory tree is under snapd's control, but we don't have full knowledge of its structure
[11:02] <zyga> I wish we had set $XDG_DATA_DIRS to /var/lib/snapd/export/desktop
[11:03] <zyga> it would play nicely with the idea to export other kinds of content
[11:03] <jamesh> or export/share
[11:04] <zyga> jamesh: would it be okay to iterate over keys of "content" and error if it matches any of the globs? similar to what this does: https://github.com/snapcore/snapd/blob/master/osutil/syncdir.go#L69
[11:04] <zyga> I'm really trying to avoid the situation when this executes in unexpected ways
[11:05] <jamesh> zyga: as I said, I think it would need to be a second glob (or set of globs)
[11:05] <jamesh> to avoid one snap poisoning a second snap
[11:06] <zyga> jamesh: wait, perhaps I'm missing something
[11:06] <zyga> (I might as well be, it's hot and there's no air conditioning here)
[11:06] <zyga> jamesh: I'm not talking about the directory walk
[11:06] <zyga> jamesh: just about the input arguments
[11:07] <jamesh> I'll try expressing myself in code in a comment on the PR
[11:08] <zyga> ok
[11:09]  * Chipaca still bleugh but trying to work
[11:13] <jamesh> zyga: https://github.com/snapcore/snapd/pull/6959#discussion_r302010405 <- I think this demonstrates the problem
[11:13] <zyga> looking
[11:15] <zyga> jamesh: and what will actually happen if you do this pair of calls?
[11:15] <zyga> what will happen to disk and what will the function return?
[11:16] <jamesh> zyga: at the moment, we don't protect against it, so there will be an EnsureDirState call for "$baseDir/somedir" that will fail when it tries to remove "snap.bar.directory"
[11:17] <jamesh> If the first call is done on behalf of snap A, and the other on behalf of snap B, then the source of the problem is going to be fairly far removed from the symptom
[11:19] <zyga> re, net failure
[11:20] <zyga> could we detect that in the dir walk and bail out, doing nothing?
[11:20] <zyga> I'm just trying to make this function fail in a well-defined way
[11:21] <jamesh> yes.  The second call could bail out when it detects the trap the first call set
[11:21] <zyga> this one is also related https://github.com/snapcore/snapd/pull/6959#discussion_r296584872
[11:21] <zyga> since when something fails it will rm -rf all matching content
[11:22] <zyga> and this is surprising because one has to consult the documentation of EnsureDirStateGlobs to know that
[11:24] <jamesh> I guess for the tree version that should cover all the subdirs it successfully synchronised
[11:24] <jamesh> before the failure
[11:27] <zyga> jamesh: indeed, I though about just documenting it but now that you mention it, it seems actual code is needed
[11:33] <jamesh> combinging with the previous issue, it would fail to remove the "somedir/snap.bar.directory" trap since it isn't empty
[11:34] <jamesh> I'll have a look at this again tomorrow.
[11:34] <zyga> jamesh: thank you!
[11:55] <pedronis> mvo: could you review 7016 ?
[11:56]  * zyga small break from heat
[12:08] <mvo> pedronis: yes, after lunch
[12:48] <zyga> re
[13:15] <tartley> o/ Morning all
[13:16] <tartley> oops wrong channel
[13:34]  * zyga hammers spread and grabs a cofee
[13:39] <mborzecki> still spamming with new PRs: https://github.com/snapcore/snapd/pull/7087
[13:41] <zyga> mborzecki: looking
[13:50] <roadmr> zyga: it's easier if you... spread it around with a knife. Hammering it will just crush your bread.
[13:51] <roadmr> context-dependent jokes are the best 😉
[13:51] <zyga> today I would love to see rain, my mind is melting away at the heat
[13:57] <roadmr> "I live in such a hot, tropical place". "Where, Cuba? the Caribbean?" "No - Poland"
[14:08] <zyga> roadmr: today it's actually closer to cuba, we're back in Spain
[14:09] <zyga> roadmr: poland already has autumn
[14:09]  * zyga took hold shower
[14:09] <roadmr> hehe zyga
[14:10] <zyga> I needed that
[14:10]  * zyga needs a review on https://github.com/snapcore/snapd/pull/7082
[14:13]  * zyga continues reviews
[14:49] <ogra> https://www.omgubuntu.co.uk/2019/07/devs-want-to-drop-snap-support-from-gnome-software
[14:50] <ogra> heh ... it is funny that the reaction in the commenst seems to be "drop GNOME" ... not "drop this snap stuff"
[14:50] <ogra> *comments
[14:52] <zyga> ogra: sensationalism, it's just "press" latching onto a story
[14:53] <ogra> zyga, sure, but usually the comments section has "cnonical should drop that snap stuff, flatpack is so much better" (ignoring the actual difference) or "shitty canonical NIH stuff" (ignoring that snaps are two years older than flatpak)
[14:54] <zyga> ogra: that's true but I would say that comment sections are in general, horrible
[14:54] <zyga> ogra: it's just that we are more lucky this time
[14:55] <ogra> the article itself is indeed definitely  clickbait
[14:55] <zyga> ogra: having said that, I'm curious about the snap store app
[14:55] <ogra> i find comments sections a big source of entertainment ... and after all they reflect a fraction of users out there
[14:55] <ogra> (just dont comment yourself ... )
[14:56] <ogra> zyga, well, ask robert_ancell_ then ;)
[14:57]  * ogra senses a webdm comeback as electron app :P
[14:57] <ogra> j/k
[14:58] <zyga> ogra: maybe we will all use enlightenment again ;)
[14:58] <ogra> lol
[14:58]  * diddledan peeks in.. sees ogra has op status.. runs out screaming about the end of the world
[14:59] <ogra> LOL !!
[15:00] <zyga> ogra: oh, you are *the* op
[15:20]  * zyga spawns lots of spread machines to check a change and takes a break
[15:20] <zyga> mvo: I would love a review for https://github.com/snapcore/snapd/pull/7082 to unblock me
[15:24] <zyga> ijohnson: ^
[15:25] <ijohnson> zyga: thanks I'll take a look after my meeting right now
[15:25] <zyga> thanks, I'm really blocked by that
[15:26] <zyga> it's not super perfect, I know, it could use more testable design, I just really want to move towards the code that uses it :)
[15:29] <mvo> zyga: meetings :/
[15:29]  * zyga hugs mvo
[15:36]  * cachio lunch
[15:39]  * zyga takes a break for some back pain relief
[16:03] <ijohnson> zyga: approved 7082
[16:13]  * ijohnson lunches
[16:27] <zyga> ijohnson: fantastic, thank you
[16:28] <zyga> ijohnson: one more if you have time today https://github.com/snapcore/snapd/pull/7089
[16:28] <zyga> ijohnson: treating size= differently because it is not super deterministic even when rewriting
[16:31] <zyga> ijohnson: also some advice on the upcoming test, it measures mount namespaces of a number of things; the bulk of the test is normalized expected data
[16:31] <zyga> ijohnson: I wonder if I should propose it all at once and then work on reviewing or split it
[16:31] <zyga> ijohnson: e.g. qemu vs google could be split easily (separate data sets per backend)
[16:45] <zyga> ijohnson: I will propose it all-at-once once 7089 is merged, then we can discuss
[16:45] <zyga> ijohnson: it's is mainly either establishing a baseline
[16:45] <zyga> ijohnson: so not a sophisticated review
[16:45] <zyga> ijohnson: or actually reviewing the sensibility of the mount namespace
[16:46] <zyga> ijohnson: and here I'd argue that some things are silly and warrant changing
[16:46] <zyga> ijohnson: in either case I have some work on early changes to core legacy to fix things
[16:56] <zyga> ijohnson: the mount namespace test will be used to sanity check changes to propagation settings and to some corrections to ubuntu-core legacy mode
[19:37]  * cachio afk
[21:35] <jdstrand> roadmr: hi! can you pull 20190709-2230UTC?
[21:36] <roadmr> jdstrand: sure thing, will put it in the queue at least
[21:57] <ijohnson> zyga: I looked at 7089 for you and approved with a couple name/description suggestions. I don't quite follow all of what you said about about the future work, but it will probably make sense to me after seeing the full test
[22:41] <zyga> ijohnson: ack
[22:42] <zyga> ijohnson: suggestions applied, thank you!
[22:43] <zyga> ijohnson: I'm slowly heading to bed, I'll open the main PR for the ns test tomorrow
[22:43] <zyga> thank you again :)
[23:55] <mwhudson> zyga: do you get mail about debian snapd bug reports?
[23:56] <mwhudson> or more generally, does some snapd developer?