[06:45] <dholbach> good morning
[07:06] <fgimenez> good morning
[09:08] <JamesTait> Good morning all; happy Monday, and happy Walk on Stilts Day! 😃
[09:11]  * Chipaca winces
[09:12] <JamesTait> Chipaca, what could possibly go wrong?
[09:12] <Chipaca> JamesTait: with *my* balance and co-ordination? *EVERYTHING*
[09:13] <Chipaca> oh, maybe i forgot to mention my endemic bad luck also :)
[09:13] <JamesTait> Chipaca, I never got the hang of it myself. But then I probably should have tried for more than a couple of minutes.
[10:29] <ogra_> phew .. so much fallout
[10:39] <ricmm> ogra_: of?
[10:40] <ogra_> ricmm, https://plus.google.com/+OliverGrawert/posts/iF5CqLtFEAR?cfem=1
[10:41] <ogra_> ricmm, which turned into http://news.softpedia.com/news/kde-s-plasma-mobile-not-giving-credit-to-ubuntu-touch-says-developer-487806.shtml
[10:42] <ogra_> (which got me a bit of mail and comments ... )
[10:51] <ricmm> :)
[10:51] <ricmm> not sure about continuing to reply in that g+ post
[10:52] <ricmm> it will clearly go to flameland
[10:52] <ogra_> yeah, it atarted to get quieter now, i surely wont stir it up again :)
[10:52] <svij> ogra_: I like this part: "how about we talk about it over a beer at #ubucon ? ;)﻿" ;-)
[10:52] <ogra_> ;)
[10:52] <ogra_> sadly he didnt answer it
[10:53]  * ogra_ wanted to trigger commitment that some KDE people would show up :)
[10:54] <svij> martin gräßlin showed up 2012 + 2013
[10:54] <svij> (at ubucon de)
[10:55] <ogra_> well, after his mir battling i doubt he will this time
[10:55] <svij> yeah :(
[10:56] <Chipaca> ogra_: the part that yanks my chain on that is their explicitly announcing it as "free of corporate [somethingorother]"
[10:56] <Chipaca> which i read as canonical (amongst others, sure)
[10:56] <ogra_> hah, i didnt even notice that yet :)
[10:58] <svij> Blue Systems is based in Bielefeld and all Germans know, that Bielefeld doesn't exist. So it's kinda true. :P
[10:58] <ogra_> hahaha
[11:20] <ogra_> oh !
[11:20] <ogra_> sebas commented ...
[11:45]  * Chipaca ~> luncheon
[11:46] <Chipaca> that's like a lunch that lasts an eon \o/
[12:32] <elopio> good morning.
[13:05] <rsalveti> ricmm: ogra_: would be fun to compare performance between wayland and mir though
[13:05] <rsalveti> since it's using ubuntu-touch anyway
[13:34] <lool> rsalveti: oh the plasma thing is on wayland? interesting
[13:35] <lool> I thought they were on mir for that demo
[13:35] <rsalveti> lool: http://vizzzion.org/blog/2015/07/embracing-mobile/
[13:36] <rsalveti> I would need to check the src code for it, but I'd assume they are using wayland
[13:36] <rsalveti> libhybris enables both wayland and mir
[13:36] <rsalveti> which is why it would be nice to compare both :-)
[13:36] <lool> rsalveti: right, I saw the video but in the context of a quite limited french translation of the original
[13:36] <rsalveti> it might generate some great flames :-)
[13:37] <lool> haha
[13:37] <ogra_> they are using wayland
[13:37] <lool> yeah, the blog post keeps rehashing that point
[13:38] <ogra_> after being bashed for two days after my post i can tell you for sure it is wayland ;)
[13:38] <lool> ogra_: I give you credit for a good flame
[13:38] <ogra_> lol
[13:39] <ogra_> rsalveti, isnt wayland still limited to only a few android drivers though ?
[13:39] <rsalveti> ogra_: same drivers as we are
[13:39] <rsalveti> in the end it's all libhybris
[13:39] <ogra_> ah, i thought thesir situation was worse ... http://www.jlekstrand.net/jason/projects/wayland/wayland-android/
[13:41] <rsalveti> our situation is not so much better
[13:42] <rsalveti> which is why we always end up requiring changes at the driver side
[13:42] <ogra_> ah
[13:52] <ogra_> mterry, hmm, so snapcraft wont support multiarch snaps ?
[13:52] <ogra_> thats quite a drawback
[13:52] <mterry> ogra_, well it doesn't right now anyway
[13:53] <rsalveti> ogra_: we don't plan to block that work, but don't want to solve that now
[13:53] <mterry> ogra_, the plan seems to be to build multiarch/crossbuilding support on top of snapcraft via comfy and such
[13:53] <ogra_> ok
[13:53] <rsalveti> ideally the store would allow multiple uploads for multiple archs
[13:53] <ogra_> well, as long as i dont have to have a foo-armhf and a foo-x86 snapy that i need to inependently maintain
[13:53] <rsalveti> but, until that is done, we'd need some sort of helper to mix both snaps and create a fat package
[13:53] <ogra_> *snap
[13:54] <ogra_> right
[13:54] <beuno> ...and we'll support separate binaries for separate arches in the store in the mid-term
[13:54] <ogra_> i thought that was what snapcratf was upposed to do ...
[13:54] <ogra_> beuno, yes, but i dont want them :)
[13:54] <rsalveti> snapcraft is about helping you creating one snap
[13:54] <ogra_> as a maintainer i dont want to have to care for different trees and packages :)
[13:55] <beuno> ogra_, the store will support both
[13:55] <rsalveti> right, we'll get there
[13:55] <ogra_> but as long as we can have somethin on top that can merge both ... or if it is easy to script something around that. i'm fine
[14:07] <rsalveti> ogra_: all good with 132 then, right?
[14:08]  * rsalveti resuming the release process
[14:08] <rsalveti> let me push that to alpha
[14:08] <ogra_> rsalveti, if QA doesnt have anything .-.. and if we are happy with the missing rollback, yes
[14:08] <rsalveti> and give it another round of tests
[14:08] <rsalveti> unfortunately, not much we can do in there
[14:08] <ogra_> yeah
[14:09] <rsalveti> alpha here we go
[14:09] <rsalveti> elopio: ogra_: fgimenez: upadte from 8->9->8 should work now
[14:09] <rsalveti> at least that's the hope :-)
[14:09] <ogra_> it did between 131 and 132 at least
[14:10]  * ogra_ rolls an alpha image
[14:11] <fgimenez> rsalveti, ok, on it
[14:18] <ogra_> grrr
[14:18] <ogra_> forgot to use --revision
[14:18]  * ogra_ starts over
[14:47] <fgimenez> rsalveti, 8 -> 9 -> 8 goes fine here, i'm executing now the automated suite against 9
[14:47] <rsalveti> cool
[14:52] <vmayoral> ogra_: is there any way to install OEM snap without using the ubuntu-device-flash tool (dev purposes)?
[14:52] <ogra_> i dont think there is
[14:53] <beuno> vmayoral, you mean, to update a client, for example?
[14:54] <beuno> or a genuine fresh install of the OEM snap to a running client who hasn't installed it before?
[14:55] <vmayoral> ogra_, beuno: let me rephrase it: I'm making changes in our OEM snap and everytime i want to install it (to test it), do i need to create a new image?
[14:55] <ogra_> rsalveti, i'm still getting the "cant find vmlinuz" ... beyond that the upgrade looks good
[14:55]  * ogra_ reboots and rolls back
[14:55] <rsalveti> ogra_: yeah, that's expected because of the system-image issue
[14:55] <ogra_> right
[14:55] <rsalveti> no kernel differences
[14:55] <ogra_> we need to mention it in the release notes
[14:56] <beuno> vmayoral, I think if it was part of the original installed image, you should be able to push to the device and just upgrade
[14:56] <rsalveti> it should work just fine when migrating to stable
[14:56] <rsalveti> because it's a different kernel
[14:56] <ogra_> because it swallows the "reboot required" message
[14:56] <rsalveti> ogra_: is there a way to remove an image from the channel easily?
[14:56] <vmayoral> beuno: that makes sense, but that'll imply having the OEM snap already accepted in the store
[14:57] <rsalveti> would be nice to simulate the stable again, since we got so many more images in alpha
[14:57] <ogra_> rsalveti, hmm, i've never done that ...
[14:57] <rsalveti> maybe creating a temporary channel or some sort of it
[14:57] <rsalveti> need to think
[14:58] <vmayoral> beuno: isn't there a quick way of changing the OEM snap for dev purposes?
[14:58] <beuno> vmayoral, oh, you should be able to sideload the oem snap
[14:59] <ogra_> are you sure ?
[14:59]  * ogra_ isnt so sure that works
[14:59] <vmayoral> beuno: could you explain what you mean by "sideloading" the oem snap?. I've seen the ".sideload" in a few test snaps i've made in the last days but didn't quite get it
[15:00] <beuno> vmayoral, sideloading is installing outside of the store, for development purposes
[15:00] <beuno> it's lterally pushing the snap and installing it locally
[15:00] <beuno> to allow for fast development cycles
[15:00] <beuno> you will have to pass in a flag, --allow-untrusted or something similar
[15:00] <ogra_> scp it it and "snappy install /path/to/snap" ...
[15:00] <beuno> so it skips checking the signature
[15:00] <ogra_> or you use snappy-remote from a remote machine
[15:03] <vmayoral> beuno, ogra_: thanks for explaining, tried that with the "--allow-unauthenticated" flag
[15:04] <vmayoral> and that doesn't help with the oem snap
[15:04] <vmayoral> it seems to be restricted somehow
[15:04] <ogra_> yeah, i expected that
[15:06] <beuno> hm
[15:06] <beuno> so we need to fix that
[15:06] <beuno> cc rsalveti ^^
[15:06] <beuno> iterating on the OEM snap
[15:07] <sergiusens> ogra beuno: vmayoral oem snaps can't be sideloaded
[15:07] <Chipaca> vmayoral: beuno: i don't think you can sideload the oem snap yet
[15:07] <Chipaca> vmayoral: beuno: you can tell u-d-f to use a local one though afaik
[15:07] <sergiusens> u-d-f --oem [oem.snap] --developer-mode
[15:17] <Chipaca> sergiusens: golang and python's standard libraries both check http_proxy and HTTP_PROXY :)
[15:22] <vmayoral> sergiusens, Chipaca: searched for "u-d-f" but didn't find anything, mind pointing out where can i find that tool?
[15:22] <Chipaca> vmayoral: ubuntu-device-flash
[15:22] <vmayoral> silly me, thanks!
[15:23] <beuno> Chipaca, sergiusens, sounds like we at least want to document this piece
[15:23] <beuno> how to iterate on OEM snaps
[15:29] <elopio> fgimenez: I can take your fix-expected-yaml-parse-error branch and extend it to make all the tests pass in 15.04.
[15:29] <elopio> I think that would be a good use of my time today.
[15:29] <fgimenez> elopio, ok, that would be great :)
[15:30] <fgimenez> elopio, about the refactoring card, we could begin by extracting the build and adtrun code to helpers, what do you think?
[15:31] <elopio> fgimenez: yes, that would be good too. Want me to start?
[15:32] <fgimenez> elopio, as you like, if you don't finish it i can continue tomorrow
[15:32] <elopio> fgimenez: if we want to test those, we can use the link Chipaca sent. http://npf.io/2015/06/testing-exec-command/
[15:33] <elopio> I'm not yet sure how much I want to test them, but adding a couple of tests never hurts.
[15:34] <fgimenez> elopio, ok looks very good
[15:34] <Chipaca> ogra_: sergiusens: but s-i uses https to get the image, which makes proxying it a little bit harder :-(
[15:35] <ogra_> Chipaca, it is really not *that* important (as long as core stays small)
[15:37]  * Chipaca considers making a wwwwoffle snap
[15:43] <fgimenez> elopio, about executing the suite from tarmac, maybe we can reuse part of the snappy-tests-job, or autopkgtest's nova script
[15:43] <vmayoral> sergiusens, Chipaca: tried using "--oem" in u-d-f, that option is not available anymore
[15:44] <vmayoral> just updated snappy-tools to make sure i've got the latest
[15:44] <vmayoral> same result
[15:44] <elopio> fgimenez: you tell me. We can change the .tarmac.sh to be anything, like a call to snappy-test-job's main, or  two calls, one to provision and one to _integration-tests/main
[15:45] <fgimenez> elopio, we can try both approaches, the nova script makes a lot of sense, but we should fork and modify it
[15:47] <rsalveti> vmayoral: which version of u-d-f are you using?
[15:47] <sergiusens> vmayoral: ubuntu-device-flash core rolling --oem [.snap]
[15:47] <rsalveti> right, --oem needs to be after core
[15:48] <rsalveti> ubuntu-device-flash core --help
[15:49] <vmayoral> rsalveti: https://gist.github.com/vmayoral/90da57bebc20ada52f56
[15:50]  * vmayoral is removing u-d-f and reinstalling it
[15:50] <rsalveti> looks like an old version
[15:50] <rsalveti> try the one from https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed
[15:50] <rsalveti> we're migrating it to https://launchpad.net/~snappy-dev/+archive/ubuntu/tools later today
[15:51] <rsalveti>  goget-ubuntu-touch 	0.27-0ubuntu1
[15:54] <vmayoral> ok, let me write that down, will try it again later and give feedback, thanks
[16:06] <kyrofa> seb128, have you had any time to check out https://code.launchpad.net/~kyrofa/ubuntu-seeds/ubuntu-touch.wily_add_unity-scope-snappy/+merge/265568 ?
[16:06] <seb128> kyrofa, no
[16:06] <seb128> sorry, busy on other things atm
[16:06] <seb128> but maybe ogra_ or mvo can help you
[16:07] <kyrofa> seb128, alright, thanks!
[16:08] <kyrofa> ogra_, ^^ trying to get the snappy scope into the Ubuntu Personal seed, if you have any time to check it out
[16:09] <seb128> kyrofa, sorry about that, I need to spend some cycles on wily work but I plan to go back to snappy personal in a few days
[16:09] <ogra_> seb128, hmm, does that use a metapackage ? do you knwo ?
[16:09]  * ogra_ can indeed just merge the seed
[16:10] <kyrofa> seb128, that's quite alright, I understand!
[16:10] <ogra_> i'm just not sure the meta is actually used for the snappy image
[16:13] <seb128> ogra_, yes, the seed are used to build the iso
[16:14] <ogra_> yes, i know how tezh iso works ... for snappy core we dont have a metapackage though, it uses germinate directly
[16:15] <seb128> unsure what desktop does, it's based on what core does I think
[16:15] <seb128> in any case the seed need to be updated no?
[16:16] <ogra_> yeah
[16:16] <kyrofa> ogra_, seb128 do I need to make a MP elsewhere as well?
[16:17] <ogra_> kyrofa, hmm, i cant merge it ... i think the desktop-next part actually comes from the touch seed
[16:18] <kyrofa> ogra_, not the desktop seed?
[16:18] <ogra_> lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/
[16:19] <ogra_> and in there the desktop file
[16:19] <seb128> correct
[16:20] <kyrofa> ogra_, I'm confused... isn't that what this MP is against?
[16:20] <ogra_> oh
[16:20] <ogra_> silly me
[16:21] <ogra_> kyrofa, merged and pushed (might need a meta package rebuild though, but the seed should be fine now)
[16:23] <kyrofa> ogra_, thank you! I'm unfamiliar with the meta package to which you're referring
[16:23]  * ogra_ too ;)
[16:23] <kyrofa> Oh :P
[16:23] <ogra_> if there is one, i guess Laney knows about it
[16:24] <kyrofa> ogra_, walk me through that real quick-- I generate an Ubuntu Personal image using u-d-f personal rolling --channel edge . Magic happens, and I have an image
[16:25] <Laney> for what?
[16:25] <Laney> desktop-next -> ubuntu-touch-meta
[16:25] <ogra_> Laney, desktop-next ... does the snappy build use a meta package ? (core doesnt, thats why i ask)
[16:25] <ogra_> ah, ok, even on snappy then
[16:26] <Laney> it uses the tasks
[16:26] <Laney> but the metapackage exists
[16:26] <Laney> (IIRC)
[16:26] <ogra_> bah
[16:26] <ogra_> ogra@anubis:~/Devel/packages/ubuntu-touch-meta-1.234$
[16:27] <Laney> »···»···add_task install minimal standard ubuntu-desktop-next ubuntu-sdk-libs
[16:27] <ogra_> i really really dont want to update that ... look at the version !
[16:27] <Laney> ya
[16:27]  * ogra_ tries to overcome the resistance to break that beautiful schema
[16:27] <kyrofa> Hahaha
[16:29] <kyrofa> A month down the road ogra_ gets hit with "Why is ubuntu-touch-meta on 1.2.34-0ubuntu145?
[16:29] <kyrofa> "
[16:29] <ogra_> heh
[16:31] <kyrofa> ogra_, are you taking care of that, then? Or do I need to do something?
[16:31] <ogra_> yes, the metapackage is already updating here, that takes a bit
[16:32] <ogra_> i'll upload it then
[16:32] <ogra_> nothing to do for you
[16:32] <seb128> ogra_, thanks
[16:32] <seb128> the next time I look at the personal image maybe the snappy scope works out of the box ;-)
[16:33] <seb128> but I need to deal with some desktop backlog and look at that gcc5 transition this week, before going back to snappy
[16:33] <kyrofa> seb128, hey, take care of that desktop stuff, it's important to all of us :P
[16:35] <seb128> :-)
[16:36] <kyrofa> ogra_, thank you for your time and help :)
[16:37] <ogra_> np
[16:42] <ogra_> and uploaded ... next image build should have your scope
[16:49] <kyrofa> ogra_, fantastic!
[17:44] <zeromon_> Why does Ubuntu use snappy instead of using apt-get?
[17:44] <elopio> \o/ all tests passing in 15.04 edge.
[17:44] <beuno> zeromon_, why does Ubuntu Snappy use snappy instead of apt-get?
[17:44] <zeromon_> beuno: ye.. sorry that is what I want to ask exactly..
[17:45] <beuno> zeromon_, I don't understand the underlying question. This flavor of Ubuntu is based around the fact that it doesn't use debian packages
[17:46] <beuno> is your question why this flavor exists?
[17:46] <beuno> I mean, Ubuntu with apt-get is just classic Ubuntu
[17:46] <beuno> which still exists, obviously
[17:46] <ogra_> and wont go away any time soon
[17:46] <zeromon_> beuno: I mean... Are there some significant benefits??? Or Ubunt wants to have their own packaging system... What is the point?
[17:47] <ogra_> yes, there are plenty of benefits ...
[17:47] <beuno> zeromon_, so, I can't tell if you're just here to troll, but lets give it a go
[17:47] <ogra_> (rollback abilities, diff upgrades, no dependencies, to just name a few)
[17:48] <beuno> let me find you some information about why this flavor doesn't use debs
[17:48] <beuno> https://developer.ubuntu.com/en/snappy/
[17:48] <beuno> there's some high-level information
[17:48] <ogra_> well, technicallly we use debs ... to build the images :)
[17:48] <zeromon_> beuno: I am not to troll here. I am very curious what the difference is..
[17:48] <ogra_> and you will also be able to create a snap out of a bunch of deb packages
[17:48] <zeromon_> ogra_: thanks for kind explanation
[17:50] <ogra_> so if you have a project ... say "mailserver" ... you can create a snap that contains postfix, dovecot and all the bits and pieces to have a fully functional mailserver setup in a single snap (and the snap will be able to give you access to settings via the snappy config commabnd)
[17:50] <beuno> zeromon_, and on a lower level than that link, here's some information on security benefits: https://penguindroppings.wordpress.com/2015/01/30/snappy-app-trust-model/
[17:50] <beuno> well, and many other benefits
[17:52] <zeromon_> thanks fot information. I am trying to understand it.
[17:59] <zeromon_> Can I install Ubuntu snappy core on the normal PC?
[18:02] <elopio> Chipaca: sergiusens: could you please check if we have too many packages in there? http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/files/head:/_integration-tests/helpers/
[18:02] <elopio> I'm have the feeling that things are conceptually and functionally different, but it feels weird to have one package per go file.
[18:03] <sergiusens> elopio: too many packages? doesn't seem so; if anything I just don't like calling things 'helpers' :-P
[18:03] <elopio> zeromon_: you can install it now in a kvm: https://developer.ubuntu.com/en/snappy/start/#snappy-local
[18:03] <elopio> at some point in the future you will be able to install the ubuntu personal flavor.
[18:03] <elopio> sergiusens: I didn't want to have that folder, but otherwise I can't distinguish between integration tests, and the other tests.
[18:04] <zeromon_> elopio: thanks a lot
[18:04] <elopio> sergiusens: if you can think of a better name, or a way to exclude a package from the test run, please let us know.
[18:07] <sergiusens> elopio: testutils?
[18:07] <sergiusens> elopio: I don't mind the folder, I just don't like the generic name ;)
[18:08] <elopio> testutils and _integration-tests/helpers sound like the same for me, but if you are happy with that, I'm happy.
[18:08] <elopio> sergiusens: is it ok put some files in testutils/ and some files in testutils/config, for example?
[18:16] <sergiusens> elopio: yes
[18:17] <sergiusens> elopio: look at path and path/filepath
[18:17] <sergiusens> elopio: http://golang.org/src/path/
[18:17] <elopio> right.
[18:18] <elopio> so the current helpers/utils/utils.go should probably live in testutils/utils.go
[18:18] <elopio> probably some things from helpers/common/common.go should be there too.
[18:19] <elopio> and instead of common, we should name it base, or something like that.
[18:21] <sergiusens> elopio: ah, I thought you were only talking about layout, I have no idea what is expected of each package, we can look at that too
[18:22] <elopio> sergiusens: yes, federico wants to split things because main and common are too big. So I will be sending some branches.
[18:22] <elopio> please leave your suggestions on the MPs.
[20:20] <ted> Is there a reason we don't have snappy generic images for arm and other arches?
[20:22] <beuno> ted, from what I know, there is no such thing as generic arm, due to booting
[20:22] <beuno> and the x86, AFAIK, is generic
[20:22] <ted> beuno, Then what does qemu-arm take?
[20:22] <beuno> ted, some form of specific arm?  :)
[20:23] <beuno> my understanding is that ARM doesn't have a standard for booting, so you need a different kernel for each, many times with trivial differences
[20:32] <rsalveti> it's as generic as the kernel is
[20:33] <rsalveti> as long the kernel supports qemu-arm (which is probably the case), we only need the generic oem for it
[20:33] <rsalveti> similar to what we have for amd64
[20:33] <rsalveti> beuno: we do have a standard in there, the generic armhf kernel we have is indeed generic
[20:33] <rsalveti> the hardware specific part is described by the device tree
[20:34] <rsalveti> the problem is that not necessarily every hardware is supported by the upstream kernel
[20:34] <ted> Sure, but I only need QEMU's CPU and networkng.
[20:35] <rsalveti> right, I believe it might be easy to support that, but would required a generic oem
[20:35] <rsalveti> in the past we had omap3 targets in qemu, not sure how well supported is that atm
[20:35] <ted> Would be handy if I could build these docker images on Snappy, just so it's all the same version of docker, etc.
[20:36] <rsalveti> ted: well, you could simply have a docker image with ubuntu and build the docker image inside that docker image :-)
[20:36] <kickinz1> ted, you can
[20:36] <rsalveti> docker inception
[20:36] <ted> Heh, yeah.
[20:38] <rsalveti> utlemming: we're just finishing the testing phase for our current alpha image (image 9), and that will be migrated to stable
[20:38] <rsalveti> or latest edge (132)
[20:39] <rsalveti> utlemming: can you run your usual testing scenarios over it and see if there is any issue with the cloud targets?
[20:43] <rsalveti> beuno: sergiusens: why is the mir framework showing up on webdm even on armhf?
[20:43] <rsalveti> afaik it's only amd64
[20:50] <ted> rsalveti, I can't seem to find a prebuild .img file for ARM on cdimage, do you know of one I'm missing?
[20:50] <rsalveti> ted: we only have for beaglebone
[20:51] <ted> rsalveti, For snappy, is there one for deb-based Ubuntu?
[20:51] <rsalveti> maybe just the tarball
[20:51] <rsalveti> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/
[20:51] <rsalveti> let me look
[20:52] <rsalveti> guess only the tarball indeed
[20:52] <ted> Bummer, was hoping to not have to build the image.
[21:10] <sergiusens> rsalveti: probably marked as arch all
[21:11] <sergiusens> rsalveti: oh, it's not...
[21:11] <sergiusens> rsalveti: it still has no alias
[21:11] <rsalveti> right, but would that have anything to this issue?
[21:12] <sergiusens> rsalveti: no, the snappy client (webdm in this case) just sends a request with X-Architecture: amd64 and the store returns the results
[21:12] <rsalveti> right
[21:13] <rsalveti> so probably something for beuno to check
[21:15] <sergiusens> rsalveti: curl -s -H 'accept: application/hal+json' -H "X-Ubuntu-Release: 15.04-core" -H "X-Ubuntu-Architecture: armhf" "https://search.apps.ubuntu.com/api/v1/search?q=mir" | python -m json.tool
[21:15] <sergiusens> works fine
[21:16] <sergiusens> setting to amd64 makes it return
[21:18] <sergiusens> rsalveti: what image?
[21:18] <sergiusens> I can check
[21:21] <rsalveti> sergiusens: hm, maybe I ended up messing up with my ips in here
[21:21] <rsalveti> I think it might end up being the amd64 one
[21:22] <rsalveti> doing testing in parallel
[21:22] <rsalveti> sergiusens: beuno: yeah, my mistake
[21:22] <rsalveti> sorry for the noise
[21:26] <sergiusens> rsalveti: no worries, was going to be my next question :-)
[21:36] <sergiusens> rsalveti: fwiw, the banners should be different in webdm
[21:38] <rsalveti> sergiusens: yeah
[21:39] <sergiusens> rsalveti: even in cli ;-)
[21:40] <rsalveti> sure :-)
[21:40] <rsalveti> the problem of doing many things in parallel
[21:44] <kgunn> just curious, i've a snap (& client) that i'm working to make confined
[21:45] <ted> rsalveti, All the instructions I can find for building an img assume you can chroot into it to install stuff. Is there a way to cross build an img?
[21:45] <kgunn> i had the mir server confined and running reliably, just rebuilt (as i had done a few times before)
[21:45] <kgunn> and now getting "new" denials
[21:45] <kgunn> anyone seen something strange like that ?
[21:46] <rsalveti> ted: rootstock-ng is one way, you can give qemu-arm-static to debootstrap
[21:46] <rsalveti> http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/view/head:/rootstock-touch
[21:46] <rsalveti> it's currently touch focused, but might be easy to change to produce a core image instead
[21:46] <kgunn> mterry: for your deb2snap, i looked, but you're not injecting "unconfined" templates  are you? ( i see you do for xmir...but that shoulndt effect me)
[21:47] <ted> rsalveti, K, let me give that a try
[21:47] <mterry> kgunn, not by default.  You can pass --aa-template unconfined or something like that to make it unconfined
[21:47] <mterry> kgunn, but without arguments, we use default confinement
[21:47] <kgunn> mterry: ok, and nope...actually trying to make sure it's confined
[21:47] <kgunn> just seeing weird stuff
[21:47] <rsalveti> ted: also make sure to use https://launchpad.net/~snappy-dev/+archive/ubuntu/image since we got a specific livecd-rootfs version in there
[21:47] <rsalveti> and this ppa is also used when creating the image
[21:47] <mterry> kgunn, hrm.  You can always check the resulting snap's package.yaml file
[21:48] <sergiusens> Chipaca: jdstrand is /var/lib/apparmor/clicks still needed or can we do with just .../snappy ?
[21:55]  * kgunn suspects he's done too much to this image and vmm project files...blows aways and starts fresh
[22:02] <jdstrand> sergiusens: it is needed as long as click-apparmor is around
[22:02] <jdstrand> which abviously is meant to go away
[22:02] <jdstrand> the dir could obviously be changed
[22:11] <sergiusens> jdstrand: k, just seeing we have /var/lib/apparmor/[snappy|clicks] ... but I don't have snappy proper running right now to double check they are the same