[00:11] <mup> PR snapcraft#2838 opened: add support for system-usernames <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2838>
[00:12] <cjp256> mup: well done! you are quite responsive today! :D
[00:12] <mup> cjp256: In-com-pre-hen-si-ble-ness.
[01:52] <mup> PR snapd#7877 opened: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>
[06:27] <mborzecki> morning
[07:19] <sdhd-sascha> good morning
[07:33] <zyga> Good morning
[07:33] <zyga> I will start late today
[07:34] <zyga> Kids have no regular school and nobody woke up early
[07:49] <mborzecki> zyga: no school today? have i missed something?
[07:50] <mup> PR snapd#7821 closed: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
[08:01] <pstolowski> morning
[08:04] <mup> PR snapd#7872 closed: doc: HACKING.md change autopkgtest-trusty-amd64.img name <Created by sd-hd> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7872>
[08:11] <mup> PR snapd#7876 closed: seed: fix seed location of local but asserted snaps <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7876>
[08:21] <mvo> mborzecki: do you think you could have a look at 7870?
[08:21] <mborzecki> mvo: sure
[08:22] <mvo> mborzecki: thank you!
[08:22] <mup> PR snapd#7874 closed: seed: support ModeSnaps(mode) for mode != "run" <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7874>
[08:34] <zyga> mborzecki: no, theatre and medical examination for Iza and Jan respectively
[08:34] <zyga> Nothing makes the morning lively as a broken jar of jam on the carpet
[08:35] <zyga>  But on the upside the carpet was not this clean in weeks
[08:35] <zyga> And I also cleaned the dust filter in Iza’s PC
[08:36] <zyga> Now I only need breakfast and shower an I can get to work
[09:44] <zyga> re
[09:44] <zyga> finally
[09:44] <zyga> everyone's gone and I can work
[09:45] <zyga> I'm on bug triage duty today
[10:33] <mup> PR snapd#7870 closed: boot,bootloader: setup the snap recovery system bootenv <UC20> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7870>
[10:34] <mup> PR snapd#7817 closed: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7817>
[10:44] <mup> PR snapd#7878 opened: cmd/snapd-generator: fix unit name for non /snap mount locations <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7878>
[10:45] <mborzecki> zyga: mvo: ^^ trivial fix
[10:56] <pedronis> pstolowski: we can try to have our chat about services after the standup today?
[10:58] <pstolowski> pedronis: great. i'll need a 10 minute break right after the standup for a very quick errand
[10:59] <pedronis> pstolowski: that's fine with me
[11:00] <pedronis> mvo: suggested comment for one of your follow ups as discussed:  https://paste.ubuntu.com/p/PTFrKZGgz5/
[11:04] <Chipaca> whoops, forgot to turn on irc today for some reason
[11:05] <Chipaca> only realised because i thought to share: i need to measure, but the impression i get is that interacting with snapd perceptibly slows down as the number of changes grows
[11:05] <Chipaca> now this might just mean i get more impatient as the test i'm working on progresses :)
[11:06] <Chipaca> so i need to measure, but, that
[11:07] <pedronis> Chipaca: it's not impossible we do quite a few things that in the order of #changes
[11:07] <Chipaca> pedronis: yup
[11:07] <Chipaca> pedronis: it shouldn't be perceptible though :)
[11:07] <Chipaca> in the sense that if it is we might want to fix it
[11:07] <Chipaca> so i'll be measuring that at some point
[11:07] <pedronis> Chipaca: yes, but please channels first
[11:07] <mvo> pedronis: thanks, in a meeting
[11:08] <pedronis> mborzecki: mvo: #7873 needs a master merge now I think
[11:08] <mup> PR #7873: image: set recovery system label when creating the image <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7873>
[11:08] <zyga> mborzecki: looking
[11:08] <Chipaca> pedronis: that's the test i'm working on that i saw this in
[11:08] <mborzecki> just yesterday I read an article about O(n^2) in WMI, maybe we're hitting a similar sweet-spot with changes
[11:08] <Chipaca> channels i mean
[11:08] <mborzecki> pedronis: already updated
[11:08] <pedronis> mborzecki: thx, just saw that
[11:11] <mvo> pedronis: will do after my meeting, thank you!
[11:11] <pedronis> mborzecki did it already
[11:11] <pedronis> I also +1ed
[11:11] <pedronis> it
[11:27] <mvo> pedronis: \o/
[11:27] <mvo> pedronis, mborzecki thank you so much!
[11:41] <mup> PR snapd#7878 closed: cmd/snapd-generator: fix unit name for non /snap mount locations <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7878>
[12:05] <mup> PR snapd#7873 closed: image: set recovery system label when creating the image <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7873>
[12:35] <mup> PR snapd#7879 opened: [RFC] devicestate: use httputil.ShouldRetryError() in prepareSerialRequest <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7879>
[12:37] <mup> PR snapd#7880 opened: snapstate: add support for UC20 gadget in {Config,Gadget}Defaults <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7880>
[12:58] <cachio> mvo, hey
[12:59] <cachio> mborzecki, hey
[12:59] <cachio> https://paste.ubuntu.com/p/KbBGqQNC2R/
[12:59] <cachio> after we run some tests the rsyslog remains masked
[12:59] <cachio> an example is ubuntu-core-config-defaults-once
[13:00] <cachio> it happens on ubuntu core 18
[13:00] <cachio> where the rsyslog is not part of the system
[13:00] <cachio> seems to be a bug
[13:00] <cachio> zyga, ~
[13:01] <cachio> someone could confirm if it is working as design or it is something to fix?
[13:20] <mvo> hey cachio ! thanks for this report
[13:26] <cachio> mvo, yaw
[13:34] <mborzecki> cachio: snap-set-core-config needs a fix, but that other test does not, my comment was about the other test
[13:38] <cachio> mborzecki, my question is about the problem seems to be in snapd itself because it leaves the rsyslog as masked in case hte service does not exist in the system
[13:39] <cachio> I mean, in case rsyslog does not exist, when we restore everyting in the test the rsyslog service should not appear any more in systemd right?
[13:44] <zyga> cachio: are you saying test restore should undo the masking
[13:44] <zyga> cachio: or snapd should undo the masking under some condition?
[13:45] <cachio> zyga, snapd should do it if possible
[13:45] <zyga> cachio: ok, what is the condition when snapd should unmask rsyslog?
[13:45] <cachio> but if not, I'll change the test ot do it in the test
[13:45] <cachio> zyga, in core18 rsyslog is not installed by default
[13:46] <cachio> so we mask it but it not installed
[13:52] <zyga> cachio: do we ever ask snapd to unmask it?
[13:52] <cachio> no
[13:52] <cachio> zyga, but perhaps we should no mask a service which does not exist
[13:53] <zyga> so the fact it is not installed is not relevant
[13:53] <zyga> if it was installed the bug would be back
[13:53] <zyga> we either need to ask snapd to unmask it
[13:53] <zyga> or know about this in global test restore and undo it
[13:53] <cachio> zyga, I can unmask the service in the test
[13:53] <cachio> it is easy
[13:54] <zyga> consider doing that globally as well
[13:54] <zyga> since it is part of the "state" we undo
[13:54] <cachio> zyga, ok
[13:54] <cachio> I am working in another PR to make a set of validations during hte restore
[13:54] <cachio> I'll include that on this one
[13:55] <zyga> sure, as you wish
[14:47] <pstolowski> pedronis: i'm in, can you hear me?
[14:48] <pedronis> pstolowski: sorry, one sec
[14:56]  * cachio afk 10 mins
[15:22] <ijohnson> hey folks, quick question how can I create cohorts for a demo of how they work? (maybe pedronis can point me in the right direction?)
[15:31] <jdstrand> pedronis: hey, can you take a look at https://forum.snapcraft.io/t/synchrorep-need-classic-confinement/13347/8 (and https://forum.snapcraft.io/t/synchrorep-need-classic-confinement/13347/9). no need to say anything unless you want to overrule me
[15:43] <zyga> ijohnson: hey
[15:43] <ijohnson> zyga hey
[15:43] <zyga> ijohnson: you need to set a cohort key via snap set AFAIK
[15:43] <zyga> ijohnson: any number of machines can set the same key
[15:43] <ijohnson> but how do I create a cohort key
[15:43] <ijohnson> ?
[15:43] <zyga> ijohnson: and then they will see the same view of revisions
[15:43] <zyga> ijohnson: it's just a string
[15:43] <zyga> AFAIK
[15:43] <zyga> but I can be wrong
[15:43] <zyga> Chipaca: ^ quick help please
[15:43] <ijohnson> hmm
[15:44]  * cachio lunch
[15:45] <pedronis> ijohnson: snap create-cohort snap-names
[15:45] <zyga> thank you pedronis!
[15:46] <ijohnson> perfect thanks!
[15:47] <pedronis> ijohnson: you can one key per snap
[15:47] <pedronis> that you care about
[15:49] <jdstrand> pedronis, mvo: fyi, I'm going through store reviews today and then moving to PR reviews https://github.com/snapcore/snapd/pulls/review-requested/jdstrand (jeez, a ton came in since the sprint)
[15:50] <Chipaca> zyga: in a meeting sorry
[15:50] <zyga> Chipaca: no worries, pedronis already gave the answer
[15:51] <jdstrand> pedronis, mvo: I am going to start with 7238, then 5822 and 7490 (the priority that pedronis gave me in Vancouver)
[15:51] <Chipaca> ijohnson: snap create-cohort
[15:51] <jdstrand> pedronis, mvo: fyi, I had a huge pile of stuff that accumulated due to sprint prep, sprint immediate asks, postsprint catchup, then holidays
[15:51] <pedronis> jdstrand: yes, that's why we setup a meeting later in the week to try to prioritize those a bit, and reunderstand the very old ones
[15:52] <Chipaca> ijohnson: gives you a yaml that you then ship everywhere that wants to use the cohort
[15:52] <jdstrand> pedronis, mvo: which is why I am behind. we can meet on thur as requested, but honestly, I'd prefer an email with the PRs in the priority you'd like them reviewed. then I can work that list and give updates until it is done
[15:53] <jdstrand> pedronis, mvo: ok, well, that's fine. I'm just going off what you want, but we can have the meeting
[15:53] <jdstrand> hopefully the list will be a little shorter by then
[15:56] <Chipaca> pedronis: mvo: as a conclusion I don't think we need to block cutting the next release, but we do need to not actually release it without the TBD fixes
[15:56] <Chipaca> pedronis: mvo: so maybe a -pre would be more honest :)
[16:07] <sdhd-sascha> zyga: hope it was ok to write you per mail directly?
[16:07] <zyga> sdhd-sascha: that's ok, I haven't seen your mail yet though
[16:07] <zyga> I don't really follow email that well (>>>1000 email unread)
[16:08] <sdhd-sascha> oh
[16:36] <pedronis> mvo_: seems lot of Core 20 bits were not in 2.42 but after
[16:44] <mvo_> pedronis yeah, that sounds plausible
[16:45] <mvo_> pedronis 2.42 is pretty "old" :/
[16:45] <mvo_> pedronis why is it a concern? is anyone using stable for uc20?
[16:49] <Chipaca> zyga: what was the name of the forum thing where we document some missing things in snapd, like homes needing to be there all the time?
[16:49] <Chipaca> ah, limitations in snapd, got it
[16:50] <zyga> Chipaca: ah, let me find it
[16:50] <zyga> ah you found it :D
[16:50] <zyga> sorry
[16:51] <Chipaca> zyga: context is https://forum.snapcraft.io/t/updates-delete-user-application-data/14568 fwiw
[16:55] <sdhd-sascha> zyga: just want to say that you can also give me some  tasks.
[16:57] <zyga> sdhd-sascha: if you want to get into development my best advice would be follow code reviews
[16:57] <zyga> we have lots of things going on
[16:58] <zyga> and we have a specific style of interaction that may not be common in other projects
[16:58] <zyga> most churn goes into RPs at the top of the list
[16:58] <zyga> older PRs tend to "sink" to the bottom where they see less activity
[16:58] <zyga> reviewing code has two benefits: you get to familiarize yourself with what's going on and where
[16:58] <zyga> and you get to see how the review process looks like
[16:59] <zyga> note, I have not read your mail yet
[17:02] <mvo> jdstrand: thanks for your feedback earlier, I will think about it
[17:22] <mup> PR snapd#7768 closed: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7768>
[17:23] <pedronis> jdstrand: I merged ^ , now 7875 has some conflicts
[17:24] <jdstrand> pedronis: thanks and ack (weird, I branched off my last commit to raw-volume, but I'll fix)
[17:25] <pedronis> jdstrand: it's likely because I squased 7768 because there was too much back and forth in its history
[17:26] <mvo> hm, 7830 has two +1 and is green - can I merge it?
[17:27] <pedronis> mvo: it would be ok for me
[17:29] <mvo> ta
[17:30] <mup> PR snapd#7830 closed: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7830>
[18:17] <sdhd-sascha> jdstrand: hi. If i understand it right, then classic will be in future only supported in a few cases. For me it's ok if you write into the forum, that it want be supported and there will be soon other ways to launch other applications. E.g. "app-launch". Then i can close my issue on github and point to the forum. I personally want to concentrate on the strict wayland snap.
[20:10] <blackboxsw> hi folks, are people seeing issues where snapd.seeded never completes on lxc (disco && eoan) https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1806070?
[20:10] <mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1806070>
[20:26] <jdstrand> degville: hey, fyi, took a stab at https://forum.snapcraft.io/t/the-raw-volume-interface/14578
[20:40] <degville> jdstrand: brilliant, thanks you!
[20:52] <ogra> blackboxsw, given that bug was fixed a year ago, you should really better open a fresh one ... (your error also does look different, snapd isnt stuck in the "Doing" state for the initialization but actually errored)
[20:52] <blackboxsw> ogra: will do. Thanks, I'll try grabbing more details about the symptoms I'm seeing and file fresh
[20:53] <blackboxsw> worth opening a bug or snapcraft forum discussion?
[20:53] <ogra> (you probably want to include the output of "snap tasks 1" as well)
[20:53]  * blackboxsw reads : https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38 
[20:53] <blackboxsw> thx will do
[20:53] <ogra> i'd open a bug ... but thats really up to you, the snapd guys look at both, launchapd as well as the forum
[20:53] <blackboxsw> ok thanks
[21:08]  * cachio eod
[21:34] <sdhd-sascha> zyga: it's not urgent. but maybe, you have a hint for me. I want to allow access to /run/systemd/sessions/<id> . No i found that commonFilesInterface doesn't allow apparmor wildcards... Is there another where, instead of using "system-files" ?
[21:35] <sdhd-sascha> zyga: sorry... "login-session-observe"
[21:35] <sdhd-sascha> i found it
[22:30] <mup> PR pc-amd64-gadget#25 opened: Fix kernel path in recovery grub.cfg <Created by cmatsuoka> <https://github.com/snapcore/pc-amd64-gadget/pull/25>
[22:31] <jdstrand> degville: fyi, one more for you: https://forum.snapcraft.io/t/the-login-session-observe-interface/14580
[22:47] <zyga> sdhd-sascha: I think /run is special cased to be off-limits by some of the special interfaces
[22:47] <zyga> sdhd-sascha: ping me tomorrow please
[22:47] <sdhd-sascha> zyga: login_session_observe from jdstrand, 18 days ago seems to work
[22:48] <zyga> sdhd-sascha: that's cool, I meant that the generic "gimme a path" interfaces may not work
[22:48] <sdhd-sascha> zyga: i have found a missing apparmor method in login-session-control
[22:48] <sdhd-sascha> i will push it later
[22:48] <zyga> obviously a precise interface can open any location
[22:48] <zyga> ok
[22:48] <sdhd-sascha> but i didn't found a interface for policykit ...
[22:48] <sdhd-sascha> but let's talk tomorrow
[22:49] <sdhd-sascha> "gimme a path" ?
[22:50] <sdhd-sascha> zyga: good night
[22:56] <mup> PR pc-amd64-gadget#25 closed: Fix kernel path in recovery grub.cfg <Created by cmatsuoka> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/25>
[23:07] <degville> jdstrand: looks good - thanks for letting me know!
[23:07] <jdstrand> np
[23:14] <mup> PR snapd#7881 opened: login-session-control - added missing dbus commands <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7881>
[23:47] <jdstrand> rbasak: fyi, I haven't forgotten about certbot. it is first up tomorrow