[05:16] morning [06:03] Good morning [06:03] I will be around in 30 [06:07] zyga: hey [06:17] Hey :-) [06:17] Good to be back [06:39] mvo: morning [06:41] hey mborzecki ! good morning and welcome back [06:44] mvo: anything interesting happened last week? [06:50] o/ [06:51] I would love to know as well [06:52] * zyga checks email and other administrativa [06:58] zyga: mvo started with some cgroupv2 work https://github.com/snapcore/snapd/pull/7109 [06:58] PR #7109: [RFC] snap-confine: fallback gracefully on a cgroup v2 only system [07:02] mborzecki: reviewing [07:03] mborzecki: hm, not that much, but we did push some PRs forward so that was good [07:05] mvo: i saw systemd guys pushed a fix for the mount problem we saw [07:05] mborzecki: yes, I saw that too, iirc I even added a card in trello [07:06] Speaking of pushing prs forward, can anyone look into approving my cla for this? https://github.com/snapcore/snapd/pull/7129 [07:06] mborzecki: I looked at it briefly but even backporting to bionic did not look trivial [07:06] PR #7129: userd: allow setting default-url-scheme-handler [07:06] mvo: reviewed [07:06] jwheare: hey, let me look :) [07:06] mvo: who can approve CLA things? [07:07] mborzecki: but *maybe* its not hard, I have not looked but it definitely needs some prereq patches [07:07] zyga: it should be enough to click through this web thing we have [07:07] mvo: which web thing? [07:07] mvo: i had some scripts to build the image with a version of systemdd from source, perhaps i could try that now [07:07] * mvo looks [07:07] mborzecki: that would be great [07:08] I submitted the web form [07:08] mborzecki: I looked over the patch and it all seems to make sense [07:08] jwheare: hey, sorry that you have trouble, let me try to find out what is going on [07:08] jwheare: normally the web form should be fine [07:08] Had no idea what to put in the “project manager contact” field tho [07:09] And was a bit uncomfortable having to leave address and phone number with no explicit note on privacy on that page. [07:09] But I think I did it right? [07:09] mvo: I think the web thing is still a queue for someone to approve [07:10] jwheare: I need to inquire, I can't see these forms myself (and I think only very very few people can for the privacy reasons you mentioned above). btw, I can ask to clarify the privacy policy around the address [07:11] zyga: I will find out, its possible [07:11] zyga: I *thought* it got automated but maybe I misremember, if not automatic its not ideal on e.g. weekends :/ [07:11] mvo: hm perhaps there should be an explicit note given GDPR and such [07:11] It’s this thing https://ubuntu.com/legal/contributors/agreement [07:12] mborzecki: exactly [07:12] The pr template and contibuting.md should mention what to put in “Project contact” imo [07:12] jwheare: that looks good, is your launchpad-id the same as your irc nick? [07:12] mvo: building an image with latest systemd [07:12] mvo: nope it’s l-james [07:12] jwheare: excellent suggestion, let me fix that too [07:13] Email is james@wheare.org [07:14] jwheare: thank you! [07:20] Thanks for taking a look :) [07:22] jwheare: thanks, mail sent, I will get back to you as soon as I get a reply (but this involves legal people so things might be not super fast :/ [07:25] jwheare: thanks for the PR too, that looks pretty good - did you see the concern that james hensdrige had? [07:40] mvo: not really :) [07:41] afaik there's a dialog prompt when setting this anyway, it's pretty common functionality, and as james stated, it's no more of a concern than setting the default browser [07:41] mvo: hi, sorry created quite a few PRs Friday and over the weekend, they have all cards now pointing to them [07:46] pedronis: thank you! [07:47] jwheare: ok, I have not looked myself in depth yet, just skimmed the comments will do so later [07:47] * mvo needs a cup of tea first :) [07:51] mvo: so far so good, cannot reproduce the mount problem with the script i used here https://github.com/systemd/systemd/issues/10872#issue-383105075 [07:54] mborzecki: awsome [07:55] mborzecki: I guess we should explore how much work a backport would be [07:55] mborzecki, zyga another "fun" issue last week: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836914 [07:55] Bug #1836914: Doing multiple squashfs (and other loop?) mounts in parallel breaks

