[00:11] PR snapcraft#2838 opened: add support for system-usernames [00:12] mup: well done! you are quite responsive today! :D [00:12] cjp256: In-com-pre-hen-si-ble-ness. [01:52] PR snapd#7877 opened: tests: avoid mask rsyslog service in case is not enabled on the system [06:27] morning [07:19] good morning [07:33] Good morning [07:33] I will start late today [07:34] Kids have no regular school and nobody woke up early [07:49] zyga: no school today? have i missed something? [07:50] PR snapd#7821 closed: interfaces/seccomp: parallelize seccomp backend setup [08:01] morning [08:04] PR snapd#7872 closed: doc: HACKING.md change autopkgtest-trusty-amd64.img name [08:11] PR snapd#7876 closed: seed: fix seed location of local but asserted snaps [08:21] mborzecki: do you think you could have a look at 7870? [08:21] mvo: sure [08:22] mborzecki: thank you! [08:22] PR snapd#7874 closed: seed: support ModeSnaps(mode) for mode != "run" [08:34] mborzecki: no, theatre and medical examination for Iza and Jan respectively [08:34] Nothing makes the morning lively as a broken jar of jam on the carpet [08:35] But on the upside the carpet was not this clean in weeks [08:35] And I also cleaned the dust filter in Iza’s PC [08:36] Now I only need breakfast and shower an I can get to work [09:44] re [09:44] finally [09:44] everyone's gone and I can work [09:45] I'm on bug triage duty today [10:33] PR snapd#7870 closed: boot,bootloader: setup the snap recovery system bootenv [10:34] PR snapd#7817 closed: boot,bootloader: make MakeBootable() uc20 aware [10:44] PR snapd#7878 opened: cmd/snapd-generator: fix unit name for non /snap mount locations [10:45] zyga: mvo: ^^ trivial fix [10:56] pstolowski: we can try to have our chat about services after the standup today? [10:58] pedronis: great. i'll need a 10 minute break right after the standup for a very quick errand [10:59] pstolowski: that's fine with me [11:00] mvo: suggested comment for one of your follow ups as discussed: https://paste.ubuntu.com/p/PTFrKZGgz5/ [11:04] whoops, forgot to turn on irc today for some reason [11:05] 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] now this might just mean i get more impatient as the test i'm working on progresses :) [11:06] so i need to measure, but, that [11:07] Chipaca: it's not impossible we do quite a few things that in the order of #changes [11:07] pedronis: yup [11:07] pedronis: it shouldn't be perceptible though :) [11:07] in the sense that if it is we might want to fix it [11:07] so i'll be measuring that at some point [11:07] Chipaca: yes, but please channels first [11:07] pedronis: thanks, in a meeting [11:08] mborzecki: mvo: #7873 needs a master merge now I think [11:08] PR #7873: image: set recovery system label when creating the image [11:08] mborzecki: looking [11:08] pedronis: that's the test i'm working on that i saw this in [11:08] just yesterday I read an article about O(n^2) in WMI, maybe we're hitting a similar sweet-spot with changes [11:08] channels i mean [11:08] pedronis: already updated [11:08] mborzecki: thx, just saw that [11:11] pedronis: will do after my meeting, thank you! [11:11] mborzecki did it already [11:11] I also +1ed [11:11] it [11:27] pedronis: \o/ [11:27] pedronis, mborzecki thank you so much! [11:41] PR snapd#7878 closed: cmd/snapd-generator: fix unit name for non /snap mount locations [12:05] PR snapd#7873 closed: image: set recovery system label when creating the image [12:35] PR snapd#7879 opened: [RFC] devicestate: use httputil.ShouldRetryError() in prepareSerialRequest [12:37] PR snapd#7880 opened: snapstate: add support for UC20 gadget in {Config,Gadget}Defaults [12:58] mvo, hey [12:59] mborzecki, hey [12:59] https://paste.ubuntu.com/p/KbBGqQNC2R/ [12:59] after we run some tests the rsyslog remains masked [12:59] an example is ubuntu-core-config-defaults-once [13:00] it happens on ubuntu core 18 [13:00] where the rsyslog is not part of the system [13:00] seems to be a bug [13:00] zyga, ~ [13:01] someone could confirm if it is working as design or it is something to fix? [13:20] hey cachio ! thanks for this report [13:26] mvo, yaw [13:34] cachio: snap-set-core-config needs a fix, but that other test does not, my comment was about the other test [13:38] 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] 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] cachio: are you saying test restore should undo the masking [13:44] cachio: or snapd should undo the masking under some condition? [13:45] zyga, snapd should do it if possible [13:45] cachio: ok, what is the condition when snapd should unmask rsyslog? [13:45] but if not, I'll change the test ot do it in the test [13:45] zyga, in core18 rsyslog is not installed by default [13:46] so we mask it but it not installed [13:52] cachio: do we ever ask snapd to unmask it? [13:52] no [13:52] zyga, but perhaps we should no mask a service which does not exist [13:53] so the fact it is not installed is not relevant [13:53] if it was installed the bug would be back [13:53] we either need to ask snapd to unmask it [13:53] or know about this in global test restore and undo it [13:53] zyga, I can unmask the service in the test [13:53] it is easy [13:54] consider doing that globally as well [13:54] since it is part of the "state" we undo [13:54] zyga, ok [13:54] I am working in another PR to make a set of validations during hte restore [13:54] I'll include that on this one [13:55] sure, as you wish === ricab is now known as ricab|lunch [14:47] pedronis: i'm in, can you hear me? [14:48] pstolowski: sorry, one sec [14:56] * cachio afk 10 mins === ricab|lunch is now known as ricab [15:22] 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] 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] ijohnson: hey [15:43] zyga hey [15:43] ijohnson: you need to set a cohort key via snap set AFAIK [15:43] ijohnson: any number of machines can set the same key [15:43] but how do I create a cohort key [15:43] ? [15:43] ijohnson: and then they will see the same view of revisions [15:43] ijohnson: it's just a string [15:43] AFAIK [15:43] but I can be wrong [15:43] Chipaca: ^ quick help please [15:43] hmm [15:44] * cachio lunch [15:45] ijohnson: snap create-cohort snap-names [15:45] thank you pedronis! [15:46] perfect thanks! [15:47] ijohnson: you can one key per snap [15:47] that you care about [15:49] 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] zyga: in a meeting sorry [15:50] Chipaca: no worries, pedronis already gave the answer [15:51] pedronis, mvo: I am going to start with 7238, then 5822 and 7490 (the priority that pedronis gave me in Vancouver) [15:51] ijohnson: snap create-cohort [15:51] 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] 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] ijohnson: gives you a yaml that you then ship everywhere that wants to use the cohort [15:52] 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] pedronis, mvo: ok, well, that's fine. I'm just going off what you want, but we can have the meeting [15:53] hopefully the list will be a little shorter by then [15:56] 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] pedronis: mvo: so maybe a -pre would be more honest :) [16:07] zyga: hope it was ok to write you per mail directly? [16:07] sdhd-sascha: that's ok, I haven't seen your mail yet though [16:07] I don't really follow email that well (>>>1000 email unread) [16:08] oh [16:36] mvo_: seems lot of Core 20 bits were not in 2.42 but after [16:44] pedronis yeah, that sounds plausible [16:45] pedronis 2.42 is pretty "old" :/ [16:45] pedronis why is it a concern? is anyone using stable for uc20? === mvo_ is now known as mvo [16:49] 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] ah, limitations in snapd, got it [16:50] Chipaca: ah, let me find it [16:50] ah you found it :D [16:50] sorry [16:51] zyga: context is https://forum.snapcraft.io/t/updates-delete-user-application-data/14568 fwiw [16:55] zyga: just want to say that you can also give me some tasks. [16:57] sdhd-sascha: if you want to get into development my best advice would be follow code reviews [16:57] we have lots of things going on [16:58] and we have a specific style of interaction that may not be common in other projects [16:58] most churn goes into RPs at the top of the list [16:58] older PRs tend to "sink" to the bottom where they see less activity [16:58] reviewing code has two benefits: you get to familiarize yourself with what's going on and where [16:58] and you get to see how the review process looks like [16:59] note, I have not read your mail yet [17:02] jdstrand: thanks for your feedback earlier, I will think about it [17:22] PR snapd#7768 closed: interfaces: add raw-volume interface for access to partitions [17:23] jdstrand: I merged ^ , now 7875 has some conflicts [17:24] pedronis: thanks and ack (weird, I branched off my last commit to raw-volume, but I'll fix) [17:25] jdstrand: it's likely because I squased 7768 because there was too much back and forth in its history [17:26] hm, 7830 has two +1 and is green - can I merge it? [17:27] mvo: it would be ok for me [17:29] ta [17:30] PR snapd#7830 closed: interfaces: include hooks in plug/slot apparmor label [18:17] 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] 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] Bug #1806070: snapd.seeded.service never completes preventing full boot to default target

