/srv/irclogs.ubuntu.com/2019/08/15/#snappy.txt

sarnoldis this the right channel for someone who's having trouble getting skype to work?00:46
cjp256sarnold: what is the problem you are having?02:30
sarnoldcjp256: 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 skype02:32
sarnoldcjp256: 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 work02:33
sarnoldI 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 end02:34
sarnoldis this the right place to send people who are having trouble with snap?02:34
cjp256it 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... :D02:35
mupPR snapd#7249 closed: packaging/fedora: build on RHEL8 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7249>04:57
mupPR snapd#7248 closed: interfaces/mount: discard mount ns on backend Remove <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7248>04:58
pedronismvo: 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 one06:01
pedronismvo: sounds reasonable?06:12
mvopedronis: yes06:21
mvopedronis: thanks, once I finish some org stuff I will jump to the reviews for those06:21
pedronismvo: the first one has already 2 +1 I'm tweaking it as we speak though06:33
mvopedronis: first one is 7111 ?06:34
pedronisyes06:35
pedronisI'll ask you to check my tweaks once pushed06:35
mvota06:35
jameshmvo: 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:06
mvojamesh: nice! thats great to hear. thanks for this. I will have another look in some minutes then :)07:08
pedronismmh07:17
pedronismvo: can you look at my own commits to 711107:36
pedronisthat I just pushed07:36
mvopedronis: yes07:43
mupPR snapd#7257 opened: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/7257>08:06
mvowelcome back mup !08:10
* mvo hugs niemeyer 08:10
pedronismvo: I'll look again at 6404 in a little bit08:40
mvopedronis: thanks! I noticed small issues with 7111 (not in your new code, that part looks fine). review should be ready soon08:41
mvopedronis: deriveContent is missing a test and also never changes firstRun08:41
Chipacahah, i was just about to ask about 640408:41
Chipacai wish github had 'private' tags08:43
Chipacaie that i could tag things without everybody seeing them as tagged08:43
Chipacajamesh: what's the status of #5822 ?08:48
mupPR #5822: wrappers: allow user mode systemd daemons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>08:48
jameshChipaca: blocked on being able to control user daemons over snap install/upgrade/removal08:49
Chipacahmmm08:49
jameshChipaca: this is what the user session agent branches I've been working on are intended to solve08:49
Chipacazyga: what happened to refresh control? (is that what we were calling it)08:49
pedronisChipaca: what's the context for that question?08:55
pedronisalso z-yga is supposed to be off today08:55
Chipacapedronis: 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 ? dunno08:58
Chipacawas trying to figure out if/how those two fit together really08:58
pedronisChipaca: that is not refresh control,  that's refresh awarere/prevent refreshes while running09:00
Chipacayeah that09:00
pedronisheh, awareness09:00
pedronisChipaca: but, there was progress, but daemon have they own rules09:00
Chipacatoo late, it's awarere now09:00
pedronistheir09:00
pedronisalso we cannot really expect the user to be on top of daemons (vs gui apps)09:01
pedronisso it's related but also orthogonal09:01
pedronisto the issue of user session services09:01
Chipacato me they are separate issues09:01
Chipacaone is preventing the refresh09:01
mvopedronis: 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:01
Chipacathe other is notifying the user or the snap about the refresh09:02
pedronisyes, we know that09:02
Chipacathere is a rather strong demand from good snap authors for them to be in the pipeline of this09:02
Chipacathat is09:02
Chipacathe snap wants to be told there is a refresh there09:02
Chipacaand for user-mode daemons, same thing could apply? again dunno, but, don't see why we can't start there09:03
Chipacaanyhow09:03
Chipacamoving on up the queue09:03
=== pedronis_ is now known as pedronis
pedronisChipaca: that work is discussed, tracked here: https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736/1309:05
pedronisfwiw09:05
pedronisthough that needs an update from a couple discussions in toronto09:05
Chipacapro tip: don't start on the third page of PRs unless you're immune to getting into a funk09:16
* Chipaca is not immune and needs a break now09:16
pedronisChipaca: to be fair atm we should just concetrate on 2.41 marked ones09:17
* ogra plays some jazz to get Chipaca out of the funk09:18
mvopedronis: I pushed a tiny patch to 7111, double checking would be appreicated09:18
AavarI 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:31
ChipacaAavar: I did not see. What's the output of 'snap version'?09:33
pedronismvo: I'll look in a bit09:33
AavarChipaca, https://paste.ubuntu.com/p/Xv3zqPQCcC/09:34
ChipacaAavar: what's special about your installation?09:35
AavarChipaca, 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
Aavarbrb, lunch.09:37
ChipacaAavar: are you running X?09:37
pedronismvo: I was reviewing #725409:38
mupPR #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:38
pedronismvo: you have a change to templage.go that looks wrong09:42
* Chipaca takes a break09:42
Chipacahmm, it looks like core 18 is broken?09:59
Chipacalots of core18 spread tests failing09:59
AavarChipaca, I am running X yes.10:01
mvopedronis: yeah, fixed. silly me10:02
ChipacaAavar: can you snap install xbill-xaw?10:02
AavarChipaca, yes, and then run it?10:03
ChipacaAavar: yes please, run just 'xbill-xaw'10:04
AavarChipaca, "Error: Can't open display: :0"10:04
AavarChipaca, only that.10:04
diddledanthat's an odd one if you're not in Wayland10:04
ChipacaAavar: can you 'snap run -strace xbill-xaw' please10:05
diddledan--strace, no?10:05
Chipacayes10:05
Chipacaprobably10:05
diddledandouble that dash!10:06
AavarChipaca, Got a bunch of errors. Let me paste that.10:06
AavarChipaca, diddledan: https://paste.ubuntu.com/p/zHvtXYcmms/10:08
diddledanlooks like the socket was EACCESS10:09
diddledani.e. permission denied for some reason10:09
ChipacaAavar: dmesg | grep DENIED ?10:10
ograwhat kind of desktop env and display manager is running there ?10:10
diddledanrandom Windows folder name oddity for your bemusement :-) https://usercontent.irccloud-cdn.com/file/8lZTm56c/image.png10:11
AavarChipaca, https://paste.ubuntu.com/p/XpDd8tTJKW/10:11
ChipacaAavar: I'm now suspicious of your apparmor10:12
AavarChipaca, are there some way to completely shut down apparmor for testing?10:12
ChipacaAavar: 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:13
AavarChipaca, 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=73569310:14
diddledanand what commands did you use to reinstall all the apt packages - might be you got your system in a wonky state by doing that10:14
Chipaca200810:14
Chipacayeah10:14
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
ChipacaAavar: didn't the "this has been tested on 7.10" alert you to anything?10:15
pedronismvo: frequent red, landing things will be hard10:15
Chipacadiddledan: for pkg in `dpkg --get-selections | awk '{print $1}' | egrep -v '(dpkg|apt|mysql|mythtv)'` ; do apt-get -y --force-yes install --reinstall $pkg ; done10:16
ograi wonder what that is supposed to ahieve10:16
ogra*achieve10:16
Chipacaogra: from the forum post above10:17
AavarChipaca, 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
mvopedronis: yeah, the next red I will go berzerk and just disable tests10:17
ograyes10:17
ograi saw that10:17
ChipacaAavar: do you have any data in ~/snap that you care about10:17
AavarChipaca, nope.10:17
ograstill wondering ... it will only replace existing binaries and leave the configs alone10:17
Chipacamvo: core 18 seems broken tho10:17
ChipacaAavar: sudo apt purge snapd10:17
ChipacaAavar: and then sudo apt install snapd10:17
AavarChipaca, btw, I did try to add a new user and it gave me the same result.10:18
ChipacaAavar: and then reboot10:18
AavarChipaca, will do. brb10:18
ograunlikely to change anything over what has been there ... unless someone actively rm'ed something from the rootfs10:18
mvoChipaca: oh no? what exactly10:18
diddledanmvo: "everything" :-p10:18
diddledanI troll10:18
* mvo hugs diddledan 10:18
ogra!10:19
diddledan\o/ huggies!10:19
Chipacamvo: https://api.travis-ci.org/v3/job/571891969/log.txt10:19
Chipacamvo: i'm trying to figure out what exactly10:19
Chipacamvo: bunch of apparently different errors, everything failed to prepare/restore and nothing succeeded afaict10:19
mvoChipaca: :( I wonder if an core18 upload borke it10:19
Chipacawaiting for a debug run of spread to get me a shell now10:20
Chipacaso i can get more info10:20
Chipacabut, thought i'd mention it :)10:20
Chipacadiddledan: wrt that screenshot, if I saw that folder I'd assume it was malware and nuke the installation10:21
diddledanit looks like the issue in that spread log might be related to coming back online after the reboot?10:23
diddledanspecifically 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:24
diddledanmaybe not after reboot - but after reboot or restart of core after the refresh10:25
AavarChipaca, After reinstall I get this error: https://paste.ubuntu.com/p/S69zyQg8yM/ Do I need to start the daemon?10:26
diddledanyou will need to reinstall the snaps10:26
ChipacaAavar: what's 'snap version' now?10:26
diddledanoh I see you were10:27
diddledanthe daemon should automatically start IIRC10:27
ChipacaAavar: maybe snapd was just taking a bit of time starting? what's the output of systemctl status snapd?10:27
diddledanit's prolly refreshing itself?10:27
Chipacaeither that, or we should send thoughts & prayers10:28
Chipacamvo: no debug shell :-(10:28
Chipacamvo: EOF of death10:28
AavarChipaca, diddledan: https://paste.ubuntu.com/p/pzcjRqFVZm/ looks like the service is not running properly.10:28
ChipacaAavar: yeah gonna need that status thing10:28
* Chipaca prepares a wreath10:28
AavarChipaca, sorry. https://paste.ubuntu.com/p/ZT8dQ35G7Y/10:29
ChipacaAavar: you've apparently changed things so services aren't started automatically on install?10:30
ChipacaAavar: try sudo systemctl enable --now snapd.\*10:30
AavarChipaca, not on purpose...10:30
Chipacai don't remember if * worked for 'enable'10:30
ChipacaAavar: I purposely did not say you did it intentionally10:31
Chipaca:)10:31
AavarChipaca, * didn't work but I'll run it for all the services.10:31
ChipacaAavar: k. some won't like being enabled but that's probably ok10:32
Chipaca(some of them are only for weird systems)10:32
Chipacasnap.service and snapd.socket should both be enabled10:32
Chipacasnapd.service*10:32
* Chipaca struggling to type10:32
AavarChipaca, ok, Now i'm installing xbill-xaw again.10:33
AavarChipaca, or should I do something else?10:34
ChipacaAavar: hold on10:34
ChipacaAavar: what's the status of apparmor.service ?10:34
AavarChipaca, Enabled and running it seems. https://paste.ubuntu.com/p/STBbmj24zN/10:35
ChipacaAavar: ok, try xbill again please10:37
AavarChipaca, same :(10:38
ChipacaAavar: 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:38
ChipacaAavar: but at this point I'd say your system is fubar10:39
Chipacamvo: do you know why core18 still does not include bash completion? i filed the bug ages ago :-(10:40
AavarChipaca, 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
AavarChipaca, thank you for your help :)10:42
mupBug #1840244 opened: docker snap cannot bind mount ssh sockets correctly <Snappy:New> <https://launchpad.net/bugs/1840244>10:45
Chipacamvo: I can't reproduce the weird issues in actual core18, fwiw10:46
popey_Can someone on the snappy team please update https://launchpad.net/snappy10: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/snapd10:53
ijohnsonmorning folks10:55
ijohnsonChipaca: when you get time could you give another pass at my `snap model` PR (#7149) ?10:56
Chipacaijohnson: yep10:56
mupPR #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
ijohnsonthanks10:56
popey_niemeyer: ^ I don't have access to modify those pages, would be good to make them less messy10:57
ChipacaI think I can change those10:58
Chipacapopey_: better?10:59
diddledanit'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
Chipacadiddledan: only code is on github11:00
Chipacadiddledan: bugs are on launchpad11:01
Chipacafor snapd11:01
popey_<3 Chipaca thanks11:02
Chipacaijohnson: what's the status of #6697 btw?11:02
mupPR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>11:02
Chipacapopey_: 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=9311:02
* Chipaca steps away quickly11:02
diddledanI've been earwormed by that too hard11:03
ijohnsonChipaca: 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 about11:03
cachiomvo, hey, about the go-build test, do you know if any change done lastly could affect it to take more time?11:04
pedronismvo: re-reviewed #6403, needs a little bit more work I think11:15
pedronissorry #640411:16
mupPR #6403: many: cleanup golang.org/x/net/context <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>11:16
mupPR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>11:16
pedroniscachio: we are timing out very often now? do we need more workers?11:17
pedronisor something else11:17
cachiopedronis, the time outs are realted to the gobuild test11:17
cachioat least the last timeouts11:17
cachiopedronis, I am debugging the test to see the time it takes11:18
cachiopedronis, based on the logs the problem is related to 18.04, I think it should have the same number of workers than 16.0411:20
cachiopedronis, https://paste.ubuntu.com/p/V7BqpSvVz4/11:22
pedronisbtw it needs tweaking because now we have a couple of libraries in there11:25
mvocachio: I think the archive is slower currently for whatever reason so fetching the debs for the building takes a long time11:26
mvopedronis: thanks, thats fine, I move it to 2.42 then11:26
cachiomvo, pedronis based on logs the last system finishing always is ubuntu 18.0411:26
mupPR 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
mvocachio: I wonder if we can try to use a in-cloud apt mirror (if there is such a thing)11:26
cachiomvo, pedronis #725811:26
mupPR #7258: tests: adding more spread workers for ubuntu-18.04-64 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7258>11:26
mvocachio: aha, ok. I probably need to look again then11:26
mvocachio: more works is definitely a good idea11:27
cachiocachio, it is necesary based on the number of tests we are running on that system11:27
pedroniscachio: don't think it affects time but  we should replace -name \*.go  with -name main.go in that test11:27
pedronisit's building lib packages atm11:27
pedronisfor no good reason11:27
cachiopedronis, ah, ok11:28
cachiolet me make that change11:28
cachioand measure the test time11:28
pedroniswe should make the change either way11:28
pedronisit's the conceptual correct thing11:28
pedroniswe are just trying to build our commands11:29
pedroniswhich are the entrypoints to everything else11:29
cachiopedronis, makes sense11:29
cachiopedronis, thanks11:30
pedronismvo: #7131 and #7133 need your reviews, the rest is a bit blocked on the red at this point11:31
mupPR #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
mupPR #7133: overlord,daemon: adjust startup timeout via EXTEND_TIMEOUT_USEC using an estimate <Created by pedronis> <https://github.com/snapcore/snapd/pull/7133>11:31
mupPR snapd#7209 closed: firstboot: queue service commands before mark-seeded <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7209>11:48
pedronismvo: do we need #7257 for 2.41 ?11:50
mupPR #7257: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/7257>11:50
mupPR 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:08
pedronismvo: ^ landed, I have now merged master into and tweaked #711212:48
mupPR #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:48
mupPR snapd#7259 opened: tests: just build snapd commands on go-build test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>12:50
mvopedronis: we need 7257 yes12:54
pedronismvo: ok12:54
mvopedronis: thanks, looking at 7112 now12:54
pedronisjdstrand: hi, we landed 7111 after some more work,  I reworked a bit 7112 further now12:55
pedronisjdstrand: one issue to keep in mind for the future was error message style12:55
pedronismvo: I marked it for 2.41 (7257)12:57
mvopedronis: thanks12:57
pedronisjdstrand: btw, we need a review for #725413:23
mupPR #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
pedronisit's a bug fix that could go in 2.4113:23
jdstrandpedronis: ack, I'm fixing up PR 7124 for the recent merge and fixups and will move to that after looking at ijohnson's questions13:24
mupPR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>13:24
mupPR snapcraft#2663 closed: elf: handle invalid elf files <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2663>13:24
mupPR 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:28
pedronismvo: I marked the gadget update ones for 2.41, but let you do the honor of merging it13:44
mvopedronis: thank you!13:48
mupPR 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:48
mupPR snapd#7253 closed: interfaces: remove BeforePrepareSlot from commonInterface <Simple 😃> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7253>13:49
ijohnsonthanks jdstrand13:50
mupPR 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:52
ijohnsonjdstrand: I re-added that attr for docker-support test so I think that's good to merge13:53
ijohnsonmvo, 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.4213:53
mupPR #7010: interfaces/docker-support: add controls-device-cgroup <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>13:53
mvoijohnson: yes, it has 2 +113:55
mvoijohnson: I can do a final check if you want13:55
ijohnsonmvo: no need, I'm sure you have more important things to look at right now :-)13:56
ijohnson(unless you want to of course)13:56
pedronisijohnson: seems the summary and the description will need updating though? it was using an attribute and doesn't anymore?14:01
jdstrandijohnson: oh, daemon notify is not on my plate for today (not 2.41), but will look at netplan apply and docker-support14:19
jdstrandI netplan apply isn't 2.41 either, but still14:20
pedronisjdstrand: the spread tests in 7124 will need tweaks because of the changes to the error messages14:26
pedronisin the previous PRs14:26
jdstrandpedronis: ack14:40
mvowhat was the in-cloud GCE mirror for apt again? I think someone mentioned it but I misplaced the reference :/14:44
Chipacamvo: it depends where in gce you are14:48
Chipacae.g. europe-west1.gce.archive.ubuntu.com or us-central1.gce.archive.ubuntu.com14:48
Chipacaetc14:48
jdstrandijohnson: fyi, I responded to your feedback in PR 721414:48
mupPR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>14:48
Chipacamvo: maybe gce.clouds.archive.ubuntu.com figures it out? (dunno)14:49
ijohnsonjdstrand that's fine no need to review the daemon notify anytime soon14:50
mvoChipaca: thanks, that sounds right14:50
ijohnsonthanks for the docker-support and the netplan apply comment14:51
ijohnsonmvo, it looks like we will need to get one more change to upstream netplan apply D-Bus service file14:51
cyphermoxoh?14:51
mvoijtthe AssumeAppArmorLabel=unconfined ?14:51
mvoijohnson: -^14:52
ijohnsonoh hey cyphermox didn't realize you were here too14:52
ijohnsonmvo yes14:52
mvoijohnson: yeah, I think this is why I'm a bit annoyed, IMNSHO this should be the default14:52
cyphermoxijohnson: asap please, I'm trying to cut a release atm14:52
jdstrandmvo: you are not the only one14:52
ijohnsonokay, filing PR right now, it's just a single line change14:52
* jdstrand shakes fist at dbus upstream14:52
jdstrandcyphermox: fyi, https://github.com/snapcore/snapd/pull/7214#discussion_r31433368314:53
mupPR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>14:53
pedronisjdstrand: I did a first pass at 7124 (haven't looked at the spread tests tough)14:53
pedronis*though14:53
mvojdstrand: heh :) can you point me to a bugreport/PR? at least then I can voice my opinion14:53
jdstrandpedronis: I'm adjusting spread now14:53
ijohnsonalright verified the fix, cyphermox PR is here: https://github.com/CanonicalLtd/netplan/pull/10114:58
mupPR CanonicalLtd/netplan#101: io.netplan.Netplan.service.in: add assumed apparmor label <Created by anonymouse64> <https://github.com/CanonicalLtd/netplan/pull/101>14:58
cyphermoxcool15:02
ijohnsoncyphermox: oh sorry my local master was out-of-date do you want me to rebase?15:07
pedronisjdstrand: let me know if you have questions on my comments15:07
cyphermoxijohnson: no it's all good15:08
ijohnsoncyphermox ack thanks, sorry for the last minute rush15:08
pedronismvo: you added --extra-users support to userdel ?15:10
pedroniswhat't the status of that15:11
ijohnsonpedronis: I updated the PR title/description on #7010, lmk if you think it needs to be adjusted more15:11
mupPR #7010: interfaces/docker-support: set controls-device-cgroup spec <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>15:11
mvopedronis: I did15:12
pedronismvo: ubuntu only though?15:12
mvopedronis: 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.415:12
mvopedronis: yes, its only useful on core anyway15:13
pedronisah, yes15:13
pedronisjdstrand: ^15:13
mvopedronis: 7112 LGTM - do you wanto to do the second review or do we need to find someone else?15:17
mvo(its also green which is a big plus :)15:18
pedronisI think  if Chipaca gave it a look it would be better15:18
pedronisgiven that I tweaked it quite a bit15:18
Chipacai can do that15:18
Chipacamvo: so15:20
Chipacamvo: us-east1.gce.archive.ubuntu.com15:20
Chipacamvo: has a ping of .5ms15:20
Chipacamvo: from our spread machines15:20
Chipacamvo: that's probably the one we want15:21
pedronisijohnson: looks alright, 7010 description. I changed the summary a bit again15:21
mupPR 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:21
Chipacamvo: gce.cloud.a.u.c is ~24ms away so whatever it is, it isn't the one we want15:22
Chipacamvo: (that's worse than a.u.c itself)15:22
jdstrandpedronis: https://github.com/snapcore/snapd/pull/7124#discussion_r31436071815:22
mupPR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>15:22
mvoChipaca: nice!15:22
mvoChipaca: thanks for figuring this out15:22
mvoChipaca: I think this will help a lot if we can update our tests to use the gce mirror when inside gce15:23
ijohnsonpedronis: looks good thanks15:23
jdstrandpedronis: ack that userdel now supports --extrausers (it didn't when I wrote the initial PR 6681 :)15:23
pedronisjdstrand: thx, that would be ideal15:23
mupPR #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
pedronisalso much cleaner15:23
Chipacamvo: also, cloud-id -l | cut -f2 → us-east115:23
pedronisjdstrand: also note my comment about user.Lookup* returning Unknown* vs other errors15:24
jdstrandmvo: does groupdel suppoer --extrausers?15:24
jdstrandsupport*15:24
jdstrand$ groupdel --extrausers foo15:24
jdstrandgroupdel: unrecognized option '--extrausers'15:24
jdstrandI need groupdel since we necessarily must use groupadd then useradd since useradd with --user-group chooses something from the range in login.defs15:27
jdstrandpedronis, mvo: ^15:27
jdstrandbut that could be in a followup PR. I can clean up on classic and add a comment for core15:28
diddledanI still haven't worked out which I should use to add and remove users - adduser or useradd15:28
diddledanthey're not the same...15:28
jdstranddiddledan: on a Debian-derived system, adduser15:28
jdstrandit has a nicer interface15:28
pedronisjdstrand: yes, can leave a TODO, much easier either way if this is encapsulated, vs in snapstate15:28
jdstrandbut isn't portable15:28
jdstrandpedronis: I understand15:28
jdstranddiddledan: if you just want it to always work everywhere all the time, useradd, but you have to be careful with it15:29
mvojdstrand: uh, oh. ok - it seems like there is some work to do there then :/15:29
mvojdstrand: (groupdel --extrausers)15:29
* jdstrand nods15:30
mvojdstrand: this is a blocker, yes?15:30
diddledangotcha15:30
jdstrandmvo: no15:30
jdstrandmvo: I can cleanup on classic, add a todo for core to cleanup when groupdel --extrausers is available15:30
jdstrand(see Samuele's comment above ^)15:30
Chipacamvo, pedronis, #7112 GTG FWIW15:31
mupPR #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
mvoChipaca: please merge15:31
Chipacatoo late, pedronis did already :)15:31
pedronisjdstrand: ^15:32
mupPR 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:32
ijohnsonyay15:33
mupPR snapcraft#2665 opened: Plugin catkin: disable parallel option <Created by artivis> <https://github.com/snapcore/snapcraft/pull/2665>15:36
* cachio lunch16:14
juliankIs there a way for me to workaround apparmor denials?16:51
juliankI'm trying to build a blog post, but the hugo snap confinement is borken16:51
ograjuliank, what kind of denials ...17:14
juliankogra: simply /etc/gitconfig https://github.com/gohugoio/hugo/issues/622617:14
juliankI switched it to devmode to be able to proceed, but that's suboptimal :D17:15
ograjuliank, there is a system-files interface that allows read access to such locations, but you need to file a request on the forum for it17:15
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
juliankI don't think it really needs the gitconfig17:16
juliankit's like doing git describe HEAD or something17:17
juliankBut I was looking for a more confined local workaround than devmode-ing it17:17
ograwell, you could hack around it by shipping a git binary that simply links to $SNAP/bin/true or some such ...17:17
ograif /etc/gitconfig is unavoidable the system-files interfact is the way to go though17:18
ograhttps://forum.snapcraft.io/t/the-system-files-interface/935817:19
juliankI 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
ograoh, you could probably also use a layout17:19
ograhttps://forum.snapcraft.io/t/snap-layouts/720717:19
ograi dont think hacking apparmor profiles is an option out of using an interface17:20
juliankThat's all useful for the people doing the snap17:20
ogra(you can surely do that locally for yourself but would denied store uploads with that)17:20
juliankBut I'm just using it and want to workaround it :)17:20
ograah, then hacking the profile is indeed an option ... i'll hand you over to jdstrand for that one ;)17:21
ograthe profile shuld be in /var/lib/snapd/apparmor/profiles/17:22
ograbut i dont know the runes for re-geneating it properly from the top of my head17:22
juliankah I can hack that in and then apparmor_parser -r it17:23
julianknot a permanent solution, but ok17:23
ograyeah, as i said, layouts or system-files or shipping your own gitconfig in the snap and pointing the app to it are the ways17:26
ogra(i'm actually curious what /etc/gitconfig would be ... i have never seen it on an ubuntu system)17:28
ograjuliank, btw, you can tell the guys to simply set GIT_CONFIG_NOSYSTEM=true in their app launcher in snapcraft.yaml ;)17:33
ograthat will avoid looking for a (likely non-existent) systemwide git configuration17:34
mupPR 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
juliankogra: good idea17:34
mupPR snapd#7251 closed: packaging: fix removal of old apparmor profile <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7251>17:35
juliankogra: I just did17:47
jdstrandjuliank: 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:14
jdstrandjuliank: not that snapd while undo your change at various times (after reboot, refresh, etc)18:15
juliankjdstrand: yes thanks, just the path to the profile was enough already :)18:15
jdstrandnote*18:15
juliankalso *will18:15
juliankbut yes18:15
jdstrandheh, yes, will* :)18:15
juliankBut as ogra pointed out GIT_CONFIG_NOSYSTEM=true, just setting that when launching hugo works just fine too :)18:15
mupPR 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>18:22
mupPR snapcraft#2666 opened: tests: move meta testing to its own package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2666>19:07
mupPR snapcraft#2667 opened: yaml utils: move OctInt from meta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2667>19:16
* ijohnson reboots19:34
mupPR 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:29
mupPR 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>20:59
mupPR snapcraft#2668 opened: Restore cmake artifacts <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2668>21:43
lifelessmorningish :)22:26
lifelessso I filed https://bugs.launchpad.net/snappy/+bug/1840244 last night, and I'd like to know how to fix it locally22:27
mupBug #1840244: docker snap cannot bind mount ssh sockets correctly <Snappy:New> <https://launchpad.net/bugs/1840244>22:27
lifelesswhere 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 whatever22:28
lifelessmwhudson: ^22:33
mwhudsonlifeless: pretty sure all snap things run with private /tmp, not there's a quick fix for that22:34
lifelessah; 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 see22:35
lifeless(on https://snapcraft.io/docker )22:35
lifelessI guess I'll have to bind mount /tmp to /tmp2 or some such22:38
lifelesshow do you disable automatic snapshots on uininstall22:40
lifelessI don't want an archive of GBs of docker images22:40
mwhudsonthere were some forum posts about that sort of thing, i don't remember the details though22:41
lifelessfound it https://snapcraft.io/docs/snapshots22:41
lifelessTo disable automatic snapshots, set the retention time to no:22:41
lifeless$ snap set system snapshots.automatic.retention=no22:41
mwhudsoni 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:42
lifelessI can make /tmp for everyone else be /tmp2 bind mounted to /tmp if I have to22:43
lifelessbut my current plan is to just stop using snappy22:44

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!