| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| fgimenez | good morning | 07:11 |
|---|---|---|
| longsleep | hey 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 done | 08:03 |
| * ogra_ just noticed the livecd-rootfs upload ... i thought we dont need that with the go tool | 08:04 | |
| longsleep | ogra_: ok - is that happening soon? I need to check about the fw_* commands right? | 08:04 |
| mvo | ogra_: my uboot-go work does not, the current branch is based on fw_setenv/fw_printend | 08:04 |
| ogra_ | mvo, i think we should switch over | 08:05 |
| mvo | ogra_: 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 add | 08:05 |
| mvo | ogra_: sure, I work on this now | 08:05 |
| ogra_ | mvo, is the snappy-hub branch the actual branch we buiold the beaglebone snap from ? | 08:06 |
| longsleep | fw_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 system | 08:09 |
| longsleep | oh | 08:09 |
| longsleep | thats 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 instead | 08:09 |
| longsleep | i 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 file | 08:11 |
| longsleep | ogra_: 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 ones | 08:12 |
| ogra_ | longsleep, see line 9 | 08:13 |
| longsleep | ogra_: super - thanks i think i got it | 08: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 file | 08:15 |
| longsleep | ogra_: my u-boot loads a file called boot.ini - so i guess i could just load the uboot.env from there. | 08:15 |
| longsleep | ogra_: see here: https://github.com/longsleep/snappy-odroidc/blob/master/oem/boot-assets/boot.ini the current script | 08: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 base | 08:16 |
| ogra_ | and to that i added the vars from snappy-system.txt and uEnv.txt | 08:16 |
| ogra_ | (plus "snappy_trial_boot") | 08:17 |
| longsleep | that 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 enc | 08:17 |
| ogra_ | *env | 08:17 |
| ogra_ | which is why you should exclude them | 08:18 |
| ogra_ | witzh the uboot patch your ini file can be empty | 08:18 |
| longsleep | right | 08:18 |
| longsleep | that is worth a try | 08:18 |
| ogra_ | all environment will be read from uboot.env | 08:19 |
| longsleep | assuming my u-boot tree supports CONFIG_ENV_* / checking now | 08:19 |
| ogra_ | thats a pretty generic function | 08:19 |
| ogra_ | (usually used to write the env to a raw space on the SD or NAND though) | 08:19 |
| longsleep | yeah lots of grep matches | 08:19 |
| longsleep | so that looks good | 08:20 |
| ogra_ | great | 08:20 |
| longsleep | so for testing i could just create a uboot.env manually and see if i can boot with only that? | 08:20 |
| ogra_ | yeah | 08:20 |
| longsleep | great - let me try that | 08:20 |
| longsleep | ogra_: 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 |
| longsleep | ogra_: makes sense - at least if loading the .env file undefines already defined stuff | 08:29 |
| ogra_ | right | 08: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 |
| longsleep | depends 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 else | 08:32 |
| longsleep | ok | 08:32 |
| === erkules_ is now known as erkules | ||
| longsleep | well - my u-boot tree does not have CONFIG_ENV_IS_IN_FAT :-/ | 08:38 |
| ogra_ | bah | 08:38 |
| longsleep | just checking when this was added | 08:38 |
| ogra_ | it muste be really old | 08:38 |
| ogra_ | i remember using it years ago on pandabaords | 08:39 |
| longsleep | the tree i have to use is from early 2013 | 08:39 |
| ogra_ | (pandaboard went out of production in 2012) | 08:40 |
| longsleep | mhm :) | 08:40 |
| longsleep | you are right - added 2012-03-30 | 08:41 |
| longsleep | so i shoud have it .. | 08:41 |
| longsleep | but the whole file is not there in my tree .. damn! | 08:41 |
| longsleep | this is the commit - just for the record: http://git.denx.de/?p=u-boot.git;a=commit;h=57210c7cc363cf2a2a28010658c7ea67388f8d21 | 08:42 |
| ogra_ | well, at least it should be easy to apply | 08:42 |
| longsleep | yes looks easy | 08:43 |
| JamesTait | Good morning all; happy Monday, and happy Space Exploration Day! 😃 | 09:08 |
| mvo | ogra_: 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 far | 09:25 |
| mvo | ogra_: next I will do a bit of code cleanup and write code to import files like the existing snappy-system.txt | 09: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 |
| longsleep | well seems like my u-boot created a uboot.env file after saveenv and next boot seems to have loaded it without error | 09:56 |
| ogra_ | awesome ! | 09:57 |
| ogra_ | you should be able to use tools/mkenvimage though ... to pre-create it from a txt file | 09:58 |
| longsleep | yeah | 09:58 |
| ogra_ | (line 16 in http://paste.ubuntu.com/11893737/) | 09:58 |
| longsleep | checking the u-boot side first - patching was messy | 09:58 |
| ogra_ | :( | 09:58 |
| longsleep | i could not cherry pick cleanly | 09:58 |
| longsleep | ogra_: so the source for your uboot.env is the new-Env.txt file ? | 10:01 |
| ogra_ | yeah | 10:01 |
| ogra_ | but that indeed includes the BBB default env ... i assume you want to create your oown from scratch | 10:02 |
| longsleep | ok let me see where i get this tool - or do you recommend to use https://github.com/mvo5/uboot-go instead? | 10:02 |
| longsleep | mkenvimage 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 tool | 10:04 |
| * longsleep tries the go tool first | 10:06 | |
| longsleep | well uboot-go says bad CRC when trying to print the file created by saveenv | 10:16 |
| longsleep | at least it is consistent - u-boot says bad CRC when loading a uboot.env created by the uboot-go :) | 10:21 |
| ogra_ | yeah, not good | 10:21 |
| longsleep | ogra_: 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 nothing | 10:22 |
| longsleep | mhm - 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 BBB | 10:24 |
| longsleep | armhf version of what? | 10:24 |
| longsleep | uboot-go ? | 10:24 |
| ogra_ | of the go tool | 10:24 |
| longsleep | mhm there should not be any difference in go no matter what arch | 10:24 |
| ogra_ | http://people.canonical.com/~mvo/tmp/ | 10:25 |
| longsleep | ok let me try that build | 10:25 |
| mvo | longsleep: the uboot env format is "funny". its either 4 byte (crc) or 5 byte (crc+flags) | 10:27 |
| longsleep | mvo: any idea where i could quickly upload the env file? | 10:28 |
| mvo | longsleep: 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 header | 10:28 |
| mvo | longsleep: hexdump -C uboot.env|head is probably enough for me for now, just pastebin that :) | 10:28 |
| longsleep | mvo: well i cherry picked and hacked around the env fat code so it might well be a u-boot issue as well | 10:29 |
| longsleep | mvo: ok hold on | 10:29 |
| longsleep | mvo: http://paste.ubuntu.com/11908556 | 10:30 |
| mvo | longsleep: 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 |
| mvo | longsleep: joy, looks like you have a 4 byte header | 10:30 |
| longsleep | mvo: that is news - i had no idea about .env format before today | 10:30 |
| longsleep | i do not even have mkenvinmage yet as this is newer than my uboot :) | 10:31 |
| longsleep | but the size triggers a bell | 10:31 |
| mvo | longsleep: heh :) ok, I can tell you all I know, its going to be quick ;) | 10:31 |
| mvo | longsleep: 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 |
| longsleep | i have CONFIG_ENV_SIZE (32 * 1024) | 10:32 |
| longsleep | is that the size you mean? | 10:32 |
| mvo | yes | 10:32 |
| longsleep | and CONFIG_ENV_OFFSET (512 * 1024) | 10:32 |
| longsleep | that might be a problem? | 10:32 |
| mvo | I'm not sure, I *think* (but could be totally off) that this is ignored when writing to fat files | 10:33 |
| * longsleep checks the code | 10:33 | |
| longsleep | seems so as its not used in the FAT code. CONFIG_ENV_SIZE is used | 10:33 |
| mvo | great! | 10:33 |
| mvo | longsleep: the uboot.env from the pastebin, was that created using saveenv from your uboot prompt? | 10:34 |
| longsleep | yes | 10:34 |
| mvo | hm, 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 ports | 10:35 |
| mvo | but I can probably add auto-detect magic to my go-code, but its a bit ugly, something like "if isAscii(content[4])" which feels …wrong | 10:35 |
| longsleep | assuming that my file is supposted to work then yes - but i thought you have a 4 byte header as well? | 10:36 |
| mvo | we 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" env | 10:39 |
| mvo | whatever that means | 10:39 |
| longsleep | mvo: i do not know either, no redundant what so ever related to env in my build config for u-boot. | 10:40 |
| longsleep | mvo: if you want to have the complete file: https://www.stdin.xyz/downloads/people/longsleep/tmp/uboot.env-odroidsaveenv | 10:42 |
| mvo | longsleep, ogra_ do you have CONFIG_SYS_REDUNDANT_ENVIRONMENT in your build config? | 10:44 |
| mvo | that seems to be the magic configuration | 10:44 |
| ogra_ | ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot-latest$ grep CONFIG_SYS_REDUNDANT_ENVIRONMENT configs/am335x_boneblack_defconfig | 10:45 |
| ogra_ | ogra@anubis:~/datengrab/rpi/uboot/bbb/u-boot-latest$ | 10:45 |
| ogra_ | nope | 10:45 |
| longsleep | mvo: grep shows nothing in u-boot that - so does not seems so | 10:45 |
| mvo | ups, sorry, typo on my side :( | 10:46 |
| mvo | CONFIG_SYS_REDUNDAND_ENVIRONMENT | 10:46 |
| mvo | -^ | 10:46 |
| longsleep | that matches but i do not have it set | 10:47 |
| ogra_ | nope, not either | 10:47 |
| mvo | ogra_: not set either | 10:47 |
| mvo | hmmmmm | 10:47 |
| longsleep | it also seems only be used in env_embedded | 10:47 |
| longsleep | and in envcrc | 10:47 |
| longsleep | hold on | 10:47 |
| mvo | for me (current u-boot git) it defines the size o fenv_t | 10:48 |
| mvo | i.e. typedef struct environment_s {} env_t | 10:48 |
| mvo | but 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 work | 10:49 |
| mvo | on reading at least | 10:49 |
| mvo | writing is a different matter, need to add flags or something | 10:50 |
| mvo | ogra_: but why we do not set it really confuses me, i.e. how we end up with a long header | 10:50 |
| ogra_ | i have no idea | 10:50 |
| mvo | ogra_: could you pastebin our config? maybe its somehow derrived | 10:51 |
| longsleep | i just pushed my u-boot branch https://github.com/longsleep/u-boot-odroidc/tree/odroidc-configfat | 10:51 |
| longsleep | thats the tree i have to use | 10:51 |
| longsleep | mvo: what file is that with the size? | 10:52 |
| * ogra_ grumbles about sergiusens sending messages i cant open | 10:52 | |
| longsleep | environment.h found it | 10:52 |
| * mvo gets lunch | 10:53 | |
| mvo | longsleep: include/environment.h is it for me that defines the header size | 10:53 |
| longsleep | mvo: yeah i see it - maybe that has changed in later uboots | 10:54 |
| * mvo nods | 10:54 | |
| longsleep | mvo: see https://github.com/longsleep/u-boot-odroidc/blob/odroidc-configfat/include/environment.h - i will compare as well | 10:54 |
| * longsleep gets lunch too | 10:55 | |
| mvo | looks similar at first glance | 10:55 |
| mvo | oh - CONFIG_ENV_OFFSET_REDUND | 10:55 |
| mvo | looks like it might be a derrived config value | 10:55 |
| longsleep | that REDUND stuff looks like a big mess | 10:57 |
| longsleep | but anyhow - i agree that you should only end up with a 5 byte header when REDUNDAND_ENVIRONMENT is set | 10:57 |
| === EllieGoulding is now known as plop_its_ellie | ||
| longsleep | mvo: just to confirm, when changing headerSize to 4 in your env.go the odroidc file parses just fine | 11:55 |
| longsleep | ogra_: 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 too | 11:57 |
| longsleep | ogra_: http://paste.ubuntu.com/11908839/ is the uboot.env default content - if you want to compare with yours | 12:00 |
| zyga | hi | 12:03 |
| zyga | I'd like to have a bit of web service | 12:04 |
| zyga | and I'd like to register my service to avahi | 12:04 |
| zyga | so | 12:04 |
| zyga | should I bundle avahi (seems wrong) | 12:04 |
| mvo | longsleep: great to hear that it works with that header size | 12:04 |
| zyga | or should I start to work on a avahi.framework? | 12:04 |
| zyga | mvo: hey :-) | 12:04 |
| mvo | hey zyga | 12:04 |
| ogra_ | zyga, you should bundle avahi | 12:04 |
| mvo | longsleep: and yeah, I need we need to figure out whats going on :) | 12:04 |
| zyga | ogra_: but how can that work if there can be only one avahi server on a host | 12:04 |
| zyga | ogra_: one to bind to the magic port | 12:04 |
| zyga | ogra_: it's a system-level feature | 12:05 |
| ogra_ | zyga, there was some planning that user installed snaps can override that | 12:05 |
| zyga | ogra_: two apps cannot both bundle avahi (server) | 12:05 |
| * ogra_ remembers some discussion on the ML | 12:05 | |
| zyga | ogra_: can you explain how this would work ? | 12:05 |
| ogra_ | no | 12:05 |
| ogra_ | but i know that the expectation was that you bundle it | 12:05 |
| ogra_ | and that the preinstalled avahi goes oout of your wa< | 12:05 |
| zyga | ogra_: mmm, so I don't get it, if I do my snap with avahi server I effectively prevent all other snaps from doing that | 12:05 |
| ogra_ | way | 12:05 |
| zyga | ? | 12:05 |
| zyga | is there a preinstalled avahi? | 12:06 |
| ogra_ | no idea | 12:06 |
| ogra_ | yes, webdm ships avahi | 12:06 |
| zyga | hmm, does it? | 12:07 |
| zyga | I don't see that here | 12:07 |
| ogra_ | yes | 12:07 |
| mvo | longsleep, 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 this | 12:07 |
| ogra_ | well, and that wouldnt help on "create" | 12:07 |
| longsleep | mvo: well the question is how is the initial .env file created. | 12:08 |
| zyga | ah, so snappyd has an avahi server inside? | 12:08 |
| longsleep | +is | 12:08 |
| zyga | hmmm, I still don't get how this can work with more than one app | 12:08 |
| mvo | longsleep: 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 tool | 12:09 |
| ogra_ | from the tools dir | 12:09 |
| ogra_ | that should give you the right header for your uboot | 12:09 |
| longsleep | yes all kinds of stuff might need to be set in addition to snappy boot logic | 12:09 |
| mvo | longsleep: 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 here | 12:09 |
| ogra_ | yes, it should be compiled with the righ defaults for your specific build | 12:10 |
| longsleep | well the default could be provided in the oem package | 12:10 |
| longsleep | the problem is how and where does the snappy boot logic get triggered | 12:10 |
| ogra_ | i assume some devices will adapt all that stuff to a possible NAND that we dont use | 12:10 |
| longsleep | in ogra_ 's file he does it with uenvcmd | 12:10 |
| longsleep | that only works because his defaults run this macro in bootcmd | 12:10 |
| longsleep | in my file this will have to be totally different | 12:11 |
| ogra_ | all devices use snappy_boot | 12:11 |
| ogra_ | your bootcmd should already be adjusted for this | 12:11 |
| longsleep | the bootcmd should directly load snappy_boot ? | 12:11 |
| longsleep | yours loads uenvcmd | 12:11 |
| ogra_ | which the loads snappy_boot | 12:12 |
| ogra_ | *then | 12:12 |
| longsleep | so you say that the defaults should somehow end up loading snappy_boot? | 12:12 |
| longsleep | i am good with that | 12:12 |
| ogra_ | the final env needs to be a merger of all the former snappy- files uEnv.txt and the default env | 12:12 |
| longsleep | right | 12:12 |
| ogra_ | like you used it before ... just now merged | 12:13 |
| longsleep | i was not using uEnv.txt before - so it might be a bit different | 12:13 |
| longsleep | i was using boot.ini to set stuff | 12:13 |
| ogra_ | well, but for rollback and stuff you used snappy-system-txt | 12:13 |
| ogra_ | *.txt | 12:13 |
| longsleep | right | 12:13 |
| ogra_ | so your boot.ini somehow pulled in and called snappy_boot | 12:14 |
| longsleep | correct | 12:14 |
| ogra_ | which has the logic | 12:14 |
| ogra_ | right, so now, just do the same :) | 12:14 |
| longsleep | yes i can do it manually i get that | 12:14 |
| ogra_ | just not scattered across multiple files | 12:14 |
| longsleep | the question is how to automate it | 12:14 |
| longsleep | or make it generic | 12:14 |
| ogra_ | your initial txt file should have it | 12:14 |
| longsleep | ok - so that is still shipped by the OEM snap or whatever there is in the future | 12:15 |
| ogra_ | yes | 12:15 |
| ogra_ | uboot.env will be shipped | 12:15 |
| ogra_ | in your snap | 12:15 |
| longsleep | then the 4 or 5 byte problem should be none as well | 12:15 |
| longsleep | the tool just needs to keep the header size as the same | 12:15 |
| ogra_ | right, if mvo can autodetect it and we can just rely on mkenvimage we should be all fine | 12:16 |
| longsleep | mkenvimage - that tool is a problem - i would prefer the go version from mvo | 12:16 |
| ogra_ | i wouldnt like to generalize here since it might break the ability of a board to actually use the NAND | 12:16 |
| ogra_ | in case you want to switch to that we shouldnt break your defaults | 12:17 |
| ogra_ | mkenvimage guarantees that your env file will be readable for sure though | 12:17 |
| ogra_ | (for u-boot at least) | 12:17 |
| longsleep | corret - but this would be created on OEM snap building right? So that tool is a build requiredment | 12:17 |
| ogra_ | yeah | 12:18 |
| ogra_ | well, its is a req for your port | 12:18 |
| longsleep | ah - 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 |
| mvo | ogra_: how would it break nand when we use the go version? just curious? mkenvfile can only create a file afaics | 12:20 |
| ogra_ | mvo, it could break NAND if we enforce a certain header in the u-boot build ... not in the go version | 12:21 |
| mvo | ogra_: oh, sure, the go version will be able to deal with both headers, thats for sure, same way as mkenvfile with a flag | 12:21 |
| longsleep | ah 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 change | 12:21 |
| ogra_ | what mkenvfile creates could be written to nand | 12:21 |
| mvo | but no worries, using mkenvfile is fine | 12:21 |
| mvo | I just wanted to understand if there is anything I need to support for NAND | 12:22 |
| ogra_ | yeah, i think thats the safest option | 12:22 |
| ogra_ | no | 12: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_ | err | 12:22 |
| ogra_ | :) | 12:22 |
| longsleep | so you propose to ship mkenvfile as pat of a snappy system and use this tool to modify .env files? | 12:23 |
| longsleep | s/pat/part | 12:23 |
| ogra_ | no | 12:23 |
| ogra_ | i propose to ask porters to use it to create their initial uboot.env file | 12:23 |
| ogra_ | when they do their u-boot.img build | 12:23 |
| longsleep | ok thats fine | 12:24 |
| longsleep | and for updates use the go tool? | 12:24 |
| ogra_ | for our purpoose the go binary should be fine | 12:24 |
| longsleep | +1 | 12: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 |
| longsleep | well 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 tree | 12:26 |
| longsleep | ogra_: ok - i guess this is a valid assumption | 12:27 |
| ogra_ | (especially since you need to patch it anyway for the uboot.env support i would expect you to recompile it) | 12:27 |
| longsleep | ogra_: by patching you mean enabling the defines in the board configuration? | 12:29 |
| ogra_ | right | 12:29 |
| longsleep | ogra_: i thought newer uboots have a config file for this instead of header files | 12:29 |
| ogra_ | oh,, do they ? | 12:30 |
| * ogra_ hasnt heard of that | 12:30 | |
| longsleep | i think so, i had some troubles backporting stuff because of this change | 12:30 |
| longsleep | yes | 12:31 |
| longsleep | see http://git.denx.de/?p=u-boot.git;a=tree;f=configs;h=ff6b998c4ffa4e9da3ab367141156391d5fcad3d;hb=HEAD | 12:31 |
| ogra_ | what about that ? that has always been the config dir | 12:32 |
| longsleep | no - not in my tree | 12:32 |
| longsleep | all the defconfig stuff is rather new | 12:32 |
| ogra_ | ah | 12:32 |
| * ogra_ remembers using it for beagle XM installs years ago | 12:33 | |
| longsleep | well 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 wrong | 12:34 |
| longsleep | ogra_: 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 bit | 12:36 |
| longsleep | i thought it was easier to change compile settings without patching in a bunch of defines | 12:37 |
| longsleep | mvo: uboot-go seems to have another setting for headerSize as it seems to create 5 bytes headers even with headerSize set to 4 | 12:38 |
| * ogra_ tried a static kodi build on the weekend to use it in snap and click packages ... | 12:41 | |
| mvo | longsleep: oh, let me check | 12:41 |
| ogra_ | seems building something static as soon as pytjhon is involved becomes a major pain :( | 12:41 |
| longsleep | thats 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 myself | 12:43 |
| ogra_ | such a mess .( | 12:43 |
| longsleep | having a kodi snap would be pretty awesome | 12:43 |
| mvo | longsleep: I'm fixing this right now, give me some minutes, I will yell once I have a fix | 12:44 |
| longsleep | mvo: awesome thanks | 12:44 |
| ogra_ | well, i was more after a click :) but yeah, rolling a snap at the same time shouldnt be hard | 12:44 |
| longsleep | what is a "click" - i think i missed something | 12:44 |
| ogra_ | longsleep, the predecessor of snap | 12:48 |
| longsleep | ogra_: oh - seems i have missed that | 12:49 |
| ogra_ | it is what we use on the phone | 12:50 |
| * longsleep tries to compile mkenvimage | 12:53 | |
| ogra_ | just "make all" ;) | 12:53 |
| longsleep | nah - had to backport it into my u-boot :) | 12:54 |
| longsleep | but seems like it compiled | 12:54 |
| Chipaca | anybody here on 14.04, to try the mir snap in virt-manager? | 12:55 |
| longsleep | ogra_, mvo - i think i just might have found why you have 5 bytes headers | 12:56 |
| ogra_ | because we are the cooler kids ! | 12:57 |
| ogra_ | :P | 12:57 |
| longsleep | in your example you have -r parameter to mkenvimage - i guess that means redundant | 12:57 |
| longsleep | "the environment has multiple copies in flash" | 12:57 |
| ogra_ | right, and without -r we get CRC errors | 12:57 |
| longsleep | ok :) | 12:57 |
| ogra_ | so the uboot binary expects the 5 bytes | 12:57 |
| mvo | longsleep: 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 commit | 12:58 |
| longsleep | mvo: cool / i will try in 2 minutes | 12:58 |
| mvo | no rush | 12:59 |
| mvo | I'm here for at least 3h | 12:59 |
| longsleep | ok with the old version i can read a 4 bytes file created with mkenvimage | 13:00 |
| longsleep | lets update | 13:00 |
| longsleep | still works with updated version | 13:01 |
| longsleep | lets see if i can create | 13:01 |
| longsleep | mvo: yes works - cool | 13:01 |
| mvo | yay | 13:01 |
| mvo | yay^2 | 13:01 |
| longsleep | lets try to set something :) | 13:01 |
| longsleep | set works too now - now the boot test | 13:02 |
| ogra_ | yippies | 13:02 |
| longsleep | mvo: works like a charm | 13:03 |
| ogra_ | \o/ | 13:04 |
| longsleep | ogra_: and you were right, uboot.env removes all previously loaded defaults | 13:04 |
| longsleep | i now have essentially only foo=bar in the environment | 13:04 |
| ogra_ | yeah | 13:04 |
| longsleep | but thats something - i think i could get the odroidc platform boot fine with this ne scheme | 13:05 |
| longsleep | new | 13:05 |
| ogra_ | just think about the kids^WATAGs ... | 13:05 |
| ogra_ | (respective handed through dtb settings) | 13:05 |
| mvo | longsleep: there is now also "import" to read from key=value files | 13:05 |
| longsleep | mvo: oh let me try that | 13:06 |
| longsleep | mvo: yeah works fine as well | 13:07 |
| longsleep | (note that i have changed headerSize to 4) | 13:07 |
| tedg | I 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 |
| Chipaca | tedg: what's up/down? | 13:15 |
| ogra_ | was a newer Mir uploaded to the store yet ? | 13:15 |
| ogra_ | you can use uappexplorer | 13:15 |
| Chipaca | tedg: ah, you mean the snap? | 13:15 |
| ogra_ | (unless that now filters snaps) | 13:15 |
| Chipaca | tedg: bzr branch lp:~mir-team/mir/snappy-packaging && cd snappy-packaging && make && echo YEAH | 13:16 |
| tedg | It was in the store, just need a newer version. Which kgunn said he was uploading on Friday. | 13:16 |
| tedg | I need to know whether it's my fault or not before I complain :-) | 13:16 |
| Chipaca | s/echo/notify-send/ | 13:16 |
| tedg | Chipaca, Sure, just trying to get everything working "out-of-the-box" | 13:16 |
| ogra_ | https://uappexplorer.com/app/my-world.testsnappy ... doesnt filter it seems | 13:16 |
| ogra_ | so if a new snap is uploaded it should show up in https://uappexplorer.com/apps | 13:17 |
| ogra_ | (usually sorts newest first) | 13:17 |
| tedg | I can't find the original in uappexplorer, because it's a framework? | 13:17 |
| Chipaca | probably | 13:17 |
| Chipaca | what version do you see? | 13:18 |
| tedg | snap1 | 13:18 |
| ogra_ | ah, right, a search for docker doesnt return anything | 13:18 |
| ogra_ | hmm, just because i searched wrongly | 13:19 |
| ogra_ | https://uappexplorer.com/app/com.ubuntu.snappy.docker | 13:19 |
| ogra_ | https://uappexplorer.com/apps?sort=relevance&type=snappy | 13:19 |
| ogra_ | that actually lists all snaps | 13:19 |
| tedg | Still don't see Mir though. | 13:19 |
| ogra_ | only 59 :((( | 13:19 |
| tedg | kgunn, Where you able to get Mir uploaded on Friday? | 13:20 |
| kgunn | tedg: i did, altho, prolly just in store review queue...lemme check | 13:20 |
| mvo | longsleep: 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 |
| kgunn | tedg: ah...says published, so snappy search should say snap1.1 | 13:21 |
| longsleep | mvo: good question - can give it a try | 13:21 |
| longsleep | mvo: i guess i would be fine if it does not break anything | 13:22 |
| kgunn | tedg: lemme know if you have issue with install | 13:22 |
| tedg | Hmm, no. I don't see it. And neither does uappexplorer. https://uappexplorer.com/app/mir.mvp-demo | 13:23 |
| tedg | (finally found it there) | 13:23 |
| * longsleep compiling u-boot with CONFIG_SYS_REDUNDAND_ENVIRONMENT | 13:24 | |
| ogra_ | tedg, yeah, weird that uappexplorer doesnt list it at all | 13:25 |
| longsleep | mvo: seems to work just fine - now i get CRC error with 4 byte env file | 13:27 |
| tedg | We may need to ping the store. | 13:28 |
| longsleep | mvo: saveenv just worked fine and it seems to load the file it just created | 13:28 |
| ogra_ | 4 byte is so last build anyway :P | 13:28 |
| longsleep | hehe | 13:28 |
| mvo | yay | 13:28 |
| ogra_ | moar bytes ! | 13:28 |
| longsleep | now let me create a new 5 byte file | 13:28 |
| tedg | Could someone check with a "snappy search mir" on their device and see if snap1.1 is available to them? | 13:29 |
| ogra_ | not here | 13:29 |
| ogra_ | no neither of my armhf devices | 13:29 |
| ogra_ | but i guess that is because kgunn is a lazy guy and only built for x86 :) | 13:29 |
| tedg | Okay, thanks ogra_ | 13:29 |
| tedg | Oh, I want it for amd64, so I'm happy there :-) | 13:29 |
| Chipaca | tedg: no mir for amd64 here either | 13:30 |
| longsleep | mvo, ogra_ : Seems like i do not care if its 5 or 4 byte header - i can do both :) | 13:30 |
| ogra_ | cool ! | 13:30 |
| mvo | longsleep: then go with 5 ;) | 13:30 |
| mvo | makes our life easier | 13:30 |
| ogra_ | 5 is the future ! | 13:30 |
| longsleep | mvo: all right - just make sure to add it to the docs that one needs to set CONFIG_SYS_REDUNDAND_ENVIRONMENT | 13:31 |
| longsleep | and that typo will give problems for sure ;) | 13:31 |
| mvo | heh | 13:33 |
| tedg | kgunn, Can you check your store page again to make sure it's published? And then we'll look to see what happened. | 13:35 |
| kgunn | tedg: so on myapps.developer.ubuntu.com/dev/click-apps/?format=snap i see mir snap1.1 and it says "published" with a little green bubble | 13:36 |
| kgunn | tedg: or do you mean some other way of checking ? | 13:36 |
| kgunn | tedg: ah...wait, there's another page | 13:37 |
| ogra_ | yeah, the public appstore | 13:37 |
| kgunn | tedg: "current approved version" snap1 | 13: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 |
| tedg | kgunn, Do you approve or do we need a store approver? | 13:39 |
| tedg | Is that a popey thing? | 13:39 |
| ogra_ | thats likely a review thing | 13:39 |
| popey | i can | 13:39 |
| popey | if in stores | 13:39 |
| kgunn | popey: yeah, i uploaded friday | 13:40 |
| tedg | popey, You can trust kgunn for this, he's a manager, but it's okay. ;-) | 13:40 |
| kgunn | lol | 13:40 |
| popey | hah | 13:40 |
| * kgunn grabs steel ball and rubber hammer to show them | 13:41 | |
| popey | kgunn: 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 :P | 13:50 |
| ogra_ | (just re-pack as click and popey will let it through ;) ) | 13:50 |
| kgunn | popey: np, jdstrand should be on soon | 13:50 |
| kgunn | tedg: ^ ...so waiting now | 13:53 |
| tedg | Yeah, glad we figured out what the issue is though. Now I can move to track down others :-) | 13:53 |
| longsleep | ogra_, mvo: Seems that i can release the u-boot changes already as everything works as before as long as where is no uboot.env file | 13:57 |
| mvo | yay! | 13:57 |
| longsleep | if there is such a file, it completely takes over | 13:57 |
| longsleep | and whatever new behaviour jumps in | 13:57 |
| ogra_ | yeah, the new behavior is the part we're still working on | 13: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 |
| longsleep | right - 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_ | yeah | 14:01 |
| ogra_ | thats our evil masterplan :) getting rid of writing files to fat | 14:01 |
| longsleep | very good plan | 14:02 |
| longsleep | I 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...master | 14:03 |
| jdstrand | benoitc: fyi, server error going to https://myapps.developer.ubuntu.com/dev/click-apps/reviewer/ | 14:15 |
| jdstrand | benoitc: nm | 14:15 |
| jdstrand | beuno: fyi, server error going to https://myapps.developer.ubuntu.com/dev/click-apps/reviewer/ | 14:16 |
| jdstrand | (tab fail) | 14:16 |
| jdstrand | beuno: OOPS-0393df0da7284ccf8501cfb761c0ce4d | 14:16 |
| beuno | jdstrand, oh-oh | 14:22 |
| beuno | nessita, ^ | 14:22 |
| nessita | beuno, ack, seems like we have some issues with the quarantined apps | 14:23 |
| nessita | jdstrand, one sec, we're removing the troubling apps | 14:24 |
| === chihchun is now known as chihchun_afk | ||
| nessita | jdstrand, 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 | ||
| jdstrand | nessita: I was going to look at the mir one | 14: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/265259 | 14:31 |
| mvo | heh | 14:31 |
| mvo | ogra_: Chipaca will have a look I'm sure | 14:32 |
| ogra_ | yeah | 14:32 |
| nessita | jdstrand, 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 |
| longsleep | ogra_: 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 |
| nessita | jdstrand, then go to the package details of the desired app https://myapps.developer.ubuntu.com/dev/click-apps/2811/ | 14:33 |
| nessita | and append /review/ to the url: https://myapps.developer.ubuntu.com/dev/click-apps/2811/review/ | 14:34 |
| ogra_ | longsleep, yes | 14: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 content | 14:34 |
| longsleep | ogra_: Great thats good, as i currently have to overwrite it. | 14:34 |
| nessita | jdstrand, sorry for the trouble but we're working right now on fixing it | 14:35 |
| longsleep | ogra_: Understood thanks | 14:35 |
| ogra_ | since snappy-system.txt is created by ubuntu-device-flash you need to pull the original content from a former install i fear | 14:35 |
| ogra_ | (and then apply my changes to snappy_boot) | 14:36 |
| ogra_ | (mainly getting rid of fatwrite and using a variable) | 14:36 |
| longsleep | ogra_: well i think it just needs to be documented what env variables are changed on update and the boot scripting then needs to use them | 14:36 |
| longsleep | ogra_: right now i think, on update just snappy_mode will be changed | 14:37 |
| longsleep | ogra_: and whatever scripting happens needs to check that and toggle root to a or b | 14:37 |
| ogra_ | well, snappy_boot holds essentially the whole logic for updates/rollback/reboot | 14:37 |
| longsleep | ogra_: yes - i guess that macro needs just to be documented. Though what is currently shipped does boot a initrd zimage | 14:38 |
| jdstrand | nessita: no worries and thanks :) | 14:38 |
| longsleep | ogra_: my u-boot can only boot uimages | 14:38 |
| longsleep | ogra_: thus i had to overwrite the whole macro | 14:38 |
| ogra_ | right, so you need to adjust for that | 14:38 |
| longsleep | ogra_: but if the macro goes into oem domain then this is fine | 14:38 |
| ogra_ | hmm | 14:38 |
| ogra_ | snappy_boot doesnt use initrd or uninitrd anywhere | 14:38 |
| longsleep | at the end it calls bootz does it not? | 14:39 |
| ogra_ | ah, right | 14:39 |
| ogra_ | so yeah, you need to change it to bootm | 14:39 |
| longsleep | yes | 14:39 |
| ogra_ | we should probably push that out of that line and define it elsewhere | 14:39 |
| longsleep | well - if the whole thing gets owned by the image creator then it does not matter | 14: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 bootm | 14:40 |
| ogra_ | without hacking the actual command | 14:40 |
| longsleep | true - the more modular the better | 14:40 |
| nessita | jdstrand, review UI fixed! :-) | 14:41 |
| jdstrand | nessita: that was fast! :) | 14:43 |
| nessita | jdstrand, 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_lorenz | hi - 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 bug | 14: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 | ||
| tedg | jdstrand, Were you able to approve the mir snap? | 15:14 |
| === JamesTai1 is now known as JamesTait | ||
| jdstrand | tedg: not yet but am working on it | 15:22 |
| tedg | jdstrand, Cool, thank you! | 15:22 |
| === zyga_ is now known as zyga | ||
| fgimenez | rsalveti, 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 |
| hallyn | hi - 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 |
| ubottu | bug 1475751 in lxc (Ubuntu) "need phablet support for mods to /etc/lxc/lxc-usernet (vivid+stable ppa overaly)" [High,New] https://launchpad.net/bugs/1475751 | 15:54 |
| fgimenez | rsalveti, it seems to be in the previous line, where should i report this? | 15:55 |
| jdstrand | tedg: can someone request a manual review for mir? | 16:04 |
| jdstrand | tedg: I've reviewed it, but I can't accept it until someone does that | 16:04 |
| jdstrand | kgunn: ^ | 16:05 |
| kgunn | ack looking | 16:05 |
| kgunn | jdstrand: hmmm, not apparent how i do that....i see the failure due to unconfined and framework | 16:08 |
| kgunn | but i don't see how to ask for a manual review | 16:09 |
| kgunn | i see i can make a comment on the failures...? | 16:09 |
| kgunn | jdstrand: do i need to "unpublish" ? | 16:10 |
| jdstrand | kgunn: no. maybe it was the link I went to. I got there via another means and can see that I can approve | 16:11 |
| jdstrand | kgunn: since it is already up for review, I guess you can't request to manually review | 16:11 |
| jdstrand | anyway, taking care of it | 16:11 |
| jdstrand | kgunn: ok, approved, but please see my review feedback | 16:14 |
| kgunn | jdstrand: ok, thanks... tedg ^ | 16:14 |
| === nyx_ is now known as moonwalk | ||
| longsleep | ogra_: 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.txt | 17:21 |
| ogra_ | longsleep, perfect ! | 17:22 |
| longsleep | ogra_: 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 for | 17:25 |
| longsleep | i see - by the way i found one problem | 17:25 |
| ogra_ | since the fatwrite way we used there is not reliable and always trashes the fat after some going back and forth | 17:25 |
| longsleep | yeah - i could never reproduce this on the odroidc | 17:26 |
| longsleep | never mind, the problem i found might be no problem after all | 17:26 |
| longsleep | well - saveenv will add extra stuff to the stored env file. Like mac address and system serial. | 17:27 |
| longsleep | not sure if that is a problem | 17:27 |
| ogra_ | i dont think it is, they are usually not changing | 17:27 |
| tedg | Great, thanks jdstrand! | 17:27 |
| ogra_ | if we find a var that actually has probs with that we'll deal with it then | 17:28 |
| longsleep | ogra_: right, but it might give a surprise when the media is moved to another device | 17:28 |
| ogra_ | true | 17:28 |
| ogra_ | sadly there is no selective-saveenv to just store single var changes | 17:29 |
| longsleep | yeah - well we will see how this goes in the wild | 17:29 |
| ogra_ | yup | 17:29 |
| ogra_ | i dont imagine it will be problematic ... but we'll see | 17:29 |
| longsleep | i will experiment a bit on this | 17:30 |
| ogra_ | cool, thanks ! | 17:30 |
| longsleep | ogra_: 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 then | 17:40 |
| tedg | jdstrand, 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 |
| tedg | Uhg, 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 |
| ev | no, that's for internal use | 18:23 |
| ev | elopio_: 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 engineering | 18:25 |
| ev | teams who will now own these Jenkins instances, and is done as just installing the tarmac package, not a charm. | 18:25 |
| ev | This is unrelated to the work the CI product squad (tanuki) is doing to build what we discussed last week | 18:25 |
| === elopio_ is now known as elopio | ||
| ev | think 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 up | 18:28 |
| ev | if you have deeper questions, feel free to kick this over to a PM | 18:28 |
| elopio | ev: ok, from playing with that charm I found it easier to just install tarmac too. | 18:28 |
| elopio | ev: no more questions for now. If your kitsune team wants alpha users, count me in. | 18:29 |
| ev | they've got their hands full with community core apps and mir/unity at the moment, but I'll keep you posted | 18:30 |
| ev | as it turns out, self-service CI is a desired thing :D | 18:30 |
| jdstrand | tedg: /var/lib/snappy/seccomp/profiles | 18:32 |
| jdstrand | tedg: note, seccomp policy is not regenerated on upgrade yet | 18:33 |
| tedg | jdstrand, Yeah, I figured out my issue. Apparently qmlscene opens a socket for even local file access if you use the XMLHTTP() object. | 18:33 |
| tedg | jdstrand, Had to add in network-client | 18:33 |
| jdstrand | ah, yeah | 18:34 |
| jdstrand | I remember that with touch policy | 18:34 |
| jdstrand | now that you mention it | 18: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 | ||
| tedg | kgunn, Are there plans to make a mir package for the RaspPi2? | 19:46 |
| kgunn | tedg: kinda... it's not just adding arm, we need to add sw rendering to mir | 20:01 |
| tedg | kgunn, Oh, can't use the RaspPi drivers? I thought they were accelerated? | 20:02 |
| tedg | kgunn, Also it seems keyboard isn't working for me. Is that expected? Or something I did wrong :-) | 20:02 |
| kgunn | tedg: bregma and bschaefer have poked around on RPi, i think egl might have been missing ? | 20:03 |
| bschaefer | kgunn, the entire /dev/dri/card* is missing | 20:04 |
| kgunn | tedg: ...and i can't speak to keyboard issues | 20:04 |
| bschaefer | right, 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 |
| kyrofa | seb128, you still around? | 20:15 |
| kyrofa | kgunn, quick update: the snappy scope is is the NEW queue for wily awaiting review | 20:17 |
| kgunn | kyrofa: that's good news! | 20:17 |
| kgunn | kyrofa: so are you able to install a snap ? | 20:17 |
| kyrofa | kgunn, search/install/uninstall, yes | 20:18 |
| kgunn | oh man...nice! | 20:18 |
| kyrofa | kgunn, as soon as it hits the archives I'll make a MP to get it into the Personal seed | 20:18 |
| kyrofa | kgunn, 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 preloaded | 20:19 |
| kyrofa | I'll ping sergiusens in the morning to see if I can get that to happen soon | 20:20 |
| kyrofa | kgunn, until then you'll have to sideload it | 20:21 |
| kgunn | thanks | 20:23 |
| mariogrip | ogra_: Im running snappy in lxc :D https://usercontent.irccloud-cdn.com/file/e9wYtfMb/ | 20:26 |
| mariogrip | ogra_: Im running snappy in lxc :D | 20:26 |
| mariogrip | using the snappy personal | 20:28 |
| bregma | keyboard works fine on rasPi for me, but I'm using the serial console not USB | 20:28 |
| * bregma does not have enough desks for a keyboard just for a pi | 20:29 | |
| * bregma is waiting like a vulture for his daughter to move out again | 20: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!