[20:26] degville: hey, fyi, took a stab at https://forum.snapcraft.io/t/the-raw-volume-interface/14578 [20:40] jdstrand: brilliant, thanks you! [20:52] 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] ogra: will do. Thanks, I'll try grabbing more details about the symptoms I'm seeing and file fresh [20:53] worth opening a bug or snapcraft forum discussion? [20:53] (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] thx will do [20:53] 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] ok thanks [21:08] * cachio eod [21:34] zyga: it's not urgent. but maybe, you have a hint for me. I want to allow access to /run/systemd/sessions/ . No i found that commonFilesInterface doesn't allow apparmor wildcards... Is there another where, instead of using "system-files" ? [21:35] zyga: sorry... "login-session-observe" [21:35] i found it [22:30] PR pc-amd64-gadget#25 opened: Fix kernel path in recovery grub.cfg [22:31] degville: fyi, one more for you: https://forum.snapcraft.io/t/the-login-session-observe-interface/14580 [22:47] sdhd-sascha: I think /run is special cased to be off-limits by some of the special interfaces [22:47] sdhd-sascha: ping me tomorrow please [22:47] zyga: login_session_observe from jdstrand, 18 days ago seems to work [22:48] sdhd-sascha: that's cool, I meant that the generic "gimme a path" interfaces may not work [22:48] zyga: i have found a missing apparmor method in login-session-control [22:48] i will push it later [22:48] obviously a precise interface can open any location [22:48] ok [22:48] but i didn't found a interface for policykit ... [22:48] but let's talk tomorrow [22:49] "gimme a path" ? [22:50] zyga: good night [22:56] PR pc-amd64-gadget#25 closed: Fix kernel path in recovery grub.cfg [23:07] jdstrand: looks good - thanks for letting me know! [23:07] np [23:14] PR snapd#7881 opened: login-session-control - added missing dbus commands [23:47] rbasak: fyi, I haven't forgotten about certbot. it is first up tomorrow