[08:18] <fgimenez> good morning
[09:39] <JamesTait> Good morning all; happy Tuesday, and happy Golden Gate Bridge Day! 😃
[11:01] <Chipaca> stevebiscuit: mo'in!
[11:01] <Chipaca> stevebiscuit: a question that suddenly came to me
[11:01] <Chipaca> stevebiscuit: why is webdm fetching the icon?
[11:02] <Chipaca> stevebiscuit: (as opposed to giving the url to the browser and letting it figure it out)
[11:08] <stevebiscuit> Chipaca: hello!
[11:09] <LefterisJP> hello
[11:09] <stevebiscuit> Chipaca: the browser could handle things for uninstalled packages as the icon path would be something on the store
[11:10] <LefterisJP> When using snappy-remote, to upload a testing snap to a snappy target is it supposed to give some form of progress bar? I would like to determine if my process is stuck or if it's actually doing something
[11:10] <stevebiscuit> Chipaca: for installed packages, the path would be something like "/1.0/icons/myapp.myorigin/icon" which would be unaccessible
[11:11] <Chipaca> hurr durr
[11:11] <Chipaca> stevebiscuit: sorry i even asked :-)
[11:12] <stevebiscuit> Chipaca: not to worry, I had to double check!
[11:47] <LefterisJP> Hey all got a question. I am trying to deploy some test snapps from the snapcraft examples. The host is an Ubuntu 14.04 LTS and the snappy target is a Raspberry PI.
[11:48] <LefterisJP> When I do snapcraft the resulting .snap file has amd64 in its name and when I try to deploy with snap-remote I get this error:
[11:49] <LefterisJP> /tmp/webcam-webui_1_amd64.snap failed to install: package's supported architectures (amd64) is incompatible with this system (armhf)
[11:49] <LefterisJP>  
[11:49] <LefterisJP> How can I generate a .snap file for specific architecture?
[12:06] <LefterisJP> hmmm is anyone seeing my messages/questions or is there a problem with my IRC client :-) ?
[12:15] <Chipaca> LefterisJP: wait a bit for sergiusens or kyrofa to be around, i think
[12:15] <Chipaca> stevebiscuit: how much do we care about somebody calling their icon something utf8-ish?
[12:17] <kyrofa> Good morning
[12:18] <stevebiscuit> Chipaca: good question, when a snap is built will it allow a utf8 filename?
[12:19] <Chipaca> stevebiscuit: let's assume no, at least for now
[12:19] <kyrofa> LefterisJP, I believe snapcraft needs to be run on the target arch
[12:20] <stevebiscuit> Chipaca: grand, I'm happy to abdicate the responsibilty :)
[12:20] <Chipaca> stevebiscuit: especially because what we do know is incorrect for utf8 filenames only on firefox
[12:20] <Chipaca> which does blow my mind a little bit
[12:20] <Chipaca> and not in a good way
[12:21] <Chipaca> although that's 2013 info; might need updating
[12:23] <LefterisJP> kyrofa: thanks for the reply. So I would have to install snapcraft in a Raspberry PI and then build the package there?
[12:25] <kyrofa> LefterisJP, I believe so, assuming you're compiling (last I checked snapcraft didn't support cross-compiling)
[12:26] <kyrofa> LefterisJP, or in an arhm qemu or something
[12:26] <kyrofa> s/arhm/arm/
[12:33] <sergiusens> good morning
[12:35] <kyrofa> Morning sergiusens :)
[12:35] <kyrofa> sergiusens, to double check: to build an armhf .snap with snapcraft, snapcraft needs to run on an arm, right?
[12:36] <sergiusens> kyrofa, today, yes
[12:36] <LefterisJP> or in general what is the recommended way to build for Raspberry PI target from an Ubuntu host.
[12:37] <sergiusens> kyrofa, you are up early, or maybe I am up late :-P
[12:38] <kyrofa> sergiusens, yeah a little. This time of year exercising in the morning sucks
[12:38] <kyrofa> sergiusens, so I'm trying to shift my schedule back a little so I can exercise after work
[12:39] <LefterisJP> sergiusens: You mentioned today yes. Is there any plans to add support for compiling for RaspPi (armhf) from an Ubuntu host in the future?
[12:40] <sergiusens> LefterisJP, only ideas; probably mostly for things like go and node. Nothing stops you today from writing a custom plugin basing out of one of the existing ones that does just that for your needs though
[12:41] <LefterisJP> I am still getting my bearings as to how Snappy Ubuntu works and how I can accomplish my goals.
[12:41] <LefterisJP> Thanks I understand.
[12:41] <sergiusens> LefterisJP, what are your goals?
[12:41] <LefterisJP> I may bother you guys a bit more with extra "newbie" questions.
[12:43] <kyrofa> LefterisJP, no bother!
[12:50] <kyrofa> LefterisJP, but yeah, if you can explain what exactly you're looking to accomplish, we can probably point you in the easiest direction
[12:53] <LefterisJP> I am working for slockit (http://slock.it/) and am trying to evaluate and see if it makes sense to use Snappy Ubuntu for our work. I am trying to gather as much info as possible to creating Snappy Frameworks as my final goal is to create an Ethereum(https://ethereum.org/) Snappy Framework which other Snappy apps can utilize.
[12:53] <LefterisJP> At least for now for testing purposes I use a Raspberry Pi as my testing target environment
[12:54] <kyrofa> LefterisJP, for evaluation purposes perhaps it would be easier to use an amd64 virtual machine running snappy?
[12:55] <kyrofa> LefterisJP, a qemu VM is just going to be slow is all
[12:55] <sergiusens> kyrofa, btw are you on xenial?
[12:55] <kyrofa> (an arm one anyway)
[12:55] <sergiusens> kyrofa, I am seeing this with the tests http://paste.ubuntu.com/14410381/
[12:56] <sergiusens> but it does not happen on travis
[12:56] <kyrofa> sergiusens, no I'm on trusty :P
[12:56] <kyrofa> sergiusens, huh, that doesn't look good
[12:57] <kyrofa> Looks like the mock lib changed... ?
[12:57] <sergiusens> kyrofa, indeed
[12:57] <kyrofa> grr... breaking api...
[12:58] <kyrofa> sergiusens, I'm not sure how to fix that in a backward-compatible way
[12:58] <sergiusens> kyrofa, I'll look into it
[12:58] <kyrofa> sergiusens, alright let me know. I can fire up a xenial lxc in no time
[12:59] <sergiusens> kyrofa, I can do it with more code
[13:00] <sergiusens> kyrofa, the problem is the error 'helper' message when the assertion fails
[13:00] <kyrofa> sergiusens, oh. Did they just remove support for it?
[13:01] <sergiusens> kyrofa, I don't think it was removed entirely as I use it too and those don't fail (Equal), only in the called one it seems
[13:01] <kyrofa> sergiusens, worst case we can just remove the helper message and that will work on all versions
[13:01]  * sergiusens checks the docs
[13:01] <sergiusens> kyrofa, I;ll leave the message, don't worry ;-)
[13:01] <sergiusens> easy to fix
[13:11] <sergiusens> kyrofa, so even worse, nothing changed; assert_not_called only exists in 3.5 and trusty uses 3.4 so you were tricked by the mock's consumtion of anything it was called with :-P
[13:11] <kyrofa> sergiusens, oh no
[13:11] <kyrofa> sergiusens, that's _terrible_
[13:11] <kyrofa> sergiusens, oh, so embarrassing :P
[13:13] <kyrofa> sergiusens, easy fix though
[13:13] <sergiusens> kyrofa, yeah, done already; taking more time to think of a commit message than anything else :-
[13:13] <sergiusens> :-P
[13:14] <kyrofa> sergiusens, just using .called?
[13:14] <sergiusens> kyrofa, yeah
[13:14] <kyrofa> sergiusens, great, thanks for mopping up behind me
[13:14] <sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/200
[13:35] <LefterisJP> So I have a bit more general question. Once you make an app or Framework for Ubuntu core it does not mean that it will run on every device running Ubuntu core, right? It means only for devices having the same architecture? Then to support each device you would have to generate a .snap for that device's architecture separately?
[13:36] <kyrofa> LefterisJP, you have the right idea, although it's possible to create a .snap for multiple architectures if your project supports such a thing. An example might be a series of shell scripts, or something you've already compiled for other architectures
[13:37] <kyrofa> LefterisJP, keep in mind that you don't HAVE to have snapcraft build your snap for you. In current releases you can just snappify a directory with snappy build (future releases moves that functionality into snapcraft, but you can still just snappify a directory)
[13:41] <LefterisJP> interesting, where can I find more information for multiple architectures projects? I mean I saw some projects adding an architectures list in the yaml file, like: `architecture: [amd64, armhf]` but how can you specify the rules as to how to build each architecture.
[13:49] <kyrofa> LefterisJP, that's what I'm saying-- if you want snapcraft to do the building for you, you're going to be stuck with the host arch
[13:50] <LefterisJP> hmm okay
[13:50] <kyrofa> LefterisJP, however, let's pretend your project was written in go, or C++. Let's say you built it yourself for multiple architectures and ended up with a binary for each
[13:51] <kyrofa> Then you name them according to their arch: project_amd64, project_armhf, etc
[13:51] <kyrofa> LefterisJP, then you make a shell script that looks at the current arch, and launches the right onw
[13:51] <kyrofa> one*
[13:51] <kyrofa> LefterisJP, now that shell script is your snappy binary
[13:51] <kyrofa> LefterisJP, and voila, you support multiple architectures in the same .snap
[13:52] <kyrofa> LefterisJP, and you don't need snapcraft to build it-- just setup the meta/package.yaml etc. accordingly and run snappy build
[13:56] <LefterisJP> kyrofa: Thank you for your help
[13:56] <LefterisJP> Is there any blog post or tutorial or something I can use for reference for this?
[13:56] <LefterisJP> I found this to be useful: https://insights.ubuntu.com/2015/06/03/so-you-want-to-write-a-snappy-app/
[13:58] <kyrofa> LefterisJP, of course, it's why we're here :) . And yeah, that sounds kinda like what I described, nice
[14:04] <kyrofa> LefterisJP, and we are indeed trying to make that better in snapcraft. But supporting cross-compiling for all the supported possibilities in a general way is a difficult problem to solve
[14:08] <LefterisJP> yeah I understand. I had seen a presentation by Maarten Ectors in (Ethereum) Devcon1 about Ubuntu Core and I had understood that you had somehow had a magical way to cross-compile for everything already. I know it's a hard problem to solve, but who knows, with enough research and work many architectures may be supported.
[14:08] <LefterisJP> Are these snapcraft pluging used for cross-compiling? https://github.com/ubuntu-core/snapcraft/tree/master/snapcraft/plugins
[14:11] <sergiusens> LefterisJP, no, those are just used for building natively
[14:11] <sergiusens> you can override them and support a specific target if you want
[14:13] <LefterisJP> I see. Then just out of curiosity in which part of the system would any cross-compiling capability be built (in the future as you said)
[14:13] <sergiusens> LefterisJP, in the plugin itself
[14:13] <sergiusens> as each plugin (tech) uses a different mechanism to support this
[14:14] <kyrofa> LefterisJP, right, cross-compiling C++ is different than cross-compiling Go, for example
[14:16] <LefterisJP> yeah I know :(
[14:17] <LefterisJP> 2 clients exist for Ethereum, one in Go and one in C++. I like C++ a lot myself but well ... cross-compiling it for different architectures is painful
[14:17] <kyrofa> LefterisJP, yeah that's my favorite
[14:18] <kyrofa> I'm afraid snapcraft isn't going to be the C++ cross compiling silver bullet though, sorry :( . At least... not yet ;)
[14:18] <kyrofa> LefterisJP, what build system does the C++ client use?
[14:20] <LefterisJP> cmake
[14:22] <kyrofa> LefterisJP, well at least you have that-- cross compiling is a little easier with a good build system obviously
[14:30]  * kyrofa 's day always improves when he thinks he's out of coffee... and then discovers there's actually a little bit left
[14:32] <kyrofa> sergiusens, standup?
[14:32] <sergiusens> oops
[14:50] <LefterisJP> where you guys located at? Europe or US or both?
[15:05] <enoch85> ping kyrofa
[15:06] <kyrofa> Hey enoch85 :)
[15:07] <enoch85> kyrofa, so I installed Ubuntu Snappy once again, and didn't touch anything else. what would be the next step?
[15:07] <enoch85> kyrofa, do I build the ownCloud.snap seperatly from the system, and can this be done inside a VM?
[15:08] <enoch85> kyrofa, can I use my scripts in the .snap or do I have to build it from schratch?
[15:08] <kyrofa> enoch85, in order to develop the .snap, I'd ignore the rpi2 for now and do this on your dev machine
[15:09] <enoch85> kyrofa, ok, where do I begin?
[15:09] <kyrofa> enoch85, well, assuming you're running Ubuntu on your dev machine. Are you?
[15:09] <enoch85> yes
[15:09] <kyrofa> enoch85, which version?
[15:10] <enoch85> on my laptop I have Ubuntu Mate 15.10, and when I develop scripts and such I usually do this on a Ubuntu Server VM
[15:11] <enoch85> kyrofa, sorry forgot to mention you...
[15:12] <kyrofa> Excellent. First of all, get snapcraft setup (https://developer.ubuntu.com/en/snappy/build-apps/get-started/)
[15:12] <kyrofa> enoch85, haha, no problem
[15:13] <kyrofa> enoch85, let me fire up a 15.10 lxc real quick so I can walk through with you
[15:13] <enoch85> kyrofa, hmm, so I can make a standard VM and use snapcraft to compile it onto snappy? that would be awesome!
[15:14] <enoch85> kyrofa, ok!
[15:14] <kyrofa> enoch85, indeed
[15:15] <enoch85> kyrofa, yeah, and I will create a dev envirroment I think... to keep things seperated.
[15:15] <enoch85> kyrofa, which one do you recomend?
[15:15] <enoch85> kyrofa, server or desktop?
[15:15] <kyrofa> enoch85, what virtualization tech are you using?
[15:16] <enoch85> kyrofa, VMware Workstation
[15:16] <kyrofa> enoch85, short answer is server-- you won't need a GUI
[15:16] <kyrofa> enoch85, but it won't hurt anything to have a gui either
[15:16] <sergiusens> kyrofa, this was fixed, right? https://bugs.launchpad.net/snapcraft/+bug/1524374
[15:16] <enoch85> kyrofa, ok, but will it end up in alot of files all over the place, or is it clean in case I want to remove it later, in that case I don't need to create a seperate VM
[15:17] <enoch85> enoch85, I can just use my laptop as dev machine
[15:17] <kyrofa> sergiusens, yes I believe so-- let me verify
[15:18] <kyrofa> enoch85, the files it creates are pretty localized
[15:19] <kyrofa> sergiusens, yes: https://github.com/ubuntu-core/snapcraft/pull/161
[15:19] <kyrofa> enoch85, assuming you're talking about the process of building a .snap
[15:20] <enoch85> kyrofa, so basically purge snappy-tools when I'm done?
[15:20] <sergiusens> kyrofa, I can't remember when we did the split; I'll mark it fixed commited for trunk but leave it open for 1.x
[15:20] <enoch85> kyrofa, yes, that as well
[15:20] <kyrofa> sergiusens, I think it was after, so that sounds good
[15:21] <kyrofa> enoch85, ah, yeah. And remove the PPA
[15:21] <kyrofa> enoch85, of course if you're worried, virtualize it (I do)
[15:21] <enoch85> kyrofa, ok, then let's go
[15:22] <enoch85> kyrofa, naah, I need to reformat my latop soon anyway, just another reason to do it if I choose not to proceed ;)
[15:22] <kyrofa> enoch85, hahaha, okay
[15:23] <kyrofa> enoch85, give me one sec, setting up...
[15:23] <enoch85> kyrofa, ok cool :)
[15:23] <enoch85> kyrofa, oh, nice progress bar when installing the tools
[15:24] <enoch85> kyrofa, can I get that in the server env as well?
[15:26] <kyrofa> enoch85, heh, I'm not sure what you're referring to
[15:26] <enoch85> kyrofa, I got a progress bar when I installed the tools, it appeard in the bottom line
[15:26] <enoch85> kyrofa, just wondering if I can script that in a regular apt-get upgrade command on a server for instance
[15:27] <kyrofa> enoch85, via apt-get? Yeah I'd assume that would be the same regardless of desktop or server
[15:27] <enoch85> kyrofa,
[15:27] <enoch85> cool
[15:27] <enoch85> kyrofa, anyway, on page 2 now in the guide
[15:27] <enoch85> kyrofa, snapcraft tutorial
[15:28] <kyrofa> enoch85, right, so, snapcraft is a tool that will build .snaps for you if you tell it your dependencies, etc.
[15:28] <enoch85> kyrofa, could I use ondrejs PPA for PHP 7 for instance?
[15:29] <enoch85> kyrofa, btw a completley doifferent question: will PHP 7 be optional in UBuntu 16.04?
[15:29] <kyrofa> enoch85, yes, but you'll need to write a custom snapcraft plugin for the nonstandard repo. And honestly I'm not sure regarding 16.04
[15:29] <kyrofa> enoch85, is PHP7 a requirement for owncloud nowadays?
[15:31] <enoch85> kyrofa, ok, so what I want is: LAMP with PHP 7 + ownCloud + some scripts that will be included in the snap at boot for the ownCloud. Basically, I want the same as I have today: https://en0ch.se/index.php/s/i3csGfYlpivkFvh
[15:31] <enoch85> kyrofa, not a requrement, but nice to have. speed things up quite a bit.
[15:32] <enoch85> kyrofa, please download and try if you have the time
[15:33] <LefterisJP> I am playing around with deploying a simple "Hello World" shell script snappy in a Pi and after succesfully deploying it with snappy-remote when I try to run it inside the Pi I get: `appname Test-snap-echo.sideload not allowed`
[15:33] <LefterisJP>  
[15:33] <LefterisJP> what am I doing wrong?
[15:33] <kyrofa> enoch85, alright. That sounds doable. I've not put together a php .snap before, so we may want to start with the default repos, just for simplicity for now
[15:34] <enoch85> kyrofa, yeah ok, and I (we) can develop it further later on
[15:34] <enoch85> :)
[15:34] <kyrofa> enoch85, exactly
[15:36] <kyrofa> sergiusens, hey on wily, snappy-tools doesn't seem to include snapcraft?
[15:38] <kyrofa> So enoch85 you'll need to `apt-get install snapcraft` as well
[15:38] <enoch85> kyrofa, on it
[15:38] <sergiusens> kyrofa, I'll add a note to check
[15:38] <enoch85> kyrofa, done
[15:38] <kyrofa> sergiusens, just makes the docs inconsistent is all
[15:39] <kyrofa> Alright enoch85, let's first try to just make a .snap that has apache running
[15:40] <enoch85> kyrofa, ok
[15:40] <enoch85> kyrofa, LAMP**
[15:40] <enoch85> kyrofa, wouldn't it be possible to make a LAMP snap?
[15:41] <kyrofa> enoch85, haha, we're getting there
[15:41] <enoch85> kyrofa, ok
[15:41] <enoch85> :)
[15:41] <kyrofa> enoch85, but all the .snaps I've made so far are a little simpler. So we're going to learn together. Sound okay?
[15:41] <enoch85> kyrofa, very good. win-win
[15:42] <kyrofa> enoch85, I figure once we get a .snap with apache, we'll add PHP, then mysql, then owncloud
[15:42] <enoch85> kyrofa, into one snap, or seperate?
[15:42] <kyrofa> enoch85, into one
[15:42] <enoch85> kyrofa, ok cool
[15:43] <kyrofa> enoch85, alright, make sure you're here: https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
[15:43] <enoch85> kyrofa, yes
[15:43] <kyrofa> enoch85, scroll down to the "Snapcraft Recipe"
[15:43] <enoch85> kyrofa, yes
[15:44] <enoch85> kyrofa, mkdir apache?
[15:44] <kyrofa> enoch85, so we use a file named `snapcraft.yaml` to instruct snapcraft on how to assemble our .snap
[15:44] <kyrofa> enoch85, make a folder for the overall snap. I'm making a ~/src/owncloud-snap folder
[15:44] <enoch85> kyrofa, ok
[15:45] <kyrofa> enoch85,  In that folder, create a snapcraft.yaml file
[15:45] <enoch85> kyrofa, touch i suppose?
[15:45] <enoch85> or just copy the text and add my things instead?
[15:46] <kyrofa> enoch85, or vi or some other editor, no matter. Right, take the text from the tutorial and alter to fit
[15:46] <kyrofa> enoch85, just the name through the icon
[15:46] <kyrofa> enoch85, generic metadata
[15:46] <kyrofa> enoch85, ooo, actually just run snapcraft init, haha
[15:47] <kyrofa> Get in that folder and run snapcraft init. Then alter the snapcraft.yaml to fit
[15:47] <kyrofa> enoch85, if I actually read the tutorial...
[15:47] <enoch85> kyrofa, haha ok
[15:47] <enoch85> sec
[15:48] <enoch85> kyrofa, sorry for noise:
[15:48] <enoch85> name: owncloud-server
[15:48] <enoch85> version: 1
[15:48] <enoch85> vendor: Daniel Hansson <daniel@techandme.se>
[15:48] <enoch85> summary: ownCloud Server Snap
[15:48] <enoch85> description: ownCloud server is you self-hosted cloud
[15:48] <enoch85> icon: icon.png
[15:48] <enoch85> something like that?
[15:48] <kyrofa> enoch85, sure, that works fine
[15:48] <LefterisJP> guys ping: `appname Test-snap-echo.sideload not allowed` when trying to run a binary of an app I installed via snappy-remote. Why would I get this?
[15:50] <kyrofa> enoch85, make sure you actually have that icon. I use a .svg simply containing `<svg />` or something
[15:50] <kyrofa> enoch85, eventually we can actually use the owncloud icon
[15:50] <enoch85> kyrofa, was just about to ask... don't have an icon
[15:50] <enoch85> can copy one from ownCloud though
[15:50] <kyrofa> enoch85, that works
[15:50] <enoch85> kyrofa, yes
[15:50] <enoch85> sec
[15:53] <kyrofa> LefterisJP, is the shell script executable?
[15:53] <enoch85> kyrofa, saved that inside the owncloud-snap folder (my dev folder)
[15:53] <enoch85> kyrofa, togehter with the icon
[15:54] <kyrofa> enoch85, owncloud? That's fine, we won't use it just yet but it won't hurt anything. 8.2.2?
[15:54] <LefterisJP> kyrofa: yes
[15:54] <enoch85> kyrofa, yes, latest
[15:54] <kyrofa> LefterisJP, out of curiosity (not sure it will fix anything) try changing the name to something without hyphens and try again
[15:55] <kyrofa> enoch85, alright, so now let's tell snapcraft that we want apache
[15:55] <enoch85> kyrofa, exiteing!
[15:55] <enoch85> kyrofa, exciting!*
[15:56] <LefterisJP> kyrofa: Will do. Does that mean I need to purge it from the snappy target too? Also, my package.yaml calls the executable like:
[15:56] <LefterisJP>    exec: ./bin/testecho.sh
[15:56] <LefterisJP> do I need to put sh in front? The script does have the shebang on the top
[15:57] <kyrofa> LefterisJP, no as long as the shebang is valid you should be good. And no, when you're sideloading you can load it right over the top
[15:58] <kyrofa> enoch85, so we're going to specify parts, like further in the tutorial
[15:58] <enoch85> kyrofa, i'm with you
[15:59] <enoch85> kyrofa, just a file called parts?
[15:59] <kyrofa> enoch85, no, no files, this is all in the yaml
[15:59] <enoch85> kyrofa, sorry, add it to .yaml
[15:59] <kyrofa> enoch85, right, you got it
[15:59] <kyrofa> enoch85, so every .snap is made up of (potentially many) parts
[15:59] <enoch85> kyrofa, cool
[16:00] <enoch85> kyrofa, what repos can I use here?
[16:01] <kyrofa> enoch85, in snapcraft, each part is assembled by one of its many plugins. Part of the process we're going through may very well end up making a php plugin
[16:01] <kyrofa> (since snapcraft doesn't have one)
[16:02] <enoch85> kyrofa, ok. is it ok to post here or do you want a pastebin instead?
[16:02] <enoch85> kyrofa, maybe PM?
[16:02] <kyrofa> enoch85, pastebin is less noisy and easier to read. Perhaps PM would quiet the list down a bit :)
[16:03] <enoch85> kyrofa, like that?
[16:03] <enoch85> kyrofa, what should be instead of plugin and source i.e?
[16:04] <kyrofa> enoch85, let's take this PM
[16:09] <LefterisJP> I have a question about this blogpost: https://insights.ubuntu.com/2015/06/03/so-you-want-to-write-a-snappy-app/
[16:10] <LefterisJP> He has a snappy directory with bin/ARCH1 and bin/ARCH2 and has 2 executables under it
[16:11] <LefterisJP> how does snappy build know which one to put in what architecture? Cause I tried to do something similar and it ended up having bin/ARCH1 and bin/ARCH2 under the Raspberry PI where I only wanted to have the corresponding Architecture subtree there.
[16:11] <kyrofa> dholbach, https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/ doesn't show sublists
[16:11] <kyrofa> LefterisJP, that's the thing-- it puts both
[16:12] <kyrofa> LefterisJP, that's why you need that third item-- the shell script that determines which one to run
[16:12] <dholbach> kyrofa: ok, looking into it
[16:12] <LefterisJP> I could do that, but then how does (in the blogpost) the package.yaml point to the same executable?
[16:12] <kyrofa> LefterisJP, the executable is the shell script
[16:12] <kyrofa> LefterisJP, which will run on all archs
[16:13] <kyrofa> LefterisJP, then launch the corresponding binary
[16:13] <dholbach> kyrofa: I filed https://bugs.launchpad.net/developer-ubuntu-com/+bug/1531200 to track it
[16:14] <kyrofa> dholbach, thank you! Yeah, I'm just pointing people to github for now
[16:15] <dholbach> kyrofa: we're getting closer to finally having the markdown importer working and deployed, from there on it should be a lot less tedious and we started adding tests as well
[16:15] <kyrofa> dholbach, awesome!
[16:15] <LefterisJP> kyrofa: I understand what you say, but in the blog post he seems to produce a binary called "port-listener" from go-build and then another one with the same name through go-build cross compiling for ARM. And he only puts them in different bin/ directories under the main snappy/ dir.
[16:16] <LefterisJP> kyrofa: And his package.yaml does not seem to contain a shell script
[16:16] <LefterisJP> services:
[16:16] <LefterisJP>  - name: port-listener
[16:16] <LefterisJP>    description: "template Go snappy project"
[16:16] <LefterisJP>    start: ./bin/port-listener
[16:16] <LefterisJP>    caps:
[16:16] <LefterisJP>      - networking
[16:16] <LefterisJP>      - network-service
[16:16] <LefterisJP> Unless this bin/port-listener is actually a selection shell script
[16:17] <kyrofa> LefterisJP, exactly!
[16:17] <kyrofa> LefterisJP, your last point is spot on
[16:18] <kyrofa> LefterisJP, and it in turn runs the binary that it knows will run on the current arch
[16:20] <LefterisJP> kyrofa: I see. Quite strange that he does not mention this in the blog post (https://insights.ubuntu.com/2015/06/03/so-you-want-to-write-a-snappy-app/)
[16:21] <kyrofa> LefterisJP, "The run file plays a little trick. It invokes the correct binary file depending on the currently running architecture. This allows you to package one snap that works on my architectures. "
[16:24] <LefterisJP> kyrofa: My bad
[16:24] <LefterisJP> kyrofa: Missed that line totally
[16:25] <LefterisJP> kyrofa: Okay now I found it in the bzr repo too. Got the shell file. This will be really helpful. Thanks.
[16:26] <kyrofa> LefterisJP, no problem!
[16:30] <renat> Hi! It's Renat from Screenly. I wanted to contact @mectors about creating a custom store for screenly snaps. It is set up by store.id setting in YAML file for the  OEM snap. Is there any information about that? Thanks.
[16:30] <renat> Hi, kyrofa!
[16:32] <kyrofa> renat, hey there!
[16:33] <LefterisJP> kyrofa: But wouldn't it be smarter if the binaries were only uploaded to the device for which they were made, and having package.yaml determine which binary goes to which architecture? And then snappy-remote or snappy-install can simply deny installation for incompatible architectures. Because as it stands right now we will end up having binaries inside the /apps/bin/ of a snappy app that we would never use. I am wondering how come
[16:33] <LefterisJP> things ended up as they are now
[16:34] <renat> kyrofa, can you help me please? I want to contact mectors, but cannot see his nick in users list here. Question about custom store for Screenly becoming more urgent, and I want to resolve it until it's too late.
[16:35] <kyrofa> sergiusens, do you know anything about renat's question?
[16:36] <kyrofa> renat, I'm afraid I've not dealt with that, but I'd be curious about the answer as well. We'll see if we can find someone else to help you :)
[16:48] <kyrofa> sergiusens, or know who to talk to about it, anyway. I suspect mectors is not actually the right person
[16:57] <sergiusens> renat, do you have his email?
[16:58] <sergiusens> renat, kyrofa I think you want to talk to beuno
[17:00] <renat> sergiusens, kyrofa, thanks.
[17:00] <renat> sergiusens, how can I contact beuno?
[17:00] <kyrofa> sergiusens, yeah I wondered. renat have you tried the snappy mailing list?
[17:01] <sergiusens> renat, I just pinged beuno to join, not sure why he isn't here
[17:20] <renat> sergiusens, thanks!
[18:41] <sergiusens> Chipaca, hey, does license agreement require a license version or vice versa?
[18:43] <Chipaca> sergiusens: no
[18:44] <sergiusens> Chipaca, either of those require a license though? And if not, it seems sane if I require those keys to have a license defined, right?
[18:44] <Chipaca> sergiusens: if package version A has require-license-agreement, and B has require-license-agreement, and A is installed, and A and B both have the same license version, then the user isn't asked again
[18:44] <Chipaca> on upgrade i mean
[18:46] <Chipaca> sergiusens: if you require a license agreement, a license file is required and must be nonempty
[18:48] <Chipaca> sergiusens: i'm not sure i'm answering your question =)
[18:49] <enoch85> does anyone know the user and pass to the snappy OVA image?
[18:49] <enoch85> found here: https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/
[18:50] <ogra_> same as everywhere :)
[18:50] <ogra_> ubuntu/ubuntu by default
[18:50] <sergiusens> Chipaca, perfectly; it was obvious, but was making sure :-)
[18:51] <sergiusens> Chipaca, but you can have a license, require an agreement and not version it, meaning it is a one time thing or until you version it
[18:52] <enoch85> ogra_, tried ubuntu ubuntu, but no. :/
[18:52] <Chipaca> sergiusens: yes. And you can have a license and a version and not require an agreement
[18:52] <ogra_> enoch85, then something must be broken ... the rootfs is the same everywhere for snappy
[18:52] <Chipaca> sergiusens: and you can have a license version and no license and not require an agreement, and that probably doesn't complain even =)
[18:53] <enoch85> http://i.imgur.com/UPPwifU.png ogra_
[18:54] <enoch85> ogra_, and I get: intel_rapl: no valid rapl domains found in package 0
[18:54] <enoch85> maybe that's the cause?
[18:54] <ogra_> i doubt that
[18:55] <sergiusens> Chipaca, that last one seems more like a bug though ;-)
[18:55] <sergiusens> Chipaca, I'm making it complain in snapcraft fwiw
[18:56] <enoch85> ogra_, any clue?
[18:57] <ogra_> enoch85, not from that screenshot ... perhaps cloud-init went south or something ... check your boot loag (i'm officially not here btw :) )
[18:57] <ogra_> *log
[18:57] <enoch85> ogra_, ok, thanks :)
[19:32] <plars> elopio: on x86, I'm seeing a message from udf with rolling/edge: "expected 5 partitons but found 0" but it exits 0. I'm assuming this was a silent failure?
[19:57] <plars> elopio: and on a different system, I get 'error while executing external command kpartx -ds /tmp/x86.img: device-mapper: remove ioctl on loop1p5 failed: Device or resource busy'