[03:00] PR snapcraft#2408 closed: multipass: avoid stdin where possible === JanC_ is now known as JanC [06:08] morning [07:14] mvo: morning [07:19] hey mborzecki - good morning [07:34] Hey [07:34] Oh boy, winter is coming [07:36] mborzecki: RHEL 8 has very recent kernel [07:37] zyga: and a very far relase date :) [07:57] What is the release date? [08:00] zyga: when it's ready [08:00] zyga: i don't think they've annouced anything yet [08:00] Mmm [08:03] morning [08:05] pstolowski: hey hey [08:10] 2.36 branch is failing all the time [08:10] the travis job [08:13] google:opensuse-42.3-64:tests/main/interfaces-openvswitch-support is failing, i'd be surprised if it's https://bugzilla.opensuse.org/show_bug.cgi?id=1115168 [08:29] PR snapd#6152 closed: spdx: update licenses to current data <⛔ Blocked> [08:30] there's something messed up with our opensuse-42.3 images, they are not 43.2 but leap 15.0, https://paste.ubuntu.com/p/ZYFc8Rkjq4/ [08:31] i guess cachio is the only one who can fix it? [08:33] mborzecki: yeah, I think so - we can set opensuse to manual though to unblock us [08:36] mvo: hi, I closed the spdx PR for now, it needs some more thoughts, we also need to check what we did about licenses in our oldest releases out (debian? 16.04 active images?) [08:36] PR snapd#6163 opened: interfaces: tweak deny-auto-connect policy tests [08:36] pedronis: yeah, thats fine [08:36] pedronis: I agree this needs more work [08:38] mvo: the personal/system-files PR needs a jdstrand re-review, right? I haven't really done a review myself yet, just gone over some bits, also sorry, not sure if I put some comments at the wrong place, or the code changed under them [08:38] pedronis: your comments were useful, I addressed them now [08:39] pedronis: yeah, jdstrand should look at this again, I added the allow-install: false now [08:39] yes, saw that [08:39] thanks [08:41] zyga: mvo: I saw we put some bug cards (with landed PR) in the Done column, shouldn't they go in the cur release column? [08:41] pedronis: I think so, this may require a 2.36 colum now that we have backported some of the bugfixes [08:42] or a backport label [08:42] but yes [08:42] pedronis: yeah, or that :) [08:44] mvo: were they backported already? [08:44] pedronis: yes, let me double check but yes, we pulled into 3 PRs into 2.36 yesterday [08:45] one doesn't have a card [08:45] (it's ok) [08:45] mvo: yet, another approach is indeed two columns, and copy the cards [08:47] pedronis: or we put the card just in 2.36 and assume that whatever bugfix we did there automatically is also in all higher versions (which is generally true because we always cherry-pick from master) [08:47] yes, that's usually the case [08:47] let's try that [08:47] great [08:48] mvo: does it look right now? [08:53] pedronis: yeah - looks good, I would switch the order 2.36 and 2.37 (so that its from lower to higher) but thats a) nitpick b) personal preference [09:00] pedronis: re, I think you may be right, let me re-read the trello rules post [09:01] pedronis: thank you for moving them to the appropriate lanes [09:03] zyga: I'm not sure the rules explain the done lanes [09:03] I can add that [09:08] tumblweed moved to 4.19 [09:08] mvo: zyga: I added a para about the done lanes into the rules [09:08] hope it makes sense (I hope it makes a bit also without reading them tough) [09:16] zyga: i've just did snap run --shell gnome-calculator and got this: [09:17] https://www.irccloud.com/pastebin/TVwffLQo/ [09:17] zyga: expected? [09:17] nope [09:17] some of those are bugs in the theme [09:17] that are quite unexpected since they were reported months ago [09:17] but the last few are certainly unexpected [09:17] is this on master? [09:18] zyga: i'm on edge, 2.36.1+git1017.fdb9926~ubuntu16.04.1 [09:18] thank you, I will check this out [09:19] "fun" (not) [09:19] zyga: gnome stuff is from stable [09:19] pstolowski: https://forum.snapcraft.io/t/gtk-common-themes-bind-mount-sources-are-symlinks-missing-sounds/8540/1 [09:19] pstolowski: can you file the bug about /snap/ [09:20] zyga: sure [09:20] $SNAP/share/sounds is missing entirely, and Saru icon theme is a symlink [09:20] rebooting and jumping into this [09:21] pstolowski: there's a github issue as well https://github.com/snapcrafters/gtk-common-themes/issues/16 can you add it to the topic? [09:23] oho [09:23] 4.19 is not working too great with snaps [09:23] zyga: 4.19.1-arch1-1-ARCH, didn't notice anything special, what does not work in your setup? [09:24] type=AVC msg=audit(1542360228.183:306): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/tmp/snapd.quirks_fAGbSk/" pid=4922 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 [09:24] zyga@yantra:~> snap run gnome-calculator [09:24] cannot create temporary directory for /var/lib/snapd mount point: Permission denied [09:24] hm, profile update? [09:24] is that the kernel really? or selinux? [09:25] zyga: also if it's hairy can you take a note and look more later? [09:25] pedronis: sure [09:25] I wonder if this is because I have been hacking on this machine [09:25] probably so, let me just reinstall the package [09:25] pedronis: on suse there's just apparmor, no selinux [09:25] ok [09:26] yes :) [09:26] uff [09:26] I didn't have the permission to do quirks because I was hacking on quirks removal here [09:26] all is good [09:26] looking at the theme issue [09:30] pedronis: morning. Do I understand correctly that you think having the 0 epoch (or rather, anything that serialises back to "0") deserialise to unset is the best approach? [09:30] pedronis: (I think I agree, but wanted to confirm before implementing it -- in the same pr?) [09:30] zyga: not sure if i described it correctly, but here you go: https://bugs.launchpad.net/snapd/+bug/1803687 [09:30] Bug #1803687: snap run --shell gnome-calculator gives a series of errors [09:31] Chipaca: yes, if we basically say internal unset === "0", it seems saner to normalize [09:31] Chipaca: can be a follow up tough [09:31] that PR is around since a while [09:32] (relatively speaking, is not ancient in snapd PR terms) [09:32] pedronis: 8 days old, if you count the original homonymous pr, yes [09:33] pedronis: anything else I should do on this one and not the followup? [09:38] Chipaca: you are asking because it's green ? :) [09:40] Chipaca: there's the amend test revision to change, it's ok for a follow up if it doesn't get lost [09:41] thank you pawel [09:43] reproduced [09:44] great! [09:47] mvo: do we have a edge build now for https://bugs.launchpad.net/tillamook/+bug/1802581 ? [09:47] to announce [09:47] pedronis: I believe so, I can test on my device quicklyl [09:48] pedronis: was asking because the tests were green, and it's got a 'changes requested' from you :-) [09:48] refreshing to edge, i'll know in 3 minutes [09:48] pedronis: yeah, build 5h ago and landed last night but if its not trouble for zyga to double check lets wait for that first [09:48] yes, that's fine [09:51] rebooting pi3-1 [09:53] testing now [09:54] confirmed [09:54] edge allows to disable and enable the snap that previously reproduced the issue [09:56] mvo, pedronis: +1 [10:02] mvo: zyga: I'm writing something in the bug [10:02] thank you [10:03] done [10:05] Chipaca: I wrote what we discussed yesterday about restart SNAP etc here: https://bugs.launchpad.net/snapd/+bug/1803212 [10:05] Bug #1803212: snap restart starts disabled services [10:05] zyga: if you have a rhel instance, can you `yum --enablerepo=epel-testing install snapd` and report feedback here https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b240f3418f ? [10:06] mborzecki: I don't have one handy now [10:06] mborzecki: actually, maybe I'm wrong [10:06] one sec [10:06] nope [10:06] I think I killed it [10:08] ah ok, nvm, i've given +1, snapd installs and runs on 7.6 [10:11] Chipaca: I have a remark, it seems all the store tests use either "0" or nil, no test with something a bit more interesting [10:11] in epoch [10:11] I also don't know if the change we plan affects that [10:12] pedronis: there is one snap.E("1*") in the store tests (for the amend case) [10:13] Chipaca: yes, but nothing for context [10:13] hmmm [10:13] i'll see how things change with this [10:13] I made a remark [10:14] pstolowski: ah [10:14] pstolowski: I think it's not terrible [10:14] I was worried this is a regression [10:14] I improved logging of trespassing events [10:15] Chipaca: gave a +1 assuming you'll work through my wonderings :) [10:15] in the follow up [10:15] mbuahaha [10:15] i mean, "yes of course" [10:15] :-p [10:15] pstolowski: quick question, was it failing to start in your case? [10:15] for me it starts ok [10:15] (as in, runs) [10:16] https://www.irccloud.com/pastebin/lBeg5CYb/ [10:16] zyga: no, no, it worked (i used --shell) [10:16] look at line 1 [10:16] this is really telling us this [10:16] the snap gnome-calculator [10:17] was trying to write to /snap/gtk-common-themes/808/share/sounds/Yaru [10:17] and that was refused [10:17] it was trying to write there because of a content connection [10:17] that's the "remote" end [10:17] but it is absent (not really in the snap) [10:17] so the code tried to make it [10:17] but it wasn't allowed to [10:17] that's all [10:17] interesting [10:18] I mean, we could allow writes to /snap/*/ except for /snap/bin [10:18] but I really think this is a bug in the desktop themes snap [10:18] I don't quite understand what is the thing going on there [10:19] I mean [10:19] it's totally bogus [10:20] sound themes exposed by gtk-common-themes https://www.irccloud.com/pastebin/1T1cK5k0/ [10:20] the share/sounds directory is not even in the snap! [10:20] PR snapd#6142 closed: overlord/snapstate, store: always send epochs [10:21] kenvandine: ^ should we escalate that, it feels like stable version of gtk-common-themes is missing files [10:22] zyga: https://forum.snapcraft.io/t/gtk-common-themes-bind-mount-sources-are-symlinks-missing-sounds/8540 heh [10:22] heh, thank you for reporting this maciek [10:22] pinged popey and kenvandine there ;) [10:22] with enough eyeballs :) [10:23] wat [10:24] the snap is on gnome gitlab [10:25] k, done [10:25] good :) [10:25] back to features [10:27] zyga: i see, good :) [10:29] zyga, mborzecki thanks for reporting it [10:32] zyga: can we do a HO about mounts & rhel/centos? wanted to discuss something [10:32] sure [10:32] let me join [10:33] can we "meet" instead? [10:33] https://meet.google.com/sri-fdeu-yur?authuser=0 [10:33] just had this open now [10:34] zyga: is there anything new re mount issue that's also reported here https://bugs.launchpad.net/snapd/+bug/1772016 ? [10:34] Bug #1772016: Mount snap "snapcraft" (1591) ([start snap-snapcraft-1591.mount] failed with exit status 1: [10:34] pstolowski: I'll check after the call with mborzecki [10:38] Chipaca: was https://bugs.launchpad.net/snapd/+bug/1767445 fixed already in snapd? [10:38] Bug #1767445: Uninstalled snaps show most recent channel version, not version to be installed by default

