=== chihchun_afk is now known as chihchun [05:58] morning [06:03] hi [06:03] mborzecki: man, I need more sleep [06:03] zyga-ubuntu: hey [06:03] seen the snow outside? [06:04] yes [06:04] my kids are happy [06:04] my wife is not, the car is all covered with snow [06:05] haha, same here :) [06:06] i see Chipaca fixed #4291 [06:06] man [06:06] PR #4291: osutil/sys: reimplement getuid and chown with the right int type [06:06] our logs are too long [06:14] i'm slightly confused, there's 'syscall' package and 'golang.org/x/sys/unix', looks like 'syscall' is covered by go's stable api promise but x/sys/unix is not, so any fixing if 'syscall' actually happens in x/sys/unix [06:14] s/if 'syscall'/of 'syscall'/ [06:18] mborzecki: and x/sys/unix is not ported to all arches [06:18] mborzecki: anyway, I'm happy with https://github.com/snapcore/snapd/pull/4324 [06:18] PR #4324: cmd/snap-confine: discard stale mount namespaces [06:18] needs small rework but it is worth it [06:20] let me have a quick look [06:23] mborzecki: if you have backlog from yesterday midnight it's sensible to look [06:23] well, 22:04 -> 23 [06:30] small coffee [06:43] zyga-ubuntu, thats called espresso [06:46] ogra_: no, I wasn't honest [06:46] after my wife made me de-snow the car in flip flops [06:46] I want a 1L jug of tea [06:47] and a bit coffee with lots of warm water [06:47] maaan [06:47] it's winter :D [06:47] mborzecki: how would you feel about migrating away from indent onto clang-format? [06:47] dont tell me ... i have a broken ankle and have to fly home in flip/flops on sat. [06:48] not yet sure how i'll manage to get from frankfurt to kassel without proper shoes then [06:48] zyga-ubuntu: sounds good to me, have you checked if 14.04 (or do we need it there for the unit tests?) [06:48] clearly I have not had a morning coffee yet [06:49] mborzecki: I'll check everything in detail, I only saw it failed on core (where it reboots so there's no need for this) [06:49] looking at 14.04 log again [06:49] though [06:49] zyga-ubuntu: uncrustify if a simpler alternative though [06:49] I'll have to rewrite this a bit after yesterday's discussion [06:50] but first [06:50] shower and tea [06:50] ogra_: uh, did you break it during the sprint? sorry to hear that, get well! [06:51] mvo, yeah, directly on monday evening ... only a micro fracture but really annoying when you cant walk around the city a lot in the evenings [06:51] ogra_: :( [06:51] ogra_: indeed. get well! [06:51] ogra_: you need more structural integrity ;_) [06:51] OTOH i had an exciting day at the taipei hospital [06:51] (sorry, bad humor in the morning perhaps) [06:52] quite an experience ... [06:52] mvo: https://github.com/snapcore/snapd/pull/4324 [06:52] PR #4324: cmd/snap-confine: discard stale mount namespaces [06:52] ogra_: heh, at least you got a good story out of it [06:52] zyga-ubuntu, tsk ... thats exactly the same my GF said ! [06:52] zyga-ubuntu: yeah, I saw it [06:53] mvo: will need a small change (more forking to avoid kernel bugs) [06:53] mvo, yeah, and i could see some of the city by daylight even ... which i normally dont during a sprint :) [06:53] haha, so truuuueeee [06:54] ogra_: so "break a leg" will now mean "enjoy the sprint outside of the office"? :D [06:54] yeah ! [06:58] mborzecki: you triggered a build 2h ago? man, you are up early :) [07:00] PR snapd#4319 closed: tests: add support for autopkgtests on s390x [07:06] PR snapd#4326 opened: interfaces/builtin: blacklist zigbee dongle [07:10] re [07:42] mvo, if i want to add a new config option to core now, where do i do it ? still in the core snap source or somewhere hidden in snapd ? [07:44] ogra_: its now in snapd, one sec [07:44] ogra_: https://github.com/snapcore/snapd/tree/master/corecfg [07:44] configstate/configcore/ ? [07:45] ah [07:45] ogra_: yeah, that is the final one [07:45] ogra_: but the PR is iirc not quite merged [07:45] ogra_: I was about to point you to the PR :) what option do you need? [07:45] mvo, https://forum.snapcraft.io/t/disabling-the-assertion-auto-import-job-on-core-should-be-possible/2923 [07:46] (for a customer, not super urgent but soon it will be, so i wanted to check how it works now) [07:47] hmm [07:47] the question is if the service managing works on things in multi-user-target too ... [07:47] * zyga-ubuntu runs tests and hopes for the best [07:47] * ogra_ wonders if systemd is clever enough [07:54] mvo, hmm, i see Disable in https://github.com/snapcore/snapd/blob/master/systemd/systemd.go but i dont see mask used anywhere, didnt we switch to mask because of writable transitions ? [07:54] (to force linking to /dev/null) [07:54] mvo: offtopic, did you consider changing the display on your x250? [07:54] ogra_: oh, that is possible that this got lost during the transition, that is a must-fix, let me double check [07:55] grepping for "ask" doesnt reveal anything in https://github.com/snapcore/snapd/blob/master/systemd/systemd.go or https://github.com/snapcore/snapd/blob/master/corecfg/services.go [07:55] so i think it got lost [07:55] zyga-ubuntu: I have not considered that just yet, is it worth it? [07:55] mvo: I'm lookin at it and I think it is [07:55] mvo: I have a slightly broken panel [07:55] mvo: and considering swapping it for a new one [07:56] mvo: the HD TN panel is half the price [07:56] ogra_: do you remember the original PR? [07:56] but it really looks like crap when compared side-by-side [07:56] zyga-ubuntu: heh, yeah, I think I would go for the best available one [07:56] mvo, https://github.com/snapcore/core/pull/61 [07:56] PR core#61: Also "mask" services when disabling them [07:56] zyga-ubuntu: given that its a lot of your time that you need to invest into fixing it [07:56] ogra_: nice, thank you! [07:56] mvo: well, it's open already :D [07:57] zyga-ubuntu: heh [07:57] mvo: I sent you three photos [07:57] the 2nd laptop is a music box while I wait for parts :) [07:57] the viewing angles on that TN panel are horrid [07:58] tn? [07:58] mborzecki: x240 with TN panel vs x250 with IPS [07:58] iirc x250 had full hd ips panels too [07:58] zyga-ubuntu: heh [07:58] the current TN panel is broken a little and I'm just considering which to replace [07:58] ogra_: thanks for the link, I will add code to corecfg today to fix this. good catch! [07:59] mvo, hmm, but mask for snapd.autoimport.service just creates a /dev/null symlink in /etc/systemd/system ... /etc/systemd/system/multi-user.target.wants/snapd.autoimport.service still exists and points to the old target [08:00] so that might be a bit trickier than just calling mask/stop/etc ... [08:00] (fingers crossed guys:) [08:00] :/ [08:00] zyga-ubuntu: http://allegro.pl/matryca-lenovo-x240-x250-1920x1080-fhd-ips-04x3922-i7010276242.html ? [08:01] mborzecki: right, I was looking at ebay but the prices there are similar [08:02] mborzecki: I was a bit tempted to see if there is a FHD + touch model [08:02] mborzecki: but I didn't check if the motherboard for non-touch model accepts that [08:02] mborzecki: since this laptop is for my mother, she could probably use touch as extra-intuitive input method [08:02] mborzecki: though she will mainy use it for writing books [08:03] hmm, but it seems systemctl is clever enough here ... [08:03] ogra@pi3:~$ sudo systemctl list-unit-files|grep autoimport [08:03] snapd.autoimport.service enabled [08:03] ogra@pi3:~$ sudo systemctl mask snapd.autoimport.service [08:03] Created symlink from /etc/systemd/system/snapd.autoimport.service to /dev/null. [08:03] ogra@pi3:~$ sudo systemctl list-unit-files|grep autoimport [08:03] snapd.autoimport.service masked [08:04] .... even though /etc/systemd/system/multi-user.target.wants/snapd.autoimport.service still exists and points to the old target [08:04] PR snapd#4327 opened: release: merge 2.30~rc1 back into master [08:12] pstolowski: hey, good morning. do we have a forum topic for the post-refresh hook? I'm updating the roadmap right now [08:14] PR snapd#4328 opened: wrappers: fix unit tests to use dirs.SnapMountDir [08:14] trivial review ^^ [08:14] mvo, hey! there was something, but I'm not sure if it's useful to anyone. i need to search it [08:16] mvo, ok, that was https://forum.snapcraft.io/t/install-remove-hooks/478 but it's not really covering post- and pre- which we ended up with [08:17] mvo, I'll respond in this thread with up-to-date info [08:18] mvo: thanks for the review [08:19] mborzecki: doing [08:19] done [08:20] zyga-ubuntu: thanks [08:22] pstolowski: ta [08:24] small simplification and another run [08:24] maybe last one :) [08:54] Hi, I'm having trouble downloading Ubuntu Core 16 for RPi3 (edge) image. I get the Apache 403 sever error. Can somebody configure that real quick? [08:55] here is the link: http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+raspi3.img.xz [08:55] KristijanZic: works for me [08:55] KristijanZic: maybe you have a transparent proxy? [08:57] zyga-ubuntu: thanks, it was my adblock [08:59] anyone wants to take a stab at reviewing #4313? [08:59] PR #4313: timeutil: refresh timer take 2 [09:01] mborzecki: I'll look but I want to finish this invalidation first [09:06] oohh [09:06] darn [09:06] 1 vs 0 typo [09:06] now it works [09:06] ffss.. [09:07] :) [09:07] damn my back hurts [09:08] came back to playing badminton again after one month pause, wasn't able to walk up and down the stairs yesterday [09:09] mborzecki: man, did you exert yourself too much? [09:09] mborzecki: or did you have some accident during the game? [09:09] (tests rolling now) [09:11] guess it just was a bit too much, rally after rally ;) badminton is really fast, lost of movement back and forth at full speed down to full stop [09:13] PR snapd#4329 opened: cmd/snap-confine: discard stale mount namespaces (v2) [09:13] so [09:13] mvo: what shall we do with indent [09:13] mvo: the version in artful produces different "canonical" representation than the version of indent in xenial [09:14] zyga-ubuntu: meh, that is sad [09:14] mvo: I'm inclined to kill it [09:14] mvo: and go to clang-format which is a bit better [09:14] mvo: (flag day to run make fmt) [09:14] zyga-ubuntu: can we change gradually? what I hate is that we lose the history [09:14] mvo: not that I see [09:14] mvo: we can disable the check [09:15] zyga-ubuntu: well, not loose totally but it makes things harder [09:15] zyga-ubuntu: lets do that then [09:15] mvo: kk [09:18] PR snapd#4330 opened: cmd: disable check-syntax-c [09:18] mvo: ^^ [09:21] that is :( [09:23] pedronis: ? [09:23] pedronis: are you talking about 4330 [09:31] mvo: I'm a bit sleepy and tired, I have to stop working till midnight [09:31] mvo: when stale base v2 patch is green I'll break and get a long walk in the sno [09:31] mvo: I'll be back to discuss this with jdstrand and jjohansen as actually, the workaround we discussed last night is still showing the kernel bug [09:32] mvo: so whatever we end up doing, I think we need more jjohansen's eyes on this [09:32] zyga-ubuntu: ok, thanks for the headsup [09:37] * zyga-ubuntu sees green ^_^ [09:38] let's run 14.04 [09:38] zyga-ubuntu: yes, when do we run it? in our unit tests? when we build the deb? [09:38] pedronis: it's a part of "make check" [09:39] pedronis: so it affects unit tests, package builds and everything [09:39] pedronis: I kept the target, just detached it from make check [09:39] even manually we need to decide where to run it? no? [09:39] otherwise it will be a whack-a-mole [09:39] pedronis: I think unless we figure out how to make indent behave, it's useless [09:40] pedronis: we can run "make fmt" [09:40] pedronis: (as an informal requirement for C code changes) [09:40] pedronis: the output will look mostly consistent but there will be small changes between xenial and artful [09:40] I think we are mostly all on artful (or equivalently recent indent) [09:40] yes, but if one runs make fmt with one versio and the next person with another [09:41] pedronis: yes, so as long as this is reasonably consistent inside the team (few people touch this code) then I think it's not a problem [09:41] that sounds optimistic to me [09:42] maybe we should code a version in fmt and just warn, do nothing if it is not that one [09:44] pedronis: I'll look into this [09:44] pedronis: maybe there's a new knob in indent [09:44] pedronis: and we don't control it so it fluctuates [09:44] but this assumes that we can still make a profile that won't die on xenial [09:45] man, I should have used clang-format years ago [09:49] 14.04 is good too [09:49] this looks like a winner [09:50] https://github.com/snapcore/snapd/pull/4329 if someone wants to go down there and examine dragons [09:50] PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) [09:52] PR snapd#4291 closed: osutil/sys: reimplement getuid and chown with the right int type [09:53] mvo: can you create the 2_31 tag in the forum [09:53] PR snapd#4331 opened: systemd: add support for the mask/unmask operations [09:53] pedronis: let me try, I think I can [09:53] pedronis: anything specific I should tag? [09:53] there are at least things to move [09:54] pedronis: +1 [09:54] because they didn't make it for 2.30 [09:54] pedronis: updated [09:55] thank you [09:56] now when 2.30 goes to stable [10:10] we can cleanup upcoming stuff [10:15] PR snapd#4332 opened: corecfg: also "mask" services when disabling them [10:17] PR snapd#4328 closed: wrappers: fix unit tests to use dirs.SnapMountDir [10:45] man [10:45] I will never go out [10:45] slooow tests [10:45] got this: error: cannot list snaps: cannot list local snaps! cannot find publisher details: snap-declaration (99T7MUlRhtI3U0QFgl5mXXESAiSwt776; series:16) not found [10:45] any idea where this is coming from? [10:45] hmmm, looks like missing assertion [10:45] no idea [10:45] (why) [10:46] that's `snap list` [10:47] funny, if I do `snap install core` then it complains that core is installed, but there no core in /var/lib/snapd/snap [10:47] what did you do to get there? [10:49] that is a weird state [10:49] PR snapd#4333 opened: packaging/arch: add bash-completion as optional dependency [10:50] hmm must have borked something when playing locally with the package [10:51] niemeyer: “2017-11-30 10:45:02 Error debugging qemu:ubuntu-14.04-32:tests/main/snap-confine-privs : EOF” <- probably not the network [10:55] niemeyer: the thing that stands out is that the first line of output of the failing test output is 'stdin: is not a tty' [11:08] eh [11:08] ok [11:08] that's it [11:12] * zyga-ubuntu -> walk [11:26] * sergiusens waves [11:29] sergiusens: hey [11:38] niemeyer: if 4322 captures your suggestion from some days ago, please merge, I have work on topic of it but I wanted to double check with you first that the name is what you had in mind [11:44] PR snapcraft#1778 opened: Add sentences to error when registering name [11:48] re [11:48] mpt hey there, it's me again and I have a small request, can you look at https://github.com/snapcore/snapcraft/pull/1778/files ? It is an error message improvement and the author created it from a Google code-in task [11:48] PR snapcraft#1778: Add sentences to error when registering name [11:48] man, I need polish-weather-proof shoes [11:50] zyga-ubuntu: https://i.imgur.com/R2Iwz6G.jpg [11:52] Chipaca: you laugh but I was using that for 80% of the year back in spain [11:53] zyga-ubuntu: oh, i'm laughing alright [11:53] Chipaca: my "winter shoes" were just that + small outer layer [11:53] I want back! [11:53] niemeyer, I'll be 5 minutes late today [11:54] looking [12:15] eh [12:15] I wish it was xmas [12:15] PR snapd#4327 closed: release: merge 2.30~rc1 back into master [12:15] tests would be happier [12:15] everybody is happier on xmas [12:15] and there's more green [12:16] cachio: Ack, and hellos [12:16] I am late myself today as well [12:17] zyga-ubuntu: Well, just pretend it is! It's not too different from the 25th.. it's just more people pretending.. [12:18] Chipaca: Is it the same test? [12:18] mvo: Will look, thanks [12:19] niemeyer: http://pastebin.ubuntu.com/26080210/ [12:19] niemeyer: hey [12:19] niemeyer: I was wishing for more green tests :) [12:20] at some point we'll talk about eco-tests [12:20] PR snapd#4322 closed: corecfg: rename package to overlord/configstate/configcore [12:20] mvo: It's in.. good branch name too :) [12:21] zyga-ubuntu: Some good discussions here from last night.. a bit too long to jump in without context, but curious to hear your thoughts on it during or after the standup [12:21] i might be missing the standup today: the cops said they'd come by at 12 but they haven't yet, and if it's any later than it'll overlap [12:21] s/than/then/ [12:21] Chipaca: Cops? Are you okay? [12:22] niemeyer: gladly [12:22] niemeyer: bullying at the boys school escalated [12:22] there's now apparently a video on youtube [12:22] Chipaca: Oh my.. what are we doing with our society [12:23] omg, kids [12:23] but then adults are not that much better [12:23] No, more like OMG people overvaluing kids actions [12:24] Well, or maybe not [12:24] It really depends on what's going on, and I'm inferring from recent experiences.. so I'll just shut up. [12:26] niemeyer: can i ask you for a review of #4313? [12:26] PR #4313: timeutil: refresh timer take 2 [12:27] Chipaca: The stdin is indeed not a tty.. [12:27] Chipaca: Nor the stdout [12:28] Chipaca: Unless the shell is used, obviously [12:29] niemeyer: but wherefore the message? [12:30] (TIL a new word) [12:30] niemeyer: it's an old word :-) [12:30] Chipaca: Because it's indeed not.. it's a pipe in this case [12:31] Chipaca: Something was trying to do something and failed [12:31] Chipaca: This wouldn't justify a disconnection, even more considering that the output did continue [12:32] Chipaca: Did you manage to reproduce it predictably? [12:32] Chipaca: If the other end is managing to disconnect reliably, it has to do with either networking or ssh [12:32] niemeyer: i'll answer that in a few minutes when it runs again === chihchun is now known as chihchun_afk [12:32] Chipaca: Note that networking is indeed involved in qemu, despite being local [12:32] (still ssh) [12:33] niemeyer: yeah but it's not some network op along the route toggling a box [12:33] Chipaca: Killing sshd would also have a similar effect [12:34] niemeyer: (i'm only involving you because they're weird enough they might be indicative of something more obscure; i'll continue continuing) [12:34] Chipaca: Yeah, it will be something more interesting, like a bug in Spread's client or something inside the VM poking the system state [12:34] Chipaca: Thanks, glad to continue investigating [12:34] mborzecki: Yeah, let me just finish a review and will pick that one next [12:35] dran you travis [12:35] travis is penalizing us for having many long tests [12:36] Chipaca: Did you update your Spread from the tarball recently? [12:36] As in, late last week [12:37] niemeyer: aug 24 [12:37] zyga-ubuntu: Huh? [12:37] Chipaca: Okay, not a bug in the zlib thing then [12:37] niemeyer: I went for a walk after one of my tests timed out [12:37] niemeyer: it's still "waiting to start" [12:37] niemeyer: that was ~2 hours ago [12:38] zyga-ubuntu: That's not Travis penalizing us.. that's usually Travis constraining how much they are willing to give us (for free!) at once [12:38] yes, that's true [12:39] zyga-ubuntu: Right *now* we have 8 branches waiting to be tested [12:40] zyga-ubuntu: If you push something to test *now*, it will take about 8*30min/3 [12:40] zyga-ubuntu: hey, it may be because of the unconditional sc_reassociate_with_pid1_mount_ns() in main.c [12:40] zyga-ubuntu: Which is about 1h30mins [12:41] zyga-ubuntu: so I think we were doing a triple setns(). -> 1, -> inside to verify -> 1 as needed [12:42] zyga-ubuntu: curious if you comment that out in your current refactored branch if you see the issue [12:42] (as a temporary test) [12:42] jdstrand: but that doesn't do anything [12:42] jdstrand: that just stats and does nothing more [12:42] jdstrand: we _dont_ setns there [12:42] jdstrand: (hey) [12:43] maybe I misread something. hold on [12:43] jdstrand: comment out what exactly? [12:44] jdstrand: the code in sc_reassociate_with_pid1_mount_ns doesn't ns unless it has to, and in this case it doesn't [12:44] jdstrand: I can comment that out and see if the confusion goes away [12:45] jdstrand: note that I also use absolute paths, not fchdir + relative paths [12:45] jdstrand: IMO apparmor is confused by something we do, but it's not just setns [12:47] zyga-ubuntu: I'm reading sc_reassociate_with_pid1_mount_ns() in ns-support.c. I see only one return. where is it deciding not to setns to pid 1? [12:48] zyga-ubuntu: I was suggesting just commenting out the line in main.c: // sc_reassociate_with_pid1_mount_ns(); [12:49] oh the memcmp. let me read more carefully [12:49] * jdstrand is not completely awake yet [12:50] :) [12:50] jdstrand: no worries [12:51] jdstrand: I'm happy to experiemnt to see what is breaking it [12:51] jdstrand: I also devised a way to not setns and measure [12:51] jdstrand: it's a bit more contrived but will work [12:51] zyga-ubuntu: commenting that out is certainly a fast test [12:52] jdstrand: test in progress [12:52] zyga-ubuntu: nice. I thought of a rather crude way to not setns from devmode too. fork/exec snap-confine from snap-confine. still want to think through that [12:53] jdstrand: look at freezer cgroup, look at each pid, look at its mountinfo [12:53] jdstrand: as long as any process is there, we can see the mountinfo [12:53] zyga-ubuntu: oh, that's good [12:53] jdstrand: so this gives us two values: we know if it's empty [12:53] yep [12:53] (but we don't know if it's stale then, that's a downside) [12:53] jdstrand: and we know if it's active and then which root is used [12:53] hey guys, i'm gonna be 5 minutes late to standup [12:54] jdstrand: I haven't founda way not to setns to measure if it is really empty [12:54] jdstrand: so I didn't implement that as it reduces to current problem in worst-case [12:55] created bug #1735410 for l10n support, should I start doing it? [12:55] Bug #1735410: Localization support [12:55] woot, thank you m4sk1n [12:55] (for snapcraft) [12:55] zyga-ubuntu: well, the fork/exec into the freezer/setns into the mount namespace would do it [12:56] jdstrand: fork + exec as opposed to just fork? [12:56] jdstrand: I really want to get to the bottom of this bug in the kernel [12:56] it doesn't have to be a full on helper though. [12:56] jdstrand: as I feel like we're walking on a minefield with our eyes closed [12:56] jdstrand: we could fexec /bin/cat [12:56] jdstrand: to cat mountinfo [12:58] zyga-ubuntu: the fork may be enough, but would need jjohansen to confirm [12:58] jdstrand: hold on, we fork now [12:58] jdstrand: it's not enough [12:59] ok, so I'll start today [12:59] m4sk1n: yes, I think so [12:59] m4sk1n: kalikiana is a snapcrafter so he can help you out [12:59] m4sk1n: I will gladly review the translation as I'm familiar with the language and the topic [13:04] jdstrand: confirmed, that has no impact [13:04] PR snapd#4333 closed: packaging/arch: add bash-completion as optional dependency [13:04] jdstrand: I commented out both the extra apparmor rule and the optional reassociation [13:05] * jdstrand nods [13:05] zyga-ubuntu: well, this is good info for jjohansen [13:12] * mvo hugs Son_Goku [13:12] what brought this on? [13:20] zyga-ubuntu niemeyer we moved over to using travis stages, overall the whole suite can take longer, but it is mitigated as the fast tests are what usually fail not needing to wait for all the jobs to end (jobs from the next stage won't pass if the previous one isn't completely green) [13:20] this has saved us plenty of wait [13:21] sergiusens: We need to wait for tests to end either way, because we're limited on the number of worker machines too [13:25] jdstrand: I have a suspicion about what _may_ be going on, I'll write a small C program and apparmor profile to help jjohansen [13:25] jdstrand: I'll keep you posted [13:26] jdstrand: in the end we need some idea if the workaround I implemented in both PRs is acceptable [13:26] jdstrand: and if we can roll with it [13:27] zyga-ubuntu: note that the double setns is not desirable regardless [13:28] zyga-ubuntu: but maybe there is something else that can be done to your current attempt after jjohansen looks at it [13:33] jdstrand: we don't do double setns now [13:33] zyga-ubuntu: I know [13:34] ah,o k [13:34] zyga-ubuntu: I wasn't sure if you were saying that you wanted to go back to what you had yesterday [13:35] zyga-ubuntu: and I was simply saying what you did today was good on its own, even if there is still something else going on [13:36] zyga-ubuntu did you make any progress on that non ubuntu kernel snap-confine die issue which makes me disable apparmor completely? [13:38] sergiusens, done [13:45] jdstrand: no, no I mean I just need some advice on what to do next [13:45] jdstrand: I see, thank you for clarifying that [13:46] sergiusens: no, sorry, still entangled in bugs [13:53] zyga-ubuntu: jjohansen would be able to provide that, there is just a question of timing. I'll let him comment-- he may need to talk to tyhicks/ratliff if it requires deep investigation [13:54] jdstrand: I reproduced this [13:54] jdstrand: reducing it to a small C program [13:54] jdstrand: woot :) [13:55] niemeyer: ^ I was right abount my hunch I said during the call :) [13:55] zyga-ubuntu: a small reproducer will be super helpful [13:56] jdstrand: yep, just writing a README file now [13:56] mvo: hey, curious if the 'include -> #include' fix will be in 2.29.4? [14:02] jdstrand, hey [14:02] jdstrand, I am working in a PR to test the netlink connector interface [14:02] jdstrand, #4325 [14:02] PR #4325: Adding test for netlink-connector interface [14:03] I am getting an error "Bad system call" when I try to use the interface and the plug is disconnected [14:03] jdstrand, not sure if it is expected or not? [14:05] kyrofa, o/ hey, thanks for the comments in the PR (https://github.com/snapcore/snapcraft/pull/1774), pushed some updates for when you get some minutes; let me know if you have any other comments [14:05] PR snapcraft#1774: Push binary metadata to the Store [14:17] jdstrand: I think it will be in 2.30 [14:17] jdstrand: I don't recall any backports done to that PR [14:28] when is 2.30ish? [14:33] ikey: next week [14:33] oo nice [14:33] thats when ill do my call for testing then === pbek_ is now known as pbek [14:54] jdstrand: the include fix is not in 2.29.4, do you need it? it is in 2.30 and we could pull it in to the 2.29 branch *if* we need to do another 2.29 (which I hope we don't need to :) [14:55] mvo: I thought someone mentioned it as a regression in bionic, which means the sru would be halted, no? [14:56] maybe it wasn't bionic specific. let me reread the bug [14:57] mvo: actually, it affects 17.10: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1733700 [14:57] Bug #1733700: aa-enforce fails due to syntax error in snapd.snap-confine profile [14:57] I thought there was another bug... [15:00] jdstrand: uhh, ok [15:01] ok, yes 1734038 [15:01] * jdstrand reads [15:01] jdstrand: this is very annoying, I will pull it into branches/2.29 and we need to discuss what to do [15:02] yes, 1734038 mentions artful as well [15:05] zyga-ubuntu: silly question but why is it #include "/var/lib/snapd/apparmor/snap-confine" in master vs ".../snap-confin.d" in 2.29? [15:05] jdstrand: or maybe you know the answer -^ [15:05] mvo: I think we need a spread test to do 'apparmor_parser -QTK /path/to/snap-confine/profile' [15:06] mvo: that will make sure that the policy is good everywhere [15:06] mvo: the fact that cache files masked the issue is unfortunate [15:07] mvo: let me look [15:07] jdstrand: ok, let me write a test for this [15:08] mvo: note that as of recent PRs, the interfaces-many spread test I added achieves the same result for snaps [15:08] so it will be nice to ohave that for snap-confine itself [15:10] sergiusens: Hi! re: snapcraft 2.35 on xenial, its been 7 days today, so I guess we can move that from xenial-proposed to -updates ? [15:10] mvo: niemeyer asked us to drop the .d [15:11] zyga-ubuntu: aha, ok. can/should this happen in 2.29 as well? we are a bit inconsistent right now between 2.29 and 2.30+ [15:12] zyga-ubuntu: does the move away from .d cleanup the .d directory? if so, are reverts handled ok? [15:12] om26er you can help with the SRU process by adding a comment on the SRU bug, elopio did a call for testing a while back [15:13] he's on holidays so it is taking longer than usual [15:13] mvo: not sure [15:13] jdstrand: not sure either [15:14] man [15:14] jdstrand: I can trigger the bug with a small C program [15:14] jdstrand: but only if snap-confine first produces a namespace [15:14] jdstrand: if I use a simple tool that produces a namespace I don't get that bug [15:15] jdstrand: I wonder which of the things we are doing is causing it [15:15] PR snapd#4334 opened: tests: ensure snap-confine apparmor profile is parsable [15:15] jdstrand: my mini-tool now does unshare + pivot_root [15:17] sergiusens: ok, I added my comments there as well. I hope that gets promoted to -updates soon. [15:17] mvo: oh right, so the apparmor -QTK test is absolutely valid, but wouldn't have caught this (I forgot, the parser is fine, it is the apparmor python tools that are not, which is why users see this and qrt kernel failures). let me give you an additional test for -QTK [15:18] to -QTK [15:18] meh, let me give you the userspacec tools test too [15:19] mvo: before I right that, this is tricky [15:19] mvo: cause say you fix this. the previously broken revision is still on the system [15:20] mvo: and the userspace tools will still fail [15:20] jdstrand: what's the problem? [15:21] jdstrand: is it the #include vs include? [15:21] zyga-ubuntu: yes [15:21] so, apparmor_parser is fine [15:21] jdstrand: can we fix the userspace tools [15:21] so snaps work [15:21] jdstrand: this is IMO a bug in the tools [15:22] but apparmor python tools don't understand 'include' and the tools read all profiles that are in /etc/apparmor.d [15:22] jdstrand: sure, can we fix those tools to understand the same language that the other tools do? [15:23] so if someone has a broken revision and gets the new unbroken revision, then the userspace tools will still be broken until the broken revision rotates out [15:23] I think we have to [15:23] jdstrand: yes, I think this is the correct way to deal with this [15:24] mvo: I think the spread test is valuable. I don't think the 2.29 respin is required [15:24] tyhicks: we need to update the userspace tools everywhere for 1734038 and 1733700 [15:24] man, that sucks [15:26] mvo: in addition to 'apparmor_parser -QTK /path/to/profile', please also do 'apt-get install apparmor-utils && aa-enforce $ sudo aa-enforce /path/to/profile' [15:29] * zyga-ubuntu hugs jdstrand [15:29] it's not too bad, just one gazillion packages [15:30] would it be valid to refer to/copy files from partA in partB's install scriptlet using a relative path (e.g. ../../partA/install/some/file.ext), provided I declare that partB is built after partA, or is that discouraged? [15:30] mvo: when it doesn't fail, it simply will compile the profile and load it into the kernel [15:30] mvo: but aa-enforce will (weirdly) pull in all the profiles, just like logprof and genprof [15:31] sergiusens, you probably know? ^ [15:32] oSoMoN not until I read what this is all about :-) [15:32] sergiusens, just that one question 3 lines above [15:33] oSoMoN discouraged, parts are private, think of it like using private headers, you can, but if it breaks you get to keep the pieces [15:33] jdstrand: ok, I have a reproducer in C, separate form snapd [15:33] *from [15:33] sergiusens, right, that's what I feared [15:33] oSoMoN it would be more convenient to stage the files from partA and consume them in partB from $SNAPCRAFT_STAGE [15:34] sergiusens, ah, I didn't know of $SNAPCRAFT_STAGE, that sounds like what I need [15:34] oSoMoN or if you have a plugin `self.project.stagedir` iirc [15:34] one sec, an example to arrive [15:34] great [15:34] but I need to run a scriptlet on those files, isn't it too late for that at the stage phase? [15:36] oSoMoN https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/integration/snaps/stage_env/snapcraft.yaml [15:36] jdstrand: ok, will do. [15:37] oSoMoN if a part depends on another, the dependant part goes all the way to staging as that is the only place a dependency can be consumed (in the for of a library, runnable or whatever other artifact) [15:37] jdstrand: silly question, could you do something like s/include/#include/ in your python tools as a quick fix? [15:37] sergiusens, great, so that should do the trick [15:37] thanks! [15:39] mvo: that is what I was saying-- we have to sru apparmor everywhere to do that (or backport the actual patch) [15:40] jdstrand: ok, thank you [15:43] jdstrand: PR updated to include aa-enforce [15:43] jdstrand: where can I share the program? [15:43] jdstrand: actually, I'll just add that to the bug report [15:46] mvo: The point about .d was that all of these are .d-irectories.. :) [15:46] mvo: There's nothing special about that one [15:46] mvo: I did originally ask back then, quite a while ago actually, whether this was already released.. the answer was no [15:48] jjohansen, jdstrand: https://bugs.launchpad.net/apparmor/+bug/1735459 [15:48] Bug #1735459: Incorrect denial on umount with bind-mounted mount namespace [15:49] niemeyer: ^ that bug with small C reproducer [15:49] niemeyer: I said it wasn't AFAIK, I must have made a mistake there [15:50] mvo: btw I checked, snap install lxd lxd really creates twice the tasks, and then they confuse each other [15:50] running at the same time [15:52] zyga-ubuntu: I do remember grepping the code and finding no uses either, so at the very least I made the same mistake [15:53] zyga-ubuntu: we could work around that denial if needed, but I defer to jjohansen [15:53] niemeyer: I looked at git tags [15:53] pedronis: This demonstrates the issue, but it's an obvious case that we don't in fact want to reach that code.. this should drop duplicates very early on.. in the API itself [15:53] jdstrand: the example contains a workaround as well [15:53] jdstrand: but I'd like jjohansen to analyze and figure it out [15:54] jjohansen: I'm happy to help [15:54] jjohansen: (with the kernel side) [15:54] Anyone tried snapd on fedora 27 recently? It just hangs, and I get messages in the journal about selinux blocking access to /proc//stat [15:54] popey: no :/ [15:54] I have never knowingly disabled selinux on fedora before. [15:54] jdstrand, jjohansen: We just need something that works soon, and we need an ack that we can trust it not to break in the foreseeable future.. if you guys have a different suggestion, we can go with anything else too.. we just need to get this working and out of the way. [15:54] I just booted it and updated the machine and now snaps don't work [15:54] Son_Goku: ^ is that something we can fix for 2.30? [15:55] popey, zyga-ubuntu: Yes, we did try recently, as in last week.. we've just built images for it [15:55] cachio will have more details [15:55] niemeyer: ah, indeed! [15:56] I don't understand. I had snaps working here previously [15:56] suddenly since an update, i cant install snaps [15:56] niemeyer: yes, it's really a different kind of issue/bug, anyway it's there atm [15:57] popey, last week I executed the snapd test suite on fedora 27 and just 1 test failed [15:58] popey, we are using the image fedora-27-64 on linode, that will be ready next week [15:58] cachio: is selinux enabled on our image? [15:58] (worth having a spread test for it) [15:59] zyga-ubuntu, I need to check that [16:00] Do I need to file a bug somewhere? Because right now Fedora 27 users can't install snaps (AFAICT) [16:03] niemeyer (cc jjohansen and zyga): that is what we all want and are working towards [16:03] jdstrand: I'm talking pragmatically about the specific code that zyga-ubuntu posted today [16:04] jdstrand: One of them works, the suggested approach doesn't [16:04] popey, yes please [16:04] jdstrand: We cannot use a suggested approach that doesn't work, of course.. so either we need a +1 on the approach that does work, or we need a third approach that you and jj can vouch for and does work too [16:04] popey, I'll be researching that [16:04] mvo: is bug #1734038 marked as a blocker for sru? in thinking about it, it probably should be because if 2.29 goes to stable releases, the offending rule will be on disk for everyone, regardless of if they use snap install and get a new core, meaning all stable release users who use apparmor-utils will break whether they use snaps or not [16:05] Bug #1734038: utils don't understand «include "/where/ever"» (was: Potential regression found with apparmor test on Xenial/Zesty) (Ubuntu):Invalid> [16:05] cachio: where should I file it? forum / launchpad / github? [16:05] popey, in the forum please [16:06] jdstrand: This has been coming for some time and I understand we all want to reach the same goal.. but we need to get it through and move on [16:06] niemeyer: I understand. what zyga posted today may be fine and just a bug that can be worked around in policy as opposed to what was there yesterday that went against the grain of how namespaces are intended to function [16:07] niemeyer: we need jjohansen to comment. I just wanted you to know that it is understood that this is a priority and no one wants to block [16:07] jdstrand: 1734038 is not a blocker yet, I can update 2.29 and do a new SRU if needed, we probably also need to update the core snap though as this will also write include (and not #include) [16:08] jdstrand: Thanks a lot, and please don't take my words as "we need to move on anyway".. the point is just that we do need to move on, so we need to investigate and get to an understanding and agreement that a given approach solves the problem and is reliable in terms of the implementation not changing behind us tomorrow [16:08] niemeyer: understood (cc jjohansen ^) [16:08] jdstrand: zyga-ubuntu produced a smaller test case which hopefully will make things easier for you and jj to discuss and find a workable agreement in those terms [16:09] tyhicks, ratliff: do note the above ^ (since I can't just assign jjohansen to something :) [16:09] niemeyer: yes [16:15] zyga-ubuntu: did you send your test case to jjohansen with a brief description? I don't think that it is optimal for him to try to read through this backscroll [16:18] ratliff: better: https://bugs.launchpad.net/apparmor/+bug/1735459 [16:18] Bug #1735459: Incorrect denial on umount with bind-mounted mount namespace [16:18] zyga-ubuntu: excellent, thanks! [16:23] jjohansen (cc niemeyer, ratliff, tyhicks): re bug #1735459, the question is whether that approach is sane or not. if so, we can add a workaround rule and treat it like a regular bug. if not, we should recommend an approach to zyga [16:23] Bug #1735459: Incorrect denial on umount with bind-mounted mount namespace [16:26] PR snapd#4335 opened: snap-confine: use #include in snap-confine.apparmor.in [16:27] jdstrand: -^ [16:30] mvo: approved. where is the pr for the -QTK/aa-enforce spread test? [16:30] mvo: hmm [16:30] mvo: we merged https://github.com/snapcore/snapd/pull/4335/files before!?! [16:30] PR #4335: snap-confine: use #include in snap-confine.apparmor.in [16:30] mvo: what am I missing? [16:30] mvo: I pushed this yesterday or two days ago [16:30] zyga-ubuntu: release/2.29 [16:31] ahh [16:31] sorry [16:31] all good [16:31] * zyga-ubuntu had panic moment [16:41] PR snapd#4335 closed: snap-confine: use #include in snap-confine.apparmor.in [16:45] PR snapd#4330 closed: cmd: disable check-syntax-c [16:46] zyga-ubuntu, after double check status on fedora 27 [16:47] zyga-ubuntu, selinux is enabled [16:47] and we are using kernel 4.13.15-300.fc27.x86_64 [16:47] popey, please read this [16:48] ok [16:48] cachio: perhaps popey's machine uses different kernel [16:48] cachio: or perhaps the workstation image contains some different defaults [16:48] its a vm [16:48] cachio: would be good to check a full workstation VM [16:48] just a plain vanilla fedora 27 vm [16:48] zyga-ubuntu, I think this is the real diff [16:48] nothing special. [16:48] popey: correction *workstation* vm [16:48] popey: fedora has workstation, server and atomic editions AFAIK [16:48] yeah, it's workstation [16:49] popey: our CI is done on cloud images [16:49] popey: I don't fully understand how they differ [16:50] One of them doesn't work, that's a key difference ;) [16:53] PR snapd#4336 opened: Adding fedora 27 and rawhide to spread.yaml [16:59] * zyga-ubuntu goes to test vlc and that amd gpu for popey [17:08] popey: oy, doing that test now, man, I haven't booted this in a while [17:08] I' got a gazillion updates [17:11] popey: that bunny movie is hard to download, from the blender website at least [17:12] I hear there are free movies on the internet [17:13] yes, but all over 18 [17:13] I'm trying blender mirrors [17:18] popey: well [17:19] popey: it works [17:19] popey: not sure if this is hw accelerated [17:19] popey: any hints on how to check [17:19] it should tell you on the console [17:19] probably mentioning VDPAU or VAAPI [17:19] [00007f782801a800] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding [17:19] so yep [17:19] and that it's trying to load a vdpau or va-api module [17:19] oooooh [17:19] butter smooth [17:19] :-) [17:19] that's freaking awesome [17:19] yep [17:19] I'll comment on the forum [17:19] thank you! [17:19] and VLC looks great [17:19] awesome [17:24] popey: done [17:24] thanks. [17:25] my pleasure [17:25] it was surprisingly flawless :) [17:26] i should hope so after the effort that went into making that snap! :D [17:26] popey: do you need a Nvidia test? [17:26] zyga: so... i'm getting very weird errors from the spread suite, and i thought maybe you knew something (seeing as you'd spent some time hating it this week) [17:26] no, got that covered thanks [17:26] popey: I don't have anything recent, I have one old laptop with nvidia gpu [17:27] Chipaca: yes? [17:27] me and wimpy both have nvidia by default, so easy to cover that [17:27] popey: great, thank you for doing this [17:27] zyga: there's a test that fails every time, but never if i run it on its own [17:27] Chipaca: want to help me figure it out? [17:27] zyga: and when it fails i get no debug info, and i can't -debug it by hand, because it's just EOF [17:27] oh [17:27] hmm [17:27] well [17:27] I'd start with this: [17:28] Chipaca: install this copy of spread https://github.com/snapcore/spread/pull/47 [17:28] PR spread#47: Add support for project-wide measure-each stanza [17:28] Chipaca: add measure-each: to spread.yaml, I do something like this: [17:28] Chipaca: something-to-measure > /tmp/now.log [17:29] Chipaca: if [ ! -e /tmp/vanilla.log ]; cp /tmp/now.log /tmp/vanilla.log; fi [17:29] Chipaca: diff -u /tmp/vanilla.log /tmp/now.log [17:29] Chipaca: start small, something that few tests break [17:29] Chipaca: and iterate with -seed set [17:29] Chipaca: I made some things that help: [17:29] zyga: uh... but [17:29] zyga: i don't see anything broken :-/ [17:30] Chipaca: run this on linode to save network if you want to avoid that [17:30] Chipaca: sure [17:30] it just dies [17:30] Chipaca: my point is that _something_ messes up [17:30] Chipaca: and over time, as we measure more things [17:30] Chipaca: one more idea [17:30] Chipaca: patch spread to don't do headless qemu [17:30] Chipaca: when it breaks, log in from the window and see what you get [17:30] Chipaca: I didn't do this but it's useful [17:30] Chipaca: maybe something rm -rf's / [17:33] Chipaca: another idea, run each possible combination of (n, test_that_eofs) where n is each test in the suite [17:34] Chipaca: unless the bug is a combination of more than one cleanup going wrong [17:38] * zyga reboots to get new kernel [17:40] pedronis: Hey, which specific test case where you referring to the whole time in our call? [17:40] Sorry, not the case, condition [17:40] Sorry, not test case, condition [17:40] pedronis: I'm now wondering whether we were talking across each other the whole time.. that would explain why it took us a while === anta_ is now known as kw [17:47] Chipaca: I hope my messages were not grim [17:49] popey: I got one denial [17:49] [ 262.410700] audit: type=1400 audit(1512064138.223:71): apparmor="DENIED" operation="open" profile="snap.vlc.vlc" name="/etc/xdg/QtProject/qtlogging.ini" pid=3902 comm="vlc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [17:49] looks harmless [17:49] not seen that before, thanks [17:49] I wish we had a way to deny things per-snap [17:49] "silence those denials" [17:49] mvo: I'm pretty sure this was the case.. [17:50] popey: another one [ 328.556164] audit: type=1400 audit(1512064204.370:72): apparmor="DENIED" operation="open" profile="snap.vlc.vlc" name="/etc/vdpau_wrapper.cfg" pid=3902 comm="vlc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [17:50] popey: ohh, subtitles are broken [17:50] yeah, i get that one, it's fine [17:50] ooh [17:50] popey: I ran a anime movie and it shows garbage [17:50] broken how? [17:50] fonts probably? [17:50] "the wind raises" [17:51] probably [17:51] or [17:51] encoding/locale [17:51] more likely [17:51] the movie is in japanese with english subs [17:51] and I'm not sure if we ship an UTF-8 capable locale by default [17:51] mvo: Which would be super ironic, and somewhat telling about how easy it is to discuss the wrong thing :) [17:51] ugh [17:52] I can attach a photo [17:52] k [17:53] is it an mkv? [17:53] i have some which have subtitles so can probably test here [17:53] yes [17:54] hey, even the appindicator works :D [17:58] huh, that's interesting [17:58] Nov 30 17:57:11 autopkgtest rngd[3413]: read error [17:58] out of randomness? [17:58] somehow [17:59] probably qemu doesn't have /dev/hwrng [18:02] Chipaca: hmm [18:02] -object rng-random,id=id,filename=/dev/random [18:02] Creates a random number generator backend which obtains entropy from a device on the host. The id parameter is a unique ID that will be used to reference this entropy backend from the virtio-rng device. The [18:02] filename parameter specifies which file to obtain entropy from and if omitted defaults to /dev/random. [18:02] Chipaca: I can search for random strings in qemu man page [18:02] (pun intended :) [18:03] oh, I didn't mention: I'm off tomorrow, burning holidays [18:03] jjohansen: do you need anything from me, I'll be back for part of next week [18:03] running htop inside the qemu doing the spread tests is interesting [18:03] also: boring [18:03] also: EOD time here, but i'll be around async [18:04] zyga, popey: we should allow /etc/vdpau_wrapper.cfg I think. what happens if you add it? [18:05] jdstrand: checking [18:05] * jdstrand adds it to todo for the next policy updates for 2.30 [18:06] jdstrand: it still works [18:06] zyga: cool. I'll get that into 2.30 [18:06] jdstrand: thank you :) [18:07] jdstrand: in case this is interesting: [18:07] $ cat /etc/vdpau_wrapper.cfg [18:07] enable_flash_uv_swap=1 [18:07] disable_flash_pq_bg_color=1 [18:08] thanks [18:09] popey: where is the sublime text snap? [18:09] popey: AFAIK we had some [18:09] news to me [18:09] aha [18:09] I saw some chatter on the forum [18:09] it was desired [18:13] mvo, starting sru, do you have the lp link? [18:13] cachio: bad news, we need a respin [18:14] cachio: I just uploaded 2.29.4.2 to beta [18:14] mvo: uh [18:14] cachio: if you could validate so that we can push to candidate tomorrow(ish) that would be great [18:14] cachio: and then I push new SRUs [18:14] zyga: yeah, include ftw :( [18:14] zyga: but it breaks people so we need to fix it [18:15] mvo: but didnt jdstrand say this is a bug that needs to be fixed in apparmor [18:17] mvo, sure [18:17] mvo, which is the issue fixed? [18:21] zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1734038/comments/15 [18:21] Bug #1734038: snap-confine profile uses 'include' instead of '#include' which breaks apparmor-utils python tools (Ubuntu Zesty):New> [18:22] zyga: the problem is that if the sru goes through without the updated rule, all non-snap users that use apparmor-utils will regress (ie, server/cloud users) [18:22] so we either need to delay the snapd sru to depend on the apparmor sru, or fix the snapd sru and do apparmor sru separately [18:24] zyga: so you can't currently do that, see bug [18:24] jjohansen: looking [18:25] jjohansen: that's okay then [18:25] jjohansen: I think we can land https://github.com/snapcore/snapd/pull/4329 [18:25] PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) [18:40] cachio: sorry for the slow answer, I just pushed the new packages into -propsed but they need SRU approval first, the only change is to change "include" to "#include" in our snap-confine apparmor file [18:41] mvo, great, thanks [18:41] mvo, ok, I am creating beta images to run beta validation [18:42] but my internet connection is slow today [18:42] cachio: thank you, much appreciated [18:42] cachio: sorry for this last minute change :/ [18:42] mvo, np [18:55] PR snapcraft#1779 opened: catkin-tools plugin: use stage-packages [18:59] cratliff, if you could give that ^ a test when you're able I'd very much appreciate it! [19:03] It looks big, but that's only because I added that integration test [19:17] kyrofa, Yeah, I'll give it a look. [20:23] it would be nice if anyone whould like to review and +1 this request: https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 . Thanks. [20:50] zyga: hey, I just noticed that we are calling a nmber of things after sc_create_or_join_ns_group() (the setns() to the snap's mount namespace). this isn't wrong per se since we are mounting things like /sys into the namespace, but feels a bit weird. eg, shouldn't we be setting up the snap's freezer cgroup before we setns? [20:56] jdstrand: hmm [20:57] jdstrand: I think the freezer needs to be set just before we exec, at any time [20:57] jdstrand: I wanted to avoid snap-confine getting frozen by accident in the more critical aprts [20:57] *parts [20:57] jdstrand: not sure if that answers your question, please ask again if needed [20:58] zyga: really I'm not asking for you to do anything right this second but maybe add to your todo to consider that we should probably setns() as late as possible [20:59] zyga: and do as much management of the snap in the default mount namespace as possible, to avoid subtle bugs down the line [21:00] jdstrand: noted [21:00] jdstrand: I added two points to your description on the v2 patch [21:01] jdstrand: (fantastic description btw, worth saving in a README) [21:02] snappy-m-o, autopkgtest 1779 xenial:amd64 [21:02] kyrofa: I've just triggered your test. [21:02] zyga: thanks [21:04] Hey niemeyer, are you around? Would you mind taking a quick look through #4323? [21:04] PR #4323: interfaces: add gpio-memory-control interface [21:08] kyrofa: Hey [21:08] kyrofa: Not entirely, but I have a quick window now.. let me look [21:09] niemeyer, really just need your input on the name [21:12] kyrofa: Do you have docs for the kernel? [21:13] kyrofa: On that device [21:13] niemeyer, the link there is all I have: https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/char/broadcom/bcm2835-gpiomem.c [21:20] kyrofa: LGTM [21:20] Thanks niemeyer, I appreciate your time :) [21:53] ok, time to sleep! [21:53] night night everone [21:53] everyone [22:46] PR snapd#4323 closed: interfaces: add gpio-memory-control interface [23:23] is the build.snapcraft.io not triggering amd64/i386 builds anymore? I just triggered a build but only arm gets built. [23:25] something is wrong with build.snapcraft.io [23:59] PR snapcraft#1780 opened: cli: add export-login command