**** BEGIN LOGGING AT Wed Jul 17 02:59:59 2013 Jul 17 03:12:24 Hello all Jul 17 03:12:44 once sepbuildir is inherited is there anyway i can deactivate it for a certain package? Jul 17 03:12:56 B = "${S}" has no effect as i see... Jul 17 03:13:26 It is just ignored Jul 17 03:15:32 Anyone? Jul 17 07:28:33 Hi, One question: does oe limit a package size? Jul 17 07:32:03 here's my situation: after do_compile(), I got a bin file larger than 120M(the oe turn on -g in CFLAGS by default), and then do_package() produce some errors, like: Jul 17 07:32:37 NOTE: Executing RunQueue Tasks Jul 17 07:32:38 ERROR: debugedit failed with exit code 256 (cmd was '/home/karfield/poky/beaglebone/product/sysroots/x86_64-linux/usr/lib/rpm/bin/debugedit' -b '/home/karfield/poky/beaglebone/product/work/armv7a-vfp-neon-poky-linux-gnueabi' -d '/usr/src/debug' -i -l '/home/karfield/poky/beaglebone/product/work/armv7a-vfp-neon-poky-linux-gnueabi/webrtc/0.0+depot0-r0/debugsources.list' '/home/karfield/poky/beaglebone/product/work/armv7a-vfp-neon-poky-linux-gnueabi/webrtc Jul 17 07:32:38 /0.0+depot0-r0/package/usr/bin/demo_client'): Jul 17 07:32:38 /home/karfield/poky/beaglebone/product/sysroots/x86_64-linux/usr/lib/rpm/bin/debugedit: canonicalization unexpectedly shrank by one character Jul 17 07:32:40 ERROR: Function failed: split_and_strip_files Jul 17 07:32:42 ERROR: Logfile of failure stored in: /home/karfield/poky/beaglebone/product/work/armv7a-vfp-neon-poky-linux-gnueabi/webrtc/0.0+depot0-r0/temp/log.do_package.10818 Jul 17 07:32:45 ERROR: Task 10 (/home/karfield/poky/meta-karlab/recipes-rtc/webrtc/webrtc_depot.bb, do_package) failed with exit code '1' Jul 17 07:32:48 NOTE: Tasks Summary: Attempted 9 tasks of which 4 didn't need to be rerun and 1 failed. Jul 17 07:32:54 any one could help this, Thx! Jul 17 08:21:31 morning all Jul 17 08:32:57 Hey, I am trying to build a package, and I receive this error during do_package (Which I do not manually set) that I will admit I don't quite understand: http://pastebin.com/V8FHBtc7 (Recipe included). Any pointers on how to start debugging this issue? Jul 17 08:35:37 Stygia: run the shown command manually to see what the error was Jul 17 08:36:26 JaMa, Will do, hang on. Jul 17 08:36:41 stygia: i got that working yesterday with the cpan bbclass Jul 17 08:37:12 I did send a patch to print the output from commands such as objcopy during do_package Jul 17 08:37:56 stygia: never got that issue, but i recommend you move to using the cpan bbclass... everything becomes much more simple :) Jul 17 08:38:05 zibri, perl-module-dbd-sqlite? Jul 17 08:38:20 zibri, I tried it with the CPAN metaclass but I couldn't get it to work. Do you have a recipe that builds? Jul 17 08:38:48 JaMa, Also, turns out I probably don't have the program in my path, I'll look into it. Jul 17 08:41:10 stygia: http://codepad.org/JxWQcLQJ Jul 17 08:43:52 zibri, Alright, I will try. Remind/teach me... what is a "native" deb again? Jul 17 08:44:34 zibri, Why would I depend on cpan-dbi-native instead of just cpan-dbi? Jul 17 08:45:52 Stygia: if it's something that is to be run on the build host, it would be -native Jul 17 08:46:10 bluelightning, Ah, makes sense. Jul 17 08:46:17 Thanks. Jul 17 08:48:39 zibri, And of course it just worked... I swear I already tried this. Jul 17 08:48:53 zibri, Well. Thanks dude. :) You saved me quite a bit of wasted time there, then. Jul 17 08:49:10 zibri, I wonder what I did wrong, though. I've done so many CPAN recipes, I checked it for typo's so many times... Jul 17 08:49:15 zibri, Ah, well. On to the next thing. :P Jul 17 08:49:15 stygia: heh, no problem :). Jul 17 08:49:26 good luck! Jul 17 08:49:31 zibri, Hmm, just formally, do you release this code for me to use under a BSD or MIT license? Jul 17 08:49:47 whatever you want, based on your recipe you pastebinned yesterday :) Jul 17 08:50:04 zibri, Heh sure. :P I plan to put it under BSD 3-clause. Not very fond of GPL. Jul 17 08:51:40 zibri, I think your adding DEPENDS = "cpan-dbi-native" did the trick Jul 17 08:52:02 zibri, I already had cpan-dbi in my DEPENDS when I tried CPAN for this one, I believe, but it didn't work, presumably because it wants to build some stuff locally or something. Jul 17 08:52:16 yeah, that's because it's required within the Makefile.PL (i.e. run on the build host) Jul 17 08:53:06 zibri, Hmm yes, which is why I ended up doing a lot of sed's on that Makefile to ensure that local-sounding paths got redirected to the working/destination directories. Jul 17 08:53:12 Hi I'm looking for someone with a bit of SDK and Qt knowledge, as I'm trying to produce an SDK with Qt4 support (qmake) with my own custom image Jul 17 08:56:15 Stygia: of course it's up to you, but the norm is to use MIT license for metadata Jul 17 08:58:35 bluelightning, Hmm MIT is fine, but I do like the third clause of BSD, not to advertise with my name. But I think it's hardly realistic in this case. Jul 17 08:59:14 I don't recall that it's ever happened in our community :) Jul 17 09:00:01 the most likely thing that could happen would be the name of the project being used for promotion; even that's not been much of an issue (and the Yocto Project has a means for enabling that in any case) Jul 17 09:02:23 stygia: btw, the cpan-test-* rdepends can probably be discarded unless you plan to run unittests on target Jul 17 09:03:00 zibri, Presumably. But meta-cpan did list it as dependencies for this package. Jul 17 09:03:02 and they are all coremodules distributed with perl anyway :) Jul 17 09:03:13 zibri, Maybe I could just set them as depends though. Jul 17 09:03:21 zibri, Well... the OE perl is pretty messed up. And they are? Jul 17 09:04:21 they are in installed in my sysroot at least Jul 17 09:05:27 actually all the rdepends except DBI is core modules Jul 17 09:06:06 zibri, the OE perl is pretty messed up, it lacks several core modules. But this is listed as a module: https://metacpan.org/module/File::Spec Jul 17 09:06:21 zibri, And not as part of perl 5.14.3, _possibly_ 5.18 though. Jul 17 09:07:00 stygia: nope, File::Spec was introduced in 5.4.5 Jul 17 09:07:20 stygia: try `corelist File::Spec` :) Jul 17 09:09:01 zibri, Then why is it shown as a separate module on metacpan? Jul 17 09:09:54 a lot of modules live dual lives, e.g. for backporting fixes. active development is usually made outside of perl, but merged to perl on release etc Jul 17 09:20:07 zibri, Weird. Jul 17 09:20:29 zibri, Well, I will look into it. Once we have everything building here, you and me can perhaps try and fix the OE perl recipe, as that recipe only includes the bare minimum. Jul 17 09:21:04 zibri, Would you believe that inteteger.pm, vars.pm, attributes.pm and similar things aren't even installed by default? Jul 17 09:21:31 zibri, I had to make this bbappend to even make simple perl things work: http://pastebin.com/Sx2KX8qP Jul 17 09:22:33 stygia: hum, i have those in my sysroot Jul 17 09:23:14 zibri, Hmm, your BB sysroot? They may _be_ there, but unless they go in FILES they aren't actually deployed. Jul 17 09:23:22 although, some of the modules in your list aren't core modules (e.g. URI and URI::Escape) Jul 17 09:23:50 zibri, OH wait, nice spotted, I have those as modules, fixed it. :) Jul 17 09:25:33 stygia: the FILES variable only affects stuff being picked up for packaging from the per recipe destination dir (e.g. ${WORKDIR}/image) if i understand correctly. Jul 17 09:26:40 if things wasn't included in FILES, but installed, we would get qa warnings when running bitbake Jul 17 09:27:06 zibri, Yea... you would think so. And yet, when I used the standard perl recipe and deployed, crucial modules like intereger.pm were missing. Jul 17 09:27:20 zibri, It took quite a while to allow even simple modules and my script to work. Jul 17 09:29:13 stygia: i think you have to rdepend on perl-lib Jul 17 09:29:36 FILES_${PN}-lib = "... ${libdir}/perl5 ..." Jul 17 09:29:50 (from the perl recipe) Jul 17 09:30:49 Is there someone who can nudge me in the right direction for generating a Qt SDK? Jul 17 09:32:24 zibri, That's... possible, I guess? But ${libdir}/perl5 cgertainly doesn't contain _all_ the files, they are pretty scattered. Jul 17 09:32:45 zibri, Actually they were almost all in ${libdir}/perl/5.14.3/ Jul 17 09:34:28 /usr/lib/perl5 is a symlink to /usr/lib/perl :) Jul 17 09:35:17 zibri, Ah well... fair enough then. :P Jul 17 09:35:26 zibri, And dear fuck... if you're right I've wasted so much time. Jul 17 09:35:43 zibri, Someone really needs to mind the OE documentation more. I'm probably gonna write a OE crash-course tutorial thing once I'm done here. Jul 17 09:38:56 Stygia: we've a documentation writer, so if there's any problems/missing sections then feel free to file bugs Jul 17 09:40:10 rburton, I may take you up on that. Just to verify, I should file the bug with the yocto project, yes? Jul 17 09:42:03 rburton, I never got the whole oe/bitbake/poky/yocto thing straight honestly. Jul 17 09:47:25 Stygia: yes Jul 17 09:48:49 the short version is that Yocto is an umbrella project, containing bitbake (the build tool) and oe-core (the core metadata). poky is a reference distro build using bitbake+oe-core. the rest of "oe", such as meta-oe, isn't actually part of the Yocto Project, although its simple for any layer to be Yocto Compatible and so on. Jul 17 09:50:03 rburton, Ah right, makes sense. Thanks dude. :) Jul 17 09:50:28 the confusing this is the layers that make up poky are called meta-yocto. that's stupid. Jul 17 09:51:33 rburton: just report documentation bugs to filezilla? Jul 17 09:51:42 rburton: eerrrr bugzilla -.- Jul 17 09:51:44 fenrig: yeah Jul 17 09:51:58 rburton: okay will do :d Jul 17 09:52:01 bluelightning: hi, are you awake yet? Jul 17 09:52:54 zecke: yep Jul 17 09:53:16 bluelightning: hehe, is there a command to 'prune' the sstate cache? Jul 17 09:53:56 zecke: there is, one sec Jul 17 09:54:10 bluelightning: my laptop is running low on disk space. Jul 17 09:54:24 zecke: sstate-cache-management.sh (under scripts/) Jul 17 09:56:46 ah thanks. let me see if that works for edison too. :) Jul 17 09:58:35 it does :) Jul 17 12:14:08 rburton: If you have time please comment here: http://patches.openembedded.org/patch/53489/ Jul 17 12:14:18 I want to finish it before getting into something else Jul 17 12:27:40 mshakeel: sorry for not doing so before, done Jul 17 12:45:26 rburton: thanks, then I just need to make sure that do_install_append() in systemd.bbclass is appended after any package recipe do_install_append() Jul 17 12:45:45 good point. Jul 17 12:45:47 must be a way to ensure that Jul 17 12:45:57 do it as a package postprocess func? Jul 17 12:46:04 that's hopefully not too *late* Jul 17 12:47:19 yes, seems like either we need a post func of do_install or we can prepend do_package Jul 17 12:47:45 PACKAGE_PREPROCESS_FUNCS? Jul 17 12:48:32 could add a new task in the class, that would work. Jul 17 12:48:44 I was thinking something similar to: do_install[postfuncs] += "func_for_systemd" Jul 17 12:49:03 yes, a new task will make things simpler Jul 17 12:49:05 bluelightning: any opinion on the best place for a class to go in and delete files after do_install? Jul 17 12:50:04 options appear to be a new task added by the class / do_install[postfunc] / PACKAGE_PREPROCESS_FUNCS Jul 17 12:51:16 I just gave it a run and do_install_append() from systemd.bbclass is the first thing appended in do_install Jul 17 12:52:29 assuming the inherit happens first, that would make sense Jul 17 13:41:17 i'm trying to rebase a very custom system from danny -> dylan, and mostly was easy except the kernel install is looping infinitely doing "depmod"; sound like a familiar symptom to anyone? Jul 17 13:41:50 it's quite painful to read all the generated shell script and try to debug that way Jul 17 13:45:30 zeddii: ^ any ideas? Jul 17 13:46:11 ohh...maybe it's not an infloop, it's just running depmod after each individual kernel module rpm install Jul 17 13:49:11 * zeddii reads Jul 17 13:50:29 depmod would be running as part of the kernel.bbclass, so no need to look at any generated shell code, and yes, there's nothing terribly efficient about the kernel packaging and install at the moment .. but it is better than it used to be. Jul 17 13:52:58 do you guys make use of rpm %posttrans anywhere? git grep says no but Jul 17 13:53:06 it's significantly more efficient Jul 17 13:54:06 walters: that sounds like a useful thing, I guess nobody ever got around to doing something like that Jul 17 13:55:05 walters: I guess the difficulty would be it would need some kind of generic hint of which postinstalls (or which parts of a postinstall) could be deferred *if* the package backend supports it Jul 17 13:55:45 yeah, dpkg's approach is different, and opkg... well, is opkg. Jul 17 13:55:59 * rburton curses gtk and goes to walk the dog instead Jul 17 13:58:09 rburton, what'd gtk do? Jul 17 14:04:02 bluelightning_: I have a theory and maybe you find a flaw. kernel.bbclass does not appear to pass TUNE_CC (e.g. no -march=arm..) to the kernel compilation.. my kernel appears to die in unaligned memory access.. cat /proc/cpu/alignment shows system issues Jul 17 14:04:45 bluelightning_: now I wonder what gcc 4.8.1 optimizes for by default (I am on arm9/armv5t) system.. so somehow I think gcc will generate unaligned memory access by default now? Is that plausible? Jul 17 14:05:08 Hi Jul 17 14:05:19 how do I enable sftp support in my image? Jul 17 14:05:36 zecke: I don't know I'm afraid, not my area of expertise... zeddii or khem would be the best people to speak to about that I would think Jul 17 14:06:12 khem: ping? Jul 17 14:06:16 fenrig: server or client? Jul 17 14:06:25 bluelightning_: server ;) Jul 17 14:07:14 fenrig: add "openssh-sftp-server" to IMAGE_INSTALL Jul 17 14:07:30 bluelightning_: cool, how do I find this information? Jul 17 14:08:15 zecke, the kernel shouldn't be taking tune arguments from a build system, it knows best for any given arch. Jul 17 14:08:42 if there's a bad tuning, we need to look into kernel patches, not passing build system arguments in, that would potentially be toolchain specific. Jul 17 14:09:00 fenrig: I just did "git grep sftp" to find that... Jul 17 14:09:15 bluelightning_: ah okay sorry :/ Jul 17 14:09:25 bluelightning_: could have found that myself then :/ Jul 17 14:09:44 fenrig: well sometimes it's not that easy Jul 17 14:10:05 zeddii: http://paste.lisp.org/display/138077 is the first two oopses I get Jul 17 14:10:30 zeddii: that is 3.2.48 + two memset fixes from newer kernel releases Jul 17 14:13:44 zeddii: http://paste.lisp.org/display/138077#1.. so I wonder if the data abort is a red herring or not. :} Jul 17 14:14:43 zeddii: same kernel compile with GCC 4.6 (minus the two memset patches is okay). I will now build with gcc 4.6 and the two new patches. :} Jul 17 14:16:39 * zeddii looks Jul 17 14:17:38 zecke, I don't have all the background. you are seeing the traps with what ? gcc 4.8 ? Jul 17 14:17:59 zeddii: gcc 4.8.1 from oe-core as of today Jul 17 14:18:38 ok. so perhaps not surprising. We've been through lots of issues with gcc 4.8 and the kernel. What arch was this again ? Jul 17 14:18:54 zeddii: ARM, armv5t Jul 17 14:19:01 * zeddii nods. Jul 17 14:19:41 if you are using the same two memset fixes that we've been discussing on the mailing lists, you are most of the way there, but 3.2 may be missing more. Jul 17 14:20:15 walters: change "something" between 2 and 3, so now my widget grows in a size-allocate loop forever Jul 17 14:22:30 ah Jul 17 14:22:35 yeah the sizing stuff is...messy Jul 17 14:25:11 cool, finally got a basic Cross development enviroment working Jul 17 14:27:52 with Qt Creator ;) Jul 17 14:34:43 congrats fenrig :) Jul 17 14:36:25 ok, i replaced the pkg_postinst_modules() in kernel-module-split.bbclass with /bin/true for now...this build system ends up running depmod in a different layer anyways, and that got me going Jul 17 14:40:45 Random question ; some recipes seem to have a "files" directory in the same dir as the .bb, others have a dir the same name as the recipe name - is there any particular convention? Jul 17 14:42:15 pev: I guess "files" is common to all recipes in that directory. A directory named after the recipe is only for that particular recipe. Jul 17 14:42:41 you'll also see foo-1.0 where patches are specific to a single version Jul 17 14:42:55 I think you can also use - to apply restrictions per version. Jul 17 14:45:12 Thanks :-) Jul 17 14:46:20 You're welcome. :-) Jul 17 14:58:37 Ok, so another fun question - I'm looking at how to put together a shared library recipe under yocto. I'm trying to use a simplish example to break down so im looking at ./meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb to start with. I can see how "FILES_${PN}-dev" handles the libs, but I'm not sure what happens to the header files? Do they not need to be exported somehow so other apps building can find them or is that down to the Makefile of the package itself? Jul 17 14:59:52 the makefile is expected to install them to (usually) /usr/include Jul 17 15:00:01 and then they go into PN-dev Jul 17 15:01:05 even though /usr/include isnt in -dev's FILES? Jul 17 15:02:50 it is by default Jul 17 15:02:55 see bitbake.conf Jul 17 15:03:07 Cool. Also, what part of the Makefile should do the install? If it's under a "install:" rule, does the build system make that by default? Jul 17 15:03:26 or do I need to put the install under my "all:" rule? Jul 17 15:03:38 now you're entering style choices Jul 17 15:03:50 autotools-style is "all" is build, and "install" is install Jul 17 15:04:12 and they'll get ran by default Jul 17 15:04:40 no, i'm wrong Jul 17 15:04:45 I'm trying to keep simple and just have raw source and a Makefile avoiding autotools :-D Jul 17 15:05:03 writing a raw makefile *and* supporting cross compilation isn't always easy Jul 17 15:05:25 but if you insist, have an install rule that installs the files Jul 17 15:05:26 I have no doubt of that :-P Jul 17 15:05:29 and call that in your do_install() Jul 17 15:05:37 Great, I'll give that a shot! Jul 17 15:05:47 by *default*, we run make in the compile phase, and hope the recipe knows what its doing to install Jul 17 15:05:56 ie autotools.bbclass knows it can run make install Jul 17 15:12:24 anybody knows what can be the root cause of that error: ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. it was found on an ubuntu 12.04 64-bit machine. Jul 17 15:15:16 there's a patch for that Jul 17 15:15:21 i thought it was merged already Jul 17 15:16:25 FAKEROOTBASEENV in bitbake.conf Jul 17 15:16:29 should end in lib64 not lib Jul 17 15:16:38 "Issue with pseudo on 64-bit build host" on oe-core Jul 17 15:16:48 seebs: was that resolved or still pending a fix from someone? Jul 17 15:17:09 i have seen that on dylan. Jul 17 15:21:46 Another (possibly) silly question I'm afraid...! In the simple Makefile I do a "CFLAGS -I. -fPIC" which works correctly. However when bitbake calls it, if I look at the output it seems that CFLAGS appears to have been overwritten! Jul 17 15:21:58 zecke: yes Jul 17 15:22:18 pev: yes, that's how make behaves Jul 17 15:22:54 the environment definition overrides the makefile Jul 17 15:23:34 So if I need to add to what yocto uses to override? Or just use a different env name in the makefile for the flags I dont want overriden? Jul 17 15:23:58 up to you. last time I wrote a makefile from scratch i think i used my own varname inside . Jul 17 15:24:39 thanks! Talk about learning curve :-) Jul 17 15:26:46 rburton: about the pseudo issue, not all hosts seem to be impacted. is that expected? also we use dylan, not master, and FAKEROOTBASEENV has been added after dylan. Jul 17 15:27:31 OK, back to the doing an install... in my install rule I need to pass the location where to install to. Is that what in autotools land would have been dealt with by PREFIX? Jul 17 15:27:36 ndec: i made the problem go away by switching from rpm to ipk, so i'm not sure it's entirely understood Jul 17 15:27:54 well, we use ipk. Jul 17 15:28:02 pev: no, prefix is the real location ("/usr") and DESTDIR is used to re-parent it temporarily for packaging Jul 17 15:28:48 so use $DESTDIR in all of your install commands Jul 17 15:29:00 this is about the point when people realise that modern autotools isn't all that bad Jul 17 15:29:44 Yep! Looks like $DESTDIR doesnt get set for some reason though... Jul 17 15:30:40 I've just been putting off learning how to use autotools for years... I'm told it shouldnt take long to figure out for something simple like this though...! Jul 17 15:31:12 pev: sure, you'll have to set something like DESTDIR yourself Jul 17 15:31:20 as i said, that's what autotools does Jul 17 15:31:24 if you're writing it yourself you get to define it yourself Jul 17 15:31:33 call it I_HATE_MAKEFILES if you want :) Jul 17 15:31:57 Sorry, I thought you meant it was automagically set by bitbake... Ack that! Jul 17 15:31:59 autotools_do_install is basically this: oe_runmake 'DESTDIR=${D}' install Jul 17 15:36:51 Bollocks to it, I'll read the autotools chapter of 21st C C tonight....! :-D Jul 17 15:39:26 autotooling a small library is entirely trivial Jul 17 15:41:57 rburton: Hopefully it will be after I've read up on it :-) Jul 17 16:03:35 my thoughts on autotools always come down to: they suck, but they suck in known, predictable ways we can workaround, which is more than we can say for some other homerolled systems :) Jul 17 16:05:50 ndec: I'm not sure but I can see the same issue could happen with previous versions because we set PSEUDOLIBDIR to point to ..../lib rather than ..../lib64 in scripts/bitbake Jul 17 16:06:46 bluelightning: my initial guess was that it relates to 32-bit vs 64-bit too, even before this discussion. Jul 17 16:06:53 khem: hi! i am rebuilding.. and rebuilding again (I added -mno-unalign... to the conf/machine/include for armv5 but removed it again). Once my laptop reaches kernel compilation again I will check if my kernel compilation passes -march=armv5... properly Jul 17 16:07:04 bluelightning: the problem is that it happens on someone's PC which i don't have access to. Jul 17 16:08:07 ndec: sure... as a workaround you could get them to try editing scripts/bitbake to use lib64 and see what happens Jul 17 16:08:47 seebs: this is a bit puzzling... you said in the thread it should install to a lib64 subdirectory, so if that's the case how can we ensure PSEUDO_LIBDIR gets set correctly? Jul 17 16:09:54 also, is that clear why it doesn't happen to everyone? that guy isn't using a fancy distro... but ubuntu 12.04.. Jul 17 16:10:12 is there any 'host contamination' somehow? Jul 17 16:10:28 ndec: I'm not yet clear on that either Jul 17 16:11:12 * ndec never opened script/bitbake so far ... ouch... Jul 17 16:11:23 * kergoth chuckles Jul 17 16:11:25 ndec: yeah, it's gone in master :) Jul 17 16:11:48 really, that looks like one incentive to move ;-) Jul 17 16:12:09 it existed to work around the issue that bitbake needed to be re-run under pseudo but pseudo wasn't initially built Jul 17 16:12:35 then a few other things got thrown in there (e.g. fixes for broken host tar/git) Jul 17 16:13:23 re master, I wouldn't switch to it for production Jul 17 16:13:24 well, 'few other things', that's a neat way to say it! Jul 17 16:13:35 heh Jul 17 16:13:43 no, we can't use master for now. Jul 17 16:13:48 for sure. Jul 17 16:14:35 ok, so what you want me to try is to modify almost the very last line in script/bitbake. e.g. PSEUDO_BINDIR=$PSEUDOBINDIR PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo $BITBAKE $@ Jul 17 16:16:18 ndec: right Jul 17 16:16:26 interestingly, on my machine where i don't get any issue (and running 13.04/64-bit), libpseudo is here tmp/sysroots/x86_64-linux/usr/lib/pseudo/lib64/libpseudo.so Jul 17 16:16:42 ndec: indeed, same here on my CentOS 6.4 build machine Jul 17 16:16:50 (also 64-bit of course) Jul 17 16:17:34 it might be some subtlety about LD_LIBRARY_PATH already pointing to the right location, except for on the affected systems Jul 17 16:19:06 is pseudo bin supposed to 'link' against libpseudo? Jul 17 16:19:18 mine doesn't. Jul 17 16:19:29 at least not explicitely (objump -p) Jul 17 16:20:04 * kergoth mulls over altering binreloc to support macs Jul 17 16:21:34 ndec: no, I think that's expected Jul 17 16:22:58 bluelightning: running from devshell, i get this: Jul 17 16:22:58 # echo $LD_LIBRARY_PATH Jul 17 16:22:58 /work/rdk/build-dylan-qemuarm/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib:/work/rdk/build-dylan-qemuarm/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib64 Jul 17 16:23:13 so, something is indeed appending the right folder here Jul 17 16:23:41 ndec: hmm, interesting Jul 17 16:23:55 and Jul 17 16:23:55 echo $PSEUDO_LIBDIR Jul 17 16:23:55 /work/rdk/build-dylan-qemuarm/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib Jul 17 16:37:42 moin Jul 17 16:50:33 bluelightning: ok, i have asked our dev to send me a lot of information (variable dumps, tarball of pseudo, ...). he is probably sleeping by now, but i should be able to study the logs tomorrow morning. Jul 17 16:52:40 i really don't see where LD_LIBRARY_PATH is being modified... i suspect this can be related to the presence of 32-bit header files (stubs-32.h)... Jul 17 16:53:36 e.g. libc6-dev-i386 on ubuntu. Jul 17 16:54:20 ndec: hmm, that might possibly have something to do with it Jul 17 16:54:39 pseudo build itself seems to be impacted by that, at least. Jul 17 16:54:50 ndec: FWIW I am setting up an Ubuntu 12.04 64-bit machine here to run some tests (and incidentally because we need another build machine) Jul 17 16:55:05 * ndec is doing that too locally ;-) Jul 17 16:55:16 well, a chroot, not a real machine. Jul 17 16:55:39 I have a VM already but unfortunately I'm too short of space on my laptop to use it for a full build Jul 17 17:00:34 bluelightning: i am going away now. i hope to get more data tomorrow. thanks a lot for your help. Jul 17 17:07:05 ndec: no problem Jul 17 17:07:10 cu later Jul 17 17:07:17 As I recall, pseudo has some code to try to fix up the library directory. I think we do have a known issue in some cases, but I haven't yet had a chance to go stare at it and try to figure out what's up. Jul 17 19:06:28 hi guys Jul 17 19:06:41 I have an issue with my Yocto build for RaspberryPi Jul 17 19:06:42 basically, on first boot everything works fine, but any subsequent boots then networking stays down Jul 17 19:07:08 please don't spam to multiple channels :) Jul 17 19:07:20 I can manually bring it up, by logging in locally, then issuing "ifdown eth0" then "ifup eth0" Jul 17 19:07:22 hi kergoth, been a bit :) Jul 17 19:07:55 hey, how goes it Jul 17 19:08:00 pretty good Jul 17 19:08:16 you interested in doing some consulting work? Jul 17 19:08:59 sorry - I tried in #poky but there wasnt many people in there Jul 17 19:09:20 here is best, indeed Jul 17 19:09:36 or contact the folks that maintain the raspberry pi layer, they might have hit it before Jul 17 19:10:02 ok thanks Jul 17 19:10:15 it sounds like your /etc/network/interface is misconfigured, unless you're using NetworkManager Jul 17 19:10:19 google is giving me nothing - so I am just trying to rule out HW or something Jul 17 19:10:48 its possible. try adding 'auto eth0' to /etc/ntework/interfaces and rebooting, as a starting point Jul 17 19:11:06 does it get built/changed on first boot? Jul 17 19:11:24 I am based on minimal platform - so CLI only Jul 17 19:11:28 first boot runs a ton of package postinst scripts which diodn't run at image creation time Jul 17 19:11:34 ah ok Jul 17 19:11:48 not everything can be run at build time due to the cross-compilation Jul 17 19:11:53 so maybe the initial interfaces file is good - but the post-inst one is bad (but looks fine) Jul 17 19:12:00 of course Jul 17 19:12:13 it sounds like the other way around. you said first boot worked, so it sounds like the postinst brought up the interface Jul 17 19:14:17 yeah - so I wonder if something altered the interfaces file, after the bring up Jul 17 19:14:42 unlikely, more likely the interfaces file just doesn't have 'auto' in it, which is what makes it automatically bring up the interface on boot Jul 17 19:14:48 which is why i suggested adding it about 5 minutes ago Jul 17 19:14:53 :) Jul 17 19:15:04 it did have auto in it Jul 17 19:15:16 I have completely wiped and rebuilt the file now Jul 17 19:15:20 just testing Jul 17 19:15:28 check syslog, see if there were any errors when it tried to bring up the interface on boot Jul 17 19:15:30 it did have some extra interfaces which I wont be needing Jul 17 19:15:52 eth1, wlan0 etc Jul 17 19:15:52 could be a timing issue, trying to bring it up before its ready? *shrug* Jul 17 19:15:56 tough to say, many variables Jul 17 19:16:06 indeed - appreciate your thoughts Jul 17 19:16:19 sometime it takes someone to point out the obvious :D Jul 17 19:16:29 np, good luck with it Jul 17 19:16:57 seems that a "clean" file is working after reboot and power cycle Jul 17 19:17:21 might need to alter the base image files to just keep it simple :) Jul 17 19:18:02 probably best off creating a new empty layer and adding a bbappend to base-files to provide your own default interfaces file without modfiying the core Jul 17 19:18:12 yeah Jul 17 19:18:24 im very very new to this (started on Monday) so still learning Jul 17 19:18:27 * kergoth nods Jul 17 19:18:39 I gathered I can override certain things that way Jul 17 19:18:57 hmm ok - powercycle and its not coming back up again Jul 17 19:19:00 random Jul 17 19:19:40 does sound like timing could be a concern. maybe you can drop the 'auto' from interfaces and see if it gets brought up by udev when the device shows up (used to be called coldplug)? Jul 17 19:19:42 * kergoth shrugs Jul 17 19:23:53 hmm - removed auto from eth0 and after a boot only lo came up Jul 17 19:24:30 I will look at the timing - but I would imaging the RPi guys would be on this if it was a generic issue Jul 17 19:25:41 couldn't hurt to talk with them, see if anyone else has hit a similar issue Jul 17 19:26:05 just gotta find a way to reach them Jul 17 19:26:14 mailing lists arn't my thing :( Jul 17 19:32:41 heh, you won't get much done without using mailing lists around here Jul 17 19:34:14 I can tell :D found the OE RPi link - let's see if anyone bites Jul 17 19:34:32 thanks for your pointers - glad to know Im not just being thick Jul 17 19:35:04 np Jul 17 20:07:01 How can I make my image bigger so I have room for logfiles on the target? Jul 17 20:07:33 I tried adding IMAGE_ROOTFS_EXTRA_SPACE="1048576" to my core-image-myimage.bb to no effect. Jul 17 20:15:33 Circuitsoft I was just looking at this, how random :) Jul 17 20:15:46 I think I read that it can be awkward Jul 17 20:15:50 but that it about it Jul 17 20:19:16 awkward is the guy sitting next to you ragging on open source developers for things they can't even control... Jul 17 20:20:07 i guess other than one of our subs, i'm the only "open source" guy here now. Jul 17 20:24:30 hey mr_sceince - thanks for the pointers the other night Jul 17 20:24:34 got me sorted Jul 17 20:25:42 RichBayliss_: np Jul 17 20:26:18 mr_science: I've been that guy... can be difficult sometimes, hang in there :) Jul 17 20:45:02 one more jenkins deployment enhancement... Jul 17 20:45:24 kinda like "just one more theeen leeetle mint..." Jul 17 21:09:04 * mr_science wonders why someone's ant build config would suppress all compiler warnings... Jul 17 21:18:06 maybe the IDE interface is just too scary with all those warning hihjlights Jul 17 21:18:21 *highlights even Jul 18 00:12:35 has anybody tried putting everything into /usr before? and linking /[s]bin to /usr/[s]bin etc. kinda like the way Fedora does things now. Jul 18 00:16:25 I know busybox puts stuff in /bin and /sbin. This could be solved. glibc is installed in lib when I want it to go in /usr/lib. Jul 18 00:17:10 has anyone tried changing base_prefix to something other than ""? Jul 18 00:18:56 do you think it would break many packages? Jul 18 00:31:34 myopiate, i have a brutal hack to do it but it operates after the packages Jul 18 00:32:26 myopiate, https://github.com/cgwalters/poky/commit/2ecded006b59455e3e55bbdd029ea089a1e1eddf - if you want the packages to have UsrMove, i suspect it'd be a lot of work Jul 18 00:44:48 walters, thanks! I had thought about doing it this way. it is probably all i need **** ENDING LOGGING AT Thu Jul 18 02:59:58 2013