[03:24] <stevebiscuit> dz0ny_: I'm still in the process of getting WebDM building against the latest snappy
[05:39] <chriss_> hello
[05:40] <chriss_> Any one their
[05:44] <chriss_> hey
[06:27] <rampa> when will the new porting guide for Snappy get release?
[07:01] <dpm> morning all
[07:03] <dpm> asac, do you happen to own the webdm snap? It does not seem to work atm, and if so, would you mind unpublishing it from the store until it's been fixed?
[07:04] <dpm> Same for whoever owns the xkcd-webserver snap
[07:04] <dpm> People are installing these on their desktops and get confused about running them
[08:42] <flexiondotorg> I've been experimenting when making my first snaps.
[08:43] <flexiondotorg> They are Python utilities and the Python plugins for snappy are ace. I have snaps and all dependencies are met. Great!
[08:43] <flexiondotorg> However, when I execute tools from these snaps they complain about permission errors or not being able to read dot files etc.
[08:44] <flexiondotorg> Is there something "special" I should be doing to allow these snaps to access dot files and data in my home directory?
[08:56] <stevebiscuit> dpm: I don't have access to the store and I think most if not all of the core team have taken the day off today. sergiusens could possibly be of help
[08:57] <dpm> flexiondotorg, check the notes on the 'home' interface here: https://developer.ubuntu.com/en/desktop/examples/#snap-python
[08:58] <dpm> stevebiscuit, ok, thanks, I'll check with him when he's up
[08:58] <flexiondotorg> dpm, Thanks. I already see this solution :-)
[09:00] <popey> :)
[09:25] <flexiondotorg> dpm, This is good stuff - https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md
[09:26] <flexiondotorg> If I have an application that want to read dotfiles/dirs in my home directory, does the document about imply that is simply not possible?
[09:27] <davidcalle> jdstrand: ^
[09:27] <dpm> flexiondotorg, I think that's what it means, but you might want to ask the security team for the rationale, jdstrand or tyhicks might be able to help you when they're up later on
[09:28] <flexiondotorg> dpm, Thanks. Guidance appreciated.
[09:28] <dpm> np :)
[09:28] <flexiondotorg> One of the apps I'm snapping is Mackup, which is a dotfile backup tool.
[09:29] <flexiondotorg> The other is a static site generator.
[09:29] <flexiondotorg> Some the 'home' plug is fine.
[09:39] <flexiondotorg> Hmm, still not able to access files in my home directory :-(
[09:42] <asac> dpm: nope ... thats sergiusens and one of beuno's folks now i think...
[09:42] <asac> dpm: xkcd-webserer is mvo
[09:42] <asac> the above was for webdm
[09:43] <asac> i own(ed) hello-world with all its neat features :)
[09:43] <asac> and go-example-serbserer
[09:43] <asac> webserver
[09:43] <asac> but that one i didnt rev for a while
[09:43] <asac> and hello-world seems good to go
[09:43] <dpm> asac, those two are actually fine, they work
[09:44] <asac> i love hello-world.sh on desktop :)
[09:44] <asac> shows you right away how you feel in the sandbox
[09:44] <asac> hehe
[09:44]  * asac just tried
[09:55] <dholbach> how far are we with the images on cdimage.u.c? are all of them official, golden and working now?
[10:01] <ogra_> dholbach, far from
[10:02] <ogra_> the ones that mvo built had partially broken kernels ... i.e. the final arm kernels only landed wednesday evening ...
[10:02] <ogra_> yesterday i was busy fixing the breakage the renaming of the kernel packages caused ...
[10:03] <ogra_> the store is in a proper shape now but i havent re-built the images yet ... i'll put some up when i'm done generating and testing them
[10:03] <dholbach> ok, THANKS
[10:03] <dholbach> thanks
[10:03] <dholbach> sorry, caps lock strikes again
[10:03] <ogra_> heh
[10:03] <dholbach> "big thanks" :)
[10:05] <ppisati> $ sudo snap install blabla.snap
[10:05] <ppisati> error: change finished in status "Hold" with no error message
[10:05]  * ogra_ runs snap find blabla
[10:06] <ppisati> how do i debug this?
[10:08] <ogra_> ppisati, is that on an image or on desktop
[10:09] <ppisati> ogra_: amd64 image, kvm, while installing a custom kernel
[10:09] <ogra_> well, thats a zyga or mvo question i fear
[10:10] <ppisati> if i recompile a 4.4 kernel with snapcraft, everything is fine now - it install fine and i can boot the img
[10:10] <ogra_> (neither is around)
[10:10] <ppisati> if i recompile an old kernel (3.14 in this case), i get this
[10:10] <ogra_> cool !
[10:10] <ogra_> (good to know the initrd works now)
[10:10] <ppisati> in the 4.4 case, x86_64_defconfig + snappy options + sqaushfs with xz support: ok, working img
[10:11] <ppisati> in the 3.14 case, i get that error
[10:11] <ppisati> ogra_: yep, at least it boot now
[10:11] <ppisati> the next step is to get a 3.14 minimal kernel to work
[10:12] <ogra_> one of the biggest requests i had at embedded world was a proper realtime kernel ... i was wondering if we could provide a source tree with the required patches for people ...
[10:12] <ogra_> (without building or officially supporting it indeed)
[10:13] <ppisati> ogra_: once we get this stuff sorted out, i think we can talk about that
[10:13] <ppisati> ogra_: what i would like to find, is a suite of tests to run again a series of kernels (3.14...4.4) to assess that everything is fine
[10:13] <ogra_> yeah
[10:14] <ogra_> well, a config checker would be nice ...
[10:14] <ogra_> hooked into the kernel plugin
[10:15] <ogra_> ppisati, did you try the --devmode option yet ?
[10:15] <ogra_> snap install --devmode blabla.snap
[10:15] <ppisati> ogra_: nope
[10:15] <ogra_> perhaps that works around that
[10:15] <ppisati> ogra_: but i didn't need that woth the 4.4
[10:15]  * ppisati tries
[10:16] <ppisati> same error
[10:16] <ogra_> hmm
[10:16] <ppisati> i'm using mvo's amd64 img, FWIW
[10:16] <ppisati> http://people.canonical.com/~mvo/all-snaps/
[10:16] <ppisati> the amd64 img there
[10:16] <ogra_> yeah
[10:42] <ogra_> yakkety !
[10:43] <asac> hmm... what a mystery... bought a wifi dongle, plugged into rpi, shows up as wlan0, seems its a mac80211 driver we have in our kernel, can connect with wpa-psk ... so far so fine
[10:43] <asac> but ... iw list does not show it
[10:43] <asac> neither is there a phyX somewhere in sysfs :(\
[10:43] <asac> on pi2
[10:44]  * asac lost... on desktop it has a phy in sysfs and also is visible in iw list...
[10:44] <asac> ppisati: any idea?
[10:45] <ogra_> asac, did you simply try to create a file in /etc/network/interfaces.d and reboot ?
[10:46] <ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/dragonboard/README works just fine on the dragonboard
[10:46] <ppisati> asac: uhm, nope
[10:46] <asac> ogra_: I CAN connect to wifi
[10:46] <asac> its there was wlan0 etc.
[10:46] <asac> it just has no phy :)
[10:46] <ogra_> cant have everything :P
[10:46] <asac> lol
[10:47] <asac> no radio :)
[10:47] <asac> magic
[10:47] <ogra_> pfft, radio ... use spotify ... :P
[10:49] <asac> pitti: any idea? is there udev magic involved to get ieee80211/phyX entries in sysfs?
[10:49]  * ogra_ wonders who had the glorious idea to use xz for all images nowadays ... i'm really doubting the extra time it takes to cokmpress them actually pays off that much 
[10:50] <ogra_> (gzip is only a few MB bigger but 20x as fast)
[10:50] <pitti> asac: no, /sysfs (and most of /dev) is entirely managed by the kernel
[10:50] <asac> right
[10:50] <asac> pitti: so on my pi2 i have it as wlan0
[10:50] <asac> on desktop where it has phy it is like the new long format
[10:51]  * asac reboots and hopes for magic
[10:52] <asac> ogra_: think for our squash it makes some sense... for the download artifacts i feel the same
[10:54] <asac> ogra_: guess now we have two times xz? first xz the tar, then untar and squash again?
[10:56] <asac> ppisati: who is our wifi expert? :) seth?
[10:58] <asac> maybe i should try 4.4 kernel... still on 4.3
[10:58] <asac> but this cant be such new feature
[11:02] <ogra_> asac, no, i'm talking about img.xz actually ... the snaps are created directly with no tarballs involved
[11:03] <asac> cool thats good news at least
[11:03] <ogra_> (i actually need to turn off tarball creation in cdimage since we dont use them anymore ... they are still built in parallel)
[11:03] <asac> so yeah, guess for our images with squash xz for core inside etc. it doesnt need xz
[11:04] <asac> shouldnt be super big gain
[11:04] <ogra_> well, i'Äm currently producing them on my laptop (udf and trustys kpartx dont work well, so i cant use my desktop)
[11:05] <ogra_> compressing one image takes around 12min ... 2-3 with gzip
[11:05] <asac> ppisati: its the pi2 kernel for sure... tested on db and beagle and both get the /sys/class/ieee80211/phy* entry
[11:05] <asac> unforuntatley its the 4.3 one still
[11:06] <ogra_> thats broken
[11:06] <ogra_> (seccomp bugs)
[11:06] <asac> ogra_: can i get a 4.4 kernel for the old all snaps?
[11:06] <asac> right
[11:06] <asac> but not the 4.3
[11:06] <asac> still its super weird
[11:06] <asac> that the wlan0 interface works
[11:06] <ogra_> i only uploaded to the 16 series
[11:06] <asac> but no radio hardware is seen
[11:06] <ogra_> snap refresh shoudl work if you are on one of these images
[11:07] <asac> guess have to work on the beagle then for the time
[11:07] <asac> fine
[11:07] <ogra_> i'll push a new image up once they are built and i have at least boot tested them
[11:07] <asac> ogra_: but 16 series images have no classic, or?
[11:08] <ogra_> right
[11:08] <asac> so yeah let me not go down that path :)
[11:08] <ogra_> you need to use an ubuntu-core tarball and chroot for the moment
[11:08] <asac> rather wait for stuff to settle
[11:09] <ogra_> that might take some time though
[11:09] <ogra_> and we wont update the rolling images anymore
[11:13] <asac> sounds like its perfect to use that last image for work :) ... e.g. stable until the other side settles in
[11:13] <asac> if the wifi only would work well on pi2 :P
[11:18]  * asac moves classic files to beagle
[11:25] <dz0ny_> heh http://mjg59.dreamwidth.org/42320.html
[11:25] <dz0ny_> Circumventing Ubuntu Snap confinement
[11:34] <ogra_> dz0ny_, yeah, known issue
[11:34] <ogra_> (there was discussion to show a popup to make the user confirm, but that was considered to intrusive, not sure what the final outcvome was though)
[11:36] <svij> ogra_: too bad, now it feels like, everyone is just repeating matthew garrets blog post, rather than the other improvements on snappy :/
[11:36] <ogra_> well
[11:36] <ogra_> he's not wrong though
[11:36] <svij> I know
[11:38] <svij> what happens if someone publishes his package to the store, does the automatic review tool recognise that? I think no?
[11:39] <ogra_> you got to ask tyhicks or jdstrand
[11:40] <popey> svij: snaps aren't currently automatically reviewed
[11:40] <popey> so if he (or someone else) uploaded it, it wouldn't get to customer machines
[11:40] <popey> (AIUI)  😃
[11:40] <svij> ah, so someone checks them manually right now?
[11:48] <sergiusens> dpm what's up?
[11:48] <sergiusens> good morning!
[11:48] <dpm> hey sergiusens, morning!
[11:48] <dpm> sergiusens, so, webdm does not seem to be working, and I was suggesting to unpublish it from the store until it's fixed
[11:49] <dpm> people are starting to install everything they see with 'snap find'
[11:49] <dpm> and are getting confused at things not working
[11:49] <dpm> same with xkcd-server
[11:49] <dpm> but I think that one is for mvo when he's back
[11:54] <simosx> A common question regarding snappy is whether more diskspace and memory will be used when you have installed several snaps.
[11:54] <simosx> Is there a page that talks about this?
[11:55] <ogra_> you mean because of the bundeling of libs ?
[11:55] <ogra_> (i dont think there is a page)
[11:59] <dpm> hi simosx, certainly more disk space, although we're looking at options to reduce this. Not sure why snaps should consume more memory, but I'm not an expert
[12:00] <simosx> ogra_, yes, having extra copies for the libraries. Also, since the libraries are not shared libraries, there would be a few extra copies loaded in memory for the same library.
[12:00] <ogra_> usually they are shared
[12:00] <ogra_> snapcraft uses deb packages by default
[12:00] <sergiusens> dpm check if it is still there
[12:01] <sergiusens> took me some time to find it :-)
[12:01] <ogra_> but they arent shared between snaps
[12:01] <dpm> sergiusens, it's still there - did you unpublish it? Perhaps there is some delay until it's hidden
[12:02] <simosx> I assume a stock answer would be "surely, more diskspace and somewhat more RAM is used. But in practice, the RAM issue is not so big"
[12:02] <ogra_> right
[12:02] <dpm> ogra_, do you happen to know why all the non-amd64 canonical-* gadgets appear in the output of 'snap find' on the desktop?
[12:02] <ogra_> there will be ways that you can ship a library snap ... to be consumed by your own snaps ...
[12:02] <simosx> It would be important to have some answer on this, preferably on a blog post.
[12:03] <ogra_> dpm, no, but i'm ranting about that since a year :)
[12:03] <ogra_> dpm, gadgets should simply be hidden ... or only visible via some option to find ... like --type=gadget or so
[12:04] <dpm> ok, I pinged Martin about it, see if he can shed some light into it. At the very least, I think they should not appear listed in foreign architectures
[12:04] <ogra_> dpm, there are no foreign arches ... gadgets are arch all ;)
[12:04] <dpm> oh, that explains it then :)
[12:05] <ogra_> that is why i think we need to filter by type instead :)
[12:06] <kyrofa> Good morning
[12:08] <sergiusens> dpm Status Unpublished
[12:08] <sergiusens> dpm btw, super close to get a build of vscode working; I just need to pull in electron
[12:08] <sergiusens> all using just the nodejs plugin (I did however had to export envvarts)
[12:09] <dpm> sergiusens, ah, awesome. Have you had some thoughts about how to deal with electron apps?
[12:10] <sergiusens> dpm apparently you just need to gulp it
[12:10] <sergiusens> was going to ask stevebiscuit or beowulf what the nicest way to do that would be
[12:11] <dpm> I'm not familiar with gulp, other than having heard the name
[12:11] <flexiondotorg> Hmm.
[12:11] <flexiondotorg> I'm confused.
[12:12] <flexiondotorg> I have made 3 Python snaps.
[12:12] <flexiondotorg> None are able to read anything in my home directory.
[12:12] <ogra_> hwo would they
[12:12] <dpm> flexiondotorg, do they use the 'home' plug, and did you connect it manually?
[12:12] <flexiondotorg> http://paste.ubuntu.com/15980091/
[12:12] <ogra_> they are confined
[12:13] <flexiondotorg> dpm, See one example.
[12:13] <ogra_> right, you need to connect the plug
[12:13] <ogra_> after install
[12:13] <flexiondotorg> Is there anything obviously wrong there?
[12:13] <flexiondotorg> Connect to the plug?
[12:13] <flexiondotorg> In the yaml?
[12:14] <ogra_> no, using the snap command
[12:14] <dpm> flexiondotorg, did you check out the link I sent you earlier on? https://developer.ubuntu.com/en/desktop/examples/#snap-python
[12:14] <dpm> it shows you how to do the manual connection
[12:14] <flexiondotorg> dpm, Ahh.
[12:14] <dpm> :)
[12:15] <flexiondotorg> So those plugins are not automatically exposed.
[12:15] <flexiondotorg> *plugs
[12:15] <dpm> flexiondotorg, going forward, there have been some talks of doing the prompt more interactive, but for now, you'll need to manually connect
[12:15] <ogra_> they are exposed, but not automatically interconnected
[12:16] <flexiondotorg> Right, got it.
[12:16] <flexiondotorg> Once the plugs are connected to they persist across boots?
[12:16] <popey> dpm: do you detect arch triplet in any of your snaps, or hard wire it for amd64?
[12:16] <sergiusens> dpm I might need to run a "re index" not sure; last time I did that I broke the store. I'll jut delegate to matiasb, nessita or beuno
[12:17] <dpm> popey, I'm glad you ask :) -> askubuntu.com/questions/757668/how-to-build-multi-arch-snaps
[12:17] <ogra_> popey, do you want to build a 600MB calculator multi snap ?
[12:17] <popey> haha
[12:17] <ogra_> (though for all arches that might become 1GB)
[12:17] <dpm> ogra_, too late for that!
[12:17]  * popey considers a 1.2GB DocViewer
[12:17] <ogra_> (since we now also support s390x and ppc64el)
[12:18] <ogra_> really ... dont do multi snaps
[12:18] <sergiusens> popey I would create a snap call coreapps with all the apps in there ;-)
[12:18] <dpm> popey, for clock and calculator, I built separate snaps for each arch.
[12:18] <ogra_> (multiple snaps with same name for different arch is fully supported)
[12:18] <sergiusens> popey you would save lots of space by having all of them in
[12:18] <popey> sergiusens: I'll put kvm and an iso in one containing all the core apps :þ
[12:18] <dpm> but for some reason the x86 fail to start
[12:19] <popey> pffft i386 is dead to me
[12:19] <popey> except for this 10 year old Thinkpad T43 on my desk :)
[12:19] <popey> thanks for the snippet dpm
[12:20] <dpm> sergiusens, so https://github.com/sergiusens/qt5conf works well for binary Qt5 apps, but is there a way to specify a different launch command, for QML apps, for example? Up until now, I've exec'd them so in the wrapper file:
[12:20] <dpm> cd $SNAP
[12:20] <dpm> exec $SNAP/usr/bin/qmlscene $SNAP/usr/share/ubuntu-clock-app/ubuntu-clock-app.qml
[12:21] <dpm> nw popey
[12:23] <flexiondotorg> Hmmm, I'm unable to connect to the home plug using this snap - http://paste.ubuntu.com/15980091/
[12:23] <flexiondotorg> I have multiple executables in that snap. I can't find a namespace the the home plug with connect to.
[12:23] <flexiondotorg> But the network plug appears to be connected to the podpublish namespace.
[12:24] <dpm> flexiondotorg, what does 'snap' interfaces show you?
[12:24] <dpm> sorry, `snap interfaces`
[12:24] <jdstrand> svij: no. the automated review tool cannot discover a malicous app wrt mjg's post
[12:25] <flexiondotorg> dpm, This http://paste.ubuntu.com/15980231/
[12:25] <flexiondotorg> Last line looks odd.
[12:26] <dpm> flexiondotorg, it tells your app's plug you it's not connected to the ubuntu-core:home slot
[12:26] <dpm> flexiondotorg, and `sudo snap connect podpublish:home ubuntu-core:home` does not work for you?
[12:27] <flexiondotorg> Right, sec. Will report back...
[12:27] <flexiondotorg> Just building the snap...
[12:30] <svij> jdstrand: ah okay
[12:30] <jdstrand> as of today because applications use X you have to trust the application
[12:31] <jdstrand> that was always understood to be the case
[12:31] <flexiondotorg> dpm, OK, progress.
[12:31] <flexiondotorg> But not quite working.
[12:32] <dpm> flexiondotorg, something that helps when debugging is looking at /var/log/kern.log to watch for AppArmor denials
[12:32] <flexiondotorg> http://paste.ubuntu.com/15980333/
[12:32] <flexiondotorg> dpm, So running the executable works and can parse the configuration file. So can access my home directory.
[12:33] <dpm> good
[12:33] <flexiondotorg> But then the path of the files in the configuration are being passed back in a different hierarchy.
[12:33] <dpm> so did you forget to ship that file, or is there some path that needs to be readjusted?
[12:33] <flexiondotorg> http://paste.ubuntu.com/15980333/
[12:34] <flexiondotorg> ERROR! /home/martin/snap/podpublish/100001/Dropbox/UbuntuPodcast/Backdrops/S09E07.jpg was not found. Abort.
[12:34] <flexiondotorg> The file path configured in the .ini file is /home/martin/Dropbox/UbuntuPodcast/Backdrops/S09E07.jpg
[12:34] <flexiondotorg> And it exists.
[12:35] <dpm> it seems to me that the python app is making that path relative to where it's launched from?
[12:35] <flexiondotorg> It doesn't.
[12:36] <flexiondotorg> It does expand the user home directory.
[12:37] <ogra_> you might need to generate the ini file from a wrapper then
[12:37] <flexiondotorg> In fact it doesn't do that.
[12:37] <dpm> right, but it seems that on doing expansion, it adds "snap/podpublish/100001 [...]" as a relative path to construct the final path
[12:37] <dpm> just guessing, I don't know the code
[12:37] <flexiondotorg> It just takes the configuration entry.
[12:37] <flexiondotorg> featured_image=~/Dropbox/UbuntuPodcast/Backdrops/S09E07.jpg
[12:37] <flexiondotorg> Which is that ^
[12:38] <dpm> jdstrand, how does HOME get set within a snap? ^
[12:38] <ogra_> HOME=/home/ubuntu/snap/hello-world/25
[12:38] <dpm> $ hello-world.env | grep HOME
[12:38] <dpm> HOME=/home/dpm/snap/hello-world/23
[12:38] <ogra_> the prob might be that bash overrides that when expanding  ~
[12:38] <kyrofa> dpm it's in the binary wrapper or service file
[12:39] <ogra_> try using $HOME in the config
[12:39] <flexiondotorg> This is in the wrapper
[12:39] <flexiondotorg> export HOME="$SNAP_USER_DATA
[12:39] <ogra_> right
[12:39] <ogra_> but you use ~
[12:39] <flexiondotorg> Yep.
[12:39] <ogra_> which could be auto-expanded by the calling shell
[12:39] <flexiondotorg> Because it is defined in an .ini file.
[12:40] <flexiondotorg> Which I don't think would be an uncommon expecation?
[12:40] <ogra_> dunno
[12:41]  * ogra_ would try using $HOME in the ini first ... 
[12:41] <ogra_> and if that doesnt work, instead generate the ini on first startup instead
[12:41] <ogra_> -instead
[12:42] <flexiondotorg> ConfigObj doesn't expand environment variables.
[12:43] <flexiondotorg> The ini file is human created.
[12:44] <ogra_> yes, so make it script created instead ... for the initial file
[12:44] <ogra_> then you can use the vars
[12:46] <flexiondotorg> ogra_, I don't follow.
[12:46] <flexiondotorg> Make what a script?
[12:46] <ogra_> call a script from the wrapper that checks if there is an init file already .... if there isnt, generate one using the SNAP vars
[12:46] <ogra_> *ini
[12:49] <ogra_> ppisati, hmpf ... testing the i386 image here i get eth0 on first boot and ens3 on all subsequent ones ... (which makes me end up with an eth0 config that indeed doesnt work after reboot)
[12:52] <ogra_> hmm, same with amd64
[12:53] <ogra_> i dont get why it changes names
[12:53] <ogra_> pitti, ^^^ any idea ?
[12:53] <ogra_> (we usually set net.ifnames=0 and should probably do that for x86 arches too ... but still it shouldnt change its name after first boot)
[13:00] <sergiusens> stevebiscuit you should ask fgimenez for help wrt to tarmac ;-)
[13:08] <stevebiscuit> sergiusens: I was wondering who to bother! the laptop was nearly being thrown out the window
[13:09] <kyrofa> stevebiscuit, haha
[13:10] <stevebiscuit> sergiusens: I'm only acting the part of a front-end developer btw... compiling all the JS assets would be the thing to do and there's no end of ways of doing that. copying the gulfile from webdm would certainly get you going along that path
[13:10] <fgimenez> hey stevebiscuit :) what's the problem?
[13:11] <stevebiscuit> fgimenez: hello! the machine building https://code.launchpad.net/~stevenwilkin/webdm/add-remove-snaps-via-api/+merge/288437 seems to have run out of disk space
[13:13] <ppisati> ogra_: yep, i noticed the name change too
[13:14] <ppisati> ogra_: but at least it's consistent here
[13:14] <ppisati> i always get ens3
[13:14] <ogra_> yeah, i just dont get why it changes
[13:14] <ogra_> only from the second boot on
[13:14] <ogra_> on first boot i see eth0
[13:16] <fgimenez> stevebiscuit, mmm seems to have enough space http://paste.ubuntu.com/15980970/, let me try merging again
[13:17] <stevebiscuit> fgimenez: cool, hopefully the thing actually builds heh
[13:23] <Elleo> quick question, can you upload snaps using the reserved permissions (like "x11" or "unity7") to the store? do they require manual approval? was just wondering if that should be mentioned in this sort of discussion: https://www.reddit.com/r/linux/comments/4fwfch/circumventing_ubuntu_snap_confinement/
[13:24] <sborovkov> Hi. Does this syntax still work? snap isntall snap.name config.yaml
[13:26] <ogra_> sborovkov, no
[13:27] <ogra_> sborovkov, the config interface is gone (temporary)
[13:27] <sborovkov> ogra_: Oh, ok, and here I was wondering why my snap's not working after this properly :-)
[13:28] <ogra_> yeah, its a bit painful ...
[13:28] <sborovkov> How temporary is that? Should I consider changing how it's working on my side?
[13:28] <ogra_> all foxcus was on brining snappy to the desktop for the last weeks ... things like config will come back soon
[13:28] <ogra_> it is high on the TODO afaik
[13:29] <flexiondotorg> ogra_, dpm http://paste.ubuntu.com/15981191/
[13:29] <flexiondotorg> I've create python test case, see above.
[13:30] <ogra_> yeah, so do what i asid ... generate the ini on first start
[13:30] <ogra_> then you get proper paths
[13:30] <ogra_> *said
[13:35] <flexiondotorg> ogra_, You're missing the point.
[13:36] <ogra_> am i ?
[13:36] <ogra_> your app can only see /home/martin/snap/home-tester/100001
[13:36] <ogra_> so your ini needs to point to that
[13:36] <flexiondotorg> Python code the tries to reference the home directory either via $HOME or os.path.expanduser() result is being given a directory path that is not the home directory.
[13:36] <seb128> ideally things would work out of the box without requesting every app to writer wrappers when they can to use the standard userdir
[13:36] <flexiondotorg> And is in fact, empty.
[13:36] <ogra_> to get the right value in a multi user system you can only grab it on first start
[13:37] <ogra_> your app runs inside /home/martin/snap/home-tester/100001 by default
[13:37] <flexiondotorg> But that is not my home directory.
[13:37] <ogra_> (if the binary supports it you could also use relative paths)
[13:37] <ogra_> bno, it is the home dir of the snap when it gets started
[13:37] <ogra_> this is part of app confinement
[13:38] <flexiondotorg> So I am not able to actually access my home directory using snaps unles I create the snap completely unconfined?
[13:39] <ogra_> not sure how the home plug actually works ... but the snap subdir was a constraint we had before that
[13:39] <ogra_> i'd be surprised if the interface gives you full access to all of home
[13:39] <ogra_> you have to ask zyga or niemeyer though
[13:42] <pitti> ogra_: can you check /proc/cmdline if it still actually has net.ifnames? if you set it on first boot, you indeed need to set it on others too, or disable that udev rule
[13:43] <ogra_> pitti, no, x86 doesnt ... so a weird name is expected ... but i dont expect it to change between two reboots
[13:48] <ogra_> (i.e. we end up with /etc/network/interfaces.d/eth0 on first boot and an eth0 interface being up ... after reboot there is only ens3)
[13:54] <niemeyer> flexiondotorg, ogra: The home interface allows access to files in the user's home which are not hidden (.*).
[13:55] <flexiondotorg> niemeyer, Yes, it does.
[13:55] <ogra_> niemeyer, but when ui start a snappy app its home points to ~/snap/app-name/100001
[13:55] <flexiondotorg> I can point my python, which is snapped, at a file in my home directory and the file is read.
[13:55] <flexiondotorg> Good :-)
[13:56] <flexiondotorg> However, if my file is a configuration file that then want to reference other files in my home directory.
[13:56] <ogra_> niemeyer, so apps that use ~/ in a config file get that expanded to  ~/snap/app-name/100001 instead of just ~/
[13:56] <flexiondotorg> The path expansion is to ~/snap/app/#ref#
[13:56] <niemeyer> ogra_: This dir is always available, even without the interface, and it's where the app should store its own data and control files
[13:57] <flexiondotorg> niemeyer, Which is fine.
[13:57] <niemeyer> The home interface is supposed to be used by apps that actually want interaction with user content
[13:57] <niemeyer> Downloads, pictures, etc
[13:57] <flexiondotorg> But using  os.path.expanduser() in a snapp Python application doesn't evaluate to /home/me it evaluates to /home/me/snap/app/#ref#
[13:58] <niemeyer> We'll definitely make this more fine grained, but for now that's how we bootatrapped
[13:58] <ogra_> niemeyer, but a commandline app that uses ~/myapp/config.conf ... will not look in /home/user/myapp/ for config.conf
[13:58] <ogra_> because the ~/ expands to the snap subdir
[13:59] <niemeyer> flexiondotorg: That's a good thing because it makes things just work for a lot of apps that want to write on the user's home just to store its own data
[14:00] <asac> ogra_: was the store for rolling killed too?
[14:00] <flexiondotorg> But also breaks lots of others.
[14:00] <ogra_> niemeyer, but it means you need to patch all apps that use ~/ somehow
[14:01] <niemeyer> Well, not really.. Most things don't break because they find $HOME elsewhere
[14:01] <flexiondotorg> I just happen to have picked 3 applications to snap that simply can't be snapped :-(
[14:01] <niemeyer> Note that there's really no perfect answer here..
[14:01] <ogra_> well, they could with a wrapper ... :)
[14:01] <niemeyer> flexiondotorg: Why?
[14:02] <flexiondotorg> A podcast encoder and uploader. Since all the assets exist outside the snap directory.
[14:02] <ogra_> as i said ... generate it on first start of the app and everything will have the right paths
[14:02] <flexiondotorg> A static site generator.
[14:02] <niemeyer> And what's the problem with that?
[14:02] <flexiondotorg> A dotfile/dotdir backup utility.
[14:02] <niemeyer> Just access the assets wherever they are?
[14:02] <flexiondotorg> Those applications have established workflow.
[14:03] <sergiusens> ogra_ `home` interface give access to all unhidden files in $HOME (or should); I'm not sure setting $HOME to $SNAP_USER_DATA is the right thing
[14:03] <niemeyer> flexiondotorg: dot files are restricted for now..
[14:03] <ogra_> niemeyer, the app has "my_work_dir=~/foo-bar" ... the snap turns that into /home/me/snap/app/#ref# at runtime and doesnt find its config
[14:03] <flexiondotorg> niemeyer, Yeah. Get that. Understand why. So no issue.
[14:05] <niemeyer> ogra_: That's a bit strange.. I don't use any applications that restrict their use to a particular part within $HOME
[14:05] <ogra_> niemeyer, http://paste.ubuntu.com/15981191/ thats a test app that flexiondotorg did
[14:06] <sborovkov> Is home app for snap persistent? Or will it get created again when snap's version  is changed?
[14:06] <ogra_> if you now have a config file that expects ~/app.conf ... it woint look in your home but in the snap subdir
[14:07] <niemeyer> Yes, and that's exaclty one of the reasons we did it
[14:07] <niemeyer> Most likely it won't be in ~/foo.conf, but in ~/.foo.conf, which should be inside /snap/1
[14:08] <niemeyer> sborvkov: you mean the dir?
[14:09] <sborovkov> niemeyer: yes.
[14:10] <sborovkov> Does it have persistent data? I mean after I update snap
[14:10] <sborovkov> to newer version
[14:10] <niemeyer> Yeah
[14:10] <ogra_> niemeyer, right, but it means that the majority of apps needs a wrapper to mangle the config at runtime or to have a different config patched in at build time
[14:11] <sborovkov> ok, got it
[14:11] <oobartez> hi all, where can i find a list of all desktop apps available as snaps? Sth like the deb repo browsers, ideally online
[14:11] <niemeyer> sborovkov: It's currently copied over so rollbacks are possible, but we'll likely change how that happens soon.. In either case you can trust it to persist data in there across updates
[14:11] <ogra_> oobartez, you can call "snap find" on a xenial desktop
[14:11] <niemeyer> ogra_: Or they need to do what they always did and write in $HOME
[14:12] <ogra_> oobartez, but there isnt much yet (go on, produce some !!!)
[14:12] <ogra_> niemeyer, but home isnt home :)
[14:12] <niemeyer> Some will need to be changed to be optimal, for sure
[14:12] <ogra_> (home isnt the home upstream expects that is)
[14:13] <niemeyer> ogra_: Yep, and for reasons.. We'll learn whether that's a great idea or not over time, but if we change we'll be breaking other use cases..
[14:13] <niemeyer> So no golden answer, as usual in life :)
[14:13] <ogra_> yeah
[14:14] <ogra_> well, my personal golden answer is a first start wrapper that simply knows the vars ... but that needs to be written indeed ...
[14:14] <ogra_> (when you port an app)
[14:14] <oobartez> ogra_: this is what I was thinking ;) just kinda want to figure out what types of apps are already converted, and which ones it'd be best to focus on
[14:18]  * ogra_ now wonders what to do with the 16.04 images ... while the amr arches are rather fine, x86 falls apart on second boot :(
[14:18] <ogra_> *arm
[14:20] <ogra_> i guess i'll wait til monday and sort that with mvo rather than pushing out broken stuff
[14:33] <sergiusens> niemeyer ogra_ when using the `home` interface we should probably change where HOME points to (well someone needs to analyze, but as a first thought seems good).
[14:33] <ogra_> yeah
[14:33] <ogra_> thats kind of what the interface implies :) access to home ... inetad of home/snaps/
[14:34] <jdstrand> dpm: sorry, I was responding to some other issues
[14:34] <dpm> jdstrand, no worries, we've already found that, so 'unping' :-)
[14:35] <dpm> *figured it out, I meant
[14:35] <jdstrand> dpm: do you still need the question answered regarding HOME? (it is via the script in /snap/bin/...)
[14:35] <jdstrand> ok
[14:35] <dpm> all good, thanks
[14:36] <fgimenez> stevebiscuit, should be fixed now, btw lots of interesting stuff in there! :) reminds me of old times, phatomjs, karma, lodash sigh..
[14:39] <dpm> Elleo, I'm not sure if you got your question answered, but I don't think either 'x11' or 'unity7' trigger a manual review. But I think one can double-check that on https://launchpad.net/click-reviewers-tools, which is the same code the store runs
[14:39] <dpm> jdstrand, sorry for the many pings today, but perhaps you can answer that one with more authority ^
[14:40] <ogra_> perhaps you should write the list you mailed to the ML as a blogpost :)
[14:42] <Elleo> dpm: ah, okay; so not really an answer to the x11 criticisms then
[14:42] <jdstrand> they do not trigger a manual review
[14:43] <jdstrand> because that wouldn't help anything (the review would be looking at binaries)
[14:43] <jdstrand> ogra_: pass
[14:43] <jdstrand> :)
[14:43] <Elleo> jdstrand: is there any warning given to users installing apps with x11/unity7 permissions, maybe that'd be at least a reasonable compromise?
[14:44] <jdstrand> people are discussing the messaging
[14:44] <jdstrand> Elleo: not at this time
[14:44] <ogra_> hehe
[14:50] <sergiusens> jdstrand there is no way out of this, right http://pastebin.ubuntu.com/15982675/ ?
[14:51] <sergiusens> jdstrand in the sense that I'll need to patch the code or anything that wants to use QNetworkManager ?
[14:51] <jdstrand> the answer to that is connectivity-api
[14:51] <jdstrand> or let people talk to network-manager and live with the info leak
[14:51] <sergiusens> jdstrand yeah, I figured; so I need to change the code :-)
[14:51] <sergiusens> well first figure it out ;-)
[14:52] <jdstrand> it is hard to take a firm line on the network-manager info leak with GetAll when we are allowing x11
[14:56] <oobartez> is there some place where I could find fairly up-to-date statistics of most downloaded packages from the official ubuntu repos?
[14:57] <oobartez> *desktop
[14:58] <dpm> sergiusens, not sure if you saw the question earlier - so https://github.com/sergiusens/qt5conf works well for binary Qt5 apps, but is there a way to specify a different launch command, for QML apps, for example? Up until now, I've exec'd them so in the wrapper file:
[14:58] <dpm>  cd $SNAP
[14:58] <dpm>  exec $SNAP/usr/bin/qmlscene $SNAP/usr/share/ubuntu-clock-app/ubuntu-clock-app.qml
[15:05] <dz0ny_> it's getting better zdnet: "Ubuntu 16.04's new Snap format is a security risk"
[15:05] <dz0ny_> the gist seems to be that caveat that it is more secure than apt
[15:05] <dz0ny_> and "news" organizations have picked that...
[15:22] <sergiusens> dpm so doesn't `command: qt5-launch qmlscene $SNAP/usr/share/ubuntu-clock-app/ubuntu-clock-app.qml` should work
[15:23] <sergiusens> jdstrand it does ;-)
[15:42] <dougb_> Can anyone offer me some guidance on how to enable the available serial ports on a BeagleBone Snappy?
[15:51] <qengho> dougb_: enable how? To make character devices that could work, or to talk through them from inside a Snap package?
[16:17] <geneios> Does anyone have any resources for using snappy with a python 2.7 project?
[16:21] <kyrofa> geneios, you mean like this? https://github.com/ubuntu-core/snapcraft/tree/master/examples/py2-project
[16:25] <geneios> That is helpful, I was looking at that earlier. This page here https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-parts/ mentions embedding a Python runtime. I guess I was looking for a "Your First Snap" page using python.
[16:27] <kyrofa> geneios, yeah anything that uses the python2 plugin will embed the python2 runtime
[16:28] <kyrofa> geneios, so you should be able to morph that example into what you need
[16:29] <dz0ny_> kyrofa: source: https://github.com/markokr/spongeshaker.git#rev supported in snapcraft
[16:30] <kyrofa> dz0ny_, are you asking me a question? :P
[16:30] <geneios> kyrofa, thanks so much! I am going to give it a try and see what happens.
[16:31] <kyrofa> geneios, no problem-- we're here if you need some help :)
[16:37] <flexiondotorg> ogra_, dpm, niemeyer Just finished work and read the backlog.
[16:38] <kyrofa> Hey jdstrand, just to clarify: that systray example worked for you with no devmode?
[16:38] <flexiondotorg> What if the 'home' plug was really /home/user and a 'data' or 'snapdata' plug were added to provide the current behaviour?
[16:39] <jdstrand> kyrofa: it launched, I saw an icon in the launcher (surely just from the desktop file), I clicked stuff and I say notification bubbles. I don't know if it was supposed to do other stuff
[16:39] <jdstrand> s/I say/I saw/
[16:39] <flexiondotorg> Perhaps 'home' with access /home/user should have manual review.
[16:39] <kyrofa> jdstrand, there wasn't a desktop file included there, but yeah you saw the right stuff... but I only saw it with devmode. Maybe I'm out of date?
[16:39] <flexiondotorg> Where as really confined 'data' apps do not.
[16:40] <kyrofa> (checking now)
[16:40] <jdstrand> kyrofa: I saw a heart in the launcher...
[16:40] <kyrofa> jdstrand, oh, the launcher-- how about in the indicators?
[16:40] <jdstrand> I didn't see anything in the indicators
[16:40] <kyrofa> jdstrand, ah, you're supposed to. Try devmode then?
[16:40] <jdstrand> but the one dbus denial wasn't a Unity 7 denial
[16:41] <jdstrand> it was some kde dbus denial
[16:41] <jdstrand> kyrofa: can you add to the bug more information-- what I'm supposed to see, how I am supposed to see it and any denials?
[16:42] <kyrofa> jdstrand, huh. I'm no indicator expert either, I just _believe_ it's dbus :P . And since it didn't work without devmode I figured it was a unity7 interface issue
[16:42] <kyrofa> jdstrand, yeah I'll try to flesh that out a bit more
[16:42] <kyrofa> jdstrand, also, the indicators-- were they the nice pretty libnotify indicators, or the ugly yellow ones?
[16:42] <kyrofa> Not indicators sorry-- notifications
[16:43] <kyrofa> Because those didn't work without devmode either
[16:44] <jdstrand> kyrofa: the notification bubble was ugly
[16:45] <kyrofa> jdstrand, alright I'll put some links to screenshots in there
[16:45] <jdstrand> thanks!
[16:47] <kyrofa> Anyone else having trouble making their fingers stop after typing "apt" ?
[16:48] <sergiusens> elopio https://github.com/ubuntu-core/snapcraft/pull/484 has conflicts for some reason
[16:57] <niemeyer_> http://blog.labix.org/2016/04/22/snappy-interfaces
[16:59] <roadmr> so, snap install $something fails inside a xenial lxd container, even with nesting and privileged set to true :/ is it desirable to be able to install snaps inside containers?
[17:00] <kyrofa> jdstrand, updated description
[17:09] <dougb_> qengho We have a serial application running on the BBB. We are now using the console port. We want to use one of the other available serial ports, but don't know how to enable them in Snappy Ubuntu.
[17:09] <dpm> niemeyer -> https://plus.google.com/u/2/b/100887841569748798697/+Ubuntu/posts/hUKMDYE9bR9
[17:10] <niemeyer_> dpm: Thanks!
[17:13] <qengho> dougb_: the kernel has to support it. I think you'll get far examining "dmesg" and "lsmod" and comparing to BBB that work for you.
[20:31] <guest1221> Does anyone know if there was a Snappy 16.04 image for IoT devices released yet?
[20:31] <ogra_> not yet
[20:32] <ogra_> the first alpha will likely come out next week
[20:32] <guest1221> Perfect, thanks!
[20:32] <ogra_> there are some experimental image sif you feel brave :)
[20:33] <ogra_> *images if
[20:33] <ogra_> http://people.canonical.com/~mvo/all-snaps/
[20:34] <guest1221> I don't think our code is ready for that yet, but that will help us prepare for the coming changes.  Thanks a lot!
[23:50] <mcphail> stgraber: is it possible to run snappy  within lxc/d yet?
[23:50] <tsimonq2> my bet is yes