(Ubuntu Xenial):Fix Released>

[10:39] * Chipaca looks [10:39] PR snapd#6164 opened: wrappers: rename the desktop file to their apps [10:40] pstolowski: no, there was nothing to fix in the current api [10:40] bah [10:41] pstolowski: yeah, that [10:41] Chipaca: can be closed in snapd then? or it's for the future? [10:43] pstolowski: I mean, as described in the attached forum post, snapd could workaround things, but it's mostly up to the store to return the most stablest revision or not, there [10:44] pstolowski: i'd go with a "Won't fix" on snapd side though, with the rationale that (a) look in the channel map if you want to know what you'll get in stable, and (b) store can change what's returned outside the channel map, which we'd forward on [10:45] Chipaca: allright, thanks, it wasn't clear where the things are since that topic is 5 months old [10:46] pstolowski: looking [10:47] ah [10:47] this is the issue we know about [10:47] it's bound to be fixed this cycle [10:49] pedronis: what do you think about adding a pre-remove script? one of the bug reports request that we have a remove hook that runs before stop-snap-services, not after. we kina expected this when remove hook was introduced, but just wanted feedback and people actually starting to use hooks [10:49] zyga: great, thanks for updating it [10:50] kjackal: hello [10:50] kjackal: do you have a moment to talk about microk8 [10:50] pstolowski: can you point me to the actual bug? [10:50] hi zyga, yes go ahead [10:50] whats up? [10:50] I'm looking at https://bugs.launchpad.net/snapd/+bug/1802332 [10:50] and I'd like to reproduce it locally [10:50] Bug #1802332: Apparmor complains in strict confinement with base: core18 [10:50] is the snap something you built locally or can I get it somewhere? [10:50] pedronis: https://bugs.launchpad.net/snapd/+bug/1777121 [10:50] Bug #1777121: Remove is called after snap services are stopped [10:51] pstolowski: thanks, I'll put in my queue of things to look at [10:51] the snap is patched, let me find the branch [10:51] kjackal: can you send me the snap please [10:51] perhaps via wormhole :) [10:52] zyga: what's the status of per-user mounts? wating o reviews? [10:52] Ah it is on the ticket https://github.com/ubuntu/microk8s/tree/feature/strict [10:52] pedronis: yes, I really need to land the current set [10:52] zyga: ^ [10:52] pedronis: it's bound with several dependencies but it should all be landable [10:52] kjackal: so I just need to take that snap, build it, and run it? [10:52] yes [10:53] zyga: for building the snap I went to snapcraft, version 3.0+git13.g04f18f5 [10:54] kjackal: let me try, I'll bug you if I cannot get it somehow [10:55] thank you [10:56] zyga: do nag people for reviews a bit :) , given I'm sprinting next week I will not dive into that [10:57] pedronis: ay ay sir! [10:57] mborzecki: could you do a 2nd review on https://github.com/snapcore/snapd/pull/6145 [10:57] that's the first one to go in [10:57] PR #6145: cmd/libsnap: add sc_verify_snap_lock [11:14] mvo: or you perhaps? ^ [11:14] this unclogs the pipe :) [11:33] PR snapd#6165 opened: cmd/snap-update-ns: extra debugging of trespassing events [11:40] PR snapd#6157 closed: userd: force zenity width if the text displayed is long [11:40] * Chipaca afk for a bit [11:44] hmm [11:44] where does snapcraft 3.0 drop built snaps? [11:46] zyga: pwd? [11:46] cwd [11:46] nope :) [11:46] not for me [11:46] I forked microk8s and built it with snapcraft and multipass [11:47] no snaps found [11:49] I'll clean and try again [11:49] but ... wtf [11:49] no errors or anything [11:53] sergiusens: [11:53] sergiusens: halp [11:53] snapcraft 3.0 [11:54] build works for a while [11:54] then nothing [11:54] error code 0 [11:54] last messages are: [11:54] https://www.irccloud.com/pastebin/V8knVrdk/ [11:58] oh boy :) [11:59] I need snapcraft, not snapcraft build [11:59] * zyga facepalms [12:07] mvo, hey [12:07] https://paste.ubuntu.com/p/CwM7k7ntvW/ [12:10] zyga: help no longer required I assume? [12:10] yes :) [12:10] sergiusens: my only comment would be to auto-match the number of cores in qemu to the cores on the host [12:10] 6 core machine had 4 cores idle [12:11] it matters in the last step (compression) [12:11] cachio: hey, we have a problem with opensuse-42.3 images, they are in fact leap 15.0 images [12:11] cachio: hm, hm, is it connected? I assume so [12:11] zyga: oh, you can do that manually, but we were killing the machines because you need to also assign around at least 1G of RAM per core [12:11] cachio: that's why 2.36 branch is failing on travis [12:12] mborzecki, checking [12:12] zyga: it was the original design, moved away from it after some testing and agreements with Saviq [12:12] 1G ram per core? why [12:12] cachio: https://paste.ubuntu.com/p/ZYFc8Rkjq4/ this was on release/2.36 branch [12:13] zyga: SNAPCRAFT_BUILD_ENVIRONMENT_CPU=8 SNAPCRAFT_BUILD_ENVIRONMENT_MEMORY=8G snapcraft (for a fresh project) [12:14] given that 8 is the most common amount of RAM out there (I have one of those configurations) and that I usually barely manage to have 2G of free RAM I thought this conservative approach would be best for the wider audience [12:16] mborzecki, it seems that the last automatic update did it [12:17] cachio: can you fix it? [12:18] mborzecki, yes [12:18] I am on that [12:18] cachio: thank you! [12:19] mborzecki, np [12:19] mvo, yes, it is connected [12:32] simple review for https://github.com/snapcore/snapd/pull/6165 [12:32] PR #6165: cmd/snap-update-ns: extra debugging of trespassing events [12:34] jdstrand, i see some very weird behaviour with the kvm interface ... when i switch qemu-virgil into --devmode i all of a sudden get "qemu-system-x86_64: failed to initialize KVM: Operation not permitted" ... switching back to --jailmode makes it work again [12:35] mborzecki, I am creating the new image [12:35] (nothing is printed in journalctl when that happens) [12:36] cachio: did the automatic update tool pick the wrong name the last time? [12:36] mborzecki, the change was caused because opoensuse project changed hte default image from 42.3 to 15 [12:36] and we build based on that [12:36] mborzecki, I just changed to point to a specific 42.3 image [12:40] PR snapd#6165 closed: cmd/snap-update-ns: extra debugging of trespassing events [12:40] thank you :) [12:43] #6100 needs 2nd review [12:43] PR #6100: overlord/ifacestate: hotplug-remove-slot task handler [12:43] and has nice PR number ;) [12:45] haha, nice [12:45] looking [12:46] PR snapcraft#2407 closed: build providers: preset the timezone [12:46] mvo, this is interesting https://paste.ubuntu.com/p/Fx48q9phRR/ [12:50] zyga: https://bugs.launchpad.net/snapcraft/+bug/1795666 [12:50] and https://github.com/CanonicalLtd/multipass/issues/420 [12:50] ogra: that is weird. when you go to --devmode, is that an remove/install --devmode or something else? [12:51] s/an/a/ [12:51] Saviq: using 4 cores on a 2 core system is certainly wrong [12:51] jdstrand, a refresh [12:51] Saviq: not sure about using 6 cores on a 6 core system [12:51] also not sure how ram relates [12:51] is there really a kvm correlation between ram and cores? [12:52] ogra: I suspect it would work right with a remove/install. I bet something isn't right with the device cgroup when refreshing to devmode. that probably deserves a forum topic [12:52] jdstrand, with qemu-virgil normally installed i did "sudo snap refresh qemu-virgil --edge --devmode" and "sudo snap refresh qemu-virgil --stable --devmode" [13:04] jdstrand: hi, is re-reviewing #5845 in your queue? [13:06] pstolowski: I left some comments in the hotplug-disconnect PR, we probably need to be a bit more careful about conflicts there [13:07] pedronis: yep, just noticed, thanks! [13:08] * pstolowski lunch [13:15] mborzecki, new opensuse image ready [13:16] mvo, snapd[30158]: task.go:303: DEBUG: 2018-11-16T11:53:56Z INFO snap "test-snapd-sh" has bad plugs or slots: personal-files (cannot add personal-files plug: "$HOME" must start with " [13:16] I see this error too [13:17] cachio: thanks, let me restart the travis jobs and see if it's ok now [13:18] hum hum [13:18] I need to run an errand now [13:18] I may miss the standup [13:22] mborzecki, nice, sorry about that issue but this leap image is not under our control [13:22] mborzecki, I'll see if I can create a copy to our project and then use it [13:22] cachio: so you mean it's some other project that's changed the image? [13:23] mborzecki, yes [13:23] cachio: yeah, copy sounds like a good idea [13:23] mborzecki, for some oss I get the images from other projects [13:24] i.e. opensuse, debian, etc [13:28] cachio: interessting error, I look at it [13:31] INFO snap "test-snapd-sh" has bad plugs or slots: personal-files (cannot add personal-files plug: "$HOME" must start with "$HOME") [13:31] this is the full message [13:33] https://github.com/snapcore/snapd/pull/6150 is the next branch in the chain [13:56] zyga: the Suru symlink issue is fixed in a Yaru PR by jamesh, I think [13:58] zyga: indeed the sounds are missing [14:02] zyga: standup? [14:07] kenvandine: and the sound theme issue? [14:08]