[00:02] <mup> PR snapcraft#2106 closed: nodejs plugin: lazy load the required tarballs <bug> <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2106>
[01:51] <mup> PR snapcraft#2100 closed: build_providers: new build provider using multipass <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2100>
[02:09] <mup> PR snapcraft#2107 opened: Release changelog for 2.42 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2107>
[02:31] <sergiusens> diddledan: if you can add notes to the PR and confirm it working it would be great
[02:34] <mup> PR snapd#5102 opened: tests: new utility to save and restore the snap state <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5102>
[05:12] <zyga> good morning
[05:12] <mborzecki> zyga: hey
[05:33] <zyga> mborzecki: I sent a few extra trivial PRs
[05:33] <zyga> mborzecki: could you please look at them, they have a few lines to a few dozen at most
[05:57] <mup> PR snapd#5101 closed: testutil: don't dot-import check.v1 <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5101>
[06:10] <zyga> Thanks!
[06:12] <zyga> I feel great today, hopefully this will be a good day for coding :-)
[06:15] <mup> PR snapd#5099 closed: testutil: rename UNMOUNT_NOFOLLOW to umountNoFollow <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5099>
[06:19] <mborzecki> the tests are shellcheck clean now
[06:20] <mborzecki> 249 files changed, 1338 insertions(+), 797 deletions(-)
[06:20] <mup> PR snapd#5086 closed: osutil,interfaces,cmd: use fewer hardcoded strings <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5086>
[06:20] <zyga> Wooooot
[06:20] <zyga> Send the patches!
[06:21] <mborzecki> it's all here now https://github.com/bboozzoo/snapd/commits/bboozzoo/spread-shellcheck i need to chop the last patch into smaller, reviewable pieces
[06:23] <zyga> Ok
[06:23] <zyga> Use things that qualify for simple :-)
[06:25] <mborzecki> ok, i need to go out for 2-3h now, will be back ~11
[06:48] <zyga> Ok
[06:53] <ogra_`> /join #ubuntu-release-party
[06:53] <ogra_`> oops
[07:06] <zyga> Oh
[07:07] <mup> PR snapd#5100 closed: testutil: document all fake syscall/os functions <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5100>
[07:09] <pstolowski> mornings
[07:19] <zyga> Hey
[08:08] <Chipaca> zyga: I think I addressed your concerns with #4983
[08:08] <mup> PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
[08:10] <zyga> looking
[08:26] <zyga> Chipaca: done
[08:27] <zyga> Chipaca: do you want to look at https://github.com/snapcore/snapd/pull/5081
[08:27] <mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
[08:27] <zyga> I could use it to propose the fix for the 1st layout issue
[08:28] <Chipaca> looking
[08:31] <Chipaca> zyga: ok,  question time
[08:31] <zyga> I'm all ears
[08:31] <Chipaca> zyga: in /foo/bar/froz with depth 2
[08:31] <Chipaca> zyga: see the doctor about that
[08:31] <Chipaca> zyga: why is 'right' /foo/bar/{*,*/,froz} rw ?
[08:31] <Chipaca> why even have froz there if you have *?
[08:32] <zyga> that's just simplicity, yes, we could special case that last part
[08:32] <zyga> since froz is covered by * and froz/ (if it was a directory) would be covered by */
[08:32] <Chipaca> zyga: ok, how about, in /foo/bar/baz/froz with depth 2
[08:32] <zyga> ok
[08:33] <Chipaca> zyga: would right be /foo/bar/{*,*/,baz/froz} rw ?
[08:33] <zyga> no
[08:33] <zyga> it would be, /foo/bar/{*,*,baz/{*,*/,froz}
[08:33] <zyga> (the rw, part is separate so I will omit it)
[08:33] <zyga> ah., I missed } above :)
[08:33] <zyga> it would be, /foo/bar/{*,*,baz/{*,*/,froz}}
[08:34] <zyga> it would be, /foo/bar/{*,*/,baz/{*,*/,froz}}
[08:34] <Chipaca> zyga: I definitely don't understand then
[08:34] <zyga> sorry, this one should be it :-D
[08:34] <Chipaca> it seems the right-hand thing could always be omitted
[08:34] <zyga> omitted how?
[08:35] <Chipaca> zyga: I don't remember if */ implies */* and  */*/
[08:35] <zyga> * is any file, */ is any directory
[08:35] <Chipaca> zyga: but even if it doesn't, it seems just using *s always covers the explicit case
[08:35] <zyga> ** implies any file and directory recursively forever
[08:36] <Chipaca> zyga: i.e. /foo/bar/{*,*/,*/{*,*/}}
[08:36] <Chipaca> what does adding the explicit names give you, that this doesn't?
[08:37] <zyga> it hands out different permissions
[08:37] <zyga> note that this allows you to make /foo/bar/<any file or directory here but not deeper>
[08:37] <zyga> expand the version as implemented
[08:37] <zyga> and the one with */,*
[08:37] <Chipaca> zyga: so it's any file or directory along this path but not parallel to it
[08:38] <Chipaca> ie /foo/bar/baz/froz at 2 would let you do /foo/bar/boo, /foo/bar/baz/boo, but not /foo/bar/meep/vorp
[08:39] <Chipaca> ?
[08:39] <zyga> you can do /foo/bar/<anything here but not deeper> yes
[08:39] <zyga> it's an abbreviation of multi-line variant of that
[08:39] <zyga> I wanted to avoid **
[08:39] <zyga> which is like _anything_ flies
[08:40] <Chipaca> zyga: what's the use case for it? when do you want to allow this and just this?
[08:40] <zyga> for writable mimics specifically
[08:40] <Chipaca> zyga: also p.s. 'cnt' as a variable name reads wrong (just noticed) :-)
[08:40] <zyga> count :)
[08:40] <zyga> ok
[08:41] <Chipaca> maybe i've just got a dirty mind :-)
[08:41] <zyga> https://github.com/snapcore/snapd/pull/5074/commits/eb6d997ab607ecee966de5deffb87a83684e6fe3
[08:41] <mup> PR #5074: many: allow mimics in parents of layout <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5074>
[08:41] <zyga> Chipaca: I will change it
[08:41] <zyga> Chipaca: this is the consumer of that patch
[08:41] <zyga> (probably needs small rebase)
[08:42] <zyga> look at the writableMimicProfile there
[08:42] <zyga> Chipaca: look at the test diff below
[08:42] <zyga> it replaces a list of rules
[08:43] <zyga> with one rule that expands to that and then some
[08:44] <Chipaca> zyga: I still don't get why you need * if you already know the name
[08:44] <zyga> because it may be at any earlier stage
[08:44] <zyga> if we want to make a layout at /usr/share/magic/software
[08:45] <zyga> but magic isn't in the core snap
[08:45] <zyga> we need to construct a mimic at /usr/share
[08:45] <zyga> and this rule grants that
[08:45] <zyga> also let's say magic exists but software doesnt
[08:45] <zyga> then we need to make one at /usr/share/magic
[08:45] <zyga> this is a generalised way to make those
[08:46] <Chipaca> but that would mean something like /usr/share/{,magic/{,software}}
[08:46] <zyga> yes
[08:46] <zyga> but then you realise what is needed to make a mimic
[08:46] <zyga> you need to mount tmpfs on /usr/share
[08:46] <zyga> then make *any file or directory there*
[08:46] <zyga> and bind mount the originals back
[08:46] <zyga> so you need the * and */ rules
[08:46] <zyga> see?
[08:46] <Chipaca> zyga: yes
[08:47] <Chipaca> zyga: thanks
[09:01] <Chipaca> zyga: mostly +1, holding off the actual +1 because I think it needs more tests
[09:01] <Chipaca> zyga: should be easy to add them though :-)
[09:01] <zyga> ack, looking
[09:01] <zyga> Thank you for looking, this is tricky stuff :)
[09:02] <Chipaca> zyga: it is, and some of the tests I ask for are probably silly _today_ :-) but might help us at some point down the road
[09:46] <mvo> zyga: I got a report about a "apparmor="DENIED" operation="change_onexec"
[09:46] <mvo> info="label not found" error=-2 profile="/usr/lib/snapd/snap-confine"" does that ring a bell? is that the "profiles vanish on boot" issue?
[09:46] <mvo> "cannot
[09:46] <mvo> change profile for the next exec call: No such file or directory"
[09:46] <zyga> yes
[09:46] <zyga> that or pre run-waits fix
[09:48] <zyga> mvo: what more do you know?
[09:48] <zyga> did you experience that/
[09:54] <mborzeck1> re
[09:54] <mborzecki> that took longer than i anticipated
[09:54] <mvo> zyga: I forwarded you a mail with all the info I have
[09:54] <zyga> checking
[09:54] <mvo> zyga: thank you!
[10:04] <om26er> popey: hey! android-studio has 3400+ installs (and ever growing), impressive ?
[10:04] <popey> wow
[10:04] <popey> thats great!
[10:05]  * ogra_` is surprised that mjpeg-streamer ha over 1000 already ... 
[10:05] <ogra_`> *has
[10:05] <om26er> popey: how is sublime doing ?
[10:05] <popey> We found that if we put an application in the featured list, it *always* jumps in userbase
[10:06] <popey> om26er: over 4k!
[10:06] <ogra_`> i wouldnt have thought such a trivial tool can be so popular
[10:06] <mvo> sergiusens: re 1764998> is corebird a sideloaded snap?
[10:06] <om26er> wow!
[10:07] <om26er> for a tool like Android Studio that 3400+ is an impressive count, give that a few months and it'll surpass 10k
[10:07] <sergiusens> mvo: no, if you have the bug report I believe I added snap info for corebird, I still see the issue btw
[10:08] <mvo> sergiusens: always with the same snap?
[10:08] <mvo> sergiusens: or is thta random?
[10:08] <sergiusens> mvo: just that one
[10:09] <mvo> sergiusens: and do you see any pattern? Like profiles vanish after auto-refresh ? or after boot? or anything?
[10:11] <sergiusens> mvo: certainly after reboot, not consistent
[10:12] <tomwardill> mvo, sergiusens: huh, that bug ticket and enable/disable just fixed my corebird. It's after reboot almost definitely for me, and sometimes after an app restart (maybe after a refresh while the app is open?)
[10:12] <tomwardill> I also only see it on that snap
[10:13] <sergiusens> mvo: this snap is feature packed with interfaces (including `content`)
[10:14] <mvo> tomwardill, sergiusens thanks! that is useful information
[10:15] <mvo> zyga: ^-- looks like a certain property of the snap makes it vanish
[10:16] <zyga> hmm
[10:22] <mvo> zyga, sergiusens fwiw, I installed corebird and rebooted 5 times, so far so good, I suspect more needs to happen to trigger it, I need to run in a bit but will try to figure out more
[10:27] <ogra_`> sergiusens, bah ... whats that ? https://paste.ubuntu.com/p/zWP3m9ktMx/
[10:28] <ogra_`> (the part is plainly using the make plugin, caring for the cross stuf on its own)
[10:28] <ogra_`> is there a way to override that ?
[10:36] <zyga> sergiusens: can you install this unit on your sytem
[10:36] <zyga> lp-1764998.service https://www.irccloud.com/pastebin/GU7D0QRT/
[10:36] <zyga> in case it happens again
[10:37] <zyga> mvo: ^
[10:37] <mvo> zyga: nice!
[10:37] <zyga> journald contains the output so we can inspect it later
[10:38] <sergiusens> ogra_`: create snap/plugins/x_make.py
[10:40] <ogra_`> sergiusens, thanks ... found another solution (using the deb :P ... )
[11:03] <zyga> Chipaca: I think https://github.com/snapcore/snapd/pull/5081 is ready for another look
[11:03] <mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
[11:09] <zyga> hmmm
[11:09] <zyga> I _may_ have theory
[11:14] <Chipaca> zyga: +1, although I note you didn't add tests for wonky depths :-)
[11:15] <zyga> Chipaca: because it's already there :)
[11:15] <zyga> well
[11:15] <zyga> not for negative depths
[11:15] <zyga> that's a good idea
[11:15] <zyga> https://github.com/snapcore/snapd/pull/5081/files#diff-16cc40a4b635e1e0e4c9d520342fd500R295 is deeper then than the number of directories
[11:15] <mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
[11:15] <zyga> but yeah
[11:15] <Chipaca> ah, the 4 is bigger
[11:15] <Chipaca> k
[11:16] <zyga> orders a beer, orders a "", orders 252341342352
[11:16] <zyga> :-)
[11:16] <zyga> I'll do it
[11:16] <Chipaca> quite
[11:16] <zyga> pstolowski: reviewed the Undesired field branch
[11:16] <Chipaca> pretty much
[11:16] <zyga> pstolowski: let's talk in 10 minutes
[11:16] <zyga> I have an idea I want to run by you
[11:16] <pstolowski> zyga: thanks, sure
[11:31] <pstolowski> zyga: interesting remark about possibly dropping auto flag. hmm
[11:31] <zyga> pstolowski: as I wrote below, not just the auto flag, all but the Undesired flag should be dropped
[11:31] <zyga> (perhaps the interface type should remain as well but it is unclear what to do when it changes under us)
[11:51] <mup> PR snapd#5103 opened: tests: shellcheck spread tasks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5103>
[11:51] <mborzecki> basic setup for shellchecking spread files ^^
[11:56] <Chipaca> mborzecki: hah. I'd added it to spread, your approach seems a lot more polite
[11:58] <mborzecki> Chipaca: well, we could do it now ;) i have all the fixes
[11:59] <mborzecki> jokes aside, shellcheck is terribly annoying with some of the warnings
[11:59] <ogra_`> +1
[11:59] <ogra_`> totally overzealous at times
[12:03] <Chipaca> ogra_`: aren't we all
[12:03] <ogra_`> i pretend not to ... (but i'm really bad at that)
[12:06] <Chipaca> ogra_`: https://www.youtube.com/watch?v=mLRjFWDGs1g&t=16s
[12:06] <ogra_`> hahahaha
[12:07] <ogra_`> now i want a moustache !
[12:24] <pstolowski> niemeyer: hey, can you clarify on the one open question in the https://github.com/snapcore/snapd/pull/4358 (the naming of connect-slot-task vs slot-hook-task etc)? that's the last point that I potentially need to address once agreed on
[12:24] <mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
[12:24] <niemeyer> pstolowski: Yeah, on it
[12:24] <pstolowski> thanks
[12:26] <niemeyer> pstolowski: But the PR hasn't changed at all yet?
[12:31] <niemeyer> pstolowski?
[12:31] <pstolowski> niemeyer: it did, it's just this one aspect that I haven't changed, all other points addressed and pushed
[12:32] <niemeyer> pstolowski: That's not what I see in the actual PR
[12:35]  * kalikiana lunch
[12:36] <pstolowski> niemeyer: https://github.com/snapcore/snapd/pull/4358/commits/804c1b3f38463da4892d56fc181d03945c36b94e is addresseing all your comments from last review
[12:36] <mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
[12:37] <niemeyer> pstolowski: I'm literally looking at https://github.com/snapcore/snapd/pull/4358/files
[12:37] <niemeyer> pstolowski: I can see both the code and the comment in the actual PR
[12:39] <pedronis> niemeyer: I asked him to put hook in those names, because we have "connect" tasks and are not those tasks, so I find that confusing
[12:39] <pstolowski> niemeyer: ah, you're right, looks like the Conversation summary didn't show them and I missed those... sorry about that
[12:40] <pstolowski> niemeyer: so I missed some of your comments re formatting, will fix in a few moments
[12:40] <pedronis> ah, I was confused too
[12:40] <pedronis> pstolowski: there's  "load more" thing in the middle of the comment lists
[12:41] <pstolowski> pedronis: hah, indeed
[12:41] <pstolowski> totally unexpected
[12:41] <pedronis> it's a recent change
[12:42] <pstolowski> :)
[12:42] <pedronis> (also github is kind of slow for me recently)
[12:42] <pstolowski> yes for me too.. i just had to restart my browser as github slowed it down to a halt
[12:43] <pstolowski> i need to run to school, bb for standup
[12:43] <mup> PR snapd#5104 opened: overlord,systemd: store snap revision in mount units <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5104>
[12:43] <niemeyer> pedronis: Ack, sounds fine then
[12:43] <niemeyer> pstolowski: ^
[12:58] <mup> PR snapd#5038 closed: data/systemd: helper service for waking up the main snapd service <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5038>
[12:59] <mup> PR snapd#4399 closed: rewrite snappy-app-dev <Decaying> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/4399>
[13:00] <mup> PR snapd#5105 opened: testutil,cmd: rename test helper of Lstat to OsLstat <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5105>
[13:13] <thresh> nice, new snapcraft store lookanfeel
[13:15] <mup> PR snapd#5106 opened: testutil: add test helper for SysLstat <Created by zyga> <https://github.com/snapcore/snapd/pull/5106>
[13:31] <kalikiana> re
[13:33] <thresh> jdstrand, updated the apparmor/vlc/link bug with an info from ubuntu 16.04 - same thing is happening there it seems :O
[13:34] <jdstrand> thresh: that's weird... jjohansen is watching the bug. thanks for the feedback!
[13:35] <thresh> :)
[13:39] <zyga> thresh: can you pass the URL please
[13:40] <thresh> zyga, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1766628 there you go
[13:40] <mup> Bug #1766628: apparmor denies VLC to open files in devmode <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1766628>
[13:40] <thresh> it's quite hectic because I suck at bug reporting
[13:49] <mborzecki> Chipaca: 1.9 breaks with your uid sample right?
[13:50] <Chipaca> mborzecki: yes
[13:51] <Chipaca> mborzecki: if you hit a 'too many threads', reduce N to see the bug
[13:51] <Chipaca> (also, get a slower cpu)
[13:51] <Chipaca> (or was it a faster one)
[13:53] <mborzecki> hmm broke very quickly ;)
[13:53] <zyga> Chipaca: what do you think about https://github.com/snapcore/snapd/pull/5104
[13:53] <mup> PR #5104: overlord,systemd: store snap revision in mount units <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5104>
[13:54] <Chipaca> zyga: i'll look at it when i get back from the school run
[13:54] <zyga> Thank you sir!
[13:54] <thresh> should I file snapcraft bug at github or launchpad?
[13:54] <zyga> launchpad please
[13:54] <Chipaca> mborzecki: if it looks like a stack trace, it's not my bug
[13:54] <thresh> allright
[13:54] <Chipaca> mborzecki: mine is {something in brackets}
[13:54] <Chipaca> mborzecki: main.Result{uidBefore:12345, uidDuring:12345, uidAfter:12345}
[13:55]  * Chipaca runs
[13:55] <mborzecki> Chipaca: yup, that's what I see, just made it a panic so it doesn't spam my terminal too much :)
[13:55] <Chipaca> mborzecki: with all those goroutines it should be less spammy than a panic
[13:55] <Chipaca> but, you do you
[13:56]  * Chipaca really runs
[14:03] <zyga> and in other news, when I'm not hacking on snapd I'm a super-hero on twitter ;-) https://twitter.com/keshavmail68/status/989503868730933248
[14:22] <mborzecki> Chipaca: this looks really awkward https://paste.ubuntu.com/p/4q2wz2w739/
[14:22] <zyga> mborzecki: who clones new threads when all threads are busy?
[14:22] <zyga> which process does that
[14:22] <zyga> is there a zygote in go?
[14:23] <mborzecki> runtime does that, whenever all threads are blocked and you have runnable goroutine
[14:23] <zyga> yeah but who is the parent
[14:23] <zyga> it is relevant
[14:36]  * cachio lunch
[14:45] <mborzecki> GOMAXPROCS=1 makes it go away
[14:49] <zyga> mborzecki: "let's all write in C" ;-)
[14:49]  * zyga -> break
[14:50] <zyga> it rains like crazy so  no walk for me
[14:50] <zyga> but I can cook now :)
[14:51] <mborzecki> race detector not very helpful, too many goroutines
[15:12] <Chipaca> mborzecki: for extra fun, pass uid
[15:13] <Chipaca> mborzecki: ie for uid:=1; uid<100000; uid ++ { go f(uid, ch)  }
[15:15] <mborzecki> hm the channel buffer is short, so that's where the conetntion comes from, more threads spawned as goroutines can run, now if syscall is a scheduling point, could it happen so that a thread is spawned from a locked thread which is running under different uid?
[15:17] <mborzecki> Chipaca: does that make any sense?
[15:17] <Chipaca> mborzecki: if locked threads are still candidates for cloning yes
[15:20] <sergiusens> mvo zyga btw, it is observable in lxd, the next exec call thing https://bugs.launchpad.net/snapcraft/+bug/1760514
[15:20] <mup> Bug #1760514: cannot change profile for the next exec call: No such file or directory <Snapcraft:New for kalikiana> <https://launchpad.net/bugs/1760514>
[15:20] <mborzecki> Chipaca: https://github.com/golang/go/blob/master/src/runtime/proc.go#L1835 so they check if a thread is locked
[15:20] <mborzecki> (at least in 1.10)
[15:21] <zyga> Ack, i am eating lunch now but I will check soon
[15:21] <mborzecki> Chipaca: but not in 1.9? https://github.com/golang/go/blob/release-branch.go1.9/src/runtime/proc.go
[15:22] <Chipaca> mborzecki: yeah, 1.10 saw work in this area
[15:23] <Chipaca> mborzecki: there's a change in api which probably had them look at the code and go wtf :-)
[15:25] <mborzecki> Chipaca: https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef0b0c55e66fb8d90f
[15:26] <zyga> Ha
[15:27] <zyga> This answers my question
[15:27] <zyga> The zygote/template thread
[15:27] <zyga> Lack of that would explain what you saw
[15:27] <Chipaca> heh
[15:29] <mborzecki> Chipaca: le's avoid contention then
[15:30] <Chipaca> //go:nocontention
[15:31] <Chipaca> mborzecki: having a mutex held around the lockosthread?
[15:31] <Chipaca> that seems to do the trick
[15:38] <Chipaca> did I just kill the mborzecki
[15:39] <zyga> - Download snap "test-snapd-openvswitch-support" (11) from channel "stable" (received an unexpected http response code (503) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/Pe3FPk3JcUeEuBMT3As6sF5V9Yle5MBb_11.snap?t=2018-04-26T19:00:00Z&h=ee1bb7faf045ee33a046739c4f22f2a57fb01198)
[15:39] <zyga> store is wonky again?
[15:42] <Chipaca> zyga: who're you calling wonFIVE OH THREE
[15:42] <roadmr> NO CARRIER
[15:42] <Chipaca> I'm glad I got the tone right :-)
[15:43] <tomwardill> zyga: unfortunately, yes. Recovering (hopefully) now.
[15:44] <zyga> tomwardill: thank you for the note
[15:44] <zyga> anyone wants to take a trivial rename: https://github.com/snapcore/snapd/pull/5105
[15:44] <mup> PR #5105: testutil,cmd: rename test helper of Lstat to OsLstat <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5105>
[15:46] <zyga> mborzecki: reviewed your spread checker
[15:54] <mborzecki> zyga: thanks
[15:59] <mborzecki> Chipaca: huh, tried to cherry-pick some relevant commits, ran into conflicts, cherry-picked more commits, more conflicts
[16:00] <Chipaca> mborzecki: seriously a mutex around the lock-to-thread leaves me unable to reproduce the issue
[16:01] <Chipaca> mborzecki: that's probably good enough :-)
[16:01] <mborzecki> Chipaca: yup
[16:02] <zyga> anyone? :)
[16:02] <zyga> it's just a bunch of renames
[16:03] <Chipaca> zyga: I'm against all renames for ever
[16:03]  * Chipaca probably needs more tea
[16:03] <mborzecki> Chipaca: at least it was fun to look into go runtime
[16:04] <Chipaca> mborzecki: it is :-)
[16:07] <zyga> Chipaca: you were saying?
[16:08] <Chipaca> zyga: delete your account >:(
[16:18] <zyga> pstolowski: replied
[16:18] <zyga> Chipaca: thank you :)
[16:18] <pstolowski> zyga: ty
[16:19] <Chipaca> zyga: :-)
[16:20] <Chipaca> I'm with pstolowski, let's get rid of all sucky stat calls
[16:20] <zyga> s/sucky/portable/
[16:20] <zyga> but yeah
[16:20] <Chipaca> fstatat is where it's atat
[16:20] <zyga> I have some of those done already but nobody will review a 3K branch
[16:20] <pstolowski> niemeyer: naming question wrt your review comment - does AttrMap sounds ok for map[string]interface? or more verbose InterfaceAttributes?
[16:21] <Chipaca> zyga: also, renameat2
[16:21] <zyga> Chipaca: renameat2?
[16:21] <Chipaca> zyga: renameat2.
[16:22] <Chipaca> zyga: like renameat but with flags!
[16:22] <zyga> yeah. I know it exists but are we using it?
[16:22] <Chipaca> zyga: we are not, yet
[16:22] <Chipaca> zyga: we would if we could but we can't so we don't
[16:22] <Chipaca> a wild mvo appears!
[16:22] <zyga> oh
[16:22] <zyga> that's cool
[16:22] <zyga> whiteout
[16:22] <zyga> do you know there's DT_WHT
[16:22] <zyga> but it's not used anywhere in the kernel
[16:22] <mup> PR snapd#5105 closed: testutil,cmd: rename test helper of Lstat to OsLstat <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5105>
[16:22] <pstolowski> he is watching us all the time
[16:22] <zyga> hey, welcome mvo
[16:22] <zyga> :)
[16:24] <Chipaca> zyga: yes, whiteout might be good at some point; noreplace is the one that caught  my eye
[16:25] <zyga> I like the exchange one
[16:25] <zyga> I didn't know that such flags existed
[16:25] <zyga> that's cool, thank you for sharing
[16:25] <zyga> and about lstat
[16:25] <zyga> our sponsor is this PR: https://github.com/snapcore/snapd/pull/5106
[16:25] <mup> PR #5106: testutil: add test helper for SysLstat <Created by zyga> <https://github.com/snapcore/snapd/pull/5106>
[16:25] <zyga> please click to know more :D
[16:25] <roadmr> clickbait
[16:25] <zyga> alleged clickbait
[16:26] <roadmr> does anyone know if I can get snapcraft to show me raw http requests/responses via an env var or something similar?
[16:27] <kyrofa> roadmr, no, debug mode will show you what APIs are being hit, but not raw
[16:29] <niemeyer> pstolowski: Where is that?
[16:30] <niemeyer> pstolowski: The Map suffix sounds unnecessary.. it also reminds me of a few other maps we already have there
[16:30] <pstolowski> niemeyer: this was about passing map[...] to/from getDynamicHookAttributes and setDynamicHookAttributes
[16:30] <Chipaca> var buf syscall.Stat_t
[16:30] <niemeyer> pstolowski: I'm still not sure about what the question is
[16:30] <pstolowski> niemeyer: yes, when we have a name for this map I can apply it in a few other places
[16:30] <Chipaca> I mean, I know it's a buffer way down low, but calling it a buffer when it's a struct is a bit … i dunno
[16:31] <pstolowski> niemeyer: the question is about the name for the type
[16:31] <zyga> Chipaca: can you bike shed on 5104
[16:32] <zyga> mvo suggested something
[16:32] <pstolowski> niemeyer: or maybe I misread your comment
[16:32] <zyga> so if I'm going to tweak wording
[16:32] <zyga> I want to know your opinion too :)
[16:32] <pedronis> pstolowski: I think  it's about naming the return values (not their types)
[16:32] <pedronis> if I remeber the comment
[16:32] <pstolowski> niemeyer: ah, ok, i see
[16:34] <Chipaca> zyga: hold my can of green paint
[16:34] <Chipaca> #5104
[16:34] <mup> PR #5104: overlord,systemd: store snap revision in mount units <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5104>
[16:35] <pedronis> pstolowski: so } (plugAttrs, slotAttrs map[...
[16:35] <pedronis> or something like that
[16:35] <pstolowski> pedronis: yes yes i get that, just misread the intention
[16:35] <pstolowski> thanks
[16:41] <Caelum> zyga: if and when you do the osc command to submit to factory, let me know how it goes, or if you want, just add me to the devel project and I will do it myself, my obs id is rkitover
[16:42] <zyga> Caelum: ah, I missed that I thought you had done it
[16:43] <zyga> let me look
[16:44] <zyga> submitting, just booting my opensuse box
[16:45] <Caelum> awesome
[16:51] <zyga> osc submitrequest system:snappy/snapd devel:languages:go
[16:51] <zyga> created request id 601651
[16:52] <sergiusens> ogra_: skull canyon is Intel
[16:56] <mup> PR snapd#5106 closed: testutil: add test helper for SysLstat <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5106>
[17:00] <zyga> popey: https://twitter.com/sysrich/status/989549287787909120
[17:02] <zyga> Caelum: ^ I think we will have things to do soon :-)
[17:06] <popey> zyga: yay
[17:06] <zyga> Chipaca: thank you for the reviews!
[17:07] <zyga> I just opened #5107 that fixes one of the three bugs pawel found
[17:07] <mup> PR #5107: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Created by zyga> <https://github.com/snapcore/snapd/pull/5107>
[17:07] <zyga> it is now small and simple
[17:07] <zyga> though I didn't use the simple tag :)
[17:07] <mup> PR snapd#5107 opened: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Created by zyga> <https://github.com/snapcore/snapd/pull/5107>
[17:08] <pstolowski> when I thought I found one bug, zyga turned it into three ;)
[17:09] <zyga> pstolowski: with enough eyeballs all bugs are shallow
[17:13] <pstolowski|afk> true that
[17:14] <mup> PR snapd#5104 closed: overlord,systemd: store snap revision in mount units <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5104>
[17:15] <roadmr> kyrofa: hm it may suffice, how do I enable debug mode?
[17:15] <roadmr> (thanks btw!)
[17:15] <kyrofa> roadmr, snapcraft -d <whatever>
[17:16] <roadmr> thanks kyrofa !
[17:18] <roadmr> kyrofa: ah interestingly - debug mode *does* give me a "Store error response:" and gives me a repr of the requests HTTPResponse object, which should contain what I need \o/
[17:18] <kyrofa> roadmr, ah, you just wanted the response? Nice
[17:19] <roadmr> yes, that should suffice for what I need :)
[17:20] <om26er> is there going to be a Ubuntu Core 18 release today as well ?
[17:21] <zyga> om26er: no
[17:21] <zyga> om26er: core18 will still take some time to make
[17:21] <zyga> there's a core18 snap but it's not the final version and it will grow and improve
[17:21] <zyga> and it cannot be used for booting yet
[17:21] <om26er> zyga: thanks!
[17:22] <zyga> Chipaca: I killed the 15.04 references in systemd test
[17:22] <zyga> Chipaca: should I go for it all and make that code consume snap.Info?
[17:23] <mup> PR snapd#5108 opened: systemd: replace ancient paths with 16.04+ standards <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5108>
[17:23] <Caelum> zyga: awesome
[17:29] <zyga> google is having a bad SSL day: 2018-04-26 17:24:45 Cannot allocate google:ubuntu-18.04-64: cannot perform Google request: Get https://www.googleapis.com//compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: net/http: TLS handshake timeout
[17:45] <mborzecki> bad-SSL-day, sounds like something taken straight out of Civilization series ;)
[17:54] <kyrofa> zyga, cannot change profile for the next exec call: No such file or directory
[17:54] <kyrofa> Help
[17:54] <zyga> kyrofa: tell me
[17:55] <kyrofa> zyga, looks like all that has happened recently is a few unrelated snaps automatically refreshed
[17:55] <kyrofa> (not core, either)
[17:56] <kyrofa> Getting this in syslog: Apr 26 10:56:01 Pandora kernel: [22703.874785] audit: type=1400 audit(1524765361.346:118): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 profile="/snap/core/4486/usr/lib/snapd/snap-confine" name="snap.snapcraft-pr.init" pid=26853 comm="snap-confine"
[17:56] <mup> PR #26: Feature/hw assign symlink <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/26>
[17:56] <kyrofa> hw assign, that brings back memories
[17:56] <zyga> kyrofa: can you please check if snap.snapcraft-pr.init apparmor profile is on disk
[17:56] <zyga> I'm just debugging this issue with kissiel as we speak
[17:57] <kyrofa> zyga, no, it seems not
[17:57] <zyga> can you collect snapd logs please
[17:57] <kyrofa> $ ls /var/lib/snapd/apparmor/profiles/*snapcraft-pr*
[17:57] <kyrofa> ls: cannot access '/var/lib/snapd/apparmor/profiles/*snapcraft-pr*': No such file or directory
[17:57] <zyga> from journald
[17:57] <zyga> man
[17:57] <zyga> what is the secret
[17:58] <kyrofa> zyga, https://pastebin.ubuntu.com/p/Xyg4FJxPCr/
[17:59] <kyrofa> Wait no, cut off
[17:59] <zyga> that looks partial
[17:59] <zyga> tip: | to cat
[17:59] <zyga> pipe to cat to turn off "smart" features
[18:00] <kyrofa> https://pastebin.ubuntu.com/p/htqqFMP4Sh/
[18:00] <kyrofa> Indeed, journalctl always bites me with that
[18:00] <zyga> man
[18:01] <zyga> hmm hmm
[18:01] <zyga> can you see that snap in "snap list"
[18:01] <zyga> kyrofa: and can you please pastebin "snap changes"
[18:04] <zyga> Apr 25 15:49:35 Pandora snapd[1892]: 2018/04/25 15:49:35.795290 helpers.go:217: cannot connect plug "network-bind" from snap "core", no such plug
[18:04] <mup> PR #25: use the network-client cap instead of the old, deprecated networking cap <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/25>
[18:04] <zyga> pstolowski|afk: ^ when would we show this message
[18:05] <zyga> when the plug is gone
[18:05] <zyga> it looks like the core snap has lost interfaces
[18:05] <zyga> kyrofa: without rebooting, pease run "snap interfaces"
[18:05] <kyrofa> zyga, https://pastebin.ubuntu.com/p/ZDYSfZ5GmD/
[18:06] <kyrofa> Oh, sorry, doing snap changes now
[18:06] <kyrofa> zyga, https://pastebin.ubuntu.com/p/4MZgmRmm97/
[18:06] <kyrofa> zyga, and yes, snapcraft-pr is in `snap list`
[18:09] <kyrofa> This has happened in the past, I do believe a reboot solves it, but I won't do that until you give me the go-ahead
[18:11] <zyga> thanks
[18:14] <zyga> hmm hmm hmm
[18:14] <zyga> kyrofa: so let me put a timeline
[18:14] <zyga> you booted
[18:14] <zyga> did the snap work then?
[18:14] <zyga> then you refreshed
[18:14] <zyga> and noticed it is broken
[18:14] <zyga> is that accurate?
[18:17] <kyrofa> zyga, unfortunately it's a little more wishy-washy than that. I haven't rebooted for a day or two. I successfully used this snap yesterday, though. It has not been refreshed, but multipass has been, and I installed snapcraft (all yesterday). Other snaps seem to work fine, but I just tried using snapcraft-pr for the first time today, to be greeted by that
[18:18] <zyga> ah, snapcraft-pr is a separate snap
[18:18] <zyga> ok
[18:18] <zyga> hmm hmm
[18:18] <zyga> so
[18:18] <zyga> I have a theory
[18:18] <zyga> let me experiment for a sec
[18:18] <zyga> can you ls -ld /var/lib/snapd/apparmor/profiles
[18:19] <zyga> er
[18:19] <zyga> sans the d
[18:19] <zyga> so just ls -l ...
[18:19] <zyga> if this is it than man
[18:19] <zyga> I have screwed up badly
[18:19] <kyrofa> https://pastebin.ubuntu.com/p/hCcxNXW2WS/
[18:20] <zyga> thanks
[18:20] <zyga> I wanted to see the timestamps mostly
[18:20] <kyrofa> zyga, here is the `snap list` to compare against: https://pastebin.ubuntu.com/p/KspPkqMPqN/
[18:21] <zyga> reproduced
[18:21] <zyga> and I know what this is
[18:21] <zyga> don't reboot yet though
[18:21] <zyga> man
[18:21] <zyga> I'm so so so ashamed of myself
[18:21] <kyrofa> Haha, no problem
[18:22] <zyga> in case I get under a bus
[18:22] <zyga> this is the reason we need .6 https://www.irccloud.com/pastebin/KlGkPfRK/
[18:22] <zyga> Chipaca: ^
[18:22] <zyga> we will do 2.32.6
[18:22] <zyga> please look to see if I got the same conclusion as you will
[18:25]  * zyga curses silently
[18:25] <zyga> it's a one char diff
[18:26]  * zyga hugs kyrofa 
[18:26] <zyga> I owe you and kissiel a beer for helping me find this
[18:28] <zyga> this is not a new bug
[18:28] <zyga> we had it since forever
[18:30] <kyrofa> That would explain why I've hit it a few times, but typically just reboot
[18:30] <kyrofa> zyga, oh no :P
[18:31] <kyrofa> Hahahahahaha, I wondered if it was somehow related to that
[18:31] <zyga> kyrofa: I just look at a patch that breaks it
[18:31] <zyga> b1217a35b077ef67840cc2c6a18f2f7e9d3b3be7
[18:32]  * zyga blames himself 
[18:32] <zyga> sorry everyone
[18:33] <kyrofa> fmt.Sprintf("snap*.%s*", snapName)?
[18:33] <zyga> yes
[18:33] <zyga> snap.%s.*
[18:33] <kyrofa> Yep
[18:33] <zyga> that's what's missing
[18:33] <zyga> I'm reviewing the rest of the code for this
[18:33] <zyga> and adding tests
[18:33] <kyrofa> That's alright man, easy mistake to make
[18:33] <zyga> and adding a commit message
[18:33] <zyga> we have a helper that returns the right tinh
[18:33] <zyga> (that I wrote)
[18:33] <zyga> but I didn't use it
[18:33] <zyga> man
[18:33] <zyga> I suck
[18:34] <zyga> niemeyer: bug fixed
[18:34] <zyga> niemeyer: it's all my fault really, details in a PR soon
[18:35] <kyrofa> zyga, I assume I'm okay to reboot now?
[18:36] <kyrofa> Or, just reinstall it really
[18:45] <zyga> kyrofa: yes
[18:45] <zyga> but this won't fix it
[18:45] <zyga> enable/disable
[18:45] <zyga> but really
[18:45] <zyga> man
[18:45] <zyga> I'll have a fix shortly
[18:46] <kyrofa> Yep, disable/enable worked
[18:46] <kyrofa> I also just removed snapcraft. How dare it share my snap's name
[18:46] <kyrofa> Even a portion
[18:47] <Chipaca> kyrofa: snapcraft-pr, it's snapcraft but paginated
[18:47] <kyrofa> Hahaha
[18:48] <kyrofa> Better logging, of course
[18:48]  * Chipaca wonders how many people actually use 'pr' these days
[18:50]  * Chipaca is off to play stellaris for a while
[18:51] <Pharaoh_Atem> zyga: you did the wrong thing here: https://build.opensuse.org/request/show/601651
[19:06] <pedronis> zyga: https://github.com/snapcore/snapd/pull/4590#discussion_r166224513
[19:06] <mup> PR #4590: many: allow constructing layouts (phase 1) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4590>
[19:08] <pedronis> there seem to have also been a rebase there, so it's very hard to tell the story of how it was reviewed
[19:10] <zyga> pedronis: that was subsequently removed
[19:10] <zyga> and re-introduced with another PR
[19:10] <zyga> but still, we missed that part in all the cases
[19:11] <zyga> I took a break to setup a customer device but now I'm back to fixing this
[19:11] <zyga> Pharaoh_Atem: yeah I got some feedback on twitter as well
[19:11] <zyga> Pharaoh_Atem: I will resume this as soon as I fix this issue that kyrofa and kissiel helped me fijnd
[19:11] <zyga> find*
[19:18] <pedronis> zyga: I see, anyway not sure anyone is particularly to blame, all those PRs seems to have had the needed reviews, globs are dangerous, all of use need to keep it in mind
[19:19] <zyga> yeah, I just feel bad about it
[19:19] <zyga> finishing tests now
[19:19] <zyga> I will review all backends next
[19:19] <zyga> I let mvo know in case we do a .6 tonight
[19:26] <pedronis> I see two glob1 in apparmor/backend.go
[19:26] <zyga> yes, one for setup and one for remove
[19:26] <zyga> I added a function and removed them both so that there's less places for this issue to re-surface
[19:28] <pedronis> there's a lot of globbing of course going on all over interaces
[19:29] <sergiusens> zyga, kyrofa: that seems to be the root of the corebird issue
[19:29] <zyga> yes
[19:30] <pedronis> is this right:    glob := fmt.Sprintf("snap.%s.*fstab", snapName)  ?    I would expected a dot before fstab.   or there's a case where * matches "" there
[19:30] <pedronis> it's in mount/backend.go
[19:30] <zyga> I think so
[19:30] <zyga> it's not obvious
[19:30] <zyga> let me see if there's a comment for this
[19:30] <diddledan> if you're after literal dots and it's a regex, you need to escape them
[19:31] <zyga> diddledan: it's a glob
[19:31] <kyrofa> diddledan, it's globbing
[19:31] <diddledan> ok
[19:31] <zyga> pedronis: we used to have a per-app mount profiles
[19:31] <pedronis> they are globs, we are mostly looking for missing dots or spurious *
[19:31]  * diddledan goes back to sleep
[19:31] <zyga> pedronis: if you add that dot there it becomes:
[19:31] <zyga> ... value *errors.errorString = &errors.errorString{s:"cannot synchronize mount configuration files for snap \"snap-name\": internal error: EnsureDirState got filename \"snap.snap-name.fstab\" which doesn't match the glob pattern \"snap.snap-name.*.fstab\""} ("cannot synchronize mount configuration files for snap \"snap-name\": internal error: EnsureDirState got filename \"snap.snap-name.fstab\" which doesn't match the glob
[19:31] <zyga> pattern \"snap.snap-name.*.fstab\"")
[19:32] <zyga> in reality it's a single file now so we could drop the *
[19:32] <zyga> but having the glob helps if you update from ancient snapd
[19:32] <zyga> where we still had the per-app profiles
[19:32] <zyga> with an epoch we could drop the *
[19:32] <pedronis> as I said I wasn't sure, just wondered
[19:32] <pedronis> it might merit a comment though
[19:32] <zyga> yes, totally
[19:32] <zyga> I will add it
[19:44] <zyga> pedronis, Chipaca: https://github.com/snapcore/snapd/pull/5109
[19:44] <mup> PR #5109: interfaces/apparmor: fix incorrect apparmor profile glob <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/5109>
[19:44] <mup> PR snapd#5109 opened: interfaces/apparmor: fix incorrect apparmor profile glob <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/5109>
[19:45] <mup> PR snapd#5110 opened: interfaces/apparmor: fix incorrect apparmor profile glob (2.32) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/5110>
[19:47] <zyga> niemeyer: ^ FYI
[19:47] <zyga> that's that thing
[19:48] <zyga> kyrofa: I will let you know when edge is fixed
[19:48] <zyga> or where we have a beta release that has this
[19:48] <zyga> sergiusens: ^
[19:48] <kyrofa> Thanks zyga
[19:49] <mup> PR snapd#5074 closed: many: allow mimics in parents of layout <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5074>
[19:50] <sergiusens> thatnks
[20:03] <mup> PR snapd#5108 closed: systemd: replace ancient paths with 16.04+ standards <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5108>
[20:05] <mup> PR snapcraft#2108 opened: HACKING: suggest snapcraft-pr for evaluating PRs <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2108>
[20:05] <zyga> kyrofa: maybe wait until this is fixed
[20:06] <zyga> kyrofa: ;-)
[20:09] <kyrofa> zyga, hahaha
[20:13] <zyga> cachio: did we remove our linode images now?
[20:14] <zyga> a 2.32-based PR seems to have issue allocating certain systems
[20:14] <cachio> zyga, linode images are still there
[20:14] <zyga> ah, thanks I will retry
[20:15] <cachio> I was using them to run sru
[20:16] <zyga> FYI, I'm seeing some issues with governor sync
[20:16] <zyga> quiet: govendor sync
[20:16] <zyga> quiet: exit status 2. Output follows:
[20:16] <zyga> Error: Remotes failed for:
[20:16] <zyga> 	Failed for "golang.org/x/crypto/cast5" (failed to ping remote repo): unrecognized import path "golang.org/x/crypto/cast5"
[20:17] <cachio> zyga, it is on linode?
[20:17] <cachio> or google ?
[20:19] <zyga> this was on google
[20:19] <zyga> I restarted it
[20:19] <zyga> let's see what happens
[20:26] <Chipaca> zyga: +1ish
[20:27] <Chipaca> man! /apps/!
[20:29] <zyga> Chipaca: replied,
[20:29] <zyga> I can do a quick follow-up here too
[20:29] <zyga> I don't mind
[20:30] <zyga> (too = in that PR)
[20:30] <Chipaca> zyga: pedronis: ah, if it's just used like that, []string is the right thing
[20:30] <zyga> yes, just like that
[20:36] <pedronis> zyga: any reason btw why the code is not using the old code with SecurityTag helper?
[20:37] <zyga> I was looking at that myself, it used to
[20:37] <zyga> because snap-update-ns doesn't have a corresponding function
[20:37] <pedronis> that's ok
[20:37] <zyga> I wanted to move this down to individual backends
[20:37] <pedronis> it doesn't need a real glob either
[20:37] <zyga> now that dbus is the only remaining user of that function
[20:37] <pedronis> I'm just noticing that there is duplication
[20:38] <pedronis> there's another place that computes "snap-update-ns.%s" at least
[20:38] <zyga> oh, where?
[20:38] <pedronis> addUpdateNSProfile
[20:41] <pedronis> I'm nit picking here, but the old code was doing  interfaces.SecurityTagGlob(snapName)
[20:41] <zyga> yeah, I know, that's what I meant above
[20:41] <pedronis> it seems the new code should do []string{interfaces.SecurityTagGlob(snapName), nsProfileName(snapName)}
[20:42] <zyga> hmm
[20:42] <zyga> that's nice
[20:42] <zyga> I'll do that
[20:42] <pedronis> they can still be inside a profileGlobs helper
[20:42] <pedronis> it helps having a precise test
[20:44] <pedronis> and then nsProfileName (or what we want to call it) can also be used in addUpdateNSProfile
[20:44] <zyga> yep, exactly, doing that now
[20:47] <zyga> pedronis: can you review https://github.com/snapcore/snapd/pull/5092
[20:47] <mup> PR #5092: snap: do not use overly short timeout in `snap {start,stop,restart}` <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5092>
[20:47] <zyga> mvo wants to pull that into .6
[20:47] <zyga> he just told me that on telegram
[20:50] <zyga> pedronis, Chipaca: 5109 updated as discussed
[20:51] <zyga> if you give me a +1 I'll squash this to make 2.32 back port easier
[20:53]  * zyga is hungry a little
[20:54] <pedronis> I have reviewed both
[20:54] <pedronis> would be good though if mvo or Chipaca also looked at 5109 again
[20:55] <Chipaca> 's good, +1 stands
[20:57] <pedronis> I wonder what else is on 2.32 since .5
[20:57] <zyga> pedronis: I asked mvo
[20:58] <pedronis> just test changes and the follow up to the stop-mode stuff afaict
[20:58] <zyga> pedronis: he said that those two PRs should be enough as nothing else stands as critical
[21:00] <zyga> mvo just said that he will review the rest but it will be likely just the two fixes (stop and this one)
[21:00] <pedronis> did you rebase 5109?  instead of letting github squash merge?
[21:00] <zyga> yes, to cherry pick it into 2.32
[21:00] <pedronis> mmh
[21:00] <zyga> they are now with the same patch
[21:00] <pedronis> this kills the history in it
[21:01] <zyga> I can undo that
[21:01] <zyga> I have the history locally still
[21:01] <zyga> I can leave 2.32 as is
[21:01] <zyga> and restore history for master
[21:01] <pedronis> I usually squash merge and then do the cherry pick
[21:01] <zyga> WDYT?
[21:02] <zyga> I opened both before I had the feedback, I worry that we may have issues with tests in 2.32
[21:02] <zyga> (like last time)
[21:06] <pedronis> it's more of a general comment,  rebasing before commiting leave a bit of confusing history in the PRs
[21:06] <pedronis> I don't want to force anything either way atm,  the most important thing is to fix stuff vs risk breakage
[21:07] <zyga> ack, understood
[21:07] <zyga> let's rest and regroup tomorrow
[21:07] <zyga> Thank you guys!
[21:33] <om26er> who maintains docker snap, apparently its outdated .
[21:33] <om26er> that was supposed to be a pretty important snap IMO.
[21:40] <zyga> om26er: AFAIK it is docker itself
[22:05] <mup> PR snapd#5109 closed: interfaces/apparmor: fix incorrect apparmor profile glob <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5109>