[06:29] <Guest10540> 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] <dholbach> good morning
[07:03] <fgimenez> good morning
[07:05] <sturmflut2> fgimenez: o/
[07:14] <davidcalle> Morning o/
[09:17] <JamesTait> Good morning all; happy Monday, and happy Take Your Webmaster To Lunch Day! 😃
[09:24] <Chipaca> JamesTait: Just realized: I'm my own webmaster!
[09:24]  * Chipaca will take himself to lunch
[09:24] <JamesTait> Chipaca, me too. :(
[09:25] <Chipaca> JamesTait: :(? \o/!
[09:27] <JamesTait> 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] <JamesTait> Chipaca, also, happy Fried Chicken Day! Enjoy your solitary trip to KFC. 😉
[09:30] <Chipaca> JamesTait: was about to point out i had no kfc close enough, but i was wrong!
[09:31] <Chipaca> but there's a “kebabs & southern fried chicken” closer than that
[09:31] <Chipaca> i'm not feeling brave enough for either tbh
[09:40] <JamesTait> Chipaca, so... happy fry your own chicken day?
[09:41] <Chipaca> JamesTait: happy leftovers day \o/ :)
[09:41] <JamesTait> Hah! You win!
[09:41] <Chipaca> need to polish off some things before they go off
[09:42] <Chipaca> including a palta and a ball of bufala mozzarella
[09:42] <Chipaca> so dunno what it's going to be, but it's going to be awesome :)
[09:45] <Chipaca> JamesTait: are you not in .uy?
[09:46] <JamesTait> Chipaca, nope.
[09:46] <Chipaca> JamesTait: ah, ok then :)
[09:46] <JamesTait> Off the top of my head I'm not sure who's over there, tbh.
[09:47] <JamesTait> I don't think it's many though, IIUC it's at Martin's place.
[10:44] <Chipaca> JamesTait: here, one for you: http://www.whitevinyldesign.com/solarbeat/
[10:47] <JamesTait> Chipaca, that is beautiful. ☺
[10:50] <vmayoral|pc> greetings
[10:51] <vmayoral|pc> can i have someone review a framework i submitted yesterday called "capes"?
[10:51] <vmayoral|pc> spent the weekend porting our packages from "binaries" to "services" and we'll need that framework in order to upload the apps
[14:01] <rsalveti> ogra_: sergiusens: for https://bugs.launchpad.net/snappy/+bug/1429749, what would be the proper fix?
[14:02] <rsalveti> not allow update for ubuntu-core?
[14:02] <ogra_> yes, sergiusens added a warning to udf recently for that
[14:02] <ogra_> and i thought the plan was to not support that at all
[14:02] <rsalveti> ogra_: but this is on a running system?
[14:02] <rsalveti> s/?//g
[14:03] <ogra_> well, it does the download but wont switch partitions
[14:03] <ogra_> i understood that will be fixed on a snappy level so it wont attempt the download
[14:18] <rsalveti> ogra_: right, that's what I assumed as well, but don't know if we got anything for it yet
[14:18] <rsalveti> maybe sergiusens knows more
[14:18] <ogra_> i thin that waits for the s-i dropping
[14:18] <ogra_> *think
[14:23] <sergiusens> ogra_: rsalveti running systems won't be affected by the change, only new ones
[14:23] <ogra_> indeed, since running systems wouldnt use udf :)
[14:23] <ogra_> neither will people that use the stable image and dd it
[14:25] <rsalveti> sergiusens: right, they can flash new images, that's fine
[14:25] <rsalveti> sergiusens: but is there anything we can do in snappy itself to forbid such update?
[14:25] <rsalveti> or give a better error or such?
[14:26] <sergiusens> rsalveti: not without manual hacks
[14:26] <rsalveti> sergiusens: why manual hacks?
[14:26] <rsalveti> sergiusens: can't we check for the origin?
[14:26] <ogra_> right, we discussed that before ... which made me think we'll wait for the switch away from s-i
[14:26] <sergiusens> rsalveti: the origin feature only landed last week
[14:26] <sergiusens> into rolling
[14:26] <sergiusens> trunk
[14:27] <sergiusens> and origins for device tarballs is sort of complicated
[14:27] <rsalveti> sergiusens: sure, not necessarily for this week/release, just trying to understand what would be the proper solution
[14:27] <sergiusens> rsalveti: move to snaps
[14:27] <sergiusens> that's the proper solution ;-)
[14:27] <sergiusens> for stable though, anything we do will be a hack
[14:28] <ogra_> (on a sidenote it is trivial to hack around the issue currently ... by just hacking snappy-system.txt)
[14:28] <sergiusens> unless it's done during prov
[14:28] <rsalveti> yeah, was wondering for stable
[14:28] <sergiusens> ogra_: right, but that is a prov thing
[14:30] <ogra_> even if it would be supported, the RPi uboot cant handle it currently
[14:30] <ogra_> (on another sidenote :) )
[14:40] <elopio> good morning
[14:41] <elopio> they are fixing the plumbing in my apartment today, so I might be on and off during the morning.
[14:42] <elopio> fgimenez: have you seen any errors while doing the failover updates?
[14:43] <rsalveti> mterry: ogra_: sergiusens: about bug 1444049, should we just include libc6:i386?
[14:43] <rsalveti> I imagine this to be an issue soon
[14:43] <rsalveti> and not a trivial one to let the user to fix himself
[14:43] <fgimenez> elopio, yes, with version #98 TestZeroSizeSystemd is failing
[14:43] <ogra_> hmm
[14:44] <fgimenez> elopio, this branch fixes it https://code.launchpad.net/~fgimenez/snappy/fix-zerosize-systemd-failover-test
[14:44] <elopio> fgimenez: I saw one grub error yesterday in that test, but didn't dig anything.
[14:44] <ogra_> rsalveti, can we do that without additional deps ?
[14:44] <elopio> cool, you already fixed it :)
[14:44] <mterry> rsalveti, ogra_: depends how much we want to cater to running x32 executables...  It is rather difficult right now
[14:44] <rsalveti> what would be the additional deps?
[14:44] <rsalveti> this is just libc
[14:45] <rsalveti> ogra_: one for you: https://bugs.launchpad.net/snappy/+bug/1456340 :-)
[14:45] <fgimenez> elopio, yep, just setting the same permissions to the empty file fixes it
[14:45] <ogra_> i understand the conveninece that adds ... but where do we draw the line ?
[14:45] <elopio> let me give it a try.
[14:45] <vmayoral|home> hi everyone! any chance i can get my new framework reviewed? (it's called "capes")
[14:45] <ogra_> rsalveti, *yawn* ... always the same bugs everywhere ... thats boring
[14:45] <rsalveti> ogra_: I'd say just libc for now
[14:45] <mterry> rsalveti, ogra_: I think it pulls in libgcc1 too (but that's it)
[14:46] <ogra_> rsalveti, yes, but then there is this other compelling lib to add ... and a week later another one ....
[14:46] <rsalveti> ogra_: :-)
[14:46] <rsalveti> ogra_: well, don't think we'll add much
[14:46] <ogra_> i'm just a bit afraid that over time more and more sneaks into the image like this
[14:47] <rsalveti> just that not having libc is kind of too much for someone to start
[14:47] <ogra_> yeah, lets add it then
[14:47] <rsalveti> ogra_: easy for rolling, how to add it for stable? :-)
[14:47] <rsalveti> ogra_: should we create a meta package for it?
[14:47] <ogra_> hmm, how did we handle stable til now ?
[14:48] <rsalveti> and force that meta package in the livecd-rootfs script
[14:48] <ogra_> (given we dont have meta packages at all)
[14:48] <rsalveti> ogra_: in livecd-rootfs itself
[14:49] <ogra_> if we need to hack livecd-rootfs anyway i wouldnt add a meta .... just add libc there
[14:49] <rsalveti> ogra_: that's fine I guess, we don't plan to increase this much anyway
[14:49] <ogra_> (though i'm not sure if live-build is multiarch aware )
[14:49] <rsalveti> hm, right
[14:49] <ogra_> needs a test i guess
[14:50] <rsalveti> ogra_: and about gdbserver, should we add it as well?
[14:50] <ogra_> yeah
[14:50] <rsalveti> alright, adding both bugs to you then :-)
[14:51] <ogra_> :)
[14:51] <ogra_> gdbserver should eb a hard dep of libc :P then we dont need to seed it everywhere
[14:51] <ogra_> *be
[14:51] <elopio> fgimenez: with your filter branch, I started modifying the real update tests. Here's my idea:
[14:51] <elopio> - 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] <elopio> - 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] <elopio> - 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] <ogra_> seems everyone and his cousin wants it installed everywhere anyway
[14:52] <elopio> fgimenez: any thoughts?
[14:52] <rsalveti> mterry: care to backport https://bugs.launchpad.net/snappy/+bug/1461070 ?
[14:54] <mterry> rsalveti, ok
[14:54] <rsalveti> mterry: https://bugs.launchpad.net/snappy/+bug/1461917 as well
[14:56] <fgimenez> 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] <balloons> elopio, how's the images and everything today?
[14:57] <elopio> fgimenez: yes, I didn't think your filters would be so useful. Looking at your comment on the branch...
[14:57] <balloons> are we all set? what needs finishing?
[14:57] <elopio> balloons: things seem on nice on wily and using the proposed ppa on vivid.
[14:58] <elopio> balloons: rsalveti and the team are backporting things to the 15.04 branch. Once they are backported, we will have an RC.
[15:02] <balloons> elopio, does install system-status.victor work for you? (sudo snappy install system-status.victor)
[15:03] <elopio> balloons: I can give it a try in ~10 minutes.
[15:03] <balloons> elopio, ack, tyu
[15:29] <ogra_> Chipaca, so no console= should be the default
[15:30] <ogra_> Chipaca, but we need a way to define one console= option for images that should default to serial
[15:31] <Chipaca> when somebody comes to us complaining about X weird behaviour
[15:31] <Chipaca> we would need to remember to ask for their boot commandline
[15:31] <bregma> 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] <ogra_> Chipaca, well, certain HW implies certain console= settings ... embedded boards like the BB or RPi should efault to serial console
[15:32] <ogra_> grub based images that run in a VM or on real HW shouldnt
[15:32] <Chipaca> ogra_: i'm reading "i'm fine with it being in the gadget snap"
[15:33] <ogra_> Chipaca, no, totally not fine with that ...
[15:33] <ogra_> because it would mean you need separate gadget snaps pre console option
[15:33] <Chipaca> ogra_: i know, that's why i said it -- so you'd expand :)
[15:33] <ogra_> *per
[15:33] <Chipaca> ogra_: but you're saying the default is per device, aren't you?
[15:33] <Chipaca> ogra_: ie bb or rpi need it, vm or real hw don't
[15:33] <ogra_> well ...
[15:34]  * Chipaca notes ogra just said the bb wasn't real hardware
[15:34]  * Chipaca blames the dentist
[15:34] <ogra_> 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] <ogra_> so they'd want to be able to switch back and forth
[15:35] <ogra_> personal specifically might want to use a boot splash ... and would need a graphical soncole device set
[15:35] <ogra_> *console
[15:36] <ogra_> 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] <Chipaca> rsalveti: sergiusens: https://code.launchpad.net/~chipaca/snappy/fix-1461262/+merge/263917
[15:38] <Chipaca> 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] <ogra_> well, you can make it not look like a kernel option :)
[15:38] <Chipaca> 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] <rsalveti> ogra_: start a thread in snappy-devel :-)
[15:39] <ogra_> i just dont think it is sane to have a million identical gadget snaps for changed kernel cmdline options
[15:40] <Chipaca> ogra_: i agree with you :)
[15:40] <Chipaca> ogra_: i just think you're the one who can defend your point the best. Please do make it on the list :)
[15:40] <ogra_> and sadly snappy-config wont work until you booted ...
[15:40] <rsalveti> Chipaca: thanks for the mr
[15:40] <ogra_> yeah
[15:41] <elopio> balloons: package with namespace not supported?
[15:41] <Chipaca> bregma: how would the network devices be created traditionally?
[15:42] <bregma> Chipaca, through the equivalent of a sudo operation, I imagine
[15:43] <bregma> since this is done by the user at first-run
[15:43] <Chipaca> bregma: i mean, you'd drop something into network/interfaces.d?
[15:45] <balloons> elopio, yea.. https://bugs.launchpad.net/snappy/+bug/1466674.
[15:46] <elopio> balloons: I don't fully understand what nessita is asking in there.
[15:47] <elopio> but the error message doesn't come from the snappy source code.
[15:47] <balloons> that makes two of us, heh. Is there anyway to get more verbose output? Where is the source for the error?
[15:48] <elopio> let me see what install does.
[15:49] <balloons> does it use alias?
[15:49] <balloons> that's the only difference I see between the packages
[15:49] <nessita> elopio, hey!
[15:49] <elopio> balloons: what packages are you comparing?
[15:49]  * elopio waves at nessita.
[15:50] <nessita> 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] <balloons> 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] <balloons> the hello world package has an alias, the system status package has null for that field
[15:50] <elopio> balloons: can you please link to the source of that package?
[15:50] <nessita> balloons, for package metadata you should query the index, since the fields inside a package may not be accurate
[15:51] <nessita> (the package index)
[15:51] <balloons> 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] <balloons> elopio, links ^^
[15:51] <bregma> 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] <nessita> 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] <balloons> thanks nessita
[15:53] <Chipaca> bregma: i might be wrong, but i think having an unprivileged snap do privileged things is not currently possible
[15:54] <Chipaca> arbitrary privileged things, that is
[15:54] <elopio> nessita: buen provecho.
[15:54] <Chipaca> bregma: although what you're wanting to do is something we want to suppor
[15:54] <Chipaca> t
[15:55] <Chipaca> bregma: so maybe we need to map out what you want, and expose it in some way
[15:55] <bregma> Chipaca, our current plan is to just use PAM to elevate privs with authentiction, will that still work on Snappy?
[15:56] <Chipaca> bregma: i'm going to guess 'no'
[15:56] <bregma> :(
[15:56] <Chipaca> but i'm not fully sure of what you mean, so :)
[15:56] <Chipaca> if you mean "after snappy install, run sudo yadda yadda", then maybe yes
[15:57] <Chipaca> but that won't work in a number of scenarios
[15:57] <Chipaca> mostly around not having console access to the device :)
[15:57] <ogra_> well, the lxd framework should offer you all this, no ?
[15:58] <bregma> 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] <Chipaca> ogra_: yep, but it'll need something very close to uncontained :)
[15:58] <bregma> and LXD just doesn't meet our needs in any way
[15:58] <ogra_> oh, why is that ?
[15:59] <ogra_> i thopught it is only used to fire up lxc containers
[16:00] <elopio> balloons: http://bazaar.launchpad.net/~vthompson/+junk/system-status/view/head:/meta/package.yaml
[16:01] <elopio> http://paste.ubuntu.com/11831452/
[16:01] <balloons> looks fine to me
[16:01] <elopio> balloons: that's what's needed ^
[16:02] <balloons> 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] <elopio> balloons: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/hello-world/meta/package.yaml
[16:02] <elopio> not on the metadata.
[16:04] <balloons> ok, so then the question for nessita is why the package wasn't unpublished then
[16:04] <balloons> as that was the old style
[16:04] <balloons> ty elopio
[16:04] <elopio> also, in here it says that "." is allowed in the name
[16:04] <elopio> https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
[16:04] <balloons> ohh good catch!
[16:04] <balloons> can you summarize in a comment on the bug?
[16:04] <balloons> i'll add the website to it so it can be fixed too
[16:08] <balloons> whoa.. "snappy autopilot triggered a reboot to boot into an up to date system"
[16:14] <elopio> balloons: autopilot is following you!
[16:15] <balloons> scary!
[16:21] <Chipaca> sergiusens: you around?
[16:37] <sergiusens> Chipaca: yes
[16:40] <Chipaca> sergiusens: good.
[16:41] <Chipaca> sergiusens: wondering why 'snappy search' would find a package, but install wouldn't
[16:41] <Chipaca> sounds all very weird to me :)
[16:42] <sergiusens> Chipaca: search does partial matching while install requires an exact match?
[16:43] <Chipaca> sergiusens:
[16:43] <Chipaca> (amd64)ubuntu@localhost:~$ snappy search mir
[16:43] <Chipaca> Name Version Summary
[16:43] <Chipaca> mir  snap1   Mir example server snap
[16:44] <sergiusens> Chipaca: http://search.apps.ubuntu.com/api/v1/package/mir.mvp-demo that one?
[16:44] <ogra_> bah, amd64 only ?
[16:44] <sergiusens> Chipaca: it has no alias
[16:44] <ogra_> not found on any armhf device
[16:44] <sergiusens> Chipaca: and it is a framework, that is why
[16:44] <ogra_> thats lame
[16:45] <sergiusens> ogra_: we don't care about armhf ever since you stopped using your chromebook ;-)
[16:45] <Chipaca> i still have the ac100
[16:45] <sergiusens> have != use
[16:46] <ogra_> damn ... i'll dig it out next WE !
[16:46] <Chipaca> well.. i use it to separate the gray lego from the green lego
[16:47] <Chipaca> ogra_: oooh! if snappy core boots that, i'll be happy :)
[16:47] <ogra_> do you fear little dark green legos ?
[16:47] <Chipaca> ogra_: if you saw the mess that is the lego box, you'd be laughing too :D
[16:47] <ogra_> :)
[16:48] <Chipaca> it's officially the lego box, but i think the floor has more lego
[16:48] <sergiusens> ogra_: I'm waiting a bit more for that
[16:48] <Chipaca> i should probably rename it 'misc junk' or sth
[16:48] <ogra_> haha
[16:49]  * Chipaca sideloads the mir snap
[16:49] <Chipaca> aaand it's a bad snap :-(
[16:49] <Chipaca> (amd64)ubuntu@localhost:~$ sudo snappy install ./mir.mvp-demo_snap1_amd64.snap
[16:49] <Chipaca> Installing ./mir.mvp-demo_snap1_amd64.snap
[16:49] <Chipaca> ./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] <sergiusens> elopio: Chipaca if you build images for 15.04/edge do they work out?
[17:08] <sergiusens> elopio: Chipaca if you build images for 15.04/edge do they work out?
[17:08] <sergiusens> there :-P
[17:08] <elopio> sergiusens: let me try.
[17:09] <sergiusens> elopio: seem to missing a systemd service here
[17:10] <elopio> udf'ing
[17:15] <nessita> elopio, balloons the package may be old style but is still super valid
[17:15] <nessita> elopio, balloons, so code should be prepared to handle both formats
[17:16] <nessita> we will not unpublish such packages since they are still valid, as far as the store is concerned
[17:17] <Chipaca> nessita: which package?
[17:17] <nessita> Chipaca, system-status.victor
[17:18] <nessita> Chipaca, https://search.apps.ubuntu.com/api/v1/package/system-status.victor
[17:19] <balloons> 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] <sergiusens> nessita: it's not valid, frameworks and oems need to have an alias
[17:20] <sergiusens> nessita: wrt beuno said oem and framework types would automatically get aliased when accepted
[17:21] <nessita> 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] <nessita> sergiusens, which I'm not aware we have in our radar, but surely is on our backlog
[17:21] <nessita> our radar == current items being worked on
[17:21] <beuno> I've found an owner for that
[17:22] <beuno> within the next few weeks
[17:22] <beuno> hopeolly
[17:22] <sergiusens> 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] <nessita> sergiusens, yes
[17:22] <sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snappy/closeMe/+merge/263943
[17:23] <elopio> sergiusens: yes, it prints lots of errors. Not sure which is the first.
[17:24] <nessita> sergiusens, last published version is 1.0.3 and was automatically approved by the scripts with no errors and only 1 warning
[17:26] <nessita> sergiusens, last 4 uploaded versions (1.0.4 up to 1.0.7) are all failing with
[17:26] <nessita> security_policy_vendor_matches_framework (meta/system-status.apparmor):
[17:26] <nessita> ubuntu-snappy != ubuntu (ubuntu-core-15.04-dev1)
[17:26] <nessita> sergiusens, does that give you any debug information?
[17:28] <sergiusens> 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] <sergiusens> nessita: date of last upload? I hope it's newer than the great purge date we did in austin with beuno
[17:30] <sergiusens> nessita: according to the json result last_updated: "2015-02-24T03:44:14.674552Z",
[17:30] <nessita> sergiusens, version 1.0.3 was approved and published on  2015-02-24
[17:30] <sergiusens> this package should not be published
[17:31] <sergiusens> nessita: we made a massive unpublish in April before release
[17:31] <nessita> sergiusens, who should have unpublished it?
[17:31] <nessita> (to try to track down debug information)
[17:31] <sergiusens> nessita: beuno and james_w
[17:31] <sergiusens> nessita: it was an implicit unpublish, asac had requested to wipe the store
[17:32] <ogra_> yeah, the format of package.yaml changed
[17:32]  * ogra_ still hasnt re-published all his packages
[17:32] <ogra_> unpublishing was a requirement ... that package simply slipped through
[17:32] <ogra_> there is no bug ...
[17:32] <sergiusens> ogra_: no, it wasn't there and now it is
[17:32] <nessita> 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] <beuno> I think I decided to no unpublish things that would get filtered out automatically because we now required a release
[17:33] <ogra_> sergiusens, that package is really old ... i used to try it out way before the unpublishing
[17:33] <sergiusens> 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] <nessita> sergiusens, see beuno s comment
[17:34] <sergiusens> beuno: right, but I guess anyone going in can tick a release, right?
[17:34] <beuno> yes
[17:34] <beuno> so I guess I wasn't *that* smart
[17:34] <nessita> I think that solves the mistery, now we need to come up with a fix that suits everyone
[17:34] <sergiusens> beuno: which makes packages that were published before sort of dangerous
[17:34] <sergiusens> because the semantics don't match anymore
[17:35] <sergiusens> and to be honest, the system-status snap might as well be an app and not a framework ;-)
[17:38] <sergiusens> 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] <sergiusens> rsalveti: not sure if we need to revert that change or wait for that upstream fix to land...
[17:39] <balloons> sergiusens, beuno nessita thanks for getting to the root of this
[17:39] <sergiusens> elopio: I think that triggers the issue ^
[17:45] <elopio> if we want the rc tomorrow, maybe we should revert.
[17:48] <elopio> 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] <elopio> are we missing something else?
[17:50] <balloons> elopio, afaik, no. I just need to review the google form again
[17:51] <balloons> 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] <sergiusens> elopio: I think I know where this comes from, I'll take a look
[17:52] <elopio> balloons: no, that should be 15.04/rc.
[17:56] <balloons> elopio, ok, I'll update it again
[17:58] <sergiusens> elopio: rsalveti I think this fixes our issue at hand http://paste.ubuntu.com/11831998/
[17:59] <balloons> elopio, I don't see an rc image on cdimage though.
[18:00] <balloons> This goes back to our conversation on u-d-f vs cdimage download
[18:00] <elopio> sergiusens: how can we test that?
[18:00] <elopio> balloons: yes, once we get the rc rsalveti will publish it on cdimage.
[18:00] <sergiusens> elopio: new image build, or mount the .img and remove the dangling link
[18:01] <balloons> elopio, I assumed as much, y
[18:02] <sergiusens> elopio: I did that, worked fine
[18:03] <sergiusens> 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] <sergiusens> elopio: but it requires a new image to get things going
[18:05] <rsalveti> sergiusens: hm, I think mvo also published the real fix
[18:05] <rsalveti> which is why he reverted the workaround
[18:06] <rsalveti> sergiusens: oh, you got it
[18:06] <rsalveti> sergiusens: just upload that fix then
[18:07] <sergiusens> rsalveti: I just did ;-)
[18:07] <rsalveti> great
[18:07] <sergiusens> rsalveti: the workaround wasn't completely reverted though
[18:07] <rsalveti> yeah
[18:07] <sergiusens> rsalveti: btw, can you dput the latest snappy trunk?
[18:07]  * sergiusens needs to get the ppu paperwork done
[18:07] <rsalveti> sergiusens: sure
[18:08] <sergiusens> rsalveti: thanks
[18:08]  * elopio learns kpartx
[18:09] <ogra_> 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] <sergiusens> ogra_: I am not aware of a branch, I just used the packaging
[18:09] <ogra_> k. sounds fine ...
[18:09] <sergiusens> ogra_: same for ubuntu-core-config
[18:09] <rsalveti> sergiusens: do we need to backport https://code.launchpad.net/~sergiusens/snappy/closeMe/+merge/263943 ?
[18:10] <ogra_> thanks !
[18:10] <sergiusens> rsalveti: nope, only required for the latest u-d-f builds to allow clean unmounts ;-)
[18:10] <rsalveti> great
[18:10] <sergiusens> ogra_: are you changing anything crazy? Since I want to trigger a new build soon to get a working image
[18:11] <ogra_> rsalveti, so seeds definitely dont support multiarch ... (i asked cjwatson) ...
[18:11] <rsalveti> ogra_: hm, that's interesting
[18:11] <rsalveti> how is that done on the desktop?
[18:11] <ogra_> sergiusens, one insane (test) thing and one easy and safe one
[18:11] <rsalveti> or libc just gets installed when required/
[18:11] <rsalveti> ?
[18:11] <sergiusens> ogra_: hmmm, then let me trigger a build before that :-)
[18:11] <ogra_> rsalveti, we dont have any images where foreign arch packages are preinstalled
[18:12] <rsalveti> ogra_: nice
[18:12] <sergiusens> ogra_: so we have a working test base and I don't need to chase my tail like a dog :-P
[18:12] <ogra_> sergiusens, well, i can do it tomorrow morning (would actually prefer to) ... but it is for RC
[18:12] <rsalveti> sergiusens: trigger an image now
[18:12] <rsalveti> build is kind of fast anyway
[18:12] <sergiusens> rsalveti: waiting for packages to publish
[18:12] <ogra_> 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] <rsalveti> ogra_: right
[18:13] <ogra_> (and indeed i have no local setup)
[18:13] <rsalveti> sergiusens: gotta love launchpad
[18:13] <sergiusens> rsalveti: did you read my latest blog entry? :-P
[18:13] <rsalveti> sergiusens: not fully yet, in my toread
[18:14] <rsalveti> new kernel landed in updates
[18:14] <rsalveti> yay
[18:22] <elopio> sergiusens: on your post I think that you are not taking into account that travis is not running trusty.
[18:22] <rsalveti> sergiusens: package was just published
[18:23] <rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.5ubuntu1
[18:23] <Saviq> 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] <ogra_> uboot you mean
[18:24] <ogra_> yes, it talks to serial only
[18:25] <ogra_> Saviq, any probs with that ?
[18:26] <ogra_> (uEnv.txt is for overrides, it could well be that uboot itself sets some HW related defaults before processing uEnv.txt)
[18:27] <sergiusens> 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] <elopio> sergiusens: what about the calls we make to ubuntu-device-flash?
[18:28] <sergiusens> elopio: that does not happen on tarmac today
[18:28] <elopio> could we backport the ppa to ... lucid I think is what they have
[18:28] <sergiusens> elopio: they have precise envs
[18:29] <sergiusens> elopio: and we don't use ppa's in our tarmac setup
[18:29] <sergiusens> elopio: nor package building
[18:29] <elopio> oh, well, that's right. No much different to our present.
[18:29] <sergiusens> elopio: but giving webhooks are instantly available, we can do a lot already
[18:30] <sergiusens> elopio: rsalveti: ogra_ I triggered a vivid image
[18:37] <rsalveti> mterry: https://code.launchpad.net/~mterry/snappy/set-sudo-15.04/+merge/263920 missing withMutex
[18:38] <rsalveti> Chipaca: https://code.launchpad.net/~chipaca/snappy/fix-1461262/+merge/263917/comments/661898
[18:38] <mterry> rsalveti, hah, whoops, run-checks failed but without a good error and I wasn't sure why, so I was going to let jenkins sort it out while I had lunch.  Looks like it did, thanks for the heads up  :)
[18:39] <rsalveti> Chipaca: oauth/oauth_test.go:25:2: cannot find package "gopkg.in/check.v1" in any of
[18:39] <rsalveti> mterry: :-)
[18:39] <rsalveti> the joy of backports
[18:43] <rsalveti> Chipaca: maybe we can just use gocheck to avoid a larger backport
[18:43] <sergiusens> it should use gocheck, yes
[18:45] <rsalveti> sergiusens: can you see why https://code.launchpad.net/~mterry/snappy/systemd-restart-15.04/+merge/263915/comments/661903 failed?
[18:45] <mterry> rsalveti, yeah that is interesting.  run-checks locally *did* pass for that one -- and it's really a tiny change
[18:46] <rsalveti> right
[18:46] <sergiusens> rsalveti: cmd/snappy/cmd_internal_unpack.go:70:6: func readUid should be readUID helpers/touch.go:39:5: exported var ErrNotAbsPath should have comment or be unexported
[18:46] <rsalveti> not related with the mr for sure
[18:46] <rsalveti> sergiusens: why failing now?
[18:46] <rsalveti> the check changed?
[18:46] <sergiusens> rsalveti: mterry update golint
[18:47] <rsalveti> right
[18:48] <Saviq> ogra_, yeah, I've changed uEnv.txt and still I get garbage on boot when I have the emon board connected
[18:48] <rsalveti> will just backport rev 520 then
[18:48] <Saviq> ogra_, the board talks on ttyAMA0
[18:48] <mterry> sergiusens, rsalveti: what's the Right way to do that in my workspace?
[18:49] <sergiusens> mterry: go get -u "the go lint package" iirc
[18:50]  * sergiusens takes a break
[18:50] <mterry> sergiusens, thanks
[18:51] <rsalveti> mterry: https://code.launchpad.net/~rsalveti/snappy/15.04-fixing-lint-errors/+merge/263956
[18:52] <kyrofa> seb128, you mentioned last week that if I was willing to get my hands dirty, I could get an Ubuntu Personal-ish image up and running?
[18:52] <mterry> rsalveti, I see those now too :)
[18:52] <sergiusens> +1
[18:53] <Saviq> ogra_, but it does seems as if it never goes to actually loading the kernel, so it might be u-boot itself is talking on tty (/me records a video)
[18:57] <ogra_> Saviq, well, whats the actual kernel cmdline you end up with after booting (regardless if with or without the thing attached)
[18:59] <Saviq> ogra_, right, checking that now
[19:02] <rsalveti> ogra_: image finished already if you want to play with livebuild
[19:02] <ogra_> rsalveti, k
[19:10] <sergiusens> rsalveti: from what I see, the image is still building...
[19:10] <rsalveti> sergiusens: just not yet fully imported
[19:10] <rsalveti> sergiusens: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/
[19:13] <Saviq> ogra_, yeah, it boots the right cmdline, but it never goes past u-boot when the thing's connected https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d#
[19:13]  * Saviq needs to find out if u-boot talks ttyAMA0 for some reason
[19:13] <Saviq> biab
[19:36] <ogra_> rsalveti, bah ... https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7625955 ...
[19:36] <ogra_> "Start in 5 hours "
[19:36] <rsalveti> ogra_: that's arm64
[19:36] <rsalveti> which we don't support
[19:36] <rsalveti> you can cancel it
[19:36] <ogra_> oh, will it still publish ?
[19:37] <rsalveti> ogra_: or just let it there, lp will publish the other packages
[19:37] <rsalveti> we don't have proposed for ppas :-)
[19:37] <ogra_> oh, ok
[19:37] <ogra_> (i thought it was more like the phone overlay PPA)
[19:37]  * ogra_ kicks a build then
[19:39] <ogra_> rsalveti, hmm, infinity just told me ubuntu-fan v1 isnt suitable for seeding, we should wait for v3 (which btw wont depend on dnsmasq)
[19:39] <ogra_> so i'll unseed it again :P
[19:40] <rsalveti> ogra_: oh, alright :-)
[19:40] <rsalveti> we still need the kernel sru to be in place anyway
[19:40]  * ogra_ sighs ... this is getting ebarassing 
[19:40] <ogra_> most awkward seed changelog ... in -> out -> in -> out ..
[19:41] <rsalveti> hahah
[19:42] <sergiusens> ogra_: seeding in rolling should be fine though
[19:43] <sergiusens> rsalveti: https://code.launchpad.net/~sergiusens/snappy/originsOrNamespaceWhatever/+merge/263960
[19:43] <ogra_> damned !
[19:43] <ogra_> i just triggered a vivid phone build
[19:43] <ogra_> sigh
[19:44] <rsalveti> ogra_: hahah
[19:44] <ogra_> and do you know why ?
[19:44] <sergiusens> or Chipaca: https://code.launchpad.net/~sergiusens/snappy/originsOrNamespaceWhatever/+merge/263960
[19:44] <ogra_> because i couldnt mark the whole line at the size the terminal window was ... the overlay scrollbar didnt let me reach the last letter ... so i maximized and ended up in the wrong line
[19:45] <ogra_> yay design
[19:45] <ogra_> hmpf
[19:45] <ogra_> and snappy cant build due to a lockfile
[19:46] <ogra_> which i assume comes from the stalled arm64 build of sergiusens image (which i just cancelled)
[19:46] <ogra_> damn
[19:47] <sergiusens> ogra_: hey, don't go around pointing fingers at me :-P
[19:47] <ogra_> sergiusens, alll your fault that the arm64 builders are so slow !!!
[19:48] <ogra_> aha, just took a moment
[19:52] <ogra_> ok, that didnt go so well
[19:52] <ogra_> E: Unable to locate package libc6
[19:53] <ogra_> so just add_package wont work either ...
[19:57] <bschaefer> Hello, just dd'd the ras pi 2 onto an SD and everything seems to be working except one issue
[19:57] <bschaefer> "Net initialization skipped"
[19:57] <bschaefer> and no ip or network at all on the image :(
[19:59] <sergiusens> Chipaca or rsalveti: https://code.launchpad.net/~sergiusens/snappy/seccompError/+merge/263964
[20:02] <sergiusens> rsalveti: not sure I can get this one done by today https://bugs.launchpad.net/snappy/+bug/1450169 I need to leave for a bit
[20:03] <rsalveti> sergiusens: are you going to be around later today?
[20:03] <rsalveti> I'll be off for a few as well, but back in a few hours
[20:03] <rsalveti> and going to trigger a new image
[20:04] <ogra_> rsalveti, so the multiarch doesnt work (and a meta package wont help)
[20:04] <ogra_> it doesnt find any i386 packages at all during build
[20:04] <ogra_> i'll roll back the libc part but keep gdbserver in ...
[20:04] <ogra_> (and take a look tomorrow)
[20:14] <balloons> elopio, so i've setup https://wiki.ubuntu.com/Snappy/OpenHouses/20150707 and tweaked https://wiki.ubuntu.com/Snappy/OpenHouses/. Going to work a little on the form. Let me know if there's anything els
[20:14] <sergiusens> rsalveti: in 4hours or so, I have a dentist issue coincidentally :-P
[20:14] <elopio> balloons: thanks.
[20:14] <sergiusens> I broke a tooth last night :-P
[20:14] <sergiusens> eating popcorn...
[20:15] <elopio> sergiusens: ...rioting after the game.
[20:15] <ogra_> sergiusens, did you pick the one with extra butter and concrete ?
[20:59] <rsalveti> sergiusens: eating a popcorn?
[21:03] <balloons> elopio, http://bit.ly/1KHQZF6 is the form
[21:04] <elopio> balloons: +1. Thanks.
[21:16] <kgunn> https://pastebin.canonical.com/134686/
[21:17] <kgunn> sergiusens: wonder if you might know...this was working last thurs, was just trying and got that error ^
[21:17] <kgunn> it actually created an image, but it just stuck at "booting from disk"
[21:19] <elopio> kgunn: if you are on vivid, you can get the fix of that using the tools-proposed ppa.
[21:19] <elopio> kgunn: if you are on wily, just upgrade.
[21:21] <kgunn> ta
[21:21] <kgunn> needed to upgrade
[21:23]  * kgunn considers probably should just move to wily
[21:24] <jdstrand> Saviq: hey, did you get an answer to emonhub?
[21:27] <jdstrand> Saviq: the problem is that the review tools are expecting snappy-systemd in the click compatibility manifest and a corresponding meta/emonhub.snappy-systemd in the snap produced by snappy build
[21:27] <jdstrand> Saviq: how did you generate the snap? snappy build? what version of snappy?
[21:39] <jdstrand> Saviq: I see that you uploaded to the store. I'll comment there
[21:44] <jdstrand> sergiusens: fyi, I left feedback in https://myapps.developer.ubuntu.com/dev/click-apps/2954/feedback/
[21:45] <jdstrand> sergiusens: it looks like snappy perhaps dropped "snappy-systemd" from the hooks db in the click compatibility manifest
[21:46] <jdstrand> sergiusens: either it is a bug in snappy or a bug in the review tools (can we please have the review tools run as part of the go build/check/whatever or the self-tests?)
[21:47] <jdstrand> Chipaca: fyi, I came across that ^. I saw in backscroll from days ago about re-enabling the review tools. looks like an incompatible change rolled in recently
[21:49] <elopio> jdstrand: we have just added a test for snappy build that does some simple checks.
[21:49] <elopio> jdstrand: could you please report a bug, or make a card, or explain here how to reproduce that bug so we can automate it?
[21:49] <elopio> should be easy.
[21:49] <jdstrand> elopio: I think there is already a card for it
[21:49] <jdstrand> let me see if I can find it
[21:50] <jdstrand> I can't seem to find it
[21:51] <jdstrand> it keeps coming up in email threads
[21:51] <elopio> jdstrand: https://trello.com/c/Gp9gtKiu/59-self-tests-for-snappy-build
[21:51] <elopio> I see your comment in there.
[21:52] <elopio> we added tests for one correct snap and two simple errors.
[21:52] <elopio> I'll make another card to extend the suite.
[21:52] <jdstrand> elopio: you are doing 'click-review /path/to/snap'?
[21:53] <elopio> jdstrand: no, just snappy build.
[21:53] <jdstrand> elopio: ok, so right now snappy build disabled the click-review run
[21:53] <elopio> I saw the code for click-review in the build command commented out.
[21:54] <jdstrand> elopio: right. this was because the review tools were out of date cause the yaml was changing so fast and the review tools weren't updated in lock step
[21:55] <jdstrand> elopio: so, I got them all up to date, but it looks like something changed in snappy again without a corresponding mp for the review tools
[21:55] <elopio> I see. So update, uncomment, and add test.
[21:56] <jdstrand> elopio: I'm happy to do the change in the review tools this time so that they are on good footing, but I want to make sure I understand the change and where it landed
[21:57] <jdstrand> depending on the test, a few simple tests aren't going to be enough though
[21:57] <elopio> jdstrand: for that part, lets wait for sergiusens.
[21:57] <jdstrand> as it happens, if the simple yaml had a 'services' definition, it would have this time
[21:57] <elopio> he had a fight with some chilean popcorn ;)
[21:58] <jdstrand> but we are going to want build tests for all yaml
[21:58] <jdstrand> if we want to be sure to avoid this in the future
[21:59] <elopio> jdstrand: we should probably add some basic tests in the snappy branch, an extensive suite in click-review, and a way to trigger the click review tests when snappy is updated.
[21:59] <jdstrand> but sure, I'll wait for sergiusens
[21:59] <jdstrand> elopio: the review tools has extensive tests itself
[21:59] <jdstrand> elopio: the problem is what is being fed to it
[22:00] <jdstrand> if snappy build starts outputing something new or different...
[22:00] <jdstrand> it seems the right place is to have a collection of simple but exhaustive snaps that click-review can iterate over
[22:01] <jdstrand> personally, I think that should be in snappy itself or maybe the self tests
[22:01] <jdstrand> well, probably not the self tests, those run on the image
[22:05] <elopio> jdstrand: yes, we currently are doing the builds on the image. Is that wrong?
[22:05] <elopio> seemed a lot more simple than to split the suite into running some in the testbed and some in the host.
[22:18] <jdstrand> elopio: it isn't wrong per se, but I didn't think the review tools would be available on the image (they are python with various python deps)
[22:19] <elopio> jdstrand: it works now. I suppose it will break soon.
[22:19] <jdstrand> elopio: yes, as soon as the review tools are reenabled
[22:20] <elopio> we are thinking about containers inside the testbed for these cases to make it easier to handle the adt-run calls. We'll have a prototype soon.
[22:20] <jdstrand> that should be fine. install tests in a container won't, but build, sure
[22:21] <elopio> a container that can do builds. We add a bunch of yamls and iterate over them. Shouldn't slow the selftests a lot.
[22:21] <elopio> well, a lot more. They are already slow.
[22:22] <rsalveti> comfy should help with that
[22:22] <rsalveti> once we get the container in place
[22:22] <rsalveti> for usual builds and such
[22:22] <rsalveti> the same container will also be the bed for snapcraft, so should be good
[22:23] <elopio> the future will solve all our present problems :)
[22:23] <rsalveti> that's true, but comfy should be around the corner
[22:23] <rsalveti> just waiting lool to return from his vacation
[22:24] <elopio> now build in the container and install out of the container, I don't know how to handle that case. Federico will probably come with a clever solution.
[22:27] <jcastro> is there a generic snappy x86 image that would work on like a NUC or old laptop?
[22:34] <elopio> jcastro:  I see you can do:
[22:34] <elopio> sudo ubuntu-device-flash --verbose core rolling --channel edge --oem generic-i386 -o snappy.img
[22:34] <elopio> but I haven't tried that.
[22:41] <rsalveti> mterry: https://code.launchpad.net/~mterry/snapcraft/debian-packaging/+merge/263937/comments/661944
[22:43] <mterry> rsalveti, huh...  i depend on python3, would have expected that to include python3-minimal.  I didn't build in pbuilder though, oddly enough.  will make I pass in that
[22:48] <rsalveti> yeah, it's a bit weird
[22:49] <mterry> rsalveti, oh weird, dh_auto_clean tries to do a python2 thing by default (sigh, the world is still unready for py3-only stuff)
[22:53] <Saviq> jdstrand, thanks, no, didn't get an answer et
[22:53] <Saviq> +y
[22:55] <elopio> I'm going to take a break.
[22:55] <elopio> rsalveti: let me know if you need me to do something for the RC, and I'll get to it when I get back.
[22:57] <rsalveti> elopio: sure, just started a new image build, which should be close to what we want
[22:57] <rsalveti> just missing one more mr from sergiusens and the other change from ogra
[22:57] <rsalveti> but we'll see if we can get to that tomorrow
[22:57] <rsalveti> going to be off for a few as well, time to grab some dinner
[22:57] <rsalveti> be back later
[23:04] <Saviq> jdstrand, so if I understand correctly, this basically means that something in the build process failed?