**** BEGIN LOGGING AT Wed Sep 26 02:59:58 2012 Sep 26 07:16:39 morning Sep 26 07:28:45 NIGHT Sep 26 07:28:47 oops Sep 26 07:28:49 night Sep 26 07:28:53 keyboard lol Sep 26 08:01:50 morning all Sep 26 08:06:17 'morning =) Sep 26 08:21:08 hello Sep 26 08:23:18 morning hrw, all Sep 26 08:31:01 hi bluelightning, hrw Sep 26 08:31:08 hi silvio Sep 26 08:51:30 can someone remidn me syntax for min/max revision for applying patches? Sep 26 08:51:54 file://fix.patch;maxrev=23242;minrev=5454 or other it was/ Sep 26 08:51:57 ? Sep 26 09:27:03 bluelightning: do you know is meta-toolchain buildable at all with current oecore? Sep 26 09:27:48 hrw: where does it fail for you? Sep 26 09:28:13 | The directory that should contain system headers does not exist: Sep 26 09:28:23 | /home/hrw/HDD/devel/canonical/aarch64/build/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-linux/usr/include Sep 26 09:28:52 tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-linux/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/include/ exists instead Sep 26 09:32:13 http://pastebin.com/uVFXF7kJ is 'bitbake -e meta-toolchain' output Sep 26 09:32:16 brb Sep 26 09:34:44 hrw: it's not something I build regularly on my own machine; I'm building it now though Sep 26 09:40:21 morning all Sep 26 09:40:31 hi pb_ Sep 26 10:02:28 phew, finally I have managed to rid my builds of perl again Sep 26 10:07:12 nice Sep 26 10:09:14 yeah. well, I guess I should have made a fuss at the time the dependencies on perl got added. apparently I failed to notice that at the time it happened. Sep 26 10:10:34 hrw: for me it fails in nativesdk-perl Sep 26 10:19:35 JaMa: which way? Sep 26 10:22:34 hrw: FWIW, I just built it successfully Sep 26 10:24:12 if i add a kernel_do_install_append() function in my kernel recipie will it be executed (it inherits from kernel..bbclass) ? Sep 26 10:25:01 bluelightning: thanks Sep 26 10:25:14 afournier: add do_install_append() Sep 26 10:25:21 ok Sep 26 10:26:19 hrw: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/028990.html Sep 26 10:27:47 JaMa: same problem I had Sep 26 10:28:09 but first need to build gdb-cross_git Sep 26 10:28:20 7.5 is a bit old Sep 26 10:35:49 what would be the cause of .so and .so.(shorterversion) not being symlinks but real libraries that are almost the same size as .so.(fullversion) - about 4-bytes difference? Sep 26 10:38:06 accidentally making a hard link rather than a symlink, maybe? hard to think what would cause a difference of 4 bytes though. Sep 26 10:40:32 yes, that was the strange bit - I was suspecting installation with cp -L before I noticed the slight difference Sep 26 10:41:38 you could imagine that the .so.fullversion might be getting post-processed in some way after installation (e.g. stripping) which would make it a bit different, but I can't think offhand of anything that would be likely to make it differ by only 4 bytes Sep 26 10:41:47 they are actually different versions accidently made by link breakage at some point Sep 26 10:44:14 well this is a from-scratch build of the recipe as far as I am aware... silvio can supply further details, it's his issue I was trying to help with Sep 26 10:47:35 Now I have to go afk, after I check source of package Sep 26 10:48:03 anyway I try to made a recipe for latest version of qjson Sep 26 10:48:48 wow.. this is more complicated than rocket science, getting oe to use a self-build external toolchain Sep 26 10:52:33 using the sourcery config/recipes as example is maybe not the best idea, the structure of the self-built sdk is radically different from the sourcery toolchain Sep 26 11:01:38 you dont have enough black sourcery :-) Sep 26 11:02:56 mana++ Sep 26 11:03:24 * XorA taps JaMa for an extra mana Sep 26 12:32:56 meh.. now pseudo depends on the external toolchain, and the external toolchain depends on pseudo Sep 26 12:41:59 pseudo, or pseudo-native? Sep 26 12:42:11 there doesn't seem to be any good reason for pseudo-native to depend on the toolchain. I think that must be a bug. Sep 26 12:42:37 conversely, pseudo would (obviously) depend on the toolchain, but the toolchain shouldn't depend on it. Sep 26 12:43:25 uhm yes, pseudo-native indeed Sep 26 12:43:52 i have nu clue where to begin to debug this Sep 26 12:44:13 where exactly is the dependency showing up? Sep 26 12:45:22 external-foo-toolchain.do_instal depends on pseudo-native.do_populate_sysroot Sep 26 12:45:37 and so do external-foo-toolchain.do_package and do_package_write_ipk Sep 26 12:45:54 possibly this is because i added some additional packages provided by the toolchain (ie, autoconf-native, m4-native, ...) Sep 26 12:46:05 okay, that's to be expected. why does pseudo-native depend on the toolchain? Sep 26 12:46:15 oh, your toolchain providers autoconf-native? Sep 26 12:46:38 that is not a good idea, those auto* recipes require special and delicate handling to get the dependencies right. Sep 26 12:46:47 uhoh Sep 26 12:47:08 well, the goal is to *not* have to rebuild all those essential build tools on every instance Sep 26 12:47:47 you might be able to provide a dedicated autoconf-native-prebuilt kind of recipe if you wanted, but I don't think you can sensibly mix it in with something else since the sequencing will be all screwed up. Sep 26 12:48:07 autoconf-native is needed very early, since virtually everything else requires it to configure Sep 26 12:48:35 you might be able to put autoconf-native and automake-native in one recipe, but I think that's about as far as you can go. Sep 26 12:48:38 autoconf, automake, gnu-config, m4, libtool, ncurses, python, opkg, sqlite3, pkgconfig , opkg (all in their native variants) is what i added to the sdk Sep 26 12:49:10 so apart from autoconf and automake, anything else i shouldn't want to include in the sdk? Sep 26 12:49:38 gmc: the preferred solution to "not building those tools every time" is shared state Sep 26 12:50:24 that sounds scary :) Sep 26 12:51:53 gmc: well, it's basically built in and should work out of the box if you set SSTATE_MIRRORS to point to a pre-populated shared state directory Sep 26 12:52:34 so when i try to compile a kernel module, i have an error beacuse it cannot find bounds.h, the recipe uses sysroots/ARCH/kernel. And this does not contain the bounds.h. So i am trying to modify my kernel recipe so it can copy this file too at the kernel_install. But looking at kernel.bbclass, everything is copied under ${kerneldir}, and that points to work/ARCH/linux/image and not sysroots/ARCH/kernel. What did i miss ? Sep 26 12:53:33 afournier: the sysroot_stage_all_append() in kernel.bbclass Sep 26 12:53:40 afournier: you're using denzil right? Sep 26 12:53:47 There are also 3 lines about copying this file when it exists, but the path is not the same "include/generated/bounds.h" instead of "include/linux/bounds.h" Sep 26 12:53:55 yes Sep 26 12:54:27 and i am using 2.6.32 Sep 26 12:54:32 bluelightning: and what would i accomplish with that? how does it fit in with all the other magic? Sep 26 12:54:49 (pointer to some docco would help as well, 'shared state' in the search box on openembedded.org wiki yields nothing useful) Sep 26 12:55:11 gmc: if the tool compilation and anything that affects it has not changed, it will simply be extracted from the shared state packages instead of being compiled Sep 26 12:55:49 so "sysroot_stage_dir ${D}/kernel ${SYSROOT_DESTDIR}/kernel" is the key, it copies everything (?) that is in work image to the sysroot Sep 26 12:56:00 gmc: http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#shared-state-cache Sep 26 12:56:58 so calling kernel install over and over is useless if i don't call the staging function Sep 26 12:57:11 bluelightning: tnx! Sep 26 12:57:29 oe.. poky.. yocto.. as if oe itself wasn't complicated enough already :)) Sep 26 12:58:40 how can i force the staging of the kernel ? Sep 26 12:58:45 hm, binutils in oe-core trunk seems to be busted, it's setting DT_TEXTREL in my libelf.so for no apparent reason Sep 26 12:58:47 bitbake -c stage ? Sep 26 12:59:05 bitbake -f -c populate_sysroot, I think. something like that anyway. Sep 26 12:59:25 "bitbake -c stage" is about 8 years out of date :-} Sep 26 12:59:54 ok Sep 26 13:00:03 pb_ i was just guessing Sep 26 13:02:30 populate_sysroot did not populate anything Sep 26 13:08:03 afournier: I'm a bit puzzled why the path to bounds.h would be different in your case... Sep 26 13:09:16 because i use 2.6.32 maybe Sep 26 13:10:16 my recipie inherit kernel.bbclass and not kernel-yocto.bbclass, dunno if it's related Sep 26 13:11:51 that's fine Sep 26 13:11:57 i added this to my recipe and it does the job i think, but i am not sure (i did a -c clean and bitbake again, so it's still compiling) Sep 26 13:12:00 http://pastebin.com/HW1YP3rp Sep 26 13:12:35 but i checked the discussions about bounds.h problem Kbuild and Makefile bugs in 2.6.26, and that's not my problem Sep 26 13:12:44 gmc: we're working to remove confusing term usage from our documentation, FWIW Sep 26 13:13:26 afournier: I don't know enough about this header to know what the most correct solution is... if nobody else answers then it would be great if you could ask on the mailing list Sep 26 13:13:43 afournier: ideally we would like kernel.bbclass to handle these kinds of situations properly without the need for workarounds Sep 26 13:14:09 as soon as it works i'll make a mail to the ML Sep 26 13:14:10 and building 2.6.2x / 2.6.3x should still be supported Sep 26 13:14:25 the build is ok :) but the module building is not Sep 26 13:14:59 this header moved many times i think Sep 26 13:25:12 if that's the case, I guess kernel.bbclass should look for it in the alternative location(s) as well Sep 26 13:25:20 i think to Sep 26 13:25:54 i am looking at the 2.6 changes, and there is one message "Update .gitignore to include include/linux/bounds.h" prior to this one "kbuild: move bounds.h to include/generated" Sep 26 13:26:16 so i guess my linux version felt between two oe bugfixes Sep 26 13:49:55 I made my image, but I notice that are add too many packages, where I see and controll packet that going in a image Sep 26 13:50:24 silvio_: since you're setting up your own image they'll be coming in via dependencies Sep 26 13:51:05 silvio_: you can use buildhistory to produce dependency graphs for the image: https://wiki.yoctoproject.org/wiki/Buildhistory Sep 26 13:51:45 thanks Sep 26 14:03:09 there is a simplest way to manage dependecy instead of "depends.dot"? Sep 26 14:04:00 silvio_: what do you mean? Sep 26 14:04:47 I have a nand of 512 Mb, but my image is of 563Mb, so I need remove some packages, like qt-example etc... Sep 26 14:05:15 I need to know dependencies to remove (and how remove them from image) Sep 26 14:05:58 silvio_: so somewhere you are requesting the main qt4-x11-free (or qt4-embedded, whichever you are using) package to be installed - that pulls in everything Sep 26 14:06:10 silvio_: what is your IMAGE_INSTALL? Sep 26 14:06:43 there was a GUI in bitbake to check packages dependencies Sep 26 14:07:15 yes, bitbake -g -u depexp Sep 26 14:07:21 that's it Sep 26 14:07:27 it could help silvio no ? Sep 26 14:07:30 bluelightning, is quite long... I inerith qt4-x11-free, but I can remove for example QT-example or demo? Sep 26 14:07:48 the thing is, a number of situations result in runtime dependencies only being calculated at package time, which means they won't show up in that UI Sep 26 14:07:56 afournier, Is Xdot, but is not intellegible, too big Sep 26 14:09:09 silvio_: the demos and examples get pulled in if you have the package named "qt4-x11-free" in IMAGE_INSTALL or RDEPENDS somewhere; this is because qt4-x11-free is a meta-package that installs everything that Qt builds Sep 26 14:09:38 this is probably not what you want; the simple answer is don't install that package, only install what you need from qt Sep 26 14:09:59 afournier, I visualize "depends.dot" with XDot, but not usefull too complex to mange is funny-absurd :) Sep 26 14:10:05 most of the time since Qt is mostly libraries, all of the required packages will be pulled in as dependencies automatically Sep 26 14:10:25 bluelightning, k, so I need modify original qt4-x11-free meta-package Sep 26 14:10:31 no Sep 26 14:10:37 you need to not depend upon that Sep 26 14:11:16 silvio_: if you have qt4-x11-free in your IMAGE_INSTALL or an RDEPENDS_ (not DEPENDS) line in a recipe somewhere, remove it Sep 26 14:11:47 unless you need something from Qt that is not a library, it will still bring in the necessary packages and everything will be fine :) Sep 26 14:12:05 ouch, ok, I can soubstitute it with the packages that I need? Sep 26 14:12:53 silvio_: which packages do you need? Sep 26 14:14:59 bluelightning, qt4-x11 for gles acceleration, QWT, Qjson Sep 26 14:15:56 silvio_: no, but what in qt? as I said above, if what you need from Qt is just libraries that other things you install are linked to, you don't need to explicitly request anything, they will be brought in automatically Sep 26 14:21:23 bluelightning, ok, I have to check, so instead of "inherit qt4x11" I put needed lybrary in "DEPENDs =" ? Sep 26 14:21:38 bluelightning, ok, I have to check, so instead of "inherit qt4x11" I put needed library in "DEPENDs =" ? Sep 26 14:23:13 silvio_: no, that's not it Sep 26 14:23:31 silvio_: that's a build-time dependency, I am talking about runtime Sep 26 14:23:52 silvio_: can you check the depends.dot to see what depends on qt4-x11-free? Sep 26 14:27:26 http://paste.ubuntu.com/1228543/ Sep 26 14:27:31 bluelightning, http://paste.ubuntu.com/1228543/ Sep 26 14:28:49 silvio_: ah right, you've installed the dev packages - all bets are off Sep 26 14:29:16 it is not really intended that you install dev packages onto a constrained system... Sep 26 14:30:52 bluelightning, it is possible remove from the image? And how? Sep 26 14:31:41 silvio_: what have you set IMAGE_FEATURES to ? Sep 26 14:31:58 to check: bitbake -e | grep ^IMAGE_FEATURES Sep 26 14:32:38 IMAGE_FEATURES="debug-tweaks" Sep 26 14:32:38 IMAGE_FEATURES = debug-tweaks Sep 26 14:32:51 Has anyone got experience with what (I think Python) module provides Helper. I am running into the following compilation failure in XBMC Sep 26 14:33:04 http://pastebin.com/7tf8drYM Sep 26 14:34:12 ok it seems that Helper is provided in the git tree but it is not picking it up Sep 26 14:34:12 https://github.com/xbmc/xbmc/tree/master/tools/codegenerator Sep 26 14:35:14 silvio_: is qdbusnetworkmanager_staticdev in your IMAGE_INSTALL? Sep 26 14:35:48 yes Sep 26 14:36:04 silvio_: do you actually need the .a file on the target? Sep 26 14:36:18 bluelightning, IMAGE_INSTALL += "qdbusnetworkmanager-staticdev qdbusnetworkmanager-example qscpecg qjson qwt qtcardiopad" Sep 26 14:37:26 bluelightning, yes I need, but not in final image Sep 26 14:38:01 silvio_: ok, then remove it from IMAGE_INSTALL Sep 26 14:38:06 kk Sep 26 14:49:25 bluelightning: do you remember why b82c216c1ee8e2a009e87856b7adad08f7f50482 adds -pulseaudio switch, but then adds --enable-pulseaudio and --disable-pulseaudio? Sep 26 14:51:12 JaMa: IIRC the qt configure script is flexible, it converts various with/without/disable/enable to the appropriate option if such an option exists Sep 26 14:51:26 JaMa: pretty sure I tested it at the time Sep 26 14:57:20 bluelightning: ok Sep 26 14:58:22 bluelightning, you my wizard!!! From 563Mb to 155Mb, thanks Sep 26 15:02:27 silvio_: np Sep 26 16:26:32 sigh, gcc-4.7 breaks with -fasynchronous-unwind-tables on mips Sep 26 16:26:35 * pb_ stabs it Sep 26 16:30:32 pb_: out of interest, does that option provide a significant speedup? Sep 26 16:31:30 no speedup, but significantly improved debuggability Sep 26 16:31:41 ah, I see Sep 26 16:31:58 it basically tells the compiler to output unwind tables that you can use to get a backtrace from arbitrary points. Sep 26 16:32:09 without that, debugging an optimised program is a bit of a hit and miss affair Sep 26 17:16:01 Is it possible to disable license checks for a single test recipe (or disable it build-wide if necessary)? Sep 26 17:16:21 This is for poky/bitbake (denzil branch) Sep 26 17:16:32 you could set LICENSE = "CLOSED", that's what i recently discovered Sep 26 17:17:36 That works - a nice little warning about it, but build happily finishes. Thanks! Sep 26 17:38:41 runexe: if it's not actually closed-source and you intend to publish it somewhere, don't forget to change that ;) Sep 26 17:43:02 bluelightning: Right - thanks :) Sep 26 19:00:38 is it possible to build only the dependencies of a recipe using bitbake ? Sep 26 19:03:42 ? Sep 26 19:03:49 bitbake -c configure Sep 26 19:03:53 bitbake -c configure foo Sep 26 19:04:00 should build you the deps Sep 26 19:07:34 ha Sep 26 19:07:41 thanks Sep 26 19:53:42 is meta-oe ever going to drop its copy of kernel.bbclass? Sep 26 20:00:31 dont ask me Sep 26 20:00:57 * kergoth shakes head and sighs Sep 26 20:04:25 ack http://patchwork.openembedded.org/patch/36407/ Sep 26 20:05:49 ah, there it is Sep 26 20:14:12 could we use the linux .gitignore to have a snapshot of the generated files ? Sep 26 21:05:57 what is the preferred place to store your local.conf file? Sep 26 21:06:46 your build directory, next to bblayers.conf. Sep 26 21:09:08 i'm storing it in git, and the build directory is .gitignore'd in oe-core Sep 26 21:17:10 so put your build dir somewhere other than oe-core **** ENDING LOGGING AT Thu Sep 27 02:59:57 2012