[06:03] morning [06:03] hey mborzecki - good morning [06:03] mvo: hey [06:04] mvo: did i miss anything on friday? [06:10] mborzecki: not much was relatively quiet [06:12] mvo: i like quiet :) [06:12] mee too [06:41] zyga: 6575 has some conflicts [07:35] 89.§34-[\8p] [07:35] = [07:35] good morning [07:35] mvo: thank you, looking now [07:35] zyga: good morning! [07:36] it's good to be back [08:04] mborzecki: Hi, I made a couple of suggestions in 6576 [08:04] pedronis: thanks, reading now [08:06] morning [08:07] pedronis: tbh i've alawys used determinant in the math sense, but i suppose your suggestion works too [08:08] mborzecki: an other option is interfaceConstraint [08:08] mborzecki: it's command impl, not an API or something used everywhere [08:08] so mostly trying to unblock this [08:09] hey pstolowski - good morning [08:09] pstolowski: hey [08:12] mvo: quick question about https://github.com/snapcore/snapd/pull/6574#discussion_r264106985 - can you explain that again please? [08:12] PR #6574: cmd/snap-confine: track per-app and per-hook processes [08:12] mvo: is the goal to see more than one process at a time? [08:13] pedronis: reading dict output a bit more, 'determinant' sounds good [08:15] zyga: it was mostly to ensure that the cgroup really tracks all the pids, we know this so maybe silly [08:15] zyga: otoh *might* be useful when we go to cgroup v2 - otoh there will probably be different interfaces then so maybe again not super useful [08:16] mvo: wait wait, I'm not sure I understand the comment you made [08:16] zyga: i.e. to ensure that any children of the test-snapd-tools.sh app are also part of the cgroup that tracks the activity of "sh" [08:16] mvo: is it really to track two processes? [08:16] ah [08:16] thanks! [08:16] I understand now [08:16] mvo: I will look at conjuring something that checks that [08:16] zyga: great! sorry for the slightly winded way of explaining it [08:17] thank you for clarifying :) [08:17] zyga: cool! but don't kill yourself I think its a bit optional, cgroups tend to work [08:17] I think it's not hard, just a small extra chunk after the two tests there [08:18] mborzecki: quick question about 6238 - this (probably) needs a master merge to make tests happy and a full review from pstolowski - is that accurate? [08:18] zyga: nice [08:22] mvo: and a small update, some new denials were found in the tests which need a little bit of investigation [08:25] pedronis: pushed an update [08:27] mborzecki: thx [08:29] mborzecki: thank you [09:20] mborzecki: #6576 seems to be GTG [09:20] PR #6576: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection [09:21] aand merged [09:21] mborzecki: squash-merged? [09:21] Chipaca: yup [09:22] phew [09:22] :-) [09:22] PR snapd#6576 closed: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection [09:23] mvo: opening a branch with a cherry picke in a minute [09:25] PR snapd#6578 opened: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection (2.38) [09:43] mborzecki: if it can be cherry-picked without a conflcit no need to open a PR [09:44] mborzecki: thanks for landing this so timely! [09:44] mvo: ah, opened the PR anyway, feel free to close :) [09:45] pstolowski: thanks for applying the last round of comment on timings [09:45] mborzecki: thats fine [09:45] mborzecki: I just wanted to make your life easier :) [09:46] pedronis: sure, thanks for the suggestions [09:46] Chipaca: hi, thanks again for the epochs docs, there is a couple of things maybe to clarify and degville has some input too, when is a good time to chat for you and and degville [09:46] ? [09:47] pedronis: anytime before 6pm :-) [09:47] pedronis: Chipaca: same for me :) [09:48] Chipaca: degville: can we have a HO (same as standup) in 10 mins then? [09:48] sure [09:48] Chipaca: pedronis: good for me! [09:59] zyga: updated #6329, please take a look [09:59] PR #6329: cmd/snap-confine, packaging: support SELinux <⛔ Blocked> [09:59] mborzecki: ack, enqueued [10:00] zyga: thanks! [10:05] mvo: added the test to https://github.com/snapcore/snapd/pull/6574 [10:05] PR #6574: cmd/snap-confine: track per-app and per-hook processes [10:08] zyga: nice, thank you [10:13] mvo: #6578 is green [10:13] PR #6578: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection (2.38) [10:16] mborzecki: yay - thanks [10:17] PR snapd#6578 closed: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection (2.38) [10:23] pedronis: https://pastebin.ubuntu.com/p/2wMJ6DtjNz/ [10:30] pedronis: because the check is done in mount-snap, which isn't done for reverts [10:39] Chipaca: ok, so we have a problem [11:00] brb [11:01] mborzecki: is https://github.com/snapcore/snapd/pull/6329/files#r261618980 done? [11:01] PR #6329: cmd/snap-confine, packaging: support SELinux <⛔ Blocked> [11:02] zyga: line 64? [11:02] ahh [11:02] thanks, I missed that (sorry) [11:02] zyga: how about we switch all of the code to clang-format in a separate PR? [11:04] mborzecki: the downside of doing this is that we loose a lot of history for git blame [11:04] of snap-confine? [11:05] I fear we cannot afford that [11:08] hmn wonder if git blame -w would work around that [11:08] mborzecki: might be worth a quick experiment [11:08] (in a local PR) [11:08] eh, local branch [11:12] brb, gym [11:14] mborzecki: let's not [11:14] mborzecki: I wanted that but then considered it a bad move [11:14] mborzecki: it's better to evolve code over time [11:15] mborzecki: this is why I use new files, things slowly move to clang-format [11:16] zyga: actually git blame -w looks quite good locally, but github blame is all bs now and there's no way to switch it [11:17] mborzecki: more reasons to refactor snap-confine tree :) [11:18] mborzecki: sent review on selinux branch [11:23] zyga: not sure how at address your question here https://github.com/snapcore/snapd/pull/6329#discussion_r264181494 [11:23] PR #6329: cmd/snap-confine, packaging: support SELinux <⛔ Blocked> [11:30] zyga: is that correct in the typical case we expect the /usr hierarchy to come from the base snap? [11:38] pedronis: I am experimenting a bit more with remodel right now, one thing I noticed is that refresh of the kernel track will now trigger a re-refresh check which is not compatible with our requirement that we can't have things talking to the network in the install phase of the remodel. thats seems to be a bit of a tricky one [11:48] zyga: updated #6329 [11:48] PR #6329: cmd/snap-confine, packaging: support SELinux <⛔ Blocked> [11:54] mborzecki: thanks! [11:55] pedronis: yes [12:17] mborzecki: https://github.com/snapcore/snapd/pull/6329#discussion_r264181494 [12:17] PR #6329: cmd/snap-confine, packaging: support SELinux <⛔ Blocked> [12:18] ah [12:18] odd [12:18] github doesn't show the replies in some views [12:18] mvo: that's probably easiest to deal with a flag for now [12:18] mborzecki: approved [12:19] zyga: thanks! [12:23] PR snapd#6579 opened: cmd/snap-confine: make sc_args helpers const-correct [12:23] mborzecki, mvo: quick one please ^ [12:24] pedronis: ok [12:25] mvo: we probably want canarying for (automatic) remodeling at some point but is quite premature to have that bit there [12:25] we need to decide what it really means [12:27] pedronis: yeah, a flag for now is fine for me === alan_g_ is now known as alan_g [13:01] off to pick up the kids === ricab is now known as ricab|lunch [13:08] Chipaca: could you review #6568 when you have a bit of time? [13:08] PR #6568: overlord/snapstate: fix restoring of "old-current" revision config in undoLinkSnap [13:10] mvo: https://github.com/snapcore/snapd/pull/6575 needs a 2nd review now [13:10] PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around [13:14] mvo: probably want to look at #6574 a 2nd time [13:14] PR #6574: cmd/snap-confine: track per-app and per-hook processes [13:16] PR snapd#6580 opened: cmd/snap-confine: drop unused dependency on libseccomp [13:17] mborzecki: ^ that one might be interesting for you [13:20] mvo: quick trivial, 2nd review: https://github.com/snapcore/snapd/pull/6579 [13:20] PR #6579: cmd/snap-confine: make sc_args helpers const-correct [13:25] PR snapd#6581 opened: daemon: move a struct def that was between an other struct and its methods [13:26] trivial PR ^ [13:32] hehe [13:32] pedronis: +1 just from the description [13:33] pedronis: of course github thinks you moved a func def, not a struct def [13:34] Chipaca: no, it's a func, is just that my brain conceptuall thought it's a struct [13:34] (because it's kind of response) [13:35] daemon/ does kinda blur the lines [13:35] there are things in there that are funcs that have methods on 'em [13:36] Chipaca: I fixed the descr/commit now [13:36] pedronis: about daemon, I was thinking of slowly (oportunistically) moving api* chunks out to daemon/api/, to separate the api from the daemon bits, and make refactoring the one without breaking the other easier [13:37] pedronis: do you think that might be a good approach for that? [13:37] Chipaca: I don't know, I need to understand a bit more what it entails [13:37] we don't seem close to that [13:37] the tests use daemon often [13:37] and they don't use exported things only either [13:38] yeah [13:38] blackboxing has only just started, in daemon [13:38] or is it whiteboxing [13:38] * Chipaca is colourblind [13:38] Chipaca: more small scale, I'm about to split out one api_*[_test].go file for asserts [13:38] pedronis: nice [13:38] pedronis: and make it daemon_test? [13:39] I don't know is that possible? [13:39] debug stuff isn't doing that for example [13:39] Chipaca: sorry, to be clear, I'm not doing this to cleanup, I want to add a feature (returning json stuff for asserts if asked) [13:40] but I might as well do that first [13:46] pedronis: I've been moving to _test opportunistically :-) [13:47] pedronis: I need to do something about apiBaseSuite to be able to move to the package [13:47] pedronis: it'll come in time [13:48] might be as simple as adding an exported type alias for it [13:48] but, too fiddly to do as an on-the-fly refactor imho [13:56] pstolowski: seems 6568 can be landed [14:01] mvo: *cough* [14:01] ah there you are [14:02] PR snapd#6568 closed: overlord/snapstate: fix restoring of "old-current" revision config in undoLinkSnap === ricab|lunch is now known as ricab [14:32] zyga: is there a request to openSUSE:Factory with snapd already open? [14:33] mborzecki: no, it was automatically closed [14:33] we need to fix our "badness" score by allowing setuid root and polkit policy first [14:33] hmm [14:33] that's why I opened those two bugs about that [14:34] zyga: do you post links to the bugs? [14:35] https://bugzilla.suse.com/show_bug.cgi?id=1127366 and https://bugzilla.suse.com/show_bug.cgi?id=1127368 [14:35] zyga: thanks! [14:42] * zyga goes for lunch [14:59] PR snapd#6581 closed: daemon: move a function that was between an other struct and its methods [15:14] Chipaca, mvo, i'm booting my first core18 image (beaglebone) here and the first boot looks pretty odd doing interactive snap animations (mounting/installing with the spinner and such) on the serial console [15:14] is that intentional ? [15:16] ogra: that sounds odd [15:16] i mean ... it looks fancy ... but a bit out of place between all the system startup messages [15:17] :) [15:18] cachio, are you the guy to refresh the rawhide image? https://github.com/MirServer/mir/pull/749#pullrequestreview-212741294 [15:19] PR MirServer/mir#749: release/1.1 [15:20] ogra: its intentinal but if its too odd its easy to remove [15:21] ogra: it was added mostly to show that things are happing but if its too out-of-place its easy to change [15:22] mvo: I wasn't aware of this [15:22] mvo, well, it looks unusual [15:22] zyga: https://forum.snapcraft.io/t/plans-for-sharing-a-gl-lib/10298/4 [15:22] but i'm not sure if i actually find it too odd after overcoming the first shock ;) [15:25] ogra, pedronis http://paste.ubuntu.com/p/Sjm4j6jXK5/ in core18 is all that is needed to remove the progress [15:26] ah [15:26] I see [15:26] PR core#38 closed: Add another pi-config option [15:26] PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build [15:26] mvo, after letting it sink in i think it is fine ... unless you have a slow enough board that they kick in during console-conf [15:27] PR core#38 opened: Add another pi-config option [15:27] PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build [15:27] ppisati, FYI [15:27] ogra@localhost:~$ uname -a [15:27] Linux localhost 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:34:18 UTC 2019 armv7l armv7l armv7l GNU/Linux [15:27] ogra@localhost:~$ snap list |grep kernel [15:27] pc-kernel 4.15.0-46.49 194 18/edge canonical* kernel [15:27] ogra: console-conf will wait for those [15:27] PR #49: allow (optional) snappy update $pkgname [15:27] mvo, ah, is that new in core18 ? it didnt in core16 [15:27] ogra: correct [15:27] awesome [15:30] re [15:31] mborzecki: ack [15:33] PR snapd#6579 closed: cmd/snap-confine: make sc_args helpers const-correct [15:33] thanks! [15:34] PR snapd#6574 closed: cmd/snap-confine: track per-app and per-hook processes [15:40] * cachio lunch [15:43] ogra@localhost:~$ sudo hostnamectl set-hostname beaglebone [15:43] Could not set property: Failed to set static hostname: Read-only file system [15:43] ogra@localhost:~$ ls -l /etc/writable/ [15:43] total 0 [15:43] ogra@localhost:~$ ls -l /etc/hostname [15:43] lrwxrwxrwx 1 root root 17 Mar 8 10:46 /etc/hostname -> writable/hostname [15:43] mvo, ^^^ [15:44] mborzecki: replied on that thread [15:46] mvo: if you have some time https://github.com/snapcore/snapd/pull/6575 would be enough for me to propose the final bit of the core16 fixup [15:46] PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around [15:46] mborzecki: can you please look at https://github.com/snapcore/snapd/pull/6580? [15:46] PR #6580: cmd/snap-confine: drop unused dependency on libseccomp [15:48] $ sudo timedatectl set-timezone Europe/Berlin [15:48] Failed to set time zone: Failed to set time zone: Read-only file system [15:48] mvo, same for timezone :( [15:49] ogra: *cough* [15:49] ogra: hey, I got a ping about the pi3 gadget snap [15:49] ogra: are builds working there? [15:50] ogra: after fixing the spi interface name supposedly there are no more builds in edge [15:50] zyga, no idea, thats foundation nowadays [15:50] ogra: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 [15:50] ogra: and in addition, someone should plan to release that [15:50] Bug #1778936: please re-add Support-system-image-read-only-etc.patch

