=== ev_ is now known as ev [00:28] elopio, kyrofa I think I want to disable the catkin plugin example test for now https://bugs.launchpad.net/snapcraft/+bug/1544790 [00:28] Launchpad bug 1544790 in Snapcraft "ros example fails in adt" [Undecided,New] [01:25] hello [01:26] \join [01:26] anyone here? === balloons16 is now known as balloons [07:06] good morning! [08:05] good morning === ljp is now known as lpotter [08:16] good morning [08:16] hey dholbach, fgimenez! [08:17] morning didrocks and dholbach :) [08:20] hey fgimenez, good morning! how is the recent 15.04 alpha image looking? any issues that might block a migration? [08:21] 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] mvo, are you feeling better? [08:23] salut didrocks - hola fgimenez! :) [08:28] fgimenez: yeah, thanks! better, still not great but I wanted to cleanup some things before the weekend [08:31] 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] mvo, great :) [08:38] mvo, I hope you can take some time off and get well again? [08:38] dholbach: thanks, I feel better, just want to ensure I tie up some loose ends [08:52] 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] asac: I suspect it's 2 weeks away from trunk to be able to do that with skills [09:33] hi asac [09:33] hi ysionneau [09:41] 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] hi, can I create a snap from .deb files? [09:55] mvo, ogra_: please ping me with updated instructions, I'll refresh ubuntu-image [09:55] once those bits are in the store [09:55] vir17: hey, maybe, please look at snapcraft examples on github [10:01] 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] vir17: why don't you just unpack those debs [10:02] vir17: there are plugins for just shoving a tar content into your snap [10:03] thanks zyga i will try that [10:03] 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] 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] mvo: \o/ great [10:13] mvo: can you tell me the names of each of the snaps? [10:13] --gadget canonical-dragon.canonical \ [10:13] --kernel canonical-dragon-linux.canonical \ [10:13] --os ubuntu-core.canonical [10:13] zyga: -^ [10:14] thanks! [10:17] 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] mvo: works, except for the gadget [10:20] mvo: I'll keep gadget as a copy from ogra's directory [10:21] 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] mvo: actually, the kernel doesn't resolve [10:21] mvo, uuh, stop [10:21] zyga: I will keep an eye on the store issue [10:21] ogra_: hm? [10:21] zyga: it does not? [10:22] mvo, the gadget needs bootdely=0 set in uboot.env.in first [10:22] *bootdelay [10:22] + 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] 789be3cf25f8a66b1f1658b8fa4f8c443fe --developer-mode -o dragon-devel.img [10:22] Determining gadget configuration [10:22] mvo, and the kernel snap needs a fixed resize script that can deal with GPT on u-boot (working on that today) [10:23] mvo: (downloads some parts then): [10:23] Installing canonical-dragon-linux.canonical [10:23] canonical-dragon-linux failed to install: snappy package not found [10:23] mvo: maybe it's not published yet, you can see which version of udf I was using here [10:23] ogra_: ok [10:24] zyga: ok [10:24] 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] ogra_: ok, I leave that to you [10:25] mvo: try your serial board again, use various usb cables, I had 1/4 work/not work ration [10:25] ratio* [10:27] zyga: I won't spend time on it today, other stuff is more important :) [10:30] sure [10:31] zyga: but thanks, good to know that there is a fail rate [10:46] ysionneau: ricmm is ricardo [10:47] ok :) [10:47] thanks again guys! [10:47] I'll try to think about all of this, right now it's a lot to process :) [10:48] new (minor) stable update for 15.04 ! [10:50] mvo, including the new rpi oem snap ? [10:50] * ogra_ guesses so ... i guess the old one is gone from the store :) [10:50] ogra_: so far it is only a system-image update, no new image yet [10:51] oh, that reminds me ... i havent updated snappy-hub yet [10:51] but the snap is in the store, so you will get it [11:10] ysionneau: right. can imagine, but in the end its pretty simplisitic :) [11:48] 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] Good morning [12:20] hey kyrofa! [12:20] Hey didrocks! [12:21] Haha, elopio yes, catkin is the worst build system on earth [12:34] anyone had installed snapcraft in raspian? [12:35] ppisati, so we have another prob on the dragonbaord .... the MAC doesnt persist ... [12:36] ogra_: ohh? [12:36] 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] ppisati, i wonder if you know any method to pull the MAC out of /proc/device-tree in that case [12:41] 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] anyone knows how to solve this? [12:42] kyrofa, didrocks morning [12:42] vir17, what do you expect snapcraft in raspbian to produce once you have it installed ? [12:43] hey sergiusens, how are you? [12:43] vir17, i highly doubt the binaries woill be executable on snappy [12:43] didrocks, fine, just thinking we might need an FFe ;-) [12:43] sergiusens: oh no, it's that fun time again! :-) [12:43] as we will barely land all the features next week [12:43] or we can just land everything broken [12:43] ;-) [12:44] sergiusens: don't remind me of those dark times in the distro :) [12:44] Hey sergiusens :) [12:44] ok ogra_ i will abandon this solution then [12:46] kyrofa, hey, can you take a look at https://bugs.launchpad.net/snapcraft/+bug/1544790 [12:46] Launchpad bug 1544790 in Snapcraft "ros example fails in adt" [Undecided,New] [12:47] kyrofa, I want to either fix or disable that test in adt :-) [12:47] kyrofa, there might be a proxy issue [12:47] sergiusens, yeah that's a difficult log to digest, haha [12:47] sergiusens, I want my line breaks back! [12:48] kyrofa, maybe blame subunit [12:48] or elopio ;-) [12:48] kyrofa, I did grab the relevant failure there [12:48] kyrofa, should be reproduceable locally too iirc [12:49] Ah, I like reproduceable ones [12:53] kyrofa, you can probably edit debian/tests/control and just run the catkin example [13:00] sergiusens, ah, so I can't just run the example test to see this? [13:01] kyrofa, only reproduceable in an adt env [13:02] kyrofa, hmmm, unless the python path fix made it fail, but this test has been failing since before that [13:02] sergiusens, I've not had to do that before, can you point me in the right direction? [13:02] ogra_, wrt generic initrd; any ETA? [13:03] sergiusens, after i'm done with the dragonbaord [13:03] (i hoped to finish that today, but still digging on that MAC address issue atm) [13:08] dholbach, btw, is the clinic an hour from now, two or three? [13:11] kyrofa, when time permits https://github.com/ubuntu-core/snapcraft/pull/320 [13:12] sergiusens, 3 I think [13:13] sergiusens, 1600 UTC, right? [13:14] kyrofa, what a relief :-) [13:14] sergiusens, hahaha [13:14] kyrofa, I hope you show up too, unless well, you know ;-) [13:14] sergiusens, I fully plan on it! Unless well, you know :P [13:15] sergiusens, 2.x features right? Got an idea of what we'll talk about? [13:15] sergiusens, will we try to stay on what is currently available, or will we discuss what it'll be come 16.04? [13:22] mvo, for setting the MAC on the dragonboard we need /lib/firmware/wlan/macaddr0 being writable :/ [13:23] yay android drivers :(( [13:23] kyrofa, differencenes between 1 and 2; then what is coming for 2 [13:23] sergiusens, sounds fun! [13:24] * zyga has updated unofficial ubuntu-image to handle dragon board from the store [13:25] ogra_: uh, we need /lib/firmware/wlan/macaddr0 to be writable?!? [13:25] mvo, well, we need that file to contain the MAC [13:25] if you have an idea how to do it without a writable file ... [13:26] ogra_: we could make it a symlink in the os snap and point to something in /run that the initrd creates/populates [13:26] ogra_: but all rather terrible [13:26] (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] *to look [13:40] ogra_: that information is not part of the device tree [13:40] ppisati, well ... it is ... [13:40] but only of the lk DT [13:40] ogra_: uhm [13:40] i just found a way to parse that from uboot ... similar to how we do it on the rpi [13:42] ogra_: how did you do that? [13:42] "fdt addr $value_i_fished_out_of_lk_output ; fdt get value args /chosen bootargs" [13:43] thsi works by hand ... still fiddling with scripting it now [13:43] ogra_: oh ok [13:43] mvo: thanks! I see my devices were updated and have the security updates :) [13:43] * jdstrand isn't really here [13:43] mvo: you feeling better? [13:44] => fdt addr 0x81e00000 [13:44] => fdt get value args /chosen bootargs [13:44] => printenv args [13:44] args= androidboot.emmc=true androidboot.serialno=7c16331a androidboot.baseband=apq mdss_mdp.panel=0:dsi:0: [13:44] ppisati, ^^^ [13:44] ogra_: but there's no mac address there [13:44] ppisati, the serial is the MAC [13:45] 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] kyrofa, it obnly works on 4GB cards ... like the big fat notice in the README says [13:45] and yes, resizing still wipes the partition table [13:46] ogra_, I know, but you mentioned if I resized manually before trying to boot it shouldn't try the resize [13:46] ogra_, but it was a little weird on trusty [13:46] ogra_, so I wouldn't be surprised if it didn't work out [13:46] hmm, perhaps your manual resize somehow messed it up ? [13:47] you need to be super sure the IDs, size and content of the first partitions doesnt change ... ever [13:48] 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] ogra_, or is there a bug I can keep my eye on? [13:48] 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] 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] 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] ogra_, oh you're good man, I didn't mean to rush you :) [13:50] ogra_, glad to hear it's on the horizon, though [13:50] mvo: I don't know if that is a definite part of the problem-- it is just something I noticed [13:50] well, i need to work on generic initrd next week ... so i ant the dragonboard done today [13:51] ok, really gone now [13:51] ogra_, understood. By the way, is that porting guide still applicable? Or does it need to be rewritten completely for all-snaps? [13:51] the latter [13:52] i'll work on that once we are through all these conference thingies :) [13:52] 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] ubuntu@localhost:~$ cat /proc/cmdline [14:01] 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] ogra_: nice! [14:07] jdstrand: cool, thanks and enjoy your holiday [14:08] 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] ok [14:09] i get cold shivers seeing that code though :P [14:11] (especially the "first writing the file wrongly and then fixing it with sed" part ...) [14:16] sergiusens, 16 UTC, so in 1h44m from now [14:16] http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/30 [14:16] changes pushed [14:36] https://github.com/zyga/devtools updated with i386 snappy, i386 virtualization and latest dragonboard support [14:54] dholbach, thanks [15:19] mvo, would you do me a favour and push that update for the dragon to the store ? [15:19] (with fresh uboot.env generated from rev 30 on snappy-hub) [15:19] (if you dont have time i'll do it tonight) [15:30] fgimenez: we are still in the snapcraft planning session. [15:30] you can join us if you want :) [15:31] 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] sudo kvm -m 512 -redir :8090::80 -redir :8022::22 ubuntu-15.04-snappy-amd64-generic.img [15:31] WARNING: Image format was not specified for 'ubuntu-15.04-snappy-amd64-generic.img' and probing guessed raw. [15:31] Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. [15:31] Specify the 'raw' format explicitly to remove the restrictions. [15:31] Could not initialize SDL(No available video device) - exiting [15:31] elopio, i'm not feeling well today, still a bit sick, maybe next time :) [15:32] ogra_: sure, I assume I can just bzr up; snappy build? [15:32] i guess so ... hwo did you produce the last one ? [15:32] :) [15:32] ogra_: exactly this way [15:32] yeah, then it shoudl eb fine ... uboot.env needs updating first ... [15:33] ogra_: I ran mkenvimage [15:33] well, let me do that and commit it so the bionary is in sync with the source [15:33] ah, k [15:35] 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] has anyone here done such a thing [15:35] wiggleworm, i think there are examples for snapcraft to get the java bits bundled properly inside your snap [15:36] ogra_: bootdelay is zero and the bootargs is for the mac address? [15:36] mvo, yeah [15:36] the bootdelay thing is a bit unfortunate but no better workaround for now [15:36] ogra_: ha! thats magic [15:37] wiggleworm, yeah, run 'snapcraft help ant' or `snapcraft help maven' [15:37] wiggleworm, also look at the examples for maven and a hello world [15:37] ok - thanks I will take a look [15:37] 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] mvo, ok [15:40] mvo, hmm is --gadget canonical-dragon/edge the right syntax ? [15:40] seems u-d-f doesntz find it (with or without /edge) [15:41] ogra_: http://paste.ubuntu.com/15023254/ works for me [15:41] ah .canonical [15:41] ogra_: this should give us fully updaable ones, well - except for the partition resize issue :) [15:42] 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] 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] mvo, hmm u-d-f dies for me with "can not find OS part" [15:45] using --os ubuntu-core.canonical like in your paste [15:45] bah, silly me ... forgot --channel :P [15:52] ogra_: :) [15:52] ogra_: if all is looking well I'm happy to promote to stable [15:53] mvo, i'll let you know ... [15:53] * ogra_ waits for xz and dd [16:02] for everyone waiting for the Snappy Clinic - we're just about to start [16:02] http://ubuntuonair.com [16:05] if you have questions for the clinic, just make sure you prefix them with QUESTION: [16:07] ubuntu@localhost:~$ cat /proc/cmdline [16:07] 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] mvo, ^^^ looks good ... and boots with serial board detached too [16:07] mvo, promote it :) [16:09] ogra_: all snaps available on stable now, once the resize bug is fixed we should push a new image [16:10] 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] i can luckily do it all inside the -linux snap [16:17] mvo, can we get a new OS today or is that too much to ask? [16:18] asac: do you know any target supported by snappy, with a somehow working qemu port? [16:19] ysionneau, amd64 [16:20] sorry, I forgot to mention : arm target [16:20] heh [16:20] i dont think there is any [16:20] I found a qemu-raspi2 on github, didn't manage to get it to work yet though [16:20] QUESTION: how long does it take for an app to be reviewed? [16:20] 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] https://github.com/0xabu/qemu [16:21] noise][, auto-revie is usually happening in munites [16:21] ogra_: +1 [16:21] bah [16:21] sergiusens: any particular arch that is important to you? [16:21] noizer, ^^^ [16:21] mvo, snap launcher [16:21] mvo, it creates dirs, also systemd SNAP_USER_DATA set correctly [16:21] ogra :p [16:21] mvo, x86 and armhf [16:21] noizer, manual review can takes weeks or months and is also likely to be rejected [16:21] first more important than the second [16:22] ogra_ ok [16:22] awesome [16:25] QUESTION: will it be possible to share libraries over multiple snaps with skills? (SO files) [16:27] nice questions - keep them coming :) [16:34] 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] sergiusens: arm is ready in some minutes as well [16:38] pitti: is this a correct incantation? https://paste.ubuntu.com/15025272/ [16:38] It just gets stuck after creating the instance. [16:42] snapcraft 2 is realy awesome :D [16:43] it is !! [16:44] yea xD just one problem I had was when I'm installing my snap to much I cant delete it [16:44] any more questions? :) [16:45] When will be the stable release for 16.04. [16:45] ? [16:46] noizer, april 2016 [16:46] kyrofa nicee :D [16:46] (those release numbers are dates) [16:47] kyrofa ooh didn't know that [16:51] If I ever finish debian merges I still plan on tackling kde :) [16:52] thanks everyone! [16:52] ty [16:52] thanks to you dholbach. [16:53] Thanks dholbach :) [16:56] sergiusens, kyrofa, elopio: thank YOU :) [17:01] QUESTION: When will we be able to run graphical snaps on the desktop? [17:05] probably not before the desktop defaults to Mir [17:12] "§%e%/&§$=%§/%/& !!!! [17:12] GRRRR [17:14] ^^^ this is me when accidentially hititng the "cursor up" and enter keys in a terminal where dd just finished .... [17:14] :((( [17:14] ogra_: lol [17:14] ogra_: dd should remember the last request and ask "are you sure? [n/y]" [17:14] yeah [17:15] speaking of which, let's try parted [17:15] 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] so another useless dd-time-waste [17:16] ogra_: oh, SIGINT clobbers the card? [17:16] ogra_: as in writing partially shit? [17:17] 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] well, is the rest different compared to earlier write? [17:18] it seems that it's just an overwrite [17:18] with same blob [17:18] so it should be safe to kill [17:19] * ogra_ boots and sits in awe [17:19] thibaut, were you watching the hangout in non live mode? [17:20] ubuntu@localhost:~$ ifconfig wlan0|grep HW [17:20] wlan0 Link encap:Ethernet HWaddr 02:00:7c:16:33:1a [17:20] ubuntu@localhost:~$ cat /run/macaddr0 [17:20] 02:00:7c:16:33:1a [17:20] YAY !!!!!! [17:22] ogra_: new gadget or kernel? [17:22] 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] sergiusens: how did you generate your changes file? [17:23] hmm, I have terrible serial data connection [17:23] tons of bytes lost [17:23] all right my friends - have a great weekend! [17:23] ogra_: gimme, I'll gladly try it [17:23] dholbach: likewise, enjoy [17:23] zyga, currently uploading for mvo to push it to the store [17:24] ogra_: so will that actually auto-update/ [17:24] 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] zyga, i guess [17:24] woot [17:25] ogra_: how do you rebuild from the store? [17:25] ogra_: anything I could tweak in ubuntu-image for that? [17:25] have a good week-end everyone! [17:25] for what exactly ? [17:27] ogra_: for being able to get fresher (test) snaps [17:27] zyga, well, i guess from now on we'll just push to the store regulary [17:28] so as long as you use the edge channel you will get the latest crack [17:29] elopio, gbp buildpackage -S [17:30] ogra_: perfect [17:33] ogra_: does 'sudo snappy update' works for you? [17:34] ogra_: for me it doesn't (store issue?) [17:34] i'd have to set up networking [17:34] ahh [17:34] I didn't either - sorry :) [17:35] yeah, then snappy spills that wonderful informative error message [17:36] zyga, but what would you want to update ? there is no new rootfs or anything [17:36] ogra_: the new kernel, later [17:37] not sure the old one was uploaded yet [17:37] ogra_: btw, the kernel version is weird, is the generic-dragon410c needed? [17:37] ogra_: it had to be, I built the image I'm running from the store earlier [17:37] (that might cause us issues since we dont have a minor version we can easily bump) [17:37] (well 30 minutes ago) [17:38] not sure how/if mvo can solve that [17:38] mvo can do anything :) [17:39] if the store lets him :P [17:39] beuno can break all of us nowadays, he has the powah :) [17:41] still I cannot be happier, all my 6 boards are working [17:41] 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: "!\ndebian-binar" [17:41] ssweeny: the snap is using the old format (not valid for 16.04) [17:41] aha [17:42] ssweeny: it's the clickdeb format apparently [17:42] ssweeny, yeah, stgraber needs to update the snap to the new all-snaps setup (using squashfs and all via snapcraft 2.x) [17:42] that makes sense [17:42] this is from before 16.04 moved I take it [17:42] yeah [17:43] since other 15.04 snaps don't show up at all for me [17:43] most of the snaps are currently non-installable from the store ... only few have been updated yet [17:44] ok, good to know [17:44] i suppose i can use classic mode for development until containers are working again [17:45] yeah ... effectively you should now always use classic mode [17:45] (it is just a container after all :) but with a lot less overhead) [17:45] right :) [17:46] * ogra_ needs to get dinner ... mvo let me know if there is something i can test :) [17:47] ogra_: FYI classic on dragon doesn't work [17:48] ogra_: missing parts somewhere: [17:48] ubuntu@localhost:/etc/network/interfaces.d$ sudo snappy enable-classic [17:48] needle "ubuntu;xenial;arm64;default;" not found [17:49] zyga, I bet there isn't an arm64 image available on the image server [17:49] zyga, ogra_ yeah, that's it http://images.linuxcontainers.org/images/ubuntu/xenial/ [17:50] zyga, yes, known, stgraber is on it [17:50] hah, was just about to ping him ;-) [17:50] thanks! [17:51] zyga, sergiusens bug 1543764 [17:51] bug 1543764 in Snappy "snappy classic must use officially supported lxd images from simplestream; not unsupported ones from linux-containers.org" [High,New] https://launchpad.net/bugs/1543764 [17:53] ysionneau: we only use qemu for x86... otherwise boards [17:54] ysionneau: shouldnt be that hard to make it work on versatile though etc. [17:54] I am now able to boot the raspberry pi 2 img (with my own kernel) on some custom qemu [17:54] but it fails to login with ubuntu:ubuntu l/p [17:55] hmmmm [17:55] 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] ah, cloud-init is failing :) [17:56] maybe because I get no network [17:56] and writable is most likely not properly mounted either [17:56] that shouldnt be a problem for credentials [17:56] asac, thats just fallout [17:56] ysionneau: ogra is your man i guess :) ... he is the master of ARM bringups :P [17:57]