[00:28] <sergiusens> elopio, kyrofa I think I want to disable the catkin plugin example test for now https://bugs.launchpad.net/snapcraft/+bug/1544790
[01:25] <yasser> hello
[01:26] <yasser> \join
[01:26] <yasser> anyone here?
[07:06] <didrocks> good morning!
[08:05] <fgimenez> good morning
[08:16] <dholbach> good morning
[08:16] <didrocks> hey dholbach, fgimenez!
[08:17] <fgimenez> morning didrocks and dholbach :)
[08:20] <mvo> hey fgimenez, good morning! how is the recent 15.04 alpha image looking? any issues that might block a migration?
[08:21] <fgimenez> hey mvo good to see you around! yep, all is fine with the image, i did a first pass with kvm and bbb and elopio confirmed including rpi2
[08:22] <fgimenez> mvo, are you feeling better?
[08:23] <dholbach> salut didrocks - hola fgimenez! :)
[08:28] <mvo> fgimenez: yeah, thanks! better, still not great but I wanted to cleanup some things before the weekend
[08:31] <mvo> fgimenez: very nice, thanks to you and elopio for the validation. I will create a new stable update then in the channel today then based on the validated alpha
[08:33] <fgimenez> mvo, great :)
[08:38] <dholbach> mvo, I hope you can take some time off and get well again?
[08:38] <mvo> dholbach: thanks, I feel better, just want to ensure I tie up some loose ends
[08:52] <zyga> asac: hey, I'm not sure -- that would be a framework but we removed them, I don't know what today can generate a dbus profile in 16.04
[08:52] <zyga> asac: I suspect it's 2 weeks away from trunk to be able to do that with skills
[09:33] <ysionneau> hi asac
[09:33] <asac> hi ysionneau
[09:41] <mvo> ogra_: hey, good morning! great work on the dragonboard. I upload your kernel snap to the store now and check the other snaps. that should allow building an image that can be updated remotly :)
[09:54] <vir17> hi, can I create a snap from .deb files?
[09:55] <zyga> mvo, ogra_: please ping me with updated instructions, I'll refresh ubuntu-image
[09:55] <zyga> once those bits are in the store
[09:55] <zyga> vir17: hey, maybe, please look at snapcraft examples on github
[10:01] <vir17> zyga:  I check and I cannot find an example that suits what I want to do, I forget to add that I want to have the .deb files into the folder where is the .yaml file and I try to find an example like that
[10:02] <zyga> vir17: why don't you just unpack those debs
[10:02] <zyga> vir17: there are plugins for just shoving a tar content into your snap
[10:03] <vir17> thanks zyga  i will try that
[10:03] <opny> Good morning, do you know a way to run an arm xenial image on qemu ? (In place of running snapcraft on the Pi)
[10:12] <mvo> ogra_: I uploaded the snaps now, hopefully http://paste.ubuntu.com/15023254/ will install it now all from the store. there is one open issue with the gadget snap as it does not download from the store right now (401 error). I suspect this will be resolved soon(ish), I asked the store people already. this should give us remote updateable arm64 images
[10:12] <zyga> mvo: \o/ great
[10:13] <zyga> mvo: can you tell me the names of each of the snaps?
[10:13] <mvo>      --gadget canonical-dragon.canonical \
[10:13] <mvo>      --kernel canonical-dragon-linux.canonical \
[10:13] <mvo>      --os ubuntu-core.canonical
[10:13] <mvo> zyga: -^
[10:14] <zyga> thanks!
[10:17] <mvo> ogra_: note that the ubuntu-core-arm64 is no longer needed, we now have multi-dimension snaps in the store so ubuntu-core on arm64 will resolve to the right ubuntu-core:arm64
[10:20] <zyga> mvo: works, except for the gadget
[10:20] <zyga> mvo: I'll keep gadget as a copy from ogra's directory
[10:21] <mvo> zyga: if you could build the image using the gadget with that dir and see if that boots that would be great. I mean, pass the local gadget but kernel and os from the store. if thats booting, then I can upload the image soon(ish)
[10:21] <zyga> mvo: actually, the kernel doesn't resolve
[10:21] <ogra_> mvo, uuh, stop
[10:21] <mvo> zyga: I will keep an eye on the store issue
[10:21] <mvo> ogra_: hm?
[10:21] <mvo> zyga: it does not?
[10:22] <ogra_> mvo, the gadget needs bootdely=0 set in uboot.env.in first
[10:22] <ogra_> *bootdelay
[10:22] <zyga> + exec sudo /home/zyga/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391 core rolling --channel edge --kernel canonical-dragon-linux.canonical --os ubuntu-core.canonical --gadget /home/zyga/.cache/ubuntu-image/blob.e9d33cda70f8384c0ec31e4822a6ed457c98ca7ce6682b93875390507903413a04d81e9a8c8966c32d2d32865f56e
[10:22] <zyga> 789be3cf25f8a66b1f1658b8fa4f8c443fe --developer-mode -o dragon-devel.img
[10:22] <zyga> Determining gadget configuration
[10:22] <ogra_> mvo, and the kernel snap needs a fixed resize script that can deal with GPT on u-boot (working on that today)
[10:23] <zyga> mvo: (downloads some parts then):
[10:23] <zyga> Installing canonical-dragon-linux.canonical
[10:23] <zyga> canonical-dragon-linux failed to install: snappy package not found
[10:23] <zyga> mvo: maybe it's not published yet, you can see which version of udf I was using here
[10:23] <mvo> ogra_: ok
[10:24] <mvo> zyga: ok
[10:24] <ogra_> mvo, with the bootdelay=0 we sadly wont be able to enter the uboot console (unless you set it to something other than 0) but you can at least boot without the serial board attached
[10:25] <mvo> ogra_: ok, I leave that to you
[10:25] <zyga> mvo: try your serial board again, use various usb cables, I had 1/4 work/not work ration
[10:25] <zyga> ratio*
[10:27] <mvo> zyga: I won't spend time on it today, other stuff is more important :)
[10:30] <zyga> sure
[10:31] <mvo> zyga: but thanks, good to know that there is a fail rate
[10:46] <asac> ysionneau: ricmm is ricardo
[10:47] <ysionneau> ok :)
[10:47] <ysionneau> thanks again guys!
[10:47] <ysionneau> I'll try to think about all of this, right now it's a lot to process :)
[10:48] <mvo> new (minor) stable update for 15.04 !
[10:50] <ogra_> mvo, including the new rpi oem snap ?
[10:50]  * ogra_ guesses so ... i guess the old one is gone from the store :)
[10:50] <mvo> ogra_: so far it is only a system-image update, no new image yet
[10:51] <ogra_> oh, that reminds me ... i havent updated snappy-hub yet
[10:51] <ogra_> but the snap is in the store, so you will get it
[11:10] <asac> ysionneau: right. can imagine, but in the end its pretty simplisitic :)
[11:48] <mvo> jdstrand: fwiw, a stable update via system-image is now enabled, no new images yet though but the right bits should flow to the people via the stable update
[12:18] <kyrofa> Good morning
[12:20] <didrocks> hey kyrofa!
[12:20] <kyrofa> Hey didrocks!
[12:21] <kyrofa> Haha, elopio yes, catkin is the worst build system on earth
[12:34] <vir17> anyone had installed snapcraft in raspian?
[12:35] <ogra_> ppisati, so we have another prob on the dragonbaord .... the MAC doesnt persist ...
[12:36] <zyga> ogra_: ohh?
[12:36] <ogra_> ppisati, apparently linaro does this https://git.linaro.org/landing-teams/working/qualcomm/wcnss-config.git/blob/HEAD:/wcnss-gen-macaddr to work around it ... but we dont get androidboot.serialno= in u-bnoot because the lk doesnt hand it over
[12:36] <ogra_> ppisati, i wonder if you know any method to pull the MAC out of /proc/device-tree in that case
[12:41] <vir17> I try to install snapcraft in rasbian.I clone the repository and then "sudo python setup.py install". When I try to create a snap I get this error: http://pastebin.com/b1ZAvFZW
[12:41] <vir17> anyone knows how to solve this?
[12:42] <sergiusens> kyrofa, didrocks morning
[12:42] <ogra_> vir17, what do you expect snapcraft in raspbian to produce once you have it installed ?
[12:43] <didrocks> hey sergiusens, how are you?
[12:43] <ogra_> vir17, i highly doubt the binaries woill be executable on snappy
[12:43] <sergiusens> didrocks, fine, just thinking we might need an FFe ;-)
[12:43] <didrocks> sergiusens: oh no, it's that fun time again! :-)
[12:43] <sergiusens> as we will barely land all the features next week
[12:43] <sergiusens> or we can just land everything broken
[12:43] <sergiusens> ;-)
[12:44] <didrocks> sergiusens: don't remind me of those dark times in the distro :)
[12:44] <kyrofa> Hey sergiusens :)
[12:44] <vir17> ok ogra_ i will abandon this solution then
[12:46] <sergiusens> kyrofa, hey, can you take a look at  https://bugs.launchpad.net/snapcraft/+bug/1544790
[12:47] <sergiusens> kyrofa, I want to either fix or disable that test in adt :-)
[12:47] <sergiusens> kyrofa, there might be a proxy issue
[12:47] <kyrofa> sergiusens, yeah that's a difficult log to digest, haha
[12:47] <kyrofa> sergiusens, I want my line breaks back!
[12:48] <sergiusens> kyrofa, maybe blame subunit
[12:48] <sergiusens> or elopio ;-)
[12:48] <sergiusens> kyrofa, I did grab the relevant failure there
[12:48] <sergiusens> kyrofa, should be reproduceable locally too iirc
[12:49] <kyrofa> Ah, I like reproduceable ones
[12:53] <sergiusens> kyrofa, you can probably edit debian/tests/control and just run the catkin example
[13:00] <kyrofa> sergiusens, ah, so I can't just run the example test to see this?
[13:01] <sergiusens> kyrofa, only reproduceable in an adt env
[13:02] <sergiusens> kyrofa, hmmm, unless the python path fix made it fail, but this test has been failing since before that
[13:02] <kyrofa> sergiusens, I've not had to do that before, can you point me in the right direction?
[13:02] <sergiusens> ogra_, wrt generic initrd; any ETA?
[13:03] <ogra_> sergiusens, after i'm done with the dragonbaord
[13:03] <ogra_> (i hoped to finish that today, but still digging on that MAC address issue atm)
[13:08] <sergiusens> dholbach, btw, is the clinic an hour from now, two or three?
[13:11] <sergiusens> kyrofa, when time permits https://github.com/ubuntu-core/snapcraft/pull/320
[13:12] <kyrofa> sergiusens, 3 I think
[13:13] <kyrofa> sergiusens, 1600 UTC, right?
[13:14] <sergiusens> kyrofa, what a relief :-)
[13:14] <kyrofa> sergiusens, hahaha
[13:14] <sergiusens> kyrofa, I hope you show up too, unless well, you know ;-)
[13:14] <kyrofa> sergiusens, I fully plan on it! Unless well, you know :P
[13:15] <kyrofa> sergiusens, 2.x features right? Got an idea of what we'll talk about?
[13:15] <kyrofa> sergiusens, will we try to stay on what is currently available, or will we discuss what it'll be come 16.04?
[13:22] <ogra_> mvo, for setting the MAC on the dragonboard we need /lib/firmware/wlan/macaddr0 being writable :/
[13:23] <ogra_> yay android drivers :((
[13:23] <sergiusens> kyrofa, differencenes between 1 and 2; then what is coming for 2
[13:23] <kyrofa> sergiusens, sounds fun!
[13:24]  * zyga has updated unofficial ubuntu-image to handle dragon board from the store
[13:25] <mvo> ogra_: uh, we need /lib/firmware/wlan/macaddr0 to be writable?!?
[13:25] <ogra_> mvo, well, we need that file to contain the MAC
[13:25] <ogra_> if you have an idea how to do it without a writable file ...
[13:26] <mvo> ogra_: we could make it a symlink in the os snap and point to something in /run that the initrd creates/populates
[13:26] <mvo> ogra_: but all rather terrible
[13:26] <ogra_> (i mean, we could also patch the driver top look somewhere else ... but i doubt ppisati would like to carry such a patch forever)
[13:27] <ogra_> *to look
[13:40] <ppisati> ogra_: that information is not part of the device tree
[13:40] <ogra_> ppisati, well ... it is ...
[13:40] <ogra_> but only of the lk DT
[13:40] <ppisati> ogra_: uhm
[13:40] <ogra_> i just found a way to parse that from uboot ... similar to how we do it on the rpi
[13:42] <ppisati> ogra_: how did you do that?
[13:42] <ogra_> "fdt addr $value_i_fished_out_of_lk_output ; fdt get value args /chosen bootargs"
[13:43] <ogra_> thsi works by hand ... still fiddling with scripting it now
[13:43] <ppisati> ogra_: oh ok
[13:43] <jdstrand> mvo: thanks! I see my devices were updated and have the security updates :)
[13:43]  * jdstrand isn't really here
[13:43] <jdstrand> mvo: you feeling better?
[13:44] <ogra_> => fdt addr 0x81e00000
[13:44] <ogra_> => fdt get value args /chosen bootargs
[13:44] <ogra_> => printenv args
[13:44] <ogra_> args= androidboot.emmc=true androidboot.serialno=7c16331a androidboot.baseband=apq mdss_mdp.panel=0:dsi:0:
[13:44] <ogra_> ppisati, ^^^
[13:44] <ppisati> ogra_: but there's no mac address there
[13:44] <ogra_> ppisati, the serial is the MAC
[13:45] <kyrofa> ogra_, so I can't seem to get the all-snaps image to boot on the dragonboard. I have the SD card switch on, but it keeps booting to the linaro image I flashed to internal. Is that interfering somehow? Or did I just fail on resizing the partition?
[13:45] <ogra_> kyrofa, it obnly works on 4GB cards ... like the big fat notice in the README says
[13:45] <ogra_> and yes, resizing still wipes the partition table
[13:46] <kyrofa> ogra_, I know, but you mentioned if I resized manually before trying to boot it shouldn't try the resize
[13:46] <kyrofa> ogra_, but it was a little weird on trusty
[13:46] <kyrofa> ogra_, so I wouldn't be surprised if it didn't work out
[13:46] <ogra_> hmm, perhaps your manual resize somehow messed it up ?
[13:47] <ogra_> you need to be super sure the IDs, size and content of the first partitions doesnt change ... ever
[13:48] <kyrofa> ogra_, yeah. Okay I just wanted to make sure there wasn't something special I was supposed to do if I had already flashed another image. Any chance you could let me know when that resize bug is fixed?
[13:48] <kyrofa> ogra_, or is there a bug I can keep my eye on?
[13:48] <jdstrand> mvo: I'm on holiday today so stepping away (after asking my question). I'll take the fact that you are here as you feeling better (and I'm glad for it)
[13:49] <ogra_> kyrofa, no bug ... but i was planning to get this done today ... its a matter of how long this MAC address thing now takes ... i didnt plan that one :P
[13:49] <jdstrand> mvo: I'll also provide a potentially other clue on the apps reinstalling over and over again on stable. it seems to only happen with snaps that exist in both rolling and stable. eg, hello-world and snappy-debug, but not ufw
[13:50] <kyrofa> ogra_, oh you're good man, I didn't mean to rush you :)
[13:50] <kyrofa> ogra_, glad to hear it's on the horizon, though
[13:50] <jdstrand> mvo: I don't know if that is a definite part of the problem-- it is just something I noticed
[13:50] <ogra_> well, i need to work on generic initrd next week ... so i ant the dragonboard done today
[13:51] <jdstrand> ok, really gone now
[13:51] <kyrofa> ogra_, understood. By the way, is that porting guide still applicable? Or does it need to be rewritten completely for all-snaps?
[13:51] <ogra_> the latter
[13:52] <ogra_> i'll work on that once we are through all these conference thingies :)
[13:52] <kyrofa> There's one piece of hardware I'd really like to support, and I feel like it'd be a great learning experience
[14:01] <ogra_> ubuntu@localhost:~$ cat /proc/cmdline
[14:01] <ogra_>  androidboot.emmc=true androidboot.serialno=7c16331a androidboot.baseband=apq mdss_mdp.panel=0:dsi:0: console=ttyMSM0,115200n8 root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc snappy_os=ubuntu-core-arm64.sideload_IMNAJeAIfTOc.snap snappy_kernel=canonical-dragon-linux.sideload_IMNAJdKaXGIP.snap
[14:01]  * ogra_ dances 
[14:06] <mvo> ogra_: nice!
[14:07] <mvo> jdstrand: cool, thanks and enjoy your holiday
[14:08] <ogra_> mvo, well, thats only half the fix .... we need something like https://git.linaro.org/landing-teams/working/qualcomm/wcnss-config.git/blob/HEAD:/wcnss-gen-macaddr now
[14:09] <mvo> ok
[14:09] <ogra_> i get cold shivers seeing that code though :P
[14:11] <ogra_> (especially the "first writing the file wrongly and then fixing it with sed" part ...)
[14:16] <dholbach> sergiusens, 16 UTC, so in 1h44m from now
[14:16] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/30
[14:16] <ogra_> changes pushed
[14:36] <zyga> https://github.com/zyga/devtools updated with i386 snappy, i386 virtualization and latest dragonboard support
[14:54] <sergiusens> dholbach, thanks
[15:19] <ogra_> mvo, would you do me a favour and push that update for the dragon to the store ?
[15:19] <ogra_> (with fresh uboot.env generated from rev 30 on snappy-hub)
[15:19] <ogra_> (if you dont have time i'll do it tonight)
[15:30] <elopio> fgimenez: we are still in the snapcraft planning session.
[15:30] <elopio> you can join us if you want :)
[15:31] <rtg> I've been trying out the kvm instructions in order to test sideloading a 16.04 kernel snap. However, the instructions on the web page do not appear to be correct. The example for 15.04 doesn't work, e.g.,
[15:31] <rtg> sudo kvm -m 512 -redir :8090::80 -redir :8022::22 ubuntu-15.04-snappy-amd64-generic.img
[15:31] <rtg> WARNING: Image format was not specified for 'ubuntu-15.04-snappy-amd64-generic.img' and probing guessed raw.
[15:31] <rtg>          Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
[15:31] <rtg>          Specify the 'raw' format explicitly to remove the restrictions.
[15:31] <rtg> Could not initialize SDL(No available video device) - exiting
[15:31] <fgimenez> elopio, i'm not feeling well today, still a bit sick, maybe next time :)
[15:32] <mvo> ogra_: sure, I assume I can just bzr up; snappy build?
[15:32] <ogra_> i guess so ... hwo did you produce the last one ?
[15:32] <ogra_> :)
[15:32] <mvo> ogra_: exactly this way
[15:32] <ogra_> yeah, then it shoudl eb fine ... uboot.env needs updating first ...
[15:33] <mvo> ogra_: I ran mkenvimage
[15:33] <ogra_> well, let me do that and commit it so the bionary is in sync with the source
[15:33] <ogra_> ah, k
[15:35] <wiggleworm> I am looking for some help installing java on snappy so that my app will run. I think I need to have it packaged along with my app during the snap craft process but not sure.
[15:35] <wiggleworm> has anyone here done such a thing
[15:35] <ogra_> wiggleworm, i think there are examples for snapcraft to get the java bits bundled properly inside your snap
[15:36] <mvo> ogra_: bootdelay is zero and the bootargs is for the mac address?
[15:36] <ogra_> mvo, yeah
[15:36] <ogra_> the bootdelay thing is a bit unfortunate but no better workaround for now
[15:36] <mvo> ogra_: ha! thats magic
[15:37] <sergiusens> wiggleworm, yeah, run 'snapcraft help ant' or `snapcraft help maven'
[15:37] <sergiusens> wiggleworm, also look at the examples for maven and a hello world
[15:37] <wiggleworm> ok - thanks I will take a look
[15:37] <mvo> ogra_: I pushed to "edge", if you could double check that everything is ok and give me green light I push to stable
[15:38] <ogra_> mvo, ok
[15:40] <ogra_> mvo, hmm is --gadget canonical-dragon/edge the right syntax ?
[15:40] <ogra_> seems u-d-f doesntz find it (with or without /edge)
[15:41] <mvo> ogra_: http://paste.ubuntu.com/15023254/ works for me
[15:41] <ogra_> ah .canonical
[15:41] <mvo> ogra_: this should give us fully updaable ones, well - except for the partition resize issue :)
[15:42] <ogra_> yeah, i hope to get that done before EOD ... its just super time consuming since i need to test on all arches (lots of dd*'ing and waiting)
[15:43] <ogra_> i wonder if i shoudl just make the resize code a no-op just for this initrd for now ... that would be quick and dirty :)
[15:44] <ogra_> mvo, hmm u-d-f dies for me with "can not find OS part"
[15:45] <ogra_> using --os ubuntu-core.canonical like in your paste
[15:45] <ogra_> bah, silly me ... forgot --channel :P
[15:52] <mvo> ogra_: :)
[15:52] <mvo> ogra_: if all is looking well I'm happy to promote to stable
[15:53] <ogra_> mvo, i'll let you know ...
[15:53]  * ogra_ waits for xz and dd
[16:02] <dholbach> for everyone waiting for the Snappy Clinic - we're just about to start
[16:02] <dholbach> http://ubuntuonair.com
[16:05] <dholbach> if you have questions for the clinic, just make sure you prefix them with QUESTION:
[16:07] <ogra_> ubuntu@localhost:~$ cat /proc/cmdline
[16:07] <ogra_>  androidboot.emmc=true androidboot.serialno=7c16331a androidboot.baseband=apq mdss_mdp.panel=0:dsi:0: console=ttyMSM0,115200n8 root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc snappy_os=ubuntu-core.canonical_16.04.0-3.arm64.snap snappy_kernel=canonical-dragon-linux.sideload_IMRdLKVUXAPL.snap
[16:07] <ogra_> mvo, ^^^ looks good ... and boots with serial board detached too
[16:07] <ogra_> mvo, promote it :)
[16:09] <mvo> ogra_: all snaps available on stable now, once the resize bug is fixed we should push a new image
[16:10] <ogra_> mvo, yeah, i'll probably go with a quick fix specific to this initrd for now (and i can also quickly hack it up to get the MAC linked into /lib/firemware/wlan)
[16:10] <ogra_> i can luckily do it all inside the -linux snap
[16:17] <sergiusens> mvo, can we get a new OS today or is that too much to ask?
[16:18] <ysionneau> asac: do you know any target supported by snappy, with a somehow working qemu port?
[16:19] <ogra_> ysionneau, amd64
[16:20] <ysionneau> sorry, I forgot to mention : arm target
[16:20] <ogra_> heh
[16:20] <ogra_> i dont think there is any
[16:20] <ysionneau> I found a qemu-raspi2 on github, didn't manage to get it to work yet though
[16:20] <noizer> QUESTION: how long does it take for an app to be reviewed?
[16:20] <mvo> sergiusens: what do you need in the new OS? happy to build one, we just won't have snappy updated because the auto-build is broken
[16:21] <ysionneau> https://github.com/0xabu/qemu
[16:21] <ogra_> noise][, auto-revie is usually happening in munites
[16:21] <mvo> ogra_: +1
[16:21] <ogra_> bah
[16:21] <mvo> sergiusens: any particular arch that is important to you?
[16:21] <ogra_> noizer, ^^^
[16:21] <sergiusens> mvo, snap launcher
[16:21] <sergiusens> mvo, it creates dirs, also systemd SNAP_USER_DATA set correctly
[16:21] <noizer> ogra :p
[16:21] <sergiusens> mvo, x86 and armhf
[16:21] <ogra_> noizer, manual review can takes weeks or months and is also likely to be rejected
[16:21] <sergiusens> first more important than the second
[16:22] <noizer> ogra_ ok
[16:22] <noizer> awesome
[16:25] <noizer> QUESTION: will it be possible to share libraries over multiple snaps with skills? (SO files)
[16:27] <dholbach> nice questions - keep them coming :)
[16:34] <mvo> sergiusens: ubuntu-core is updated for amd64 in the edge channel, if you could give it a quick test if it has what you need I will promote
[16:35] <mvo> sergiusens: arm is ready in some minutes as well
[16:38] <elopio> pitti: is this a correct incantation? https://paste.ubuntu.com/15025272/
[16:38] <elopio> It just gets stuck after creating the instance.
[16:42] <noizer> snapcraft 2 is realy awesome :D
[16:43] <ogra_> it is !!
[16:44] <noizer> yea xD just one problem I had was when I'm installing my snap to much I cant delete it
[16:44] <dholbach> any more questions? :)
[16:45] <noizer> When will be the stable release for 16.04.
[16:45] <noizer> ?
[16:46] <kyrofa> noizer, april 2016
[16:46] <noizer> kyrofa nicee :D
[16:46] <kyrofa> (those release numbers are dates)
[16:47] <noizer> kyrofa ooh didn't know that
[16:51] <sgclark> If I ever finish debian merges I still plan on tackling kde :)
[16:52] <dholbach> thanks everyone!
[16:52] <sgclark> ty
[16:52] <elopio> thanks to you dholbach.
[16:53] <kyrofa> Thanks dholbach :)
[16:56] <dholbach> sergiusens, kyrofa, elopio: thank YOU :)
[17:01] <thibaut> QUESTION: When will we be able to run graphical snaps on the desktop?
[17:05] <ogra_> probably not before the desktop defaults to Mir
[17:12] <ogra_> "§%e%/&§$=%§/%/& !!!!
[17:12] <ogra_> GRRRR
[17:14] <ogra_> ^^^ this is me when accidentially hititng the "cursor up" and enter keys  in a terminal where dd just finished ....
[17:14] <ogra_> :(((
[17:14] <zyga> ogra_: lol
[17:14] <zyga> ogra_: dd should remember the last request and ask "are you sure? [n/y]"
[17:14] <ogra_> yeah
[17:15] <zyga> speaking of which, let's try parted
[17:15] <ogra_> the bad thing is that i didnt just leave it running but did hit ctrl-C .... which gets only respected after it is half done :/
[17:16] <ogra_> so another useless dd-time-waste
[17:16] <zyga> ogra_: oh, SIGINT clobbers the card?
[17:16] <zyga> ogra_: as in writing partially shit?
[17:17] <ogra_> well, you hit ctrl C but it will finish writing the block from ram ... depening on the blocksize you have a half written card then
[17:17]  * ogra_ uis curently using bs=128M ... dd wrote ~400M (it told me) even with ctrt-C
[17:18] <zyga> well, is the rest different compared to earlier write?
[17:18] <zyga> it seems that it's just an overwrite
[17:18] <zyga> with same blob
[17:18] <zyga> so it should be safe to kill
[17:19]  * ogra_ boots and sits in awe
[17:19] <sergiusens> thibaut, were you watching the hangout in non live mode?
[17:20] <ogra_> ubuntu@localhost:~$ ifconfig wlan0|grep HW
[17:20] <ogra_> wlan0     Link encap:Ethernet  HWaddr 02:00:7c:16:33:1a
[17:20] <ogra_> ubuntu@localhost:~$ cat /run/macaddr0
[17:20] <ogra_> 02:00:7c:16:33:1a
[17:20] <ogra_> YAY !!!!!!
[17:22] <zyga> ogra_: new gadget or kernel?
[17:22] <ogra_> zyga, kernel ... resize cvompletely ripped out and MAC adedress handling fixed (that will both need more work later, but good enough for now)
[17:22] <elopio> sergiusens: how did you generate your changes file?
[17:23] <zyga> hmm, I have terrible serial data connection
[17:23] <zyga> tons of bytes lost
[17:23] <dholbach> all right my friends - have a great weekend!
[17:23] <zyga> ogra_: gimme, I'll gladly try it
[17:23] <zyga> dholbach: likewise, enjoy
[17:23] <ogra_> zyga, currently uploading for mvo to push it to the store
[17:24] <zyga> ogra_: so will that actually auto-update/
[17:24] <ogra_> mvo, http://people.canonical.com/~ogra/snappy/dragonboard/tmp/canonical-dragon-linux_4.2.0-2012-generic-dragon410c_arm64.snap ... push to edge again and i'Äll test it from the store, then we can release
[17:24] <ogra_> zyga, i guess
[17:24] <zyga> woot
[17:25] <zyga> ogra_: how do you rebuild from the store?
[17:25] <zyga> ogra_: anything I could tweak in ubuntu-image for that?
[17:25] <didrocks> have a good week-end everyone!
[17:25] <ogra_> for what exactly ?
[17:27] <zyga> ogra_: for being able to get fresher (test) snaps
[17:27] <ogra_> zyga, well, i guess from now on we'll just push to the store regulary
[17:28] <ogra_> so as long as you use the edge channel you will get the latest crack
[17:29] <sergiusens> elopio, gbp buildpackage -S
[17:30] <zyga> ogra_: perfect
[17:33] <zyga> ogra_: does 'sudo snappy update' works for you?
[17:34] <zyga> ogra_: for me it doesn't (store issue?)
[17:34] <ogra_> i'd have to set up networking
[17:34] <zyga> ahh
[17:34] <zyga> I didn't either - sorry :)
[17:35] <ogra_> yeah, then snappy spills that wonderful informative error message
[17:36] <ogra_> zyga, but what would you want to update ? there is no new rootfs or anything
[17:36] <zyga> ogra_: the new kernel, later
[17:37] <ogra_> not sure the old one was uploaded yet
[17:37] <zyga> ogra_: btw, the kernel version is weird, is the generic-dragon410c needed?
[17:37] <zyga> ogra_: it had to be, I built the image I'm running from the store earlier
[17:37] <ogra_> (that might cause us issues since we dont have a minor version we can easily bump)
[17:37] <zyga> (well 30 minutes ago)
[17:38] <ogra_> not sure how/if mvo can solve that
[17:38] <zyga> mvo can do anything :)
[17:39] <ogra_> if the store lets him :P
[17:39] <ogra_> beuno can break all of us nowadays, he has the powah :)
[17:41] <zyga> still I cannot be happier, all my 6 boards are working
[17:41] <ssweeny> trying to install lxd from the store on my rpi2 (rolling, all-snap) I get this error: lxd failed to install: can not open /tmp/lxd893703768: cannot open snap: unknown header: "!<arch>\ndebian-binar"
[17:41] <zyga> ssweeny: the snap is using the old format (not valid for 16.04)
[17:41] <ssweeny> aha
[17:42] <zyga> ssweeny: it's the clickdeb format apparently
[17:42] <ogra_> ssweeny, yeah, stgraber needs to update the snap to the new all-snaps setup (using squashfs and all via snapcraft 2.x)
[17:42] <ssweeny> that makes sense
[17:42] <ssweeny> this is from before 16.04 moved I take it
[17:42] <ogra_> yeah
[17:43] <ssweeny> since other 15.04 snaps don't show up at all for me
[17:43] <ogra_> most of the snaps are currently non-installable from the store ... only few have been updated yet
[17:44] <ssweeny> ok, good to know
[17:44] <ssweeny> i suppose i can use classic mode for development until containers are working again
[17:45] <ogra_> yeah ... effectively you should now always use classic mode
[17:45] <ogra_> (it is just a container after all :) but with a lot less overhead)
[17:45] <ssweeny> right :)
[17:46]  * ogra_ needs to get dinner ... mvo let me know if there is something i can test :)
[17:47] <zyga> ogra_: FYI classic on dragon doesn't work
[17:48] <zyga> ogra_: missing parts somewhere:
[17:48] <zyga> ubuntu@localhost:/etc/network/interfaces.d$ sudo snappy enable-classic
[17:48] <zyga> needle "ubuntu;xenial;arm64;default;" not found
[17:49] <sergiusens> zyga, I bet there isn't an arm64 image available on the image server
[17:49] <sergiusens> zyga, ogra_ yeah, that's it http://images.linuxcontainers.org/images/ubuntu/xenial/
[17:50] <ogra_> zyga, yes, known, stgraber is on it
[17:50] <sergiusens> hah, was just about to ping him ;-)
[17:50] <zyga> thanks!
[17:51] <ogra_> zyga, sergiusens bug 1543764
[17:53] <asac> ysionneau: we only use qemu for x86... otherwise boards
[17:54] <asac> ysionneau: shouldnt be that hard to make it work on versatile though etc.
[17:54] <ysionneau> I am now able to boot the raspberry pi 2 img (with my own kernel) on some custom qemu
[17:54] <ysionneau> but it fails to login with ubuntu:ubuntu l/p
[17:55] <asac> hmmmm
[17:55] <asac> ysionneau: so i think the ubuntu/ubuntu credential might be set by cloud-init... do you see that running? (dont ask why its called like that :))
[17:55]  * ogra_ doubts you actually booted correctly then
[17:56] <ysionneau> ah, cloud-init is failing :)
[17:56] <ysionneau> maybe because I get no network
[17:56] <ogra_> and writable is most likely not properly mounted either
[17:56] <asac> that shouldnt be a problem for credentials
[17:56] <ogra_> asac, thats just fallout
[17:56] <asac> ysionneau: ogra is your man i guess :) ... he is the master of ARM bringups :P
[17:57] <ogra_> did you actually fish the initrd out of the image to hand it to qemu (i assume you need to point it to kernel and initrd on cmdline)
[17:57] <zyga> ysionneau: try https://github.com/zyga/devtools/
[17:57] <zyga> ysionneau: if you just want a working vm
[17:57] <zyga> ysionneau: for other goals -> look elsewhere :)
[17:57] <asac> zyga: he is experimenting how to his own kernel/board etc.
[17:57] <asac> on 15.04
[17:57] <zyga> ah
[17:57] <ysionneau> ogra_: nop I didn't put the initrd from the image in qemu, I'll do that :)
[17:58] <asac> ysionneau: so if you have your own kernel there are a couple patches you need for our security bits
[17:58] <asac> that you need to add
[17:58] <ysionneau> something which bothers me is that I wasn't able to tell qemu to just boot from the .img
[17:58] <ogra_> ysionneau, well, only if you actually use --ramdisk and --kernel options in qemu indeed
[17:58] <ysionneau> I had to build my own kernel/dtb and pass it to -kernel
[17:58] <asac> yeah snappy needs our initrd
[17:58] <ysionneau> and then with the root=/dev/mmcblk0p2 it works
[17:58] <asac> thats where the magic failover bootlogic and other stuff is
[17:58] <ysionneau> so I'm not even using the snappy kernel
[17:58] <ogra_> i really doubt you can get that to work at all
[17:59] <ogra_> outr image needs crtain bootloadder login that lives in uboot
[17:59] <ysionneau> arg ok
[17:59] <ogra_> root=/dev/mmcblk0p2 isnt enough
[17:59] <ogra_> (the cmdline is actually getting assembled during boot)
[17:59] <ysionneau> do you know how to tell qemu to boot directly from the sd ? :o
[17:59] <asac> ysionneau: in case you want to do your own kernel check out these: https://wiki.ubuntu.com/SecurityTeam/AppArmorForSnappyKernels
[17:59] <ysionneau> asac: thx
[18:00] <kyrofa> elopio, sergiusens so adt-run passed for me on xenial...
[18:00] <ogra_> i'm not sure the qemu arm system implementation can actually use u-boot (i could be wrong though, it is years that i have used qemu-system last)
[18:01] <kyrofa> elopio, sergiusens just using the released package as a test. Shouldn't they fail?
[18:01] <rtg> ogra_, where do the magic scripts for the initrd live ? I've got kernel snaps working for raspi2 and BBB (and sort of working for amd64/i386)
[18:01] <asac> ogra_: i know that beagleboard worked with uboot iirc
[18:01] <ogra_> rtg, initramfs-tools-ubuntu-core
[18:01] <rtg> ogra_, right, lemme make sure I'm getting those in rootstock
[18:01] <ogra_> asac, yeah, but also with -kernel and -ramdisk iirc so thats only half
[18:01] <asac> i think its more likely you could get a beagleboard image work on qemu with uboot... as upstream state is far more
[18:02] <asac> ogra_: no... i remember us booting it with .img
[18:02] <ogra_> asac, beagleboard != beaglebone :(
[18:02] <asac> right
[18:02] <ogra_> anyway ...
[18:02] <asac> still i think its more likely to work with beaglebone than pi2
[18:02]  * ogra_ goes back to the dinner table :P
[18:02] <sergiusens> kyrofa, drats, that means it will be a hard fix
[18:02] <asac> given that beaglebone works all plain vanilla upstream
[18:02] <kyrofa> sergiusens, yeah :(
[18:03] <asac> for beagleboard with img see https://wiki.linaro.org/Resources/HowTo/Qemu-beagleboard
[18:03] <asac> so maybe building kernel and uboot for beagleboard might be a way to get this going
[18:05] <sergiusens> ogra_, there is nothing simple about this json http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:download.json
[18:05] <asac> do we have a prebuilt bone .img?
[18:05] <ogra_> sergiusens, thats what i learned today ... sadly
[18:06] <sergiusens> ogra_, I prefer the container site (which is what I started to use for cleanbuild)
[18:06] <zyga> asac: I tried qemu with beagle * and support in our ubuntu copy of qemu is no longer there
[18:07] <zyga> asac: linaro had a patched qemu that had -M beaglexm support
[18:07] <zyga> asac: I tried this earlier today
[18:07] <asac> hmm. that never made it upstream?
[18:07] <asac> bummer
[18:07] <zyga> asac: or got removed, it's not in our qemu for sure
[18:07] <zyga> asac: probably just a linaro patch
[18:08] <asac> https://launchpad.net/qemu-linaro
[18:08] <asac> seems outdated too there
[18:08] <zyga> yeah, linaro moved to internal git
[18:09] <asac> internal?
[18:09] <zyga> well
[18:09] <zyga> internally hosted :)
[18:09] <zyga> it's public for most of the part
[18:09] <zyga> https://git.linaro.org/
[18:09] <zyga> tons of hits for qemu, good luck finding the right branch to follow
[18:09] <zyga> I'd look for tarballs
[18:10] <asac> http://git.linaro.org/pkg/qemu-linaro.git also not better
[18:10] <zyga> well, someone would have to have a look, compare to upstream, etc
[18:10] <zyga> asac: is the goal to have bbb image working in qemu
[18:10] <zyga> ?
[18:11] <asac> that would be a good start i guess
[18:11] <asac> think cool woudl be to have snappy work on any qemu
[18:11] <asac> doesnt matter which kernel etc.
[18:12] <zyga> right
[18:12] <zyga> I'd switch to one of the supported vexpress modules and just build a vexpress kernel
[18:12] <asac> ok asked fabo in #linaro
[18:12] <zyga> probably saner than chasing $random_board kernels
[18:12] <zyga> and emulation
[18:13] <asac> yeah guess vexpress would be the best wayt o go, but that doesnt have u-boot
[18:13] <asac> so you cant do the real thing
[18:13] <asac> with tx updates and friends
[18:13] <zyga> what does it do to boot?
[18:13] <zyga> efi?
[18:13] <asac> nothing
[18:13] <zyga> oh?
[18:13] <asac> just pure kernel i think
[18:13] <asac> with qemu setting things up right to start
[18:13] <zyga> isn't that something you can also get physically, with big fpga's and stuff
[18:13] <zyga> it boots off sd cards AFAIR
[18:13] <asac> yeah you can get vexpress
[18:14] <asac> those are cool :)
[18:14] <asac> cost a lot, but you can swap out SoCs in plug and play fashion :P
[18:14] <zyga> I mean, if the real thing boots from SD, does it also load a kernel from some fixed offset?
[18:14] <asac> its a motherboard basically where you can plug in new SoCs that are just reference low-volume SoCs done by ARM
[18:14] <zyga> can we do something like that for the emulated vexpress with barebones kernel/u-boot?
[18:14] <zyga> ah
[18:15] <zyga> well, let's see what fabo says
[18:15] <asac> the real thing boots very weird i remember
[18:15]  * zyga hasn't seen fabo in ages
[18:15] <asac> lots of stuff you can do
[18:15] <asac> before it even hits the bootloader afaik
[18:15] <asac> but then, we dont have one of those toys anyway :P
[18:15] <asac> ok i am out for a bit...
[18:17] <kyrofa> sergiusens, so maybe disable the test for now since the catkin plugin may be changing a bit?
[18:18] <kyrofa> sergiusens, I don't understand why I'm not seeing the failure. Have you tried locally?
[18:19] <sergiusens> kyrofa, not today, network errors a galore
[18:19] <kyrofa> pitti, hey, your docs on autopkgtest were extremely helpful by the way
[18:25] <ogra_> mvo, i have an appointment in ~30min ... if there is anything to test in the edge channel, just leave me a note here and i can test later tonight
[18:26] <ogra_> mvo, (regarding the kernel from above that is)
[18:43] <mvo> ogra_: hi, sorry, was at dinner myself, I'm uploading now, I made up a version number for you (added a +1 at the end :P and that should be enough to make the store and snappy happy
[18:43] <kyrofa> mvo, if I wanted to test out all-snaps edge, how would I do it?
[18:44] <ogra_> mvo, yeah, but we need to find some agreement with the kernel guys how we do that in the future (without clashing etc)
[18:44] <mvo> kyrofa: http://people.canonical.com/~mvo/all-snaps/ is the best place and then use "snappy update ubuntu-core/edge "
[18:45] <mvo> kyrofa: that should work if not let me know :)
[18:45] <kyrofa> Ah, so just change channel from within the image? Okay easy enough :)
[18:45] <mvo> ogra_: adding a +1 (or +2) should always be safe
[18:45] <mvo> kyrofa: well, it should work if not we need to talk
[18:45] <mvo> kyrofa: and it works today, next week on the sprint the /channel syntax is up for discussion
[18:45] <kyrofa> mvo, heh :)
[18:50] <kyrofa> mvo, I get "the given snap is not installed."
[18:50] <kyrofa> mvo, I tried .canonical as well
[18:50] <sergiusens> kyrofa, so are you creating the PR to disable that test?
[18:51] <kyrofa> sergiusens, do you agree that's the best way forward until we figure out a way to reproduce it?
[18:52] <sergiusens> kyrofa, yes
[18:52] <kyrofa> sergiusens, should I simply remove it from the examples test, or is there a way to just not run that one from debian/tests/control?
[18:56] <sergiusens> kyrofa, there is a way; don't know the syntax
[18:57] <kyrofa> elopio, do you have the magic?
[18:58] <sergiusens> kyrofa, there's a filter command, maybe a reverse-filter option would do
[18:59] <kyrofa> sergiusens, alright, researching!
[18:59] <sergiusens> kyrofa, I'll take over it if you want
[19:00] <kyrofa> sergiusens, nah, I don't know anything about this. That means I should
[19:00] <kyrofa> sergiusens, unless you're in a hurry :)
[19:00] <sergiusens> kyrofa, ok, look at example_tests/__main__.py
[19:01] <kyrofa> sergiusens, thanks for the pointers!
[19:02] <sergiusens> kyrofa, probably change debian/tests/exampletests and instead of ./runtests.sh just call python3 -m exmaple_tests --reverse-filter 'ros'
[19:02] <sergiusens> kyrofa, or come up with a regex that matches everything but ros and just pass --filter
[19:04] <sergiusens> kyrofa, something like '^(?!ros$).*$'
[19:08] <sergiusens> kyrofa, hmm, I think I did it already :-P
[19:08] <kyrofa> sergiusens, hahaha, alright, go ahead
[19:09] <sergiusens> kyrofa, just need to add --filter at the end of the command
[19:09] <kyrofa> sergiusens, oh, yeah I was just playing with that actually
[19:09] <sergiusens> kyrofa, python3 -m examples_tests --skip-install --filter '^(?!ros$).*$'
[19:10] <kyrofa> sergiusens, but examples_tests's main supports passing --filter
[19:10] <kyrofa> sergiusens, and run-tests.sh passes $@ through
[19:10] <sergiusens> kyrofa, yeah, it is a one line change
[19:10] <sergiusens> ./runtests.sh examples --skip-install --filter '^(?!ros$).*$'
[19:11] <kyrofa> sergiusens, yup, works fine
[19:13] <sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/321
[19:16] <ogra_> mvo, hmm, doesnt look like i got the right kernel snap :(
[19:17] <ogra_> mvo, are you sure thats http://people.canonical.com/~ogra/snappy/dragonboard/tmp/canonical-dragon-linux_4.2.0-2012-generic-dragon410c_arm64.snap ?
[19:18] <ogra_> anyway, need to run
[19:19] <beuno> ogra_, the latest upload from mvo broke the store  :)
[19:19] <beuno> the + sign in the version number is causing problems
[19:19] <beuno> unlikely we'll get that fixed today, I'd suggest re-uploading with a non-+ version  :)
[19:55] <mvo> ogra_: I re-uploaded with a "-1" instead of a "+1", fortunately that also counts as a higher version
[19:55] <mvo> ogra_: should be in the store now
[19:56] <mvo> kyrofa: hrm, hrm, thats a bug, I think I know what to do
[19:57] <kyrofa> mvo, haha, sorry!
[20:06] <sergiusens> elopio, kyrofa https://github.com/ubuntu-core/snapcraft/pull/322
[20:23] <ogra_> mvo, still not :(
[20:23] <ogra_> looks like it has the wrong initr
[20:23] <ogra_> d
[20:24] <ogra_> hmm, no ... seems to be the completely wrong one
[20:24] <ogra_> ubuntu@localhost:~$ ls /lib/firmware/wlan/
[20:24] <ogra_> prima
[20:25] <ogra_> (there should be a "macaddr0" link in there pointing to /run/macaddr0)
[20:32] <mvo> ogra_: hm, sorry, let me try harder
[20:33] <ogra_> 903ded84656483c34616143dbf492f29  canonical-dragon-linux_4.2.0-2012-generic-dragon410c_arm64.snap
[20:33] <ogra_> thats the md5
[20:34] <ogra_> and
[20:34] <ogra_> ogra@anubis:~/Devel/dragonboard$ md5sum xenial-chroot/snap/initrd.img-4.2.0-2012-generic-dragon410c
[20:34] <ogra_> 24508f65cbdf05aa13e8613836d4609d  xenial-chroot/snap/initrd.img-4.2.0-2012-generic-dragon410c
[20:36] <mvo> ogra_: a new version should be ready RSN
[20:37] <ogra_> take your time :)
[20:38] <mvo> ogra_: should be ready in edge now (for real this time)
[20:39] <ogra_> heh
[22:08] <kyrofa> sergiusens, elopio I'm off for the weekend. FYI monday is a holiday here
[22:10] <sergiusens> kyrofa, enjoy!
[22:15] <sergiusens> kyrofa, elopio adt passed \o/ http://autopkgtest.ubuntu.com/packages/s/snapcraft/xenial/amd64/
[22:19] <kyrofa> sergiusens, awesome! A little bittersweet considering WHY it's all green now, but still awesome :)
[22:32] <ogra_> beuno, are you able to push mvos last upload to stable from edge ? (the snap is good)
[22:37] <Tertain> When using docker with ubuntu snappy, is it meant that the docker containers are using traditional ubuntu, or other distro as the base image?
[23:16] <elopio> sergiusens: yay1!!
[23:19] <ogra_> Tertain, totally your choice