[15:50] zyga, same ... also foundations [15:50] ogra: who should I ping? [15:50] ogra: it tells you something about how well our SRUs are working :/ [15:50] ogra: note the date of the patch [15:50] zyga, sil2100 is the one i always ping (priobably wrongly, who knows *g* ) [15:51] sil2100: ^ pi3 gadget snap [15:51] * zyga hugs sil2100 [15:51] thank you! [15:51] On my TODO list, yes o/ [15:51] mvo, well, not a year yet ... let it ripen a bit more :P [15:51] ogra: yeah! I'm not bitter, no no [15:52] DMB meeting now... [15:54] * zyga wishes for a snap of https://github.com/sharkdp/hexyl [15:55] * ogra points zyga to https://forum.snapcraft.io/t/snap-wishlist-suggestions-wanted/567 [15:56] wow that's a LONG thread [15:56] our longest :) [15:56] i blame popey [15:57] we should open a thread "brexit is good for the economy" to beat that ;) [15:57] haha [15:58] ondra, did you ever install avahi alongside lxd on a core image ? ... bad things happen :) [15:58] ogra I think I did [15:58] but tell me more [15:59] well, when lxd brings up its lxdbrX devices somehow avahi considers it needs to attach a -2 to the MDNS hostname [16:00] there seems to be some race somewhere between the two [16:00] and avahi restarts avahid with a $hostname-2.local entry [16:06] PR snapd#6583 opened: cmd/snap-confine: move ubuntu-core fallback checks [16:07] mvo, pedronis: ^ that's the last of the fixes needed for core16 [16:07] (to allow core16 fallback to core) [16:08] I need to EOD now [16:08] I can check the status of stuff and merge things in the evening [16:11] PR snapd#6584 opened: spread.yaml: bump delta referece [16:27] mvo, I see errors like this one during the execution https://paste.ubuntu.com/p/WWJR8dhB7Z/ [16:29] mvo, it breaks all the tests restore [16:35] cachio: hm, hm, this one looks like no snapd is running and system key changed that the same time - if you have access to the system you can probably check if snapd is running [16:35] mvo, cgecjubg [16:35] mvo, is not running [16:36] https://paste.ubuntu.com/p/B9sy66TxMr/ [16:36] mvo, this could help [16:36] yeah [16:44] Chipaca: shouldn't the export_snapshots_test.go etc be called export_api_snapshots_test.go ? [16:44] pedronis: yeah, probably yes [16:45] 'twas the first split one so i might've gotten the pattern wrong ¯\_(ツ)_/¯ [16:45] snap_file is the same [16:48] PR snapcraft#2497 opened: Improved error message for specific cases (type error and bad length) [16:54] PR snapd#6585 opened: tests: add undo test with hanging stop command [16:55] mvo, could you identify the problem with that log, do you need anything else? [16:56] mvo, otherwise I'll kill that vms [16:56] (re from a coffee shop) [16:56] pedronis: replied on https://github.com/snapcore/snapd/pull/6583#discussion_r264330080 [16:56] PR #6583: cmd/snap-confine: move ubuntu-core fallback checks [16:57] zyga: I don't understand the reply [16:57] cachio: I know what I need to know, we need to make sure sandp runs or the system-key is updated when running the rsync code [16:58] mvo, nice [16:58] mvo, that made fail some runs today testing 2.38 [16:59] thanks [17:00] pedronis: oh, sorry, I wanted to say that perhaps the desire to swap the order of the functions to achieve normal mode on core16 bases is correcet but leads to the correct behavior only happening if the fallback logic is triggered. If you don't have any fallback at all (core16 is installed) then then normal mode should be enabled as well, currently is would not. Therefore we need to ensure *that* happens regardless of the [17:00] fallback. [17:00] ? [17:01] maybe we should chat tomorrow [17:01] pedronis: https://github.com/snapcore/snapd/commit/44e59fbd243b7f64d23a47a87e40c0c977274bdf#diff-0c384f3cd817f18339705204e8e7b788R304 should not depend on https://github.com/snapcore/snapd/commit/44e59fbd243b7f64d23a47a87e40c0c977274bdf#diff-0c384f3cd817f18339705204e8e7b788R299 [17:01] pedronis: sure [17:02] zyga: there is only one case where we want no pivot, which is on core 16 if the base is core [17:03]