**** BEGIN LOGGING AT Mon Jan 09 02:59:57 2012 Jan 09 07:09:48 I want to build filesystem with Xephyr .... how can I include it in my minimal-gpe-image.bb file Jan 09 07:24:02 hi Jan 09 07:57:15 Should I use Yocto with TI AM335X? Jan 09 08:27:19 Hi guys Jan 09 08:28:25 I'm using yocto 1.0 and I need the iperf recipe...I've tried to download from git the meta-openembedded layer in which there is that recipe, but I'm not able to compile anything as I'm getting a lot of errors for missing files. Jan 09 08:28:53 What am I doing wrong? Jan 09 10:59:34 I want to build minimal-gpe-image for mini2440 with dietlibc.... will it be possible to build image with dietlibc.... Jan 09 11:47:40 hmm looks like the yocto autobuilder is down? Jan 09 11:49:53 abustany: indeed... Jan 09 11:58:22 Hello Jan 09 11:58:34 Can someone look at http://paste.debian.net/151522/ (bitbake patch) Jan 09 12:40:35 otavio: eeek, no ;-) Jan 09 12:40:51 otavio: There is code in __init__.py which does something slightly different with localpath Jan 09 12:41:14 RP__: any way for me to accomplish the same end result? Jan 09 12:41:29 RP__: I looked at __init__.py but didn't find a way for that Jan 09 12:41:47 otavio: have you tried localpath? Jan 09 12:42:02 * otavio looks Jan 09 12:43:49 RP__: seems that it will work; let me test it Jan 09 12:56:24 RP__: doesn't work Jan 09 12:56:38 RP__: it seems wget doesn't work with overriden localpath Jan 09 12:56:57 RP__: http://paste.debian.net/151527/ Jan 09 13:03:28 otavio: try prefixing that with DL_DIR Jan 09 13:09:44 RP__: fails Jan 09 13:09:45 WARNING: Fetcher failure for URL: 'ftp://ftp.mozilla.org/pub/mozilla.org/mozilla.org/firefox/releases/3.6.8/linux-i686/xpi/pt-BR.xpi'. The fetch command returned success for url ftp://ftp.mozilla.org/pub/mozilla.org/mozilla.org/firefox/releases/3.6.8/linux-i686/xpi/pt-BR.xpi but /home/otavio/hacking/ossystems/embedded-linux/downloads/firefox-l10n-pt-br-3.6.8/pt-BR.xpi Jan 09 13:10:11 RP__: the issue is simple IMO; wget is not using -O to put it on localpath Jan 09 13:13:44 RP__: this is need because the firefox localization files are not versioned but its version is on the path up to them; so I do need to mangle localfile or localpath Jan 09 13:30:50 RP__: I dropped all that and mangled DL_DIR on the recipe Jan 09 13:31:04 RP__: that fix my problem but wget is still broken anyway Jan 09 13:35:49 use curl instead! =B) Jan 09 13:36:21 B4gder: the problem is bitbake wget fetcher Jan 09 13:36:39 yeah I figured something like that, I wasn't serious anyway I'm just the main curl author Jan 09 13:37:01 otavio: Can we find a way to help localpath work? What I'd prefer to avoid is several different fetcher options which all do subtly different things Jan 09 13:37:24 RP__: yes; sure. Jan 09 13:37:27 RP__: I agre Jan 09 13:37:31 RP__: I agree Jan 09 13:56:28 RP__: however it seems wget doesn't get localpath on it Jan 09 13:56:48 RP__: and what is even worse is that bitbake.conf sets -P to DL_DIR Jan 09 13:57:01 RP__: so we do need to use -O to fix it Jan 09 14:27:26 otavio: Adding -O ${FILE} to the command in bitbake.conf might help? Jan 09 14:27:50 RP__: not sure; maybe Jan 09 14:28:01 RP__: I haven't try that but I can do Jan 09 14:28:15 otavio: also read the warnings on the wget help text about -O :/ Jan 09 14:28:28 RP__: but one problem is that there's no code to create the localpath dir Jan 09 14:36:25 otavio: hi, which runtime dependencies would you obtain for x11-common? just adding xinput-calibrator? Jan 09 15:22:03 RP__: Hi, I was wondering why some allarch recipes are doing do_package again after MACHINE switch and bitbake-diffsigs shows e.g. List of dependencies for variable TUNE_CCARGS changed from set(['ARM_THUMB_M_OPT', 'ARMPKGSFX_THUMB']) to set(['ARMPKGSFX_DSP', 'ARM_THUMB_M_OPT', 'ARMPKGSFX_THUMB']) Jan 09 15:23:02 RP__: and some other changed checksums like from gcc-cross and eglibc etc, shouln't do_package (at least for allarch) ignore them? Jan 09 15:26:28 RP__: since I've stoped using rm_work I see multimachine builds improving (not rebuilding everything), but after every machine switch I get do_package for all new stuff which takes quite long too Jan 09 16:05:29 JaMa: they shouldn't rerun do_package Jan 09 16:05:50 JaMa: sounds like those variables are creeping in and shouldn't be Jan 09 16:06:15 kergoth: any luck with that mulitprocessing issue? Jan 09 16:07:24 RP__, still trying to get the home-rolled process pool to behave. first pass seems to work, but then hangs, think I need to cancel the result queue join thread in the processes, but only for the parse error case, not for the success case. :\ Jan 09 16:07:48 RP__, https://github.com/kergoth/bitbake/compare/parsing-fix-futures does fix the problem, perhaps we should apply it and then look at removing the dep as a second step, since users are hitting this Jan 09 16:14:02 kergoth: It might be an idea... Jan 09 16:14:16 haven't given up on it, just being sucked onto higher priority tasks Jan 09 16:15:30 RP__: shoulnd't for allarch or for all recipes as long as it's same arch? Jan 09 16:36:25 JaMa: the packages should only build once Jan 09 16:56:08 We were forced to perform a hard reboot of autobuilder.yoctoproject.org. I will post status updates here. Jan 09 17:23:39 sgw: have you figured out how to solve the 'touch existing symlink' issue? Jan 09 17:27:14 ant_work: this is the /init issue? Jan 09 17:27:50 yes, in our case, nut is more general Jan 09 17:27:56 *but Jan 09 17:31:17 autobuilder.yoctoproject.org is again available. Jan 09 17:31:37 We are looking into the cause of the downtime. Jan 09 17:38:29 sgw: trying here in my /home on Gentoo: touch doesn't error out and touch -h changes the atime. I'll retry in devshell Jan 09 17:40:17 RP__, got it :) it shuts down cleanly both on parse failure and on user interrupt, the first ^C and it shuts down Jan 09 17:40:25 RP__, (the home rolled bit, not futures) Jan 09 17:41:12 kergoth: even with many BB_THREADS? sounds great Jan 09 17:41:29 now i need to sanity check with many types of parse failure Jan 09 17:54:52 kergoth: cool, the Ctrl+C thing has bugged me for a while too Jan 09 17:55:43 yeah, not responding immediately to any sort of user input is a problem Jan 09 18:12:52 gah, crap, got another hang, thought I got all of them. hmm. Jan 09 18:13:00 * kergoth peruses the code to find it via inspection Jan 09 18:14:28 damn Jan 09 18:14:29 grrr Jan 09 18:14:40 i hate threads. Jan 09 18:19:44 kergoth: threads makes me feel a kind of love and hateness ;-) Jan 09 18:20:07 i really hate deadlocks ;) Jan 09 18:27:01 more than 2 threads are incomprehendable for human brain Jan 09 18:39:13 damn, 25th parse it hung again Jan 09 18:39:14 * kergoth mutters Jan 09 18:45:17 bluelightning: you around? I am looking at both Tom's and Andrei's License code and wondering if there is some way to merge or make this a part license.bbclass as helper functions, pidge should review this also. Jan 09 18:45:50 sgw: looking now. Jan 09 18:46:00 is this the OR handling stuff? Jan 09 18:46:11 kergoth: part of it yes. Jan 09 18:46:27 because the license parsing that uses the python ast can already handle OR Jan 09 18:46:34 you pass it a callback which decides between the two Jan 09 18:46:43 SPDX and INCOMPATIBLE_LICENSE along with Tom's recent LICENSE_FLAGS vs COMMERCIAL_LICENSE Jan 09 18:46:44 and it hands you a flattened tree Jan 09 18:47:59 kergoth: it more about determine if the recipe should be skipped, but the OR stuff also comes into play from a License preference or priority. Jan 09 18:48:26 i know, but using it for that is trivial. weight the side that doesn't contain incompatible licenses, then check the flat list Jan 09 18:51:46 right, I am thinking that direction also, then it purely become a weighted priority, but we would still need to exclude any LICENSES or LICENSE_TYPES not on either list, hmm now it becomes an PREFERRED_LICENSE list of acceptable liceneses? (Designing on the fly). Jan 09 18:53:18 Problem there is PREFERRED_LICENSE would list all licenses (maybe default to SPDX + currently known OE List) and then explicity exclude unwanted LICENSES? I need to think about this more and will write an email. Jan 09 18:54:28 https://github.com/openembedded/oe-core/blob/master/meta/classes/copyleft_compliance.bbclass Jan 09 18:54:43 seen that? it's related. doesn't do the same thing, but it's similar Jan 09 18:54:55 uses include/exclude patterns to decide what sources to deploy for gpl compliance Jan 09 18:55:02 uses the license parser for it Jan 09 18:55:32 usr/share/i586-oe-linux_config_site.d/ has three files zlib_config eglibc_config ncurses_config Jan 09 18:55:44 Ok, I think I had heard of it, not really looked at it. Jan 09 18:55:48 and they can read by configure for all the recipes which use it Jan 09 18:55:57 I dont think its the right thing Jan 09 18:56:46 not saying its necessarily the best route, but it seemed strange to be splitting and manipulating the license string when we already have code to parse its contents Jan 09 18:56:48 * kergoth shrugs Jan 09 18:57:41 kergoth: agreed, that what I am thinking about where are all the places parsing happens and try to coordinate the include/exclude to a nice set of methods. Jan 09 18:58:15 * kergoth nods Jan 09 19:03:50 kergoth: is there a way we can specify some variables before calling configure e.g. ./configure blah but I want VAR=foo ./configure blah Jan 09 19:04:11 kergoth: one way is to export them but I want to have is overridable Jan 09 19:04:51 VAR=foo ./configure works fine Jan 09 19:04:57 assuming the configure script obeys that var from the env Jan 09 19:05:01 or you can pass vars on the commandline Jan 09 19:05:04 ./configure VAR=foo Jan 09 19:05:11 afaik anyway Jan 09 19:05:34 ./configure VAR=foo is not same as VAR=foo ./configure Jan 09 19:05:43 thats the problem Jan 09 19:05:56 so I cant use EXTRA_OECONF Jan 09 19:06:06 well, as i said, if the configure script obeys env vars, VAR=foo ./configure will do it Jan 09 19:08:01 right but in oe how to inject VAR=foo before ./configure Jan 09 19:08:07 is there some existing variables Jan 09 19:08:12 that I can use ? Jan 09 19:08:15 I dont think so Jan 09 19:08:45 is there some reason you don't want to just export VAR=foo in the recipe? Jan 09 19:09:33 override Jan 09 19:09:44 I want to make it possible to override it Jan 09 19:09:58 like cache it for uclibc but not for eglibc e.g. Jan 09 19:12:36 can you elaborate? saying you want to override doesn't tell me anything, vars can always be overridden Jan 09 19:12:45 you mean you have multiple configure commands to run, and want them to have different values? Jan 09 19:14:23 I have a configure var like ac_blah_blah which is determined by configure tests usually Jan 09 19:14:37 so I want to set it to yes or no Jan 09 19:14:49 so configure does not try to determine it Jan 09 19:15:10 generally it is safe to pass cached values on the configure commandline afaik.. Jan 09 19:16:31 you mean ./configure ac_var=yes ? Jan 09 19:16:34 etc. Jan 09 19:16:40 it seems not to respect that Jan 09 19:16:40 yeah Jan 09 19:16:43 I've seen that done before Jan 09 19:16:45 huh, odd Jan 09 19:17:01 ah, probably an interaction with our CONFIG_SITE.. Jan 09 19:17:04 in this case EXTRA_OECONF would just work Jan 09 19:17:11 what about export ac_foo = bar in the recipe? Jan 09 19:17:16 that does work Jan 09 19:17:31 but then overriding it might be clumsy Jan 09 19:17:36 how so? Jan 09 19:18:06 oh, then you'd have to know what all the vars are that are set, and there's no way to "unset" a variable also, though you could unexport Jan 09 19:18:18 guess your best bet is just overriding do_configure and running oe_runconf yourself Jan 09 19:18:36 yeah I want to avoid that Jan 09 19:18:45 * kergoth nods, understandable Jan 09 19:19:01 is it possible to export in a func() Jan 09 19:19:08 probably not Jan 09 19:19:10 you mean export a var just for one task? Jan 09 19:19:14 yeah Jan 09 19:19:15 that would be nice, but id on't think we have that yet Jan 09 19:19:33 you could always do something like: ${EXTRAVARS} oe_runconf ...; then you could at least set all the vars from the metadata instead of each recipe having to override the task Jan 09 19:19:41 EXTRAVARS="ac_foo=bar" Jan 09 19:19:57 hmm, not sure how that'd act if that var was empty :) Jan 09 19:19:58 yeah thats what I had in mind Jan 09 19:20:24 if var is empty it will probably rerun the test Jan 09 19:20:50 usually tests are like x$var = x Jan 09 19:20:57 inside configure scripts Jan 09 19:21:02 no, i meant if EXTRAVARS was empty, regarding the shell syntax Jan 09 19:21:10 but i guess that should be fine, don't think shells care about leading whitespace Jan 09 19:21:12 :) Jan 09 19:21:30 kergoth: EXTRAVARS empty is no problem Jan 09 19:21:50 I would add it to autotools.bbclass actually Jan 09 19:24:12 doesn't seem like an unreasonable thing to do Jan 09 19:24:30 Hm, wasn't there a recipe level site file support at some point? Jan 09 21:02:01 hm, hit the problem of the .pc files being in util-linux-dev now Jan 09 21:02:15 so re the -dev packages, from what i understand http://pastebin.mozilla.org/1441799 is enough? Jan 09 21:02:31 i can just carry this locally against the edison release for now until there's some plan Jan 09 21:06:52 that'd do it, yeah ,assuming you're intending to avoid the automatic dep of -dev packages on the -dev packages of its deps Jan 09 21:07:12 probably need to manually install some dependent packages since there's no analysis of headers going on yet Jan 09 21:43:02 Does Mark Hatle usually available on the IRC? Jan 09 21:43:22 Is Mark Hatle usually available on the IRC? Jan 09 21:46:50 khem: Hello, I am starting to test with some of your patches, but I am not building uclibc right now, what is your test build and maybe I will build out something else. Jan 09 21:47:04 autif: Mark Hatle is fray Jan 09 21:47:31 sgw - thanks! Jan 09 21:49:23 fray - I have posted several emails on the yocto mailing list, you might recall as you are the only one replied. I am fighting with libtool at the moment and would want to pick your brain sometime tomorrow - just a heads up - going home now :-) Jan 09 21:57:34 sgw: standalone oe-core Jan 09 21:57:56 khem: on all arches or just selected ones? Jan 09 21:57:59 sgw: TCLIBC=uclibc bitbake core-image-minimal Jan 09 21:58:06 I did on all arches Jan 09 21:58:16 hmm I also have this in local.conf Jan 09 21:58:32 EXTRA_IMAGE_FEATURES = "debug-tweaks nfs-server tools-sdk" Jan 09 21:58:32 EXTRA_IMAGE_FEATURES_append_pn-core-image-minimal = " ssh-server-openssh " Jan 09 21:58:57 khem: thanks, I want to run a uclibc build (I have not in a while, which is bad I know). Jan 09 21:59:02 sgw: generally core-image-sato should also work but I have not tried that yet Jan 09 21:59:28 khem: Also any update on Upstream-Status for the uclibc patches? They are the last 40 or patches that are missing status. Jan 09 21:59:38 hmm :( Jan 09 21:59:51 I will see Jan 09 22:00:03 I am planning to do an update of uclibc to latest git Jan 09 22:00:13 and that might be when I can refresh the comments Jan 09 22:00:16 khem thanks. I could throw pending in all of them, but I am not sure that's correct. Jan 09 22:00:27 Yeah Jan 09 22:00:40 khem: Ok great, just want to keep it on your list. Jan 09 22:02:46 np thanks for reminding Jan 09 22:40:20 hrm Jan 09 22:41:36 * kergoth digs into the license handling Jan 09 22:48:19 kergoth: go for it! a place many dare to tread ;-) Jan 09 22:53:29 kergoth: I'm fixing a bug with LICENSE_${PN} right now, just as an FYI, I'll be in license as well Jan 09 22:54:26 sgw: I have maybe an update wrt /init Jan 09 22:54:40 in rootfs the symlink appears broken Jan 09 22:55:01 lrwxrwxrwx 1 andrea users 18 Jan 9 23:45 init -> /usr/bin/kexecboot Jan 09 22:55:40 I say appears, because this is the absolute path and once booted is fine Jan 09 22:57:39 Hmm, this looks like on of the thinks zenlinux has been looking at where things cross the / /usr boundry Jan 09 22:57:54 http://paste.debian.net/151604/ Jan 09 22:58:09 see the bogus 'aa' Jan 09 22:59:20 fwiw the QA check for unsafe references to /usr (exec_prefix) is only done for binary files and scripts, not symlinks Jan 09 22:59:23 I see the aa, but you could be create a file that will get mounted over top of if /usr is mounted from a different disk. Jan 09 23:00:37 sure, is just to show in this case touch doesn't error out Jan 09 23:01:11 Got it. Jan 09 23:01:42 gotta reboot (thanks to vmware lockup) Jan 09 23:23:27 sgw, http://gist.github.com/1585584 - I wonder if something like this would do the job, if enhanced further for the per-package LICENSE Jan 09 23:23:53 sgw, results in PRIORITIZED_LICENSE = "LGPLv2.1" for qt4-embedded for example (LICENSE = "LGPLv2.1 | GPLv3") Jan 09 23:24:00 * kergoth thinks Jan 09 23:25:53 kergoth: but what if you explicitly want to exclude GPLv3 for example the * wildcard would bring it back int right? Would this work to replace the copyleft include/exclude code also? Jan 09 23:26:22 this just prioritizes for *us*. inclusion based on the priotized list is something else Jan 09 23:26:50 so yeah, if there's no alternative, PRIORITIZED_LICENSE could well contain gplv3, at which point the user exerts *their* control over exclusion of it Jan 09 23:28:01 so base.bbclass would take the simpler, easier to deal with, flattened list by priority and check for excluded licenses Jan 09 23:28:09 * kergoth shrugs Jan 09 23:28:16 maybe there's a better way of doing it :) Jan 09 23:28:35 Oh, I see we first get the PRIORTIZED_LICENSE, does this return the spdx mapped license? Jan 09 23:28:48 it checks both right now Jan 09 23:28:56 but returns the existing entry Jan 09 23:29:09 that is, it checks spdx to get priorities, but the PRIORITIZED_LICENSE holds non-spdx values Jan 09 23:29:14 sanitizing it as well wouldn't be a bad way to go Jan 09 23:29:21 simplify the job of base.bbclass even further Jan 09 23:29:23 It would be good to return the mapped licence, since the the check would be standard for exclusion. Jan 09 23:29:26 * kergoth nods Jan 09 23:30:49 actually the exclusion check should be a license.bbclass function that could (should be mapped) and then just returns to base.bbclass on a per recipe basis. Jan 09 23:30:54 I think we need the bits in two different pieces, because then we can use this in packaging, etc Jan 09 23:31:09 as distributors, given the choice, we choose *these things* over *those*, and mark our packages as such Jan 09 23:31:17 then the user is free to exert control after those choices Jan 09 23:31:19 Right, we need to check the packaging (finer grained) than recipe. Jan 09 23:32:51 it'd be cool to be able to exclude gplv3 packages from the feeds / images but still include non-gplv3 pieces, when we have both in a single recipe Jan 09 23:32:55 rather than doing the whole skippackage thing Jan 09 23:33:55 that would be a good next step, stuff like core-utils with lspci or gettext with tools and libraries. Jan 09 23:34:03 * kergoth nods Jan 09 23:34:28 some days i wish i didn't add skippackage support to bitbake :) Jan 09 23:35:13 * kergoth 'll take this sort of thing as a basis and try to flesh out the rest and then post a prototype Jan 09 23:40:13 kergoth: thanks for looking at this, just curious will this prototype try to address the COMMERCIAL_LICENSE / Tom's new LICENSE_FLAGS stuff also, the timing of it all! I was thinking of a way to incorporate the 2. Jan 09 23:40:26 Nothing pretty comes to mind yet :/ Jan 09 23:41:51 * kergoth hasn't even had a chance to read that thread yet, looks Jan 09 23:44:02 kergoth: we put that in place to extend the LICENSE when there might be other Terms or conditions that would not make it shippable in a commercial product even though the source code was open (various codecs) Jan 09 23:44:08 minor gripe: the caps in LICENSE_FLAGS. if its a space separated list not unlike *_FEATURES, it should behave similarly, and the convention is all lowercase Jan 09 23:46:26 given license flags are all about distribution restrictions, you'd think it'd be per-package, not per-recipe Jan 09 23:48:35 I think license flags are really rather independent from license. they're similar, but need separate variables for both the user control and the recipe content Jan 09 23:48:46 and don't need as complex parsing, just a list Jan 09 23:54:19 * kergoth wanders off Jan 09 23:54:39 * khem wanders off too Jan 09 23:55:19 kergoth: Thanks for taking a look and your comments. Jan 10 00:13:02 kergoth: that's my worry about this. it really should allow package and recipe level distribution restrictions IMHO. **** ENDING LOGGING AT Tue Jan 10 02:59:58 2012