Wednesday, 2013-07-24

*** ant_home <ant_home!> has quit IRC00:04
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto00:05
*** JimBaxter <JimBaxter!> has quit IRC00:09
*** sameo <sameo!samuel@nat/intel/x-qsyfmyoziqmtdiqq> has quit IRC00:29
*** davest <davest!~Adium@> has quit IRC00:41
*** RagBal <RagBal!> has quit IRC00:48
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:50
*** RagBal <RagBal!> has joined #yocto00:55
*** _julian <_julian!> has joined #yocto00:59
*** _julian_ <_julian_!> has quit IRC01:02
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC01:02
*** mulhern <mulhern!> has quit IRC01:27
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:28
*** smartin_ <smartin_!> has quit IRC01:36
*** mulhern <mulhern!> has joined #yocto01:44
mulhernWhat provides all those perl-module-* packages?01:44
*** mulhern <mulhern!> has quit IRC01:59
*** silviof1 <silviof1!~silviof@> has joined #yocto02:15
*** Jefro <Jefro!> has quit IRC02:17
*** silviof <silviof!> has quit IRC02:18
*** silviof1 <silviof1!~silviof@> has quit IRC02:24
*** silviof1 <silviof1!~silviof@> has joined #yocto02:25
frankAnyone can tell me the difference between PACKAGE_INSTALL and IMAGE_INSTALL ?02:51
*** mitz <mitz!> has quit IRC03:59
*** mitz <mitz!> has joined #yocto04:01
*** mitz <mitz!> has quit IRC04:12
*** mitz <mitz!> has joined #yocto04:14
*** mitz <mitz!> has quit IRC04:34
*** behanw <behanw!> has quit IRC04:42
*** seebs <seebs!> has quit IRC04:45
*** seebs <seebs!> has joined #yocto04:47
*** mihai <mihai!~mihai@> has quit IRC04:47
*** mitz <mitz!> has joined #yocto04:52
*** davest <davest!Adium@nat/intel/x-dlyunrwrchgivtln> has joined #yocto05:06
*** agust <agust!> has joined #yocto05:08
*** Jefro <Jefro!> has joined #yocto05:15
*** davest <davest!Adium@nat/intel/x-dlyunrwrchgivtln> has quit IRC05:20
*** Jefro <Jefro!> has quit IRC05:25
*** nslu2-log_ <nslu2-log_!~nslu2-log@> has joined #yocto05:27
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC05:29
*** nslu2-log_ is now known as nslu2-log05:29
*** zerus <zerus!> has joined #yocto05:32
*** tor <tor!> has joined #yocto05:34
*** mihai <mihai!~mihai@> has joined #yocto05:36
*** zeeblex <zeeblex!apalalax@nat/intel/x-qlaydvncefhbgowr> has joined #yocto05:38
*** zerus <zerus!> has quit IRC05:38
-YoctoAutoBuilder- build #226 of poky-tiny is complete: Failure [failed Building Images Publishing Artifacts] Build details are at
*** runexe_ <runexe_!> has quit IRC05:40
-YoctoAutoBuilder- build #235 of nightly-intel-gpl is complete: Success [build successful] Build details are at
*** swex_ <swex_!~swex@> has joined #yocto06:00
*** zenlinux_ <zenlinux_!> has joined #yocto06:03
*** qiang__ <qiang__!~qiang@> has joined #yocto06:03
*** swex <swex!~swex@> has quit IRC06:04
*** zenlinux <zenlinux!> has quit IRC06:04
*** frank <frank!~qiang@> has quit IRC06:04
*** scottrif <scottrif!> has joined #yocto06:05
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:14
*** qiang__ <qiang__!~qiang@> has quit IRC06:15
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06:17
*** qiang__ <qiang__!~qiang@> has joined #yocto06:17
*** mitz <mitz!> has quit IRC06:25
*** mitz <mitz!> has joined #yocto06:35
*** mthalmei_away is now known as mthalmei06:42
*** mckoan|away is now known as mckoan07:07
mckoangood morning07:07
*** ka6sox is now known as ka6sox-away07:08
*** eballetbo <eballetbo!> has joined #yocto07:10
*** panda84kde <panda84kde!> has joined #yocto07:10
*** ant_work <ant_work!> has joined #yocto07:11
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto07:15
*** tbn <tbn!~tbn@> has joined #yocto07:19
*** tbn is now known as Guest9901107:20
-YoctoAutoBuilder- build #61 of minnow-lsb is complete: Success [build successful] Build details are at
*** TuTizz <TuTizz!~TuTizz@> has quit IRC07:23
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto07:23
-YoctoAutoBuilder- build #222 of nightly-mips is complete: Failure [failed Running Sanity Tests Building Images_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at
lpappis there anyone who can help me with external toolchains? I still did not move forward a bit.07:29
*** ivali <ivali!~ivali@unaffiliated/ivali> has joined #yocto07:31
-YoctoAutoBuilder- build #232 of nightly-x32 is complete: Failure [failed Running Sanity Tests] Build details are at
*** smartin <smartin!> has joined #yocto07:38
*** slaine <slaine!~slaine@> has joined #yocto07:40
*** shoragan <shoragan!~jlu@2001:6f8:1178:2:219:99ff:fe56:8d7> has joined #yocto07:42
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has joined #yocto07:42
*** qiang__ <qiang__!~qiang@> has quit IRC07:46
*** roric <roric!> has joined #yocto07:46
*** frank <frank!~frank@> has joined #yocto07:47
*** elmi82 <elmi82!> has joined #yocto07:47
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:52
*** sameo <sameo!~samuel@> has joined #yocto07:55
-YoctoAutoBuilder- build #75 of minnow is complete: Success [build successful] Build details are at
*** blitz00 <blitz00!stefans@nat/intel/x-ujnyqczvwfimodhe> has joined #yocto08:01
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto08:01
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC08:03
bluelightningmorning all08:08
lpappwhy cannot I interrupt the bitbake process with ctrl-c? :O08:09
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto08:12
lpappalso, it made my system super laggy that I pressed ctrl-z.08:13
*** zerus <zerus!> has joined #yocto08:18
*** honschu_ <honschu_!> has joined #yocto08:27
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto08:27
*** Daemon405 <Daemon405!> has joined #yocto08:28
*** belen <belen!Adium@nat/intel/x-ujhpkvutugyenvkm> has joined #yocto08:28
*** lpapp_ <lpapp_!> has joined #yocto08:28
*** tor_ <tor_!> has joined #yocto08:28
ivalikill solves it08:29
*** yzhao2_ <yzhao2_!~yzhao2@> has quit IRC08:29
*** lpapp <lpapp!> has quit IRC08:29
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC08:29
*** tor <tor!> has quit IRC08:29
*** pidge <pidge!> has quit IRC08:29
*** sgw_ <sgw_!> has quit IRC08:29
*** pidge <pidge!> has joined #yocto08:30
lpapp_ctrl-c should just work of course.08:30
lpapp_I consider it a serious bug.08:30
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC08:30
*** scottrif <scottrif!> has left #yocto08:31
lpapp_so I am more interested in fixing the bug.08:31
lpapp_rather than working around, and have it non-working for the next user.08:31
*** yzhao2 <yzhao2!~yzhao2@> has joined #yocto08:33
*** sgw1 <sgw1!> has joined #yocto08:33
*** Umeaboy <Umeaboy!> has joined #yocto08:34
*** lpapp_ <lpapp_!> has quit IRC08:37
*** Crofton <Crofton!> has quit IRC08:45
*** ivali <ivali!~ivali@unaffiliated/ivali> has quit IRC09:01
*** JimBaxter <JimBaxter!> has joined #yocto09:16
*** Umeaboy <Umeaboy!> has quit IRC09:17
*** Umeaboy <Umeaboy!> has joined #yocto09:19
*** belen <belen!Adium@nat/intel/x-ujhpkvutugyenvkm> has quit IRC09:22
*** belen <belen!~Adium@> has joined #yocto09:23
*** silviof1 is now known as silviof09:30
*** sameo <sameo!~samuel@> has quit IRC09:33
*** belen <belen!~Adium@> has quit IRC09:41
*** belen <belen!Adium@nat/intel/x-iaawovgiocbyaxil> has joined #yocto09:45
*** belen <belen!Adium@nat/intel/x-iaawovgiocbyaxil> has quit IRC09:50
*** belen <belen!~Adium@> has joined #yocto09:59
*** lpapp <lpapp!~lpapp@> has joined #yocto10:00
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto10:07
ereno/ morning all10:08
lpappanyone got a clue for this bitbake issue?
rburtonlpapp: 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.10:13
rburtonlpapp: did you compare the files?10:14
lpapprburton: I waited 20 minutes.10:15
lpapprburton: yes10:15
rburtonlpapp: so, did you resolve any differences and set the version in your conf/bblayers.conf to match the sample?10:16
lpapprburton: ?10:17
lpappthere are no differences other than expected.10:17
rburtonlpapp: and the versions match?10:18
rburtonlpapp: do a find for other bblayers.conf.sample files10:20
rburtonmaybe your layer has one in?10:20
lpapprburton: ?10:20
ndeciirc VERSION is 5 in dylan.10:21
lpappndec: ?10:21
rburtonlpapp: search for other files in your tree called bblayers.conf.sample, as bitbake it clearly not looking at the file you're comparing.10:22
rburtonlpapp: my suspicion is that your layer has a bblayers.conf.sample too10:22
lpappndec: surely, it is not?10:22
lpapprburton: unfortunately, nope.10:23
lpappfind ./ -name bblayers.conf.sample10:23
lpappthis is the only result.10:23
rburtonhow odd.10:23
lpappit is !10:24
rburtonwhat happens if you wipe away your bblayers and re-run oe-init-build-env?10:24
lpappit is with wiping away10:24
lpappbut I can do it again.10:24
rburtoni bet your distro is setting LAYER_CONF_VERSION itself10:28
lpappthat means what?10:28
rburtonthats the number that the layer version is compared against10:29
rburtonif your distro is forcing it to something that it shouldn't be, you'll get this10:29
rburtondoes your layer define a distro?10:29
lpappsince it is a semi-distro layer10:30
lpappweird thing is that, I do not get such issues with denzil though.10:30
rburtonof course10:30
rburtonbecause the version is older then10:30
lpapp../meta-foo/conf/ff-local.conf:102:DISTRO ?= "poky"10:31
lpapp../meta-foo/conf/foo-local.conf:102:DISTRO ?= "poky"*10:31
lpapps/poky/foo/ maybe?10:31
lpappas I have this:10:31
lpappin any case, the error message is not so intuitive10:31
lpappit would be nice to improve it.10:31
rburtonwhat distro does your local.conf specify?10:32
rburtonits best not to change the value of DISTRO in several places10:33
rburtonand have a look in your distro conf files, as i said i expect it's setting LAYER_CONF_VERSION10:33
lpappas I said, it is not setting.10:34
lpapp"grep -rn LAYER_CONF_VERSION meta-foo" yields nothing.10:34
lpappchange the distro in several places mean what?10:34
rburtonright, you didn't say that.10:34
lpappI did. ;-)10:34
rburtonyou're setting DISTRO in multiple places10:34
lpappI only replicate poky.10:34
lpappI have a foo10:34
lpappand foo-tiny10:34
rburtonjust set it in your local.conf10:34
lpappsimilarly to poky.10:34
lpappinteresting, I have not written the LAYER_CONF_VERSION10:35
lpappthen I just intended. :)10:35
lpappas I checked right after you wrote.10:35
rburtonset LCONF_VERSION in your bblayers.conf to 510:35
rburtonbet that makes it work10:36
*** slaine <slaine!~slaine@> has quit IRC10:36
lpappso, probably I should not have foo-local.conf in meta-foo/conf10:36
lpappas meta-yocto does not seem to have that either.10:36
*** slaine <slaine!~slaine@> has joined #yocto10:36
rburtonyeah, drop it one10:36
lpappbut ... but, it is 6.10:36
lpappwhy ?10:36
rburtonyes, so change it to 510:37
* lpapp is lost10:37
lpappthat is meta-yocto from dylan10:37
lpappit is 6 in there.10:37
rburtonlets start with "its moaning when the value is 6, so lets change it to 5"10:37
lpappwhy ?10:37
rburtonbut importantly, you're distro isn't poky10:37
rburtonso don't copy poky files.10:37
lpappwell, it is almost poky10:37
lpappand I still do not understand why 6 should not work.10:37
rburton6 is the layer conf version set by poky10:38
lpappin any case, I will drop meta-foo/conf/foo-local.conf then10:38
rburtonif you're not running poky, you'll get the default of 510:38
lpappwe probably do not need it.10:38
rburton(that bump was a poky-specific change)10:38
lpappok, nice trap then.10:38
rburtonyou can drop meta-yocto entirely if you're not using poky, as it's actively causing harm10:38
lpappno no10:39
lpappit is better to keep it as upstream has.10:39
lpappI mean it is easier to update stuff10:39
lpappI will try again: can I drop meta-foo/conf/foo-local.conf or it has any significance?10:39
lpappapparently, me predecessor put it there.10:40
lpappbut I would not know why it is neede.10:40
rburtonno idea, never seen that filename style before.10:40
lpapperr... it is not about the file name.10:40
lpappit is about the concept having a local.conf inside the mylayer/conf10:40
lpapprather than build/conf/local.conf10:40
rburtonwell, you said foo-local.conf10:40
rburtona local.conf inside a layer would be wrong10:41
lpappit is probably a local.conf with custom stuff.10:41
lpappand what about site-foo.conf inside the layer?10:41
lpappshould that also be gone?10:41
rburtoni guess inside the layer is somewhere to put it10:42
rburtonput a site.conf wherever you want10:42
lpappso the bblayers.conf is generated with 6 because it generates meta-yocto by default?10:42
rburtonno, because it found a bblayers.conf.sample in meta-yocto10:43
rburtonand assumed that that's the one you wanted10:43
lpappyeah, so renaming to site.conf makes sense10:43
lpappespecially since it is literally the sample.10:43
lpapprburton: how can I override that?10:43
rburtonif you're not using poky you can wipe those layers entirely10:43
lpappor how can I make 6 work?10:43
rburtonor just keep the bsp layer10:43
rburtonyou make the 6 work by using poky10:43
lpappok, it will be weird to check the build folder in.10:44
rburtonyes, very weird10:44
rburtondon't do that10:44
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto10:44
lpappthat is the only solution for upgradability?10:44
rburtonjust remove meta-yocto* from your setup, you don't need it10:44
lpappI mean, clearly, it should be fixed once, and then shared.10:44
*** mulhern <mulhern!> has joined #yocto10:44
rburtonas you've said, your distro isn't poky.10:44
lpappwhich means, build/conf/local.conf ends up in the repository10:44
lpappah, sorry.10:45
lpappthat is not bblayers.conf10:45
lpappwell well ....10:45
lpappit is kinda sucky then.10:45
lpappwell removing poky is also suboptimal.10:45
ant_worklpapp: why don't you customize starting from the core?10:45
lpappbecause then it will be more work to upgrade upstream poky.10:45
lpappoh, and btw10:45
lpappwe do need poky.10:45
ant_workI'm working with distro-less defaults and all seems ok10:46
panda84kdehi otavio10:46
lpappwe only have hardware adaptation in our layer, mostly.10:46
lpapprburton: we do not wanna reinvent the wheel.10:46
rburtonlpapp: but your setting the distro to something else, so what do you need "poky" for?10:46
ant_worklpapp: it is easy if you start adding to
lpapprburton: for the whole stuff10:46
lpapprburton: every package pretty much should come from poky.10:46
lpappreplicating the poky layer in my layer would not make much sense.10:46
lpapprburton: so my distro is poky + minor custom stuff10:47
ant_workpoky or oe-core?10:47
rburtonlpapp: are you actually aware of what recipes poky adds over oe-core?10:47
rburton1) a changed splashscreen 2) a tiny configuration for busybox.10:47
rburtonlpapp: if you want to "inherit" poky, then your distro.conf should require conf/distro/poky.conf10:49
rburtonso you get poky and then can change it10:49
rburtonthat will also solve your conflicting version problem10:49
rburton(that's what guacamayo does, inherits poky and changes a few values)10:49
mulhernI'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?10:50
mulhernI see packages that DEPEND on some perl-module-.*. What provides these modules?10:50
lpapprburton: and busybox10:56
rburtonlpapp: yes, a tiny configuration for busybox10:56
lpapprburton: we have our own custom kernel10:57
lpappour own busybox10:57
lpappour own splash screen10:57
lpappperhaps then poky is not much of value for us10:57
*** zeddii <zeddii!~ddez@> has quit IRC10:57
rburtondepends how much you want to change.  poky is a good starting point, or you can start from scratch.10:58
lpapprburton: I guess poky would make more sense if we could upstraem our changes.10:58
lpappkernel, busybox, etc10:58
*** zeddii <zeddii!~ddez@> has joined #yocto10:58
rburtonthe 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.10:58
lpappI think the end goal should be poky.10:58
lpappbut since we have custom patches for pretty much everything in poky.10:59
rburtonwell, having your own distro is fine, it lets you make changes specfic to your distro.10:59
rburtonjust either inherit poky, or remove the meta-yocto layers10:59
ndeci 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.10:59
ndecso if you don't use poky, but download 'poky' (as opposed to oe-core), you probably want to tweak that.11:00
ndecbut, if you have your own distro , you might want to provide your own template conf files directly. that's what i do.11:00
ant_workremembering that distro/defaultsetup.conf is providing valid defaults11:02
rburtonpoky does do more qa, iirc11:02
*** swex__ <swex__!~swex@> has joined #yocto11:02
-YoctoAutoBuilder- build #194 of nightly-fsl-arm is complete: Success [build successful] Build details are at
mulhernUmmm, can I be a squeaky wheel and get a little grease?11:05
ndecrburton: 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?11:05
ant_workit's just matter of changing local.conf11:05
*** swex_ <swex_!~swex@> has quit IRC11:06
mulhernAlso, 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?11:06
rburtonndec: its just distro vars, yeah. set them wherever you want.11:06
ant_workso the Distro abstraction is useful because is stable and commercially affordable11:06
ant_workbut is not necessary11:06
rburtonmulhern: not really. there was someone who'd packaged up about 80 modules from cpan though...11:07
rburtonmulhern: assuming your modules come from cpan, metadata boilerplate + inherit cpan should be close to all you need11:07
rburtonbluelightning: can you remember who was packaging vast amounts of perl?11:08
mulhernOh, 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.11:08
bluelightningrburton: that was Stygia11:08
ant_workand erbo11:08
bluelightningant_work: ah ok, didn't know he was also doing that11:09
bluelightninghope they are talking to eachother :)11:09
rburtonpackage deathmatch!11:09
mulhernWhen 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.11:12
rburtonmulhern: got one specifically?11:13
rburtonhm maybe perl magically provides those for the modules it contains11:13
-YoctoAutoBuilder- build #193 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at
lpapprburton: so poky or not?11:16
rburtonlpapp: personally i like inheriting poky, but it depends on how much you want to change the distro variables.11:16
mulhernI see a recipes with RDEPENDS containing a whole list: perl perl-module-text-wrap perl-module-getopt-long ….11:17
rburtonmulhern: right, a lot of those are the subpackages that perl splits into11:17
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC11:18
mulhernOK, now I see that in
rburtonmulhern: for reducing installed size, perl (and python) split their library modules into as many packages as possible11:21
rburtonso you can just install what is needed11:21
rburtonthe downside of this is that there are ~fifteen quadzillion packages for each11:21
mulhernrburton: That's perfectly sensible.11:22
*** Daemon405 is now known as Daemon40411:23
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto11:23
mulhernBut, 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.11:23
rburtoni suspect the names are generated automatically11:25
rburtonand that is only for manually additions11:25
lpapprburton: what distro variables?11:25
rburtonmulhern: yes, has a populate_packages_prepend() that does do_split_packages().  that chops each module directory into a package with the right name.11:26
rburton"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."11:27
rburtonthat's a slightly better error message11:27
rburtonlpapp: well, what what your distro setting so far?  DISTRO_FEATURES, the QA checks, global compilation flags, etc are all distro variables.11:27
lpapprburton: DISTRO_FEATURES_append = " largefile --disable-zlib"11:28
rburtonthat's not how DISTRO_FEATURES works11:28
rburton(specifically, --disable-zlib doesn't make sesnse there)11:29
lpappwhat makes sense there then?11:30
lpappanyway, that is all we set.11:30
lpappI still need to understand whether I should go for poky, or not.11:30
rburtonits up to you, really.11:30
lpappobviously, but I need to understand what that decision is based on.11:30
lpappand yes, I mean technical considerations.11:30
*** Net147 <Net147!> has joined #yocto11:31
rburtonit entirely comes down to how much customisation you expect to make to the distro11:32
rburtonyou can start with inheriting poky and and switch to your own distro entirely if you want in the future, whatever.11:32
rburtonjust be aware that --disable-zlib in DISTRO_FEATURES isn't doing anything11:32
rburtonthe list of valid distro features is in the documentation11:32
lpappas far as I can tell, poky is really not much11:34
lpapp95% is in oe-core.11:34
rburtonoh, more than that11:34
rburtonits 99% policy in poky.conf11:34
rburtona new splash screen and the poky-tiny confguration for busybox.11:34
lpappwhat is the point of poky then?11:34
lpappIt does not contribute much11:34
lpappmost of the stuff is done by oe-core.11:35
rburtonand some more BSPs11:35
rburtonits a reference distribution11:35
rburtona known-working component that is tested by QA11:35
*** synthnassizer <synthnassizer!~quassel@> has quit IRC11:35
lpappthe problem is that we have own linux adaptation changes (huge patches)11:35
lpappown patches against busybox.11:35
lpappown splash screen11:35
lpappso not much left in poky we could actually reuse.11:36
lpapptiny-init maybe?11:36
rburtonthat's for poky-tiny, where by "init system" you mean "busybox sh"11:36
*** synthnassizer <synthnassizer!~quassel@> has joined #yocto11:36
rburtonas i said, poky is mostly policy in poky.conf11:36
rburtonyou can happily inherit and tweak that, or start from the defaults in oe-core.11:37
rburtonpeople do both, there is no "right" answer11:37
lpapphappily is a bit exaggeration11:38
lpappit has caused a headache for half a day11:38
lpappwith the version thingie and wrong error message.11:38
rburtonsure, i'm writing the commit message now to clarify that error11:39
lpapprburton: how would I solve it with inheriting anyway?11:41
lpappI would still need to roll back to version 5?11:41
rburtonthe problem is that oe-core and poky have different layer versions11:41
rburtonyou're using poky templates because you're using the poky tarball, but not using poky11:41
rburtonso 5!=611:41
lpappinheriting poky means we cannot have our own distro definition? o_O11:42
rburtonsure you can11:42
* lpapp is lost then11:42
lpapphow can I make 6 work then with inheritance?11:43
rburtonrburton: lpapp: if you want to "inherit" poky, then your distro.conf should require conf/distro/poky.conf11:43
rburtonrburton: so you get poky and then can change it11:43
rburtonrburton: that will also solve your conflicting version problem11:43
rburtonrburton: (that's what guacamayo does, inherits poky and changes a few values)11:43
lpappis that something people often do?11:45
rburtonsome.  others don't use a distro. others roll their own distro from scratch.11:45
*** ivali <ivali!~ivali@unaffiliated/ivali> has joined #yocto11:46
lpappfrom scratch means based upon oe-core?11:47
lpappis there an example for this require thingie?11:51
-YoctoAutoBuilder- build #184 of nightly is complete: Success [build successful] Build details are at
rburtonlpapp: my line was literally an example, but is the source of what i was saying.  that's a distro based on poky.11:53
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto11:54
*** slaine <slaine!~slaine@> has quit IRC12:00
lpapprburton: WARNING: Unable to get checksum for foo SRC_URI entry authorized_keys: file could not be found12:01
lpapprburton: WARNING: Unable to get checksum for foo SRC_URI entry bar: file could not be found12:01
lpappthis was not a problem with denzil12:01
lpappthis enforcement was introduced later?12:01
rburtonsomething probably changed12:02
rburtonshow some context and we can help12:02
lpappnothing changed in our package.12:03
lpappoh, btw, we have custom user space tools as well in meta-foo12:03
lpappit is called recipes-foo12:03
lpappthat kinda yields a reason for an own distro, too?12:03
rburtona distro is mostly policy, global cflags, distro-features, etc.12:04
lpappadditional packages are distro features12:07
lpappwhich are not present in one, but does present in another.12:07
*** sveinse <sveinse!~chatzilla@> has joined #yocto12:07
lpappthose are distro features.12:07
rburtonthey are not "DISTRO_FEATURES"12:08
rburtonwhich is what i meant12:08
lpappSRC_URI = "file://bar \12:08
lpappin foo_foover.bb12:08
lpappwe cannot upstream our custom commercial utils.12:08
rburtonsure, of course not12:08
lpappso it is very unlikely to end up in poky12:08
rburtonyou're not forced to either, yocto is all MIT12:09
lpappin which case, not having our own distribution is kinda moot.12:09
lpappwhat shall I run for bitbake to return the checksum for me?12:09
sveinseI'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.12:10
lpapp"bitbake foo" did not help.12:10
rburtonlpapp: you shouldn't need checksums for file:// uris12:10
lpappsveinse: the former.12:10
rburtonso what's the actual src_uri?12:10
sveinseBecause if its the former (which I presume), you need a meta- for the BSP and another meta for describing the entire system, right12:10
lpapprburton: ?12:10
lpappsveinse: yeah12:10
rburtonlpapp: you shouldn't need checksums for file:// URIs12:11
rburtonlpapp: so what's the full SRC_URI?12:11
ndecbluelightning: hehe... i was able to do what i wanted in bblayers.conf. BBLAYERS += "${@' ${LL} ' if os.path.isfile('${LL}/conf/layer.conf') else ''}" works.12:11
sveinselpapp: are there any yocto OOB examples how this top-level is setup?12:11
lpappI cannot stop bitbake again. :(12:11
lpappthis is annoying, really.12:11
lpappctrl-c should just work.12:11
lpappany hackaround?12:11
ndeci got the idea from the guacayamo conf file that was just posted above...12:11
rburtonlpapp: as i said earlier, there's a race.  control-z then kill works.12:11
lpappis there a shortcut to clean up the build folder except the already set config files?12:14
lpappto avoid this command manually:12:14
rburtonlpapp: that file doesn't match your errors?12:14
lpapprm -rf bitbake.lock cache downloads sstate-cache tmp12:14
lpapprburton: ?12:14
lpapprburton: that is the file.12:14
lpappreferring to bar.12:14
rburtonmaybe it just can't find the file and will later ignore doing a checksum12:15
rburtonthere was a change to the file lookup, where is it?12:15
rburtonwhen it was changed was almost zero fallout, but you may have used a bad place.12:15
rburton(i.e. where is bar in relation to the recipe)12:15
rburtonif its alongside it, don't do that.  put it in files/ or foo/12:16
ndeclpapp: you should remove WORKDIR from LIC_FILES_CHECKSUM no?12:16
lpapprburton: beside it.12:16
lpapprburton: why ?12:16
rburtonit causes problems12:17
rburtonput files in a directory12:17
rburtoncall it files, or $PN, or $PN-$PV12:17
rburtonalongside working was luck as iirc that wasn't documented anywhere12:17
lpapprburton: well, in an ideal world, it should not cause problems, I believe.12:17
rburtonlpapp: well, it caused problems.  if you're curious you can dig out the commit and read the rationale.12:18
lpappndec: that sounds like a good idea to me...12:18
lpapprburton: ok, I will ignore the warning for now.12:18
lpappthat recipe, as you can see, is just about installing a file.12:18
lpappa conf file, pretty much.12:18
lpappwill bitbake clean or so help me with the other issue?12:19
rburtonlpapp: just rm -rf tmp12:19
rburtonkeep downloads and sstate-cache unless you know you've managed to taint your cache12:19
lpappshould not there be an option doing that?12:20
lpappndec: I removed.12:20
lpapprburton: I moved stuff into files12:20
lpappalthough I am still getting this:12:21
lpappWARNING: Unable to get checksum for foo SRC_URI entry bar: file could not be found12:21
lpappWARNING: Unable to get checksum for root-ssh-authorized SRC_URI entry COPYRIGHT: file could not be found12:21
lpappWARNING: Unable to get checksum for foo SRC_URI entry COPYRIGHT: file could not be found*12:21
lpappSRC_URI = "file://files/bar \12:22
bluelightninglpapp: file://bar not file://files/bar12:22
lpappbluelightning: ?12:23
lpappwe have just discussed to move into files.12:23
rburtonyes, move the files, the src_uri references were find12:23
rburtonbitbake will hunt around for the right ones12:24
lpappCOPYRIGHTS should also move to files?12:24
bluelightninglpapp: yes, files/ is already in the search path for a recipe by default, so you don't need to specify it12:24
rburtonby default as discussed you can use files, $PN, or $PN-PV.12:24
rburtonso you can have files for all recipes in that directory, then files for a specific recipe, and other files for specific versions of specific recipes12:24
lpappyeah, I know12:24
lpappbut what about COPYRIGHT?12:24
lpappeverything is supposed to go into those except
lpappwhich is supposed to go into the package root?12:25
lpappWARNING: Variable package_do_filedeps contains tabs, please remove these (/home/lpapp/Projects/Yocto/poky-dylan-9.0.0/meta-foo/recipes-core/busybox/
lpappthat warnings must have been introduced after denzil, too.12:26
rburtonlpapp: yes12:26
rburtonpython functions  need to be four-space indented12:26
rburtonmight be easier to re-base your patches against our busybox with a bbappend?12:27
JaMabluelightning: Hi, is meta-openembedded-contrib/log/?h=paule/mosh ready to be merged?12:27
lpapprburton: nope, it is really custom12:27
lpappnot expected to be upstreamed.12:27
lpappis there a reformatting tool?12:27
bluelightningJaMa: if people are happy with where the recipes are going, yes (and I think they are)12:27
*** mthalmei is now known as mthalmei_away12:27
JaMabluelightning: 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 merge12:27
lpappsome astyle thingie?12:27
rburtonlpapp: sadly not12:28
JaMarburton: test-dependencies run finished today (finally), I'm sending few more patches with deps discovered in smaller builds (with less layers)12:28
rburtonlpapp: search/replace on "\t" to "    " should work nicely though12:28
rburtonJaMa: woo12:28
lpapprburton: there is no tab in that file fwiw.12:29
bluelightningJaMa: great job btw, thanks for going through that exercise and fixing up the issues found12:29
lpapprburton: again, poor error message.12:29
lpapprburton: should spot the line?12:29
rburtonlpapp: does it do an include?12:29
lpapprequire you mean?12:29
rburtonrequire or include12:29
lpappyes, first line12:29
rburtoncheck that file12:30
lpapprequire busybox.inc12:30
rburtoniirc the syntax check happens after the parse, so it doesn't know that12:30
lpappwell, it should report the right file anyway12:30
lpappeven if not line number12:30
lpappI imagine this would have been a headache for me without help12:30
lpappI would not really have known what the problem is12:31
rburtonlpapp: patches welcome12:31
rburtonit tells you what python function has the tabs in12:31
lpapprburton: I welcome them, too. ;)12:31
rburtonso this isn't exactly rocket science12:31
lpapprburton: function is not enough12:32
lpappI really need file.12:32
rburtondude, grep12:32
lpappand even line number12:32
rburtonthe *entire function*12:32
rburtonits not just one tab, the entire function needs re-indenting12:32
* rburton -> food12:33
JaMarburton: bluelightning: what do you think about backporting those fixes to dylan after some time in master?12:33
lpapprburton: well, it could list all the offending lines.12:33
ant_worklpapp: this only happens to the developers and he'd immediately notice it on next bitbake run12:33
bluelightningJaMa: if they're applicable to the versions in dylan, I don't see why not12:33
JaMarburton: 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)12:33
bluelightningJaMa: ok, thanks12:34
lpappant_work: ?12:34
rburtonlpapp: 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.12:34
*** _Lucretia__ <_Lucretia__!~munkee@> has quit IRC12:34
ant_workif you are bitbaking your recipe you'll see you did some mistake12:34
JaMabluelightning: ok I'll send pull-request after few weeks if nobody finds any issue in master12:34
lpappant_work: again, I would not have known without help.12:35
lpappI would not have looked into inc files.12:35
*** mulhern <mulhern!> has quit IRC12:36
lpapprburton: bluelightning
bluelightninglpapp: are you adding your own busybox recipe solely for changing the config?12:44
lpappbluelightning: no12:45
lpappbluelightning: we have custom patches to core utils.12:45
bluelightninglpapp: 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 recipe12:45
lpappbluelightning: ?12:46
bluelightninglpapp: 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 need12:46
bluelightninglpapp: "This usually means one provides something the other doesn't and should."12:46
lpappbluelightning: no no12:47
lpappthe patches are not meant to be updated.12:47
lpappthey are quite domain specific12:47
bluelightningI'm not making any reference to upstreaming12:47
lpappI am doing,12:47
lpappyou 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.12:48
bluelightninglpapp: yep, and I'm not contradicting that12:48
lpappbluelightning: ?12:48
bluelightninglpapp: I'm suggesting that rather than an additional busybox recipe, use a busybox bbappend to achieve the same thing12:49
*** _Lucretia__ <_Lucretia__!~munkee@> has joined #yocto12:49
bluelightninglpapp: that way you avoid some of the compatibility problems when you upgrade, like the one you are hitting now12:49
lpappbluelightning: ?12:49
lpappthe whole idea was to maintain it on our own12:49
bluelightningyes, and that won't change by using a bbappend12:50
lpappif I use bbappend I *am* forced to update my change.12:50
lpappeven though when it is totally unreasonable due to our milestone.12:50
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-wzqcdggrptpydfjq> has joined #yocto12:51
lpappso, I do not feel comfortable at all without external force.12:51
lpappthat is exactly the reason why I would like to maintain my version12:51
lpappwithout any explicit requirement to upgrade it.12:51
lpappso how can I fix this situation with my own recipe, et cetera?12:54
melonipoikai am having some problems with arago-oe-dev, hope someone could help :-)12:56
melonipoikaI added this layer to my bblayers.conf12:56
lpappbluelightning: ^12:56
melonipoikabut when buliding the image, i get this error:12:56
melonipoikaERROR: ParseError at /home/jose/mcsdk/sources/arago-oe-dev/classes/java.bbclass:8: unparsed line: 'datadir_java ?= ${datadir}/java'12:57
bluelightninglpapp: 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 required12:57
bluelightningmelonipoika: looks like the value is missing enclosing quotes12:58
lpappbluelightning: could you please be a bit more specific12:58
lpappdylan uses exactly the same upstream version.12:59
bluelightninglpapp: compare the two files to see what the difference is12:59
melonipoikathis is how the line 8 looks like12:59
melonipoika# Jar location on target12:59
melonipoikadatadir_java ?= ${datadir}/java12:59
lpappbluelightning: which files?12:59, .bb, etc?12:59
bluelightninglpapp: busybox_xyz.bb12:59
bluelightninglpapp: and the inc files12:59
bluelightningmelonipoika: I think that needs to be datadir_java ?= "${datadir}/java"13:00
lpappbluelightning: they have a shitload of patches.13:00
lpappagain, I think bitbake has a very poor error reporting.13:00
melonipoikabluelightning, thanks, will try it'13:00
lpappit should write exactly what the problem is.13:00
lpappthat error message is just as vague as the previous ones.13:01
lpappperhaps for 10.0 the error reporting system should be revamped.13:01
bluelightninglpapp: 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 thrown13:02
lpappbluelightning: that is what I mentioned revamping.13:02
lpappthe architecture should make sure you do have the information.13:03
*** frank_fighting71 <frank_fighting71!~frank@> has joined #yocto13:21
*** JimNH2 <JimNH2!> has quit IRC13:21
frank_fighting71How should I add libnfsidmap package to rootfs using IMAGE_INSTALL ?13:23
frank_fighting71libnfsidmap package has been renamed to libnfsidmap0 by debian.bbclass13:23
bluelightningfrank_fighting71: in IMAGE_INSTALL you use the name before the renaming, i.e. libndfsidmap13:24
bluelightningfrank_fighting71: er, I meant libnfsidmap13:24
frank_fighting71bluelightning: I did as you said, but I met do_rootfs error13:25
bluelightningfrank_fighting71: please pastebin it13:25
frank_fighting71indicating libnfsidmap not found in the feed13:25
*** behanw <behanw!> has joined #yocto13:28
*** davest <davest!~Adium@> has joined #yocto13:31
bluelightningfrank_fighting71: hmm, that works here with ipk... which version of the build system are you using?13:34
frank_fighting71how to check the version ? I git clone poky repo several days ago.13:36
sveinsewhats special about the yocto kernel compared to vanilla kernel?13:36
frank_fighting71ipk also also rename the lib package name ?13:36
bluelightningfrank_fighting71: oh so you're using master... FWIW, my test was with master so it should work...13:37
sveinseI 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?13:37
*** sameo <sameo!~samuel@> has joined #yocto13:38
bluelightningsveinse: you should be able to use your own kernel config if that's what you prefer13:38
sveinsebluelightning: ok. Which brings me to my first question: Why a yocto kernel?13:39
lpappbluelightning: any clue what the problem might be?13:42
bluelightninglpapp: have you compared the recipes and inc files?13:43
lpappbluelightning: it is a lot of diff13:43
lpappI honestly have no clue what can cause issues for oe-core13:43
lpappand since it is not verbose, I would need to look into the oe-core code13:43
lpappunless someone here can help me.13:43
bluelightninglpapp: perhaps you would be best off using the new recipes as a basis and putting your patches into that13:43
lpappit should not be a problem at all to ship your own version.13:43
lpappbluelightning: in the short term, yes.13:44
lpappbluelightning: for long term thinking, not really, no.13:44
bluelightninglpapp: so what is it that you want?13:44
lpappand I am considering yocto for long term, so I need to understand why it complains.13:44
lpappI cannot just do things blindly.13:44
lpappI need to understand what is going on.13:44
lpappand if error reporting is not helpful.13:44
bluelightninglpapp: then, you need to look at and understand the differences13:45
lpappand no one can help here, I will have hard time, but I will need to look into the code.13:45
rburtonlpapp: have a look at the busybox in oe-core and see what it PROVIDES13:45
rburtonthen compare that with your own recipe13:45
bluelightningand RPROVIDES13:45
rburtonyeah, and that13:45
rburtonas the message says, one of them provides something the other doesn't, so it needs to build both to resolve all dependencies.13:45
bluelightningsveinse: 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 development13:46
lpappthere is no such a thing as PROVIDES in the recipe though.13:46
lpappnor in the .inc13:46
bluelightninglpapp: any difference in PACKAGES will also constitute a difference in effective PROVIDES13:46
bluelightningsveinse: dvhart or zeddii are your best bet for a proper answer to that question13:47
sveinsebluelightning: 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 work13:47
rburtonsveinse: 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.13:48
ant_worksveinse: about yocto kernel the patchset is 'public' but the advantage you get are 1) is maintained 2) free stable patchsets, 3) almost zero maintenance13:48
*** munch <munch!> has joined #yocto13:48
denixare people now trying to add random stuff to their bblayers.conf?13:49
denixmelonipoika: why are you even adding arago-oe-dev to yocto config?13:49
lpappgrep PACKAGES -rn ../meta/recipes-core/busybox/13:50
lpapp../meta/recipes-core/busybox/ =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev ${PN}-hwclock"13:50
lpapp../meta/recipes-core/busybox/ = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev ${PN}-hwclock"13:50
lpapp../meta/recipes-core/busybox/ = "${PN}-syslog"13:50
sveinsepoint 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.13:50
lpappgrep PACKAGES -rn ../meta-foo/recipes-core/busybox/13:51
lpapp../meta-foo/recipes-core/busybox/ =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev"13:51
lpapp../meta-foo/recipes-core/busybox/ = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-udhcpc ${PN}-mdev"13:51
lpapphwclock maybe?13:52
bluelightninglpapp: not unlikely: meta/recipes-core/packagegroups/    ${@base_contains("MACHINE_FEATURES", "rtc", "busybox-hwclock", "", d)} \13:52
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC13:52
lpappbluelightning: then what else to check, really13:54
sveinseSo 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 manual13:54
*** Net147 <Net147!> has quit IRC13:55
bluelightninglpapp: no, I mean it's likely to be the lack of busybox-hwclock that's causing the issue13:55
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC13:56
lpappbtw, poky-denzil-7.0.1/meta/recipes-core/busybox/ -> it contains tabs13:56
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto13:56
lpappso old denzil code was bad, and it was not our mistake apparently.13:56
* zeddii has to bolt to the airport. grab me by email if there are questions.13:56
*** zeddii <zeddii!~ddez@> has quit IRC13:56
bluelightninglpapp: we introduced the requirement after denzil, before that it was an inconsistent mess, hence why we changed to enforce four spaces13:56
bluelightninglpapp: FWIW, this was mentioned in the migration info I linked yesterday13:57
lpappdo you have that link at hand?13:57
sveinseIMHO 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.13:58
*** belen <belen!~Adium@> has quit IRC13:58
lpappbluelightning: yeah, hw-clock was it.13:59
-YoctoAutoBuilder- build #227 of poky-tiny is complete: Success [build successful] Build details are at
lpappso how about the other toolchain errors?14:00
sveinseant_work: Thanks. Another option is to rebase our kernel changes into a yocto kernel clone14:00
lpappelibc, etc?14:00
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto14:00
lpappand external-sourcery-toolchain14:00
*** belen <belen!~Adium@> has joined #yocto14:00
*** davest <davest!~Adium@> has quit IRC14:00
ant_worksveinse: it has been developed with git in mind but you really don't need a branch. You ca paraxite linux-yocto with a .bbappend14:00
bluelightning_sveinse: or use linux-yocto-custom as a base (see meta-skeleton)14:01
bluelightning_sveinse: the BSP guide should cover creating a simple BSP14:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC14:03
sveinsebluelightning_: Perhaps it does. I'm trying to absorb and read as much as I can, so I have probably missed it.14:03
bluelightning_sveinse: if you find shortcomings in the docs after looking there it would be useful feedback14:05
lpapprburton: ^14:06
rburtonlpapp: never used an external toochain, sorry14:06
lpapp -> so getting 3-10 basically.14:07
lpappis it really external toolchain related?14:07
lpappor does it happen to be a problem with that package, but a general yocto issue?14:07
*** Crofton <Crofton!> has joined #yocto14:08
*** andyross <andyross!> has joined #yocto14:08
sveinseLet 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 contents14:09
lpappis the maintainer in here?14:10
lpappis it actually actively supported?14:10
frank_fighting71bluelightning: you're right, I compiled with master and IMAGE_INSTALL += "libnfsidmap", succussful! Thanks!14:11
bluelightning_frank_fighting71: great!14:11
*** TuTizz <TuTizz!~TuTizz@> has quit IRC14:12
bluelightning_lpapp: the person who usually maintains it is kergoth14:12
frank_fighting71BTW, is there a way to compile multilib in yocto ?14:12
lpappbluelightning_: ah, the one I ignored back then.14:12
lpappbluelightning_: will ask on the mailing list anyway14:12
bluelightning_frank_fighting71: yes we support multilib -
lpappnot that I got solutions for my previous issues. :(14:13
frank_fighting71bluelightning: Thanks !14:13
*** andyross <andyross!> has quit IRC14:14
lpappbluelightning_: anyway, that issue has no relation to my layer14:14
lpappnot according to the error message, anyway.14:15
lpapplikely a platform bug.14:15
lpappkergoth: bluelightning_
*** mulhern <mulhern!> has joined #yocto14:17
rburtonbluelightning_: the dev-so sanity check, i wonder if we should refine it to only warn if its a proper dev symlink, i.e. if points at  eg only warn if target starts with symlink name.14:17
lpappbut state it clearly: is the external sourcery thingie officially supported?14:18
*** arky <arky!~arky@> has joined #yocto14:21
lpappwho maintains poky-dylan-9.0.0/meta/recipes-core/eglibc/ ?14:22
lpappwho maintains libiconv?14:23
bluelightning_lpapp: eglibc, libiconv and the toolchain we actually build is mostly maintained by khem14:24
lpappkhem: idea?14:24
lpappbluelightning_: I have the temptation of removing those provides from the external sourcery...14:25
lpappnot sure if it was blowing up...14:25
lpappbluelightning_: are those supported officially?14:35
lpappor just leisure time projects for someone?14:35
bluelightning_lpapp: which?14:35
lpappall those14:35
frank_fighting71Is there a simple method to remove a default package from a image(eg,core-image-sato) ? __except__ hob.14:36
bluelightning_lpapp: what we actually test: eglibc + the toolchain we actally build14:36
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC14:36
lpappbluelightning_: so external toolchains are not supported by the yocto project?14:37
*** mulhern <mulhern!> has quit IRC14:37
bluelightning_lpapp: there are a number of organisations involved in the Yocto Project that do use it in conjunction with external toolchains14:37
lpappthat is not what I asked.14:38
*** ka6sox-away is now known as ka6sox14:38
bluelightning_lpapp: that is the only answer I have for you, I personally do not use an external toolchain14:38
*** mulhern <mulhern!> has joined #yocto14:39
lpappso you do not know, I take it.14:39
lpappbluelightning_: one negative point in yocto is the lack of proper error reporting system14:41
lpapphopefully it will improve over time.14:41
bluelightning_lpapp: we have a proper error reporting system14:41
bluelightning_lpapp: yep14:41
lpappotherwise all the issues today would have been clear for everyone.14:41
bluelightning_lpapp: we have some error cases where information is not displayed that would be helpful14:42
lpappno no14:42
lpappI mean error reporting system:-14:42
lpappyou have the information needed at the right place.14:43
lpappbluelightning_: even bruteforce commenting of those offending packages in poky-dylan-9.0.0/meta/recipes-core/meta/ did not help. :(14:47
*** pidge <pidge!> has quit IRC14:49
*** icanicant <icanicant!~klawson@> has quit IRC14:51
lpappbluelightning_: what is a virtual, btw?14:51
bluelightning_lpapp: it's a convention for items that may be provided by more than one provider14:52
lpappbluelightning_: what is the expected result when they are?14:52
bluelightning_lpapp: a PREFERRED_PROVIDER needs to be set to select which one should be built14:53
lpappbluelightning_: where?14:54
bluelightning_lpapp: at the global level14:54
bluelightning_lpapp: local.conf, distro config, machine config depending on what you're selecting a preferred provider for14:56
lpappbluelightning_: what is the point of virtual then?14:57
bluelightning_lpapp: I thought I explained that above14:58
rburtonlpapp: an example would be virtual/libgl.  there's more than one GL implementation.14:58
*** bluelightning1 <bluelightning1!~paul@> has joined #yocto15:03
lpappbluelightning_: you did, but it does not make sense to me.15:03
lpappbluelightning_: why do you need to tag something like that when you need to choose between two anyways?15:03
lpapprburton: ?15:03
lpapprburton: different implementations mean different projects with different packages.15:03
rburtonbut applications just care that they get GL headers15:03
rburtonso packages can depend on virtual/libgl15:04
bluelightning1lpapp: it's a convention, so that we know it's intended to be a selection rather than one specific recipe15:04
*** bluelightning1 is now known as bluelightning15:04
lpappI specifically care about which gl implementation is implemented.15:04
*** bluelightning <bluelightning!~paul@> has quit IRC15:04
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto15:04
lpappi.e. not some open source crap15:04
lpappbut real stuff from the vendor with 3d acceleration and so forth.15:04
rburtonlpapp: sigh.  of course *you* care, you're building the distro.15:04
lpapprburton: no no15:04
rburtonlpapp: thats why you get to pick, using PREFERRED_PROVIDER15:04
lpappI care as a user of the library15:04
lpappi.e. game engine developer.15:04
rburtonbut the library when its building doesn't care15:04
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC15:06
*** roinn <roinn!~roinn@> has quit IRC15:07
*** davest <davest!Adium@nat/intel/x-degonadqahyzvyum> has joined #yocto15:07
lpappso people have to pick now, but they did not need with denzil?15:07
*** sveinse <sveinse!~chatzilla@> has quit IRC15:07
*** andyross <andyross!> has joined #yocto15:08
rburtonvirtuals have been around for many years15:08
rburtonany errors you're seeing related to external toolchains are ... related to external toolchains.15:08
rburtonat which point you'll need to find someone else to help as i've not used them either.15:08
rburtonhalstead: there?15:09
*** ant_work <ant_work!> has quit IRC15:10
rburtonhalstead: "Receiving objects:  13% (399274/2853620), 144.89 MiB | 5 KiB/s" <-- i was hoping for a faster clone than that from git.yocto :(15:10
halsteadrburton, Here. On a call right now. How long has the bandwidth been constrained at that level?15:14
rburtonhalstead: 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.15:15
*** dlern <dlern!~dlerner@> has joined #yocto15:15
lpappbluelightning: rburton
lpappr.e. busybox15:15
lpappwhat is this again? :O15:15
*** darknighte is now known as darknighte_znc15:16
lpappfwiw: 131 do_configure () {15:16
lpapp132     do_prepare_config15:16
lpapp133 -m .config ${@" ".join(find_cfgs(d))}15:16
lpapp134     cml1_do_configure15:16
lpapp135 }15:16
rburtonlpapp: according to grep, that's defined in busybox.inc15:17
lpappthis happens when using external-sourcery15:17
lpappinstead of external-csl15:17
lpappfor the TCLMODe thingie15:17
lpapprburton: sure15:18
lpapprburton: so what is the problem then?15:19
lpappit is requiring that15:19
rburtonlpapp: no idea, works for me.15:20
rburtonmaybe that external toolchain is breaking some other things15:20
lpapprburton: but it is not toolchain scope.15:20
lpappit looks like a bitbake issue.15:20
rburtonsorry, no idea.15:21
lpappyeah, I replied to bill.15:21
lpappis he using irc?15:21
wmatam I the Bill you're referring to? ;)15:22
lpappyep. :)15:22
*** zenlinux_ <zenlinux_!> has quit IRC15:24
lpappwmat: got a clue for the error?15:24
lpapprburton: I wonder why my predecessor thought --disable-zlib would be working ...15:25
wmatlpapp: not immediately15:25
lpapprburton: oh, and fwiw, poky has opengl in there, but the handbook does not mention such a feature:
rburtonlpapp: very true. is the current docs, that site is old.15:26
*** zeeblex <zeeblex!apalalax@nat/intel/x-qlaydvncefhbgowr> has left #yocto15:27
lpapprburton: perhaps it should be marked so then?15:27
lpapprburton: also, the new link yields this, 403 Forbidden15:27
rburtonlpapp: yes15:27
rburton, sorry15:27
lpapprburton: well, cannot find opengl there either.15:28
rburtonlpapp: yeah needs to be added.  probably a few others missing too.15:28
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto15:28
*** TuTizz <TuTizz!~TuTizz@> has quit IRC15:29
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto15:29
lpappso who is the python master here?15:29
*** frank___ <frank___!~Android@> has joined #yocto15:30
lpappwho can tell more about the busybox thingie?15:30
lpappthe function is clearly defined in the inc.15:30
lpappalso, why does it care about the meta / busybox?15:30
lpappshouldn't it pick up my busybox from my layer?15:30
lpappso the real question is: why does it not ignore the "default" from oe-core?15:30
rburtonlpapp: its probably trying to parse it, so this is before it decides to not execute anything there15:31
*** frank___ <frank___!~Android@> has quit IRC15:31
lpapprburton: that sounds bad ordering.15:31
rburtonlpapp: very hard to ignore something unless you know what it is15:32
lpapprburton: you should know in advance what to ignore.15:32
rburtonlpapp: but it doesn't know what it is until the file has been parsed15:32
lpappit should parser the whitelist file.15:33
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto15:33
lpappthat is what it should start with.15:33
lpappand then the relevant version that is whitelisted.15:33
lpappin any case, how parsing a python file can be related to an external toolchain?15:34
lpappI am using python 2.7 fwiw.15:35
lpapplet us see if they get a clue on #python.15:40
rburtonlpapp: #python can't help15:41
lpappwell, tell me a better place for help.15:41
rburtonwell, here15:41
lpappyeah, like no one has been giving solutions for external toolchain issues for two days?15:41
rburtonif you can reliably replicate changing the toolchain means the error disappears and appears, then that's a good data point15:42
*** lpapp <lpapp!~lpapp@> has quit IRC15:42
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto15:42
rburtonand bitbake -e will be very useful to find the differences that causes15:42
*** mihai <mihai!~mihai@> has quit IRC15:42
rburtonhere is best, but also a limited number of people use external toolchains, so you'll have to be patient15:42
lpappbusiness does not work with patient.15:42
lpappif I do not get help, I need to go the hard way.15:42
rburtondoesn't help that you'd blocked the one guy who is best placed to help15:42
lpappwell, he could reply on the mailing list?15:43
rburtonbusiness can pay for support from a commercial support partner15:43
lpappno no15:43
lpappbusiness does not mean people have money for everything.15:43
rburtontwo options.  1) pay for support.  2) community support.15:43
lpapp3) solve it yourself.15:43
lpappmeh, even bitbake help is broken with dylan. :(15:45
rburtonreally sounds like you've broken your setup somehow15:45
lpappbitbake help -> starts building15:45
lpappit should not start15:45
rburtonwhy not?15:46
lpappit should print the help output.15:46
rburtonyou've told it to build "help"15:46
rburtondid you mean --help?15:46
wmatlpapp: bitbake help is not broken on my dylan setup15:46
lpappwasn't the "help" the same for the bblayer util?15:46
lpappand for this, it is --help?15:46
lpappisn't that tad confusing?15:46
*** hollisb <hollisb!> has joined #yocto15:46
rburtonpatches welcome15:46
*** darknighte_znc is now known as darknighte15:47
rburtonbitbake-layers is a tiny little convenience tool15:47
bluelightninglpapp: FWIW, --help on bitbake-layers will trigger the help output anyway15:47
lpappbluelightning: not for me, anyhow15:47
lpappalso, why is that not the official way?15:48
lpappI have been told stuff help here yesterday15:48
lpappso I tried that for bitbake15:48
rburtonif we're going to argue about command syntax, bitbake-layers is the outlier15:48
rburtoni suggest living with it15:48
lpapprburton: the bitbake -e output is quite spammy.15:49
rburtonlpapp: that's not spam, it's the entire configuration space15:49
rburtonyou might be able to identify why changing toolchain breaks busybox with that15:49
lpapprburton: bitbake -e busybox should do it?15:50
rburtonlpapp: yep15:50
lpapprburton: did not help15:54
lpappbitbake -e busybox > sourcery.log15:54
*** eren <eren!~eren@unaffiliated/eren> has quit IRC15:55
lpappit is not actually printing such stuff.15:55
*** volker <volker!> has quit IRC15:56
*** Guest99011 <Guest99011!~tbn@> has quit IRC15:56
lpapprburton: so something even before -e is broken in the pipeline.15:57
wmatlpapp: what version of Python and what version of BitBake?15:58
*** belen <belen!~Adium@> has quit IRC15:58
wmatlpapp: and what CSL toolchain? I'll try to reproduce your error.15:59
*** zenlinux <zenlinux!> has joined #yocto15:59
lpappwmat: CSL toolchain means?16:00
wmatlpapp: CodeSourcery?16:00
lpappwmat: arm-2009q1 if that is what you mean.16:00
wmatlpapp: yes16:00
*** belen <belen!Adium@nat/intel/x-qmhwzbggigudgfzl> has joined #yocto16:01
lpappsorry, I was wrong16:01
lpappI regenerated sourcery.log and now it is more complete.16:01
wmatlpapp: the EABI or GNU/Linux toolchain?16:02
lpappwmat: arm-none-linux-gnueabi16:05
kergothit'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
kergothwe intend to sort out this situation to reduce confusion in the near future16:06
*** elmi82 <elmi82!> has quit IRC16:07
*** zenlinux <zenlinux!> has quit IRC16:10
lpappdenzil external-cs worked just fine16:11
lpappit is so sad that dylan broke the external toolchain usage. :(16:11
*** arky <arky!~arky@> has quit IRC16:12
*** zenlinux <zenlinux!> has joined #yocto16:13
lpappwhat was the reason of not keeping external-csl around?16:13
lpappuntil you have a _stable_ and _mature_ external-sourcery?16:13
lpappfor embedded developers, probably denzil is the way to go then... but that is not maintained. :(16:14
lpappso in the end of the day, embedded developers are screwed.16:14
lpappusing cross-toolchain. :(16:14
wmatthe fix may be a simple patch once the problem is determined16:16
lpappsure, but it is beyond my league.16:16
lpappand a patch will not get into the release now. :(16:16
*** ivali <ivali!~ivali@unaffiliated/ivali> has quit IRC16:16
lpappcat csl.log | ix16:24
lpappcat sourcery.log | ix16:25
lpappif anyone can check the mystery with diff.16:25
lpappI do not see significant diffs.16:25
*** mckoan is now known as mckoan|away16:26
*** alexhairyman <alexhairyman!> has joined #yocto16:30
*** eballetbo <eballetbo!> has quit IRC16:30
lpappwmat: I wonder if you could check the diff.16:33
lpappwmat: also, could you reproduce the issue?16:33
wmatlpapp: I'm still waiting for Mentor to send me the link to download the toolchain :/16:34
rburtonlpapp: the diff doesn't appear to contain anything apart from an extra include and timestamps16:35
rburtonlpapp: you can reliably switch between the two toolchain modes and the error changes?16:35
lpappwmat: I can send it to you if that is quicker.16:36
lpapprburton: as written, yes.16:36
lpapprburton: + image name.16:36
lpapp+ do_devshell hash16:37
lpapprburton: so you think, the diff is ok, then?16:42
lpapprburton: and the issue cannot be figured out from it?16:42
rburtonlpapp: nope16:43
lpapprburton: nope?16:44
lpappfor which question, that is16:45
rburtonthe diff is fine, but its not useful16:45
wmatlpapp: how large is the toolchain file? is it email-able?16:47
lpappwmat: of course no. :)16:47
lpappwmat: but I can put it on dropbox.16:47
wmatok, make it so16:47
lpappwmat: which host do you use?16:47
wmatlpapp: linux x86_6416:48
lpappwmat: I mean which distro16:48
lpapparch looks the same as mine16:48
lpappso my binaries should work then.16:48
*** seebs <seebs!> has quit IRC16:49
lpappwmat: phew, it takes ages to just compress.16:50
lpapplot of translation stuff. :/16:51
*** seebs <seebs!> has joined #yocto16:51
wmatlpapp: for dany, did you download the tarball or clone the repo?16:52
lpappwmat: it is dylan16:52
lpappI downloaded the release 9.0.016:52
lpappwmat: hmm, sorry, I cannot send the toolchain.16:53
lpappit contains our git history.16:53
lpappagain, what is your linux host?16:53
lpappI would be surprised if they did not provide ready-made binaries off-hand.16:53
-YoctoAutoBuilder- build #223 of nightly-mips is complete: Success [build successful] Build details are at
lpappwhat toolchain was the sourcery thingie tested?16:55
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:56
lpapprburton: is there a zlib disabling distro feature?16:56
rburtonlpapp: nope16:56
*** belen <belen!Adium@nat/intel/x-qmhwzbggigudgfzl> has quit IRC16:57
rburtonif you really don't want zlib installed you'll have to use bbappends to disable it in each recipe that links to it16:57
lpappthat is kinda crazy. :)16:58
mr_sciencenot as crazy as what i just did lat night...16:59
lpappthat does not comform me, I am afraid.16:59
lpappbut my sympathy is there though.16:59
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-wzqcdggrptpydfjq> has quit IRC17:00
*** belen <belen!Adium@nat/intel/x-ivyjprgxklmanphc> has joined #yocto17:00
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-xjmbwkbvrlwhnoel> has joined #yocto17:01
*** fitzsim <fitzsim!~user@nat/cisco/x-gatiaonknqjnejaw> has joined #yocto17:04
wmatlpapp: mentor does provide binaries, I just haven't received the link to download them yet17:05
rburtonlpapp: if you're even considering removing zlib you've clearly got a tiny install image, so it won't be a lot of effort17:05
wmatlpapp: x86_6417:05
lpapprburton: well, we are using nor flashes17:05
lpapp32 MB17:05
*** mulhern <mulhern!> has quit IRC17:06
lpappwmat: yeah, but the distribution package would not need waiting.17:06
wmatlpapp: i found a link in an old email. You said a 2009 version?17:09
lpappwmat: quarter 1, yes.17:10
*** iwamatsu___ <iwamatsu___!> has quit IRC17:11
*** iwamatsu___ <iwamatsu___!> has joined #yocto17:11
*** sameo <sameo!~samuel@> has quit IRC17:14
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto17:19
lpappwmat: did you get the link?17:22
lpappwmat: btw, you do not need to await any link17:22
lpappthe one from here can be downloaded off-hand.17:22
lpappwmat: could you obtain it a way or another?17:26
*** panda84kde <panda84kde!> has quit IRC17:26
wmatlpapp: i have it now17:27
lpappwmat: can you repro the issue?17:27
wmatlpapp: so the only customizations you did were what?17:27
lpappmy layer17:27
lpappand that is pretty much it17:27
wmatto conf files?17:28
lpappMACHINE ?= "polatisnic"17:28
lpappsorry, for the spam17:28
*** Umeaboy <Umeaboy!> has quit IRC17:28
lpappMACHINE ?= "mymachine"17:28
lpappDISTRO ?= "mydistro-tiny"17:28
lpappand that is it17:28
lpappand of course TCMODE = "external-csl"17:29
lpappEXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1"17:29
lpappTARGET_PREFIX = "arm-none-linux-gnueabi-"17:29
lpappI can try with poky-tiny as well17:29
lpappor even "poky" for now.17:29
lpappperhaps I should not, though.17:29
* lpapp is not sure17:29
lpapphelp is appreicated.17:29
wmatlpapp: I'll use beagleboard17:30
lpappfor the machine, right?17:30
lpappfor the DISTRO?17:30
lpappok, let me try with that17:31
wmatand what command like bitbake did you issue?17:31
lpappunparsed line: 'MACHINE ?= beagleboard'17:31
lpappbitbake core-image-minimal17:32
lpappah, missing quotes.17:32
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC17:32
lpapphmm, I cannot reproduce the issue with those setups.17:33
*** jkridner <jkridner!~jkridner@> has joined #yocto17:34
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto17:34
lpappis there a way to surpress the host distribution warning about unsupported stuff?17:35
bluelightninglpapp: SANITY_TESTED_DISTROS = "" in your local.conf17:36
lpappI do not like the syntax of that, but it will do it for now.17:38
bluelightningit's a list of distros that have been tested as used by sanity.bbclass; if no list is specified the host distro isn't checked17:39
bluelightning(since there's nothing to check it against)17:40
lpappit would be nice to have a boolean syntax for this.17:41
lpappfor enabling/disabling17:41
*** galak <galak!> has joined #yocto17:41
lpappwmat: I use armv5 fwiw.17:42
lpappwmat: yeah, I can definitely reproduce it with poky and beagleboard17:44
lpappalthough with my layer inside the bblayers.conf17:44
lpappnot sure that should matter.17:44
*** zenlinux <zenlinux!> has quit IRC17:45
wmatas soon as you issue the bitbake command, do you see the two errors about the missing toolchain?17:45
lpappwmat: no17:45
lpapponly at home.17:46
lpapphere at the company, I do not see that error.17:46
wmatyou did say you were using arm-none-eabi-* correct?17:47
wmatnot arm-none-linux-gnueabi-*?17:48
lpappwmat: gnueabi what I use.17:50
lpappbut this is now strange... I can even reproduce with external-csl17:50
lpappif I use the poky+beagleboard setup.17:50
lpappwmat: so could you reproduce the issue?17:51
wmatlpapp: I ahve to grab the gnueabi toolchain, as I only have the eabi toolchain now17:54
lpappwmat: I already gave you the link,
lpappwmat: btw, what errors did you get?17:55
lpappis it similar to what I got at home?17:55
lpappsome INVALID stuff in the error?17:55
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:55
wmatlpapp: gimme a sec17:56
lpappwmat: it could potentially help me a lot if you express that.17:57
wmatlpapp: i'm sure it would, I just need time to complete the test17:57
lpappwhat test?17:57
*** belen <belen!Adium@nat/intel/x-ivyjprgxklmanphc> has quit IRC17:57
lpappI thought you would have already done the experiment?17:57
lpappfor the wrong toolchain, so you could just paste the output you got?17:57
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto17:59
*** belen <belen!~Adium@> has joined #yocto17:59
wmatlpapp: it's building now with the correct toolchain18:01
lpappwmat: I do not think you need to go that far.18:01
lpappit does not even start the building for me.18:01
lpappso if it is building for you, you simply cannot reproduce the issue.18:02
*** smartin_ <smartin_!> has joined #yocto18:02
wmatyep, mine is building fine18:03
lpappso, can you give me the error message then?18:03
wmatI got an error about multiple .bb files are going to be built for eglibc18:04
wmatand an error about zlib fetch failed18:05
lpappwith the gnueabi toolchain?18:05
lpapp"I got an error about multiple .bb files are going to be built for eglibc18:05
lpappthat looks exactly my issue18:05
lpappif you read my email18:05
wmatbut with -k, it keeps building18:05
lpappand with the right toolchain, you do not get those errors?18:06
wmatno, I do18:06
wmatbecause the eglibc recipe exists twice18:07
lpappright, so you can actually reproduce then.18:07
wmatonce in core and once in meta18:07
lpappcould you please make sure you are getting the same errors as me on the mailing list?18:07
* wmat looks again18:07
lpappok, so it is an upstream bug.18:07
lpappnothing to do with my setup.18:07
lpappalso, could you please let me know the error with the wrong toolchain?18:09
*** zenlinux <zenlinux!> has joined #yocto18:09
wmatjust that it couldn't find the toolchain, which is correct18:10
lpappmind pasting the error message?18:10
lpappis it the same I have on the mailing list?18:10
lpappI can reproduce the busybox thingie even with dylan vanilla18:11
lpappwithout my layer18:11
wmatlpapp: no, it wasn't the same. It was just a missing toolchain error, as I didn't have the right toolchain.18:11
wmatI didn't save it18:12
lpappwmat: no, I mean I have two errors18:12
lpappthe one here at the company18:12
lpappand in the same thread, I had another from home, yesterday.18:12
lpappwmat: in any case, is this a hard fix upstream for the external thingie?18:12
wmatlpapp: once the build completes, I can paste the log somewhere18:13
lpapphope the fix can come with a poky dylan bugfix release soon in the near future ...18:13
lpappwmat: I do not particularly need the log.18:13
lpappwe already discussed it.18:13
wmatlpapp: well, a bug needs to be opened for it to be fixed18:13
lpappor if you mean for the wrong toolchain, then ok.18:13
lpappwmat: that is the less issue.18:13
lpappthe main thing is that do you have any clue how to fix it?18:14
wmatat present, no18:15
lpappwmat: can you ask kergoth18:16
lpappI think he is ignoring me18:16
lpappotherwise he would have chimmed in already.18:16
sgw1lpapp: I replied to your email, please file a bug with all your configuration files so that the information is all in one place18:17
wmatI have to move onto other work now, but I'd try opening a bug18:17
lpappsgw1: I already did18:18
*** belen <belen!~Adium@> has quit IRC18:18
sgw1lpapp: where, I just checked the and do not see any bug from you18:19
lpappsgw1: maybe you need to refresh or so18:20
sgw1lpapp sorry, timing of bugzilla I guess18:20
lpappI did it a couple of minutes ago18:20
lpappanyway, even if no one can work on it, I need a workaround ASAP18:21
lpappit is kinda blocking my company work right now.18:21
lpappwmat: is the -k thingie an acceptable workaround?18:21
lpappit will not blow up later?18:21
sgw1lpapp: understood, I am going to try and repoduce this here now18:21
wmatlpapp: I use -k frequently18:22
sgw1lpapp: to confirm, you are now using dlyan HEAD from git?18:22
lpappsgw1: no18:22
lpappdylan 9.0.018:22
sgw1lpapp: I thought it was suggested that you use dylan HEAD, since there are some patches that you needed in it.18:23
sgw1ok I will use the 9.0.0 tag18:23
lpappsgw1: we cannot afford the risk as a company.18:23
lpappif something is not working, we need to backport.18:24
lpappthe relevant stabilization patches.18:24
kergothI'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 end18:24
lpappbut we definitely cannot base stuff on a rolling 'dev' branch.18:24
lpappsgw1: please check the bugreport again, as I have just written a few additional information about the toolchain, and the dylan version.18:25
lpappwell, I can try HEAD18:25
lpappit does not take long18:25
lpappnot that we will use it.18:25
lpappbut we can see if it got fixed in there.18:25
wmatkergoth: I'd agree with that. I'd rather complete a build and deal with a nice log file afterwards.18:27
kergothit requires much less babysitting18:27
kergothand developer time is valuable18:27
lpappwmat: what is the workaround?18:28
sgw1lpapp if not head how about the stable update of 9.0.1?18:28
wmatlpapp: use -k is all I did18:28
lpappwmat: is that acceptable?18:28
lpappwill it not blow up later?18:28
lpappcan we breath the air safely afterwards?18:28
wmatlpapp: it's acceptable to me18:28
sgw1lpapp what command did you issue to get the failure?18:29
lpappsgw1: we can only use releases.18:29
lpappand if we choose dylan now, we will stick to it for at least a year18:29
sgw1lpapp: 9.0.1 is a release18:29
*** alexhairyman <alexhairyman!> has quit IRC18:29
lpappand only stable bugfix releases would be acceptable.18:29
lpappsgw1: not mentioned on the website.18:29
sgw1it's the stable bugfix release for dylan18:29
lpappsgw1: fix the website then.18:29
wmatlpapp: also, why not use a newer toolchain?18:30
lpappwmat: because our software is based on old?18:30
lpappwmat: and we did not have the time to fix stuff around it when even yocto does not work?18:30
lpappyou know ... step by step.18:31
lpappwe are not an engineer army.18:31
lpappI would love to update to 2013.05 due to C++1118:31
sgw1lpapp: it's on the website,, first item on the list Poky 9.0.1 released 6/27, fix your eyes ;-)18:31
lpappand later to c++1418:31
lpappfirst result on google18:31
sgw1lpapp: what command did you use to get the failure: bitbake ???18:31
lpapppoky dylan download18:32
lpappI get no selectable list18:32
lpappsgw1: check bugzilla, please.18:32
sgw1lpapp: click on the downloads link and you will get the list18:32
lpappbitbake core-image-minimal18:33
lpappERROR: ParseError at /home/lpapp/Projects/poky/meta/recipes-core/gettext/ unparsed line: '<<<<<<< HEAD'                                                                                | ETA:  00:0018:33
lpappmaster is even more broken. :(18:33
sgw1lpapp: I just checked the bug, so you mean core-image-minimal since image minimal is not a valid target18:33
lpappsgw1: yeah, that is a typo, and the crappy bugzilla does not allow edit.18:34
lpappso yeah, master is more broken.18:35
lpappis there any stable release for dylan?18:35
lpappmy last try is 9.0.118:36
sgw1lpapp, I have to go for a while lunch here, back later build is in progress18:36
lpappI need to leave anyway18:36
lpappit is getting 8 pm in here.18:36
sgw1lpapp, I hope to have something for you later my afternoon18:37
lpappthat would be appreciated.18:37
wmati see multiple eglibc recipes with git head as well18:38
lpappkergoth mentioned the stuff is totally unmaintained in oe-core18:38
lpappand they use meta-sourcery18:38
lpappso perhaps it is a "not possible" fix.18:38
lpappand the proper integration fix would come months later.18:38
lpappthat frankly scares me18:38
*** JaMa <JaMa!> has quit IRC18:39
lpappbut I will stop being pessimistic.18:39
lpappdenzil seems to have worked.18:39
lpapptoo bad I spent 2-3 days with it if it is now worse.18:39
lpappwmat: right, so it is probably not fixed in 9.0.1 either18:40
lpappalthough I am trying, just in case ...18:40
*** JaMa <JaMa!> has joined #yocto18:40
rburtonlpapp: that parse error is because its parsing the output of a merge, delete those files18:41
lpappwhat worries me is that it seems there is no QA gate for external toolchains18:41
rburtonboth the filename and the line its failing to parse tell you its the output from a merge conflict18:41
lpapprburton: there is no any merge.18:41
lpappit is a fresh clone/pull.18:41
lpappno QA toolchain because denzil worked, same stuff got broken by dylan.18:42
lpappthere is no proper regression test.18:42
lpappwhich again, makes me unsafe about using Yocto18:42
rburtonlpapp:  "/home/lpapp/Projects/poky/meta/recipes-core/gettext/"18:42
rburtonmerge conflict18:42
lpapprburton: well I just cloned and pulled.18:42
lpappit can hardly my mistake. :)18:43
rburtonok, lets check git18:43
rburtonwhat revision have you checked out?18:43
lpappmaster HEAD18:43
lpappI also mentioned in the bugreport.18:44
*** jkridner|work <jkridner|work!~jkridner@nat/ti/x-legwuvlkjdmkydxm> has joined #yocto18:44
rburtoni don't see a file called
rburtonso its local to you18:44
lpappyeah, same issue with 9.0.118:44
rburtonits a merge confict which bitbake is attempting to parse18:44
rburtondelete it18:44
lpapprburton: well I deleted the whole repository18:44
rburtondo a git status and check there's nothing else sitting around like that too18:44
lpappand I am cloning a brand new stuff18:45
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC18:45
* rburton -> dinner/jog/etc18:45
lpappphew, clone is extremely slow.18:45
* lpapp -> dinner/cycling/etc18:46
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC18:48
*** mulhern <mulhern!> has joined #yocto18:51
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-xjmbwkbvrlwhnoel> has quit IRC18:55
kergothsent 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 it18:57
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-isyxsflkanupbgxu> has joined #yocto18:58
*** ant_home <ant_home!> has joined #yocto19:01
*** zeddii <zeddii!> has joined #yocto19:03
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has quit IRC19:07
*** djszapi <djszapi!~lpapp@kde/lpapp> has joined #yocto19:13
djszapiwmat: what error did you get with the wrong toolchain?19:14
wmatdjszapi: I can try it again if you like, buy I can't remember now19:15
*** djszapi is now known as lpapp19:15
lpappplease do if you can.19:15
wmatbut why, as it's not the same toolchain you're using?19:15
wmatand I set the local.conf file to my 'wrong' toolchain as well19:16
wmatfwiw, 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 location19:17
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC19:17
kergothI 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 us19:19
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto19:19
lpappwmat: I missed it, I guess.19:19
kergothit's also part of the mentor embedded linux commercial product19:19
wmatlpapp: exact same errors. 3 eglibc issues, and 1 issue with a missing location19:22
*** forcev <forcev!> has joined #yocto19:22
wmatlpapp: I'm done with this now. I'd try meta-sourcery.19:23
kergothwe 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 used19:24
lpappwmat: issue with what?19:24
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC19:24
kergotheither 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 directly19:24
lpappwmat: well, this stuff worked 1.5 years ago.19:25
kergothI'm currently working on breaking up the external-toolchain recipe into individual recipes for each component, but it's not my current priority19:25
lpappit looks awkward that some de-evolution is taking place about it.19:25
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has left #yocto19:25
lpappperhaps we should not use yocto, just a ready-made distribution.19:26
lpapplife might become a lot easier.19:26
lpappcurrently there is no stable way of using a cross-compilation toolchain ->19:26
lpappembedded developers are screwed mostly.19:26
lpapphopefully the technology will become accessible enough in a few years to revisit the question.19:27
*** andyross <andyross!> has quit IRC19:30
-YoctoAutoBuilder- build #233 of nightly-x32 is complete: Success [build successful] Build details are at
kergothdamn, oe-core is still missing a heck of a lot of systemd services19:36
lpappwmat: have you actually tested that layer/19:40
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC19:40
*** lpapp <lpapp!> has joined #yocto19:41
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto19:41
wmatlpapp: no19:41
lpappwmat: can you ask kergoth to unignore me to discuss the issue?19:43
*** tor_ <tor_!> has quit IRC19:43
wmatlpapp: i'd probably stick to the mailing list and bug report for communication with him19:49
*** zenlinux <zenlinux!> has quit IRC19:54
-YoctoAutoBuilder- build #222 of nightly-arm is complete: Failure [failed Running Sanity Tests Building Images_1 Building Toolchain Images Building Toolchain Images_1 Publishing Artifacts] Build details are at
lpappwmat: well, he does not reply.19:56
*** fenrig <fenrig!5bb53956@gateway/web/freenode/ip.> has joined #yocto19:56
fenrigHi I can't seem to find how to add a conditional dependency (based on the machine)19:57
wmatlpapp: just keep trying, but also have patience19:57
*** zeddii <zeddii!> has quit IRC19:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:59
lpappwmat: to be honest, I do not care.20:00
lpappif he wanted, he could have contributed to it.20:00
fenrigdoes anybody know how to add conditional dependencies based on the machine that is being built for?20:03
fenrigI want to add "gst-fsl-plugin" when I'm building for a freescale board (in this situation the I.Mx5320:04
bluelightningfenrig: DEPENDS_append_machinename = " gst-fsl-plugin"20:05
bluelightningfenrig: note the leading space, that's important20:06
fenrigbluelightning: string concatenation?20:06
lpappsgw1: I am here if you need any information from me.20:07
fenrigbluelightning: I also have a question about licenses when you built a recipe :)20:07
lpappI am in a relaxing evening mood, but I will do my best.20:07
fenrigbluelightning: I understand you add the license file in the root of the layer (meta dir)20:08
fenrigbluelightning: Or is that a wrong assumption20:08
kergothmost recipes should be pointing to existing license file(s) or headers in the source of the thing, not things in the layer20:09
bluelightningfenrig: right, what kergoth said20:10
*** JimBaxter <JimBaxter!> has quit IRC20:11
*** fenrig <fenrig!5bb53956@gateway/web/freenode/ip.> has quit IRC20:15
*** JimBaxter <JimBaxter!> has joined #yocto20:16
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC20:21
*** mr_science <mr_science!> has joined #yocto20:24
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto20:24
*** smartin_ <smartin_!> has quit IRC20:27
*** andyross <andyross!> has joined #yocto20:29
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-isyxsflkanupbgxu> has quit IRC20:31
*** frank_fighting71 <frank_fighting71!~frank@> has quit IRC20:34
*** andyross <andyross!> has quit IRC20:34
*** frank_fighting71 <frank_fighting71!~frank@> has joined #yocto20:34
*** andyross <andyross!> has joined #yocto20:34
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC20:34
*** andyross <andyross!> has quit IRC20:35
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mzbxovyidcikxrgi> has joined #yocto20:37
*** andyross <andyross!> has joined #yocto20:38
*** andyross <andyross!> has quit IRC20:40
*** andyross <andyross!> has joined #yocto20:41
sgw1lpapp: so the external toolchain issue is solved now, it seems there might still be some kind of variable binding bug though20:42
lpappsgw1: how did you solve it?20:43
sgw1lpapp: I am asking you, you sent and email about MACHINE??= being set20:43
lpappsgw1: that is another issue as written20:44
sgw1lpapp: I guess I mis-understood your email, sorry.20:47
lpappsgw1: see the email I replied to.20:49
lpappsgw1: note how I have not replied to the issue we discussed in here.20:49
lpappsgw1: you might wanna invite kergoth to the bugreport.20:51
lpappsgw1: he seems to claim that meta-sourcery is the way.20:51
lpappand the one in oe-core is unsupported.20:51
lpappit is an uncool regression, but that is how they seem to have made it. :(20:52
*** joeythesaint <joeythesaint!~jjm@> has quit IRC20:54
kergothI feel like the new bitbake self restarting stuff doesn't cope well with SIGINT20:56
*** galak <galak!> has quit IRC20:56
kergothperiodically i have to ^Z kill %1; pkill -f bitbake20:56
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto21:05
*** eren <eren!~eren@unaffiliated/eren> has quit IRC21:18
*** jkridner|work <jkridner|work!~jkridner@nat/ti/x-legwuvlkjdmkydxm> has quit IRC21:26
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto21:27
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:31
*** sameo <sameo!~samuel@> has joined #yocto21:33
* kergoth notices in a systemd environment, alsactl itself handles save/restore of state, but in sysvinit, alsa-state does, and sighs21:41
* kergoth grumbles21:41
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto21:42
kergothnot sure what the cleanest way to resolve this is..21:42
*** munch <munch!> has quit IRC21:43
*** Umeaboy <Umeaboy!> has joined #yocto21:50
*** andyross <andyross!> has quit IRC21:58
*** andyross <andyross!> has joined #yocto21:59
*** mulhern <mulhern!> has quit IRC22:00
*** jkridner <jkridner!~jkridner@nat/ti/x-yekwtoisiudgrzki> has joined #yocto22:01
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto22:01
*** Umeaboy <Umeaboy!> has quit IRC22:01
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC22:04
*** jkridner <jkridner!~jkridner@nat/ti/x-cyryhpswzlhnfujy> has joined #yocto22:05
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto22:05
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC22:09
*** davest <davest!Adium@nat/intel/x-degonadqahyzvyum> has quit IRC22:12
*** ivali <ivali!ivali@unaffiliated/ivali> has joined #yocto22:14
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has joined #yocto22:16
*** ivali <ivali!ivali@unaffiliated/ivali> has quit IRC22:18
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC22:24
sgw1khem: you around to talk about the ppc floor() issue?22:30
*** zenlinux <zenlinux!> has joined #yocto22:47
*** zerus <zerus!> has quit IRC22:47
*** sameo <sameo!~samuel@> has quit IRC22:52
*** frank____ <frank____!~Android@> has joined #yocto22:56
*** frank____ <frank____!~Android@> has quit IRC22:57
*** zeddii <zeddii!~bruce@> has joined #yocto23:02
*** seebs <seebs!> has quit IRC23:03
*** seebs <seebs!> has joined #yocto23:08
*** fray <fray!U2FsdGVkX1@> has quit IRC23:12
*** jkridner <jkridner!~jkridner@nat/ti/x-jypfijnrdliiofju> has joined #yocto23:17
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto23:17
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC23:23
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto23:25
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:26
*** agust <agust!> has quit IRC23:31
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-mzbxovyidcikxrgi> has quit IRC23:33
*** vmeson <vmeson!~quassel@> has quit IRC23:38
*** mulhern <mulhern!> has joined #yocto23:39
*** vmeson <vmeson!~quassel@> has joined #yocto23:43
*** ant_home <ant_home!> has quit IRC23:46
*** andyross <andyross!> has quit IRC23:56

Generated by 2.11.0 by Marius Gedminas - find it at!