[03:55] Howdy. A question in #ubuntu then #ubuntu-mate had me try & run software-boutique but I get same error as OP in rooms; since it's a snap - where does request for help (bug report?) get filed please? or where can I learn more about (not sure what to ask sorry) [03:56] (on 19.10 ^) [03:58] actually I may have it; I think it's installed by ubuntu-mate-welcome; thus I have a .deb and can use launchpad... [04:19] Bug #1575560 changed: snap refresh in status hold; not clear how to continue [04:19] Bug #1595649 changed: Audio playback fails for KDE apps with Phonon [04:19] Bug #1620815 changed: Test failures in github.com/snapcore/snapd/cmd/snap at 0187d66 [05:16] morning [05:45] mvo: hey [06:03] mvo: i'll be looking into the failures with go.mod [06:03] mvo: perhaps the tests need a tweak [06:04] mborzecki: thank you! any news from xerrors for f30 yet? [06:05] Hey guys [06:05] Good [06:05] Morning :-) [06:06] mvo: nope, tried to catch the maintainer on irc yesterday, prepared a spec and a scratch build for f30, but have not heard back, i'll open a ticket in bz and ping him via email [06:06] mborzecki: thank you! [06:06] amurray: thank you! [06:11] PR snapd#6174 closed: many: add snap debug refresh-catalogs [06:44] re [06:58] huh [06:58] https://travis-ci.org/snapcore/snapd/jobs/600949213 [06:58] what happened here? === pstolowski|afk is now known as pstolowski [07:01] morning [07:02] good morning Pawel [07:02] pstolowski: winter is coming [07:05] zyga: up to 19 deg celsius still estimated for today here, pretty crazy [07:05] pstolowski: -7 forecast by next week [07:06] zyga: ah, time to change for winter tires indeed [07:08] pstolowski: yeah, it's probably high time to swap the tires [07:09] pstolowski: though i'm seriously considering getting an all-year set [07:10] mborzecki: yeah i've been thinking of it too, although, when it really gets bad (and it sometimes does) or when i go south to the mountains (which i do almost every year) i appreciate having winter tires ;) [07:34] brb [07:51] back from breakfast and into testing [08:00] PR snapd#7635 opened: tests/lib/gendevmodel: helper tool for generating developer model assertions [08:01] pedronis: ^^ [08:17] archlinux. `sudo snap install thing` gives 'error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:' followed by mount failed on a tmpdir beginning with 'sanity-mountpoint'. known issue? squashfs-tools and squashfuse are both installed [08:36] causasui: can you cat /proc/filesystems - is squashfs there? [08:36] causasui: it's not a known issue [08:36] cc mborzecki ^ [08:37] causasui: can you post the otput of `uname -r` and `pacman -Q linux` ? [08:41] mborzecki: uname -r -> 5.3.7-arch1-1-ARCH ; pacman -Q linux -> linux 5.3.7.arch1-1 [08:41] zyga: grep -i squash /proc/filesystems -> null :thinking-face: [08:41] no squashfs [08:41] that's why it fails [08:41] now why there's no squashfs? :) [08:41] ^ [08:42] idk, seems to work here on the same kernel version [08:42] causasui: anything in dmesg? [08:42] mborzecki: do you think a good old "modprobe" will fix it? [08:42] mborzecki: you probably have squashfs module loaded I'm guessing [08:42] zyga: it's supposed to be automatic [08:42] yeah but worth a shot [08:43] probably cant hurt, modprobe just 'squashfs' right? [08:43] indeed [08:45] alright, now squashfs is in /proc/filesystems but I get the same operation not permitted error [08:45] down the rabbit hole we go [08:45] causasui: anytyhing in dmesg? [08:45] causasui: what gives you operation-not-permitted? [08:46] Chipaca: you got here a minute late, just 'sudo snap install thing' throws an error about operation not permitted mounting to /tmp/sanity-mountpoint-stuff with squashfs [08:47] mborzecki: tail dmesg shows a bunch of audit messages about snapd that end with 'res=success' which I guess is good? [08:47] msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [08:48] causasui: did you restart snapd after loading squashfs? [08:48] no [08:48] the sanity check is performed at start and if it fails snapd enters "abandon all hope" mode [08:48] here goes [08:49] ok did `sudo systemctl restart snapd && sudo snap install ` and no change [08:49] I'm checking for random degraded services [08:49] 🐀 [08:49] systemctl --failed is 0 [08:50] causasui: journalctl -u snapd then? [09:15] mvo says he'll be here in 20, fwiw [09:19] mborzecki: hm picking out some interesting things, ' helpers.go:104: error trying to compare the snap system key: system-key missing on disk' [09:19] messages about apparmor not being enabled but that wouldn't cause this I think? [09:20] zyga: do we have any known issues with having /home on nfs? [09:20] it's way past my bed time sadly, hopefully there will be activity when I'm up. thanks for the help so far [09:20] causasui: maybe ijohnson and you overlap a little [09:20] causasui: g'night [09:26] pstolowski: hey [09:26] pstolowski: auto-mount is not working there [09:26] pstolowski: or to be precise, if you have autofs then it doesn't work [09:26] explicit nfs is tested in spread and should work [09:26] zyga: ok, good [09:27] pstolowski: I updated https://github.com/snapcore/snapd/pull/7632 [09:27] no more buffering [09:27] no more splitting [09:27] PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules [09:27] zyga: nice, ty, will re-review [09:27] if you want I could split the automatic changes [09:27] that is, change how we write [09:27] before adding de-dupe [09:28] the the branch can simply enable de-duplication and observe a cascade of changes [09:28] let me know if this helps in review [09:29] I added this as a comment in the review now [09:29] pstolowski: #7597 and #7431 (in that order) are Ian's PRs that need reviews [09:29] PR #7597: overlord/snapstate: add LastActiveDisabledServices, missingDisabledServices [09:29] PR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc [09:31] pedronis: ack [09:39] mvo: hey [09:39] mvo: I updated https://github.com/snapcore/snapd/pull/7632 -- I asked a question at the bottom of the PR [09:39] PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules [09:40] mvo: splitting that branch could land the bigger automatic chunk easily [09:40] zyga: thanks, I have a look [09:40] I'll grab coffee and add the remaining missing part [09:40] jdstrand: Are there any known issues with the network-manager interface on Core when I use it in the post-refresh hook? I added the plug to this hook and it works fine when testing on Ubuntu Desktop, but on Core I always get AppArmor denials. [09:40] a test that compiles some profiles and ensures we are under 500M of memory [09:40] and run it before and after just to be sure [09:40] dot-tobias: jdstand is off today [09:40] dot-tobias: if you share the denials I can look [09:40] brb for coffee [09:42] zyga: Ok, thanks. The denial is here: https://paste.ubuntu.com/p/CfyfPYsYR7/ [09:46] zyga: I looked at the policies file in /var/lib/snapd/apparmor/profiles/snap.mirros-one.hook.post-refresh *before* the refresh, and it contains the default lines which should already grant access to the Introspectable interface. snapcraft.yaml contains the 'network-manager' plug for the post-refresh hook, see https://gitlab.com/glancr/mirros-one-snap/blob/tmp-core16/snap/snapcraft.yaml#L21 [09:49] Hey snappy people, I am missing something. We released microk8s to edge/strict yesterday. I can snap install it now, but cannot connect interfaces. Is this expected? Any idea why? [09:49] "cannot connect interfaces" ... [09:50] can you be a bit more detailed ? [09:50] (what command do you call, whats the error, did you check the journal for errors etc) [09:52] "snap connections microk8s" showes all connections. I am expecting "sudo snap connectio microk8s:home :home" to change the "Notes" column saying something like "manual" [09:52] dot-tobias: can you look for the DENIED line, it has some more information that is absent here [09:52] not sure it does this if the interface is already connected [09:53] (and home auto-connects on desktop) [09:53] dot-tobias: looking [09:53] let me see then [09:53] s/desktop/classic installs/ [09:54] dot-tobias: network-manager interface does not grant that method [09:54] awesome orga, you are right, everything was already connected [09:55] dot-tobias: one could argue it should, could you please report a bug, I can look into it [09:55] yay [09:56] zyga: But why does it work when I test the (confined) snap on Ubuntu Desktop, or run the same command (Ruby wrapper for D-Bus calls) from the installed snap? This denial only occurs on Core during post-refresh. [09:56] and you are sure the interface is connected at that time ? [09:56] zyga: Re dmesg line → https://paste.ubuntu.com/p/rg6SXb2vMf/ [09:57] dot-tobias: how are you testing it on the desktop? [09:57] dot-tobias: introspection is usually not required [09:57] dot-tobias: perhaps it's something specific to core that triggers it [09:57] dot-tobias: note this: [09:57] const networkManagerConnectedPlugAppArmor = ` [09:57] # Description: Allow using NetworkManager service. This gives privileged access [09:57] # to the NetworkManager service. [09:57] #include [09:57] # Allow all access to NetworkManager service [09:57] dbus (receive, send) [09:57] bus=system [09:57] (also ... on core you are likely using the NM snap while the deb runs on desktop, the interface migth act differetly in that case) [09:57] path=/org/freedesktop/NetworkManager{,/**} [09:57] peer=(label=###SLOT_SECURITY_TAGS###), [09:57] # NM implements org.freedesktop.DBus.ObjectManager too [09:57] dbus (receive, send) [09:57] bus=system [09:57] path=/org/freedesktop [09:57] interface=org.freedesktop.DBus.ObjectManager [09:57] peer=(label=###SLOT_SECURITY_TAGS###), [09:57] ` [09:57] oh god, sorry [09:58] yay [09:58] dot-tobias: apparmor spec for connected network-manager plug https://www.irccloud.com/pastebin/faBWA4Jd/ [09:58] the only thing that differs between core and classic is the peer label, either "unconfined" on the desktop or some snap label on core [09:58] note that the interospectable interface is not there in either case [09:58] since the program was ruby [09:59] I can infer that it builds a method map for each object it talks to [09:59] by using introspection [09:59] zyga, ogra: On Desktop, I have my snap from stable installed, then attempt to refresh from edge which contains the new D-Bus calls. Works. Same on Core errors as above. [09:59] but this is ruby, perhaps on the desktop it reads some files to get that without asking [09:59] I honestly don't know [09:59] but I can explain why there's a denial on core for sure: because it is not permitted [10:00] zyga: Will test further on core, thanks in the meantime. The Ruby wrapper is a third-party lib, and yes it uses Introspect to map Properties/Interfaces. [10:00] dot-tobias: you can expand the interface to add the introspection locally [10:01] it might help you move further along [10:01] to see if there's something else blocking [10:01] let me know if you need any help with that [10:01] zyga: You mean adding an entry to /var/lib/snapd/apparmor/profiles/snap.mirros-one.hook.post-refresh ? [10:02] dot-tobias, what i meant is that the slot side might act different in the NM snap compared to the (completely unconfined) deb ... [10:03] ogra: Yeah, sorry forgot to answer you. I guess that's the case, at least explains why Desktop/Core act differently when the only policy difference is the label (as zyga mentioned above) [10:04] right [10:04] ogra/zyga: Ah, the dmesg output (to me) hints in this direction: https://paste.ubuntu.com/p/rg6SXb2vMf/ → if I read this correctly, the second line denies the call for the network-manager snap itself [10:05] thats what i meant :) [10:05] yep [10:05] (or guessed rather :) ) [10:05] dot-tobias: in any case, if you report a bug I can get it fixed today [10:05] I just need to write a regression test for somethnig else [10:06] zyga: On it, should I file against snapd? [10:06] yes, please [10:23] zyga: https://bugs.launchpad.net/snapd/+bug/1849291 → let me know if you need more info. And thank you very much in advance! Just to have a timeframe: If this is fixed, when could I expect the next core release? So that I don't deploy my own snap before that. Wouldn't want user's devices to retry refreshes just to error out 😊 [10:23] Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable [10:29] dot-tobias: not sure, I'll add this to the bug when I konw [10:29] *know [10:31] wow, what a dramatic difference this fix makes!!! [10:34] zyga: which? [10:35] before [10:35] wall: 0:03.17, mem: 1552532 Kb [10:35] after [10:35] wall: 0:00.22, mem: 37728 Kb [10:35] that's a winner [10:35] :D [10:37] Chipaca: this is the mount de-duplicating [10:37] *deduplication [10:47] PR pc-amd64-gadget#21 closed: Xnox closing uc20 branch [10:54] PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil [11:02] PR snapd#7636 opened: gadget, overlord/devicestate: dd support for customized update policy, add remodel policy [11:02] mvo: pedronis: ^^ [11:02] should be a simple one [11:03] zyga: you said somethng about exponential growth the other day, didn't you? :) [11:03] yeah [11:03] wrapping up the test soon :) [11:03] but happy to fix this [11:04] this will save a lot of energy planet-wide [11:04] zyga: there a line for your CV ;) [11:04] wrote inefficient code, fixed it after shipping to everyone [11:05] sounds too familiar when you put it this way [11:05] isnt that the standard anyway ? [11:08] PR snapd#7637 opened: tests/main/interfaces-contacts-service: disable on openSUSE Tumbleweed [11:08] ^^ should unblock master [11:09] and PRs too [11:10] PR pc-amd64-gadget#22 opened: Store changes [11:16] zyga: mborzecki: "croud-sourced performance measurements" [11:16] Chipaca: practical experience in reducing climate change [11:23] ok, test executing now [11:25] mborzecki: thanks, trying to get to a pause point with something else, and then I will switch to do a bit of PR reviewing [11:25] pedronis: thanks! [11:27] mborzecki: thanks for this one (I changed dd -> add in the title, hope that was ok) [11:29] mvo: haha thanks! [11:30] heh, for a second I wondered if the 'dd' command was involved [11:46] ijohnson: hey, sorry about all the nitpicks re missing dots in comments (added inline suggestions where i spotted those); i found such comments (especially longer doc strings) slightly hard to read / grasp quickly with no fullstops [11:58] PR snapd#7637 closed: tests/main/interfaces-contacts-service: disable on openSUSE Tumbleweed [11:58] yay [12:05] thanks mvo [12:06] zyga: thanks to mborzecki [12:06] pstolowski: do you have time to work with me on the apparmor fix, I was thinking about reducing the branch by moving the automatic changes elsewhere and landing [12:06] pstolowski: so that the actual fix is just a small change + test changes + regression test [12:17] zyga: only if i park something else; is it possible though to split it? all the profile changes need to land with the fix no? [12:17] pstolowski: it's very easy to split, vast majority of change is the "getting ready" code [12:17] pstolowski: that can land without any effect to tests or actual performance today === ricab is now known as ricab|lunch [12:19] pstolowski: I'm mainly looking for someone who would follow along and review it [12:19] pstolowski: but no rush, I'm working on the spread test still, I need to check the numbers as I see some discrepancy [12:19] zyga: okay, perhaps after standup [12:20] booo [12:20] there's no "time" command on core [12:21] pstolowski: thanks! [12:21] mvo: Chipaca: does https://github.com/snapcore/snapd/pull/7615 needs my input? or should be ok for you two to work to land it? [12:21] PR #7615: policy: implement CanRemove policy for the snapd type [12:21] core has no time [12:21] core is super busy [12:22] pedronis: i think it's ok without your input [12:22] ok [12:22] pedronis: ah, one question there, was that I recommended using model.Classic() instead of release.OnClassic, wdyt? [12:23] that sounds fine [12:23] mborzecki: is there a "time" command on arch? [12:23] pedronis: ok [12:23] zyga: there's 2 time commands, some shells have a builtin, and there's gnu time at /usr/bin/time [12:24] I need GNU time [12:24] zyga: yup, that one is avialble, you may need to install it separately [12:24] Chipaca: we should just be consistent across policy about that [12:24] mborzecki: thanks [12:24] pedronis: agreed [12:25] mborzecki: zyga: why wouldn't gnu time be installed? [12:25] Chipaca: it's not on core [12:25] Chipaca: tbh i think it rarely is [12:25] and not on arch or sid [12:25] huh [12:26] iirc fedora doesn't have it by default either [12:26] zyga, core ships at least the shell builtin [12:26] ogra: it's not what I need [12:26] I need the other one [12:26] zyga: you probably need time -v right? [12:26] no [12:26] time -f %M [12:26] snap it then ;) [12:26] heh ;) [12:27] ogra: cannot run snaps with snaps [12:27] pfft, minor detail ... [12:30] * zyga breaks for lunch [12:30] see you at the standup [12:31] * zyga watches https://www.youtube.com/watch?v=L-7W5pc7OjU while eating veggies [12:37] zyga: is #7615 GTG IYHO? [12:37] one sec [12:37] PR #7615: policy: implement CanRemove policy for the snapd type [12:38] ah [12:38] I'll do a pass, I think so [12:38] it looked ok before [12:38] just had that one question then [12:50] PR snapd#7638 opened: Add OnlyKey to List [12:54] mborzecki: I reviewed #7630, the main thing might require a prereq PR, it seems it might be time to split some .go files. they mix too much and they are getting big [12:54] PR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility [12:55] pedronis: thanks, will take a look after than standup [12:56] s/than/the/ ofc [12:58] eep, the standup [12:58] * Chipaca runs [13:05] hey snappy people, to use the "system-usernames:" I need snapd to be patched to be aware of the username? [13:06] kjackal: no, only one username is supported for now [13:07] kjackal: 1 sec, there's an explanation [13:07] ondra: nice work on https://github.com/snapcore/snapd/pull/7596 [13:08] PR #7596: overlord/snapstate: skip catalog refresh if unseeded [13:08] kjackal: we're in phase 1, https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461 [13:09] kjackal: sorry, this: https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461/3?u=chipaca [13:09] phase 1 is described at the end of that comment [13:11] kjackal: i assume you've seen https://forum.snapcraft.io/t/system-usernames/13386 already [13:11] kjackal: which is also describing current, ie phase 1 [13:11] Chipaca: so there is only one user/group I can use, the "snap_daemon", right? [13:11] kjackal: at this stage, yes [13:12] sounds good, let me try that [13:13] PR snapd#7596 closed: overlord/snapstate: skip catalog refresh if unseeded [13:28] and now I have an 1080p IPS display [13:29] :D [13:29] the difference is insane :D [13:31] mine's bigger :-p [13:31] * zyga is very happy with what he has :) === ricab|lunch is now known as ricab [13:32] diddledan: it's not how big it is, it's how much you giggle while using it [13:32] haha. and that did make me giggle [13:33] * Chipaca rests his case [13:33] giggle when you wiggle it :-) [13:34] github actions really need better (more) examples [13:36] I wish CI services had local working environments to test that you've configured correctly before you upload to your shared project repository [13:37] otherwise you end up with "Add Travis CI" in one commit followed by 15 further "Fix Travis CI" and "Really Fix Travis CI" and "FFS, Travis CI Again" [13:37] diddledan: I very much share this opinion [13:38] it's very annoying [13:38] I think travis used to have something like that [13:38] via their ruby command line tool [13:38] it'd let you run a job against your working directory [13:38] it's not just travis though, none of them have anything like it [13:41] diddledan: did you see https://github.com/travis-ci/travis.rb [13:44] PR snapcraft#2760 opened: remote-build: rebase onto master [13:46] interesting [13:57] Hey all, I have a snap that no longer has plug defined, so I want to remove it. But when I try to disconnect it, it says the snap has no plug or slot with that name. Is there some way to force the disconnect? [13:57] Chipaca: there's a bug about that [13:57] er [13:57] ChrisTownsend: ^ [13:58] ChrisTownsend: sorry, tab completed incorrectly [13:58] ChrisTownsend: we need to look into it [13:58] zyga: Ah, ok...no worries about tab completion:) [13:58] zyga: Do you have the bug number handy? [13:59] https://bugs.launchpad.net/snapd/+bug/1848516 [13:59] Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh [13:59] zyga: Also, if there is an active connection listed and I did remove the plug/slot, can I be guaranteed that the new snap will indeed not use that connection? [13:59] zyga: Thanks for the link [14:00] ChrisTownsend: that part works okay but we need to fix the UX to match AFAIK [14:00] zyga: Ok, great, thanks! [14:06] pstolowski: so do you have a moment [14:06] zyga: yes, but need a (late) lunch first [14:07] pstolowski: ok, please ping me later [14:07] zyga: sure [14:07] * zyga goes to play with the thinkpad for a moment [14:16] hmmm [14:16] https://www.irccloud.com/pastebin/E6MEZkwC/ [14:17] is "command foo" equivalent to running /usr/bin/foo over alias/builtin? [14:48]