[05:16] <mborzecki> morning
[06:03] <zyga> Good morning
[06:03] <zyga> I will be around in 30
[06:07] <mborzecki> zyga: hey
[06:17] <zyga> Hey :-)
[06:17] <zyga> Good to be back
[06:39] <mborzecki> mvo: morning
[06:41] <mvo> hey mborzecki ! good morning and welcome back
[06:44] <mborzecki> mvo: anything interesting happened last week?
[06:50] <zyga> o/
[06:51] <zyga> I would love to know as well
[06:52]  * zyga checks email and other administrativa
[06:58] <mborzecki> zyga: mvo started with some cgroupv2 work https://github.com/snapcore/snapd/pull/7109
[06:58] <mup> PR #7109: [RFC] snap-confine: fallback gracefully on a cgroup v2 only system <Created by mvo5> <https://github.com/snapcore/snapd/pull/7109>
[07:02] <zyga> mborzecki: reviewing
[07:03] <mvo> mborzecki: hm, not that much, but we did push some PRs forward so that was good
[07:05] <mborzecki> mvo: i saw systemd guys pushed a fix for the mount problem we saw
[07:05] <mvo> mborzecki: yes, I saw that too, iirc I even added a card in trello
[07:06] <jwheare> Speaking of pushing prs forward, can anyone look into approving my cla for this? https://github.com/snapcore/snapd/pull/7129
[07:06] <mvo> mborzecki: I looked at it briefly but even backporting to bionic did not look trivial
[07:06] <mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
[07:06] <zyga> mvo: reviewed
[07:06] <zyga> jwheare: hey, let me look :)
[07:06] <zyga> mvo: who can approve CLA things?
[07:07] <mvo> mborzecki: but *maybe* its not hard, I have not looked but it definitely needs some prereq patches
[07:07] <mvo> zyga: it should be enough to click through this web thing we have
[07:07] <zyga> mvo: which web thing?
[07:07] <mborzecki> 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] <mvo> mborzecki: that would be great
[07:08] <jwheare> I submitted the web form
[07:08] <mvo> mborzecki: I looked over the patch and it all seems to make sense
[07:08] <mvo> jwheare: hey, sorry that you have trouble, let me try to find out what is going on
[07:08] <mvo> jwheare: normally the web form should be fine
[07:08] <jwheare> Had no idea what to put in the “project manager contact” field tho
[07:09] <jwheare> And was a bit uncomfortable having to leave address and phone number with no explicit note on privacy on that page.
[07:09] <jwheare> But I think I did it right?
[07:09] <zyga> mvo: I think the web thing is still a queue for someone to approve
[07:10] <mvo> 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] <mvo> zyga: I will find out, its possible
[07:11] <mvo> zyga: I *thought* it got automated but maybe I misremember, if not automatic its not ideal on e.g. weekends :/
[07:11] <mborzecki> mvo: hm perhaps there should be an explicit note given GDPR and such
[07:11] <jwheare> It’s this thing https://ubuntu.com/legal/contributors/agreement
[07:12] <mvo> mborzecki: exactly
[07:12] <jwheare> The pr template and contibuting.md should mention what to put in “Project contact” imo
[07:12] <mvo> jwheare: that looks good, is your launchpad-id the same as your irc nick?
[07:12] <mborzecki> mvo: building an image with latest systemd
[07:12] <jwheare> mvo: nope it’s l-james
[07:12] <mvo> jwheare: excellent suggestion, let me fix that too
[07:13] <jwheare> Email is james@wheare.org
[07:14] <mvo> jwheare: thank you!
[07:20] <jwheare> Thanks for taking a look :)
[07:22] <mvo> 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] <mvo> jwheare: thanks for the PR too, that looks pretty good - did you see the concern that james hensdrige had?
[07:40] <jwheare> mvo: not really :)
[07:41] <jwheare> 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] <pedronis> mvo: hi,  sorry created quite a few PRs Friday and over the weekend, they have all cards now pointing to them
[07:46] <mvo> pedronis: thank you!
[07:47] <mvo> 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] <mborzecki> 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] <mvo> mborzecki: awsome
[07:55] <mvo> mborzecki: I guess we should explore how much work a backport would be
[07:55] <mvo> mborzecki, zyga another "fun" issue last week: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836914
[07:55] <mup> Bug #1836914: Doing multiple squashfs (and other loop?) mounts in parallel breaks <amd64> <apport-bug> <eoan> <rls-ee-incoming> <linux (Ubuntu):Confirmed> <https://launchpad.net/bugs/1836914>
[07:56] <mborzecki> mvo: heh, that sounds familiar to the forum topic i opened
[07:56] <pedronis> mvo: we landed a fix for this, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824226 no ?
[07:57] <mborzecki> 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] <mborzecki> mvo: bad news, i can still reproduce the mount problem
[08:13] <diddledan> popey_: you working today?
[08:17] <popey_> ya, back at my desk today
[08:19] <diddledan> cool, in that case then, we've had a person approach from irccloud: https://github.com/snapcrafters/irccloud-desktop/issues/22
[08:19] <popey_> oooooh
[08:19] <popey_> I'll take a look once I'm off the phone
[08:19] <diddledan> cool
[08:25] <jwheare> hi that's me :)
[08:25] <popey_> Oh hai!
[08:25] <popey_> Just talking about this on my current phone call with my boss.
[08:25] <popey_> Will reply to it once I get off the phone
[08:26] <jwheare> cool! just heading to the dentist, be back to chat in about half an hour
[08:26] <popey_> groovy!
[08:27] <jamesh> hi jwheare.  Thanks for the PR :-)
[08:28] <Chipaca> pedronis: productive weekend for you i see
[08:34] <diddledan> awesome :-)
[08:35] <ackk> 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] <diddledan> do do do de do do 'cos I eat's me spinich
[08:37] <diddledan> :-p
[08:37]  * diddledan is evil
[08:47] <abeato> 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] <jwheare> back
[08:50] <popey_> o/
[08:50] <diddledan> \o
[08:50] <diddledan> '\o/'
[08:51]  * popey_ installs irccloud
[08:51] <jwheare> 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] <popey_> jwheare: where is that config file being written to?
[08:52] <jwheare> i think it snuck in on a round of dep updates, since your last released build (0.11.0)
[08:52] <jwheare> popey_: just the standard userdata dir. the issue is kind of convoluted
[08:52] <popey_> i bumped irccloud-desktop to 0.12.0 the other day.
[08:52] <jwheare> spread across a few github issues
[08:52] <popey_> ah
[08:53] <jwheare> https://github.com/sindresorhus/conf/pull/82
[08:53] <mup> PR sindresorhus/conf#82: fix: do not use chown on write - system default permissions is enough <Created by develar> <https://github.com/sindresorhus/conf/pull/82>
[08:54] <popey> hello from irccloud snap
[08:54] <popey_> that works then :)
[08:54] <popey_> One question we haven't discussed, is the name.
[08:55] <popey_> Once these blockers are solved, do you want to keep irccloud, or would you like us to transfer irccloud-desktop to you?
[08:55] <popey_> We can't rename snaps in the store, but we can "encourage" existing irccloud-desktop users to move over
[08:55] <popey_> (not automatically, but they can be nagged to do it)
[08:55] <mborzecki> mvo: left a note https://github.com/systemd/systemd/issues/10872#issuecomment-513703519 :/
[08:55] <jwheare> 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] <jwheare> nagging probably works well enough
[08:56] <popey_> We did this with the vscode snap, to move them to code, and it works well enough
[08:56] <popey_> active users will get punched in the face with a dialog to "recommend" they move over
[08:56] <diddledan> we can replace the irccloud-desktop with a neutered snap that just says "not 'ere, guv'"
[08:56] <popey_> it's annoying enough to make people want to move over
[08:57] <popey_> well, the irccloud-desktop snap "only" has a few hundred users.
[08:57] <jwheare> dialog sounds good
[08:57] <jwheare> copy approved
[08:57] <popey_> 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] <popey_> hah
[09:09] <zyga> https://src.fedoraproject.org/rpms/gnome-software/pull-request/1 this thread is horrible
[09:09] <zyga> anyone who ever says "*buntu is evil" should read it
[09:11] <popey_> Not convinced that is a useful assertion to make in a public place zyga
[09:11]  * diddledan edits history
[09:11] <diddledan> oh wait, this isn't telegram
[09:12] <zyga> I will just ignore this topic for now, work on productive stuff instead
[09:13] <popey_> That's the spirit! :D
[09:29] <zyga> mvo: I'm removing lxd now, let's see what happens, this is an easier way to fix this
[09:30] <zyga> (for context: Qemu and google images differ in preinstalled package sets, this makes fighting tests leaking side-effects easier)
[09:30] <mvo> mborzecki: uh, ok - if you can still reproduce the mount problem, mind to tell upstream?
[09:30] <mvo> ackk: probably best to ask jdstrand why/if block-devices interface intentionally doesn't allow access to partitions
[09:31] <mborzecki> mvo: yup, already left a note under the issue
[09:31] <mvo> abeato: classic core18> I need to look
[09:31] <ackk> mvo, thanks, will ping him later
[09:33] <mborzecki> 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] <abeato> mvo, ack, thanks
[09:44] <popey_> jwheare: on the subject of irccloud. Is it possible to globally disable logging for a particular irc server / network?
[09:45] <jwheare> 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] <popey_> 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] <jwheare> 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] <popey_> I wonder if people would be happier if they were encrypted with a personal key
[09:46] <jwheare> but something like a 7 day retention policy is probably reasonable
[09:46] <popey_> but that's quite a lot to do
[09:47] <jwheare> encryption is a whole other kettle of fish
[09:47] <popey_> btw, I *love* that you can easily add slack channels to irccloud and it looks and behaves just like irc
[09:49] <jwheare> 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] <popey_> yeah, wire is similar. messages just disappear
[09:50] <jwheare> but having an off the record mode you can toggle for sensitive private messages would make sense
[09:50] <pedronis> #7134 is quite simple and avoids running some test suite tests twice
[09:50] <mup> PR #7134: image: clean up the validateSuite <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7134>
[09:50] <zyga> brb
[09:52] <mborzecki> mvo: well, same thing on fedora
[09:57] <mvo> mborzecki: thanks
[09:59] <mvo> abeato: I released classic/18 to edge now (and also building a new one)
[10:00] <abeato> mvo, nice, thanks! will give it a go for arm64
[10:01] <mvo> abeato: thank you, I think I never tested it there so please keep me updated
[10:01] <abeato> sure thing
[10:01] <mvo> ta - if it works for you I will move it to beta
[10:06] <mvo> 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] <mvo> jwheare: thanks again for raising this!
[10:11] <Wimpress> jwheare: Thanks for publishing `ircloud` to the edge channel. I've switched to it here 👍
[10:12] <jwheare> mvo: great to hear, thanks for following up
[10:13] <jwheare> 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] <Wimpress> Will do.
[10:14] <jwheare> That EPERM crash on quit/config change being the main one
[10:26] <Wimpress> jwheare: That crash on exit recently started happening in the community maintained `irccloud-desktop` snap.
[10:26] <Wimpress> But this is a new issue. Hadn't ever seen it until recently.
[10:28] <popey_> I must say, I so rarely close it I hadn't noticed that issue
[10:28] <Wimpress> And that.
[10:28] <jwheare> Window resize/move might trigger it too
[10:28] <jwheare> Or toggling full screen
[10:32] <jwheare> actually those only get set on quit. but adjusting zoom level will crash i think
[11:15] <ackk> jdstrand, hi, mind giving an opinion on https://bugs.launchpad.net/snapd/+bug/1837369 ?
[11:15] <mup> Bug #1837369: Read-only interface for block devices <maas> <snapd-interface> <snapd:New> <https://launchpad.net/bugs/1837369>
[11:25] <mup> PR snapd#7136 opened: tests: part4 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7136>
[11:26] <ppisati> ogra: do you have a json file that i can use to build a pi3 core 18 image?
[11:34] <ppisati> ogra: nm, typo
[11:48] <ogra> ppisati, nope, but there are some on the forum, th eonly core18 image i personally have is for pi4 currently
[11:49] <ogra> forum post is here: https://forum.snapcraft.io/t/model-assertions-for-core18/6870
[11:58] <zyga> hey ijohnson :)
[12:02] <ijohnson> morning zyga
[12:02]  * ijohnson needs coffee, brb
[12:28] <mup> PR snapd#7134 closed: image: clean up the validateSuite <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7134>
[13:11] <mup> PR snapd#7137 opened: gadget: support for writing symlinks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7137>
[13:49] <zyga> 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] <ijohnson> zyga: ack I can review that today
[13:50] <zyga> thanks!
[13:59] <Chipaca> had to turn off the camera because my laptop was literally melting the placemat i had it on
[14:00] <Chipaca> i hope it un-warps when it cools back down =(
[14:00] <ijohnson> pedronis, mvo, niemeyer: I posted https://forum.snapcraft.io/t/netplan-apply-inside-snaps/12411 as a starting point for our discussions
[14:01] <pedronis> 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] <pedronis> s
[14:01] <ijohnson> pedronis: sure
[14:01] <pedronis> thx
[14:02] <mvo> ijohnson: thank you!
[14:04] <ijohnson> np, let me know if y'all have time for a meeting today to discuss
[14:11] <mvo> ijohnson: I setup something, does that time work for you?
[14:12] <ijohnson> mvo: yes
[14:30] <ackk> jdstrand, hi, around?
[14:30] <mborzecki> zyga: omg, silly typo
[14:31] <zyga> mborzecki: haha
[14:31] <zyga> mborzecki: I was preparing this nice batch for you
[14:31] <zyga> but you pushed :)
[14:31] <mborzecki> zyga: didn't push, not yet ;)
[14:31] <zyga> ah, my bad, sorry
[14:31] <zyga> GH changed the UI again
[14:32] <mborzecki> zyga: ha, can't craete a batch on gh, wtf?
[14:32] <zyga> you can but I opted not to because I cannot commit
[14:32] <zyga> you can batch commit
[14:32] <zyga> not batch suggest
[14:33] <mborzecki> zyga: nah, 'add suggestion to batch' is greyed out
[14:33] <Chipaca> mvo: question for you about some code you last touched in 2016 … /o\
[14:33] <mborzecki> nvm, i'll push a patch
[14:38] <jdstrand> ackk: I answered in the bug
[14:39] <jdstrand> mvo: fyi, block-devices intentionally does not allow access to partitions (it is a comment in the interface code)
[14:40] <ackk> jdstrand, yes, we do use hardware-observe
[14:41] <ackk> jdstrand, btw I reopened https://bugs.launchpad.net/snapd/+bug/1831473 with a comment
[14:41] <mup> Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:New for jdstrand> <https://launchpad.net/bugs/1831473>
[14:42] <jdstrand> ackk: I saw that
[14:42] <jdstrand> ackk: it should probably be a new bug, but that is fine
[14:42] <ackk> jdstrand, hardware-observe doesn't let you read /dev/sd* or other block devices though
[14:43] <jdstrand> ackk: please connect the interfaces, run in devmode and add the policy violation to the bug
[14:44] <jdstrand> violations*
[14:44] <ackk> jdstrand, will do, thanks
[14:45] <mvo> Chipaca: what question (in a meeting so might be slow to reply)
[14:45] <mvo> Chipaca: 2016 sounds scary
[14:45] <ackk> 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] <Chipaca> 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] <Chipaca> s/if//
[14:47] <jdstrand> 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] <mup> Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:New for jdstrand> <https://launchpad.net/bugs/1831473>
[14:47] <ackk> jdstrand, you mean mention that we're using the interface?
[14:48] <ackk> oh I see, hardware-observe has permission for /proc/1/sched commented out
[14:48] <jdstrand> 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] <mup> PR snapd#7138 opened: tests: remove lxd / lxcfs if pre-installed <Created by zyga> <https://github.com/snapcore/snapd/pull/7138>
[14:50] <mup> PR snapd#7139 opened: tests: don't leak /run/netns mount <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7139>
[14:50] <jdstrand> ackk: ackk as for the other question, let me check something
[14:51] <ackk> jdstrand, I see pid 1 in /proc/1/sched  both in my system and in a container
[14:52] <ackk> 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] <jdstrand> 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] <mup> PR snapd#7140 opened: overlord/devicestate: update gadget update handlers and mocks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7140>
[14:54] <ackk> 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] <ackk> jdstrand, in a container, s-d-v works and I don't see the denial
[14:55] <ackk> 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] <mup> PR snapd#7141 opened: tests: add mountinfo-tool --ref-x1000 <Created by zyga> <https://github.com/snapcore/snapd/pull/7141>
[15:03] <zyga> ijohnson: 7141 is the one I mentioned before
[15:03] <zyga> I will look at reviews now, just need a small break
[15:07] <ijohnson> zyga: ack will take a look
[15:07] <zyga> ijohnson: thanks!
[15:19] <jdstrand> 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] <jdstrand> ackk: the policy is lacking 'capability kill,'. I need to think through how to allow that
[15:21] <ackk> 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] <jdstrand> 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] <jdstrand> ackk: that is consistent with what I described and the current policy
[15:22] <jdstrand> I need to think through how to expose this
[15:22] <Chipaca> pedronis: https://github.com/snapcore/snapd/pull/7142 «boot, o/snapst, o/devicest: limit knowledge of boot vars to boot»
[15:22] <mup> PR #7142: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot <Created by chipaca> <https://github.com/snapcore/snapd/pull/7142>
[15:23] <Chipaca> wait mup lives
[15:23] <ackk> 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] <mup> PR snapd#7142 opened: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot <Created by chipaca> <https://github.com/snapcore/snapd/pull/7142>
[15:23] <jdstrand> ackk: probably not. supervisord is root and trying to kill a snap_daemon child.
[15:24] <jdstrand> ackk: in either case, supervisord could temporarily drop, send the signal, then re-reaise
[15:25] <ackk> jdstrand, uhm, you mean by just setuid/gid(0) again?
[15:25] <jdstrand> 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] <jdstrand> ackk: not setuid/gid, seteuid/gid.
[15:26] <ackk> 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] <jdstrand> eg, seteuid(uid_t of snap_daemon), kill, seteuid(0)
[15:27] <ackk> jdstrand, cool, lemme try that
[15:27] <pedronis> Chipaca: thanks, feel free to request me as reviewer
[15:29] <jdstrand> ackk: for 'uid_t of snap_daemon', do a getpwuid()
[15:30] <ackk> jdstrand, yeah I'm doing it from python, using pwd.getpwnam(username).pw_uid
[15:30] <ackk> (and grp.getgrnam(username).gr_gid)
[15:30] <jdstrand> 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] <jdstrand> getpwname/getpwent/etc is always acceptable
[15:31] <ackk> jdstrand, thanks
[15:31] <jdstrand> getpwnam*
[15:40] <zyga> hmm, github is giving me 500
[15:43] <zyga> anyone else?
[15:44] <ackk> zyga, WFM
[15:44] <zyga> https://www.githubstatus.com says is is in degraded performance
[15:44] <zyga> oh well
[15:58] <zyga> hmm
[15:58] <zyga> + expected='(?s)Name +Version +Publisher +Notes +Summary *\n(.*?\n)?test-snapd-tools +.*? *\n.*'
[15:58] <zyga> + grep -Pzq '(?s)Name +Version +Publisher +Notes +Summary *\n(.*?\n)?test-snapd-tools +.*? *\n.*'
[15:58] <zyga> + snap find test-snapd-tools
[15:59] <zyga> running that manually gives me test-snapd-tools-core18  1.0      canonical✓  -
[15:59] <zyga> Chipaca: ^ is that expected search result?
[16:06] <zyga> ackk: now it says "major outage" :)
[16:06] <zyga> ackk: not that I'm happy for GitHub, at least I can expect it to be down
[16:17] <ackk> jdstrand, should we use seteuid/gid for dropping privileges too? we currently user set-uid/gid
[16:18] <jdstrand> ackk: only if you need to re-raise. it is almost always 'no'
[16:18] <ackk> jdstrand, ha yeah I meant to re-raise
[16:20] <zyga> cachio, mvo: did anyone publish test-snapd-tools-core18?
[16:20] <cachio> zyga, I dont
[16:20] <jdstrand> 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] <cachio> zyga, why?
[16:21] <zyga> it causes google:ubuntu-18.04-64:tests/main/searching to fail
[16:21] <zyga> (on all systems)
[16:21] <mvo> zyga: I probably did a long time ago, why? do you need anything there?
[16:21] <zyga> ^
[16:21] <zyga> or the store just changed?
[16:21] <zyga> look at what I said earlier
[16:21] <zyga> snap find test-snapd-tools
[16:21] <zyga> it fills test-snapd-tools-core18 now
[16:22] <zyga> not test-snapd-tools
[16:22]  * zyga looks at the test
[16:22] <cachio> zyga, which is the test?
[16:22] <cachio> searching
[16:22] <zyga> tests/main/searching
[16:22] <mvo> zyga: maybe a store hickup?
[16:23] <cachio> I didn't ready that
[16:23] <zyga> it failed on all my PRs
[16:23] <zyga> no worries :)
[16:23] <cachio> I enabled that last week for core18
[16:23] <zyga> noise][: was there a store rollout in the last 4 hours?
[16:23] <zyga> cachio: oh?
[16:23] <cachio> but I was working properly
[16:23] <cachio> something has to be changed on the store I think
[16:24] <cachio> zyga, do you have a link with this error?
[16:26] <zyga> cachio: https://api.travis-ci.org/v3/job/562141949/log.txt
[16:27] <zyga> this is from https://github.com/snapcore/snapd/pull/7139
[16:27] <mup> PR #7139: tests: don't leak /run/netns mount <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7139>
[16:27] <cachio> zyga, checking
[16:27] <ijohnson> 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] <pedronis> ijohnson: I think is more complicated then that
[16:28] <pedronis> it's done that way because it needs to work from the session
[16:28] <ijohnson> ah I see looking at the code it needs to talk to userd
[16:28] <pedronis> not via snapd
[16:28] <ijohnson> right nevermind
[16:29] <cachio> zyga, I changed the test listing, not the searching, I was confused
[16:29] <cachio> zyga, I think it is something new
[16:30] <noise][> cachio: zyga: looks like test-snapd-tools is marked as "unlisted" for search
[16:31] <cachio> zyga, this is wrong https://paste.ubuntu.com/p/sRv5nqFZss/
[16:31] <cachio> noise][, that makese sense
[16:31] <zyga> cachio: I understand that, I wonder what changed to make that happen
[16:31] <zyga> noise][: is there a way to see if that was recently different?
[16:32] <noise][> zyga: i would assume it was, but I don't think we audit log that field
[16:33] <zyga> noise][: can you tell me who owns that snap please?
[16:33] <noise][> Canonical account - you can see it with snap info
[16:36] <zyga> I see, thank you
[16:37] <zyga> mvo, pedronis: do you recall making any changes to test-snapd-tools-core18 recently? (today?)
[16:39] <zyga> Chipaca, ^ or yourself perhaps?
[16:41] <cachio> zyga, other tests failing as well
[16:43] <zyga> cachio: which one?
[16:43] <mvo> zyga: definitely not today
[16:44] <cachio> Auto-refresh on fedora
[16:44] <cachio> zyga, first time I see this error https://paste.ubuntu.com/p/HqwKnnQP2K/
[16:45] <cachio> zyga, not sure if it caused by the same but seems that could be related
[16:46] <zyga> mmmm
[16:48] <cachio> zyga, I see other weird errors on fedora as well, perhaps this new fedora has problems
[16:48] <cachio> zyga, https://paste.ubuntu.com/p/yGbw4PRFmP/
[16:49] <cachio> first line of the test fails
[16:49] <cachio> perhaps there is something new causing this
[17:03]  * zyga gives up for now
[17:22] <pedronis> zyga: I don't even have access to it
[17:25] <Chipaca> zyga: I set some test-snapd- snaps to unlisted, but not -core18
[17:26] <Chipaca> i don't have access to that one
[17:27] <zyga> Chipaca: that might explain it
[17:27] <zyga> Chipaca: test-snapd-tools is now unlisted, failing the test
[17:28] <pedronis> we use it in find tests
[17:28] <Chipaca> hmm
[17:28] <pedronis> we cannot have it both way
[17:28] <Chipaca> whoops
[17:28] <pedronis> might we should use something else
[17:28] <Chipaca> my bad
[17:28] <Chipaca> put it back to public
[17:29] <zyga> Chipaca: thank you!
[17:29] <zyga> Chipaca: I'll restart the test to confirm
[17:29] <Chipaca> i'd like to make every hello-<developer> snap unlisted also :-)
[17:41] <zyga> re
[17:41] <zyga> sorry, lost power at home
[18:32] <mup> PR snapcraft#2619 closed: make: add "none" and "core20" as supported bases <Created by xnox> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2619>
[18:32] <mup> PR snapcraft#2635 closed: Legacy errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2635>
[18:42] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/7139 -- cherry picked out of the bigger mount namespace measurement PR
[18:42] <mup> PR #7139: tests: don't leak /run/netns mount <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7139>
[18:44] <ijohnson> zyga: approved
[18:52] <zyga> thanks :)
[19:02] <mup> PR snapd#7107 closed: overlord/ctlcmd: add netplan-apply cmd to snapctl <⛔ Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7107>
[19:10]  * ijohnson relocates to coffee shop
[19:17] <mup> PR snapcraft#2636 opened: Release changelog for 3.7 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2636>
[19:56] <popey_> https://bugs.launchpad.net/snapd/+bug/1837460
[19:56] <mup> Bug #1837460: snap refresh slows down computer dramatically <snapd:New> <https://launchpad.net/bugs/1837460>
[19:56] <popey_> Be interested to know what additional debug info might be useful here.
[21:48] <mup> PR snapcraft#2637 opened: unit tests: make lifecycle tests more robust <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2637>