[00:02] PR snapcraft#2106 closed: nodejs plugin: lazy load the required tarballs === chihchun is now known as chihchun_afk [01:51] PR snapcraft#2100 closed: build_providers: new build provider using multipass [02:09] PR snapcraft#2107 opened: Release changelog for 2.42 === AndyWojo_ is now known as AndyWojo === joc__ is now known as joc === akash_ is now known as akash === Ursinha_ is now known as Ursinha === seyeongkim_ is now known as seyeongkim === sergiusens_ is now known as sergiusens === jamespage_ is now known as jamespage [02:31] diddledan: if you can add notes to the PR and confirm it working it would be great [02:34] PR snapd#5102 opened: tests: new utility to save and restore the snap state === essembe is now known as sbeattie === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:12] good morning [05:12] zyga: hey [05:33] mborzecki: I sent a few extra trivial PRs [05:33] mborzecki: could you please look at them, they have a few lines to a few dozen at most [05:57] PR snapd#5101 closed: testutil: don't dot-import check.v1 [06:10] Thanks! === chihchun_afk is now known as chihchun [06:12] I feel great today, hopefully this will be a good day for coding :-) [06:15] PR snapd#5099 closed: testutil: rename UNMOUNT_NOFOLLOW to umountNoFollow [06:19] the tests are shellcheck clean now [06:20] 249 files changed, 1338 insertions(+), 797 deletions(-) [06:20] PR snapd#5086 closed: osutil,interfaces,cmd: use fewer hardcoded strings [06:20] Wooooot [06:20] Send the patches! [06:21] 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] Ok [06:23] Use things that qualify for simple :-) [06:25] ok, i need to go out for 2-3h now, will be back ~11 [06:48] Ok [06:53] /join #ubuntu-release-party [06:53] oops [07:06] Oh [07:07] PR snapd#5100 closed: testutil: document all fake syscall/os functions === pstolowski|afk is now known as pstolowski [07:09] mornings [07:19] Hey [08:08] zyga: I think I addressed your concerns with #4983 [08:08] PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json [08:10] looking [08:26] Chipaca: done [08:27] Chipaca: do you want to look at https://github.com/snapcore/snapd/pull/5081 [08:27] PR #5081: interfaces/apparmor: add chopTree [08:27] I could use it to propose the fix for the 1st layout issue [08:28] looking [08:31] zyga: ok, question time [08:31] I'm all ears [08:31] zyga: in /foo/bar/froz with depth 2 [08:31] zyga: see the doctor about that [08:31] zyga: why is 'right' /foo/bar/{*,*/,froz} rw ? [08:31] why even have froz there if you have *? [08:32] that's just simplicity, yes, we could special case that last part [08:32] since froz is covered by * and froz/ (if it was a directory) would be covered by */ [08:32] zyga: ok, how about, in /foo/bar/baz/froz with depth 2 [08:32] ok [08:33] zyga: would right be /foo/bar/{*,*/,baz/froz} rw ? [08:33] no [08:33] it would be, /foo/bar/{*,*,baz/{*,*/,froz} [08:33] (the rw, part is separate so I will omit it) [08:33] ah., I missed } above :) [08:33] it would be, /foo/bar/{*,*,baz/{*,*/,froz}} [08:34] it would be, /foo/bar/{*,*/,baz/{*,*/,froz}} [08:34] zyga: I definitely don't understand then [08:34] sorry, this one should be it :-D [08:34] it seems the right-hand thing could always be omitted [08:34] omitted how? [08:35] zyga: I don't remember if */ implies */* and */*/ [08:35] * is any file, */ is any directory [08:35] zyga: but even if it doesn't, it seems just using *s always covers the explicit case [08:35] ** implies any file and directory recursively forever [08:36] zyga: i.e. /foo/bar/{*,*/,*/{*,*/}} [08:36] what does adding the explicit names give you, that this doesn't? [08:37] it hands out different permissions [08:37] note that this allows you to make /foo/bar/ [08:37] expand the version as implemented [08:37] and the one with */,* [08:37] zyga: so it's any file or directory along this path but not parallel to it [08:38] 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] ? [08:39] you can do /foo/bar/ yes [08:39] it's an abbreviation of multi-line variant of that [08:39] I wanted to avoid ** [08:39] which is like _anything_ flies [08:40] zyga: what's the use case for it? when do you want to allow this and just this? [08:40] for writable mimics specifically [08:40] zyga: also p.s. 'cnt' as a variable name reads wrong (just noticed) :-) [08:40] count :) [08:40] ok [08:41] maybe i've just got a dirty mind :-) [08:41] https://github.com/snapcore/snapd/pull/5074/commits/eb6d997ab607ecee966de5deffb87a83684e6fe3 [08:41] PR #5074: many: allow mimics in parents of layout [08:41] Chipaca: I will change it [08:41] Chipaca: this is the consumer of that patch [08:41] (probably needs small rebase) [08:42] look at the writableMimicProfile there [08:42] Chipaca: look at the test diff below [08:42] it replaces a list of rules [08:43] with one rule that expands to that and then some [08:44] zyga: I still don't get why you need * if you already know the name [08:44] because it may be at any earlier stage [08:44] if we want to make a layout at /usr/share/magic/software [08:45] but magic isn't in the core snap [08:45] we need to construct a mimic at /usr/share [08:45] and this rule grants that [08:45] also let's say magic exists but software doesnt [08:45] then we need to make one at /usr/share/magic [08:45] this is a generalised way to make those [08:46] but that would mean something like /usr/share/{,magic/{,software}} [08:46] yes [08:46] but then you realise what is needed to make a mimic [08:46] you need to mount tmpfs on /usr/share [08:46] then make *any file or directory there* [08:46] and bind mount the originals back [08:46] so you need the * and */ rules [08:46] see? [08:46] zyga: yes [08:47] zyga: thanks [09:01] zyga: mostly +1, holding off the actual +1 because I think it needs more tests [09:01] zyga: should be easy to add them though :-) [09:01] ack, looking [09:01] Thank you for looking, this is tricky stuff :) [09:02] 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] zyga: I got a report about a "apparmor="DENIED" operation="change_onexec" [09:46] 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] "cannot [09:46] change profile for the next exec call: No such file or directory" [09:46] yes [09:46] that or pre run-waits fix [09:48] mvo: what more do you know? [09:48] did you experience that/ [09:54] re === mborzeck1 is now known as mborzecki [09:54] that took longer than i anticipated [09:54] zyga: I forwarded you a mail with all the info I have [09:54] checking [09:54] zyga: thank you! [10:04] popey: hey! android-studio has 3400+ installs (and ever growing), impressive ? [10:04] wow [10:04] thats great! [10:05] * ogra_` is surprised that mjpeg-streamer ha over 1000 already ... [10:05] *has [10:05] popey: how is sublime doing ? [10:05] We found that if we put an application in the featured list, it *always* jumps in userbase [10:06] om26er: over 4k! [10:06] i wouldnt have thought such a trivial tool can be so popular [10:06] sergiusens: re 1764998> is corebird a sideloaded snap? [10:06] wow! [10:07] for a tool like Android Studio that 3400+ is an impressive count, give that a few months and it'll surpass 10k [10:07] mvo: no, if you have the bug report I believe I added snap info for corebird, I still see the issue btw [10:08] sergiusens: always with the same snap? [10:08] sergiusens: or is thta random? [10:08] mvo: just that one [10:09] sergiusens: and do you see any pattern? Like profiles vanish after auto-refresh ? or after boot? or anything? [10:11] mvo: certainly after reboot, not consistent [10:12] 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] I also only see it on that snap [10:13] mvo: this snap is feature packed with interfaces (including `content`) [10:14] tomwardill, sergiusens thanks! that is useful information [10:15] zyga: ^-- looks like a certain property of the snap makes it vanish [10:16] hmm [10:22] 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] sergiusens, bah ... whats that ? https://paste.ubuntu.com/p/zWP3m9ktMx/ [10:28] (the part is plainly using the make plugin, caring for the cross stuf on its own) [10:28] is there a way to override that ? [10:36] sergiusens: can you install this unit on your sytem [10:36] lp-1764998.service https://www.irccloud.com/pastebin/GU7D0QRT/ [10:36] in case it happens again [10:37] mvo: ^ [10:37] zyga: nice! [10:37] journald contains the output so we can inspect it later [10:38] ogra_`: create snap/plugins/x_make.py [10:40] sergiusens, thanks ... found another solution (using the deb :P ... ) [11:03] Chipaca: I think https://github.com/snapcore/snapd/pull/5081 is ready for another look [11:03] PR #5081: interfaces/apparmor: add chopTree [11:09] hmmm [11:09] I _may_ have theory [11:14] zyga: +1, although I note you didn't add tests for wonky depths :-) [11:15] Chipaca: because it's already there :) [11:15] well [11:15] not for negative depths [11:15] that's a good idea [11:15] https://github.com/snapcore/snapd/pull/5081/files#diff-16cc40a4b635e1e0e4c9d520342fd500R295 is deeper then than the number of directories [11:15] PR #5081: interfaces/apparmor: add chopTree [11:15] but yeah [11:15] ah, the 4 is bigger [11:15] k [11:16] orders a beer, orders a "", orders 252341342352 [11:16] :-) [11:16] I'll do it [11:16] quite [11:16] pstolowski: reviewed the Undesired field branch [11:16] pretty much [11:16] pstolowski: let's talk in 10 minutes [11:16] I have an idea I want to run by you [11:16] zyga: thanks, sure [11:31] zyga: interesting remark about possibly dropping auto flag. hmm [11:31] pstolowski: as I wrote below, not just the auto flag, all but the Undesired flag should be dropped [11:31] (perhaps the interface type should remain as well but it is unclear what to do when it changes under us) [11:51] PR snapd#5103 opened: tests: shellcheck spread tasks [11:51] basic setup for shellchecking spread files ^^ [11:56] mborzecki: hah. I'd added it to spread, your approach seems a lot more polite [11:58] Chipaca: well, we could do it now ;) i have all the fixes [11:59] jokes aside, shellcheck is terribly annoying with some of the warnings [11:59] +1 [11:59] totally overzealous at times [12:03] ogra_`: aren't we all [12:03] i pretend not to ... (but i'm really bad at that) === chihchun is now known as chihchun_afk [12:06] ogra_`: https://www.youtube.com/watch?v=mLRjFWDGs1g&t=16s [12:06] hahahaha [12:07] now i want a moustache ! === ogra_` is now known as ogra_ [12:24] 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] PR #4358: interfaces: interface hooks implementation [12:24] pstolowski: Yeah, on it [12:24] thanks [12:26] pstolowski: But the PR hasn't changed at all yet? [12:31] pstolowski? [12:31] niemeyer: it did, it's just this one aspect that I haven't changed, all other points addressed and pushed [12:32] pstolowski: That's not what I see in the actual PR [12:35] * kalikiana lunch [12:36] niemeyer: https://github.com/snapcore/snapd/pull/4358/commits/804c1b3f38463da4892d56fc181d03945c36b94e is addresseing all your comments from last review [12:36] PR #4358: interfaces: interface hooks implementation [12:37] pstolowski: I'm literally looking at https://github.com/snapcore/snapd/pull/4358/files [12:37] pstolowski: I can see both the code and the comment in the actual PR [12:39] 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] niemeyer: ah, you're right, looks like the Conversation summary didn't show them and I missed those... sorry about that [12:40] niemeyer: so I missed some of your comments re formatting, will fix in a few moments [12:40] ah, I was confused too [12:40] pstolowski: there's "load more" thing in the middle of the comment lists [12:41] pedronis: hah, indeed [12:41] totally unexpected [12:41] it's a recent change [12:42] :) [12:42] (also github is kind of slow for me recently) [12:42] yes for me too.. i just had to restart my browser as github slowed it down to a halt [12:43] i need to run to school, bb for standup [12:43] PR snapd#5104 opened: overlord,systemd: store snap revision in mount units [12:43] pedronis: Ack, sounds fine then [12:43] pstolowski: ^ [12:58] PR snapd#5038 closed: data/systemd: helper service for waking up the main snapd service [12:59] PR snapd#4399 closed: rewrite snappy-app-dev [13:00] PR snapd#5105 opened: testutil,cmd: rename test helper of Lstat to OsLstat === chihchun_afk is now known as chihchun [13:13] nice, new snapcraft store lookanfeel [13:15] PR snapd#5106 opened: testutil: add test helper for SysLstat [13:31] re [13:33] jdstrand, updated the apparmor/vlc/link bug with an info from ubuntu 16.04 - same thing is happening there it seems :O [13:34] thresh: that's weird... jjohansen is watching the bug. thanks for the feedback! [13:35] :) [13:39] thresh: can you pass the URL please [13:40] zyga, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1766628 there you go [13:40] Bug #1766628: apparmor denies VLC to open files in devmode [13:40] it's quite hectic because I suck at bug reporting === pstolowski is now known as pstolowski|lunch [13:49] Chipaca: 1.9 breaks with your uid sample right? [13:50] mborzecki: yes [13:51] mborzecki: if you hit a 'too many threads', reduce N to see the bug [13:51] (also, get a slower cpu) [13:51] (or was it a faster one) [13:53] hmm broke very quickly ;) [13:53] Chipaca: what do you think about https://github.com/snapcore/snapd/pull/5104 [13:53] PR #5104: overlord,systemd: store snap revision in mount units [13:54] zyga: i'll look at it when i get back from the school run [13:54] Thank you sir! [13:54] should I file snapcraft bug at github or launchpad? [13:54] launchpad please [13:54] mborzecki: if it looks like a stack trace, it's not my bug [13:54] allright [13:54] mborzecki: mine is {something in brackets} [13:54] mborzecki: main.Result{uidBefore:12345, uidDuring:12345, uidAfter:12345} [13:55] * Chipaca runs [13:55] Chipaca: yup, that's what I see, just made it a panic so it doesn't spam my terminal too much :) [13:55] mborzecki: with all those goroutines it should be less spammy than a panic [13:55] but, you do you [13:56] * Chipaca really runs [14:03] 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] Chipaca: this looks really awkward https://paste.ubuntu.com/p/4q2wz2w739/ [14:22] mborzecki: who clones new threads when all threads are busy? [14:22] which process does that [14:22] is there a zygote in go? [14:23] runtime does that, whenever all threads are blocked and you have runnable goroutine [14:23] yeah but who is the parent [14:23] it is relevant === pstolowski|lunch is now known as pstolowski [14:36] * cachio lunch === chihchun is now known as chihchun_afk [14:45] GOMAXPROCS=1 makes it go away [14:49] mborzecki: "let's all write in C" ;-) [14:49] * zyga -> break [14:50] it rains like crazy so no walk for me [14:50] but I can cook now :) [14:51] race detector not very helpful, too many goroutines [15:12] mborzecki: for extra fun, pass uid [15:13] mborzecki: ie for uid:=1; uid<100000; uid ++ { go f(uid, ch) } [15:15] 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] Chipaca: does that make any sense? [15:17] mborzecki: if locked threads are still candidates for cloning yes [15:20] mvo zyga btw, it is observable in lxd, the next exec call thing https://bugs.launchpad.net/snapcraft/+bug/1760514 [15:20] Bug #1760514: cannot change profile for the next exec call: No such file or directory [15:20] Chipaca: https://github.com/golang/go/blob/master/src/runtime/proc.go#L1835 so they check if a thread is locked [15:20] (at least in 1.10) [15:21] Ack, i am eating lunch now but I will check soon [15:21] Chipaca: but not in 1.9? https://github.com/golang/go/blob/release-branch.go1.9/src/runtime/proc.go [15:22] mborzecki: yeah, 1.10 saw work in this area [15:23] mborzecki: there's a change in api which probably had them look at the code and go wtf :-) [15:25] Chipaca: https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef0b0c55e66fb8d90f [15:26] Ha [15:27] This answers my question [15:27] The zygote/template thread [15:27] Lack of that would explain what you saw [15:27] heh [15:29] Chipaca: le's avoid contention then [15:30] //go:nocontention [15:31] mborzecki: having a mutex held around the lockosthread? [15:31] that seems to do the trick [15:38] did I just kill the mborzecki [15:39] - 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] store is wonky again? [15:42] zyga: who're you calling wonFIVE OH THREE [15:42] NO CARRIER [15:42] I'm glad I got the tone right :-) [15:43] zyga: unfortunately, yes. Recovering (hopefully) now. [15:44] tomwardill: thank you for the note [15:44] anyone wants to take a trivial rename: https://github.com/snapcore/snapd/pull/5105 [15:44] PR #5105: testutil,cmd: rename test helper of Lstat to OsLstat [15:46] mborzecki: reviewed your spread checker [15:54] zyga: thanks [15:59] Chipaca: huh, tried to cherry-pick some relevant commits, ran into conflicts, cherry-picked more commits, more conflicts [16:00] mborzecki: seriously a mutex around the lock-to-thread leaves me unable to reproduce the issue [16:01] mborzecki: that's probably good enough :-) [16:01] Chipaca: yup [16:02] anyone? :) [16:02] it's just a bunch of renames [16:03] zyga: I'm against all renames for ever [16:03] * Chipaca probably needs more tea [16:03] Chipaca: at least it was fun to look into go runtime [16:04] mborzecki: it is :-) === zyga is now known as zyga-what-were-y === zyga-what-were-y is now known as zyga-renamed === zyga-renamed is now known as zyga [16:07] Chipaca: you were saying? [16:08] zyga: delete your account >:( [16:18] pstolowski: replied [16:18] Chipaca: thank you :) [16:18] zyga: ty [16:19] zyga: :-) [16:20] I'm with pstolowski, let's get rid of all sucky stat calls [16:20] s/sucky/portable/ [16:20] but yeah [16:20] fstatat is where it's atat [16:20] I have some of those done already but nobody will review a 3K branch [16:20] niemeyer: naming question wrt your review comment - does AttrMap sounds ok for map[string]interface? or more verbose InterfaceAttributes? [16:21] zyga: also, renameat2 [16:21]