[07:56] mvo: heh, that sounds familiar to the forum topic i opened [07:56] mvo: we landed a fix for this, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824226 no ? [07:57] mvo: john has assisted someone with this problem https://forum.snapcraft.io/t/cannot-launch-snaps-on-eoan-and-kernel-5-2/12341 and it looked the same as on arch [08:04] * mvo is in a meeting right now, so appologies for not replying [08:06] mvo: bad news, i can still reproduce the mount problem [08:13] popey_: you working today? [08:17] ya, back at my desk today [08:19] cool, in that case then, we've had a person approach from irccloud: https://github.com/snapcrafters/irccloud-desktop/issues/22 [08:19] oooooh [08:19] I'll take a look once I'm off the phone [08:19] cool [08:25] hi that's me :) [08:25] Oh hai! [08:25] Just talking about this on my current phone call with my boss. [08:25] Will reply to it once I get off the phone [08:26] cool! just heading to the dentist, be back to chat in about half an hour [08:26] groovy! [08:27] hi jwheare. Thanks for the PR :-) [08:28] pedronis: productive weekend for you i see [08:34] awesome :-) [08:35] mvo, hi, we noticed the block-devices interface intentionally doesn't allow access to partitions, what's the reason for it? [08:37] * diddledan hums.. humm.. the sailor man.. [08:37] do do do de do do 'cos I eat's me spinich [08:37] :-p [08:37] * diddledan is evil [08:47] mvo, hey, morning! I've noticed the classic snap in the 18 track is only published for amd64, is there any plan to publish it for other archs? [08:50] back [08:50] o/ [08:50] \o [08:50] '\o/' [08:51] * popey_ installs irccloud [08:51] diddledan: the main blocker we have now is a permissions error that crashes the app whenever the config file is written to (happens on quit) [08:52] jwheare: where is that config file being written to? [08:52] i think it snuck in on a round of dep updates, since your last released build (0.11.0) [08:52] popey_: just the standard userdata dir. the issue is kind of convoluted [08:52] i bumped irccloud-desktop to 0.12.0 the other day. [08:52] spread across a few github issues [08:52] ah [08:53] https://github.com/sindresorhus/conf/pull/82 [08:53] PR sindresorhus/conf#82: fix: do not use chown on write - system default permissions is enough [08:54] hello from irccloud snap [08:54] that works then :) [08:54] One question we haven't discussed, is the name. [08:55] Once these blockers are solved, do you want to keep irccloud, or would you like us to transfer irccloud-desktop to you? [08:55] We can't rename snaps in the store, but we can "encourage" existing irccloud-desktop users to move over [08:55] (not automatically, but they can be nagged to do it) [08:55] mvo: left a note https://github.com/systemd/systemd/issues/10872#issuecomment-513703519 :/ [08:55] irccloud is our preferred name, but would be nice if irccloud-desktop could be "merged"... ah, ok. well it's not a huge deal [08:56] nagging probably works well enough [08:56] We did this with the vscode snap, to move them to code, and it works well enough [08:56] active users will get punched in the face with a dialog to "recommend" they move over [08:56] we can replace the irccloud-desktop with a neutered snap that just says "not 'ere, guv'" [08:56] it's annoying enough to make people want to move over [08:57] well, the irccloud-desktop snap "only" has a few hundred users. [08:57] dialog sounds good [08:57] copy approved [08:57] We could use this as an opportunity to promote the irccloud snap, to highlight it and help raise awareness of the app iself / service, and get people moving [08:57] hah [09:09] https://src.fedoraproject.org/rpms/gnome-software/pull-request/1 this thread is horrible [09:09] anyone who ever says "*buntu is evil" should read it [09:11] Not convinced that is a useful assertion to make in a public place zyga [09:11] * diddledan edits history [09:11] oh wait, this isn't telegram [09:12] I will just ignore this topic for now, work on productive stuff instead [09:13] That's the spirit! :D [09:29] mvo: I'm removing lxd now, let's see what happens, this is an easier way to fix this [09:30] (for context: Qemu and google images differ in preinstalled package sets, this makes fighting tests leaking side-effects easier) [09:30] mborzecki: uh, ok - if you can still reproduce the mount problem, mind to tell upstream? [09:30] ackk: probably best to ask jdstrand why/if block-devices interface intentionally doesn't allow access to partitions [09:31] mvo: yup, already left a note under the issue [09:31] abeato: classic core18> I need to look [09:31] mvo, thanks, will ping him later [09:33] mvo: i'm double checking this on fedora 30 too, it's using 5.1 kernel and he probably used that during development, that would rule out any arch specific issues [09:34] mvo, ack, thanks [09:44] jwheare: on the subject of irccloud. Is it possible to globally disable logging for a particular irc server / network? [09:45] not at the moment. the usefulness of the service hinges pretty hard on logging. however, we do have plans for limited log retention policies [09:45] jwheare: yeah, I figured as much. I can imagine *whisltes* certain corporations that use irc a lot might not be happy about a 3rd party having access to all that text [09:46] but "no logging" is a bit tricky. would make things like system or app restarts very destructive, even if you're privacy concious [09:46] I wonder if people would be happier if they were encrypted with a personal key [09:46] but something like a 7 day retention policy is probably reasonable [09:46] but that's quite a lot to do [09:47] encryption is a whole other kettle of fish [09:47] btw, I *love* that you can easily add slack channels to irccloud and it looks and behaves just like irc [09:49] proper e2e has similar unwanted effects to no logging, i've often been baffled when e.g. signal completely forgets who i am and who i've communicated with if i simply stop using it for a few months [09:49] yeah, wire is similar. messages just disappear [09:50] but having an off the record mode you can toggle for sensitive private messages would make sense [09:50] #7134 is quite simple and avoids running some test suite tests twice [09:50] PR #7134: image: clean up the validateSuite [09:50] brb [09:52] mvo: well, same thing on fedora [09:57] mborzecki: thanks [09:59] abeato: I released classic/18 to edge now (and also building a new one) [10:00] mvo, nice, thanks! will give it a go for arm64 [10:01] abeato: thank you, I think I never tested it there so please keep me updated [10:01] sure thing [10:01] ta - if it works for you I will move it to beta [10:06] jwheare: hey, I got feedback, the process is manual so it may take a little bit but I did ping the right ppl so hopefully its reaosnable quick. they will also add a link to the table where each software project lists the respective project lead and clarify the privacy bits [10:06] jwheare: thanks again for raising this! [10:11] jwheare: Thanks for publishing `ircloud` to the edge channel. I've switched to it here 👍 [10:12] mvo: great to hear, thanks for following up [10:13] Wimpress: nice, let me know if you encounter any issues beyond the known problems here https://github.com/irccloud/irccloud-desktop/issues/142 [10:13] Will do. [10:14] That EPERM crash on quit/config change being the main one [10:26] jwheare: That crash on exit recently started happening in the community maintained `irccloud-desktop` snap. [10:26] But this is a new issue. Hadn't ever seen it until recently. [10:28] I must say, I so rarely close it I hadn't noticed that issue [10:28] And that. [10:28] Window resize/move might trigger it too [10:28] Or toggling full screen [10:32] actually those only get set on quit. but adjusting zoom level will crash i think [11:15] jdstrand, hi, mind giving an opinion on https://bugs.launchpad.net/snapd/+bug/1837369 ? [11:15] Bug #1837369: Read-only interface for block devices

