[00:46] is this the right channel for someone who's having trouble getting skype to work? [02:30] sarnold: what is the problem you are having? [02:32] cjp256: another user in #ubuntu was having trouble getting skype to work via the snap; he had to run /snap/bin/skype explicitly, and once he did that he had problems with some authentication step within skype [02:33] cjp256: I asked if this was a good place for user help when he was having trouble figuring out how to even run skype, but another #ubuntu user aimed him towards /snap/bin/skype, which appeared to work [02:34] I wanted to make sure this was the right place to send him, before sending him here, since it'd exceeded my knowledge ;) but he got far enough to find out that he wasn't going to be able to use the skype snap in the end [02:34] is this the right place to send people who are having trouble with snap? [02:35] it depends, naturally :) but I've been working with the skype snap a lot lately and figured I'd ask. It can't hurt to ask the question and see where fate takes it... :D [04:57] PR snapd#7249 closed: packaging/fedora: build on RHEL8 [04:58] PR snapd#7248 closed: interfaces/mount: discard mount ns on backend Remove [06:01] mvo: hi, so jdstrand first two PRs are in better shape, but they are split a bit strangely so that the first will turn on the feature in a broken state, a full reorg of the PRs is probably too much at this point, my idea is to tweak the first to use a temporary global flag, to keep the feature off while we work through them one by one [06:12] mvo: sounds reasonable? [06:21] pedronis: yes [06:21] pedronis: thanks, once I finish some org stuff I will jump to the reviews for those [06:33] mvo: the first one has already 2 +1 I'm tweaking it as we speak though [06:34] pedronis: first one is 7111 ? [06:35] yes [06:35] I'll ask you to check my tweaks once pushed [06:35] ta [07:06] mvo: thanks for calling me up on that lock issue with the session agent PR. Getting rid of the need not to use defer to release the lock ended up making the code simpler. [07:08] jamesh: nice! thats great to hear. thanks for this. I will have another look in some minutes then :) [07:17] mmh [07:36] mvo: can you look at my own commits to 7111 [07:36] that I just pushed [07:43] pedronis: yes [08:06] PR snapd#7257 opened: packaging: fix symlink for snapd.session-agent.socket [08:10] welcome back mup ! [08:10] * mvo hugs niemeyer [08:40] mvo: I'll look again at 6404 in a little bit [08:41] pedronis: thanks! I noticed small issues with 7111 (not in your new code, that part looks fine). review should be ready soon [08:41] pedronis: deriveContent is missing a test and also never changes firstRun [08:41] hah, i was just about to ask about 6404 [08:43] i wish github had 'private' tags [08:43] ie that i could tag things without everybody seeing them as tagged [08:48] jamesh: what's the status of #5822 ? [08:48] PR #5822: wrappers: allow user mode systemd daemons [08:49] Chipaca: blocked on being able to control user daemons over snap install/upgrade/removal [08:49] hmmm [08:49] Chipaca: this is what the user session agent branches I've been working on are intended to solve [08:49] zyga: what happened to refresh control? (is that what we were calling it) [08:55] Chipaca: what's the context for that question? [08:55] also z-yga is supposed to be off today [08:58] pedronis: context of the question was that I thought we'd made progress on it, and that if we had that then refresh of things with user daemons would be a'ight ? dunno [08:58] was trying to figure out if/how those two fit together really [09:00] Chipaca: that is not refresh control, that's refresh awarere/prevent refreshes while running [09:00] yeah that [09:00] heh, awareness [09:00] Chipaca: but, there was progress, but daemon have they own rules [09:00] too late, it's awarere now [09:00] their [09:01] also we cannot really expect the user to be on top of daemons (vs gui apps) [09:01] so it's related but also orthogonal [09:01] to the issue of user session services [09:01] to me they are separate issues [09:01] one is preventing the refresh [09:01] pedronis: I will do the tiny fix in interfaces/seccomp/backend in 7111 because the current running tests are failing (network again it seems) so it seems to be fine to push this small fix (removing firstRun) [09:02] the other is notifying the user or the snap about the refresh [09:02] yes, we know that [09:02] there is a rather strong demand from good snap authors for them to be in the pipeline of this [09:02] that is [09:02] the snap wants to be told there is a refresh there [09:03] and for user-mode daemons, same thing could apply? again dunno, but, don't see why we can't start there [09:03] anyhow [09:03] moving on up the queue === pedronis_ is now known as pedronis [09:05] Chipaca: that work is discussed, tracked here: https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736/13 [09:05] fwiw [09:05] though that needs an update from a couple discussions in toronto [09:16] pro tip: don't start on the third page of PRs unless you're immune to getting into a funk [09:16] * Chipaca is not immune and needs a break now [09:17] Chipaca: to be fair atm we should just concetrate on 2.41 marked ones [09:18] * ogra plays some jazz to get Chipaca out of the funk [09:18] pedronis: I pushed a tiny patch to 7111, double checking would be appreicated [09:31] I have (as you may have seen earlier) a problem with launching graphical snaps. I have zyga helping me, but we have not figured it out. If anyone else has something to add it would be appriciated:) https://paste.ubuntu.com/p/MjhDYjt8GR/ [09:33] Aavar: I did not see. What's the output of 'snap version'? [09:33] mvo: I'll look in a bit [09:34] Chipaca, https://paste.ubuntu.com/p/Xv3zqPQCcC/ [09:35] Aavar: what's special about your installation? [09:37] Chipaca, hmm... Nothing more than that I have messed with it for about a year... THe last thing I did yesterday was to try to reinstall all the apt-packages on my system. [09:37] brb, lunch. [09:37] Aavar: are you running X? [09:38] mvo: I was reviewing #7254 [09:38] PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts [09:42] mvo: you have a change to templage.go that looks wrong [09:42] * Chipaca takes a break [09:59] hmm, it looks like core 18 is broken? [09:59] lots of core18 spread tests failing [10:01] Chipaca, I am running X yes. [10:02] pedronis: yeah, fixed. silly me [10:02] Aavar: can you snap install xbill-xaw? [10:03] Chipaca, yes, and then run it? [10:04] Aavar: yes please, run just 'xbill-xaw' [10:04] Chipaca, "Error: Can't open display: :0" [10:04] Chipaca, only that. [10:04] that's an odd one if you're not in Wayland [10:05] Aavar: can you 'snap run -strace xbill-xaw' please [10:05] --strace, no? [10:05] yes [10:05] probably [10:06] double that dash! [10:06] Chipaca, Got a bunch of errors. Let me paste that. [10:08] Chipaca, diddledan: https://paste.ubuntu.com/p/zHvtXYcmms/ [10:09] looks like the socket was EACCESS [10:09] i.e. permission denied for some reason [10:10] Aavar: dmesg | grep DENIED ? [10:10] what kind of desktop env and display manager is running there ? [10:11] random Windows folder name oddity for your bemusement :-) https://usercontent.irccloud-cdn.com/file/8lZTm56c/image.png [10:11] Chipaca, https://paste.ubuntu.com/p/XpDd8tTJKW/ [10:12] Aavar: I'm now suspicious of your apparmor [10:12] Chipaca, are there some way to completely shut down apparmor for testing? [10:13] Aavar: when you tried to reinstall all the apt-packages, did you reinstall apparmor? [10:13] (it's an apt package with that name) [10:14] Chipaca, I am not sure, but I guess so. I ran this script that is supposed to reinstall all packages. https://ubuntuforums.org/showthread.php?t=735693 [10:14] and what commands did you use to reinstall all the apt packages - might be you got your system in a wonky state by doing that [10:14] 2008 [10:14] yeah [10:15] (I know it's a bad idea run scripts from the internett, but I figured it was worth a try as I am stuck anyway...) [10:15] Aavar: didn't the "this has been tested on 7.10" alert you to anything? [10:15] mvo: frequent red, landing things will be hard [10:16] diddledan: for pkg in `dpkg --get-selections | awk '{print $1}' | egrep -v '(dpkg|apt|mysql|mythtv)'` ; do apt-get -y --force-yes install --reinstall $pkg ; done [10:16] i wonder what that is supposed to ahieve [10:16] *achieve [10:17] ogra: from the forum post above [10:17] Chipaca, I did read that, and figured that I would reinstall if it broke my system. To be fair, the script seemed to run fine and I am in the same spot now that I was before. [10:17] pedronis: yeah, the next red I will go berzerk and just disable tests [10:17] yes [10:17] i saw that [10:17] Aavar: do you have any data in ~/snap that you care about [10:17] Chipaca, nope. [10:17] still wondering ... it will only replace existing binaries and leave the configs alone [10:17] mvo: core 18 seems broken tho [10:17] Aavar: sudo apt purge snapd [10:17] Aavar: and then sudo apt install snapd [10:18] Chipaca, btw, I did try to add a new user and it gave me the same result. [10:18] Aavar: and then reboot [10:18] Chipaca, will do. brb [10:18] unlikely to change anything over what has been there ... unless someone actively rm'ed something from the rootfs [10:18] Chipaca: oh no? what exactly [10:18] mvo: "everything" :-p [10:18] I troll [10:18] * mvo hugs diddledan [10:19] ! [10:19] \o/ huggies! [10:19] mvo: https://api.travis-ci.org/v3/job/571891969/log.txt [10:19] mvo: i'm trying to figure out what exactly [10:19] mvo: bunch of apparently different errors, everything failed to prepare/restore and nothing succeeded afaict [10:19] Chipaca: :( I wonder if an core18 upload borke it [10:20] waiting for a debug run of spread to get me a shell now [10:20] so i can get more info [10:20] but, thought i'd mention it :) [10:21] diddledan: wrt that screenshot, if I saw that folder I'd assume it was malware and nuke the installation [10:23] it looks like the issue in that spread log might be related to coming back online after the reboot? [10:24] specifically there's several of these: `error: cannot communicate with server: Get http://localhost/v2/connections?select=all: read unix @->/run/snapd.socket: read: connection reset by peer` [10:25] maybe not after reboot - but after reboot or restart of core after the refresh [10:26] Chipaca, After reinstall I get this error: https://paste.ubuntu.com/p/S69zyQg8yM/ Do I need to start the daemon? [10:26] you will need to reinstall the snaps [10:26] Aavar: what's 'snap version' now? [10:27] oh I see you were [10:27] the daemon should automatically start IIRC [10:27] Aavar: maybe snapd was just taking a bit of time starting? what's the output of systemctl status snapd? [10:27] it's prolly refreshing itself? [10:28] either that, or we should send thoughts & prayers [10:28] mvo: no debug shell :-( [10:28] mvo: EOF of death [10:28] Chipaca, diddledan: https://paste.ubuntu.com/p/pzcjRqFVZm/ looks like the service is not running properly. [10:28] Aavar: yeah gonna need that status thing [10:28] * Chipaca prepares a wreath [10:29] Chipaca, sorry. https://paste.ubuntu.com/p/ZT8dQ35G7Y/ [10:30] Aavar: you've apparently changed things so services aren't started automatically on install? [10:30] Aavar: try sudo systemctl enable --now snapd.\* [10:30] Chipaca, not on purpose... [10:30] i don't remember if * worked for 'enable' [10:31] Aavar: I purposely did not say you did it intentionally [10:31] :) [10:31] Chipaca, * didn't work but I'll run it for all the services. [10:32] Aavar: k. some won't like being enabled but that's probably ok [10:32] (some of them are only for weird systems) [10:32] snap.service and snapd.socket should both be enabled [10:32] snapd.service* [10:32] * Chipaca struggling to type [10:33] Chipaca, ok, Now i'm installing xbill-xaw again. [10:34] Chipaca, or should I do something else? [10:34] Aavar: hold on [10:34] Aavar: what's the status of apparmor.service ? [10:35] Chipaca, Enabled and running it seems. https://paste.ubuntu.com/p/STBbmj24zN/ [10:37] Aavar: ok, try xbill again please [10:38] Chipaca, same :( [10:38] Aavar: if you want to figure out why, maybe jdstrand can shed some light on it (later in the day, it's early for him to be around) [10:39] Aavar: but at this point I'd say your system is fubar [10:40] mvo: do you know why core18 still does not include bash completion? i filed the bug ages ago :-( [10:42] Chipaca, Ok, I will try jdstrand. But I think you are right the system is destroyed. I mostly tried to fix this to learn, but a reinstall is possible too :) [10:42] Chipaca, thank you for your help :) [10:45] Bug #1840244 opened: docker snap cannot bind mount ssh sockets correctly [10:46] mvo: I can't reproduce the weird issues in actual core18, fwiw [10:53] Can someone on the snappy team please update https://launchpad.net/snappy [10:53] (the home page link is broken) [10:53] the first link points to https://launchpad.net/snapd which tells you to go to https://github.com/snapcore/snapd [10:55] morning folks [10:56] Chipaca: when you get time could you give another pass at my `snap model` PR (#7149) ? [10:56] ijohnson: yep [10:56] PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs [10:56] thanks [10:57] niemeyer: ^ I don't have access to modify those pages, would be good to make them less messy [10:58] I think I can change those [10:59] popey_: better? [11:00] it's still a click followed by another click to get to the snapd github - seems silly to say "go here for snapd" and then on that page it says "go HERE for snapd" [11:00] diddledan: only code is on github [11:01] diddledan: bugs are on launchpad [11:01] for snapd [11:02] <3 Chipaca thanks [11:02] ijohnson: what's the status of #6697 btw? [11:02] PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test [11:02] popey_: that was a quick drive-by but maybe degville can look into making it better at some point :) [11:02] * diddledan earworms you all: https://www.youtube.com/watch?v=O5HQ1sZseKg&t=93 [11:02] * Chipaca steps away quickly [11:03] I've been earwormed by that too hard [11:03] Chipaca: it would be good to get zyga's response, but really I'm waiting for jdstrand to comment as apparently there are some problems with my PR that hitherto have been too numerous to comment about [11:04] mvo, hey, about the go-build test, do you know if any change done lastly could affect it to take more time? [11:15] mvo: re-reviewed #6403, needs a little bit more work I think [11:16] sorry #6404 [11:16] PR #6403: many: cleanup golang.org/x/net/context [11:16] PR #6404: snapstate: auto transition on experimental.snapd-snap=true [11:17] cachio: we are timing out very often now? do we need more workers? [11:17] or something else [11:17] pedronis, the time outs are realted to the gobuild test [11:17] at least the last timeouts [11:18] pedronis, I am debugging the test to see the time it takes [11:20] pedronis, based on the logs the problem is related to 18.04, I think it should have the same number of workers than 16.04 [11:22] pedronis, https://paste.ubuntu.com/p/V7BqpSvVz4/ [11:25] btw it needs tweaking because now we have a couple of libraries in there [11:26] cachio: I think the archive is slower currently for whatever reason so fetching the debs for the building takes a long time [11:26] pedronis: thanks, thats fine, I move it to 2.42 then [11:26] mvo, pedronis based on logs the last system finishing always is ubuntu 18.04 [11:26] PR snapd#7258 opened: tests: adding more spread workers for ubuntu-18.04-64 [11:26] cachio: I wonder if we can try to use a in-cloud apt mirror (if there is such a thing) [11:26] mvo, pedronis #7258 [11:26] PR #7258: tests: adding more spread workers for ubuntu-18.04-64 [11:26] cachio: aha, ok. I probably need to look again then [11:27] cachio: more works is definitely a good idea [11:27] cachio, it is necesary based on the number of tests we are running on that system [11:27] cachio: don't think it affects time but we should replace -name \*.go with -name main.go in that test [11:27] it's building lib packages atm [11:27] for no good reason [11:28] pedronis, ah, ok [11:28] let me make that change [11:28] and measure the test time [11:28] we should make the change either way [11:28] it's the conceptual correct thing [11:29] we are just trying to build our commands [11:29] which are the entrypoints to everything else [11:29] pedronis, makes sense [11:30] pedronis, thanks [11:31] mvo: #7131 and #7133 need your reviews, the rest is a bit blocked on the red at this point [11:31] PR #7131: overlord/devicestate: detect clashing concurrent (ongoing, just finished) remodels or changes [11:31] PR #7133: overlord,daemon: adjust startup timeout via EXTEND_TIMEOUT_USEC using an estimate [11:48] PR snapd#7209 closed: firstboot: queue service commands before mark-seeded [11:50] mvo: do we need #7257 for 2.41 ? [11:50] PR #7257: packaging: fix symlink for snapd.session-agent.socket [12:08] PR snapd#7111 closed: many: support system-usernames for 'snap_daemon' user [12:48] mvo: ^ landed, I have now merged master into and tweaked #7112 [12:48] PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 [12:50] PR snapd#7259 opened: tests: just build snapd commands on go-build test [12:54] pedronis: we need 7257 yes [12:54] mvo: ok [12:54] pedronis: thanks, looking at 7112 now [12:55] jdstrand: hi, we landed 7111 after some more work, I reworked a bit 7112 further now [12:55] jdstrand: one issue to keep in mind for the future was error message style [12:57] mvo: I marked it for 2.41 (7257) [12:57] pedronis: thanks [13:23] jdstrand: btw, we need a review for #7254 [13:23] PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts [13:23] it's a bug fix that could go in 2.41 [13:24] pedronis: ack, I'm fixing up PR 7124 for the recent merge and fixups and will move to that after looking at ijohnson's questions [13:24] PR #7124: many: create system-usernames user/group if both don't exist [13:24] PR snapcraft#2663 closed: elf: handle invalid elf files [13:28] PR snapd#7258 closed: tests: adding more spread workers for ubuntu-18.04-64 [13:44] mvo: I marked the gadget update ones for 2.41, but let you do the honor of merging it [13:48] pedronis: thank you! [13:48] PR snapcraft#2664 opened: cli/clean: handle exception when cleaning a part with a fresh project [13:49] PR snapd#7253 closed: interfaces: remove BeforePrepareSlot from commonInterface [13:50] thanks jdstrand [13:52] PR snapd#7174 closed: overlord/configstate/configcore: allow setting start_x=1 to enable CSI camera on RPi [13:53] jdstrand: I re-added that attr for docker-support test so I think that's good to merge [13:53] mvo, pedronis, if tests are green can I merge #7010 too? or would you rather wait til after 2.41 is cut and put that for 2.42 [13:53] PR #7010: interfaces/docker-support: add controls-device-cgroup [13:55] ijohnson: yes, it has 2 +1 [13:55] ijohnson: I can do a final check if you want [13:56] mvo: no need, I'm sure you have more important things to look at right now :-) [13:56] (unless you want to of course) [14:01] ijohnson: seems the summary and the description will need updating though? it was using an attribute and doesn't anymore? [14:19] ijohnson: oh, daemon notify is not on my plate for today (not 2.41), but will look at netplan apply and docker-support [14:20] I netplan apply isn't 2.41 either, but still [14:26] jdstrand: the spread tests in 7124 will need tweaks because of the changes to the error messages [14:26] in the previous PRs [14:40] pedronis: ack [14:44] what was the in-cloud GCE mirror for apt again? I think someone mentioned it but I misplaced the reference :/ [14:48] mvo: it depends where in gce you are [14:48] e.g. europe-west1.gce.archive.ubuntu.com or us-central1.gce.archive.ubuntu.com [14:48] etc [14:48] ijohnson: fyi, I responded to your feedback in PR 7214 [14:48] PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages [14:49] mvo: maybe gce.clouds.archive.ubuntu.com figures it out? (dunno) [14:50] jdstrand that's fine no need to review the daemon notify anytime soon [14:50] Chipaca: thanks, that sounds right [14:51] thanks for the docker-support and the netplan apply comment [14:51] mvo, it looks like we will need to get one more change to upstream netplan apply D-Bus service file [14:51] oh? [14:51] ijtthe AssumeAppArmorLabel=unconfined ? [14:52] ijohnson: -^ [14:52] oh hey cyphermox didn't realize you were here too [14:52] mvo yes [14:52] ijohnson: yeah, I think this is why I'm a bit annoyed, IMNSHO this should be the default [14:52] ijohnson: asap please, I'm trying to cut a release atm [14:52] mvo: you are not the only one [14:52] okay, filing PR right now, it's just a single line change [14:52] * jdstrand shakes fist at dbus upstream [14:53] cyphermox: fyi, https://github.com/snapcore/snapd/pull/7214#discussion_r314333683 [14:53] PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages [14:53] jdstrand: I did a first pass at 7124 (haven't looked at the spread tests tough) [14:53] *though [14:53] jdstrand: heh :) can you point me to a bugreport/PR? at least then I can voice my opinion [14:53] pedronis: I'm adjusting spread now [14:58] alright verified the fix, cyphermox PR is here: https://github.com/CanonicalLtd/netplan/pull/101 [14:58] PR CanonicalLtd/netplan#101: io.netplan.Netplan.service.in: add assumed apparmor label [15:02] cool [15:07] cyphermox: oh sorry my local master was out-of-date do you want me to rebase? [15:07] jdstrand: let me know if you have questions on my comments [15:08] ijohnson: no it's all good [15:08] cyphermox ack thanks, sorry for the last minute rush [15:10] mvo: you added --extra-users support to userdel ? [15:11] what't the status of that [15:11] pedronis: I updated the PR title/description on #7010, lmk if you think it needs to be adjusted more [15:11] PR #7010: interfaces/docker-support: set controls-device-cgroup spec [15:12] pedronis: I did [15:12] mvo: ubuntu only though? [15:12] pedronis: its available in both bionic and xenial:https://launchpad.net/ubuntu/+source/shadow/1:4.5-1ubuntu2 andhttps://launchpad.net/ubuntu/+source/shadow/1:4.2-3.1ubuntu5.4 [15:13] pedronis: yes, its only useful on core anyway [15:13]