guivercHowdy.  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:55
guiverc(on 19.10 ^)03:56
guivercactually I may have it; I think it's installed by ubuntu-mate-welcome; thus I have a .deb and can use launchpad...03:58
mupBug #1575560 changed: snap refresh in status hold; not clear how to continue <Snappy:Expired> <https://launchpad.net/bugs/1575560>04:19
mupBug #1595649 changed: Audio playback fails for KDE apps with Phonon <Snappy:Expired> <https://launchpad.net/bugs/1595649>04:19
mupBug #1620815 changed: Test failures in github.com/snapcore/snapd/cmd/snap at 0187d66 <Snappy:Expired> <https://launchpad.net/bugs/1620815>04:19
mborzeckimvo:  hey05:45
mborzeckimvo: i'll be looking into the failures with go.mod06:03
mborzeckimvo: perhaps the tests need a tweak06:03
mvomborzecki: thank you! any news from xerrors for f30 yet?06:04
zygaHey guys06:05
zygaMorning :-)06:05
mborzeckimvo: 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 email06:06
mvomborzecki: thank you!06:06
zygaamurray: thank you!06:06
mupPR snapd#6174 closed: many: add snap debug refresh-catalogs <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6174>06:11
zygawhat happened here?06:58
=== pstolowski|afk is now known as pstolowski
zygagood morning Pawel07:02
zygapstolowski: winter is coming07:02
pstolowskizyga: up to 19 deg celsius still estimated for today here, pretty crazy07:05
zygapstolowski: -7 forecast by next week07:05
pstolowskizyga: ah, time to change for winter tires indeed07:06
mborzeckipstolowski: yeah, it's probably high time to swap the tires07:08
mborzeckipstolowski: though i'm seriously considering getting an all-year set07:09
pstolowskimborzecki: 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:10
zygaback from breakfast and into testing07:51
mupPR snapd#7635 opened: tests/lib/gendevmodel: helper tool for generating developer model assertions <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7635>08:00
mborzeckipedronis: ^^08:01
causasuiarchlinux. `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 installed08:17
zygacausasui: can you cat /proc/filesystems - is squashfs there?08:36
zygacausasui: it's not a known issue08:36
zygacc mborzecki ^08:36
mborzeckicausasui: can you post the otput of `uname -r` and `pacman -Q linux` ?08:37
causasuimborzecki: uname -r -> 5.3.7-arch1-1-ARCH ; pacman -Q linux -> linux 5.3.7.arch1-108:41
causasuizyga: grep -i squash /proc/filesystems -> null :thinking-face:08:41
zygano squashfs08:41
zygathat's why it fails08:41
zyganow why there's no squashfs? :)08:41
mborzeckiidk, seems to work here on the same kernel version08:42
mborzeckicausasui: anything in dmesg?08:42
zygamborzecki: do you think a good old "modprobe" will fix it?08:42
causasuimborzecki: you probably have squashfs module loaded I'm guessing08:42
mborzeckizyga: it's supposed to be automatic08:42
zygayeah but worth a shot08:42
causasuiprobably cant hurt, modprobe just 'squashfs' right?08:43
causasuialright, now squashfs is in /proc/filesystems but I get the same operation not permitted error08:45
causasuidown the rabbit hole we go08:45
mborzeckicausasui: anytyhing in dmesg?08:45
Chipacacausasui: what gives you operation-not-permitted?08:45
causasuiChipaca: 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 squashfs08:46
causasuimborzecki: tail dmesg shows a bunch of audit messages about snapd that end with 'res=success' which I guess is good?08:47
causasuimsg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'08:47
Chipacacausasui: did you restart snapd after loading squashfs?08:48
Chipacathe sanity check is performed at start and if it fails snapd enters "abandon all hope" mode08:48
causasuihere goes08:48
causasuiok did `sudo systemctl restart snapd && sudo snap install <thing>` and no change08:49
causasuiI'm checking for random degraded services08:49
causasuisystemctl --failed is 008:49
mborzeckicausasui: journalctl -u snapd then?08:50
Chipacamvo says he'll be here in 20, fwiw09:15
causasuimborzecki: hm picking out some interesting things, ' helpers.go:104: error trying to compare the snap system key: system-key missing on disk'09:19
causasuimessages about apparmor not being enabled but that wouldn't cause this I think?09:19
pstolowskizyga: do we have any known issues with having /home on nfs?09:20
causasuiit's way past my bed time sadly, hopefully there will be activity when I'm up. thanks for the help so far09:20
Chipacacausasui: maybe ijohnson and you overlap a little09:20
Chipacacausasui: g'night09:20
zygapstolowski: hey09:26
zygapstolowski: auto-mount is not working there09:26
zygapstolowski: or to be precise, if you have autofs then it doesn't work09:26
zygaexplicit nfs is tested in spread and should work09:26
pstolowskizyga: ok, good09:26
zygapstolowski: I updated https://github.com/snapcore/snapd/pull/763209:27
zygano more buffering09:27
zygano more splitting09:27
mupPR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>09:27
pstolowskizyga: nice, ty, will re-review09:27
zygaif you want I could split the automatic changes09:27
zygathat is, change how we write09:27
zygabefore adding de-dupe09:27
zygathe the branch can simply enable de-duplication and observe a cascade of changes09:28
zygalet me know if this helps in review09:28
zygaI added this as a comment in the review now09:29
pedronispstolowski: #7597 and #7431 (in that order) are Ian's PRs that need reviews09:29
mupPR #7597: overlord/snapstate: add LastActiveDisabledServices, missingDisabledServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7597>09:29
mupPR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>09:29
pstolowskipedronis: ack09:31
zygamvo: hey09:39
zygamvo: I updated https://github.com/snapcore/snapd/pull/7632 -- I asked a question at the bottom of the PR09:39
mupPR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>09:39
zygamvo: splitting that branch could land the bigger automatic chunk easily09:40
mvozyga: thanks, I have a look09:40
zygaI'll grab coffee and add the remaining missing part09:40
dot-tobiasjdstrand: 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
zygaa test that compiles some profiles and ensures we are under 500M of memory09:40
zygaand run it before and after just to be sure09:40
zygadot-tobias: jdstand is off today09:40
zygadot-tobias: if you share the denials I can look09:40
zygabrb for coffee09:40
dot-tobiaszyga: Ok, thanks. The denial is here: https://paste.ubuntu.com/p/CfyfPYsYR7/09:42
dot-tobiaszyga: 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#L2109:46
kjackalHey 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
ogra"cannot connect interfaces" ...09:49
ogracan you be a bit more detailed ?09:50
ogra(what command do you call, whats the error, did you check the journal for errors etc)09:50
kjackal"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
zygadot-tobias: can you look for the DENIED line, it has some more information that is absent here09:52
ogranot sure it does this if the interface is already connected09:52
ogra(and home auto-connects on desktop)09:53
zygadot-tobias: looking09:53
kjackallet me see then09:53
ogras/desktop/classic installs/09:53
zygadot-tobias: network-manager interface does not grant that method09:54
kjackalawesome orga, you are right, everything was already connected09:54
zygadot-tobias: one could argue it should, could you please report a bug, I can look into it09:55
dot-tobiaszyga: 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
ograand you are sure the interface is connected at that time ?09:56
dot-tobiaszyga: Re dmesg line → https://paste.ubuntu.com/p/rg6SXb2vMf/09:56
zygadot-tobias: how are you testing it on the desktop?09:57
zygadot-tobias: introspection is usually not required09:57
zygadot-tobias: perhaps it's something specific to core that triggers it09:57
zygadot-tobias: note this:09:57
zygaconst networkManagerConnectedPlugAppArmor = `09:57
zyga# Description: Allow using NetworkManager service. This gives privileged access09:57
zyga# to the NetworkManager service.09:57
zyga#include <abstractions/dbus-strict>09:57
zyga# Allow all access to NetworkManager service09:57
zygadbus (receive, send)09:57
zyga    bus=system09:57
ogra(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
zyga    path=/org/freedesktop/NetworkManager{,/**}09:57
zyga    peer=(label=###SLOT_SECURITY_TAGS###),09:57
zyga# NM implements org.freedesktop.DBus.ObjectManager too09:57
zygadbus (receive, send)09:57
zyga    bus=system09:57
zyga    path=/org/freedesktop09:57
zyga    interface=org.freedesktop.DBus.ObjectManager09:57
zyga    peer=(label=###SLOT_SECURITY_TAGS###),09:57
zygaoh god, sorry09:57
zygadot-tobias: apparmor spec for connected network-manager plug  https://www.irccloud.com/pastebin/faBWA4Jd/09:58
zygathe only thing that differs between core and classic is the peer label, either "unconfined" on the desktop or some snap label on core09:58
zyganote that the interospectable interface is not there in either case09:58
zygasince the program was ruby09:58
zygaI can infer that it builds a method map for each object it talks to09:59
zygaby using introspection09:59
dot-tobiaszyga, 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
zygabut this is ruby, perhaps on the desktop it reads some files to get that without asking09:59
zygaI honestly don't know09:59
zygabut I can explain why there's a denial on core for sure: because it is not permitted09:59
dot-tobiaszyga: 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
zygadot-tobias: you can expand the interface to add the introspection locally10:00
zygait might help you move further along10:01
zygato see if there's something else blocking10:01
zygalet me know if you need any help with that10:01
dot-tobiaszyga: You mean adding an entry to /var/lib/snapd/apparmor/profiles/snap.mirros-one.hook.post-refresh ?10:01
ogradot-tobias, what i meant is that the slot side might act different in the NM snap compared to the (completely unconfined) deb ...10:02
dot-tobiasogra: 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:03
dot-tobiasogra/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 itself10:04
ograthats what i meant :)10:05
ogra(or guessed rather :) )10:05
zygadot-tobias: in any case, if you report a bug I can get it fixed today10:05
zygaI just need to write a regression test for somethnig else10:05
dot-tobiaszyga: On it, should I file against snapd?10:06
zygayes, please10:06
dot-tobiaszyga: 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
mupBug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <snapd:New> <https://launchpad.net/bugs/1849291>10:23
zygadot-tobias: not sure, I'll add this to the bug when I konw10:29
zygawow, what a dramatic difference this fix makes!!!10:31
Chipacazyga: which?10:34
zygawall: 0:03.17, mem: 1552532 Kb10:35
zygawall: 0:00.22, mem: 37728 Kb10:35
zygathat's a winner10:35
zygaChipaca: this is the mount de-duplicating10:37
mupPR pc-amd64-gadget#21 closed: Xnox closing uc20 branch <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/21>10:47
mupPR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <Closed by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/10>10:54
mupPR snapd#7636 opened: gadget, overlord/devicestate: dd support for customized update policy, add remodel policy <Remodel :train:> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7636>11:02
mborzeckimvo: pedronis: ^^11:02
mborzeckishould be a simple one11:02
mborzeckizyga: you said somethng about exponential growth the other day, didn't you? :)11:03
zygawrapping up the test soon :)11:03
zygabut happy to fix this11:03
zygathis will save a lot of energy planet-wide11:04
mborzeckizyga: there a line for your CV ;)11:04
zygawrote inefficient code, fixed it after shipping to everyone11:04
mborzeckisounds too familiar when you put it this way11:05
ograisnt that the standard anyway ?11:05
mupPR snapd#7637 opened: tests/main/interfaces-contacts-service: disable on openSUSE Tumbleweed <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7637>11:08
mborzecki^^ should unblock master11:08
mborzeckiand PRs too11:09
mupPR pc-amd64-gadget#22 opened: Store changes <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/22>11:10
Chipacazyga: mborzecki: "croud-sourced performance measurements"11:16
zygaChipaca: practical experience in reducing climate change11:16
zygaok, test executing now11:23
pedronismborzecki: thanks, trying to get to a pause point with something else, and then I will switch to do a bit of PR reviewing11:25
mborzeckipedronis: thanks!11:25
mvomborzecki: thanks for this one (I changed dd -> add in the title, hope that was ok)11:27
mborzeckimvo: haha thanks!11:29
pedronisheh, for a second I wondered if the 'dd' command was involved11:30
pstolowskiijohnson: 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 fullstops11:46
mupPR snapd#7637 closed: tests/main/interfaces-contacts-service: disable on openSUSE Tumbleweed <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7637>11:58
zygathanks mvo12:05
mvozyga: thanks to mborzecki12:06
zygapstolowski: 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 landing12:06
zygapstolowski: so that the actual fix is just a small change + test changes + regression test12:06
pstolowskizyga: 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
zygapstolowski: it's very easy to split, vast majority of change is the "getting ready" code12:17
zygapstolowski: that can land without any effect to tests or actual performance today12:17
=== ricab is now known as ricab|lunch
zygapstolowski: I'm mainly looking for someone who would follow along and review it12:19
zygapstolowski: but no rush, I'm working on the spread test still, I need to check the numbers as I see some discrepancy12:19
pstolowskizyga: okay, perhaps after standup12:19
zygathere's no "time" command on core12:20
zygapstolowski: thanks!12:21
pedronismvo: 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
mupPR #7615: policy: implement CanRemove policy for the snapd type <Created by mvo5> <https://github.com/snapcore/snapd/pull/7615>12:21
pstolowskicore has no time12:21
mborzeckicore is super busy12:21
Chipacapedronis: i think it's ok without your input12:22
Chipacapedronis: ah, one question there, was that I recommended using model.Classic() instead of release.OnClassic, wdyt?12:22
pedronisthat sounds fine12:23
zygamborzecki: is there a "time" command on arch?12:23
Chipacapedronis: ok12:23
mborzeckizyga: there's 2 time commands, some shells have a builtin, and there's gnu time at /usr/bin/time12:23
zygaI need GNU time12:24
mborzeckizyga: yup, that one is avialble, you may need to install it separately12:24
pedronisChipaca: we should just be consistent across policy about that12:24
zygamborzecki: thanks12:24
Chipacapedronis: agreed12:24
Chipacamborzecki: zyga: why wouldn't gnu time be installed?12:25
zygaChipaca: it's not on core12:25
mborzeckiChipaca: tbh i think it rarely is12:25
zygaand not on arch or sid12:25
mborzeckiiirc fedora doesn't have it by default either12:26
ograzyga, core ships at least the shell builtin12:26
zygaogra: it's not what I need12:26
zygaI need the other one12:26
mborzeckizyga: you probably need time -v right?12:26
zygatime -f %M12:26
ograsnap it then ;)12:26
mborzeckiheh ;)12:26
zygaogra: cannot run snaps with snaps12:27
ograpfft, minor detail ...12:27
* zyga breaks for lunch12:30
zygasee you at the standup12:30
* zyga watches https://www.youtube.com/watch?v=L-7W5pc7OjU while eating veggies12:31
Chipacazyga: is #7615 GTG IYHO?12:37
zygaone sec12:37
mupPR #7615: policy: implement CanRemove policy for the snapd type <Created by mvo5> <https://github.com/snapcore/snapd/pull/7615>12:37
zygaI'll do a pass, I think so12:38
zygait looked ok before12:38
zygajust had that one question then12:38
mupPR snapd#7638 opened: Add OnlyKey to List <Created by onlykey> <https://github.com/snapcore/snapd/pull/7638>12:50
pedronismborzecki: 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 big12:54
mupPR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel :train:> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>12:54
mborzeckipedronis: thanks, will take a look after than standup12:55
mborzeckis/than/the/ ofc12:56
Chipacaeep, the standup12:58
* Chipaca runs12:58
kjackalhey snappy people, to use the "system-usernames:" I need snapd to be patched to be aware of the username?13:05
Chipacakjackal: no, only one username is supported for now13:06
Chipacakjackal: 1 sec, there's an explanation13:07
zygaondra: nice work on https://github.com/snapcore/snapd/pull/759613:07
mupPR #7596: overlord/snapstate: skip catalog refresh if unseeded <Simple 😃> <Created by kubiko> <https://github.com/snapcore/snapd/pull/7596>13:08
Chipacakjackal: we're in phase 1, https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/146113:08
Chipacakjackal: sorry, this: https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461/3?u=chipaca13:09
Chipacaphase 1 is described at the end of that comment13:09
Chipacakjackal: i assume you've seen https://forum.snapcraft.io/t/system-usernames/13386 already13:11
Chipacakjackal: which is also describing current, ie phase 113:11
kjackalChipaca: so there is only one user/group I can use, the "snap_daemon", right?13:11
Chipacakjackal: at this stage, yes13:11
kjackalsounds good, let me try that13:12
mupPR snapd#7596 closed: overlord/snapstate: skip catalog refresh if unseeded <Simple 😃> <Created by kubiko> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7596>13:13
zygaand now I have an 1080p IPS display13:28
zygathe difference is insane :D13:29
diddledanmine's bigger :-p13:31
* zyga is very happy with what he has :)13:31
=== ricab|lunch is now known as ricab
Chipacadiddledan: it's not how big it is, it's how much you giggle while using it13:32
diddledanhaha. and that did make me giggle13:32
* Chipaca rests his case13:33
diddledangiggle when you wiggle it :-)13:33
diddledangithub actions really need better (more) examples13:34
diddledanI wish CI services had local working environments to test that you've configured correctly before you upload to your shared project repository13:36
diddledanotherwise 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
zygadiddledan: I very much share this opinion13:37
zygait's very annoying13:38
zygaI think travis used to have something like that13:38
zygavia their ruby command line tool13:38
zygait'd let you run a job against your working directory13:38
diddledanit's not just travis though, none of them have anything like it13:38
zygadiddledan: did you see https://github.com/travis-ci/travis.rb13:41
mupPR snapcraft#2760 opened: remote-build: rebase onto master <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2760>13:44
ChrisTownsendHey 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
zygaChipaca: there's a bug about that13:57
zygaChrisTownsend: ^13:57
zygaChrisTownsend: sorry, tab completed incorrectly13:58
zygaChrisTownsend: we need to look into it13:58
ChrisTownsendzyga: Ah, ok...no worries about tab completion:)13:58
ChrisTownsendzyga: Do you have the bug number handy?13:58
mupBug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:New> <https://launchpad.net/bugs/1848516>13:59
ChrisTownsendzyga: 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
ChrisTownsendzyga: Thanks for the link13:59
zygaChrisTownsend: that part works okay but we need to fix the UX to match AFAIK14:00
ChrisTownsendzyga: Ok, great, thanks!14:00
zygapstolowski: so do you have a moment14:06
pstolowskizyga: yes, but need a (late) lunch first14:06
zygapstolowski: ok, please ping me later14:07
pstolowskizyga: sure14:07
* zyga goes to play with the thinkpad for a moment14:07
zygais "command foo" equivalent to running /usr/bin/foo over alias/builtin?14:17
zygamborzecki: around?14:48
zygamborzecki, pstolowski: this is the emit PR: https://github.com/snapcore/snapd/pull/763914:48
mupPR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>14:49
zygait puts enough indirection for the de-duplication PR to shrink14:49
mupPR snapd#7639 opened: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>14:49
pstolowskizyga: ok, looking. how can i help with the remainder?15:01
mupPR snapd#7640 opened: snap-recovery: deploy gadget content when creating partitions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7640>15:01
mupPR snapd#7615 closed: policy: implement CanRemove policy for the snapd type <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7615>15:03
zygapstolowski: re15:05
zygapstolowski: please review https://github.com/snapcore/snapd/pull/763915:06
mupPR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>15:06
zygathis is the no-op part of the real fi15:06
zygaso if it lands I can shrink the other PR to the real essence15:06
zygapstolowski: for context on emit15:10
zygapstolowski: it is used in the "big" PR where it is a thin wrapper around simply adding a de-duplicated snipper15:10
pstolowskizyga: yes, looks like a good plan15:14
Chipacazyga: did you check onlykey for CLA signature before +1'ing?15:25
Chipacazyga: I don't think CLA is needed for the code so far, but fixing the test as well might push it over? dunno15:25
pedronisijohnson: https://forum.snapcraft.io/t/systemctl-service-management-unification/13808/315:27
pstolowskizyga: a bit of a general question there15:35
* cachio lunch15:37
zygaChipaca: no, because there's a CI part for it15:37
zygapstolowski: looking15:38
zygapstolowski: replied15:38
zygapstolowski: replied again15:42
pstolowskizyga: where are these helpers tested? i grepped the code / looked for references, found nothing15:45
Chipacazyga: that, when I added, I said should be checked for false-negatives of newcomers15:45
Chipacaor is that false-positives? either way, this is one of those cases15:46
zygapstolowski: huh, you are right! they are no tested directly15:46
zygathey can be dropped15:46
pstolowskiuff ;)15:46
zygathey are tested indirectly obviously but I thought we had a bunch of explicit tests as well15:46
zygaChipaca: aha, I didn't know that15:47
zygapstolowski: dropped now15:47
zygathanks, that's a nice catch :)15:47
zygaChipaca: I think it's false-sense-of-security then :)15:48
zygapstolowski: do you plan to do any more reviews todayt/16:04
zygapstolowski: if not I will EOD16:04
zygapstolowski: and return here tomorrow16:04
pstolowskizyga: just added last comment16:05
zygapstolowski: I tried to reply, perhaps we can HO quickly if you want to16:07
zygathough I won't mind to wait for tomorrow if you want to EOD16:07
pstolowskizyga: yep tomorrow, i need to leave soon, taking my daughter to horse club16:08
zygapstolowski: cool! I'm sure she will love it16:08
zygamvo: hey :) welcome back?16:08
zygapstolowski: thank you, lets continue tomorrow morning16:08
* zyga EODs16:08
mvozyga: yeah, was back before but then network decided to stop working16:08
pstolowskizyga: it's weekly routine for a while already ;)16:08
* zyga looks at shiny new thinkpad screen :)16:08
zygapstolowski: my daughter is way more lazy16:09
zygashe only did it three times16:09
zygamvo: the screen is gorgeous :)16:09
pstolowskizyga: horses 1x a week, football 2-3x a week :O16:09
mvozyga: 1900x1200 ?16:09
zygamvo: I won't bother you tonight, I have some PRs for review but I think it's time to stop16:09
zygamvo: 1080p only16:09
zygamvo: it's a panel that fits into the device but it's not sold with it originally16:10
om26erCan I use python 3.8 in my snap, is there a how-to for that ?16:10
zygaom26er: yes, if you build python3.8 it can be used there16:10
zygaI don't know if there's a tutorial for it16:10
zygaom26er: snapcraft may or may not help you with it a lot16:10
zygaom26er: but technically you can ship that snap to 14.04 tomorrow and it will work16:10
om26erI want 3.8 because apparently we can set custom location for pycache tree, skipping the build time bytecompile of files and doing that using a post-install hook, ultimately causing a reduction is snap size16:12
zygaom26er: if you start with a part that builds 3.8 from scratch16:12
zygaom26er: add your app in a way that doesn't cause snapcraft to pull in all of python 3.7 for you again16:12
zygaom26er: in other words, yes, for sure, just more manually than otherwise snapcraft allows for16:13
om26erin our case our snap of 33mb becomes 49mbs with bytecompiled code. (doing that is important because startup on raspberry pi changes from 30 seconds to 10)16:13
om26erzyga hmm, I will dig into this16:13
zygaom26er: good luck!16:13
zygaom26er: as you get that done you also gain independence and flexibility16:13
zygaom26er: you can optimize python16:13
zygaom26er: build some parts disabled16:13
zygaom26er: and go to 3.9 the day it is out16:14
zygaom26er: or you can follow fixes that you need16:14
=== pstolowski is now known as pstolowski|afk
om26erheh, I think 3.8 is what I need, no other requirements for now ;-)16:14
om26erOTOH: Can we use python 3.6 from core18 -- so we don't bundle our own copy of python ?16:15
zygaom26er: yes16:15
zygaom26er: again, I don't know if snapcraft makes that easy16:15
* om26er adds that to "to dig" list :-)16:16
om26erWimpress ping! you talked about trimming a Python based snap at Ubucon, can you share a snapcraft yaml that does that ?16:17
ijohnsonpedronis: ack thanks for looking at that, so do I have general consensus on the proposal outlined there? or do you anticipate having more comments?16:22
ijohnson(I know Chipaca will review it as well, but just wondering if I should consider your comment as a +1)16:31
Saviqjdstrand: hey, I'm running snap-review in our CI, and we're switching to strict with the `multipass-support` plug - any way we can make snap-review pass? https://travis-ci.org/CanonicalLtd/multipass/jobs/601308279#L475016:45
zygaSaviq: jdstrand is back tomorrow16:49
Saviqack :)16:49
pedronisijohnson: it's +1 assuming my expansion of your point seems to match what you had in mind17:10
ijohnsonyes it matches17:11
ijohnsonthanks pedronis17:11
pedronisijohnson: you'll have to chat a bit with pstolowski|afk though because I fear that your change and what he will need to do for the bug he mentioned today will interfere a bit17:15
pedronisijohnson: because it sound he needs start-snap-services to become a start --enable17:16
ograom26er, while you can indeed use the python binary itself from core/core18 you still need your python modules ... the python binar itself is 4-5MB uncompressed, compressed inside your snap that will just save you 1MB or so in the end ...17:40
ogra7me isnt sure thats actually worth the effort17:41
ijohnsonpedronis: ack yes I will chat with him tomorrow17:44
causasuiarchlinux. `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'. squashfs-tools and squashfuse are both installed & squashfs is in /proc/filesystems18:44
causasuihave rebooted since install & last kernel update is loaded etc18:44
mupPR snapcraft#2760 closed: remote-build: rebase onto master <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2760>18:48
ijohnsonhey causasui sorry we missed you earlier, do you see anything in dmesg when this happens?18:57
causasuiijohnson: messages about apparmor not being enabled but that wouldn't cause this I think? http://ix.io/1ZwJ there's a sample18:59
ijohnsoncausasui: what does `snap changes` show for you?19:00
causasui1    Done    yesterday at 23:52 PDT  yesterday at 23:52 PDT  Initialize system state19:02
mupPR snapd#7641 opened: tests: moving ubuntu-19.10-64 from google-unstable to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7641>19:15
causasuiijohnson: has this risen to the level of a forum / stackexchange post?19:22
ijohnsoncausasui: thanks for that, what is `snap version` for you?19:22
causasuiijohnson: 2.42-2 http://ix.io/1ZwR19:22
ijohnsoncausasui: can you run `snap download hello-world && mkdir test && sudo mount -o squashfs hello-world*.snap test` and see what happens?19:25
ogracausasui, grep squash /proc/filesystems19:25
ijohnsonsnap download doesn't currently go through snapd so that should work fine19:25
ijohnsonogra: he already has squash in /proc/filesystems19:25
ogra(see if your kernel doesnt accidentially miss squashfs)19:25
ijohnsons/he/they/ (sorry)19:25
ograoh, ok19:25
ogra(right, i havent seen the first line above)19:26
ijohnsonmy best guess is this is some kine of kernel mount problem19:26
ograthere was a bug in 5.219:26
ijohnsoncan't type today for some reason19:26
ijohnsonyeah they have 5.3.719:26
ograprobably the fix got lost with the newer update ?19:28
ijohnsonyeah could be19:28
causasuiogra: it's there19:32
causasuiogra: squashfs in /proc/filesystems that is19:32
causasuiijohnson: 'he' is fine, thanks19:33
ijohnson:-) don't want to assume19:33
ijohnsonwere you able to run that snippet above?19:33
causasuiijohnson: which?19:34
ijohnsoncausasui: can you run `snap download hello-world && mkdir test && sudo mount -o squashfs hello-world*.snap test` and see what happens?19:34
causasuimount: hello-world*.snaptest: can't find in /etc/fstab.19:35
causasuioh you forgot the mountpoint19:36
mupPR snapcraft#2761 opened: Core20 base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2761>19:36
ijohnsonhmm copy paste error?19:37
causasuiah it wrapped19:37
causasuimount: /tmp/test: special device hello-world*.snaptest does not exist.19:38
ogramissing space19:38
ogra sudo mount -o squashfs hello-world*.snap tes19:38
ogra sudo mount -o squashfs hello-world*.snap test19:38
causasuimount: test/: mount failed: Operation not permitted.19:38
ijohnsonare you root?19:38
ijohnsonor using sudo?19:38
causasuiI'll try becoming root, why not19:39
causasuiyeah same error as root19:40
ijohnsonhmm, try `sudo strace -emount mount -o squashfs hello-world*.snap test` ?19:40
zygacausasui: if you are getting permission denied as root then there must be a LSM around you19:41
zygacausasui: or something is intercepting system calls for you19:41
ograselinux ?19:41
ograthat would produce dmesg messages, no ?19:41
ijohnsondoes arch use selinux? I didn't think so19:42
ogra(or kern.log or whatever arch uses)19:42
causasuiselinux is available but it takes some work to set up, based on the wiki. I for sure did not install it knowingly19:42
ograyeah, unlikrly thats it then19:42
ijohnsoncausasui: is this perhaps some kind of container?19:43
causasuiijohnson: what is "this"? I thought snaps were containers19:43
ograyour archlinux ..19:43
causasuiogra: that's not obvious from the question, sorry. no, it's not19:43
ijohnsonerr sorry is your arch installation is it a container or a VM or something?19:43
ograis it running indside a container19:43
ograanything in dmesg from your mount attempts ?19:43
causasuino new messages in dmesg19:44
ograjournald ?19:44
zygadmesg may not contain anything related to LSMs if there's nothing collecting those from the kernel and turning them into log messages19:44
zygae.g. auditd19:44
ograsure, but always worth taking a look anyway19:44
causasuiogra: I don't see anything relevant in journalctl exept sudo logging the mount attempts themselves19:45
ijohnsonat this point I think a forum post is warranted, I have no idea what this is, and it very well could be an upstream kernel issue with mounts19:45
ogrado you have any opportunity to use an older kernel for a uick test ?19:46
ijohnsonif you're getting permission denied from trying to mount a squashfs but squashfs is in /proc/filesystems and you don't have selinux on, then smells like a kernel thing to me19:46
ograsmells really similar to the forum post above about archs 5.2 kernel19:47
ijohnsonyeah indeed19:47
ograbut there you had at least a few chatty error messages19:47
ograsilence in all logs is really weird19:47
mupPR snapcraft#2762 opened: appstream: extract title and version <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2762>20:00
ijohnsoncachio: any chance you could review #7581 this afternoon?20:17
mupPR #7581: tests: add netplan test on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7581>20:17
causasuiijohnson: ogra: I assume the best venue is the one linked in the topic :) I'll type something up in there, thanks20:18
ijohnsonsounds good to me20:18
causasuithis is snapd not snapcraft right?20:22
ijohnsonit's a snapd bug yes, but the official forum is forum.snapcraft.iot20:24
ijohnsonerr forum.snapcraft.io20:24
cwayneAww man it should be .iot20:26
ijohnsonthat would be a cool TLD20:29
causasuiijohnson: yes but there are different tags in that forum20:31
ijohnsoncausasui: right snapd tag is correct20:31
ijohnsonthanks, we'll make sure that our resident arch expert mborzecki takes a look tomorrow20:32
cyphermoxijohnson: are there tests we can add to netplan too to check that things are sane?20:38
ijohnsoncyphermox: what things need to be tested?20:57
cyphermoxijohnson: I don't know, but if you're adding tests for netplan in snapd, I'm questioning if there's some test I can add in netplan to facilitate20:57
cachioijohnson, sure21:09
ijohnsoncyphermox: ah right that test, well I think you already have tests for that on your side, all I added was tests for accessing the info d-bus method to network-setup-{observe,control}21:32
cyphermoxok :)21:41

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