/srv/irclogs.ubuntu.com/2015/07/20/#snappy.txt

=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
fgimenezgood morning07:11
longsleephey folls is there any docs other than the trello about the upcoming u-boot changes. I want to try as early as possible for the ODROID-C1.08:02
ogra_mvo, oh, does your uboot-env command need fw_env ?08:03
ogra_longsleep, i'll write it up once we're done08:03
* ogra_ just noticed the livecd-rootfs upload ... i thought we dont need that with the go tool08:04
longsleepogra_: ok - is that happening soon? I need to check about the fw_* commands right?08:04
mvoogra_: my uboot-go work does not, the current branch is based on fw_setenv/fw_printend08:04
ogra_mvo, i think we should switch over08:05
mvoogra_: I can move forward to the native go version, iirc the missing bit was that I need to implement a gettenv for a single var, thats easy to add08:05
mvoogra_: sure, I work on this now08:05
ogra_mvo, is the snappy-hub branch the actual branch we buiold the beaglebone snap from ?08:06
longsleepfw_setenv is a different command from setenv, fw_printenv different from printenv right?08:08
ogra_the fw_ ones are userspace commends you run from a running system08:09
longsleepoh08:09
longsleepthats good information thanks :)08:09
ogra_but they are rather buggy ... thois is why https://github.com/mvo5/uboot-go exists ... and i think we'll use that instead08:09
longsleepi see - and where is the stuff stored? Question is what does my u-boot need to load such a file?08:10
ogra_longsleep, here are my notes http://paste.ubuntu.com/11893737/08:11
ogra_the uboot.env file just sits on the vfat partition next to the empty uEnv.txt file08:11
longsleepogra_: i see thanks. But the uboot.env needs to be loaded somehow. Do you know what feature that is in u-boot config?08:12
ogra_we merge all env settings into a sinlge file and get rid of the scattered config that spans across multiple ones08:12
ogra_longsleep, see line 908:13
longsleepogra_: super - thanks i think i got it08:13
ogra_getting the exact initial env was a bit tricky ... some env vars get set from dtb values or atags, you need to make sure they are not pre-set in your .env file08:15
longsleepogra_: my u-boot loads a file called boot.ini - so i guess i could just load the uboot.env from there.08:15
longsleepogra_: see here: https://github.com/longsleep/snappy-odroidc/blob/master/oem/boot-assets/boot.ini the current script08:15
ogra_what i did was: booting with an empty .env file ... that gets you the dtb or atag values ... then boot with a broken .env file and run printenv in the uboot shell ...08:16
ogra_that printenv with the vars from the first step removed was my base08:16
ogra_and to that i added the vars from snappy-system.txt and uEnv.txt08:16
ogra_(plus "snappy_trial_boot")08:17
longsleepthat sounds complicated - these values come from u-boot tree for the particular hardware right?08:17
ogra_yes and i'm not sure they get overwritten if they are inside the enc08:17
ogra_*env08:17
ogra_which is why you should exclude them08:18
ogra_witzh the uboot patch your ini file can be empty08:18
longsleepright08:18
longsleepthat is worth a try08:18
ogra_all environment will be read from uboot.env08:19
longsleepassuming my u-boot tree supports CONFIG_ENV_* / checking now08:19
ogra_thats a pretty generic function08:19
ogra_(usually used to write the env to a raw space on the SD or NAND though)08:19
longsleepyeah lots of grep matches08:19
longsleepso that looks good08:20
ogra_great08:20
longsleepso for testing i could just create a uboot.env manually and see if i can boot with only that?08:20
ogra_yeah08:20
longsleepgreat - let me try that08:20
longsleepogra_: when looking at your .evn file. Lots of values seem to be not required. Did you check already what can be cleaned up?08:22
ogra_longsleep, no, i actually use the complete default env from uboot up to now ... not sure if we want to clean it up (to not lose any features)08:26
longsleepogra_: makes sense - at least if loading the .env file undefines already defined stuff08:29
ogra_right08:29
ogra_it is loaded before anyting else so if you wanted you could still put overrides in boot.ini or uEnv.txt (whatever you use)08:30
longsleepdepends when the boot.ini is loaded - it is a custom patch from aml doing all kind of stuff ..08:31
ogra_as i said, uboot.env is loaded immediately on startup ... before anything else08:32
longsleepok08:32
=== erkules_ is now known as erkules
longsleepwell - my u-boot tree does not have CONFIG_ENV_IS_IN_FAT :-/08:38
ogra_bah08:38
longsleepjust checking when this was added08:38
ogra_it muste be really old08:38
ogra_i remember using it years ago on pandabaords08:39
longsleepthe tree i have to use is from early 201308:39
ogra_(pandaboard went out of production in 2012)08:40
longsleepmhm :)08:40
longsleepyou are right - added 2012-03-3008:41
longsleepso i shoud have it ..08:41
longsleepbut the whole file is not there in my tree .. damn!08:41
longsleepthis is the commit - just for the record: http://git.denx.de/?p=u-boot.git;a=commit;h=57210c7cc363cf2a2a28010658c7ea67388f8d2108:42
ogra_well, at least it should be easy to apply08:42
longsleepyes looks easy08:43
JamesTaitGood morning all; happy Monday, and happy Space Exploration Day! 😃09:08
mvoogra_: http://people.canonical.com/~mvo/tmp/snappy_armhf <- thats a updated version that uses the new native go uboot env handling code, if you have a moment, would be great if you could give it a go (I only tested via unittests so far09:25
mvoogra_: next I will do a bit of code cleanup and write code to import files like the existing snappy-system.txt09:26
ogra_you mean on updates ?09:31
ogra_mvo, the file is still sourced by uboot, so with the first "saveenv" the content should show up in the uboot.env ... what we need to make sure is to check it matches the uboot.env content and then empty it (so it doesnt get sourced again)09:33
longsleepwell seems like my u-boot created a uboot.env file after saveenv and next boot seems to have loaded it without error09:56
ogra_awesome !09:57
ogra_you should be able to use tools/mkenvimage though ... to pre-create it from a txt file09:58
longsleepyeah09:58
ogra_(line 16 in http://paste.ubuntu.com/11893737/)09:58
longsleepchecking the u-boot side first - patching was messy09:58
ogra_:(09:58
longsleepi could not cherry pick cleanly09:58
longsleepogra_: so the source for your uboot.env is the new-Env.txt file ?10:01
ogra_yeah10:01
ogra_but that indeed includes the BBB default env ... i assume you want to create your oown from scratch10:02
longsleepok let me see where i get this tool - or do you recommend to use https://github.com/mvo5/uboot-go instead?10:02
longsleepmkenvimage was added to u-boot in http://git.denx.de/?p=u-boot.git;a=commit;h=a6337e6ffdea211e70dd8d6c638f6a5ec2295400 - i guess i can cherry pick that one or use the other tool10:04
* longsleep tries the go tool first10:06
longsleepwell uboot-go says bad CRC when trying to print the file created by saveenv10:16
longsleepat least it is consistent - u-boot says bad CRC when loading a uboot.env created by the uboot-go :)10:21
ogra_yeah, not good10:21
longsleepogra_: did you try that too and have the same issue?10:22
ogra_no, works fine for me ... but mvo develops on the BBB (and i try on the BBB) so that proves nothing10:22
longsleepmhm - i might have an older format of the file. Let me upload it for you somewhere.10:23
ogra_note that i'm using the armhf version *on* the BBB10:24
longsleeparmhf version of what?10:24
longsleepuboot-go ?10:24
ogra_of the go tool10:24
longsleepmhm there should not be any difference in go no matter what arch10:24
ogra_http://people.canonical.com/~mvo/tmp/10:25
longsleepok let me try that build10:25
mvolongsleep: the uboot env format is "funny". its either 4 byte  (crc) or 5 byte (crc+flags)10:27
longsleepmvo: any idea where i could quickly upload the env file?10:28
mvolongsleep: it seems like the flag is for "redundant" envs, but thats just a theory from reading the u-boot code, maybe your thing expects a different header10:28
mvolongsleep: hexdump -C uboot.env|head is probably enough for me for now, just pastebin that :)10:28
longsleepmvo: well i cherry picked and hacked around the env fat code so it might well be a u-boot issue as well10:29
longsleepmvo: ok hold on10:29
longsleepmvo: http://paste.ubuntu.com/1190855610:30
mvolongsleep: for the 5 bytes image you need to pass mkenvimage -r iirc (redundant). plus the size must exactly match the size that is compiled into the uboot binary (but I guess thats all no news for you :)10:30
mvolongsleep: joy, looks like you have a 4 byte header10:30
longsleepmvo: that is news - i had no idea about .env format before today10:30
longsleepi do not even have mkenvinmage yet as this is newer than my uboot :)10:31
longsleepbut the size triggers a bell10:31
mvolongsleep: heh :) ok, I can tell you all I know, its going to be quick ;)10:31
mvolongsleep: so header is important (either 4 or 5 byte). size must match exactly the one thats compiled in, then it should work (tm)10:32
longsleepi have CONFIG_ENV_SIZE (32 * 1024)10:32
longsleepis that the size you mean?10:32
mvoyes10:32
longsleepand CONFIG_ENV_OFFSET (512 * 1024)10:32
longsleepthat might be a problem?10:32
mvoI'm not sure, I *think* (but could be totally off) that this is ignored when writing to fat files10:33
* longsleep checks the code10:33
longsleepseems so as its not used in the FAT code. CONFIG_ENV_SIZE is used10:33
mvogreat!10:33
mvolongsleep: the uboot.env from the pastebin, was that created using saveenv from your uboot prompt?10:34
longsleepyes10:34
mvohm, I wonder if there is a way to get a 5 byte header there as well. would be nice if it would be all the same on all ports10:35
mvobut I can probably add auto-detect magic to my go-code, but its a bit ugly, something like "if isAscii(content[4])" which feels …wrong10:35
longsleepassuming that my file is supposted to work then yes - but i thought you have a 4 byte header as well?10:36
mvowe have a 5 byte header but I have not yet figured out why, I don't know if its maybe a config option in the uboot build, maybe ogra_ knows. its seems releated to "redundant"  env10:39
mvowhatever that means10:39
longsleepmvo: i do not know either, no redundant what so ever related to env in my build config for u-boot.10:40
longsleepmvo: if you want to have the complete file: https://www.stdin.xyz/downloads/people/longsleep/tmp/uboot.env-odroidsaveenv10:42
mvolongsleep, ogra_ do you have CONFIG_SYS_REDUNDANT_ENVIRONMENT in your build config?10:44
mvothat seems to be the magic configuration10:44
ogra_ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot-latest$ grep CONFIG_SYS_REDUNDANT_ENVIRONMENT configs/am335x_boneblack_defconfig10:45
ogra_ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot-latest$10:45
ogra_nope10:45
longsleepmvo: grep shows nothing in u-boot that - so does not seems so10:45
mvoups, sorry, typo on my side :(10:46
mvoCONFIG_SYS_REDUNDAND_ENVIRONMENT10:46
mvo-^10:46
longsleepthat matches but i do not have it set10:47
ogra_nope, not either10:47
mvoogra_: not set either10:47
mvohmmmmm10:47
longsleepit also seems only be used in env_embedded10:47
longsleepand in envcrc10:47
longsleephold on10:47
mvofor me (current u-boot git) it defines the size o fenv_t10:48
mvoi.e. typedef struct environment_s {} env_t10:48
mvobut nevermind, I am pretty sure I can do the auto-detection magic, reading the code further, content[4] is either 0 or 1 when its a 5 byte header and its ascii if its a 4 byte header, so auto-detect should work10:49
mvoon reading at least10:49
mvowriting is a different matter, need to add flags or something10:50
mvoogra_: but why we do not set it really confuses me, i.e. how we end up with a long header10:50
ogra_i have no idea10:50
mvoogra_: could you pastebin our config? maybe its somehow derrived10:51
longsleepi just pushed my u-boot branch https://github.com/longsleep/u-boot-odroidc/tree/odroidc-configfat10:51
longsleepthats the tree i have to use10:51
longsleepmvo: what file is that with the size?10:52
* ogra_ grumbles about sergiusens sending messages i cant open10:52
longsleepenvironment.h found it10:52
* mvo gets lunch10:53
mvolongsleep: include/environment.h is it for me that defines the header size10:53
longsleepmvo: yeah i see it - maybe that has changed in later uboots10:54
* mvo nods10:54
longsleepmvo: see https://github.com/longsleep/u-boot-odroidc/blob/odroidc-configfat/include/environment.h - i will compare as well10:54
* longsleep gets lunch too10:55
mvolooks similar at first glance10:55
mvooh - CONFIG_ENV_OFFSET_REDUND10:55
mvolooks like it might be a derrived config value10:55
longsleepthat REDUND stuff looks like a big mess10:57
longsleepbut anyhow - i agree that you should only end up with a 5 byte header when REDUNDAND_ENVIRONMENT is set10:57
=== EllieGoulding is now known as plop_its_ellie
longsleepmvo: just to confirm, when changing headerSize to 4 in your env.go the odroidc file parses just fine11:55
longsleepogra_: i think the reason why your u-boot has 5 bytes header and mine has 4 bytes needs to be found.11:57
ogra_yeah, i need to check on the RPi too11:57
longsleepogra_: http://paste.ubuntu.com/11908839/ is the uboot.env default content - if you want to compare with yours12:00
zygahi12:03
zygaI'd like to have a bit of web service12:04
zygaand I'd like to register my service to avahi12:04
zygaso12:04
zygashould I bundle avahi (seems wrong)12:04
mvolongsleep: great to hear that it works with that header size12:04
zygaor should I start to work on a avahi.framework?12:04
zygamvo: hey :-)12:04
mvohey zyga12:04
ogra_zyga, you should bundle avahi12:04
mvolongsleep: and yeah, I need we need to figure out whats going on :)12:04
zygaogra_: but how can that work if there can be only one avahi server on a host12:04
zygaogra_: one to bind to the magic port12:04
zygaogra_: it's a system-level feature12:05
ogra_zyga, there was some planning that user installed snaps can override that12:05
zygaogra_: two apps cannot both bundle avahi (server)12:05
* ogra_ remembers some discussion on the ML12:05
zygaogra_: can you explain how this would work ?12:05
ogra_no12:05
ogra_but i know that the expectation was that you bundle it12:05
ogra_and that the preinstalled avahi goes oout of your wa<12:05
zygaogra_: mmm, so I don't get it, if I do my snap with avahi server I effectively prevent all other snaps from doing that12:05
ogra_way12:05
zyga?12:05
zygais there a preinstalled avahi?12:06
ogra_no idea12:06
ogra_yes, webdm ships avahi12:06
zygahmm, does it?12:07
zygaI don't see that here12:07
ogra_yes12:07
mvolongsleep, ogra_: lets try to get to the bottom of this, if all else fails I add the auto-magic, but I hope I don't have to do this12:07
ogra_well, and that wouldnt help on "create"12:07
longsleepmvo: well the question is how is the initial .env file created.12:08
zygaah, so snappyd has an avahi server inside?12:08
longsleep+is12:08
zygahmmm, I still don't get how this can work with more than one app12:08
mvolongsleep: indeed, you guys need some default values in there right? that come from the default_env of the uenv code?12:09
ogra_longsleep, preferably indeed by your mkenv tool12:09
ogra_from the tools dir12:09
ogra_that should give you the right header for your uboot12:09
longsleepyes all kinds of stuff might need to be set in addition to snappy boot logic12:09
mvolongsleep: I have go code that can read a key=value\n file and create a uboot.env but I don't know about the initial defaults. I wonder if mkenvimage helps here12:09
ogra_yes, it should be compiled with the righ defaults for your specific build12:10
longsleepwell the default could be provided in the oem package12:10
longsleepthe problem is how and where does the snappy boot logic get triggered12:10
ogra_i assume some devices will adapt all that stuff to a possible NAND that we dont use12:10
longsleepin ogra_ 's file he does it with uenvcmd12:10
longsleepthat only works because his defaults run this macro in bootcmd12:10
longsleepin my file this will have to be totally different12:11
ogra_all devices use snappy_boot12:11
ogra_your bootcmd should already be adjusted for this12:11
longsleepthe bootcmd should directly load snappy_boot ?12:11
longsleepyours loads uenvcmd12:11
ogra_which the loads snappy_boot12:12
ogra_*then12:12
longsleepso you say that the defaults should somehow end up loading snappy_boot?12:12
longsleepi am good with that12:12
ogra_the final env needs to be a merger of all the former snappy- files uEnv.txt and the default env12:12
longsleepright12:12
ogra_like you used it before ... just now merged12:13
longsleepi was not using uEnv.txt before - so it might be a bit different12:13
longsleepi was using boot.ini to set stuff12:13
ogra_well, but for rollback and stuff you used snappy-system-txt12:13
ogra_*.txt12:13
longsleepright12:13
ogra_so your boot.ini somehow pulled in and called snappy_boot12:14
longsleepcorrect12:14
ogra_which has the logic12:14
ogra_right, so now, just do the same :)12:14
longsleepyes i can do it manually i get that12:14
ogra_just not scattered across multiple files12:14
longsleepthe question is how to automate it12:14
longsleepor make it generic12:14
ogra_your initial txt file should have it12:14
longsleepok - so that is still shipped by the OEM snap or whatever there is in the future12:15
ogra_yes12:15
ogra_uboot.env will be shipped12:15
ogra_in your snap12:15
longsleepthen the 4 or 5 byte problem should be none as well12:15
longsleepthe tool just needs to keep the header size as the same12:15
ogra_right, if mvo can autodetect it and we can just rely on mkenvimage we should be all fine12:16
longsleepmkenvimage - that tool is a problem - i would prefer the go version from mvo12:16
ogra_i wouldnt like to generalize here since it might break the ability of a board to actually use the NAND12:16
ogra_in case you want to switch to that we shouldnt break your defaults12:17
ogra_mkenvimage guarantees that your env file will be readable for sure though12:17
ogra_(for u-boot at least)12:17
longsleepcorret - but this would be created on OEM snap building right? So that tool is a build requiredment12:17
ogra_yeah12:18
ogra_well, its is a req for your port12:18
longsleepah - the .env file needs to be changed on update too - you want this to be done by the mkenvimage tool as well?12:19
ogra_will ave to go into the porting documentation (once we have such a thing :P )12:19
mvoogra_: how would it break nand when we use the go version? just curious? mkenvfile can only create a file afaics12:20
ogra_mvo, it could break NAND if we enforce a certain header in the u-boot build ... not in the go version12:21
mvoogra_: oh, sure, the go version will be able to deal with both headers, thats for sure, same way as mkenvfile with a flag12:21
longsleepah yes - thats true - but we do not neede to enforce the header. Just make the go tool support 4 and 5 bytes and keep the size on change12:21
ogra_what mkenvfile creates could be written to nand12:21
mvobut no worries, using mkenvfile is fine12:21
mvoI just wanted to understand if there is anything I need to support for NAND12:22
ogra_yeah, i think thats the safest option12:22
ogra_no12:22
ogra_and we dont plan to support it atm ... but i want us to not break the potential use of it either :(12:22
ogra_err12:22
ogra_:)12:22
longsleepso you propose to ship mkenvfile as pat of a snappy system and use this tool to modify .env files?12:23
longsleeps/pat/part12:23
ogra_no12:23
ogra_i propose to ask porters to use it to create their initial uboot.env file12:23
ogra_when they do their u-boot.img build12:23
longsleepok thats fine12:24
longsleepand for updates use the go tool?12:24
ogra_for our purpoose the go binary should be fine12:24
longsleep+112:24
ogra_jusr not for the initial creation (unless we have a header -zize option or some such and know exactly which board needs which header size)12:24
longsleepwell the developer should know, i am not so sure that the mkenvfile will know either as it needs to be compiled exactly with the same config.12:25
ogra_right, which is what i simply assume when you build your u-boot tree12:26
longsleepogra_: ok - i guess this is a valid assumption12:27
ogra_(especially since you need to patch it anyway for the uboot.env support i would expect you to recompile it)12:27
longsleepogra_: by patching you mean enabling the defines in the board configuration?12:29
ogra_right12:29
longsleepogra_: i thought newer uboots have a config file for this instead of header files12:29
ogra_oh,, do they ?12:30
* ogra_ hasnt heard of that 12:30
longsleepi think so, i had some troubles backporting stuff because of this change12:30
longsleepyes12:31
longsleepsee http://git.denx.de/?p=u-boot.git;a=tree;f=configs;h=ff6b998c4ffa4e9da3ab367141156391d5fcad3d;hb=HEAD12:31
ogra_what about that ? that has always been the config dir12:32
longsleepno - not in my tree12:32
longsleepall the defconfig stuff is rather new12:32
ogra_ah12:32
* ogra_ remembers using it for beagle XM installs years ago 12:33
longsleepwell arm u-boot is so messy, but the diff you use for BBB also does not seem to use it as your change is in a header file - or maybe i get it wrong12:34
longsleepogra_: well ok - it uses both, earlier it was only includes. Never mind.12:35
ogra_yeah, it now includes the includes :)12:36
ogra_they changed the structure a bit12:36
longsleepi thought it was easier to change compile settings without patching in a bunch of defines12:37
longsleepmvo: uboot-go seems to have another setting for headerSize as it seems to create 5 bytes headers even with headerSize set to 412:38
* ogra_ tried a static kodi build on the weekend to use it in snap and click packages ... 12:41
mvolongsleep: oh, let me check12:41
ogra_seems building something static as soon as pytjhon is involved becomes a major pain :(12:41
longsleepthats why you use Go :)12:42
ogra_longsleep, doesnt help when wanting to build some nonn go thing like kodi (xbmc)12:42
ogra_obviously i can only build it as static binary if i also have a static python i have to build myself12:43
ogra_such a mess .(12:43
longsleephaving a kodi snap would be pretty awesome12:43
mvolongsleep: I'm fixing this right now, give me some minutes, I will yell once I have a fix12:44
longsleepmvo: awesome thanks12:44
ogra_well, i was more after a click :) but yeah, rolling a snap at the same time shouldnt be hard12:44
longsleepwhat is a "click" - i think i missed something12:44
ogra_longsleep, the predecessor of snap12:48
longsleepogra_: oh - seems i have missed that12:49
ogra_it is what we use on the phone12:50
* longsleep tries to compile mkenvimage12:53
ogra_just "make all" ;)12:53
longsleepnah - had to backport it into my u-boot :)12:54
longsleepbut seems like it compiled12:54
Chipacaanybody here on 14.04, to try the mir snap in virt-manager?12:55
longsleepogra_, mvo - i think i just might have found why you have 5 bytes headers12:56
ogra_because we are the cooler kids !12:57
ogra_:P12:57
longsleepin your example you have -r parameter to mkenvimage - i guess that means redundant12:57
longsleep"the environment has multiple copies in flash"12:57
ogra_right, and without -r we get CRC errors12:57
longsleepok :)12:57
ogra_so the uboot binary expects the 5 bytes12:57
mvolongsleep: if you git pull from my uboot-go repo it should hopeflly work, no auto-detection yet though, you still need to set the header size manually, I add that in the next commit12:58
longsleepmvo: cool / i will try in 2 minutes12:58
mvono rush12:59
mvoI'm here for at least 3h12:59
longsleepok with the old version i can read a 4 bytes file created with mkenvimage13:00
longsleeplets update13:00
longsleepstill works with updated version13:01
longsleeplets see if i can create13:01
longsleepmvo: yes works - cool13:01
mvoyay13:01
mvoyay^213:01
longsleeplets try to set something :)13:01
longsleepset works too now - now the boot test13:02
ogra_yippies13:02
longsleepmvo: works like a charm13:03
ogra_\o/13:04
longsleepogra_: and you were right, uboot.env removes all previously loaded defaults13:04
longsleepi now have essentially only foo=bar in the environment13:04
ogra_yeah13:04
longsleepbut thats something - i think i could get the odroidc platform boot fine with this ne scheme13:05
longsleepnew13:05
ogra_just think about the kids^WATAGs ...13:05
ogra_(respective handed through dtb settings)13:05
mvolongsleep: there is now also "import" to read from key=value files13:05
longsleepmvo: oh let me try that13:06
longsleepmvo: yeah works fine as well13:07
longsleep(note that i have changed headerSize to 4)13:07
tedgI don't see an updated Mir in my updates, is there a way to check the store to make sure it's not my local system being broken?13:14
Chipacatedg: what's up/down?13:15
ogra_was a newer Mir uploaded to the store yet ?13:15
ogra_you can use uappexplorer13:15
Chipacatedg: ah, you mean the snap?13:15
ogra_(unless that now filters snaps)13:15
Chipacatedg: bzr branch lp:~mir-team/mir/snappy-packaging && cd snappy-packaging && make && echo YEAH13:16
tedgIt was in the store, just need a newer version. Which kgunn said he was uploading on Friday.13:16
tedgI need to know whether it's my fault or not before I complain :-)13:16
Chipacas/echo/notify-send/13:16
tedgChipaca, Sure, just trying to get everything working "out-of-the-box"13:16
ogra_https://uappexplorer.com/app/my-world.testsnappy ... doesnt filter it seems13:16
ogra_so if a new snap is uploaded it should show up in https://uappexplorer.com/apps13:17
ogra_(usually sorts newest first)13:17
tedgI can't find the original in uappexplorer, because it's a framework?13:17
Chipacaprobably13:17
Chipacawhat version do you see?13:18
tedgsnap113:18
ogra_ah, right, a search for docker doesnt return anything13:18
ogra_hmm, just because i searched wrongly13:19
ogra_https://uappexplorer.com/app/com.ubuntu.snappy.docker13:19
ogra_https://uappexplorer.com/apps?sort=relevance&type=snappy13:19
ogra_that actually lists all snaps13:19
tedgStill don't see Mir though.13:19
ogra_only 59 :(((13:19
tedgkgunn, Where you able to get Mir uploaded on Friday?13:20
kgunntedg: i did, altho, prolly just in store review queue...lemme check13:20
mvolongsleep: silly question, how terrible would it be for you to enable this redundand option? or is that not availalbe at all for your version of uboot?13:21
kgunntedg: ah...says published, so snappy search should say snap1.113:21
longsleepmvo: good question - can give it a try13:21
longsleepmvo: i guess i would be fine if it does not break anything13:22
kgunntedg: lemme know if you have issue with install13:22
tedgHmm, no. I don't see it. And neither does uappexplorer. https://uappexplorer.com/app/mir.mvp-demo13:23
tedg(finally found it there)13:23
* longsleep compiling u-boot with CONFIG_SYS_REDUNDAND_ENVIRONMENT13:24
ogra_tedg, yeah, weird that uappexplorer doesnt list it at all13:25
longsleepmvo: seems to work just fine - now i get CRC error with 4 byte env file13:27
tedgWe may need to ping the store.13:28
longsleepmvo: saveenv just worked fine and it seems to load the file it just created13:28
ogra_4 byte is so last build anyway :P13:28
longsleephehe13:28
mvoyay13:28
ogra_moar bytes !13:28
longsleepnow let me create a new 5 byte file13:28
tedgCould someone check with a "snappy search mir" on their device and see if snap1.1 is available to them?13:29
ogra_not here13:29
ogra_no neither of my armhf devices13:29
ogra_but i guess that is because kgunn is a lazy guy and only built for x86 :)13:29
tedgOkay, thanks ogra_13:29
tedgOh, I want it for amd64, so I'm happy there :-)13:29
Chipacatedg: no mir for amd64 here either13:30
longsleepmvo, ogra_ : Seems like i do not care if its 5 or 4 byte header - i can do both :)13:30
ogra_cool !13:30
mvolongsleep: then go with 5 ;)13:30
mvomakes our life easier13:30
ogra_5 is the future !13:30
longsleepmvo: all right - just make sure to add it to the docs that one needs to set CONFIG_SYS_REDUNDAND_ENVIRONMENT13:31
longsleepand that typo will give problems for sure ;)13:31
mvoheh13:33
tedgkgunn, Can you check your store page again to make sure it's published? And then we'll look to see what happened.13:35
kgunntedg: so on myapps.developer.ubuntu.com/dev/click-apps/?format=snap i see mir snap1.1 and it says "published" with a little green bubble13:36
kgunntedg: or do you mean some other way of checking ?13:36
kgunntedg: ah...wait, there's another page13:37
ogra_yeah, the public appstore13:37
kgunntedg: "current approved version" snap113:37
ogra_(it is a community project using the store api ... might be an api bug and beuno's fault that we dont see it)13:38
tedgkgunn, Do you approve or do we need a store approver?13:39
tedgIs that a popey thing?13:39
ogra_thats likely a review thing13:39
popeyi can13:39
popeyif in stores13:39
kgunnpopey: yeah, i uploaded friday13:40
tedgpopey, You can trust kgunn for this, he's a manager, but it's okay. ;-)13:40
kgunnlol13:40
popeyhah13:40
* kgunn grabs steel ball and rubber hammer to show them13:41
popeykgunn: not confident approving this. I really only approve clicks right now. might need to wait for jdstrand ?13:49
ogra_yeah, just estimate a few months for the review ... non click apps can take long :P13:50
ogra_(just re-pack as click and popey will let it through ;) )13:50
kgunnpopey: np, jdstrand should be on soon13:50
kgunntedg: ^ ...so waiting now13:53
tedgYeah, glad we figured out what the issue is though. Now I can move to track down others :-)13:53
longsleepogra_, mvo: Seems that i can release the u-boot changes already as everything works as before as long as where is no uboot.env file13:57
mvoyay!13:57
longsleepif there is such a file, it completely takes over13:57
longsleepand whatever new behaviour jumps in13:57
ogra_yeah, the new behavior is the part we're still working on13:58
ogra_(on the snappy side)13:58
ogra_(and i need to prepare an MP for the snappy-hub tree for the default BBB env)13:59
longsleepright - i just wanted to check possible u-boot issues on my end as early as possible. So for now i am good as everthing seems to work and i might eventually even be able to remove some of the FAT backports i had to do.14:00
ogra_yeah14:01
ogra_thats our evil masterplan :) getting rid of writing files to fat14:01
longsleepvery good plan14:02
longsleepI merged it to master of my u-boot tree: If you are interested in the changes i had to backport https://github.com/longsleep/u-boot-odroidc/compare/odroidc-0.2...master14:03
jdstrandbenoitc: fyi, server error going to https://myapps.developer.ubuntu.com/dev/click-apps/reviewer/14:15
jdstrandbenoitc: nm14:15
jdstrandbeuno: fyi, server error going to https://myapps.developer.ubuntu.com/dev/click-apps/reviewer/14:16
jdstrand(tab fail)14:16
jdstrandbeuno: OOPS-0393df0da7284ccf8501cfb761c0ce4d14:16
beunojdstrand, oh-oh14:22
beunonessita, ^14:22
nessitabeuno, ack, seems like we have some issues with the quarantined apps14:23
nessitajdstrand, one sec, we're removing the troubling apps14:24
=== chihchun is now known as chihchun_afk
nessitajdstrand, do you need to review a specific app?14:26
* ogra_ bets the one you just removed :)14:28
=== tvoss is now known as tvoss|afk
jdstrandnessita: I was going to look at the mir one14:31
ogra_mvo, if i only had any clue on go ... then i would approve https://code.launchpad.net/~mvo/snappy/snappy-snappy-bootsuccess-env2/+merge/26525914:31
mvoheh14:31
mvoogra_: Chipaca will have a look I'm sure14:32
ogra_yeah14:32
nessitajdstrand, so until we fix the review you can workaround like this: search for the app in https://myapps.developer.ubuntu.com/dev/click-apps/search/14:32
longsleepogra_: In the new uboot.evn approach - do you have already any ideas wher ethe snappy_boot macro comes from? Am i supposed to add this there myself?14:33
nessitajdstrand, then go to the package details of the desired app https://myapps.developer.ubuntu.com/dev/click-apps/2811/14:33
nessitaand  append /review/ to the url: https://myapps.developer.ubuntu.com/dev/click-apps/2811/review/14:34
ogra_longsleep, yes14:34
ogra_longsleep, your uboot.env needs to be a merge of boot.ini/uEnv.txt (whatever of the two your device uses), the default env and the snappy-system-txt content14:34
longsleepogra_: Great thats good, as i currently have to overwrite it.14:34
nessitajdstrand, sorry for the trouble but we're working right now on fixing it14:35
longsleepogra_: Understood thanks14:35
ogra_since snappy-system.txt is created by ubuntu-device-flash you need to pull the original content from a former install i fear14:35
ogra_(and then apply my changes to snappy_boot)14:36
ogra_(mainly getting rid of fatwrite and using a variable)14:36
longsleepogra_: well i think it just needs to be documented what env variables are changed on update and the boot scripting then needs to use them14:36
longsleepogra_: right now i think, on update just snappy_mode will be changed14:37
longsleepogra_: and whatever scripting happens needs to check that and toggle root to a or b14:37
ogra_well, snappy_boot holds essentially the whole logic for updates/rollback/reboot14:37
longsleepogra_: yes - i guess that macro needs just to be documented. Though what is currently shipped does boot a initrd zimage14:38
jdstrandnessita: no worries and thanks :)14:38
longsleepogra_: my u-boot can only boot uimages14:38
longsleepogra_: thus i had to overwrite the whole macro14:38
ogra_right, so you need to adjust for that14:38
longsleepogra_: but if the macro goes into oem domain then this is fine14:38
ogra_hmm14:38
ogra_snappy_boot doesnt use initrd or uninitrd anywhere14:38
longsleepat the end it calls bootz does it not?14:39
ogra_ah, right14:39
ogra_so yeah, you need to change it to bootm14:39
longsleepyes14:39
ogra_we should probably push that out of that line and define it elsewhere14:39
longsleepwell - if the whole thing gets owned by the image creator then it does not matter14:40
ogra_snappy_default_bootcmd=bootz ${loadaddr} ${initrd_addr}:${initrd_size} ${fdtaddr} ...14:40
ogra_then you can more easily re-define it to be bootm14:40
ogra_without hacking the actual command14:40
longsleeptrue - the more modular the better14:40
nessitajdstrand, review UI fixed! :-)14:41
jdstrandnessita: that was fast! :)14:43
nessitajdstrand, faster than expected, yeah (we managed to fix a package in a inconsistent state instead of having to wait for a new deploy)14:46
p_lorenzhi - is there already a snappy image for the raspberry pi 2 which does not have the random mac address assigning bug? ( @ogra_ ?)14:48
ogra_p_lorenz, nope, the next 15.04 image will have that ... but the image itself got delayed due to another bug14:51
ogra_(we had planned to release it last week, but that didnt happen yet and i can only build the actual RPi image once the image is out)14:52
=== nyx_ is now known as moonwalk
tedgjdstrand, Were you able to approve the mir snap?15:14
=== JamesTai1 is now known as JamesTait
jdstrandtedg: not yet but am working on it15:22
tedgjdstrand, Cool, thank you!15:22
=== zyga_ is now known as zyga
fgimenezrsalveti, while at the writable paths test i've found what seems to be an error, the path for /etc/NetworkManager/system-connections is missing the leading slash http://paste.ubuntu.com/11909810/15:53
hallynhi - there's an open bug about updating a package's config file (/etc/lxc/lxc-usernet) from another package (phablet).  phablet wants to add an entry.  What would be the proper way to do that, given that lxc-usernet is ro?15:54
hallyn(bug 1475751 fwiw)15:54
ubottubug 1475751 in lxc (Ubuntu) "need phablet support for mods to /etc/lxc/lxc-usernet (vivid+stable ppa overaly)" [High,New] https://launchpad.net/bugs/147575115:54
fgimenezrsalveti, it seems to be in the previous line, where should i report this?15:55
jdstrandtedg: can someone request a manual review for mir?16:04
jdstrandtedg: I've reviewed it, but I can't accept it until someone does that16:04
jdstrandkgunn: ^16:05
kgunnack looking16:05
kgunnjdstrand: hmmm, not apparent how i do that....i see the failure due to unconfined and framework16:08
kgunnbut i don't see how to ask for a manual review16:09
kgunni see i can make a comment on the failures...?16:09
kgunnjdstrand: do i need to "unpublish" ?16:10
jdstrandkgunn: no. maybe it was the link I went to. I got there via another means and can see that I can approve16:11
jdstrandkgunn: since it is already up for review, I guess you can't request to manually review16:11
jdstrandanyway, taking care of it16:11
jdstrandkgunn: ok, approved, but please see my review feedback16:14
kgunnjdstrand: ok, thanks... tedg ^16:14
=== nyx_ is now known as moonwalk
longsleepogra_: I finished experimental uboot.env building in my build environment - it boots just fine. So i have this environment combining defaults, boot.ini and snappy-system.txt: https://github.com/longsleep/snappy-odroidc/blob/uboot-env-support/oem/boot-assets/uboot.env.txt17:21
ogra_longsleep, perfect !17:22
longsleepogra_: so assuming a tool will change snappy_mode regular to try it should just work. Is that something you want in 15.04?17:24
ogra_yes, it is what we hold back the release for17:25
longsleepi see - by the way i found one problem17:25
ogra_since the fatwrite way we used there is not reliable and always trashes the fat after some going back and forth17:25
longsleepyeah - i could never reproduce this on the odroidc17:26
longsleepnever mind, the problem i found might be no problem after all17:26
longsleepwell - saveenv will add extra stuff to the stored env file. Like mac address and system serial.17:27
longsleepnot sure if that is a problem17:27
ogra_i dont think it is, they are usually not changing17:27
tedgGreat, thanks jdstrand!17:27
ogra_if we find a var that actually has probs with that we'll deal with it then17:28
longsleepogra_: right, but it might give a surprise when the media is moved to another device17:28
ogra_true17:28
ogra_sadly there is no selective-saveenv to just store single var changes17:29
longsleepyeah - well we will see how this goes in the wild17:29
ogra_yup17:29
ogra_i dont imagine it will be problematic ... but we'll see17:29
longsleepi will experiment a bit on this17:30
ogra_cool, thanks !17:30
longsleepogra_: well i guess i could just compile u-boot without network support.17:40
ogra_i think the ftd will still hand over a MAC even then17:40
tedgjdstrand, I'm still getting a bad system call with the updated Mir package. Where do I find the seccomp policy to make sure it's the one with socketpair() ?17:53
tedgUhg, found it. That's not it.17:54
elopio_good morning!18:19
elopio_internet is bad in here, again. Seems better now, so I'll make it up for my tardiness working late today.18:20
elopio_ev: what about https://code.launchpad.net/~tanuki/charms/trusty/tarmac/trunk ?18:22
elopio_are you supporting that?18:22
evno, that's for internal use18:23
evelopio_: the kitsune squad is working with engineering teams to get what CI used to run for them transitioned over to self-service CI. This is done with Jenkins-as-a-service, a push button deployment of a Jenkins. Part of that will be using Tarmac for injecting MP events into Jenkins, but that's on a case by case basis, ultimately managed by the engineering18:25
evteams who will now own these Jenkins instances, and is done as just installing the tarmac package, not a charm.18:25
evThis is unrelated to the work the CI product squad (tanuki) is doing to build what we discussed last week18:25
=== elopio_ is now known as elopio
evthink of kitsune as helping teams get a Jenkins, and get familiar with running their own jobs. Tanuki is about product-testing, wherein the CI service is just about telling you there are product test opportunities, helping direct these opportunities down to your lab and your devices to be run, and giving you a place to pass binary result states up18:28
evif you have deeper questions, feel free to kick this over to a PM18:28
elopioev: ok, from playing with that charm I found it easier to just install tarmac too.18:28
elopioev: no more questions for now. If your kitsune team wants alpha users, count me in.18:29
evthey've got their hands full with community core apps and mir/unity at the moment, but I'll keep you posted18:30
evas it turns out, self-service CI is a desired thing :D18:30
jdstrandtedg: /var/lib/snappy/seccomp/profiles18:32
jdstrandtedg: note, seccomp policy is not regenerated on upgrade yet18:33
tedgjdstrand, Yeah, I figured out my issue. Apparently qmlscene opens a socket for even local file access if you use the XMLHTTP() object.18:33
tedgjdstrand, Had to add in network-client18:33
jdstrandah, yeah18:34
jdstrandI remember that with touch policy18:34
jdstrandnow that you mention it18:34
=== howefield_afk is now known as howefield
=== devil is now known as Guest88846
=== Guest88846 is now known as devil_
=== nyx_ is now known as moonwalk
tedgkgunn, Are there plans to make a mir package for the RaspPi2?19:46
kgunntedg: kinda... it's not just adding arm,  we need to add sw rendering to mir20:01
tedgkgunn, Oh, can't use the RaspPi drivers? I thought they were accelerated?20:02
tedgkgunn, Also it seems keyboard isn't working for me. Is that expected? Or something I did wrong :-)20:02
kgunntedg: bregma and bschaefer have poked around on RPi, i think egl might have been missing ?20:03
bschaeferkgunn, the entire /dev/dri/card* is missing20:04
kgunntedg: ...and i can't speak to keyboard issues20:04
bschaeferright, i was getting no keyboard events in a kvm through mir (wasnt sure if it was the VM it self or an issue with snappy/mir)20:04
kyrofaseb128, you still around?20:15
kyrofakgunn, quick update: the snappy scope is is the NEW queue for wily awaiting review20:17
kgunnkyrofa: that's good news!20:17
kgunnkyrofa: so are you able to install a snap ?20:17
kyrofakgunn, search/install/uninstall, yes20:18
kgunnoh man...nice!20:18
kyrofakgunn, as soon as it hits the archives I'll make a MP to get it into the Personal seed20:18
kyrofakgunn, there's a caveat. It requires the webdm snap to work, which has not yet been released in the personal channel so it can't be preloaded20:19
kyrofaI'll ping sergiusens in the morning to see if I can get that to happen soon20:20
kyrofakgunn, until then you'll have to sideload it20:21
kgunnthanks20:23
mariogripogra_: Im running snappy in lxc :D  https://usercontent.irccloud-cdn.com/file/e9wYtfMb/20:26
mariogripogra_: Im running snappy in lxc :D20:26
mariogripusing the snappy personal20:28
bregmakeyboard works fine on rasPi for me, but I'm using the serial console not USB20:28
* bregma does not have enough desks for a keyboard just for a pi20:29
* bregma is waiting like a vulture for his daughter to move out again20:29
* bregma has plans, of yes, he has plans.....20:30
=== nyx is now known as Guest8985
=== howefield is now known as howefield_afk

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!