[00:35] <erio> Hi
[00:35] <erio> I lost connection later...
[04:26] <stevebiscuit> kyrofa: great post, cheers!
[04:27] <ayan> stevebiscuit: which article?
[04:32] <stevebiscuit> ayan: I'm in the process of getting Launchpad to build snaps of WebDM so this was useful: https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way
[04:39] <ayan> stevebiscuit: ah -- that is useful.
[07:16] <dholbach> hey hey
[07:18] <didrocks> morning dholbach
[07:19] <dholbach> salut didrocks
[07:26] <seb128> lut dholbach
[07:26] <dholbach> salut seb128
[07:29] <seb128> dholbach, did you change from https://github.com/ubuntu/snappy-playpen/commit/7c6f2275 work as you wanted?
[07:29] <seb128> I though about that yesterday evening and now I see you already did it :p
[07:33] <dholbach> no, it doesn't :-/
[08:27] <zyga> o/
[08:28] <joc_> morning zyga
[08:38] <joc_> zyga: just a reminder that I would like your feedback on latest serial interface, when you have time :)
[08:42] <_morphis> zyga: snapcraft@lists.ubuntu.com being the right one these days to discuss that?
[08:45] <zyga> joc_: I know, believe me
[08:45] <zyga> _morphis: yes, I think so
[08:46] <_morphis> zyga: ok
[08:46]  * zyga had a super rough night, is barely awake
[08:46] <_morphis> .-)
[08:47] <joc_> zyga: sure, look after yourself
[11:39] <pmp> I asked this two weeks ago and couldn't work on it - as things are changing fast currently I'm asking again ;-)
[11:40] <pmp> I'd like to boot a custom kernel (4.7-rc2) for raspberry pi2
[11:40] <pmp> I build one for raspian and it works as I'd like to
[11:41] <ogra_> use snapcraft and the snapcraft kernel plugin to create a snap
[11:42] <ogra_> here is a demo snapcraft.yaml using that plugin https://github.com/ubuntu-core/snapcraft/tree/master/demos/96boards-kernel
[11:44] <pmp> ogra_: thx, that's what you told me two weeks ago, I somehow hope there now a faster-better-newer way to do it - OK I go with snapcraft
[11:47] <ogra_> pmp, i doubt there will be any easier and faster way (i actually doubt it is easier to solve than via such a snapcraft.yaml )
[11:48] <pmp> ogra_: iirc, you told me that currently the pi2-kernel.snap is generated as a side-product of the deb-build
[11:48] <ogra_> nope
[11:48] <ogra_> it is created as a side product of the os snap build
[11:50] <pmp> is there a dedicated snapcraft.yaml in there for building a kernel for pi?
[11:50] <seb128> dholbach, sorry I didn't see you reply earlier, what doesn't work?
[11:50] <seb128> with the troltech conf
[11:52] <pmp> ogra_: I'm afraid starting from the 96boards-kernel won't give me a nice working snap...
[11:52] <ogra_> pmp, well, it works for many other people ... why do you think it wouldnt work for you ?
[11:53] <pmp> ogra_: good question ;-)
[12:18] <dholbach> seb128, copying the file over
[12:23] <seb128> dholbach, I can have a look if you want
[12:23] <pmp> ogra_: actually what I meant was I don't know what to put into the snapcraft.yaml
[12:24] <pmp> ogra_: I'd like to use the standard raspi2-kenrel and just add the missing CONFIG_'s
[12:24] <dholbach> seb128, it's basically https://github.com/ubuntu/snappy-playpen/tree/musique/musique
[12:25] <ogra_> pmp, well, isnt the snapcraft.ymal in the demo self explaning ? ...
[12:26] <seb128> dholbach, k, just finishing something else and having a look
[12:27] <dholbach> thanks a lot seb128
[12:27] <ogra_> for defconfig: [defconfig, distro.config] you probably only want "defconfig" and define the additional bits in kconfigs ... you wont need any initrd firmware so you can remove that block and can also drop the last few lines that are about specific dragonboard firmware
[12:27] <seb128> dholbach, yw!
[12:27] <ogra_> and indeed you want to point the source option to your own kernel tree
[12:27] <ogra_> (as well as adjusting the device trees to point to the right ones)
[12:30] <pmp> ogra_: you see, not that easy.. for example: dtbs/overlays.tgz
[12:30] <ogra_> ignore that for the start
[12:30] <pmp> no, I need an overlay
[12:30] <ogra_> well, but the rpi doesnt allow overlays anywhere but in the bootloader ... so they need to go into the gadget snap anyway
[12:31] <ogra_> so ignore that bit ... you will later need to use your own gadget for that
[12:31] <ogra_> *after* you have a kernel snap that boots
[12:31] <pmp> ok
[12:32] <ogra_> ('m currently trying to play with the new dtb loading feature from uboot, that might solve this issue but it is still in its early stages)
[13:15] <bsperes> What is the correct way to go about deleting the default ubuntu user from snappy? I'm able to create a new user using useradd with the --extrausers flag, but there doesn't seem to be such a flag for the userdel comand.
[13:15] <seb128> dholbach, the config file is there for me ... what error do you get?
[13:15] <dholbach> seb128, can you launch musique?
[13:15] <seb128> yes
[13:15] <dholbach> oh?
[13:16] <dholbach> in my case it explodes and wants to access /etc/xdg/Trolltech.conf
[13:16] <ogra_> bsperes, i'd just leave it around and simply use "passwd -l" to lock it down
[13:16] <seb128> dholbach, I used --devmode though
[13:17] <ogra_> bsperes, http://paste.ubuntu.com/17116610/ is a script i used to use in 15.04 installs
[13:18] <dholbach> seb128, ok
[13:18] <ogra_> (when snappy config was still a thing though)
[13:18] <seb128> dholbach, works without devmode as well
[13:18] <dholbach> hohum...
[13:18] <dholbach> in that case I must be doing it wrong :)
[13:18] <seb128> dholbach, ignore me, I didn't test right
[13:18] <seb128> dholbach, the host /etc is mounted on the snap and I've qt4 installed
[13:18] <seb128> let me try to move that away
[13:20] <seb128> dholbach, still work though
[13:20] <seb128> Fontconfig error: Cannot load default config file
[13:20] <seb128> QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.
[13:20] <seb128> QSqlDatabase: QSQLITE driver not loaded
[13:20] <seb128> it displays those but starts
[13:20] <dholbach> ok... I'll test it locally again
[13:21] <dholbach> it starts now as well
[13:21] <dholbach> ... with --devmode that is
[13:21] <seb128> and without?
[13:21] <bsperes> ogra_, ok sounds good, thanks for your help!
[13:22] <seb128> dholbach, well in any case let me know if you get the error again
[13:22] <dholbach> seb128, tries to access /etc/xdg/Trolltech.conf
[13:22] <seb128> but it errors out on that?
[13:23] <dholbach> yep
[13:23] <dholbach> Bad system call
[13:23] <dholbach> and tries to write to /snap/musique/100001/usr/share/data/...
[13:23] <dholbach> which is something I guess I can patch in the source, or there might be a config for it
[13:23] <dholbach> but the XDG thing is something which might be a problem deeper down the stack
[13:24] <seb128> dholbach, does it work if you edit /var/lib/snapd/seccomp/profiles/snap.musique.musique and uncomment the "socketcall" line before starting it?
[13:24] <seb128> when does it try to write
[13:24] <seb128> I wonder why I don't get those issues :-/
[13:24] <dholbach> seb128, it's a message on stdout when you start it with --devmode
[13:25] <dholbach> wants to create a .db there
[13:26] <dholbach> in which case would the socketcall bit help?
[13:26] <dholbach> (it doesn't change anything)
[13:26] <seb128> I don't know, I just need to do that because I'm on i386 and there is a seccomp bug
[13:27] <seb128> I was wondering if the workaround was making me not see your bug
[13:28] <dholbach> ok
[13:29] <seb128> well, wfm :-/
[13:30] <dholbach> can you import a small directory of files and does it show up next time you start?
[13:34] <seb128> no, import seems to fail
[13:34] <seb128> I get those writable share warning now
[13:37] <seb128> dholbach, I think it's because it can't connect to the database
[13:38] <dholbach> I'm trying to figure out which variable to change to make it use $SNAP_USER_DATA instead
[13:38] <kyrofa> sergiusens, how would you feel about a `godeps_file` key being added to the go plugin to pull down godeps for a package before building?
[13:38] <seb128> dholbach, you mean the write to /usr error?
[13:38] <dholbach> yep
[13:38] <seb128> dholbach, that's because of export XDG_DATA_HOME=$SNAP/usr/share
[13:38] <kyrofa> `godeps-file` I guess. The name is of course up for discussion
[13:39] <dholbach> seb128, ok, let me see
[13:40] <seb128> dholbach, see https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
[13:40] <seb128> that's supposed to be a writable directory
[13:40] <seb128> but indeed, seems that export is copied around
[13:40] <seb128> it was in the calculator snap from jdstrand when we picked it up as well
[13:41] <dholbach> even removing them doesn't make it work
[13:41] <dholbach> I think the path is put together by using QDesktopServices::DataLocation in src/database.c
[13:46] <seb128> dholbach, for me unsetting XDG_DATA_HOME removes the warning
[13:47] <seb128> but adding files doesn't work because it can't access the database
[13:47] <dholbach> I'm doing a clean build again
[13:52] <dholbach> seb128, it works :)
[13:53] <seb128> nice
[13:57] <sergiusens> kyrofa should it be a new plugin or an extension of the go plugin?
[13:57] <sergiusens> kyrofa a new plugin would make more sense or we will soon get parameter overload
[13:58] <kyrofa> sergiusens, probably a good point-- lots of ways to handle go dependencies
[13:58] <kyrofa> sergiusens, but then you need to filter code out of the stage dir
[13:59] <kyrofa> Rather, you need to filter it using the `prime` keyword so it doesn't end up in the snap
[14:00] <sergiusens> kyrofa huh? Why can't the plugin take care of that?
[14:00] <kyrofa> sergiusens, hmm. Do you mean make a `go-with-godeps` plugin or some kind?
[14:00] <kyrofa> of some kind*
[14:01] <kyrofa> sergiusens, I thought you meant a `godeps` plugin
[14:02] <sergiusens> kyrofa yeah, a `godeps` plugin
[14:02] <sergiusens> kyrofa what does that have to do with `prime`?
[14:02] <pmp> ogra_: I build the snap with snapcraft --target-arch=armhf snap
[14:03] <pmp> ogra_: I snap install
[14:03] <kyrofa> sergiusens, I may be missing something here. If we have a `godeps` plugin, the `go` part will need to use the after keyword to make sure it uses the stuff pulled in by godeps, which would put the deps in the stagedir. No?
[14:03] <ogra_> pmp, i dont think that works ... you would need to use ubuntu-device-flash to actually create an image with it
[14:04] <ogra_> not sure if/how well sideloading kernel snaps actually works
[14:04] <pmp> ogra_: and uboot now says: Bad ARM zImage magic or similar
[14:04] <kyrofa> sergiusens, which means the code pulled by godeps will by default end up in the snap
[14:04] <ogra_> pmp, is that with our gadget snap in use ?
[14:05] <dholbach> ok, music playback doesn't work in musique now, but I guess that's a known issue, even with --devmode?
[14:05] <ogra_> pmp, i really think you need to create the image from scratch with that kernel snap in use
[14:05] <kyrofa> sergiusens, though now that I mention it, I think adding to that filter is in the plugin API
[14:07] <pmp> ogra_: I'm u-d-f'ing just now
[14:13] <pmp> Even after u-d-f'ing I have Bad Linux ARM zImage magic
[14:14] <ogra_> hmm, did it actually produce a proper vmlinuz ?
[14:14] <pmp> Well, in the same folder I build the image I used ealier with raspbian
[14:14] <pmp> I
[14:14] <pmp> will check
[14:15] <ogra_> oh, you might need "kernel-image-target: zImage"
[14:15] <ogra_> in your snapcraft.yaml
[14:15] <ogra_> arm64 devices can not use compressed kernel binaries ... so the 96boards demo uses a plain Image ... not zImage
[14:17] <pmp> can I just re-run the install-part of the installation?
[14:18] <pmp> instead of recompiling everything
[14:18] <pmp> (which takes a long time - unfortunately)
[14:18] <ogra_> not sure, i think you need to fully clean the tree
[14:19] <ogra_> really ?
[14:19] <ogra_> i thought you cross-build
[14:20] <pmp> yeah, it seems the bcm2709-defconfig for 4.7 has enabled much more modules than the one of 4.6 (and before)
[14:21] <pmp> And I'm running Ubuntu inside a docker
[14:23] <ogra_> ah
[14:38] <episensor> hi all - quick question. we're running some tests with snapcraft. with out current build system, our .jar files are located in /lib/ - is it reasonable to edit line 48 of the ant.py plugin and point it at /lib/? is there any other location where this can be configured?
[14:38] <episensor> *our
[15:02] <dholbach> episensor, maybe file a bug?
[15:02] <ogra_> i guess running the copy plugin first to get the files copied in place might work
[15:02] <dholbach> or that... right
[15:03] <ogra_> not sure though if that can actually pull from outside the snapcraft tree
[15:03] <croepha> What are some good ways to manage several similar sanppy  installations?  Are things like Chef and Puppet recommended? what would be the recommended way to install snappy on a device with some set configurations? (like versions of things installed, configurations...) What would be the recommended way push new configurations to existing snappy installations?
[15:03] <mhall119> where do snaps put their .desktop files?
[15:04] <ogra_> mhall119, inside the snap your mean ?
[15:04] <ogra_> or after install
[15:04] <mhall119> I mean, where does the Dash find them
[15:04] <mhall119> after install
[15:04] <ogra_> /var/lib/snapd/desktop
[15:04] <ogra_> see XDG_DATA_DIRS in your env
[15:05] <ogra_> croepha, once snappy config is back you should be able to use the REST api of snapd to manage configs i guess ... Chipaca might know more
[15:06] <croepha> Sweet thanks, I didn't know about snapd, now I got something to research!
[15:06] <ogra_> croepha, though if you talk about appliance devices that all use the same/a similar image, you would do all this inside a specific gadget snap for your image
[15:06] <ogra_> in either case i think snappy config coming back is required first though
[15:07] <ogra_> (it is on the TODO, i dont know with what prio though)
[15:07] <mhall119> thanks ogra_
[15:14] <netphreak> hi, guys!
[15:17] <croepha> hi netphreak
[15:18] <netphreak> has snappy enable-classic been reintroduced?
[15:29] <pmp> ogra_: the kernel boots - thanks for your help - what to do now with the overlay? could it be as simple as unsquashing the gagdet and then squashing it again after add the overlay
[15:32] <pmp> ogra_: recreating the overlay.tgz with the *-overlay.dtb from my kernel?
[15:36] <ogra_> pmp, well, the gadget also only allows a tgz file ... that wont help you to load the overaly in the end
[15:37] <ogra_> just create an overlay subdir in the system-boot partition and copy the dtbs there
[15:37] <ogra_> the rest is config.txt hacking
[16:14] <atriv> Hi all, Not sure if any core devs are in... I noticed recently that gpio and i2c support was added for the raspberry pi. i'm curious if there's support for samsung's artik modules and if not if there's a roadmap
[17:22] <arosales> Hello, is this the place for the Snap Caffe?
[17:24] <elopio> arosales: welcome, have a sit.
[17:24]  * arosales waves at elopio
[17:25] <elopio> atriv: hello. I bet you'll get better luck with your question in the mailing list.
[17:25] <elopio> people who know more details about that seem to be afk now.
[17:26] <atriv> thanks elopio
[17:26] <arosales> I wanted to check here if Caffe would be a good candidate to snap
[17:26] <arosales> I have been following http://caffe.berkeleyvision.org/install_apt.html
[17:27] <arosales> to get it built myself I have that done with GPU support, and I am working on non-gpu support
[17:28] <arosales> note, compilation steps continue @ http://caffe.berkeleyvision.org/installation.html#compilation
[17:28] <arosales> so its not a super straight forward process
[17:28] <arosales> thoughts?
[17:28] <elopio> arosales: everything is a good candidate. That one seems awesome.
[17:29] <elopio> arosales: you can start trying that cmake they mention there. We have a cmake plugin in snapcraft.
[17:32] <arosales> elopio: thanks for the feedback, do you have a pointer to plugins in general and the cmake one specifically?
[17:48] <elopio> arosales: snapcraft help cmake
[17:49] <elopio> and there are some examples using cmake in https://github.com/ubuntu/snappy-playpen
[17:52] <arosales> elopio: thanks. I'll take a whack at it
[18:51] <marcoceppi> Does snappy work on S390X ?
[18:53] <qengho> marcoceppi: No. Nothing technical in the way. Just demand and attention. You can use: amd64, i386, armhf, arm64
[18:53] <marcoceppi> qengho: I have a demand ;)
[18:54] <qengho> marcoceppi: come back with 1e6 others.
[18:54]  * marcoceppi registers 1e6 more irc accounts
[18:54] <elopio> marcoceppi: I haven't tested it there yet.
[18:56] <qengho> marcoceppi: It is probably possible, and we would love to see it. Please contribute something.
[19:13] <marcoceppi> qengho: like what?
[19:21] <qengho> marcoceppi: I am wrong. I apologise! We do have s390x images. http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[19:41] <marcoceppi> \o/
[20:09] <ogra_> marcoceppi, only snappy on classic, we dont build boot images for s390x IoT devices ;)
[20:10] <ogra_> marcoceppi, i havent found anyone to test them yet, so please report bugs
[22:51] <AndyWojo> Wow mark is really active on the snappy mailing lists. That's cool.
[23:00] <mhall119> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1590599 has been killing me all day
[23:03] <sergiusens> mhall119 yeah, that can be troublesome on bigger projects. kyrofa want to have a look at that one?
[23:04] <sergiusens> mhall119 it is not the prereq itself btw, it is the calculation involved to really know the prereq has really run or became dirty along the way
[23:23] <mhall119> sergiusens: is there any way it would become dirty between one check and the next?
[23:23] <mhall119> in the same call
[23:32] <mhall119> sergiusens: kyrofa: anyway, I hope the profile data helps, I can give you the raw cProfile data file if you want