**** BEGIN LOGGING AT Wed Jul 24 02:59:59 2013 **** BEGIN LOGGING AT Wed Jul 24 05:27:42 2013 Jul 24 07:07:39 good morning Jul 24 07:29:29 is there anyone who can help me with external toolchains? I still did not move forward a bit. Jul 24 08:08:56 morning all Jul 24 08:09:15 why cannot I interrupt the bitbake process with ctrl-c? :O Jul 24 08:12:21 bluelightning: http://paste.kde.org/~lpapp/p7d4e8a59/ Jul 24 08:13:19 also, it made my system super laggy that I pressed ctrl-z. Jul 24 08:29:16 kill solves it Jul 24 08:30:24 ctrl-c should just work of course. Jul 24 08:30:42 I consider it a serious bug. Jul 24 08:31:43 so I am more interested in fixing the bug. Jul 24 08:31:58 rather than working around, and have it non-working for the next user. Jul 24 10:08:07 o/ morning all Jul 24 10:09:46 yo Jul 24 10:13:27 anyone got a clue for this bitbake issue? http://paste.kde.org/p6570e219/ Jul 24 10:13:50 lpapp: fwiw, first control-c requests a graceful shutdown when the current tasks have finished, second should abort the current tasks. you'll often find you've then got a pile of data to still get to disk, so it may appear to hang for a bit. Jul 24 10:14:15 lpapp: did you compare the files? Jul 24 10:15:04 rburton: I waited 20 minutes. Jul 24 10:15:09 rburton: yes Jul 24 10:16:28 lpapp: so, did you resolve any differences and set the version in your conf/bblayers.conf to match the sample? Jul 24 10:17:25 rburton: ? Jul 24 10:17:31 there are no differences other than expected. Jul 24 10:18:14 lpapp: and the versions match? Jul 24 10:18:24 rburton: http://imagebin.org/265472 Jul 24 10:20:13 lpapp: do a find for other bblayers.conf.sample files Jul 24 10:20:18 maybe your layer has one in? Jul 24 10:20:57 rburton: ? Jul 24 10:21:26 iirc VERSION is 5 in dylan. Jul 24 10:21:45 ndec: ? Jul 24 10:22:04 lpapp: search for other files in your tree called bblayers.conf.sample, as bitbake it clearly not looking at the file you're comparing. Jul 24 10:22:40 lpapp: my suspicion is that your layer has a bblayers.conf.sample too Jul 24 10:22:58 ndec: surely, it is not? Jul 24 10:23:00 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/bblayers.conf.sample?h=dylan Jul 24 10:23:30 rburton: unfortunately, nope. Jul 24 10:23:40 find ./ -name bblayers.conf.sample Jul 24 10:23:40 ./meta-yocto/conf/bblayers.conf.sample Jul 24 10:23:44 this is the only result. Jul 24 10:23:51 how odd. Jul 24 10:24:00 it is ! Jul 24 10:24:06 what happens if you wipe away your bblayers and re-run oe-init-build-env? Jul 24 10:24:33 it is with wiping away Jul 24 10:24:35 but I can do it again. Jul 24 10:27:23 rburton: http://paste.kde.org/p19df8b0f/ Jul 24 10:27:41 hm Jul 24 10:28:13 i bet your distro is setting LAYER_CONF_VERSION itself Jul 24 10:28:53 that means what? Jul 24 10:29:07 thats the number that the layer version is compared against Jul 24 10:29:18 if your distro is forcing it to something that it shouldn't be, you'll get this Jul 24 10:29:26 does your layer define a distro? Jul 24 10:29:57 yes Jul 24 10:30:04 since it is a semi-distro layer Jul 24 10:30:15 weird thing is that, I do not get such issues with denzil though. Jul 24 10:30:18 of course Jul 24 10:30:21 because the version is older then Jul 24 10:30:58 ? Jul 24 10:31:07 ../meta-foo/conf/ff-local.conf:102:DISTRO ?= "poky" Jul 24 10:31:14 ../meta-foo/conf/foo-local.conf:102:DISTRO ?= "poky"* Jul 24 10:31:18 s/poky/foo/ maybe? Jul 24 10:31:25 as I have this: Jul 24 10:31:33 ../meta-foo/conf/distro/foo.conf Jul 24 10:31:40 in any case, the error message is not so intuitive Jul 24 10:31:44 it would be nice to improve it. Jul 24 10:32:25 what distro does your local.conf specify? Jul 24 10:32:53 foo-tiny Jul 24 10:33:23 its best not to change the value of DISTRO in several places Jul 24 10:33:37 and have a look in your distro conf files, as i said i expect it's setting LAYER_CONF_VERSION Jul 24 10:34:02 as I said, it is not setting. Jul 24 10:34:28 "grep -rn LAYER_CONF_VERSION meta-foo" yields nothing. Jul 24 10:34:36 change the distro in several places mean what? Jul 24 10:34:36 right, you didn't say that. Jul 24 10:34:41 I did. ;-) Jul 24 10:34:46 you're setting DISTRO in multiple places Jul 24 10:34:47 I only replicate poky. Jul 24 10:34:48 I have a foo Jul 24 10:34:53 and foo-tiny Jul 24 10:34:53 just set it in your local.conf Jul 24 10:34:54 similarly to poky. Jul 24 10:35:39 interesting, I have not written the LAYER_CONF_VERSION Jul 24 10:35:42 then I just intended. :) Jul 24 10:35:48 as I checked right after you wrote. Jul 24 10:35:58 set LCONF_VERSION in your bblayers.conf to 5 Jul 24 10:36:12 bet that makes it work Jul 24 10:36:29 so, probably I should not have foo-local.conf in meta-foo/conf Jul 24 10:36:35 as meta-yocto does not seem to have that either. Jul 24 10:36:47 5? Jul 24 10:36:53 yeah, drop it one Jul 24 10:36:53 but ... but, it is 6. Jul 24 10:36:56 why ? Jul 24 10:37:01 yes, so change it to 5 Jul 24 10:37:09 * lpapp is lost Jul 24 10:37:11 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/bblayers.conf.sample?h=dylan Jul 24 10:37:16 that is meta-yocto from dylan Jul 24 10:37:18 it is 6 in there. Jul 24 10:37:22 lets start with "its moaning when the value is 6, so lets change it to 5" Jul 24 10:37:28 why ? Jul 24 10:37:29 but importantly, you're distro isn't poky Jul 24 10:37:37 so don't copy poky files. Jul 24 10:37:47 well, it is almost poky Jul 24 10:37:53 and I still do not understand why 6 should not work. Jul 24 10:38:02 6 is the layer conf version set by poky Jul 24 10:38:11 in any case, I will drop meta-foo/conf/foo-local.conf then Jul 24 10:38:13 if you're not running poky, you'll get the default of 5 Jul 24 10:38:14 we probably do not need it. Jul 24 10:38:24 (that bump was a poky-specific change) Jul 24 10:38:45 ok, nice trap then. Jul 24 10:38:49 you can drop meta-yocto entirely if you're not using poky, as it's actively causing harm Jul 24 10:39:18 no no Jul 24 10:39:25 it is better to keep it as upstream has. Jul 24 10:39:31 I mean it is easier to update stuff Jul 24 10:39:49 I will try again: can I drop meta-foo/conf/foo-local.conf or it has any significance? Jul 24 10:40:14 apparently, me predecessor put it there. Jul 24 10:40:20 but I would not know why it is neede. Jul 24 10:40:21 d Jul 24 10:40:22 no idea, never seen that filename style before. Jul 24 10:40:34 err... it is not about the file name. Jul 24 10:40:46 it is about the concept having a local.conf inside the mylayer/conf Jul 24 10:40:54 rather than build/conf/local.conf Jul 24 10:40:57 well, you said foo-local.conf Jul 24 10:41:06 a local.conf inside a layer would be wrong Jul 24 10:41:18 it is probably a local.conf with custom stuff. Jul 24 10:41:33 and what about site-foo.conf inside the layer? Jul 24 10:41:41 should that also be gone? Jul 24 10:42:21 i guess inside the layer is somewhere to put it Jul 24 10:42:26 put a site.conf wherever you want Jul 24 10:42:43 so the bblayers.conf is generated with 6 because it generates meta-yocto by default? Jul 24 10:43:06 no, because it found a bblayers.conf.sample in meta-yocto Jul 24 10:43:16 and assumed that that's the one you wanted Jul 24 10:43:19 yeah, so renaming to site.conf makes sense Jul 24 10:43:25 especially since it is literally the sample. Jul 24 10:43:38 rburton: how can I override that? Jul 24 10:43:42 if you're not using poky you can wipe those layers entirely Jul 24 10:43:44 or how can I make 6 work? Jul 24 10:43:46 or just keep the bsp layer Jul 24 10:43:52 you make the 6 work by using poky Jul 24 10:44:15 ok, it will be weird to check the build folder in. Jul 24 10:44:20 yes, very weird Jul 24 10:44:22 don't do that Jul 24 10:44:24 ? Jul 24 10:44:34 that is the only solution for upgradability? Jul 24 10:44:36 just remove meta-yocto* from your setup, you don't need it Jul 24 10:44:45 I mean, clearly, it should be fixed once, and then shared. Jul 24 10:44:47 as you've said, your distro isn't poky. Jul 24 10:44:53 which means, build/conf/local.conf ends up in the repository Jul 24 10:45:12 ah, sorry. Jul 24 10:45:15 that is not bblayers.conf Jul 24 10:45:17 well well .... Jul 24 10:45:20 it is kinda sucky then. Jul 24 10:45:38 well removing poky is also suboptimal. Jul 24 10:45:41 lpapp: why don't you customize starting from the core? Jul 24 10:45:46 because then it will be more work to upgrade upstream poky. Jul 24 10:45:56 oh, and btw Jul 24 10:45:59 we do need poky. Jul 24 10:46:00 I'm working with distro-less defaults and all seems ok Jul 24 10:46:07 hi otavio Jul 24 10:46:09 we only have hardware adaptation in our layer, mostly. Jul 24 10:46:20 rburton: we do not wanna reinvent the wheel. Jul 24 10:46:26 lpapp: but your setting the distro to something else, so what do you need "poky" for? Jul 24 10:46:29 lpapp: it is easy if you start adding to http://www.openembedded.org/wiki/OE-Core_Standalone_Setup Jul 24 10:46:34 rburton: for the whole stuff Jul 24 10:46:41 rburton: every package pretty much should come from poky. Jul 24 10:46:49 replicating the poky layer in my layer would not make much sense. Jul 24 10:47:00 rburton: so my distro is poky + minor custom stuff Jul 24 10:47:11 poky or oe-core? Jul 24 10:47:13 lpapp: are you actually aware of what recipes poky adds over oe-core? Jul 24 10:47:47 1) a changed splashscreen 2) a tiny configuration for busybox. Jul 24 10:49:02 lpapp: if you want to "inherit" poky, then your distro.conf should require conf/distro/poky.conf Jul 24 10:49:11 so you get poky and then can change it Jul 24 10:49:21 that will also solve your conflicting version problem Jul 24 10:49:42 (that's what guacamayo does, inherits poky and changes a few values) Jul 24 10:50:31 I'm building a Perl package. It seems to rely on a bunch of CPAN modules that are not in a standard distribution. But now I'm not so sure. How can I figure out what Perl modules are already available via some package? Jul 24 10:50:59 I see packages that DEPEND on some perl-module-.*. What provides these modules? Jul 24 10:56:13 rburton: and busybox Jul 24 10:56:43 lpapp: yes, a tiny configuration for busybox Jul 24 10:57:06 rburton: we have our own custom kernel Jul 24 10:57:15 our own busybox Jul 24 10:57:20 our own splash screen Jul 24 10:57:29 perhaps then poky is not much of value for us Jul 24 10:57:39 indeed Jul 24 10:58:08 depends how much you want to change. poky is a good starting point, or you can start from scratch. Jul 24 10:58:15 rburton: I guess poky would make more sense if we could upstraem our changes. Jul 24 10:58:20 kernel, busybox, etc Jul 24 10:58:36 the problem you've got is that you've pulled in the layers but are not using it, so you get samples files that don't work with your setup. Jul 24 10:58:54 I think the end goal should be poky. Jul 24 10:59:02 but since we have custom patches for pretty much everything in poky. Jul 24 10:59:16 well, having your own distro is fine, it lets you make changes specfic to your distro. Jul 24 10:59:37 just either inherit poky, or remove the meta-yocto layers Jul 24 10:59:40 i think the main problem here is that poky comes with its own 'init' script that does : TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}. so you end up using the templates from meta-yocto. Jul 24 11:00:15 so if you don't use poky, but download 'poky' (as opposed to oe-core), you probably want to tweak that. Jul 24 11:00:48 but, if you have your own distro , you might want to provide your own template conf files directly. that's what i do. Jul 24 11:02:12 remembering that distro/defaultsetup.conf is providing valid defaults Jul 24 11:02:36 poky does do more qa, iirc Jul 24 11:05:01 Ummm, can I be a squeaky wheel and get a little grease? Jul 24 11:05:13 rburton: it does more QA because it sets QA in the distro vars, right? but if we reproduce the same config in another distro, we should get same QA, right? Jul 24 11:05:34 it's just matter of changing local.conf Jul 24 11:05:43 ok. Jul 24 11:06:08 Also, if I do have to fetch, build, and install a lot of tiny Perl modules is there some standard way to do that in one recipe, instead of a whole bunch of separate recipes? Jul 24 11:06:14 ndec: its just distro vars, yeah. set them wherever you want. Jul 24 11:06:21 so the Distro abstraction is useful because is stable and commercially affordable Jul 24 11:06:36 but is not necessary Jul 24 11:07:04 mulhern: not really. there was someone who'd packaged up about 80 modules from cpan though... Jul 24 11:07:25 mulhern: assuming your modules come from cpan, metadata boilerplate + inherit cpan should be close to all you need Jul 24 11:08:02 bluelightning: can you remember who was packaging vast amounts of perl? Jul 24 11:08:29 Oh, yeah, I can set up little recipes and everything happens automatically. But what if all those little recipes are redundant? And they sure do clutter everything up. Jul 24 11:08:45 rburton: that was Stygia Jul 24 11:08:59 and erbo Jul 24 11:09:10 ant_work: ah ok, didn't know he was also doing that Jul 24 11:09:23 hope they are talking to eachother :) Jul 24 11:09:28 heh Jul 24 11:09:43 package deathmatch! Jul 24 11:12:51 When a package DEPENDS on a perl-module-.* that must come from somewhere but I can't even figure out what provides these modules. It's unusually mysterious. Jul 24 11:13:22 mulhern: got one specifically? Jul 24 11:13:39 hm maybe perl magically provides those for the modules it contains Jul 24 11:16:06 rburton: so poky or not? Jul 24 11:16:34 lpapp: personally i like inheriting poky, but it depends on how much you want to change the distro variables. Jul 24 11:17:29 I see a recipes with RDEPENDS containing a whole list: perl perl-module-text-wrap perl-module-getopt-long …. Jul 24 11:17:52 mulhern: right, a lot of those are the subpackages that perl splits into Jul 24 11:19:37 OK, now I see that in perl-rprovides.inc. Jul 24 11:21:27 mulhern: for reducing installed size, perl (and python) split their library modules into as many packages as possible Jul 24 11:21:34 so you can just install what is needed Jul 24 11:21:54 the downside of this is that there are ~fifteen quadzillion packages for each Jul 24 11:22:03 rburton: That's perfectly sensible. Jul 24 11:23:36 But, the interesting thing is that for instance with perl-module-text-wrap that I mentioned is that perl depends on it, it doesn't provide it. Jul 24 11:24:58 ah Jul 24 11:25:05 i suspect the names are generated automatically Jul 24 11:25:17 and that rprovides.inc is only for manually additions Jul 24 11:25:23 rburton: what distro variables? Jul 24 11:26:24 mulhern: yes, perl_5.14.3.bb has a populate_packages_prepend() that does do_split_packages(). that chops each module directory into a package with the right name. Jul 24 11:27:03 "Your version of bblayers.conf has the wrong LCONF_VERSION (has 62, expecting 6). Please compare the your file against bblayers.conf.sample and merge any changes before continuing." Jul 24 11:27:08 that's a slightly better error message Jul 24 11:27:53 lpapp: well, what what your distro setting so far? DISTRO_FEATURES, the QA checks, global compilation flags, etc are all distro variables. Jul 24 11:28:19 rburton: DISTRO_FEATURES_append = " largefile --disable-zlib" Jul 24 11:28:35 that's not how DISTRO_FEATURES works Jul 24 11:29:04 ? Jul 24 11:29:08 (specifically, --disable-zlib doesn't make sesnse there) Jul 24 11:30:18 what makes sense there then? Jul 24 11:30:22 anyway, that is all we set. Jul 24 11:30:30 I still need to understand whether I should go for poky, or not. Jul 24 11:30:36 its up to you, really. Jul 24 11:30:53 obviously, but I need to understand what that decision is based on. Jul 24 11:30:56 and yes, I mean technical considerations. Jul 24 11:32:05 it entirely comes down to how much customisation you expect to make to the distro Jul 24 11:32:19 you can start with inheriting poky and and switch to your own distro entirely if you want in the future, whatever. Jul 24 11:32:33 just be aware that --disable-zlib in DISTRO_FEATURES isn't doing anything Jul 24 11:32:39 the list of valid distro features is in the documentation Jul 24 11:34:07 as far as I can tell, poky is really not much Jul 24 11:34:11 95% is in oe-core. Jul 24 11:34:28 oh, more than that Jul 24 11:34:34 its 99% policy in poky.conf Jul 24 11:34:50 a new splash screen and the poky-tiny confguration for busybox. Jul 24 11:34:53 what is the point of poky then? Jul 24 11:34:56 It does not contribute much Jul 24 11:35:02 most of the stuff is done by oe-core. Jul 24 11:35:04 and some more BSPs Jul 24 11:35:07 yes Jul 24 11:35:10 its a reference distribution Jul 24 11:35:23 a known-working component that is tested by QA Jul 24 11:35:53 the problem is that we have own linux adaptation changes (huge patches) Jul 24 11:35:55 own patches against busybox. Jul 24 11:35:59 own splash screen Jul 24 11:36:21 so not much left in poky we could actually reuse. Jul 24 11:36:26 tiny-init maybe? Jul 24 11:36:43 that's for poky-tiny, where by "init system" you mean "busybox sh" Jul 24 11:36:57 as i said, poky is mostly policy in poky.conf Jul 24 11:37:12 you can happily inherit and tweak that, or start from the defaults in oe-core. Jul 24 11:37:26 people do both, there is no "right" answer Jul 24 11:38:19 happily is a bit exaggeration Jul 24 11:38:24 it has caused a headache for half a day Jul 24 11:38:32 with the version thingie and wrong error message. Jul 24 11:39:08 sure, i'm writing the commit message now to clarify that error Jul 24 11:41:09 rburton: how would I solve it with inheriting anyway? Jul 24 11:41:19 I would still need to roll back to version 5? Jul 24 11:41:21 no Jul 24 11:41:37 the problem is that oe-core and poky have different layer versions Jul 24 11:41:53 you're using poky templates because you're using the poky tarball, but not using poky Jul 24 11:41:57 so 5!=6 Jul 24 11:42:16 inheriting poky means we cannot have our own distro definition? o_O Jul 24 11:42:21 sure you can Jul 24 11:42:41 * lpapp is lost then Jul 24 11:43:04 how can I make 6 work then with inheritance? Jul 24 11:43:07 rburton: lpapp: if you want to "inherit" poky, then your distro.conf should require conf/distro/poky.conf Jul 24 11:43:09 rburton: so you get poky and then can change it Jul 24 11:43:11 rburton: that will also solve your conflicting version problem Jul 24 11:43:13 rburton: (that's what guacamayo does, inherits poky and changes a few values) Jul 24 11:45:11 is that something people often do? Jul 24 11:45:39 some. others don't use a distro. others roll their own distro from scratch. Jul 24 11:47:14 from scratch means based upon oe-core? Jul 24 11:51:10 yes Jul 24 11:51:30 is there an example for this require thingie? Jul 24 11:53:31 lpapp: my line was literally an example, but https://github.com/Guacamayo/meta-guacamayo/blob/master/meta-guacamayo/conf/distro/guacamayo.conf is the source of what i was saying. that's a distro based on poky. Jul 24 11:54:27 weird Jul 24 12:01:29 rburton: WARNING: Unable to get checksum for foo SRC_URI entry authorized_keys: file could not be found Jul 24 12:01:38 rburton: WARNING: Unable to get checksum for foo SRC_URI entry bar: file could not be found Jul 24 12:01:44 this was not a problem with denzil Jul 24 12:01:53 this enforcement was introduced later? Jul 24 12:02:16 something probably changed Jul 24 12:02:21 show some context and we can help Jul 24 12:03:00 nothing changed in our package. Jul 24 12:03:18 oh, btw, we have custom user space tools as well in meta-foo Jul 24 12:03:22 it is called recipes-foo Jul 24 12:03:33 that kinda yields a reason for an own distro, too? Jul 24 12:04:01 nope Jul 24 12:04:22 a distro is mostly policy, global cflags, distro-features, etc. Jul 24 12:07:04 ? Jul 24 12:07:13 additional packages are distro features Jul 24 12:07:20 which are not present in one, but does present in another. Jul 24 12:07:25 those are distro features. Jul 24 12:08:24 they are not "DISTRO_FEATURES" Jul 24 12:08:24 which is what i meant Jul 24 12:08:32 SRC_URI = "file://bar \ Jul 24 12:08:37 in foo_foover.bb Jul 24 12:08:41 well... Jul 24 12:08:48 we cannot upstream our custom commercial utils. Jul 24 12:08:54 sure, of course not Jul 24 12:08:54 so it is very unlikely to end up in poky Jul 24 12:09:02 you're not forced to either, yocto is all MIT Jul 24 12:09:04 in which case, not having our own distribution is kinda moot. Jul 24 12:09:31 what shall I run for bitbake to return the checksum for me? Jul 24 12:10:02 I'm trying to wrap my head around the layers concept. What is a BSP in yocto's sense of the word? Is that a collection of low-level rules which provides kernel, bootloader, etc. Or is a BSP a highlevel description saying: "My system consists of this kernel, this bootloader, this app, these libs" and so on. Jul 24 12:10:16 "bitbake foo" did not help. Jul 24 12:10:25 lpapp: you shouldn't need checksums for file:// uris Jul 24 12:10:28 sveinse: the former. Jul 24 12:10:34 so what's the actual src_uri? Jul 24 12:10:40 Because if its the former (which I presume), you need a meta- for the BSP and another meta for describing the entire system, right Jul 24 12:10:41 rburton: ? Jul 24 12:10:49 sveinse: yeah Jul 24 12:11:01 lpapp: you shouldn't need checksums for file:// URIs Jul 24 12:11:12 lpapp: so what's the full SRC_URI? Jul 24 12:11:19 bluelightning: hehe... i was able to do what i wanted in bblayers.conf. BBLAYERS += "${@' ${LL} ' if os.path.isfile('${LL}/conf/layer.conf') else ''}" works. Jul 24 12:11:21 daaaaaaamn Jul 24 12:11:24 lpapp: are there any yocto OOB examples how this top-level is setup? Jul 24 12:11:24 I cannot stop bitbake again. :( Jul 24 12:11:27 this is annoying, really. Jul 24 12:11:30 ctrl-c should just work. Jul 24 12:11:34 any hackaround? Jul 24 12:11:40 i got the idea from the guacayamo conf file that was just posted above... Jul 24 12:11:41 kill? Jul 24 12:11:42 lpapp: as i said earlier, there's a race. control-z then kill works. Jul 24 12:13:01 rburton: http://paste.kde.org/p63cf3a6c/ Jul 24 12:14:07 is there a shortcut to clean up the build folder except the already set config files? Jul 24 12:14:14 to avoid this command manually: Jul 24 12:14:20 lpapp: that file doesn't match your errors? Jul 24 12:14:26 rm -rf bitbake.lock cache downloads sstate-cache tmp Jul 24 12:14:30 rburton: ? Jul 24 12:14:43 rburton: that is the foo_ver.bb file. Jul 24 12:14:46 referring to bar. Jul 24 12:15:12 maybe it just can't find the file and will later ignore doing a checksum Jul 24 12:15:29 there was a change to the file lookup, where is it? Jul 24 12:15:49 when it was changed was almost zero fallout, but you may have used a bad place. Jul 24 12:15:57 (i.e. where is bar in relation to the recipe) Jul 24 12:16:11 if its alongside it, don't do that. put it in files/ or foo/ Jul 24 12:16:37 lpapp: you should remove WORKDIR from LIC_FILES_CHECKSUM no? Jul 24 12:16:39 rburton: beside it. Jul 24 12:16:59 rburton: why ? Jul 24 12:17:06 it causes problems Jul 24 12:17:10 put files in a directory Jul 24 12:17:19 call it files, or $PN, or $PN-$PV Jul 24 12:17:39 alongside working was luck as iirc that wasn't documented anywhere Jul 24 12:17:45 rburton: well, in an ideal world, it should not cause problems, I believe. Jul 24 12:18:09 lpapp: well, it caused problems. if you're curious you can dig out the commit and read the rationale. Jul 24 12:18:12 ndec: that sounds like a good idea to me... Jul 24 12:18:32 rburton: ok, I will ignore the warning for now. Jul 24 12:18:42 that recipe, as you can see, is just about installing a file. Jul 24 12:18:47 a conf file, pretty much. Jul 24 12:19:12 will bitbake clean or so help me with the other issue? Jul 24 12:19:46 lpapp: just rm -rf tmp Jul 24 12:19:57 keep downloads and sstate-cache unless you know you've managed to taint your cache Jul 24 12:20:22 should not there be an option doing that? Jul 24 12:20:34 ndec: I removed. Jul 24 12:20:37 rburton: I moved stuff into files Jul 24 12:21:04 although I am still getting this: Jul 24 12:21:12 WARNING: Unable to get checksum for foo SRC_URI entry bar: file could not be found Jul 24 12:21:18 WARNING: Unable to get checksum for root-ssh-authorized SRC_URI entry COPYRIGHT: file could not be found Jul 24 12:21:26 WARNING: Unable to get checksum for foo SRC_URI entry COPYRIGHT: file could not be found* Jul 24 12:22:07 SRC_URI = "file://files/bar \ Jul 24 12:22:23 lpapp: file://bar not file://files/bar Jul 24 12:23:30 bluelightning: ? Jul 24 12:23:36 we have just discussed to move into files. Jul 24 12:23:54 yes, move the files, the src_uri references were find Jul 24 12:23:56 fine Jul 24 12:24:01 bitbake will hunt around for the right ones Jul 24 12:24:03 ok Jul 24 12:24:10 COPYRIGHTS should also move to files? Jul 24 12:24:10 lpapp: yes, files/ is already in the search path for a recipe by default, so you don't need to specify it Jul 24 12:24:17 by default as discussed you can use files, $PN, or $PN-PV. Jul 24 12:24:17 k Jul 24 12:24:37 so you can have files for all recipes in that directory, then files for a specific recipe, and other files for specific versions of specific recipes Jul 24 12:24:45 yeah, I know Jul 24 12:24:49 but what about COPYRIGHT? Jul 24 12:25:00 everything is supposed to go into those except foo_bar.bb? Jul 24 12:25:14 which is supposed to go into the package root? Jul 24 12:26:11 WARNING: Variable package_do_filedeps contains tabs, please remove these (/home/lpapp/Projects/Yocto/poky-dylan-9.0.0/meta-foo/recipes-core/busybox/busybox_1.20.2.bb) Jul 24 12:26:18 that warnings must have been introduced after denzil, too. Jul 24 12:26:28 lpapp: yes Jul 24 12:26:44 python functions need to be four-space indented Jul 24 12:26:49 kinda Jul 24 12:27:17 might be easier to re-base your patches against our busybox with a bbappend? Jul 24 12:27:18 bluelightning: Hi, is meta-openembedded-contrib/log/?h=paule/mosh ready to be merged? Jul 24 12:27:31 rburton: nope, it is really custom Jul 24 12:27:35 not expected to be upstreamed. Jul 24 12:27:48 is there a reformatting tool? Jul 24 12:27:49 JaMa: if people are happy with where the recipes are going, yes (and I think they are) Jul 24 12:27:53 bluelightning: I'm lost a bit in discussion about it and verification build will take another day at least, so I'll trust your word and merge Jul 24 12:27:54 some astyle thingie? Jul 24 12:28:15 lpapp: sadly not Jul 24 12:28:39 rburton: test-dependencies run finished today (finally), I'm sending few more patches with deps discovered in smaller builds (with less layers) Jul 24 12:28:40 lpapp: search/replace on "\t" to " " should work nicely though Jul 24 12:28:45 JaMa: woo Jul 24 12:29:01 rburton: there is no tab in that file fwiw. Jul 24 12:29:06 JaMa: great job btw, thanks for going through that exercise and fixing up the issues found Jul 24 12:29:20 rburton: again, poor error message. Jul 24 12:29:25 rburton: should spot the line? Jul 24 12:29:34 lpapp: does it do an include? Jul 24 12:29:45 require you mean? Jul 24 12:29:52 require or include Jul 24 12:29:57 yes, first line Jul 24 12:30:01 check that file Jul 24 12:30:04 require busybox.inc Jul 24 12:30:17 iirc the syntax check happens after the parse, so it doesn't know that Jul 24 12:30:44 well, it should report the right file anyway Jul 24 12:30:53 even if not line number Jul 24 12:30:58 I imagine this would have been a headache for me without help Jul 24 12:31:04 I would not really have known what the problem is Jul 24 12:31:19 lpapp: patches welcome Jul 24 12:31:45 it tells you what python function has the tabs in Jul 24 12:31:46 rburton: I welcome them, too. ;) Jul 24 12:31:50 so this isn't exactly rocket science Jul 24 12:32:22 rburton: function is not enough Jul 24 12:32:26 I really need file. Jul 24 12:32:31 dude, grep Jul 24 12:32:33 and even line number Jul 24 12:32:39 the *entire function* Jul 24 12:32:48 its not just one tab, the entire function needs re-indenting Jul 24 12:33:01 * rburton -> food Jul 24 12:33:03 rburton: bluelightning: what do you think about backporting those fixes to dylan after some time in master? Jul 24 12:33:16 rburton: well, it could list all the offending lines. Jul 24 12:33:20 lpapp: this only happens to the developers and he'd immediately notice it on next bitbake run Jul 24 12:33:27 -s Jul 24 12:33:42 JaMa: if they're applicable to the versions in dylan, I don't see why not Jul 24 12:33:45 rburton: bluelightning: I have jansa/dylan-backports branch for oe-core/meta-oe which contains all needed changes for these dependencies in dylan (where I was running most of build tests) Jul 24 12:34:01 JaMa: ok, thanks Jul 24 12:34:08 ant_work: ? Jul 24 12:34:09 lpapp: it's the *entire function*, line numbers won't help any more than just the function name. and as i said, the error is happening at the wrong point in the parse to know about includes. if it bothers you that much feel free to rewrite the parser. Jul 24 12:34:34 if you are bitbaking your recipe you'll see you did some mistake Jul 24 12:34:57 bluelightning: ok I'll send pull-request after few weeks if nobody finds any issue in master Jul 24 12:35:05 ant_work: again, I would not have known without help. Jul 24 12:35:11 I would not have looked into inc files. Jul 24 12:43:25 rburton: bluelightning http://paste.kde.org/p69f1bde6/ Jul 24 12:44:57 lpapp: are you adding your own busybox recipe solely for changing the config? Jul 24 12:45:11 bluelightning: no Jul 24 12:45:40 bluelightning: we have custom patches to core utils. Jul 24 12:45:44 lpapp: you are hitting this problem I suspect because you're bringing in an old busybox recipe which does not match up to the requirements based upon the current recipe Jul 24 12:46:20 bluelightning: ? Jul 24 12:46:34 lpapp: even so, my suggestion would be to use a bbappend rather than a complete recipe; you can still apply patches and/or change the config / variables / whatever you need Jul 24 12:46:47 lpapp: "This usually means one provides something the other doesn't and should." Jul 24 12:47:00 bluelightning: no no Jul 24 12:47:04 the patches are not meant to be updated. Jul 24 12:47:08 they are quite domain specific Jul 24 12:47:11 er... Jul 24 12:47:17 upstreamed* Jul 24 12:47:31 I'm not making any reference to upstreaming Jul 24 12:47:54 I am doing, Jul 24 12:48:10 you mentioned last time if we wanna maintain a software on our own, it is better to put into our own layer which I agree with. Jul 24 12:48:22 lpapp: yep, and I'm not contradicting that Jul 24 12:48:54 bluelightning: ? Jul 24 12:49:02 lpapp: I'm suggesting that rather than an additional busybox recipe, use a busybox bbappend to achieve the same thing Jul 24 12:49:42 lpapp: that way you avoid some of the compatibility problems when you upgrade, like the one you are hitting now Jul 24 12:49:50 bluelightning: ? Jul 24 12:49:57 the whole idea was to maintain it on our own Jul 24 12:50:07 yes, and that won't change by using a bbappend Jul 24 12:50:08 if I use bbappend I *am* forced to update my change. Jul 24 12:50:17 even though when it is totally unreasonable due to our milestone. Jul 24 12:51:36 so, I do not feel comfortable at all without external force. Jul 24 12:51:43 that is exactly the reason why I would like to maintain my version Jul 24 12:51:49 without any explicit requirement to upgrade it. Jul 24 12:54:04 so how can I fix this situation with my own recipe, et cetera? Jul 24 12:55:53 morning Jul 24 12:56:13 i am having some problems with arago-oe-dev, hope someone could help :-) Jul 24 12:56:38 I added this layer to my bblayers.conf Jul 24 12:56:50 bluelightning: ^ Jul 24 12:56:50 but when buliding the image, i get this error: Jul 24 12:57:03 ERROR: ParseError at /home/jose/mcsdk/sources/arago-oe-dev/classes/java.bbclass:8: unparsed line: 'datadir_java ?= ${datadir}/java' Jul 24 12:57:54 lpapp: ok, so if you want to keep to the fixed version, you can keep your full recipe; however since upgrading you'll need to base it on the current busybox recipe since that clearly provides some things that the old one does not and those things are required Jul 24 12:58:39 melonipoika: looks like the value is missing enclosing quotes Jul 24 12:58:39 bluelightning: could you please be a bit more specific Jul 24 12:59:00 dylan uses exactly the same upstream version. Jul 24 12:59:14 lpapp: compare the two files to see what the difference is Jul 24 12:59:15 this is how the line 8 looks like Jul 24 12:59:16 # Jar location on target Jul 24 12:59:17 datadir_java ?= ${datadir}/java Jul 24 12:59:37 bluelightning: which files? Jul 24 12:59:41 .inc, .bb, etc? Jul 24 12:59:45 lpapp: busybox_xyz.bb Jul 24 12:59:54 lpapp: and the inc files Jul 24 13:00:11 melonipoika: I think that needs to be datadir_java ?= "${datadir}/java" Jul 24 13:00:13 bluelightning: they have a shitload of patches. Jul 24 13:00:23 again, I think bitbake has a very poor error reporting. Jul 24 13:00:25 bluelightning, thanks, will try it' Jul 24 13:00:54 it should write exactly what the problem is. Jul 24 13:01:00 that error message is just as vague as the previous ones. Jul 24 13:01:09 perhaps for 10.0 the error reporting system should be revamped. Jul 24 13:02:19 lpapp: we'd all like to see such error messages be more helpful, but fixing that for all error messages isn't a straightforward task; in a lot of the cases we don't have the information needed in the context where the error needs to be thrown Jul 24 13:02:55 bluelightning: that is what I mentioned revamping. Jul 24 13:03:04 the architecture should make sure you do have the information. Jul 24 13:03:09 why* Jul 24 13:23:22 How should I add libnfsidmap package to rootfs using IMAGE_INSTALL ? Jul 24 13:23:53 libnfsidmap package has been renamed to libnfsidmap0 by debian.bbclass Jul 24 13:24:31 frank_fighting71: in IMAGE_INSTALL you use the name before the renaming, i.e. libndfsidmap Jul 24 13:24:40 frank_fighting71: er, I meant libnfsidmap Jul 24 13:25:24 bluelightning: I did as you said, but I met do_rootfs error Jul 24 13:25:35 frank_fighting71: please pastebin it Jul 24 13:25:42 indicating libnfsidmap not found in the feed Jul 24 13:34:47 frank_fighting71: hmm, that works here with ipk... which version of the build system are you using? Jul 24 13:36:06 how to check the version ? I git clone poky repo several days ago. Jul 24 13:36:27 whats special about the yocto kernel compared to vanilla kernel? Jul 24 13:36:42 ipk also also rename the lib package name ? Jul 24 13:37:04 frank_fighting71: oh so you're using master... FWIW, my test was with master so it should work... Jul 24 13:37:52 I have some custom HW where I have a complete custom 3.4.24 kernel. Can I use that with yocto as-is, or do I need to merge in some yoctoisms into the kernel? Jul 24 13:38:19 sveinse: you should be able to use your own kernel config if that's what you prefer Jul 24 13:39:25 bluelightning: ok. Which brings me to my first question: Why a yocto kernel? Jul 24 13:42:08 bluelightning: any clue what the problem might be? Jul 24 13:43:09 lpapp: have you compared the recipes and inc files? Jul 24 13:43:18 bluelightning: it is a lot of diff Jul 24 13:43:25 I honestly have no clue what can cause issues for oe-core Jul 24 13:43:38 and since it is not verbose, I would need to look into the oe-core code Jul 24 13:43:42 unless someone here can help me. Jul 24 13:43:49 lpapp: perhaps you would be best off using the new recipes as a basis and putting your patches into that Jul 24 13:43:54 it should not be a problem at all to ship your own version. Jul 24 13:44:09 bluelightning: in the short term, yes. Jul 24 13:44:16 bluelightning: for long term thinking, not really, no. Jul 24 13:44:29 lpapp: so what is it that you want? Jul 24 13:44:32 and I am considering yocto for long term, so I need to understand why it complains. Jul 24 13:44:45 I cannot just do things blindly. Jul 24 13:44:50 I need to understand what is going on. Jul 24 13:44:56 and if error reporting is not helpful. Jul 24 13:45:01 lpapp: then, you need to look at and understand the differences Jul 24 13:45:07 and no one can help here, I will have hard time, but I will need to look into the code. Jul 24 13:45:10 lpapp: have a look at the busybox in oe-core and see what it PROVIDES Jul 24 13:45:16 then compare that with your own recipe Jul 24 13:45:19 and RPROVIDES Jul 24 13:45:22 yeah, and that Jul 24 13:45:47 as the message says, one of them provides something the other doesn't, so it needs to build both to resolve all dependencies. Jul 24 13:46:09 sveinse: I don't have a complete answer for you; I do know we maintain a tested patch series on top of the kernel that includes some things that are not in mainline, as well as providing tools to aid kernel development Jul 24 13:46:13 there is no such a thing as PROVIDES in the recipe though. Jul 24 13:46:32 nor in the .inc Jul 24 13:46:44 lpapp: any difference in PACKAGES will also constitute a difference in effective PROVIDES Jul 24 13:47:31 sveinse: dvhart or zeddii are your best bet for a proper answer to that question Jul 24 13:47:46 bluelightning: Thanks, I think that's enough info now. I just wanted to know if I lost something when deviating to a custom kernel. E.g. android requires many androidisms to be able to work Jul 24 13:48:27 sveinse: i'm no expert, but if you want to roll your own kernel then feel free. yocto doesn't expect any patches to be applied, unlike android. Jul 24 13:48:28 sveinse: about yocto kernel the patchset is 'public' but the advantage you get are 1) is maintained 2) free stable patchsets, 3) almost zero maintenance Jul 24 13:49:35 are people now trying to add random stuff to their bblayers.conf? Jul 24 13:49:58 melonipoika: why are you even adding arago-oe-dev to yocto config? Jul 24 13:50:31 grep PACKAGES -rn ../meta/recipes-core/busybox/ Jul 24 13:50:31 ../meta/recipes-core/busybox/busybox.inc:18:PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev ${PN}-hwclock" Jul 24 13:50:34 ../meta/recipes-core/busybox/busybox.inc:27:INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev ${PN}-hwclock" Jul 24 13:50:37 ../meta/recipes-core/busybox/busybox.inc:36:SYSTEMD_PACKAGES = "${PN}-syslog" Jul 24 13:50:58 point is, we have a product on the marked where a custom kernel was developed for the custom HW (omap3 based display device). So now I'm considering yocto to be able to make a smaller, more lean system. Jul 24 13:51:24 grep PACKAGES -rn ../meta-foo/recipes-core/busybox/ Jul 24 13:51:41 ../meta-foo/recipes-core/busybox/busybox.inc:26:PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev" Jul 24 13:51:49 ../meta-foo/recipes-core/busybox/busybox.inc:34:INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-udhcpc ${PN}-mdev" Jul 24 13:52:20 hwclock maybe? Jul 24 13:52:47 lpapp: not unlikely: meta/recipes-core/packagegroups/packagegroup-core-boot.bb: ${@base_contains("MACHINE_FEATURES", "rtc", "busybox-hwclock", "", d)} \ Jul 24 13:54:37 bluelightning: then what else to check, really Jul 24 13:54:55 So here I am n00b-ing and trying to figure out where to go after watching the getting started screencast and building my first image with the quick start manual Jul 24 13:55:52 lpapp: no, I mean it's likely to be the lack of busybox-hwclock that's causing the issue Jul 24 13:56:14 btw, poky-denzil-7.0.1/meta/recipes-core/busybox/busybox.inc -> it contains tabs Jul 24 13:56:21 so old denzil code was bad, and it was not our mistake apparently. Jul 24 13:56:38 sveinse: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/00-README Jul 24 13:56:40 * zeddii has to bolt to the airport. grab me by email if there are questions. Jul 24 13:56:51 lpapp: we introduced the requirement after denzil, before that it was an inconsistent mess, hence why we changed to enforce four spaces Jul 24 13:57:15 lpapp: FWIW, this was mentioned in the migration info I linked yesterday Jul 24 13:57:48 do you have that link at hand? Jul 24 13:58:28 lpapp: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration Jul 24 13:58:34 IMHO there is a gap in the docs from the tutorial building an existing image/system to the various dev manuals. Particularly I'm lacking a small howto to setup a new BSP and how to setup a new top-level configuration where you can select which packages go into the image. Jul 24 13:59:54 bluelightning: yeah, hw-clock was it. Jul 24 14:00:01 so how about the other toolchain errors? Jul 24 14:00:03 ant_work: Thanks. Another option is to rebase our kernel changes into a yocto kernel clone Jul 24 14:00:06 elibc, etc? Jul 24 14:00:27 and external-sourcery-toolchain Jul 24 14:00:59 sveinse: it has been developed with git in mind but you really don't need a branch. You ca paraxite linux-yocto with a .bbappend Jul 24 14:01:21 sveinse: or use linux-yocto-custom as a base (see meta-skeleton) Jul 24 14:01:27 righto Jul 24 14:01:36 sveinse: the BSP guide should cover creating a simple BSP Jul 24 14:03:03 bluelightning_: Perhaps it does. I'm trying to absorb and read as much as I can, so I have probably missed it. Jul 24 14:05:25 sveinse: if you find shortcomings in the docs after looking there it would be useful feedback Jul 24 14:06:27 rburton: ^ Jul 24 14:06:43 lpapp: never used an external toochain, sorry Jul 24 14:06:54 :( Jul 24 14:07:24 http://paste.kde.org/p69f1bde6/ -> so getting 3-10 basically. Jul 24 14:07:31 is it really external toolchain related? Jul 24 14:07:44 or does it happen to be a problem with that package, but a general yocto issue? Jul 24 14:09:03 Let me see if I got the setup of this right: I download poky into poky/. I want to setup a git for our metas, so I use yocto-layers to create meta-laerdal as a top-level dir (only). From within that dir, I can use yocto-bsp to create a meta-myhw. And if I understand thing correctly, I should setup another meta- dir for specifying the top-level image contents Jul 24 14:10:02 is the external-sourcery-toolchain.bb maintainer in here? Jul 24 14:10:50 is it actually actively supported? Jul 24 14:11:02 bluelightning: you're right, I compiled with master and IMAGE_INSTALL += "libnfsidmap", succussful! Thanks! Jul 24 14:11:45 frank_fighting71: great! Jul 24 14:12:05 lpapp: the person who usually maintains it is kergoth Jul 24 14:12:11 BTW, is there a way to compile multilib in yocto ? Jul 24 14:12:29 bluelightning_: ah, the one I ignored back then. Jul 24 14:12:54 bluelightning_: will ask on the mailing list anyway Jul 24 14:12:55 frank_fighting71: yes we support multilib - http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#combining-multiple-versions-library-files-into-one-image Jul 24 14:13:13 not that I got solutions for my previous issues. :( Jul 24 14:13:22 bluelightning: Thanks ! Jul 24 14:14:58 bluelightning_: anyway, that issue has no relation to my layer Jul 24 14:15:04 not according to the error message, anyway. Jul 24 14:15:17 likely a platform bug. Jul 24 14:15:47 kergoth: bluelightning_ https://lists.yoctoproject.org/pipermail/yocto/2013-July/017394.html Jul 24 14:17:50 bluelightning_: the dev-so sanity check, i wonder if we should refine it to only warn if its a proper dev symlink, i.e. if libfoo.so points at libfoo.so.1.2.3. eg only warn if target starts with symlink name. Jul 24 14:18:13 but state it clearly: is the external sourcery thingie officially supported? Jul 24 14:22:10 who maintains poky-dylan-9.0.0/meta/recipes-core/eglibc/eglibc_2.17.bb ? Jul 24 14:23:43 who maintains libiconv? Jul 24 14:24:16 lpapp: eglibc, libiconv and the toolchain we actually build is mostly maintained by khem Jul 24 14:24:39 khem: idea? Jul 24 14:25:26 bluelightning_: I have the temptation of removing those provides from the external sourcery... Jul 24 14:25:33 not sure if it was blowing up... Jul 24 14:35:30 bluelightning_: are those supported officially? Jul 24 14:35:43 or just leisure time projects for someone? Jul 24 14:35:44 lpapp: which? Jul 24 14:35:49 all those Jul 24 14:36:45 Is there a simple method to remove a default package from a image(eg,core-image-sato) ? __except__ hob. Jul 24 14:36:54 lpapp: what we actually test: eglibc + the toolchain we actally build Jul 24 14:37:21 bluelightning_: so external toolchains are not supported by the yocto project? Jul 24 14:37:42 lpapp: there are a number of organisations involved in the Yocto Project that do use it in conjunction with external toolchains Jul 24 14:38:10 that is not what I asked. Jul 24 14:38:48 lpapp: that is the only answer I have for you, I personally do not use an external toolchain Jul 24 14:39:12 so you do not know, I take it. Jul 24 14:41:10 bluelightning_: one negative point in yocto is the lack of proper error reporting system Jul 24 14:41:25 hopefully it will improve over time. Jul 24 14:41:44 lpapp: we have a proper error reporting system Jul 24 14:41:50 nope Jul 24 14:41:53 lpapp: yep Jul 24 14:41:58 otherwise all the issues today would have been clear for everyone. Jul 24 14:42:09 lpapp: we have some error cases where information is not displayed that would be helpful Jul 24 14:42:51 no no Jul 24 14:42:56 I mean error reporting system:- Jul 24 14:43:08 you have the information needed at the right place. Jul 24 14:47:58 bluelightning_: even bruteforce commenting of those offending packages in poky-dylan-9.0.0/meta/recipes-core/meta/external-sourcery-toolchain.bb did not help. :( Jul 24 14:51:29 bluelightning_: what is a virtual, btw? Jul 24 14:52:14 lpapp: it's a convention for items that may be provided by more than one provider Jul 24 14:52:27 bluelightning_: what is the expected result when they are? Jul 24 14:53:02 lpapp: a PREFERRED_PROVIDER needs to be set to select which one should be built Jul 24 14:54:03 bluelightning_: where? Jul 24 14:54:32 lpapp: at the global level Jul 24 14:54:42 means? Jul 24 14:56:57 lpapp: local.conf, distro config, machine config depending on what you're selecting a preferred provider for Jul 24 14:57:40 bluelightning_: what is the point of virtual then? Jul 24 14:58:00 lpapp: I thought I explained that above Jul 24 14:58:54 lpapp: an example would be virtual/libgl. there's more than one GL implementation. Jul 24 15:03:15 bluelightning_: you did, but it does not make sense to me. Jul 24 15:03:29 bluelightning_: why do you need to tag something like that when you need to choose between two anyways? Jul 24 15:03:32 rburton: ? Jul 24 15:03:43 rburton: different implementations mean different projects with different packages. Jul 24 15:03:47 yes Jul 24 15:03:54 but applications just care that they get GL headers Jul 24 15:03:59 ? Jul 24 15:04:00 nope? Jul 24 15:04:04 so packages can depend on virtual/libgl Jul 24 15:04:08 lpapp: it's a convention, so that we know it's intended to be a selection rather than one specific recipe Jul 24 15:04:20 I specifically care about which gl implementation is implemented. Jul 24 15:04:24 i.e. not some open source crap Jul 24 15:04:30 wow Jul 24 15:04:34 but real stuff from the vendor with 3d acceleration and so forth. Jul 24 15:04:38 lpapp: sigh. of course *you* care, you're building the distro. Jul 24 15:04:44 rburton: no no Jul 24 15:04:48 lpapp: thats why you get to pick, using PREFERRED_PROVIDER Jul 24 15:04:49 I care as a user of the library Jul 24 15:04:54 i.e. game engine developer. Jul 24 15:04:58 but the library when its building doesn't care Jul 24 15:07:45 so people have to pick now, but they did not need with denzil? Jul 24 15:08:24 virtuals have been around for many years Jul 24 15:08:36 any errors you're seeing related to external toolchains are ... related to external toolchains. Jul 24 15:08:54 at which point you'll need to find someone else to help as i've not used them either. Jul 24 15:09:53 halstead: there? Jul 24 15:10:24 halstead: "Receiving objects: 13% (399274/2853620), 144.89 MiB | 5 KiB/s" <-- i was hoping for a faster clone than that from git.yocto :( Jul 24 15:14:34 rburton, Here. On a call right now. How long has the bandwidth been constrained at that level? Jul 24 15:15:16 halstead: it was like that for about five minutes until i noticed. aborted and re-started, now "flying" at 60K/s which still seems throttled for my connection. Jul 24 15:15:47 bluelightning: rburton http://paste.kde.org/p9c2e493f/ Jul 24 15:15:51 r.e. busybox Jul 24 15:15:54 what is this again? :O Jul 24 15:16:46 fwiw: 131 do_configure () { Jul 24 15:16:46 132 do_prepare_config Jul 24 15:16:46 133 merge_config.sh -m .config ${@" ".join(find_cfgs(d))} Jul 24 15:16:46 134 cml1_do_configure Jul 24 15:16:46 135 } Jul 24 15:17:27 lpapp: according to grep, that's defined in busybox.inc Jul 24 15:17:46 this happens when using external-sourcery Jul 24 15:17:48 instead of external-csl Jul 24 15:17:54 for the TCLMODe thingie Jul 24 15:18:48 rburton: sure Jul 24 15:19:21 rburton: so what is the problem then? Jul 24 15:19:27 it is requiring that Jul 24 15:20:04 lpapp: no idea, works for me. Jul 24 15:20:10 maybe that external toolchain is breaking some other things Jul 24 15:20:54 rburton: but it is not toolchain scope. Jul 24 15:20:57 it looks like a bitbake issue. Jul 24 15:21:40 sorry, no idea. Jul 24 15:21:48 yeah, I replied to bill. Jul 24 15:21:54 is he using irc? Jul 24 15:22:20 am I the Bill you're referring to? ;) Jul 24 15:22:42 yep. :) Jul 24 15:22:46 hi Jul 24 15:23:19 hello Jul 24 15:24:47 wmat: got a clue for the error? Jul 24 15:25:00 rburton: I wonder why my predecessor thought --disable-zlib would be working ... Jul 24 15:25:32 lpapp: not immediately Jul 24 15:25:34 rburton: oh, and fwiw, poky has opengl in there, but the handbook does not mention such a feature: http://pokylinux.org/doc/poky-handbook.html Jul 24 15:26:46 lpapp: very true. http://www.yoctoproject.org/docs/current/ is the current docs, that site is old. Jul 24 15:27:14 rburton: perhaps it should be marked so then? Jul 24 15:27:30 rburton: also, the new link yields this, 403 Forbidden Jul 24 15:27:31 lpapp: yes Jul 24 15:27:57 https://www.yoctoproject.org/documentation/current, sorry Jul 24 15:28:42 rburton: well, cannot find opengl there either. Jul 24 15:28:57 lpapp: yeah needs to be added. probably a few others missing too. Jul 24 15:29:55 so who is the python master here? Jul 24 15:30:02 who can tell more about the busybox thingie? Jul 24 15:30:08 the function is clearly defined in the inc. Jul 24 15:30:16 also, why does it care about the meta / busybox? Jul 24 15:30:23 shouldn't it pick up my busybox from my layer? Jul 24 15:30:54 so the real question is: why does it not ignore the "default" from oe-core? Jul 24 15:31:24 lpapp: its probably trying to parse it, so this is before it decides to not execute anything there Jul 24 15:31:58 rburton: that sounds bad ordering. Jul 24 15:32:10 lpapp: very hard to ignore something unless you know what it is Jul 24 15:32:36 rburton: you should know in advance what to ignore. Jul 24 15:32:44 it* Jul 24 15:32:49 lpapp: but it doesn't know what it is until the file has been parsed Jul 24 15:33:00 it should parser the whitelist file. Jul 24 15:33:03 parse* Jul 24 15:33:08 that is what it should start with. Jul 24 15:33:15 and then the relevant version that is whitelisted. Jul 24 15:34:09 in any case, how parsing a python file can be related to an external toolchain? Jul 24 15:35:25 I am using python 2.7 fwiw. Jul 24 15:40:21 let us see if they get a clue on #python. Jul 24 15:41:03 lpapp: #python can't help Jul 24 15:41:30 well, tell me a better place for help. Jul 24 15:41:34 well, here Jul 24 15:41:54 yeah, like no one has been giving solutions for external toolchain issues for two days? Jul 24 15:42:03 if you can reliably replicate changing the toolchain means the error disappears and appears, then that's a good data point Jul 24 15:42:09 and bitbake -e will be very useful to find the differences that causes Jul 24 15:42:32 here is best, but also a limited number of people use external toolchains, so you'll have to be patient Jul 24 15:42:46 business does not work with patient. Jul 24 15:42:54 if I do not get help, I need to go the hard way. Jul 24 15:42:55 doesn't help that you'd blocked the one guy who is best placed to help Jul 24 15:43:08 well, he could reply on the mailing list? Jul 24 15:43:11 business can pay for support from a commercial support partner Jul 24 15:43:15 no no Jul 24 15:43:22 business does not mean people have money for everything. Jul 24 15:43:25 sure Jul 24 15:43:40 two options. 1) pay for support. 2) community support. Jul 24 15:43:49 3) solve it yourself. Jul 24 15:43:52 sure Jul 24 15:45:03 meh, even bitbake help is broken with dylan. :( Jul 24 15:45:20 really sounds like you've broken your setup somehow Jul 24 15:45:39 ? Jul 24 15:45:54 bitbake help -> starts building Jul 24 15:45:57 it should not start Jul 24 15:45:58 sure Jul 24 15:46:00 why not? Jul 24 15:46:01 it should print the help output. Jul 24 15:46:06 you've told it to build "help" Jul 24 15:46:10 did you mean --help? Jul 24 15:46:11 huh? Jul 24 15:46:14 lpapp: bitbake help is not broken on my dylan setup Jul 24 15:46:32 wasn't the "help" the same for the bblayer util? Jul 24 15:46:37 and for this, it is --help? Jul 24 15:46:42 isn't that tad confusing? Jul 24 15:46:56 patches welcome Jul 24 15:47:03 bitbake-layers is a tiny little convenience tool Jul 24 15:47:09 lpapp: FWIW, --help on bitbake-layers will trigger the help output anyway Jul 24 15:47:41 bluelightning: not for me, anyhow Jul 24 15:48:05 also, why is that not the official way? Jul 24 15:48:14 I have been told stuff help here yesterday Jul 24 15:48:19 so I tried that for bitbake Jul 24 15:48:46 if we're going to argue about command syntax, bitbake-layers is the outlier Jul 24 15:48:49 i suggest living with it Jul 24 15:49:07 rburton: the bitbake -e output is quite spammy. Jul 24 15:49:18 lpapp: that's not spam, it's the entire configuration space Jul 24 15:49:38 you might be able to identify why changing toolchain breaks busybox with that Jul 24 15:50:40 rburton: bitbake -e busybox should do it? Jul 24 15:50:46 lpapp: yep Jul 24 15:51:14 k Jul 24 15:54:29 rburton: did not help Jul 24 15:54:38 bitbake -e busybox > sourcery.log Jul 24 15:55:38 rburton: http://paste.kde.org/p29f3c3a3/ Jul 24 15:55:44 it is not actually printing such stuff. Jul 24 15:57:18 rburton: so something even before -e is broken in the pipeline. Jul 24 15:58:17 lpapp: what version of Python and what version of BitBake? Jul 24 15:59:28 lpapp: and what CSL toolchain? I'll try to reproduce your error. Jul 24 16:00:06 wmat: CSL toolchain means? Jul 24 16:00:18 lpapp: CodeSourcery? Jul 24 16:00:25 wmat: arm-2009q1 if that is what you mean. Jul 24 16:00:29 lpapp: yes Jul 24 16:01:42 sorry, I was wrong Jul 24 16:01:49 I regenerated sourcery.log and now it is more complete. Jul 24 16:02:13 lpapp: the EABI or GNU/Linux toolchain? Jul 24 16:05:14 wmat: arm-none-linux-gnueabi Jul 24 16:06:27 it's worth noting that mentor themselves haven't given much attention to the external-sourcery in oe-core, leaving it primarily as an example. we maintain https://github.com/MentorEmbedded/meta-sourcery Jul 24 16:06:41 we intend to sort out this situation to reduce confusion in the near future Jul 24 16:11:33 denzil external-cs worked just fine Jul 24 16:11:45 it is so sad that dylan broke the external toolchain usage. :( Jul 24 16:11:56 external-csl* Jul 24 16:13:44 what was the reason of not keeping external-csl around? Jul 24 16:13:54 until you have a _stable_ and _mature_ external-sourcery? Jul 24 16:14:21 for embedded developers, probably denzil is the way to go then... but that is not maintained. :( Jul 24 16:14:30 so in the end of the day, embedded developers are screwed. Jul 24 16:14:36 using cross-toolchain. :( Jul 24 16:16:03 the fix may be a simple patch once the problem is determined Jul 24 16:16:15 sure, but it is beyond my league. Jul 24 16:16:22 and a patch will not get into the release now. :( Jul 24 16:24:54 cat csl.log | ix Jul 24 16:24:57 http://ix.io/6QZ Jul 24 16:25:05 cat sourcery.log | ix Jul 24 16:25:06 http://ix.io/6R1 Jul 24 16:25:15 if anyone can check the mystery with diff. Jul 24 16:25:21 I do not see significant diffs. Jul 24 16:33:54 wmat: I wonder if you could check the diff. Jul 24 16:33:59 wmat: also, could you reproduce the issue? Jul 24 16:34:21 lpapp: I'm still waiting for Mentor to send me the link to download the toolchain :/ Jul 24 16:35:11 lpapp: the diff doesn't appear to contain anything apart from an extra include and timestamps Jul 24 16:35:32 lpapp: you can reliably switch between the two toolchain modes and the error changes? Jul 24 16:36:07 wmat: I can send it to you if that is quicker. Jul 24 16:36:23 rburton: as written, yes. Jul 24 16:36:55 rburton: + image name. Jul 24 16:37:15 + do_devshell hash Jul 24 16:42:05 rburton: so you think, the diff is ok, then? Jul 24 16:42:12 rburton: and the issue cannot be figured out from it? Jul 24 16:43:38 lpapp: nope Jul 24 16:44:32 rburton: nope? Jul 24 16:45:11 for which question, that is Jul 24 16:45:22 the diff is fine, but its not useful Jul 24 16:47:11 lpapp: how large is the toolchain file? is it email-able? Jul 24 16:47:25 wmat: of course no. :) Jul 24 16:47:32 wmat: but I can put it on dropbox. Jul 24 16:47:42 ok, make it so Jul 24 16:47:51 wmat: which host do you use? Jul 24 16:48:32 lpapp: linux x86_64 Jul 24 16:48:45 wmat: I mean which distro Jul 24 16:48:55 arch looks the same as mine Jul 24 16:48:58 so my binaries should work then. Jul 24 16:50:58 wmat: phew, it takes ages to just compress. Jul 24 16:51:11 lot of translation stuff. :/ Jul 24 16:52:01 lpapp: for dany, did you download the tarball or clone the repo? Jul 24 16:52:16 wmat: it is dylan Jul 24 16:52:30 I downloaded the release 9.0.0 Jul 24 16:53:12 wmat: hmm, sorry, I cannot send the toolchain. Jul 24 16:53:17 it contains our git history. Jul 24 16:53:29 again, what is your linux host? Jul 24 16:53:40 I would be surprised if they did not provide ready-made binaries off-hand. Jul 24 16:55:03 what toolchain was the sourcery thingie tested? Jul 24 16:55:08 with* Jul 24 16:56:09 rburton: is there a zlib disabling distro feature? Jul 24 16:56:42 lpapp: nope Jul 24 16:57:22 if you really don't want zlib installed you'll have to use bbappends to disable it in each recipe that links to it Jul 24 16:58:00 phew... Jul 24 16:58:06 that is kinda crazy. :) Jul 24 16:59:05 not as crazy as what i just did lat night... Jul 24 16:59:30 that does not comform me, I am afraid. Jul 24 16:59:33 comfort* Jul 24 16:59:45 but my sympathy is there though. Jul 24 17:05:23 lpapp: mentor does provide binaries, I just haven't received the link to download them yet Jul 24 17:05:26 lpapp: if you're even considering removing zlib you've clearly got a tiny install image, so it won't be a lot of effort Jul 24 17:05:32 lpapp: x86_64 Jul 24 17:05:54 rburton: well, we are using nor flashes Jul 24 17:05:55 32 MB Jul 24 17:06:10 wmat: yeah, but the distribution package would not need waiting. Jul 24 17:09:39 lpapp: i found a link in an old email. You said a 2009 version? Jul 24 17:10:03 wmat: quarter 1, yes. Jul 24 17:22:02 wmat: did you get the link? Jul 24 17:22:38 wmat: btw, you do not need to await any link Jul 24 17:22:40 https://developer.ridgerun.com/wiki/index.php/Code_Sourcery_ARM_toolchain_2009q1-203 Jul 24 17:22:45 the one from here can be downloaded off-hand. Jul 24 17:26:44 wmat: could you obtain it a way or another? Jul 24 17:27:00 lpapp: i have it now Jul 24 17:27:13 wmat: can you repro the issue? Jul 24 17:27:20 lpapp: so the only customizations you did were what? Jul 24 17:27:30 my layer Jul 24 17:27:36 and that is pretty much it Jul 24 17:28:16 to conf files? Jul 24 17:28:21 MACHINE ?= "polatisnic" Jul 24 17:28:24 oopsie Jul 24 17:28:30 sorry, for the spam Jul 24 17:28:35 MACHINE ?= "mymachine" Jul 24 17:28:46 DISTRO ?= "mydistro-tiny" Jul 24 17:28:50 and that is it Jul 24 17:29:04 and of course TCMODE = "external-csl" Jul 24 17:29:04 EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1" Jul 24 17:29:05 TARGET_PREFIX = "arm-none-linux-gnueabi-" Jul 24 17:29:14 I can try with poky-tiny as well Jul 24 17:29:24 or even "poky" for now. Jul 24 17:29:28 perhaps I should not, though. Jul 24 17:29:31 * lpapp is not sure Jul 24 17:29:48 help is appreicated. Jul 24 17:29:54 appreciated* Jul 24 17:30:17 lpapp: I'll use beagleboard Jul 24 17:30:34 for the machine, right? Jul 24 17:30:38 yes Jul 24 17:30:39 for the DISTRO? Jul 24 17:30:52 poky Jul 24 17:31:05 ok, let me try with that Jul 24 17:31:38 and what command like bitbake did you issue? Jul 24 17:31:56 unparsed line: 'MACHINE ?= beagleboard' Jul 24 17:32:04 bitbake core-image-minimal Jul 24 17:32:39 ah, missing quotes. Jul 24 17:33:44 hmm, I cannot reproduce the issue with those setups. Jul 24 17:35:50 is there a way to surpress the host distribution warning about unsupported stuff? Jul 24 17:36:39 lpapp: SANITY_TESTED_DISTROS = "" in your local.conf Jul 24 17:38:14 thanks Jul 24 17:38:28 I do not like the syntax of that, but it will do it for now. Jul 24 17:39:52 it's a list of distros that have been tested as used by sanity.bbclass; if no list is specified the host distro isn't checked Jul 24 17:40:10 (since there's nothing to check it against) Jul 24 17:41:04 it would be nice to have a boolean syntax for this. Jul 24 17:41:08 for enabling/disabling Jul 24 17:42:03 wmat: I use armv5 fwiw. Jul 24 17:44:42 wmat: yeah, I can definitely reproduce it with poky and beagleboard Jul 24 17:44:50 although with my layer inside the bblayers.conf Jul 24 17:44:55 not sure that should matter. Jul 24 17:45:40 as soon as you issue the bitbake command, do you see the two errors about the missing toolchain? Jul 24 17:45:54 wmat: no Jul 24 17:46:02 only at home. Jul 24 17:46:08 here at the company, I do not see that error. Jul 24 17:47:50 you did say you were using arm-none-eabi-* correct? Jul 24 17:48:24 not arm-none-linux-gnueabi-*? Jul 24 17:50:29 wmat: gnueabi what I use. Jul 24 17:50:42 but this is now strange... I can even reproduce with external-csl Jul 24 17:50:49 if I use the poky+beagleboard setup. Jul 24 17:51:50 wmat: so could you reproduce the issue? Jul 24 17:54:17 lpapp: I ahve to grab the gnueabi toolchain, as I only have the eabi toolchain now Jul 24 17:55:22 wmat: I already gave you the link, https://developer.ridgerun.com/wiki/index.php/Code_Sourcery_ARM_toolchain_2009q1-203 Jul 24 17:55:28 wmat: btw, what errors did you get? Jul 24 17:55:33 is it similar to what I got at home? Jul 24 17:55:39 some INVALID stuff in the error? Jul 24 17:56:11 lpapp: gimme a sec Jul 24 17:57:00 wmat: it could potentially help me a lot if you express that. Jul 24 17:57:25 lpapp: i'm sure it would, I just need time to complete the test Jul 24 17:57:41 what test? Jul 24 17:57:50 I thought you would have already done the experiment? Jul 24 17:57:59 for the wrong toolchain, so you could just paste the output you got? Jul 24 18:01:11 lpapp: it's building now with the correct toolchain Jul 24 18:01:47 wmat: I do not think you need to go that far. Jul 24 18:01:55 it does not even start the building for me. Jul 24 18:02:04 so if it is building for you, you simply cannot reproduce the issue. Jul 24 18:03:26 yep, mine is building fine Jul 24 18:03:37 so, can you give me the error message then? Jul 24 18:04:51 I got an error about multiple .bb files are going to be built for eglibc Jul 24 18:05:14 and an error about zlib fetch failed Jul 24 18:05:19 when? Jul 24 18:05:30 with the gnueabi toolchain? Jul 24 18:05:34 yes Jul 24 18:05:38 "I got an error about multiple .bb files are going to be built for eglibc Jul 24 18:05:39 " Jul 24 18:05:43 that looks exactly my issue Jul 24 18:05:47 if you read my email Jul 24 18:05:57 but with -k, it keeps building Jul 24 18:06:12 and with the right toolchain, you do not get those errors? Jul 24 18:06:38 no, I do Jul 24 18:07:02 because the eglibc recipe exists twice Jul 24 18:07:18 right, so you can actually reproduce then. Jul 24 18:07:28 once in core and once in meta Jul 24 18:07:35 could you please make sure you are getting the same errors as me on the mailing list? Jul 24 18:07:43 * wmat looks again Jul 24 18:07:47 ok, so it is an upstream bug. Jul 24 18:07:51 nothing to do with my setup. Jul 24 18:09:26 also, could you please let me know the error with the wrong toolchain? Jul 24 18:10:00 just that it couldn't find the toolchain, which is correct Jul 24 18:10:09 mind pasting the error message? Jul 24 18:10:24 is it the same I have on the mailing list? Jul 24 18:10:54 granted Jul 24 18:11:01 I can reproduce the busybox thingie even with dylan vanilla Jul 24 18:11:03 without my layer Jul 24 18:11:53 lpapp: no, it wasn't the same. It was just a missing toolchain error, as I didn't have the right toolchain. Jul 24 18:12:02 I didn't save it Jul 24 18:12:07 wmat: no, I mean I have two errors Jul 24 18:12:10 the one here at the company Jul 24 18:12:21 and in the same thread, I had another from home, yesterday. Jul 24 18:12:32 wmat: in any case, is this a hard fix upstream for the external thingie? Jul 24 18:13:11 lpapp: once the build completes, I can paste the log somewhere Jul 24 18:13:15 hope the fix can come with a poky dylan bugfix release soon in the near future ... Jul 24 18:13:25 wmat: I do not particularly need the log. Jul 24 18:13:28 we already discussed it. Jul 24 18:13:44 lpapp: well, a bug needs to be opened for it to be fixed Jul 24 18:13:46 or if you mean for the wrong toolchain, then ok. Jul 24 18:13:55 wmat: that is the less issue. Jul 24 18:14:01 the main thing is that do you have any clue how to fix it? Jul 24 18:15:15 at present, no Jul 24 18:16:25 :( Jul 24 18:16:36 wmat: can you ask kergoth Jul 24 18:16:39 I think he is ignoring me Jul 24 18:16:45 otherwise he would have chimmed in already. Jul 24 18:17:43 lpapp: I replied to your email, please file a bug with all your configuration files so that the information is all in one place Jul 24 18:17:47 I have to move onto other work now, but I'd try opening a bug Jul 24 18:18:13 sgw1: I already did Jul 24 18:19:14 lpapp: where, I just checked the bugzilla.yoctoproject.org and do not see any bug from you Jul 24 18:20:43 sgw1: maybe you need to refresh or so Jul 24 18:20:45 lpapp sorry, timing of bugzilla I guess Jul 24 18:20:47 I did it a couple of minutes ago Jul 24 18:21:14 anyway, even if no one can work on it, I need a workaround ASAP Jul 24 18:21:21 it is kinda blocking my company work right now. Jul 24 18:21:30 wmat: is the -k thingie an acceptable workaround? Jul 24 18:21:34 it will not blow up later? Jul 24 18:21:39 lpapp: understood, I am going to try and repoduce this here now Jul 24 18:22:16 lpapp: I use -k frequently Jul 24 18:22:33 lpapp: to confirm, you are now using dlyan HEAD from git? Jul 24 18:22:39 sgw1: no Jul 24 18:22:44 dylan 9.0.0 Jul 24 18:23:39 lpapp: I thought it was suggested that you use dylan HEAD, since there are some patches that you needed in it. Jul 24 18:23:50 ok I will use the 9.0.0 tag Jul 24 18:23:59 sgw1: we cannot afford the risk as a company. Jul 24 18:24:06 if something is not working, we need to backport. Jul 24 18:24:15 the relevant stabilization patches. Jul 24 18:24:18 I've often thought that bitbake's -k argument would make a sane default behavior, if we did a little better job of summarizing the results and failures at the end Jul 24 18:24:24 but we definitely cannot base stuff on a rolling 'dev' branch. Jul 24 18:25:28 sgw1: please check the bugreport again, as I have just written a few additional information about the toolchain, and the dylan version. Jul 24 18:25:44 well, I can try HEAD Jul 24 18:25:47 it does not take long Jul 24 18:25:55 not that we will use it. Jul 24 18:25:58 but we can see if it got fixed in there. Jul 24 18:27:20 kergoth: I'd agree with that. I'd rather complete a build and deal with a nice log file afterwards. Jul 24 18:27:41 it requires much less babysitting Jul 24 18:27:46 and developer time is valuable Jul 24 18:28:18 wmat: what is the workaround? Jul 24 18:28:24 lpapp if not head how about the stable update of 9.0.1? Jul 24 18:28:39 lpapp: use -k is all I did Jul 24 18:28:46 wmat: is that acceptable? Jul 24 18:28:49 will it not blow up later? Jul 24 18:28:55 can we breath the air safely afterwards? Jul 24 18:28:57 lpapp: it's acceptable to me Jul 24 18:29:19 lpapp what command did you issue to get the failure? Jul 24 18:29:21 sgw1: we can only use releases. Jul 24 18:29:31 and if we choose dylan now, we will stick to it for at least a year Jul 24 18:29:35 lpapp: 9.0.1 is a release Jul 24 18:29:39 and only stable bugfix releases would be acceptable. Jul 24 18:29:46 sgw1: not mentioned on the website. Jul 24 18:29:50 it's the stable bugfix release for dylan Jul 24 18:29:55 sgw1: fix the website then. Jul 24 18:30:25 lpapp: also, why not use a newer toolchain? Jul 24 18:30:42 wmat: because our software is based on old? Jul 24 18:30:55 wmat: and we did not have the time to fix stuff around it when even yocto does not work? Jul 24 18:31:10 you know ... step by step. Jul 24 18:31:14 we are not an engineer army. Jul 24 18:31:21 I would love to update to 2013.05 due to C++11 Jul 24 18:31:23 lpapp: it's on the website, www.yoctoproject.org/downloads, first item on the list Poky 9.0.1 released 6/27, fix your eyes ;-) Jul 24 18:31:25 and later to c++14 Jul 24 18:31:50 sgw1: https://www.yoctoproject.org/download/yocto-project-14-poky-900 Jul 24 18:31:55 first result on google Jul 24 18:31:59 lpapp: what command did you use to get the failure: bitbake ??? Jul 24 18:32:03 poky dylan download Jul 24 18:32:08 I get no selectable list Jul 24 18:32:17 sgw1: check bugzilla, please. Jul 24 18:32:24 Hmm. Jul 24 18:32:58 lpapp: click on the downloads link and you will get the list Jul 24 18:33:21 bitbake core-image-minimal Jul 24 18:33:22 ERROR: ParseError at /home/lpapp/Projects/poky/meta/recipes-core/gettext/gettext_0.18.1.1.bb.BACKUP.13382.bb:8: unparsed line: '<<<<<<< HEAD' | ETA: 00:00 Jul 24 18:33:27 master is even more broken. :( Jul 24 18:33:46 lpapp: I just checked the bug, so you mean core-image-minimal since image minimal is not a valid target Jul 24 18:34:26 sgw1: yeah, that is a typo, and the crappy bugzilla does not allow edit. Jul 24 18:35:49 so yeah, master is more broken. Jul 24 18:35:57 is there any stable release for dylan? Jul 24 18:36:02 my last try is 9.0.1 Jul 24 18:36:18 lpapp, I have to go for a while lunch here, back later build is in progress Jul 24 18:36:30 I need to leave anyway Jul 24 18:36:33 it is getting 8 pm in here. Jul 24 18:37:17 lpapp, I hope to have something for you later my afternoon Jul 24 18:37:49 that would be appreciated. Jul 24 18:38:06 i see multiple eglibc recipes with git head as well Jul 24 18:38:30 kergoth mentioned the stuff is totally unmaintained in oe-core Jul 24 18:38:35 and they use meta-sourcery Jul 24 18:38:43 so perhaps it is a "not possible" fix. Jul 24 18:38:55 and the proper integration fix would come months later. Jul 24 18:38:57 that frankly scares me Jul 24 18:39:03 but I will stop being pessimistic. Jul 24 18:39:10 denzil seems to have worked. Jul 24 18:39:32 too bad I spent 2-3 days with it if it is now worse. Jul 24 18:40:28 wmat: right, so it is probably not fixed in 9.0.1 either Jul 24 18:40:33 although I am trying, just in case ... Jul 24 18:41:16 lpapp: that parse error is because its parsing the output of a merge, delete those files Jul 24 18:41:39 what worries me is that it seems there is no QA gate for external toolchains Jul 24 18:41:41 both the filename and the line its failing to parse tell you its the output from a merge conflict Jul 24 18:41:51 rburton: there is no any merge. Jul 24 18:41:55 it is a fresh clone/pull. Jul 24 18:42:15 no QA toolchain because denzil worked, same stuff got broken by dylan. Jul 24 18:42:21 there is no proper regression test. Jul 24 18:42:27 which again, makes me unsafe about using Yocto Jul 24 18:42:34 lpapp: "/home/lpapp/Projects/poky/meta/recipes-core/gettext/gettext_0.18.1.1.bb.BACKUP.13382.bb" Jul 24 18:42:38 merge conflict Jul 24 18:42:59 rburton: well I just cloned and pulled. Jul 24 18:43:03 it can hardly my mistake. :) Jul 24 18:43:32 ok, lets check git Jul 24 18:43:36 what revision have you checked out? Jul 24 18:43:55 latest Jul 24 18:43:56 master HEAD Jul 24 18:44:01 I also mentioned in the bugreport. Jul 24 18:44:12 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/gettext Jul 24 18:44:22 i don't see a file called gettext_0.18.1.1.bb.BACKUP.13382.bb Jul 24 18:44:25 so its local to you Jul 24 18:44:32 yeah, same issue with 9.0.1 Jul 24 18:44:45 its a merge confict which bitbake is attempting to parse Jul 24 18:44:47 delete it Jul 24 18:44:58 rburton: well I deleted the whole repository Jul 24 18:44:58 do a git status and check there's nothing else sitting around like that too Jul 24 18:45:02 and I am cloning a brand new stuff Jul 24 18:45:10 * rburton -> dinner/jog/etc Jul 24 18:45:31 phew, clone is extremely slow. Jul 24 18:46:51 * lpapp -> dinner/cycling/etc Jul 24 18:57:57 sent out an rfc about some read-only-rootfs and tmpfiles bits to oe-core list, would appreciate comments/thoughts before i take any further steps with it Jul 24 19:14:07 wmat: what error did you get with the wrong toolchain? Jul 24 19:15:00 djszapi: I can try it again if you like, buy I can't remember now Jul 24 19:15:09 please do if you can. Jul 24 19:15:36 but why, as it's not the same toolchain you're using? Jul 24 19:16:01 and I set the local.conf file to my 'wrong' toolchain as well Jul 24 19:17:13 fwiw, with master HEAD and the same toolchain as you, I get 3 errors regarding multiple eglibc recipes and 1 error regarding do_install trying to cp to a nonexisting location Jul 24 19:19:00 I really recommend using meta-sourcery with current sourcery g++ toolchains. it's 100% known working, used by me and others all day every day, and is fully supported by us Jul 24 19:19:11 wmat: I missed it, I guess. Jul 24 19:19:27 it's also part of the mentor embedded linux commercial product Jul 24 19:22:56 lpapp: exact same errors. 3 eglibc issues, and 1 issue with a missing location Jul 24 19:23:21 lpapp: I'm done with this now. I'd try meta-sourcery. Jul 24 19:24:26 we moved to a separate layer because it was the only way to avoid having tuning argument overrides in the tcmode file, as there are certain sourcery-only tuning arguments that hae to be used in ertain contexts to ensure the correct multilib sysroot is used Jul 24 19:24:42 wmat: issue with what? Jul 24 19:24:52 either we need to add the tuning overrides to the tcmode in oe-core, despite the ugliness, or it should just be removed, or pointed out as an example only, not to be used directly Jul 24 19:25:11 wmat: well, this stuff worked 1.5 years ago. Jul 24 19:25:20 I'm currently working on breaking up the external-toolchain recipe into individual recipes for each component, but it's not my current priority Jul 24 19:25:27 it looks awkward that some de-evolution is taking place about it. Jul 24 19:26:14 perhaps we should not use yocto, just a ready-made distribution. Jul 24 19:26:19 life might become a lot easier. Jul 24 19:26:37 currently there is no stable way of using a cross-compilation toolchain -> Jul 24 19:26:45 embedded developers are screwed mostly. Jul 24 19:27:15 hopefully the technology will become accessible enough in a few years to revisit the question. Jul 24 19:36:57 damn, oe-core is still missing a heck of a lot of systemd services Jul 24 19:40:44 wmat: have you actually tested that layer/ Jul 24 19:40:46 ? Jul 24 19:41:56 lpapp: no Jul 24 19:43:44 wmat: can you ask kergoth to unignore me to discuss the issue? Jul 24 19:49:55 lpapp: i'd probably stick to the mailing list and bug report for communication with him Jul 24 19:56:21 wmat: well, he does not reply. Jul 24 19:57:04 Hi I can't seem to find how to add a conditional dependency (based on the machine) Jul 24 19:57:18 lpapp: just keep trying, but also have patience Jul 24 20:00:02 wmat: to be honest, I do not care. Jul 24 20:00:10 if he wanted, he could have contributed to it. Jul 24 20:03:24 does anybody know how to add conditional dependencies based on the machine that is being built for? Jul 24 20:04:34 I want to add "gst-fsl-plugin" when I'm building for a freescale board (in this situation the I.Mx53 Jul 24 20:05:59 fenrig: DEPENDS_append_machinename = " gst-fsl-plugin" Jul 24 20:06:07 fenrig: note the leading space, that's important Jul 24 20:06:24 bluelightning: string concatenation? Jul 24 20:06:39 yep Jul 24 20:07:35 sgw1: I am here if you need any information from me. Jul 24 20:07:53 bluelightning: I also have a question about licenses when you built a recipe :) Jul 24 20:07:53 I am in a relaxing evening mood, but I will do my best. Jul 24 20:08:15 bluelightning: I understand you add the license file in the root of the layer (meta dir) Jul 24 20:08:34 bluelightning: Or is that a wrong assumption Jul 24 20:09:43 most recipes should be pointing to existing license file(s) or headers in the source of the thing, not things in the layer Jul 24 20:10:31 fenrig: right, what kergoth said Jul 24 20:42:52 lpapp: so the external toolchain issue is solved now, it seems there might still be some kind of variable binding bug though Jul 24 20:43:06 sgw1: how did you solve it? Jul 24 20:43:24 lpapp: I am asking you, you sent and email about MACHINE??= being set Jul 24 20:44:24 sgw1: that is another issue as written Jul 24 20:47:11 lpapp: I guess I mis-understood your email, sorry. Jul 24 20:49:37 sgw1: see the email I replied to. Jul 24 20:49:48 sgw1: note how I have not replied to the issue we discussed in here. Jul 24 20:51:31 sgw1: you might wanna invite kergoth to the bugreport. Jul 24 20:51:41 sgw1: he seems to claim that meta-sourcery is the way. Jul 24 20:51:49 and the one in oe-core is unsupported. Jul 24 20:52:04 it is an uncool regression, but that is how they seem to have made it. :( Jul 24 20:56:17 I feel like the new bitbake self restarting stuff doesn't cope well with SIGINT Jul 24 20:56:30 periodically i have to ^Z kill %1; pkill -f bitbake Jul 24 21:01:50 ls Jul 24 21:41:02 * kergoth notices in a systemd environment, alsactl itself handles save/restore of state, but in sysvinit, alsa-state does, and sighs Jul 24 21:41:09 * kergoth grumbles Jul 24 21:42:30 not sure what the cleanest way to resolve this is.. Jul 24 22:30:52 khem: you around to talk about the ppc floor() issue? Jul 25 00:56:36 hello. Anyone know how I might add a repository/channel to the smart package manager when I'm building an image. Jul 25 00:56:49 ? Jul 25 02:32:44 sgw1: yes. now I have few mins here **** ENDING LOGGING AT Thu Jul 25 02:59:58 2013