[02:31] <wililupy> Question: With snapcraft, is there a way to run make oldconfig when snapping a kernel?
[02:32] <wililupy> Or should I do that before and then run make [menu]config and save the config and point to the kconfigfile in my snapcraft.yaml?
[03:55] <qengho> wililupy: Does "snapcraft help kbuild" answer your question? You should provide your config and snapcraft will run "make oldconfig" after installing it.
[04:02] <wililupy> qengho: That makes more sense now. I was reading that and wasn't quite sure what it meant.
[04:03] <wililupy> I'll give it a shot tomorrow to see how that works since I know that defconfig is very minimal, and I need to add a bunch of kconfigs to make my kernel work.
[04:07] <qengho> wililupy: cool.
[04:08] <wililupy> It's almost easier for me to just follow the directions here: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild and then in menuconfig, save the config and copy it to my snapcraft.yaml location and build using kconfigfile: in snapcraft.yaml.
[04:09] <wililupy> qengho: However, I think the way you mention is cleaner and the better way to do it :)
[04:17] <wililupy> qengho: Or, use the /boot/config-`uname -r` for the kdefconfig: and then use kconfigs: for the specific ones I need since it will then use yes "" | make oldconfig when creating a new .config.
[06:34] <dholbach> good morning
[06:35] <seb128> hey dholbach
[06:35] <dholbach> salut seb128
[06:35] <dholbach> comment ça va?
[06:36] <tsimonq2> hey it's dholbach \o/
[06:36] <tsimonq2> dholbach: how are you?
[06:36] <dholbach> hi tsimonq2
[06:36] <dholbach> good good :) how are you?
[06:36] <tsimonq2> great :)
[06:37] <tsimonq2> dholbach: look at what I've been working on: https://github.com/tsimonq2/lubuntu-distro-snaps
[06:37] <tsimonq2> I have the parts defined, now for the apps tag
[06:37] <seb128> dholbach, good, and you?
[06:38] <dholbach> seb128, I need a bit more mate tea to fully wake up, but I'm doing well :)
[06:38] <seb128> :-)
[06:39] <dholbach> tsimonq2, nice work - so this snap bundles all lubuntu core related packages and their dependencies, is that what it does?
[06:39] <dholbach> tsimonq2, does it work?
[06:43] <didrocks> good morning dholbach, tsimonq2
[06:43] <dholbach> salut didrocks
[06:44] <tsimonq2> o/ didrocks
[06:44] <tsimonq2> didrocks: I might as well show you too :) https://github.com/tsimonq2/lubuntu-distro-snaps
[06:45] <tsimonq2> dholbach: well currently, the lubuntu-core snap is meant to make a very minimal Lubuntu snap
[06:45] <tsimonq2> dholbach: it is pretty much the lubuntu-core metapackage
[06:45] <tsimonq2> !info lubuntu-core
[06:45] <dholbach> tsimonq2, right
[06:45] <tsimonq2> dholbach: it doesn't work right now because I don't have apps: tags yet, working on that now
[06:45] <dholbach> nice
[06:45] <tsimonq2> but soon :)
[06:45] <didrocks> tsimonq2: nice! can't wait to see apps there )
[06:47] <tsimonq2> didrocks: I basically took the .travis.yml and ci-run files from the snappy-playpen repo and modified them to set up Travis for mine
[06:47] <didrocks> yeah, saw that, sweet reuse! :)
[06:47] <tsimonq2> so I'm using your docker container if you don't mind ;)
[06:48] <didrocks> I'm ofc really really upset! :-)
[06:48] <tsimonq2> :P
[06:48] <tsimonq2> hmm, how do I do systemd services?
[06:49] <didrocks> daemon: simple
[06:49] <didrocks> in your apps declaration
[06:49] <didrocks> (look at snapcraft.io, there is an example of this)=
[06:49] <tsimonq2> oh okay thanks :)
[06:49] <tsimonq2> didrocks: I'm asking because the lubuntu-core snap has lightdm
[07:00] <didrocks> dholbach: so, here are 2 new "gtk" parts, sharing most of their code. Reviewed with seb128 and pulling the minimum deps needed for the launcher: https://wiki.ubuntu.com/Snappy/Parts
[07:00] <didrocks> I think I need to migrate it as well to the new wiki for 2.11
[07:01] <dholbach> yes
[07:01] <didrocks> I'm going to integrate then qt4 & 5 to it
[07:01] <didrocks> using the same template
[07:02] <didrocks> dholbach: who should we set as a maintainer for those parts? it's under the ubuntu/ snapcraft
[07:02] <didrocks> we can maybe set it under snapcraft.io ML?
[07:04] <dholbach> didrocks, sounds good
[07:04] <dholbach> didrocks, seb128: nice work!
[07:04] <didrocks> will do :)
[07:04] <didrocks> thx!
[07:06] <seb128> thanks :-)
[07:17] <tsimonq2> alright, apps: tag added, waiting for a build on Travis, and if it works, then it's time to test!
[07:18] <tsimonq2> CC dholbach, didrocks ^
[07:19] <didrocks> tsimonq2: crossing fingers!
[07:19] <tsimonq2> didrocks: tell me about it :D
[07:19] <tsimonq2> didrocks: if you want to cross fingers with me :P https://travis-ci.org/tsimonq2/lubuntu-distro-snaps/builds/141002975
[07:20] <didrocks> tsimonq2: ahah, I have other stressing builds in progress ;)
[07:20] <tsimonq2> didrocks: :)
[07:50] <didrocks> dholbach: do you have snapcraft 2.12 already?
[07:51] <dholbach> didrocks, https://launchpad.net/ubuntu/+source/snapcraft
[07:51] <dholbach> it's in -proposed still
[07:52] <didrocks> dholbach: yeah, the question was if you installed it manually :)
[07:52] <didrocks> (as I'm still on 2.11 and I saw that the wiki parts are already moved, I wondered if you tried it with it)
[07:52] <dholbach> yes, I did for testing one of the sru bugs
[07:53] <didrocks> dholbach: do you mind looking for my "desktop" parts?
[07:54] <didrocks> and ensuring that desktop.gtk2 and desktop.gtk3 returns content?
[07:56] <dholbach> didrocks, http://paste.ubuntu.com/18083742/
[07:58] <didrocks> dholbach: nice!
[07:58] <didrocks> thanks a lot :)
[07:59] <tsimonq2> didrocks: I'm on Yakkety, I got it from the archive, FWIW
[08:01] <didrocks> tsimonq2: sweet! I think the output from dholbach confirms it work, but if you have a minute, do you mind:
[08:01] <didrocks> 1. git clone https://github.com/ubuntu/snapcraft-desktop-helpers
[08:01] <didrocks> cd snapcraft-desktop-helpers/demo/gtk3
[08:01] <didrocks> 2. vi snapcraft.yaml
[08:01] <tsimonq2> s/vi/vim/ *AHEM* ;)
[08:01] <didrocks> 3. replacing "gtk3" with "desktop.gtk3" in the after part
[08:02] <didrocks> 4. trying to snapcraft it :)
[08:02] <didrocks> didrocks@tidus:~$ ls -l /usr/bin/vi
[08:02] <didrocks> lrwxrwxrwx 1 root root 20 mai   28  2012 /usr/bin/vi -> /etc/alternatives/vi
[08:02] <didrocks> didrocks@tidus:~$ ls -l /etc/alternatives/vi
[08:02] <didrocks> lrwxrwxrwx 1 root root 16 août  12  2013 /etc/alternatives/vi -> /usr/bin/vim.gtk
[08:02] <didrocks> -> same on my machine :p
[08:05] <tsimonq2> didrocks: error:
[08:05] <tsimonq2> $ snapcraft cleanbuild
[08:05] <tsimonq2> Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'desktop.gtk3'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache
[08:05] <tsimonq2> I'll run snapcraft update then
[08:06] <dholbach> it still can't be found
[08:06] <didrocks> yeah, you need to refresh
[08:06] <tsimonq2> still :/
[08:06] <didrocks> hum, interesting
[08:06] <didrocks> but the definition appears though
[08:06] <didrocks> as per dholbach's output
[08:06] <didrocks> can be a snapcraft bug?
[08:07] <didrocks> sergiusens: once you are back ^
[08:07] <didrocks> sergiusens: also, I would like to just use the namespace without having to declare a stupid part "desktop, plugin: nil part" ;)
[08:07] <tsimonq2> didrocks: http://img.ctrlv.in/img/16/06/29/577381bf95606.png
[08:08] <didrocks> tsimonq2: did you try "snapcraft define desktop" and "snapcraft define desktop.gtk2" for instance?
[08:10] <tsimonq2> didrocks: http://img.ctrlv.in/img/16/06/29/5773827e686af.png
[08:11] <didrocks> this is after snapcraft update, right?
[08:12] <tsimonq2> yep
[08:13] <didrocks> sergiusens: ^
[09:46] <didrocks> tsimonq2: mind retrying? We may have scheduled importer
[09:56] <tsimonq2> didrocks: sure
[09:58] <tsimonq2> didrocks: \o/ works fine now
[09:59] <didrocks> phew, that was just an importer cron thingy though
[10:00] <didrocks> sergiusens: I guess it worth a mention on this on the wiki page or anything ^
[10:00] <didrocks> thanks tsimonq2
[10:00] <tsimonq2> np didrocks :)
[10:06] <zyga> jdstrand: https://bugs.launchpad.net/snappy/+bug/1597259
[10:06] <zyga> jdstrand: feel free to assign to me if you think this should be in the base template
[10:29] <willcooke> seb128, for my gedit310 snap, I've worked around the missing libs issue, but now I'm getting:
[10:29] <willcooke> (gedit:20800): GLib-GIO-ERROR **: Settings schema 'org.gnome.gedit.preferences.editor' is not installed
[10:30] <willcooke> any suggestions for a way I can work around that one?
[10:32] <ogra_> i think there was work going on for a dbus interface
[10:33] <ogra_> zyga, ^^
[10:39] <zyga> mmm
[10:39] <zyga> so yes, there was some work on gsettings proxy
[10:39] <zyga> but I don't know if this is actually something the proxy would handle, this seems like it wants to access the schema files
[10:40] <willcooke> I've just copied the schema files over from my local fs in to the stage dir and am going to rebuild and see if that helps
[11:30] <seb128> willcooke, do you use the standard gtk wrapper?
[11:31] <willcooke> seb128, yeah
[11:31] <seb128> weird
[11:32] <seb128> can you share the snapcraft.yaml?
[11:37] <willcooke> seb128, https://github.com/8none1/gedit310
[11:38] <seb128> willcooke, oh, you coimmented the prefix option, that's the issue
[11:38] <seb128> it's looking for schemas in the standard location
[11:39] <seb128> and the default prefix from snappy is buggy in that regard
[11:39] <seb128> willcooke, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1590831
[11:39] <willcooke> seb128, hmm, I think I commented them out for a reason, lemme try
[11:40] <seb128> willcooke, it might create issue, did you try to combine it with the organize I suggested?
[11:40] <seb128> let me try to build it with those
[11:43] <willcooke> seb128, hmm
[11:43] <willcooke> it works now :D
[11:43] <willcooke> sorry
[11:43] <seb128> lol
[11:43] <seb128> no worry
[11:43] <seb128> you already rebuilt?
[11:44] <willcooke> seb128, I think I should copy the themes over
[11:44] <willcooke> ah, but... I had to do
[11:44] <willcooke> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./usr/lib/gedit/ gedit
[11:44] <willcooke> so maybe I will need another customer launcher there?
[11:44] <seb128> likely
[11:45] <seb128> I don't know if you can add an env like that in the apps: section of the snapcraft.yaml
[11:45] <willcooke> and for themes, is there and env var for that, and shall I just copy them over from my fs?
[11:46] <seb128> you can stage light-themes
[11:46] <seb128> which is what others do
[11:48] <dpm> hey didrocks, I just noticed your new gtk launchers, good work. Are these ready to replace the 'gtkconf' part?, and if so, do we want to start migrating apps from the playpen to them?
[11:54] <seb128> willcooke, you should also stage libglib2.0-bin for the schemas compile
[11:54] <seb128> dconf-gsettings-backend as well for dconf to work
[11:56] <seb128> willcooke, oh and you want to use the "gsettings" interface, it's not included under unity7
[11:57] <willcooke> seb128, thank you!! Added and rebuilding
[11:58] <seb128> yw
[12:00] <didrocks> dpm: yes and yes :) I just have to give a try at pulseaudio, but the rest is good and should replace yours and so, playpen!
[12:00] <didrocks> dpm: do you know of a good pulseaudio simple demo btw?
[12:01] <willcooke> ooh, new gtk launcher?  didrocks what's new in your one?
[12:01] <dpm> didrocks, cool, you might have done it already, but if not, seb128 had been working on things like translations, you might want to talk to him
[12:01] <didrocks> willcooke: it's based on the existing ones, just cleaned up (like dynamic gtk2/3 detection, keeping xdg cache on upgrade and such) while being able to share base functionality with Qt ones
[12:02] <dpm> didrocks, I don't know any short and sweet pulseaudio off the top of my head, sorry :/
[12:02] <didrocks> dpm: yeah, we did a review on it yesterday evening :)
[12:02] <dpm> pulseaudio *demo, I mean
[12:02] <willcooke> nice one, thanks didrocks seb128
[12:02] <dpm> excellent
[12:02] <didrocks> yeah, that's my issue, seb128 and I are unsure we need to export LD_LIBRARY_PATH to it
[12:02] <didrocks> or add the library itself
[12:02] <didrocks> hence a demo would be great for testing :)
[12:05] <seb128> didrocks, we can maybe have a simple snap with pavucontrol or something
[12:05] <seb128> though playing sound and controling the channels etc is not the same
[12:05] <seb128> so maybe just paplay and ubuntu-sounds
[12:05] <didrocks> seb128: yeah, I had the same issue with pavumeter
[12:06] <didrocks> so yeah, let's try paplay + ubuntu-sounds
[12:07] <seb128> current snapd is buggy though
[12:08] <seb128> you need https://github.com/snapcore/snapd/pull/1359
[12:08] <didrocks> ah?
[12:08] <seb128> which hasn't been rolled out in distro version yet
[12:08] <didrocks> ok, so next snapd
[12:08] <seb128> yes
[12:08]  * didrocks puts that on side thus
[12:08] <didrocks> let enable me creating a placeholder for now
[12:09] <seb128> you can probably try a daily snapd if you want
[12:09] <seb128> is the next version due tomorrow?
[12:09] <didrocks> I think it is
[12:09] <didrocks> and I have enough with working on helping others + qt4/5 launchers + converting existing stuff for keeping me occupied until then :)
[12:11] <seb128> yeah
[12:19] <didrocks> dpm: willcooke: oh, also another difference on this launcher: it's pulling the base launcher dependencies for you, so no need to overload them anymore in your parts (build- and stages-)
[12:20] <willcooke> nice!
[12:20] <willcooke> didrocks, where can I see a list of those?
[12:21] <didrocks> willcooke: snapcraft 2.11 or 2.12?
[12:21] <didrocks> it's built in in 2.12, but the definition is taken from https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml
[12:22] <didrocks> it's strictly the launcher requirements + what flavor you wants (gtk2 or gtk3 here)
[12:23] <willcooke> didrocks, thanks!
[12:23] <seb128> didrocks, just curious but what's the desktop part about?
[12:23] <willcooke> willcooke, grep - new gtk launcher list of packages - ^
[12:23] <seb128> it only has a nil plugin
[12:25] <didrocks> seb128: nothing, but it seems to be required to have then desktop.<something> namespace
[12:25] <didrocks> I feel that's a snapcraft bug, it shouldn't
[12:26] <seb128> you mean you can't name a part desktop.gtk3?
[12:26] <seb128> directly
[12:26] <didrocks> not if there is no desktop part
[12:26] <seb128> I see
[12:27] <seb128> but your parts are named gtk2/gtk3
[12:27] <didrocks> yeah, see https://wiki.ubuntu.com/snapcraft/parts
[12:27] <seb128> how do they translate to their real name?
[12:27] <seb128> is that from the wiki?
[12:27] <didrocks> you have a project-part: desktop
[12:27] <didrocks> then, for exposing other parts, it's parts: [gtk2, gtk3]
[12:27] <seb128> I see
[12:27] <didrocks> which is using the project-part namespace
[12:27] <seb128> similar to the commands
[12:27] <didrocks> I read it from http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
[12:28] <didrocks> yes
[12:28] <seb128> thanks
[12:28] <didrocks> I find it counter-intuitive though
[12:28] <didrocks> yw
[12:28] <seb128> I'm that blogpost in my list of things to read
[12:28] <seb128> going to do that now ;-)
[12:28] <didrocks> and you can even see sergio had the same issue with mttq btw :p
[12:28] <didrocks> mqtt*
[12:28] <seb128> :-)
[12:28] <didrocks> heh, happy reading!
[12:55] <jdstrand> zyga: 1597259 already has a PR
[12:57] <jdstrand> zyga: hehe, and you merged it (https://github.com/snapcore/snapd/pull/1435)
[13:00] <kyrofa> jdstrand, is it a known issue that a home dir mounted via NFS results in u-c-l denials trying to create the user data directory?
[13:04] <zyga> jdstrand: ohh, right
[13:04] <zyga> jdstrand: that's good
[13:04] <zyga> jdstrand: release is today
[13:12] <willcooke> seb128, halp!  I just did a snapcraft clean and then tried to rebuild that snap....  libtool: warning: 'libgedit-private.la' has not been installed in '/usr/lib/gedit'
[13:12] <willcooke> I don't get it, it was working find a moment ago :)
[13:12] <seb128> urg
[13:12] <seb128> dunno about this one
[13:13] <willcooke> seb128, I think this is why I commented out the prefix stuff originally
[13:13] <willcooke> stupid brain can't remember though
[13:14] <willcooke> Will play with it...
[13:14] <seb128> doesn't make sense why gedit would fail to build with a prefix
[13:14] <willcooke> make[3]: Entering directory '/home/will/source/gedit/gedit310/gedit310/parts/gedit/build/gedit'
[13:14] <willcooke>  /bin/mkdir -p '/usr/bin'
[13:14] <willcooke>   /bin/bash ../libtool   --mode=install /usr/bin/install -c gedit '/usr/bin'
[13:14] <willcooke> libtool: warning: 'libgedit-private.la' has not been installed in '/usr/lib/gedit'
[13:14] <willcooke> libtool: install: /usr/bin/install -c .libs/gedit /usr/bin/gedit
[13:14] <willcooke> Makefile:879: recipe for target 'install-binPROGRAMS' failed
[13:15] <willcooke> could be a makefile issue
[13:16] <jdstrand> kyrofa: heh, that would not surprise me. what is the denial?
[13:17] <kyrofa> jdstrand, http://pastebin.ubuntu.com/18097641/
[13:20] <jdstrand> kyrofa: I think that is going to be fixed in the pending upload because that directory will no longer be created by the confined launcher
[13:20] <kyrofa> jdstrand, ah right, snap run
[13:20] <kyrofa> jdstrand, that would be operating under a similar profile?
[13:20] <kyrofa> won't rather
[13:20] <jdstrand> it is unprivileged
[13:21] <jdstrand> I don't believe it has a profile
[13:21] <jdstrand> zyga: can you comment? ^
[13:22] <kyrofa> Alright good deal
[13:22] <kyrofa> Thanks jdstrand!
[13:38] <zyga> jdstrand: looking
[13:40] <zyga> jdstrand: I'm not sure what to make of it
[13:40] <zyga> jdstrand: which directory is no longer created, I don't see anything that snap would create?
[13:44] <jdstrand> zyga: ~/snap/foo/... is no longer created by snap-confine. The question is, what is doing that now (assuming 'snap-run') and is that thing confined (assuming not)
[13:46] <zyga> hmmmm
[13:46] <zyga> I don't think it is doing that
[13:46] <zyga> ah, wait, snap run might be indeed doing that
[13:48] <juanrubio> hi all, I'm wondering if anyone would know why there is a 'parts/myapp/install' and a 'parts/myapp/installlib' folders?. My app contains a mix of c, c++ and python libs and the python modules show up in the 'installlib' dir.
[13:48] <mhall119> sergiusens: did you see my response last night?
[13:48] <sergiusens> mhall119 yes, thanks
[13:53] <mhall119> sergiusens: will that make it into the next snapcraft release?
[13:59] <didrocks> tsimonq2: did you retried with 2.12?
[13:59] <didrocks> retry*
[13:59] <zyga> jdstrand: what confused me is this: name="/home/xcore/mberger/
[13:59] <didrocks> sergiusens: hey, I still don't see my desktop. parts appearing on https://parts.snapcraft.io/v1/parts.yaml
[13:59] <zyga> jdstrand: that's not a $HOME/snap/$SNAP_NAME
[13:59] <didrocks> sergiusens: should I start getting nervous? :)
[13:59] <didrocks> (I updated the wiki this morning, like 7h before)
[14:00] <juanrubio> for some reason I get my python modules in 'parts/mayapp/installlib/python2.7' and I would expected to show up in 'parts/mayapp/install/lib/python2.7'
[14:00] <juanrubio> .. is this a snapcraft bug?#
[14:00] <juanrubio> .. is this a snapcraft bug?
[14:01] <jdstrand> zyga: no, it isn't. the user is using an alternative directory for HOME which would be a problem if the process creating the dir is confined, but it isn't any more aiui
[14:01] <didrocks> juanrubio: do you use the python plugin? if so, I would says it can be, sergiusens ^
[14:01] <jdstrand> zyga: fyi, not sure if this could be snuck in: https://github.com/snapcore/snapd/pull/1441
[14:01] <jdstrand> zyga: if not, 2.0.11 is fine
[14:02] <zyga> jdstrand: checking
[14:02] <juanrubio> I'm using the autotools plugin.. all my project built with autotools
[14:02] <didrocks> ah, and you stage-packages: [python2] ?
[14:03] <didrocks> I guess if it's in install/ it's due to your build tools installing them there
[14:05] <juanrubio> when I build everything outside snapcraft with make, make install, the python packages are installed under 'prefix/lib/python2.7'
[14:07] <juanrubio> didrocks: I stage with a fileset, 'libraries: lib/*', but the python packages got installed in 'parts/installlib/python2.7'
[14:08] <didrocks> juanrubio: interesting, maybe sergiusens could have a look later in if you post your snapcraft.yaml here :)
[14:09] <didrocks> and maybe open a bug report against snapcraft on launchpad about it? https://launchpad.net/snapcraft
[14:09] <didrocks> (post your snapcraft.yaml there)
[14:10] <juanrubio> my file is here is anyone wants to have a look: https://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml
[14:10] <juanrubio> I've just started with this, so I'm probably getting something wrong...
[14:11] <didrocks> hum
[14:11] <didrocks>       modules:
[14:11] <juanrubio> I'll open the ticket in launchpad as well... thanks
[14:11] <didrocks>         - installlib/python2.7/dist-packages/*.py
[14:11] <didrocks> this is due to the wrong install path I guess you are encountering :)
[14:12] <juanrubio> didrocks: yes, that was an attempt to get the python modules staged, but that does even work... if you remove that line, there is no change
[14:12] <didrocks> yeah, I guess open the ticket with your clean snapcraft.yaml
[14:12] <didrocks> (without this then)
[14:12] <didrocks> I'm sure we'll get to it quickly
[14:12] <juanrubio> sure, I will, thanks again!
[14:12] <didrocks> your .yaml looks good otherwise
[14:12] <didrocks> yw! :)
[14:13] <didrocks> just a tip: you don't need source-type: git
[14:13] <didrocks> as you ended up your url with .git, snapcraft is smart enough for this :)
[14:13] <juanrubio> great, I'll remove that too
[14:20] <kyrofa> juanrubio, you might try providing --prefix=/ as a configflag to see if anything chnges
[14:21] <juanrubio> let me try that
[14:41] <juanrubio> kyrofa: that worked beautifully.. now my python packages are under 'parts/tizonia/install/lib/python2.7/site-packages'
[14:41] <juanrubio> should I still open the launchpad bug report?. can do if that helps...
[14:42] <kyrofa> juanrubio, good deal. Means the problem is within the build system for that project, not snapcraft
[14:43] <juanrubio> I see, I'll have to investigate that...
[14:44] <juanrubio> ...but for now I have a solution in place... so now on to another question:
[14:44] <sergiusens> elopio any idea when our infra will catch up with the repo move?
[14:44] <sergiusens> mhall119 yes
[14:45] <sergiusens> didrocks did it show?
[14:45] <sergiusens> didrocks I see some issue from the parser, josepht mind looking?
[14:46] <juanrubio> what would be the best practice here... my project depends on some pip packages, e.g. gmusicapi, these change rapidly, so no chance I can get them as debs... can I add parts that download and install these python modules using pip?
[14:48] <ogra_> kyrofa, i'm just answering a question about the nextcloud snap and was wondering if you wouldnt like to add another blog post about how to migrate your data from a former install to the shiny new snappy system
[14:48] <juanrubio> I could not find a snapcraft 'demo' project with 'pip' in it.. if there is one, I would appreciate pointers..
[14:48] <kyrofa> ogra_, that's a good idea, thanks!
[14:48] <ogra_> (for people coming from classic etc)
[14:50] <elopio> sergiusens: we are waiting for niemeyer to add the bot to the team.
[14:50] <elopio> everything else seems good.
[14:50] <niemeyer> Doing that now
[14:51] <sergiusens> elopio coveralls as well?
[14:51] <niemeyer> @elopio What bot do you want there?
[14:51] <nothal> niemeyer: No such command!
[14:52] <didrocks> sergiusens: thx for looking at it with josepht :)
[14:53] <niemeyer> sergiusens: What bot do you want there?
[14:53] <josepht> sergiusens: I'll take a look
[14:53] <niemeyer> sergiusens: I also added you as a team maintainer now, so you should be able to do that yourself btw
[14:54] <wililupy> Is there a way to create a udev rule in my snap so that it is installed in /etc/udev/rules.d?
[14:54] <wililupy> Or should I just use the copy plugin?
[14:55] <ogra_> how would the copy plugin help ?
[14:55] <ogra_> you cant copy anything outside of your snap root
[14:55] <josepht> didrocks, sergiusens: fwiw, there's a tab in the wiki.
[14:55] <wililupy> Ahh, gotcha ogra_
[14:56] <sergiusens> niemeyer oh goodie, thanks. For the bot name we have to wait elopio to provide it though
[14:56] <ogra_> wililupy, i know there were discussions beween zyga and jdstrand about udev rules in snaps, not sure where that ended
[14:57] <elopio> niemeyer: snappy-m-o.
[14:57] <niemeyer> sergiusens, elopio: Coveralls enabled, repo token dJaU2S3FSEyMoRkrV4bxhOmIjOUyWMbBq
[14:57] <elopio> niemeyer: hum, the token should be secret :) Can you regenerate it and send it privately, please?
[14:57] <niemeyer> elopio: Yeah, I know.. public channel, duh
[14:58]  * ogra_ lols
[14:58] <didrocks> josepht: outrageous! :)
[14:58] <jdstrand> ogra_: what we talked about was less about that and more about enumerating devices and files from udev queries. most of what you referred to would be in the gadget snap realm which afaik is still being designed
[14:58] <niemeyer> elopio: You got a new one privately
[14:58] <didrocks> josepht: feel free to change it
[14:58] <ogra_> jdstrand, ah, i thought there was a discussion about udev rules to allow symlinks so apps find the properly named devices etc
[14:59] <ogra_> which wuold kind of touch that area
[14:59] <niemeyer> elopio: Any chance we can stop snappy-m-o from spamming everyone on GH issues?
[14:59] <josepht> didrocks, sergiusens: nm, that was me being dense.
[14:59] <niemeyer> Alternatively, can we rename it to spammy-m-o?
[15:00] <jdstrand> ogra_: I recall that, but that isn't something I'm personally driving is all I meant
[15:00] <ogra_> ah
[15:01] <elopio> niemeyer: not if you want to keep the jenkins tests running. If you are ready to disable those tests, I can disable the bot for snapd.
[15:02] <niemeyer> elopio: I was hoping we could get the bot fixed instead of disabling it
[15:03] <elopio> niemeyer: that would require patching the jenkins plugin, which is an ugly java thing. We can do it, but not this week. Report a bug and we'll get to it.
[15:03] <niemeyer> Report where?
[15:03] <elopio> niemeyer: short term solution, add people to the whitelist.
[15:04] <elopio> niemeyer: github.com/ubuntu-core/snappy-jenkins
[15:04] <niemeyer> elopio: Doesn't work.. the bug reference I mentioned to you had "add to whitelist" on the history, and it continued nevertheless
[15:05] <niemeyer> elopio: https://github.com/snapcore/snapd/pull/1379
[15:05] <elopio> niemeyer: when you comment add to whitelist, it is stored in the jenkins running instance. But it is redeployed often. In order to add to the whitelist permanently, it needs to be changed in the source of the job: https://github.com/ubuntu-core/snappy-jenkins/tree/master/containers/jenkins-master/config/jobs
[15:06] <niemeyer> I guess we should just work to take down that tool altogether then..
[15:06] <elopio> also, people from the team snapcore should be whitelisted, so alternatively you can add people there. I see a bug, that we didn't update from ubuntu-core there, I'll quickly change that.
[15:07] <elopio> niemeyer: that works too. I don't enjoy jenkins. But we need a tool for general pipelines and triggers.
[15:08] <niemeyer> I'm talking about that java plugin, not jenkins, to be clear
[15:08] <josepht> didrocks, sergiusens: I had to upgrade the snapcraft code on the parts service.  The desktop parts are now in the parser output
[15:09] <didrocks> nice! thanks josepht
[15:09] <josepht> didrocks: np
[15:10] <elopio> niemeyer: I'm not sure if there's a way to do it differently. Improve the plugin can be done for sure, but some things are just blocked by jenkins architecture. Like stopping a test if a newer push arrived, that's not doable in a nice way, afaik.
[15:10] <elopio> sergiusens: niemeyer: PR tests are working as before. Thanks!
[15:11] <elopio> niemeyer: can you please disable the coveralls comment? There's a switch in the settings page.
[15:12] <niemeyer> elopio: It's software.. everything is doable.. the question is how much we care to fix it
[15:13] <niemeyer> elopio: Comments disabled
[15:13] <elopio> ty.
[15:14] <niemeyer> https://github.com/ubuntu-core/snappy-jenkins/issues/184, FWIW
[15:17] <sergiusens> elopio kyrofa please don't merge anything just yet
[15:18] <elopio> sergiusens: ack
[15:35] <joc_> sergiusens: with respect to python3 plugin not creating entry_points, i filed a bug, and proposed this alternative to using pip3 --target https://github.com/snapcore/snapcraft/pull/614
[15:35] <sergiusens> joc_yup cwayne already got me up to speed
[15:35] <joc_> ah cool
[15:36] <sergiusens> joc_ I do recall tedg debating wether to use root or target there. I guess this outweighs the original logic
[15:38] <tedg> sergiusens: Haha, I think I used root and you changed it! ;-)  (I have no clue why I used root though really, probably cargo culted it from somewhere)
[15:39] <tedg> Interesting that you can pass an install option like that, that was probably the bug with my implementation.
[15:39] <joc_> sergiusens: tedg obviously would appreciate you checking the command i used
[15:41] <tedg> joc_: Oh, not me. Everything I know about python is because barry answered a question about it for me.
[15:54] <elopio> didrocks: you added gtk and gtk3 to the old wiki. 2.12 uses wiki.ubuntu.com/snapcraft/parts instead.
[15:56] <elopio> didrocks: scratch that, I'm just not subscribed to the new one :)
[15:56] <elopio> *was
[15:58] <roadmr> jdstrand: hey, reviewer-tools r687 is live on the store \o/
[15:58] <didrocks> elopio: heh :)
[16:08] <jdstrand> roadmr: woohoo! :) thanks
[16:22] <tsimonq2> elopio: hey, ping, you around?
[16:36] <tsimonq2> sergiusens: what does it mean to have a bug nominated for a release of snapcraft? does that mean that all the bugs targeted have to be fixed for the release? how does a bug get nominated?
[16:37] <tsimonq2> sergiusens: ( https://launchpad.net/snapcraft/+milestone/2.13 for example)
[16:41] <sergiusens> tsimonq2 we like to have a fixed focus to work on
[16:41] <sergiusens> tsimonq2 nothing is really set in stone though. And yes, the goal is to try and fix them for the next release
[16:44] <sergiusens> tsimonq2 do you have something in mind that you would want to tackle?
[16:50] <tsimonq2> sergiusens: just a couple suggestions :) bug 1590807 bug 1596777
[16:50] <tsimonq2> sergiusens: both assigned to me
[16:51] <tsimonq2> sergiusens: I'll get them fixed for 2.13, I was just wondering if you wanted to tag them
[16:57] <sergiusens> tsimonq2 the first one might be tricky to get in to 2.13 timing wise, but yes do work on it
[16:57] <sergiusens> tsimonq2 I'll just move to 2.14 if not done in time
[16:57] <sergiusens> tsimonq2 Ideally our milestones last 1 week, give or take depending on holidays, sickness, unexpected issues, etc.
[17:03] <tsimonq2> sergiusens: ah okay, it's been slow recently?
[17:03] <tsimonq2> just looking at https://github.com/snapcore/snapcraft/releases :)
[17:04] <sergiusens> tsimonq2 yes, travel and holidays account for that ;-)
[17:04] <tsimonq2> sergiusens: alright :)
[17:08] <tsimonq2> sergiusens: elopio gave a +1 on https://github.com/snapcore/snapcraft/pull/616 , can you second that?
[17:15] <niemeyer> jdstrand: New spread snap up for review..
[17:16] <jdstrand> niemeyer: was it not auto-approved? I don't see it
[17:17] <niemeyer> jdstrand: IT WAS \o/
[17:17] <jdstrand> nice :)
[17:17] <jdstrand> the review tools branch landed a bit earlier today for that
[17:18] <niemeyer> First time in my life I upload something that is available on Ubuntu without manual interaction!
[17:18]  * niemeyer does the happy dance
[17:18] <jdstrand> congrats! :)
[17:18] <niemeyer> jdstrand: ... to us all! ;)
[17:18] <ogra_> s/happy/snappy/ no ?
[17:18] <jdstrand> :)
[17:18] <jospoortvliet> jamiebennett - any clue on the timeline for the first Core release?
[17:19] <jospoortvliet> as in, a clue you're willing to share, I'm sure you know how/where things stand :D
[17:19] <jospoortvliet> I'm asking to get an idea when we could do the first Nextcloud Pidrive version for end users ;-)
[17:20] <jospoortvliet> (the WD Labs collaboration we have, continueing from ownCloud)
[17:22] <ogra_> jospoortvliet, i'd guess still a few weeks til the first images appear ... and then 4-6 additional weeks til we call it a stable release (provably more, probably less), we explicitly didnt put to many constraints on this to make sure we do it the debian way "when it is ready and rocksolid"
[17:22] <ogra_> if you need something to play with you can use an rpi server install in the meantime, it comes with snap support too :)
[17:23] <ogra_> http://cdimage.ubuntu.com/releases/16.04/release/ubuntu-16.04-preinstalled-server-armhf+raspi2.img.xz ...
[17:23] <jospoortvliet> ogra_: well the thing is, we want to ship this on a product to users so it's not a great idea to have something we're not 100% confident about ;-)
[17:24] <jospoortvliet> it isn't a super critical thing on one hand, but upgrades have to work entirely smooth and I'm guessing that that is the hard part right now?!?!
[17:24] <ogra_> yeah, understood
[17:24] <ogra_> we are making damned sure that the images we will release will always be upgradeable indeed ;)
[17:25] <jospoortvliet> it's the big draw of snappy, from my perspective
[17:25] <ogra_> that is also the reason we are still holding back, kernel and gadget snaps are not 100% finalized ... as long as they can change there is a potential risk you need to re-flash
[17:25] <jospoortvliet> that way you can have a zero maintenance solution for end users
[17:25] <ogra_> yeah, thats the plan
[17:25] <jospoortvliet> excellent
[17:25] <jospoortvliet> so you're saying 2-3 months still, though
[17:25] <jospoortvliet> or am I reading it too pessimistically?
[17:26] <ogra_> i say less than a month for the first images where we can say "yu dont need to re-flash, but it is probably not feature complete and has bugs"
[17:26] <ogra_> so you could start prototyping by that date ... but not push it to production yet
[17:27] <jospoortvliet> ach, minor bugs aren't a huge deal, we'll update in production :P
[17:27] <ogra_> :)
[17:27] <jospoortvliet> the first 500 devices we'll sell are still kind'a pioneer devices
[17:27] <jospoortvliet> so that 'under a month' is good enough for us. We just want to be able to fix everything automatically rather than requiring a re-flash
[17:27] <ogra_> cool ...
[17:28] <ogra_> dont nail me down on it though :) thats just a guesstimate
[17:28] <niemeyer> jospoortvliet: What sort of device is it, out of curiosity?
[17:28] <ogra_> niemeyer, the Wd thingie we worked on with owncloud ... a NAS type device
[17:28] <jospoortvliet> it is a WD PiDrive with custom box (with Nextcloud logo), 1TB hard drive. On the SD/Harddrive will be Core with Nextcloud.
[17:29] <jospoortvliet> bring-your-own-Pi
[17:29] <ogra_> with owncloud preinstalled (now with nextcloud i guess :) )
[17:29] <jospoortvliet> yeah...
[17:29] <jospoortvliet> the new box is compattible with oDroid C2, btw, that gives it quite some more power.
[17:29] <ogra_> niemeyer, https://owncloud.org/blog/wd-labs-raspberry-pi-owncloud-and-ubuntu/
[17:29] <niemeyer> Thanks, and nice!
[17:32] <jamiebennett> jospoortvliet: Sorry, was just grabbing dinner. I think ogra_ has told you all the rationale behind the decision to get things right before final release. I would not go to production without our final release though unless your customers are PoC/early adopters. Still, there will be pain. I think by the end of July is optimistic so don't plan around that just yet. Of course you can use classic for now.
[17:33] <jospoortvliet> well, we're doing a small batch for about 500 people. They will be able to deal with bugs, even a potential dataloss issue (rather not, of course) as long as they don't need too many skills to get it fixed. That is, if the auto-upgrade works and can be used to fix issues, we're good for the early adopters.
[17:34] <jospoortvliet> after them we will do a bigger batch of course
[17:35] <jospoortvliet> Basically I'm happy to warn people to not yet use the devices for super important files and backup regularly as long as I can promise that if they just wait the software will improve.
[17:48] <sergiusens> kyrofa josepht care to review https://github.com/snapcore/snapcraft/pull/615/files ?
[17:49] <GeoffW> I'm struggling to get the Snappy image working on a Raspberry Pi - anybody know what I'm doing wrong?!
[17:57] <jamiebennett> jospoortvliet: OK. Happy to work with you on the details nearer the time.
[18:49] <svij> do I understand correctly that "parts" in snapcraft 2.12 can be some kind of librarys/dependencies of another snap?
[18:55] <kyrofa> svij, yes, but only build-time dependencies. They still get bundled for run-time
[18:56] <svij> ah
[18:56] <svij> that would have been my follow up question :)
[18:56] <kyrofa> svij, the idea is that library devs can ship parts that essentially tells snapcraft how to best build it
[18:57] <svij> right
[19:07] <szszszsz> hi! I have made something bad apparently. After snappy package installation I do not have commands in my path. Do you have any tips?
[19:08] <szszszsz> It worked before I have purged snapd and used reset script
[19:09] <szszszsz> By no commands I mean no possibility to run applications installed with snappy from command line
[19:11] <szszszsz> (mentioned reset script https://github.com/zyga/devtools/blob/master/reset-state)
[19:17] <szszszsz> alternatively, could someone tell me how to run snap application when its not in the path? should I search /snap/ for a wrapper to run or somewhere else?
[19:29] <netphreak> what's the latest version of snaps?
[19:29] <netphreak> snapd?
[19:32] <sergiusens> netphreak if you are on ubuntu, just run `rmadison snapd`
[19:32] <sergiusens> for xenial  snapd | 2.0.9       | xenial-updates   | source, amd64, arm64, armhf, i386, ppc64el, s390x
[19:35] <szszsz_> @szszszsz ^ reboot has helped (its like with windows, yay!)
[19:35] <nothal> szszsz_: No such command!
[19:36] <szszsz_> u dont say
[19:37] <netphreak> thx
[19:48] <thomi> hi everyone. I'm trying to help an upstream snap something that requires wxPython 2.8. It seems I need to build this from source (it's not in pypi), but that requires building wxPython, wxWidgets, Gtk, glib, atk, gobject-introspection and a whole bunch more.
[19:48] <thomi> My question is - is there an easier way that creating a part for each library in the chain?
[19:48] <thomi> I'm guessing the answer is 'no', but thought I'd ask anyway
[20:00] <mhall119> sergiusens: kyrofa: when a snap's binary looks at /usr/ does it see /snap/<snap>/current/usr/ or the actual /usr/ on the host?
[20:00] <kyrofa> mhall119, the actual /usr/
[20:00] <kyrofa> mhall119, we're experimenting with ld preload stuff to change that, but that's the way it is right now
[20:01] <mhall119> ok, thanks
[20:06] <sergiusens> thomi can't you use the glib/gtk in xenial
[20:06] <thomi> sergiusens: no, it's too new (3.x vs 2.x)
[20:07] <sergiusens> mhall119 kyrofa also, "actual user on the host" is the core snap, not the classic ubuntu system
[20:07] <thomi> sergiusens: and anyway - wouldn't that break confinement?
[20:07] <kyrofa> sergiusens, ah yes, thank you
[20:07] <sergiusens> thomi it wouldn't break confinement, they'd be added to the resulting snap (automagically if using build-packages)
[20:08] <sergiusens> thomi I have some ideas about prebuilt parts kind of like docker layers
[20:08] <sergiusens> but that is still in dreamland
[20:10] <thomi> sergiusens: ahh, gotchya
[20:14] <mhall119> sergiusens: ok, still doesn't help me though, will find a work-around
[20:17] <tsimonq2> sergiusens: would you be able to point out the obvious here? I'm not getting how to fix this and it seems really obvious. I have https://github.com/tsimonq2/snapcraft/tree/downloaded-files-checksum-bug-1585913 built on Travis here: https://travis-ci.org/tsimonq2/snapcraft/builds/140983815 and I'm missing where to define source_checksum. It's a work in progress fix of bug 1585913
[20:25] <sergiusens> elopio https://github.com/snapcore/snapcraft/pull/617 can you tell me how to get the FakeLogger to not show urllib logs?
[20:29] <elopio> sergiusens: with a filter maybe? http://stackoverflow.com/a/879937/2665322
[20:32] <elopio> from that link, I have no idea what you are trying to do.
[20:32] <sergiusens> tsimonq2 you need to update all the constructors and their call to super https://github.com/tsimonq2/snapcraft/commit/273c8fde9f59dfb3f66f8a68a86911d6aac0b84b#diff-e6205a80af76b4faec1d9241dc3b3b7cR160
[20:33] <sergiusens> tsimonq2 also, please use the checksum python module instead of subprocess
[20:34] <sergiusens> tsimonq2 something like https://github.com/snapcore/snapcraft/blob/master/snapcraft/storeapi/__init__.py#L209
[20:35] <tsimonq2> thanks sergiusens for the feedback :)
[20:35]  * tsimonq2 sleeps
[21:02] <sergiusens> elopio the fixture code seems to not like what I have to say
[21:47] <popey> sergiusens: congratulations on the snapcraft release!
[21:55] <mcphail> Trying the gedit snap from Will Cooke's G+ posting. There is still an issue with snappy where an invoked snap "cd's" to the install directory, thereby messing up paths supplied as parameters. Is there a plan to fix or change this?
[21:57] <popey> i filed a bug for that
[21:57] <mcphail> popey: great. Can you link so I can +1 it?
[21:57] <popey> hmm
[21:57] <popey> i filed one against qt launcher
[21:57] <popey> https://github.com/sergiusens/qt5conf/issues/3
[21:58] <popey> i guess the gtk-launch also has the issue
[21:58] <popey> cd $SNAP
[21:58] <popey> exec "$@"
[21:58] <popey> yup
[21:59] <mcphail> Yes, the bug ismore generic than that. I think Imoaned on here about it a year ago when I was making a silversearcher snap
[21:59] <popey> ok, will poke people tomorrow about it
[21:59] <popey> it breaks a bunch of things, you're not alone
[21:59] <mcphail> ta.
[21:59] <popey> np
[21:59] <popey> thanks for testing that with the gtk launcher!
[22:00] <popey> i dont actually know where the upstream for gtk-launch is
[22:00] <mcphail> looks neat. Don't know how we're going to get around the --devmode flag though