[00:32] jdstrand: ah, fwiw the only reason we exec snappy is to snappy unpack === utlemming_away is now known as utlemming [02:38] sergiusens: will release snappy and goget-ubuntu-touch [02:51] rsalveti: ok, I'm preparing a nice u-d-f branch that makes things nicer [02:52] sergiusens: oh, great then [02:52] sergiusens: the other branch is already merged, and pushed ubuntu-snappy already [02:53] should hit proposed in a few, then an upload for goget-ubuntu-touch should do it [02:53] then just need to copy it over tools-proposed, and test it again [03:53] rsalveti: did you create the next milestone already? :-P [03:58] rsalveti: hmm, the u-d-f change wasn't needed :P [03:59] rsalveti: this branch would allow to preprovision images with frameworks that provide policies https://code.launchpad.net/~sergiusens/snappy/policyRoot/+merge/261802 [03:59] utlemming: btw ^ [03:59] such as docker [06:20] hey snappy world [06:20] slangasek, hey, just as a fyi, desktop-next built on amd64 now ;-) [06:22] seb128: yay, does it also boots ;) [06:25] mvo, dunno, I still didn't manage to transform those tarballs in an image locally [06:25] the reply I got is "get the build on a s-i channel and use u-d-f" [06:25] and its not yet imported info s-i? [06:26] it was not yesterday [06:26] unsure if that happened during the night [06:26] somebody needs to set that up [06:26] unsure who the somebody is, slangasek? [06:29] seb128: does it have a config already? [06:29] looks like it [06:29] [channel_ubuntu-personal/rolling/edge] [06:30] seb128: looks like you have a image [06:31] Well, hmm. The latest snappy rpi image comes pre-loaded with ogra_ 's ssh key in .ssh/authorized_keys. [06:32] mvo, oh, nice ;-) [06:32] mvo, going to try that in a bit [06:32] seb128: I guess the next step is that you get u-d-f support for personal, it derrives the url from the product name (core) so right now its not working [06:32] oh? [06:32] seb128: or do you have a commandline that works? [06:32] I see [06:32] I don't [06:32] * mvo i smaybe missing something [06:32] I didn't try u-d-f yet [06:32] I didn't even know the channel was configured [06:33] seb128: slangasek added it yesterday (according to the bzr logs). so say a big thank you to him :) [06:34] slangasek, thanks ;-) [06:34] * seb128 is going to pay some beers at the next conference [06:34] mvo, thanks as well ;-) [06:34] mvo, who do I pay beers to for the u-d-f changes now? ;-) [06:38] seb128: sergiusens is the man! let me see if I can add something for you to unblock you [06:43] mvo, thanks [06:47] seb128: you can try http://paste.ubuntu.com/11700595/ first line is the command, second the diff to use for u-d-f [06:48] mvo, danke [06:57] seb128: heh, u-d-f needs to create bigger partitions for you now [06:59] mvo, those are not dynamic to accomodate the tarball? [07:01] good morning [07:02] seb128: no, hardcoded afaik [07:02] fgimenez: hey, good morning [07:02] mvo, do you know where? did you try to generate a personnal image? did it fail because of that? [07:03] hi mvo! [07:05] Good morning o/ [07:07] ogra_, hello, still want to wait for the raspi2 to become officially supported to updated the dev site? The "I expect this URL to persist for a while" from your ml email makes me think we should do it now. [07:07] * davidcalle grabs coffee, brb [07:09] I have a lot of learning to do to figure out how rpi2+snappy works. [07:11] to update* [07:11] seb128: so system-{a,b} are just 1gb big, how much do you need? 4? [07:11] With snappy and systemd and no apt-get and all the other new stuff, it feels like a whole different operating system. [07:11] ToyKeeper: yeah, it is [07:13] mvo, I'm unsure, is it compressed or uncompressed? it should be pretty similar to our standard iso which is a bit over 1G, I'm unsure how much is the installed system nowadys but 4G should be enough [07:13] Speaking of partitions, one of the things on my todo list is change partition sizes to use the whole card instead of just 4GB. [07:15] But not tonight. Tonight, bed. [07:16] seb128: ok, you get a updated debdiff in a sec [07:16] mvo, thanks ;-) [07:16] ToyKeeper, night [07:16] ToyKeeper: if you use u-d-f you set the size at image creation time [07:17] seb128: but only for the writable partitions, the system-a/b are hardcoded [07:17] mvo, ? [07:17] mvo, was that second line for ToyKeeper as well? [07:17] seb128: for you because you need partition size changes :) http://paste.ubuntu.com/11700710/ should do it [07:17] seb128: sorry, too little context I guess [07:18] mvo, ? [07:18] mvo, trying that change, thanks [07:18] mvo, " seb128: but only for the writable partitions, the system-a/b are hardcoded" [07:18] not sure what that meant [07:18] anyway, I understand your code change, so trying that ;-) [07:19] seb128: sorry, too little context. I was refering to that ubuntu-device-flash has a --size option. but that it won't help you because of the hardcoding of the sizes of a/b [07:20] oh, right [07:20] mvo, I though it was a reply to ToyKeeper "one of the things on my todo list is change partition sizes to use the whole card instead of just 4GB." [07:21] * mvo nods [07:21] the snaps are installed in the writable one right? [07:22] seb128: yes [07:28] mvo, u-d-f ongoing, it's a bit weird, it downloads a 78M file and a 456M one, those doesn't match the generated tarballs from launchpad [07:28] but let's see [07:28] maybe it's normal and I'm having wrong assumptions there [07:28] seb128: might be different compression (xz vs gz)? the 78mb is the kernel [07:29] mvo, kernel = device tarball? [07:30] mvo, it's 148M on https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29455 [07:30] hum [07:30] mvo, did you try that command? [07:30] "issue while mapping partitions: more partitions then expected while creating loop mapping [07:30] " [07:30] it bails out on that here [07:35] seb128: meh, I got that now too [07:35] seb128: not sure what to do, maybe we need sergiusens for the rescue this is not really a area I worked in much [07:36] seb128: but could also be something else, I just set it back to 1024 and get the same error, maybe it got confused because of the earlier error? [07:36] mvo, ok, no worry, that can wait a few hours [07:36] mvo, or maybe something in the channel is wrongly set [07:36] ? [07:36] ubuntu-core doesn't have a device tarball [07:36] ubuntu-desktop-next has [07:36] could be [07:36] so maybe they have different configs and need another u-d-f handling [07:36] mvo, let's wait for sergiusens [07:36] 150mb vs 78 is indeed a huge diffrence [07:37] thanks for trying to help ;-) [07:37] yw, sorry that it did not work out [07:37] no worry [08:01] davidcalle, that was my plan ... i have some meetings til noon though [08:06] ogra_: did you see what ToyKeeper wrote earlier? [08:07] mvo, its a fake key ... i explicitly generated it and moved my real one away ... u-d-f --developer-mode requires it [08:07] (it refuses to roll the image if there is no key) [08:09] ogra_, np, to update the page, I just need to know if the first udf snippet (the one not using the OEM .snap) is still relevant and what should replace it. (https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2). I think I can figure out the rest with your README and the current text. [08:09] ogra_: heh, nice. is it a actual key or a string like "garrrrr, kthxbye")? [08:09] mvo, i wasnt sure if it checks for validity so it is actually a key :) [08:09] else i would just have touched the file ... will try that for the next build :) [08:10] (it is quite an annoying process btw ... once you moved a new key in place half the desktop gets confused because gnome-keyring-daemon caches the wrong one) [08:12] ogra_: woah [08:13] ogra_: I guess some people will be unhappy if it looks like a valid key because they have no way of knowing that there exists on maching key on your side :/ [08:21] mvo, well, ppisati has a new kernel binary, there is the issue witjh the serial number on cmdline to get a fixed MAC ... i'll have to re-roll anyway soon i guess [08:21] i'll try the touched file then [08:21] nice [08:21] thanks! [08:23] Hello, I haven't tried yet but can you say is it possible in amd64/i386 stable images possible to configure and custom grub menus without loosing the settings after ubuntu core updates? [08:26] lol, why do people always ask the easy questions :) [08:27] mvo, i think the above is a very interesting question ... will snappy personal support dual booting (which means we need a grub menu) ? [08:30] there is only etc/grub.d/09_snappy. what did you mean by snappy personal ? is it some other than https://developer.ubuntu.com/en/snappy/ ? [08:31] yes, the desktop version [08:31] or the converged version ... [08:31] vsuojanen: its not straightforward right now, what use-case do you see here? [08:31] ... however you want to call it :) [08:31] ogra_: *uff* we want to get rid of update-grub soon [08:32] mvo, well, for a desktop install i would expect people to still have dual boot here and there [08:32] or rather "to want to have" ... :) [08:32] ogra_: right, I see the need, I just have no idea right now what to do [08:33] ogra_: well, there are various ways :) need to think about this, but I really really want our grub to be dramatically simpler [08:33] why are we getting rid of update-grub instead of making it get out of our way ? [08:33] coreos support pxe and ipxe so that you can netboot and load your rootfs with root= separately. [08:34] vsuojanen, but without using the snappy initrd you wont get the snappy filesystem setup at all [08:35] (you need to make sure thats supplied by your PXE setup ... and even then it will look for partition labels which you would need to hack up inside the initrd) [08:36] ogra_: it adds (lots) of complexity we don't need. we know exactly what kernels are on the system and where to find them. we can remove ~500 lines of shell to detect labels/parittions/kernels we also can make the mounting much simpler, right now we chroot into the "other" parition and bind-mount back the original one because the system needs to see them both [08:36] lots of complexity here that will come and bite us with bugs === erkules_ is now known as erkules [08:37] yeah [08:37] ogra_: but other OSes is something we need to think hard about [08:37] so snappy is both kernel (with initrd) and rootfs ? [08:37] yes [08:38] well, a readonly rootfs [08:38] apps are there in the persistent partition [08:38] and a writable partition where the files live you need writable on a system [08:39] and in fact it is two readonly rootfs'es if you want the rollback support [08:43] thanks ogra_ mvo === devil is now known as Guest56205 [08:50] hi === Guest56205 is now known as devil_ [08:50] * zyga goes to figure out what's wrong with https://bugs.launchpad.net/snappy/+bug/1464275 [08:50] Ubuntu bug 1464275 in Snappy "Unable to boot beagle bone black from prebuilt image #3" [Undecided,New] [08:51] it is funny that only you seem to hit it [08:53] ogra_: next sd card, verified everything [08:53] ogra_: and previous image ran [08:53] ogra_: magic [08:55] Good morning all; happy Friday, and happy Peanut Butter Cookie Day! 😃 [08:56] ogra_: is this correct based on your knowledge https://bugs.launchpad.net/snappy/+bug/1464275/comments/6 [08:56] Ubuntu bug 1464275 in Snappy "Unable to boot beagle bone black from prebuilt image #3" [Undecided,New] [08:57] ogra_: the external sd card is mmc 0, the boot partition (fat) is 1 [09:02] ogra_: where do bootpart and loadaddr come from, are they hardwired into uboot? [09:03] usually from uEnv.txt [09:03] ogra_: well, the uEnv.txt I have is just two lines [09:03] # where to load initrd [09:03] initrd_addr=0x88080000 [09:03] # load Snappy environment and call into Snappy boot after processing this file [09:03] uenvcmd=load mmc ${bootpart} ${loadaddr} snappy-system.txt; env import -t $loadaddr $filesize; run snappy_boot [09:03] not sure if the BBB image ships a uboot.env file [09:03] (+ comments) [09:03] nope [09:03] just uEnv.txt and snappy-system.txt [09:03] at least in the image I've got [09:04] * zyga really really wants someone to try to reproduce that [09:04] hmm, does anyone else have issues reaching people.canonical.com ? [09:04] zyga, then it just uses the defaults from u-boot [09:08] hrm, seems my VPN is screwed up === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [09:13] ogra_: oh [09:14] ogra_, I cannot reach canonical's irc [09:14] yep, same here [09:15] and the VPN is dead too [09:15] yay, friday :P [09:16] ogra_: I figured it out [09:16] ogra_: I need to check if it works just because everyone that ties still has debian on emmc [09:16] ogra_: but the config is borked [09:16] ogra_: the defaults point to emmc [09:16] ogra_: and there's nothing there [09:16] fgimenez: hey, do you have a beagle bone black? [09:16] there should be an SPL [09:17] ogra_: can it insert variables into uboot? [09:17] no, it doesnt, it will just switch to SD [09:17] but you need something there to actually boot [09:17] ogra_: the problem seems to be that on the image we ship, bootpart is 1:2 [09:17] that's eMMC, partition 2 [09:18] and nothing in uEnv.txt changes that [09:18] * ogra_ wonders if you have a different model [09:18] ogra_: different model of what? uboot from the sd card? [09:18] BBB [09:18] zyga, yes, but no serial cable, yesterday version 3 worked for me, do you want me to try? [09:19] the BBB is open HW, anyone can make and sell them ... we usually all have element14 devices [09:19] there might be minor differences when manufactured by another manufacturer [09:31] (sorry, system crash) [09:32] ogra_: I have A5A written on the side, [09:32] ogra_: trying to look at elinux.org but it seems down [09:32] (looking for changelog) [09:32] ogra_: both of my beagles are from element 14 [09:33] well, then we should all be on the same HW [09:34] ogra_: I think it's a minor issue to fix, it _did_ work until I upgraded to -3 [09:34] elinux is fine here [09:34] ogra_: and it seems the issue can be fixed with one line in the uEnv.txt [09:34] ogra_: which version do you have? [09:34] dunno [09:34] ogra_: (and if you know) how to determine the version correctly [09:34] fgimenez: which version do you have [09:44] zyga the box says it's bbb rev C, don't know if i can query the hw somehow, was the 4gb flash storage size in rev B? [09:44] fgimenez: I think it was 2GB in B [09:45] fgimenez: ok, you have some C version [09:45] fgimenez: can you erase your emmc to see if this is unique to a5? [09:47] mvo: which lab runs tests on snappy/beagle? (looking at one ofthe TODO:QA cards on trello) [09:47] zyga: I don't know but I was able to run all of them here with my local BBB [09:47] mvo: I'm trying to understand who runs those tests and how that's set up [09:49] zyga: fgimenez or leo can help here I think [09:51] zyga mvo there's still no lab for that, we hope to set up an environment for running the selftest on this monthly iteration [09:52] fgimenez: do you have a location? [09:54] zyga nope, we'll contact CI for that, and in the meantime (and always to have consistent results from the tests) we'll run the automated suite locally [09:55] fgimenez: thanks [09:55] mvo: how do you run tests with adt? [10:10] morning [10:10] sergiusens: hi [10:11] seb128: I'll take care of personal; you need more snappy[a|b] storage space, right? [10:11] zyga: where does booting stop for you? [10:11] * sergiusens tries to avoid reading the full backlog in detail [10:12] sergiusens: it doesn't get out of uboot [10:12] sergiusens: tries to load everything from the wrong partition [10:12] zyga: oh, weird; on a bbb revC? [10:12] sergiusens: I can figure out the workaround, just being frustrated at the replacement laptop just being slow and crappy [10:12] sergiusens: A5A [10:12] sergiusens: I doubt it's rev relevant [10:12] sergiusens: more like what you have on emcc [10:13] mmc [10:13] sergiusens: unless uboot has wrong defaults for rev A [10:13] sergiusens: (which is possible) [10:13] zyga: yes, maybe, plars had a similar issue with that board [10:13] zyga: and the quick solution was to first install the latest debian to the emmc [10:13] sergiusens: have a look at https://bugs.launchpad.net/snappy/+bug/1464275 [10:13] sergiusens: well [10:13] Ubuntu bug 1464275 in Snappy "Unable to boot beagle bone black from prebuilt image #3 (hardware A5A, empty emmc)" [Undecided,New] [10:13] sergiusens: the image is just broken :) [10:14] sergiusens: it's just plain wrong and easy to see why :) [10:14] sergiusens: if you can confirm that your bbb has the same defaults on revc (interrupt uboot) [10:14] sergiusens: then it's not specific to board revision [10:14] sergiusens: where can I send patches to uboot config (uEnv.txt) [10:15] zyga: lp:snappy-hub/snappy-systems [10:15] sergiusens: thanks, I'll branch that [10:16] https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems ? [10:16] zyga: yeah, beagleblack/uEnv.txt iirc [10:17] yeah, got it [10:19] sergiusens: yes [10:19] sergiusens: that fixes it [10:19] sergiusens: I'll sent a merge request out [10:21] ogra_: I fixed it :) [10:24] ack [10:24] https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 [10:24] * zyga looks at how to rebuild a clean image for testing [10:30] zyga: sorry for the delay, there is a readme for that, once sec [10:31] zyga: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/integration-tests/run-in-image/README [10:34] mvo: thanks! [10:38] sergiusens: are there any instructions for rebuilding the fully snappy image? [10:39] zyga: from which point? [10:39] sergiusens: I want to rebuild the bootloader snap [10:39] sergiusens: and rebuild the SD card image with that and core-3 [10:40] * zyga needs to get some terminology right [10:40] (please teach me) [10:40] zyga: if it's to integrate your new bbb snap, snappy build it and then; sudo ubuntu-device-flash core 15.04 --oem ./local_beagleblack.snap --developer-mode --output bbb.img [10:40] sergiusens: fantastic, thanks [10:40] sergiusens: do I need any ppas apart from the snappy one> [10:41] zyga: it's just that the personal folk are dealing with the same one level deeper [10:41] zyga: no, it's all in ppa:snappy-dev/tools [10:44] sergiusens: is sudo needed for that? [10:44] sergiusens: or is it just a habit [10:44] u-d-f needs to mount images [10:45] so it need sudo [10:45] *needs [10:45] ah, I see [10:46] the patch looks sane, but i'd like to hear from lool, perhaps he sees drawbacks [10:46] ogra_: thanks [10:46] (and you probably want some verification that it doesnt regress for working boards indeed [10:46] ) [10:47] * zyga sees hardware packs and linaro-media-create everywhere he looks ;-) [10:47] ogra_: yep, I'll test a clean image now [10:47] ogra_: and I want to see how it works on other beagles [10:47] yeah, its kind of an evolution of that :) [10:56] ogra_, do you still have issues accessing irc.canonical.com, too? [10:57] nope [10:57] vpn works, irc works [11:11] ogra_: boots okay on empty emmc [11:29] o/ [11:29] sergiusens: https://launchpad.net/snappy/+milestone/15.04.2 :-) [11:38] tvoss, did you restart your VPN connection after the outage ? [11:38] ogra_, not running on a vpn connection here [11:38] ah [11:38] did we have another outage? [11:40] sergiusens, hey, yes, mvo tried to bump it to 4G with http://paste.ubuntu.com/11700710/ but the image build fails atm with a "issue while mapping partitions: more partitions then expected while creating loop mapping" [11:40] rsalveti, vpn and irc were gone ... not sure if for everyone [11:41] sergiusens, but maybe something is wrong with the channel content, it tries to download a 78M device tarball where the one generated by the launchpad builder is 140M [11:41] ogra_: right, was fine for me at least [11:41] weird :-) [11:43] zyga: ah, right, the way uboot is set up on the BBB image is really weird. I've mostly got it sorted though [11:44] zyga: I'm just waking up though, give me a bit and I'll send you the info on it [11:57] plars: hey [11:57] plars: I fixed the bug [11:57] plars: details are here https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 [11:58] plars: with that patch merged you can always boot [12:32] seb128: I'll sort it out [12:32] asac, ping [12:33] mvo: hey, can you later look at https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/beBetter/+merge/261804 ? [12:33] sergiusens: sure [12:34] sergiusens, thanks, let me know if you figure out anything or if you have any patch/hack to try [12:35] sergiusens, I would have liked to get an image I can boot today, just to a nice way to wrap the week feeling like we get things in shape ;-) [12:40] sergiusens: you will hate me, have tons of questions. sorry for that, probably because its so hot here. nothing to worry about though (and I'm only at ~20% of the MP sso far) :/ [12:40] mvo: no worries, I mostly switched to composing and implementing the diff in that MP [12:59] zyga: yeah, we should discuss later. Basically the control over boot location with the s2 button doesn't necessarily do what you'd expect wrt where it pulls uboot from, and even which image it boots (it should worry you that you don't have to press s2 to boot snappy from the sd card) [13:00] and in fact, you are booting the uboot from emmc when you do that, not the one that came on the snappy image [13:02] plars: I'll explain after the meeting === joet is now known as josepht === mwenning is now known as mwenning-wfh [13:47] hello [13:54] elopio, Howdy! [13:55] plars: s2 doesn't change anything here, the problem is that even if you hold s2 and boot from sd [13:55] plars: uboot will load environment from emmc [13:55] plars: and that environment shipped on production boards from element 14 [13:55] plars: actually allows our current images to boot [13:55] zyga: right, that's why I had to rebuild uboot [13:56] plars: if you wipe emmc then you still boot from sd but now don't have the missing uEnv.txt [13:56] plars: the patch I provided changes that so emmc is irrelevant [13:56] zyga: noooo, we want emmc [13:56] zyga: without it, what happens if you flash a bad snappy image? [13:56] zyga: you have no sensible way of replacing it [13:56] plars: it tries to load snappy from emmc, look at this: [13:57] https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 [13:57] plars: replacing what? [13:57] zyga: I think we're talking about two slightly different, but related problems [13:57] plars: we want emmc but the defaults in our image are wrong [13:57] plars: with this patch you can still use emmmc for anything [13:57] plars: it just won't be on the critical path for booting [13:57] heya snappers. I did snappy update ubuntu-core (on rpi2), snappy list -v showed 81* and 83!, but when I rebooted it didn't switch to 83, shows 81* 83. Where do I start looking at what happened? [13:57] zyga: scenario: automated snappy testing on bbb, you flash a bad snappy image to the sd, boot, and find out it's broken. How do you get back your stable testing platform? [13:58] zyga: that's what I was going for [13:58] you're just hitting the bad bootpart setting in uboot [13:58] plars: well, I don't know, that's out of the scope [13:59] zyga: I certainly hope not! [13:59] plars: my point is that snappy images that we ship should work _regardless_ of what you have on emmc [13:59] plars: (well, we can use lava LMP) [13:59] zyga: indeed, and I agree [13:59] plars: or "master image" on emmc [13:59] elopio: spain won in the end, right? [13:59] plars: so I think it is out of scope [13:59] zyga: haha, well, they don't even use that. Apparently it doesn't work [13:59] plars: as long as the image we use boots regardless if placed on sd card [13:59] zyga: talk to dave sometime [13:59] plars: oh? :D [13:59] plars: I would love to talk to them [13:59] rsalveti: yeah... We were close to a tie though. [13:59] zyga: yeah, I had the same hope, but they told me it was doa [14:00] saw a few minutes, and was a bit intense, the goalkeeper was doing an amazing job [14:00] elopio: yeah, cool [14:00] zyga: at least that's what he said a few weeks ago, and didn't sound optimistic at the time [14:01] fgimenez: I forgive you. I'm setting up the hangout. [14:02] fgimenez: https://plus.google.com/hangouts/_/gwxohxu2okyw57dw2o5w2657jqa [14:04] everybody: fgimenez and I will start doing a daily hangout before the standup. Join us if you ever feel alone and need somebody to talk to... about tests. [14:05] elopio, omw 2-1... [14:18] davidcalle, so how can i log in to the developer.ubuntu.com site in a way that i can edit (i think you or daniel once gave me edit rights) [14:19] the "log in" button only expands a "my apps" option when i click it [14:21] lool, can you remove your pi2.lool snap from the store (i guess we either want an updated one or none at all) [14:22] elopio: can you send me an invite please [14:22] zyga: I think it's open, just use the link: https://plus.google.com/hangouts/_/gwxohxu2okyw57dw2o5w2657jqa [14:23] lool: hi, could you have a look at https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 [14:23] let me know if it doesn't work. [14:24] elopio: looking [14:24] elopio: cool [14:38] ogra_, https://developer.ubuntu.com/openid/login/ (make sure you check the "editor" checkbox) [14:56] sergiusens, did you look at the snappy personnal image build yet? just curious to know if you see an issue or a workaround we could use to try to get an image build today ;-) [15:11] seb128: I just got back from errands, so will be looking now [15:12] sergiusens, thanks [15:13] sergiusens: so overnight my bbb is now not responding to ssh. it will respond to pings [15:13] sergiusens: is there an r83 image now? [15:16] mwenning-wfh: all your comments are awesome btw [15:17] err, mvo I mean ^ :-) [15:17] aw man I was trying to sleep [15:18] :-) [15:22] sergiusens: thanks [15:23] davidcalle, geez, are we serious about that CMS ? it manages to get my 8 core i7 with 16G ram to its knees ! [15:23] ogra_, how? [15:24] seems to have ginormous amounts of javascript that eat my CPU and ram [15:24] ogra_, there are a some pretty bad things with it (and a lot of cool ones), but this one is new to me :/ [15:25] well, hangout in one tab, the CMS in another and my browser turns to a slideshow [15:26] ogra_, hmm, for now, do you want to send me your edits (or draft or notes), working fine for me [15:26] no, i'm fine its just dog slow [15:28] elopio, so, the problem with the wrapper is related to the build of the debs, the dependencies are updated and doesn't work on vivid, right? [15:29] fgimenez: I have a brain overload. The build of the deb worked on the desktop, but ssh failed. ssh works on the laptop, but the build fails. [15:29] http://paste.ubuntu.com/11702627/ [15:31] http://paste.ubuntu.com/11702636/ [15:32] elopio, the first one seems to be related to the different release versions, if you try to execute bzr-buildpkage it should fail too [15:34] mvo: here's another one (just a rebase) https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865 [15:34] bzr bd works. [15:35] elopio, yep it seems to be more permissive with changes in the source tree [15:36] have a great weekend everyone === shaderslayer is now known as shadeslayer [15:37] bye zyga [15:43] elopio, do you think that we should compile the tests in the deb build process as part of the wrapper card? [15:44]