[11:25] PR snapd#7136 opened: tests: part4 making tests work on ubuntu-core-18 [11:26] ogra: do you have a json file that i can use to build a pi3 core 18 image? [11:34] ogra: nm, typo [11:48] ppisati, nope, but there are some on the forum, th eonly core18 image i personally have is for pi4 currently [11:49] forum post is here: https://forum.snapcraft.io/t/model-assertions-for-core18/6870 [11:58] hey ijohnson :) [12:02] morning zyga [12:02] * ijohnson needs coffee, brb [12:28] PR snapd#7134 closed: image: clean up the validateSuite === cmatsuoka is now known as cmatsuoka_debcon === cmatsuoka_debcon is now known as cmatsuoka [13:11] PR snapd#7137 opened: gadget: support for writing symlinks [13:49] ijohnson: I have one more change to mountinfo-tool, when working on the test I realised that any change to the initial mount namespace ripples to per-snap and per-user simply because mount IDs and peer group numbers are consecutive. I had the idea to use a 1000 x "depth" as base, so on host the numbers start from zero, on per-snap they start from 1000 and per-user they start from 2000. I'll push that soon [13:50] zyga: ack I can review that today [13:50] thanks! [13:59] had to turn off the camera because my laptop was literally melting the placemat i had it on [14:00] i hope it un-warps when it cools back down =( [14:00] pedronis, mvo, niemeyer: I posted https://forum.snapcraft.io/t/netplan-apply-inside-snaps/12411 as a starting point for our discussions [14:01] ijohnson: was looking at it , it reflects the current thinking, can you add a note that the attributre is similar to how browser-suppoer allow-sandbox work [14:01] s [14:01] pedronis: sure [14:01] thx [14:02] ijohnson: thank you! [14:04] np, let me know if y'all have time for a meeting today to discuss [14:11] ijohnson: I setup something, does that time work for you? [14:12] mvo: yes [14:30] jdstrand, hi, around? [14:30] zyga: omg, silly typo [14:31] mborzecki: haha [14:31] mborzecki: I was preparing this nice batch for you [14:31] but you pushed :) [14:31] zyga: didn't push, not yet ;) [14:31] ah, my bad, sorry [14:31] GH changed the UI again [14:32] zyga: ha, can't craete a batch on gh, wtf? [14:32] you can but I opted not to because I cannot commit [14:32] you can batch commit [14:32] not batch suggest [14:33] zyga: nah, 'add suggestion to batch' is greyed out [14:33] mvo: question for you about some code you last touched in 2016 … /o\ [14:33] nvm, i'll push a patch [14:38] ackk: I answered in the bug [14:39] mvo: fyi, block-devices intentionally does not allow access to partitions (it is a comment in the interface code) [14:40] jdstrand, yes, we do use hardware-observe [14:41] jdstrand, btw I reopened https://bugs.launchpad.net/snapd/+bug/1831473 with a comment [14:41] Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap [14:42] ackk: I saw that [14:42] ackk: it should probably be a new bug, but that is fine [14:42] jdstrand, hardware-observe doesn't let you read /dev/sd* or other block devices though [14:43] ackk: please connect the interfaces, run in devmode and add the policy violation to the bug [14:44] violations* [14:44] jdstrand, will do, thanks [14:45] Chipaca: what question (in a meeting so might be slow to reply) [14:45] Chipaca: 2016 sounds scary [14:45] jdstrand, sorry, one more question, related to snap_daemon. if a process spawn a subprocess which runs as snap_daemon, there's no way for the spawning process it to kill it right? [14:46] mvo: tracing the code back it seems to be a can't-happen, but just in case: if overlord/snapstate/booted.go's UpdateBootRevisions would never actually run in snap_mode=="trying", right? [14:46] s/if// [14:47] ackk: also, in https://launchpad.net/bugs/1831473, can you comment wrt https://github.com/snapcore/snapd/blob/master/interfaces/builtin/hardware_observe.go#L112 [14:47] Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap [14:47] jdstrand, you mean mention that we're using the interface? [14:48] oh I see, hardware-observe has permission for /proc/1/sched commented out [14:48] ackk: no, I mean, read the comment at line 112 and then comment in the bug relative to it. I'm surprised you are seeing it [14:49] PR snapd#7138 opened: tests: remove lxd / lxcfs if pre-installed [14:50] PR snapd#7139 opened: tests: don't leak /run/netns mount [14:50] ackk: ackk as for the other question, let me check something [14:51] jdstrand, I see pid 1 in /proc/1/sched both in my system and in a container [14:52] jdstrand, I don't see /proc/1/sched inside the snap, if that's what you mean. which seems to be the issue with systemd-detect-virt [14:52] ackk: can you comment in the bug? this should be non-fatal. comment on if systemd-detect-virt is reporting the wrong thing [14:53] PR snapd#7140 opened: overlord/devicestate: update gadget update handlers and mocks [14:54] jdstrand, I mean, I don't know if that's what's making s-d-v fail. but it does fail in a VM, and I see the denial [14:55] jdstrand, in a container, s-d-v works and I don't see the denial [14:55] jdstrand, which seems to point at the fact that it's not trying to read that file in a container (since /sched is not readable there as well) [14:56] * cachio lunch [15:00] PR snapd#7141 opened: tests: add mountinfo-tool --ref-x1000 [15:03] ijohnson: 7141 is the one I mentioned before [15:03] I will look at reviews now, just need a small break [15:07] zyga: ack will take a look [15:07] ijohnson: thanks! [15:19] ackk: ok, atm, depending on how your application is written, there are times when it is currently expected that you can't kill the child [15:20] ackk: the policy is lacking 'capability kill,'. I need to think through how to allow that [15:21] jdstrand, I see. so basically our current case is that we have supervisord spawn a process, which drops privileges to snap_daemon. it seems when supervisord needs to kill it, it doesn't happen [15:21] ackk: so if you have root, that spawns a child that drops, then you will run into this. if you have a process that drops, then spawns a child, it will be able to send signals [15:22] ackk: that is consistent with what I described and the current policy [15:22] I need to think through how to expose this [15:22] pedronis: https://github.com/snapcore/snapd/pull/7142 «boot, o/snapst, o/devicest: limit knowledge of boot vars to boot» [15:22] PR #7142: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot [15:23] wait mup lives [15:23] jdstrand, mhm so maybe if we go back to having supervisord spawn the child with snap_daemon that might work better? [15:23] * Chipaca hugs mup [15:23] PR snapd#7142 opened: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot [15:23] ackk: probably not. supervisord is root and trying to kill a snap_daemon child. [15:24] ackk: in either case, supervisord could temporarily drop, send the signal, then re-reaise [15:25] jdstrand, uhm, you mean by just setuid/gid(0) again? [15:25] it might be safe to add 'capability kill,' since we have signal rules to mediate things, so I may add it to the PR. but I also want to think through process-control, which currently does not have capability kill [15:26] ackk: not setuid/gid, seteuid/gid. [15:26] jdstrand, I see. so perhaps I can try that in the script that traps SIGINT/TERM and signals the child. dropping uid around that should work IIUC [15:27] eg, seteuid(uid_t of snap_daemon), kill, seteuid(0) [15:27] jdstrand, cool, lemme try that [15:27] Chipaca: thanks, feel free to request me as reviewer [15:29] ackk: for 'uid_t of snap_daemon', do a getpwuid() [15:30] jdstrand, yeah I'm doing it from python, using pwd.getpwnam(username).pw_uid [15:30] (and grp.getgrnam(username).gr_gid) [15:30] ackk: when the PR is finalized, you will be able to hardcode a value instead of doing a lookup, but the value isn't finalized yet [15:31] getpwname/getpwent/etc is always acceptable [15:31] jdstrand, thanks [15:31] getpwnam* [15:40] hmm, github is giving me 500 [15:43] anyone else? [15:44] zyga, WFM [15:44] https://www.githubstatus.com says is is in degraded performance [15:44] oh well [15:58] hmm [15:58] + expected='(?s)Name +Version +Publisher +Notes +Summary *\n(.*?\n)?test-snapd-tools +.*? *\n.*' [15:58] + grep -Pzq '(?s)Name +Version +Publisher +Notes +Summary *\n(.*?\n)?test-snapd-tools +.*? *\n.*' [15:58] + snap find test-snapd-tools [15:59] running that manually gives me test-snapd-tools-core18 1.0 canonical✓ - [15:59] Chipaca: ^ is that expected search result? [16:06] ackk: now it says "major outage" :) [16:06] ackk: not that I'm happy for GitHub, at least I can expect it to be down [16:17] jdstrand, should we use seteuid/gid for dropping privileges too? we currently user set-uid/gid [16:18] ackk: only if you need to re-raise. it is almost always 'no' [16:18] jdstrand, ha yeah I meant to re-raise [16:20] cachio, mvo: did anyone publish test-snapd-tools-core18? [16:20] zyga, I dont [16:20] ackk: fyi, I've decided that for now snaps by default will *not* have CAP_KILL for reasons that will be in the code comments. process-control will have CAP_KILL added [16:20] zyga, why? [16:21] it causes google:ubuntu-18.04-64:tests/main/searching to fail [16:21] (on all systems) [16:21] zyga: I probably did a long time ago, why? do you need anything there? [16:21] ^ [16:21] or the store just changed? [16:21] look at what I said earlier [16:21] snap find test-snapd-tools [16:21] it fills test-snapd-tools-core18 now [16:22] not test-snapd-tools [16:22] * zyga looks at the test [16:22] zyga, which is the test? [16:22] searching [16:22] tests/main/searching [16:22] zyga: maybe a store hickup? [16:23] I didn't ready that [16:23] it failed on all my PRs [16:23] no worries :) [16:23] I enabled that last week for core18 [16:23] noise][: was there a store rollout in the last 4 hours? [16:23] cachio: oh? [16:23] but I was working properly [16:23] something has to be changed on the store I think [16:24] zyga, do you have a link with this error? [16:26] cachio: https://api.travis-ci.org/v3/job/562141949/log.txt [16:27] this is from https://github.com/snapcore/snapd/pull/7139 [16:27] PR #7139: tests: don't leak /run/netns mount [16:27] zyga, checking [16:27] pedronis: would it be useful to convert the user-open command in snapctl to a more formal hidden snapctl command now that we have hidden snapctl commands? [16:27] ijohnson: I think is more complicated then that [16:28] it's done that way because it needs to work from the session [16:28] ah I see looking at the code it needs to talk to userd [16:28] not via snapd [16:28] right nevermind [16:29] zyga, I changed the test listing, not the searching, I was confused [16:29] zyga, I think it is something new [16:30] cachio: zyga: looks like test-snapd-tools is marked as "unlisted" for search [16:31] zyga, this is wrong https://paste.ubuntu.com/p/sRv5nqFZss/ [16:31] noise][, that makese sense [16:31] cachio: I understand that, I wonder what changed to make that happen [16:31] noise][: is there a way to see if that was recently different? [16:32] zyga: i would assume it was, but I don't think we audit log that field [16:33] noise][: can you tell me who owns that snap please? [16:33] Canonical account - you can see it with snap info [16:36] I see, thank you [16:37] mvo, pedronis: do you recall making any changes to test-snapd-tools-core18 recently? (today?) [16:39] Chipaca, ^ or yourself perhaps? [16:41] zyga, other tests failing as well [16:43] cachio: which one? [16:43] zyga: definitely not today [16:44] Auto-refresh on fedora [16:44] zyga, first time I see this error https://paste.ubuntu.com/p/HqwKnnQP2K/ [16:45] zyga, not sure if it caused by the same but seems that could be related [16:46] mmmm [16:48] zyga, I see other weird errors on fedora as well, perhaps this new fedora has problems [16:48] zyga, https://paste.ubuntu.com/p/yGbw4PRFmP/ [16:49] first line of the test fails [16:49] perhaps there is something new causing this [17:03] * zyga gives up for now [17:22] zyga: I don't even have access to it [17:25] zyga: I set some test-snapd- snaps to unlisted, but not -core18 [17:26] i don't have access to that one [17:27]