[06:58] <mborzecki> morning
[06:59] <mvo> hey mborzecki
[06:59] <mvo> good morning
[06:59] <mborzecki> last day this year :)
[07:00] <mborzecki> mvo: are you aware of any documentation for snapd that might list kernel config options that we require?
[07:02] <mvo> mborzecki: yeah, last day!
[07:02] <mvo> mborzecki: I don't think we have such a list yet
[07:02] <mvo> mborzecki: sounds like a good forum topic
[07:02] <mvo> mborzecki: there is a "docs" tag in the forum
[07:03] <mborzecki> there's a guy right here, clearly having some issue with the kernel missing features that we need, https://forum.snapcraft.io/t/mount-of-core-failed-to-setup-loop-device/3267/8
[07:05] <mvo> mborzecki: yeah, just looked over this and indeed, he probably missed squashfs first and now cgroup freezer
[07:06] <mborzecki> i'm writing a reply, just wanted to double check if we have something i could point him to
[07:08]  * mvo nods
[07:24] <mup> Issue snapcraft#1827 opened: cross-compilation support for catkin plugin <Created by Timple> <https://github.com/snapcore/snapcraft/issue/1827>
[07:32] <mup> PR snapd#4420 opened: cmd: clarify "This leaves %s tracking %s." message <Created by mvo5> <https://github.com/snapcore/snapd/pull/4420>
[07:44] <mborzecki> hmm now i have 2 spotifys installed, so picking the icon from gnome dashboard i have no clue which one will start
[07:59] <mvo> mborzecki: yeah, thats annoying
[07:59] <mup> PR snapd#4421 opened: daemon: add new polkit action to manage interfaces <Created by mvo5> <https://github.com/snapcore/snapd/pull/4421>
[09:38] <mborzecki> mvo: on arch there's no locale set by default so it's C, we override it in tests and set it C.UTF-8 (which doesn't work btw), now if i do `LC_ALL=C snap info` i'll get utf-8 characters anyway (the arrow pointing upwards)
[09:39] <ikey> C.UTF-8 is a Debuntuism
[09:39] <ikey> Doesn't exist anywhere else
[09:39] <mborzecki> yup, we've discussed this :)
[09:40] <mborzecki> small patch on glibc side, but unlikely to hit arch unless upstream merges it
[09:40] <ikey> was it ever sent upstream? not tryna be funny just generally curious
[09:41] <ikey> i know gnu projects are terrible at responding to patches in general
[09:41] <mborzecki> ikey: https://sourceware.org/bugzilla/show_bug.cgi?id=17318
[09:41] <ikey> 3 years, not bad
[09:41] <ikey> i figured if it was it was maybe 4, in my head, lol
[09:41] <mborzecki> idk, glibc has become much more civlized since leadership change
[09:42] <ikey> glibc itself has yes, but GNU projects still have a certain way around them.. ^^
[09:42] <ikey> 'cept nano. nano is just cool
[09:42]  * ikey goes off to steal utf8 patch for solus
[09:42] <ikey> erm imean borrow
[09:43] <mborzecki> ikey: it's all free software after all, right? :)
[09:44] <ikey> indeed :D
[09:45] <mborzecki> anyways, i suppose we shouldn't output utf-8 unless the it's allowed by locale
[10:19] <mvo> mborzecki: yeah, this looks iffy, thanks for noticing
[10:31] <mup> Issue snapcraft#1693 closed: Develop metadata handler system <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1693>
[10:31] <mup> PR snapcraft#1825 closed: metadata: add infrastructure for extracting metadata from parts <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1825>
[10:34] <ikey> q: i see that the metadata can be extracted *from* appstream, but is the appstream raw data available separately somehow?
[10:34] <ikey> i.e. for software center integration and non broken screenshots
[10:55] <mup> Issue snapcraft#1828 opened: Support desktop and icon in appstream handler <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1828>
[11:16] <sergiusens> ikey that is a simpler part once the bike shedding on what to call the entry ends :-)
[11:16] <ikey> ah
[11:16] <sergiusens> so, maybe, it is the hardest part as it involves people :-P
[11:16] <ikey> yeaa
[11:17]  * sergiusens goes off to run some errands
[12:04] <mup> PR snapd#4422 opened: packaging/arch: disable services when removing <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4422>
[12:04] <mvo> mborzecki: slightly sad that the last two PRs are unhappy again
[12:04] <mborzecki> mvo: which ones?
[12:04] <mvo> mborzecki: my last two, one looks real, so my fault but one had a spurious test failure. oh well
[12:04] <mvo> mborzecki: but things in general are better, its just a single failure at least :)
[12:05] <mvo> mborzecki: thanks for spotting the extra whitespace btw
[12:05] <mborzecki> nothing compared to what we had with debian sid :)
[12:05] <mborzecki> sure
[12:06] <mborzecki> fwiw, i think it'd be nice to renable debian sid at some point, it's possible that we were causing the instability after all :P
[12:08] <mvo> mborzecki: yeah, definitely, we need to investigate that
[12:08] <mvo> mborzecki: its also likely that real users on sid have problems :(
[12:08] <mvo> mborzecki: but then, sid is by nature unstable but still
[12:08] <mborzecki> 'real users', you mean debian devs? :D
[12:08] <mvo> lol
[12:09] <mvo> *cough* yes
[13:35] <mborzecki> mvo: #4404 selinux PR that i mentioned
[13:35] <mup> PR #4404: data/selinux: allow messages from policykit <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4404>
[13:37] <mup> Issue snapcraft#1694 closed: Develop appstream handler <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1694>
[13:37] <mup> PR snapcraft#1826 closed: extractors: support appstream metadata in parts <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1826>
[13:41] <mborzecki> mvo: the exact forum topic is https://forum.snapcraft.io/t/selinux-blocking-snapd-since-update-on-fedora-27/3002 shall I tag it?
[13:54]  * sergiusens waves again
[13:58] <mvo> mborzecki: thanks, I cherry-pick it
[13:58] <mborzecki> mvo: great
[14:02] <mvo> mborzecki: cherry-picked, thanks for the reminder
[14:02] <mborzecki> sure
[14:07]  * Son_Goku hopes that now people other than him will actually help fix snapd-selinux things
[14:08] <ikey> people use selinux?
[14:08] <ikey> *runs*
[14:10] <mup> PR snapd#4423 opened: snap: provide more meaningful errors for installMany and friends <Created by mvo5> <https://github.com/snapcore/snapd/pull/4423>
[14:11] <ikey> i meant *merry christmas
[14:11] <ikey> common typo
[14:15] <Son_Goku> ikey: your sarcasm is noted and ignored
[14:16] <Son_Goku> it's not quite Christmas yet, so Happy Holidays :)
[14:16] <ikey> i expected no less :P
[14:16] <ikey> yep. merry christmas. :)
[14:16] <ikey> ( :P )
[14:16]  * ikey doesn't buy into the happy holidays thing
[14:16] <Son_Goku> well, technically we're in Hanukkah right now
[14:16] <ikey> oh right
[14:16] <ikey> happy harmonica
[14:16] <Son_Goku> :D
[14:16]  * ikey is cultured
[14:16]  * mvo is impressed
[14:17] <Son_Goku> at one point, I've celebrated both
[14:17] <ikey> oh cool
[14:17] <Son_Goku> used to hang out with a Jewish family a lot as a kid
[14:17] <Son_Goku> so we did both
[14:17] <ikey> ah
[14:17] <Son_Goku> my family isn't Christian (not too surprising), so we were okay with doing both
[14:17] <ikey> irish catholic family so we had a different approach altogether
[14:18] <ikey> if something went wrong it was probably our fault and thats why god doesnt love us :P
[14:18] <Son_Goku> ...
[14:18] <Son_Goku> that's, terrifying
[14:18] <ikey> hey we got chocolates
[14:18] <ikey> was worth it
[14:18] <ikey> xD
[14:19] <Son_Goku> heh
[14:19] <ikey> besides, it didn't have any lasting effects
[14:19]  * ikey settles the eye twitch
[14:19] <Son_Goku> you know, I'm not so sure...
[14:19] <ikey> lmao
[14:25] <mborzecki> Son_Goku: fwiw, i'll do what i can on the snapd-selinux front :)
[14:26] <Son_Goku> the only other thing I hope for is someone to implement an selinux backend for the snappy security rules HLL
[14:28] <oSoMoN> I’ve finally taken the time to rename the play0ad snap to "0ad", now that this is a valid name, wondering if there's a mechanism in place to transition existing users to the new snap?
[15:04] <mup> PR snapcraft#1829 opened: pluginhandler: warn the inclusion of libraries from the host <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1829>
[15:22] <sergiusens> ikey don't buy into the happy holidays or the happy part of it? :-)
[15:23] <ikey> the not saying christmas part of it
[15:24] <sergiusens> ah, yeah, over here it's around 40 Celsius, the vibe is totally different than in the north
[15:25]  * sergiusens just realized that George R. R. might have had a vision; if that wall gets built and we see the "Day after tomorrow" happen; will there be white walkers?
[15:31] <Son_Goku> ikey: when it's actually Christmas, I'll say "Merry Christmas" :)
[15:31] <Son_Goku> but as most people I know aren't Jewish, Happy Hanukkah doesn't quite work and some people get offended
[15:32] <mborzecki> ok, i'm done for today and this year :) enjoy your holidays, see you around in 2018
[15:33] <mvo> mborzecki: thank you! enjoy the holidays
[15:33] <mup> PR snapd#4424 opened: corecfg: pam_env can only handle 1024 byte <Created by mvo5> <https://github.com/snapcore/snapd/pull/4424>
[15:58] <mup> PR snapd#4425 opened: config: add support for `snap set core proxy.no_proxy=...` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4425>
[16:07] <mvo> popey: if you are still around, I'm trying to reproduce the xdg-open from classic snap crash currently, do you know if we have any electron classic snap in the store that I can try?
[16:10] <popey> mvo: hmm. flexiondotorg might have a better list...
[16:12] <mvo> popey: thanks, I tried with electron-quick-start but when I create a link there it uses the internal browser, it does not luanch anything external
[16:13] <cachio> mvo, in opensuse it is happening that if I remove and install the snapd.rpm then the snapd.service is not started automatically
[16:14] <cachio> and it is making hte test snap-set-core-w-no-core to fail
[16:14] <mvo> cachio: oh, that is strange. maybe morphis knows more, iirc he did the initial opensuse packaging. or zyga
[16:15] <cachio> mvo, sure, thanks
[16:22] <popey> mvo: i might have a private snap I could share with you which exhibits the issue?
[16:22] <mvo> popey: sure, that would work
[16:22] <flexiondotorg> mvo popey I've fixed most of the classic Electron snaps in the store.
[16:23] <mvo> flexiondotorg: oh? what did that involve?
[16:24] <mvo> flexiondotorg: fwiw, context is https://bugs.launchpad.net/snapd/+bug/1736925
[16:24] <mup> Bug #1736925: SIGSEGV while calling xdg-open from classic snap of Electron application <snapd:Incomplete> <https://launchpad.net/bugs/1736925>
[16:26] <popey> flexiondotorg: even the one where the voip client would crash on loading firefox?
[16:28] <popey> mvo: answered https://bugs.launchpad.net/snapd/+bug/1736939
[16:28] <mup> Bug #1736939: Classic snaps do not work on some Linux distros <snapd:Incomplete> <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1736939>
[16:28] <popey> it's not missing /snap
[16:31] <Son_Goku> it doesn't matter because classic snaps won't work anyway
[16:31] <Son_Goku> even if the redirections are working, they'll fail due to ABI incompat
[16:32] <Son_Goku> there are several issues that the snapcraft guys and I noticed about classic snaps leaking and pulling stuff from the host libraries instead of the base snap
[16:32] <Son_Goku> it also broke classic snaps with Ubuntu 17.10 too, if I remember correctly
[16:33] <Son_Goku> popey: and this is why I don't *ever* suggest making classic snaps work in Fedora
[16:33] <Son_Goku> the whole classic snaps thing is fundamentally broken
[16:33] <popey> Ok :)
[16:34] <Son_Goku> there a bunch of things that need to change to make classic snaps saner, but unfortunately, as niemeyer and I discussed it a while back, it's pretty hard to fix
[16:34] <flexiondotorg> popey: Yes, the voip client opening the browser is fixed by using snapcraft 2.30 from the beta channel. Confirmed upstream.
[16:35] <flexiondotorg> Son_Goku: The issue you describe should be resolved with snapcraft 2.30, which is currently in the beta channel.
[16:35] <Son_Goku> but most snaps aren't built with it
[16:36] <flexiondotorg> Right, but we are contacting the publishers who are affected.
[16:36] <flexiondotorg> Many are already fixed in the store.
[16:38] <mup> PR snapcraft#1829 closed: pluginhandler: warn the inclusion of libraries from the host <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1829>
[16:42] <mvo> flexiondotorg: \o/ for fixing the world!
[16:43] <flexiondotorg> mvo: Thank sergiusens :-)
[16:43]  * mvo hugs sergiusens 
[16:43] <sergiusens> hey, glad to help! meta-team effort as always though! :-)
[16:44] <mup> Issue snapcraft#1827 closed: cross-compilation support for catkin plugin <Created by Timple> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1827>
[16:50] <kyrofa> cprov, any chance you're around?
[16:51] <kyrofa> cprov, unping. Got it
[16:52] <kyrofa> Although cprov, the time returned from acl/verify does not seem to have timezone information in it
[17:00] <flexiondotorg> sergiusens: What snapcraft LP bug actually closes this? - https://bugs.launchpad.net/snapd/+bug/1736925
[17:00] <mup> Bug #1736925: SIGSEGV while calling xdg-open from classic snap of Electron application <snapd:Incomplete> <https://launchpad.net/bugs/1736925>
[17:06] <mup> PR snapd#4426 opened: snap: print friendly message if `snap keys` is empty <Created by mvo5> <https://github.com/snapcore/snapd/pull/4426>
[17:08] <mup> PR snapcraft#1830 opened: Release changelog for 2.38 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1830>
[18:38] <mup> PR snapcraft#1831 opened: cli: add expiration option to export-login <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1831>
[18:47] <mup> PR snapcraft#1830 closed: Release changelog for 2.38 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1830>
[19:28] <sergiusens> ikey by any chance do you know of any cli project using appstream?
[19:46] <Son_Goku> sergiusens: there's a few web projects that use it
[19:47] <Son_Goku> off the top of my head, while AppStream supports console apps, GNOME Software and Plasma Discover will exclude all of them from the view or search
[19:54] <cmiles74> I have snapd running and it'll download and mount snaps, the mount unit files appear in systemd and systemd returns their status correctly. Still, I'm seeing an error "Mount snap 'core' (3604) (internal error: could not unmarshal state entry 'snap-type': invalid snap type '')". Does anyone know what might be causing the issue? I'm on kernel 4.9.70; I am seeing complains from snapd at startup about apparmor
[19:54] <cmiles74> being enabled but some features are missing (dbus, mount, namespaces, network, ptrace, signal).
[19:54] <kyrofa> cmiles74, I always get that until I reboot at least once after creating a lxd container
[19:55] <cmiles74> kyrofa: Thank you, that is easy to test! :-D
[19:55] <kyrofa> Not sure what the issue is, but something doesn't get setup until I reboot
[19:55] <kyrofa> cmiles74, I'm crossing my fingers for you!
[19:56] <cmiles74> kyrofa: I have a pretty non-standard setup, I'm working on the NixOS module. My expectations are... low.
[19:56] <kyrofa> cmiles74, hey, pretty awesome progress though
[19:56] <cmiles74> kyrofa: Thank you for the encouragement. :-)
[20:13] <jjohansen> cmiles74: what kernel are you using?
[21:32] <cmiles74> jjohansen: kernel 4.9.70. Do you know if that's too old?
[21:35] <jjohansen> cmiles74: so not too old on an ubuntu kernel but
[21:35] <jjohansen> the namespaces stuff primarily landed in upstream 4.10 and 4.11
[21:35] <jjohansen> ptrace in 4.13
[21:35] <jjohansen> mount and signal in 4.14
[21:35] <jjohansen> unfortunately there were issues with network and dbus stuff in 4.14 so that part got reverted and we are trying again for 4.16
[21:39] <cmiles74> jjohansen: Thank you. I'll try moving up to 4.14.7 and see if that makes a difference... I think there's a 4.15-rc1 package as well.
[22:02] <mup> Bug #1738295 changed: snap auto-refresh re-installs removed snaps <Snappy:Invalid> <https://launchpad.net/bugs/1738295>