**** BEGIN LOGGING AT Thu Jul 25 02:59:58 2013 Jul 25 03:13:13 sgw1: any news? Jul 25 04:30:54 lpapp: 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. Jul 25 04:43:51 sgw1: :( Jul 25 04:43:59 the problem is that there is no workaround Jul 25 04:44:08 so I am fully blocked with my company work Jul 25 04:46:09 lpapp: 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. Jul 25 04:47:27 sgw1: it is not about to fix. Jul 25 04:47:36 as written, I do not even have a workaround. Jul 25 04:47:59 anyway, I will probably switch away from Yocto for now. Jul 25 04:48:00 lpapp: it's about a fix or workaround, and I have neither right now, this is not my strong area Jul 25 04:48:21 it is too unstable for embedded developer as of now. Jul 25 04:48:54 I appreciate your help though, so do not take it personally. Jul 25 04:49:01 it is just not the right technology at the moment. Jul 25 04:49:31 lpapp: 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. Jul 25 04:50:07 lpapp: good night Jul 25 04:50:09 sgw1: it is not about what I believe. Jul 25 04:50:16 it is not subjective Jul 25 04:50:21 it just does not work, it is objective. Jul 25 04:50:24 it is a fact. Jul 25 04:51:11 sgw1: good night Jul 25 05:39:29 http://lpapp.blogspot.ie/2013/07/yocto-mature-or-not.html Jul 25 05:53:18 denix, 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 maintained Jul 25 06:13:53 khem: you around now, I know it's late! Jul 25 06:49:25 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4902 Jul 25 06:49:25 Bug 4902: normal, Undecided, ---, richard.purdie, NEW , Add an option or util for automatically updating the file checksum Jul 25 06:58:36 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4903 Jul 25 06:58:37 Bug 4903: normal, Undecided, ---, richard.purdie, NEW , No proper error message for layer version mismatch Jul 25 07:03:27 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4905 Jul 25 07:03:28 Bug 4905: normal, Undecided, ---, richard.purdie, NEW , No proper location diagnostic for tab/space issues Jul 25 07:06:30 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4906 Jul 25 07:06:31 Bug 4906: normal, Undecided, ---, scott.m.rifenbark, NEW , No opengl mentioned Jul 25 07:11:00 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4907 Jul 25 07:11:01 Bug 4907: normal, Undecided, ---, scott.m.rifenbark, NEW , Add an external sourcery chain example with documentation Jul 25 07:11:12 I need to stop it for now, but I will submit more bugreports. Jul 25 07:43:10 wmat: do you know how to use the meta-sourcery layer? Jul 25 07:54:07 morning all Jul 25 07:54:18 morning bluelightning Jul 25 07:54:25 morning Jul 25 07:58:13 gm Jul 25 08:22:29 Hi, 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 ... Jul 25 08:24:07 dzoe: which branch are you on? Jul 25 08:24:26 Danny. Jul 25 08:27:50 dzoe: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/ttf-fonts?h=danny Jul 25 08:28:16 dzoe: bitbake ttf-dejavu should build all of the ttf-dejavu-* packages Jul 25 08:28:36 dzoe: (or indeed bitbake anything-depending-on-ttf-dejavu-*) Jul 25 08:29:45 o/ morning Jul 25 08:30:31 Mea culpa ... I was searching outdated tree from some older experiment where we had those recipes deleted... Sorry for asking stupid questions... Jul 25 08:31:30 dzoe: no worries Jul 25 08:32:04 I have a most probably stupid question too, but here it goes :-) Jul 25 08:32:21 i am trying to build a headless machine and i would like it to run a vnc server Jul 25 08:32:37 i have x11vnc instaleld in my image Jul 25 08:32:45 but i am missing x Jul 25 08:33:03 i think i should install xvfb, but can't find it in any layer Jul 25 08:33:06 what's the default behavior of PACKAGECONFIG? (regarding to the latest commit from JaMa) Jul 25 08:33:07 so is it just me, or I cannot really edit comments on bugzilla? Jul 25 08:33:12 +PACKAGECONFIG ??= "" Jul 25 08:33:19 PACKAGECONFIG[cap] = "--with-libcap,--without-libcap,libcap" Jul 25 08:33:27 lpapp: correct, bugzilla comments are immutable Jul 25 08:33:31 by default, then, no PACKAGECONFIG is given for the package Jul 25 08:33:40 so, "cap" is disabled by default? Jul 25 08:33:44 eren: correct Jul 25 08:33:50 then, --without-cap is given Jul 25 08:33:52 is xvfb the way to go, or is there any other better approach? Jul 25 08:34:09 if it were "PACKAGECONFIG ??= "cap" assignment, it means that it's enabled by default Jul 25 08:34:24 eren: yep Jul 25 08:34:28 oh, okkie. thanks! Jul 25 08:35:17 melonipoika: xvfb sounds like a good idea Jul 25 08:35:43 that is a very unfortunate limitation... Jul 25 08:35:47 is that a feature or bug? Jul 25 08:36:00 JaMa: how did you manage to detect these options from sysroot? I mean, the autodetection of libraries and enabling automatically while the package is being built Jul 25 08:36:34 rburton, thanks. Do you know what layer provides xvfb? Jul 25 08:36:51 melonipoika: i suspect it might be in meta-oe Jul 25 08:36:56 (i ma using arago and my target hw is a TI TCI6638 EVM) Jul 25 08:36:59 I am getting an error from the denzil branch when running bitbake ... http://paste.kde.org/~lpapp/p40944183/ Jul 25 08:37:16 with a brand fresh checkout for the branch. Jul 25 08:37:28 ok Jul 25 08:37:50 ERROR: 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' Jul 25 08:38:05 lpapp: you need a new bblayers Jul 25 08:38:16 lpapp: as meta-yocto-bsp didn't exist in denzil Jul 25 08:38:21 (iirc) Jul 25 08:38:26 (still need a second coffee) Jul 25 08:38:32 I love error messages, have I ever mentioned? :) Jul 25 08:38:41 its a perfectly good error message Jul 25 08:38:48 you told it to load a layer, that layer doesn't exist Jul 25 08:39:06 DEBUG: Adding layer /home/lpapp/Projects/poky/meta-yocto-bsp Jul 25 08:39:09 DEBUG: LOAD /home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf Jul 25 08:39:11 ERROR: 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' Jul 25 08:39:15 not sure how much more concrete that could be to be honest Jul 25 08:39:25 it is perfectly good for you. Jul 25 08:39:32 but I doubt it is perfectly good for a user, like me. Jul 25 08:39:35 lpapp: how could it be improved? Jul 25 08:39:38 well, it could be a lot more concrete. Jul 25 08:39:43 its incredibly concrete Jul 25 08:39:47 I was about to open a bugreport. Jul 25 08:39:48 it is not? Jul 25 08:39:57 I'm adding a layer / i'm opening this specific file / that specific file doesn't exist Jul 25 08:40:11 it told you what layer its trying to add, and what file it can't find Jul 25 08:40:23 which is wrong, yes. Jul 25 08:40:56 lpapp: ? Jul 25 08:41:34 please be patient Jul 25 08:41:47 as I said, I was already opening a bugreport for it. Jul 25 08:43:44 lpapp: 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. Jul 25 08:44:32 lpapp: normally *developers* are building the images and users are just expected to update packages on target Jul 25 08:45:08 bluelightning: rburton https://bugzilla.yoctoproject.org/show_bug.cgi?id=4909 Jul 25 08:45:09 Bug 4909: normal, Undecided, ---, richard.purdie, NEW , Improve the error message for tray bblayers.conf files Jul 25 08:45:24 ant_work: user experience is *not* tied to a frontend. Jul 25 08:45:30 ant_work: any frontend should be usable. Jul 25 08:45:32 I'm a little bit confused about what SRCPV actually does. I've realized that all git recipes use SRCREV, and assign PV = "+git${SRCPV}". Why don't they use +git${SRCREV} ? Jul 25 08:45:49 ant_work: and no, I do not like HOB. I actually very much dislike gtk. Jul 25 08:46:03 I believe the current documentation is not clear on the variable either. Jul 25 08:46:06 "Returns the version string of the current package. This string is used to help define the value of PV." Jul 25 08:46:27 lpapp: neverthless, it has many of the automatisms you're asking for Jul 25 08:47:16 (I only gave a glimpse, I'm not HOB user fwiw) Jul 25 08:48:51 ant_work: well, thanks for the information, but I am not going to use HOB. Jul 25 08:49:10 I also think that HOB is the wrong layer to address it at. Jul 25 08:49:24 some of the things should be addressed on the bitbake layer. Jul 25 08:51:35 rburton: bluelightning http://paste.kde.org/~lpapp/p23e563aa/ Jul 25 08:51:43 this is with the denzil branch, poky, and beagleboard Jul 25 08:51:54 I cannot get any branch working with an external toolchain. :( Jul 25 08:52:22 | automake.texi:13043: @itemx must follow @item Jul 25 08:52:31 looks a lot like the problems caused by new texinfo Jul 25 08:52:31 also this: ERROR: Execution of event handler 'csl_version_handler' failed Jul 25 08:52:52 texinfo 5.1 in her. Jul 25 08:52:53 here* Jul 25 08:53:05 yeah, that caused errors all over the place Jul 25 08:53:07 but I would be interested in the other error, too. Jul 25 08:53:47 try changing that CmdError to bb.process.CmdError Jul 25 08:53:54 ah, yeah, that was fixed by us. Jul 25 08:56:22 should probably be fixed in upstream, too. Jul 25 08:56:47 it would be nice to give a last go to meta-sourcery before leaving Yocto. Jul 25 08:56:53 commit caee06405f90d44b3476af645e2b3918578ba6b9 Jul 25 08:56:54 but to be honest, I am not even sure what I am supposed to do with it. Jul 25 08:56:56 Author: Christopher Larson Jul 25 08:56:58 Date: Tue May 15 20:28:24 2012 -0500 Jul 25 08:57:02 csl-versions: fix bb.process.CmdError reference Jul 25 08:57:08 you can cherry-pick that into your denzil branch Jul 25 08:57:09 rburton: I meant the denzil branch. Jul 25 08:57:18 I fixed that on my own before. Jul 25 08:57:41 anyone having any idea how one is supposed to use the meta-sourcery layer? Jul 25 08:58:17 lpapp: if you backport it you can send it to oe-core tagged for denzil Jul 25 08:58:56 rburton: too much effort that I do not have time for. Jul 25 08:58:57 lpapp: maybe I missed it, why don't you consider using the native toolchain? You have patches to coreutils? Add patches in your layer. Jul 25 08:59:11 ant_work: I do not have any patches to core utils ... Jul 25 08:59:13 coreutils* Jul 25 08:59:27 ant_work: huh? Jul 25 08:59:37 arm native toolchain on non-arm? Jul 25 08:59:39 that is kinda joke? Jul 25 08:59:46 lpapp: built by OE/Yocto Jul 25 08:59:55 it does not matter who builds it Jul 25 09:00:00 you cannot run ARM binary on the host Jul 25 09:00:04 without qemu, and other slow stuff Jul 25 09:00:13 lpapp: try to understand, I mean NO EXTERNAL TC Jul 25 09:00:38 that is not a native toolchain Jul 25 09:00:47 that is non-external non-native. Jul 25 09:00:53 i.e. internal cross-toolchain. Jul 25 09:01:14 because we do not wanna build it. Jul 25 09:01:28 it takes time, and we do not have time for things that exist in binary forms off-hand. Jul 25 09:01:46 those are the reasons? Jul 25 09:02:00 yes, plus the lot of effort for refactoring. Jul 25 09:02:12 those are all blocker reasons Jul 25 09:03:07 lpapp: I think you're missing the Yocto goals Jul 25 09:03:50 ant_work: our project is not Yocto Jul 25 09:03:53 we have different goals. Jul 25 09:04:02 so yes, of course we miss the Yocto goals. Jul 25 09:06:39 so if I integrate this meta-sourcery, what am I supposed to set in my conf/layer.conf? Jul 25 09:06:48 or in bblayers.conf if any? Jul 25 09:09:07 is it just me being silly? Jul 25 09:09:10 and it is trivial? Jul 25 09:09:16 or is it something to ask from the MG guys? Jul 25 09:09:17 lpapp: 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... Jul 25 09:09:29 bluelightning: stop this please. Jul 25 09:09:31 it is not productive. Jul 25 09:09:43 how did you know for *sure* it was going to cause issues? Jul 25 09:09:52 also, are you aware of the cost a full stack refactoring in a company? Jul 25 09:10:01 are you also aware of the fact developers *do* dislike the slow builds? Jul 25 09:10:16 also, I am *not* complaining. Jul 25 09:10:19 I am stating facts. Jul 25 09:10:21 lpapp: but you immediately ignore the default option which is tested and works Jul 25 09:10:31 well, if you call that complaining, that is fine. Jul 25 09:10:48 bluelightning: you do not wanna realize what I wrote Jul 25 09:11:02 developers dislike the slow builds, it costs a lot of time to refactor, test, validate, develop, fix bugs and so forth Jul 25 09:11:21 why would a "full stack refactoring" even be needed? Jul 25 09:11:24 even if the latter took zero effort, which it does not. Jul 25 09:11:29 then former argument would stay around. Jul 25 09:11:38 bluelightning: because it is the damn toolchain Jul 25 09:11:44 the very low-part of the stack. Jul 25 09:11:52 and every part above depending on it. Jul 25 09:12:00 yes, and luckily we have quite a lot of experience building and testing that part Jul 25 09:12:39 how is that relevant? Jul 25 09:12:44 We need to test our software with it Jul 25 09:12:49 and we have a huuuuuuge software Jul 25 09:13:00 it is a different project to change the toolchain if it is every worth it Jul 25 09:13:03 and not a small project. Jul 25 09:13:07 we do not have budget for that now. Jul 25 09:13:13 makes sense? Jul 25 09:14:02 ever* Jul 25 09:15:11 lpapp: if you are having problems with m-s, then yes, continue talking to kergoth. Jul 25 09:15:23 rburton: he is ignoring me here even though I unignored him Jul 25 09:15:31 rburton: and he has not replied for the email queries on the list Jul 25 09:15:40 I am now filing a bug against meta-sourcery on github Jul 25 09:15:42 not sure I can do more. Jul 25 09:16:49 rburton: https://github.com/MentorEmbedded/meta-sourcery/issues/9 Jul 25 09:22:44 When adding IMAGE_INSTALL += "libnfsidmap", it will be renamed to libnfsidmap0 as param passing to translate_oe_to_smart(). Jul 25 09:23:12 Where is the code made this change? Jul 25 09:25:10 I mean where did the changes to IMAGE_INSTALL or PACKAGE_INSTALL ? Jul 25 09:26:01 rburton: is that github report clear? Jul 25 09:26:17 would you report the same if you were interested in using it, but they do not provide documentation? Jul 25 09:26:21 frank: I guess you switched from ipk to rpm ? Jul 25 09:26:23 should I add any additional information? Jul 25 09:27:19 bluelightning: I will spend half an hour with the internal toolchain Jul 25 09:27:26 bluelightning: do you have documentation at hand? Jul 25 09:27:45 lpapp: it's the default option, you shouldn't need to do anything special Jul 25 09:27:51 bluelightning: ? Jul 25 09:28:02 bluelightning: I would like to be able to specify the compiler Jul 25 09:28:06 lpapp: just comment out the lines you added to enable the external toolchain and you'll be configured to use it Jul 25 09:28:10 what architecture, what gcc version, etc. Jul 25 09:28:21 because I would like to use C++11 as much as possible, and C++14 soon. Jul 25 09:28:26 I would like to build for a particular arm. Jul 25 09:28:36 lpapp: all of that is determined from the MACHINE you have set Jul 25 09:28:37 bluelightning: that did not fly last time. Jul 25 09:28:43 bluelightning: it built native x86 binaries Jul 25 09:28:55 lpapp: you did not specify a MACHINE Jul 25 09:29:18 bluelightning: not exactly, I just find sometimes, "libnfsidmap" is not renamed with the lib version Jul 25 09:29:25 ant_work: I di. Jul 25 09:29:25 d Jul 25 09:29:58 So, I want to browse the code doing this rename. Jul 25 09:30:14 lpapp: # This sets the default machine to be qemux86 if no other machine is selected: Jul 25 09:30:15 MACHINE ??= "qemux86" Jul 25 09:31:12 lpapp: pls explicitly add MACHINE = "foo" (from your BSP layer) Jul 25 09:31:13 frank: ok, translate_oe_to_smart() is only used for rpm Jul 25 09:31:21 frank: I'll find some pointers for you, one sec Jul 25 09:31:21 ant_work: I am not sure what you mean Jul 25 09:31:24 and where you get that from. Jul 25 09:31:28 I definitely have a different local.conf Jul 25 09:31:29 http://cgit.openembedded.org/openembedded-core/tree/meta/conf/local.conf.sample Jul 25 09:31:41 no no Jul 25 09:31:44 bluelightning: yes. Thanks a lot ! Jul 25 09:31:47 I have local.conf setup for my environment. Jul 25 09:31:55 I did not get something blindly which I have never modified. Jul 25 09:32:11 lpapp: it looks like smthg went wrong then ;) Jul 25 09:32:32 lpapp: if I say 'spitz' I get code for that armv5te Jul 25 09:32:33 yes, but elsewhere. Jul 25 09:32:50 ./meta/conf/machine/include/tune-arm926ejs.inc -> so if I include it, it should build for that. Jul 25 09:33:10 dylan has gcc 4.7? Jul 25 09:33:19 I mean arm gcc gnueabi Jul 25 09:33:37 frank: the actual code that does that is runtime_mapping_rename() in meta/classes/package.bbclass Jul 25 09:33:46 frank: it's called from meta/classes/image.bbclass Jul 25 09:35:50 bluelightning: Thanks! Jul 25 09:36:00 frank: 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) Jul 25 09:37:16 bluelightning: I will make a test build Jul 25 09:37:28 bluelightning: Got it ! Jul 25 09:37:29 bluelightning: slow building is definitely better than no building for now. Jul 25 09:37:40 but we need to get the MG stuff working in the end of the day. Jul 25 09:37:50 I consider the internal an interim workaround Jul 25 09:37:54 provided it works. Jul 25 09:38:03 lpapp: remember you build the compiler once, after that it's in the cache Jul 25 09:38:20 lpapp: don't play with the tune files, those are included by the machine.conf Jul 25 09:38:26 ant_work: ? Jul 25 09:38:29 ant_work: we have our own machine Jul 25 09:38:37 that is why we have a different layer in the first place. ;) Jul 25 09:38:47 and our machine includes that. Jul 25 09:39:22 lpapp: we maintain machines in an external BSP as well and the machine.conf just includes the tune files of oe-core Jul 25 09:39:48 I do need to deal with it Jul 25 09:39:56 i.e. I need to include it in my machine/foo.conf Jul 25 09:40:04 that is where the information should come from I believe. Jul 25 09:40:10 whether it is building with a cross-toolchain. Jul 25 09:40:21 bluelightning: it is using cross-toolchain rather than emulated native, right? Jul 25 09:40:32 lpapp: absolutely Jul 25 09:40:40 k Jul 25 09:42:18 rburton: I do not like cache Jul 25 09:42:22 it is causing hard to debug issues Jul 25 09:43:56 bluelightning: internal toolchain does not work either. :/ Jul 25 09:44:31 bluelightning: http://paste.kde.org/pccafd75c/ Jul 25 09:44:37 the busybox error is back from yesterday... Jul 25 09:45:03 I guess I should open a bugreport about it now? Jul 25 09:45:11 I guess I am blocked then with the internal toolchain way as well. :/ Jul 25 09:45:36 lpapp: remove your layers from bblayer.conf and try a build with qemuarm. Jul 25 09:45:43 lpapp: then you can rule out any interaction with your layers Jul 25 09:45:50 because busybox builds for everyone else Jul 25 09:46:08 rburton: well, the error is not coming from my layer. Jul 25 09:47:37 does everyone else test with bleeding arch? Jul 25 09:47:38 perhaps not. Jul 25 09:47:47 lpapp: i didn't say it did, but lets reduce the test case Jul 25 09:47:55 try a build with no custom layers, and see if that works Jul 25 09:48:18 yeah, I am doing that. Jul 25 09:49:17 rburton: seems to work with my distro Jul 25 09:49:24 when I add my machine, then it does not. Jul 25 09:49:37 see, useful data point :) Jul 25 09:49:42 can you pastebin your machine? Jul 25 09:49:54 no Jul 25 09:50:06 I am still investigating, and I need to be careful what to paste. :) Jul 25 09:50:09 it takes me some time. Jul 25 09:50:26 it is weird Jul 25 09:50:30 qemuarm -> mymachine Jul 25 09:50:34 I added it back, and then it works. Jul 25 09:50:38 again cache issue? Jul 25 09:50:42 * lpapp dislikes cache Jul 25 09:51:10 doubt it, the cache is keyed on almost everything that can change, and you get a fresh sysroot for every machine. Jul 25 09:52:03 eren: see the script in first patch in that patchset Jul 25 09:52:51 lpapp: what are your layers doing with BBPATH ? Jul 25 09:54:20 bluelightning: ./meta-polatis/conf/layer.conf:2:BBPATH := "${BBPATH}:${LAYERDIR}" Jul 25 09:54:27 bluelightning: ./meta-foo/conf/layer.conf:2:BBPATH := "${BBPATH}:${LAYERDIR}"* Jul 25 09:54:55 so just something that everyone else does. Jul 25 09:55:54 lpapp: ok... was just trying to rule out that maybe the layer was picking up the wrong busybox.inc file with something odd in BBPATH Jul 25 09:56:11 bluelightning: it is working noqw Jul 25 09:56:13 now Jul 25 09:56:21 I did not do anything else than switching to qemuarm and then back Jul 25 09:56:33 and I deleted the cache in the meantime. Jul 25 09:56:39 bitbake.cache? Jul 25 09:56:52 lock file tmp sstate cache etc Jul 25 09:56:55 bitbake.lock Jul 25 09:56:58 everything really. Jul 25 09:56:59 except conf Jul 25 09:57:12 I still think it is nasty to have conf files in build/ Jul 25 09:57:19 otherwise I could do rm -rf build/* Jul 25 09:57:29 of course a non-existing tool could help. Jul 25 09:57:34 if it was getting existent. Jul 25 09:57:39 bitbake --clean Jul 25 10:00:36 lpapp: 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. Jul 25 10:01:19 mainly for disk allocation reasons but also useful for wiping stuff if i really destroy something. Jul 25 10:16:26 ahh, internal toolchain crashes Jul 25 10:16:31 due to 4.8 vs. 4.7 with gcc. Jul 25 10:16:39 anyway, we cannot use a new toolchain. Jul 25 10:16:42 an internal* Jul 25 10:16:52 I will go for denzil and a support debian in chroot for now. Jul 25 10:17:01 until the guys fix the sourcery issues. Jul 25 10:20:13 Is there a simple method to check what packages are included by a package group ? Jul 25 10:20:27 oh, debian is not supported. :( Jul 25 10:20:56 well, that sucks huge balls. Jul 25 10:21:09 so basically, I cannot install anything into chroot to get it work Jul 25 10:21:13 but I have to use virtualization. Jul 25 10:21:25 I dislike the vmware/vbox/etc stuff Jul 25 10:21:33 chroot would be so much more logical for a cli build. Jul 25 10:21:42 lpapp: we do test against debian regularly Jul 25 10:21:43 JaMa: okkie, I will, thanks Jul 25 10:22:04 bluelightning: the website writes it is not supported. Jul 25 10:22:47 Ubuntu Jul 25 10:22:50 Fedora Jul 25 10:22:52 openSUSE Jul 25 10:22:55 CentOS Jul 25 10:23:00 https://wiki.yoctoproject.org/wiki/Distribution_Support -> Debian Wheezy failing. Jul 25 10:24:24 lpapp: the linked report is from 2011... Jul 25 10:27:22 bluelightning: yeah, so update it please. Jul 25 10:30:05 lpapp: to be honest if nobody from QA is keeping that page up-to-date I'd rather see it deleted Jul 25 10:31:04 bluelightning: the links to it from the documentation should be removed as well then Jul 25 10:31:31 Net147: yes, good point :/ Jul 25 10:32:18 I usually refer to the list of supported distributions in the reference manual - e.g. http://www.yoctoproject.org/docs/1.4/ref-manual/ref-manual.html#detailed-supported-distros Jul 25 10:33:22 bluelightning: I will submit a bugreport. Jul 25 10:33:29 I dislike wikis Jul 25 10:33:34 I agree about it being deleted. Jul 25 10:33:44 Net147: 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.conf Jul 25 10:34:24 and SANITY_TESTED_DISTROS gets updated as a matter of course for every release Jul 25 10:44:36 bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4911 Jul 25 10:44:37 Bug 4911: normal, Undecided, ---, scott.m.rifenbark, NEW , Wiki: Distribution Support outdated Jul 25 10:45:30 lpapp: I think you may have pasted the wrong link Jul 25 10:45:37 into the bug report Jul 25 10:46:32 bluelightning: whoops Jul 25 10:46:34 ;) Jul 25 10:46:51 indeed, konsole copy is buggy. Jul 25 10:46:55 thanks. Jul 25 10:47:13 lovely that I cannot edit a comment on bugzilla. :( Jul 25 10:47:36 updated. Jul 25 10:48:02 standard for bugzilla out of the box I guess Jul 25 10:48:26 yeah, luckily enough Jira allows it. Jul 25 10:49:38 so does mantis Jul 25 10:52:26 * lpapp is installing wheezy (7.0). Jul 25 10:53:43 lpapp: you already interact with kde that uses bugzilla, can you edit your comments there? Jul 25 10:54:10 bluelightning: I am interacting with Qt more. Jul 25 10:54:13 where Jira is in use. Jul 25 10:54:16 at my company, where mantis. Jul 25 10:55:23 bluelightning: no, bugs.kde.org does not allow that either. Jul 25 10:55:32 nor the meego bugtracker. Jul 25 10:55:35 nor gcc. Jul 25 10:55:45 I use Trac which allows editing comments Jul 25 10:57:59 FWIW, I'm a fan of Mantis, I use it on one of the projects I maintain Jul 25 10:58:37 I have not used Mantis much. Jul 25 10:58:43 and I do not see it used that much in open source projects. Jul 25 10:58:49 can you mention any big open source project using it? Jul 25 10:59:12 Hi guys, I'm using poky dylan-9.0.1 tag, found a problem in poky/scripts/rpm2cpio.sh. 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. Jul 25 11:01:38 Krz: 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? Jul 25 11:02:43 lpapp: I don't know of any major one no, but then I haven't checked what they all use Jul 25 11:03:37 bluelightning: 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? Jul 25 11:08:39 Krz: I guess so, I'd have to look at where rpm2cpio would be called and see if we need a dependency added there Jul 25 11:08:57 Krz: Ideally it would have its own check and error if file is not available since it's a script that can be run externally Jul 25 11:10:15 sgw1: is there anyone still investigating about the CS external toolchain issue? Jul 25 11:10:47 bluelightning: 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 dependency Jul 25 11:11:12 Krz: right... would you mind filing a bug for that issue so it is tracked? Jul 25 11:11:49 bluelightning: yes, I can do that. I requested access to Yocto bugzilla, but didn't receive activation email :(. Probably some email filters. Jul 25 11:12:29 Krz: ah ok... if you continue to have problems with getting the activation email you might want to talk to halstead Jul 25 11:13:25 * dzoe sighs ... Jul 25 11:13:42 Compiling ttf-dejavu works, but building image that includes it results in: | Unable to resolve package ttf-dejavu Jul 25 11:14:13 Should I try something more than bitbake -f -c compile ? Jul 25 11:18:04 bluelightning: ok, have access to bugzilla.yoctoproject.org. Is the Build System & Metadata -> BitBake the right place for scripts/rpm2cpio.sh related problem? Jul 25 11:20:30 when is the next dylan bugfix release expected to come? Jul 25 11:37:25 Krz: it's not bitbake, it's OE-Core Jul 25 11:39:12 lpapp: I don't think a date has been set, but I think it's likely to be over a month away Jul 25 11:40:00 dzoe: maybe it's a case that the ttf-dejavu package itself is empty and only ttf-dejavu-xyz packages get produced? Jul 25 11:40:27 bluelightning: phew... Jul 25 11:40:42 ? Jul 25 11:42:11 that is a lot of time .... Jul 25 11:42:13 https://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html Jul 25 11:42:17 1.3.2. Required Packages for the Host Development System Jul 25 11:42:22 debian is not there and supported, really? Jul 25 11:42:28 another bugreport to file against bugzilla? Jul 25 11:43:13 bluelightning: 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? Jul 25 11:44:50 lpapp: yes. it would just be a copy of the ubuntu section, anyway. Jul 25 11:44:51 bluelightning: 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'" Jul 25 11:45:02 lpapp: the section above does say debian 6 and debian 7, fwiw Jul 25 11:45:31 rburton: not necessarily, no Jul 25 11:45:35 debian is not ubuntu after all. Jul 25 11:45:54 anyway, even if it should be the same which I dislike, but let us say it is Jul 25 11:46:03 1.3.2.1 should be Ubuntu _and_ Debian Jul 25 11:46:06 so bugreport is being created. Jul 25 11:46:36 for the base development stuff if the package names are not identical i'd be massively surprised Jul 25 11:47:26 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4912 Jul 25 11:47:27 Bug 4912: normal, Undecided, ---, scott.m.rifenbark, NEW , No "Required Packages" mentioned for Debian Jul 25 11:48:02 dzoe: when you do "bitbake xyz", the xyz is a built-time target, i.e. a recipe or a recipe variant Jul 25 11:48:03 what's the best way to add an environment variable to a new RootFS image, so that it is available after starting up the embedded system Jul 25 11:48:36 dzoe: ttf-dejavu is a build-time target, ttf-dejavu-sans-mono is a runtime package so "bitbake ttf-dejavu-sans-mono" would be invalid Jul 25 11:49:09 dzoe: however, IMAGE_INSTALL takes runtime packages so adding ttf-dejavu-sans-mono to IMAGE_INSTALL is valid Jul 25 11:49:12 Which means I should build ttf-dejavu and include ttf-dejavu-sans-mono? Jul 25 11:49:49 dzoe: 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 automatically Jul 25 11:50:07 dzoe: (adding ttf-dejavu-sans-mono that is) Jul 25 11:50:28 I'd expect that, but that's what (I think) failed, gonna try again ... maybe I'm just overlooking something again. Jul 25 11:50:52 rburton: yeah I do have a patch around here somewhere to do just that Jul 25 11:53:50 volker: 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 needed Jul 25 11:55:02 bluelightning: thanks, will try that Jul 25 12:29:47 http://paste.kde.org/~lpapp/p15489db4/ -> why am I getting error for bitbake on wheezy? Jul 25 12:38:57 lpapp: your chroot is missing /dev/shm Jul 25 12:39:21 lpapp: current versions check for the existence of that file and give you a proper error Jul 25 12:39:22 bluelightning: weird Jul 25 12:39:30 because /dev is mounted from fstab. Jul 25 12:39:49 -> /dev/shm is there. Jul 25 12:39:51 but it is empty. Jul 25 12:39:57 just like on the host Jul 25 12:40:29 ok, not sure then, but errors usually only happen in that part of the code because /dev/shm can't be used Jul 25 12:40:45 so wheezy will not work either? :( Jul 25 12:40:50 what will work for Yocto then, seriously? Jul 25 12:41:49 seriously, the list of distros/versions we test for every release Jul 25 12:42:55 the listed distribution does not work for me? Jul 25 12:43:59 I am reporting a bug again, sigh, but I do not think I can wait for any bug fixed. Jul 25 12:44:07 can anyone actually mention a setup where it should work? Jul 25 12:44:18 I am disappointed at large that even a reference platform is broken. :( Jul 25 12:44:19 Gentoo is not listed but working Jul 25 12:44:29 ok, so that is a complete no go. Jul 25 12:44:59 lpapp: you should really start a basic build for qemuarm Jul 25 12:45:18 then add the layers one by one Jul 25 12:46:44 actually, this issue, just like the other upstream, has nothing to do with layers. Jul 25 12:49:52 lpapp: I know of several people who are using debian in a chroot to do builds on a regular basis, so it is possible Jul 25 12:50:28 lpapp: but it's not a configuration we ever regularly test Jul 25 12:50:36 nor did we ever claim anywhere that it was Jul 25 12:50:47 debian wheezy is mentioned as a supported distribution. Jul 25 12:51:11 anyway, let us start off with a bugreport. Jul 25 12:51:12 lpapp: http://bec-systems.com/site/1029/os-containers-for-build-systems Jul 25 12:51:25 how to build OE, on Arch, using LXC and Debian. Jul 25 12:51:59 lpapp: yep, but when you run a chroot of debian that is *not* the same thing as running debian Jul 25 12:52:37 i casually build dylan on ubuntu (12.04, 12.10, 13.04), and Debian/sid. and some of my team members use OpenSuse. Jul 25 12:52:52 ndec: ? Jul 25 12:53:07 bluelightning: how do you *really* know it is a chroot issue? Jul 25 12:53:12 lpapp: 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. Jul 25 12:53:58 ndec: I have always used stuff as on the host Jul 25 12:54:03 have never had any issues Jul 25 12:54:09 this is not the first I am using debian in chroot Jul 25 12:54:13 we had to use that back then for meego, too. Jul 25 12:54:59 also, please note that sudo bitbake will not fly. Jul 25 12:55:11 ok. Jul 25 12:55:19 bluelightning: it *might* just well be a generic debian issue Jul 25 12:55:36 unless you prove it *is* a chroot isuse. Jul 25 12:55:38 issue* Jul 25 12:57:14 lpapp: re. meta-sourcery layer, you add it to bblayers.conf to use it Jul 25 12:57:32 wmat: that is all? Jul 25 12:58:08 lpapp: here's an example of how the xilinx folks use it -> https://github.com/Xilinx/meta-xilinx Jul 25 12:58:15 lpapp: see the README Jul 25 12:58:33 wmat: README of? Jul 25 12:58:48 of that Github link, just scroll down Jul 25 12:59:00 ok, so the README of meta-xiling Jul 25 12:59:02 x Jul 25 12:59:08 and not meta-sourcery, or something else. Jul 25 12:59:13 yes Jul 25 12:59:17 lpapp: i can tell you for sure that debian is a working host, as i've been using it non-stop for over a year now Jul 25 12:59:35 rburton: any idea then? Jul 25 12:59:35 lpapp: presumably the permissions on your /dev/shm are wrong? Jul 25 12:59:36 wmat: please be more precise Jul 25 12:59:53 lpapp: the error says permission denied, to check the permissions. Jul 25 12:59:54 wmat: ok, better to make sure Jul 25 13:00:12 ant_work: more precise? Jul 25 13:00:36 rburton: 755 Jul 25 13:00:42 rburton: 777 on the host Jul 25 13:00:46 and I cannot assign +w to it. Jul 25 13:01:11 lpapp: well that's the problem Jul 25 13:01:18 nothing to do with bitbake, but a bad chroot Jul 25 13:01:45 rburton: ? Jul 25 13:01:58 sudo LANG=C.UTF-8 chroot /mnt/wheezy /bin/bash -l -> this is the right way to chroot. Jul 25 13:02:24 and this is how it is mounted: /dev /mnt/wheezy/dev auto bind 0 0 Jul 25 13:02:29 full of regular stuff Jul 25 13:02:30 sure. i meant the contents of the chroot when you are in it, is wrong. your /dev/shm isn't world-writable. Jul 25 13:02:35 could you please clarify why it is a *chroot* issue? Jul 25 13:02:46 right, so it is not a chroot issue Jul 25 13:02:47 because its different inside and outside the chroot? Jul 25 13:02:57 ffs, this is just semantic bullshit Jul 25 13:03:02 your /dev/shm has the wrong permissions. Jul 25 13:03:04 that's the problem Jul 25 13:03:25 lets not play games at identifying exactly who is to blame so we can glare at them Jul 25 13:03:31 lets just fix the permissions Jul 25 13:03:53 I do not like people when they think it is a chroot issue Jul 25 13:03:58 and they can free up their hand Jul 25 13:04:05 I think it is very important to get it straight. Jul 25 13:04:09 also, I am about to submit another bugreport Jul 25 13:04:15 it should suggest /dev/shm in some way. Jul 25 13:04:25 this is again something totally mysterious to me. Jul 25 13:04:29 I would have never guessed it. Jul 25 13:07:11 lpapp: that's not our code, that's python multiprocessing Jul 25 13:07:24 lpapp: and we already have a check in master for that, so no bug report needed Jul 25 13:07:41 huh? Jul 25 13:07:45 the error is coming from bitbake. Jul 25 13:07:50 bitbake should know what it is doing. Jul 25 13:07:52 lpapp: check the code path Jul 25 13:07:54 you can hardly blame upstream. Jul 25 13:08:22 lpapp: http://patchwork.openembedded.org/patch/49621/ Jul 25 13:09:08 which has been merged as http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fd8dcd7b88925dbb8203b0d2ec6ac62fe667676c Jul 25 13:09:17 bluelightning: I do not like that change. Jul 25 13:09:23 so I will submit a bugreport/change Jul 25 13:09:26 * rburton lols Jul 25 13:09:33 lpapp: ? Jul 25 13:09:34 I think the exact issue could be specified without the option. Jul 25 13:09:44 what option? Jul 25 13:09:53 you do not need to give a list of issue that can go wrong. Jul 25 13:10:01 you can directly give the *offending* issue. Jul 25 13:10:22 list of issues* Jul 25 13:12:39 bluelightning: agree? Jul 25 13:14:12 lpapp: 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 that Jul 25 13:14:39 bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4914 Jul 25 13:14:40 Bug 4914: normal, Undecided, ---, richard.purdie, NEW , Not talkative enough error message for /dev/shm issues Jul 25 13:15:01 rburton: lols ? Jul 25 13:15:14 bluelightning: I have never said it is a big dela. Jul 25 13:15:16 deal* Jul 25 13:15:23 but small deals are not welcome, or what? Jul 25 13:18:21 hmm, none /dev/shm tmpfs defaults,size=1G 0 0 did not help Jul 25 13:18:25 it is still not writable... :( Jul 25 13:20:17 did you verify that your /dev/shm in the chroot is actually a tmpfs? Jul 25 13:20:33 when i mount a tmpfs, the mode on the mountpoint change to 1777 Jul 25 13:20:46 oh, debian uses /run/shm Jul 25 13:20:49 not /dev/shm Jul 25 13:20:52 so bitbake is wrong then. Jul 25 13:20:58 no, /dev/shm is a symlink Jul 25 13:21:02 but then I actually wonder how it is a supported platform?! Jul 25 13:21:17 lrwxrwxrwx 1 root root 8 Jul 15 09:29 /dev/shm -> /run/shm Jul 25 13:21:22 no no, it is not. Jul 25 13:21:30 that was a ls from my *debian system* Jul 25 13:21:45 ls -ld /dev/shm/ Jul 25 13:21:46 drwxr-xr-x 2 root root 40 Jul 25 11:33 /dev/shm/ Jul 25 13:23:53 rburton: what is the permission on your /run/shm? Jul 25 13:23:57 If 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. Jul 25 13:24:02 lpapp: same as all tmpfs, 1777 Jul 25 13:24:26 rburton: 755 in here. Jul 25 13:24:30 mulhern: my standard reply to anything related to license fields is to say "ask beth" :) Jul 25 13:24:42 lpapp: sounds like the tmpfs isn't actually mounted to me Jul 25 13:24:49 OK. :) Jul 25 13:24:54 rburton: you mean from the host. Jul 25 13:26:27 rburton: you mean, I also need to bind it? Jul 25 13:26:29 from the host to chroot? Jul 25 13:27:12 http://superuser.com/questions/460815/mounts-not-present-in-fstab-where-are-they Jul 25 13:27:42 The bind mount call attaches only (part of) a single filesystem, Jul 25 13:27:44 not possible submounts. The entire file hierarchy including sub‐ Jul 25 13:27:59 mounts is attached a second place using Jul 25 13:27:59 says the mount documentation Jul 25 13:28:37 tmpfs is of course attached to the host system if that is only what you mean Jul 25 13:28:44 but it might well be that it needs to be bound to the chroot. Jul 25 13:29:06 yes, see the documentation quote i pasted Jul 25 13:41:34 rburton: can you show the relevant lines from your fstab? Jul 25 13:41:37 I am not getting it. Jul 25 13:41:48 why is bitbake relying on it anyway? Jul 25 13:42:00 instead of getting the tmp variable content? Jul 25 13:42:03 it looks silly to me. Jul 25 13:42:50 lpapp: i don't run debian in a chroot Jul 25 13:44:23 but you need to get it mounted on the host as well anyway? Jul 25 13:44:33 sure, the init system does that Jul 25 13:44:46 not from fstab? Jul 25 13:45:02 correct Jul 25 13:46:11 bizarro Jul 25 13:47:57 wmat: lolz @ INSANE_SKIP_external-sourcery-toolchain-dev += "ldflags" Jul 25 13:48:53 wmat: have you tried PREFERRED_PROVIDER_virtual/* Jul 25 13:57:57 wmat: why is meta-xilinx using TCMODE = "external-csl"? Jul 25 13:58:02 instead of TCMODE = "external-sourcery"? Jul 25 14:08:06 rburton: bluelightning wmat got a clue ? http://paste.kde.org/~lpapp/pb3f03555/ Jul 25 14:08:59 NOTE: preferred version 141 of udev not available (for item udev-utils) says your distro config still thinks its (probably) denzil Jul 25 14:09:32 the pseudo problem is just incredibly frustrating. the cp says external-sourcery, i thought you were using our own compilers? Jul 25 14:11:09 rburton: no, we have used external. Jul 25 14:11:44 what is the libpseudo thingie? Jul 25 14:11:59 its like fakeroot on steriods Jul 25 14:12:30 -> /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/ Jul 25 14:12:33 oh noooes... Jul 25 14:12:41 that folder is empty btw Jul 25 14:12:56 the real problem is the cp i suspect, you'll have to debug what its trying to do and what should be there Jul 25 14:13:22 I removed the udev preference. Jul 25 14:13:27 well, I have no clue where to start the debugging. Jul 25 14:15:07 "A generic library providing simple thread-safe messaging between threads" Jul 25 14:21:54 rburton: what is this specifying? INSANE_SKIP_external-sourcery-toolchain-dev += "ldflags" Jul 25 14:22:39 lpapp: its disabling a sanity check Jul 25 14:23:05 without it you'd get a warning, which is presumably a false-positive for that package Jul 25 14:23:26 http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-INSANE_SKIP Jul 25 14:32:29 sgw1: ping Jul 25 14:33:29 lpapp: good morning Jul 25 14:33:57 sgw_: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4908 Jul 25 14:33:57 Bug 4908: normal, Undecided, ---, laurentiu.palcu, ACCEPTED , External toolchain does not work with poky dylan Jul 25 14:34:02 can you reproduce the bug at the bottom? Jul 25 14:34:43 lpapp: in a bug triage meeting reviewing the bugs now! Jul 25 14:34:43 I know meta-sourcery is not a yocto project material though, but still, any help appreciated. Jul 25 14:35:37 also, no one has reviewed the tiny change yet: https://lists.yoctoproject.org/pipermail/poky/2013-July/009056.html Jul 25 14:36:33 lpapp: it's using external-csl because it's an older set of instructions Jul 25 14:36:53 lpapp: I have not tried any of this and unfortunately do not have time to Jul 25 14:38:59 wmat: got a clue about the error though? Jul 25 14:44:45 melonipoika: that is not even a yocto layer! that is a mirror of a Classic OpenEmbedded oe-dev repository! Jul 25 14:49:27 lpapp: sort of, in so far as I've seen that pseudo error before on the mailing list Jul 25 14:49:44 lpapp: http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/15695 Jul 25 14:50:05 lpapp: see if that post rings any bells regarding your system Jul 25 14:51:26 I saw that thread. Jul 25 14:51:44 if thats the right thread it has a fix in Jul 25 14:52:09 rburton: what fix? Jul 25 14:52:27 if you find the right pseudo thread, there's a fix in it Jul 25 14:52:30 file /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc Jul 25 14:52:31 /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, stripped Jul 25 14:52:36 by fix i mean possibly hack Jul 25 14:52:41 hmm, that might be inline with the last suggestion from mark. Jul 25 14:52:44 I am using x86_64 Jul 25 14:52:50 but the external toolchain seems to be 32 bit. Jul 25 14:53:36 wmat: did you find a 64 bit toolchain? Jul 25 14:53:40 provided by Code Sourcery? Jul 25 14:53:57 hmm, that probably does not matter since we need to generate 32 bit target. Jul 25 14:54:15 although a 64 bit compiler should be able to do that, but still. Jul 25 14:54:38 Finally, you can get this message if you are on a mixed-mode (multilib) host. Jul 25 14:54:39 I.e. you have executables that are both ELF 32 and ELF64. If so, you need to Jul 25 14:54:39 configure the system to build pseudo with both target environments, otherwise Jul 25 14:54:39 only one version is generated and you'll get an error when the "other" type is Jul 25 14:54:39 being executed. Jul 25 14:54:54 how to configure the system so? Jul 25 14:56:56 lpapp: target arch is unrelated to host arch Jul 25 14:57:41 rburton: so? Jul 25 14:58:41 i 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." line Jul 25 14:58:47 just trying to be helpful Jul 25 14:58:58 ok, I think either way is fine. Jul 25 14:59:06 CS probably pushes 32 bit binaries Jul 25 14:59:47 I guess I do not need to install libpseudo on my host? Jul 25 15:00:12 bitbake builds pseudo Jul 25 15:00:17 yeah Jul 25 15:00:22 well, I have no clue to be honest. Jul 25 15:00:47 "If so, you need to configure the system to build pseudo with both target environments" -> what is that supposed to mean? Jul 25 15:01:10 lpapp: seebs is your best person to speak to about pseudo Jul 25 15:03:53 ok Jul 25 15:04:20 it is pretty hard to get Yocto work with an external toolchain. Jul 25 15:04:34 I would not be envy for pastime people who cannot even spend 8 hours a day with getting it right. Jul 25 15:05:09 this pseudo problem isn't related to external toolchains, and i've made it appear and disappear here by changing unrelated variables Jul 25 15:05:36 shouldn't the layer providers put example config files and README into their layer? Jul 25 15:05:54 well, the critical issue is the toolchain in here. Jul 25 15:06:35 lpapp: yes, that's a requirement for the yocto compatible badge Jul 25 15:07:12 rburton: ok, so meta-sourcery is not like that just yet. Jul 25 15:07:19 correct Jul 25 15:07:22 its a mentor project Jul 25 15:08:42 rburton: should I file a bugreport about the libpseudo thingie? Jul 25 15:09:33 lpapp: pretty sure there's already one Jul 25 15:09:51 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4843 Jul 25 15:09:52 Bug 4843: normal, Medium, 1.5, paul.eggleton, NEW , Issue with pseudo on 64-bit build host Jul 25 15:10:07 https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=pseudo&list_id=60922 Jul 25 15:10:51 heh, this would be fun, too: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4063 Jul 25 15:10:52 Bug 4063: enhancement, Medium, 1.5, peter.seebach, NEW , pseudo's logging and diagnostics are not very clear Jul 25 15:14:31 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4843 -> added a comment, and changed to accepted. Jul 25 15:14:32 Bug 4843: normal, Medium, 1.5, paul.eggleton, ACCEPTED , Issue with pseudo on 64-bit build host Jul 25 15:14:37 bravely... /me runs Jul 25 15:15:29 lpapp: i hope by "set you accepted" you meant "i took the bug" Jul 25 15:15:36 I wonder why seebs is not added to that report though? Jul 25 15:16:12 now, he is. Jul 25 15:16:15 no escape... :-) Jul 25 15:16:18 sorry seebs Jul 25 15:16:57 lpapp: btw my comment on that bug was in polite mode. please don't mess with bugzilla state. Jul 25 15:17:26 bluelightning: do you work on 4843? Jul 25 15:17:50 rburton: well, it is accepted Jul 25 15:17:56 as I plan to work on it if no one does already. Jul 25 15:18:02 but if someone already does, then it is accepted again. Jul 25 15:18:03 lpapp: take the assignee then Jul 25 15:18:10 see the question above to bluelightning Jul 25 15:18:21 as i said, accepted means "i am literally working on it right now, and expect to send a well-tested patch" Jul 25 15:18:28 if that isn't your intention then don't take the accepted state Jul 25 15:18:35 (and if it is, then take the assignee too) Jul 25 15:18:56 Hi guys. I've googled but didn't found useful links. How do I change keyboard layout in yocto? Jul 25 15:18:59 what is the point of having an assignee without being accepted? Jul 25 15:20:38 lpapp: i've got 30 bugs. am i working on them all right now? no. Jul 25 15:21:14 rburton: sounds bad then Jul 25 15:21:21 because others need to poke you if you work them or not. Jul 25 15:21:26 on* Jul 25 15:21:36 or just forgot to take it. Jul 25 15:21:43 anyway, I do not see the point of assignee without actual working. Jul 25 15:28:55 is there an example how to set up an own local mirror, sstate, etc? Jul 25 15:29:16 lpapp: I believe that's in the YP documentation Jul 25 15:30:10 lpapp: the short version is "share it, somehow". NFS/CIFS/HTTPD will all do. Jul 25 15:30:49 rburton: I mean what do I need to do in the yocto repository to recognize the mirror Jul 25 15:30:54 lpapp: that's in the docs Jul 25 15:31:24 ah, SSTATE_MIRRORS Jul 25 15:31:26 maybe ... Jul 25 15:31:42 you can have a local download mirror too Jul 25 15:31:45 does it work on localhost Jul 25 15:31:48 k Jul 25 16:04:43 seebs: ping Jul 25 16:17:17 can someone repaste the container log again? Jul 25 16:17:26 instead of chroot, there was some arch systemd thingie Jul 25 16:18:18 http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html Jul 25 16:19:00 no no, there was an arch and debian specific link Jul 25 16:19:03 with oe particularly. :) Jul 25 16:19:20 the guy on the link just forgot to explain why it is needed. Jul 25 16:19:27 but apparently, you cannot create symlinks inside chroot. Jul 25 16:19:29 only hard link. Jul 25 16:19:57 you can't symlink from inside to outside Jul 25 16:20:02 but you can symlink inside a chroot Jul 25 16:20:37 huh, that's interesting, hadn't seen that systemd command Jul 25 16:20:57 too bad it's part of systemd :) Jul 25 16:21:12 * lpapp needs the oe/arch/debian link again Jul 25 16:28:40 I found the root cause of the issue! Jul 25 16:31:59 NOTE: Your conf/bblayers.conf has been automatically updated. Jul 25 16:31:59 NOTE: Your conf/bblayers.conf has been automatically updated. Jul 25 16:32:01 huh ? Jul 25 16:32:13 magic! Jul 25 16:32:24 1) I hate magics. Jul 25 16:32:28 2) Nothing changed in that file. Jul 25 16:32:39 1) distro build systems are 90% magic Jul 25 16:33:01 2) presumably a false-positive Jul 25 16:33:12 majority does not make it right ... ;) Jul 25 16:34:06 you can't complain that a tool is doing something trivial and automated for you if you're using a build system Jul 25 16:35:01 trivial and automated != magics Jul 25 16:35:08 it should tell me what is doing and why. Jul 25 16:35:17 but at least the what. Jul 25 16:35:29 Updating xz ... Jul 25 16:35:33 even "magic tools" do that. Jul 25 16:35:39 looks like another bugreport to me. Jul 25 16:36:35 is it possible that poky/master has not changed since yesterday? Jul 25 16:36:40 yes Jul 25 16:36:52 last commit 30 hours ago Jul 25 16:36:54 that is fine. Jul 25 16:37:09 I wonder if anyone has time to reproduce my issue? Jul 25 16:37:10 lpapp: it re-formatted a statement, grep for that message and you'll see Jul 25 16:37:18 with cloning poky, meta-sourcery, and then I can give two config files? Jul 25 16:37:25 the issue should show up very early after running bitbake. Jul 25 16:37:31 I can reproduce it easily without my layer ... Jul 25 16:37:39 yet, kergoth claims he cannot. Jul 25 16:37:47 I suspect he has something different locally. Jul 25 16:37:49 wasn't there a comment in the bug you filed where sgw_ said he can replicate? Jul 25 16:38:10 if its the bug i'm thinking of, there is someone looking at it Jul 25 16:38:19 rburton: that was with oe-core sourcery Jul 25 16:38:27 rburton: not with the supported meta-sourcery from MG. Jul 25 16:38:33 lpapp: for that, speak to MG Jul 25 16:38:41 rburton: no no, I mean someone here Jul 25 16:38:45 who can spend a few minutes with it Jul 25 16:38:52 because it is currently 1:! Jul 25 16:38:53 1:1 Jul 25 16:38:57 I can reproduce, kergoth cannot Jul 25 16:39:02 he would love to help according to the comment Jul 25 16:39:05 he just cannot reproduce the issue. Jul 25 16:39:15 and I can, even with a brand new clone Jul 25 16:40:25 meh, I cannot attach the config files to github Jul 25 16:40:28 they only support images Jul 25 16:40:29 lame Jul 25 16:46:43 * lpapp desperately needs bitbake --clean Jul 25 16:46:56 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. Jul 25 16:46:59 rm -rf bitbake.lock cache/ downloads/ sstate-cache/ tmp/ Jul 25 16:47:04 it is very annoying to do this all the time manually. Jul 25 16:47:47 lpapp: I have not attempted to reproduce the meta-sorcery issue as that is MG's responsibility as rburton pointed out. Jul 25 16:48:08 yeah, but any volunteer is more than welcome for a few minutes testing. :) Jul 25 16:50:06 moin Jul 25 16:51:27 sgw_: well, I guess the oe-core sourcery support is not the official way anyhow. Jul 25 16:51:43 at least, I guess no one is seriously maintaining that. Jul 25 16:53:19 we use the codesourcery toolchain with oe-classic/bitbake-1.10.2-arago but i haven't tried external with yocto yet Jul 25 16:54:09 lpapp: if you can point me to your issue, i can probably try it tonight Jul 25 16:54:37 mr_science: 4908 Jul 25 16:54:53 hopefully solved by that time though. ;) Jul 25 16:56:39 regarding 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 :) Jul 25 16:56:52 (you're unignored now, so we can speed up the test cycle on getting this issue resolved) Jul 25 16:58:13 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 failure Jul 25 16:58:21 * lpapp cries for --clear Jul 25 16:59:00 sgw_: yeah, before meta Jul 25 16:59:11 sgw_: and change external-csl to external-sourcery Jul 25 16:59:15 if you have not done that yet. Jul 25 16:59:17 sgw_: https://github.com/MentorEmbedded/meta-sourcery/issues/9 has the info on my attempts to reproduce, fyi Jul 25 16:59:42 FYI, I just added NO32LIBS="0" to the meta-sourcery tcmode, to hopefully avoid that being an issue going forward Jul 25 17:00:48 * kergoth fires up a centos 5.4 VM to test there also Jul 25 17:00:56 (oldest test env i have) Jul 25 17:03:08 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. Jul 25 17:04:10 sgw_: what host? Jul 25 17:04:22 what BB_VERSION? Jul 25 17:04:43 what CSL_VER_MAIN? Jul 25 17:04:52 can you paste the build configuration as a whole please? Jul 25 17:05:04 lpapp: Master on Ubuntu 12.10 Jul 25 17:05:10 also, have you tried poky master head? Jul 25 17:05:14 64 bit or 32? Jul 25 17:06:12 posted to github issue Jul 25 17:07:34 sgw_: it would have been nice to have the same machine (qemuarm), but ok. Jul 25 17:08:17 sgw_: your meta-yocto-bsp is different Jul 25 17:08:21 perhaps due to the machine difference. Jul 25 17:09:02 sgw_: were you using my config files, third set? Jul 25 17:09:33 lpapp: honestly I have lost track, I don't know which set of your local.conf file I have Jul 25 17:10:03 it is hard to make comparison that way, unfortunately. Jul 25 17:11:09 ls /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc Jul 25 17:11:09 /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc Jul 25 17:11:20 /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -v Jul 25 17:11:20 bash: /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc: No such file or directory Jul 25 17:11:23 huh? Jul 25 17:18:32 sgw_: 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) Jul 25 17:20:53 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. Jul 25 17:24:02 kergoth: I have not ignored you for a few days now Jul 25 17:24:03 hi Jul 25 17:24:12 well, I have /usr/lib32/ld-2.17.so Jul 25 17:24:21 perhaps it is not looking into /usr/lib32, only /usr/lib? Jul 25 17:24:53 lpapp: can you do a find for libgcc_s on /usr/lib* and /lib Jul 25 17:25:20 libgcc_s? Jul 25 17:25:29 or libpthread* Jul 25 17:25:41 find /usr/lib -name \*libgcc_s\* Jul 25 17:25:41 /usr/lib/libgcc_s.so.1 Jul 25 17:25:41 /usr/lib/libgcc_s.so Jul 25 17:25:51 nothing in /lib Jul 25 17:25:54 lpapp: it's one of the files that pseudo seems to be failing to link against Jul 25 17:26:05 find /usr/lib -name \*libpthread\* Jul 25 17:26:06 /usr/lib/libpthread.so.0 Jul 25 17:26:06 /usr/lib/libpthread_nonshared.a Jul 25 17:26:06 /usr/lib/libpthread-2.17.so Jul 25 17:26:06 /usr/lib/libpthread.so Jul 25 17:26:08 /usr/lib/libpthread.a Jul 25 17:26:10 nothing in /lib Jul 25 17:26:23 right, but it is looking for 32 bit Jul 25 17:26:26 note, arch has /usr/lib32 Jul 25 17:26:51 but those pthread and gcc_s stuff is in /usr/lib32, too Jul 25 17:26:59 perhaps the stuff is not looking into /usr/lib32? Jul 25 17:27:42 please do a file on both the /usr/lib and /usr/lib32 libpthread-2.17.so (should be the actual file I think) Jul 25 17:27:43 and /usr/bin/ld is definitely 64 bit Jul 25 17:27:53 just curious Jul 25 17:28:10 file /usr/lib/libpthread-2.17.so Jul 25 17:28:10 /usr/lib/libpthread-2.17.so: 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 stripped Jul 25 17:28:16 file /usr/lib32/libpthread-2.17.so Jul 25 17:28:16 /usr/lib32/libpthread-2.17.so: 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 stripped Jul 25 17:28:39 file /usr/lib/libgcc_s.so.1 Jul 25 17:28:39 /usr/lib/libgcc_s.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2a56ef2d37d3f5f43f3ab657b4e25235cff7b145, stripped Jul 25 17:28:42 file /usr/lib32/libgcc_s.so.1 Jul 25 17:28:43 /usr/lib32/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=4c82372fdcb4f7058073bc6d06fbdc08bdd01da5, stripped Jul 25 17:28:55 Well I am at a loss then, we got past one issue and stumbled on another Jul 25 17:29:28 [Requesting program interpreter: /lib/ld-linux.so.2] Jul 25 17:29:31 seebs: any ideas why pseudo would fail to link on lpapp's machine? Jul 25 17:29:34 according to a readelf -a on the toolchain gcc Jul 25 17:29:40 so it expects that to be a 32 bit linker Jul 25 17:29:43 make sure that's the case to Jul 25 17:29:44 o Jul 25 17:30:05 * sgw_ biab Jul 25 17:30:53 Nothing obvious, although multilib hosts are a known source of trouble sometimes. Jul 25 17:30:59 the latest attached configs on the bug look solid, indeed Jul 25 17:31:30 * kergoth hasn't tried doing builds on arch in a while, remembers having to deal with /usr/bin/python being python3 Jul 25 17:31:31 what can I do to fix the issue? Jul 25 17:31:39 kergoth: that is a one liner fix Jul 25 17:31:48 added to your profile and done Jul 25 17:32:01 nod Jul 25 17:32:05 anyway, the README extension is unclear to me. Jul 25 17:32:28 at least, it does not help me understanding how to get over this issue Jul 25 17:32:30 I've never seen that pseudo build failure before, but it's unrelated to the external toolchain stuff, as its a native recipe Jul 25 17:33:00 it 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 configuration Jul 25 17:33:24 seebs: can you help circumventing the libpseudo issue? Jul 25 17:33:35 apparently, a define is not enough on the bugreport. Jul 25 17:33:48 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4843 Jul 25 17:33:50 Bug 4843: normal, Medium, 1.5, paul.eggleton, NEW , Issue with pseudo on 64-bit build host Jul 25 17:34:27 kergoth: it might be not yet related Jul 25 17:34:35 but once the libpseudo issue is fixed, it will come back Jul 25 17:34:45 note how it was coming after the libpseudo issue before, too. Jul 25 17:35:32 regardless, 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. Jul 25 17:35:33 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4908 normal, Medium+, 1.5 M3, laurentiu.palcu, ACCEPTED , External toolchain does not work with poky dylan Jul 25 17:36:35 well, documenting the local.conf usage more would be useful. Jul 25 17:36:54 I don't understand what you're referring to Jul 25 17:37:06 external-sourcery is yet mentioned for instance. Jul 25 17:37:08 the readme tells you what needs to be done, completely Jul 25 17:37:14 it's not mentioend because it's not needed Jul 25 17:37:19 meta-sourcery's layer.conf sets it for you Jul 25 17:37:21 or TARGET_PREFIX Jul 25 17:37:27 that's not needed either Jul 25 17:37:39 perhaps a note would be helpful. Jul 25 17:37:40 it searches a built in list of commonly used prefixes for sorucery toolchains Jul 25 17:37:45 because it is confusing after coming from the other end Jul 25 17:37:47 where it is needed. Jul 25 17:37:52 This is all you need Jul 25 17:37:56 if you do not wanna be explicit Jul 25 17:37:58 I'm not going to document everything people might have done following flawed instructions Jul 25 17:38:03 that could be a valuable addition to the README. Jul 25 17:38:24 it is not flawed instruction Jul 25 17:38:31 it is the official way it was before. Jul 25 17:38:32 nor does it hurt anything to set those things, as long as they're set correctly Jul 25 17:38:43 they are totally irrelevant Jul 25 17:38:50 so should not bloat the config if they are not needed. Jul 25 17:38:53 it should be made clear. Jul 25 17:39:07 I'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 mine Jul 25 17:39:18 I document what needs to be done, period. Jul 25 17:39:49 you are not helping the migration at all. Jul 25 17:39:58 I really do not understand helping people migrating is not welcome Jul 25 17:40:01 from what, crappy meta-xilinx docs? Jul 25 17:40:02 it would be a one liner after all. Jul 25 17:40:04 no Jul 25 17:40:08 from damn oe-core Jul 25 17:40:39 you developer for users, not yourself, right? Jul 25 17:40:42 develop* Jul 25 17:40:51 TARGET_PREFIX hasn't been necessary in oe-core for years. Jul 25 17:40:56 even danny handled it automatically Jul 25 17:41:13 actually danny is less than a year old only. Jul 25 17:41:37 but anyway, documentating a migration path from a certain version ... I do not understand why it is so "bad". Jul 25 17:41:39 but as i've already explained, setting those things is *not* a problem Jul 25 17:41:41 it is for your users come on ... Jul 25 17:41:45 SIGH Jul 25 17:41:49 it's not a migration, its an optimization of your local.conf Jul 25 17:41:50 let us ignore each other, and continue over email Jul 25 17:42:01 if you do not wanna help your users. Jul 25 17:42:01 good plan, i'm sick of the whining Jul 25 17:42:10 I will blog about it, and I will help *your* users Jul 25 17:42:15 what whining? Jul 25 17:42:25 suggestion from A F U C K I N G U S E R Jul 25 17:42:30 to help others Jul 25 17:43:40 * lpapp has never really understood the stubborn developers Jul 25 17:43:56 who argue against doing the work when the main goal should be helping the users as much as possible. Jul 25 17:45:51 I was not trying to do any favour for myself as I already know the lesson by learning it the "hard way". Jul 25 17:46:47 sorry guys for the capital stuff Jul 25 17:46:49 I lost my mind Jul 25 17:46:51 I apologize. Jul 25 17:47:51 * mr_science recalls the men-in-white-coats (with the extra long sleeve jackets) Jul 25 17:50:00 ? Jul 25 17:58:53 Okay, 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 reasons Jul 25 18:19:26 kergoth: seebs: did that pseudo issue get resolved by any chance? Jul 25 18:20:54 Not 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. Jul 25 18:22:26 Looking at it, PSEUDO_LIBDIR should work even if it's set to ../lib, not .../lib64, even on a 64-bit host where libpseudo.so 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. Jul 25 18:22:40 I'm expecting this to be one of those obvious single-line fixes once I have a working and non-working host to compare. Jul 25 18:22:53 seebs: 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 owners Jul 25 18:23:21 seebs: trying to debug it, I have found that the only difference between those builds was in pseudo.db Jul 25 18:23:43 seebs: and that the permissions got modified during do_package task Jul 25 18:23:47 I 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. Jul 25 18:24:04 seebs: very unfortunate when it happens on /lib/ld-* and it looses executable bit Jul 25 18:24:11 Yeah, that would be pretty bad. Jul 25 18:24:23 that's where we have discovered first :/ Jul 25 18:25:10 In 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. Jul 25 18:25:38 One cause of that can be, on 64-bit hosts, running a 32-bit binary which relinks stuff, and not having NO32LIBS = "0" Jul 25 18:26:25 that's very likely because we're using 32bit external toolchain Jul 25 18:26:30 on 64-bit host Jul 25 18:28:40 Ahh. Yes. Jul 25 18:28:50 That would indeed cause that to happen a lot, especially with the prelinker. Jul 25 18:28:56 Solution is NO32LIBS = "0" Jul 25 18:29:29 Not that I ever spent two months (1) ignoring some "harmless" messages about failing to load libpseudo.so, and (2) trying to figure out why very sporadically builds would be corrupt. Jul 25 18:29:32 That would be SILLY. Jul 25 18:30:07 :) Jul 25 18:30:18 thanks a lot I never noticed NO32LIBS before Jul 25 18:30:33 seebs: should you really be ownong Bug 4843? Jul 25 18:30:34 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4843 normal, Medium, 1.5, paul.eggleton, NEW , Issue with pseudo on 64-bit build host Jul 25 18:31:44 Good 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. Jul 25 18:37:06 i still can't see why pathologically coupling makefiles between different source repos is a good idea... Jul 25 18:37:35 * mr_science thought developers actually understood issues related to coupling Jul 25 18:41:48 unignore kergoth Jul 25 18:41:51 oopsie Jul 25 18:41:54 sorry. :) Jul 25 18:42:10 not my day, apparently. Jul 25 18:47:40 at least you're still here... Jul 25 18:49:46 * kergoth chuckles Jul 25 18:50:25 JaMa: I just added it to my tcmode now, should probably add it to the example in oe-core too (NO32LIBS) Jul 25 18:50:28 heh Jul 25 18:50:38 * kergoth should have done that a while ago, but had it in his distro config instead :) Jul 25 18:50:52 mr_science: here, but from home, and not in hacking mood. Jul 25 18:51:00 mr_science: just relaxing and enjoying the sunny evening. :) Jul 25 18:51:19 kergoth: where did you move it to? Jul 25 18:51:35 lpapp: not even lunch yet here... Jul 25 18:51:46 really belongs in the external toolchain config, since its the execution of external 32 bit binaries that requires it Jul 25 18:51:58 * kergoth is currently procrastinating doing real work Jul 25 18:52:33 i think i just found a parallel make bug... Jul 25 18:53:29 seebs: let me know if you need any information from here. Jul 25 18:53:35 I am more than happy to collaborate on solving issues. Jul 25 18:54:55 seebs: err.. one thing Jul 25 18:55:06 seebs: you think that 64 bit hosts use lib64, but that is not true for Arch Jul 25 18:55:23 seebs: since 64 bit is the common on 64 bit, they prefer to set /usr/lib to 64 bit by default Jul 25 18:55:29 and the dedicated minority is /usr/lib32 Jul 25 18:56:01 seebs: setting up arch in chroot is 10 minutes, and I can help with it if that is the only way to move forward. Jul 25 18:59:22 hmm.. i had a pseudo multilib issue on gentoo amd64 when i tried yocto there Jul 25 19:00:10 but i was much more interested in building something than debugging pseudo so i just moved everything to an ubuntu box Jul 25 19:01:10 lpapp: gentoo is the same way, ie, lib -> lib64 and lib32 sits by itself Jul 25 19:01:17 I think it makes sense Jul 25 19:01:23 because obviously 64 is the majority on 64 bit Jul 25 19:01:29 otherwise you would use the 32 bit system Jul 25 19:02:42 i (almost) always 64-bit native/multilib gentoo installs Jul 25 19:02:49 *do Jul 25 19:03:02 there'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, sadly Jul 25 19:03:06 heh Jul 25 19:03:16 and usually multilib is only for extraneous crap like firefox plugins Jul 25 19:03:57 of 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 :) Jul 25 19:04:35 mr_science: yeah, or skype. Jul 25 19:04:59 pseudo 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. Jul 25 19:05:08 Thus, it's /pseudo/{lib,lib64} Jul 25 19:05:21 And that is not contingent on what the host uses for /usr/lib* names. Jul 25 19:06:01 Going 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. Jul 25 19:06:19 well, it is blocking me right now. Jul 25 19:06:30 so at least give pointers please if you cannot do the job. Jul 25 19:06:38 also, lib32 really is very important to handle. Jul 25 19:06:45 otherwise several distros will be totally screwed. Jul 25 19:09:33 perhaps I could even give ssh access to my arch host at home. Jul 25 19:16:00 kergoth: it's well documented in local.conf example but I wasn't expecting that issues we're seeing have so simple well known cause Jul 25 19:20:55 JaMa: IMO it is a bug to specify that explicitly. Jul 25 19:21:04 it should autodetect what it needs to do. Jul 25 19:21:16 I mean it is workaround for the bug, sorry, but not a solution. Jul 25 19:21:43 yes that's what documentation for that value says Jul 25 19:27:27 JaMa: once 4843 is fixed, that variable should be history. Jul 25 19:31:08 JaMa: also, I am unlucky because even that variable does not help on Arch. Jul 25 19:40:32 so we have our first in-house package that fails randomly with make -jN (N > 1) Jul 25 19:40:54 mr_science: bugreport? Jul 25 19:41:01 the response i got was "parallel make is bad idea" Jul 25 19:41:13 LOLZ Jul 25 19:41:25 lpapp: internal = not public Jul 25 19:41:36 yeah, right. Jul 25 19:45:28 * lpapp looks for bitbake --clear reports Jul 25 19:51:52 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! Jul 25 19:52:25 sgw_: ? Jul 25 19:52:42 as for me, it is weird, I cannot even reproduce the issue now. Jul 25 19:52:48 not even the pseudo one. Jul 25 19:52:55 the only thing happend that I cleaned up the stuff Jul 25 19:53:02 happened* Jul 25 19:53:16 hmm, well, I will have some patches soon I hope Jul 25 19:53:24 EXTERNAL_TOOLCHAIN = "/usr" Jul 25 19:53:27 I only have this left. Jul 25 19:53:30 I removed the PREFIX_PATH Jul 25 19:53:34 or how it was called. Jul 25 19:53:40 and the TCSMODE Jul 25 19:53:47 I could likely even remove EXTERNAL_TOOLCHAIN Jul 25 19:53:48 EXTERNAL_TOOLCHAIN_SYSROOT I think is the correct setting Jul 25 19:53:51 as /usr is in the path Jul 25 19:53:56 ? Jul 25 19:53:58 no? Jul 25 19:54:32 "Set `EXTERNAL_TOOLCHAIN = "/path/to/your/sourcery-g++-install"` in `conf/local.conf`." Jul 25 19:54:55 probably you do not need to bother, if you install it in the path. Jul 25 19:55:12 if it is intelligent enough to pick up the one with the proper prefix. Jul 25 19:55:29 sorry, I was wrong, I can reproduce the libpseudo issue Jul 25 19:55:35 even without the hackery variable. Jul 25 19:55:50 I believe it is the matter of lib32/lib/lib64 support Jul 25 19:56:01 IMHO, guessing the library folder is wrong Jul 25 19:56:11 and the information should be obtained in a different way. Jul 25 20:03:32 well, on gentoo bitbake could actually inherit an eclass and do ${get_libdir} Jul 25 20:03:58 would be easy enough to add... Jul 25 20:04:19 I am opening a new libpseudo bugreport Jul 25 20:07:34 there you go: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4919 Jul 25 20:07:35 Bug 4919: normal, Undecided, ---, saul.wold, NEW , Failure when trying to build on Archlinux 64 bit host with 32 external toolchain Jul 25 20:07:39 seebs: sgw_ ^ Jul 25 20:23:03 okay, i'll go back and try it on gentoo amd64 again and see if i can add anything useful... Jul 25 20:23:30 or maybe you'll just fix it for me ;) Jul 25 20:23:42 heh, k, thanks in advance. Jul 25 20:25:01 seebs: so now I am seeing something different with the external toolchain and pseudo during do_install(), ERROR: ld.so: object ''\''libpseudo.so'\''' from LD_PRELOAD cannot be preloaded: ignored. Jul 25 20:25:22 seebs: pseudo builds correctly, but then this occurs during the toolchain install Jul 25 20:29:47 sgw_: that was also in a previous error posted by lpapp i believe Jul 25 20:33:40 sgw_: 4843 for that Jul 25 20:34:28 sgw_: are you using NO32LIBS = "0" now? Jul 25 20:36:13 seebs: how can I tell libpseudo to look into lib32 rather than lib? Jul 25 20:37:01 is this libpseudo a blocker for building a system anyway? Jul 25 20:37:10 desktop distributions have built without it just fine ... Jul 25 20:37:14 can we have it optional? Jul 25 20:48:31 lpapp: libpseudo provides a fakeroot equivlant with a persistent db , so it's very required Jul 25 20:50:13 sgw_: arch does not use fakeroot, nor libpseudo Jul 25 20:50:22 and arch is a fairly complex distribution. Jul 25 20:50:48 lpapp, I am not going there, different build systems for different purposes Jul 25 20:51:21 lpapp: i think fakeroot has more potential issues Jul 25 20:51:57 libseudo just needs to understand multilib environments Jul 25 20:52:21 fakeroot in the bitbake context anyway... Jul 25 20:54:28 sgw: That's interesting. Can we snoop the environment it's running in, and the executable? Jul 25 20:54:43 somehow i have a mental image of ka6sox-away caught in a tornado on his way to Oz... Jul 25 20:55:02 In 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. Jul 25 20:55:03 seebs: sure, strace or what tool, I can do reproduce it in a devshell Jul 25 20:55:04 "auntie M~ auntie M!" Jul 25 20:55:38 mr_science: I dislike both. :) Jul 25 20:55:50 sgw_: well, it is not looking into lib32 Jul 25 20:55:55 that is the issue so clearly. Jul 25 20:56:06 it looks into lib, and that is fine for Ubuntu Jul 25 20:56:10 but Ubuntu is not Arch. Jul 25 20:56:14 Well, the main thing I'd want to see would be what LD_LIBRARY_PATH is. Jul 25 20:56:21 And where you have libpseudo.so files. Jul 25 20:56:22 so we need to get libpseudo look into the right folder. How to do that? Jul 25 20:56:53 They 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. Jul 25 20:57:05 let me fire up devshell Jul 25 20:57:16 -> ./build/tmp/work/x86_64-linux/pseudo-native Jul 25 20:57:36 well, Jul 25 20:57:41 Hmm. I wonder. qemu.bbclass has its own setup for this. Jul 25 20:57:44 1) It should look into the right place Jul 25 20:57:51 in the days of old we might set an env var and let libpseudo pick it up... Jul 25 20:57:53 2) If it cannot, it should respect the manual override Jul 25 20:57:55 Oh, heyyy. Jul 25 20:57:57 seebs: another note, this is a "cp" command, and the cp works in devshell, but not when fired from the run.do_install scro[t Jul 25 20:57:57 there is no other way around. Jul 25 20:58:07 Is that under qemu_run_binary? Jul 25 20:58:09 script even Jul 25 20:58:18 seebs: no Jul 25 20:58:44 well, I can beagleboard if you are concerned about qemuarm Jul 25 20:58:46 this is the do_install for external-sourcery-toolchain Jul 25 20:58:48 use* Jul 25 20:58:58 Okay, 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. Jul 25 21:00:23 seebs, I think my issue is different that 4843 maybe Jul 25 21:00:27 I think so. Jul 25 21:02:21 seebs: Ok, so how do you want to proceed with this one? Jul 25 21:02:22 I 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. Jul 25 21:02:26 sgw_: your issue is more like 4919 Jul 25 21:03:00 seebs: how should I print that variable out? Jul 25 21:03:00 So, thinking about it, the entire build is being run with pseudo present but "disabled", as I recall. Jul 25 21:03:18 Which is why things like FAKEROOTENV, etcetera, don't have to set LD_PRELOAD or LD_LIBRARY_PATH. Jul 25 21:03:51 lpapp: no it's really a different issue Jul 25 21:04:00 sgw_: what issue? Jul 25 21:04:21 hey wait a second. Jul 25 21:04:24 I think I may have found a loose end. Jul 25 21:04:57 … 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. Jul 25 21:05:27 lpapp: my do_install() of external-sourcery-toolchain Jul 25 21:05:40 sgw_: that does not tell much to me. Jul 25 21:05:43 Interestingly, I note that prelink_image() has commented-out pieces for displaying LD_LIBRARY_PATH, LD_PRELOAD, and anything in env which matches PSEUDO. Jul 25 21:05:52 sgw_: why don't you create a bug report with a bit more details? Jul 25 21:07:55 It seems a little odd that external-sourcery-toolchain would be failing in this way when other things aren't. Jul 25 21:09:07 *thinks* sgw_, what host are you using, and what's your configuration look like? I have meta-sourcery around and can try things also. Jul 25 21:09:55 I 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. Jul 25 21:10:01 seebs: not using meta-sourcery trying to get the oe-core external-tool-chain working directly, have a patch for some bits Jul 25 21:10:44 F18 and U 12.10 (happens on both) x86-64, building qemuarm or beagleboard Jul 25 21:10:58 TCMODE = "external-csl" Jul 25 21:10:58 EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1" Jul 25 21:10:58 TARGET_PREFIX = "arm-none-linux-gnueabi-" Jul 25 21:10:58 NO32LIBS = "0" Jul 25 21:11:08 Interesting. I haven't tried the external toolchain stuff in a while, but I think I have it lying around to test. Jul 25 21:11:13 seebs that should be enough and fails quickly Jul 25 21:11:49 Tragically, my fast machine isn't either of those. But it's fast enough that I think I'll try it anyway. Jul 25 21:12:42 Huh. 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. Jul 25 21:13:09 seebs to you need a pointer to the 2009q1 toolchain? Jul 25 21:13:12 sgw_: you shouldn't be using external-csl Jul 25 21:13:26 even in oe-core its just a sstub that pulls in external-sourcery, if it still exists at all Jul 25 21:13:47 Ok, but I am not sure it will change the failure I am seeing in core Jul 25 21:13:47 I have a variety of CS toolchains, they're just not that specific one. But I think they work. … Or used to,anyway. Jul 25 21:13:49 * kergoth gets food Jul 25 21:14:30 sgw_, 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. Jul 25 21:14:33 it may not, but using it propogates problematic configurations, since people tend to copy and paste :) Jul 25 21:14:51 kergoth: got it, sorry Jul 25 21:15:35 no worries Jul 25 21:17:23 kergoth: just sent you a patch for pre-review, let me know if that's OK with you. Jul 25 21:17:30 seebs: working on a paste bin! Jul 25 21:18:29 sgw_: ah, looks fine to me, nicely done identifying the particular changes needed Jul 25 21:18:36 * kergoth never had time to look into it Jul 25 21:19:00 kergoth: between your meta-sourcery and lpapp email helped point it all out Jul 25 21:19:50 seebs: ignore me I think I just found a different problem with I looked at the script more closely Jul 25 21:20:05 seebs: # Use optimized files if available Jul 25 21:20:05 sysroot="ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. Jul 25 21:20:05 /usr/local/arm-2009q1/bin/../arm-none-linux-gnueabi/libc" Jul 25 21:20:14 seems there is more issue with generating the sysroot! Jul 25 21:20:17 Oh-hoh! Jul 25 21:20:37 I believe I know where that comes from. Jul 25 21:20:48 Because earlier, it was set by invoking gcc --print-sysroot Jul 25 21:20:58 seebs: yup, that's where I am going next! Jul 25 21:21:24 I'm a little surprised to find the stderr message showing up there. Jul 25 21:26:21 heh, it should probably not be grabbing stderr.. Jul 25 21:26:46 hey, no grabbing... Jul 25 21:26:47 And 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. Jul 25 21:26:54 yeah think! Jul 25 21:28:24 * mr_science is conditioned to respond that way Jul 25 21:28:32 especially on long car trips... Jul 25 22:23:14 seebs: here is a pastebin with the gcc and libpsuedo search http://pastebin.com/8wKaDu2r Jul 25 22:23:25 Thanks! Jul 25 22:23:50 sorry took a while had to do some other setup, that was without NO32LIBS set Jul 25 22:24:01 Oh, that's REALLY interesting. Jul 25 22:24:24 Consider: /srv/hdd/releases/dylan/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib/tls/sse2/libpseudo.so Jul 25 22:25:01 That 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. Jul 25 22:26:22 So the next question is, where did LD_LIBRARY_PATH get set originally? Jul 25 22:26:47 I am guessing it's bitbake's env since this is anon python code Jul 25 22:27:03 Hmm. Jul 25 22:27:09 bitbake -e doesn't show that being set yet. Jul 25 22:27:44 It finds the libpseudo.so once not the second time Jul 25 22:27:54 Yeah. That is also strange. Hmm. Jul 25 22:28:14 Like it looses the LD_LIBRARY_PATH on that second look up Jul 25 22:28:18 Okay, 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. Jul 25 22:28:49 Like, 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. Jul 25 22:29:20 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 wrong Jul 25 22:29:45 Hmm. That sounds very much like something is helpfully cleaning up or fixing the environment in some way... Jul 25 22:29:55 Yup Jul 25 22:31:16 I am not sure if it's the usage of PSEUDO_UNLOAD or PSEUDO_DISABLED Jul 25 22:31:28 It shouldn't be… Hmm. Jul 25 22:31:48 Okay, I think I have found a thing of which I am now suspicious. Jul 25 22:31:56 seebs: I know RP was real careful to only enable pseudo when really needed Jul 25 22:32:10 But I am still not clear on where LD_LIBRARY_PATH is coming from. But I do notice... Jul 25 22:32:28 There's a point where pseudo detects that there's no LD_LIBRARY_PATH, and you've specified PSEUDO_LIBDIR, and does the right thing. Jul 25 22:32:53 And 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. Jul 25 22:33:28 But 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. Jul 25 22:33:47 I still don't know how LD_LIBRARY_PATH is getting set, or what to, but this would be a thing that could cause problems. Jul 25 22:34:59 Which 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. Jul 25 22:35:17 seebs: in conf/distro/include/tcmode-external-sourcery.inc, there is a extc_run() which runs that gcc command, I see the PATH is set for the bb.process.run, do we need to set a PSEUDO_something there? Jul 25 22:36:37 Well, that's an interesting question. Jul 25 22:36:42 I don't know what bb.process.run does. Jul 25 22:36:57 In particular, I don't know what it does with env = {foo} Jul 25 22:37:07 and whether that might cause it to, say, wipe out other environment variables. Jul 25 22:38:35 oh. hoh. Jul 25 22:38:56 So, the options just get passed on to Popen() Jul 25 22:39:13 and Popen() says that env, if not None, is a mapping that defines the environment for the new process. Jul 25 22:39:22 Rather than, say, a mapping that overrides the current process's environment. Jul 25 22:39:59 So 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. Jul 25 22:40:16 but does not seem to? Jul 25 22:40:25 Dunno. Jul 25 22:40:41 It's at least plausible that it would be failing to recover it sufficiently. Jul 25 22:41:45 Hmm. It *should* correctly recover it. Unless it's set wrong when we get there. Jul 25 22:42:07 But if I understood the Popen() docs correctly, it should have been unset, and then pseudo should have recovered it correctly. Jul 25 22:45:24 Hmm. And it should also try to regenerate LD_PRELOAD. And that looks like it should work. Hmmm. Jul 25 22:50:39 Okay, I have a thought for this, perhaps. Jul 25 22:51:07 ata1: link online but 1 devices misclassified, retrying <= this is not good... Jul 25 22:51:16 My 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(). Jul 25 22:51:32 In the case which I think might be what's biting us. And that would at least cause this to generate quick and obvious failures. Jul 25 22:51:46 seebs: see pm for full env of gcc execve call Jul 25 23:08:44 lpapp: you still around Jul 25 23:35:52 I 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. Jul 26 01:02:41 seebs: I thought CodeSOurcery toolchains required 32 bit libs? Jul 26 01:21:30 sgw_: now, yes Jul 26 01:22:06 wmat: They do, yes. Jul 26 01:22:46 One of the problems we appear to have is that even if you set NO32LIBS to 0, we still don't actually *try* to build 32-bit libpseudo unless the host environment has a particular 32-bit header file, which is probably a poor choice. Jul 26 01:23:27 Originally, we tried to build 32-bit libpseudo on 64-bit machines if they had that file. Then the NO32LIBS stuff got added, but the check for the file wasn't changed, so there's no way to indicate "we actually require 32-bit libpseudo and if you can't build it that is a serious problem that should be reported". Jul 26 01:25:31 seebs: ah Jul 26 01:25:58 lpapp: We are making progress, I posted a patch thanks to you and kergoth for the sourcery toolchain in core, and as seebs points out we found my problem with not having a 32bit libpseudo built (different than your problem). Jul 26 01:26:52 lpapp: what we are trying to understand now is bug 4919 which is why your native build of a 32bit libpseudo is not finding the appropriate 32bit libraries from /usr/lib32 Jul 26 01:26:53 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4919 normal, Medium, 1.5, peter.seebach, NEW , Failure when trying to build on Archlinux 64 bit host with 32 external toolchain Jul 26 01:26:54 does it break when using meta-sourcery too? Jul 26 01:27:11 on a 64bit machine Jul 26 01:28:02 wmat: Yes, I beleive it failed on my machine also, but I would have to go back and check, but now that I have the gnu/stubs-32.h it will succeed. Jul 26 01:28:58 hmmm, i'm surprised Mentor didn't encounter this Jul 26 01:29:56 wmat: they do not use a sane distro. Jul 26 01:30:04 where lib is the 64 bit. :) Jul 26 01:30:16 i.e. the default is the system you are on. Jul 26 01:30:56 sgw_: do you have an arch machine? Jul 26 01:31:05 sgw_: if not, can you get one into chroot? Jul 26 01:31:17 lpapp, I am trying to build an Arch system, can you send me (by email ) a full package list that you have installed, so I don't have to go through the tap-dance of installing packages Jul 26 01:31:56 or a list that I can put on the pacstrap command line initially Jul 26 01:32:28 lpapp: I am building a VirtualBox image now Jul 26 01:33:29 sgw_: sorry, I have no any clue. Jul 26 01:33:42 sgw_: you can check what the requirement is for other distributions. Jul 26 01:34:09 lpapp: can you give me a list of what's installed on your system, that will go a long way to help. Jul 26 01:34:53 lpapp: well, it would be useless for you. Jul 26 01:35:02 and would hold you up for quite a while. Jul 26 01:35:08 as I have tons of packages installed Jul 26 01:35:17 you probably do not need 90% of it. Jul 26 01:35:20 Not having would equally hold me up Jul 26 01:35:41 because every false start will require me to install another thing Jul 26 01:35:52 sgw_: just check the requirements Jul 26 01:35:59 and use pacman -Ss for them Jul 26 01:36:11 that is what I would do. Jul 26 01:38:22 A casual check confirms that about half of the 64-bit hosts I use have x86_64 in /usr/lib, and x86 in /usr/lib32. It doesn't matter at all. Jul 26 01:40:04 seebs: well, why does it look in the wrong directory then? Jul 26 01:40:09 it should look into /usr/lib32 Jul 26 01:40:15 but it looks into /usr/lib Jul 26 01:41:09 Well, that's a really vague and open-ended question. Why does "it" look in the wrong directory? Which "it"? Jul 26 01:41:34 02:40 < lpapp> it should look into /usr/lib32 Jul 26 01:41:34 02:40 < lpapp> but it looks into /usr/lib Jul 26 01:41:37 The pseudo build specifies a -L for sqlite3 when compiling the pseudo executable which is wrong on some systems, but generally harmless if you are using the host system's sqlite, so it doesn't matter. Jul 26 01:42:57 So we have tons of successful builds where there's an extra -L which has nothing to do with anything. Jul 26 01:43:51 See, here's the thing. Jul 26 01:44:14 You said something. In that thing, you used the pronoun "it". I did not know what you were using that pronoun to refer to. Jul 26 01:44:23 So I asked you what "it" was. Jul 26 01:44:32 And you… *repasted the same two lines as though I had not just seen them*. Jul 26 01:45:12 You did not indicate whether you were talking about gcc, or whether you were talking about -L arguments or about some other compiler diagnostic, or whether you were talking about the runtime linker, or anything else. Instead, you insultingly repeated what you'd just said as though if I'd just read that I would have known what you were talking about. Jul 26 01:45:31 see the bugreport for details please. Jul 26 01:45:34 But that's not the case at all. Nothing in there tells me what "it" is. Nothing tells me where in the process you are observing a failure, or what the failure is. Jul 26 01:45:36 it is all pasted there, really. Jul 26 01:45:50 I thought you have gone through that already... Jul 26 01:45:56 See, the thing is. Without the insulting re-paste of exactly the opposite of an answer to my question, I might well. Jul 26 01:46:19 But as is, I'm going back to ignoring you because you are rude and entitled and uncooperative, and it is *not useful* to spend time trying to derive valuable information from this. Jul 26 01:46:41 there is no any insult in trying to help you. Jul 26 01:47:34 thanks you so much for stop helping with unblocking me! Jul 26 01:47:40 thank you* Jul 26 01:48:02 hack, then I cannot really say this Yocto thingie "supported". Jul 26 01:48:03 I found the repasting of the exact text I'd asked for clarification of to be insulting, because it was the opposite of an answer. Jul 26 01:48:22 Even just responding with "there's more details in the bug report" would be less obnoxious. Jul 26 01:48:31 I am tired of having issues with every setup possible. Jul 26 01:48:50 repasting is exactly repeating "it". Jul 26 01:49:03 I honestly do not know how to tell more. That is all very clear to me. Jul 26 01:49:18 Besides, the bugreport was filed relatively long ago. Jul 26 01:49:26 "it should look into /usr/lib32" <-- this sentence here. Jul 26 01:49:37 it is not an unreal expectation to read an already existing report before asking? Jul 26 01:49:39 I asked what "it" was. As in, *WHAT* should look into /usr/lib32? Jul 26 01:49:40 lpapp: I spent a good part of my day looking into this with seebs, I am working into my evening to setup a currently unsupported OS to try and test a situation that should work (lib32) Jul 26 01:49:42 gcc? Jul 26 01:49:46 sqlite? Jul 26 01:49:48 pseudo? Jul 26 01:49:49 The shell? Jul 26 01:49:50 ld.so? Jul 26 01:49:57 We have no idea. "it" should. Jul 26 01:49:58 sgw_: yeah, I appreciate that. Jul 26 01:50:03 lpapp: If you keep this up we will just punt Jul 26 01:50:18 now, that annoys me. Jul 26 01:50:25 Anyway, looking at your bug report, you're ignoring a very clear error message from the compiler and focusing on the distracting but ultimately irrelevant warnings. Jul 26 01:50:27 I am trying to help *after* my work gours Jul 26 01:50:28 hours Jul 26 01:50:35 in my leisure time Jul 26 01:50:38 see, it is 02:50 am Jul 26 01:50:52 and normal people sleep rather than collaborating here. Jul 26 01:50:56 Quick test. Run "gcc -m32 -o hello hello.c" with a normal hello world. Jul 26 01:50:59 I rather go back to sleep, I do not need this stress. Jul 26 01:51:11 everything is in the bugreport, bye Jul 26 01:51:13 If that works, and "gcc -L/usr/lib -m32 -o hello hello.c" doesn't, then you have an issue. Jul 26 01:51:28 I know it's later there, you can help by trying things, but your not willing to help that way. Jul 26 01:51:30 Eh, the bug report comes down to "lots of irrelevant errors, also key 32-bit libraries aren't installed". Jul 26 01:52:01 The compiler will search /usr/lib32 by default on a 32-bit host. The warnings about the incompatible libraries it's skipping are irrelevant. Jul 26 01:52:19 sgw_: what things, really? Jul 26 01:52:28 sgw_: information is all provided I can. Jul 26 01:52:29 What's important is that it isn't finding -lgcc and -lpthread, and if it's not finding those, that's because they're not installed. Jul 26 01:52:42 sgw_: I am trying to collaborate at *02:30* am for the fuck sake Jul 26 01:52:47 will you be here at 02:30 am, hello? Jul 26 01:53:03 Honestly, I do not feel appreciated even though I came here at fucking 02:30 Jul 26 01:53:05 I frequently am. :) Jul 26 01:53:07 so good night guys Jul 26 01:53:11 And anyway, I told you what's wrong. Jul 26 01:53:14 You can fix it or not. Jul 26 01:54:24 seebs: sorry, but you do not make any sense Jul 26 01:54:33 -L/usr/lib is unnecessary first of all Jul 26 01:54:49 secondly, I said gazillion times 32 bit stuff is in /usr/lib32 Jul 26 01:54:54 Yes, we know. Jul 26 01:55:04 echo "int main(void) { return 0; }" > hello.c Jul 26 01:55:11 gcc -L/usr/lib32 -m64 -o h hello.c Jul 26 01:55:18 I am tired, good night. Jul 26 01:55:21 see you tomorrow Jul 26 01:55:31 => A couple of "/usr/bin/ld: skipping incompatible /usr/lib32/libc.so when searching for -lc" messages. Jul 26 01:55:35 And it links successfully anyway. Jul 26 01:55:41 Because those messages are not errors, they are just warnings. Jul 26 01:56:11 The actual problem is that your compiler isn't finding the libraries it needs, and those diagnostics are irrelevant, because they aren't what's wrong with the compiler. Either the compiler's busted or you don't have *the right* 32-bit libraries in /usr/lib32. Jul 26 01:56:27 The most common problem with this setup is that you have runtime libraries but not development libraries for the 32-bit environment. Jul 26 01:57:06 I giess I am back to trying the arch linux. Jul 26 02:00:10 seebs: is there any tests I can run to help? I'm on a 64-bit Ubuntu host with a dylan source tree and old codesourcery toolchain (same as lpapp's). Jul 26 02:00:50 wmat: we really need an Arch Linux, I have an Ubuntu system (12.10) and it's fine Jul 26 02:00:59 ah, ok Jul 26 02:01:02 It's pretty easy to get the same error out of others, I believe. Jul 26 02:01:45 Pretty sure this is exactly the behavior you'd get if you had runtimes but not the -dev packages for your 32-bit stuff. Jul 26 02:02:16 And that's a really common configuration, since most systems won't install the development stuff for 32-bit if they're 64-bit native, they just install enough runtime to run the executables. Jul 26 02:02:49 seebs, but would it have the header files for 32-bit (like the stubs-32.h) without the development libs? Jul 26 02:02:56 Maybe! Jul 26 02:03:22 It's certainly possible to get some systems into that state. You could, say, have the libc-dev-32 package (whatever they call it), but omit the pthread-dev-32 and libgcc-dev-32. Jul 26 02:04:01 ah, well I am working on the arch install (both syslinux and grub failed to install, so I am kind of stuck right now) Jul 26 02:04:34 The "skipping incompatible " messages are a red herring, you can get those easily by specifying extra -L and they don't do any harm. Jul 26 02:06:11 seebs: without his package list, we can't actually determine for sure if what you suggest above is correct and he was unwilling to give that list to me. Jul 26 02:06:30 I could easily install the "right things" and have it work. Jul 26 02:07:15 That's my guess. The lib/lib32 thing is a red herring, although it might not be a bad thing to fix it just to reduce the flood of irrelevant diagnostics. Jul 26 02:08:45 don't remove those warnings, just open a ticket to document this use case in the official documentation Jul 26 02:09:42 if it turns out to be valid, that is Jul 26 02:10:27 It might not be a bad idea to, when specifying the exact path for the sqlite library, just drop the -L. **** ENDING LOGGING AT Fri Jul 26 02:59:57 2013