[06:33] <Gunther_> Good morning!
[06:36] <Gunther_> Is an expert concerning u-d-f (vivid) available? We have a problem creating an image in Docker container (oem  generic-amd64). The generated image does not boot because it fails to locate the kernel.
[06:37] <Gunther_> Out of the Docker container the image works. The udev workaround is applied (ln -s /bin/true ...)
[06:38] <didrocks> Gunther_: hey! I guess ogra_ would be able to help you once he wakes up (few hours from now :))
[06:39] <Gunther_> thank you. I will wait for him :)
[07:11] <zzarr> tyhicks, -Wall and -Werror?
[07:44] <zyga> o/
[07:49] <Gunther_> didrocks: problem solved, and I did not need ogra :)
[07:51] <Gunther_> didrocks: the docker container used u-d-f from vivid, whereas the native installation had u-d-f installed from ppa:snappy-dev
[07:52] <dholbach> would it make sense to have packages have build-essential as an essential part of their build-packages declaration?
[07:53] <dholbach> it'd certainly simplify things if you're using 'snapcraft cleanbuild' and don't have to spell out things like make, g++ and others
[07:53] <didrocks> Gunther_: ahah, making sense!
[08:25] <zyga> jdstrand, tyhicks: https://github.com/ubuntu-core/snap-confine/pull/18/files
[08:33] <tptr> Hi, any word when ubuntu core 16.04 can be expected? (eagerly waiting for the newer docker version...:-)
[08:42]  * nhaines just waits for the pulseaudio interface.
[08:51] <zyga> nhaines: it's coming :)
[08:52] <zyga> nhaines: it's merged and an SRU under way
[08:52] <nhaines> zyga: \o/
[08:52] <zyga> tptr: 16.04 is out, you can use snappy on that version directly
[08:52] <zyga> tptr: as for an all-snap image, those are available as well but aren't finalized so you may need to re-flash a few times as we make big changes
[08:53] <zyga> tptr: also the tooling around those is evolving so expect ubuntu-device-flash to go away
[08:53] <nhaines> I have a little script that requires sox and then basically makes the same sound as the Enterprise NCC-1701-D's warp engines... perfect for background noise!  :D
[08:56] <nhaines> And the moment the pulseaudio interface is available, I'll be all set!
[08:57] <ogra_> you should make that a commercial app ... you will get rich in no time
[08:57] <nhaines> ogra_: haha, tempting!
[08:58] <nhaines> The code *is* available in my book, so a for-pay snap wouldn't be unconsciable.
[09:04] <tptr> zyga: thx! I am using snappy on an Intel compute stick. So sg like ubuntu-16.04-snappy-amd64-generic.img.xz would b what I am after...
[11:43] <kyrofa> zyga, images are available? Where are they?
[11:48] <lool> ogra_, sergiusens: Ah right, I see vejmarie solved the locale issue in the end  :-)
[11:48] <ogra_> yeah, just answered your mail :)
[11:48] <ogra_> in fact the locale manpage tells you how :)
[11:48] <erio> Wait
[11:49]  * ogra_ waits
[11:49] <erio> I am having a locale issue too, can someone send links
[11:49] <erio> ?
[11:49] <ogra_> http://manpages.ubuntu.com/manpages/xenial/en/man1/locale.1.html
[11:49] <ogra_> scroll to the bottom
[11:49] <lool> oh god, people can override locales with env vars
[11:50] <lool> strings often contain %s and what not
[11:50] <ogra_> here is also an old snap http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh (currently not functional, not fully proted to 16, but you should get what it does)
[11:50] <erio> Thanks, favoriting all of this
[11:51] <erio> https://github.com/ericoporto/fgmkPackaging/blob/master/snap/snapcraft.yaml
[11:51] <erio> Made a simple test, but was failing on locale
[11:53] <ogra_> http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml
[11:53] <ogra_> you want to ship locale and libc-bin in your snap as well
[11:54] <seb128> locales are workaroundable
[11:54] <seb128> code using bindtextdomain() not so much
[11:54] <ysionneau> tyhicks: Hi! Any news on the ptmx issue?
[11:56] <erio> Thanks ogra_   !
[11:56] <ogra_> :)
[12:33] <jdstrand> zyga: cool, thanks :)
[13:03] <vejmarie> great my snap has been approved !
[13:03] <vejmarie> ;)
[13:04] <ogra_> yay
[13:04] <vejmarie> but how does users find it ? I thought this was through "Ubuntu software" / Store interface in the GUI ?
[13:05] <ogra_> using "snap find" on the commandline ... or in the ubuntu-software tool
[13:06] <eriow> Have you tried searching using snap in command line?
[13:06] <ogra_> (not sure how fast the db of the tool is wrt getting the info about the new package though)
[13:06] <zyga> jdstrand: hey
[13:06] <zyga> jdstrand: https://github.com/ubuntu-core/snap-confine/pull/20
[13:06] <zyga> jdstrand: trivial one
[13:07] <zyga> jdstrand: I just have a few patches, I will be working on cleanups in the code, making it nicer and less ifdefy
[13:13] <vejmarie> yes I see it in snap find ;)
[13:13] <vejmarie> but not in the software tool
[13:13] <vejmarie> (yet)
[13:19] <zyga> jdstrand: we also need to plan for new way to test anything
[13:19] <zyga> jdstrand: as we'll switch at some point (not today) to execing snap-exec
[13:19] <zyga> jdstrand: so the command line will almost entirely go away
[13:19] <zyga> jdstrand: we'll need some test-only environment variable
[13:20]  * jdstrand nods
[13:22] <zyga> jdstrand: I guess we can just have a secure_getenv-based test to exec a test playload (command) instead
[13:22] <zyga> jdstrand: sorry for making so many changes lately, I hope we can land seccomp filtering now
[13:23] <zyga> jdstrand: is the ubuntu kernel okay for that fature now/
[13:26] <jdstrand> zyga: seccomp arg filtering will work on any kernel with newer seccomp
[13:31] <sergiusens> dholbach I explicitly removed build-essential from this as it made building things that use nodejs incredibly and unnecessarily slow
[13:32] <dholbach> sergiusens, I see
[13:35] <vejmarie> quick question guys, how do you update manually the snap database ?
[13:36] <zyga> vejmarie: what do you mean exactly?
[13:36] <vejmarie> my colleague is looking at free cad within snap but when he kick snap find in a shell
[13:36] <vejmarie> he doesn't find it
[13:37] <zyga> vejmarie: that's always server side
[13:37] <zyga> vejmarie: is that snap published?
[13:37] <vejmarie> yes
[13:37] <zyga> vejmarie: is it published to series 16
[13:37] <vejmarie> I can see it on my system
[13:37] <vejmarie> yes
[13:37] <zyga> vejmarie: is he running snapd 2.0.5? (the latest one)
[13:37] <ogra_> ogra@styx:~$ snap find|grep freecad
[13:37] <ogra_> freecad                    0.17                       -        This is the first beta for freecad 0.17 supporting OCCT 7 / Netgen and new Smesh version
[13:37] <zyga> vejmarie: can he snap install freecad?
[13:38] <vejmarie> the main difference is that I am running 16.04 Desktop
[13:38] <ogra_> i definitely see it on my xenial lappie
[13:38] <vejmarie> he is running the server one
[13:38] <vejmarie> with X installed on it
[13:38] <ogra_> and i also see it in ubuntu-softare when i search for freecad
[13:39] <zyga> vejmarie: that's no different
[13:39] <ogra_> now ... why do i have to sign in to U1
[13:39] <vejmarie> I do not see it in ubuntu software
[13:39] <ogra_> i instaalled snaps yesterday and already did that ...
[13:39]  * ogra_ sighs ... not a nice experience 
[13:40] <vejmarie> he is running 2.0.3
[13:40] <vejmarie> we are upgrading
[13:40] <zyga> vejmarie: yeah upgrade to 2.0.5
[13:41]  * ogra_ watches it installing now
[13:41] <erio> ogra_: the old Ubuntu Software Center, even non snap related, had this losing logging every time problem.
[13:42] <ogra_> i wouldnt mind it if i had no 2fa enabled ... it is just super annoying to search my phone every time i use sw-center
[13:46] <sergiusens> ogra_ not necessary with `sudo` I believe
[13:46] <ogra_> sergiusens, sudo ?
[13:46] <sergiusens> ogra_ `sudo snap install freecad`
[13:46]  * sergiusens is installing freecad now
[13:47] <ogra_> sergiusens, i clicked on the organge paper bag in my launcher :P
[13:47] <erio> Is there a way to publish a snap to the store, but make it invisible to others? I wanted to test, but using the store as provider. Similar to ppa maybe.
[13:47] <ogra_> sergiusens, and ubuntu-software demands a new U1 login ... even though i did that yesterday when trying out another snap
[13:48] <sergiusens> erio that should be coming soon iirc. nessita might have the details
[13:48] <ogra_> now it would be really nice if the dash found any snaps that i search for :/
[13:48] <erio> Ok, thanks surgiu sen, that would be great. Ma
[13:49] <erio> Or maybe like Steam Early Access, just to put out really beta things, but that people using know upfront that the app is far from "finished
[13:49] <erio> "
[13:50] <nessita> sergiusens, details about...? :-)
[13:51] <vejmarie> good luck sergiusens
[13:51] <ogra_> nessita, to late, you are on the hook
[13:52] <vejmarie> do not forget to connect the snap to the interfaces
[13:52] <ogra_> so should the dash find any of the snaps i installed yet ?
[13:52] <ogra_> (definiely doesnt here)
[13:52] <vejmarie> by the way we still do not see free cad in ubuntu-software
[13:53] <vejmarie> how do you connect to a user account through the tool ? I didn't find this option
[13:53] <ogra_> if i search for "freecad" i see it here
[13:53] <kyrofa> nessita, details about private snaps
[13:53] <vejmarie> I think I am currently using the store without being connected to it, and perhaps do not have the credential to see my snap ;)
[13:53] <ogra_> works if i start it from a terminal :)
[13:54] <kyrofa> erio, for beta things we have the concept of "channels." edge, beta, candidate, and stable
[13:54] <ogra_> the fonts are slightly awful ... but it runs and all :)
[13:54] <kyrofa> erio, if something isn't stable, don't put it on the stable channel and the users who want to try out the unstable version can use another channel
[13:54] <ogra_> wheee !!!
[13:55] <ogra_> switching to german actually gets me german !
[13:55] <erio> Nice kyrofa_ thanks. Will look into it.
[13:56] <erio> This is the docs kyrofa ? https://developer.ubuntu.com/en/snappy/guides/channels/
[13:58] <kyrofa> erio, yeah, though that seems kind of specific to ubuntu core
[13:59] <vejmarie> ogra_: what are you testing ?
[13:59] <ogra_> vejmarie, freecad :)
[13:59] <kyrofa> erio, when you publish your snap, you just check the boxes for the channel(s) you'd like it to be released into
[13:59] <vejmarie> ogra_: good to see it switching from languages
[13:59] <ogra_> yeah
[13:59] <vejmarie> ogra_: I have noticed the font issues
[13:59] <vejmarie> this is a problem within the python code
[14:00] <ogra_> it actually seems to ship quite a few fonts
[14:00] <vejmarie> I am working on fixing it at the present time, but I am not yet an expert
[14:00] <davidcalle> erio, kyrofa: yeah, this doc is mostly for core images themselves, although, it gives an overview of our concept of channels
[14:00] <vejmarie> yes it ship the font
[14:00] <vejmarie> but looks for them in the wrong places
[14:00] <ogra_> ah
[14:00] <vejmarie> which explain why it default to ugly ones
[14:00] <vejmarie> I need to fix the code upstream
[14:00] <kyrofa> davidcalle, indeed
[14:02] <ogra_> vejmarie, well, in any case ... GOOD WORK !
[14:04] <vejmarie> thanks
[14:04] <vejmarie> I might be fixing the font during the night and we shall be good
[14:04] <vejmarie> then I need to find a way to run highly build and automatize updates
[14:05] <vejmarie> and we shall be good for ubuntu support
[14:05] <vejmarie> (I normally do MacOS build)
[14:05] <vejmarie> I shouldn't say that there, people will stop to speak with me
[14:13] <sergiusens> vejmarie freecad launched ;-)
[14:13] <vejmarie> good ;)
[14:13] <sergiusens> vejmarie it has been a while since I last used it. I'll try it out later in the day
[14:14] <sergiusens> vejmarie one sugary thing you can do is name the `FreeCAD` in apps just to be `freecad`, then you can launch it from the cli by just typing in `freecad` instead of `freecad.FreeCAD`
[14:15] <sergiusens> up to you though ;-)
[14:15] <vejmarie> no problem. Be careful this is a developper version (latest git), so there might be bugs
[14:15] <vejmarie> yep I will upgrade that, this is my first snap still need some cleanup
[14:15] <sergiusens> vejmarie ah, for developer versions and to make your users not run into unexpected expectations, you should use the approriate channels when publishing ;-)
[14:16] <vejmarie> yes do not worry this is my intend, I moved the channel temporarly
[14:16] <vejmarie> as to see if I can see it in the store (which is still not the case !)
[14:16] <vejmarie> I will update it tonight when I will have understood why my store can't see it
[14:17] <vejmarie> I would like to run nightly build and distribute it through snap which seems to be the best way to test a few crazy features into free cad which has some very heavy dependancy (OCCT is a massive stuff)
[14:21] <vejmarie> by the way sergiusens, I think the developer version is quite stable
[14:31] <vejmarie> if needed I can build a stable version
[14:35] <kyrofa> vejmarie, no need if you think it's stable enough-- the beauty here is that it's all your call!
[14:36] <kyrofa> vejmarie, the only limitation as I understand it is that you can't release a snap that _requires_ devmode into stable channels
[14:37] <ogra_> now you just need to convince apple to support snaps too ... and only have to roll one package ;)
[14:38] <vejmarie> kyrofa: it doesn't needs devmode ;)
[14:38] <kyrofa> vejmarie, then you're all good
[14:38] <vejmarie> ogra_: might be a challenge
[14:38] <ogra_> yeah, thats the most awesome bit :)
[14:39] <ogra_> vejmarie, just a "small" one :)
[14:39] <vejmarie> :)
[14:42] <roadmr> heya folks, I have a theoretical question :) how would I snap something like e.g. vim, which I'd like to be able to access pretty much any file in the system? not only in $HOME but say in /etc...
[14:45] <ogra_> you would tell users to use --dvemode
[14:45] <ogra_> *devmode
[14:45] <ogra_> or wait til some content charing mechanism is in place that you can hook into
[14:46] <ogra_> *sharing
[14:46] <roadmr> is that planned?
[14:46] <ogra_> well, unity8 has it ...
[14:46] <roadmr> because devmode has other implications as well, right?
[14:46] <ogra_> it makes the snap run unconfined
[14:47] <ogra_> but thats peobably what you want for an editor anyway
[14:49] <kyrofa> ogra_, I'm not sure the content sharing thing is what you want there, since I believe that's for inter-snap relationships
[14:51] <kyrofa> roadmr, if vi isn't unconfined you need to limit where it can write-- can't have it both ways
[14:51] <kyrofa> roadmr, sorry, my double negative made that hard to read
[14:53] <elopio> ~
[14:53] <sborovkov> hello, Is there some env variable for snap's common directory?
[14:54] <zyga> sborovkov: AFAIR not yet but I may have rusty memory
[14:54] <zyga> sborovkov: but there's a way to reach it using ../something/something reliably
[14:54]  * zyga looks
[14:55] <kyrofa> sborovkov, not yet
[14:55] <kyrofa> sborovkov, you can get to it via SNAP_DATA/../common
[14:55] <sborovkov> understood. thanks.
[14:56] <kyrofa> sborovkov, the user-specific one is SNAP_USER_DATA/../common, but the launcher doesn't have the smarts to create it just yet
[14:56] <kyrofa> (so it's not actually usable, sorry about that)
[14:56] <kyrofa> But the system wide one (next to SNAP_DATA) works fine
[14:57] <zyga> kyrofa: thanks
[14:58] <kyrofa> zyga, no problem. sborovkov they'll be named soon!
[14:58] <kyrofa> niemeyer, ^^
[15:06] <kyrofa> elopio, test test
[15:07] <elopio> works.
[15:10] <plars> xcb
[15:10] <plars> err
[15:10] <plars> kyrofa: hi, I found https://github.com/kyrofa/qt-example-snaps/blob/master/systray/parts/plugins/x-qmake.py which was really helpful
[15:10] <plars> kyrofa: I was wondering if there are plans to include it in snapcraft?
[15:11] <plars> kyrofa: also, I am hitting an error with qt things that I try to snap, wondering if you've seen it:
[15:11] <plars> This application failed to start because it could not find or load the Qt platform plugin "xcb"
[15:16] <kyrofa> plars, I wasn't planning on it, I was just collecting some qt examples there, but I suppose it could be
[15:16] <sergiusens> plars use `after` qt5conf` and in command do `command: qt5launch <cmd>`
[15:17] <kyrofa> plars, you need the stage-package I have there
[15:17] <kyrofa> And yes, the qt5conf bit
[15:17] <sergiusens> kyrofa we should add the plugin, tag it experimental if you think it is not prime time ready yet
[15:18] <kyrofa> sergiusens, I'm good with that. I wonder if kgunn might give us a review to make sure it's decent
[15:18] <sergiusens> kyrofa maybe jamiebennett wants to contribute a plugin :-P
[15:18] <kyrofa> plars, sergiusens oh oops, I didn't actually read the whole link, I thought plars was talking about the example, not the plugin. Yeah that should definitely be included
[15:19] <plars> yes, the plugin itself would be really useful
[15:19] <kyrofa> plars, agreed, we'll get that in there
[15:19] <plars> sergiusens: kyrofa: I'll give the qt5conf bit a try, thanks!
[15:19] <kyrofa> plars, we even have a bug for it.
[15:19] <plars> err, qt5launch
[15:20] <kyrofa> plars, yeah, refer to https://github.com/kyrofa/qt-example-snaps/blob/master/systray/snapcraft.yaml for details
[15:20]  * jamiebennett hides
[15:20] <kyrofa> jamiebennett, know anything about qmake?
[15:21] <jamiebennett> I know how to spell it ;)
[15:21] <sergiusens> jamiebennett that's a starter :-P
[15:21] <jamiebennett> But thats about it
[15:22] <sergiusens> elopio have you tried manually uploading with https://github.com/ubuntu-core/snapcraft/pull/532 ?
[15:22] <elopio> sergiusens: yes.
[15:22] <sergiusens> elopio than yay!
[15:23] <plars> sergiusens: kyrofa: that seems to have worked great, thanks!
[15:23] <kyrofa> jamiebennett, haha, no pressure, but if you feel like poking at snapcraft it should be a fairly easy one. Happy to take it though
[15:24] <kyrofa> plars, excellent! And thanks for the qmake poke
[15:25] <elopio> sergiusens: want me to update and rerun the tests?
[15:29] <kyrofa> kgunn, any chance you'd be willing to review a qmake plugin?
[15:29] <kgunn> kyrofa: sure
[15:29] <kgunn> i may not be the best...but i can always get some support there
[15:30] <kyrofa> kgunn, thanks-- I'm sure you'll be better than me! I'm mostly unclear about qt4 versus qt5
[15:31] <elopio> sergiusens: kyrofa: jamiebennett: fgimenez: yesterday I got a green execution of snapcraft all-snaps in bos01.
[15:31] <jamiebennett> \o/
[15:31] <elopio> I can work on getting the all-snaps images updated everyday there.
[15:32] <jamiebennett> elopio: Great work
[15:32] <kyrofa> Awesom elopio!
[15:32] <elopio> zyga: can you give me a short summary of the ubuntu-image status? Can I use it to generate images with core/edge ?
[15:32] <kyrofa> With an e
[15:33] <fgimenez> elopio, great!
[15:34] <elopio> fgimenez: to take into account when uploading the images, we need to pass the arch property, and also the hypervisor.
[15:35] <kgunn> kyrofa: was there a pull request, i checked your github activity didn't see it...
[15:35] <kyrofa> kgunn, oh no, sorry-- I'll ping you once I have something
[15:35] <kgunn> oh...nw
[15:35]  * kgunn goes back to being buried ;-P
[15:37]  * kyrofa shovels more dirt on kgunn
[15:49] <zyga> elopio: no, I'm busy with other tasks and I don't think that anyone else is touching it
[15:50] <elopio> zyga: ok, np, we will keep using the hacked one.
[15:51] <zyga> elopio: I think it is on my plate right after my current task
[15:53] <ysionneau> hmm for the extlinux.conf, am I supposed to put it inside the gadget snap ? or the kernel snap ?
[15:55] <zyga> ysionneau: what is extlinux.conf?
[15:57] <ysionneau> some kind of menu config for u-boot
[15:57] <ysionneau> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/boot-assets/uboot.env.in < the uboot script searches for it
[15:57] <zyga> ysionneau: that will be the gadget snap but only after the new ubuntu-image is in place
[15:57] <zyga> ysionneau: contributions are very much welcome
[15:58] <zyga> ysionneau: look at github.com/CanonicalLtd/ubuntu-image for details (there's a spec for gadget's image.yaml)
[15:58] <zyga> ysionneau: that desribes how to put the image togeter
[15:58] <ysionneau> ah, thanks!
[15:59] <ysionneau> this ubuntu-image is the replacement for UDF ?
[15:59] <sethj> looking through the latest snapd changelog it mentions a debian import/patch that fixes the XDG path issue. Does that mean this bug was fixed?
[15:59] <sethj> https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576303
[16:00] <zyga> ysionneau: yes
[16:00] <zyga> ysionneau: I can tell you anything you want to know about it
[16:00] <zyga> ysionneau: but I'm not currently working on it (preempted by other tasks)
[16:00] <ysionneau> fair enough!
[16:00] <zyga> ysionneau: I was going to implement and test the x86 side (there's no real difference but I was going to make new gadget snaps firsts)
[16:01] <zyga> ysionneau: but I would love someone to look after uboot side (again, no real difference for u-i)
[16:01] <ysionneau> well, if I can help somehow don't hesitate to ask
[16:03] <zyga> ysionneau: sure
[16:03] <zyga> ysionneau: you can help a lot by doing one simple thing
[16:04] <zyga> ysionneau: read the image.yaml spec there
[16:04] <zyga> ysionneau: and tell me how you'd describe an image using uboot
[16:04] <zyga> ysionneau: make a demo .yaml, stick it in a branch
[16:04] <zyga> ysionneau: at the same time, look at ...
[16:04]  * zyga looks
[16:05] <zyga> ysionneau: look at this http://paste.ubuntu.com/16922791/
[16:05] <zyga> ysionneau: this is a shell "prototype"
[16:06] <zyga> ysionneau: see if you can make a prototype like that, in shell, that assembles the image
[16:06] <zyga> ysionneau: use local snaps for everything (u-i downloads them but let's not worry about that)
[16:06] <ysionneau> hmmmm
[16:06] <zyga> ysionneau: if you can make that prototype and the corresponding image.yaml that will help me a lot
[16:07] <zyga> ysionneau: we have some code that takes the .yaml file and handles it so that we can create such shell scripts
[16:07] <ysionneau> I've made a shell script to generate "image" for my board from rpi2 snaps :o
[16:07] <ysionneau> is that of any interest?
[16:07] <zyga> ysionneau: yes!
[16:07] <zyga> ysionneau: note that u-i has one major design change from udf
[16:07] <ysionneau> https://github.com/fallen/snappy-tools/blob/master/paros_image/genimage.sh
[16:07] <zyga> ysionneau: it doesn't run any code that's system specific or that's shipped by the gadget
[16:07] <zyga> ysionneau: all the code is either generic (making partitions, filesystems, pupulating filesystem)
[16:07] <kyrofa> sergiusens, do you know anything about bug #1587193?
[16:07] <elopio> sergiusens: didrocks: If you get an error on jenkins saying something bos01, it was my fault. I'm reverting that. Sorry.
[16:07] <zyga> ysionneau: or the gadget has to ship a blob that we just stick at a given offset
[16:08] <zyga> ysionneau: so images should be 100% reproducible
[16:08] <zyga> ysionneau: the blobs can be built by the gadget snap
[16:08] <zyga> ysionneau: but similarly to how snaps are built, that's done while the gadget snap is being built
[16:08] <zyga> ysionneau: not when the image is assembled
[16:08] <zyga> ysionneau: the image is more of a linker
[16:08] <zyga> ysionneau: and takes pre-built things
[16:08] <zyga> ysionneau: does that make sense?
[16:09] <ysionneau> IIUC, the image.yaml is describing the flash layout and partitioning scheme and which file to flash where?
[16:09] <zyga> ysionneau: so your script would need to be split into something that you can snapcraft (or make) into a gadget.samp (containing image.yaml, files to put into filesystems, blobs to put into a fixed offset)
[16:09] <zyga> ysionneau: it describes how to create a big blob out of other "parts"
[16:10] <zyga> ysionneau: some of those parts are filesystems that it can populate
[16:10] <ysionneau> ah ok a big flashable blob
[16:10] <zyga> ysionneau: either with files from the gadget or with magic stuff to make the core snap work
[16:10] <ysionneau> right
[16:10] <zyga> ysionneau: and some other parts are just fixed blobs to stick somewhere (not a filesystem, not a partition)
[16:10] <zyga> ysionneau: e.g. boot code in the MBR
[16:10] <zyga> ysionneau: or stage-2 grub in the bios bootloader partition
[16:10] <zyga> ysionneau: or modem binary on dragon. etc
[16:11] <zyga> ysionneau: if you start to arrange your script into two scripts
[16:11] <zyga> ysionneau: one that builds the blobs or gets them from somewhere
[16:11] <zyga> ysionneau: does any computing needed
[16:11] <zyga> ysionneau: and spits out a gadget.snap
[16:11] <zyga> ysionneau: and another that is more akin to what I pasted as the prototype in shell
[16:11] <zyga> ysionneau: then we can align nicely
[16:11] <zyga> ysionneau: if you see any issues in this desing please tell me early
[16:12] <zyga> ysionneau: but I think the idea is flexible enough to build virtually any image (on any host OS)
[16:12] <ysionneau> one thing I think is important to say, here the input format for our flashing tool is a .tar, and not a .img
[16:12] <zyga> ysionneau: and without having to change ubuntu-image in any way (hence declartive image.yaml and prebuilt stuff in the gadget)
[16:12] <zyga> ysionneau: what is the tar content?
[16:12] <ysionneau> to flash, we basically send (via DFU or other) a bootloader, a kernel, and an installer (an ELF)
[16:13] <ysionneau> then we speak through USB to the installer
[16:13] <zyga> ysionneau: I see
[16:13] <zyga> ysionneau: that's okay
[16:13] <zyga> ysionneau: for 0.1 I'd like to just make an image reliably
[16:13] <zyga> ysionneau: for 1.0 we can export parts into various other formats
[16:13] <zyga> ysionneau: you can always take the image and export those with post-processing tools
[16:13] <zyga> ysionneau: all that is important is that the image can be built reliably and (perhaps) with 100% reproducibility
[16:14] <zyga> (apart from things like partition IDs but perhaps snapd will manage those on first boot, time will tell)
[16:14] <zyga> ysionneau: please stay in touch, I want to ensure you are supported
[16:14] <zyga> ysionneau: and please do consider hacking on ubuntu-image, I will gladly review patches and take new features
[16:16] <ysionneau> 18:12 < zyga> ysionneau: what is the tar content? < basically the entire file system(S)
[16:17] <ysionneau> it's nice that it is in Python and not go anyway
[16:17] <zyga> :-)
[16:17] <ysionneau> cause I can hack on Python and not at all on go =)
[16:17] <zyga> ysionneau: and I think it should be fairly small and well-defined
[16:17] <zyga> not open-ended like u-d-f with ever-growing list of "supported boards"
[16:17] <didrocks> elopio: thanks for the head's up!
[16:18] <ysionneau> to be more precise about our flashing process : we send a big .tar through USB and the installer 1°) formats the eMMC with the partition scheme 2°) mounts  partitions 3°) extracts the tar
[16:18] <ysionneau> the fact that we mount the partitions before untaring allows to put contents for several partitions in the same .tar file
[16:18] <zyga> ysionneau: note that ubuntu-image is precisely not ubuntu-flash
[16:18] <zyga> flashing is a separate tool that I'm not making today
[16:18] <ysionneau> (eg system-boot and writable)
[16:19] <ysionneau> yes but the image generation tool should be able to produce a file that can be processed by the flashing tool, right?
[16:19] <ysionneau> anyway, about the image generation process, Nvidia tools are doing a bit what your image.yaml is doing, except they use .xml
[16:20] <ysionneau> you either specify an .img for each partition, or a blob and that's it
[16:20] <zyga> ysionneau: that's a little open-ended, I think we will just make an image (intially), later on we might natively produce separate bits (just filesystem contents and the like)
[16:21] <zyga> the flashing tool is complex because there are lots of different things to do there
[16:21] <zyga> ysionneau: as long as we can take the  big image and build a target-specific tool that flashes it (doing anything it needs internally), I think we are good
[16:21] <zyga> ysionneau: can you point me to those tools? I'd like to know this better
[16:35] <tyhicks> zzarr: I accidentally highlighted your name with the message about -Wall and -Werror but meant to highlight someone else - sorry about that!
[16:35] <tyhicks> ysionneau: sorry but I haven't been able to debug it any more
[16:37] <ysionneau> zyga: Parrot tools unfortunately are not open source :/
[16:37] <ysionneau> and Nvidia ones, I don't know
[16:37]  * elopio <- afk.
[16:38] <ysionneau> zyga: I've got to go, maybe I can drop you an email with more precise info about our image generation / flashing process?
[16:39] <zyga> ysionneau: thanks
[16:39] <zyga> ysionneau: please do
[16:39] <zyga> ysionneau: do you have my address?
[16:40] <ysionneau> zyga: yes :)
[16:41] <ysionneau> see you soon!
[16:52] <zzarr> tyhicks, no problem, shows you are human :-)
[20:10] <kgunn> zyga: you about? finally got round to trying vm --visual, with mir i/f builtin to snapd
[20:10] <kgunn> curious, if i install mir-server snap...i see mir:mir-server under the plug column
[20:11] <kgunn> i would;ve thot mir slot would've shown up w.o mir-server snap being installed?
[20:12] <kgunn> e.g. it only appears in the interface list after mir-server snap installation
[21:16] <jdstrand> sergiusens: hey, looking at bug #1583259 I'm trying to understand what ends up in snap.yaml. snapcraft.yaml is clear-- will snap.yaml be the same or different?
[21:17] <sergiusens> jdstrand it will be a direct copy, a global `environment` (same level as `name`) and one special to each app in `apps`
[21:17] <sergiusens> jdstrand the consumer for this is snap-run
[21:20] <jdstrand> sergiusens: ack, thanks
[21:27] <zyga> kgunn: hmm
[21:27] <zyga> kgunn: can you please re-state that?
[21:27] <zyga> kgunn: which snaps did you install
[21:27] <zyga> kgunn: in what order
[21:27] <kgunn> zyga: sure...more a matter of curiosity as i see mir trying to launch...but here's what i did
[21:28] <kgunn> used your run-devel-vm --visual, then rebuilt snap/snapd, setup, run-snapd, then on the vm ./devtools.snap installed mir-server snap
[21:29] <kgunn> rebuilding snap/snapd b/c i added the mir interface to builtins
[21:29] <kgunn> literally "mir" being the interface name
[21:29] <zyga> okay
[21:29] <zyga> ah
[21:30] <zyga> hmmm
[21:30] <zyga> can you please point me to the mir interface?
[21:30] <zyga> it depends on how you made the interface
[21:30] <zyga> you can think of mir-server having a mir socket
[21:30] <zyga> s/socket/slot/
[21:30] <kgunn> zyga: i actually figured you were gonna say that :)
[21:30] <zyga> then the slot grants you permissions
[21:30] <zyga> and it's not on the core snap
[21:30] <zyga> (I think that is what we wanted)
[21:30] <zyga> you can also stick it on the core snap but I think that's less desired
[21:31] <zyga> because what we are still after is the mir plug for some demo client to run and talk to mir snap
[21:31] <zyga> in any case, I'm very happy that it's progressing and that the tooling around snapd works fine
[21:31] <zyga> if you have any questions please do ask
[21:32] <kgunn> so i implemented them as "permanent slot"
[21:33] <kgunn> and at this point, i'm not even to mir-client...this is just to get mir-server running on the core
[21:34] <kgunn> and i should be able to make some progress, like i say..i see mir-server trying to launch
[21:38] <zyga> kgunn: so the permissions to 'be mir' are on the permanent side of the mir slot?
[21:38] <zyga> kgunn: that sounds good
[22:36]  * zyga watches tests fly past his screen
[23:59] <kallisti5> any plans for 16.04 based snappy core?