**** BEGIN LOGGING AT Thu May 01 02:59:59 2014 May 01 05:36:41 sgw_: I have pushed a reverted patch from gcc 4.9 which should fix the ppc ICE issue. Please take the kraj/gcc-4.9 branch and try on the ppc target where you saw the crash and let me know how it goes May 01 06:53:16 RP: I am seeing multiple providers are available for virtual/x86_64-angstromsdk-linux-binutils-crosssdk (binutils-cross-x86_64, binutils-crosssdk-x86_64) May 01 06:53:28 after this cross renaming stuff May 01 06:54:36 ideas ? May 01 08:19:45 khem: I suspect there are some PREFERRED_PROVIDERS that need tweaking May 01 08:43:28 morning all May 01 11:18:13 Hi, is there any extensive docu on how the URL replacement algorithm works in MIRROR="" variables? I would like to do something like MIRROR="someprotocol://server.com/path;param1=x;param2=y file://${param1}/${param2}" is that even possible? May 01 11:19:04 The code of that replacement function is rather difficult :-) May 01 11:19:30 Denwid: I think it's just a regex replacement, so you should be able to set up groups in the first expression and then have them output in the replacement using \1 \2 etc. May 01 11:19:49 That sounds interesting May 01 11:20:01 (you could alternatively use named groups I guess) May 01 11:20:01 I will look at the code again and try something like that May 01 11:37:45 khem: I pushed a patch which at least partially addresses that issue May 01 11:41:17 bluelightning: I think we need to do something like http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=7cb0ed6d46be9225f46161eaa915e7356807fd5f but that triggers a ton of warnings :( May 01 11:42:01 RP: hey May 01 11:42:29 RP: I'm trying to understand the rework of cross-recipes... May 01 11:42:48 afais for multibuilds these are overwritten... May 01 11:43:55 ant_home: right now, yes but there are a third set of patches which will make them equivalent May 01 11:43:57 in sysroot both armv4 and armv5te do share /arm-oe-linux-gnueabi May 01 11:44:20 ant_home: that is intentional, there is no difference between an armv4 compiler and an armv5 compiler May 01 11:44:35 I'm testing by adding PN = "gcc-cross-${TARGET_ARCH}" May 01 11:44:42 to klcc-cross May 01 11:44:59 well, you got it May 01 11:52:35 RP: hm, libgcc is still in machine sysroot. May 01 12:03:34 ant_home: as it should be? May 01 12:05:31 bluelightning: evil? http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=278c0e87d8e8ce3d18365f4cba250a6531bcc054 May 01 12:13:26 RP: I still look for a better way to point to the klibc headers May 01 12:21:52 ant_home: Is there a summary of the problem somewhere I can refresh my memory with? May 01 12:22:35 klibc builds against linux-libc headers and syages ARCH headers (once in the multimachine sysroot, now in machine sysroot) May 01 12:22:43 s/syages/stages/ May 01 12:23:04 so I have one copy each machine, even if it's same arch May 01 12:23:13 ok, it's like libgcc May 01 12:23:35 my second problem is that klcc includes these machine-specific paths May 01 12:23:56 so until now I solved rebuilding it for each machine and overwriting May 01 12:24:00 ant_home: well, the staging once per machine in the sysroot isn't a solvable problem May 01 12:24:20 ant_home: but sstate should make that fast May 01 12:24:23 now do_compile[vardeps] += "MACHINE" don't work anymore May 01 12:24:25 the second one is the bigger issue May 01 12:24:55 yes, I think I have to use another var May 01 12:25:00 I've already added May 01 12:25:02 PN = "klcc-cross-${TARGET_ARCH}" May 01 12:25:24 ant_home: this code is in meta-oe, right? May 01 12:25:40 yes, meta-initramfs May 01 12:27:03 RP: http://pastebin.com/AEbb1uMU May 01 12:29:25 ant_home: so klcc-cross is basically a perl wrapper around other tools May 01 12:29:31 right May 01 12:29:41 the only issue is hardcoded path May 01 12:30:16 I can live with it rebuilding for each MACHINE even if it is not machine-specific May 01 12:30:24 ant_home: and our usual relocation logic doesn't work due to the escaping May 01 12:30:35 darn May 01 12:31:10 a wild guess with no results: do_compile[vardeps] += "ARCH" May 01 12:34:22 I don't understand why MACHINE doesn't work anymore... May 01 12:38:20 ant_home: its due to changes in cross.bbclass, its now BUILD_ARCH specific, not TARGET_ARCH May 01 12:38:36 ant_home: I assume klcc currently has sstate relocation issues too? May 01 12:40:07 yes, that's why we rebuild it for each machine May 01 12:40:19 and try to invalidate the sstate... May 01 12:41:25 ant_home: no, I mean if you build for MACHINE=X and then switch to a different build directory with a shared sstate cache, it will then install a klcc with the wroing paths in it? May 01 12:42:02 I suppose but never tried May 01 12:42:16 I just build for i.e collie then c7x0 and spitz May 01 12:42:45 so I was having 2 klcc, one for armv4 and one for armv5 May 01 12:44:07 ant_home: give me a few minutes with this, I'll see if I can come up with some fixes May 01 12:45:29 anyway even two builds of machines of the same arch (two armv5te) have the same problem, hardcoded machine in klcc's prefix May 01 12:46:09 thanks for any help ;) May 01 13:27:33 ant_home: http://pastebin.com/8MGYaHUi is what I'd do to it May 01 13:28:31 ant_home: I'm hoping I added enough mangling but if not, you can see how to add more May 01 13:41:37 RP: wow, thx May 01 13:41:40 testing it May 01 13:42:19 ah, yes, I removed the packaging tasks after your changes to cross.bbclass..I see you readded deltask here May 01 14:23:15 RP: hmm. mangling is the least problem with the patch... klcc-cross is not staged in sysroot and the packaging tasks are present May 01 14:29:18 almost fixed May 01 14:29:40 somehow WARNING: Function klcc_sysroot_preprocess doesn't exist May 01 14:32:26 ant_home: Are you looking in the right place in the sysroot? May 01 14:32:40 now I have it one for eac machine May 01 14:32:44 ant_home: its now in the target sysroot in usr/bin/crossscripts May 01 14:32:44 is ok May 01 14:32:49 yep May 01 14:33:27 each has the correct paths, like in the bogus 2nd line May 01 14:33:48 ant_home: step in the right direction then :) May 01 14:34:03 now, about the naming..is it a real -cross? May 01 14:34:10 ant_home: I'd say so May 01 14:34:27 before for sure May 01 14:35:36 ant_home: a similar example is libtool-cross which is named as such even though it also doesn't use cross.bbclass May 01 14:35:57 so no need to add +PN = "klcc-cross-${TARGET_ARCH}" May 01 14:36:14 ant_home: no May 01 14:36:30 ok, many thanks May 01 14:37:24 ant_home: cross.bbclass is really "autotools/gnu-cross" i.e. for the special case of cross GNU utils May 01 14:37:40 one last Q: can I remove now do_compile[vardeps] += "MACHINE" May 01 14:37:47 I doubt it will ever make much sense for things that aren't gcc/binutils/gdb May 01 14:37:51 ant_home: yes May 01 14:38:01 fine May 01 14:38:51 actually it is a crosscript May 01 14:39:00 stay at your place, klcc ! May 01 14:39:09 ;) May 01 14:44:32 ant_home: it did seem quite appropriate :) May 01 15:00:43 RP: I've added your Signed Off by May 01 15:01:08 now writing a decent comment... May 01 15:01:11 ant_home: ok May 01 15:01:30 bluelightning: good news, patch coming ^ May 01 16:44:02 bluelightning, May I run "layerindex/update.py -b daisy -x -q" or will that break something? May 01 16:44:37 halstead: that should work... in fact I was about to add that to our script May 01 16:44:45 I've created the daisy branch already May 01 16:45:08 (as you may be able to tell from the UI) May 01 16:46:20 bluelightning, Shall I let you? I'm ready to add it as well. May 01 16:47:02 halstead: if you're logged in, please go ahead :) May 01 16:47:10 bluelightning, Will do. Thanks! May 01 16:47:24 I'm seeing those errors now btw, I'll try to address them May 01 16:47:47 halstead: no, thank you :) May 01 16:52:06 bluelightning, Lots of OOM failures. I'm going to add more memory and reboot then run again. May 01 17:17:54 bluelightning, OOM is no longer a problem but I'm running into new errors. Do you have a moment to look at them with me? (Several conf/layer.conf not found for layer...) May 01 17:18:44 halstead: you mean meta-chiefriver etc? I know about those, it's basically a matter of cleaning up the database entries one by one; I'll take care of it May 01 17:19:17 bluelightning, meta-mentor, meta-bytesatwork, meta-nuc a few others. May 01 17:19:28 yes May 01 17:20:06 some have changed their structure and the maintainer hasn't updated the entry (meta-mentor); meta-bytesatwork is completely empty (not sure why they even submitted it to be honest, but hey) May 01 17:20:23 bluelightning, If you want to teach me how to clean the database I'll help out in the future. May 01 17:20:57 well each one has to be handled on a case-by-case basis; the question in each case is why isn't the file there anymore May 01 17:23:03 bluelightning, So it requires a bit more context knowledge than I'm likely to have. May 01 17:23:17 in some cases yes May 01 17:26:27 I'll try to fix them up later tonight May 01 17:26:32 bbl May 01 17:31:46 ptest also runs into issues with ro-rootfs May 01 17:32:20 not too surprising May 01 17:32:38 volker- that should likely be fixed.. I'd have expected ptests to use /tmp or similar for anything RW.. but I suspect many do not and just assume they can write to their current directory May 01 17:33:04 that would be nice May 01 17:33:08 fray: yeah, that what it seems to. but even busybox seems to run into problems there May 01 17:33:25 did anyone ever link /etc/hosts to the rw-able area? May 01 17:33:30 (like /etc/resolv.conf) May 01 17:33:59 why? normally /etc/hosts doesn't need to contain anything but the localhost ipv4/ipv6 link May 01 17:34:09 I have to say, I'm not happy with how the r/o binds are handled. Some folks seem to feel strongly that it should be done in each init package, but I think it should be independent, and behave the same for sysvinit and systemd May 01 17:34:27 yeah, there's always nss-myhostname for your local hostname resolution May 01 17:34:36 much bette rthan manually adding it to hosts like the old days :) May 01 17:34:40 kergoth I agree.. I like the populate-volatiles approach.. one stop shop... May 01 17:34:57 ptests here fail because /bin/bash is not found and python LIBDIR is wrong and sed is not the sed they expect (but from busybox) May 01 17:35:02 kergoth, ya nss approaches are much better if dynamic hosts are needed.. May 01 17:35:24 missing /bin/bash is an RDEPENDS or related issue.. May 01 17:35:39 LIBDIR, I'm curious about for the python.. is it a generic python problem, or just for a specific ptest? May 01 17:35:57 as for sed -- I don't know if there is anythign we can directly do about that other then try to require the full version of sed.. May 01 17:36:02 I need more build power just to test all the default builds with ptest and submit bugs ;-) May 01 17:36:13 I know the ptests I used, I usually run on 'bigger' systems, ones w/o busybox May 01 17:36:53 at least a "you asked for ptests but don't have package A, B, C, that is not supported!" message May 01 17:37:19 if it needs real tools, it should rdep on the real tools :) May 01 17:37:22 yes... RDEPENDS need to be fixed, and if a ptet won't work for some configuration reason it should be noted.. May 01 17:37:53 doesn't intel provide a buildfarm for yocto with tests? May 01 17:38:06 how about running ptest-runner there? May 01 17:39:14 the ptest-runner also does not provide some config flags to cherry pick builds May 01 17:51:16 Yocto powered. http://linuxgizmos.com/linux-based-k-9-doppelganger-treads-elc/ May 01 17:52:36 nice. May 01 17:52:44 :-) May 01 17:55:52 curses k-9! May 01 17:57:43 is k9 only the mailclient name or also the name of the dog in dr who? May 01 17:58:09 volker-: name of the dog in dr. who. where the client got it's name May 01 17:59:26 * LetoThe2nd totally favored the yoctenburg over k-9 in edinburgh May 01 18:20:35 okay, let me get this straight. If I have a patch for yocto, and all the changed files are in poky/meta/, that means I should clone the openembedded-core Git repository (as apposed to the Poky git repository I've been working from,) and apply my patch there? I don't see any openembedded-core-contrib repo I should be using... May 01 18:20:51 or is poky-contrib fine? May 01 18:21:18 maxtothemax, that is a fun question May 01 18:22:38 is it possible to use something like WORKDIR or ROOT_HOME in files that get copied via SRC_URI? I thought I saw something like it in the past but can't find it anymore in the doc May 01 18:23:03 can you calrify your question? May 01 18:23:16 maxtothemax: yes, and there is an openembedded-core-contrib on the oe git server May 01 18:24:31 kergoth: files that are defined in SRC_URI are getting copied to the workdir folder. Now Yocto uses variables that can be changed like ROOT_HOME (as defined in meta/conf/bitbake.conf). May 01 18:24:52 kergoth: now my question is, how can I use these variables to be automatic expanded after they are copied May 01 18:25:30 so my tests run against the correct root folder without hardcoding it. May 01 18:26:49 you can do it however you want May 01 18:27:00 most common the task in the recipe would use sed to adjust the paths in the files from SRC_URI May 01 18:27:16 kergoth: ok, so no automatic expansion option there May 01 18:28:10 I don't understand what you're talking about May 01 18:28:19 bitbake expands any variables in the recipe automatically May 01 18:28:26 but it's not going to run off and randomly modify your sources May 01 18:28:44 that wouldn't be safe, and would cause more problems than it solves May 01 18:28:52 if you May 01 18:29:06 re looking for some sort of templating mechanism, there's no standard mechanism of that sort, and the input would have to be modified to mkae use of it anyway May 01 18:29:24 kergoth: ok. some workframes (like puppet or chef) have something called "templates" that expand certain hilighted variables. May 01 18:30:18 I doubt people would be opposed to adding something like that, but it would obviously have to be opt-in, and the file format documented, etc. but nothing like that exists today May 01 18:38:34 which part gets executed directly after SRC_URI? May 01 18:38:52 SRC_URI is a variable, not a task May 01 18:38:57 that question doesn't make sense :) May 01 18:39:17 kergoth: s/after SRC_URI/after files defined in SRC_URI are copied/ May 01 18:39:56 do_fetch downloads the files in SRC_URI, do_unpack extracts them to WORKDIR, do_patch patches them, do_configure configures (e.g. autotools) and do_compile compiles your sources May 01 18:40:03 where your sed belongs really depends May 01 18:40:25 I would say directly after the do_fetch May 01 18:41:14 is there a way to "inject" commands without entirely overwriting/creating a new do_patch()? May 01 18:41:32 I showed you one way to do that yesterday, with the postfunc May 01 18:41:57 you can _append/_prepend a task, but that assumes what you're appending/prepending is the same langauge as the task you're altering, and do_patch is written in python May 01 18:42:05 you can add a prefunc/postfunc, in whatever you like May 01 18:42:12 or you could add a new task, between do_patch and another task May 01 18:42:21 i'd recommend the prefunc/postfunc approach in this case, but any could get hte job done May 01 18:43:04 kergoth: true, I forgot that postfuncs part again. :-/ May 01 18:50:27 RP: add a RecipePreFinalise event handler in one recipe, wipe your cache and reparse, and watch it run against other recipes, not just that one. May 01 18:50:41 RP: haven't investigated further, but was cause for concern May 01 18:50:46 * kergoth 'll nail it down and open a bug if necessary May 01 18:52:01 i'm guessing the event handlers aren't isolated to the recipe being parsed in the parallel up front parsing May 01 18:52:07 will dig further May 01 18:52:12 but seems likely May 01 19:26:27 RP: last fix after removing "inherit cross" is target_libdir -> libdir May 01 20:36:59 kergoth: that does not sound good. I thought we'd killed the global method scope :/ May 01 20:37:25 I thought so too. I'm guessing methods were, but not events/handlers May 01 20:37:34 kergoth: hmm, right May 01 20:37:36 https://gist.github.com/kergoth/11460892 May 01 20:38:20 not a priority, most folks dont' use event handlers, but i could definitely see needing RecipePreFinalise from time to time May 01 20:38:27 kergoth: I think I have had to work around this before now you mention it. Things like the virtclass-cross handler running in places it clearly shouldn't May 01 20:38:41 oh, yeah, i bet that explains a lot actually.. May 01 20:38:44 heh May 01 20:39:03 At the time I just changed it to check PN as it was too deep a hole to disappear down May 01 20:39:20 * kergoth nods May 01 20:40:16 I'm guessing we need to save/restore the handlers before/after each parse, in the parse function. that way we don't lose the global handlers, just undo any modifications May 01 21:17:30 I have the following in a recipe: RDEPENDS_${PN}-ptest = "cv-misc-tests-ptest" May 01 21:17:53 NOw I would assume that if the -ptest file is installed, that it would automatically install the -ptest file from the cv-misc-tests recipe May 01 21:18:32 the cv-misc-tests recipe itself is an empty recipe that does not create a cv-misc-tests package but does a cv-misc-tests-ptests one (because it only defines ptests) May 01 21:21:20 hmmm http://layers.openembedded.org/layerindex/recipe/5542/ shows git 1.8.4.4 but actual recipe is 1.9.0 how is it out of sync ? May 01 21:30:11 Hi all May 01 21:30:43 Do you have any suggestions for how to create a single file package without a "proper" source url? May 01 21:31:08 What I want is to install a single ttf font from the google font set May 01 21:33:06 I have already tried to simply put the font file in the package files dir, but then poky complains that LIC_FILES_CHKSUM is incorrect. I see no way to actually set it correctly in this case... May 01 21:33:33 simonl: http://pastebin.com/T7AXQBfu May 01 21:34:22 volker-: whats your question about cv-misc-tests May 01 21:34:24 simonl: create a recipe-test/mytest/mytest.bb and recipe-test/mytest/files/MYFILE May 01 21:35:02 simonl: best is to create a recipe for full package and then create multiple packages may per font May 01 21:35:21 volker-: Awesome, looks like exactly what I need May 01 21:35:23 and you can then include 1 package that contains the font you care for in your image_install May 01 21:35:50 that way it will be good to even send upstream May 01 21:36:01 khem: the hg repo is 3.8 GB. Big enough to actually fail during fetch... May 01 21:36:05 simonl: and as khem suggests, you can download the entire package from google, extract it and pack _each_ font into a separate package (like kernel modules f.e.) May 01 21:36:14 ugh May 01 21:36:26 It's source+binaries May 01 21:36:29 3.8G is huge May 01 21:36:49 handy sometimes I guess, but not really the source control way ^^ May 01 21:37:09 is 3.8G a git repo or tarball May 01 21:37:12 simonl: my pastebin has an error, you have to tell wher eto install, ${D}/${bindir}/MYFILENAME May 01 21:37:23 khem: mercurial May 01 21:37:57 well look for release tarballs May 01 21:38:00 so yeah, some history, but unfortunately the tarball service seemed to be broken too, so :/ May 01 21:38:08 instead of cloning full repo May 01 21:38:23 khem: I put some patches our, I hope they address the providers issue May 01 21:38:44 RP: the issue was due to meta-linaro May 01 21:38:52 it was too late in the night May 01 21:39:02 I figured it in mornin May 01 21:39:13 you set PN in binutils cross sdk recipe May 01 21:39:25 meta-linaro got the changes you did to .inc files May 01 21:39:29 but not to .bb May 01 21:39:32 :) May 01 21:39:45 RP: btw. keep an eye on my contrib tree May 01 21:39:49 its growing May 01 21:39:57 :) May 01 21:40:04 http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl May 01 21:43:58 volker-: Thanks, ${COMMON_LICENSE_DIR} was the hint I needed =) May 01 21:44:37 :) May 01 21:44:42 khem: so I see May 01 21:52:09 RP: last commit message doesn't match with version in the patch, but no big deal May 01 21:52:21 JaMa: gah, sorry :/ May 01 21:52:37 * RP is not back to multitasking properly **** ENDING LOGGING AT Fri May 02 02:59:58 2014