Thursday, 2013-07-25

*** andyross <andyross!> has joined #yocto00:01
*** zeddii <zeddii!~bruce@> has quit IRC00:01
*** zenlinux <zenlinux!> has quit IRC00:02
*** zenlinux <zenlinux!> has joined #yocto00:02
*** abelloni <abelloni!> has quit IRC00:03
*** mulhern <mulhern!> has quit IRC00:03
*** abelloni <abelloni!> has joined #yocto00:05
*** seebs <seebs!> has joined #yocto00:06
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:13
*** mulhern <mulhern!> has joined #yocto00:27
*** hollisb <hollisb!> has quit IRC00:31
*** mulhern <mulhern!> has joined #yocto00:47
*** ash_charles <ash_charles!> has joined #yocto00:54
ash_charleshello.  Anyone know how I might add a repository/channel to the smart package manager when I'm building an image.00:56
*** _julian_ <_julian_!> has joined #yocto00:58
*** _julian <_julian!> has quit IRC01:01
*** frank <frank!~frank@> has quit IRC01:12
*** frank <frank!~frank@> has joined #yocto01:13
*** andyross <andyross!> has quit IRC01:13
*** andyross <andyross!> has joined #yocto01:14
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:17
*** fray <fray!> has joined #yocto01:18
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC02:01
*** silviof1 <silviof1!> has joined #yocto02:13
*** silviof <silviof!~silviof@> has quit IRC02:16
khemsgw1: yes. now I have few mins here02:32
*** mulhern <mulhern!> has quit IRC02:37
*** darknighte is now known as darknighte_znc02:40
*** andyross <andyross!> has quit IRC03:01
*** andyross <andyross!> has joined #yocto03:01
lpappsgw1: any news?03:13
*** ash_charles <ash_charles!> has left #yocto03:32
*** seebs <seebs!> has quit IRC03:51
*** seebs <seebs!> has joined #yocto04:12
sgw1lpapp: other than I could confirm and reproduce it, but no fix, I have assigned it to kergoth to look into since he is most familiar with the external toolchain code.04:30
lpappsgw1: :(04:43
lpappthe problem is that there is no workaround04:43
lpappso I am fully blocked with my company work04:44
sgw1lpapp: your either up very late or very early!  I understand your frustration, I can't fix every bug, but I can confirm it's there and assigned to the most knowledge person.04:46
lpappsgw1: it is not about to fix.04:47
lpappas written, I do not even have a workaround.04:47
lpappanyway, I will probably switch away from Yocto for now.04:47
sgw1lpapp: it's about a fix or workaround, and I have neither right now, this is not my strong area04:48
lpappit is too unstable for embedded developer as of now.04:48
lpappI appreciate your help though, so do not take it personally.04:48
lpappit is just not the right technology at the moment.04:49
sgw1lpapp: If that's what you believe then you need to do what's right for your company, I know of many other people using, it may not be in the way you are currently.04:49
sgw1lpapp: good night04:50
lpappsgw1: it is not about what I believe.04:50
lpappit is not subjective04:50
lpappit just does not work, it is objective.04:50
lpappit is a fact.04:50
lpappsgw1: good night04:51
*** andyross <andyross!> has quit IRC04:53
*** andyross <andyross!> has joined #yocto04:54
*** andyross <andyross!> has quit IRC05:04
*** agust <agust!> has joined #yocto05:04
*** behanw <behanw!> has quit IRC05:06
*** frank <frank!~frank@> has quit IRC05:26
*** g0hl1n <g0hl1n!5be602f4@gateway/web/freenode/ip.> has quit IRC05:27
*** tor <tor!> has joined #yocto05:51
melonipoikadenix, i want to install xserver-xorg and that is the only layer i found that provides it :-) but yeah, i noticed that arago-oe-dev is not really maintained05:53
sgw1khem: you around now, I know it's late!06:13
*** mihai <mihai!~mihai@> has joined #yocto06:14
-YoctoAutoBuilder- build #225 of build-appliance is complete: Failure [failed Building Images_1 Publishing Artifacts] Build details are at
*** ka6sox is now known as ka6sox-away06:32
*** mitz <mitz!> has quit IRC06:34
*** mitz <mitz!> has joined #yocto06:36
*** volker <volker!> has joined #yocto06:41
yoctiBug 4902: normal, Undecided, ---, richard.purdie, NEW , Add an option or util for automatically updating the file checksum06:49
yoctiBug 4903: normal, Undecided, ---, richard.purdie, NEW , No proper error message for layer version mismatch06:58
*** ka6sox-away is now known as ka6sox06:59
-YoctoAutoBuilder- build #202 of nightly-oecore is complete: Failure [failed Running Sanity Tests Building Toolchain Images Building Toolchain Images_1] Build details are at
*** laur <laur!~lau@> has left #yocto07:03
yoctiBug 4905: normal, Undecided, ---, richard.purdie, NEW , No proper location diagnostic for tab/space issues07:03
*** eballetbo <eballetbo!> has joined #yocto07:04
yoctiBug 4906: normal, Undecided, ---, scott.m.rifenbark, NEW , No opengl mentioned07:06
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto07:09
yoctiBug 4907: normal, Undecided, ---, scott.m.rifenbark, NEW , Add an external sourcery chain example with documentation07:11
lpappI need to stop it for now, but I will submit more bugreports.07:11
-YoctoAutoBuilder- build #224 of nightly-non-gpl3 is complete: Failure [failed Building Images] Build details are at
*** ericben <ericben!> has joined #yocto07:17
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC07:17
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto07:19
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto07:20
*** tbn <tbn!~tbn@> has joined #yocto07:25
*** tbn is now known as Guest8926207:26
*** mihai <mihai!~mihai@> has quit IRC07:28
*** mitz <mitz!> has quit IRC07:29
*** mitz <mitz!> has joined #yocto07:31
*** slaine <slaine!~slaine@> has joined #yocto07:32
*** francois99 <francois99!> has quit IRC07:41
*** francois99 <francois99!> has joined #yocto07:41
lpappwmat: do you know how to use the meta-sourcery layer?07:43
-YoctoAutoBuilder- build #234 of nightly-x32 is complete: Failure [failed Running Sanity Tests] Build details are at
*** zeeblex <zeeblex!~apalalax@> has joined #yocto07:45
*** eren <eren!~eren@unaffiliated/eren> has quit IRC07:48
*** ant_work <ant_work!> has joined #yocto07:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:49
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC07:49
*** panda84kde <panda84kde!> has joined #yocto07:51
bluelightningmorning all07:54
rburtonmorning bluelightning07:54
*** ivali <ivali!ivali@unaffiliated/ivali> has joined #yocto08:04
*** ericben <ericben!> has quit IRC08:04
*** ericben <ericben!> has joined #yocto08:06
*** JimBaxter <JimBaxter!> has quit IRC08:11
*** JimBaxter <JimBaxter!> has joined #yocto08:18
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto08:21
*** ivali <ivali!ivali@unaffiliated/ivali> has quit IRC08:22
dzoeHi, I'm back with another (probably really stupid) question. How do I get ttf-dejavu-anything built? In meta-openembedded layer, there are a few tasks that depend on it (fonts-*), but I cannot find where to get the recipes. There's only some .inc in meta-oe/recipes-graphics/ttf-fonts. Perhaps I'm overlooking something ...08:22
bluelightningdzoe: which branch are you on?08:24
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto08:27
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.> has joined #yocto08:28
bluelightningdzoe: bitbake ttf-dejavu should build all of the ttf-dejavu-* packages08:28
bluelightningdzoe: (or indeed bitbake anything-depending-on-ttf-dejavu-*)08:28
ereno/ morning08:29
*** frank <frank!~frank@> has joined #yocto08:30
dzoeMea culpa ... I was searching outdated tree from some older experiment where we had those recipes deleted... Sorry for asking stupid questions...08:30
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC08:30
bluelightningdzoe: no worries08:31
melonipoikaI have a most probably stupid question too, but here it goes :-)08:32
melonipoikai am trying to build a headless machine and i would like it to run a vnc server08:32
melonipoikai have x11vnc instaleld in my image08:32
melonipoikabut i am missing x08:32
*** lpapp <lpapp!~lpapp@> has joined #yocto08:32
melonipoikai think i should install xvfb, but can't find it in any layer08:33
erenwhat's the default behavior of PACKAGECONFIG? (regarding to the latest commit from JaMa)08:33
lpappso is it just me, or I cannot really edit comments on bugzilla?08:33
eren+PACKAGECONFIG ??= ""08:33
erenPACKAGECONFIG[cap] = "--with-libcap,--without-libcap,libcap"08:33
rburtonlpapp: correct, bugzilla comments are immutable08:33
erenby default, then, no PACKAGECONFIG is given for the package08:33
erenso, "cap" is disabled by default?08:33
rburtoneren: correct08:33
erenthen, --without-cap is given08:33
melonipoikais xvfb the way to go, or is there any other better approach?08:33
erenif it were "PACKAGECONFIG ??= "cap" assignment, it means that it's enabled by default08:34
rburtoneren: yep08:34
erenoh, okkie. thanks!08:34
rburtonmelonipoika: xvfb sounds like a good idea08:35
lpappthat is a very unfortunate limitation...08:35
lpappis that a feature or bug?08:35
erenJaMa: how did you manage to detect these options from sysroot? I mean, the autodetection of libraries and enabling automatically while the package is being built08:36
melonipoikarburton, thanks. Do you know what layer provides xvfb?08:36
rburtonmelonipoika: i suspect it might be in meta-oe08:36
melonipoika(i ma using arago and my target hw is a TI TCI6638 EVM)08:36
lpappI am getting an error from the denzil branch when running bitbake ...
lpappwith a brand fresh checkout for the branch.08:37
lpappERROR: Unable to parse /home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf: [Errno 2] No such file or directory: '/home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf'08:37
rburtonlpapp: you need a new bblayers08:38
rburtonlpapp: as meta-yocto-bsp didn't exist in denzil08:38
rburton(still need a second coffee)08:38
lpappI love error messages, have I ever mentioned? :)08:38
rburtonits a perfectly good error message08:38
rburtonyou told it to load a layer, that layer doesn't exist08:38
rburtonDEBUG: Adding layer /home/lpapp/Projects/poky/meta-yocto-bsp08:39
rburtonDEBUG: LOAD /home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf08:39
rburtonERROR: Unable to parse /home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf: [Errno 2] No such file or directory: '/home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf'08:39
rburtonnot sure how much more concrete that could be to be honest08:39
lpappit is perfectly good for you.08:39
lpappbut I doubt it is perfectly good for a user, like me.08:39
rburtonlpapp: how could it be improved?08:39
lpappwell, it could be a lot more concrete.08:39
rburtonits incredibly concrete08:39
lpappI was about to open a bugreport.08:39
lpappit is not?08:39
rburtonI'm adding a layer / i'm opening this specific file / that specific file doesn't exist08:39
rburtonit told you what layer its trying to add, and what file it can't find08:40
lpappwhich is wrong, yes.08:40
bluelightninglpapp: ?08:40
lpappplease be patient08:41
lpappas I said, I was already opening a bugreport for it.08:41
ant_worklpapp: to sum up 2-3 days of logs, I think the things you are asking for a better "user" experience (automatic bblayers editing, adding layers, some customization) are done fundamentally HOB. It is still WIP.08:43
ant_worklpapp: normally *developers* are building the images and users are just expected to update packages on target08:44
lpappbluelightning: rburton
yoctiBug 4909: normal, Undecided, ---, richard.purdie, NEW , Improve the error message for tray bblayers.conf files08:45
lpappant_work: user experience is *not* tied to a frontend.08:45
lpappant_work: any frontend should be usable.08:45
erenI'm a little bit confused about what SRCPV actually does. I've realized that all git recipes use SRCREV, and assign PV = "<version_of_pkg>+git${SRCPV}". Why don't they use +git${SRCREV} ?08:45
lpappant_work: and no, I do not like HOB. I actually very much dislike gtk.08:45
erenI believe the current documentation is not clear on the variable either.08:46
eren"Returns the version string of the current package. This string is used to help define the value of PV."08:46
ant_worklpapp: neverthless, it has many of the automatisms you're asking for08:46
ant_work(I only gave a glimpse, I'm not HOB user fwiw)08:47
*** mihai <mihai!~mihai@> has joined #yocto08:48
lpappant_work: well, thanks for the information, but I am not going to use HOB.08:48
lpappI also think that HOB is the wrong layer to address it at.08:49
lpappsome of the things should be addressed on the bitbake layer.08:49
lpapprburton: bluelightning
lpappthis is with the denzil branch, poky, and beagleboard08:51
lpappI cannot get any branch working with an external toolchain. :(08:51
rburton| automake.texi:13043: @itemx must follow @item08:52
rburtonlooks a lot like the problems caused by new texinfo08:52
lpappalso this: ERROR: Execution of event handler 'csl_version_handler' failed08:52
lpapptexinfo 5.1 in her.08:52
rburtonyeah, that caused errors all over the place08:53
lpappbut I would be interested in the other error, too.08:53
rburtontry changing that CmdError to bb.process.CmdError08:53
lpappah, yeah, that was fixed by us.08:53
lpappshould probably be fixed in upstream, too.08:56
lpappit would be nice to give a last go to meta-sourcery before leaving Yocto.08:56
rburtoncommit caee06405f90d44b3476af645e2b3918578ba6b908:56
lpappbut to be honest, I am not even sure what I am supposed to do with it.08:56
rburtonAuthor: Christopher Larson <>08:56
rburtonDate:   Tue May 15 20:28:24 2012 -050008:56
rburton    csl-versions: fix bb.process.CmdError reference08:57
rburtonyou can cherry-pick that into your denzil branch08:57
lpapprburton: I meant the denzil branch.08:57
lpappI fixed that on my own before.08:57
lpappanyone having any idea how one is supposed to use the meta-sourcery layer?08:57
rburtonlpapp: if you backport it you can send it to oe-core tagged for denzil08:58
lpapprburton: too much effort that I do not have time for.08:58
ant_worklpapp: maybe I missed it, why don't you consider using the native toolchain? You have patches to coreutils? Add patches in your layer.08:58
lpappant_work: I do not have any patches to core utils ...08:59
lpappant_work: huh?08:59
lpapparm native toolchain on non-arm?08:59
lpappthat is kinda joke?08:59
*** belen <belen!Adium@nat/intel/x-pntzefjzityjsnij> has joined #yocto08:59
ant_worklpapp: built by OE/Yocto08:59
lpappit does not matter who builds it08:59
lpappyou cannot run ARM binary on the host09:00
lpappwithout qemu, and other slow stuff09:00
ant_worklpapp: try to understand, I mean NO EXTERNAL TC09:00
lpappthat is not a native toolchain09:00
*** belen <belen!Adium@nat/intel/x-pntzefjzityjsnij> has left #yocto09:00
lpappthat is non-external non-native.09:00
lpappi.e. internal cross-toolchain.09:00
*** belen <belen!Adium@nat/intel/x-pntzefjzityjsnij> has joined #yocto09:01
lpappbecause we do not wanna build it.09:01
lpappit takes time, and we do not have time for things that exist in binary forms off-hand.09:01
ant_workthose are the reasons?09:01
lpappyes, plus the lot of effort for refactoring.09:02
lpappthose are all blocker reasons09:02
ant_worklpapp: I think you're missing the Yocto goals09:03
lpappant_work: our project is not Yocto09:03
lpappwe have different goals.09:03
lpappso yes, of course we miss the Yocto goals.09:04
lpappso if I integrate this meta-sourcery, what am I supposed to set in my conf/layer.conf?09:06
lpappor in bblayers.conf if any?09:06
*** sameo <sameo!~samuel@> has joined #yocto09:06
lpappis it just me being silly?09:09
lpappand it is trivial?09:09
lpappor is it something to ask from the MG guys?09:09
bluelightninglpapp: you complain about time, but the fact of the matter is if you had just gone with the internal toolchain you'd likely have your working build by now...09:09
lpappbluelightning: stop this please.09:09
lpappit is not productive.09:09
lpapphow did you know for *sure* it was going to cause issues?09:09
lpappalso, are you aware of the cost a full stack refactoring in a company?09:09
lpappare you also aware of the fact developers *do* dislike the slow builds?09:10
lpappalso, I am *not* complaining.09:10
lpappI am stating facts.09:10
bluelightninglpapp: but you immediately ignore the default option which is tested and works09:10
lpappwell, if you call that complaining, that is fine.09:10
lpappbluelightning: you do not wanna realize what I wrote09:10
lpappdevelopers dislike the slow builds, it costs a lot of time to refactor, test, validate, develop, fix bugs and so forth09:11
bluelightningwhy would a "full stack refactoring" even be needed?09:11
lpappeven if the latter took zero effort, which it does not.09:11
lpappthen former argument would stay around.09:11
lpappbluelightning: because it is the damn toolchain09:11
lpappthe very low-part of the stack.09:11
lpappand every part above depending on it.09:11
bluelightningyes, and luckily we have quite a lot of experience building and testing that part09:12
lpapphow is that relevant?09:12
lpappWe need to test our software with it09:12
lpappand we have a huuuuuuge software09:12
lpappit is a different project to change the toolchain if it is every worth it09:13
lpappand not a small project.09:13
lpappwe do not have budget for that now.09:13
lpappmakes sense?09:13
rburtonlpapp: if you are having problems with m-s, then yes, continue talking to kergoth.09:15
lpapprburton: he is ignoring me here even though I unignored him09:15
lpapprburton: and he has not replied for the email queries on the list09:15
lpappI am now filing a bug against meta-sourcery on github09:15
lpappnot sure I can do more.09:15
*** Ramana_ is now known as CK09:18
*** CK is now known as ckris09:18
frankWhen  adding IMAGE_INSTALL += "libnfsidmap", it will be renamed to libnfsidmap0 as param passing to translate_oe_to_smart().09:22
frankWhere is the code made this change?09:23
*** ckris is now known as Ramana_09:23
frankI mean where did the changes to IMAGE_INSTALL or PACKAGE_INSTALL ?09:25
lpapprburton: is that github report clear?09:26
lpappwould you report the same if you were interested in using it, but they do not provide documentation?09:26
bluelightningfrank: I guess you switched from ipk to rpm ?09:26
lpappshould I add any additional information?09:26
lpappbluelightning: I will spend half an hour with the internal toolchain09:27
lpappbluelightning: do you have documentation at hand?09:27
bluelightninglpapp: it's the default option, you shouldn't need to do anything special09:27
lpappbluelightning: ?09:27
lpappbluelightning: I would like to be able to specify the compiler09:28
bluelightninglpapp: just comment out the lines you added to enable the external toolchain and you'll be configured to use it09:28
*** Corneliu <Corneliu!c0c6972b@gateway/web/freenode/ip.> has joined #yocto09:28
lpappwhat architecture, what gcc version, etc.09:28
lpappbecause I would like to use C++11 as much as possible, and C++14 soon.09:28
lpappI would like to build for a particular arm.09:28
bluelightninglpapp: all of that is determined from the MACHINE you have set09:28
lpappbluelightning: that did not fly last time.09:28
lpappbluelightning: it built native x86 binaries09:28
ant_worklpapp: you did not specify a MACHINE09:28
frankbluelightning: not exactly, I just find sometimes, "libnfsidmap" is not renamed with the lib version09:29
lpappant_work: I di.09:29
frankSo, I want to browse the code doing this rename.09:29
ant_worklpapp: # This sets the default machine to be qemux86 if no other machine is selected:09:30
ant_workMACHINE ??= "qemux86"09:30
ant_worklpapp: pls explicitly add MACHINE = "foo" (from your BSP layer)09:31
bluelightningfrank: ok, translate_oe_to_smart() is only used for rpm09:31
bluelightningfrank: I'll find some pointers for you, one sec09:31
lpappant_work: I am not sure what you mean09:31
lpappand where you get that from.09:31
*** sameo <sameo!~samuel@> has quit IRC09:31
lpappI definitely have a different local.conf09:31
lpappno no09:31
frankbluelightning: yes. Thanks a lot !09:31
lpappI have local.conf setup for my environment.09:31
lpappI did not get something blindly which I have never modified.09:31
ant_worklpapp: it looks like smthg went wrong then ;)09:32
ant_worklpapp: if I say 'spitz' I get code for that armv5te09:32
lpappyes, but elsewhere.09:32
lpapp./meta/conf/machine/include/ -> so if I include it, it should build for that.09:32
lpappdylan has gcc 4.7?09:33
lpappI mean arm gcc gnueabi09:33
bluelightningfrank: the actual code that does that is runtime_mapping_rename() in meta/classes/package.bbclass09:33
bluelightningfrank: it's called from meta/classes/image.bbclass09:33
frankbluelightning: Thanks!09:35
bluelightningfrank: it relies on the data in tmp/pkgdata (which is written during do_packagedata or do_package depending on what version of the build system you are using)09:36
lpappbluelightning: I will make a test build09:37
frankbluelightning: Got it !09:37
lpappbluelightning: slow building is definitely better than no building for now.09:37
lpappbut we need to get the MG stuff working in the end of the day.09:37
lpappI consider the internal an interim workaround09:37
lpappprovided it works.09:37
rburtonlpapp: remember you build the compiler once, after that it's in the cache09:38
ant_worklpapp: don't play with the tune files, those are included by the machine.conf09:38
lpappant_work: ?09:38
lpappant_work: we have our own machine09:38
lpappthat is why we have a different layer in the first place. ;)09:38
lpappand our machine includes that.09:38
ant_worklpapp: we maintain machines in an external BSP as well and the machine.conf just includes the tune files of oe-core09:39
lpappI do need to deal with it09:39
lpappi.e. I need to include it in my machine/foo.conf09:39
lpappthat is where the information should come from I believe.09:40
lpappwhether it is building with a cross-toolchain.09:40
lpappbluelightning: it is using cross-toolchain rather than emulated native, right?09:40
bluelightninglpapp: absolutely09:40
lpapprburton: I do not like cache09:42
lpappit is causing hard to debug issues09:42
lpappbluelightning: internal toolchain does not work either. :/09:43
lpappthe busybox error is back from yesterday...09:44
*** melonipoika <melonipoika!> has quit IRC09:44
lpappI guess I should open a bugreport about it now?09:45
lpappI guess I am blocked then with the internal toolchain way as well. :/09:45
rburtonlpapp: remove your layers from bblayer.conf and try a build with qemuarm.09:45
rburtonlpapp: then you can rule out any interaction with your layers09:45
rburtonbecause busybox builds for everyone else09:45
lpapprburton: well, the error is not coming from my layer.09:46
lpappdoes everyone else test with bleeding arch?09:47
lpappperhaps not.09:47
rburtonlpapp: i didn't say it did, but lets reduce the test case09:47
rburtontry a build with no custom layers, and see if that works09:47
lpappyeah, I am doing that.09:48
*** melonipoika <melonipoika!> has joined #yocto09:49
lpapprburton: seems to work with my distro09:49
lpappwhen I add my machine, then it does not.09:49
rburtonsee, useful data point :)09:49
rburtoncan you pastebin your machine?09:49
lpappI am still investigating, and I need to be careful what to paste. :)09:50
lpappit takes me some time.09:50
lpappit is weird09:50
lpappqemuarm -> mymachine09:50
lpappI added it back, and then it works.09:50
lpappagain cache issue?09:50
* lpapp dislikes cache09:50
rburtondoubt it, the cache is keyed on almost everything that can change, and you get a fresh sysroot for every machine.09:51
JaMaeren: see the script in first patch in that patchset09:52
bluelightninglpapp: what are your layers doing with BBPATH ?09:52
lpappbluelightning: ./meta-polatis/conf/layer.conf:2:BBPATH := "${BBPATH}:${LAYERDIR}"09:54
lpappbluelightning: ./meta-foo/conf/layer.conf:2:BBPATH := "${BBPATH}:${LAYERDIR}"*09:54
lpappso just something that everyone else does.09:54
bluelightninglpapp: ok... was just trying to rule out that maybe the layer was picking up the wrong file with something odd in BBPATH09:55
lpappbluelightning: it is working noqw09:56
lpappI did not do anything else than switching to qemuarm and then back09:56
lpappand I deleted the cache in the meantime.09:56
lpapplock file tmp sstate cache etc09:56
lpappeverything really.09:56
lpappexcept conf09:56
lpappI still think it is nasty to have conf files in build/09:57
lpappotherwise I could do rm -rf build/*09:57
lpappof course a non-existing tool could help.09:57
lpappif it was getting existent.09:57
lpappbitbake --clean09:57
*** sameo <sameo!samuel@nat/intel/x-izavkbaxeavrydqi> has joined #yocto09:58
rburtonlpapp: personally my "build" directory just contains conf/ and the bitbake parse cache, the local.conf then sets TMPDIR and SSTATE_DIR to subdirs in /data/poky-master.10:00
rburtonmainly for disk allocation reasons but also useful for wiping stuff if i really destroy something.10:01
*** dnil <dnil!> has quit IRC10:06
*** Net147 <Net147!> has joined #yocto10:09
lpappahh, internal toolchain crashes10:16
lpappdue to 4.8 vs. 4.7 with gcc.10:16
lpappanyway, we cannot use a new toolchain.10:16
lpappan internal*10:16
lpappI will go for denzil and a support debian in chroot for now.10:16
lpappuntil the guys fix the sourcery issues.10:17
frankIs there a simple method to check what packages are included by a package group ?10:20
lpappoh, debian is not supported. :(10:20
lpappwell, that sucks huge balls.10:20
lpappso basically, I cannot install anything into chroot to get it work10:21
lpappbut I have to use virtualization.10:21
lpappI dislike the vmware/vbox/etc stuff10:21
lpappchroot would be so much more logical for a cli build.10:21
bluelightninglpapp: we do test against debian regularly10:21
erenJaMa: okkie, I will, thanks10:21
lpappbluelightning: the website writes it is not supported.10:22
lpapp -> Debian Wheezy failing.10:23
bluelightninglpapp: the linked report is from 2011...10:24
-YoctoAutoBuilder- build #222 of nightly-world is complete: Failure [failed Building Images] Build details are at
lpappbluelightning: yeah, so update it please.10:27
bluelightninglpapp: to be honest if nobody from QA is keeping that page up-to-date I'd rather see it deleted10:30
Net147bluelightning: the links to it from the documentation should be removed as well then10:31
bluelightningNet147: yes, good point :/10:31
Net147I usually refer to the list of supported distributions in the reference manual - e.g.
lpappbluelightning: I will submit a bugreport.10:33
lpappI dislike wikis10:33
lpappI agree about it being deleted.10:33
bluelightningNet147: right, that should be the canonical reference, since it's derived in a semi-automated manner from the SANITY_TESTED_DISTROS list in meta-yocto/conf/poky.conf10:33
bluelightningand SANITY_TESTED_DISTROS gets updated as a matter of course for every release10:34
yoctiBug 4911: normal, Undecided, ---, scott.m.rifenbark, NEW , Wiki: Distribution Support outdated10:44
bluelightninglpapp: I think you may have pasted the wrong link10:45
bluelightninginto the bug report10:45
lpappbluelightning: whoops10:46
lpappindeed, konsole copy is buggy.10:46
lpapplovely that I cannot edit a comment on bugzilla. :(10:47
bluelightningstandard for bugzilla out of the box I guess10:48
lpappyeah, luckily enough Jira allows it.10:48
*** Krz <Krz!c0c6972c@gateway/web/freenode/ip.> has joined #yocto10:48
*** mulhern <mulhern!> has joined #yocto10:49
*** synthnassizer <synthnassizer!~quassel@> has quit IRC10:49
*** synthnassizer <synthnassizer!~quassel@> has joined #yocto10:49
lpappso does mantis10:49
* lpapp is installing wheezy (7.0).10:52
bluelightninglpapp: you already interact with kde that uses bugzilla, can you edit your comments there?10:53
lpappbluelightning: I am interacting with Qt more.10:54
lpappwhere Jira is in use.10:54
lpappat my company, where mantis.10:54
lpappbluelightning: no, does not allow that either.10:55
lpappnor the meego bugtracker.10:55
lpappnor gcc.10:55
Net147I use Trac which allows editing comments10:55
bluelightningFWIW, I'm a fan of Mantis, I use it on one of the projects I maintain10:57
lpappI have not used Mantis much.10:58
lpappand I do not see it used that much in open source projects.10:58
lpappcan you mention any big open source project using it?10:58
KrzHi guys, I'm using poky dylan-9.0.1 tag, found a problem in poky/scripts/ Basically when 'file' utility is not installed script falls back to lzma compression instead gently drop an error 'file not installed'. Eventually it causes very cryptic error.10:59
bluelightningKrz: hmm, I thought we were building file-native that would avoid that being an issue within the build process - or are you using it externally?11:01
*** ericben <ericben!> has quit IRC11:01
bluelightninglpapp: I don't know of any major one no, but then I haven't checked what they all use11:02
*** swex <swex!~swex@> has joined #yocto11:03
Krzbluelightning: I spotted this error on clean debian-wheezy build without file utility installed. After installing file problem was gone. So I would say in this case Yocto used system file instead of Yocto file. Does that make any sense?11:03
*** ericben <ericben!> has joined #yocto11:05
*** swex__ <swex__!~swex@> has quit IRC11:06
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC11:07
*** frank <frank!~frank@> has quit IRC11:08
bluelightningKrz: I guess so, I'd have to look at where rpm2cpio would be called and see if we need a dependency added there11:08
bluelightningKrz: Ideally it would have its own check and error if file is not available since it's a script that can be run externally11:08
lpappsgw1: is there anyone still investigating about the CS external toolchain issue?11:10
*** frank <frank!~frank@> has joined #yocto11:10
Krzbluelightning: either own check + error or some replacement for file. I think the same can be done without file, using only awk which is Yocto known dependency11:10
bluelightningKrz: right... would you mind filing a bug for that issue so it is tracked?11:11
Krzbluelightning: yes, I can do that. I requested access to Yocto bugzilla, but didn't receive activation email :(. Probably some email filters.11:11
bluelightningKrz: ah ok... if you continue to have problems with getting the activation email you might want to talk to halstead11:12
* dzoe sighs ...11:13
dzoeCompiling ttf-dejavu works, but building image that includes it results in: | Unable to resolve package ttf-dejavu11:13
dzoeShould I try something more than bitbake -f -c compile ?11:14
Krzbluelightning: ok, have access to Is the Build System & Metadata -> BitBake the right place for scripts/ related problem?11:18
lpappwhen is the next dylan bugfix release expected to come?11:20
*** lpapp <lpapp!~lpapp@> has quit IRC11:33
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC11:34
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto11:36
bluelightningKrz: it's not bitbake, it's OE-Core11:37
bluelightninglpapp: I don't think a date has been set, but I think it's likely to be over a month away11:39
bluelightningdzoe: maybe it's a case that the ttf-dejavu package itself is empty and only ttf-dejavu-xyz packages get produced?11:40
lpappbluelightning: phew...11:40
lpappthat is a lot of time  ....11:42
lpapp1.3.2. Required Packages for the Host Development System11:42
lpappdebian is not there and supported, really?11:42
lpappanother bugreport to file against bugzilla?11:42
rburtonbluelightning: hm, i think i just realised that the long pauses i see after bitbake finishes with "0 tasks remaining" is buildhistory writing (huge amounts of git activity in ps).  can that easily write something to the console so there's the perception of progress?11:43
rburtonlpapp: yes. it would just be a copy of the ubuntu section, anyway.11:44
dzoebluelightning: I'm not sure, tmp/pkgdata/all-poky-linux/runtime/ttf-dejavu-sans-mono looks reasonable after bitbake ttf-dejavu, but bitbake ttf-dejavu-sans-mono yields "ERROR: Nothing PROVIDES 'ttf-dejavu-sans-mono'"11:44
rburtonlpapp: the section above does say debian 6 and debian 7, fwiw11:45
lpapprburton: not necessarily, no11:45
lpappdebian is not ubuntu after all.11:45
lpappanyway, even if it should be the same which I dislike, but let us say it is11:45
lpapp1.3.2.1 should be Ubuntu _and_ Debian11:46
lpappso bugreport is being created.11:46
rburtonfor the base development stuff if the package names are not identical i'd be massively surprised11:46
yoctiBug 4912: normal, Undecided, ---, scott.m.rifenbark, NEW , No "Required Packages" mentioned for Debian11:47
bluelightningdzoe: when you do "bitbake xyz", the xyz is a built-time target, i.e. a recipe or a recipe variant11:48
volkerwhat's the best way to add an environment variable to a new RootFS image, so that it is available after starting up the embedded system11:48
bluelightningdzoe: ttf-dejavu is a build-time target, ttf-dejavu-sans-mono is a runtime package so "bitbake ttf-dejavu-sans-mono" would be invalid11:48
*** Net147 <Net147!> has quit IRC11:49
bluelightningdzoe: however, IMAGE_INSTALL takes runtime packages so adding ttf-dejavu-sans-mono to IMAGE_INSTALL is valid11:49
dzoeWhich means I should build ttf-dejavu and include ttf-dejavu-sans-mono?11:49
bluelightningdzoe: if you have to build it explicitly at all - just adding it to IMAGE_INSTALL (or RRECOMMENDS of another package if appropriate) will ensure it is built automatically11:49
bluelightningdzoe: (adding ttf-dejavu-sans-mono that is)11:50
dzoeI'd expect that, but that's what (I think) failed, gonna try again ... maybe I'm just overlooking something again.11:50
bluelightningrburton: yeah I do have a patch around here somewhere to do just that11:50
bluelightningvolker: I think you should just be able to install a script setting the vars (with export) in ${sysconfdir}/profile.d/ and that should be all that's needed11:53
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto11:54
volkerbluelightning: thanks, will try that11:55
*** arky <arky!~arky@> has joined #yocto11:57
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto12:26
*** davest <davest!Adium@nat/intel/x-wfogpkawhxinguhi> has joined #yocto12:28
lpapp -> why am I getting error for bitbake on wheezy?12:29
bluelightninglpapp: your chroot is missing /dev/shm12:38
bluelightninglpapp: current versions check for the existence of that file and give you a proper error12:39
lpappbluelightning: weird12:39
lpappbecause /dev is mounted from fstab.12:39
lpapp-> /dev/shm is there.12:39
lpappbut it is empty.12:39
lpappjust like on the host12:39
bluelightningok, not sure then, but errors usually only happen in that part of the code because /dev/shm can't be used12:40
lpappso wheezy will not work either? :(12:40
lpappwhat will work for Yocto then, seriously?12:40
bluelightningseriously, the list of distros/versions we test for every release12:41
lpappthe listed distribution does not work for me?12:42
lpappI am reporting a bug again, sigh, but I do not think I can wait for any bug fixed.12:43
lpappcan anyone actually mention a setup where it should work?12:44
lpappI am disappointed at large that even a reference platform is broken. :(12:44
ant_workGentoo is not listed but working12:44
lpappok, so that is a complete no go.12:44
ant_worklpapp: you should really start a basic build for qemuarm12:44
ant_workthen add the layers one by one12:45
lpappactually, this issue, just like the other upstream, has nothing to do with layers.12:46
*** tor <tor!> has quit IRC12:48
*** tor <tor!> has joined #yocto12:49
bluelightninglpapp: I know of several people who are using debian in a chroot to do builds on a regular basis, so it is possible12:49
*** davest <davest!Adium@nat/intel/x-wfogpkawhxinguhi> has quit IRC12:50
bluelightninglpapp: but it's not a configuration we ever regularly test12:50
bluelightningnor did we ever claim anywhere that it was12:50
lpappdebian wheezy is mentioned as a supported distribution.12:50
lpappanyway, let us start off with a bugreport.12:51
*** JaMa <JaMa!> has quit IRC12:51
ndechow to build OE, on Arch, using LXC and Debian.12:51
bluelightninglpapp: yep, but when you run a chroot of debian that is *not* the same thing as running debian12:51
ndeci casually build dylan on ubuntu (12.04, 12.10, 13.04), and Debian/sid. and some of my team members use OpenSuse.12:52
lpappndec: ?12:52
lpappbluelightning: how do you *really* know it is a chroot issue?12:53
ndeclpapp: also, i assume what you don't run as root, in your chroot. i have never tried, but i expect it might not work fine.12:53
lpappndec: I have always used stuff as on the host12:53
lpapphave never had any issues12:54
lpappthis is not the first I am using debian in chroot12:54
lpappwe had to use that back then for meego, too.12:54
lpappalso, please note that sudo bitbake will not fly.12:54
lpappbluelightning: it *might* just well be a generic debian issue12:55
lpappunless you prove it *is* a chroot isuse.12:55
wmatlpapp: re. meta-sourcery layer, you add it to bblayers.conf to use it12:57
lpappwmat: that is all?12:57
wmatlpapp: here's an example of how the xilinx folks use it ->
wmatlpapp: see the README12:58
lpappwmat: README of?12:58
wmatof that Github link, just scroll down12:58
lpappok, so the README of meta-xiling12:59
lpappand not meta-sourcery, or something else.12:59
rburtonlpapp: i can tell you for sure that debian is a working host, as i've been using it non-stop for over a year now12:59
lpapprburton: any idea then?12:59
rburtonlpapp: presumably the permissions on your /dev/shm are wrong?12:59
ant_workwmat: please be more precise12:59
rburtonlpapp: the error says permission denied, to check the permissions.12:59
lpappwmat: ok, better to make sure12:59
wmatant_work: more precise?13:00
lpapprburton: 75513:00
lpapprburton: 777 on the host13:00
lpappand I cannot assign +w to it.13:00
rburtonlpapp: well that's the problem13:01
rburtonnothing to do with bitbake, but a bad chroot13:01
lpapprburton: ?13:01
lpappsudo LANG=C.UTF-8 chroot /mnt/wheezy /bin/bash -l -> this is the right way to chroot.13:01
lpappand this is how it is mounted: /dev /mnt/wheezy/dev auto bind 0 013:02
lpappfull of regular stuff13:02
rburtonsure.  i meant the contents of the chroot when you are in it, is wrong.  your /dev/shm isn't world-writable.13:02
lpappcould you please clarify why it is a *chroot* issue?13:02
lpappright, so it is not a chroot issue13:02
rburtonbecause its different inside and outside the chroot?13:02
rburtonffs, this is just semantic bullshit13:02
rburtonyour /dev/shm has the wrong permissions.13:03
rburtonthat's the problem13:03
rburtonlets not play games at identifying exactly who is to blame so we can glare at them13:03
*** arky <arky!~arky@> has quit IRC13:03
rburtonlets just fix the permissions13:03
lpappI do not like people when they think it is a chroot issue13:03
lpappand they can free up their hand13:03
lpappI think it is very important to get it straight.13:04
lpappalso, I am about to submit another bugreport13:04
lpappit should suggest /dev/shm in some way.13:04
lpappthis is again something totally mysterious to me.13:04
lpappI would have never guessed it.13:04
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-czxmiquuhmncwnvt> has joined #yocto13:06
bluelightninglpapp: that's not our code, that's python multiprocessing13:07
bluelightninglpapp: and we already have a check in master for that, so no bug report needed13:07
lpappthe error is coming from bitbake.13:07
lpappbitbake should know what it is doing.13:07
bluelightninglpapp: check the code path13:07
lpappyou can hardly blame upstream.13:07
bluelightningwhich has been merged as
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-tqufjvqiiiryfgqg> has joined #yocto13:09
lpappbluelightning: I do not like that change.13:09
lpappso I will submit a bugreport/change13:09
* rburton lols13:09
bluelightninglpapp: ?13:09
lpappI think the exact issue could be specified without the option.13:09
bluelightningwhat option?13:09
lpappyou do not need to give a list of issue that can go wrong.13:09
lpappyou can directly give the *offending* issue.13:10
lpapplist of issues*13:10
*** behanw <behanw!> has joined #yocto13:11
lpappbluelightning: agree?13:12
bluelightninglpapp: I honestly don't think it's a big deal, but if you feel motivated to write a patch to split it out into separate checks and corresponding errors, please feel free to send a patch that does that13:14
yoctiBug 4914: normal, Undecided, ---, richard.purdie, NEW , Not talkative enough error message for /dev/shm issues13:14
lpapprburton: lols ?13:15
lpappbluelightning: I have never said it is a big dela.13:15
lpappbut small deals are not welcome, or what?13:15
*** frank_fighting71 <frank_fighting71!~frank@> has quit IRC13:16
*** Krz <Krz!c0c6972c@gateway/web/freenode/ip.> has quit IRC13:18
lpapphmm, none /dev/shm tmpfs defaults,size=1G 0 0 did not help13:18
lpappit is still not writable... :(13:18
rburtondid you verify that your /dev/shm in the chroot is actually a tmpfs?13:20
rburtonwhen i mount a tmpfs, the mode on the mountpoint change to 177713:20
lpappoh, debian uses /run/shm13:20
lpappnot /dev/shm13:20
lpappso bitbake is wrong then.13:20
rburtonno, /dev/shm is a symlink13:20
lpappbut then I actually wonder how it is a supported platform?!13:21
rburtonlrwxrwxrwx 1 root root 8 Jul 15 09:29 /dev/shm -> /run/shm13:21
lpappno no, it is not.13:21
rburtonthat was a ls from my *debian system*13:21
lpappls -ld /dev/shm/13:21
lpappdrwxr-xr-x 2 root root 40 Jul 25 11:33 /dev/shm/13:21
lpapprburton: what is the permission on your /run/shm?13:23
mulhernIf a Perl module is under license Artistic-1.0 and GPLv2 why does the corresponding recipe file use Artistic-1.0 | GPLv2? My question is about changing and to or.13:23
rburtonlpapp: same as all tmpfs, 177713:24
lpapprburton: 755 in here.13:24
rburtonmulhern: my standard reply to anything related to license fields is to say "ask beth" :)13:24
rburtonlpapp: sounds like the tmpfs isn't actually mounted to me13:24
mulhernOK. :)13:24
lpapprburton: you mean from the host.13:24
lpapprburton: you mean, I also need to bind it?13:26
lpappfrom the host to chroot?13:26
rburton              The bind mount call attaches only (part of) a single filesystem,13:27
rburton              not possible submounts. The entire file hierarchy including sub‐13:27
rburton              mounts is attached a second place using13:27
rburtonsays the mount documentation13:27
lpapptmpfs is of course attached to the host system if that is only what you mean13:28
lpappbut it might well be that it needs to be bound to the chroot.13:28
rburtonyes, see the documentation quote i pasted13:29
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC13:29
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-tqufjvqiiiryfgqg> has quit IRC13:39
*** mihai <mihai!~mihai@> has quit IRC13:39
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto13:41
lpapprburton: can you show the relevant lines from your fstab?13:41
lpappI am not getting it.13:41
lpappwhy is bitbake relying on it anyway?13:41
lpappinstead of getting the tmp variable content?13:42
lpappit looks silly to me.13:42
rburtonlpapp: i don't run debian in a chroot13:42
lpappbut you need to get it mounted on the host as well anyway?13:44
rburtonsure, the init system does that13:44
lpappnot from fstab?13:44
*** munch <munch!> has joined #yocto13:46
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-tcycxkqhgdrimiwp> has joined #yocto13:47
lpappwmat: lolz @ INSANE_SKIP_external-sourcery-toolchain-dev += "ldflags"13:47
lpappwmat: have you tried PREFERRED_PROVIDER_virtual/*13:48
lpappwmat: why is meta-xilinx using TCMODE = "external-csl"?13:57
lpappinstead of TCMODE = "external-sourcery"?13:58
*** ant_work <ant_work!> has quit IRC14:03
*** ericben <ericben!> has quit IRC14:03
*** ericben <ericben!> has joined #yocto14:05
lpapprburton: bluelightning wmat got a clue ?
rburtonNOTE: preferred version 141 of udev not available (for item udev-utils) says your distro config still thinks its (probably) denzil14:08
rburtonthe pseudo problem is just incredibly frustrating.  the cp says external-sourcery, i thought you were using our own compilers?14:09
lpapprburton: no, we have used external.14:11
lpappwhat is the libpseudo thingie?14:11
rburtonits like fakeroot on steriods14:11
*** andyross <andyross!> has joined #yocto14:12
lpapp-> /home/lpapp/Projects/polatis/Yocto/poky-dylan-9.0.0/foo-builds/tmp/work/armv5te-polatis-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/image/14:12
lpappoh noooes...14:12
lpappthat folder is empty btw14:12
rburtonthe real problem is the cp i suspect, you'll have to debug what its trying to do and what should be there14:12
lpappI removed the udev preference.14:13
lpappwell, I have no clue where to start the debugging.14:13
lpapp"A generic library providing simple thread-safe messaging between threads"14:15
lpapprburton: what is this specifying? INSANE_SKIP_external-sourcery-toolchain-dev += "ldflags"14:21
rburtonlpapp: its disabling a sanity check14:22
rburtonwithout it you'd get a warning, which is presumably a false-positive for that package14:23
*** mihai <mihai!~mihai@> has joined #yocto14:25
*** volker <volker!> has quit IRC14:25
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC14:32
lpappsgw1: ping14:32
sgw1lpapp: good morning14:33
*** sgw1 is now known as sgw_14:33
yoctiBug 4908: normal, Undecided, ---, laurentiu.palcu, ACCEPTED , External toolchain does not work with poky dylan14:33
lpappcan you reproduce the bug at the bottom?14:34
sgw_lpapp: in a bug triage meeting reviewing the bugs now!14:34
lpappI know meta-sourcery is not a yocto project material though, but still, any help appreciated.14:34
*** TuTizz_ <TuTizz_!~TuTizz@> has joined #yocto14:35
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC14:35
lpappalso, no one has reviewed the tiny change yet:
*** TuTizz_ is now known as TuTizz14:36
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto14:36
wmatlpapp: it's using external-csl because it's an older set of instructions14:36
wmatlpapp: I have not tried any of this and unfortunately do not have time to14:36
*** volker <volker!> has joined #yocto14:38
lpappwmat: got a clue about the error though?14:38
denixmelonipoika: that is not even a yocto layer! that is a mirror of a Classic OpenEmbedded oe-dev repository!14:44
wmatlpapp: sort of, in so far as I've seen that pseudo error before on the mailing list14:49
*** zeddii <zeddii!> has joined #yocto14:49
wmatlpapp: see if that post rings any bells regarding your system14:50
lpappI saw that thread.14:51
rburtonif thats the right thread it has a fix in14:51
lpapprburton: what fix?14:52
rburtonif you find the right pseudo thread, there's a fix in it14:52
lpappfile /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc14:52
lpapp/usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped14:52
rburtonby fix i mean possibly hack14:52
lpapphmm, that might be inline with the last suggestion from mark.14:52
lpappI am using x86_6414:52
lpappbut the external toolchain seems to be 32 bit.14:52
lpappwmat: did you find a 64 bit toolchain?14:53
lpappprovided by Code Sourcery?14:53
*** frank_fighting71 <frank_fighting71!~frank@> has joined #yocto14:53
*** swex <swex!~swex@> has quit IRC14:53
lpapphmm, that probably does not matter since we need to generate 32 bit target.14:53
lpappalthough a 64 bit compiler should be able to do that, but still.14:54
lpappFinally, you can get this message if you are on a mixed-mode (multilib) host.14:54
lpappI.e. you have executables that are both ELF 32 and ELF64.  If so, you need to14:54
lpappconfigure the system to build pseudo with both target environments, otherwise14:54
lpapponly one version is generated and you'll get an error when the "other" type is14:54
lpappbeing executed.14:54
lpapphow to configure the system so?14:54
rburtonlpapp: target arch is unrelated to host arch14:56
lpapprburton: so?14:57
rburtoni was answering your "hmm, that probably does not matter since we need to generate 32 bit target. / although a 64 bit compiler should be able to do that, but still." line14:58
rburtonjust trying to be helpful14:58
lpappok, I think either way is fine.14:58
lpappCS probably pushes 32 bit binaries14:59
lpappI guess I do not need to install libpseudo on my host?14:59
rburtonbitbake builds pseudo15:00
lpappwell, I have no clue to be honest.15:00
lpapp"If so, you need to configure the system to build pseudo with both target environments" -> what is that supposed to mean?15:00
rburtonlpapp: seebs is your best person to speak to about pseudo15:01
lpappit is pretty hard to get Yocto work with an external toolchain.15:04
lpappI would not be envy for pastime people who cannot even spend 8 hours a day with getting it right.15:04
rburtonthis pseudo problem isn't related to external toolchains, and i've made it appear and disappear here by changing unrelated variables15:05
lpappshouldn't the layer providers put example config files and README into their layer?15:05
lpappwell, the critical issue is the toolchain in here.15:05
rburtonlpapp: yes, that's a requirement for the yocto compatible badge15:06
lpapprburton: ok, so meta-sourcery is not like that just yet.15:07
rburtonits a mentor project15:07
lpapprburton: should I file a bugreport about the libpseudo thingie?15:08
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.> has quit IRC15:08
rburtonlpapp: pretty sure there's already one15:09
yoctiBug 4843: normal, Medium, 1.5, paul.eggleton, NEW , Issue with pseudo on 64-bit build host15:09
lpappheh, this would be fun, too:
yoctiBug 4063: enhancement, Medium, 1.5, peter.seebach, NEW , pseudo's logging and diagnostics are not very clear15:10
*** swex <swex!~swex@> has joined #yocto15:12
lpapp -> added a comment, and changed to accepted.15:14
yoctiBug 4843: normal, Medium, 1.5, paul.eggleton, ACCEPTED , Issue with pseudo on 64-bit build host15:14
lpappbravely... /me runs15:14
*** arky <arky!~arky@> has joined #yocto15:15
rburtonlpapp: i hope by "set you accepted" you meant "i took the bug"15:15
lpappI wonder why seebs is not added to that report though?15:15
lpappnow, he is.15:16
lpappno escape... :-)15:16
lpappsorry seebs15:16
rburtonlpapp: btw my comment on that bug was in polite mode. please don't mess with bugzilla state.15:16
lpappbluelightning: do you work on 4843?15:17
lpapprburton: well, it is accepted15:17
lpappas I plan to work on it if no one does already.15:17
lpappbut if someone already does, then it is accepted again.15:18
rburtonlpapp: take the assignee then15:18
lpappsee the question above to bluelightning15:18
rburtonas i said, accepted means "i am literally working on it right now, and expect to send a well-tested patch"15:18
rburtonif that isn't your intention then don't take the accepted state15:18
rburton(and if it is, then take the assignee too)15:18
panda84kdeHi guys. I've googled but didn't found useful links. How do I change keyboard layout in yocto?15:18
lpappwhat is the point of having an assignee without being accepted?15:18
rburtonlpapp: i've got 30 bugs.  am i working on them all right now? no.15:20
lpapprburton: sounds bad then15:21
*** JaMa <JaMa!> has joined #yocto15:21
lpappbecause others need to poke you if you work them or not.15:21
lpappor just forgot to take it.15:21
lpappanyway, I do not see the point of assignee without actual working.15:21
*** frank_fighting71 <frank_fighting71!~frank@> has quit IRC15:26
lpappis there an example how to set up an own local mirror, sstate, etc?15:28
wmatlpapp: I believe that's in the YP documentation15:29
rburtonlpapp: the short version is "share it, somehow".  NFS/CIFS/HTTPD will all do.15:30
lpapprburton: I mean what do I need to do in the yocto repository to recognize the mirror15:30
rburtonlpapp: that's in the docs15:30
lpappah, SSTATE_MIRRORS15:31
lpappmaybe ...15:31
rburtonyou can have a local download mirror too15:31
lpappdoes it work on localhost15:31
*** Stygia <Stygia!> has joined #yocto15:33
*** Stygia <Stygia!> has quit IRC15:36
*** Stygia <Stygia!> has joined #yocto15:36
*** slaine <slaine!~slaine@> has quit IRC15:38
*** davest <davest!~Adium@> has joined #yocto15:44
*** zeddii <zeddii!> has quit IRC15:49
*** seebs <seebs!> has quit IRC15:52
*** Stygia <Stygia!> has quit IRC15:53
*** zeeblex <zeeblex!~apalalax@> has left #yocto15:53
*** seebs <seebs!> has joined #yocto15:54
-YoctoAutoBuilder- build #223 of nightly-arm is complete: Success [build successful] Build details are at
*** Umeaboy <Umeaboy!> has joined #yocto15:55
*** davest <davest!~Adium@> has quit IRC15:56
*** belen <belen!Adium@nat/intel/x-pntzefjzityjsnij> has quit IRC15:58
*** Stygia <Stygia!> has joined #yocto15:59
*** eballetbo <eballetbo!> has quit IRC15:59
*** seebs <seebs!> has quit IRC15:59
*** pidge <pidge!> has joined #yocto16:00
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:01
*** belen <belen!Adium@nat/intel/x-hyonfkukqfwuuapa> has joined #yocto16:01
*** cetola <cetola!> has joined #yocto16:02
*** Corneliu <Corneliu!c0c6972b@gateway/web/freenode/ip.> has quit IRC16:02
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:02
*** seebs <seebs!> has joined #yocto16:03
lpappseebs: ping16:04
lpappcan someone repaste the container log again?16:17
lpappinstead of chroot, there was some arch systemd thingie16:17
*** sameo <sameo!samuel@nat/intel/x-izavkbaxeavrydqi> has quit IRC16:17
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC16:18
lpappno no, there was an arch and debian specific link16:19
lpappwith oe particularly. :)16:19
lpappthe guy on the link just forgot to explain why it is needed.16:19
lpappbut apparently, you cannot create symlinks inside chroot.16:19
lpapponly hard link.16:19
rburtonyou can't symlink from inside to outside16:19
rburtonbut you can symlink inside a chroot16:20
kergothhuh, that's interesting, hadn't seen that systemd command16:20
kergothtoo bad it's part of systemd :)16:20
* lpapp needs the oe/arch/debian link again16:21
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-tcycxkqhgdrimiwp> has quit IRC16:23
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nrqmtzpofsaxriqj> has joined #yocto16:23
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nrqmtzpofsaxriqj> has quit IRC16:23
*** davest <davest!~Adium@> has joined #yocto16:26
lpappI found the root cause of the issue!16:28
*** mulhern <mulhern!> has quit IRC16:30
*** Stygia <Stygia!> has quit IRC16:31
lpappNOTE: Your conf/bblayers.conf has been automatically updated.16:31
lpappNOTE: Your conf/bblayers.conf has been automatically updated.16:31
lpapphuh ?16:32
*** lgammo <lgammo!a12ce17f@gateway/web/cgi-irc/> has joined #yocto16:32
lpapp1) I hate magics.16:32
lpapp2) Nothing changed in that file.16:32
rburton1) distro build systems are 90% magic16:32
rburton2) presumably a false-positive16:33
lpappmajority does not make it right ... ;)16:33
*** Umeaboy <Umeaboy!> has quit IRC16:33
*** davest <davest!~Adium@> has quit IRC16:33
*** arky <arky!~arky@> has quit IRC16:33
rburtonyou can't complain that a tool is doing something trivial and automated for you if you're using a build system16:34
lpapptrivial and automated != magics16:35
lpappit should tell me what is doing and why.16:35
lpappbut at least the what.16:35
lpappUpdating xz ...16:35
lpappeven "magic tools" do that.16:35
lpapplooks like another bugreport to me.16:35
lpappis it possible that poky/master has not changed since yesterday?16:36
lpapplast commit 30 hours ago16:36
lpappthat is fine.16:36
lpappI wonder if anyone has time to reproduce my issue?16:37
rburtonlpapp: it re-formatted a statement, grep for that message and you'll see16:37
lpappwith cloning poky, meta-sourcery, and then I can give two config files?16:37
lpappthe issue should show up very early after running bitbake.16:37
lpappI can reproduce it easily without my layer ...16:37
lpappyet, kergoth claims he cannot.16:37
lpappI suspect he has something different locally.16:37
rburtonwasn't there a comment in the bug you filed where sgw_ said he can replicate?16:37
*** mulhern <mulhern!> has joined #yocto16:37
rburtonif its the bug i'm thinking of, there is someone looking at it16:38
lpapprburton: that was with oe-core sourcery16:38
lpapprburton: not with the supported meta-sourcery from MG.16:38
rburtonlpapp: for that, speak to MG16:38
lpapprburton: no no, I mean someone here16:38
lpappwho can spend a few minutes with it16:38
lpappbecause it is currently 1:!16:38
lpappI can reproduce, kergoth cannot16:38
lpapphe would love to help according to the comment16:39
lpapphe just cannot reproduce the issue.16:39
lpappand I can, even with a brand new clone16:39
lpappmeh, I cannot attach the config files to github16:40
lpappthey only support images16:40
*** mihai <mihai!~mihai@> has quit IRC16:40
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:41
*** Umeaboy <Umeaboy!> has joined #yocto16:41
*** Guest89262 <Guest89262!~tbn@> has quit IRC16:46
* lpapp desperately needs bitbake --clean16:46
sgw_lpapp: I was about to reproduce the pure oe-core issue that you filed yesterday and someone was looking into it overnight in EU, unfortunately no progress was made and I will not be able to spend too much time on it today due to my other responsibilities.  I understand it's currently blocking you.16:46
lpapprm -rf bitbake.lock cache/ downloads/ sstate-cache/ tmp/16:46
lpappit is very annoying to do this all the time manually.16:47
sgw_lpapp: I have not attempted to reproduce the meta-sorcery issue as that is MG's responsibility as rburton pointed out.16:47
*** belen <belen!Adium@nat/intel/x-hyonfkukqfwuuapa> has quit IRC16:47
lpappyeah, but any volunteer is more than welcome for a few minutes testing. :)16:48
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-arbcqniygiuoexsh> has joined #yocto16:48
lpappsgw_: well, I guess the oe-core sourcery support is not the official way anyhow.16:51
lpappat least, I guess no one is seriously maintaining that.16:51
*** eren <eren!~eren@unaffiliated/eren> has quit IRC16:51
mr_sciencewe use the codesourcery toolchain with oe-classic/bitbake-1.10.2-arago but i haven't tried external with yocto yet16:53
mr_sciencelpapp: if you can point me to your issue, i can probably try it tonight16:54
lpappmr_science: 490816:54
lpapphopefully solved by that time though. ;)16:54
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-arbcqniygiuoexsh> has quit IRC16:56
kergothregarding the clean thing, you should never need to wipe sstate-cache manually, any metadata changes that affect the output will invalidate the cache and result in tasks being rerun as necessary. neither should you need to wipe bitbake.lock or cache, those are refreshed as necessary also. the only thing i ever wipe, personally, is tmp :)16:56
kergoth(you're unignored now, so we can speed up the test cycle on getting this issue resolved)16:56
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-rpeagkxppdvkwjzv> has joined #yocto16:57
sgw_kergoth: lpapp just as a data point I was able to reproduce the meta-sourcery failure (if all I needed to do was add meta-sourcery to my bblayers.conf) same as the oe-core failure16:58
* lpapp cries for --clear16:58
*** belen <belen!Adium@nat/intel/x-umcxaurgfcnivshl> has joined #yocto16:58
lpappsgw_: yeah, before meta16:59
lpappsgw_: and change external-csl to external-sourcery16:59
lpappif you have not done that yet.16:59
*** swex <swex!~swex@> has quit IRC16:59
kergothsgw_: has the info on my attempts to reproduce, fyi16:59
kergothFYI, I just added NO32LIBS="0" to the meta-sourcery tcmode, to hopefully avoid that being an issue going forward16:59
*** swex <swex!~swex@> has joined #yocto17:00
* kergoth fires up a centos 5.4 VM to test there also17:00
kergoth(oldest test env i have)17:00
sgw_kergoth: lpapp: I did not get the errors now that I moved the layer in bblayers, i tried MACHINE = beagleboard and qemuarm, I only got some preferred version notes about 4.3 for the compiler.17:03
*** ericben <ericben!> has quit IRC17:03
lpappsgw_: what host?17:04
lpappwhat BB_VERSION?17:04
lpappwhat CSL_VER_MAIN?17:04
lpappcan you paste the build configuration as a whole please?17:04
sgw_lpapp: Master on Ubuntu 12.1017:05
lpappalso, have you tried poky master head?17:05
lpapp64 bit or 32?17:05
*** ericben <ericben!> has joined #yocto17:05
sgw_posted to github issue17:06
lpappsgw_: it would have been nice to have the same machine (qemuarm), but ok.17:07
lpappsgw_: your meta-yocto-bsp is different17:08
lpappperhaps due to the machine difference.17:08
lpappsgw_: were you using my config files, third set?17:09
sgw_lpapp: honestly I have lost track, I don't know which set of your local.conf file I have17:09
*** lgammo <lgammo!a12ce17f@gateway/web/cgi-irc/> has quit IRC17:10
lpappit is hard to make comparison that way, unfortunately.17:10
lpappls /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc17:11
lpapp/usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -v17:11
lpappbash: /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc: No such file or directory17:11
kergothsgw_: if he's seeing a 'No such file or directory' error when trying to run an executable that exists, it usually means the dynamic linker is missing, which means he's likely missing the 32 bit libc bits for his distro (I think he still has me ignored)17:18
sgw_kergoth: lpapp: yeah, it might be something like that, because with his third set of local.conf files it is building, we had pointed that we have not tested with arch linux in the past on IRC, so that's where some issue might come in.17:20
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC17:21
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto17:21
lpappkergoth: I have not ignored you for a few days now17:24
lpappwell, I have /usr/lib32/ld-2.17.so17:24
lpappperhaps it is not looking into /usr/lib32, only /usr/lib?17:24
sgw_lpapp: can you do a find for libgcc_s on /usr/lib* and /lib17:24
sgw_or libpthread*17:25
lpappfind /usr/lib -name \*libgcc_s\*17:25
lpappnothing in /lib17:25
sgw_lpapp: it's one of the files that pseudo seems to be failing to link against17:25
lpappfind /usr/lib -name \*libpthread\*17:26
lpappnothing in /lib17:26
lpappright, but it is looking for 32 bit17:26
lpappnote, arch has /usr/lib3217:26
lpappbut those pthread and gcc_s stuff is in /usr/lib32, too17:26
lpappperhaps the stuff is not looking into /usr/lib32?17:26
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:27
sgw_please do a file on both the /usr/lib and /usr/lib32 (should be the actual file I think)17:27
lpappand /usr/bin/ld is definitely 64 bit17:27
sgw_just curious17:27
lpappfile /usr/lib/libpthread-2.17.so17:28
lpapp/usr/lib/ ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=34f9c4c656a433d97f1e95495bc400f1dace7637, for GNU/Linux 2.6.32, not stripped17:28
lpappfile /usr/lib32/libpthread-2.17.so17:28
lpapp/usr/lib32/ ELF 32-bit LSB  shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=8f2c31fd48bd9964607c32037e5cb51a5525e06e, for GNU/Linux 2.6.32, not stripped17:28
lpappfile /usr/lib/
lpapp/usr/lib/ ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2a56ef2d37d3f5f43f3ab657b4e25235cff7b145, stripped17:28
lpappfile /usr/lib32/
lpapp/usr/lib32/ ELF 32-bit LSB  shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=4c82372fdcb4f7058073bc6d06fbdc08bdd01da5, stripped17:28
sgw_Well I am at a loss then, we got past one issue and stumbled on another17:28
kergoth[Requesting program interpreter: /lib/]17:29
sgw_seebs: any ideas why pseudo would fail to link on lpapp's machine?17:29
kergothaccording to a readelf -a on the toolchain gcc17:29
kergothso it expects that to be a 32 bit linker17:29
kergothmake sure that's the case to17:29
* sgw_ biab17:30
seebsNothing obvious, although multilib hosts are a known source of trouble sometimes.17:30
kergoththe latest attached configs on the bug look solid, indeed17:30
* kergoth hasn't tried doing builds on arch in a while, remembers having to deal with /usr/bin/python being python317:31
lpappwhat can I do to fix the issue?17:31
*** pidge <pidge!> has quit IRC17:31
lpappkergoth: that is a one liner fix17:31
lpappadded to your profile and done17:31
lpappanyway, the README extension is unclear to me.17:32
lpappat least, it does not help me understanding how to get over this issue17:32
kergothI've never seen that pseudo build failure before, but it's unrelated to the external toolchain stuff, as its a native recipe17:32
kergothit explains how to use meta-sourcery, I don't know how to make it any clearer than that. you've already followed those instructions, and are now hitting particular issues which are unrelated to configuration17:33
lpappseebs: can you help circumventing the libpseudo issue?17:33
lpappapparently, a define is not enough on the bugreport.17:33
yoctiBug 4843: normal, Medium, 1.5, paul.eggleton, NEW , Issue with pseudo on 64-bit build host17:33
lpappkergoth: it might be not yet related17:34
lpappbut once the libpseudo issue is fixed, it will come back17:34
lpappnote how it was coming after the libpseudo issue before, too.17:34
kergothregardless, issue #9 was about documentation being missing. it's no longer missing. if you get faiulres after getting past the pseudo failure, by all means open a new meta-sourcery bug, or we can continue to wrk against yocto bug 4908.17:35
yoctiBug normal, Medium+, 1.5 M3, laurentiu.palcu, ACCEPTED , External toolchain does not work with poky dylan17:35
lpappwell, documenting the local.conf usage more would be useful.17:36
kergothI don't understand what you're referring to17:36
lpappexternal-sourcery is yet mentioned for instance.17:37
kergoththe readme tells you what needs to be done, completely17:37
kergothit's not mentioend because it's not needed17:37
kergothmeta-sourcery's layer.conf sets it for you17:37
lpappor TARGET_PREFIX17:37
kergoththat's not needed either17:37
lpappperhaps a note would be helpful.17:37
kergothit searches a built in list of commonly used prefixes for sorucery toolchains17:37
lpappbecause it is confusing after coming from the other end17:37
lpappwhere it is needed.17:37
lpappThis is all you need17:37
lpappif you do not wanna be explicit17:37
kergothI'm not going to document everything people might have done following flawed instructions17:37
lpappthat could be a valuable addition to the README.17:38
lpappit is not flawed instruction17:38
lpappit is the official way it was before.17:38
kergothnor does it hurt anything to set those things, as long as they're set correctly17:38
lpappthey are totally irrelevant17:38
*** belen <belen!Adium@nat/intel/x-umcxaurgfcnivshl> has quit IRC17:38
lpappso should not bloat the config if they are not needed.17:38
lpappit should be made clear.17:38
kergothI'm not documenting how to minimize your local.conf. I really don't care how cluttered your local.conf is. that's your doing, not mine17:39
kergothI document what needs to be done, period.17:39
lpappyou are not helping the migration at all.17:39
lpappI really do not understand helping people migrating is not welcome17:39
kergothfrom what, crappy meta-xilinx docs?17:40
lpappit would be a one liner after all.17:40
lpappfrom damn oe-core17:40
lpappyou developer for users, not yourself, right?17:40
kergothTARGET_PREFIX hasn't been necessary in oe-core for years.17:40
kergotheven danny handled it automatically17:40
lpappactually danny is less than a year old only.17:41
lpappbut anyway, documentating a migration path from a certain version ... I do not understand why it is so "bad".17:41
kergothbut as i've already explained, setting those things is *not* a problem17:41
lpappit is for your users come on ...17:41
kergothit's not a migration, its an optimization of your local.conf17:41
lpapplet us ignore each other, and continue over email17:41
lpappif you do not wanna help your users.17:42
kergothgood plan, i'm sick of the whining17:42
lpappI will blog about it, and I will help *your* users17:42
lpappwhat whining?17:42
lpappsuggestion from A F U C K I N G  U S E R17:42
lpappto help others17:42
*** ka6sox is now known as ka6sox-away17:43
* lpapp has never really understood the stubborn developers17:43
*** davest <davest!Adium@nat/intel/x-ulxqaizjltwdzhlh> has joined #yocto17:43
lpappwho argue against doing the work when the main goal should be helping the users as much as possible.17:43
lpappI was not trying to do any favour for myself as I already know the lesson by learning it the "hard way".17:45
lpappsorry guys for the capital stuff17:46
lpappI lost my mind17:46
lpappI apologize.17:46
* mr_science recalls the men-in-white-coats (with the extra long sleeve jackets)17:47
*** Umeaboy <Umeaboy!> has quit IRC17:51
*** panda84kde <panda84kde!> has quit IRC17:51
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC17:54
kergothOkay, there, I think that should address lpapp's concerns about migration without needing to cover what the user may or may not have done, by explaining exactly what's being done for you. I'm not going any further than that. I think this has value for multiple reasons17:58
*** davest <davest!Adium@nat/intel/x-ulxqaizjltwdzhlh> has quit IRC17:59
*** davest <davest!~Adium@> has joined #yocto17:59
*** davest <davest!~Adium@> has quit IRC18:03
*** Bagder <Bagder!~daniel@> has joined #yocto18:07
*** Bagder <Bagder!~daniel@rockbox/developer/bagder> has joined #yocto18:07
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto18:11
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-rpeagkxppdvkwjzv> has quit IRC18:14
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto18:17
sgw_kergoth: seebs: did that pseudo issue get resolved by any chance?18:19
seebsNot yet. I'm still a little unsure on why it only seems to affect a few people. I am pretty sure I am missing some key piece of information.18:20
seebsLooking at it, PSEUDO_LIBDIR should work even if it's set to ../lib, not .../lib64, even on a 64-bit host where is in the lib64 dir, because pseudo knows to add a 64 when setting up LD_LIBRARY_PATH. So I think… I guess what I probably need to do is get a smallish reproducer, if I can, and figure out what the difference is between hosts where it works and hosts where it doesn't.18:22
seebsI'm expecting this to be one of those obvious single-line fixes once I have a working and non-working host to compare.18:22
JaMaseebs: have you ever seen pseudo sqlite db getting broken somehow? When running many builds and comparing files-in-image.txt in buildhistory we have found that some files sometimes get different permissions or owners18:22
JaMaseebs: trying to debug it, I have found that the only difference between those builds was in pseudo.db18:23
JaMaseebs: and that the permissions got modified during do_package task18:23
seebsI have seen some occasionally. In theory, the ways that this is likely to happen should all produce diagnostics in pseudo.log about files being found in the database that mismatch the filesystem in some way.18:23
JaMaseebs: very unfortunate when it happens on /lib/ld-* and it looses executable bit18:24
seebsYeah, that would be pretty bad.18:24
JaMathat's where we have discovered first :/18:24
*** davest <davest!Adium@nat/intel/x-dlajeimdvpzccybx> has joined #yocto18:25
seebsIn theory, pseudo is checking whether both the path and device/inode match between incoming queries and the state of the database. If they don't, the most common cause is that an inode got reused, and something which had been in the database got deleted without the database entry being deleted.18:25
seebsOne cause of that can be, on 64-bit hosts, running a 32-bit binary which relinks stuff, and not having NO32LIBS = "0"18:25
*** davest <davest!Adium@nat/intel/x-dlajeimdvpzccybx> has quit IRC18:25
JaMathat's very likely because we're using 32bit external toolchain18:26
JaMaon 64-bit host18:26
seebsAhh. Yes.18:28
seebsThat would indeed cause that to happen a lot, especially with the prelinker.18:28
seebsSolution is NO32LIBS = "0"18:28
seebsNot that I ever spent two months (1) ignoring some "harmless" messages about failing to load, and (2) trying to figure out why very sporadically builds would be corrupt.18:29
seebsThat would be SILLY.18:29
JaMathanks a lot I never noticed NO32LIBS before18:30
sgw_seebs: should you really be ownong Bug 4843?18:30
yoctiBug normal, Medium, 1.5, paul.eggleton, NEW , Issue with pseudo on 64-bit build host18:30
*** mulhern <mulhern!> has quit IRC18:30
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto18:31
seebsGood question! I am probably the right person in that I know pseudo pretty well, but since I've never been able to get it to happen on any of my systems, I am not well situated to track it down.18:31
mr_sciencei still can't see why pathologically coupling makefiles between different source repos is a good idea...18:37
* mr_science thought developers actually understood issues related to coupling18:37
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-xcccthdknydaomip> has joined #yocto18:41
lpappunignore kergoth18:41
lpappsorry. :)18:41
lpappnot my day, apparently.18:42
mr_scienceat least you're still here...18:47
* kergoth chuckles18:49
*** mulhern <mulhern!> has joined #yocto18:49
kergothJaMa: I just added it to my tcmode now, should probably add it to the example in oe-core too (NO32LIBS)18:50
* kergoth should have done that a while ago, but had it in his distro config instead :)18:50
lpappmr_science: here, but from home, and not in hacking mood.18:50
lpappmr_science: just relaxing and enjoying the sunny evening. :)18:51
*** evanp <evanp!~evan@> has quit IRC18:51
mr_sciencekergoth: where did you move it to?18:51
*** evanp <evanp!~evan@> has joined #yocto18:51
mr_sciencelpapp: not even lunch yet here...18:51
kergothreally belongs in the external toolchain config, since its the execution of external 32 bit binaries that requires it18:51
* kergoth is currently procrastinating doing real work18:51
mr_sciencei think i just found a parallel make bug...18:52
lpappseebs: let me know if you need any information from here.18:53
lpappI am more than happy to collaborate on solving issues.18:53
lpappseebs: err.. one thing18:54
lpappseebs: you think that 64 bit hosts use lib64, but that is not true for Arch18:55
lpappseebs: since 64 bit is the common on 64 bit, they prefer to set /usr/lib to 64 bit by default18:55
lpappand the dedicated minority is /usr/lib3218:55
lpappseebs: setting up arch in chroot is 10 minutes, and I can help with it if that is the only way to move forward.18:56
mr_sciencehmm..  i had a pseudo multilib issue on gentoo amd64 when i tried yocto there18:59
mr_sciencebut i was much more interested in building something than debugging pseudo so i just moved everything to an ubuntu box19:00
mr_sciencelpapp: gentoo is the same way, ie, lib -> lib64 and lib32 sits by itself19:01
lpappI think it makes sense19:01
lpappbecause obviously 64 is the majority on 64 bit19:01
lpappotherwise you would use the 32 bit system19:01
mr_sciencei (almost) always 64-bit native/multilib gentoo installs19:02
kergoththere's really an argument to be made in favor of either approach. multilib configurations vary. which is why yocto lets you configure such paths for multilib on the target, just not for your host, sadly19:03
mr_scienceand usually multilib is only for extraneous crap like firefox plugins19:03
kergothof course some distros are moving to the new multilib setup, where they can even add arm, etc binaries to an x86 system since everything is truly isolated. i personally think they're crazy, but whatever :)19:03
*** sameo <sameo!~samuel@> has joined #yocto19:04
*** ericben <ericben!> has quit IRC19:04
lpappmr_science: yeah, or skype.19:04
seebspseudo does assume that its libraries are in lib/lib64, but then, it also enforces that assumption because it places them in its own directories which are distinct from the directories used by the host.19:04
seebsThus, it's <whatever_path>/pseudo/{lib,lib64}19:05
seebsAnd that is not contingent on what the host uses for /usr/lib* names.19:05
*** ericben <ericben!> has joined #yocto19:05
seebsGoing and doing a thing, might be back later, and I do sort of plan to poke at this, I just keep having other activities also.19:06
lpappwell, it is blocking me right now.19:06
lpappso at least give pointers please if you cannot do the job.19:06
lpappalso, lib32 really is very important to handle.19:06
lpappotherwise several distros will be totally screwed.19:06
lpappperhaps I could even give ssh access to my arch host at home.19:09
*** mulhern <mulhern!> has quit IRC19:10
*** mulhern <mulhern!> has joined #yocto19:14
JaMakergoth: it's well documented in local.conf example but I wasn't expecting that issues we're seeing have so simple well known cause19:16
*** frank <frank!~frank@> has quit IRC19:17
*** JimBaxter <JimBaxter!> has quit IRC19:17
*** agust <agust!> has quit IRC19:17
*** zenlinux <zenlinux!> has quit IRC19:17
*** fitzsim <fitzsim!~user@nat/cisco/x-gatiaonknqjnejaw> has quit IRC19:17
*** jonatan <jonatan!> has quit IRC19:17
*** dv_ <dv_!> has quit IRC19:17
*** fabo <fabo!~fabo@linaro/fabo> has quit IRC19:17
*** rtollert_ <rtollert_!> has quit IRC19:17
*** awafaa <awafaa!uid716@gateway/web/> has quit IRC19:17
*** grifter1881 <grifter1881!> has quit IRC19:17
*** halstead <halstead!> has quit IRC19:17
*** khohm <khohm!> has quit IRC19:17
*** denix <denix!> has quit IRC19:17
*** gonzzor <gonzzor!> has quit IRC19:17
*** zerus <zerus!> has joined #yocto19:18
*** frank <frank!~frank@> has joined #yocto19:18
*** JimBaxter <JimBaxter!> has joined #yocto19:18
*** agust <agust!> has joined #yocto19:18
*** zenlinux <zenlinux!> has joined #yocto19:18
*** fitzsim <fitzsim!~user@nat/cisco/x-gatiaonknqjnejaw> has joined #yocto19:18
*** jonatan <jonatan!> has joined #yocto19:18
*** dv_ <dv_!> has joined #yocto19:18
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto19:18
*** rtollert_ <rtollert_!> has joined #yocto19:18
*** awafaa <awafaa!uid716@gateway/web/> has joined #yocto19:18
*** grifter1881 <grifter1881!> has joined #yocto19:18
*** halstead <halstead!> has joined #yocto19:18
*** khohm <khohm!> has joined #yocto19:18
*** denix <denix!> has joined #yocto19:18
*** gonzzor <gonzzor!> has joined #yocto19:18
*** jackmitchell <jackmitchell!> has quit IRC19:18
*** jackmitchell <jackmitchell!> has joined #yocto19:18
*** swex <swex!~swex@> has quit IRC19:20
*** seebs <seebs!> has quit IRC19:20
*** volker <volker!> has quit IRC19:20
*** andyross <andyross!> has quit IRC19:20
*** joeythesaint <joeythesaint!~jjm@> has quit IRC19:20
*** melonipoika <melonipoika!> has quit IRC19:20
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC19:20
*** silviof1 <silviof1!> has quit IRC19:20
*** RagBal <RagBal!> has quit IRC19:20
*** cristianiorga <cristianiorga!~cristiani@> has quit IRC19:20
lpappJaMa: IMO it is a bug to specify that explicitly.19:20
lpappit should autodetect what it needs to do.19:21
*** swex <swex!~swex@> has joined #yocto19:21
*** seebs <seebs!> has joined #yocto19:21
*** volker <volker!> has joined #yocto19:21
*** andyross <andyross!> has joined #yocto19:21
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto19:21
*** melonipoika <melonipoika!> has joined #yocto19:21
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto19:21
*** silviof1 <silviof1!> has joined #yocto19:21
*** RagBal <RagBal!> has joined #yocto19:21
*** cristianiorga <cristianiorga!~cristiani@> has joined #yocto19:21
lpappI mean it is workaround for the bug, sorry, but not a solution.19:21
JaMayes that's what documentation for that value says19:21
*** Ramana_ <Ramana_!7aa6729b@gateway/web/freenode/ip.> has quit IRC19:22
*** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.> has quit IRC19:22
*** Ramana_ <Ramana_!7aa6729b@gateway/web/freenode/ip.> has joined #yocto19:22
*** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.> has joined #yocto19:22
*** ka6sox-away is now known as ka6sox-farfarawa19:23
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC19:23
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC19:23
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC19:23
*** _Lucretia__ <_Lucretia__!~munkee@> has quit IRC19:23
*** levi <levi!> has quit IRC19:23
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC19:23
*** Jay7 <Jay7!jay@> has quit IRC19:23
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC19:23
*** chris__ <chris__!> has quit IRC19:23
*** Crofton|work <Crofton|work!> has quit IRC19:23
*** jukkar <jukkar!jukka@nat/intel/x-yatttauwtthqpehh> has quit IRC19:23
*** thaytan <thaytan!> has quit IRC19:23
*** ka6sox-farfarawa <ka6sox-farfarawa!ka6sox@nasadmin/ka6sox> has quit IRC19:23
lpappJaMa: once 4843 is fixed, that variable should be history.19:27
lpappJaMa: also, I am unlucky because even that variable does not help on Arch.19:31
*** acidfu <acidfu!~nib@> has joined #yocto19:34
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto19:34
*** Crofton|work <Crofton|work!> has joined #yocto19:34
*** thaytan <thaytan!> has joined #yocto19:35
*** _Lucretia__ <_Lucretia__!~munkee@> has joined #yocto19:35
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto19:35
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto19:35
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto19:35
*** levi <levi!> has joined #yocto19:35
*** Jay7 <Jay7!jay@> has joined #yocto19:35
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto19:35
*** chris__ <chris__!> has joined #yocto19:35
*** jukkar <jukkar!jukka@nat/intel/x-yatttauwtthqpehh> has joined #yocto19:35
*** ka6sox-farfarawa <ka6sox-farfarawa!ka6sox@nasadmin/ka6sox> has joined #yocto19:35
*** jackmitchell <jackmitchell!> has quit IRC19:35
*** jackmitchell <jackmitchell!> has joined #yocto19:35
*** joeythesaint <joeythesaint!~jjm@> has quit IRC19:40
mr_scienceso we have our first in-house package that fails randomly with make -jN  (N > 1)19:40
lpappmr_science: bugreport?19:40
mr_sciencethe response i got was "parallel make is bad idea"19:41
mr_sciencelpapp: internal = not public19:41
lpappyeah, right.19:41
* lpapp looks for bitbake --clear reports19:45
sgw_lpapp: based on your last email and a couple of other fixes, I can get pasted the multiple provides issue, but I have a different problem now with the install of external toolchain!19:51
lpappsgw_: ?19:52
lpappas for me, it is weird, I cannot even reproduce the issue now.19:52
lpappnot even the pseudo one.19:52
lpappthe only thing happend that I cleaned up the stuff19:52
sgw_hmm, well, I will have some patches soon I hope19:53
lpappEXTERNAL_TOOLCHAIN = "/usr"19:53
lpappI only have this left.19:53
lpappI removed the PREFIX_PATH19:53
lpappor how it was called.19:53
lpappand the TCSMODE19:53
lpappI could likely even remove EXTERNAL_TOOLCHAIN19:53
sgw_EXTERNAL_TOOLCHAIN_SYSROOT I think is the correct setting19:53
lpappas /usr is in the path19:53
lpapp"Set `EXTERNAL_TOOLCHAIN = "/path/to/your/sourcery-g++-install"` in `conf/local.conf`."19:54
lpappprobably you do not need to bother, if you install it in the path.19:54
lpappif it is intelligent enough to pick up the one with the proper prefix.19:55
lpappsorry, I was wrong, I can reproduce the libpseudo issue19:55
lpappeven without the hackery variable.19:55
lpappI believe it is the matter of lib32/lib/lib64 support19:55
lpappIMHO, guessing the library folder is wrong19:56
lpappand the information should be obtained in a different way.19:56
*** andyross <andyross!> has quit IRC19:57
mr_sciencewell, on gentoo bitbake could actually inherit an eclass and do ${get_libdir}20:03
mr_sciencewould be easy enough to add...20:03
lpappI am opening a new libpseudo bugreport20:04
lpappthere you go:
yoctiBug 4919: normal, Undecided, ---, saul.wold, NEW , Failure when trying to build on Archlinux 64 bit host with 32 external toolchain20:07
lpappseebs: sgw_ ^20:07
*** e8johan <e8johan!> has joined #yocto20:11
*** e8johan <e8johan!> has quit IRC20:14
*** e8johan <e8johan!> has joined #yocto20:16
mr_scienceokay, i'll go back and try it on gentoo amd64 again and see if i can add anything useful...20:23
mr_scienceor maybe you'll just fix it for me  ;)20:23
lpappheh, k, thanks in advance.20:23
*** ant_home <ant_home!> has joined #yocto20:24
sgw_seebs: so now I am seeing something different with the external toolchain and pseudo during do_install(), ERROR: object ''\'''\''' from LD_PRELOAD cannot be preloaded: ignored.20:25
sgw_seebs: pseudo builds correctly, but then this occurs during the toolchain install20:25
mr_sciencesgw_: that was also in a previous error posted by lpapp i believe20:29
*** tor <tor!> has quit IRC20:31
*** andyross <andyross!> has joined #yocto20:32
lpappsgw_: 4843 for that20:33
lpappsgw_: are you using NO32LIBS = "0" now?20:34
lpappseebs: how can I tell libpseudo to look into lib32 rather than lib?20:36
lpappis this libpseudo a blocker for building a system anyway?20:37
lpappdesktop distributions have built without it just fine ...20:37
lpappcan we have it optional?20:37
*** mulhern <mulhern!> has quit IRC20:38
*** mulhern <mulhern!> has joined #yocto20:40
sgw_lpapp: libpseudo provides a fakeroot equivlant with a persistent db , so it's very required20:48
lpappsgw_: arch does not use fakeroot, nor libpseudo20:50
lpappand arch is a fairly complex distribution.20:50
sgw_lpapp, I am not going there, different build systems for different purposes20:50
mr_sciencelpapp: i think fakeroot has more potential issues20:51
mr_sciencelibseudo just needs to understand multilib environments20:51
mr_sciencefakeroot in the bitbake context anyway...20:52
*** ka6sox-farfarawa is now known as ka6sox-away20:53
seebssgw: That's interesting. Can we snoop the environment it's running in, and the executable?20:54
mr_sciencesomehow i have a mental image of ka6sox-away caught in a tornado on his way to Oz...20:54
seebsIn the current design, if pseudo is being used to set up the environment, it should work consistently because it's both setting up the environment and defining where things get installed.20:55
sgw_seebs: sure, strace or what tool, I can do reproduce it in a devshell20:55
mr_science"auntie M~ auntie M!"20:55
lpappmr_science: I dislike both. :)20:55
lpappsgw_: well, it is not looking into lib3220:55
lpappthat is the issue so clearly.20:55
lpappit looks into lib, and that is fine for Ubuntu20:56
lpappbut Ubuntu is not Arch.20:56
seebsWell, the main thing I'd want to see would be what LD_LIBRARY_PATH is.20:56
seebsAnd where you have files.20:56
lpappso we need to get libpseudo look into the right folder. How to do that?20:56
seebsThey aren't installed in the standard system library directories, nor should they be, so pseudo's naming convention is pretty much arbitrary; we could have it be .../lib/pseudo/a and .../lib/pseudo/b, it wouldn't matter. In principle.20:56
sgw_let me fire up devshell20:57
lpapp-> ./build/tmp/work/x86_64-linux/pseudo-native20:57
seebsHmm. I wonder. qemu.bbclass has its own setup for this.20:57
lpapp1) It should look into the right place20:57
mr_sciencein the days of old we might set an env var and let libpseudo pick it up...20:57
lpapp2) If it cannot, it should respect the manual override20:57
seebsOh, heyyy.20:57
sgw_seebs: another note, this is a "cp" command, and the cp works in devshell, but not when fired from the run.do_install scro[t20:57
lpappthere is no other way around.20:57
seebsIs that under qemu_run_binary?20:58
sgw_script even20:58
sgw_seebs: no20:58
lpappwell, I can beagleboard if you are concerned about qemuarm20:58
sgw_this is the do_install for external-sourcery-toolchain20:58
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC20:58
seebsOkay, nevermind. The setup there looks a bit odd. And I'm a little unsure why qemu_run_binary is setting PSEUDO_UNLOAD=1, which was relevant to the case I was looking at previously.20:58
*** cetola <cetola!> has quit IRC21:00
sgw_seebs, I think my issue is different that 4843 maybe21:00
seebsI think so.21:00
*** mulhern <mulhern!> has quit IRC21:01
sgw_seebs: Ok, so how do you want to proceed with this one?21:02
seebsI am mostly curious about the existing setting of LD_LIBRARY_PATH, because that seems like it's relevant, and I am finding myself a little unsure on how it gets set.21:02
lpappsgw_: your issue is more like 491921:02
*** zerus <zerus!> has quit IRC21:02
lpappseebs: how should I print that variable out?21:03
seebsSo, thinking about it, the entire build is being run with pseudo present but "disabled", as I recall.21:03
seebsWhich is why things like FAKEROOTENV, etcetera, don't have to set LD_PRELOAD or LD_LIBRARY_PATH.21:03
sgw_lpapp: no it's really a different issue21:03
lpappsgw_: what issue?21:04
seebshey wait a second.21:04
seebsI think I may have found a loose end.21:04
seebs… Possibly irrelevant, but I did just find an invocation of localedef which looks to me like it may be wrong, since it's still using PSEUDO_RELOADED, which I think should be obsolete by now.21:04
sgw_lpapp: my do_install() of external-sourcery-toolchain21:05
lpappsgw_: that does not tell much to me.21:05
seebsInterestingly, I note that prelink_image() has commented-out pieces for displaying LD_LIBRARY_PATH, LD_PRELOAD, and anything in env which matches PSEUDO.21:05
lpappsgw_: why don't you create a bug report with a bit more details?21:05
seebsIt seems a little odd that external-sourcery-toolchain would be failing in this way when other things aren't.21:07
seebs*thinks* sgw_, what host are you using, and what's your configuration look like? I have meta-sourcery around and can try things also.21:09
seebsI am not quite sure what I am looking for right now; I am currently dealing with this vague sense of "wasn't there this thing that I wanted to look at because I didn't trust it that mightbe relevant", which is unfortunately preventing me from thinking more coherently about the data I actually *do* have.21:09
sgw_seebs: not using meta-sourcery trying to get the oe-core external-tool-chain working directly, have a patch for some bits21:10
sgw_F18 and U 12.10 (happens on both) x86-64, building qemuarm or beagleboard21:10
sgw_TCMODE = "external-csl"21:10
sgw_EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1"21:10
sgw_TARGET_PREFIX = "arm-none-linux-gnueabi-"21:10
sgw_NO32LIBS = "0"21:10
seebsInteresting. I haven't tried the external toolchain stuff in a while, but I think I have it lying around to test.21:11
sgw_seebs that should be enough and fails quickly21:11
seebsTragically, my fast machine isn't either of those. But it's fast enough that I think I'll try it anyway.21:11
seebsHuh. Except I don't have toolchain binaries there yet. This is what happens when I get shiny new hardware; I keep forgetting stuff I'll need access to at some point for it to work well.21:12
sgw_seebs to you need a pointer to the 2009q1 toolchain?21:13
kergothsgw_: you shouldn't be using external-csl21:13
kergotheven in oe-core its just a sstub that pulls in external-sourcery, if it still exists at all21:13
sgw_Ok, but I am not sure it will change the failure I am seeing in core21:13
seebsI have a variety of CS toolchains, they're just not that specific one. But I think they work. … Or used to,anyway.21:13
* kergoth gets food21:13
seebssgw_, if you could add an echo of LD_LIBRARY_PATH and LD_PRELOAD to the failing do_install, and give me the output of those, plus the run.do_install, I could probably productively study those and ask smarter questions.21:14
kergothit may not, but using it propogates problematic configurations, since people tend to copy and paste :)21:14
sgw_kergoth: got it, sorry21:14
kergothno worries21:15
*** bluelightning <bluelightning!> has joined #yocto21:17
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:17
sgw_kergoth: just sent you a patch for pre-review, let me know if that's OK with you.21:17
sgw_seebs: working on a paste bin!21:17
*** mulhern <mulhern!> has joined #yocto21:17
*** fitzsim <fitzsim!~user@nat/cisco/x-gatiaonknqjnejaw> has quit IRC21:18
kergothsgw_: ah, looks fine to me, nicely done identifying the particular changes needed21:18
* kergoth never had time to look into it21:18
sgw_kergoth: between your meta-sourcery and lpapp email helped point it all out21:19
sgw_seebs: ignore me I think I just found a different problem with I looked at the script more closely21:19
sgw_seebs:        # Use optimized files if available21:20
sgw_        sysroot="ERROR: object '' from LD_PRELOAD cannot be preloaded: ignored.21:20
sgw_seems there is more issue with generating the sysroot!21:20
seebsI believe I know where that comes from.21:20
seebsBecause earlier, it was set by invoking gcc --print-sysroot21:20
sgw_seebs: yup, that's where I am going next!21:20
seebsI'm a little surprised to find the stderr message showing up there.21:21
kergothheh, it should probably not be grabbing stderr..21:26
mr_sciencehey, no grabbing...21:26
seebsAnd come to think of it, we might have missed this internally at WR because we had fancy stuff to compare --print-sysroot values to values we expected.21:26
sgw_yeah think!21:26
* mr_science is conditioned to respond that way21:28
mr_scienceespecially on long car trips...21:28
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-xcccthdknydaomip> has quit IRC21:50
*** ericben <ericben!> has quit IRC22:04
*** ericben <ericben!> has joined #yocto22:05
*** e8johan <e8johan!> has quit IRC22:08
*** agust <agust!> has quit IRC22:14
*** ka6sox-away is now known as ka6sox22:20
-YoctoAutoBuilder- build #194 of nightly-fsl-ppc-lsb is complete: Failure [failed Building Images Publishing Artifacts] Build details are at
sgw_seebs: here is a pastebin with the gcc and libpsuedo search
sgw_sorry took a while had to do some other setup, that was without NO32LIBS set22:23
seebsOh, that's REALLY interesting.22:24
seebsConsider: /srv/hdd/releases/dylan/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib/tls/sse2/libpseudo.so22:24
seebsThat looks very much like LD_LIBRARY_PATH has lib/pseudo/lib, and something else, and I'm not sure what, is then searching for subdirectories it thinks are likely.22:25
*** mulhern <mulhern!> has quit IRC22:26
seebsSo the next question is, where did LD_LIBRARY_PATH get set originally?22:26
sgw_I am guessing it's bitbake's env since this is anon python code22:26
seebsbitbake -e doesn't show that being set yet.22:27
sgw_It finds the once not the second time22:27
seebsYeah. That is also strange. Hmm.22:27
sgw_Like it looses the LD_LIBRARY_PATH on that second look up22:28
seebsOkay, I appear to be unclear on something fairly fundamental about how bitbake is working, which is that I can't actually figure out how LD_LIBRARY_PATH got set initially.22:28
seebsLike, from the point where I type "bitbake foo" to the point at which something executes in the pseudo environment. I don't know where that happens, and casual grepping isn't finding anything likely.22:28
sgw_Ok, I will add an echo of LD_LIBRARY_PATH in the command, what even more interesting is that with the -e option is works correctly but when it generates the run.do_install it's wrong22:29
seebsHmm. That sounds very much like something is helpfully cleaning up or fixing the environment in some way...22:29
*** mulhern <mulhern!> has joined #yocto22:31
sgw_I am not sure if it's the usage of PSEUDO_UNLOAD or PSEUDO_DISABLED22:31
seebsIt shouldn't be… Hmm.22:31
seebsOkay, I think I have found a thing of which I am now suspicious.22:31
*** mario-go` <mario-go`!> has joined #yocto22:31
sgw_seebs: I know RP was real careful to only enable pseudo when really needed22:31
seebsBut I am still not clear on where LD_LIBRARY_PATH is coming from. But I do notice...22:32
seebsThere's a point where pseudo detects that there's no LD_LIBRARY_PATH, and you've specified PSEUDO_LIBDIR, and does the right thing.22:32
seebsAnd if you DO have an LD_LIBRARY_PATH at that point, it checks that for PSEUDO_LIBDIR, and if it's missing, it adds both versions.22:32
seebsBut if you had LD_LIBRARY_PATH == PSEUDO_LIBDIR, it wouldn't realize that it wants to set LD_LIBRARY_PATH to PSEUDO_LIBDIR:PSEUDO_LIBDIR64.22:33
seebsI still don't know how LD_LIBRARY_PATH is getting set, or what to, but this would be a thing that could cause problems.22:33
*** dzoe_ <dzoe_!> has joined #yocto22:33
*** reaperofsouls <reaperofsouls!> has quit IRC22:34
*** wgao__ <wgao__!~wgao@> has quit IRC22:34
*** mario-goulart <mario-goulart!> has quit IRC22:34
*** dzoe <dzoe!joe@pdpc/supporter/active/dzoe> has quit IRC22:34
seebsWhich means that changing that might well "fix" this, and I think that's the right fix, but… I also really want to know why we *just sometimes* end up with an LD_LIBRARY_PATH which is apparently missing a component.22:34
*** reaperofsouls <reaperofsouls!> has joined #yocto22:35
sgw_seebs: in conf/distro/include/, there is a extc_run() which runs that gcc command, I see the PATH is set for the, do we need to set a PSEUDO_something there?22:35
*** wgao__ <wgao__!~wgao@> has joined #yocto22:35
seebsWell, that's an interesting question.22:36
seebsI don't know what does.22:36
seebsIn particular, I don't know what it does with env = {foo}22:36
seebsand whether that might cause it to, say, wipe out other environment variables.22:37
seebsoh. hoh.22:38
seebsSo, the options just get passed on to Popen()22:38
seebsand Popen() says that env, if not None, is a mapping that defines the environment for the new process.22:39
seebsRather than, say, a mapping that overrides the current process's environment.22:39
seebsSo Python is going to be trying to run us with an environment that has nothing but $PATH set. And pseudo should, in principle, try to recover that.22:39
sgw_but does not seem to?22:40
*** mario-go` is now known as mario-goulart22:40
seebsIt's at least plausible that it would be failing to recover it sufficiently.22:40
seebsHmm. It *should* correctly recover it. Unless it's set wrong when we get there.22:41
seebsBut if I understood the Popen() docs correctly, it should have been unset, and then pseudo should have recovered it correctly.22:42
seebsHmm. And it should also try to regenerate LD_PRELOAD. And that looks like it should work. Hmmm.22:45
*** dlern <dlern!~dlerner@> has left #yocto22:45
*** JimBaxter <JimBaxter!> has quit IRC22:47
seebsOkay, I have a thought for this, perhaps.22:50
mr_scienceata1: link online but 1 devices misclassified, retrying  <=  this is not good...22:51
seebsMy thought is basically: I can give you a patch that, if you had it in pseudo, would cause it to emit a useful diagnostic and abort().22:51
seebsIn the case which I think might be what's biting us. And that would at least cause this to generate quick and obvious failures.22:51
sgw_seebs: see pm for full env of gcc execve call22:51
sgw_lpapp: you still around23:08
*** JimBaxter <JimBaxter!> has joined #yocto23:25
seebsI do note in passing: We don't have any known problems with pseudo's behavior on Ubuntu 12.04 and 12.10 64-bit, both of which use lib/lib32 rather than lib64/lib.23:35
*** mulhern <mulhern!> has quit IRC23:41
*** Jay7 <Jay7!jay@> has quit IRC23:42
*** Jay7 <Jay7!jay@> has joined #yocto23:43
*** mulhern <mulhern!> has joined #yocto23:48
*** sameo <sameo!~samuel@> has quit IRC23:55

Generated by 2.11.0 by Marius Gedminas - find it at!