[00:00] been beating my head against the wall for 3 hours now [00:00] Operation not permitted [00:01] trying to launch docker inside of my snap [00:14] elopio: there's a hackish way to generate an image with a new snappy, I can show you; not that complicated [00:25] sergiusens: show me please. === chihchun_afk is now known as chihchun === chihchun_afk is now known as chihchun === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [07:13] good morning === erkules_ is now known as erkules [08:30] mvo, doko pinged me if we are aware about the gcc 5 transition ... [08:31] ogra_: how does it affect us? [08:33] mvo, no idea ... [08:34] i just found that PM ping from last night :) [08:35] ogra_: fwiw, I'm just looking at the uboot source, aiui the plan is to use saveenv on the fat partition, correct? if so we may hit the same issue :/ both cmd_fat.c:do_fat_fswrite() and env_fat.c:saveenv() use the same file_fat_write() code. we may be lucky of course because we keep rewriting the same cluster with saveenv :) just wanted to mention it that we need to be extra careful [08:35] ogra_: well, we don't have any c++, maybe he just wants to says that it might be bumpy? but then its all done in a silo, so… [08:36] yeah [08:36] well, do we use the go compiler ? [08:38] we do for arm64 [08:38] but aiui we already use gcc5 for go [08:38] ah [08:40] mvo, well, if the env file in fat doesnt work we could still resort to a raw env partition ... but i'd like to see that as last resort due to the complexity it adds to the partitioning [08:40] Hi [08:40] Good morning all; happy Corn Fritters Day! 😃 [08:41] ogra_: yeah, I am confident it will work ifwe ship a 1k (thats the env size, right?) pre-populated env file [08:41] right, but if it doesnt we still have options :) [08:41] Does anyone work on Beaglebone Black Device tree overlay development? [08:42] ogra_: so looking at the u-boot code it seems like all its doing is adding a 32bit crc plus a 8bit flags header, the rest is just char data. [08:42] ogra_: want me to write a c-program that can deal with that? or will you do that, either way is fine, just offering help where I feel like I can be useful [08:42] mvo, you mean to edit it from userspace ? [08:42] ogra_: yeah [08:43] yeah, sure ... one sec i can give you an existing env file (from rpi) ... [08:43] ogra_: oh, thats awsome [08:44] ogra_: what is your prefered interface? just something like "uboot-env load" dump on stdout, uboot-env save file" read from stdin and save to the given file? [08:44] either that or a file converter with a txt file as option [08:46] mvo, http://people.canonical.com/~ogra/uboot.env [08:46] ta [08:50] Mohammads, yes, but no ETA yet [08:58] ogra_: silly question, how did you generate the inital version of the file? [09:00] mvo, i actually used lool's file ... but afaik you just create a txt file and use mkimage (from uboot-tools) to add a header [09:00] ogra_: nice, I explore that, thanks [09:03] ogra_: yay, I think I found all I need, will give you some stuff in some minutes (or hours, depends how it goes :) [09:03] heh, no hurry, i'll need a few hours myself still :) [09:06] mvo: there's a fw_printenv / setenv in u-boot-tools [09:06] i thought that doesnt work ? [09:06] I had a perl script to create env files too, but not sure where I've put it [09:06] (didnt you say that yesterday ? ... ) [09:06] ogra_: hmm it might be mtd only [09:06] ah, no that was sergiusens [09:07] lool: yeah, thats the one I found and was trying to use [09:07] lool: it does support vfat afaict [09:07] lool: at least the examples do [09:07] thre are other tools out there worst case [09:07] yeah, its easy enough to write one [09:07] http://free-electrons.com/blog/mkenvimage-uboot-binary-env-generator/ [09:07] but fw_* is my current approach [09:07] ah I remember now, the tool will work on files if it's built without CONFIG_MTD [09:08] someone in the comments claims: [09:08] mkimage -T script -C none -n 'setenv-name' -d u-boot.env u-boot.env.img [09:08] should work [09:08] lool: it works for me on my BBB afaict, tested it some minutes ago [09:08] ogra_: that's surprizing [09:09] lool, yeah, well, not sure he is just guessing :) [09:28] lool: is there a reason that mkenvimage is not included in the u-boot-tools? it seems to be what we need. if you don't mind I will upload that to wily and send a patch to debian (unless there is a good reason not to have it) [09:30] mvo: grr, I hate the fact I didn't check the u-boot tree earlier [09:31] mvo: I suspect it's not in the package just because the debian package was created before the tool was added [09:31] lool: no worries, I will upload and push patch unless you want to commit directly to the debian tree [09:31] mvo: yes, please do upload this [09:31] lool: sure, thats fine, thanks! [09:32] lool: http://paste.ubuntu.com/11886878/ [09:32] ogra_: do we have a trello card for the env work? I would like to add a checklist so that I don't forget the steps I need to do :) [09:35] mvo, hmm, i dont think so [09:35] where would that go ? snappy-core-roadmap ? [09:35] ogra_: I create one, hope I'm not too hyperactive in the morning, had strong tea today [09:35] ogra_: work-in-progress would be my guess === timchen1` is now known as timchen119 [09:39] mvo, created a card and added you [09:39] ogra_: \o/ [09:47] ogra_: I added a checklist, would be great if you could check if it makes sense [09:48] mvo, why do we need to modify snappy-system-txt to use getenv ? [09:48] (if we move away from it anyway) [09:48] ogra_: I don't know, if that does not make sense, kill it, its my ignorance speaking [09:49] well, we should keep it as is until we drop it i thionk [09:49] ogra_: I thought we do it in two steps, keep snappy-systems.txt initially and use the env and then move it all into the env [09:49] ogra_: but if that does not make sense, thats fine [09:49] i dont think that needs any modification in snappy-system.txt (i need to check though) [09:49] aha, even better [09:49] just adjust the checklist as needed :) [09:50] (you have a better overview about this I think) [09:50] yeah... i need to try first though, lets keep it (with a more generic text) [09:51] * mvo nods [09:53] hmm, how do i move an item [09:54] hah ! [09:54] drag n drop ... crazy stuff [09:55] :) [09:55] * mvo gets lunch [09:56] ogra_: I will add the /etc/fw_env.config to livecd-rootfs after lunch for armhf [09:56] does it work ? [09:57] (did you try the fw_* commands on teh file yet) [10:07] ogra_: lool mvo nice to know that it works. For the record I tried fw_saveenv way back on the first iteration of the bbb port and didn't work and remember lool giving me a fancy explanation of why and did not look into it anymore :) [10:29] ogra_, sergiusens: it seems to be working: http://paste.ubuntu.com/11887048/ [10:30] mvo, well, does it also work on a uboot prompt :) [10:30] oh, I have no idea, let me try. I though this way around was the problem [10:30] but yeah, smells like it could work fine [10:30] note the current uboot on BB wont load the file [10:30] (thats what i'm working on atm) [10:31] you can use it on a rpi though [10:31] mvo: ogra_ nice, when I played with this I wasn't using a uboot.env file though :-) [10:31] ah [10:38] mvo: nice [10:47] * lool lunch & [10:48] sergiusens, erm [10:48] ogra@anubis:~/datengrab/rpi/uboot/package/u-boot-2015.04+dfsg1$ ls -l /media/ogra/system-boot/ [10:48] insgesamt 4 [10:48] drwx------ 3 ogra ogra 512 Jan 18 11:31 a [10:48] drwx------ 3 ogra ogra 512 Jan 18 11:31 b [10:48] -rw-r--r-- 1 ogra ogra 1596 Jan 22 06:05 snappy-system.txt [10:48] -rw-r--r-- 1 ogra ogra 237 Jan 18 11:31 uEnv.txt [10:48] where exactly is our uboot ? [10:49] (its not in a or b either [10:49] ) [10:51] (dont tell me we dd it raw somewhere [10:51] ) [10:52] I think we do, but sergiusens will confirm [10:52] bah [10:53] ogra_: fwiw, this u-boot env will make the bootloader code more similar so massive opportunity for cleanup here, I love that soooooo much [10:53] :D [10:53] i.e. MarkCurrentBootSuccessful is now identical in boot uboot/grub :-D [10:53] * mvo will push a MP soon [10:56] mvo: consider we need to backport some things to 15.04 (the file copy part at least) [10:56] sergiusens: yeah, the backport is tricky, how do we create /boot/uboot/uboot.env on existing systems :/ [10:56] ogra_: u-boot and slp are dd'ed instead of file copied per lool's recommendation [10:57] mvo: if our update provides the latest snappy update again soonish and it would be picked up [10:58] sergiusens, do you have the lines we use for that (offset etc) [10:58] ogra_: look in the package.yaml for the oem package [10:58] is there a bzr tree ? [10:58] ogra_: yes sir [10:58] ogra_: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/beagleblack/meta/package.yaml [10:59] thx [11:02] hmm, that doesnt work :/ [11:02] (dd does, but the board doesnt boot) [11:07] ogra_: for using dd https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard [11:08] ogra_: don't truncate :-P [11:08] well,. thats what i'm using [11:08] ogra_: compile u-boot for arch == armhf? :-P [11:09] lol [11:09] * sergiusens asks ogra_ some very random dumb questions [11:09] very funny :P [11:11] sigh [11:11] aha [11:12] sigha [11:12] S2 and reset doesnt work at all ... it only works if you actually make the board powerless [11:12] ogra_: isn't that documented? [11:12] * sergiusens thought it was [11:12] at least i have it now booting to a uboot promot with my own build [11:12] I did that dance with power cycling [11:12] might be that it is documented :) [11:14] morning [11:15] sergiusens: hm, we would have to convert the existing uEnv.txt, no? i.e. we can not just ship a static file to existing systems (?) [11:15] ogra_: snappy is ready now too, but I did not do further cleanups, I wait for an end-to-end test to ensure this all works first :) [11:23] MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 [11:23] reading uboot.env [11:23] ** Unable to read "uboot.env" from mmc0:1 ** [11:23] Using default environment [11:23] \o/ [11:23] ogra_: yeah, uboot is in a raw partition [11:23] same for mlo [11:23] ugly :P [11:24] * ogra_ puts his rpi uboot.env in place for a test [11:24] mvo: yes we would [11:25] mvo: sergiusens: we can't easily update running 15.04 systems right? [11:25] because of the upgrader issue (running the upgrader from the older image) [11:25] MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 [11:25] reading uboot.env [11:25] *** Warning - bad CRC, using default environment [11:26] hmpf [11:26] oops [11:26] but at least: [11:26] U-Boot# saveenv [11:26] Saving Environment to FAT... [11:26] writing uboot.env [11:26] done [11:26] aha [11:27] and after reset [11:27] MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 [11:27] reading uboot.env [11:27] Net: cpsw, usb_ether [11:27] Hit any key to stop autoboot: 0 [11:27] so the uboot.env file we use for the rpi doesnt work ... [11:27] which indicates they are not generic :/ [11:28] (and that we might have to create the initial file using the uboot prompt ... thats rather suboptimal) [11:30] well, dump the file and check for the header [11:30] and the format [11:37] crap [11:37] so lool's raw initrd support breaks it [11:37] as soon as i enable that uboot hangs [11:38] with it disabled everything seems to work [11:41] ogra_: I can send you a uboot.env that I created via mkenvimage from uEnv.txt if you want [11:41] mvo, well, i still need a working binary first [11:41] sure [11:45] mvo, ok, i got something booting, gimme the file :) [11:50] ogra_: http://people.canonical.com/~mvo/tmp/uboot.env [11:50] ogra_: that i sa version of the stock uEnv.txt [11:50] 403 [11:50] (forbidden) [11:51] ah, better [11:51] ogra_: I can create one with both snappy-system.txt and uEnv.txt too, or you can do it yourself via "mkenvimage [11:51] ogra_: ups, try again [11:51] mkenvimage -s 0x4000 -o uboot.env snappy-system.txt [11:51] from u-boot-tools in wily (not sure if its published yet) [11:51] but I'm happy to do that until it is :) [11:52] MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 [11:52] reading uboot.env [11:52] *** Warning - bad CRC, using default environment [11:52] nope ... [11:52] doesnt work [11:53] mvo, these three work together http://people.canonical.com/~ogra/snappy/bootloader/ [11:54] (though uboot.env is just a "saveenv" dump on the uboot prompt) [11:54] (README has flashing instructions) [11:55] see if that file is usable with your fw_* setup [11:55] ogra_: hm, thats suprising that it gives a crc error [11:55] rsalveti: snappy should have the logic for the next update to be successful and have the correct uenv and uboot.envs .. we don't have logic to update the bootloader, but that can be added [11:55] well, i can try again [11:56] sergiusens: right, but would just be fixed on a following update [11:56] ogra_: let check the source, I wonder if there is something funny here [11:57] rsalveti: correct [12:01] ogra_: could you try a updated version? [12:01] ogra_: just pushed it to the same place [12:01] sure [12:02] mvo, still bad CRC [12:02] meh, thanks [12:03] * ogra_ melts [12:08] mzanetti, yesterday you suggested I add -mousetouch to /usr/share/upstart/sessions/unity8-dash.conf to get be able to drag the dash scopes drawer up. I assume that's supposed to go on the exec line? Does it matter where? I can't get it to work [12:11] mvo, hmm, i get the crc error with fw_printenv too http://paste.ubuntu.com/11887435/ [12:11] ogra_: could you try the latest again? this seems to be ok for me via fw_printenv: http://paste.ubuntu.com/11887439/ [12:12] ogra_: I have not tried uboot itself yet though [12:14] MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 [12:14] reading uboot.env [12:14] *** Warning - bad CRC, using default environment [12:14] nope ... [12:14] meh [12:14] fw_printenv also shows me the CRC error [12:14] oh [12:15] (thouh i have a slight werid setup) [12:15] ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot$ cat /etc/fw_env.config [12:15] ./uboot.env 0x0000 0x4000 [12:15] I use: [12:15] root@localhost:/boot/uboot# cat /etc/fw_env.config [12:15] /boot/uboot/uboot.env 0x0000 0x4000 [12:15] on the bbb [12:15] kyrofa, let me try [12:15] well, i use it on my desktop [12:16] (my BBB cant boot atm) [12:16] mvo, oh, and your MP has an error ... .conf vs .config [12:16] ogra_: hm, so the boot crc is on the rpi? I wonder if some configure option is different? [12:17] mvo, no, the CRC error is in uboot on the BBB [12:17] and on my trusty PC when using fw_printenv [12:18] ogra_: meh, ok [12:18] heh [12:18] ogra@anubis:/media/ogra/system-boot$ fw_printenv [12:18] Cannot access MTD device /media/ogra/syst: No such file or directory [12:19] that is when i give it the full path [12:19] (in fw_env.config ) [12:20] kyrofa, doesn't work indeed [12:20] well, even mounting in /mnt and adjusting the path doesnt help [12:20] I guess that touch->mouse conversion only works for X11 [12:21] mzanetti, hmm.... interesting [12:21] mzanetti, any idea what would be involved to make it happen? [12:21] kyrofa, I guess it might be possible to change the dconf key for favorited scopes [12:21] kyrofa, so that they show up by default [12:21] mzanetti, ah, that's a good workaround [12:21] other than that, you could launch the scopetool [12:21] -rwxr-xr-x 1 root root 131072 Jul 16 14:11 uboot.env [12:22] mvo, ^^^^ [12:22] i think the size is our issue [12:22] my saveenv'ed file is way bigger than yours [12:22] -rw-rw-r-- 1 ogra ogra 16384 Jul 16 14:11 uboot.env [12:22] thast is yours for comparison [12:22] ogra_: eh, 100k? thats a bit much [12:23] well, thats the whole saevenv dump [12:23] ogra_: what else is in there? [12:23] i could show you if i could scroll in screen ... but many many lines :) [12:23] mzanetti, unity-scope-tool? [12:23] (the default env isnt actually smnall) [12:24] we would have to use the defaults anyway so we should adjust the size [12:24] 100k is a lot, thats not exactly fits-into-a-single-cluster :/ [12:25] http://paste.ubuntu.com/11887481/ [12:25] well [12:25] Environment size: 3862/131067 bytes [12:25] its not actually 100k [12:25] kyrofa, yes [12:25] (the file is, but the content is 3k) [12:26] ogra_: do you happen to know what is the ENV_SIZE for the bbb? or maybe lool? [12:26] could be that i defined that in my patch, one sec [12:26] maybe thats the issue that the board is configured with a different one than what I set [12:27] hmm, no, i dont [12:27] 44 /* Always 128 KiB env size */ [12:27] 45 #define CONFIG_ENV_SIZE (128 << 10) [12:27] for the bbb? [12:27] yes [12:27] thats the default [12:27] (usually that lives on the eMMC) [12:28] i guess i can try going down to 16k [12:28] ogra_: that would be cool [12:28] ogra_: it seems like the ENV_SIZE is hardcoded for the loading/crc calculation, so either I need to increase the size to make the 128k or you need to decrease it, either way is fine with me [12:29] ogra_: maybe I increase ? thats probably quicker than the recompile(?) [12:29] mzanetti, not /com/canonical/unity/launcher, right? Those are the only favorites I see [12:29] kyrofa, no, that's the launcher [12:29] the panel on the left [12:30] no clue where the scopes settings are tbh [12:30] kyrofa, tsdgeos will know [12:30] mzanetti, right. That's all that's under /com/canonical/unity, though [12:31] mzanetti, alright, I'll ask him when he gets in. Thank you! [12:31] kyrofa, he's in... just not in this channel [12:31] seems the wrong one for this discussion anyways :) [12:31] mvo, ok, 16k works [12:32] mzanetti, meh... Ubuntu Personal... snappy... :P [12:32] ogra_: \o/ [12:32] oh well... as far as I'm concerned we're working with click still [12:33] hmm, or not [12:33] :( [12:33] that was the wrong file [12:33] reading uboot.env [12:33] *** Warning - bad CRC, using default environment [12:33] using your file [12:34] bah [12:34] and saveenv still creates a 128k file [12:34] even though i lowered it in the config [12:35] ogra_: any luck with http://people.canonical.com/~mvo/tmp/uboot.env4 with the default config? [12:35] let me try [12:36] ogra_: thats with -s 131072 [12:36] MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 [12:36] reading uboot.env [12:36] *** Warning - bad CRC, using default environment [12:36] nope [12:37] seems to only work right if i create it with saveenv [12:37] at the uboot prompt directly [12:37] bä [12:37] can you actually read and modify my file ? [12:38] ogra_: could you put that somehwere so that I can compare the headers? [12:38] * ogra_ suspects fw_printenv does simply not do the right thing [12:38] but it really should be just the crc :/ [12:38] i did ... 30min ago ... [12:38] http://people.canonical.com/~ogra/snappy/bootloader/ [12:40] mvo, i dont think it is bad to pre-create the file (from an empty env via uboot's saveenv) ... but we still need to be able to modify it and add stuff then [12:46] ta [12:46] let me try [12:47] mvo, oh, how do you build mkenvimage ? [12:48] ogra_: it gets build as part of the nomral package build, I did not change that, just added it to debian/u-boot-tools.install [12:48] it seems to use the crc32.o object from the actual uboot build [12:48] which might perhaps differ between versions/builds [12:50] ogra_: hm, I can't read your file fw_printenv gives me "Read error on /boot/uboot/uboot.env: Success" [12:52] ogra_: hm, I see in the envfile that you use U-Boot 2014.10-dirty ( - i use the uboot from the archive for the fw_setenv etc [12:52] ogra_: I wonder if that might play a role? [12:52] it could [12:52] i'm just trying to build mkenvimage here [12:55] nope, CRC error even with my own mkenvimage [12:56] mvo, well, i use the same base that lool used for the uboot we currently use ... which is upstreqams tree with 2014.10-dirty branch [12:57] * ogra_ needs some fresh coffee ... brb [12:57] elopio: your question from last night http://paste.ubuntu.com/11887593/ [13:01] ogra_: I'm a bit lost, I don't get the crc errors, I will look at the source some more [13:02] mvo, it loads the file on boot for you ? [13:02] (with my MLO and u-boot.img from the above url) [13:03] mmm coffee [13:03] (i dont really care so much if *my* fw_printenv works or my mkenvimage ... but i get the CRC error on boot when it loads it) [13:05] ogra_: I haven't flashed it yet, I was poking with fw_printenv so far only on the bbb [13:05] ogra_: that is the image iwth the 128k, right? [13:05] mvo, yeah [13:06] mvo, so rsalveti suggested we dump both files and compare them ... (checking header with hex editor or some such) [13:10] hmm, so in a hex editor i see the official file is filled with 00 ... while the one you created is filled with FF [13:10] and neither of them seems to have any header [13:10] s/filled/padded/ [13:10] ogra_: there should be 4byte of crc on each [13:11] ogra_: let me check [13:11] ogra_: I can change the padding to 00 [13:11] yeah, thats the only difference i see [13:11] oh, wait [13:12] there is indeed a 4 byte header [13:12] ogra_: this is what I see, it seems like there is one additional byte in yours [13:12] ogra_: let me try to create one with this extra padding [13:15] ogra_: I guess http://people.canonical.com/~mvo/tmp/uboot.env5 is still no good? [13:16] * ogra_ humps mvo's leg [13:16] http://people.canonical.com/~mvo/tmp/uboot.env5 [13:16] err [13:17] http://paste.ubuntu.com/11887669/ [13:17] ogra_: ohhhhh? [13:17] ogra_: sweet [13:17] mvo, so that works ... now the tricky part ... lool's setup is additive toi the default env (which we just wiped) ... [13:17] so we need to put all the defaults into your env file [13:18] ogra_: and make fw_setenv work again, that seems to be not working now for me with that file :/ I will dig into it [13:18] mvo, did you adjust the size in the .config file ? [13:18] I did [13:18] indeed that needs to match [13:19] root@localhost:/boot/uboot# fw_printenv [13:19] Read error on /boot/uboot/uboot.env: Success [13:19] which is funny, I mean, no crc error and the error code is "success" [13:19] I think it wants to make fun of me ;) [13:19] well, they want you to think positive, even in frustrating moments ;) [13:24] ogra_: it might be short reads, I will add debug [13:28] mvo: I've seen similar bugs in u-boot before where the error is not bubbled up correctly :-( [13:28] but at least it makes you feel good [13:33] seb128, you want the snappy scope landing in wily, not the overlay, correct? [13:33] kyrofa, correct [13:35] lool: yeah - just building it is a pita [13:35] (to add my debug stuff) [13:36] mvo: you can cross-build relatively easily, but yeah the tools build is ugly [13:36] good morning. [13:36] you can't just make -C tools, or similar, the build system is too custom [13:37] you can make all [13:37] lool: thats what I mean, I get all sorts of strange error [13:37] wotks fine here [13:37] *works [13:37] mvo: I tend to clean every thing with make mrproper between each build [13:37] ogra_: did you do the menuconfig dance first? is there a shortcut for this? [13:37] (reconfigure with make boardname_defconfig, make, make tools or similar) [13:38] aha, make tools [13:38] I need to try that [13:38] i just run "make -j4 CROSS_COMPILE=arm-linux-gnueabihf- O=uboot-bbb.bin all" [13:38] I think that's what I used to use, not sure anymore [13:38] that gets me the tools in uboot-bbb.bin/tools/ [13:38] ah it does exist but so does a cross_tools target [13:39] and yeah, mrproper and "make CROSS_COMPILE=arm-linux-gnueabihf- O=uboot-bbb.bin am335x_boneblack_config" before each build [13:40] btw, this is my config patch http://paste.ubuntu.com/11887776/ [13:41] (i guess i could leave out the ifndef/endif bits) [13:42] lool, interestingly the boot hangs if i put the CONFIG_SUPPORT_RAW_INITRD at the top of the file ... reliably [13:42] sergiusens: can you tarmac machine start a vm in canonistack? [13:44] sergiusens: and thanks for the paste. With that, I'm now not really sure if we need the full rootstock build. [13:44] will talk about that with ogra_ once Federico returns. [13:45] elopio, yeah, sorry, rootstock work is a bit on hold while i hack on the uboot fixes [13:45] i'll hopefully have time tomorrow aain [13:45] *again [13:46] ogra_: don't worry, what I'm saying is that it's probably not needed. [13:46] or well, it would be nice, but the extra info and security it will give is might not be worth it. Lets talk again before you spend your time on it. [13:47] ogra_: its funny (for some value of that) http://paste.ubuntu.com/11887823/ [13:48] mvo, twice ? [13:48] ogra_: so fw_*env uses the exta padding byte only if its in a HaveRedundEnv mode [13:48] (the line in you config file) [13:48] ogra_: yes, once is not enough [13:48] ogra_: thats what makes it work [13:48] lol [13:48] * ogra_ tries [13:48] ogra_: don't ask why, this is from reading the source, the source does not tell me what the rational for this is [13:49] i think because NAND has two env partitions by default ofr some such weridness [13:50] ogra_: that sounds reasonable, still, having a different head that is impossible to know what sizeit will have from looking at it, *not good* [13:50] elopio: no worries. Can canonistack be reached from external servers? The other thing we can do is just put that tarmac instance on canonistack and free up my server ;-) [13:50] yeah [13:50] ogra_: like - you know - having the first byte for header size and then tools could figure it out [13:50] sergiusens: yes, to both. [13:50] anyway, sorry for ranting [13:50] elopio: let's discuss after standup then! [13:51] sergiusens: you would need credentials for your server to access canonistack, so I think moving the server to canonistack would be better. [13:51] mvo, ranting in context of uboot is allowed and expected [13:51] we just need to make sure that we have an easy way to redeploy it, because things seem to die suddenly on canonistack. [13:52] ogra_: it also does not make any sense, only the last entry counts [13:52] ogra_: in the config [13:53] heh [13:56] hm, thats actually incorrect, it will read/write both it seems [13:56] * mvo shakes head [13:57] just re-implement it in go ;) [13:57] without all the mess [13:57] ogra_: thats actually a really good idea, I will do that [13:57] ogra_: probably quicker too [13:57] HAHAHAHA !!! [13:58] (that was definitely not meant serious ... but if it helps :) ) [14:01] mvo: I'm sure you're in love with the u-boot code base by now! :-) [14:01] elopio: time you learnt juju then :-P There's a tarmac charm fwiw [14:01] lool, how could anyone not be ! [14:01] sergiusens: why not? throw it to the pile of things to learn :) [14:02] should be easy. We just need your tarmac config, give it to juju, and profit. [14:04] lool: indeed [14:04] lool: it still boggles my mind [14:04] haha [14:05] mvo, now you know how all of us arm hackers got into this mental state ;) [14:05] lol [14:06] elopio: https://jujucharms.com/u/tanuki/tarmac/trusty/0 [14:06] also - /etc/fw_env.config - wuuuuut? how about fw_printenv -f /boot/uboot.env ? [14:06] I mean, seriously?!? [14:06] would be lovely [14:06] elopio: but it seems to be more popular on precise https://jujucharms.com/u/canonical-ci-engineering/tarmac/precise/29 [14:07] sergiusens: no precise please. [14:07] I can try both. [14:09] seb128, I could use a terminal in the Ubuntu Personal image. It doesn't seem that I can install the one from the click store? [14:09] kyrofa, no clue about that [14:09] don't ask me [14:09] I usually ssh in [14:09] or switch to a vt [14:09] Me too... but I need the dbus session variables [14:10] grep SSH in /proc/pidof unity8-dash/environ [14:10] then export [14:10] seb128, ah, I always forget that trick === charles is now known as jordan [15:00] Can snaps have symbolic links now? They used to not be able to [15:06] yes [15:06] mterry: we fixed that before 15.04 release, i think :) [15:07] I think 15.04 itself is symbolic! [15:08] ur-symbolism ftw [15:26] plars: I'm interested on that u-d-f to glance you mentioned. [15:27] did you find anything? [15:27] kgunn, quick update, since you were helping me on this: the touch-only areas don't seem to work with -mousetouch on mir [15:28] elopio: oh right, sorry I forgot to send you that [15:28] kgunn, so to test other scopes you need to add them to the "favorites" list manually, with gsettings set com.canonical.Unity.Dash favorite-scopes [15:28] elopio: I think it's mostly here: https://launchpad.net/snappy-proposed-image-builder [15:28] elopio: you can talk to the ci team, not sure what their future plans are with that service [15:29] plars: good, thanks! [15:29] kyrofa: ah, man that kinda stinks [15:30] kgunn, yeah it does. Although the usability of the sliding drawer with a mouse kinda sucks anyway. Will that be changed a bit eventually for windowed mode? [15:31] yeah, i think we should [15:31] kyrofa: we're putting some time in on windowed mode, lemme see if it's something we can do [15:39] kgunn, awesome. I'm not aware of other "touch areas" in unity8, but I'm sure there are some. We obviously need to figure out how to work with those, even if it's something as simple as making -touchmouse work on mir [15:39] kgunn, which may not be trivial, I'm not sure [15:45] kgunn, Ubuntu Personal may be in a bit of a tough spot. Correct me if I'm wrong, but we envision it being used on both mouse- and touch-driven devices, yes? [15:47] kyrofa: yep, this is just lack of design input, but mzanetti just made some noise...and we got the general ideo [15:47] idea [15:47] close enough that we can add something in the near term [15:47] (while design designs) [15:48] kgunn, cool! [16:17] ogra_: https://github.com/mvo5/uboot-env-go needs some love and better cmdline parsing but works [16:18] kgunn, kyrofa: this should help: https://code.launchpad.net/~mzanetti/unity8/unity8-clickable-bottom-edge-hint/+merge/265019 [16:18] mvo, sexy ! [16:18] mzanetti: curious, is it something we can land ? e.g. should only show up in windowed mode [16:18] yep [16:18] cool [16:19] ogra_: yes, dinner time now :) [16:19] kgunn, visuals don't change at all. The label arrow is clickable with a mouse (not with touch) [16:19] ogra_: but the other stuff will also work, so I hope you are not blocked, lets continue tomorrow [16:19] mvo, same here ... and i might not return today ... [16:19] yeah [16:19] enjoy! [16:19] ack [16:19] you too ! [16:21] mzanetti, quick work man, thanks! [16:22] kyrofa, np. please let me know if you notice and oddities [16:22] kyrofa, it's not perfect, the label will hide when scrolling (as per touch design) but while it's there you can click it an open the overview [16:23] mzanetti, yeah, that's fine to get us up and running a bit better :) === alexabreu is now known as alex-abreu [18:01] * mterry works on java snapcraft plugin [18:36] sergiusens, tarmac seems to have not gotten to https://code.launchpad.net/~mvo/snapcraft/python3-project/+merge/264521 after 4 hours (it's usually faster, right?) is there a problem with the branch or am I just impatient? [18:40] mterry: no commit message I'd guess [18:40] rsalveti, duh of course. I want an error for that [18:41] rsalveti, that's fine, I found a nit anyway :) yay for not merging yet [18:41] cool [18:58] mterry: yeah, mvo uses lp-propose which tells you it's setting a commit message when in reality it is setting a description :-) [19:27] * mvo adds commit message