[03:55] <guiverc> 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] <guiverc> (on 19.10 ^)
[03:58] <guiverc> 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] <mup> Bug #1575560 changed: snap refresh in status hold; not clear how to continue <Snappy:Expired> <https://launchpad.net/bugs/1575560>
[04:19] <mup> Bug #1595649 changed: Audio playback fails for KDE apps with Phonon <Snappy:Expired> <https://launchpad.net/bugs/1595649>
[04:19] <mup> Bug #1620815 changed: Test failures in github.com/snapcore/snapd/cmd/snap at 0187d66 <Snappy:Expired> <https://launchpad.net/bugs/1620815>
[05:16] <mborzecki> morning
[05:45] <mborzecki> mvo:  hey
[06:03] <mborzecki> mvo: i'll be looking into the failures with go.mod
[06:03] <mborzecki> mvo: perhaps the tests need a tweak
[06:04] <mvo> mborzecki: thank you! any news from xerrors for f30 yet?
[06:05] <zyga> Hey guys
[06:05] <zyga> Good
[06:05] <zyga> Morning :-)
[06:06] <mborzecki> 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] <mvo> mborzecki: thank you!
[06:06] <zyga> amurray: thank you!
[06:11] <mup> PR snapd#6174 closed: many: add snap debug refresh-catalogs <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6174>
[06:44] <zyga> re
[06:58] <zyga> huh
[06:58] <zyga> https://travis-ci.org/snapcore/snapd/jobs/600949213
[06:58] <zyga> what happened here?
[07:01] <pstolowski> morning
[07:02] <zyga> good morning Pawel
[07:02] <zyga> pstolowski: winter is coming
[07:05] <pstolowski> zyga: up to 19 deg celsius still estimated for today here, pretty crazy
[07:05] <zyga> pstolowski: -7 forecast by next week
[07:06] <pstolowski> zyga: ah, time to change for winter tires indeed
[07:08] <mborzecki> pstolowski: yeah, it's probably high time to swap the tires
[07:09] <mborzecki> pstolowski: though i'm seriously considering getting an all-year set
[07:10] <pstolowski> 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] <zyga> brb
[07:51] <zyga> back from breakfast and into testing
[08:00] <mup> PR 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:01] <mborzecki> pedronis: ^^
[08:17] <causasui> 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] <zyga> causasui: can you cat /proc/filesystems - is squashfs there?
[08:36] <zyga> causasui: it's not a known issue
[08:36] <zyga> cc mborzecki ^
[08:37] <mborzecki> causasui: can you post the otput of `uname -r` and `pacman -Q linux` ?
[08:41] <causasui> mborzecki: uname -r -> 5.3.7-arch1-1-ARCH ; pacman -Q linux -> linux 5.3.7.arch1-1
[08:41] <causasui> zyga: grep -i squash /proc/filesystems -> null :thinking-face:
[08:41] <zyga> no squashfs
[08:41] <zyga> that's why it fails
[08:41] <zyga> now why there's no squashfs? :)
[08:41] <causasui> ^
[08:42] <mborzecki> idk, seems to work here on the same kernel version
[08:42] <mborzecki> causasui: anything in dmesg?
[08:42] <zyga> mborzecki: do you think a good old "modprobe" will fix it?
[08:42] <causasui> mborzecki: you probably have squashfs module loaded I'm guessing
[08:42] <mborzecki> zyga: it's supposed to be automatic
[08:42] <zyga> yeah but worth a shot
[08:43] <causasui> probably cant hurt, modprobe just 'squashfs' right?
[08:43] <zyga> indeed
[08:45] <causasui> alright, now squashfs is in /proc/filesystems but I get the same operation not permitted error
[08:45] <causasui> down the rabbit hole we go
[08:45] <mborzecki> causasui: anytyhing in dmesg?
[08:45] <Chipaca> causasui: what gives you operation-not-permitted?
[08:46] <causasui> 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] <causasui> mborzecki: tail dmesg shows a bunch of audit messages about snapd that end with 'res=success' which I guess is good?
[08:47] <causasui> msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[08:48] <Chipaca> causasui: did you restart snapd after loading squashfs?
[08:48] <causasui> no
[08:48] <Chipaca> the sanity check is performed at start and if it fails snapd enters "abandon all hope" mode
[08:48] <causasui> here goes
[08:49] <causasui> ok did `sudo systemctl restart snapd && sudo snap install <thing>` and no change
[08:49] <causasui> I'm checking for random degraded services
[08:49] <Chipaca> 🐀
[08:49] <causasui> systemctl --failed is 0
[08:50] <mborzecki> causasui: journalctl -u snapd then?
[09:15] <Chipaca> mvo says he'll be here in 20, fwiw
[09:19] <causasui> 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] <causasui> messages about apparmor not being enabled but that wouldn't cause this I think?
[09:20] <pstolowski> zyga: do we have any known issues with having /home on nfs?
[09:20] <causasui> 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] <Chipaca> causasui: maybe ijohnson and you overlap a little
[09:20] <Chipaca> causasui: g'night
[09:26] <zyga> pstolowski: hey
[09:26] <zyga> pstolowski: auto-mount is not working there
[09:26] <zyga> pstolowski: or to be precise, if you have autofs then it doesn't work
[09:26] <zyga> explicit nfs is tested in spread and should work
[09:26] <pstolowski> zyga: ok, good
[09:27] <zyga> pstolowski: I updated https://github.com/snapcore/snapd/pull/7632
[09:27] <zyga> no more buffering
[09:27] <zyga> no more splitting
[09:27] <mup> PR #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] <pstolowski> zyga: nice, ty, will re-review
[09:27] <zyga> if you want I could split the automatic changes
[09:27] <zyga> that is, change how we write
[09:27] <zyga> before adding de-dupe
[09:28] <zyga> the the branch can simply enable de-duplication and observe a cascade of changes
[09:28] <zyga> let me know if this helps in review
[09:29] <zyga> I added this as a comment in the review now
[09:29] <pedronis> pstolowski: #7597 and #7431 (in that order) are Ian's PRs that need reviews
[09:29] <mup> PR #7597: overlord/snapstate: add LastActiveDisabledServices, missingDisabledServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7597>
[09:29] <mup> PR #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:31] <pstolowski> pedronis: ack
[09:39] <zyga> mvo: hey
[09:39] <zyga> mvo: I updated https://github.com/snapcore/snapd/pull/7632 -- I asked a question at the bottom of the PR
[09:39] <mup> PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
[09:40] <zyga> mvo: splitting that branch could land the bigger automatic chunk easily
[09:40] <mvo> zyga: thanks, I have a look
[09:40] <zyga> I'll grab coffee and add the remaining missing part
[09:40] <dot-tobias> 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] <zyga> a test that compiles some profiles and ensures we are under 500M of memory
[09:40] <zyga> and run it before and after just to be sure
[09:40] <zyga> dot-tobias: jdstand is off today
[09:40] <zyga> dot-tobias: if you share the denials I can look
[09:40] <zyga> brb for coffee
[09:42] <dot-tobias> zyga: Ok, thanks. The denial is here: https://paste.ubuntu.com/p/CfyfPYsYR7/
[09:46] <dot-tobias> 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] <kjackal> 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] <ogra> "cannot connect interfaces" ...
[09:50] <ogra> can 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:52] <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] <zyga> dot-tobias: can you look for the DENIED line, it has some more information that is absent here
[09:52] <ogra> not sure it does this if the interface is already connected
[09:53] <ogra> (and home auto-connects on desktop)
[09:53] <zyga> dot-tobias: looking
[09:53] <kjackal> let me see then
[09:53] <ogra> s/desktop/classic installs/
[09:54] <zyga> dot-tobias: network-manager interface does not grant that method
[09:54] <kjackal> awesome orga, you are right, everything was already connected
[09:55] <zyga> dot-tobias: one could argue it should, could you please report a bug, I can look into it
[09:55] <ogra> yay
[09:56] <dot-tobias> 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] <ogra> and you are sure the interface is connected at that time ?
[09:56] <dot-tobias> zyga: Re dmesg line → https://paste.ubuntu.com/p/rg6SXb2vMf/
[09:57] <zyga> dot-tobias: how are you testing it on the desktop?
[09:57] <zyga> dot-tobias: introspection is usually not required
[09:57] <zyga> dot-tobias: perhaps it's something specific to core that triggers it
[09:57] <zyga> dot-tobias: note this:
[09:57] <zyga> const networkManagerConnectedPlugAppArmor = `
[09:57] <zyga> # Description: Allow using NetworkManager service. This gives privileged access
[09:57] <zyga> # to the NetworkManager service.
[09:57] <zyga> #include <abstractions/dbus-strict>
[09:57] <zyga> # Allow all access to NetworkManager service
[09:57] <zyga> dbus (receive, send)
[09:57] <zyga>     bus=system
[09: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 too
[09:57] <zyga> dbus (receive, send)
[09:57] <zyga>     bus=system
[09:57] <zyga>     path=/org/freedesktop
[09:57] <zyga>     interface=org.freedesktop.DBus.ObjectManager
[09:57] <zyga>     peer=(label=###SLOT_SECURITY_TAGS###),
[09:57] <zyga> `
[09:57] <zyga> oh god, sorry
[09:58] <ogra> yay
[09:58] <zyga> dot-tobias: apparmor spec for connected network-manager plug  https://www.irccloud.com/pastebin/faBWA4Jd/
[09:58] <zyga> 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] <zyga> note that the interospectable interface is not there in either case
[09:58] <zyga> since the program was ruby
[09:59] <zyga> I can infer that it builds a method map for each object it talks to
[09:59] <zyga> by using introspection
[09:59] <dot-tobias> 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] <zyga> but this is ruby, perhaps on the desktop it reads some files to get that without asking
[09:59] <zyga> I honestly don't know
[09:59] <zyga> but I can explain why there's a denial on core for sure: because it is not permitted
[10:00] <dot-tobias> 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] <zyga> dot-tobias: you can expand the interface to add the introspection locally
[10:01] <zyga> it might help you move further along
[10:01] <zyga> to see if there's something else blocking
[10:01] <zyga> let me know if you need any help with that
[10:01] <dot-tobias> zyga: You mean adding an entry to /var/lib/snapd/apparmor/profiles/snap.mirros-one.hook.post-refresh ?
[10:02] <ogra> 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] <dot-tobias> 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] <ogra> right
[10:04] <dot-tobias> 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] <ogra> thats what i meant :)
[10:05] <zyga> yep
[10:05] <ogra> (or guessed rather :) )
[10:05] <zyga> dot-tobias: in any case, if you report a bug I can get it fixed today
[10:05] <zyga> I just need to write a regression test for somethnig else
[10:06] <dot-tobias> zyga: On it, should I file against snapd?
[10:06] <zyga> yes, please
[10:23] <dot-tobias> 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] <mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <snapd:New> <https://launchpad.net/bugs/1849291>
[10:29] <zyga> dot-tobias: not sure, I'll add this to the bug when I konw
[10:29] <zyga> *know
[10:31] <zyga> wow, what a dramatic difference this fix makes!!!
[10:34] <Chipaca> zyga: which?
[10:35] <zyga> before
[10:35] <zyga> wall: 0:03.17, mem: 1552532 Kb
[10:35] <zyga> after
[10:35] <zyga> wall: 0:00.22, mem: 37728 Kb
[10:35] <zyga> that's a winner
[10:35] <zyga> :D
[10:37] <zyga> Chipaca: this is the mount de-duplicating
[10:37] <zyga> *deduplication
[10:47] <mup> PR 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:54] <mup> PR 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>
[11:02] <mup> PR 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] <mborzecki> mvo: pedronis: ^^
[11:02] <mborzecki> should be a simple one
[11:03] <mborzecki> zyga: you said somethng about exponential growth the other day, didn't you? :)
[11:03] <zyga> yeah
[11:03] <zyga> wrapping up the test soon :)
[11:03] <zyga> but happy to fix this
[11:04] <zyga> this will save a lot of energy planet-wide
[11:04] <mborzecki> zyga: there a line for your CV ;)
[11:04] <zyga> wrote inefficient code, fixed it after shipping to everyone
[11:05] <mborzecki> sounds too familiar when you put it this way
[11:05] <ogra> isnt that the standard anyway ?
[11:08] <mup> PR 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 master
[11:09] <mborzecki> and PRs too
[11:10] <mup> PR pc-amd64-gadget#22 opened: Store changes <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/22>
[11:16] <Chipaca> zyga: mborzecki: "croud-sourced performance measurements"
[11:16] <zyga> Chipaca: practical experience in reducing climate change
[11:23] <zyga> ok, test executing now
[11:25] <pedronis> 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] <mborzecki> pedronis: thanks!
[11:27] <mvo> mborzecki: thanks for this one (I changed dd -> add in the title, hope that was ok)
[11:29] <mborzecki> mvo: haha thanks!
[11:30] <pedronis> heh, for a second I wondered if the 'dd' command was involved
[11:46] <pstolowski> 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] <mup> PR 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] <mborzecki> yay
[12:05] <zyga> thanks mvo
[12:06] <mvo> zyga: thanks to mborzecki
[12:06] <zyga> 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] <zyga> pstolowski: so that the actual fix is just a small change + test changes + regression test
[12:17] <pstolowski> 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] <zyga> pstolowski: it's very easy to split, vast majority of change is the "getting ready" code
[12:17] <zyga> pstolowski: that can land without any effect to tests or actual performance today
[12:19] <zyga> pstolowski: I'm mainly looking for someone who would follow along and review it
[12:19] <zyga> 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] <pstolowski> zyga: okay, perhaps after standup
[12:20] <zyga> booo
[12:20] <zyga> there's no "time" command on core
[12:21] <zyga> pstolowski: thanks!
[12:21] <pedronis> 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] <mup> PR #7615: policy: implement CanRemove policy for the snapd type <Created by mvo5> <https://github.com/snapcore/snapd/pull/7615>
[12:21] <pstolowski> core has no time
[12:21] <mborzecki> core is super busy
[12:22] <Chipaca> pedronis: i think it's ok without your input
[12:22] <pedronis> ok
[12:22] <Chipaca> pedronis: ah, one question there, was that I recommended using model.Classic() instead of release.OnClassic, wdyt?
[12:23] <pedronis> that sounds fine
[12:23] <zyga> mborzecki: is there a "time" command on arch?
[12:23] <Chipaca> pedronis: ok
[12:23] <mborzecki> zyga: there's 2 time commands, some shells have a builtin, and there's gnu time at /usr/bin/time
[12:24] <zyga> I need GNU time
[12:24] <mborzecki> zyga: yup, that one is avialble, you may need to install it separately
[12:24] <pedronis> Chipaca: we should just be consistent across policy about that
[12:24] <zyga> mborzecki: thanks
[12:24] <Chipaca> pedronis: agreed
[12:25] <Chipaca> mborzecki: zyga: why wouldn't gnu time be installed?
[12:25] <zyga> Chipaca: it's not on core
[12:25] <mborzecki> Chipaca: tbh i think it rarely is
[12:25] <zyga> and not on arch or sid
[12:25] <Chipaca> huh
[12:26] <mborzecki> iirc fedora doesn't have it by default either
[12:26] <ogra> zyga, core ships at least the shell builtin
[12:26] <zyga> ogra: it's not what I need
[12:26] <zyga> I need the other one
[12:26] <mborzecki> zyga: you probably need time -v right?
[12:26] <zyga> no
[12:26] <zyga> time -f %M
[12:26] <ogra> snap it then ;)
[12:26] <mborzecki> heh ;)
[12:27] <zyga> ogra: cannot run snaps with snaps
[12:27] <ogra> pfft, minor detail ...
[12:30]  * zyga breaks for lunch
[12:30] <zyga> see you at the standup
[12:31]  * zyga watches https://www.youtube.com/watch?v=L-7W5pc7OjU while eating veggies
[12:37] <Chipaca> zyga: is #7615 GTG IYHO?
[12:37] <zyga> one sec
[12:37] <mup> PR #7615: policy: implement CanRemove policy for the snapd type <Created by mvo5> <https://github.com/snapcore/snapd/pull/7615>
[12:38] <zyga> ah
[12:38] <zyga> I'll do a pass, I think so
[12:38] <zyga> it looked ok before
[12:38] <zyga> just had that one question then
[12:50] <mup> PR snapd#7638 opened: Add OnlyKey to List <Created by onlykey> <https://github.com/snapcore/snapd/pull/7638>
[12:54] <pedronis> 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] <mup> PR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel :train:> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>
[12:55] <mborzecki> pedronis: thanks, will take a look after than standup
[12:56] <mborzecki> s/than/the/ ofc
[12:58] <Chipaca> eep, the standup
[12:58]  * Chipaca runs
[13:05] <kjackal> hey snappy people, to use the "system-usernames:" I need snapd to be patched to be aware of the username?
[13:06] <Chipaca> kjackal: no, only one username is supported for now
[13:07] <Chipaca> kjackal: 1 sec, there's an explanation
[13:07] <zyga> ondra: nice work on https://github.com/snapcore/snapd/pull/7596
[13:08] <mup> PR #7596: overlord/snapstate: skip catalog refresh if unseeded <Simple 😃> <Created by kubiko> <https://github.com/snapcore/snapd/pull/7596>
[13:08] <Chipaca> kjackal: we're in phase 1, https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
[13:09] <Chipaca> kjackal: sorry, this: https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461/3?u=chipaca
[13:09] <Chipaca> phase 1 is described at the end of that comment
[13:11] <Chipaca> kjackal: i assume you've seen https://forum.snapcraft.io/t/system-usernames/13386 already
[13:11] <Chipaca> kjackal: which is also describing current, ie phase 1
[13:11] <kjackal> Chipaca: so there is only one user/group I can use, the "snap_daemon", right?
[13:11] <Chipaca> kjackal: at this stage, yes
[13:12] <kjackal> sounds good, let me try that
[13:13] <mup> PR 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:28] <zyga> and now I have an 1080p IPS display
[13:29] <zyga> :D
[13:29] <zyga> the difference is insane :D
[13:31] <diddledan> mine's bigger :-p
[13:31]  * zyga is very happy with what he has :)
[13:32] <Chipaca> diddledan: it's not how big it is, it's how much you giggle while using it
[13:32] <diddledan> haha. and that did make me giggle
[13:33]  * Chipaca rests his case
[13:33] <diddledan> giggle when you wiggle it :-)
[13:34] <diddledan> github actions really need better (more) examples
[13:36] <diddledan> 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] <diddledan> 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] <zyga> diddledan: I very much share this opinion
[13:38] <zyga> it's very annoying
[13:38] <zyga> I think travis used to have something like that
[13:38] <zyga> via their ruby command line tool
[13:38] <zyga> it'd let you run a job against your working directory
[13:38] <diddledan> it's not just travis though, none of them have anything like it
[13:41] <zyga> diddledan: did you see https://github.com/travis-ci/travis.rb
[13:44] <mup> PR snapcraft#2760 opened: remote-build: rebase onto master <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2760>
[13:46] <diddledan> interesting
[13:57] <ChrisTownsend> 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] <zyga> Chipaca: there's a bug about that
[13:57] <zyga> er
[13:57] <zyga> ChrisTownsend: ^
[13:58] <zyga> ChrisTownsend: sorry, tab completed incorrectly
[13:58] <zyga> ChrisTownsend: we need to look into it
[13:58] <ChrisTownsend> zyga: Ah, ok...no worries about tab completion:)
[13:58] <ChrisTownsend> zyga: Do you have the bug number handy?
[13:59] <zyga> https://bugs.launchpad.net/snapd/+bug/1848516
[13:59] <mup> Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:New> <https://launchpad.net/bugs/1848516>
[13:59] <ChrisTownsend> 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] <ChrisTownsend> zyga: Thanks for the link
[14:00] <zyga> ChrisTownsend: that part works okay but we need to fix the UX to match AFAIK
[14:00] <ChrisTownsend> zyga: Ok, great, thanks!
[14:06] <zyga> pstolowski: so do you have a moment
[14:06] <pstolowski> zyga: yes, but need a (late) lunch first
[14:07] <zyga> pstolowski: ok, please ping me later
[14:07] <pstolowski> zyga: sure
[14:07]  * zyga goes to play with the thinkpad for a moment
[14:16] <zyga> hmmm
[14:16] <zyga> https://www.irccloud.com/pastebin/E6MEZkwC/
[14:17] <zyga> is "command foo" equivalent to running /usr/bin/foo over alias/builtin?
[14:48] <zyga> mborzecki: around?
[14:48] <zyga> mborzecki, pstolowski: this is the emit PR: https://github.com/snapcore/snapd/pull/7639
[14:49] <mup> PR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
[14:49] <zyga> it puts enough indirection for the de-duplication PR to shrink
[14:49] <mup> PR snapd#7639 opened: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
[15:01] <pstolowski> zyga: ok, looking. how can i help with the remainder?
[15:01] <mup> PR snapd#7640 opened: snap-recovery: deploy gadget content when creating partitions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7640>
[15:03] <mup> PR 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:05] <zyga> pstolowski: re
[15:05] <zyga> so
[15:06] <zyga> pstolowski: please review https://github.com/snapcore/snapd/pull/7639
[15:06] <mup> PR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
[15:06] <zyga> this is the no-op part of the real fi
[15:06] <zyga> fix
[15:06] <zyga> so if it lands I can shrink the other PR to the real essence
[15:10] <zyga> pstolowski: for context on emit
[15:10] <zyga> pstolowski: it is used in the "big" PR where it is a thin wrapper around simply adding a de-duplicated snipper
[15:10] <zyga> snippet*
[15:14] <pstolowski> zyga: yes, looks like a good plan
[15:25] <Chipaca> zyga: did you check onlykey for CLA signature before +1'ing?
[15:25] <Chipaca> zyga: I don't think CLA is needed for the code so far, but fixing the test as well might push it over? dunno
[15:27] <pedronis> ijohnson: https://forum.snapcraft.io/t/systemctl-service-management-unification/13808/3
[15:35] <pstolowski> zyga: a bit of a general question there
[15:37]  * cachio lunch
[15:37] <zyga> Chipaca: no, because there's a CI part for it
[15:38] <zyga> pstolowski: looking
[15:38] <zyga> pstolowski: replied
[15:42] <zyga> pstolowski: replied again
[15:45] <pstolowski> zyga: where are these helpers tested? i grepped the code / looked for references, found nothing
[15:45] <Chipaca> zyga: that, when I added, I said should be checked for false-negatives of newcomers
[15:46] <Chipaca> or is that false-positives? either way, this is one of those cases
[15:46] <zyga> pstolowski: huh, you are right! they are no tested directly
[15:46] <zyga> they can be dropped
[15:46] <pstolowski> uff ;)
[15:46] <zyga> they are tested indirectly obviously but I thought we had a bunch of explicit tests as well
[15:47] <zyga> Chipaca: aha, I didn't know that
[15:47] <zyga> pstolowski: dropped now
[15:47] <zyga> thanks, that's a nice catch :)
[15:48] <zyga> Chipaca: I think it's false-sense-of-security then :)
[16:04] <zyga> pstolowski: do you plan to do any more reviews todayt/
[16:04] <zyga> pstolowski: if not I will EOD
[16:04] <zyga> pstolowski: and return here tomorrow
[16:05] <pstolowski> zyga: just added last comment
[16:07] <zyga> pstolowski: I tried to reply, perhaps we can HO quickly if you want to
[16:07] <zyga> though I won't mind to wait for tomorrow if you want to EOD
[16:08] <pstolowski> zyga: yep tomorrow, i need to leave soon, taking my daughter to horse club
[16:08] <zyga> pstolowski: cool! I'm sure she will love it
[16:08] <zyga> mvo: hey :) welcome back?
[16:08] <zyga> pstolowski: thank you, lets continue tomorrow morning
[16:08]  * zyga EODs
[16:08] <mvo> zyga: yeah, was back before but then network decided to stop working
[16:08] <pstolowski> zyga: it's weekly routine for a while already ;)
[16:08]  * zyga looks at shiny new thinkpad screen :)
[16:09] <zyga> pstolowski: my daughter is way more lazy
[16:09] <zyga> she only did it three times
[16:09] <zyga> mvo: the screen is gorgeous :)
[16:09] <pstolowski> zyga: horses 1x a week, football 2-3x a week :O
[16:09] <mvo> zyga: 1900x1200 ?
[16:09] <zyga> mvo: I won't bother you tonight, I have some PRs for review but I think it's time to stop
[16:09] <zyga> mvo: 1080p only
[16:10] <zyga> mvo: it's a panel that fits into the device but it's not sold with it originally
[16:10] <om26er> Can I use python 3.8 in my snap, is there a how-to for that ?
[16:10] <zyga> om26er: yes, if you build python3.8 it can be used there
[16:10] <zyga> I don't know if there's a tutorial for it
[16:10] <zyga> om26er: snapcraft may or may not help you with it a lot
[16:10] <zyga> om26er: but technically you can ship that snap to 14.04 tomorrow and it will work
[16:12] <om26er> I 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 size
[16:12] <om26er> https://bugs.python.org/issue33499
[16:12] <zyga> om26er: if you start with a part that builds 3.8 from scratch
[16:12] <zyga> om26er: add your app in a way that doesn't cause snapcraft to pull in all of python 3.7 for you again
[16:13] <zyga> om26er: in other words, yes, for sure, just more manually than otherwise snapcraft allows for
[16:13] <om26er> in 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] <om26er> zyga hmm, I will dig into this
[16:13] <zyga> om26er: good luck!
[16:13] <zyga> om26er: as you get that done you also gain independence and flexibility
[16:13] <zyga> om26er: you can optimize python
[16:13] <zyga> om26er: build some parts disabled
[16:14] <zyga> om26er: and go to 3.9 the day it is out
[16:14] <zyga> om26er: or you can follow fixes that you need
[16:14] <om26er> heh, I think 3.8 is what I need, no other requirements for now ;-)
[16:15] <om26er> OTOH: Can we use python 3.6 from core18 -- so we don't bundle our own copy of python ?
[16:15] <zyga> om26er: yes
[16:15] <zyga> om26er: again, I don't know if snapcraft makes that easy
[16:16]  * om26er adds that to "to dig" list :-)
[16:17] <om26er> Wimpress ping! you talked about trimming a Python based snap at Ubucon, can you share a snapcraft yaml that does that ?
[16:22] <ijohnson> pedronis: 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:31] <ijohnson> (I know Chipaca will review it as well, but just wondering if I should consider your comment as a +1)
[16:45] <Saviq> jdstrand: 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#L4750
[16:49] <zyga> Saviq: jdstrand is back tomorrow
[16:49] <Saviq> ack :)
[17:10] <pedronis> ijohnson: it's +1 assuming my expansion of your point seems to match what you had in mind
[17:11] <ijohnson> yes it matches
[17:11] <ijohnson> thanks pedronis
[17:15] <pedronis> ijohnson: 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 bit
[17:16] <pedronis> ijohnson: because it sound he needs start-snap-services to become a start --enable
[17:40] <ogra> om26er, 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:41] <ogra> 7me isnt sure thats actually worth the effort
[17:44] <ijohnson> pedronis: ack yes I will chat with him tomorrow
[18:44] <causasui> 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'. squashfs-tools and squashfuse are both installed & squashfs is in /proc/filesystems
[18:44] <causasui> have rebooted since install & last kernel update is loaded etc
[18:48] <mup> PR snapcraft#2760 closed: remote-build: rebase onto master <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2760>
[18:57] <ijohnson> hey causasui sorry we missed you earlier, do you see anything in dmesg when this happens?
[18:59] <causasui> ijohnson: messages about apparmor not being enabled but that wouldn't cause this I think? http://ix.io/1ZwJ there's a sample
[19:00] <ijohnson> causasui: what does `snap changes` show for you?
[19:02] <causasui> 1    Done    yesterday at 23:52 PDT  yesterday at 23:52 PDT  Initialize system state
[19:15] <mup> PR 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:22] <causasui> ijohnson: has this risen to the level of a forum / stackexchange post?
[19:22] <ijohnson> causasui: thanks for that, what is `snap version` for you?
[19:22] <causasui> ijohnson: 2.42-2 http://ix.io/1ZwR
[19:25] <ijohnson> causasui: can you run `snap download hello-world && mkdir test && sudo mount -o squashfs hello-world*.snap test` and see what happens?
[19:25] <ogra> causasui, grep squash /proc/filesystems
[19:25] <ijohnson> snap download doesn't currently go through snapd so that should work fine
[19:25] <ijohnson> ogra: he already has squash in /proc/filesystems
[19:25] <ogra> (see if your kernel doesnt accidentially miss squashfs)
[19:25] <ijohnson> s/he/they/ (sorry)
[19:25] <ogra> oh, ok
[19:26] <ogra> (right, i havent seen the first line above)
[19:26] <ijohnson> my best guess is this is some kine of kernel mount problem
[19:26] <ijohnson> s/kine/kind/
[19:26] <ogra> there was a bug in 5.2
[19:26] <ijohnson> can't type today for some reason
[19:26] <ijohnson> yeah they have 5.3.7
[19:27] <ogra> right
[19:27] <ogra> https://forum.snapcraft.io/t/mounts-broken-with-kernel-5-2/12272
[19:28] <ogra> probably the fix got lost with the newer update ?
[19:28] <ijohnson> yeah could be
[19:32] <causasui> ogra: it's there
[19:32] <causasui> ogra: squashfs in /proc/filesystems that is
[19:33] <causasui> ijohnson: 'he' is fine, thanks
[19:33] <causasui> :)
[19:33] <ijohnson> :-) don't want to assume
[19:33] <ijohnson> were you able to run that snippet above?
[19:34] <causasui> ijohnson: which?
[19:34] <ijohnson> causasui: can you run `snap download hello-world && mkdir test && sudo mount -o squashfs hello-world*.snap test` and see what happens?
[19:35] <causasui> mount: hello-world*.snaptest: can't find in /etc/fstab.
[19:35] <causasui> lul
[19:35] <causasui> what?
[19:36] <causasui> oh you forgot the mountpoint
[19:36] <mup> PR snapcraft#2761 opened: Core20 base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2761>
[19:37] <ijohnson> hmm copy paste error?
[19:37] <causasui> ah it wrapped
[19:38] <causasui> mount: /tmp/test: special device hello-world*.snaptest does not exist.
[19:38] <ogra> missing space
[19:38] <ogra>  sudo mount -o squashfs hello-world*.snap tes
[19:38] <ogra> bah
[19:38] <causasui> ah
[19:38] <ogra>  sudo mount -o squashfs hello-world*.snap test
[19:38] <causasui> mount: test/: mount failed: Operation not permitted.
[19:38] <causasui> odd
[19:38] <ijohnson> are you root?
[19:38] <ijohnson> or using sudo?
[19:39] <causasui> sudo
[19:39] <causasui> I'll try becoming root, why not
[19:40] <causasui> yeah same error as root
[19:40] <ijohnson> hmm, try `sudo strace -emount mount -o squashfs hello-world*.snap test` ?
[19:41] <zyga> causasui: if you are getting permission denied as root then there must be a LSM around you
[19:41] <zyga> causasui: or something is intercepting system calls for you
[19:41] <ogra> selinux ?
[19:41] <ogra> that would produce dmesg messages, no ?
[19:42] <ijohnson> does arch use selinux? I didn't think so
[19:42] <ogra> (or kern.log or whatever arch uses)
[19:42] <causasui> selinux is available but it takes some work to set up, based on the wiki. I for sure did not install it knowingly
[19:42] <ogra> yeah, unlikrly thats it then
[19:42] <ogra> *unlikely
[19:43] <ijohnson> causasui: is this perhaps some kind of container?
[19:43] <causasui> ijohnson: what is "this"? I thought snaps were containers
[19:43] <ogra> your archlinux ..
[19:43] <causasui> ogra: that's not obvious from the question, sorry. no, it's not
[19:43] <ijohnson> err sorry is your arch installation is it a container or a VM or something?
[19:43] <ogra> is it running indside a container
[19:43] <causasui> negative
[19:43] <ijohnson> hmm
[19:43] <ogra> anything in dmesg from your mount attempts ?
[19:44] <causasui> no new messages in dmesg
[19:44] <ogra> journald ?
[19:44] <zyga> dmesg may not contain anything related to LSMs if there's nothing collecting those from the kernel and turning them into log messages
[19:44] <zyga> e.g. auditd
[19:44] <ogra> sure, but always worth taking a look anyway
[19:45] <causasui> ogra: I don't see anything relevant in journalctl exept sudo logging the mount attempts themselves
[19:45] <ijohnson> at 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 mounts
[19:46] <ogra> do you have any opportunity to use an older kernel for a uick test ?
[19:46] <ijohnson> if 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 me
[19:47] <ogra> smells really similar to the forum post above about archs 5.2 kernel
[19:47] <ijohnson> yeah indeed
[19:47] <ogra> but there you had at least a few chatty error messages
[19:47] <ogra> silence in all logs is really weird
[20:00] <mup> PR snapcraft#2762 opened: appstream: extract title and version <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2762>
[20:17] <ijohnson> cachio: any chance you could review #7581 this afternoon?
[20:17] <mup> PR #7581: tests: add netplan test on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7581>
[20:18] <causasui> ijohnson: ogra: I assume the best venue is the one linked in the topic :) I'll type something up in there, thanks
[20:18] <ijohnson> sounds good to me
[20:22] <causasui> this is snapd not snapcraft right?
[20:24] <ijohnson> it's a snapd bug yes, but the official forum is forum.snapcraft.iot
[20:24] <ijohnson> err forum.snapcraft.io
[20:26] <cwayne> Aww man it should be .iot
[20:29] <ijohnson> that would be a cool TLD
[20:31] <causasui> ijohnson: yes but there are different tags in that forum
[20:31] <causasui> https://forum.snapcraft.io/t/cannot-mount-squashfs-image-using-squashfs-operation-not-permitted/13829
[20:31] <ijohnson> causasui: right snapd tag is correct
[20:32] <ijohnson> thanks, we'll make sure that our resident arch expert mborzecki takes a look tomorrow
[20:38] <cyphermox> cool
[20:38] <cyphermox> ijohnson: are there tests we can add to netplan too to check that things are sane?
[20:57] <ijohnson> cyphermox: what things need to be tested?
[20:57] <cyphermox> ijohnson: 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 facilitate
[21:09] <cachio> ijohnson, sure
[21:32] <ijohnson> cyphermox: 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:41] <cyphermox> ok :)


