**** BEGIN LOGGING AT Wed Sep 18 03:00:00 2013 Sep 18 03:18:56 sgw_: there? Sep 18 03:19:22 I am looking at u-boot build failure you reported (fw-utils) and am curious how it end being built Sep 18 03:23:35 sgw_: is it a world build? Sep 18 03:25:28 pidge_: do you have the build number which got the u-boot-fw-utils failure? Sep 18 03:25:45 the bug is https://bugzilla.yoctoproject.org/show_bug.cgi?id=5223 Sep 18 03:25:46 Bug 5223: major, High, 1.5 M5, anders, NEW , [autobuilder] u-boot-fw-utils does not build correctly Sep 18 03:27:52 Found it Sep 18 03:44:38 sgw_: I sent the u-boot-fw-utils fix Sep 18 03:45:10 zeddii: any clue about the ppc failure? I started a perf build in all my machines to see if any reproduce the issue. Sep 18 06:45:37 Good morning. Sep 18 07:16:21 Morning Sep 18 07:25:07 good morning Sep 18 07:31:37 morning all Sep 18 07:32:56 morning Sep 18 07:34:03 gm folks Sep 18 07:36:58 RP: I'm still struggling with the hardcoded paths to target_sysroot. May I ask you to comment on this by chance? http://tinyurl.com/njpzqre Sep 18 07:45:38 ant_work: we do have a sysroot per machine but that does not mean things installed into the sysroot are machine specific Sep 18 07:46:54 ant_work: the problem is the klcc scripts? Sep 18 07:47:01 yes :/ Sep 18 07:47:49 ant_work: think about how we solve this with the gcc binaries - we pass in --sysroot to them through cflags Sep 18 07:47:59 ant_work: could you pass in a --sysroot option to klcc ? Sep 18 07:49:03 klibc and klcc-cross recipes are built with standard flags Sep 18 07:50:21 and in fact klcc-cross scripts points to the right binaries under /sysroots/i686-linux/usr/bin/armvXXX Sep 18 07:50:31 the problem is the last part of it Sep 18 07:50:57 where it teach the builds where the klibc headers (extra headers plus stuff) are Sep 18 07:51:19 here I get references to the target sysroot Sep 18 07:52:22 see includedir -> http://git.kernel.org/cgit/libs/klibc/klibc.git/tree/klcc/Kbuild Sep 18 07:55:34 the switch is $(INSTALLDIR) Sep 18 08:01:11 RP: I even imagine it is possible to build klibc with headers in tcbootstrap but then the issue would remain: where to copy the headers to be shared by machine of the same arch? Sep 18 08:03:33 ant_work: you point them at the headers in the sysroot. when the sysroot changes, it needs to look in the new sysroot Sep 18 08:03:43 you have to specify this to the compiler Sep 18 08:03:57 just like we do with gcc-cross Sep 18 08:07:23 I'm sorry I can't follow.. all I can do is mangle oe_runmake 'INSTALLDIR=${STAGING_DIR_TARGET}${target_libdir}/klibc' klcc Sep 18 08:07:47 klcc i's not a binary Sep 18 08:25:21 RP: I could manage so that the klibc recipe builds but I doubt it is in it's best shape ;) I'd appreciate vey much if one of you TC masters could 'visit' the puppy Sep 18 08:27:53 Hi all! I have the following problem: I am not able to create a working ISO file using Poky 9.0.2. The boot process hangs with: "Waiting for removable media…" Who could point me in the right direction to fix this? Sep 18 08:28:54 spice: that generally means udev is waiting for the right mount to appear Sep 18 08:29:08 spice: have you been experimenting with systemd? Sep 18 08:32:29 not yet, I just tried to build core-image-base with default settings, except IMAGE_FSTYPES += "live" Sep 18 08:32:29 to get the iso file. Sep 18 08:34:49 I found this article via google, that says this was fixed in 4.0.1 ... https://lists.yoctoproject.org/pipermail/poky/2011-February/003583.html Sep 18 08:38:26 hm the embedded initramfs should definitely have the mount rules Sep 18 08:39:42 spice: you can check, go to tmp/work/[your machine]/core-image-minimal-initramfs/1.0-r0/rootfs Sep 18 08:39:50 spice: there should be etc/udev/rules.d/automount.rules Sep 18 08:40:21 question: is the initramfs built? Sep 18 08:44:07 hmm, I wonder how the unpack task can fail when I can unpack the tar.xz fine manually? Sep 18 08:46:09 ant_work: ok, how about you just create a machine specific part which takes a stored script and sets the sysroot correctly for that machine? Sep 18 08:47:33 ant_work: Right now I simply don't have the time, we should talk about it after the release Sep 18 08:54:33 RP: I'll see about removing its sstate for now, if it is recreated for each machine all is just fine. For long term I'll surely poke you, thx Sep 18 08:59:35 file -> foo.tar.xz: POSIX tar archive Sep 18 08:59:42 why is yocto struggling with it? Sep 18 08:59:48 (to unpack) Sep 18 08:59:54 lpapp: without seeing the unpack log its hard to say Sep 18 09:00:19 foo.tar.xz | tar x --no-same-owner -f - failed with return value 2 Sep 18 09:00:25 lpapp: right Sep 18 09:00:27 that's it Sep 18 09:00:29 manually running tar, it works fine. Sep 18 09:00:32 your filename is tar.xz Sep 18 09:00:34 but its not Sep 18 09:00:36 its a .tar Sep 18 09:00:43 I do not follow. Sep 18 09:00:46 its not compressed Sep 18 09:00:48 tar xvpf foo.tar.xz works just fine. Sep 18 09:01:01 so yocto should uncompress it without any issues, too. Sep 18 09:01:50 .xz means "this file has been compressed with xz" Sep 18 09:02:00 at no point in your tar command do you specify uncompressing Sep 18 09:02:09 bitbake is seeing .tar.xz, and attempting to uncompress Sep 18 09:02:10 not sure what you mean. Sep 18 09:02:16 yocto should run tar xvpf Sep 18 09:02:18 and that should work. Sep 18 09:02:39 git archive --prefix=foo-0.1/ -o foo.tar.xz HEAD -> moreover, I do not see how this could generate non xz. Sep 18 09:02:47 it used to work in the path... I wonder what channged... o_O Sep 18 09:02:49 because you didn't compress it Sep 18 09:02:54 that writes a .tar Sep 18 09:03:20 git-archive writes a tarball Sep 18 09:03:24 it does not also compress it Sep 18 09:04:38 I am not sure I follow Sep 18 09:04:43 I used the same the command as before. Sep 18 09:04:52 and it worked fine with yocto as well without bothering. Sep 18 09:05:06 you must have done something different Sep 18 09:05:13 git-archive produces an uncompressed tarball Sep 18 09:05:17 but you're calling it .tar.xz Sep 18 09:05:29 which bitbake understandably considers to be a xz-compressed tarball Sep 18 09:05:33 so tries to uncompress it Sep 18 09:05:35 and fails Sep 18 09:05:40 because its not compressed Sep 18 09:06:01 nope Sep 18 09:06:05 as git-archive --help shows, pipe git-archive through xz or gzip or bzip2 Sep 18 09:06:11 git archive is supposed to provide a compressed tarball, name 'xz' format. Sep 18 09:06:17 namely* Sep 18 09:06:41 but even if git archive fails, Yocto should not. Sep 18 09:06:47 not sure why git archive fails though. Sep 18 09:12:04 rburton: seems git cannot produce xz at all... that is a weird surprise. Sep 18 09:12:16 as i said, git archive doesn't compress Sep 18 09:12:17 anyway, it worked before with exactly the same command before copying the file to the yocto tree. Sep 18 09:12:21 so how did it work before? Sep 18 09:12:29 you did something differently Sep 18 09:12:31 nope Sep 18 09:12:36 I did exactly the same. Sep 18 09:12:56 anywya, does it matter? just pipe git-archive through xz and you'll be sorted Sep 18 09:13:34 Hi, How quick question ... How to replace this in bitbake recipe for yocto? Sep 18 09:13:35 fakeroot do_install() { Sep 18 09:13:35 well, it matters. Sep 18 09:13:38 it used to work.... Sep 18 09:13:43 I would understand why it does not work anymore.... Sep 18 09:17:21 rburton: i will have a look Sep 18 09:22:39 hi how to replace fakeroot do_install() { in yocto. It doesnt find recipe for fakeroot-native Sep 18 09:22:41 ??? Sep 18 09:22:48 rburton: I see two non commented lines in automount.rules: Sep 18 09:22:52 SUBSYSTEM=="block", ACTION=="add" RUN+="/etc/udev/scripts/mount.sh" Sep 18 09:22:58 SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh" Sep 18 09:23:18 spice: so in that case, maybe your initramfs kernel doesn't know how to mount your media or access your device Sep 18 09:23:29 hm... Sep 18 09:24:12 If I have files that should be part of the final image loaded on the hw, which isn't part of the kernel nor rootfs. How should such files be handled? Sep 18 09:24:38 rburton: spice: is the kernel really embedding the initramfs? Sep 18 09:24:47 Added to the rootfs and removed using a image postprocess command and put into it's correct container? Sep 18 09:25:06 ant_work: how do I verify that? Sep 18 09:26:34 well, check the size or the presence of the cpio.(gz:lzma) in kernel workdir under linux/usr Sep 18 09:26:36 rburton: think I found the root cause. Sep 18 09:26:42 I had the tar.xz git setting in my config Sep 18 09:26:52 not this time. Sep 18 09:27:18 ant_work: rburton: when i open the ISO file with 7-zip i see the file "initrd" and there is also an according APPEND line in isolinux.cfg Sep 18 09:27:40 ah, ok, then it is not embedded Sep 18 09:28:18 I have right now issues with the old way of embedding initramfs, settting INITRAMFS_IMAGE Sep 18 09:29:01 I thougth you're maybe impacted but I see those image uses plain old initrd Sep 18 09:29:11 rburton: file format still not recognized for unpacking... what the ... hack ? :) Sep 18 09:29:12 Guest31240: fakeroot-native should be provided by pseudo-native Sep 18 09:30:20 lpapp: run file on the tarball, check it matches the filename Sep 18 09:31:41 Guest31240: to be precise, virtual/fakeroot-native should be provided by pseudo-native Sep 18 09:32:15 Guest31240: do_install is already marked fakeroot btw, so that shouldn't be necessary in the recipe anyway Sep 18 09:40:58 I enabled 'argp' in my DISTRO_FEATURES for uclibc image, now trying to build opencv: /dev/shm/kmsywula/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux-uclibc/gcc/i586-poky-linux-uclibc/4.7.2/ld: cannot find -largp | collect2: error: ld returned 1 exit status Sep 18 09:41:04 any idea? Sep 18 09:42:13 the error comes from v4l2apps/v4l-utils_0.8.8 Sep 18 09:47:52 rburton: thanks. Sep 18 09:48:28 thx bluelightning Sep 18 09:53:21 ant_work: rburton: Any ideas what I can do to debug my non working LiveCD? Sep 18 09:58:17 rburton: ant_work: Another idea: Is there a possibility to build an initrd only LiveCD? Sep 18 10:00:45 hmm, what is the reason of having ./tmp/deploy/rpm/i586/ but not ./tmp/deploy/rpm/arm ? Sep 18 10:00:53 where can I find the rpm packages for my arm board? Sep 18 10:01:55 lpapp: if there's not there, then maybe you removed package_rpm from your PACKAGE_CLASSES Sep 18 10:02:44 rburton: hmm, yeah, it was changed to package_ipk Sep 18 10:02:48 not that I see opkg packages? Sep 18 10:03:14 the directory will be ipkg Sep 18 10:03:22 I do not have such a folder. Sep 18 10:03:55 sorry, ipk. Sep 18 10:04:03 $ ls /data/poky-master/tmp/deploy/ Sep 18 10:04:05 images ipk licenses sdk Sep 18 10:04:07 ^ mine Sep 18 10:04:52 strange. Sep 18 10:06:01 ok, now I have it after rebuild, thanks. Sep 18 10:06:11 is there a --prefix option with ipkg if I wanna install my package into /opt/foo ? Sep 18 10:06:21 or if I wanna have such a thing, I need to use rpm? Sep 18 10:06:59 lpapp: why not build your package so that it installs into /opt/foo directly Sep 18 10:07:46 rburton: because others may want to install it usually. Sep 18 10:08:24 not sure if ipk has that option Sep 18 10:08:34 it does kinda break any hard-coded paths in the files Sep 18 10:09:04 rpm has --prefix at least. Sep 18 10:10:32 sure. but any hard-coded paths will be incorrect. Sep 18 10:10:38 install -d ${D}${bindir} and install -m 0755 ${WORKDIR}/foo-0.1/foo/foo ${D}${bindir}/ Sep 18 10:10:45 I have this, yet my rpm packages are empty. :( Sep 18 10:10:52 Shouldn't at least my "foo" binary inside? Sep 18 10:11:00 did you set FILES_${PN}? Sep 18 10:11:04 we do not use hard coded paths in our software. Sep 18 10:11:07 nope Sep 18 10:11:19 but I think install should be fine to the generic locations. Sep 18 10:11:28 as the default class content takes care of the usual paths. Sep 18 10:11:57 then yes, the default should have caught that. in the work directory for that package you'll image, package, packages-split Sep 18 10:12:01 see if anything is in those Sep 18 10:12:28 (that's the order that stuff moves, do_install moves to image, then a link farm is made to package, which is then split into packages-split) Sep 18 10:15:43 rburton: yes, it is in that folder. Sep 18 10:15:49 I used rpm -l to list the content. Sep 18 10:15:58 hope that is the right command to check if there is anything inside. Sep 18 10:17:10 rpm -qpl, isn't it? Sep 18 10:17:34 ah, ok. Sep 18 10:17:36 my mistake then. :-) Sep 18 10:17:41 I thought -l would be fine. Sep 18 10:17:43 rburton: ant:work: I see another interesting thing on my LiveCD: According to the script "/rootfs/init" I should get dropped to a shell after 30 seconds, but this does not happen. What do I have to do to get manual changes to the rootfs on my ISO file to debug this? Sep 18 10:17:43 the list the content. Sep 18 10:18:42 rburton: what is the best practice for creating a bundled package? Sep 18 10:18:52 i.e. putting the openssl, etc libraries into the package. Sep 18 10:19:03 is it possible without putting those into the archive? Sep 18 10:28:50 rburton: hmm, the distributed rpm by core-image-minimal does not have the --prefix option. :( Sep 18 10:29:17 it seems to be coming from busybox? rpm Sep 18 10:29:17 BusyBox v1.20.2 (2012-11-16 01:53:09 GMT) multi-call binary. Sep 18 10:29:51 strange, my desktop busybox does not contain rpm... what is the origin of this then? Sep 18 10:32:36 yep, it is busybox. Sep 18 10:32:46 although it is a chopped variant (not supporting prefix :( Sep 18 10:32:47 ) Sep 18 10:33:46 our defconfig disables that, so presumably that's your busybox Sep 18 10:34:35 oh, packages-split seems to be already stripped. Sep 18 10:45:40 is it okay with Yocto if I want to have a daemon running automatically on boot with core-image-minimal, I just add my own init.d script in etc? Sep 18 11:09:39 lpapp: I don't think it makes much difference to Yocto if you do that :) Sep 18 11:09:55 lpapp: it sounds reasonable Sep 18 11:10:41 rburton: Hi, just a short status update: So far I did not get the *.iso working in QEMU, but when I write the *.hddimg to an USB thumb drive it successfully boots on real hardware! Sep 18 11:10:44 RP: OK, thanks. Sep 18 12:05:14 I created recipe with SRC_URI += 'my.patch' and now fetcher cannot find that file. What was the trick to let know fetcher where the file is? I added it to files/ subdirectory of my bbappend recipe. Sep 18 12:07:24 Krz_: is this a recipe or a bbappend? Sep 18 12:07:31 bluelightning: bbappend Sep 18 12:07:41 Krz_: did you also extend FILESEXTRAPATHS in the bbappend? Sep 18 12:07:59 bluelightning: no, I just added SRC_URI line Sep 18 12:08:06 bluelightning: pointing to my patch Sep 18 12:09:04 Krz_: right, you need to do FILESEXTRAPATHS_prepend := "${THISDIR}/files:" Sep 18 12:11:07 bluelightning: works like a charm, thanks Sep 18 12:12:05 Krz_: np Sep 18 13:05:33 rburton: hi ! I succeeded in building gstreamer1.0 plugins ! hiwever the pipe failed : it seems that a gbm_gallium_drm.so file is needed (linked to mesalib or ligbm1) and I pull one's hair out to find how to have this file, so if yoou have time or any idea let me know ! Sep 18 13:07:58 elbc: mesa probably built it, have a look at packages in your deploy with mesa in their name Sep 18 13:09:16 i have done a find . -name gbm_gallium_drm.so Sep 18 13:09:19 and nothing Sep 18 13:10:18 the package ligbm1 is present and installed on the image but is not providing the /usr/lib/gbm_gallium_drm.so Sep 18 13:10:28 libgbm1 Sep 18 13:12:10 there might be a mesa-driver-gallium-something Sep 18 13:12:19 by default we don't build gallium though Sep 18 13:14:17 rburton: ok thanks but how to build without gallium and to make gstreamer1.0 working under wayland ? Sep 18 13:15:05 elbc: no idea, sorry. Sep 18 13:15:09 haven't tried that yet Sep 18 13:15:20 ok thank you anyway ! Sep 18 13:56:12 sgw_1: perf fix for ppc sent Sep 18 14:12:59 I have a recipe for opencv (meta-oe) which depends on GTK+. I want to build it without GTK+ support. Can I create a bbappend + patch on top of original recipe to remove GTK+ dependency? Sep 18 14:13:55 it would be best to send patch to meta-oe converting gtk+ dependency to PACKAGECONFIG Sep 18 14:14:16 then you can have only very small .bbappend or just line in config disabling gtk+ dependency for your build Sep 18 14:15:10 hello, I want to bitbake core-image-web-kiosk for my imx53qsb Sep 18 14:15:14 this works Sep 18 14:15:22 JaMa: can you give me some pointers on how to do that? I don't have much experience with PACKAGECONFIG Sep 18 14:15:32 but I also want to add gstreamer1.0 with all plugins Sep 18 14:16:35 I do this by passing IMAGE_INSTALL_append = " gstreamer1.0 gstreamer1.0-plugins-base etc..." to my local.conf Sep 18 14:16:52 I think they are getting build, but I don't see all plugins in my rootfs Sep 18 14:17:02 I only have the libav and omx plugins available Sep 18 14:17:45 even the gstreamer0.10 which is apparantly build standard with this bitbake doesn't provide these plugins Sep 18 14:19:58 wv: the plugins are packaged in a very granular fashion, gstreamer1.0-plugins-base will only install the 'base' plugins Sep 18 14:21:16 yes, I know, with the thing that I don't see them via gst-inspect1.0 Sep 18 14:21:33 even when I should have added them via IMAGE_INSTALL_append Sep 18 14:23:15 JaMa: PACKAGECONFIG does not support 'EXTRA_OECMAKE' and I need to remove '-DWITH_GTK=ON' from that variable... Sep 18 14:24:13 Krz_: PACKAGECONFIG will add to EXTRA_OECMAKE if the recipe inherits cmake Sep 18 14:25:10 bluelightning_: in documentation PACKAGECONFIG is described as: EXTRA_OECONF, EXTRA_OECONF, DEPENDS, RDEPENDS Sep 18 14:25:36 bluelightning_: if recipe inherits cmake where do I put my EXTRA_OECMAKE ? Sep 18 14:28:36 Krz_: it happens automatically Sep 18 14:29:01 Krz_: the documentation is perhaps deficient in not mentioning that it'll add to EXTRA_OECMAKE automatically if the recipe inherits cmake Sep 18 14:29:11 (instead of EXTRA_OECONF, that is) Sep 18 14:32:12 Krz_: grep for PACKAGECONFIG in meta-oe, there are some examples from me also using EXTRA_OECMAKE (but it looks the same as in recipe with autotools and EXTRA_OECONF) Sep 18 14:42:49 Is it possible that I have somewhere a filter which prevents me in adding these gstreamer1.0-plugins-base, good etc? Sep 18 14:43:00 (rather new to yocto) Sep 18 14:56:53 Have anyone got any yocto's tutorial, I am actually reading the mega-manual and it is difficult to understand without trying. Example : for a custom image, should I write my own recipe or just write my options in the conf/local.conf file? Sep 18 14:59:13 TuTizz I don't have one, but I can help you.. Sep 18 14:59:34 if you are just screwing around, doing it in the conf/local.conf is easier... but if you are making a product, it's much better to write a custom image recipe.. Sep 18 14:59:38 MUCH easier to share and maintain Sep 18 15:01:09 yes this is it, I creating a new product. Sep 18 15:02:12 so I should create a new recipe, for example I want qt4e and openssh Sep 18 15:02:43 you can 'require' an existing image recipe, and then start modifying from that.. or copying it and make changes, etc.. Sep 18 15:03:09 it should be as simple as adding the packages (not recipes) that you want installed to the IMAGE_INSTALL (think that is right) variable Sep 18 15:03:46 ok, a good start should be extend core-image-minimal Sep 18 15:03:48 ? Sep 18 15:03:52 @TuTizz: for openssh, you'll want to add ssh-server-openssh to your IMAGE_FEATURES ... that will cause it to be picked up Sep 18 15:04:20 if you are trying for a small image,t hen yes that is a perfect starting point.. Sep 18 15:04:37 core-image-basic (or is it core-image-core) is a good point if you want discrete (not busybox) command line apps Sep 18 15:04:48 core-image-basic Sep 18 15:04:52 always try to build from small UP to what you want.. Sep 18 15:04:57 if you want more than busybox :) Sep 18 15:05:09 it's much more difficult to start with something too big and build "down" Sep 18 15:05:39 ok Sep 18 15:05:57 bluelightning: JaMa: my point is what's the syntax for PACKAGECONFIG in recipe inheriting cmake Sep 18 15:06:12 the other thing to keep in mind, unless you know -exactly- what you need in your image.. a good place to start is the various 'packagegroup' recipes.. the purpose of those is to implement specific sets of functionality Sep 18 15:06:26 qt4e-demo-image run on my imx6, (I don't want the demo so I kill it then start my own application) Sep 18 15:06:37 ok lets talk about packagegroup Sep 18 15:07:16 bluelightning: JaMa: I presume it's PACKAGECONFIG[xyz] = "EXTRA_OECMAKE, EXTRAOECMAKE, DEPENDS, RDEPENS", am I right? Sep 18 15:07:53 packagegroup-core-boot -- things required to 'boot' a typical system Sep 18 15:07:58 if I want qt4e without the demo, I can extend core-image-basic with qt4-embedded_4.8.5.bb Sep 18 15:08:42 .. what you can do is: Sep 18 15:08:45 create a new recipe Sep 18 15:08:59 require core-image-basic.bb Sep 18 15:09:08 IMAGE_INSTALL += "qt4-embedded" Sep 18 15:09:28 there is a packagegroupe though.. packagegroup-core-qt and packagegroup-core-qt4e Sep 18 15:09:38 Krz_: yes that's correct for recipes that inherit cmake Sep 18 15:09:39 that would add additional things usually needed for qt/qte Sep 18 15:09:48 bluelightning: great, thanks Sep 18 15:10:26 then bitbake myRecipe Sep 18 15:11:17 ? Sep 18 15:17:10 Another information, where should I put my new recipe? In meta directory? In meta-imx6? Sep 18 15:20:37 ys.. Sep 18 15:20:39 yes Sep 18 15:20:55 best practice is to create a new customer layer for your recipes.. Sep 18 15:20:57 then place them in there.. Sep 18 15:21:10 basically create a new directory.. 'meta-local' for instance.. Sep 18 15:21:19 then inside of there you need a conf/layer.conf Sep 18 15:22:02 look at meta-yocto/conf/layer.conf as an example.. Sep 18 15:22:26 copy that file, and then replace 'yocto' with 'local' Sep 18 15:22:47 (remove the LAYERVERSION_yocto = "2" it's not needed for your local layer) Sep 18 15:22:52 (or set it to '1') Sep 18 15:23:21 then as you create recipes.. just place them under 'recipes-//.bb Sep 18 15:25:50 TuTizz: I would also suggest reading through the Yocto Project Development manual ... take a look at section 5.1 Understanding and Creating Layers ... there's a lot to digest there, but it covers basically everything you need to develop your own custom layer for your recipes. Sep 18 15:26:07 yup.. the stuff I am telling you should all be covered.. Sep 18 15:26:22 but get in the habit of saving your work to recipes and in you own 'layer' right away.. Sep 18 15:26:36 it will pay off in the long run with code you can share with others, and an easier way to manage things in an SCM.. Sep 18 15:26:47 just to be sure that I'm not overlooking something, INCOMPATIBLE_LICENSE is global setting for whole distro, right? i.e. it cannot be different for normal-image and devel-image Sep 18 15:26:49 (you just need to store your layer and perhaps configuration files in the SCM, instead of your whole project) Sep 18 15:27:10 JaMa, it's global.. but you can use the overrides to play some games.. as well as the whitelisting Sep 18 15:29:03 true, but I cannot use e.g. image-name as _pn override, so the global flag isn't very useful for my use-case Sep 18 15:29:52 for example I cannot exclude binutils from normal image by INCOMPATIBLE_LICENSE_pn-normal-image while keeping it included in devel-image (pulled by the same packagegroup) Sep 18 15:30:18 TuTizz: fray: just to throw it out there, as it has been a big help to me the past few days, a good example of customizing Yocto/Poky to your needs is: github.com/Guacamayo/meta-guacamayo/ ... I really like how they set up their project, and it gives example of custom layers, customized recipes, and a customized distro. Sep 18 15:30:19 ya, can't do that Sep 18 15:30:54 you can do it based on global flags for debug and such Sep 18 15:31:06 ok thank you very much wmcdevel and fray, I am more confident now, I will try it. (and re-read the section 5.1) Sep 18 15:31:37 TuTizz: you're most welcome Sep 18 15:32:27 no problem.. Sep 18 15:33:24 JaMa, you can do stuff like look for 'DEBUG_BUILD' = 1 Sep 18 15:33:36 vs a FULL_OPTIMIZATION build that kind of thing Sep 18 15:36:34 huh Sep 18 15:36:57 are you saying that I can build devel-image with DEBUG_BUILD = 1 and normal-image with DEBUG_BUILD = 0? I don't think so Sep 18 15:37:26 you can.. it'll rebuild Sep 18 15:37:33 rburton: I have configured the mesa.bb to build with gallium but I've got the following error : EGL/eglplatform.h: No sych file or directory (I've seen you already know the problem) Sep 18 15:37:37 the FULL and DEBUG optimizations are differnt Sep 18 15:37:38 that's exactly what I don't want :) Sep 18 15:37:44 ok Sep 18 15:38:11 I can use uninstall feature in worst case to maintain list of incompatible packages and remove them after image is built Sep 18 15:39:24 or just carefully keep dependency trees for images separate so that any incompatible package won't leak into normal image Sep 18 15:39:44 yes Sep 18 15:40:00 you can also use the new PACKAGE_EXCLUDE functionality to prevent packages from being installed Sep 18 15:40:26 set PACKAGE_EXCLUDE = "..." in the production image that you -never- want installed on the target and it'll prevent them from 'leaking in' due to dependencies Sep 18 15:40:32 guh, BUILD_CFLAGS is exported, so ends up in the task deps of *target* recipes Sep 18 15:41:01 thats because of apps building local 'helpers' and such.. Sep 18 15:41:06 but it might make sense to avoid that.. Sep 18 15:41:26 yeah, but the output doesn't change, thats internal build use Sep 18 15:41:50 so while it's technically used, it might not be best to include it in the signature.. hmm Sep 18 15:41:55 it could affect the packaging or sysroot.. but I'm not sure if thats a real concern.. Sep 18 15:43:11 at this point we can't share target sstates across different build hosts anymore, since we had to explicitly add -march= to our builds, as we're building on centos5 with a 4.5 native toolchain Sep 18 15:43:15 heh Sep 18 15:43:28 (I'm thinking of the few recipes that build a local helper and install it into the cross sysroot.. but I'm wondering if those are all scripts and no executables) Sep 18 15:43:32 in fact I'm pretty sure that is the case Sep 18 15:44:01 the -march= is only needed on the -really- old compiler(s) Sep 18 15:45:22 centos 5 uses a really old compiler, at least according to poky's sanity.bbclass checks :) Sep 18 15:46:25 * kergoth looks into some sort of workaround until we can pursue a longer temr fix Sep 18 15:46:26 I thought latest centos 5 worked.. maybe not Sep 18 15:46:59 you can always use the ${HOST_MARCH} -- exclude HOST_MARCH, set HOST_MARCH = '-march=' when necessary Sep 18 15:47:06 we've had to work around a number of problems over time, even when using the buildtools tarball Sep 18 15:47:14 good point, that'd work as a workaround, thanks Sep 18 15:47:18 didn't think about that Sep 18 15:47:29 if you do that, I'd like to see the patch.. we may have to do the same.. :) Sep 18 15:48:48 Hi all. How to remove package source with bitbake? Sep 18 15:49:03 I have the bbappend which is not applied by Yocto on original recipe. Does the order of layers in bblayers.conf matter? Or maybe these magic numbers in layer.conf: BBFILE_PRIORITY ? Sep 18 15:49:22 order int he bblayers.conf does matter.. Sep 18 15:49:40 Krz_: bbappends are applied in priority order, but always after the recipe Sep 18 15:49:44 so does the file priority.. but I believe the file priority only matters if you have two files of identical names.. (.conf, .bb... NOT .bbappend) Sep 18 15:49:54 Is there a command to bitbake to remove package source from download directory? Sep 18 15:50:01 ahh so it does also affect application order of bbappends Sep 18 15:50:39 see #oe.. bitbake -c cleanall Sep 18 15:50:46 rburton: if you have any solution don't hesitate to tell me about. thank you again Sep 18 15:50:48 does clean, cleansstate as well Sep 18 15:50:49 fray: it didn't way back when bbappends were first introduced, but it was changed to do it quite a while ago Sep 18 15:50:57 ok Sep 18 15:51:05 does layer order matter still? Sep 18 15:51:12 I thought it did affect something Sep 18 15:52:18 layer order in bblayers affects bbpath, which affects .conf/.bbclass priority Sep 18 15:52:25 fray: the layer order will affect how BBPATH gets constructed; but that's only about how conf/classes are found Sep 18 15:52:32 gotcha.. so I had it backwards.. Sep 18 15:52:49 layer order is the .conf/.bbclass and other 'files', while priority is recipe and bbappend Sep 18 15:56:49 is there a way to force a bitbke to show messages of used commands during the fetch? I tried with -v, but I can not see much. Sep 18 15:57:46 drasko: looking at the log file? Sep 18 15:58:12 or the 'run' script Sep 18 15:58:24 ndec: no way for this to be printed on console during the execution? Sep 18 16:01:38 drasko: there -d for debug level. but i dont use it too much Sep 18 16:01:53 ndec: I am looking at the log... Sep 18 16:05:33 but I was mostly thinking about on-the-go information in the shell. For example, I am fetching the source and I'd like to see percentage of progress... Sep 18 16:05:48 And observe if download is stuck Sep 18 16:05:54 kergoth FYI, we're adding the -march via a BUILD_CFLAGS_append.. and for some reason it doesn't appear to be changing the checksum Sep 18 16:06:59 litterally if we detect a broken host.. we add the following to the local.conf -- BUILD_CFLAGS_append = " -march=" Sep 18 16:07:14 drasko: about percentage of download, no i don't think this is possible. you can probably get to see the command, though if you print all commands your console will go crazy... but that's all you can do. Sep 18 16:07:57 we've wondered in the past as well about that.. but we end up shipping to our customers already downloaded sources.. so it turns out to not really be an issue Sep 18 16:11:46 huh, interesting. i just did a diffsig between two target sstates from our 32 bit and 64 bit automated builds and saw BUILD_CFLAGS change Sep 18 16:11:50 * kergoth shrugs Sep 18 16:12:13 I've got someone running a comparison for us.. Sep 18 16:12:21 he was doing CentOS 5 and Ubuntu 12.04 Sep 18 16:12:55 possible the _append misses the checksum for some odd rason Sep 18 16:13:02 er.. reason Sep 18 16:20:24 join #xenomai Sep 18 16:21:16 we're pulling in https://github.com/MentorEmbedded/meta-mentor/blob/master/classes/add_build_arch.bbclass at the moment. not pretty, but gets the job done for us for now Sep 18 16:26:44 http://pastebin.com/t6HsyGPB Sep 18 16:27:09 Anybody has idea why Yocto breaks EXTRA_OECONF += "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\" Sep 18 16:27:30 in this way, adding ' between the words? Sep 18 16:27:39 This confuses ./configure tool Sep 18 16:27:41 kergoth ya, what we have is an external script (that writes the local.conf).. Sep 18 16:28:00 it runs three checks.. does gcc work w/o -march=.. if not, does gcc -march=native work?, if not does -march= work? Sep 18 16:28:22 hen sets the BUILD_CFLAGS_append = " -march=" based on the results of the last two tests.. Sep 18 16:28:27 (if neither work, an error is generated) ;) Sep 18 16:29:22 fray, no I explicitly added this Sep 18 16:29:30 EXTRA_OECONF += "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\" Sep 18 16:29:35 in the .bb file Sep 18 16:29:39 drasko sorry was talking about kergoths issue Sep 18 16:30:27 for the CFLAGS thing.. w/o the \" (inline quotes) the CFLAGS could get seperated into multiple "arguments" causing the shell to blow up Sep 18 16:32:12 but it has \" Sep 18 16:32:30 The whole line is : "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\" --build=x86_64-linux-gnu --host=arm-linux-gnueabihf" Sep 18 16:32:55 as needed here : http://www.xenomai.org/documentation/xenomai-2.6/html/README.INSTALL/ Sep 18 16:33:04 chapter 3.4. Building for ARM Sep 18 16:33:48 when it gets interpreted by the shell it comes out as: Sep 18 16:34:15 ...configure CFLAGS="-march=armv7-a -mfpu=vfp3\" LDFLAGS="-march=armv7-a -mfpu=vfp3" --build=x86_64-linux-gnu --host=arm-linux-gnueabihf Sep 18 16:34:46 that is trying to pass specific CFLAG and LDFLAG vlaues into configure.. Sep 18 16:34:49 nothing more Sep 18 16:35:25 but why? Sep 18 16:35:35 line seems correct Sep 18 16:36:01 most likely to avoid configure from setting it's own (incorrect) CFLAGS and LDFLAGS.. but I don't know why for that specific app Sep 18 16:36:20 "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\" --build=x86_64-linux-gnu --host=arm-linux-gnueabihf" Sep 18 16:36:28 so, this line normally is correct? Sep 18 16:36:46 it's not incorrect.. if it does the right thing or not, I don't know for that app Sep 18 16:37:00 for the app it works Sep 18 16:37:05 I can compile by hand Sep 18 16:37:27 however, bitbake separates "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\"" Sep 18 16:37:32 into separate words Sep 18 16:37:41 I can only guess because configure was implemented "poorly" for cross compiling Sep 18 16:37:51 hmmm Sep 18 16:38:00 that was an errant message.. sorry Sep 18 16:38:24 bitbake SHOULD pass the values of EXTRA_OECONF -directly- to the shell.. Sep 18 16:38:29 and the shell or configure may decided to expand it Sep 18 16:38:49 adding these CFLAGS and LDFLAGS to configure - it is needed for build Sep 18 16:38:52 you can see what is passed by looking at the tmp/work////temp/run.do_configure. so, can I pass these values to bitbke for build? Sep 18 16:39:07 maybe that will do the trick? Sep 18 16:40:05 the 'do_configure' task, calls into one of the many do_configure implementations.. assuming autotools is enabled.. it should eventually run configure w/ standard options and then ${EXTRA_OECONF} simply passed in.. Sep 18 16:40:12 the only way to see for sure is to look at the runfile Sep 18 16:43:44 here: http://pastebin.com/t6HsyGPB Sep 18 16:44:03 on the line 18 looks like bitbake passes wrong parameters to configure after all Sep 18 16:44:56 values look fine, prior to the actual call into configure Sep 18 16:45:02 then something (shell?) is breaking it up Sep 18 16:45:17 sorry, I'm not sure why.. Sep 18 16:45:48 from my point of view first call to the shell is on line 18 Sep 18 16:45:57 first call to configure Sep 18 16:46:12 before that bitbake was echoing what it will do Sep 18 16:46:21 and reall call to configure happens on line 8 Sep 18 16:46:25 ya.. and something is wrong there Sep 18 16:46:25 *18 Sep 18 16:46:31 yes Sep 18 16:46:36 prior to that you can see that it's quoted Sep 18 16:46:44 this is echo Sep 18 16:46:54 one possibility is to change the recipe to: Sep 18 16:46:59 and then when configure is actually called Sep 18 16:47:11 it is called wrongly Sep 18 16:47:12 EXTRA_OECONF += 'CFLAGS="...." LDFLAGS="..."' Sep 18 16:47:15 then you can avoid the \ Sep 18 16:47:19 I am trying this right now Sep 18 16:47:23 but... Sep 18 16:47:30 however seems like bitbake bug Sep 18 16:48:10 bitbake doesn't do the parsing.. the shell does Sep 18 16:49:55 which would say that bitbake passes line like this to configure: 'CFLAGS="-march=armv7-a' '-mfpu=vfp3"' Sep 18 16:50:06 and hopes that shell will parse this correctly... Sep 18 16:50:21 no.. Sep 18 16:50:34 it -should- pass CFLAGS="..." to the shell.. Sep 18 16:50:47 but on line 18 we see that it did not Sep 18 16:50:48 the shell should see the " and group until the next quote w/ no shell argument expansion Sep 18 16:50:59 correct.. it didn't do that.. I don't know why Sep 18 16:52:03 bitbake isn't expanding arguments.. it just writes out a run file.. (which is a shell script in this case).. you can view it directly looking at the run.do_configure. file.. Sep 18 16:52:16 it then calls /bin/sh and executes the script Sep 18 16:52:31 moin Sep 18 16:59:59 OK, with single quetes it is advancing a bit Sep 18 17:00:21 however I have a probelm: includedir=/usr/include is automatically passed by bitbake Sep 18 17:00:50 And then configure shouts : configure:2361: error: Using /usr/include as includedir is not supported. Please change your --prefix or specify another --includedir Sep 18 17:02:01 your EXTRA_OECONF should pass then --include=${includedir}/${BPN} (for instance) this is fairly common Sep 18 17:11:26 fray:this worked, thanks Sep 18 17:11:36 can you tell me why, however? Sep 18 17:11:55 differnent programs take different interpretations of what --include= should contain.. Sep 18 17:12:07 generally it's supposed to be the location (on the target fs) of where to install the headers.. Sep 18 17:12:26 and what is ${includedir}/${BPN}? Sep 18 17:12:40 many apps want their users directly in /usr/include, some automatically add a subdirectory themselves.. others (like this one) want the include directory to include a subdir Sep 18 17:12:48 includedir == /usr/include Sep 18 17:12:53 BPN == recipe name Sep 18 17:13:03 so foo_1.0.bb -- ${BPN} = 'foo' Sep 18 17:13:57 thanks a lot! Sep 18 17:14:10 no problem Sep 18 17:18:15 jwessel: any hint about embedding initramfs 'old-style'? Sep 18 17:18:51 jwessel: I can't even get the 'new-style' working :/ Sep 18 17:18:56 What is "the old style" ? Sep 18 17:19:04 embed on first pass Sep 18 17:19:35 Perhaps you can send me your local.conf Sep 18 17:19:35 I simply cannot trigger the bundle_initramfs task Sep 18 17:19:47 and build target and can fix it. Sep 18 17:19:50 is standard Sep 18 17:20:00 I'll try on qemuarm to ease up debugging Sep 18 17:20:31 note: is oe-core default, not Poky ! Sep 18 17:21:06 ok, I have an oe-core and several builds, but none error out, I imagine you set something or another in the local.conf to see the problem? Sep 18 17:21:15 not really Sep 18 17:21:36 I have tried to inject the cpio in our linux-yocto Sep 18 17:21:54 just adding the INITRAMFS variables Sep 18 17:22:07 and trying to embed core-image-minimal Sep 18 17:22:35 well, I did build core-image-base and the core-image-minimal wasn't even built Sep 18 17:22:50 ant_work: is the cpio something created as part of your build or a static file that you are adding? Sep 18 17:22:51 note we always build th ekernel in our bsp Sep 18 17:23:04 for every image Sep 18 17:24:18 For example, I have in my local.conf: Sep 18 17:24:20 INITRAMFS_IMAGE_BUNDLE = "1" Sep 18 17:24:21 INITRAMFS_IMAGE = "core-image-minimal-initramfs" Sep 18 17:24:40 hm.. I put th plain "core-image-minimal" Sep 18 17:24:43 What happens is that in the final stage the bzIamge gets re-linked to have the initramfs build in. Sep 18 17:25:03 I just do bitbake core-image-minimal in this case. Sep 18 17:25:35 jwessel: I have nothing against the two passes Sep 18 17:25:55 So you want to build core-image-minimal and then wrap it into a single binary? Sep 18 17:26:15 no, usually I embed a very very small cpio Sep 18 17:26:34 I just tried to reproduce what you were aiming for Sep 18 17:26:46 a linux-yocto embeding a big image Sep 18 17:27:12 whithout setting CONFIG_INITRAMFS_SOURCE in my cfg Sep 18 17:27:13 Well if you have a image recipe that creates your "small cpio" you can just specify it. Sep 18 17:27:44 jwessel: somehow only specifying INITRAMFS_TASK triggers the build Sep 18 17:29:07 but the do_bundle_initramfs seems not run so I don't have the copy_initramfs() -> my patch to kernel.bbclass Sep 18 17:29:08 The initramfs task is separate from the bundling. Sep 18 17:29:25 The kernel's do configure depends on the intramfs task. Sep 18 17:29:55 yes, that's the old, proven, way Sep 18 17:30:20 In that case you would need to specify where your image is. Sep 18 17:30:44 What you are asking for is the ability to specify a specific cpio image that got built in a specific location right? Sep 18 17:30:49 no Sep 18 17:31:12 I just want to specify the cpio image without path, like it was Sep 18 17:31:24 it is an image known to bitbake Sep 18 17:31:29 is in BBFILES Sep 18 17:31:49 the point is that it resides in deploy dir Sep 18 17:32:16 so in one way or other you have to copy it in /usr Sep 18 17:32:30 your code: Sep 18 17:32:31 cp ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ${B}/usr/. Sep 18 17:32:57 That is the part I was looking at. Sep 18 17:32:59 but in my tests, this funtion is never called Sep 18 17:33:04 the task is not run Sep 18 17:33:31 The function is only called if you have INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE set. Sep 18 17:33:57 I'd expect too Sep 18 17:34:10 btw the image is Sep 18 17:34:12 http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb Sep 18 17:34:37 no renames, anything Sep 18 17:34:56 but EXTRA_IMAGEDEPENDS = "" Sep 18 17:36:21 jwessel: once at home I'll send you my full setup Sep 18 17:36:26 thx for your time Sep 18 17:36:28 bbl Sep 18 17:59:18 fray: interestingly, trying : "CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3"" works Sep 18 17:59:47 so, Bitbake exports this to the shell CFLAGS="-march=armv7-a -mfpu=vfp3" Sep 18 17:59:57 as seen in run.do_configure Sep 18 18:00:49 However, doing "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\"" Sep 18 18:01:12 Bitbake exports CFLAGS=\"-march=armv7-a -mfpu=vfp3\" Sep 18 18:01:42 Looks like it takes first quote, goes to the last, and takes everything in between literally... Sep 18 18:05:05 hi there Sep 18 18:08:13 quick question for the gurus ... I'm making a BSP for a board, and I have a custom ts.conf and tslib.sh that I want to be used when building for that board. My recipe is in meta-mini6410-bsp/recipes-graphics/tslib/tslib_1.1.bbappend ... should my ts.conf and tslib.sh go in meta-mini6410-bsp/recipes-graphics/tslib/mini6410, where mini6410 == ${MACHINE}? Sep 18 18:11:10 that's one option, yes, if you set FILESEXTRAPATHS_prepend := "${THISDIR}:" Sep 18 18:13:28 wmcdevel: I think you will want it in tslib/tslib/mini6410 and this FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:" take a look at the formfactor recipe for example Sep 18 18:13:34 cool. anything else I would need to override in the bbappend with "_mini6410 at the end? Sep 18 18:14:23 ok ... yeah, don't know why I didn't think of that - that's exactly the setup I'm trying to get. :) Sep 18 18:16:40 that's also how the xorg-xserver is done as well in the same folder ... hard to work in a terminal and not see the rest of the directory structure around you Sep 18 18:37:01 another odd question to throw out there ... is it possible to build more than one cross toolchain? The customized 2.6 kernel I have for this board will build and boot just fine if I use the 4.5.x version of gcc, but when I use the 4.7.2 that gets built by bitbake, it compiles but will not boot. Sep 18 18:38:21 at the moment, I'm simply building it separately and providing it as a binary. not a big deal, but was hoping to have the entire build done by yocto/oe. Sep 18 21:02:36 Hi there :) Sep 18 21:03:19 When creating a .bbappend file, does it append til previous revisions of .bbappend files, or does the .bbappend with the highest revision append directly to the .bb recipe? Sep 18 21:04:50 kspr, I'm not totally sure, but I think all the bbappends apply in some order. Sep 18 21:05:25 seebs, ok, thanks. Trying to find some docs on this.. not easy :P Sep 18 21:05:31 kspr: what do you mean by "revision of .bbappend"? Sep 18 21:06:07 evanp, I mean, if I have multiple .bbappend files, with the PR incremented.. Sep 18 21:06:31 kspr: I'm pretty sure the .bbappends apply in layer priority order Sep 18 21:06:53 kspr: which has nothing to do with what variables they do or do not contain assignments to, of course Sep 18 21:07:23 Okay, so if I create my own .bbappend for the kernel, it should apply to both existing .bbappends for the same kernel recipe in other layers, and lastly to the recipe itself Sep 18 21:09:56 kspr: my understanding is that, effectively, the .bb and all the .bbappends are concatenated together in layer priority order and parsed as if there were only one file Sep 18 21:10:34 evanp, okay, great. So it is the layer priority that defines the order, and not the PR Sep 18 21:10:51 kspr: not sure if .bbappends in earlier layers affect .bbs in later layers.... Sep 18 21:11:09 evanp, which means that an older PR could override a newer one, if the layer order dictates it. Sep 18 21:11:17 evanp, okay :) Sep 18 21:11:55 kspr: and it _is_ possible I don't have the right mental model of what's happening, but in my own experience it behaves as I described Sep 18 21:12:24 kspr: yes, that's right Sep 18 21:12:39 evanp, right, okay :) Sep 18 22:03:37 Hmm, I have a problem configuring my kernel. Bitbake correctly copies my defconfig to .config in the do_unpack function. But then it creates a new .config in the do_configure step, and overwrites the one copied in do_unpack. Sep 18 22:04:15 qemu recipe get broken? Sep 18 22:04:22 mranostay: pull, was fixed Sep 18 22:04:28 * rburton blames emacs! Sep 18 22:10:45 * mranostay converts rburton to the church of the vim Sep 18 22:13:09 mranostay: then you'll have patches that don't apply because there's random :w:w:q:q! in the middle Sep 18 22:14:32 rburton, would you like us to slap him around sum? Sep 18 22:14:35 some? Sep 18 22:14:55 ha Sep 18 22:15:10 never encountered the militant arm of the emacs league ;) Sep 18 22:24:24 okay, dumb question time... Sep 18 22:24:52 where do i look for the packaging/versioning guidelines? Sep 18 22:25:22 ie, what's legal for a pre-release package version? Sep 18 22:25:40 something like libfoo_1.2.0_pre1 Sep 18 22:26:19 or should it be libfoo_1.2.0_rc1 Sep 18 22:26:31 best off doing 1.1.0+1.2.0_pre1 or so, so it sorts after 1.1.0 but before 1.2.0 Sep 18 22:26:33 afaik anyway Sep 18 22:27:13 it's undefined then? Sep 18 22:42:13 mr_science: nooooooooooooooooooooooooooooo; emacs is the way! lol Sep 18 22:42:30 oops; mranostay it was to you heh Sep 18 22:43:11 ttfn Sep 18 22:47:15 lisp freak... Sep 18 22:48:54 damn, shot myself in the foot on that one... Sep 18 22:51:12 mr_science: every time you use emacs god kills a kitten :P Sep 18 22:52:00 and a dog when VIM is used? Sep 18 22:52:33 sounds about right Sep 18 22:52:37 I don't care about animals, I just want to edit recipes Sep 18 22:52:43 so what happens if i use nano? does the universe implode? Sep 18 22:53:01 no no, don't be silly Sep 18 22:53:05 hamsters die Sep 18 22:53:10 good Sep 18 22:53:13 no, your pen1s gets a bit smaller :) Sep 18 22:53:36 not touching that one... Sep 18 22:54:00 mc can also open ipk archives and inspect the files Sep 18 22:54:06 that would be aweful Sep 18 22:54:18 ah you meant you're not touching nano editor, right? :) Sep 18 22:54:27 * mranostay goes back to work Sep 18 22:54:54 * JaMa goes back to watching "0: gcc-4.8.1-r0 do_compile (pid 26914)" line Sep 18 22:55:20 1 beer on that it will fail again Sep 18 22:56:38 and it just did, /me wins a beer from his own fridge (sigh), someone building gcc for armv4t and seeing this? Sep 18 22:56:41 | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7438:(.text.unlikely+0x2fa): relocation truncated to fit: R_ARM_THM_CALL against symbol `fancy_abort(char const*, int, char const*)' defined in .glue_7 section in linker stubs Sep 18 22:56:45 | /OE/shr-core/tmp-eglibc/work-shared/gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7442:(.text.unlikely+0x318): additional relocation overflows omitted from the output Sep 18 23:06:54 JaMa, I have seen things like that, and the general answer we got was "you really can't compile things that large for old thumb, it just won't work". Sep 18 23:06:59 I think. My memory is fuzzy. Sep 18 23:08:36 it looks like I've seen it too before, http://patches.openembedded.org/patch/49903/ is from 4 months ago Sep 18 23:10:51 kergoth: have you ever actually read the output of "bitbake --help" recently? Its scary :/ Sep 18 23:11:45 kergoth: things that are completely obsolete, plain wrong or using really old terminology. Thought I was done fixing it, then found more problems... Sep 18 23:12:07 no one reads docs :) Sep 18 23:12:27 RP: would you accept patch disabling thumb in gcc at this point? Sep 18 23:12:29 ouch Sep 18 23:12:48 JaMa: for armv4 only? Sep 18 23:12:51 RP: I've sent RFC long time ago and now I've discovered that it's still needed (build running to verify) Sep 18 23:13:07 RP: yes, I can change it to armv4 only Sep 18 23:13:28 the problem is triggered only on armv4t Sep 18 23:13:29 JaMa: I'd need to see the patch tbh Sep 18 23:13:48 We've had a horrible set of build failures recently :( Sep 18 23:14:17 http://patches.openembedded.org/patch/49903/ this is the old version which doesn't apply anymore, but I'll test new one with added override for armv4 and send it to list Sep 18 23:14:28 Crofton|work: A new user correctly filed a bug complaining it was confusing Sep 18 23:14:36 I'd like to see us get past build failures and work on failures of running systems to do useful stuff Sep 18 23:14:41 :) Sep 18 23:15:17 if it builds, it's good; if it boots, it's perfect Sep 18 23:15:18 JaMa: oh, I see what you mean. If you make that armv4t only we can probably get it in... Sep 18 23:15:19 :) Sep 18 23:15:48 Crofton|work: a lot of the problem were the automated boot testing ;-) Sep 18 23:15:57 yep Sep 18 23:16:16 it is annoying when people build images that do not quite work out of the box Sep 18 23:16:21 ok gotta run and eat Sep 18 23:16:23 l8r Sep 18 23:16:27 well, I say were. I'm hoping this build is good Sep 18 23:16:31 w can save this idea for the next release Sep 18 23:16:51 Crofton|work: what, building working images? :) Sep 18 23:16:58 :) Sep 18 23:17:57 heh Sep 18 23:20:30 and for 1.7 we can sell them in paper boxes :) Sep 18 23:25:19 JaMa, all normal for armv4 here Sep 18 23:26:31 gn **** ENDING LOGGING AT Thu Sep 19 02:59:59 2013