[00:28] elopio: you around? [00:28] Chipaca: o/ here [00:28] elopio: hiya [00:29] elopio: http://pastebin.ubuntu.com/12607030/ [00:29] elopio: halp :) [00:29] elopio: i don't even know what failed :-/ [00:30] Chipaca: we still have some work to do to improve that report. It doesn't tell you where it failed. [00:30] exactly! :) [00:30] you need to scroll back and search for a FAILED: message. [00:30] elopio: and then it panics [00:30] I'm willing to bet that it's this one: https://bugs.launchpad.net/snappy/+bug/1498293 [00:30] Launchpad bug 1498293 in Snappy "fake rollback integration test fails" [Undecided,New] [00:31] FAIL: /home/john/canonical/snappy/src/launchpad.net/snappy/_integration-tests/tests/failover_zero_size_file_test.go:172: failoverSuite.TestZeroSizeInitrd [00:31] elopio: ^ is that it? [00:31] um, no, damn it. I lost the bet. [00:32] Chipaca: are you running that in a published branch? [00:32] no, but i can publish it [00:32] I've been running tests all day and that one hasn't failed. [00:32] elopio: lp:~chipaca/snappy/current-data-dir [00:33] Chipaca: publish it and I'll check if it's a real bug or something to fix on the test. It's late for you, right? [00:33] Chipaca: also, you can run only that test: go run ./_integration-tests/main.go --snappy-from-branch --filter failoverSuite.TestZeroSizeInitrd [00:33] something like that. [00:33] yeh, i think i'm stopping here [00:39] elopio: it failed again, and i'm off to bed [00:40] elopio: it's entirely possible it's my branch that broke it; i haven't dug [00:40] Chipaca: I'm running it. We had problems with that test last week. Not sure what's going on, but I'll find out. [00:40] have a good night. [00:40] k [00:40] g'night :) === Bro_ is now known as Guest34947 [01:15] hi everyone.. could you help me..? how to install ubuntu OS on Samsung Galaxy S3 [01:19] i'm a new to ubuntu, and remember that ubuntu have an OS for mobilephone... that's why i wan to try install it on my Galaxy S3.. btw last day i just service my Galaxy S3 (no Samsung service center cause no guarantee more for the device) and then one-chip/peripheral already change causes Galaxy previously sundently dead.. [01:20] hope somebody help me here... i really want to try have ubuntu and become a familiar with this beautiful OS [01:23] o yey... btw the OS on my Galaxy S3 now already the default; "Factory Reser" === chihchun_afk is now known as chihchun [06:04] elopio: no news about that test? [06:05] Chipaca: I've run it like 20 times on it's own, like 5 times on the whole suite. It always passes here. [06:05] I tried some in vivid, some in wily. [06:05] elopio: with my branch? [06:06] Chipaca: yes, of course. [06:06] Chipaca: I looked at your changes and they have nothing to do with that test. [06:06] Chipaca: where you found that FAIL: /home/john/canonical/snappy/src/launchpad.net/snappy/_integration-tests/tests/failover_zero_size_file_test.go:172: failoverSuite.TestZeroSizeInitrd [06:07] you should have also an assertion error. Do you still have that trace around? [06:08] elopio: i do [06:08] a ver ... [06:08] http://pastebin.ubuntu.com/12609009/ [06:09] ... 0 files matching /boot/grub/a/snappy-selftest-initrd*, 1 expected [06:09] that's an error I supposedly fixed already. [06:10] branch is up to date with trunk fwiw [06:15] Chipaca: yes, the fix is in your branch too. I don't understand, but your branch looks good, everything passes here, so you can ignore it. [06:15] elopio: it almost sounds like you could review https://code.launchpad.net/~chipaca/snappy/current-data-dir/+merge/272691 :) [06:15] I might give you a branch tomorrow with some more prints to understand what's going on in your machine. It sucks that it's a kvm and it still behaves differently. [06:16] open /home/john/canonical/snappy/src/launchpad.net/snappy/_integration-tests/tests/failover_zero_size_file_test.go: no such file or directory [06:16] ^ what's that about? [06:16] Chipaca: http://paste.ubuntu.com/12609025/ [06:17] ah well [06:17] Chipaca: that one is https://bugs.launchpad.net/snappy/+bug/1468958 [06:17] Launchpad bug 1468958 in Snappy "selftests print "no such file or directory" on error" [Low,Triaged] [06:17] ah! got it [06:18] Chipaca: and yes, let me review your branch... [06:18] oh, i dunno if i'll let you... i'll have to think about it [06:19] well, you better think fast. I have a long queue of people eager to get my approval. [06:19] also, i should mod goctest to also work with the integration tests [06:19] finding red is a lot easier than finding "FAIL" [06:20] that would be nice. [06:20] Chipaca: but you shouldn't need to search fail. At the end of the run, we are printing the subunit result. [06:20] elopio: here it just panics [06:21] there are two problems with that. One that I was dumb and made it print only if the test passes. [06:21] elopio: which is almost, but not quite, entirely not the same [06:21] the second that it happens only when you run it from ./runtests. [06:21] we will integrate the _integration-tests/main.go with go-subunit, so everything will be super awesome :) [06:22] of course, the goctest pretty print will be faster. [06:23] ogra_: hey, while building a snappy image for rpi2 according to your instructions I've got [06:23] WARNING: this option should only be used to build azure images [06:27] morning :) [06:29] Chipaca: why do you create the symlink twice? once in line 120, and again in 128. [06:29] oh, nevermind, they are different. [06:30] elopio: one is the /apps/$APP/current symlink, the other is the /var/lib/apps/$APP/current symlink [06:32] was there a bug for this? [06:32] * Chipaca goes looking [06:35] asac: df failing> hm, /proc missing or so? are you doing this in a chroot or so? [06:53] good morning [06:54] Chipaca: +1. [06:54] Chipaca: when you remove a snap that has an empty data dir, should the dir be removed? [06:55] elopio: not necessarily, no [06:55] elopio: data dirs are left alone, for now [06:55] elopio: at some point we want garbage collection to remove the n+1th [06:56] ok, just wondering. [06:56] I'm going to bed now. See you soon. [06:57] elopio: take care, que descances [07:45] it's not yet 9am and i've already done a carnaugh map [07:45] today is going to be interesting [07:51] it's 10:51am :P [07:52] you are -3 h, portugal? [07:53] I'm -1, you're +1 :) [07:53] or something [07:53] * Chipaca checks [07:53] :D [07:53] yeh, I'm +1 [07:53] so you'r +3 [07:53] right [08:21] vmayoral|pc: got enable/disable working in branch locally. Need to add tests :) [08:22] but first, coffee [08:22] vmayoral|pc: turns out it's going to be very easy to also add it to the snappy command right now, so i'll probably do that as well [08:22] * Chipaca ~> coffee [08:23] Good morning all; happy Tuesday, and happy World Heart Day! 😃 <3 [08:39] Chipaca: that's great, thanks [08:41] JamesTait: u+1f491 through u+uf49f [08:41] Chipaca, ❤ [08:41] JamesTait: that's ctrl+shift+u, the hex code, space-or-enter [08:42] and the second one should've read u+1f49f, not u+u... [08:42] * Chipaca goes back to his coffee [08:45] ogra_: ping [08:56] sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1500759 [08:56] Launchpad bug 1500759 in Snapcraft "Add support for overriding the Makefile location in makefile part type" [Undecided,New] [09:10] Is there some documentation how the u-boot scripting should look like and how the partitions are named? Seems like my old stuff does use root=/dev/disk/by-label/system-a which does not seem to work anymore [09:11] pitti: doing it in lxc container [09:11] pitti: mtab wasnt created and also the /run/resolvconf link didnt have an existing target [09:13] Chipaca: did we land the current link for APP_DATA_PATH yet by any chance? would mvo do that? [09:13] asac: branch is on trunk as of a couple of hours ago [09:13] neat [09:14] asac: but i don't think it's released anywhere [09:14] Chipaca: waiting for review and then landing it on devel and 15.04? [09:14] asac: *on trunk* [09:14] oh review is done already [09:14] yeah [09:14] so just landing... [09:14] :) [09:16] asac: what's "landing" in this context? [09:17] asac: also note it does _not_ keep a symlink in the SNAP_APP_USER_DATA_PATH, just in SNAP_APP_DATA_PATH === chihchun is now known as chihchun_afk [09:18] ... we don't currently create SNAP_APP_USER_DATA_PATH ourselves, so it's all up to the app [09:18] ah my u-boot was broken, root=/dev/disk/by-label/system-a still works fine after all [09:33] hey vmayoral|pc [09:34] ogra_: morning [09:34] ogra_: what do you think about https://bugs.launchpad.net/snappy/+bug/1500755? [09:34] Launchpad bug 1500755 in Snappy "vchiq not working on 4.2" [Undecided,New] === vmayoral|pc is now known as vmayoral [09:43] vmayoral, see the bug :) [09:43] (will milestone it for 15.04.5 as soon as someone created the milestone) [09:48] * Chipaca grovels for reviews of https://code.launchpad.net/~chipaca/snappy/activate-package/+merge/272716 [09:51] ogra_: do you have any ideas for a quick fix that unblocks ourselves? [09:51] you could re-build your own pi2 snap [09:52] http://people.canonical.com/~platform/snappy/raspberrypi2/pi2_0.16_all.snap [09:53] (there is "Rebuilding the oem snap" in the RPi2 section on https://developer.ubuntu.com/en/snappy/start/) [09:54] make sure to keep the dtb's in place, they come from the kernel build (including overlay.tgz) [09:57] asac: /etc/mtab should be a symlink to /proc/mounts [09:59] it is :) [10:05] ogra_, hey, in the raspi2 doc email, are you talking about future install instructions or is it for the image you just released? [10:05] davidcalle, thats for current ... and i think i updated the doc accordingly === chihchun_afk is now known as chihchun [10:06] current stable is in the /~platform location ... dail/edge doesnt get actual img builds (like all other arches) [10:06] *daily [10:09] ogra_, thanks! [10:16] ogra_: got the oem snap and ready to rebuild it, just don't quite understand what are the things that i need to change [10:17] ogra_: i guess i need to compile http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/ and replace dtbs and overlay.tgz? [10:17] ogra_: master branch seems to be at 3.19, shouldn't it be 4.2 since last snappy image uses that kernel? [10:18] why would you recompile the kernel [10:19] ogra_: is it just a matter of regenerating the pi2 snap? [10:19] vmayoral, you want all of https://github.com/raspberrypi/firmware/tree/master/boot except for the dtb files and the overlay dir, they should be kept in place [10:21] all right, any shortcut to replace the pi2 snap on an existing image or should i create a new snappy image? [10:27] create a new one and make sure to use --developer-mode, else u-d-f will refuse to use local oem snaps [10:27] beuno: happy birthday! [10:28] vmayoral, oh, i'm silly, you can do it without a snap by just replacing the files /boot/uboot/ if you want to test it [10:28] ogra_: will try that out, thanks [10:29] (essentially the start* fixup* and bootcode.bin files) [10:30] sergiusens: https://code.launchpad.net/~zyga/snapcraft/plainbox-app/+merge/272720 [10:34] elopio, fgimenez hey, can you check if something is wrong with tarmac? [10:35] seems stuck; and I am missing an MP [10:35] sergiusens, sure, i'll take a look [10:37] fgimenez, ah, nevermind [10:37] fgimenez, I was just confused [10:39] sergiusens, ok np :) seems to be working fine http://paste.ubuntu.com/12610492/ [10:42] fgimenez, oh, we need to update tarmac with the latest plainbox [10:44] Chipaca, good morning; mind reviewing something? https://code.launchpad.net/~sergiusens/snapcraft/1500758/+merge/272728 [10:45] sergiusens: trade you? [10:45] Chipaca, sure [10:45] sergiusens, done, now it has plainbox 0.23+ppa~ubuntu14.04.1 installed [10:45] fgimenez, great, thanks [10:45] fgimenez, also, zyga is here and willing to share all the setup for using git and merging/testing [10:46] fgimenez, not sure how to coordinate that, but it would be nice to have this :-) [10:46] Chipaca, just note that my MP says 'simple' ;-) [10:47] sergiusens: you get to choose! [10:47] sergiusens, indeed :) let me know if we can do anything from our side [10:47] sergiusens: simple: https://code.launchpad.net/~chipaca/snappy/dddddirs/+merge/272430 [10:47] sergiusens: short: https://code.launchpad.net/~chipaca/snappy/activate-package/+merge/272716 [10:47] :) [10:49] sergiusens: LGTM, with a question :) [10:50] Chipaca, approved dirs with a suggestion :-) [10:50] sergiusens: it already is snappy/dirs [10:51] as in launchpad.net/snappy/dirs [10:51] launchpad.net/snappy/snappy just feels wrong already :) [10:51] Chipaca, oh, :-) [10:52] Chipaca, I guess it is fine, we just need to move launchpad.net/snappy/snappy/*.go to lanuchpad.net/snappy :-D [10:52] sergiusens: ... sooon ... :) [10:52] or use vendoring ;-) [10:52] Chipaca, ok, so I wait for you to approve my MP now ;-) [10:53] d'oh :) [10:54] sergiusens: where does vendoring come into the equation there? [10:54] Chipaca, nice filepaths and GOPATH goodies [13:00] vmayoral: https://launchpad.net/ubuntu/+source/linux-raspi2 [13:03] vmayoral: here too http://kernel.ubuntu.com/git/ubuntu/ubuntu-wily.git/log/?h=raspi2 [13:03] ricmm: got it [13:18] Finally got time to finish work on Bug #1496319. One question: is .json.additional file content fixed for any reason? I mean, could I add a new field to it? [13:18] bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319 [13:28] * clobrano thinks it should have used the QUESTION tag [13:29] QUESTION: Finally got time to finish work on Bug #1496319. One question: is .json.additional file content fixed for any reason? I mean, could I add a new field to it? [13:29] bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319 [13:35] clobrano, using QUESTION is only a thing when some live broadcast is happening [13:35] if not it generally is, fire and wait or get the right person [13:35] ;-) [13:35] sergiusens: I wasn't sure :), thanks [13:35] so... Chipaca maybe? ^ [13:36] what's the question again? [13:37] Chipaca: hi :), I was thinking about adding a new field to .json.additional file [13:37] trying to implement Bug #1496319 [13:37] bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319 [13:37] please don't implement bugs! :-p [13:38] * Chipaca reads [13:38] Chipaca: I expected that :D [13:41] clobrano: let me check wrt reworking of hw-assign [13:48] clobrano: right! so there will be a redesign, but not for a while, so let's do this :) [13:49] clobrano: what is it you propose to fix that? [13:49] Chipaca: I'm thinking about adding a symlink_path field, to keep information about which path links to which HW device [13:51] Chipaca: this way, when using hw-unassign on a hw device, I can see that there is also a symlink to unassign [13:54] clobrano: now i understand your question and everything! [13:54] clobrano: no issues with adding an additional field to the .additional json [13:55] Chipaca: yep, I took a long way to explain it :D [13:55] Chipaca: fine then [13:56] Chipaca: thanks === davidcalle_ is now known as davidcalle [14:22] fgimenez: https://code.launchpad.net/~zyga/snapcraft/plainbox-app/+merge/272720 [14:22] fgimenez: not entirely done (but it's safe to land if it doesn't blow up as it's not the default) [14:22] fgimenez: I'll go and do unit tests next [14:22] fgimenez: but I need to patch something first around in another project [14:23] fgimenez: the idea behind hat branch is to get rid of the shell script that does unholy things with plainbox and just use proper APIs [14:23] zyga, yes we need that :) [14:24] fgimenez: (the apis in plainbox are not in plainbox.public yet but they will be soon and the ones used here are the candidate APIs anyway) [14:24] fgimenez: please have a look at the UX there [14:24] fgimenez: I tried to make it better than the old script [14:24] zyga, ok thanks i'll ping you back [14:24] fgimenez: after you look at the basics I'd like to discuss how to integrate unit tests -- there are two ideas I have [14:25] fgimenez: thanks :) [14:38] * guest42315 ubuntuonair in 20 min http://ubuntuonair.com/ [15:00] Chipaca: Hey, i just got forwared a mail that christine seem to have added us to the contributor agreement, while i am still not seeing it in the members list i now wonder how you folks know that i am contributing for this company [15:05] * zyga stands up [15:28] longsleep: that's yet another good question I don't know the answer to. [15:29] longsleep: maybe because the one that filled out the cla for the company tells us somehow? [15:29] * Chipaca is asking elsewhere as well :) [15:30] sergiusens: http://paste.ubuntu.com/12613213/ [15:44] Chipaca: well, at least the confirmation mail did not say anything helpful in that regard. [15:44] longsleep: turns out, there wasn't a process [15:44] :D [15:45] longsleep: so, the person that signed the cla on behalf of the company [15:45] longsleep: needs to create a group [15:45] longsleep: and let us know what group that is [15:45] aha - can it be a existing group? [15:45] longsleep: and then we add that group to the CLA group [15:45] and how do we let you know [15:45] well, and it should be a controlled group ... not one everyone can join ;) [15:46] longsleep: sure, as long as membership in that group implies they can submit code in the company's name [15:46] group is strukturag - already is there [15:46] yes [15:46] ok, but the one who has submitted is not in that group yet [15:46] oh my let me fix that [15:48] Chipaca: ok, so how can we let you know that it is this group? === chihchun is now known as chihchun_afk [15:59] longsleep: you should've received an invite [16:00] longsleep: (in future we might ask that the person signing is owner of the group; for now, this'll do) [16:18] zyga, https://code.launchpad.net/~sergiusens/snapcraft/scons_options/+merge/272817 [16:24] sergiusens: https://gist.github.com/vmayoral/0ddc3b9c50198cb182a4 [16:30] Chipaca: ok great, worked perfectly - thank you ! [18:08] ogra_ hey [18:08] yo [18:08] soooo, pwm, we followed your instructions to enable it, but, errr [18:08] not sure it is working [18:09] * rickspencer3 gets a pastebin [18:10] cat /sys/firmware/devicetree/base/soc/pwm@7e20c000/status [18:10] if that says "okay" it is enabled [18:10] http://pastebin.ubuntu.com/12615323/ [18:10] * rickspencer3 looks [18:11] it says "okay" [18:11] well, then it should work ... [18:12] there is another pwm overlay (twochannel) you could tyr editing config.txt and use that instead of the basic one from ym instructions [18:12] pwm-2chan-overlay.dtb [18:12] perhaps that behaves differently [18:14] https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L419 [18:15] so you can obviously use: dtoverlay=pwm,pin=18 [18:16] * ogra_ tries [18:29] rickspencer3, the export node is a toggle ... only takes 0/1 [18:30] rickspencer3, if i echo 1 into it i see a /sys/class/pwm/pwmchip0/pwm1 being created [18:31] * ogra_ doesnt have the slightest clue what he is doing [18:31] ogra_ ok, we'll keep banging on it here and see where we get [18:31] root@localhost:~# ls /sys/class/pwm/pwmchip0/pwm1/ [18:31] duty_cycle enable period polarity power uevent [18:31] does that look like what you want ? [18:33] looking at online docs it seems the interface has changed with 4.2 ... seems in older versions there were nodes like "frequency" as well [18:33] * ogra_ assumes thats replaced by "period" [19:52] elopio, mind looking at scons again? [19:52] sergiusens: sure. [19:52] elopio, I even added the missing test I forgot the first time around :-/ [19:52] sergiusens: excuses :p [19:53] elopio, I blame zyga [20:05] elopio, thanks [20:06] np [20:06] elopio, btw, did you see zyga's branch? [20:06] sergiusens: por encimita. [20:07] elopio, it is good because we can autocomplete and select tests specifically or with a filter [20:08] ah, that's cool. [20:09] he says it doesn't yet support the unittests. But that's ok, we only need to clean up the weird script we use to launch the plainbox tests. [20:09] I'll give it a try after lunch. [20:26] kyrofa, ping [20:26] Hey victorp :) [20:26] hi kyrofa [20:26] zyga, lp:~sergiusens/snapcraft/1501035 [20:27] I am just playing with the rpi and installed your piglowtop snap [20:27] \o/ [20:27] v awesome [20:27] I was wondering if you had a bzr branch for it, that I can use as an example to learn a bit more about snappy [20:28] victorp, not bzr, but git [20:28] victorp: https://github.com/kyrofa/piglowtop [20:29] kyrofa, :P [20:29] victorp, there are two READMEs-- the main one is for the software itself, and the snappy-specific one is in meta/ [20:30] kyrofa, awesome! [20:30] thanks [20:30] victorp, any time! [21:01] sergiusens: it doesn't work [21:02] zyga, because of python3? [21:02] sergiusens: py3versions [21:03] http://pastebin.ubuntu.com/12617891/ [21:03] zyga, yeah, skip those on wily, it depends on the MP you reviewed earlier [21:03] sergiusens: py3versions itself crashes [21:03] sergiusens: I think it's different [21:03] ah [21:03] sergiusens: it crashes because py3versions is a dh-thing [21:03] sergiusens: and I suspsecy you don't have that in the stage python [21:04] sergiusens: (python3-minimal) hmm [21:04] zyga, snappy shell and try it maybe [21:04] I wonder what is error 2 [21:04] oh! [21:04] cool [21:04] snappy shell -- no such command? [21:05] snapcraft shell [21:05] sorry [21:05] zyga, ^ [21:05] ah [21:05] sergiusens: that doesn't work [21:05] (venv.x200t)zyga@x200t:/tmp/1501035/integration-tests/data/pip-requirements$ snapcraft shell [21:05] py3versions -i [21:05] pyversions -i [21:06] it needs py3versions itself :) [21:06] /tmp/tmpgzjdflwl: 7: export: python3.5/dist-packages: bad variable name [21:07] oh, python 3.5 [21:07] darn wily [21:13] "write /tmp/diskimage045123107/boot/a/dtbs/r8a7791-henninger.dtb: no space left on device" [21:14] I get this when trying to create the raspberry pi image [21:16] ah, nm, I didn't specify the device [21:16] how do you create it ? [21:17] phew [21:17] ogra_: I got it now, but what really surprised me is that udf didn't exit with a non-zero rc [21:17] * ogra_ feels like he had enough disasters tonight :P dont shock me [21:17] haha, sorry :) [21:17] :) [21:18] plars, well, if you dont specify --device it simply tries the generic tarball on top [21:19] its not an error so it doesnt exit nonzero [21:19] (the space issu is indeed) [21:19] (and probably worth filing a bug) [21:19] ogra_: I'd like to chat (not urgent, sometime when you're having a better day), about rpi2 automation [21:20] yeah [21:20] ogra_: it mostly works right now, but I wasn't able to handle reading the environment from the actual image partition that I'm testing [21:20] ogra_: so it won't cope well if we try to test upgrade/rollback [21:20] you mean uboot.env ? [21:20] ogra_: mostly just trying to work around the fact that rpi2 can only boot from one place [21:21] ogra_: yeah, I'm booting an ubuntu image off the SD card, with a lot of uboot bits from snappy. It reads a gpio to decide whether to keep booting from the sd card, or pull the kernel/initrd from usb (where I wrote the new image) and simulate the snappy boot process from the bits that are on usb [21:22] ogra_: so obviously there's a big downside that we don't actually test the bootloader from the new image, but given that we can't chainload and only have a single boot location, I don't see any way around that [21:22] yeah [21:22] well ... the rpi has config.txt .... [21:23] you could mangle the kernel=uboot.bin line [21:23] ogra_: but the other issue is that if we do an update/rollback, those settings get written to uboot.env on the usb stick, and I don't know of a good way to selectively read in just the values I care about from there [21:23] ogra_: but how do I get it back if things go wrong? [21:23] ogra_: I need to know that it will fall back to the right place no matter what [21:23] so you would still use the pre-loader from SD but could point to a different uboot [21:24] ogra_: but I don't think I could point it to the one on usb, it would still have to be on the sd card somehow [21:24] which I can't safely overwrite [21:24] yeah [21:24] you would need both uboots on the SD and duplicate the uboot config [21:24] there may not be any good options, but I figured if anyone would have ideas, it would probably be you :) [21:24] heh [21:25] ogra_: if anything comes to mind, just let me know what your thoughts are [21:25] well, i think what yu do is the sanest you can do ... [21:25] wow, did I just get accused of being sane? [21:25] you can indeed edit uboot.env from anywhere using fw_setenv ... [21:25] I guess I'm making progress [21:25] :) [21:25] hahaha [21:26] ogra_: it works pretty reliably for most things, just a few limitations that are annoying [21:26] what you need for fw_setenv is the right config ... we ship that in /etc/fw_env.config ... [21:28] ogra_: there's some strange magic there [21:28] ogra_: which entries end up getting modified when you do an update? [21:29] snappy_ab and snappy_trial_boot [21:29] err nnno [21:30] snappy_ab and snappy_mode [21:30] ogra_: yeah, if that's all, then I could possibly let it just modify the one on the sd card, but I'd have to remount after booting, and I've kind of lost control at that point (nor do I want it updating the kernel for me or any other files at that location) [21:30] well, the kernel will always only be updated on the other partition [21:31] or in case of uboot the "other dir" [21:31] ogra_: but it's still under /boot/uboot/{a,b} [21:32] ogra_: if I simply remount /boot/uboot after booting and force it to point to the mmc, then I really haven't accomplished anything [21:32] in fact, I could be causing more problems, since it won't persist after the reboot [21:32] if i'm booted into the system-a partition the kernel from /boot/uboot/a is used as well ... the update switches snappy_ab=b and snappy_mode=try ... then it reboots into system-b ... systemd sets snappy_mode=regular at the end of the boot process and you are fine ... [21:33] I don't have control after provisioning happens, from that point forward it's completely up to the test to do the right thing (which will come from somewhere else) [21:33] ... or you fail and snappy_mode is still set to try ... so the script recognizes it should switch back to a and does that [21:33] ogra_: you're still up? [21:34] no, he should be sleeping, and I should quit bothering him :) [21:34] zyga, i rarely go to bed before 2am ... worse is that i'm still working :P [21:34] :( [21:34] ogra_: well, what can I say [21:34] not your fault [21:34] me too [21:34] guys are having beer next to me though [21:35] nope, though that's not bothering me :) [21:35]