=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === ev_ is now known as ev [05:51] * conyoo good morning o_O === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [07:15] good morning [08:38] Good morning all; happy Friday, and happy Yellow Pig Day! 😃 [09:22] ogra_: I think we are getting somewhere https://github.com/mvo5/uboot-env-go might be simpler for us than fw_setenv/printenv and we can use it directly, but I will stop on that for now and wait how the rest of the uboot env work goes [09:28] mvo, yeah, i'm fiddlin with a snap currently to have the needed bits (and i also did a new checkout of the latest uboot before producing the new binary) [09:32] ogra_: nice === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [10:23] mvo, wget http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snap && sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.9_all.snap --developer-mode -o bbb.img 15.04 ... then dd it ... [10:24] it has all env vars inside the uboot.env and ships an empty uEnv.txt (i think snappy still checks for that file to determine if we boot uboot) [10:24] boots fine for me [10:26] mvo, http://paste.ubuntu.com/11892121/ is the content of my input file for uboot.env [10:28] (note there is nothing from snapy-system.txt in it yet) [10:39] ogra_: hm, we need that snappy-system.txt in there too, no? [10:39] yes, and the stamp [10:40] ogra_: yeah, uEnv.txt is currently needed, my branch fixes that (or will) [10:40] but that requires changes to udf [10:40] aha, is that writing it? [10:40] i think so ... sergiusens should know [10:40] so udf would basilcy have to take the uboot.env and append the new bits from the oem snap (?) [10:40] out uboot.env with all the default config [10:41] if so I add a task for that to the card [10:41] well, the above is only the basic bit, with that we should have a good image to do the further work [10:41] ok [10:41] so the uboot.env will just load the snappy-system.txt (?) [10:41] i guess we *could* just put the snappy-system.txt content inside uboot.env at the snap level [10:41] I guess thats fine, we may even keep that if its just reading from that file, i.e. as long as we keep the system_ab and stuff out [10:42] i would like to get rid of all these scattered single files ... [10:42] the important part is that the uEnv.txt needs to no longer take the stamp into account and instead a new trail boot var [10:42] yeah, agreed [10:42] the question is, do we want that for 15.04 [10:42] or do we just want the very basic bits for 15.04 to not risk stability [10:43] thats a good question, my gut feeling is yes, the amount of churn is already pretty substancial, so best to have 15.04 and 16.04 in sync [10:43] (whouch would mean only snappy_ab and the stamp inside the env [10:43] ok, then we need udf involvement i thinnk [10:44] and either write the snappy-system.txt content to the uboot.env directly ... or have the file content in the snap (not sure why we dont have that currently, there might be a reason) [10:46] I guess the reason is to keep snappy-system.txt bits small [10:46] i'm a little curious what happens to the env settings that come from ATAGs ... once we call "saveenv" they will be stored in uboot.env [10:47] (MAC address and the like ... nothing that chnages anyway, but i wonder if uboot will get alon with them being already set) [10:47] ATAGs? [10:48] well, or values from the dtb ... not sure, but there are like 10 vars set by default even without any environment [10:48] aha [10:48] ok [10:48] and saveenv during the boot will save them in uboot.env [10:49] (and i dont thin there is something where you can only save a single var change to the environment, afaik it is all or nothing)+ [10:49] mvo: ogra_ that is automatic already (if the file is listed) [10:49] sergiusens, "that" ? [10:49] ogra_: uboot.env copy from udf [10:50] sergiusens, yeah, thats not the issue [10:50] sergiusens, we need to feed the content of snappy-system.txt into uboot.env [10:50] and afaik thats created by udf, no ? [10:50] ogra_: yes [10:51] so it needs to learn about that ... or we move snappy-system.txt content directly into the snap [10:51] ogra_: you should be able to override it by adding it to the gadget (and that would be supported in uprgades for rolling at least) [10:51] (meaning directly into uboot.env at creation time) [10:52] so i could ship an empty file ... and in parallel push the content into uboot.env [10:52] hmm [10:52] sounds doable [10:54] ogra_: this might put some stress in mvo's work into doing the right thing (TM) inside snappy on upgrades, but he's smart ;-) [10:54] yeah, snappy needs to modify uboot.env [10:54] instead of the txt files [10:54] hrm [10:55] ogra_: right, but it needs to save the snappy-system.txt values before overwritting it, that's all [10:55] and we need to completely re-write the whole logic of the snappy_boot command [10:56] sergiusens, we can just have "snappy_stamp_last", "snappy_ab_last" and "snappy_mode_last" vars if we need that [10:56] and have snappy store the values inside uboot.env too [10:57] i want to get rid of all additional files [10:57] at least for rolling (not sure we fcan for 15.04) [11:01] ogra_: do we need to change it all? grub is also doing it with a single env, it seems we can copy that behavior for now. and yes +1 for snappy_ab_last etc [11:01] ogra_: thats going to be needed anyway for the os/kernel snap work [11:02] ogra_, sergiusens: sound I need to write some uenv merge code, let me do that [11:05] mvo, whats "it" ? [11:05] do you mean snappy_boot ? [11:05] we need to et rid of the fatwrite call in it at least ... and also change the testing for snappy_stamp ... since it wont be a file but a variable value now [11:06] ogra_: right, there is a snappy_trial_boot env in grub, one sec and I give you the details [11:09] ogra_: ok, so grub works like this: on boot grub itself sets snappy_trial_boot=1 and the boot-sucesss command in snappy clears that [11:09] ogra_: we could simply do the same for uboot now, right? my branch for snappy implements this cleaning in uboot now too [11:09] yeah [11:10] i'm just preparing a snap with merged snappy-systerm-txt (and an empty .txt file) [11:10] silly question, whats the canonical location for uEnv.txt? [11:10] ogra_: coool! [11:10] (still using the old snappy_boot command though) [11:11] ok [11:11] * ogra_ wishes for faster dd [11:17] *twiddle* [11:17] yay, seems to boot [11:21] bah [11:21] sergiusens, udf doesnt seem to respect the empty snappy-system.txt file ... [11:21] i still have content in it [11:23] http://paste.ubuntu.com/11892317/ [11:23] sergiusens, ^^^ [11:25] * ogra_ empties it manually ... crosses fingers and reboots [11:25] looks like it boots [11:26] ogra_: k [11:26] geez ! [11:26] (BeagleBoneBlack)ubuntu@localhost:~$ cat /boot/uboot/snappy-system.txt [11:26] snappy_mode=regular [11:26] snappy_ab=a [11:26] still writes to it somewhere [11:26] ogra_: you need a new snappy which mvo is taking care of I gues [11:26] s [11:27] ah, it writes that file after boot ? [11:27] ogra_: yeah, with the snappy-boot task [11:27] k [11:27] or snappy booted [11:27] well, but udf needs fixing too [11:28] ogra_: yes; but it is going to be hard to fix as we need to support older images too :-/ [11:28] ogra_: that use that snappy logic [11:28] well, just make it not create the snappy-system.txt file if the snap ships it [11:29] that would be anough [11:29] *enouh [11:29] bah ! [11:29] ogra_: right, but think of 15.04 and creating older images which still use the older snappy logic [11:30] i only think of 15.04 here [11:30] ogra_: 15.04 rev 1 then [11:30] right [11:30] but there the snaps dont ship snappy-system.txt at all [11:30] so that should be safe [11:31] * ogra_ would really like to know why he only gets the colored "OK" output every second boot [11:31] ogra_: right, but if we replace it from u-d-f and the old snappy logic is in place, rollbacks and upgrades would be broken [11:32] hmm [11:34] where is the cannical uEnv.txt location? do we have that in git somewhere? [11:34] in the snap [11:34] (snappy-hub i think... ) [11:35] * ogra_ hacks the loading of snappy-system.txt out of uboot.env ... lets see if it gets along, then the content wont matter [11:36] and more dd fun ... [11:37] ogra_: try godd - it has a progress bar :) [11:37] mvo, and that makes it faster ? [11:37] :P [11:37] ogra_: weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeel [11:37] :D [11:38] ogra_: do you want me to build you a snappy with boot-success that uses snappy_trial_boot? [11:38] well, if that can write to uboot.env already [11:39] it can using fw_setenv, but I can make you a better (native) version I think that does not need /etc/fw_env.config [11:40] with your ned code ? yeah [11:40] *new [11:40] yep [11:42] ogra_: eh, sorry, I mean, whats the canonical location of snappy-system.txt ? i.e. the file that implements the actual logic? [11:42] mvo, on disk it is /boot/uboot/snappy-system.txt ... in udf i dont know [11:42] if this dd ever finishes i'll know if we can boot completely without it [11:43] ogra_: right, udf was the bit that I was looking for, thanks! i.e. in what version control system it is [11:43] thanks! [11:43] * sergiusens celebrates an exit status 2 on snappy install [11:43] looks good ! [11:43] sergiusens: you were on fire yesterday? so many branches [11:43] (the boot i mean) [11:44] mvo: well none are really ready for review, I just got scared that I'd lose my laptop somehow and have to redo stuff :-P [11:44] lol [11:47] i updated http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snap ... snappy-system.txt shouldnt be used at all anymore with that [11:47] (now we have snappy_stamp left) [11:48] near [11:48] neat [11:48] ! [11:48] so we shouldnt need changes to udf [11:48] (it is just ugly that the file sticks around but wont do harm) [11:48] * ogra_ notes it might be time for some breakfast [11:48] :P [11:49] brb [11:50] bah, crap, forgot the meerting ... no food for me then [11:54] ogra_: highly untested, but http://people.canonical.com/~mvo/tmp/snappy will use /boot/uboot/uboot.env to set snappy_ab, snappy_mode and snappy_trial_boot [11:56] mvo, i assujme i replace /usr/bin/snappy with that ? [11:58] ogra_: yes [11:58] [FAILED] Failed to start Notify bootloader that boot was successful. [11:58] [FAILED] Failed to start Run snappy firstboot setup. [11:58] [FAILED] Failed to start Run snappy compatibility hooks. [11:58] ogra_: uh, thats the amd64 build [11:58] ogra_: I need to give you the arm build of course [11:58] lovely :P [11:58] at least we know it still boots to a prompt even with broken snappy binary :P [11:59] ogra@anubis:~/datengrab/rpi/uboot/bbb$ file snappy [11:59] snappy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=faa20b2d15c5c16533f51239a2a517f78db36dd6, not stripped [11:59] heh, yeah [12:02] ogra_: armhf version is upload [12:02] ogra_: armhf version is uploading [12:02] cool [12:03] ogra_: try http://people.canonical.com/~mvo/tmp/snappy_armhf [12:07] mvo, looks good, no failures this time [12:08] ogra_: cool, will a binary that can dump the env help? [12:08] ogra_: to verify that it works? [12:08] (BeagleBoneBlack)ubuntu@localhost:~$ cat /boot/uboot/snappy-system.txt [12:08] (BeagleBoneBlack)ubuntu@localhost:~$ [12:08] and it didnt write to the file :) [12:08] yeah, that might help [12:09] i guess to test the whole update/rollback stuff i need to build a -1 image [12:09] (and even then i'm not sure i can actually update) [12:10] ogra_: http://people.canonical.com/~mvo/tmp/uboot-env-armhf [12:10] ogra_: that uboot-env-armhf /boot/uboot/uboot.env print [12:10] ogra_: hopefully works [12:13] (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|wc -l [12:13] 70 [12:13] mvo, looks good [12:14] ogra_: does the content look ok too? i.e. snappy_boot_trial is cleared (if you set it already)? [12:14] not sure a regular user should be able to run this :) [12:14] ogra_: and try is set back to regular? [12:14] ogra_: heh :) [12:15] mvo, http://paste.ubuntu.com/11892475/ [12:17] ogra_: that looks good can you try "uboot-env-armhf /boot/uboot/uboot.env set snappy_mode=try", then reboot, then see if the boot sets it to "snappy_mode=regular" after the boot? [12:17] (BeagleBoneBlack)ubuntu@localhost:~$ sudo ./uboot-env-armhf /boot/uboot/uboot.env set snapy_mode=try [12:17] panic: runtime error: index out of rang [12:17] ups, sorry [12:18] ogra_: that looks good can you try "uboot-env-armhf /boot/uboot/uboot.env set snappy_mode try" [12:18] has to be two args [12:18] doesnt work :( [12:18] same error? [12:18] (BeagleBoneBlack)ubuntu@localhost:~$ sudo ./uboot-env-armhf /boot/uboot/uboot.env set snapy_mode try [12:18] (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|grep ^snappy_mode [12:18] snappy_mode=regular [12:18] no error ... [12:18] uh [12:18] oh [12:18] bah [12:19] * ogra_ tries without typo [12:19] (BeagleBoneBlack)ubuntu@localhost:~$ sudo ./uboot-env-armhf /boot/uboot/uboot.env set snappy_mode try [12:19] (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|grep ^snappy_mode [12:19] snappy_mode=try [12:19] :) [12:19] works without PEBKAC [12:19] ;) [12:19] puhhh, I was scared for a minute === tedg is now known as ted === ted is now known as tedg [13:30] kgunn, another change we might want to consider making for Ubuntu Personal: Disable the automatic reboot [13:31] kgunn, just make the power button red or something [13:34] kyrofa: sorry...automatic reboot ? [13:34] kgunn, yeah, Ubuntu Core seems to be configured to automatically update and reboot. Which makes a certain amount of sense for embedded devices [13:35] kgunn, but I'm not sure how much sense it makes for Ubuntu Personal (which still seems to be configured that way) [13:36] seb128: ^ not sure who we'd talk to...i mean i guess this is based on our touch update technology, and it doesn't autoupdate/reboot afaik [13:38] kgunn, kyrofa, does it really make more sense for an embedded device? depends what the device is doing [13:38] kgunn, yeah, heads up-- first few times you fire up the VM and try to ssh in only to see "snappy autopilot triggered a reboot to boot into an up to date system" or "Going down for a reboot" it catches you a bit by surprise :P [13:38] if that's your car engine control you don't want it to reboot while you are driving :p [13:38] seb128, oh it certainly depends! [13:39] seb128, but I can see it making sense for a router or something. Keep it up-to-date and secure [13:40] seb128, if it was up to me, I'd definitely not make it the default on anything [13:40] seb128, but it seems to be that way on Ubuntu Core, at least for the time being [13:40] seb128, wait... maybe that's an edge thing? [13:40] kyrofa, even a router, it might be on a critical infrastructure that should get package cut even for 10 secondes [13:40] unsure [13:41] kgunn, seb128: This may be a non-issue if it's only on edge. sergiusens can answer for sure [13:43] seb128, agreed on the auto-updates. Tough to make that case [13:43] yeah [13:44] how can we turn it off? do you know? [13:45] kgunn: kyrofa seb128 I'd discuss the issue with the architecture team [13:45] snappy config ubuntu-core config_with_ap_disabled [13:46] do we have a way to ship a different default config on the image? [13:46] or a standard place in livecd-rootfs or such to call that [13:48] mvo, I know you're busy today, but if you have time, I have some snapcraft branches I'd love some action on [13:48] seb128: create your own gadget snap [13:48] seb128: and have u-d-f pull that in instead of generic-amd64 [13:48] just for that? [13:49] hum [13:49] that sounds like more work that the change is worth [13:49] kyrofa, kgunn ^ [13:49] seb128, hum indeed [13:49] gadget snaps are exactly for that, configs [13:50] seb128, depends on what's in generic-amd64 though. Might not be too bad [13:50] seb128: I bet you will diverge more (e.g.; seed in some preinstalled snaps) [13:50] seb128, yeah, we may need to do that eventually anyway [13:50] sergiusens, that's probably true yeah [13:51] seb128: the gadget snap is like the custom tarball on the phone [13:51] except that it is declared and not just overlayed [13:52] sergiusens, yeah, those are things I didn't look at so far and I've no clue about [13:52] so I guess it's a good time to learn about them ;-) [13:52] seb128: don't look too deep though, ricmm is redefining it all [13:53] k [13:53] seb128: some things may move back to the kernel snap (as we had it before) [13:56] mterry, So, did you have thoughts about editing the package.yaml in snapcraft? [13:56] mterry, It seems like something we're gonna need, and probably in a generic way. [13:58] tedg, how do you mean editing? [13:58] mterry, For instance having a plugin add a binary [13:59] mterry, But also adding the architecture [14:00] tedg, oh... I guess I imagined the user would explicitly add binaries and such they wanted -- it's hard to do automatically. There's caps and maybe calling the binary something different, etc [14:01] mterry, So Chipaca was thinking that the QML plugin would get the QML file, and then add a binary for it that was the execution of qmlscene. [14:01] mterry, I think that's a reasonable use case, and there'll probably be others. For instance if a plugin added tools. [14:01] ogra_: so to test if you get the fs corruption or not try image 3 from alpha [14:02] and update/rollback to image 5 [14:02] rsalveti, right, not completely done yet [14:02] wget http://people.canonical.com/~ogra/snappy/bootloader/beagleblack_1.9_all.snap && sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.9_all.snap --developer-mode -o bbb.img 15.04 ... then dd it ... [14:03] that gets you a setup which doesnt use snappy-system.txt anymore ... but we still need to re-work snappy_boot to remove the fatwrite and need to integrate mvos snappy changes [14:03] did we land the snappy changes from mvo? [14:03] not yet [14:03] right [14:03] and udf changes as well [14:03] i only managed to do an initial test before he left ... we'll work on it more once he returns [14:04] udf changes arent needed [14:04] only cosmetic [14:04] but might be good to manually test it with the alpha release, to know if all the work we did will indeed not cause the fs corruption we had [14:04] (teh file will be created but not used by anything) [14:04] tedg, so for that use case, we'd want an assemble_fixes() step or something? [14:04] right, once we have all bits ready i'll test alpha [14:05] mterry, Yeah, or perhaps the "snap_file()" command would pass the current YAML as an object. [14:06] mterry, So then everyone would update it and it gets written out once. [14:06] tedg, well there's more they might want to edit, like the apparmor stuff maybe? But for sure the yaml object is 99% case [14:07] tedg, I don't think it semantically fits with snap_files(), but it is the same step [14:07] tedg, edit_package()? [14:07] tedg, we also might want to version our plugin interface, btw [14:09] mterry, Yeah, I guess I figured it was the "final step" or perhaps with assemble. [14:09] mterry, Sure, but let's wait until we have plugins that aren't in tree. [14:10] tedg, no, snap_files() is actually called on 'snap' step, not 'assemble' one [14:10] mterry, Yes, I was more suggesting where it might edit the packaging. [14:11] tedg, ah. Well so far we only copy the metadata into place during assemble. But maybe we should actually do that during snap... [14:12] tedg, maybe all the bits in assemble should really be in snap, so the user can muck with everything in its final position/state [14:12] tedg, then assemble is truly just a snappy build call [14:13] good morning. [14:14] * mterry waves at elopio [14:16] is there a bug somewhere about gpio/i2c support that I can follow? [14:17] mterry, Yeah, that makes sense to me. [14:18] nuclearbob: there is not. [14:19] nuclearbob: only a mailing list thread and the promise by ogra_ that he will let us know when it's ready. You can file one. [14:19] well, and it is a broader thin ... [14:19] *thing [14:19] ogra_: if subscribing to the list is the best thing to do, I can do that [14:19] the bugs is "adding support for overlay devicetree files" ... [14:19] elopio: thanks [14:19] oh [14:19] that does sound broader [14:20] it is ... and rather complex, since we look for a generic way and the boards function differently [14:20] on my beaglebone I saw the /dev/i2c-0 [14:20] I'll play with that :) [14:20] i will have overlay support in the next rpi image (via manual hacks) but not yet on the beaglebone [14:22] okay, the rpi is what I'm looking for since I've got the orange matchbox [14:30] rsalveti, gah [14:31] so now i definitely know that fatwrite even messes up the uboot.env file [14:31] (BeagleBoneBlack)ubuntu@localhost:~$ ./uboot-env-armhf /boot/uboot/uboot.env print|grep ^snappy_mode [14:31] 2015/07/17 14:29:29 readUbootEnv failed for /boot/uboot/uboot.env: bad CRC: 4063564654 != 861698245 [14:31] * ogra_ forgot to take the fatwrite out before reboot [14:40] ogra@anubis:~/datengrab/rpi/uboot/bbb$ ls /media/ogra/system-boot/a/ [14:40] DTBS HARDWA~1.YAM INITRD.IMG VMLINUZ [14:40] rsalveti, btw, that looks like the root cause of our corruption ^^^^ [14:40] 8+3 ... [14:41] (after fatwrite ) [14:48] ogra_: sorry, what is the root cause? [14:49] so fatwrite even when writing to a known file is already enough to cause the issue [14:49] rsalveti, seems the driver used by fatwrite doesnt support long filenames [14:49] it actually does [14:49] that's a consequence of fsck.vfat I believe [14:49] so the a and b directory content names get rewritten [14:49] oh, ok [14:49] that doesn't happen all the time [14:50] sometimes it stays fine, but fsck creates a FSCK0000.REC file [14:50] Chipaca, so getting those modules added means my snap is now 190 MB [14:50] lovely [14:50] should we perhaps kick it out ? [14:50] ogra_: so it looks like a combination of fatwrite + fsck [14:51] tedg: hah [14:51] tedg: I win, then [14:51] tedg: you're copying too much stuff [14:51] Chipaca, I have fonts ;-) [14:51] so basically we got back to the initial issue [14:51] and might need some fatwrite debugging [14:51] well, as expected ... [14:52] as i said, i forgot to take out the fatwrite stuff before rebooting [14:52] i just find it interesting that it even kills the blob if used like we did [14:52] (this wont happen once we're done) [14:52] tedg: 70MB of fonts? [14:53] Chipaca, You can never have too many emoji [14:55] Chipaca: tedg put it in a squash [14:55] tedg: 👹 [14:55] +1 [14:56] squash as squash can ! [14:56] also � with a � of � [14:56] * ogra_ wonders whyt kinds of fonts you all use ... i only get broken chars here [14:57] ogra_: it's on purpose ;-) [14:57] ogra_: symbola + quivira cover most of the fun stuff [14:57] Chipaca: oh rly? [14:57] Chipaca: I thought this was a squashing pun :-P [14:57] fonts are already compressed, fwiw [15:03] ogra_: you just reminded me of my first 3d accelerator [15:03] ogra_: :) [15:03] haha ! [15:03] oh yeah, and the fun to get the dirver up [15:33] fgimenez: ugh, that 91 tests depends on the 90 test. Are you ok if I just remove both? [15:33] elopio, sure [15:33] 91 in this case will just do a fake update, which we already have. And the 15.04_to_rolling branch fully replaces 91. [15:35] elopio, yes, it's already covered [15:40] elopio, i'm preparing a branch with the changes to main.go and the template [15:41] fgimenez: not sure what you are talking about, but bring it on! [15:41] elopio, :) for removing the includeShell code, i'll push it shortly [15:41] fgimenez: I confirm that the RC test fails to reboot on latest rolling edge. [15:42] ogra_: is there anything I need to do? i.e. are you blocked on me currently? [15:42] elopio, yep i'll report it [15:42] fgimenez: oh, good. Thanks for mentioning it, I was about to do the same. I give you the honors :) [15:42] mvo, well, land your stuff ... nothing beyond that ... i'll try to get the script bits done before EOD today ... the rest on monday then [15:43] ogra_: ok [15:46] elopio, :) thanks, done [15:48] mvo, so when turning snappy_stamp into a boolean we should be fine i guess ? starting with snappy_stamp=0 ... having the boot script set it to 1 (instead of touching the file) ... who sets it back to 0 ? (whi was responsible for deleting it from disk ) [15:49] ogra_: yeah, its snappy_trial_boot=1 in grub, would be good to just mimick that [15:49] fgimenez: what do you think of moving all the tests to the tests directory? [15:50] ogra_: so grub itself sets snappy_trial_boot=1 i in its environment on boot and then the boot-script clears that value [15:50] if we have one single package, the filtering is easier. [15:50] mvo, for rolling for sure ... would we want to do that switch in 15.04 though ? [15:50] (reanming the var and all) [15:51] ogra_: hm, good question, my gut feeling is yes, its a bigger change but at least its the same code path as grub and 16.04. and it will be different in any case from the previous version so the more uniform the better I would say [15:51] elopio, mm at first we grouped them by the image they needed, hence the 'latest', 'update' packages, which translate to different binaries, i'm not sure if it's applicable yet? [15:52] mvo, ok [15:52] mvo: ogra_ just convert the 0-1 into a counter [15:52] fgimenez: oh, right. You'll have to read the 15.04_to_rolling first for this to make sense. [15:52] sergiusens, err [15:52] we'll talk about it on monday. [15:52] or is math not doeable in u-boot? [15:52] elopio, ah ok [15:52] it is but that makes everything more complex [15:53] ogra_: yeah, but we get counter failover which makes mvo happy ;-) [15:53] if test $snappy_stamp = 1; then ... [15:53] not for 15.04 though [15:53] thats pretty trivial to add [15:53] sergiusens, Chipaca: if one of you could review https://code.launchpad.net/~mvo/snappy/snappy-bootsuccess-env/+merge/264981 - that would be very cool, that would unblock ogra_ [15:53] * Chipaca looks [15:54] mvo: not enough cleanup [15:54] :-P [15:54] sergiusens: followup branch ;) [15:54] * sergiusens jokes [15:54] mvo: oh, lol [15:55] sergiusens: but totally agreed, there is so much more we can do now [15:55] dont ask me about go ... looks fine to me but that means nothing :P [15:55] fgimenez: if you just leave a return at the end of a function, it will find the values it has to return? [15:55] elopio, if they are named in the signature yes [15:56] that is impressive. [15:56]