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