mborzecki | morning | 05:16 |
---|---|---|
zyga | Good morning | 06:03 |
zyga | I will be around in 30 | 06:03 |
mborzecki | zyga: hey | 06:07 |
zyga | Hey :-) | 06:17 |
zyga | Good to be back | 06:17 |
mborzecki | mvo: morning | 06:39 |
mvo | hey mborzecki ! good morning and welcome back | 06:41 |
mborzecki | mvo: anything interesting happened last week? | 06:44 |
zyga | o/ | 06:50 |
zyga | I would love to know as well | 06:51 |
* zyga checks email and other administrativa | 06:52 | |
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> | 06:58 |
zyga | mborzecki: reviewing | 07:02 |
mvo | mborzecki: hm, not that much, but we did push some PRs forward so that was good | 07:03 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
jwheare | Email is james@wheare.org | 07:13 |
mvo | jwheare: thank you! | 07:14 |
jwheare | Thanks for taking a look :) | 07:20 |
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:22 |
mvo | jwheare: thanks for the PR too, that looks pretty good - did you see the concern that james hensdrige had? | 07:25 |
jwheare | mvo: not really :) | 07:40 |
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:41 |
mvo | pedronis: thank you! | 07:46 |
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:47 | |
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:51 |
mvo | mborzecki: awsome | 07:54 |
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:55 |
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:56 |
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 | 07:57 |
* mvo is in a meeting right now, so appologies for not replying | 08:04 | |
mborzecki | mvo: bad news, i can still reproduce the mount problem | 08:06 |
diddledan | popey_: you working today? | 08:13 |
popey_ | ya, back at my desk today | 08:17 |
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:19 |
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:25 |
jwheare | cool! just heading to the dentist, be back to chat in about half an hour | 08:26 |
popey_ | groovy! | 08:26 |
jamesh | hi jwheare. Thanks for the PR :-) | 08:27 |
Chipaca | pedronis: productive weekend for you i see | 08:28 |
diddledan | awesome :-) | 08:34 |
ackk | mvo, hi, we noticed the block-devices interface intentionally doesn't allow access to partitions, what's the reason for it? | 08:35 |
* 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:37 | |
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:47 |
jwheare | back | 08:50 |
popey_ | o/ | 08:50 |
diddledan | \o | 08:50 |
diddledan | '\o/' | 08:50 |
* 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:51 |
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:52 |
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:53 |
popey | hello from irccloud snap | 08:54 |
popey_ | that works then :) | 08:54 |
popey_ | One question we haven't discussed, is the name. | 08:54 |
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:55 |
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:56 |
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 | 08:57 |
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:09 |
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:11 |
zyga | I will just ignore this topic for now, work on productive stuff instead | 09:12 |
popey_ | That's the spirit! :D | 09:13 |
zyga | mvo: I'm removing lxd now, let's see what happens, this is an easier way to fix this | 09:29 |
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:30 |
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:31 |
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:33 |
abeato | mvo, ack, thanks | 09:34 |
popey_ | jwheare: on the subject of irccloud. Is it possible to globally disable logging for a particular irc server / network? | 09:44 |
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:45 |
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:46 |
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:47 |
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:49 |
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:50 |
mborzecki | mvo: well, same thing on fedora | 09:52 |
mvo | mborzecki: thanks | 09:57 |
mvo | abeato: I released classic/18 to edge now (and also building a new one) | 09:59 |
abeato | mvo, nice, thanks! will give it a go for arm64 | 10:00 |
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:01 |
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:06 |
Wimpress | jwheare: Thanks for publishing `ircloud` to the edge channel. I've switched to it here 👍 | 10:11 |
jwheare | mvo: great to hear, thanks for following up | 10:12 |
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:13 |
jwheare | That EPERM crash on quit/config change being the main one | 10:14 |
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:26 |
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:28 |
jwheare | actually those only get set on quit. but adjusting zoom level will crash i think | 10:32 |
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:15 |
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:25 |
ppisati | ogra: do you have a json file that i can use to build a pi3 core 18 image? | 11:26 |
ppisati | ogra: nm, typo | 11:34 |
ogra | ppisati, nope, but there are some on the forum, th eonly core18 image i personally have is for pi4 currently | 11:48 |
ogra | forum post is here: https://forum.snapcraft.io/t/model-assertions-for-core18/6870 | 11:49 |
zyga | hey ijohnson :) | 11:58 |
ijohnson | morning zyga | 12:02 |
* ijohnson needs coffee, brb | 12:02 | |
mup | PR snapd#7134 closed: image: clean up the validateSuite <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7134> | 12:28 |
=== cmatsuoka is now known as cmatsuoka_debcon | ||
=== cmatsuoka_debcon is now known as cmatsuoka | ||
mup | PR snapd#7137 opened: gadget: support for writing symlinks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7137> | 13:11 |
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:49 |
ijohnson | zyga: ack I can review that today | 13:50 |
zyga | thanks! | 13:50 |
Chipaca | had to turn off the camera because my laptop was literally melting the placemat i had it on | 13:59 |
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:00 |
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:01 |
mvo | ijohnson: thank you! | 14:02 |
ijohnson | np, let me know if y'all have time for a meeting today to discuss | 14:04 |
mvo | ijohnson: I setup something, does that time work for you? | 14:11 |
ijohnson | mvo: yes | 14:12 |
ackk | jdstrand, hi, around? | 14:30 |
mborzecki | zyga: omg, silly typo | 14:30 |
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:31 |
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:32 |
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:33 |
jdstrand | ackk: I answered in the bug | 14:38 |
jdstrand | mvo: fyi, block-devices intentionally does not allow access to partitions (it is a comment in the interface code) | 14:39 |
ackk | jdstrand, yes, we do use hardware-observe | 14:40 |
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:41 |
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:42 |
jdstrand | ackk: please connect the interfaces, run in devmode and add the policy violation to the bug | 14:43 |
jdstrand | violations* | 14:44 |
ackk | jdstrand, will do, thanks | 14:44 |
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:45 |
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:46 |
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:47 |
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:48 |
mup | PR snapd#7138 opened: tests: remove lxd / lxcfs if pre-installed <Created by zyga> <https://github.com/snapcore/snapd/pull/7138> | 14:49 |
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:50 |
ackk | jdstrand, I see pid 1 in /proc/1/sched both in my system and in a container | 14:51 |
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:52 |
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:53 |
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:54 |
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:55 |
* cachio lunch | 14:56 | |
mup | PR snapd#7141 opened: tests: add mountinfo-tool --ref-x1000 <Created by zyga> <https://github.com/snapcore/snapd/pull/7141> | 15:00 |
zyga | ijohnson: 7141 is the one I mentioned before | 15:03 |
zyga | I will look at reviews now, just need a small break | 15:03 |
ijohnson | zyga: ack will take a look | 15:07 |
zyga | ijohnson: thanks! | 15:07 |
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:19 |
jdstrand | ackk: the policy is lacking 'capability kill,'. I need to think through how to allow that | 15:20 |
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:21 |
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:22 |
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:23 |
jdstrand | ackk: in either case, supervisord could temporarily drop, send the signal, then re-reaise | 15:24 |
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:25 |
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:26 |
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:27 |
jdstrand | ackk: for 'uid_t of snap_daemon', do a getpwuid() | 15:29 |
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:30 |
jdstrand | getpwname/getpwent/etc is always acceptable | 15:31 |
ackk | jdstrand, thanks | 15:31 |
jdstrand | getpwnam* | 15:31 |
zyga | hmm, github is giving me 500 | 15:40 |
zyga | anyone else? | 15:43 |
ackk | zyga, WFM | 15:44 |
zyga | https://www.githubstatus.com says is is in degraded performance | 15:44 |
zyga | oh well | 15:44 |
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:58 |
zyga | running that manually gives me test-snapd-tools-core18 1.0 canonical✓ - | 15:59 |
zyga | Chipaca: ^ is that expected search result? | 15:59 |
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:06 |
ackk | jdstrand, should we use seteuid/gid for dropping privileges too? we currently user set-uid/gid | 16:17 |
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:18 |
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:20 |
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:21 |
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:22 |
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:23 |
cachio | zyga, do you have a link with this error? | 16:24 |
zyga | cachio: https://api.travis-ci.org/v3/job/562141949/log.txt | 16:26 |
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:27 |
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:28 |
cachio | zyga, I changed the test listing, not the searching, I was confused | 16:29 |
cachio | zyga, I think it is something new | 16:29 |
noise][ | cachio: zyga: looks like test-snapd-tools is marked as "unlisted" for search | 16:30 |
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:31 |
noise][ | zyga: i would assume it was, but I don't think we audit log that field | 16:32 |
zyga | noise][: can you tell me who owns that snap please? | 16:33 |
noise][ | Canonical account - you can see it with snap info | 16:33 |
zyga | I see, thank you | 16:36 |
zyga | mvo, pedronis: do you recall making any changes to test-snapd-tools-core18 recently? (today?) | 16:37 |
zyga | Chipaca, ^ or yourself perhaps? | 16:39 |
cachio | zyga, other tests failing as well | 16:41 |
zyga | cachio: which one? | 16:43 |
mvo | zyga: definitely not today | 16:43 |
cachio | Auto-refresh on fedora | 16:44 |
cachio | zyga, first time I see this error https://paste.ubuntu.com/p/HqwKnnQP2K/ | 16:44 |
cachio | zyga, not sure if it caused by the same but seems that could be related | 16:45 |
zyga | mmmm | 16:46 |
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:48 |
cachio | first line of the test fails | 16:49 |
cachio | perhaps there is something new causing this | 16:49 |
* zyga gives up for now | 17:03 | |
pedronis | zyga: I don't even have access to it | 17:22 |
Chipaca | zyga: I set some test-snapd- snaps to unlisted, but not -core18 | 17:25 |
Chipaca | i don't have access to that one | 17:26 |
zyga | Chipaca: that might explain it | 17:27 |
zyga | Chipaca: test-snapd-tools is now unlisted, failing the test | 17:27 |
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:28 |
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:29 |
zyga | re | 17:41 |
zyga | sorry, lost power at home | 17:41 |
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:32 |
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:42 |
ijohnson | zyga: approved | 18:44 |
zyga | thanks :) | 18:52 |
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:02 |
* ijohnson relocates to coffee shop | 19:10 | |
mup | PR snapcraft#2636 opened: Release changelog for 3.7 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2636> | 19:17 |
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. | 19:56 |
mup | PR snapcraft#2637 opened: unit tests: make lifecycle tests more robust <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2637> | 21:48 |
=== harrisj is now known as zigford |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!