[00:13] working LXD snap: https://plus.google.com/+St%C3%A9phaneGraber/posts/aX6vogzEQ1X [00:13] just got to work on making a more restrictive policy so that it's acceptable for the store [00:29] Wow, that's pretty exciting stgraber . Nice work! [02:50] elopio: for later lp:~sergiusens/snappy/upgradeBlockedSelfTest [02:50] elopio: but I can't run adt on trusty [02:50] elopio: 2015/06/17 23:49:21 Error while running [adt-run -B --setup-commands touch /run/autopkgtest_no_reboot.stamp --setup-commands mount -o remount,rw / --setup-commands dpkg -i /tmp/snappy-debs/*deb --setup-commands sync; sleep 2; mount -o remount,ro / --override-control debian/integration-tests/control --built-tree /home/sergiusens/go/src/launchpad.net/snappy --output-dir /tmp/snappy-test/output --copy=/tmp/snappy-test/debs:/tmp/snappy-debs --- ss [03:36] sergiusens: you probably need adt from the ppa. [03:42] https://packages.debian.org/sid/autopkgtest [03:42] not the ppa, the deb ^ [04:44] sergiusens: I don't fully understand everything you are doing in your test, but instead of writing the installYaml file, can't we call ubuntu-device-flash with a device-part and deploy that to the testbed? [04:59] snappy team, for when you get up, we seem to have a regression: https://bugs.launchpad.net/snappy/+bug/1466311 [04:59] Ubuntu bug 1466311 in Snappy "selftests fail with: ubuntu-core-launcher: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory" [Undecided,New] [05:01] @nothal help [05:01] elopio: No such command! [05:01] nothal -h [05:01] @nothal -h [05:01] elopio: No such command! [05:02] @nothal info [05:02] elopio: No such command! [06:51] good morning [07:01] good morning === erkules_ is now known as erkules === chihchun_afk is now known as chihchun [09:04] Good morning all; happy International Picnic Day! 😃 [09:27] picnic \o/ [09:39] hey JamesTait - picnic today would be fantastic :) [09:41] JamesTait, I'm looking at the oem snap bits again today and I'm not quite sure how I'm supposed to use the API :) [09:41] JamesTait, http://pastebin.ubuntu.com/11734613/ is the bits of information I extracted from our discussion yesterday [09:41] but I'm not quite sure where to go [09:42] bah, couldnt they pick a day with better weather at least :P [09:45] dholbach, what is it you're wanting to find, exactly? [09:46] all snaps of the type oem [09:46] (not sure if we're going to rename them to gadget snaps at some stage?) [09:48] dholbach, I think `curl https://search.apps.ubuntu.com/api/v1/search?q=content%3Aoem -H 'X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1'` should get what you want? [09:51] cool thanks JamesTait - I'll play around with that a bit more === chihchun is now known as chihchun_afk [09:54] dholbach, it's a bit awkward, because we want queries to be additive - adding more terms to the query should match more documents, with those matching more terms scoring higher so coming first in the results (simplifying a bit) - but filters need to be subtractive - i.e. "don't show me anything I can't use with these frameworks/this architecture/etc." [09:55] yep, ok [10:03] anybody know what restrictions apparmor places on package names / versions / etc, if at all? [10:05] Chipaca: apparmor it self? minimal if any, however the are guides for what is allowed in the name [10:05] https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ [10:06] jjohansen: yep, i'm aware of what we've documented [10:06] jjohansen: i'm documenting what we actually restrict [10:06] Chipaca: apparmor does have a few limits on its profile names, the first character is restricted and // is used as name separator similar to how / is used in filenames [10:07] Chipaca: so I am not sure the exact mapping of snap name to profile name [10:07] jjohansen: ok, ta [10:07] Chipaca: currently profile names, require an alpha-numeric or '/' start character [10:08] \0 is not allowed as a valid character in the name, and // is interpreted as a name separator [10:08] eg. profile_name//child_name [10:09] jjohansen: alphanumeric is [a-zA-Z0-9], yes? [10:09] +, &, : are allowed as a leading character in some cases (as compound labels) but not actual profile names [10:09] so you might seem them reported by say ps -Z [10:10] Chipaca: its actually wider than that [10:10] what even is ps -Z [10:10] not in the manpage :) [10:10] Chipaca: ps -Z will show the security label on a process [10:11] $ ps -Z [10:11] LABEL PID TTY TIME CMD [10:11] unconfined 3253 pts/1 00:00:01 bash [10:11] unconfined 6951 pts/1 00:00:00 ps [10:11] yep [10:11] jjohansen: how is the security label connected to the apparmor profile? [10:11] that label is mostly likely a profile name, but it could be a compound label [10:12] a profile is a label, but a label could be composition of multiple profiles [10:12] A//&B [10:13] is the intersection of profile A and profile B [10:13] woh [10:13] interesting [10:13] this can show up on stacked tasks (not landed yet) [10:13] i'm going to just leave it at "starts with alphanumeric or /", and pretend the other cases are for people who know what they're doing [10:13] but also on sockets, and files that have been shared between apps [10:14] as what i'm trying to document are the limitations and checks put on a package from its metadata [10:14] Chipaca: that is a good idea, at least for now [10:14] k [10:24] sergiusens: ogra_: http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/ seems all good for vivid as well [10:30] mvo_: sergiusens: documenting what we actually do with metadata is making me sad [10:35] Chipaca: lol, why? [10:35] `name`: documented as `[a-z0-9][a-z0-9+-]`. The `package.yaml` parser requires it to be non-empty (all-whitespace is ok) and that it doesn’t contain a `.`, but otherwise doesn’t care. `ubuntu-core-launcher` requires that appname match `^[a-z0-9][a-z0-9+._-]+$` (this includes the origin though). Apparmor requires the profile name (derived from the package name) start with an alphanumeric (or /). Click review checks against `^[a-z0-9][a-z0-9+-]+$` [10:36] Chipaca: meh, sounds like a good opportunity to fix it [10:36] mvo_: concentrating on writing it out [10:36] mvo_: then we can see what/how we fix [10:36] it's not just name :) [10:36] Chipaca: ok, thanks for finding that [10:36] and arguably, maybe the checks do belong just in the review tools and snappy should be laxer? [10:37] i don't know [10:37] i'm just documenting so we can have the discussion :) [10:37] trying not to get too bogged down though [10:37] yeah [10:37] but things like the service's name not being required by the tools are already catching people off guard (because things break) [10:42] rsalveti, yeah ! [11:29] elopio: that's what I mentioned in the standup; I wanted a full e2e test but how do I trigger this, where do we store the alternate device.tar (it's not small), etc... [11:36] elopio: shouldn't we have adt in a ppa? [11:47] barry: good morning! I'm curious, what happend here https://code.launchpad.net/~barry/ubuntu-system-image/trunk ? it says " [11:47] This branch has not been pushed to yet." - I wantd to look at fixing this one bug we talked about yesterday [11:53] jdstrand: you around? [12:07] hmm, I can't run our integration tests/adt on trusty, it logs me out [12:08] might be a security feature :) [12:10] ogra_: right... [12:10] fgimenez: any ideas? [12:11] fgimenez: btw lp:~sergiusens/snappy/upgradeBlockedSelfTest [12:11] fgimenez: but elopio wants to run the E2E test from the start (I guess he wasn't paying attention to what I said during standup :-P) [12:42] Chipaca: I am here but I am heading into a meeting in a few minutes. can I circle back to you? [12:43] sergiusens, no ideas atm :( we can talk with elopio later [12:44] sergiusens, your branch looks great! now we can split the related tests in different files for instance https://code.launchpad.net/~fgimenez/snappy/failover-tests/+merge/262191 [12:47] Chipaca: you should go back to square one until he circle's back with you :-P [12:51] rsalveti: could you commit the recent changelog entries from the upload to trunk please? or if you don't have it I handy can do it too, but currently the daily builds are not updated because of the version number difference [12:51] mvo__: oh, creap [12:52] crap [12:52] I always do that [12:52] give me a minute [12:54] mvo__: done, sorry for that [12:54] rsalveti: no worries [12:54] you get that feeling that dput is the end result and forget to run bzr push :-) [12:54] would be better if a bzr push would automatically cause a dput (or similar) [12:55] but well :-) [12:59] rsalveti: yeah or if we could simply sync our ppa version to hte archive or something [12:59] rsalveti: fwiw, I'm starting the 16.04 filesystem and packaigng format docs, I noticed they are in the sprint agenda with my name on them [13:01] sergiusens: you dieded [13:02] sergiusens: hangouts don't like people talking nasty things about grub [13:05] Chipaca: haha - oh grub [13:05] Chipaca: anything interessting that is more interessting than trying to write about fs layouts? [13:06] mvo__: https://plus.google.com/hangouts/_/canonical.com/theGoodTheBadAndTheUgly?authuser=1 [13:07] * sergiusens suggests mvo__ to run /nick mvo [13:08] mvo__: i'm a bad person: https://code.launchpad.net/ubuntu-system-image/+git [13:08] sergiusens: but he has been growing that pony tail for so long === mvo_ is now known as mvo [13:15] barry: heh, excellent [13:19] mvo: the problem with package sync is that the archive police will complain that the changelog contains only "auto build" [13:19] maybe we could improve that with our build scripts [13:19] mvo_: the problem with package sync is that the archive police will complain that the changelog contains only "auto build" [13:19] seems you're having a personality issue [13:20] barry: nice [13:20] mvo: thanks, got a link for the doc? [13:21] rsalveti, mvo: yep, it's great until i tried to land the package through the train. i feel like i've derailed, or more accurately, tried to drive on a railroad with a different gauge ;) [13:21] oh right, not train compatible [13:26] rsalveti: except that i have a separate packaging branch and that is still bzr. the problem is that `bzr merge-upstream` on the resulting orig.tar.gz doesn't do the same thing if you can't merge in the upstream branch too, and that's where i'm going off the rails. I've got one or two more things to try and then i'm going to punt and do a "normal" distro upload [13:40] barry: looks painful, wonder how hard would be for the train to actually support git [13:41] rsalveti: i got the impression from robru that it wouldn't be terribly difficult, it's just that they really, really, really need to kill the spreadsheet first [13:41] hahaha [13:41] indeed [13:41] killing the spreadsheet is getting old :-P [13:41] don't think it will die [13:41] seems like a myth [13:41] yeah [13:41] naw, it just has enough lives to keep 3 or 5 kittens dancing on rainbows [13:44] sergiusens, ping [13:46] kyrofa: pong [13:47] sergiusens, morning! Quick question: the webdm api uses both DownloadSize and InstalledSize. Knowing which to use if the package is either installed or not installed is easy, but which do I use when Installing/Uninstalling? [13:48] A quick glance at the code makes me think installed -> InstalledSize, everything else -> DownloadSize [13:48] But I wanted to double-check [13:48] kyrofa: that is the right logic [13:48] kyrofa: btw, do you have time today to discuss the new api? [13:49] sergiusens, sure! I have standup at in about 45 minutes, but I'm free otherwise [13:51] kyrofa: so in 10'? [13:53] sergiusens, sounds good === mvo_ is now known as mvo [13:59] sergiusens, I sent you an invite with a video link [14:00] hrm, we really need to kill this global lock, autopilot preventing instlaling apps is anoying [14:01] kyrofa: one more sec [14:02] sergiusens, no hurry :) [14:02] kyrofa: btw, you can make up links as you go [14:03] sergiusens, you mean for the hangouts? Yeah, I'm still new at this :P [14:03] kyrofa: https://plus.google.com/hangouts/_/canonical.com/[whateveryouwant] [14:03] sergiusens, heh, good to know, thanks :) [14:07] good morning [14:07] fgimenez: I'm in the call. talky.io seems nicer than firefox hello. [14:08] elopio, mine says connecting... [14:08] fgimenez: I can see you... So not much better. [14:09] fgimenez: yes, I can hear you. [14:09] well, not anymore. [14:09] elopio, wait, i'll try again [14:24] tedg: hi! Is there something similar to click hooks in the snap installer? [14:25] tedg: also, is there something preventing snaps from shipping old fashioned .desktop files? [14:27] fgimenez: it could be talky killing my connection :( [14:37] alecu, Not yet, I've made a proposal on that, but it hasn't be ratified. [14:37] alecu, It will definitely be needed for the Ubuntu Personal use-cases [14:38] Team, can you please look at this: https://bugs.launchpad.net/snappy/+bug/1466311 [14:38] breaks the selftest [14:38] Ubuntu bug 1466311 in Snappy "selftests fail with: ubuntu-core-launcher: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory" [Undecided,New] [14:38] rsalveti: ^ [14:39] alecu, They can ship a desktop file in the package, but it's not clear whether they have to or not. The thing that won't be possible is to write the temporary ones to ~/.local/share/applications/, those will die. [14:39] * tedg does a happy dance [14:39] elopio: against which image/channel? [14:39] rsalveti: rolling edge. [14:40] doesn't happen on stable 15.04 that was the other I tried. [14:51] Chipaca: you said building the snappy for arm was simple. How do you do it? [14:56] elopio: you mean snappy the commandline tool? [14:56] Chipaca: yes. [14:56] elopio: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/cross-build.md [14:57] I was looking in the readme :) [14:57] elopio: qué bruto, póngale cero [14:58] :D [14:58] Chipaca: but to get the arm deb, well have to make a chroot, right? [14:59] elopio: unless you _really_ enjoy playing with ar, yes [14:59] well, dpkg-deb could probably do it :) === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [15:09] tedg: sounds good, thanks! [15:16] Chipaca: hey, what's up? [15:17] jdstrand: hey! um.... i think i got my questions answered :) thanks! [15:18] ok [15:18] fgimenez: elopio maybe you ca merge my branch into yours [15:19] fgimenez: elopio or maybe move that branch you are working on to be owned by snappy-dev [15:28] jdstrand: i think the last one was about click-review, wrt what ran check_framework, but i found the inspect call [15:29] fgimenez: sergiusens: +1 to merge this rev: http://bazaar.launchpad.net/~sergiusens/snappy/upgradeBlockedSelfTest/revision/510 [15:29] I would like to keep the test in a separate MP. [15:29] elopio: sure [15:38] * elopio gets a trusty vm [15:41] Laney: http://paste.ubuntu.com/11735924/ [15:42] can you take a look and fix that please? [15:47] sergiusens, elopio ok merged into lp:~fgimenez/snappy/go-functional-tests [15:48] hey snappers! I hooked up a webcam to my rpi2 and installed the webcam snap but it gives a permission denied error. I already 666'd /dev/video0, where else could I look? http://paste.ubuntu.com/11735959/ [15:49] roadmr: you need to hw-assign to the snap [15:50] roadmr: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ [15:50] sergiusens: oh! cool, let me do that [15:50] sergiusens: haha thanks, that was my next question: "where would one find out about this?" [15:51] * roadmr just deleted the webcam snap by mistake - reinstalling haaha [15:51] roadmr: I fear we don't have specific docs about security things at a user level, do we jdstrand ? [15:51] sergiusens: but I still need the -uc -us to avoid the signing. [15:51] elopio: sure, add that back [15:52] sergiusens: we do not afaik. hw-assign should be documented somewhere [15:52] (in all its forms) [15:52] fgimenez: and we need a better handling on the command line arguments. For now we could support running in beaglebone by passing the debDir. [15:53] elopio: I added the "provide my own bzr bd'ed debs" since this did something weird with my system (http://paste.ubuntu.com/11735996/) [15:53] elopio: so I was thinking more about our discussion and got to wondering... could we use the a-b booting of snappy to try new images with automatic recovery if things go badly? Do we have enough control from within snappy to make that happen? [15:53] elopio: just use the flags package or what we use [15:53] elopio, i had a branch somewhere that used flag, worked pretty well [15:54] elopio: http://golang.org/pkg/flag/ or http://godoc.org/github.com/jessevdk/go-flags (which we use everywhere now) [15:54] elopio: so in other words, keep system-a as a stable image that we never really need to change, use it to flash the new stuff (even possibly a different channel, release, etc) to system-b, reboot, see if we are in the new one, run tests, and force it back to system-a when we are done? [15:54] elopio, http://bazaar.launchpad.net/~fgimenez/snappy/cross-compile-debs/view/head:/_integration-tests/main.go [15:55] plars: we want to test upgrades, so we need to put in a version n-1 and in b version n. [15:55] sergiusens: I was going to do an MP for hw-assign and then decided not to because I didn't feel I had all the details for the oem part bits and wasn't sure if there was something beyond oem and the hw-assign command [15:56] elopio: oh I see, that would break upgrade testing [15:56] plars: for that to work, we would need a c partition, with the pristine factory approved image. Which is something I think sergiusens is planning for. [15:56] sergiusens: thanks, it works \o/ I'm now reading that doc you pointed me to [15:56] elopio: can we have a system-c for that? :) [15:56] hah, that's what I was just wondering [15:57] so the pristine image in c would be our "stable" image that we always go back to for flashing the other ones? [15:57] sergiusens: how would all that work exactly? [15:57] plars: https://docs.google.com/document/d/15nqsGbqxSzArRoqjnydsUYfbqHDYNtVayo6WlrmVGG0/edit# [15:57] sergiusens: right now I'm planning some hard-wired boot control with relays to select whether we boot from emmc or sd on bbb, but something like this would give us a better mechanism that could work even in the absence of emmc [15:58] plars: my plan is for a snappy-factory partition [15:59] plars: elopio and now I get to say ricmm has ignored my proposal so far ;-) [16:00] * sergiusens drops a smoke bomb to go get some lunch [16:00] sergiusens needs a hug. He's feeling ignored often these days :) [16:00] sergiusens: ok, done [16:01] Laney: thanks [16:02] sergiusens: it sounds like this would give me exactly what I'm looking for, as long as I could force booting into recovery somehow, it can even be used to flash a completely new image on the non-recovery part right? [16:03] plars: yeah, it can be a deploy/installer thing as well [16:03] plars: and no more u-d-f complications either :-P [16:03] ricmm: how many beers can we bribe you with to look at this? ^ :) === kickinz1 is now known as kickinz1|away === rickspencer3_ is now known as rickspencer3 [16:06] sergiusens: elopio: so how does that work if it fails to boot the image that you flash (or upgrade to)? Does it automatically failover or do you have to take some action? [16:07] plars, beers dont work, try lagavulin [16:07] ogra_: that works too, as long as I can help drink it :) [16:07] :) [16:07] plars: currently, you have to reboot to failover to the good image. [16:07] I think that should happen automatically. [16:08] plars: http://blog.sergiusens.org/posts/Snappy_rolling_back_on_kernel_panic/ [16:08] ricmm: this is being looked at and spec'd [16:08] the factory partition that is [16:09] elopio: that could be handled by waiting a reasonable amount of time to boot and triggering the reset if you don't hear back in time. And on reboot it would automatically boot the other one somehow? /me looks at the post [16:11] plars: yup. Or you could even perfor a factory reset by pressing buttons if the board is unresponsive. [16:12] nice evening everyone o/ [17:00] ogra_: what's needed to get raspberry pi to upgrade normall? [17:00] zyga, all kernel code upstream, all uboot code upstream [17:01] ogra_: hmm, but if I have a normal os snap and rpi specific snaps for the rest [17:01] ogra_: should it not be possible to upgrade in-image? [17:01] ogra_: I see that the kernel code is not in mainline kernel [17:01] you could update these two parts manually perhaps [17:01] ogra_: I see, thanks [17:02] but snappy upgrade will still not give you an upgrade of ubuntu-core via the store [17:02] ogra_: btw, for beagle, have you tried USB-booting? [17:02] zyga: with BBBlfs? [17:03] jkridner: yes [17:03] nope, Pi kept me busy the last weeks, i havent touched my beagle for a while [17:03] jkridner: there are other tools but that's the one I thought about [17:03] zyga: yeah. that's the one I think has the most attention now... [17:04] I'm in the process of trying to setup a test bench using bbblfs. [17:04] zyga, it shouodnt be a prob to switch the writable partition to USB actually [17:04] the initrd mounts everything by labels ... [17:04] ogra_: no, not like that [17:04] ogra_: flash remotely via usb-otg [17:04] oh [17:04] like the panda [17:04] jkridner: what are you doing this for? [17:04] ogra_: yes [17:04] ogra_: probably _exactly_ the same ;-) [17:04] ogra_: Have you looked into available entropy on the RPi2 when it generates ssh keys on first boot? [17:04] :) [17:05] jkridner: I'n looking at working with a few people to set this up for the testing lab [17:05] longsleep, not yet, nope [17:05] i'm still figthing with dtb overlay support ... [17:05] why cant every board be as nice as the beagle *sniff* :( [17:05] ogra_: DTB overlay - what do you need it for? [17:05] jkridner: what is your goal? [17:05] jkridner: perhaps we can work together [17:06] zyga: I'm also looking at using the BeagleBone Black's ability to cut power to the USB. [17:06] longsleep, the Pi doesnt allow using the extension headers with i2c if you dont add the right dtb overlay ... etc etc ... (there are more overlays for other HW parts) [17:06] ogra_: well i guess Snappy needs a way to handle any messy U-Boot and Kernel :) [17:06] yeah [17:06] thats what i'm fighting with [17:06] ogra_: actually, I was meaning to ask you about one thing [17:06] I'm trying to build a test infrastructure for the http://github.com/beagleboard/linux and http://builds.beagleboard.org with a bunch of capes attached. [17:07] beaglebone-per-cape. [17:07] ogra_: can we try to formalize remote flashing for snappy core [17:07] so that we can make sure all the capes are supported in the mainline kernel. [17:07] ogra_: we'll need that a lot for the lab [17:07] jkridner: oh, fantastic [17:07] ogra_: I see - i have a similar "problem" - i need to remove certain stuff from the DT based on boot settings - can that be done with overlay too? [17:07] jkridner: so I have to ask, have you tried lava? [17:07] [I used to hack lava a lot in the past] [17:07] * jkridner looks around for rcn-ee [17:07] zyga, well, you wont do it fully remote unless you have some MMC or other storage with the bootloader onboard [17:07] ogra_: for beagle and some others that's true [17:08] ogra_: but let's think big [17:08] ogra_: for products [17:08] yes, thats the prob :) [17:08] ogra_: something we could require at snappy level [17:08] thinking big means taking tons of cases into account [17:08] ogra_: android wouldn't go far without fastboot/adb [17:08] ogra_: or forcing standards [17:08] so we need to start actually small to be flexible ;) [17:08] we plan to overwrite the bootloader in eMMC using the ROM bootloader. [17:08] jkridner, never touched lava. ;) [17:08] rcn-ee, its hot ! [17:08] I will be adding a couple of issues to the Snappy tracker soon, regarding entropy, customization of boot and such - or is it too early to push for stuff like this? [17:09] jkridner: I'm starting to build a lab-as-a-service [17:09] jkridner: with a few other people [17:09] longsleep, no, keep the bugs coming [17:09] longsleep, we might not solve it immediately, but having it tracked is important [17:09] jkridner: our first use case is exposing beagle's for testing anything [17:09] right now, we are just trying to establish we can power cycle and boot/flash a downstream board. [17:09] longsleep, i need to try your image on my odroid too :) [17:09] trying to minimize cost and complexity, leveraging whatever Beagles give us. [17:09] jkridner: we have a lot of experience with that, plars can tell you about it :) [17:09] ogra_: Great - then i will just keep adding them once i have understanding what i would need [17:10] jkridner: there's a trick that we used in lava and that works well for mostly anything [17:10] ogra_: Yeag that would be awesome. I heard reports from all over the world that it seems to be working. [17:10] well, plars wrote lava ... essentially :) [17:10] jkridner: all that you need is a way to power the board [17:10] ogra_: hey, I wrote a lot of it too :P [17:10] oh, right :) [17:10] indeed, zyga was right there sharing the blame :) [17:10] i always forget that you were on the other side of the fence for a while [17:10] ogra_: (and gave it the failed launch-control name) [17:11] ogra_: nah, there was no fence [17:11] rcn-ee: if I reflash bone1 with the 5/1 image, I should at least have a gserial connection, so I'm going to do that now. [17:11] lol [17:11] ogra_: in fact, that's where he started [17:11] yeah [17:11] oh [17:11] i thought you started in canonical :) [17:11] jkridner, correct.. [17:11] zyga: yeah, we need some ideas for power.... we can cut USB power, but we'll need some additional juice a couple boards down the test chain. [17:11] ogra_: well, I kind of did start in linaro and canonical but back then linaro didn't have a nme [17:11] name* [17:12] oh, i remember [17:12] * ogra_ is getting old [17:12] jkridner: I think if you are serious about it you should just get a controllable power strip and focus on the hard bits [17:12] hmm, ssh doesn't let me in in rolling/edge #80 [17:13] jkridner: what are you trying to do exactly? I'm trying to sort through the backscroll. Right now I have a modified uboot on my emmc to use the gpio connected to s2 to boot from the right place. The default gave me some funny behavior where if you pressed s2 it would load uboot from the sd card, and boot the image on emmc, with s2 unpressed it would load [17:13] uboot from emmc and boot the image on the sd [17:13] zyga: but for snappy purposes, it looks like we may soon have a WAY easier solution to all this, that works even if you don't have emmc [17:13] rcn-ee: ugh, I just realized 5/1 is a 4GB image. :( [17:14] plars: oh, tell me? [17:14] plars: a-b? [17:14] plars: or something else [17:14] zyga: right, I was discussing earlier [17:14] zyga: a-b-c actually [17:14] plars: but for [17:14] oooooh [17:14] yes [17:14] yes [17:14] I see this [17:14] zyga: with c being recovery [17:14] well [17:14] zyga: why shouldn't I try to find something cheaper? [17:14] abc is just master [17:14] zyga: http://blog.sergiusens.org/posts/Snappy_rolling_back_on_kernel_panic/ [17:14] proper [17:14] jkridner, i'm setting up a 2gb image right now. ;) [17:14] jkridner: it's not expensive and your time is probably always more expensive [17:14] zyga: right, done officially rather than hacking around it and screwing with the images like we had to do in linaro [17:15] jkridner, flasher is here: https://rcn-ee.com/rootfs/bb.org/testing/2015-06-17/lxqt-2gb/BBB-eMMC-flasher-debian-8.1-lxqt-2gb-armhf-2015-06-17-2gb.img.xz [17:15] plars: I wrote about something like this [17:15] plars: let me find a link [17:15] (for snappy actually) [17:15] a few months back [17:15] zyga: istr at the time telling people it wasn't so crack as they wanted to think - it's what android does too really [17:15] rcn-ee: downloading. [17:15] 4.1? [17:15] yeap! ;) [17:15] sweet. [17:16] plars: do you know when it will be ready [17:16] * zyga looks for the link [17:17] zyga: no, sergiusens has a proposal but I don't think it's actually been reviewed/approved yet [17:17] Chipaca: let me know if you figure out the ssh in rolling edge. It works from my laptop, but doesn't from my desktop. [17:17] writeup of the proposal, not a merge proposal :) [17:17] elopio: you broke it! [17:18] elopio: personally, i think it's a sign from olympus that i should go get dinner moving [17:18] plars: so ricmm owns the solution, I just had a proposal to make thing look a lot simpler from a builders perspective [17:18] some things are broken on my laptop, some things are broken on my desktop. [17:18] so you just painted it over ? [17:18] why can't they just break equally, so I can go to sleep? [17:19] elopio: siesta time? [17:19] sergiusens: no, too early. [17:19] lol [17:19] sergiusens: is the solution any different from what plars talked about? [17:19] jkridner, pushed, so the x15 is now set for 2gb/jessie/v4.1.x *.img builds ;) [17:19] gaah [17:19] how do I find a bug [17:19] that I commented on [17:19] a while ago [17:19] elopio: I have my siesta when Europe has dinner; but that was when I was the only team member in the americas [17:19] not on checkbox [17:19]