| === EllieGoulding is now known as plop_its_ellie | ||
| === user is now known as Guest10540 | ||
| 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. | 06:29 |
|---|---|---|
| dholbach | good morning | 07:00 |
| fgimenez | good morning | 07:03 |
| === chihchun_afk is now known as chihchun | ||
| sturmflut2 | fgimenez: o/ | 07:05 |
| davidcalle | Morning o/ | 07:14 |
| === chihchun is now known as chihchun_afk | ||
| === bigcat is now known as bigcat[brb] | ||
| === bigcat[brb] is now known as bigcat | ||
| JamesTait | Good morning all; happy Monday, and happy Take Your Webmaster To Lunch Day! 😃 | 09:17 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | JamesTait: Just realized: I'm my own webmaster! | 09:24 |
| * Chipaca will take himself to lunch | 09:24 | |
| JamesTait | Chipaca, me too. :( | 09:24 |
| Chipaca | JamesTait: :(? \o/! | 09:25 |
| 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:27 |
| JamesTait | Chipaca, also, happy Fried Chicken Day! Enjoy your solitary trip to KFC. 😉 | 09:29 |
| Chipaca | JamesTait: was about to point out i had no kfc close enough, but i was wrong! | 09:30 |
| 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:31 |
| JamesTait | Chipaca, so... happy fry your own chicken day? | 09:40 |
| 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:41 |
| 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:42 |
| Chipaca | JamesTait: are you not in .uy? | 09:45 |
| 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:46 |
| JamesTait | I don't think it's many though, IIUC it's at Martin's place. | 09:47 |
| Chipaca | JamesTait: here, one for you: http://www.whitevinyldesign.com/solarbeat/ | 10:44 |
| JamesTait | Chipaca, that is beautiful. ☺ | 10:47 |
| vmayoral|pc | greetings | 10:50 |
| 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 | 10:51 |
| === chihchun is now known as chihchun_afk | ||
| rsalveti | ogra_: sergiusens: for https://bugs.launchpad.net/snappy/+bug/1429749, what would be the proper fix? | 14:01 |
| ubottu | Ubuntu bug 1429749 in Snappy trunk "Ubuntu Core updated but not switch to new version after reboot on Raspberry Pi 2" [Undecided,New] | 14:01 |
| 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:02 |
| 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:03 |
| 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:18 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| ogra_ | even if it would be supported, the RPi uboot cant handle it currently | 14:30 |
| ogra_ | (on another sidenote :) ) | 14:30 |
| elopio | good morning | 14:40 |
| elopio | they are fixing the plumbing in my apartment today, so I might be on and off during the morning. | 14:41 |
| elopio | fgimenez: have you seen any errors while doing the failover updates? | 14:42 |
| rsalveti | mterry: ogra_: sergiusens: about bug 1444049, should we just include libc6:i386? | 14:43 |
| ubottu | bug 1444049 in Snappy trunk "Shipping libc6:i386 in the amd64 images would be useful" [Undecided,New] https://launchpad.net/bugs/1444049 | 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:43 |
| 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:44 |
| 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 |
| ubottu | Ubuntu bug 1456340 in Snappy trunk "Add gdbserver to snappy image" [Undecided,New] | 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| ubottu | Ubuntu bug 1461070 in Snappy 15.04 "Running set active without sudo gives lower level error than it should" [Undecided,New] | 14:52 |
| mterry | rsalveti, ok | 14:54 |
| rsalveti | mterry: https://bugs.launchpad.net/snappy/+bug/1461917 as well | 14:54 |
| ubottu | Ubuntu bug 1461917 in Snappy 15.04 "snappy app services should auto restart" [Undecided,Triaged] | 14:54 |
| 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:56 |
| 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:57 |
| elopio | balloons: rsalveti and the team are backporting things to the 15.04 branch. Once they are backported, we will have an RC. | 14:58 |
| balloons | elopio, does install system-status.victor work for you? (sudo snappy install system-status.victor) | 15:02 |
| elopio | balloons: I can give it a try in ~10 minutes. | 15:03 |
| balloons | elopio, ack, tyu | 15:03 |
| ogra_ | Chipaca, so no console= should be the default | 15:29 |
| ogra_ | Chipaca, but we need a way to define one console= option for images that should default to serial | 15:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| * 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:34 |
| ogra_ | personal specifically might want to use a boot splash ... and would need a graphical soncole device set | 15:35 |
| ogra_ | *console | 15:35 |
| 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:36 |
| Chipaca | rsalveti: sergiusens: https://code.launchpad.net/~chipaca/snappy/fix-1461262/+merge/263917 | 15:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| elopio | balloons: package with namespace not supported? | 15:41 |
| Chipaca | bregma: how would the network devices be created traditionally? | 15:41 |
| bregma | Chipaca, through the equivalent of a sudo operation, I imagine | 15:42 |
| 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:43 |
| balloons | elopio, yea.. https://bugs.launchpad.net/snappy/+bug/1466674. | 15:45 |
| ubottu | Ubuntu bug 1466674 in Snappy "Snappy store contains packages with namespace" [Undecided,Incomplete] | 15:45 |
| elopio | balloons: I don't fully understand what nessita is asking in there. | 15:46 |
| 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:47 |
| elopio | let me see what install does. | 15:48 |
| 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:49 | |
| 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:50 |
| 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:51 |
| 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:52 |
| Chipaca | bregma: i might be wrong, but i think having an unprivileged snap do privileged things is not currently possible | 15:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| ogra_ | i thopught it is only used to fire up lxc containers | 15:59 |
| elopio | balloons: http://bazaar.launchpad.net/~vthompson/+junk/system-status/view/head:/meta/package.yaml | 16:00 |
| elopio | http://paste.ubuntu.com/11831452/ | 16:01 |
| balloons | looks fine to me | 16:01 |
| elopio | balloons: that's what's needed ^ | 16:01 |
| 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:02 |
| 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:04 |
| balloons | whoa.. "snappy autopilot triggered a reboot to boot into an up to date system" | 16:08 |
| elopio | balloons: autopilot is following you! | 16:14 |
| balloons | scary! | 16:15 |
| Chipaca | sergiusens: you around? | 16:21 |
| sergiusens | Chipaca: yes | 16:37 |
| Chipaca | sergiusens: good. | 16:40 |
| Chipaca | sergiusens: wondering why 'snappy search' would find a package, but install wouldn't | 16:41 |
| Chipaca | sounds all very weird to me :) | 16:41 |
| sergiusens | Chipaca: search does partial matching while install requires an exact match? | 16:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| * 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") | 16:49 |
| sergiusens | elopio: Chipaca if you build images for 15.04/edge do they work out? | 17:07 |
| 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:08 |
| sergiusens | elopio: seem to missing a systemd service here | 17:09 |
| elopio | udf'ing | 17:10 |
| 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:15 |
| nessita | we will not unpublish such packages since they are still valid, as far as the store is concerned | 17:16 |
| Chipaca | nessita: which package? | 17:17 |
| nessita | Chipaca, system-status.victor | 17:17 |
| nessita | Chipaca, https://search.apps.ubuntu.com/api/v1/package/system-status.victor | 17:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| elopio | sergiusens: yes, it prints lots of errors. Not sure which is the first. | 17:23 |
| nessita | sergiusens, last published version is 1.0.3 and was automatically approved by the scripts with no errors and only 1 warning | 17:24 |
| 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:26 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| sergiusens | and to be honest, the system-status snap might as well be an app and not a framework ;-) | 17:35 |
| 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:38 |
| balloons | sergiusens, beuno nessita thanks for getting to the root of this | 17:39 |
| sergiusens | elopio: I think that triggers the issue ^ | 17:39 |
| elopio | if we want the rc tomorrow, maybe we should revert. | 17:45 |
| 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:48 |
| balloons | elopio, afaik, no. I just need to review the google form again | 17:50 |
| 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:51 |
| 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:52 |
| balloons | elopio, ok, I'll update it again | 17:56 |
| sergiusens | elopio: rsalveti I think this fixes our issue at hand http://paste.ubuntu.com/11831998/ | 17:58 |
| balloons | elopio, I don't see an rc image on cdimage though. | 17:59 |
| 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:00 |
| balloons | elopio, I assumed as much, y | 18:01 |
| sergiusens | elopio: I did that, worked fine | 18:02 |
| 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:03 |
| rsalveti | sergiusens: hm, I think mvo also published the real fix | 18:05 |
| rsalveti | which is why he reverted the workaround | 18:05 |
| rsalveti | sergiusens: oh, you got it | 18:06 |
| rsalveti | sergiusens: just upload that fix then | 18:06 |
| 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:07 |
| sergiusens | rsalveti: thanks | 18:08 |
| * elopio learns kpartx | 18:08 | |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| rsalveti | new kernel landed in updates | 18:14 |
| rsalveti | yay | 18:14 |
| 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:22 |
| 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:23 |
| ogra_ | uboot you mean | 18:24 |
| ogra_ | yes, it talks to serial only | 18:24 |
| ogra_ | Saviq, any probs with that ? | 18:25 |
| ogra_ | (uEnv.txt is for overrides, it could well be that uboot itself sets some HW related defaults before processing uEnv.txt) | 18:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| sergiusens | elopio: rsalveti: ogra_ I triggered a vivid image | 18:30 |
| rsalveti | mterry: https://code.launchpad.net/~mterry/snappy/set-sudo-15.04/+merge/263920 missing withMutex | 18:37 |
| 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:38 |
| 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:39 |
| rsalveti | Chipaca: maybe we can just use gocheck to avoid a larger backport | 18:43 |
| sergiusens | it should use gocheck, yes | 18:43 |
| 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:45 |
| 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:46 |
| rsalveti | right | 18:47 |
| 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:48 |
| sergiusens | mterry: go get -u "the go lint package" iirc | 18:49 |
| * sergiusens takes a break | 18:50 | |
| mterry | sergiusens, thanks | 18:50 |
| rsalveti | mterry: https://code.launchpad.net/~rsalveti/snappy/15.04-fixing-lint-errors/+merge/263956 | 18:51 |
| 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:52 |
| 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:53 |
| ogra_ | Saviq, well, whats the actual kernel cmdline you end up with after booting (regardless if with or without the thing attached) | 18:57 |
| Saviq | ogra_, right, checking that now | 18:59 |
| rsalveti | ogra_: image finished already if you want to play with livebuild | 19:02 |
| ogra_ | rsalveti, k | 19:02 |
| 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:10 |
| 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:13 |
| 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:36 |
| 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:37 | |
| 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:39 |
| 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:40 |
| rsalveti | hahah | 19:41 |
| sergiusens | ogra_: seeding in rolling should be fine though | 19:42 |
| 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:43 |
| 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:44 |
| ogra_ | yay design | 19:45 |
| ogra_ | hmpf | 19:45 |
| ogra_ | and snappy cant build due to a lockfile | 19:45 |
| ogra_ | which i assume comes from the stalled arm64 build of sergiusens image (which i just cancelled) | 19:46 |
| ogra_ | damn | 19:46 |
| 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:47 |
| ogra_ | aha, just took a moment | 19:48 |
| ogra_ | ok, that didnt go so well | 19:52 |
| ogra_ | E: Unable to locate package libc6 | 19:52 |
| ogra_ | so just add_package wont work either ... | 19:53 |
| 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:57 |
| sergiusens | Chipaca or rsalveti: https://code.launchpad.net/~sergiusens/snappy/seccompError/+merge/263964 | 19:59 |
| 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:02 |
| ubottu | Ubuntu bug 1450169 in Snappy 15.04 "snappy update downloads non-namespaced package when fork is installed" [High,Triaged] | 20:02 |
| 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:03 |
| 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:04 |
| 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:14 |
| elopio | sergiusens: ...rioting after the game. | 20:15 |
| ogra_ | sergiusens, did you pick the one with extra butter and concrete ? | 20:15 |
| rsalveti | sergiusens: eating a popcorn? | 20:59 |
| balloons | elopio, http://bit.ly/1KHQZF6 is the form | 21:03 |
| elopio | balloons: +1. Thanks. | 21:04 |
| kgunn | https://pastebin.canonical.com/134686/ | 21:16 |
| 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:17 |
| 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:19 |
| kgunn | ta | 21:21 |
| kgunn | needed to upgrade | 21:21 |
| * kgunn considers probably should just move to wily | 21:23 | |
| jdstrand | Saviq: hey, did you get an answer to emonhub? | 21:24 |
| 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:27 |
| jdstrand | Saviq: I see that you uploaded to the store. I'll comment there | 21:39 |
| jdstrand | sergiusens: fyi, I left feedback in https://myapps.developer.ubuntu.com/dev/click-apps/2954/feedback/ | 21:44 |
| jdstrand | sergiusens: it looks like snappy perhaps dropped "snappy-systemd" from the hooks db in the click compatibility manifest | 21:45 |
| 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:46 |
| 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:47 |
| 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:49 |
| jdstrand | I can't seem to find it | 21:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 21:59 |
| 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:00 |
| 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:01 |
| 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:05 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| jcastro | is there a generic snappy x86 image that would work on like a NUC or old laptop? | 22:27 |
| 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:34 |
| rsalveti | mterry: https://code.launchpad.net/~mterry/snapcraft/debian-packaging/+merge/263937/comments/661944 | 22:41 |
| 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:43 |
| rsalveti | yeah, it's a bit weird | 22:48 |
| 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:49 |
| Saviq | jdstrand, thanks, no, didn't get an answer et | 22:53 |
| Saviq | +y | 22:53 |
| 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:55 |
| 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 | 22:57 |
| Saviq | jdstrand, so if I understand correctly, this basically means that something in the build process failed? | 23:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!