IRC logs for #baserock for Sunday, 2015-10-25

*** gtristan has quit IRC02:27
*** thrace has joined #baserock02:39
*** gtristan has joined #baserock02:51
*** flatmush has quit IRC03:23
*** flatmush1 has joined #baserock03:23
*** gtristan has quit IRC04:37
*** thrace has quit IRC05:54
*** thrace has joined #baserock05:54
*** tlsa_ is now known as tlsa08:59
*** gtristan has joined #baserock11:47
pedroalvarezSo, for Raspberry Pi, I need to copy some blobs from this repo to /boot:
pedroalvarezbut looks like they provide a *lot* of thins in there, making it really big (4G)17:11
pedroalvarezI'm against lorrying it, any sane alternatives?17:11
pedroalvarez- Copying files to definitions.git to be installed with install-files17:12
pedroalvarez- Copy the files to a branch of another component of the bsp (kernel?) and install them at that point?17:13
lostduckbsp-support repo, add the binaries with morph add-binary ?17:14
persiaI'm against copying the files to a branch of definitions: git doesn't maintain enough branch sanitization.17:17
pedroalvarezpersia:  I meant master of definitions.git17:17
persiaEssentially, this brings up back to the unsolved binary injection problem.17:18
persiapedroalvarez: That would be even worse.17:18
pedroalvarezlostduck: that might be the best option17:18
persiaWhen we receive a blob, we need a mechanism to inject that blob into a build, essentially treating it as a built object (with an opaque build process).17:18
persiaWe have a mechanism to treat it as a source (lostduck's suggestion), but this implies either lorrying from somewhere or that one has unmirrored sources.17:20
persiagit-fat helps make it less absolutely terrible, but ...17:20
lostduckfwiw, nix solves this by fetching blobs from a given url, the sha sum of the blob must match a sha provided by the expression17:20
persiaTo me, that makes more sense, perhaps with a parameter that explains the path the blob ought have in a final system.17:21
persiaAnd perhaps some mechanism to mirror blobs somewhere (lorry type: "blob"), to protect against loss of blob availability on the internet somewhere.17:21
pedroalvarezhm.. I think I'm going to go with the bsp-support.git option17:39
pedroalvarezI can also mirror the official repo, but it has way more things than I need17:39
persiaThe advantage of lorrying the official mirror is that you'll catch things if they change.17:45
persiaGiven the variety of things called "raspberry pi", this is probably a good thing.17:46
pedroalvarezjjardon: thanks for reviewing the GDP patch-set, and sorry I forgot about your comments, I had a busy week, and when cleaning up things today I found more things to fix than expected22:20
pedroalvarezI need to think about what to do with weston-gdp, I probably can use weston-genivi, but the weston-gdp version has this thing that you don't like (It sets WESTON_NATIVE_BACKEND depending on the architecture)22:22
pedroalvarezI believe this is essential to make weston work in our 2 GDP deployments (drm-backend for jetson, and fbdev backend for x86_64)22:23
pedroalvarezThis way the systemd unit that starts weston doesn't have to decide which one to use22:23
pedroalvarezWould it be possible to set that variable after installing weston? or does it have to be in the ./configure step when building it?22:24
jjardonpedroalvarez: question is; why do you need the fbdev backend for x86_64?22:30
jjardonalso, the drm backend is the default, so only the condition for x86_64 should be required22:36
pedroalvarezjjardon: hm.. is the drm backend available for x86?22:39
pedroalvarezI remember getting weston working with fbdev because it was the only thing available in a VM22:40
jjardonVM is not the same as x86_6422:40
jjardonin that case you have to use the fbdev backend, yes22:41
pedroalvarezheh, there is no way to know where the system will run22:42
jjardonyeah, you will have the same problem is you put your jetson image in a VM22:43
jjardonthis will be not a problem anymore when virgil get merged in qemu:

Generated by 2.15.3 by Marius Gedminas - find it at!