**** BEGIN LOGGING AT Fri May 02 02:59:58 2014 May 02 06:32:00 khem: if you have a chance can you look at the Autobuilder, we have across the board failures in oprofile: undefined reference to `bfd_elf64_powerpcle_vec' and bfd_elf64_powerpc_vec, I think it might be compiler related. May 02 06:44:55 sgw_: ok is it 4.9 ? May 02 06:46:52 and where are links ? May 02 06:51:48 nm got it https://autobuilder.yoctoproject.org/main/builders/minnow/builds/69/steps/BuildImages/logs/stdio May 02 06:54:52 buggy oprofile stupid null pointer reference May 02 08:10:05 khem: looks like there is also an mdadm issue :/ May 02 08:33:45 hi guys May 02 08:47:52 I am patching binutils for target board. I patched binutils (_class_target), I patched binutis-cross May 02 08:48:01 binutils-native is not patched - correct May 02 08:48:10 binutils-crosssdk is not patched - I think wrong May 02 08:48:27 since my sdk toolchain does not contain the patch (and it should) May 02 08:48:34 I'm bit puzzled what should I do next May 02 08:49:15 RP: blame me...I insist doing tests after 1 o'clock in the night ;) May 02 08:49:23 so the question would be - is binutils-crosssdk target part of my sdk toolchain? May 02 08:51:22 Xz: perhaps you actually want cross-canadian ? May 02 08:51:48 Xz: we also *hate* target specific toolchain patches May 02 08:52:22 RP: I added new flag to binutils, that flag works nice for all target binaries built by Yocto build. However when I build SDK and install it (.sh script), then my installed toolchain does not have the flag. May 02 08:52:53 Xz: you're probably missing it in binutils-cross-canadian May 02 08:53:10 RP: what is binutils-crosssdk then? May 02 08:53:32 Xz: that is the compiler used to build the SDK target May 02 08:53:56 RP: I thought binutils-nativesdk did that May 02 08:53:56 Xz: i.e. we use the crosssdk compiler to build binutils-cross-canadian May 02 08:54:19 RP: there are like 6 versions of binutils overall May 02 08:54:41 Xz: Correct May 02 08:54:51 RP: It always takes me a bit of time to think which does what May 02 08:55:01 RP: :) May 02 08:55:01 Xz: its easier if you think about something like a compiler on darwin May 02 08:55:47 Xz: for that you need a compiler which runs on BUILD but generates code to run on SDKHOST and when run on SDKHOST builds for target May 02 08:56:16 BUILD is 64bit x86, SDKHOST is darwin and TARGET could be 32bit uclibc x86 May 02 08:56:37 crosssdk runs no BUILD and generates SDKHOST May 02 08:56:49 RP: cool, I will try binutils-cross-canadian, thanks May 02 08:56:53 cross-candadian runs on SDKHOST and generates TARGET May 02 08:57:31 Xz: for some cases we substitute in things like odcctools instead of bintuils for darwin for example May 02 08:57:59 RP: is darwin officialy supported by Yocto? May 02 08:58:27 Xz: we do have the meta-darwin layer which can build SDKs which run on darwin May 02 08:58:49 Xz: BUILD as darwin doesn't work at this point, nor is it likely to any time soon May 02 08:59:46 RP: I thought meta-darwin was more like an experimental dev layer, not full production Yocto code May 02 09:00:04 Xz: the sdk pieces seem pretty stable May 02 09:00:19 its best effort support for it May 02 09:01:20 ok May 02 09:01:51 RP: Nothing PROVIDES 'binutils-cross-canadian' May 02 09:01:59 RP: in my case BUILD=HOST May 02 09:02:16 RP:I'm not using SDK machine May 02 09:02:18 Xz: try binutils-cross-canadian-i586 May 02 09:02:44 RP: that worked May 02 09:02:56 Xz: you must be using dora since ${TARGET_ARCH} was appended more recently May 02 09:03:45 RP: that fix is still for dylan :( May 02 09:04:03 RP: I upgraded to dora on branch however May 02 09:04:20 RP, do you know how well the state of meta-mingw is for generating win32 sdks ? May 02 09:04:50 Xz: well, its just called binutils-cross-canadian in dylan May 02 09:05:07 kroon: it can build gcc and binutils that run on win32 ok May 02 09:05:24 kroon: it has versions for dylan, dora, daisy and master May 02 09:06:36 RP, ah great. will give it a shot then May 02 09:20:51 gm May 02 10:04:22 RP: will binutils-cross-canadian always target only 'target' board? I used sth like 'SRC_URI_class-append-target' in normal binutils to prevent appending the patch to -native May 02 10:10:09 RP: answering my question - I don't use class-target for binutils-cross-canadian, since it runs on SDK machine May 02 10:20:45 I think I still don't understand where -crosssdk and -nativesdk are in my puzzle May 02 10:21:12 where are they built and where do they run? May 02 10:22:08 I understand as much as: BUILD runs -native, -cross; HOST runs -cross-canadian; TARGET runs - May 02 10:26:21 Xz: BUILD runs -native, -cross and -crosssdk May 02 10:26:37 Xz: SDK runs -cross-canadian and -nativesdk May 02 10:27:07 Xz: but seriously, the toolchain patch should be well enough written to apply everywhere and only trigger on the specific target its neeed for May 02 10:27:50 RP: are you telling my that I should apply the patch to every version of binutils? May 02 10:29:06 Xz: ideally that should not cause a problem May 02 10:29:09 Xz: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#cross-development-toolchain-generation May 02 10:29:23 ah yes I was just about to find and paste that link :) May 02 10:29:58 RP: it's is not as good right now :( May 02 10:30:27 RP: right now the patch adds the flag which is by default switched on May 02 10:30:34 so Yocto does not even know about that flag May 02 10:30:46 however if I explicitly add it to CC flags May 02 10:30:59 Xz: that is rather sad. If should be off by default and we start using the flag for the specific machines that have the issue May 02 10:31:00 then some tools fail, since they use CC flags for -native binaries May 02 10:31:23 I think ideally that should be part of 'tune' May 02 10:31:28 Xz: If you add it to TARGET_CFLAGS those should not get used for native binaries May 02 10:31:31 Xz: yes May 02 10:31:47 I played with TARGET_CFLAGS and smb used them for -native May 02 10:31:59 Xz: then smb is broken May 02 11:06:26 bluelightning: is there a way to add append to DISTROOVERRIDES and DISTROFEATURES from inside my custom layer ? This should take effect only when I am including my custom layer for creating a particular image. May 02 11:22:25 milan_1: you should have your own distro config in your layer for doing those kind of things, which you then select by setting DISTRO in your local.conf May 02 11:22:48 anything else is going to be a hack May 02 11:24:52 bluelightning: Looks like a sound approach... going to give this a try now. Thank you :) May 02 12:22:39 I've found a couple of PRINC uses in meta-raspberrypi, are PR bumps still being accepted into oe-core to keep the upgrade path clean? May 02 12:24:36 the files are recipes-bsp/formfactor/formfactor_0.0.bbappend with PRINC = "1" and recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend with PRINC := "${@int(PRINC) + 5}" May 02 13:25:13 Hi. Is there a way to get bitbake variables with newlines included? If I do d.getVar("VAR") it's all on one line :-(. May 02 15:32:04 what's the difference between meta-toolchain and meta-toolchain-sdk? May 02 15:41:57 Xz: I though we discussed this the other day... May 02 15:43:30 maybe my memory is faulty May 02 15:44:04 khem: morning May 02 15:47:40 Xz: IIRC meta-toolchain-sdk was renamed a very long time ago - where do you see a reference to it? May 02 15:58:38 bluelightning: it will be dylan May 02 15:59:35 RP: bluelightning yes, just after sourcing oe script it gives example bitbake targets May 02 16:00:47 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=ad4b709c835bb52a948dbe5d785aca4902cc8f1f May 02 16:01:19 we probably didn't remove the reference until 1.6 though May 02 16:02:34 "sdk" in that context means a gnome mobile sdk May 02 16:06:39 I love embedded systems, you run into settings that disappeared in the real world May 02 16:06:49 today: passwords longer as 8 May 02 16:07:05 volker-: that's fixed in 1.6 May 02 16:07:21 bluelightning: :) May 02 16:07:22 believe it or not the upstream default is still to use 8 chars max :( May 02 16:07:42 nothing against yocto, but in our case I was against it. It just should go on the NUC May 02 16:07:51 ick. which upstream? May 02 16:07:56 Now I have to deal with security updates & co May 02 16:08:14 kergoth: shadow May 02 16:08:17 ah May 02 16:08:19 that's sad May 02 16:08:59 http://cgit.openembedded.org/openembedded-core/commit/?id=a9e072f9f0da774411e07abf47dd4bd8c6d685d7 May 02 16:09:02 kergoth: very :( May 02 16:09:07 gm May 02 16:09:16 we are getting ready to start OEDAM May 02 16:09:31 hi Crofton May 02 16:09:39 Crofton: any chance of a video/audio feed? ;) May 02 16:09:52 I foud a camera May 02 16:09:53 someone must have a space laptop to set up a google hangout :) May 02 16:09:59 hang on May 02 16:11:04 rburton: space laptop? Is that one that is floating around over everyone's shoulder? May 02 16:11:21 that would be awesome May 02 16:12:44 autonomous quadcopter with a camera and mic, might be a little annoying buzzing around May 02 16:12:50 http://www.wirefresh.com/images/space-station-10-years-thinkpad-1.jpg May 02 16:14:38 morning Crofton May 02 16:19:17 * zeddii see fray on the google hangout May 02 16:21:16 morning RP May 02 16:21:19 gm May 02 16:22:28 did anyone else lose video on the oedam feed, other than a picture of jefro? audio seems fine, though May 02 16:22:38 * kergoth yawns May 02 16:22:42 I can hear but not see May 02 16:22:50 ya.. jefro turned off the video, too slow May 02 16:23:03 good May 02 16:23:04 ah that explains it! May 02 16:23:18 we figured out video was lagging about 3-4 minutes from realtime May 02 16:23:31 ahh, okay, audio works May 02 16:23:43 can you guys hear the introductions well enough? May 02 16:23:53 darknighte: unfortunately not ... May 02 16:25:37 there's a one second delay and repeat at the moment. May 02 16:25:41 (for me at least) May 02 16:25:59 yeah the hangout get sdelayes May 02 16:26:21 * zeddii hears darknighte May 02 16:26:21 I dropped off the hangout, to make sure I'm not causing any issues May 02 16:26:32 thats about a 15-20 second delay then May 02 16:26:38 Denys is now on May 02 16:26:48 * RP can hear denys May 02 16:26:50 and Crofton. May 02 16:26:57 audio is kind of choppy sounding May 02 16:27:00 whats the link? May 02 16:27:00 * zeddii tries to distract people talking May 02 16:27:00 now Linaro May 02 16:27:01 :) May 02 16:27:12 RP, sounds like you are nearly live then.. May 02 16:29:16 nice to have comcast on board! :) May 02 16:29:33 now michael May 02 16:29:40 and belen May 02 16:30:43 introductions of the remote people.. May 02 16:30:51 Richard is here, Yocto Project Architect May 02 16:30:56 Sorry couldn't be there in person May 02 16:31:29 Saul is here, User Space Maintainer and Richard's Sous Chefd May 02 16:31:46 nice May 02 16:31:59 Paul Eggleton here, OE TSC member & bitbake / core build sys engineer on Yocto Project @ Intel May 02 16:32:08 sgw_: you're a deamon these days? :) May 02 16:32:27 clang, clang. May 02 16:32:30 slip of the finger! May 02 16:33:18 * zeddii thanks his spokeperson fray May 02 16:34:24 that's "hash" OE to you guys ;) May 02 16:34:42 ih May 02 16:34:46 hi May 02 16:34:48 :) May 02 16:35:18 spork May 02 16:35:23 * RP notes the emphasis on long :) May 02 16:35:37 * mr_science needs food May 02 16:35:39 RP: tl;dr May 02 16:35:39 Ross (Intel) was hoping to be here but daughters are demanding baths. I'll be around later this evening. May 02 16:35:47 :P May 02 16:36:17 fray, can you summarize the list here, it's hard to hear sometimes May 02 16:36:41 they're going over agenda.. determining what to do today, with some people not ebing able to be here tomorrow May 02 16:37:42 :-) May 02 16:38:15 bug scrub, probably tomorrow morning US time May 02 16:38:20 RP: will you be able to make that? May 02 16:39:04 * fray does his best to -stop- kicking the metal backstop of the table that clangs -very- loudly.. :P May 02 16:39:28 darknighte: I can try and be around tomorrow, yes May 02 16:39:42 * RP has tried to keep this evening clear too May 02 16:40:43 review bugzilla 1.7 tagged stuff... May 02 16:40:57 I might be around later as well May 02 16:41:11 possibly tomorrow May 02 16:42:50 activity of layers as a possible indication of quality or at least maintainership May 02 16:43:19 Lune to possibly replace sato as the demo UI.. May 02 16:43:25 Lune is a WebOS/QT based layer.. May 02 16:43:30 I personally find this interesting May 02 16:43:46 this falls into the bin of more working stuff :) May 02 16:44:09 for OE/YP I see two demo issues.. showing the 'build' system doesn't help.. Toaster and a "working device" (UI) is a good demo May 02 16:46:44 * otavio likes the Lune move as well May 02 16:47:12 :) May 02 16:47:31 JaMa: do you have a link to some screenshots perhaps? ;) May 02 16:47:48 for image deployment/update best practices, if there's any suggestions for opkg, i'm around May 02 16:47:56 does link to virtualbox image work for you? May 02 16:48:56 JaMa: sure, I'll take it :) May 02 16:49:06 :D May 02 16:49:29 http://build.webos-ports.org/webos-ports/images/qemux86/ May 02 16:49:52 you probably want .zip file which includes .ovf file you can just import to virtualbox May 02 16:51:28 toaster is not yocto specific, works with standard OE too May 02 16:51:39 Its just yocto sponsored I guess May 02 16:51:53 rp +1 May 02 16:53:02 ya.. I consider it the same.. sponsored, and maintained.. but it's part of bitbake May 02 16:53:07 (repository) May 02 16:53:42 basically it wouldn't have happened without the YP :) May 02 16:53:57 HerbKuta: RP's e-mail: http://lists.openembedded.org/pipermail/openembedded-core/2014-May/092079.html May 02 16:54:28 can someone point me to a bbappend file that uses postfuncs? May 02 16:55:38 so far I have found the postfuncs only in bbclass files May 02 16:55:42 Lava May 02 16:55:46 on-going role of TSC May 02 16:55:50 Richards email topic(s) May 02 16:55:55 (plan for the morning) May 02 16:56:12 volker-, I've seen them.. but don't remember off hand which ones.. May 02 16:56:13 does the plan for the evening include beer May 02 16:56:28 We at O.S. Systems been trying to get LAVA working at our side May 02 16:56:36 been quite hard to get it working May 02 16:56:48 but we have people working on it May 02 16:57:05 otavio: you should mention that on the mailing list we setup to discuss it May 02 16:57:49 RP: I've been talking to Debian and Linaro people about it (we don't like running Ubuntu in server ;P) May 02 16:57:59 RP: so we're still in the beggning on it May 02 16:58:21 I'd be keen to see more discussion of people's progress on automated testing on the mailing list May 02 16:58:39 (the automated-testing@yoctoproject.org one) May 02 16:58:45 it's been a bit quiet May 02 16:58:51 bluelightning: we're trying those to see what fits better for us May 02 16:58:53 bluelightning: yes May 02 16:59:12 bluelightning: that's why I didn't comment on it yet. I still didn't make my head on it yet May 02 16:59:13 ok.. lava discussion time.. :) May 02 17:00:06 edgerouter May 02 17:00:17 mpc8315e-rdb (PPC) May 02 17:01:17 :) May 02 17:01:34 anyone else have the reverb/echo on the audio ? I wonder if it is just me. May 02 17:01:59 zeddii: not noticing echo, it can be hard to follow though May 02 17:02:01 talking about tests that we may be running on the autobuilder that could be moved into the lava environment.. May 02 17:02:11 most likely Intel and ARM are the primary targets of LAVA right now May 02 17:02:17 ok. I'm getting brutal echo. so it might just be my box. May 02 17:02:59 oh crap. I just figured it out. my gmail tab AND g+ were both playing audio. on a different delay. May 02 17:03:06 lol May 02 17:03:09 heh May 02 17:03:18 better May 02 17:03:23 my head hurts WAY less now. May 02 17:04:13 RP: zeddii agreed. hard to follow May 02 17:04:58 talk about needing packages feeds, compiler on target, etc to faciliate testing with LAVA May 02 17:05:06 (from the Yocto autobuilder) May 02 17:05:07 Crofton: what is the question? May 02 17:05:24 do we have any regular autobuilder images that include the compiler on the target May 02 17:05:34 we build the build-appliance image which contains everything needed to run a yocto build in it May 02 17:05:40 bluelightning: otavio: Out of curiosity, Is it confirmed that we are going ahead with LAVA for testing ? May 02 17:05:41 so we know the toolchains work! May 02 17:05:43 do we do that for all architectures? May 02 17:05:54 I know we test they work..b ut wasn't sure bout regular images May 02 17:06:09 fray: not build-appliance but we do build sdk images for all arches and run the automated tests against them May 02 17:06:29 we do test the compilers in those May 02 17:06:34 my understanding of the LAVA is we'd like the Linaro LAVA testing to use the output of the autobuilder for more test coverage May 02 17:06:49 maxin: several YP member organisations are adopting LAVA, so it's the direction we're heading in May 02 17:07:13 maxin: providing it can be made to work well for us May 02 17:07:15 maxin: About OE/YP this is not yet decided but O.S. surely will go ahead with it in our side May 02 17:07:18 dev images are built for all arches May 02 17:07:19 I am wondering why my bbappend file is not used. when I run --debug I see virtual:native:/home/data/yocto/poky/meta/recipes-extended/shadow/shadow_4.1.4.3.bb; now I am wondering if the do_configure[postfuncs] are not used because it states "virtual:native:" May 02 17:07:20 Crofton, i think this is a full package feed for ipk http://autobuilder.yoctoproject.org/pub/nightly/CURRENT/ipk/ May 02 17:07:29 bluelightning: thanks.. time to switch to LAVA then .. May 02 17:08:46 I've said this before but FYI for 1.6 we've added capabilities to export the runtime tests we've written so far in OE-Core to be run independent of the build system May 02 17:08:58 so LAVA should be able to run those without too much trouble May 02 17:08:59 maxin: bring some coffee ... it will be complex :P May 02 17:09:50 autobuilder publishes to http right now May 02 17:10:03 otavio: are you working on integrating lava in sense of providing lava-native you can build and then just run (independently from host system)? May 02 17:10:13 otavio: It will be a bit more complex to persuade people to switch from an existing test setup.. Anyway, guess, a common system will be nice :) May 02 17:10:26 http://autobuilder.yoctoproject.org/pub/nightly/CURRENT/machines/beaglebone/ May 02 17:10:35 volker-: is there a reason the bbclass examples don't work for you? syntactically it's exactly the same :) May 02 17:10:49 JaMa: in which sense you mean? May 02 17:11:19 kergoth: I want to run postfuncs in shadow_4.1.4.3.bbappend to enable SHA512 May 02 17:11:19 JaMa: you mean the peaces which need to run in the target or to build the distro to run in the LAVA server? May 02 17:11:29 I would like to see LAVA as something 'integrated'.. but immediate value of being able to just run it on a lava server would be nice May 02 17:11:46 volker- ahh you are talking post install (package) scripts.. May 02 17:11:56 I thought you were talking sysroot configuration (development time) May 02 17:12:17 maxin: yes May 02 17:12:25 I'll see if I can find an example May 02 17:12:27 otavio: "(we don't like running Ubuntu in server ;P)" this sense, can we include lava server in build-apliance? May 02 17:12:30 maxin: and LAVA installation is quite complex May 02 17:12:31 i think he's talking about the flag, to run source alterations other than patches at do_unpack/do_patch time, atually May 02 17:12:49 JaMa: yes; this would be a good solution May 02 17:12:56 fray: no, I just want to add a function to do_install to sed one file May 02 17:12:59 JaMa: for now we intend to use Debian as host May 02 17:13:10 volker-: just use do_install_append May 02 17:13:23 do_install_append() { May 02 17:13:25 JaMa: and try to have it working and easy to install/setup May 02 17:13:29 stuff to do in additional to do_install May 02 17:13:30 } May 02 17:13:43 otavio: ok fair enough May 02 17:13:48 JaMa: once this is doable, making a recipe for this shouldn't be hard ... May 02 17:13:55 otherwise it's pkg_postinstal_ () { .... } those are install time settings May 02 17:14:06 JaMa: but it is far from it yet May 02 17:14:31 * RP notes we have easy setup instructions for the autobuilder right now May 02 17:14:46 lava is by comparison hard to setup :( May 02 17:15:39 kergoth: thats it. just wondering why do_install[postfuncs] neither worked nor spit out an error May 02 17:15:57 should work fine, if you want to do that May 02 17:16:04 postfuncs isn't what you want in this case.. you want appends IMHO May 02 17:16:32 agreed May 02 17:16:50 yeah May 02 17:17:00 though sometimes i wish _append/_prepend was backed by postfuncs/prefuncs, to avoid the appending shell to python madness ;) May 02 17:17:02 so it works now, now I am wondering why the --debug didn't show the bbappend file (which is definitly used as I can see now): bitbake -c clean shadow-native ;bitbake -c build shadow-native --debug|grep bbappend May 02 17:17:25 volker-: bitbake-layers show-appends|grep shadow May 02 17:17:51 kergoth: I would still have expected it in --debug May 02 17:18:39 Phone! Answer it heh May 02 17:18:44 :) May 02 17:19:25 volker-: our debug output could certainly use work May 02 17:19:58 I suspect that because it's not that useful, not many use it - we use other means of finding such information May 02 17:20:38 I don't use --debug.. I use live logging (local patch to bitbake), bitbake -e , and looking at logs/run files.. May 02 17:23:41 sgw_: May 02 17:23:43 gm May 02 17:26:51 Hi Khem, sounds like good discuss, wish I could be down there this week. May 02 17:31:11 fray: Worth mentioning the error reporting server? May 02 17:31:25 fray: we've talked about collecting more data with that May 02 17:31:52 ha.. I was just msging someone about that.. May 02 17:32:01 thats more build errors though right? May 02 17:32:13 this is collecting build errors? May 02 17:32:21 y May 02 17:32:29 this is also cool :) May 02 17:32:46 fray: right now it collects those, yes May 02 17:32:56 Crofton: people can submit them, yes. new feature in 1.6 May 02 17:33:16 world builds now do (unless the report is too big to upload) May 02 17:33:23 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-the-error-reporting-tool May 02 17:34:03 http://errors.yoctoproject.org/Errors/ May 02 17:35:01 We are talking about scaling that system to take extra data. Perhaps performance data? May 02 17:35:41 any type of runtime test data, yes May 02 17:36:02 * JaMa already has fork reporting "build matrics", I plan to show it to belen to see what she thinks about it and integration with toaster/error-report-web May 02 17:36:03 clang May 02 17:36:19 that would be me.. :P May 02 17:36:40 it feeds into a database May 02 17:36:45 its not conencted to the bugzilla May 02 17:37:05 we don't want to automatically connect it May 02 17:37:18 Its like a failure pastebin May 02 17:37:28 it's mostly about collecting all of the information we otherwise rely upon users correctly extracting and reporting themselves May 02 17:37:52 the suggestion is add a button to fiil a bug template and submit it May 02 17:37:57 fray: exactly - the statistics will be interesting May 02 17:38:09 we need to figure out how to match up failures but we can do than once we have some data May 02 17:38:14 I'm really looking forward to statistics.. even failures due to bad configurations.. ;) May 02 17:38:30 fray: totally, I think we could learn some interesting things May 02 17:39:12 misconfiguration is one of those things if we could "detect" via common bugs, we could then return back "this is how to correct it" info.. :) May 02 17:39:33 fray: exactly, ultimately I'd like to tag things with solutions May 02 17:40:02 i thought this idea was also somewhere on the agenda, ie, a more "formal" aproach to bug wrangling May 02 17:40:11 people are off looking for display equipment.. 9and taking a break.. ;) May 02 17:40:43 RP, fray: the querying capabilities of the existing tool are very limited, though. As data comes in we might need to enhance them so that you people can get the information you need from it May 02 17:42:31 belen, yup.. this is future work.. :) May 02 17:42:53 belen: totally agreed. We need some data, then we can experiment and design :) May 02 17:44:49 RP/belen this is some of the stuff that David R is trying to setup for our WR products.. it's the infrastructure to support this that we really want.. (community and commercially) May 02 17:44:59 over time I expect more community data transform/displays.. May 02 17:45:02 fray, are we supposed to see something? May 02 17:45:13 not yet.. May 02 17:45:34 we've figure out the projector in the room.. and jefro is figuring out how tuse to the web cam to show you May 02 17:45:57 I see a small icon for the slide I think, maybe make that person the speaker May 02 17:46:18 If I click on that icon it comes up on my screen May 02 17:46:38 not sure May 02 17:47:01 cool May 02 17:51:44 does anyone know anything? :) May 02 17:51:57 nope.. I know nothing.. May 02 17:52:18 as any normal tech meeting, 1/3 of the room is playing IT.. 1/3 is typing and 1/3 is ignoring everyone else.. :) May 02 17:52:23 I am seeing video of some of you now :) May 02 17:52:41 * RP waves to fray May 02 17:52:47 :) May 02 17:53:24 * sgw_ waves back May 02 17:55:08 can people see the slide(s)? May 02 17:55:31 fray: from Alan? yes May 02 17:55:35 lava is like bitbake for testing! May 02 17:55:36 yup May 02 17:56:45 where? I see nothing May 02 17:56:53 lol May 02 17:57:02 Crofton: pertect definition lol May 02 17:57:27 fray: they're not advancing unless you're still on the title slide May 02 17:57:34 Crofton: in the past when it were most of time broken ;-) May 02 17:57:52 it's ont eh 'Vocabulary slide' May 02 17:57:52 RP: where is the slides? May 02 17:58:27 otavio: from Alan's video feed afaict but its just the title one May 02 17:58:43 video feed might be delayed May 02 17:58:46 yep same here May 02 17:59:02 fray: the other video feeds look in realtime May 02 17:59:03 I think that we are seeing the desktop screen, not the projected screen May 02 17:59:14 so left side.. kernel source -> jenkinx -> "raw artifacts" May 02 17:59:21 other builds -> "raw artifacts" May 02 17:59:37 slide the jeffery camera over to the screen May 02 17:59:40 "raw artifacts" <--> laval (job control, test and boot logs) May 02 17:59:55 not the one with Jefro the one looking at Alan's body! May 02 17:59:56 "raw artifacts <--> Generic board farm May 02 18:00:38 much better May 02 18:00:40 that better.. 4 minutes or less.. :) May 02 18:00:40 thats better May 02 18:02:10 where is the video link? May 02 18:02:18 should be the google link May 02 18:02:27 was just on the main page when I connected earlier May 02 18:03:18 i can't find it either, just got the original video link which seems to have ended May 02 18:04:05 ohhh now I see May 02 18:04:06 maybe you have to reload? May 02 18:04:08 someone tell jefro it's off-air May 02 18:04:39 what is? May 02 18:04:39 still on here May 02 18:05:19 still here too May 02 18:05:21 I can still see it, but it might explain why Paul isn't able to do so May 02 18:06:30 fray: in the top right it says "OFF AIR" instead of earlier when it said "LIVE" May 02 18:06:44 jefro was trying ot fix May 02 18:07:55 still having issues? May 02 18:09:57 paulbarker: ^ ? May 02 18:10:07 sorry, yes, i'm still lost May 02 18:10:21 it still says "OFF AIR" FWIW May 02 18:10:35 somewhere the moderator should have a switch for that May 02 18:11:07 The latest samba recipe is 3.6.8 which is kinda old. May 02 18:11:53 bluelightning: paulbarker: jefro is still working on it May 02 18:12:06 I just have the original google+ event invite with the video which has finished May 02 18:12:08 ok, now Jefro's gone so there's no audio at all May 02 18:12:27 if it's just me that's missing don't worry May 02 18:12:42 jefro is being beaten May 02 18:12:42 jefro is going to restart.. May 02 18:12:48 back in 10 min or so, will give it another try then May 02 18:12:54 I think I'm going to have to head home in a sec May 02 18:12:59 what we'e said is goal is multiple systems, multiple visualizations for various components.. May 02 18:13:13 build error reporting, toaster, runtime test, autobuilder, etc.. May 02 18:13:15 WE MUST HAVE ONE GRAND UNIFIED TOOL! May 02 18:13:33 over time we can work on putting those together for a visualization, but we want the 'unix' model of lots of small tools that can work together May 02 18:13:33 Someone is taking notes? So we discuss things in ml right? May 02 18:14:02 wiki page? May 02 18:14:09 step 1 -- autobuilder assets to LAVA May 02 18:14:14 yeah we are having DarkKnight collect the actoins May 02 18:14:15 fray: we've back now, thanks May 02 18:14:16 step 2 -- existing lava tests to those assets May 02 18:14:30 at least audio anyway May 02 18:14:32 step 3 -- adding 1.6+ tests to lava... May 02 18:14:42 (this is bill talking BTW) May 02 18:14:53 low hanging fruit.. lets prove this works and is useful May 02 18:17:17 FYI, we added basic capabilities in this area in master (deploy an image and run the tests) for EFI (via gummiboot), beaglebone, and edgerouter May 02 18:18:54 the idea being that gives us coverage for our QA requirements now May 02 18:19:30 we're breaking up temporarily.. :/ sorry.. May 02 18:19:35 even when we make use of LAVA for our QA, it can still be useful for running tests on a single board connected directly to a developer's machine May 02 18:22:49 I don't think we have 2000 tests May 02 18:23:10 yup May 02 18:23:41 no, 2000 doesn't sound quite right :) May 02 18:23:49 lol May 02 18:25:09 I'm going to have to head out in 5 mins May 02 18:27:21 bluelightning: sounds like its lunchtime there May 02 18:27:46 right, good timing :) May 02 18:28:03 * RP should cook something... May 02 18:34:57 back for now, I don't have much to add on LAVA and testing but may be able to add a few comments to later items on the agenda May 02 18:36:11 just give me a ping if theres a new link for the video or if it should be re-started May 02 18:36:18 paulbarker: will do May 02 18:36:29 i join the hangout and the first thing i hear is "i am ordering pizza" May 02 18:36:31 you bastards May 02 18:37:03 i've got a segfault to debug which should keep by plenty busy in the meantime :) May 02 18:37:14 mmmm.... pizza.... May 02 18:37:24 RP: you here? May 02 18:37:46 exactly. maybe i'll go and find dinner myself, the audio quality isn't excellent. May 02 18:38:22 but my 2c as the Sato "maintainer" is that proposals for replacements are welcome May 02 18:38:45 rburton: that's on the list for discussion, but is 2 more items down the list May 02 18:39:22 yeah, i'll be back later to check in May 02 18:50:14 * RP is back around May 02 18:51:04 RP: Good news. The OE TSC still exists. ;) May 02 18:52:05 darknighte: er, good, I think? :) May 02 18:52:26 I don't want to replace anybody, but I'm fine now with steping up if needed May 02 18:52:28 hehe. May 02 18:53:00 * RP hasn't heard anyone wanting to step away May 02 18:53:11 fray: I think most people are in that position May 02 18:53:12 For context, I made a tongue-in-cheek suggestion that we do away with the TSC and fray, sorta took me seriously May 02 18:54:17 I've heard that before, not so tongue-in-cheek.. :) May 02 18:55:28 RP: Any objection to my submitting this bbclass to oe-core for the 1.7 timeframe? https://gist.github.com/kergoth/8410245 I think there'd be value in providing this feature. Alternatively, could pursue bitbake or base.bbclass support for it. Thoughts? May 02 18:55:55 * kergoth 'll open a request in the bugzilla, just wanted to check on the overall response to the concept first May 02 18:56:30 kergoth: I'd be happy to see it in bitbake to be honest May 02 18:57:03 not sure hwat it is.. ;) May 02 18:57:08 * kergoth would love to see us pare down the global exports, and this would make it a bit easier to move in that direction May 02 18:57:13 ker1 May 02 18:57:16 RP: okay, I'll look in that direction. thanks May 02 18:57:22 kergoth: I was just thinking the same May 02 18:58:27 the tough ones to trim down would be CC, etc. autotools.bbclass could export them in do_configure, but do_compile/do_install are stuck with them for non-autotools/cmake/etc, since we don't have a "make" bbclass :) but there are others we could trim down too May 02 18:59:15 Moving to http://lists.openembedded.org/pipermail/openembedded-core/2014-May/092079.html May 02 18:59:38 kergoth: I wondered about a make class. Would be a pain to switch to but possibly worthwhile May 02 19:00:57 maybe we could make the -e in default EXTRA_OEMAKE die in a fire too someday :) May 02 19:03:38 kergoth: yes :) May 02 19:04:43 fray: yes, even documented those workflows as we can make them work today, that would be a good first step May 02 19:07:56 nerdboy: so, you essentially said something similar to "we migrated from Poky to Yocto"... grrr May 02 19:08:59 sorry? May 02 19:09:05 we have started an effort to document the workflow. It's still very rough, though May 02 19:09:07 https://bugzilla.yoctoproject.org/attachment.cgi?id=1930 May 02 19:09:30 denix: i thought i said arago classic... May 02 19:09:50 mr_science: cause you keep saying "migrated from Arago Project to Yocto" May 02 19:10:30 mr_science: what you mean is "migrated from OE classic to OE core" or "from OE core to Yocto" etc May 02 19:10:50 yeah, that's more precise May 02 19:11:00 mr_science: since Arago exists in OE-core and Yocto world May 02 19:11:02 belen: that is quite interesting. I should sit down with you and complicate that sometime :) May 02 19:11:23 RP: yes May 02 19:12:08 belen: interesting, nice start May 02 19:13:03 kergoth: we need people to pitch in, so if something doesn't look right in that diagram, let us know May 02 19:13:23 * kergoth nods, will take a closer look and point folks at his work at it May 02 19:15:29 fray: bitbake X S printdiff is a step forward if you've not seen it May 02 19:15:40 bitbake X -S printdiff May 02 19:16:32 tell Bill to see the locked sstate idea in the email :) May 02 19:16:34 as long as you didn't use an sstate mirror, anyway :) need those intermediate siginfos May 02 19:16:58 kergoth: the mirrors should have those now May 02 19:17:02 RP, fray is doing a good job channeling you May 02 19:17:10 RP: pstage_fetch downloads them? May 02 19:17:19 Crofton: that would be the intel mind meld May 02 19:17:34 last time i looked it didn't, it just downloads the sstate archive and associated siginfo file, which doesn't have the intermediate data, unless we started emitting depednent task info in that siginfo file May 02 19:17:42 * kergoth shrugs May 02 19:18:03 kergoth: I believe it should grab them now May 02 19:18:23 kergoth: I might not have covered all cases I guess May 02 19:21:36 pizza looks to be here.. May 02 19:22:09 again with the pizza May 02 19:22:46 RP: I must be missing something. dump_sigtask seems to still only emit data for the one task, and sstate_setscene only runs sstate_installpkg on the one ss object, and sstate_installpkg is the only task that runs pstaging_fetch. Where can I find what you're talking about? May 02 19:22:58 I'm sure I must just be missing it, maybe I didn't follow the code correctly May 02 19:24:28 Crofton: exactly, we document something to start with, then we can improve them May 02 19:25:40 * kergoth gets food May 02 19:26:58 kergoth: its triggered by runqueue.py calling the HASHCHECK_FUNCTION (sstate_checkhashes) in sstate.bbclass iirc May 02 19:27:24 kergoth: print_diffscenetasks() calls that checkhashes function which was intended to try and find the siginfo iirc May 02 19:28:17 kergoth: I suspect what is missing is a way to trigger the checkstatus() to actually run the download May 02 19:28:20 goes to get food.. comes back shortly.. May 02 19:28:48 * RP heard mention of drinks, then the noise took over May 02 19:28:56 RP: yep, thats what i was jsut about to say after reading it. it seems to check to see if it's there, and then not do much with that information :) thanks for the pointer May 02 19:29:17 kergoth: I probably had a local patch that has gotten lost or something :/ May 02 19:29:39 heh, know how that is. I have so many branches in so many trees i'm always losing track of what's where. sometimes end up reimpementing something :) May 02 19:31:46 * rburton cooks to the dulcet tones of many people chatting, captured terribly via hangouts May 02 19:44:07 rburton: here, I have it going through the power amp with the volume up so I can understand it. The neighbours probably think I have a party going on :) May 02 19:45:58 * rburton dropped to watch the last of the downhill world cup May 02 19:47:47 lol May 02 19:49:25 i like how hangouts does a soft-mute when you press the mute button, so it can tell you if you're talking on mute May 02 19:56:00 lol May 02 19:58:17 does yocto provide a way to cross-execute executables? (https://wiki.samba.org/index.php/Waf#Using_--cross-execute) May 02 19:58:51 yes, using qemu May 02 19:59:03 only use if its impossible to built native tooling May 02 19:59:15 (ie fontconfig uses it because the fontconfig cache format is target-specific) May 02 19:59:37 whereas mesa builds native tools directly because the output is platform independent May 02 20:09:33 looking into fontconfig, I only see there the line 'BBCLASSEXTEND = "native"', now ;bitbake samba4-native -c configure does not do the trick (where samba4 is the recipe name) May 02 20:13:10 we've resumed.. "why is embedded difficult" May 02 20:15:29 volker-: see fontcache.bbclass May 02 20:16:08 * RP notes we do all have various ways we can do quick hack'n'dev with OE May 02 20:16:27 yup.. May 02 20:16:30 e.g. bitbake X -c compile -f and then a rsync task which blasts it onto the target May 02 20:16:41 documenting them is key May 02 20:16:54 where there is commonly used functionality, we can write classes etc May 02 20:17:10 documenting is the first key.. like I said before, list of steps.. May 02 20:17:18 then it's look at the steps and simplify May 02 20:17:25 volker-: or pixbufcache.bbclass May 02 20:18:11 RP: that are all classes. I want to have it in a recipe. Right now I am looking through fontcache.bbclass and don't get the clue May 02 20:18:44 volker-: try pixbuf and the inherit qemu May 02 20:22:29 * RP wonders what would happen if we publisised the sstate from the autobuilder by default in builds May 02 20:23:20 I think there's still some work to do in optimising and making use of sstate May 02 20:23:25 fray: what was that point? May 02 20:23:32 bluelightning: agreed, very much so May 02 20:23:54 I said that shared-state was a good answer to both the integrator issue (slow builds), and for getting images built for deployment.. May 02 20:24:09 fray: right, thanks May 02 20:24:10 but it "works" now, so the next step is package feeds, for the class of users who are "using" the base OS.. May 02 20:24:18 RP, We would need to move the autobuilder something with greater available bandwidth for that to be feasible. (Which is something we are looking into now.) May 02 20:25:02 halstead: terabytes of output though is a problem, we shouldn't have that much to share in the first place IMO May 02 20:25:41 halstead: or mirror the data somewhere with the bandwidth, yes May 02 20:25:59 halstead: I'm just talking about the idea, so don't panic yet :) May 02 20:26:28 bluelightning: this is from all the rebuilds on the AB of things like master-next and mut May 02 20:26:35 I'm not panicked RP. Solving infra problems is fun. :) May 02 20:26:47 RP: right May 02 20:27:01 RP, i was talking about that earlier in some way.. what I see the sstate being useful for (sharing) is the "big" early blocker items.. cross-toolchain primarily May 02 20:27:04 halstead: If the infrastructure were capable it would be interesting to try it May 02 20:27:18 fray: unfortunately that is also large May 02 20:27:43 yes, but it's one of the components I see that someone with "modern" bandwitdh (say 10 Mbit/s) on a moderate mchine can download faster then rebuild.. May 02 20:27:45 fray: with the changes just landed in master we now have one toolchain for each arch which will help the size May 02 20:28:02 fray: agreed May 02 20:28:45 (unrelated to this topic) for the single arch toolchain.. I was wondering if we should consider creating a custom gcc "spec" with '-t' options to specify the multilib/tune/etc with a single command instead of the long set of -march, -mtune, -m.... May 02 20:30:09 fray: I'm not sure we have an issue with that but its something to think about May 02 20:33:23 could consider bittorrent to help with distribution but it would depend on how many different sets of bootstrap sstate there are to share and how often it changes May 02 20:34:58 RP's locked sstate patches provide the capability to do what Bill is talking about May 02 20:35:24 it would prevent the rebuild.. but it would likely error and say hey this is a dependency May 02 20:39:31 visual dry run would be nice :) May 02 20:40:19 bitbake X -S printdiff is effectively a dry run in that it will tell you where the differences start May 02 20:42:44 external compilers are hard since in reality its the compiler and the libc and lingcc. When you get libc/libgcc involved, things get harder as those have to be packaged May 02 20:42:51 locked sstate is the way forward for that IMO May 02 20:43:21 what I was saying was SDK compiler, and a standard way to use it.. (and validate it's the 'right' compiler) May 02 20:44:02 it won't be 4TB May 02 20:44:05 it doesn't have to be 4TB of sstate May 02 20:44:11 its the size of the toolchain May 02 20:44:12 Saul is still here May 02 20:44:25 its say 200MB May 02 20:44:30 if that May 02 20:45:08 that's not too bad... May 02 20:45:15 fray: I am in view only mode May 02 20:45:43 RP, Is it a matter of identifying the correct 200MB? May 02 20:46:36 halstead: yes, being selective about what we publish effectively May 02 20:46:38 ? May 02 20:47:05 halstead: yes, we could filter the sstate directory relatively easilyt May 02 20:49:02 If it is below 5GB that should be easy to distribute. In fact if it is 5GB or less and the largest file is 200MB or less I can get a grant for free CDN services to distribute. May 02 20:49:46 for a developer on a <10Mb connection that means overnight May 02 20:50:20 * sgw_ dropped I will read minutes later, sorry May 02 20:52:49 ka6sox-here, I would think a developer with low bandwidth would choose not to use distributed sstate. But if we can get important files on a CDN that would be effectively full speed downloads for people with higher bandwidth. May 02 20:55:47 halstead: part of the problem is the turnover. For something static like a release like dora, it wouldn't change much. master changes a lot May 02 20:56:05 * halstead nods. May 02 20:57:08 Is sstate valuable for releases without following master? May 02 20:58:28 halstead: for release, its in theory exactly what the user would build, so yes, it would be a valuable new user speedup May 02 20:58:54 what is the downside of -native builds? May 02 20:59:02 time May 02 20:59:17 only time? May 02 21:00:08 volker-: pretty much May 02 21:00:08 That reminds me, would be nice to create a little class to set up license-filtered sstate mirror population, to cover cases where one might not have redistribution rights to binaries May 02 21:00:24 kergoth: I have worried about that, yes :/ May 02 21:00:55 we should really add something to the bugzilla for that May 02 21:01:09 is there a way to only allow -native builds of a package without overwriting each config(), patch() etc? May 02 21:02:00 call it something-native and inherit native May 02 21:02:35 This is a screen capture of how I'm seeing this call: http://dan.rpsys.net/Jefro.mp4 I'm slightly unsure if hypnosis is intended and what the message may be... :) May 02 21:03:10 volker-: or raise a SkipPackage in the target case (and not in the native) May 02 21:04:03 SkipPackage does not seem to be documented in 1.5.1 May 02 21:04:11 code digging May 02 21:04:25 rp, rofl May 02 21:04:52 TAINTED: xyz May 02 21:05:24 volker-: try something like recipes-support/libiconv/libiconv_1.11.1.bb May 02 21:06:15 I have no mirrors at work :) May 02 21:07:20 yocto has so many hacks to accomplish things. But somehow it misses a good reference page for all of them. May 02 21:07:56 volker-: if SkipPackage isn't in the manual, we should document it, I will make a note of thatr May 02 21:08:02 It should also be called SkipRecipe May 02 21:08:31 Can I just say we once did try reusing the SDK toolchain May 02 21:08:32 RP: that's bothered me for a while, we should alias it in 1.7 and deprecate SkipPackage May 02 21:08:40 rp sure :) May 02 21:08:44 RP: maybe not in the main developer documentation. But I found good examples after grepping for it. Usage with python __anonymous() May 02 21:08:48 reusing the SDK toolchain was a complete and utter disaster May 02 21:08:58 I appoint fray to find out if works yet :) May 02 21:09:13 we should deprecate __anonymous while we're at it, just to increase metadata consistency May 02 21:09:15 Crofton: It is NEVER going to work well and we are not supporting that May 02 21:09:28 World of pain that still gives me nightmares May 02 21:09:36 kergoth: great, I learn something that is broken the next time ;-) May 02 21:09:45 instead I'd rather rewrite the SDK to be built from sstate May 02 21:09:54 volker-: just use python () { instead of python __anonymous (). both do the same thing, but the latter is unnecessary May 02 21:10:19 :) May 02 21:10:34 kergoth: yes May 02 21:13:29 man, I tortured myself for hours to get samba build without success. And then I got indirectly pointed to native and it works like charm... May 02 21:16:18 of course a native build is no good for the target May 02 21:17:55 quantity that are on github vs. actually indexed in the layer index *is* still a problem though... May 02 21:18:12 bluelightning: yes :( May 02 21:18:33 Crofton: No, we don't May 02 21:18:35 I've seen a -lot- of duplicates on github.. people seeb to copy layers into their own githubs and make their custom changes (fork?) May 02 21:18:53 fray: there are a ton of original layers there too May 02 21:18:57 Crofton: The policy is that we do not support that unless someone joins the triage team to help out with the bugs May 02 21:19:03 yes May 02 21:19:10 forks are half the point of github :) not too surprising there May 02 21:19:33 it's a real shame that the people who are publishing them don't see the value of the small extra step of putting them into the index May 02 21:20:23 fray: thank you for conveying that :) May 02 21:21:14 bluelightning: you cannot expect them to. We need to make some (gentle) noise about it May 02 21:21:30 a lot of people show up on the mailing list asking to find recipes which could easily be found by searching the layer index so perhaps it needs to be more publicised May 02 21:21:35 (or people may just be lazy) May 02 21:21:43 belen: I do keep complaining about it on here and in the mailing list, it's not had a lot of effect May 02 21:22:20 bluelightning: we can make it a criteria for yocto project compatible May 02 21:22:26 not that it will help this problem May 02 21:22:35 bluelightning: maybe we need to reach out further than the mailing list and the channel May 02 21:22:36 RP: might not hurt at least May 02 21:22:49 belen: might be an idea yes May 02 21:32:52 samba4 source code comes with 22 different LICENSE files May 02 21:34:18 paulbarker: I'm open to suggestions about how to better promote it May 02 21:34:33 the new website when it arrives may help May 02 21:36:42 and there are 9 unique licenses in this 22 license bundle May 02 21:37:38 JaMa: its a hard task, you're doing a good job and I hope we can encourage some more people to help... May 02 21:37:43 bluelightning: there's no poky in the layer dep selector May 02 21:37:48 http://community.validation.linaro.org/scheduler/job/11600 May 02 21:37:56 mr_science: use OE-Core ;) May 02 21:38:00 should be meta-yocto I guess? May 02 21:38:08 mr_science: openembedded-core May 02 21:40:40 * RP is in favour of wider use of the error reporting system, we just need it opt in May 02 21:40:47 http://community.validation.linaro.org/scheduler/job/11600/log_file May 02 21:40:50 i swear i thought i did that already, so if i did it got rejected May 02 21:41:09 bluelightning: thanks for reminding me... May 02 21:41:43 RP yup May 02 21:42:17 need to figure out what that lava job did :) May 02 21:42:26 akbennett, had to leave for th eairport May 02 21:43:43 mr_science: I think you submitted another layer, but not this one... FWIW I've just published this one, thanks :) May 02 21:43:59 RP: the patch I've sent was opt-in, but it doesn't prevent distribution maintainer to flip the flag and opt-in for whole distro by default May 02 21:44:56 fray: meta-selinux *is* in the layer index FWIW ;) May 02 21:45:56 re perl if anyone is keen there's a ton of recipes waiting to be integrated - they just need some cleanup May 02 21:46:10 Yocto 1.5.1, meta/files/common-licenses/PD: "This is a placeholder for the Public Domain License" May 02 21:46:20 bluelightning yup.. :) May 02 21:46:34 volker-: I think that came from SPDX May 02 21:46:35 JaMa: I think ultimately we should do this on a user by user basis, maybe something in $HOME May 02 21:46:37 re perl, I didn't know that May 02 21:46:58 bluelightning: can you prioritize "tons"? May 02 21:47:14 fray: I've been holding onto them since the original submitter never finished fixiing them up for integration May 02 21:47:27 mr_science: maybe tons is an exaggeration, but it's a few May 02 21:47:29 one sec May 02 21:47:39 bluelightning: were these mind or some others? May 02 21:47:42 mine May 02 21:48:02 RP: well there were those too May 02 21:48:06 I was referring to https://github.com/EmilRP/public_bb_recipes May 02 21:48:18 RP: but then it doesn't help with our use-case (not sure if it was understandable in audio) May 02 21:48:30 (+ pull request of mine on that repo not yet applied) May 02 21:48:33 JaMa: the company wide one? May 02 21:48:40 we want to enable/disable it for *all* internal builds May 02 21:48:41 yes May 02 21:49:09 if it's file in $HOME then my next task will be to update "setup-scripts" to create that file for all developers May 02 21:49:22 JaMa: but I think that might be the correct way to do it May 02 21:49:25 Crofton: we can auto-update the db if people start using that file - FYI already have code to read it May 02 21:49:46 JaMa: I worry about the day someone sets some distro config and all of a sudden a user leaks data they shouldn't have :/ May 02 21:49:59 the NSA already knows May 02 21:50:10 running a script that does it is quite different to bitbake doing it based on config May 02 21:50:16 Crofton: ah but they know everything, it's us that needs to know :) May 02 21:50:41 as distro maintainer I can create distro-version.bb recipe which will copy their whole $HOME, if they don't care what their distro do, then they cannot prevent leaking all data May 02 21:51:49 JaMa: but that doesn't mean I should take a function into the core so that all distros can do this using a common function :) May 02 21:52:15 :) May 02 21:52:35 JaMa: I'll likely end up patching our autobuilder scripts to set this up too but I do think its the right level of configuration May 02 21:53:52 Maybe a really simple sign-up for the public error reporter might help May 02 21:53:59 internal error reporter - no sign up May 02 21:54:25 public error reporter - signup with an API so we can have a 'enable-error-reporting' script which does the signup May 02 21:54:44 then dump a key somewhere which is used for submission to the public error reporter May 02 21:55:09 a distro maintainer would have to distribute that key which could easily be spotted as being used from many many hosts May 02 21:55:11 just an idea May 02 22:07:58 thanks for staying up guys May 02 22:08:16 Crofton: are things finishing there? May 02 22:08:27 RP: short break May 02 22:08:31 Crofton: when you all start talking its hard to know what is going on :) May 02 22:09:06 paulbarker: I think I spotted the bug, I've replied to your mail May 02 22:09:09 RP: it's recess, everyone talks and stretches legs... May 02 22:09:24 we're taking a 10 minute break May 02 22:09:35 denix: fair enough. I gave in and went and made tea before ;-) May 02 22:10:03 Its fun the odd comments that come clearly through the noise May 02 22:10:19 RP: Cheers for that, glad I asked, I'd have never worked it out without knowing about bitbake-diffsigs. I've still got plenty to learn! May 02 22:10:33 such as darknighte talking about plagiarism :) May 02 22:11:21 paulbarker: bitbake-diffsigs is invaluable when dealing with the sigs. It take one file to dump or two files to compare May 02 22:11:29 :) May 02 22:13:20 RP: Do you want to fix the codeparser or shall I change the package_ipk code to use d.getVar() where possible? May 02 22:13:32 paulbarker: fix codeparser May 02 22:14:46 RP: ok, i'll leave that to you May 02 22:19:51 whatever Intel is doing with the NUC. The only available new Atom NUCs have prices way above the retail price. May 02 22:21:26 paulbarker: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=f3cc05644aa9ba9fa3676ae564e90866925b12c4 if you want to test May 02 22:21:33 except that misses the cache version bump May 02 22:22:28 paulbarker: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=ec27b843d5b930929e6a3ea523d274ad48cecf15 May 02 22:23:58 RP: I'm building on daisy & bitbake 1.22, I'll cherry-pick it. Only immediate thought is: does .getVarFlags() matter? May 02 22:24:47 paulbarker: No, we don't do magic on that May 02 22:35:19 RP: Looks like bitbake wants to do a full rebuild. I'll check back on it in an hour May 02 22:39:24 heh, surprised we never noticed the localdata.getVar problem before :) May 02 22:39:27 well spotted May 02 22:42:42 paulbarker: a lot of checksums likely changed as a result of this May 02 22:46:06 RP: Yea, sounds right. I'll let the rebuild finish and kick off another, that 2nd one should do nothing if the checksums are stable. Then change my variable, kick off a 3rd build and ensure the change is picked up May 02 22:46:29 paulbarker: sounds like a good test May 02 22:51:46 bluelightning: http://layers.openembedded.org/layerindex/branch/master/layer/meta-alt-desktop-extras/ <= how's that? May 02 22:53:13 Hi. I was wondering... has anyone tried to build a yocto-based image with a read-only root filesystem before? May 02 22:53:37 bryan_: yes, all my builds here are ro-rootfs May 02 22:54:33 bryan_: I have my own distro, else in local.conf: http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#creating-a-read-only-root-filesystem May 02 22:55:26 Hi volker. I added read-only-rootfs to EXTRA_IMAGE_FEATURES. My build failed, and after digging I found multiple postinsts which needed to be run on the target on first boot, which is obviously problematic. May 02 22:55:58 bryan_: your build fails or when you boot the build? May 02 22:56:13 bryan_: I mean 'boot the image' May 02 22:56:25 The build fails with "ERROR: Some packages could not be configured offline and rootfs is read-only." May 02 22:56:43 and tons of other output, but that is the important one. May 02 22:57:33 bryan_: sorry, don't know. I have only a minimal distro here with manual cherry-picked additional packages and didn't run in such kind of problems May 02 22:57:38 bryan_: what do you try to build? May 02 22:57:47 Out of curiosity, what is the reason you use a read-only FS? May 02 22:58:21 It is an XFCE-based desktop with a ton of multimedia packages, so I am not surprised I guess. May 02 22:58:26 r/o has to be dealt with on a case-by-case basis. whether you support r/o fully depends on what you put in your image, and what of those things you actually need to run May 02 22:58:35 so presumably no one has gotten xfce working for it yet :) May 02 22:58:40 our devices will go into the field and should not run into issues due of modified rootfs. For updates we mount it read-write and after it we remount it again ro May 02 22:59:12 do you have any persistent state, or is everything writing to tmpfs? May 02 22:59:17 (out of curiosity) May 02 22:59:26 ro-rootfs prevents us mainly from separating the entire disk into dozen partition to avoid filesystem corruptions due of crashs May 02 23:00:14 kergoth: for some data we use in some devices SD cards. In the new one we will have two partitions: one for customer data and one to store logfiles etc May 02 23:00:25 ah, cool. makes sense May 02 23:00:43 My situation is the following. I have only a small bit of data that needs to be editable after building. My plan was to put that on a separate read-write partition and mount the root FS as read-only to hopefully prevent filesystem corruption on power failure. May 02 23:00:45 it can happen that the SD cards go corrupt or have issues when the customer has frequent power issues, but we can always easily recover because the rootfs will stay intact May 02 23:00:49 I honestly used to hate the r/o rootfs setup on the zaurus back in the day, but nowadays I like it a great deal. less risk in the field May 02 23:01:19 of course, bind mounts are much less ugly than symlinks all over the place :) May 02 23:01:43 bryan_: I would recommend you to start with a really small distro and then add one package after another. Then you see where you fail (and if it is for production you don't want to have unused software installed anyway). May 02 23:02:11 kergoth: yeah, and these days it is getting easier with the new layers. Look at docker containers, its awesome & crazy what they do May 02 23:02:23 s/new layers/new FS layes/ May 02 23:03:00 That is good advise. I was planning to start stripping out un-needed packages once we got our main software working. Perhaps it would be good to start that now. May 02 23:03:07 kergoth: at my old university we had linux diskless systems, there you want to control the RW part, too. So RO makes in a lot of cases sense. The only problem is the software support May 02 23:04:05 bryan_: if you are just starting: be aware that minimal system is really minimal. E.g. standard python modules and kernel modules (for network cards etc) are often separate pacakges that you need to manually add May 02 23:04:40 .o( maybe I should write my experiences and what I have learnt/would have liked to known earlier down ) May 02 23:04:53 I was imagining another option and would like to hear your thought on it. Is it possible to run entirely from RAM (like puppy linux), so the rootFS can be modified, but the changes do not persist between boots? May 02 23:04:56 i really need to play with ostree some as an update delivery mechanism. seems promising May 02 23:05:48 bryan_: I can't answer that. But there are union fs layers (or how they are called these days) which but a persistent file system layer over rootfs. That stores the difference between the underlaying (read only) layer and the changes you did May 02 23:05:52 bryan_: you could either copy the entire fs into ram on boot and pivot onto it, or use a unioning filesystem, of which there are multiple. or you could use the yocto r/o mechanism, which boots the r/o rootfs, but bind mounts ramdisks over parts of the fs that need to be writable May 02 23:06:04 volker-: unioning/unionfs/aufs/etc May 02 23:06:18 i dont think there's a standard one, even after all these years, projects come and go for doing it May 02 23:06:19 kergoth: yes, too much different names these days :) May 02 23:06:21 me shrugs May 02 23:06:23 * kergoth shrugs May 02 23:06:37 don't know which one is the most stable/supported one these days. May 02 23:06:59 linux-yocto carries aufs supprot May 02 23:07:28 ok, I have to leave. happy weekend :) May 02 23:07:41 Is there a reason one might choose running from RAM instead of RO filesystem? May 02 23:07:51 Ok. Thanks volker for the help :-) May 02 23:08:25 RP: nice, didnt' know that May 02 23:08:39 bryan_: oh, and just build it, run it with runqemu, test it, modify it, rebuild it, test it again :) May 02 23:09:35 Ok. Thanks :) May 02 23:12:43 RP: scratching head...klcc is broken for the 2nd built machine of the same arch. No way to retrigger do_compile as before? May 02 23:13:31 It looks like if I want a R/O root FS, I need to aggressively remove unneeded packages and hope that ones I actually need aren't causing problems. Are there disadvantages to using a R/O root FS instead of a RAM-based filesystem? It would seem to me that some things might expect to be able to modify parts of the root FS (like /sys). May 02 23:21:44 ant_home: broken how? May 02 23:21:53 ant_home: the idea is the sstate relocations should solve that May 02 23:22:05 poreferring to the previous built machine May 02 23:22:22 i.e. poodle has c7x0 in prefix May 02 23:22:35 2nd line is correct May 02 23:25:46 ant_home: do you have those lines commented out? May 02 23:25:59 uncommented May 02 23:26:24 ant_home: are all the references unconvered or just some? May 02 23:27:43 prefix, bindir, libdir, includedir May 02 23:30:59 May 02 23:31:03 ant_home: the idea was that the target mangle should take care of that :/ May 02 23:31:37 ant_home: have a look in the temp directory, see if there is an sstate installation log for populate_sysroot May 02 23:31:41 http://pastebin.com/GQSBfTMb May 02 23:31:43 ^ May 02 23:32:41 ant_home: can you share the log from temp/ ? May 02 23:33:20 sure, for poodle you mean May 02 23:33:41 ant_home: there should be a log for c7x0 too May 02 23:34:12 well. it is in armv5te- May 02 23:34:14 http://community.validation.linaro.org/scheduler/job/11600 May 02 23:34:25 test results for core image sato on LAVA May 02 23:34:30 with some random tests May 02 23:34:46 fails look like related to dpkg-query May 02 23:34:48 missing May 02 23:38:01 RP: http://pastebin.com/ENYmhvkk May 02 23:38:58 ant_home: note the sed  -i -e 's:/oe/oe-core/build/tmp-eglibc/sysroots/c7x0:FIXMESTAGINGDIRHOST:g' -e 's:\\/oe\\/oe\-core\\/build\\/tmp\-eglibc\\/sysroots\\/c7x0:FIXME_MANGLEDSTAGINGDIRTARGET:g' -e 's:\\/oe\\/oe\-core\\/build\\/ tmp\-eglibc\\/sysroots:FIXME_MANGLEDSTAGINGDIR:g' May 02 23:39:53 ant_home: I wonder if the - escape isn't correct May 02 23:40:02 should be //- ? May 02 23:40:38 counting... May 02 23:40:53 RP: Test of the codeparser fix looks good, 2nd build did nothing other than do_rootfs, 3rd build after the variable change detected it and looks to be executing do_package_write_ipk for everything. May 02 23:41:47 paulbarker: I'm finding the gcc checksums have issues after the change, am working through those May 02 23:42:38 ant_home: .replace("-", "\\-") -> .replace("-", "\\\\-") May 02 23:42:47 ant_home: try that May 02 23:46:06 conference burnout is a real issue :( May 02 23:47:34 paulbarker: thanks for the feedback though, should be able to get this in once I get some other issues sorted May 02 23:47:58 RP: seems last try works. testing twicw May 02 23:51:23 I'm calling it a night now that build is done, thanks all May 02 23:51:51 paulbarker: 'night! May 02 23:52:06 sgw_: I have refresh gcc-4.9 branch with fixes May 02 23:52:20 it bulds world for x86 now May 02 23:52:35 but my machine is slow takes 4-6 hrs for one build May 02 23:53:08 RP: seems solved, I'll verify tomorrow. Thanks May 02 23:53:11 gn May 02 23:53:19 great, 'night ant_home May 03 00:52:28 I have just install Yocto1.6 on Ubuntu 14.04 , got an error when try first build "bitbake core-image-minimal", ERROR: Task 324 (poky/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb, do_compile) failed with exit code '1' May 03 00:53:57 how can I fix this? **** ENDING LOGGING AT Sat May 03 02:59:58 2014