[04:52] <robru> vila, well I am EOW now so I won't be looking at this again until monday regardless of what happens.


[19:02] <tiagoscd> hi
[19:02] <tiagoscd> how I can request Ubuntu marketing items, like tablecloth and banners, to an approved loco team?


[06:03] -ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
[06:03] -ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there
[06:04] <fabbione> logs will be available from the next hours or so
[09:50] <DMTM> hello
[09:50] <DMTM> i would like to register my nickname
[10:12] <thom> why do people think upstart is a support channel?
[10:15] <DMTM> hmm
[10:15] <Md> because it's the first or last channel I joined, so stupid people use /who to look for staff members and then think it's a good idea to ask support questions in a random channel
[10:20] <DMTM> ok
[11:45] <LarstiQ> Md: smooth :)
[07:32] <Coldbyte> Md are you there
[07:32] <Coldbyte> ?
[10:20] <NthDegree> i'm using ubuntu edgy eft, and i'm having trouble sorting out a script to mount my dm-crypt loopback drive at boot
[10:20] <NthDegree> can someone help me with getting it added to the new upstart runlevels?


[09:11] <santa_> good morning everybody
[09:12] <santa_> RikMills: the _archive branches of frameworks are not updated, also, at least the _staging branch of plasma-workspace
[09:14] <RikMills> plasma-workspace is all up to date for me. nothing to push on any branch
[09:15] <RikMills> oh, doko did a rebuild......
[09:15] <RikMills> got gpsd library bump
[09:15] <RikMills> *for
[09:15] <santa_> ah, yes
[09:16] <santa_> nevermind these are the things I usually sync myself without bothering you
[09:16] <RikMills> pushing fw. sorry
[09:16] <santa_> yeah, fw was actually outdated
[09:16] <santa_> RikMills: ok if I sync plasma-workspace in git, or are you doing it?
[09:17] <RikMills> go ahead
[09:19] <santa_> done
[13:21] <BluesKaj> Hi folks


[01:42] <braddr> anyone awake with sparc32 abi experience?
[08:07] <fabbione> morning
[08:07] <fabbione> braddr: sparc32???
[08:32] <braddr> g'morning
[08:33] <braddr> hey, not everyone builds for 64bits all the time. :)
[08:34] <fabbione> what are you trying to build in 64bit?
[08:34] <braddr> I'm working on getting gdc working on solaris (the d language front end for gcc).  It mostly works.
[08:34] <braddr> the one are that doesn't 'work' is what I believe to be an abi difference between x86 and solaris
[08:35] <braddr> er.. s/solaris/sparc/
[08:35] <braddr> too used to solaris equating to sparc.
[08:36] <braddr> I haven't actually confirmed, but I believe gdc sticks with 32bit compilation for all platforms.  I should confirm that, but it's tangential to the problem I'm seeing.
[08:36] <braddr> lemee pull up a url
[08:36] <fabbione> hmm no, i can't help on slolaris
[08:36] <fabbione> i don't have enough experience in building crap over there
[08:37] <braddr> the problem is that an idiom that's become prevelant in D code is really really abusing an x86ism.
[08:37] <braddr> that doesn't hold true with other abi calling conventions.
[08:37] <braddr> http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/1778