=== EllieGoulding is now known as plop_its_ellie === user is now known as Guest10540 [06:29] Has anyone managed to get OVA on VirtualBox working? (https://developer.ubuntu.com/en/snappy/start/#ova) I see many complaints about not being able to log in after cloud-init, ..., and I wasn't able to, either. [07:00] good morning [07:03] good morning === chihchun_afk is now known as chihchun [07:05] fgimenez: o/ [07:14] Morning o/ === chihchun is now known as chihchun_afk === bigcat is now known as bigcat[brb] === bigcat[brb] is now known as bigcat [09:17] Good morning all; happy Monday, and happy Take Your Webmaster To Lunch Day! 😃 === chihchun_afk is now known as chihchun [09:24] JamesTait: Just realized: I'm my own webmaster! [09:24] * Chipaca will take himself to lunch [09:24] Chipaca, me too. :( [09:25] JamesTait: :(? \o/! [09:27] Chipaca, possibly. The benefit of someone else taking me to lunch is they'll pay. That may or may not be outweighed by the burden of their company, depending who they are. [09:29] Chipaca, also, happy Fried Chicken Day! Enjoy your solitary trip to KFC. 😉 [09:30] JamesTait: was about to point out i had no kfc close enough, but i was wrong! [09:31] but there's a “kebabs & southern fried chicken” closer than that [09:31] i'm not feeling brave enough for either tbh [09:40] Chipaca, so... happy fry your own chicken day? [09:41] JamesTait: happy leftovers day \o/ :) [09:41] Hah! You win! [09:41] need to polish off some things before they go off [09:42] including a palta and a ball of bufala mozzarella [09:42] so dunno what it's going to be, but it's going to be awesome :) [09:45] JamesTait: are you not in .uy? [09:46] Chipaca, nope. [09:46] JamesTait: ah, ok then :) [09:46] Off the top of my head I'm not sure who's over there, tbh. [09:47] I don't think it's many though, IIUC it's at Martin's place. [10:44] JamesTait: here, one for you: http://www.whitevinyldesign.com/solarbeat/ [10:47] Chipaca, that is beautiful. ☺ [10:50] greetings [10:51] can i have someone review a framework i submitted yesterday called "capes"? [10:51] spent the weekend porting our packages from "binaries" to "services" and we'll need that framework in order to upload the apps === chihchun is now known as chihchun_afk [14:01] ogra_: sergiusens: for https://bugs.launchpad.net/snappy/+bug/1429749, what would be the proper fix? [14:01] Ubuntu bug 1429749 in Snappy trunk "Ubuntu Core updated but not switch to new version after reboot on Raspberry Pi 2" [Undecided,New] [14:02] not allow update for ubuntu-core? [14:02] yes, sergiusens added a warning to udf recently for that [14:02] and i thought the plan was to not support that at all [14:02] ogra_: but this is on a running system? [14:02] s/?//g [14:03] well, it does the download but wont switch partitions [14:03] i understood that will be fixed on a snappy level so it wont attempt the download [14:18] ogra_: right, that's what I assumed as well, but don't know if we got anything for it yet [14:18] maybe sergiusens knows more [14:18] i thin that waits for the s-i dropping [14:18] *think [14:23] ogra_: rsalveti running systems won't be affected by the change, only new ones [14:23] indeed, since running systems wouldnt use udf :) [14:23] neither will people that use the stable image and dd it [14:25] sergiusens: right, they can flash new images, that's fine [14:25] sergiusens: but is there anything we can do in snappy itself to forbid such update? [14:25] or give a better error or such? [14:26] rsalveti: not without manual hacks [14:26] sergiusens: why manual hacks? [14:26] sergiusens: can't we check for the origin? [14:26] right, we discussed that before ... which made me think we'll wait for the switch away from s-i [14:26] rsalveti: the origin feature only landed last week [14:26] into rolling [14:26] trunk [14:27] and origins for device tarballs is sort of complicated [14:27] sergiusens: sure, not necessarily for this week/release, just trying to understand what would be the proper solution [14:27] rsalveti: move to snaps [14:27] that's the proper solution ;-) [14:27] for stable though, anything we do will be a hack [14:28] (on a sidenote it is trivial to hack around the issue currently ... by just hacking snappy-system.txt) [14:28] unless it's done during prov [14:28] yeah, was wondering for stable [14:28] ogra_: right, but that is a prov thing [14:30] even if it would be supported, the RPi uboot cant handle it currently [14:30] (on another sidenote :) ) [14:40] good morning [14:41] they are fixing the plumbing in my apartment today, so I might be on and off during the morning. [14:42] fgimenez: have you seen any errors while doing the failover updates? [14:43] mterry: ogra_: sergiusens: about bug 1444049, should we just include libc6:i386? [14:43] bug 1444049 in Snappy trunk "Shipping libc6:i386 in the amd64 images would be useful" [Undecided,New] https://launchpad.net/bugs/1444049 [14:43] I imagine this to be an issue soon [14:43] and not a trivial one to let the user to fix himself [14:43] elopio, yes, with version #98 TestZeroSizeSystemd is failing [14:43] hmm [14:44] elopio, this branch fixes it https://code.launchpad.net/~fgimenez/snappy/fix-zerosize-systemd-failover-test [14:44] fgimenez: I saw one grub error yesterday in that test, but didn't dig anything. [14:44] rsalveti, can we do that without additional deps ? [14:44] cool, you already fixed it :) [14:44] rsalveti, ogra_: depends how much we want to cater to running x32 executables... It is rather difficult right now [14:44] what would be the additional deps? [14:44] this is just libc [14:45] ogra_: one for you: https://bugs.launchpad.net/snappy/+bug/1456340 :-) [14:45] elopio, yep, just setting the same permissions to the empty file fixes it [14:45] Ubuntu bug 1456340 in Snappy trunk "Add gdbserver to snappy image" [Undecided,New] [14:45] i understand the conveninece that adds ... but where do we draw the line ? [14:45] let me give it a try. [14:45] hi everyone! any chance i can get my new framework reviewed? (it's called "capes") [14:45] rsalveti, *yawn* ... always the same bugs everywhere ... thats boring [14:45] ogra_: I'd say just libc for now [14:45] rsalveti, ogra_: I think it pulls in libgcc1 too (but that's it) [14:46] rsalveti, yes, but then there is this other compelling lib to add ... and a week later another one .... [14:46] ogra_: :-) [14:46] ogra_: well, don't think we'll add much [14:46] i'm just a bit afraid that over time more and more sneaks into the image like this [14:47] just that not having libc is kind of too much for someone to start [14:47] yeah, lets add it then [14:47] ogra_: easy for rolling, how to add it for stable? :-) [14:47] ogra_: should we create a meta package for it? [14:47] hmm, how did we handle stable til now ? [14:48] and force that meta package in the livecd-rootfs script [14:48] (given we dont have meta packages at all) [14:48] ogra_: in livecd-rootfs itself [14:49] if we need to hack livecd-rootfs anyway i wouldnt add a meta .... just add libc there [14:49] ogra_: that's fine I guess, we don't plan to increase this much anyway [14:49] (though i'm not sure if live-build is multiarch aware ) [14:49] hm, right [14:49] needs a test i guess [14:50] ogra_: and about gdbserver, should we add it as well? [14:50] yeah [14:50] alright, adding both bugs to you then :-) [14:51] :) [14:51] gdbserver should eb a hard dep of libc :P then we dont need to seed it everywhere [14:51] *be [14:51] fgimenez: with your filter branch, I started modifying the real update tests. Here's my idea: [14:51] - when there are no available updates, we make the tests to fake one, as we discussed last week. So we flash the latest image, and run everything in there. [14:51] - we flash rev -1. We use a filter that will only run the update so it will leave the image on the latest rev. And then we run on this image all the tests. [14:51] - we flash 15.04. We run only a test that will update it to latest. And then we run on this image all the tests. [14:52] seems everyone and his cousin wants it installed everywhere anyway [14:52] fgimenez: any thoughts? [14:52] mterry: care to backport https://bugs.launchpad.net/snappy/+bug/1461070 ? [14:52] Ubuntu bug 1461070 in Snappy 15.04 "Running set active without sudo gives lower level error than it should" [Undecided,New] [14:54] rsalveti, ok [14:54] mterry: https://bugs.launchpad.net/snappy/+bug/1461917 as well [14:54] Ubuntu bug 1461917 in Snappy 15.04 "snappy app services should auto restart" [Undecided,Triaged] [14:56] elopio, great! :) taking care also of passing the right testList (latest, previous,...) for each case and the testFilter to adtRun will make it very straightforward [14:57] elopio, how's the images and everything today? [14:57] fgimenez: yes, I didn't think your filters would be so useful. Looking at your comment on the branch... [14:57] are we all set? what needs finishing? [14:57] balloons: things seem on nice on wily and using the proposed ppa on vivid. [14:58] balloons: rsalveti and the team are backporting things to the 15.04 branch. Once they are backported, we will have an RC. [15:02] elopio, does install system-status.victor work for you? (sudo snappy install system-status.victor) [15:03] balloons: I can give it a try in ~10 minutes. [15:03] elopio, ack, tyu [15:29] Chipaca, so no console= should be the default [15:30] Chipaca, but we need a way to define one console= option for images that should default to serial [15:31] when somebody comes to us complaining about X weird behaviour [15:31] we would need to remember to ask for their boot commandline [15:31] I'm working on a snap that will need to create some network devices (traditionally done as root during package installation) -- how does that, and other similar privileged admin tasks -- work with a snap? [15:32] Chipaca, well, certain HW implies certain console= settings ... embedded boards like the BB or RPi should efault to serial console [15:32] grub based images that run in a VM or on real HW shouldnt [15:32] ogra_: i'm reading "i'm fine with it being in the gadget snap" [15:33] Chipaca, no, totally not fine with that ... [15:33] because it would mean you need separate gadget snaps pre console option [15:33] ogra_: i know, that's why i said it -- so you'd expand :) [15:33] *per [15:33] ogra_: but you're saying the default is per device, aren't you? [15:33] ogra_: ie bb or rpi need it, vm or real hw don't [15:33] well ... [15:34] * Chipaca notes ogra just said the bb wasn't real hardware [15:34] * Chipaca blames the dentist [15:34] while the BBB is definitely not suited for personal, i would expect that RPi users might run kodi on their boards ... or some other graphical thing [15:34] so they'd want to be able to switch back and forth [15:35] personal specifically might want to use a boot splash ... and would need a graphical soncole device set [15:35] *console [15:36] as i said before already ... i thinbk the only sane way would be to have a u-d-f option to set a non-default console device ... but sergiusens didnt sound happy about addin more u-d-f options [15:37] rsalveti: sergiusens: https://code.launchpad.net/~chipaca/snappy/fix-1461262/+merge/263917 [15:38] ogra_: right now, udf has no kernel options exposed. If we expose one, do you promise your axe to help us defend against the horde? [15:38] well, you can make it not look like a kernel option :) [15:38] ogra_: (i'm not sure whether it's an option at all, really -- people are already complaining about too many obscure options in udf) [15:39] ogra_: start a thread in snappy-devel :-) [15:39] i just dont think it is sane to have a million identical gadget snaps for changed kernel cmdline options [15:40] ogra_: i agree with you :) [15:40] ogra_: i just think you're the one who can defend your point the best. Please do make it on the list :) [15:40] and sadly snappy-config wont work until you booted ... [15:40] Chipaca: thanks for the mr [15:40] yeah [15:41] balloons: package with namespace not supported? [15:41] bregma: how would the network devices be created traditionally? [15:42] Chipaca, through the equivalent of a sudo operation, I imagine [15:43] since this is done by the user at first-run [15:43] bregma: i mean, you'd drop something into network/interfaces.d? [15:45] elopio, yea.. https://bugs.launchpad.net/snappy/+bug/1466674. [15:45] Ubuntu bug 1466674 in Snappy "Snappy store contains packages with namespace" [Undecided,Incomplete] [15:46] balloons: I don't fully understand what nessita is asking in there. [15:47] but the error message doesn't come from the snappy source code. [15:47] that makes two of us, heh. Is there anyway to get more verbose output? Where is the source for the error? [15:48] let me see what install does. [15:49] does it use alias? [15:49] that's the only difference I see between the packages [15:49] elopio, hey! [15:49] balloons: what packages are you comparing? [15:49] * elopio waves at nessita. [15:50] elopio, what I'm asking/saying is that a package's manifest can vadily have as "name" the package full path (ie the store allows this) [15:50] elopio, nessita I simply looked at the json for the hello-world package (which works fine) and the system status package from victor [15:50] the hello world package has an alias, the system status package has null for that field [15:50] balloons: can you please link to the source of that package? [15:50] balloons, for package metadata you should query the index, since the fields inside a package may not be accurate [15:51] (the package index) [15:51] nessita, I used https://search.apps.ubuntu.com/api/v1/package/system-status.victor and https://search.apps.ubuntu.com/api/v1/package/hello-world [15:51] elopio, links ^^ [15:51] Chipaca, we're trying to create an unprivileged LXC container, so there are a number of steps that need elevated privileges including creating UIDs and running LXC tools to create VETH devices (the exact nature of such operations is beyond my kenning) [15:52] elopio, I'm currently in a sprint so I will try tyo answer as I can, need to run for lunch now (being kick off the room) [15:52] thanks nessita [15:53] bregma: i might be wrong, but i think having an unprivileged snap do privileged things is not currently possible [15:54] arbitrary privileged things, that is [15:54] nessita: buen provecho. [15:54] bregma: although what you're wanting to do is something we want to suppor [15:54] t [15:55] bregma: so maybe we need to map out what you want, and expose it in some way [15:55] Chipaca, our current plan is to just use PAM to elevate privs with authentiction, will that still work on Snappy? [15:56] bregma: i'm going to guess 'no' [15:56] :( [15:56] but i'm not fully sure of what you mean, so :) [15:56] if you mean "after snappy install, run sudo yadda yadda", then maybe yes [15:57] but that won't work in a number of scenarios [15:57] mostly around not having console access to the device :) [15:57] well, the lxd framework should offer you all this, no ? [15:58] our snap is designed to work only on devices with full user interaction, so we don;t care about ones without console access [15:58] ogra_: yep, but it'll need something very close to uncontained :) [15:58] and LXD just doesn't meet our needs in any way [15:58] oh, why is that ? [15:59] i thopught it is only used to fire up lxc containers [16:00] balloons: http://bazaar.launchpad.net/~vthompson/+junk/system-status/view/head:/meta/package.yaml [16:01] http://paste.ubuntu.com/11831452/ [16:01] looks fine to me [16:01] balloons: that's what's needed ^ [16:02] elopio, sure that would fix it I suppose; it's just odd that it fails when the hello-world package has name as hello-world.canonical as the name [16:02] balloons: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/hello-world/meta/package.yaml [16:02] not on the metadata. [16:04] ok, so then the question for nessita is why the package wasn't unpublished then [16:04] as that was the old style [16:04] ty elopio [16:04] also, in here it says that "." is allowed in the name [16:04] https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ [16:04] ohh good catch! [16:04] can you summarize in a comment on the bug? [16:04] i'll add the website to it so it can be fixed too [16:08] whoa.. "snappy autopilot triggered a reboot to boot into an up to date system" [16:14] balloons: autopilot is following you! [16:15] scary! [16:21] sergiusens: you around? [16:37] Chipaca: yes [16:40] sergiusens: good. [16:41] sergiusens: wondering why 'snappy search' would find a package, but install wouldn't [16:41] sounds all very weird to me :) [16:42] Chipaca: search does partial matching while install requires an exact match? [16:43] sergiusens: [16:43] (amd64)ubuntu@localhost:~$ snappy search mir [16:43] Name Version Summary [16:43] mir snap1 Mir example server snap [16:44] Chipaca: http://search.apps.ubuntu.com/api/v1/package/mir.mvp-demo that one? [16:44] bah, amd64 only ? [16:44] Chipaca: it has no alias [16:44] not found on any armhf device [16:44] Chipaca: and it is a framework, that is why [16:44] thats lame [16:45] ogra_: we don't care about armhf ever since you stopped using your chromebook ;-) [16:45] i still have the ac100 [16:45] have != use [16:46] damn ... i'll dig it out next WE ! [16:46] well.. i use it to separate the gray lego from the green lego [16:47] ogra_: oooh! if snappy core boots that, i'll be happy :) [16:47] do you fear little dark green legos ? [16:47] ogra_: if you saw the mess that is the lego box, you'd be laughing too :D [16:47] :) [16:48] it's officially the lego box, but i think the floor has more lego [16:48] ogra_: I'm waiting a bit more for that [16:48] i should probably rename it 'misc junk' or sth [16:48] haha [16:49] * Chipaca sideloads the mir snap [16:49] aaand it's a bad snap :-( [16:49] (amd64)ubuntu@localhost:~$ sudo snappy install ./mir.mvp-demo_snap1_amd64.snap [16:49] Installing ./mir.mvp-demo_snap1_amd64.snap [16:49] ./mir.mvp-demo_snap1_amd64.snap failed to install: can not parse package.yaml: missing required fields 'vendor' (from: "name: mir\nversion: snap1\narchitecture: amd64\ntype: framework\nservices:\n - name: system-compositor\n description: \"system compositor\"\n start: bin/server\n security-template: unconfined\n") [17:07] elopio: Chipaca if you build images for 15.04/edge do they work out? [17:08] elopio: Chipaca if you build images for 15.04/edge do they work out? [17:08] there :-P [17:08] sergiusens: let me try. [17:09] elopio: seem to missing a systemd service here [17:10] udf'ing [17:15] elopio, balloons the package may be old style but is still super valid [17:15] elopio, balloons, so code should be prepared to handle both formats [17:16] we will not unpublish such packages since they are still valid, as far as the store is concerned [17:17] nessita: which package? [17:17] Chipaca, system-status.victor [17:18] Chipaca, https://search.apps.ubuntu.com/api/v1/package/system-status.victor [17:19] ok . . . well, then something on the installation side needs fixed. As it stands it can't be installed and gives the unhelpful error. I'd guess other packages might have the same issue [17:20] nessita: it's not valid, frameworks and oems need to have an alias [17:20] nessita: wrt beuno said oem and framework types would automatically get aliased when accepted [17:21] sergiusens, as far as the store is concerned, that package name is very valid. If it needs an alias that is another feature/story [17:21] sergiusens, which I'm not aware we have in our radar, but surely is on our backlog [17:21] our radar == current items being worked on [17:21] I've found an owner for that [17:22] within the next few weeks [17:22] hopeolly [17:22] nessita: it's not supposed to be published; we have a very manual process for publishing frameworks and oems, can you track down who accepted that package into the store? [17:22] sergiusens, yes [17:22] Chipaca: https://code.launchpad.net/~sergiusens/snappy/closeMe/+merge/263943 [17:23] sergiusens: yes, it prints lots of errors. Not sure which is the first. [17:24] sergiusens, last published version is 1.0.3 and was automatically approved by the scripts with no errors and only 1 warning [17:26] sergiusens, last 4 uploaded versions (1.0.4 up to 1.0.7) are all failing with [17:26] security_policy_vendor_matches_framework (meta/system-status.apparmor): [17:26] ubuntu-snappy != ubuntu (ubuntu-core-15.04-dev1) [17:26] sergiusens, does that give you any debug information? [17:28] elopio: [ 5.783593] systemd[1]: Failed to isolate default target: Unit snappy-workaround-apparmor.service failed to load: No such file or directory. [17:30] nessita: date of last upload? I hope it's newer than the great purge date we did in austin with beuno [17:30] nessita: according to the json result last_updated: "2015-02-24T03:44:14.674552Z", [17:30] sergiusens, version 1.0.3 was approved and published on 2015-02-24 [17:30] this package should not be published [17:31] nessita: we made a massive unpublish in April before release [17:31] sergiusens, who should have unpublished it? [17:31] (to try to track down debug information) [17:31] nessita: beuno and james_w [17:31] nessita: it was an implicit unpublish, asac had requested to wipe the store [17:32] yeah, the format of package.yaml changed [17:32] * ogra_ still hasnt re-published all his packages [17:32] unpublishing was a requirement ... that package simply slipped through [17:32] there is no bug ... [17:32] ogra_: no, it wasn't there and now it is [17:32] sergiusens, so do you know what was the criteria to unpublish packages? obviously the store can not be wiped since we have all the click world in it :-) [17:33] I think I decided to no unpublish things that would get filtered out automatically because we now required a release [17:33] sergiusens, that package is really old ... i used to try it out way before the unpublishing [17:33] nessita: snappy store was to be wiped, the catalog at least; and it's because during the week of austin we decided to make breaking changes for release which required this [17:33] sergiusens, see beuno s comment [17:34] beuno: right, but I guess anyone going in can tick a release, right? [17:34] yes [17:34] so I guess I wasn't *that* smart [17:34] I think that solves the mistery, now we need to come up with a fix that suits everyone [17:34] beuno: which makes packages that were published before sort of dangerous [17:34] because the semantics don't match anymore [17:35] and to be honest, the system-status snap might as well be an app and not a framework ;-) [17:38] rsalveti: image is broken due to https://launchpadlibrarian.net/210538856/ubuntu-core-config_0.6.15%2Bppa6_0.6.15%2Bppa7.diff.gz [17:38] rsalveti: not sure if we need to revert that change or wait for that upstream fix to land... [17:39] sergiusens, beuno nessita thanks for getting to the root of this [17:39] elopio: I think that triggers the issue ^ [17:45] if we want the rc tomorrow, maybe we should revert. [17:48] balloons: once we know what's the latest image we can test tomorrow, I'll make a note on the flashing section of the wiki page. [17:48] are we missing something else? [17:50] elopio, afaik, no. I just need to review the google form again [17:51] I saw https://developer.ubuntu.com/en/snappy/guides/channels/ was updatedso 15.04/edge is what we want people to use yes? [17:52] elopio: I think I know where this comes from, I'll take a look [17:52] balloons: no, that should be 15.04/rc. [17:56] elopio, ok, I'll update it again [17:58] elopio: rsalveti I think this fixes our issue at hand http://paste.ubuntu.com/11831998/ [17:59] elopio, I don't see an rc image on cdimage though. [18:00] This goes back to our conversation on u-d-f vs cdimage download [18:00] sergiusens: how can we test that? [18:00] balloons: yes, once we get the rc rsalveti will publish it on cdimage. [18:00] elopio: new image build, or mount the .img and remove the dangling link [18:01] elopio, I assumed as much, y [18:02] elopio: I did that, worked fine [18:03] elopio: sudo kpartx -avs 15.04.img; sudo rm /media/sergiusens/system-a/lib/systemd/system/multi-user.target.requires/snappy-workaround-apparmor.service; umount /media/sergiusens/system-a; sudo kpartx -ds 15.04.img; kvm_snappy 15.04.img [18:03] elopio: but it requires a new image to get things going [18:05] sergiusens: hm, I think mvo also published the real fix [18:05] which is why he reverted the workaround [18:06] sergiusens: oh, you got it [18:06] sergiusens: just upload that fix then [18:07] rsalveti: I just did ;-) [18:07] great [18:07] rsalveti: the workaround wasn't completely reverted though [18:07] yeah [18:07] rsalveti: btw, can you dput the latest snappy trunk? [18:07] * sergiusens needs to get the ppu paperwork done [18:07] sergiusens: sure [18:08] rsalveti: thanks [18:08] * elopio learns kpartx [18:09] sergiusens, seeing that you were the last one to touch the vivid livecd-rootfs in the snappy PPA, do we have a branch for that or do you just patch the package directly ? [18:09] ogra_: I am not aware of a branch, I just used the packaging [18:09] k. sounds fine ... [18:09] ogra_: same for ubuntu-core-config [18:09] sergiusens: do we need to backport https://code.launchpad.net/~sergiusens/snappy/closeMe/+merge/263943 ? [18:10] thanks ! [18:10] rsalveti: nope, only required for the latest u-d-f builds to allow clean unmounts ;-) [18:10] great [18:10] ogra_: are you changing anything crazy? Since I want to trigger a new build soon to get a working image [18:11] rsalveti, so seeds definitely dont support multiarch ... (i asked cjwatson) ... [18:11] ogra_: hm, that's interesting [18:11] how is that done on the desktop? [18:11] sergiusens, one insane (test) thing and one easy and safe one [18:11] or libc just gets installed when required/ [18:11] ? [18:11] ogra_: hmmm, then let me trigger a build before that :-) [18:11] rsalveti, we dont have any images where foreign arch packages are preinstalled [18:12] ogra_: nice [18:12] ogra_: so we have a working test base and I don't need to chase my tail like a dog :-P [18:12] sergiusens, well, i can do it tomorrow morning (would actually prefer to) ... but it is for RC [18:12] sergiusens: trigger an image now [18:12] build is kind of fast anyway [18:12] rsalveti: waiting for packages to publish [18:12] rsalveti, and i'm not sure about using :i386 in live-build, i need at least one test build to see what happens [18:13] ogra_: right [18:13] (and indeed i have no local setup) [18:13] sergiusens: gotta love launchpad [18:13] rsalveti: did you read my latest blog entry? :-P [18:13] sergiusens: not fully yet, in my toread [18:14] new kernel landed in updates [18:14] yay [18:22] sergiusens: on your post I think that you are not taking into account that travis is not running trusty. [18:22] sergiusens: package was just published [18:23] sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.5ubuntu1 [18:23] ogra_, if I edited uEnv.txt on the boot partition on a snappy Pi, it should change the kernel command line, should it? does uEnv (it's the bootloader, right?) itself talk console by any chance? [18:24] uboot you mean [18:24] yes, it talks to serial only [18:25] Saviq, any probs with that ? [18:26] (uEnv.txt is for overrides, it could well be that uboot itself sets some HW related defaults before processing uEnv.txt) [18:27] elopio: we don't care, sbuild for package builds and go is avail on the platform so it is not far away from what we have today [18:28] sergiusens: what about the calls we make to ubuntu-device-flash? [18:28] elopio: that does not happen on tarmac today [18:28] could we backport the ppa to ... lucid I think is what they have [18:28] elopio: they have precise envs [18:29] elopio: and we don't use ppa's in our tarmac setup [18:29] elopio: nor package building [18:29] oh, well, that's right. No much different to our present. [18:29] elopio: but giving webhooks are instantly available, we can do a lot already [18:30] elopio: rsalveti: ogra_ I triggered a vivid image [18:37]