[00:00] <zyga> kyrofa: look at the wiki link above
[00:00] <zyga> kyrofa: that's the accurate state of the packaging support
[00:00] <zyga> kyrofa: I think only ubuntu and debian are up-to-date and maintained
[00:00] <zyga> kyrofa: everyting else is not
[00:06] <kyrofa> zyga, that works, thanks
[00:45] <mup> Bug #1660865 opened: [interface] hardware-observe should allow broader access to  /proc/bus/pci <Snappy:New> <https://launchpad.net/bugs/1660865>
[01:41] <HumbleBeaver> odysseywestra anyone get around to you?
[01:41] <HumbleBeaver> sorry it took so long to get back
[01:43] <HumbleBeaver> I took a look at your project, I think it will pretty easy to snap. Is there a step you are confused about?
[01:55] <bso> Hi I would like to ask if I can install avahi-daemon on Ubuntu Core.
[01:56] <bso> On Ubuntu Desktop, I can install by "sudo apt install avahi-daemon".
[01:57] <bso> On Ubuntu Core, "snap find avahi" returned 0 snaps.
[01:57] <bso> So, I installed the classic snap.
[01:58] <bso> On the classic prompt, I tried to install avahi-daemon with "sudo apt install avahi-daemon", but it seems it failed.
[01:58] <bso> I saw the following message at the end of installation.
[01:58] <bso> invoke-rc.d: policy-rc.d denied execution of force-reload. invoke-rc.d: policy-rc.d denied execution of start.
[01:59] <bso> So, it seems it failed to install avahi-daemon.
[01:59] <bso> Does anybody know why I can't install this package on classic snap?
[02:53] <odysseywestra> HumbleBeaver: Basically, how to put it together really. Maybe it would help If I could see what other have done?
[03:01] <bso> Does anybody know how to install avahi-daemon on Ubuntu Core?
[03:07] <HumbleBeaver> odysseywestra, thats basically how I got started,
[03:07] <HumbleBeaver> the snapcraft.yaml file is stupid easy once you get over the initial "now what" about it.
[03:10] <HumbleBeaver> odysseywestra http://paste.ubuntu.com/23903144/ <--this is one I got help with here today, by mhall119 and jstrand
[03:12] <HumbleBeaver> odysseywestra http://paste.ubuntu.com/23903151/ <--heres one I'm still messing around with its probably closer to what you need.
[03:12] <HumbleBeaver> Note the source is a git repository.
[03:16] <odysseywestra> okay. I'll take a look at those, and go from there. I'll show you what i have in a bit. Thanks for giving me a starting point.
[03:19] <mup> Bug #1660879 opened: snap refresh with more than one argument produces poor error message <Snappy:New> <https://launchpad.net/bugs/1660879>
[04:02] <bso> ping
[04:02] <bso> Anybody used avahi on Ubuntu Core?
[05:43] <olympionex> does anyone know if there is a bug that prevents the classic flag from functioning in 'try' mode.  I'm using version 2.20.1ubuntu1 on 16.04 and it seems to ignore the classic flag
[05:45] <olympionex> same on 2.21
[06:18] <mup> PR snapcraft#1097 opened: lifecycle: print the command needed to clean the dirty part <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1097>
[07:45] <zyga> olympionex: yex, it was already fixed in master AFAIK
[07:46] <zyga> olympionex: I think that you can switch to edge (snap refresh --edge core) to use nightly builds on your machine (even on classic :-)
[07:46] <zyga> olympionex: (classic distro)
[07:46] <zyga> olympionex: and this bug, I believe, is gone there
[07:46] <zyga> olympionex: for more on this please ask chipaca
[07:46] <zyga> olympionex: he should be around in a few hours
[07:55] <olympionex> zyga: thanks very much!
[08:55] <mup> PR snapd#2724 closed: overlord,tests: have enable/disable affect security profiles <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2724>
[08:58] <mup> PR snapd#2754 opened: tests: improve debug when the core transition test hangs <Created by mvo5> <https://github.com/snapcore/snapd/pull/2754>
[09:33] <mup> PR snapd#2727 closed: overlord/ifacestate: register all security backends with the repository <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2727>
[09:33] <mup> PR snapd#2755 opened: interfaces: port the mount backend to new APIs while retaining snippets <Created by zyga> <https://github.com/snapcore/snapd/pull/2755>
[09:43] <core-snappy> Do we have support for ubuntu 16.04 on dell gateway 5000
[09:43] <core-snappy> can I upgrade from 15.04 to 16 ubuntu core
[09:54] <mup> PR snapcraft#1094 closed: core: switch to using rpath for clasic confinement <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1094>
[09:57] <mup> PR snapcraft#1092 closed: meta: properly get the icon extension from splitted name <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1092>
[10:00] <mup> PR snapcraft#1086 closed: print snapcraft's version on startup when running with --debug <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1086>
[10:21] <timp> is it possible with snap to compile different versions of binaries to have an optimized version for different CPU generations?
[10:22] <mcphail> timp: I don't know if the automatic snapcraft building can do that, but you can certainly hand-roll a snap to meet those requirements. Sounds like a lot of work for ? how much reward, though!
[10:23] <timp> would I then include different binaries inside a single snap? Or can different snap packages be selected depending on the CPU? (not just the architecture, but also the generation)
[10:24] <timp> I'm asking for a project that is meant for scientific computations. Doing eigen analysis and such. The reward there can be big, because the computations for full datasets can take hours
[10:24] <mcphail> I'm not sure of the latter option, but you could certainly pack multiple binaries in a single snap and have a wrapper script pick the correct one
[10:26] <mcphail> I don't know how easy it would be to automate, though, as I don't know if confinement would give you access to /proc/cpuinfo (or similar) to autodetect
[10:27] <zyga> timp: you can do that inside your snap
[10:27] <timp> right. Sounds like a bit of a hassle though.
[10:28] <zyga> timp: one binary that uses appropriate function based on the cpu
[10:28] <zyga> timp: this is a gcc feature
[10:28] <zyga> timp: and it should be pretty easy to use
[10:28] <timp> ah, that sounds cool.
[10:28] <timp> I got the question here http://community.mrtrix.org/t/provide-mrtrix3-as-a-snap-package-for-linux/687/2
[10:28] <zyga> timp: so that one binary will work good everywhere
[10:28] <zyga> timp: https://gcc.gnu.org/wiki/FunctionMultiVersioning
[10:28] <zyga> timp: try that, good luck :)
[10:28] <timp> in particular they want to use the -march=native flag.
[10:29] <timp> thanks for the info :)
[10:29] <zyga> timp: well, that particular flag is pretty pointless
[10:29] <zyga> timp: as the resulting snap will be optimized for whoever builds it
[10:30] <zyga> timp: for binary packages that's the totally wrong way to go
[10:30] <timp> right, that's why they provide sources now instead of binary packages
[10:30] <zyga> timp: I think that with this gcc feature you can deliver performant binaries anywhere
[10:32] <timp> I will propose that to them.
[10:33] <timp> I would say that is good enough for binaries. And the source will anyway be available for people who want to compile it themselves.
[10:39] <mup> PR snapcraft#1096 closed: schema,copy plugin: better errors when item has no value <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1096>
[10:52] <Hanonim> Hi folks !
[10:52] <Hanonim> Does anyone have experience running Snappy on a raspberry? :)
[10:54] <jamiebennett> Hanonim: yes, classic Ubuntu or Ubuntu Core?
[11:01] <Hanonim> jamiebennett: Ubuntu Core
[11:02] <Hanonim> jamiebennett: I'm new to snaps so I'm at that stage where it's quite frustrating not to have apt
[11:03] <Hanonim> My first question is this one : is it possible to use wiringpi on snappy core ? I've searched a lot and the one thing i found show it's quite impossible (or really hard?)
[11:04] <ogra_> you can surely use it inside a snap
[11:04] <ogra_> snap interfaces exposes all GPIOs, you just need to connect the interface as needed and wiringpi should be able to manage it
[11:05] <Hanonim> ogra_: is there a proper tutorial somewhere ?
[11:05] <ogra_> the interfaces are named after http://pinout.xyz/#
[11:05] <ogra_> i sthink http://snapcraft.io should have everything teaching you how to roll a snap and use interfaces with it
[11:06] <ogra_> (if you run into issues, just ask here :) )
[11:06] <ogra_> also https://docs.ubuntu.com/core/en/ ...
[11:06] <Hanonim> ogra_: ok, i better study it better. now, my goal is to run a java app using pi4j, do you think it is "snapable" ?  raspbian can run my stuff
[11:07] <ogra_> sure ...
[11:07] <ogra_> you might need to tweak some paths etc to make it work in the snap context, but if it runs on raspbian it will run on core too
[11:08] <Hanonim> ok well, i'll come back if i'm stuck
[11:08] <Hanonim> thanks very much for your help !
[11:09] <ogra_> that is why we are here ;)
[11:11] <Hanonim> a somewhat "simpler" solution might be to install ubuntu server, but then there is not support for the GPIOs, is there ?
[11:20] <ogra_> Hanonim, i dont know i must admit ... you have to try :)
[11:20]  * ogra_ hasnt used classic installs on Pi in a long time
[11:22] <Hanonim> ogra_: the issue i see is that wiringpi writes to /dev/mem which is, i beleive, read-only in snappy core. is it the kind of problems snapcraft resolves ?
[11:24] <ogra_> snapcraft just helps you to roll a snap ... device access is managed through interfaces ...
[11:24] <ogra_> (the second link i gave above describs the security system and interfaces)
[11:29] <Hanonim> okay, i'll study it and stop asking too much questions :)
[11:35] <Hanonim> i'm surprised there is almost nothing on how to use gpios/pi4j on snappy core, i expected it to be a hot topic
[11:41] <zyga> Pharaoh_Atem: ouch on gitlab
[11:41] <zyga> Pharaoh_Atem: do you have the repo of the policy somewhere?
[12:13] <mup> PR snapd#2756 opened: snapctl: add config in client to disable auth and use it in snapctl <Created by mvo5> <https://github.com/snapcore/snapd/pull/2756>
[12:26] <mup> Bug #1660957 opened: Need a way to get aa_is_enabled() and aa_query_label() to function <Snappy:New> <https://launchpad.net/bugs/1660957>
[12:31] <Son_Goku> zyga, the repo is fine
[12:31] <Son_Goku> I can push it elsewhere, yes
[12:33] <Son_Goku> zyga, do you need it now?
[12:44] <zyga> Son_Goku: it would be good to keep it safe
[12:45] <zyga> Son_Goku: just worried that gitlab will go belly up
[12:45] <Son_Goku> they're in the middle of recovery right now: https://www.youtube.com/watch?v=nc0hPGerSd4
[12:46] <zyga> Son_Goku: wow, nice that they do it live
[12:47] <zyga> Son_Goku: but pretty terrible with the defunct backups and rm -rf mistake :/
[12:47] <Son_Goku> that was pretty damn unlucky, yeah
[12:47] <Son_Goku> https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
[12:47] <zyga> I read the report
[12:48] <zyga> the used space graph is depressing
[12:48] <zyga> rm -rf /internet
[12:48] <zyga> nohup ;)
[12:48] <Son_Goku> yep
[13:33] <Son_Goku> mvo: woo!
[13:33] <Hanonim> i'm confused ! in this video
[13:33] <Hanonim> https://www.youtube.com/watch?v=VbDAvTEBxew
[13:33] <mvo> hey Son_Goku! in a meeting right now, but I will read backlog and reply async :)
[13:34] <Hanonim> it's not ubuntu snappy core, it's ubuntu server ?
[13:34] <Hanonim> he uses apt and everything
[13:34] <Son_Goku> yeah, he's not using snappy core
[13:34] <Son_Goku> that stuff doesn't work there
[14:03] <zioproto> hello there, I have a problem pushing to the store staff with classic confinement. Can I get help here ?
[14:04] <zioproto> https://myapps.developer.ubuntu.com/dev/click-apps/6815/
[14:23] <mup> PR snapd#2757 opened: tests: add regression spread test for #1660941 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2757>
[14:33] <Hanonim> This list of interfaces :
[14:33] <Hanonim> http://snapcraft.io/docs/reference/interfaces
[14:33] <Hanonim> shows "gpio" and "i2c" interfaces
[14:33] <Hanonim> on my raspberry pi 2 i only see "io-ports-control", which is not referenced
[14:34] <Hanonim> is there a link between gpio and i2c provided by the RPI and the io-ports-control interface ?
[14:35] <ogra_> Hanonim, http://paste.ubuntu.com/23905508/
[14:35] <ogra_> this is only in the edge channel builds currently though ... but shoudl migrate to stable eventually
[14:36] <roadmr> jdstrand: hello! hey, we got hit by malformed 'name': '00-test-snap-build' lint-snap-v2_name_valid
[14:37] <ogra_> daily edge builds can be found here http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
[14:37] <ogra_> the interface names follow http://pinout.xyz/#
[14:37] <roadmr> jdstrand: (but the store allowed the name registration and as far as some knowldgeable people think, it should be a valid snap name. Do you recall the status of converging on one snap name regex to rule them all?
[14:37] <Hanonim> ogra_: nice, too bad it's not fully stable. what about i2c ?
[14:38] <Hanonim> what does io-ports-control do ? i can't find info
[14:38] <ogra_> in the works
[14:38] <ogra_> i think morphis knows about io-ports ... likely nothing you want to use
[14:38] <ogra_> iirc thats some legacy thing
[14:41] <Hanonim> ogra_: hmmm, for now i'm a bit disappointed with the current state of affair. i might keep using raspbian unfortunately
[14:42] <ogra_> Hanonim, well, come back eventually :) it is constantly improving ...
[14:42] <ogra_> (and has many advantages over an apt based system ... )
[14:43] <Hanonim> ogra_: yes, the idea is really good, just too restrictive right now (at least for my projets)
[14:44] <ogra_> restrictive but secure :)
[14:44] <roadmr> jdstrand: I have the regex that snapd is supposedly using and it allows the name I posted, so maybe the tools need to update the regex they use? let me know and I can share it
[14:44] <ogra_> your devices wont be conquered by a botnet :)
[14:44] <roadmr> ... yet :)
[14:44] <ogra_> and reliable ... it is nearly impossible to break it
[14:45] <ogra_> roadmr, pessimist :P
[14:45] <Hanonim> ogra_: yup, and documentation will help. for instance, i can't even find one example on how to create a java snap. maybe i didn't look properly
[14:46] <ogra_> Hanonim, https://github.com/ogra1/jtiledownloader ... thats a desktop app though
[14:46] <ogra_> but headless apps wont be much different to package
[14:47] <jdstrand> roadmr: we should be using the same snapd regex as snapd now. Did snapd change?
[14:47] <roadmr> jdstrand: maybe! the regex is this ^(?:[a-z0-9]+-?)*[a-z](?:-?[a-z0-9])*$
[14:47] <Hanonim> thanks
[14:48] <roadmr> jdstrand: (I don't follow snapd that closely, my report is mainly about what the package submitter observed with that name)
[14:49] <jdstrand> this is what the review tools use: ^[a-z](?:-?[a-z0-9])*$
[14:49] <jdstrand> let me check snapd
[14:50] <roadmr> jdstrand: yes, your regex doesn't like the name I reported, while the one I gave, which should be snapd's, does
[14:50] <jdstrand> snapd is using: var validSnapName = regexp.MustCompile("^(?:[a-z0-9]+-?)*[a-z](?:-?[a-z0-9])*$")
[14:51] <jdstrand> it looks like they changed
[14:51] <roadmr> jdstrand: /o\
[14:51] <jdstrand> I'll adjust the tools
[14:51] <roadmr> thanks jdstrand!
[14:52] <jdstrand> yeah, it changed in 88665e9a
[14:54] <roadmr> jdstrand: oh! yes, that's about when we had that discussion on names, I think.
[14:54] <roadmr> (early sept 2016)
[14:55] <jdstrand> roadmr: this has been an ongoing conversation, cause I distinctly remember updating the tools to have precisely what snapd has. In fact, before 88665e9a, snapd used ^[a-z](?:-?[a-z0-9])*$ (the same as the tools)
[14:55] <jdstrand> regardless, fixing it
[14:57] <roadmr> jdstrand: thanks!
[14:57] <roadmr> jdstrand: sorry it took so long to find this discrepancy and alerting you in such an indirect way :(
[14:58] <jdstrand> it's fine. I'll have a fix in just a moment
[14:58] <roadmr> many thanks :)
[15:03] <jdstrand> roadmr: can you pull r835?
[15:03] <roadmr> jdstrand: sure, coming up
[15:08] <Kaleo> jdstrand, hey, (I think it's you I should ask), can you approve uploads #39, #40 and #41 of the ubuntu-terminal-app snap? it's
[15:09] <zyga> jdstrand: hey
[15:10] <zyga> jdstrand: going through the apparmor issue, trying to wrap my head around what is going on
[15:10] <zyga> jdstrand: no luck yet but I'm trying more thigs
[15:10] <zyga> jdstrand: I replied on the stpcpy branch, not sure if you replied back yet
[15:17] <jdstrand> zyga: I saw and I did. bummer on reproducing
[15:18] <jdstrand> zyga: I'm having the fun time of debugging an intermittent spread failure. I run it from here. fine. from travis, fail
[15:19] <jdstrand> at least got some nice debugging improvements for snap-confine out of it
[15:19] <jdstrand> snap-confine testsuite*
[15:20] <zyga> jdstrand: when you ran it locally, which spread version did you use?
[15:20] <zyga> jdstrand: fgimenez found some issues in how some of the tests are ran that would explain some of the failures we saw (e.g. no core snap)
[15:21] <zyga> jdstrand: there was a new release of spread lately, perhaps upgrade to see if this is consistent with what you see on linode
[15:21] <jdstrand> I may be out of date. thanks for the tip
[15:21] <fgimenez> jdstrand, zyga hopefully will be fixed very soon
[15:24] <zyga> jdstrand: HA
[15:24] <zyga> jdstrand: I just got a super trivial way to reproduce this :)
[15:24] <zyga> jdstrand: snap install snapd-hacker-toolbelt --devmode
[15:24] <jdstrand> zyga: nice! :)
[15:24] <zyga> jdstrand: snapd-hacker-toolbelt.busybox sh
[15:25] <stokachu> nessita, am i not supposed to be able to see my conjure-up package in the snap store?
[15:25] <zyga> jdstrand: nsenter -m/proc/1/ns/mnt
[15:25] <zyga> jdstrand: this gives me the following error in syslog:
[15:25] <zyga> jdstrand: Feb 01 16:25:13 xenial-server audit[22275]: AVC apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.snapd-hacker-toolbelt.busybox//null-/usr/bin/nsenter" name="" pid=22275 comm="nsenter" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[15:26] <zyga> jdstrand: I'll adjust the test case to simplfy this
[15:26] <zyga> jjohansen: ^^ if this helps you to have a look as well
[15:26] <zyga> jdstrand, jjohansen: (above please prefix Feb 01 16:25:13 xenial-server audit[22275]: AVC apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.snapd-hacker-toolbelt.busybox//null-/usr/bin/nsenter" name="" pid=22275 comm="nsenter" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[15:26] <zyga> er
[15:26] <zyga> jdstrand, jjohansen: above please prefix snapd-hacker-toolbelt.busybox sh with sudo
[15:27] <nessita> stokachu, checking, one sec
[15:28] <zyga> jdstrand: this essentially takes my patch out of the loop
[15:28] <zyga> jdstrand: as it is simply nsenter that fails
[15:28] <zyga> jdstrand: and the snap is installed in devmode so apparmor should be in complain mode
[15:28] <zyga> jdstrand: and snap-confine is out of the way (after setting up the namespace initially)
[15:28] <zyga> jdstrand: and also its apparmor profile is out of the way
[15:29] <stokachu> nessita, thanks, i just tested an upload and it seems to be going through
[15:29] <jdstrand> zyga: note that apparmor is really out of the way if it is in complain mode. please give your finding to jjohansen
[15:29] <jdstrand> (there could be a complain mode bug)
[15:29] <nessita> stokachu, how are you uploading?
[15:29] <nessita> because I don't see you being defined as collaborator, which is weird
[15:29] <stokachu> nessita, snapcraft push ./conjure-up_2.1.0_amd64.snap --release edge
[15:30] <stokachu> nessita, it's still uploading so it may complain
[15:30] <zyga> jdstrand: it is! (snap install with --devmode)
[15:30] <nessita> stokachu, let me know how that does please
[15:30] <zyga> jdstrand: yeah, I'll prep a mail
[15:30] <nessita> goes*
[15:30] <zyga> oh, need to run to pick up kids from school
[15:30] <jdstrand> zyga: I'm saying that just cause it is in devmode doesn't mean that an apparmor complain mode bug isn't causing trouble
[15:32] <stokachu> nessita, http://paste.ubuntu.com/23905726/ did show an error
[15:34] <nessita> stokachu, asking for some advice, one sec
[15:34] <stokachu> nessita, ok ty!
[15:35] <sitter> heya, zyga, kyrofa: any tips on how I would go about running the xdg-open shim from ubuntu-core? the way I see it a snap would have no way to get ahold of ubuntu-core stuff given http://snapcraft.io/docs/reference/env
[15:38] <sergiusens> sitter: I get to open just fine for konversation (using now); only thing missing is to set it as the default action
[15:39] <sergiusens> sitter: http://imgur.com/a/aArpk
[15:40] <sergiusens> sitter: there is a host side bug though which is that nothing is currently depending on snapd-xdg-open; I thikn zyga was looking into that
[15:41] <sitter> hm
[15:41] <sergiusens> sitter: aside from not being able to set it as a default action, only other thing I am missing is proper icons; I get `?` most likely due to the Icon entry having a value of a name that doesn't exist on my host.
[15:41] <sitter> sergiusens: indeed. I think it is only QDesktopService::openUrl that falls over
[15:42] <sitter> sergiusens: e.g. try help -> about konversation and click any link
[15:42] <sergiusens> sitter: yeah, that doesn't work
[15:42] <sitter> which supposedly comes back false here https://github.com/qt/qtbase/blob/5b1f18b0f1cd07f2dfcafe79b456338f908de531/src/platformsupport/services/genericunix/qgenericunixservices.cpp#L91
[15:43] <didrocks> yeah, we did develop snapd-xdg-open and a fake xdg-open in core snap side for that reason
[15:43] <didrocks> dependency was still to be sorted out, zyga is owning this AFAIK
[15:44] <sitter> ah, I get it. usr/local/bin is missing from PATH ^^
[15:45] <didrocks> oh? I remember to have mentioned it on the ML and I thought after all our discussions that was fixed
[15:46] <sitter> certainly isn't when using `snap run --shell` nor is it documented at http://snapcraft.io/docs/reference/env
[15:46] <nessita> stokachu, so seems like what I promised about you being added automatically as a collabortor was not true, sorry. Could you please ping mvo and ask him to invite you as collaborator for that snap?
[15:46] <didrocks> no, I guess that wasn't fixed after it was removed from PATH after all (and you're right)
[15:46] <nessita> stokachu, mvo  should fill the form under https://myapps.developer.ubuntu.com/dev/click-apps/5479/collaboration/
[15:47] <mvo> nessita: sure, I can add stokachu
[15:47] <stokachu> ok
[15:47] <sergiusens> sitter: didrocks if I get a bug report on snapcraft I can easily add the PATH
[15:47] <stokachu> mvo, oh thank you
[15:47] <stokachu> mvo, do you need my email or anything?
[15:47] <Hanonim> okay, i've read quite a bunch of docs about ubuntu core and snapcraft and i don't see how i could use wiringpi (that needs to write to /dev/mem)
[15:47] <mvo> stokachu: yes, your ubuntu-one primary mail would be nice
[15:47] <didrocks> sergiusens: yeah, I wonder if that's the right place, but it can help for now as it seems it doesn't have traction snapd-side :)
[15:47] <mvo> stokachu: just /msg it to me
[15:48] <didrocks> sitter: mind opening the bug for sergiusens?
[15:48] <didrocks> I can add it to desktop-launch as well for Qt apps for now
[15:48] <didrocks> (but doesn't help on KDE's one as you are using your own launcher)
[15:50] <sitter> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1661023
[15:50] <mup> Bug #1661023: PATH does not include /usr/local/bin and /usr/local/sbin <Snapcraft:New> <https://launchpad.net/bugs/1661023>
[15:50] <sitter> didrocks: yeah, easy enough to work around for now
[15:53] <stokachu> nessita, thanks for you're help, im good to go now
[15:53] <stokachu> your*
[15:59] <sitter> about dialog links work like a charm with modified PATH. thanks for the help :)
[15:59] <nessita> stokachu, excellent, sorry for the "honest" lie yesterday
[16:00] <didrocks> sitter: nice! btw, we are going to promote your KDE snaps in the "top snaps of the month" for January :-)
[16:02] <sitter> \o/
[16:06] <mup> PR snapd#2756 closed: snapctl: add config in client to disable auth and use it in snapctl <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2756>
[16:45] <zyga> re
[16:45] <zyga> jdstrand: I agree, I think you are exactly right
[16:45] <zyga> didrocks: hey
[16:46] <zyga> didrocks: so the snapd-xdg-open bug
[16:46] <zyga> didrocks: AFAIR there was some discussion and it didn't culminate with a decision as to how the dependency should be injected
[16:47] <zyga> didrocks: I don't feel I own this bug actually, I think it belongs to foundations/desktop or if it belongs I don't have a plan to solve it anytime soon; adding the dependency is easy but it would be complex on server/headless installs
[17:07] <HumbleBeaver> Morning everyone, Is anyone here using the snap version of Telegram?
[17:15] <pachulo> I do HumbleBeaver
[17:15] <stokachu> which one? telegram-latest or telegram-sergiusens
[17:15] <HumbleBeaver> stokachu: Both actually
[17:16] <stokachu> oh are they both required to be installed?
[17:16]  * stokachu doesn't know which one to use
[17:16] <pachulo> I'm using telegram-sergiusens and no, you don't need them both
[17:16] <HumbleBeaver> No I had one installed and when it started to mess up, I uninstalled it and tried the other
[17:17] <HumbleBeaver> I'm thinking it might have something to do with an extension I added when I installed the kconnect ppa.
[17:17] <zyga> jjohansen: hey, can you please ping me when you are around. I have some good progress on the bug we've been talking about
[17:20] <HumbleBeaver> pachulo have you had any issue with it not allowing attachments?
[17:20] <HumbleBeaver> If not its something on my system and I'll do some digging.
[17:35] <stokachu> only issue ive seen with this telegram app is the tray icon is missing
[17:40] <HumbleBeaver> thanks stokachu, I've been fighting with an issue on my system and I'm starting to see a pattern.
[17:41] <HumbleBeaver> Why it affect the snaps I'm not sure
[17:41] <zyga> HumbleBeaver: the tray icon issue?
[17:41] <zyga> HumbleBeaver: because it's a broken protocol, it's been researched by a few folks AFAIK. The actual icon is saved to /tmp and /tmp is private for each snap.
[17:42] <zyga> there are a few other ways to show an icon there so it depends on the toolkit/app
[17:42] <stokachu> so that requires a user talking to upstream to get that fixed?
[17:43] <zyga> we should have /tmp-IPC backend for cases like this
[17:43] <zyga> stokachu: it's a complex issue, I think
[17:43] <zyga> stokachu: part of legacy protocols, old agrements, not sure
[17:43] <stokachu> ok, wasn't sure if it was something we could workaround in the snapcraft
[17:43] <stokachu> with organize or something
[17:43] <zyga> stokachu: there's a bug that tracks this with a lot of details
[17:43] <zyga> stokachu: doubtful
[17:43] <zyga> stokachu: more likely in snapd
[17:43] <stokachu> ah ok
[17:44] <zyga> stokachu: or at a toolkit level
[17:44] <zyga> stokachu: but then telegram bundles qt so you'd have to fix it and advertise the fix
[17:44] <stokachu> would a classic snap work ootb for now?
[17:44] <zyga> yes
[17:44] <zyga> no
[17:45] <zyga> we found some issues with the design of classic snaps
[17:45] <stokachu> it is a nitpick detail but a lot of users would probably not like having a default icon there
[17:45] <zyga> we know how to fix them but the work has not started
[17:45] <stokachu> zyga, ah ok
[17:45] <zyga> I think I'd stick for strict/devmode for now
[17:47] <HumbleBeaver> zynga, no the file attachment bug. I'm starting to think that installed something that has caused snap packages and others to behave strangely
[17:48] <HumbleBeaver> I've asked a few others and they say it works fine. I can also drag an drop file into telegram without issue
[17:49] <zyga> jjohansen, jdstrand: https://bugs.launchpad.net/apparmor/+bug/1656121/comments/13
[17:49] <mup> Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <AppArmor:Confirmed> <https://launchpad.net/bugs/1656121>
[17:50] <zyga> HumbleBeaver: I don't know anything about file attachment bugs but I could say that since the snap works in a different namespace it doesn't see the same filesystem as your desktop
[17:51] <zyga> jdstrand: the last thing on that comment is key I think
[17:51] <zyga> jdstrand: note that we don't see the disconnected profile anymore
[17:52] <zyga> er, path
[17:52] <zyga> jjohansen: if you have a branch I could test with a locally built kernel I'd like to keep digging
[17:52] <mup> PR snapd#2758 opened: overlord/devicestate: implement policy about gadget and kernel matching the model <Created by pedronis> <https://github.com/snapcore/snapd/pull/2758>
[17:53] <zyga> jjohansen: this is my top priority now
[17:59] <kyrofa> ogra_, how would one enable SPI on the joule?
[17:59] <ogra_> kyrofa, oh, no idea
[17:59] <ogra_> never seen a joule
[17:59] <zyga> kyrofa: is /dev/spi* around?
[18:00] <kyrofa> ogra_, turns out that's the hw being used in that askubuntu question I pinged you about yesterday :P
[18:00] <ogra_> yeah
[18:00] <kyrofa> zyga, no idea
[18:00] <kyrofa> ogra_, any idea who made the gadget for that?
[18:00] <ogra_> i remember but i have no idea about joule ... you have to ask someone knowing the HW
[18:00] <zyga> kyrofa: do you have a joule?
[18:01] <ogra_> kyrofa, JohnAgosta might be able to point you to someone
[18:01] <kyrofa> zyga, I'm afraid not
[18:01] <zyga> kyrofa: meh, too bad then
[18:01] <kyrofa> JohnAgosta, any idea who made the Joule gadget?
[18:02] <JohnAgosta> kyrofa, are you referencing the gadget snap in the Joule image?
[18:03] <JohnAgosta> https://developer.ubuntu.com/core/get-started/intel-joule
[18:10] <mup> PR snapcraft#1078 closed: tests: do not rely on project_dir <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1078>
[18:18] <kyrofa> JohnAgosta, sorry, internet flaked on me. Yes, that's what I'm referring to
[18:20] <JohnAgosta> kyrofa, that was created by either of Robert Liu or Tim Chen. They are on Chinese New year break
[18:21] <kyrofa> JohnAgosta, do you know of anyone around who might know how to enable SPI?
[18:21] <JohnAgosta> kyrofa, please make sure you are looking at the correct one...this was all updated to beta4 images in the past week
[18:22] <JohnAgosta> kyrofa, my brain is flaking out -- what is "SPI"?
[18:22] <kyrofa> JohnAgosta, Serial Peripheral Interface
[18:22] <kyrofa> JohnAgosta, hardware interface protocol
[18:23] <kyrofa> Like i2c
[18:23] <kyrofa> JohnAgosta, at least in e.g. the rpi, it needs to be enabled in the gadget
[18:24] <kyrofa> JohnAgosta, we have an askubuntu question about it seemingly not being enabled on the joule, and no one knows how to enable it :P
[18:24] <JohnAgosta> kyrofa, let me look...i cannot remember if it is enabled in this image...do you have access to private LP project https://bugs.launchpad.net/tuchuck?
[18:24] <JohnAgosta> looking now
[18:24] <kyrofa> I do
[18:25] <ondra> kyrofa were discussing SPI for other project, and there is no SPI interface
[18:25] <JohnAgosta> kyrofa, it will be listed as i2c
[18:25] <ondra> kyrofa but we defo need it
[18:25] <ogra_> +1
[18:25] <ogra_> we need it on the pi too
[18:25] <ogra_> (the interface)
[18:26] <ondra> ogra_ do it! :P
[18:26] <ogra_> well, i'm busy with other stuff
[18:26] <JohnAgosta> kyrofa, ok, found it... it is now there in latest image https://bugs.launchpad.net/tuchuck/+bug/1607195
[18:27] <JohnAgosta> kyrofa, we just updated the image on the website a week ago -- early image did not have it enabled yet
[18:28] <JohnAgosta> kyrofa, one thing missing from our website is a pointer to the required BIOS (174).  I have an open request to Intel for a public share with that required BIOS
[18:29] <kyrofa> JohnAgosta, this is i2c-- are you saying that covers spi as well?
[18:30] <JohnAgosta> kyrofa, beyond my knowledge area... i was stating i2c only based upon your earlier comment referring to i2c as an example
[18:31] <kyrofa> JohnAgosta, yeah it seems like i2c works
[18:31] <kyrofa> But SPI does not
[18:33] <kyrofa> JohnAgosta, mind if I create a new bug? Perhaps those guys can look into it once they return?
[18:33] <JohnAgosta> kyrofa, please wait -- i am still researching
[18:33] <kyrofa> JohnAgosta, sure thing
[18:33] <kyrofa> ondra, thanks for the info by the way
[18:34] <ondra> kyrofa no worries :)
[18:35] <kyrofa> tvoss, https://askubuntu.com/questions/878750/package-conflicts-whith-snapd-on-ubuntu-14-04
[18:35] <kyrofa> tvoss, might be of interest to you
[18:36] <JohnAgosta> kyrofa, ok, I don't see anything in our project plans for SPI. Please create a "tuchuck" bug and I will track first with Intel to understand their module support as I don't even see anything from Intel.
[18:37] <JohnAgosta> kyrofa, you can assign to me jagosta
[18:38] <kyrofa> JohnAgosta, will do, thank you for investigating
[18:38] <kyrofa> ogra_, ondra thanks for your help
[18:38] <ogra_> np
[18:39] <kyrofa> JohnAgosta, just FYI, this lists two SPI buses: https://software.intel.com/en-us/iot/hardware/joule
[18:40] <mup> PR snapcraft#1098 opened: Ignore .tox directories when creating cleanbuild tar <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/1098>
[18:42] <JohnAgosta> kyrofa, doesn't mean Intel has finished the linux driver yet. :)  Also, not sure why Intel did not include in project plan
[18:42] <JohnAgosta> this is all still in development -- audio drivers not done yet either
[18:43] <kyrofa> JohnAgosta, ah interesting, indeed that may be the case
[18:43] <kyrofa> JohnAgosta, I created https://bugs.launchpad.net/tuchuck/+bug/1661067 but I don't seem to have permission to assign it to you
[18:44] <JohnAgosta> kyrofa, interesting... I see WiFi LEDs on this sheet too and Intel is still discussing whether they even have WiFI LEDs.  :)
[18:44] <kyrofa> Hahahaha
[18:58] <tvoss> kyrofa: thanks for the hint, answering right now
[18:58] <kyrofa> tvoss, of course, thank you!
[19:02] <tvoss> kyrofa: https://askubuntu.com/questions/878750/package-conflicts-whith-snapd-on-ubuntu-14-04/878770#878770
[19:03] <tvoss> ^ and others reading backlog :-)
[19:03] <kyrofa> tvoss, user83107?!
[19:03] <kyrofa> At least you have a picture :P
[19:17] <jdstrand> zyga: https://bugs.launchpad.net/apparmor/+bug/1656121/comments/14
[19:17] <mup> Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <AppArmor:Confirmed> <https://launchpad.net/bugs/1656121>
[19:33] <zyga> jdstrand: thank you for the tip, I'll check that out
[19:34] <zyga> jdstrand: honestly this makes me worried, we should investigate 1648903 and understand what is going on
[19:34] <zyga> jdstrand: if this doesn't work then why should we assume other rules are respected
[19:35] <jdstrand> that's why I filed the bug, though just cause one complain rule isn't working right doesn't mean they all aren't
[19:35] <zyga> jdstrand: but when something as fundamental as this misbehaves a red flag gets raised in my mind
[19:36] <zyga> jdstrand: I'll try the workaround to see if this helps
[19:36] <zyga> jdstrand: perhaps jjohansen's kernel fixed one issue just to uncover another
[19:37] <jdstrand> well, that is why I filed a bug. I'm just saying I don't think it requires panicking cause I only ever saw this with namespaces. we'd have tons of bug for devmode if it was wider spread
[19:38] <zyga> jdstrand: that's true
[19:45] <jjohansen> zyga: that is what I think is going on, the behavior changed with the kernel patch. So I think we move forward with it being a separate issue. I have already sent the patch for the complain issue up to the kt
[19:47] <zyga> jjohansen: I agree, I think this is the right course of action
[19:47] <zyga> jjohansen: did you look at the other issue, the one that jdstrand suggested?
[19:47] <zyga> jjohansen: do you have any insight into that issue?
[19:48] <jdstrand> to be clear, I only asked a question :)
[19:48] <zyga> (a very plausible idea though)
[19:50] <jjohansen> zyga: I'm looking
[19:50] <zyga> jjohansen: btw: did you see the script I've attatched to the bug report?
[19:55] <jjohansen> yes
[19:56] <tvoss> kyrofa: hmmm, I logged in with my launchpad account, I had assumed that would give me a reasonable username
[20:15] <tvoss> wow, that was more complicated than I expected :) kyrofa: managed to change my profile name
[20:16] <kyrofa> tvoss, haha! Much better
[20:44] <stokachu> so trying to get a config file to be included during my python part build http://dpaste.com/2T9HYX7
[20:44] <stokachu> the filesets section isn't getting included though, the only way i could was make it seperate and add the dump plugin
[20:44] <stokachu> is there a way to do both on a single part?
[20:46] <kyrofa> stokachu, let me make sure I understand
[20:47] <kyrofa> stokachu, the `conjure-up` part contains a `etc/conjure-up.conf` file that the setup.py doesn't install, so you want snapcraft to install it?
[20:47] <stokachu> kyrofa, yea exactly
[20:47] <kyrofa> stokachu, easy: use the `install` scriptlet
[20:47] <stokachu> but in the same part (if possible)
[20:48] <kyrofa> stokachu, are you familiar with that?
[20:48] <stokachu> kyrofa, reading snapcraft help plugins now :)
[20:48] <kyrofa> stokachu, it's part of the core, not a plugin: https://snapcraft.io/docs/build-snaps/scriptlets
[20:49] <kyrofa> davidcalle, you're rocking on those docs, by the way
[20:49] <stokachu> kyrofa, so would it just be `cp etc/conjure-up.conf $SNAP/etc/conjure-up.conf`?
[20:49] <kyrofa> stokachu, almost-- $SNAP is a runtime-only variable
[20:49] <stokachu> oh SNAPCRAFT_PART_INSTALL
[20:49] <kyrofa> stokachu, you got it
[20:49] <stokachu> cool! thanks ill give this a whirl
[20:49] <stokachu> and yes davidcalle++ for the docs
[20:50] <kyrofa> stokachu, just FYI, `filesets` does nothing by itself
[20:50] <kyrofa> stokachu, it gives you the ability to define filesets that can be used by name in the `stage` and `prime` keywords
[20:50] <stokachu> ah thats all? i think i was treating it like snap
[20:51] <kyrofa> Yeah, the format isn't even correct-- you're using it like `organize`
[20:51] <stokachu> kyrofa, hah ok thanks for clearing that up
[20:51] <kyrofa> Well, not even that. But yeah, you can safely toast that line
[20:51] <stokachu> kyrofa, so one more thing, where you see organize under spells:
[20:51] <stokachu> i basically want to just put that whole repo into a directory in the snap
[20:51] <stokachu> is that the right way?
[20:52] <kyrofa> stokachu, indeed, that should work
[20:52] <stokachu> should i just use an install scriptlet
[20:52] <stokachu> ok cool
[20:52] <davidcalle> kyrofa: stokachu: hey, thanks o/
[20:52] <kyrofa> davidcalle, it's taken me a while to start referring people there instead of in-source docs, but man. So professional
[20:53] <davidcalle> There should be a small blog post going live tomorrow on how MySQL uses scriptlets
[20:54] <kyrofa> Nice!
[20:54] <stokachu> kyrofa, do you know if there are a lot of big changes still needed for https://github.com/snapcore/snapcraft/pull/1093?
[20:54] <mup> PR snapcraft#1093: python plugin: do the right thing with classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1093>
[20:54] <stokachu> im itching to get conjure-up running on trusty
[20:54] <kyrofa> stokachu, nope, just about there
[20:54] <stokachu> cool
[20:55] <kyrofa> stokachu, rather, yes, I know, and no :P
[20:55] <kyrofa> Man that's a hard question to answer
[20:55] <stokachu> :D
[22:18] <mup> Bug #1631270 changed: running a command for a snap in try mode fails on trusty <trusty> <Snappy Launcher:Invalid> <Snappy:Fix Released by thomas-voss> <snap-confine (Ubuntu):Invalid> <https://launchpad.net/bugs/1631270>
[23:43] <mup> PR snapcraft#1099 opened: catkin plugin: don't pass args to setup.sh <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1099>