| === chihchun_afk is now known as chihchun | ||
| === wolfeidau_ is now known as wolfeidau | ||
| dholbach | good morning | 06:45 |
|---|---|---|
| === _morphis is now known as morphis | ||
| fgimenez | good morning | 07:06 |
| === erkules_ is now known as erkules | ||
| JamesTait | Good morning all; happy Monday, and happy Walk on Stilts Day! 😃 | 09:08 |
| * Chipaca winces | 09:11 | |
| JamesTait | Chipaca, what could possibly go wrong? | 09:12 |
| Chipaca | JamesTait: with *my* balance and co-ordination? *EVERYTHING* | 09:12 |
| 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. | 09:13 |
| === cprov_ is now known as cprov | ||
| === andyrock_ is now known as andyrock | ||
| === alecu_ is now known as alecu | ||
| ogra_ | phew .. so much fallout | 10:29 |
| ricmm | ogra_: of? | 10:39 |
| ogra_ | ricmm, https://plus.google.com/+OliverGrawert/posts/iF5CqLtFEAR?cfem=1 | 10:40 |
| 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:41 |
| ogra_ | (which got me a bit of mail and comments ... ) | 10:42 |
| ricmm | :) | 10:51 |
| ricmm | not sure about continuing to reply in that g+ post | 10:51 |
| 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:52 |
| * ogra_ wanted to trigger commitment that some KDE people would show up :) | 10:53 | |
| svij | martin gräßlin showed up 2012 + 2013 | 10:54 |
| svij | (at ubucon de) | 10:54 |
| ogra_ | well, after his mir battling i doubt he will this time | 10:55 |
| svij | yeah :( | 10:55 |
| 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:56 |
| 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 | 10:58 |
| === yofel_ is now known as yofel | ||
| ogra_ | oh ! | 11:20 |
| ogra_ | sebas commented ... | 11:20 |
| === howefield_afk is now known as howefield | ||
| * Chipaca ~> luncheon | 11:45 | |
| Chipaca | that's like a lunch that lasts an eon \o/ | 11:46 |
| elopio | good morning. | 12:32 |
| 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:05 |
| === tedg is now known as ted | ||
| lool | rsalveti: oh the plasma thing is on wayland? interesting | 13:34 |
| lool | I thought they were on mir for that demo | 13:35 |
| rsalveti | lool: http://vizzzion.org/blog/2015/07/embracing-mobile/ | 13:35 |
| 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:36 |
| lool | haha | 13:37 |
| ogra_ | they are using wayland | 13:37 |
| lool | yeah, the blog post keeps rehashing that point | 13:37 |
| 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:38 |
| ogra_ | rsalveti, isnt wayland still limited to only a few android drivers though ? | 13:39 |
| === rcj` is now known as rcj | ||
| 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:39 |
| rsalveti | our situation is not so much better | 13:41 |
| rsalveti | which is why we always end up requiring changes at the driver side | 13:42 |
| ogra_ | ah | 13:42 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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 | 13:55 |
| rsalveti | ogra_: all good with 132 then, right? | 14:07 |
| * 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:08 |
| 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:09 |
| * ogra_ rolls an alpha image | 14:10 | |
| fgimenez | rsalveti, ok, on it | 14:11 |
| ogra_ | grrr | 14:18 |
| ogra_ | forgot to use --revision | 14:18 |
| * ogra_ starts over | 14:18 | |
| fgimenez | rsalveti, 8 -> 9 -> 8 goes fine here, i'm executing now the automated suite against 9 | 14:47 |
| rsalveti | cool | 14:47 |
| === chihchun is now known as chihchun_afk | ||
| 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:52 |
| beuno | vmayoral, you mean, to update a client, for example? | 14:53 |
| beuno | or a genuine fresh install of the OEM snap to a running client who hasn't installed it before? | 14:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 14:59 |
| 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:00 |
| vmayoral | beuno, ogra_: thanks for explaining, tried that with the "--allow-unauthenticated" flag | 15:03 |
| 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:04 |
| 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:06 |
| 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:07 |
| Chipaca | sergiusens: golang and python's standard libraries both check http_proxy and HTTP_PROXY :) | 15:17 |
| 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:22 |
| beuno | Chipaca, sergiusens, sounds like we at least want to document this piece | 15:23 |
| beuno | how to iterate on OEM snaps | 15:23 |
| 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:29 |
| fgimenez | elopio, about the refactoring card, we could begin by extracting the build and adtrun code to helpers, what do you think? | 15:30 |
| elopio | fgimenez: yes, that would be good too. Want me to start? | 15:31 |
| 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:32 |
| elopio | I'm not yet sure how much I want to test them, but adding a couple of tests never hurts. | 15:33 |
| 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:34 |
| ogra_ | Chipaca, it is really not *that* important (as long as core stays small) | 15:35 |
| * Chipaca considers making a wwwwoffle snap | 15:37 | |
| 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:43 |
| 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:44 |
| fgimenez | elopio, we can try both approaches, the nova script makes a lot of sense, but we should fork and modify it | 15:45 |
| 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:47 |
| rsalveti | ubuntu-device-flash core --help | 15:48 |
| vmayoral | rsalveti: https://gist.github.com/vmayoral/90da57bebc20ada52f56 | 15:49 |
| * 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:50 |
| rsalveti | goget-ubuntu-touch 0.27-0ubuntu1 | 15:51 |
| vmayoral | ok, let me write that down, will try it again later and give feedback, thanks | 15:54 |
| 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:06 |
| kyrofa | seb128, alright, thanks! | 16:07 |
| kyrofa | ogra_, ^^ trying to get the snappy scope into the Ubuntu Personal seed, if you have any time to check it out | 16:08 |
| 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:09 | |
| 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:10 |
| seb128 | ogra_, yes, the seed are used to build the iso | 16:13 |
| ogra_ | yes, i know how tezh iso works ... for snappy core we dont have a metapackage though, it uses germinate directly | 16:14 |
| 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:15 |
| ogra_ | yeah | 16:16 |
| kyrofa | ogra_, seb128 do I need to make a MP elsewhere as well? | 16:16 |
| ogra_ | kyrofa, hmm, i cant merge it ... i think the desktop-next part actually comes from the touch seed | 16:17 |
| kyrofa | ogra_, not the desktop seed? | 16:18 |
| ogra_ | lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/ | 16:18 |
| ogra_ | and in there the desktop file | 16:19 |
| seb128 | correct | 16:19 |
| kyrofa | ogra_, I'm confused... isn't that what this MP is against? | 16:20 |
| ogra_ | oh | 16:20 |
| ogra_ | silly me | 16:20 |
| ogra_ | kyrofa, merged and pushed (might need a meta package rebuild though, but the seed should be fine now) | 16:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| 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:31 |
| 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:32 |
| 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:33 |
| seb128 | :-) | 16:35 |
| kyrofa | ogra_, thank you for your time and help :) | 16:36 |
| ogra_ | np | 16:37 |
| ogra_ | and uploaded ... next image build should have your scope | 16:42 |
| kyrofa | ogra_, fantastic! | 16:49 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:50 |
| zeromon_ | thanks fot information. I am trying to understand it. | 17:52 |
| zeromon_ | Can I install Ubuntu snappy core on the normal PC? | 17:59 |
| 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:02 |
| 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:03 |
| 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:04 |
| sergiusens | elopio: testutils? | 18:07 |
| sergiusens | elopio: I don't mind the folder, I just don't like the generic name ;) | 18:07 |
| 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:08 |
| sergiusens | elopio: yes | 18:16 |
| sergiusens | elopio: look at path and path/filepath | 18:17 |
| sergiusens | elopio: http://golang.org/src/path/ | 18:17 |
| elopio | right. | 18:17 |
| 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:18 |
| elopio | and instead of common, we should name it base, or something like that. | 18:19 |
| 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:21 |
| 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. | 18:22 |
| === howefield is now known as howefield_afk | ||
| ted | Is there a reason we don't have snappy generic images for arm and other arches? | 20:20 |
| 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:22 |
| 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:23 |
| rsalveti | it's as generic as the kernel is | 20:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| rsalveti | utlemming: can you run your usual testing scenarios over it and see if there is any issue with the cloud targets? | 20:39 |
| === kickinz1 is now known as kickinz1|afk | ||
| rsalveti | beuno: sergiusens: why is the mir framework showing up on webdm even on armhf? | 20:43 |
| rsalveti | afaik it's only amd64 | 20:43 |
| 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:50 |
| 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:51 |
| rsalveti | guess only the tarball indeed | 20:52 |
| ted | Bummer, was hoping to not have to build the image. | 20:52 |
| sergiusens | rsalveti: probably marked as arch all | 21:10 |
| 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:11 |
| 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:12 |
| rsalveti | so probably something for beuno to check | 21:13 |
| 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:15 |
| sergiusens | setting to amd64 makes it return | 21:16 |
| sergiusens | rsalveti: what image? | 21:18 |
| sergiusens | I can check | 21:18 |
| 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:21 |
| rsalveti | doing testing in parallel | 21:22 |
| rsalveti | sergiusens: beuno: yeah, my mistake | 21:22 |
| rsalveti | sorry for the noise | 21:22 |
| sergiusens | rsalveti: no worries, was going to be my next question :-) | 21:26 |
| sergiusens | rsalveti: fwiw, the banners should be different in webdm | 21:36 |
| rsalveti | sergiusens: yeah | 21:38 |
| sergiusens | rsalveti: even in cli ;-) | 21:39 |
| rsalveti | sure :-) | 21:40 |
| rsalveti | the problem of doing many things in parallel | 21:40 |
| kgunn | just curious, i've a snap (& client) that i'm working to make confined | 21:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| sergiusens | Chipaca: jdstrand is /var/lib/apparmor/clicks still needed or can we do with just .../snappy ? | 21:48 |
| * kgunn suspects he's done too much to this image and vmm project files...blows aways and starts fresh | 21:55 | |
| 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:02 |
| 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 | 22:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!