[00:46] <sarnold> is this the right channel for someone who's having trouble getting skype to work?
[02:30] <cjp256> sarnold: what is the problem you are having?
[02:32] <sarnold> 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] <sarnold> 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] <sarnold> 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] <sarnold> is this the right place to send people who are having trouble with snap?
[02:35] <cjp256> 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] <mup> PR snapd#7249 closed: packaging/fedora: build on RHEL8 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7249>
[04:58] <mup> PR snapd#7248 closed: interfaces/mount: discard mount ns on backend Remove <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7248>
[06:01] <pedronis> 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] <pedronis> mvo: sounds reasonable?
[06:21] <mvo> pedronis: yes
[06:21] <mvo> pedronis: thanks, once I finish some org stuff I will jump to the reviews for those
[06:33] <pedronis> mvo: the first one has already 2 +1 I'm tweaking it as we speak though
[06:34] <mvo> pedronis: first one is 7111 ?
[06:35] <pedronis> yes
[06:35] <pedronis> I'll ask you to check my tweaks once pushed
[06:35] <mvo> ta
[07:06] <jamesh> 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] <mvo> jamesh: nice! thats great to hear. thanks for this. I will have another look in some minutes then :)
[07:17] <pedronis> mmh
[07:36] <pedronis> mvo: can you look at my own commits to 7111
[07:36] <pedronis> that I just pushed
[07:43] <mvo> pedronis: yes
[08:06] <mup> PR snapd#7257 opened: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/7257>
[08:10] <mvo> welcome back mup !
[08:10]  * mvo hugs niemeyer 
[08:40] <pedronis> mvo: I'll look again at 6404 in a little bit
[08:41] <mvo> pedronis: thanks! I noticed small issues with 7111 (not in your new code, that part looks fine). review should be ready soon
[08:41] <mvo> pedronis: deriveContent is missing a test and also never changes firstRun
[08:41] <Chipaca> hah, i was just about to ask about 6404
[08:43] <Chipaca> i wish github had 'private' tags
[08:43] <Chipaca> ie that i could tag things without everybody seeing them as tagged
[08:48] <Chipaca> jamesh: what's the status of #5822 ?
[08:48] <mup> PR #5822: wrappers: allow user mode systemd daemons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
[08:49] <jamesh> Chipaca: blocked on being able to control user daemons over snap install/upgrade/removal
[08:49] <Chipaca> hmmm
[08:49] <jamesh> Chipaca: this is what the user session agent branches I've been working on are intended to solve
[08:49] <Chipaca> zyga: what happened to refresh control? (is that what we were calling it)
[08:55] <pedronis> Chipaca: what's the context for that question?
[08:55] <pedronis> also z-yga is supposed to be off today
[08:58] <Chipaca> 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] <Chipaca> was trying to figure out if/how those two fit together really
[09:00] <pedronis> Chipaca: that is not refresh control,  that's refresh awarere/prevent refreshes while running
[09:00] <Chipaca> yeah that
[09:00] <pedronis> heh, awareness
[09:00] <pedronis> Chipaca: but, there was progress, but daemon have they own rules
[09:00] <Chipaca> too late, it's awarere now
[09:00] <pedronis> their
[09:01] <pedronis> also we cannot really expect the user to be on top of daemons (vs gui apps)
[09:01] <pedronis> so it's related but also orthogonal
[09:01] <pedronis> to the issue of user session services
[09:01] <Chipaca> to me they are separate issues
[09:01] <Chipaca> one is preventing the refresh
[09:01] <mvo> 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] <Chipaca> the other is notifying the user or the snap about the refresh
[09:02] <pedronis> yes, we know that
[09:02] <Chipaca> there is a rather strong demand from good snap authors for them to be in the pipeline of this
[09:02] <Chipaca> that is
[09:02] <Chipaca> the snap wants to be told there is a refresh there
[09:03] <Chipaca> and for user-mode daemons, same thing could apply? again dunno, but, don't see why we can't start there
[09:03] <Chipaca> anyhow
[09:03] <Chipaca> moving on up the queue
[09:05] <pedronis> Chipaca: that work is discussed, tracked here: https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736/13
[09:05] <pedronis> fwiw
[09:05] <pedronis> though that needs an update from a couple discussions in toronto
[09:16] <Chipaca> 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] <pedronis> 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] <mvo> pedronis: I pushed a tiny patch to 7111, double checking would be appreicated
[09:31] <Aavar> 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] <Chipaca> Aavar: I did not see. What's the output of 'snap version'?
[09:33] <pedronis> mvo: I'll look in a bit
[09:34] <Aavar> Chipaca, https://paste.ubuntu.com/p/Xv3zqPQCcC/
[09:35] <Chipaca> Aavar: what's special about your installation?
[09:37] <Aavar> 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] <Aavar> brb, lunch.
[09:37] <Chipaca> Aavar: are you running X?
[09:38] <pedronis> mvo: I was reviewing #7254
[09:38] <mup> PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/7254>
[09:42] <pedronis> mvo: you have a change to templage.go that looks wrong
[09:42]  * Chipaca takes a break
[09:59] <Chipaca> hmm, it looks like core 18 is broken?
[09:59] <Chipaca> lots of core18 spread tests failing
[10:01] <Aavar> Chipaca, I am running X yes.
[10:02] <mvo> pedronis: yeah, fixed. silly me
[10:02] <Chipaca> Aavar: can you snap install xbill-xaw?
[10:03] <Aavar> Chipaca, yes, and then run it?
[10:04] <Chipaca> Aavar: yes please, run just 'xbill-xaw'
[10:04] <Aavar> Chipaca, "Error: Can't open display: :0"
[10:04] <Aavar> Chipaca, only that.
[10:04] <diddledan> that's an odd one if you're not in Wayland
[10:05] <Chipaca> Aavar: can you 'snap run -strace xbill-xaw' please
[10:05] <diddledan> --strace, no?
[10:05] <Chipaca> yes
[10:05] <Chipaca> probably
[10:06] <diddledan> double that dash!
[10:06] <Aavar> Chipaca, Got a bunch of errors. Let me paste that.
[10:08] <Aavar> Chipaca, diddledan: https://paste.ubuntu.com/p/zHvtXYcmms/
[10:09] <diddledan> looks like the socket was EACCESS
[10:09] <diddledan> i.e. permission denied for some reason
[10:10] <Chipaca> Aavar: dmesg | grep DENIED ?
[10:10] <ogra> what kind of desktop env and display manager is running there ?
[10:11] <diddledan> random Windows folder name oddity for your bemusement :-) https://usercontent.irccloud-cdn.com/file/8lZTm56c/image.png
[10:11] <Aavar> Chipaca, https://paste.ubuntu.com/p/XpDd8tTJKW/
[10:12] <Chipaca> Aavar: I'm now suspicious of your apparmor
[10:12] <Aavar> Chipaca, are there some way to completely shut down apparmor for testing?
[10:13] <Chipaca> Aavar: when you tried to reinstall all the apt-packages, did you reinstall apparmor?
[10:13] <Chipaca> (it's an apt package with that name)
[10:14] <Aavar> 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] <diddledan> 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] <Chipaca> 2008
[10:14] <Chipaca> yeah
[10:15] <Aavar> (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] <Chipaca> Aavar: didn't the "this has been tested on 7.10" alert you to anything?
[10:15] <pedronis> mvo: frequent red, landing things will be hard
[10:16] <Chipaca> 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] <ogra> i wonder what that is supposed to ahieve
[10:16] <ogra> *achieve
[10:17] <Chipaca> ogra: from the forum post above
[10:17] <Aavar> 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] <mvo> pedronis: yeah, the next red I will go berzerk and just disable tests
[10:17] <ogra> yes
[10:17] <ogra> i saw that
[10:17] <Chipaca> Aavar: do you have any data in ~/snap that you care about
[10:17] <Aavar> Chipaca, nope.
[10:17] <ogra> still wondering ... it will only replace existing binaries and leave the configs alone
[10:17] <Chipaca> mvo: core 18 seems broken tho
[10:17] <Chipaca> Aavar: sudo apt purge snapd
[10:17] <Chipaca> Aavar: and then sudo apt install snapd
[10:18] <Aavar> Chipaca, btw, I did try to add a new user and it gave me the same result.
[10:18] <Chipaca> Aavar: and then reboot
[10:18] <Aavar> Chipaca, will do. brb
[10:18] <ogra> unlikely to change anything over what has been there ... unless someone actively rm'ed something from the rootfs
[10:18] <mvo> Chipaca: oh no? what exactly
[10:18] <diddledan> mvo: "everything" :-p
[10:18] <diddledan> I troll
[10:18]  * mvo hugs diddledan 
[10:19] <ogra> !
[10:19] <diddledan> \o/ huggies!
[10:19] <Chipaca> mvo: https://api.travis-ci.org/v3/job/571891969/log.txt
[10:19] <Chipaca> mvo: i'm trying to figure out what exactly
[10:19] <Chipaca> mvo: bunch of apparently different errors, everything failed to prepare/restore and nothing succeeded afaict
[10:19] <mvo> Chipaca: :( I wonder if an core18 upload borke it
[10:20] <Chipaca> waiting for a debug run of spread to get me a shell now
[10:20] <Chipaca> so i can get more info
[10:20] <Chipaca> but, thought i'd mention it :)
[10:21] <Chipaca> diddledan: wrt that screenshot, if I saw that folder I'd assume it was malware and nuke the installation
[10:23] <diddledan> it looks like the issue in that spread log might be related to coming back online after the reboot?
[10:24] <diddledan> 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] <diddledan> maybe not after reboot - but after reboot or restart of core after the refresh
[10:26] <Aavar> Chipaca, After reinstall I get this error: https://paste.ubuntu.com/p/S69zyQg8yM/ Do I need to start the daemon?
[10:26] <diddledan> you will need to reinstall the snaps
[10:26] <Chipaca> Aavar: what's 'snap version' now?
[10:27] <diddledan> oh I see you were
[10:27] <diddledan> the daemon should automatically start IIRC
[10:27] <Chipaca> Aavar: maybe snapd was just taking a bit of time starting? what's the output of systemctl status snapd?
[10:27] <diddledan> it's prolly refreshing itself?
[10:28] <Chipaca> either that, or we should send thoughts & prayers
[10:28] <Chipaca> mvo: no debug shell :-(
[10:28] <Chipaca> mvo: EOF of death
[10:28] <Aavar> Chipaca, diddledan: https://paste.ubuntu.com/p/pzcjRqFVZm/ looks like the service is not running properly.
[10:28] <Chipaca> Aavar: yeah gonna need that status thing
[10:28]  * Chipaca prepares a wreath
[10:29] <Aavar> Chipaca, sorry. https://paste.ubuntu.com/p/ZT8dQ35G7Y/
[10:30] <Chipaca> Aavar: you've apparently changed things so services aren't started automatically on install?
[10:30] <Chipaca> Aavar: try sudo systemctl enable --now snapd.\*
[10:30] <Aavar> Chipaca, not on purpose...
[10:30] <Chipaca> i don't remember if * worked for 'enable'
[10:31] <Chipaca> Aavar: I purposely did not say you did it intentionally
[10:31] <Chipaca> :)
[10:31] <Aavar> Chipaca, * didn't work but I'll run it for all the services.
[10:32] <Chipaca> Aavar: k. some won't like being enabled but that's probably ok
[10:32] <Chipaca> (some of them are only for weird systems)
[10:32] <Chipaca> snap.service and snapd.socket should both be enabled
[10:32] <Chipaca> snapd.service*
[10:32]  * Chipaca struggling to type
[10:33] <Aavar> Chipaca, ok, Now i'm installing xbill-xaw again.
[10:34] <Aavar> Chipaca, or should I do something else?
[10:34] <Chipaca> Aavar: hold on
[10:34] <Chipaca> Aavar: what's the status of apparmor.service ?
[10:35] <Aavar> Chipaca, Enabled and running it seems. https://paste.ubuntu.com/p/STBbmj24zN/
[10:37] <Chipaca> Aavar: ok, try xbill again please
[10:38] <Aavar> Chipaca, same :(
[10:38] <Chipaca> 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] <Chipaca> Aavar: but at this point I'd say your system is fubar
[10:40] <Chipaca> mvo: do you know why core18 still does not include bash completion? i filed the bug ages ago :-(
[10:42] <Aavar> 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] <Aavar> Chipaca, thank you for your help :)
[10:45] <mup> Bug #1840244 opened: docker snap cannot bind mount ssh sockets correctly <Snappy:New> <https://launchpad.net/bugs/1840244>
[10:46] <Chipaca> mvo: I can't reproduce the weird issues in actual core18, fwiw
[10:53] <popey_> Can someone on the snappy team please update https://launchpad.net/snappy
[10:53] <popey_> (the home page link is broken)
[10:53] <popey_> the first link points to https://launchpad.net/snapd which tells you to go to https://github.com/snapcore/snapd
[10:55] <ijohnson> morning folks
[10:56] <ijohnson> Chipaca: when you get time could you give another pass at my `snap model` PR (#7149) ?
[10:56] <Chipaca> ijohnson: yep
[10:56] <mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
[10:56] <ijohnson> thanks
[10:57] <popey_> niemeyer: ^ I don't have access to modify those pages, would be good to make them less messy
[10:58] <Chipaca> I think I can change those
[10:59] <Chipaca> popey_: better?
[11:00] <diddledan> 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] <Chipaca> diddledan: only code is on github
[11:01] <Chipaca> diddledan: bugs are on launchpad
[11:01] <Chipaca> for snapd
[11:02] <popey_> <3 Chipaca thanks
[11:02] <Chipaca> ijohnson: what's the status of #6697 btw?
[11:02] <mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
[11:02] <Chipaca> 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] <diddledan> I've been earwormed by that too hard
[11:03] <ijohnson> 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] <cachio> mvo, hey, about the go-build test, do you know if any change done lastly could affect it to take more time?
[11:15] <pedronis> mvo: re-reviewed #6403, needs a little bit more work I think
[11:16] <pedronis> sorry #6404
[11:16] <mup> PR #6403: many: cleanup golang.org/x/net/context <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
[11:16] <mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
[11:17] <pedronis> cachio: we are timing out very often now? do we need more workers?
[11:17] <pedronis> or something else
[11:17] <cachio> pedronis, the time outs are realted to the gobuild test
[11:17] <cachio> at least the last timeouts
[11:18] <cachio> pedronis, I am debugging the test to see the time it takes
[11:20] <cachio> 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] <cachio> pedronis, https://paste.ubuntu.com/p/V7BqpSvVz4/
[11:25] <pedronis> btw it needs tweaking because now we have a couple of libraries in there
[11:26] <mvo> cachio: I think the archive is slower currently for whatever reason so fetching the debs for the building takes a long time
[11:26] <mvo> pedronis: thanks, thats fine, I move it to 2.42 then
[11:26] <cachio> mvo, pedronis based on logs the last system finishing always is ubuntu 18.04
[11:26] <mup> PR snapd#7258 opened: tests: adding more spread workers for ubuntu-18.04-64 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7258>
[11:26] <mvo> cachio: I wonder if we can try to use a in-cloud apt mirror (if there is such a thing)
[11:26] <cachio> mvo, pedronis #7258
[11:26] <mup> PR #7258: tests: adding more spread workers for ubuntu-18.04-64 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7258>
[11:26] <mvo> cachio: aha, ok. I probably need to look again then
[11:27] <mvo> cachio: more works is definitely a good idea
[11:27] <cachio> cachio, it is necesary based on the number of tests we are running on that system
[11:27] <pedronis> cachio: don't think it affects time but  we should replace -name \*.go  with -name main.go in that test
[11:27] <pedronis> it's building lib packages atm
[11:27] <pedronis> for no good reason
[11:28] <cachio> pedronis, ah, ok
[11:28] <cachio> let me make that change
[11:28] <cachio> and measure the test time
[11:28] <pedronis> we should make the change either way
[11:28] <pedronis> it's the conceptual correct thing
[11:29] <pedronis> we are just trying to build our commands
[11:29] <pedronis> which are the entrypoints to everything else
[11:29] <cachio> pedronis, makes sense
[11:30] <cachio> pedronis, thanks
[11:31] <pedronis> mvo: #7131 and #7133 need your reviews, the rest is a bit blocked on the red at this point
[11:31] <mup> PR #7131: overlord/devicestate: detect clashing concurrent (ongoing, just finished) remodels or changes <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7131>
[11:31] <mup> PR #7133: overlord,daemon: adjust startup timeout via EXTEND_TIMEOUT_USEC using an estimate <Created by pedronis> <https://github.com/snapcore/snapd/pull/7133>
[11:48] <mup> PR snapd#7209 closed: firstboot: queue service commands before mark-seeded <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7209>
[11:50] <pedronis> mvo: do we need #7257 for 2.41 ?
[11:50] <mup> PR #7257: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/7257>
[12:08] <mup> PR snapd#7111 closed: many: support system-usernames for 'snap_daemon' user <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7111>
[12:48] <pedronis> mvo: ^ landed, I have now merged master into and tweaked #7112
[12:48] <mup> PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7112>
[12:50] <mup> PR snapd#7259 opened: tests: just build snapd commands on go-build test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>
[12:54] <mvo> pedronis: we need 7257 yes
[12:54] <pedronis> mvo: ok
[12:54] <mvo> pedronis: thanks, looking at 7112 now
[12:55] <pedronis> jdstrand: hi, we landed 7111 after some more work,  I reworked a bit 7112 further now
[12:55] <pedronis> jdstrand: one issue to keep in mind for the future was error message style
[12:57] <pedronis> mvo: I marked it for 2.41 (7257)
[12:57] <mvo> pedronis: thanks
[13:23] <pedronis> jdstrand: btw, we need a review for #7254
[13:23] <mup> PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/7254>
[13:23] <pedronis> it's a bug fix that could go in 2.41
[13:24] <jdstrand> 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] <mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
[13:24] <mup> PR snapcraft#2663 closed: elf: handle invalid elf files <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2663>
[13:28] <mup> PR snapd#7258 closed: tests: adding more spread workers for ubuntu-18.04-64 <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7258>
[13:44] <pedronis> mvo: I marked the gadget update ones for 2.41, but let you do the honor of merging it
[13:48] <mvo> pedronis: thank you!
[13:48] <mup> PR snapcraft#2664 opened: cli/clean: handle exception when cleaning a part with a fresh project <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2664>
[13:49] <mup> PR snapd#7253 closed: interfaces: remove BeforePrepareSlot from commonInterface <Simple 😃> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7253>
[13:50] <ijohnson> thanks jdstrand
[13:52] <mup> PR snapd#7174 closed: overlord/configstate/configcore: allow setting start_x=1 to enable CSI camera on RPi <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7174>
[13:53] <ijohnson> jdstrand: I re-added that attr for docker-support test so I think that's good to merge
[13:53] <ijohnson> 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] <mup> PR #7010: interfaces/docker-support: add controls-device-cgroup <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>
[13:55] <mvo> ijohnson: yes, it has 2 +1
[13:55] <mvo> ijohnson: I can do a final check if you want
[13:56] <ijohnson> mvo: no need, I'm sure you have more important things to look at right now :-)
[13:56] <ijohnson> (unless you want to of course)
[14:01] <pedronis> ijohnson: seems the summary and the description will need updating though? it was using an attribute and doesn't anymore?
[14:19] <jdstrand> 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] <jdstrand> I netplan apply isn't 2.41 either, but still
[14:26] <pedronis> jdstrand: the spread tests in 7124 will need tweaks because of the changes to the error messages
[14:26] <pedronis> in the previous PRs
[14:40] <jdstrand> pedronis: ack
[14:44] <mvo> what was the in-cloud GCE mirror for apt again? I think someone mentioned it but I misplaced the reference :/
[14:48] <Chipaca> mvo: it depends where in gce you are
[14:48] <Chipaca> e.g. europe-west1.gce.archive.ubuntu.com or us-central1.gce.archive.ubuntu.com
[14:48] <Chipaca> etc
[14:48] <jdstrand> ijohnson: fyi, I responded to your feedback in PR 7214
[14:48] <mup> PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>
[14:49] <Chipaca> mvo: maybe gce.clouds.archive.ubuntu.com figures it out? (dunno)
[14:50] <ijohnson> jdstrand that's fine no need to review the daemon notify anytime soon
[14:50] <mvo> Chipaca: thanks, that sounds right
[14:51] <ijohnson> thanks for the docker-support and the netplan apply comment
[14:51] <ijohnson> mvo, it looks like we will need to get one more change to upstream netplan apply D-Bus service file
[14:51] <cyphermox> oh?
[14:51] <mvo> ijtthe AssumeAppArmorLabel=unconfined ?
[14:52] <mvo> ijohnson: -^
[14:52] <ijohnson> oh hey cyphermox didn't realize you were here too
[14:52] <ijohnson> mvo yes
[14:52] <mvo> ijohnson: yeah, I think this is why I'm a bit annoyed, IMNSHO this should be the default
[14:52] <cyphermox> ijohnson: asap please, I'm trying to cut a release atm
[14:52] <jdstrand> mvo: you are not the only one
[14:52] <ijohnson> okay, filing PR right now, it's just a single line change
[14:52]  * jdstrand shakes fist at dbus upstream
[14:53] <jdstrand> cyphermox: fyi, https://github.com/snapcore/snapd/pull/7214#discussion_r314333683
[14:53] <mup> PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>
[14:53] <pedronis> jdstrand: I did a first pass at 7124 (haven't looked at the spread tests tough)
[14:53] <pedronis> *though
[14:53] <mvo> jdstrand: heh :) can you point me to a bugreport/PR? at least then I can voice my opinion
[14:53] <jdstrand> pedronis: I'm adjusting spread now
[14:58] <ijohnson> alright verified the fix, cyphermox PR is here: https://github.com/CanonicalLtd/netplan/pull/101
[14:58] <mup> PR CanonicalLtd/netplan#101: io.netplan.Netplan.service.in: add assumed apparmor label <Created by anonymouse64> <https://github.com/CanonicalLtd/netplan/pull/101>
[15:02] <cyphermox> cool
[15:07] <ijohnson> cyphermox: oh sorry my local master was out-of-date do you want me to rebase?
[15:07] <pedronis> jdstrand: let me know if you have questions on my comments
[15:08] <cyphermox> ijohnson: no it's all good
[15:08] <ijohnson> cyphermox ack thanks, sorry for the last minute rush
[15:10] <pedronis> mvo: you added --extra-users support to userdel ?
[15:11] <pedronis> what't the status of that
[15:11] <ijohnson> pedronis: I updated the PR title/description on #7010, lmk if you think it needs to be adjusted more
[15:11] <mup> PR #7010: interfaces/docker-support: set controls-device-cgroup spec <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>
[15:12] <mvo> pedronis: I did
[15:12] <pedronis> mvo: ubuntu only though?
[15:12] <mvo> 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] <mvo> pedronis: yes, its only useful on core anyway
[15:13] <pedronis> ah, yes
[15:13] <pedronis> jdstrand: ^
[15:17] <mvo> pedronis: 7112 LGTM - do you wanto to do the second review or do we need to find someone else?
[15:18] <mvo> (its also green which is a big plus :)
[15:18] <pedronis> I think  if Chipaca gave it a look it would be better
[15:18] <pedronis> given that I tweaked it quite a bit
[15:18] <Chipaca> i can do that
[15:20] <Chipaca> mvo: so
[15:20] <Chipaca> mvo: us-east1.gce.archive.ubuntu.com
[15:20] <Chipaca> mvo: has a ping of .5ms
[15:20] <Chipaca> mvo: from our spread machines
[15:21] <Chipaca> mvo: that's probably the one we want
[15:21] <pedronis> ijohnson: looks alright, 7010 description. I changed the summary a bit again
[15:21] <mup> PR snapd#7087 closed: overlord/devicestate, tests: use gadget.Update() proper, spread test <Gadget update> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7087>
[15:22] <Chipaca> mvo: gce.cloud.a.u.c is ~24ms away so whatever it is, it isn't the one we want
[15:22] <Chipaca> mvo: (that's worse than a.u.c itself)
[15:22] <jdstrand> pedronis: https://github.com/snapcore/snapd/pull/7124#discussion_r314360718
[15:22] <mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
[15:22] <mvo> Chipaca: nice!
[15:22] <mvo> Chipaca: thanks for figuring this out
[15:23] <mvo> Chipaca: I think this will help a lot if we can update our tests to use the gce mirror when inside gce
[15:23] <ijohnson> pedronis: looks good thanks
[15:23] <jdstrand> pedronis: ack that userdel now supports --extrausers (it didn't when I wrote the initial PR 6681 :)
[15:23] <pedronis> jdstrand: thx, that would be ideal
[15:23] <mup> PR #6681: many: support system-users for 'daemon' user <Complex> <⛔ Blocked> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
[15:23] <pedronis> also much cleaner
[15:23] <Chipaca> mvo: also, cloud-id -l | cut -f2 → us-east1
[15:24] <pedronis> jdstrand: also note my comment about user.Lookup* returning Unknown* vs other errors
[15:24] <jdstrand> mvo: does groupdel suppoer --extrausers?
[15:24] <jdstrand> support*
[15:24] <jdstrand> $ groupdel --extrausers foo
[15:24] <jdstrand> groupdel: unrecognized option '--extrausers'
[15:27] <jdstrand> I need groupdel since we necessarily must use groupadd then useradd since useradd with --user-group chooses something from the range in login.defs
[15:27] <jdstrand> pedronis, mvo: ^
[15:28] <jdstrand> but that could be in a followup PR. I can clean up on classic and add a comment for core
[15:28] <diddledan> I still haven't worked out which I should use to add and remove users - adduser or useradd
[15:28] <diddledan> they're not the same...
[15:28] <jdstrand> diddledan: on a Debian-derived system, adduser
[15:28] <jdstrand> it has a nicer interface
[15:28] <pedronis> jdstrand: yes, can leave a TODO, much easier either way if this is encapsulated, vs in snapstate
[15:28] <jdstrand> but isn't portable
[15:28] <jdstrand> pedronis: I understand
[15:29] <jdstrand> diddledan: if you just want it to always work everywhere all the time, useradd, but you have to be careful with it
[15:29] <mvo> jdstrand: uh, oh. ok - it seems like there is some work to do there then :/
[15:29] <mvo> jdstrand: (groupdel --extrausers)
[15:30]  * jdstrand nods
[15:30] <mvo> jdstrand: this is a blocker, yes?
[15:30] <diddledan> gotcha
[15:30] <jdstrand> mvo: no
[15:30] <jdstrand> mvo: I can cleanup on classic, add a todo for core to cleanup when groupdel --extrausers is available
[15:30] <jdstrand> (see Samuele's comment above ^)
[15:31] <Chipaca> mvo, pedronis, #7112 GTG FWIW
[15:31] <mup> PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7112>
[15:31] <mvo> Chipaca: please merge
[15:31] <Chipaca> too late, pedronis did already :)
[15:32] <pedronis> jdstrand: ^
[15:32] <mup> PR snapd#7112 closed: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7112>
[15:32] <jdstrand> \o/
[15:33] <ijohnson> yay
[15:36] <mup> PR snapcraft#2665 opened: Plugin catkin: disable parallel option <Created by artivis> <https://github.com/snapcore/snapcraft/pull/2665>
[16:14]  * cachio lunch
[16:51] <juliank> Is there a way for me to workaround apparmor denials?
[16:51] <juliank> I'm trying to build a blog post, but the hugo snap confinement is borken
[17:14] <ogra> juliank, what kind of denials ...
[17:14] <juliank> ogra: simply /etc/gitconfig https://github.com/gohugoio/hugo/issues/6226
[17:15] <juliank> I switched it to devmode to be able to proceed, but that's suboptimal :D
[17:15] <ogra> juliank, there is a system-files interface that allows read access to such locations, but you need to file a request on the forum for it
[17:16] <ogra> (if you cant just ship git inside your snap and point the app to the in-snap config which would be the usual way to do this without interfaces)
[17:16] <juliank> I don't think it really needs the gitconfig
[17:17] <juliank> it's like doing git describe HEAD or something
[17:17] <juliank> But I was looking for a more confined local workaround than devmode-ing it
[17:17] <ogra> well, you could hack around it by shipping a git binary that simply links to $SNAP/bin/true or some such ...
[17:18] <ogra> if /etc/gitconfig is unavoidable the system-files interfact is the way to go though
[17:19] <ogra> https://forum.snapcraft.io/t/the-system-files-interface/9358
[17:19] <juliank> I was just hoping to hack in /etc/gitconfig into the local apparmor profile I have running while upstream figures out what to do :)
[17:19] <ogra> oh, you could probably also use a layout
[17:19] <ogra> https://forum.snapcraft.io/t/snap-layouts/7207
[17:20] <ogra> i dont think hacking apparmor profiles is an option out of using an interface
[17:20] <juliank> That's all useful for the people doing the snap
[17:20] <ogra> (you can surely do that locally for yourself but would denied store uploads with that)
[17:20] <juliank> But I'm just using it and want to workaround it :)
[17:21] <ogra> ah, then hacking the profile is indeed an option ... i'll hand you over to jdstrand for that one ;)
[17:22] <ogra> the profile shuld be in /var/lib/snapd/apparmor/profiles/
[17:22] <ogra> but i dont know the runes for re-geneating it properly from the top of my head
[17:23] <juliank> ah I can hack that in and then apparmor_parser -r it
[17:23] <juliank> not a permanent solution, but ok
[17:26] <ogra> yeah, as i said, layouts or system-files or shipping your own gitconfig in the snap and pointing the app to it are the ways
[17:28] <ogra> (i'm actually curious what /etc/gitconfig would be ... i have never seen it on an ubuntu system)
[17:33] <ogra> juliank, btw, you can tell the guys to simply set GIT_CONFIG_NOSYSTEM=true in their app launcher in snapcraft.yaml ;)
[17:34] <ogra> that will avoid looking for a (likely non-existent) systemwide git configuration
[17:34] <mup> PR snapd#7255 closed: store: use track/risk for "channel" name when parsing store details <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7255>
[17:34] <juliank> ogra: good idea
[17:35] <mup> PR snapd#7251 closed: packaging: fix removal of old apparmor profile <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7251>
[17:47] <juliank> ogra: I just did
[18:14] <jdstrand> juliank: if you want to modify a profile locally, you can edit the profile for the command in /var/lib/snapd/apparmor/profiles/snap.... then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap....
[18:15] <jdstrand> juliank: not that snapd while undo your change at various times (after reboot, refresh, etc)
[18:15] <juliank> jdstrand: yes thanks, just the path to the profile was enough already :)
[18:15] <jdstrand> note*
[18:15] <juliank> also *will
[18:15] <juliank> but yes
[18:15] <jdstrand> heh, yes, will* :)
[18:15] <juliank> But as ogra pointed out GIT_CONFIG_NOSYSTEM=true, just setting that when launching hugo works just fine too :)
[18:22] <mup> PR snapd#7260 opened: tests: add a runtime scripts generation to generate scripts to call functions <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7260>
[19:07] <mup> PR snapcraft#2666 opened: tests: move meta testing to its own package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2666>
[19:16] <mup> PR snapcraft#2667 opened: yaml utils: move OctInt from meta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2667>
[19:34]  * ijohnson reboots
[20:29] <mup> PR snapd#7261 opened: [WIP] interfaces/serial-port: support pci bus serial-port with Hotplu… <Hotplug 🔌> <Precious Logs> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7261>
[20:59] <mup> PR snapd#7262 opened: tests: use a different archive based on the spread backend on go-build test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7262>
[21:43] <mup> PR snapcraft#2668 opened: Restore cmake artifacts <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2668>
[22:26] <lifeless> morningish :)
[22:27] <lifeless> so I filed https://bugs.launchpad.net/snappy/+bug/1840244 last night, and I'd like to know how to fix it locally
[22:27] <mup> Bug #1840244: docker snap cannot bind mount ssh sockets correctly <Snappy:New> <https://launchpad.net/bugs/1840244>
[22:28] <lifeless> where fix means 'run those components with the global /tmp rather than their own namespace' - as doing a deep integration seems like a snappy long term project goal, and this ia a regression to be fixed vs upstreams regular delivered packaging as a deb or whatever
[22:33] <lifeless> mwhudson: ^
[22:34] <mwhudson> lifeless: pretty sure all snap things run with private /tmp, not there's a quick fix for that
[22:35] <lifeless> ah; theres some reference to a docker-privilege command, but it doesn't seem to exist, and there's no link to the packaging source anywhere that I can see
[22:35] <lifeless> (on https://snapcraft.io/docker )
[22:38] <lifeless> I guess I'll have to bind mount /tmp to /tmp2 or some such
[22:40] <lifeless> how do you disable automatic snapshots on uininstall
[22:40] <lifeless> I don't want an archive of GBs of docker images
[22:41] <mwhudson> there were some forum posts about that sort of thing, i don't remember the details though
[22:41] <lifeless> found it https://snapcraft.io/docs/snapshots
[22:41] <lifeless> To disable automatic snapshots, set the retention time to no:
[22:41] <lifeless> $ snap set system snapshots.automatic.retention=no
[22:42] <mwhudson> i don't think mounting /tmp at /tmp2 will help, will it? needs to be something that gets propagated into the docker snap's mount namespace (and i don't know what that is off the top of my head)
[22:43] <lifeless> I can make /tmp for everyone else be /tmp2 bind mounted to /tmp if I have to
[22:44] <lifeless> but my current plan is to just stop using snappy