Wednesday, 2013-09-18

-YoctoAutoBuilder- build #303 of nightly-x32 is complete: Success [build successful] Build details are at
*** andyross <andyross!> has quit IRC00:21
*** kmccombe <kmccombe!> has quit IRC00:21
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:23
*** drasko_ <drasko_!> has quit IRC00:24
*** kmccombe <kmccombe!> has joined #yocto00:24
*** kmccombe <kmccombe!> has quit IRC00:26
*** kmccombe <kmccombe!> has joined #yocto00:37
-YoctoAutoBuilder- build #294 of nightly-non-gpl3 is complete: Success [build successful] Build details are at
*** kmccombe <kmccombe!> has quit IRC00:44
*** kmccombe <kmccombe!> has joined #yocto00:47
*** mulhern <mulhern!> has quit IRC00:49
*** scot_ <scot_!~scot@> has quit IRC00:49
*** mulhern <mulhern!> has joined #yocto00:50
*** vmeson <vmeson!~quassel@> has quit IRC00:50
*** kmccombe <kmccombe!> has quit IRC00:53
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC00:59
*** Jefro <Jefro!~jefro@> has quit IRC01:00
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto01:00
-YoctoAutoBuilder- build #297 of nightly-x86-lsb is complete: Success [build successful] Build details are at
*** vmeson <vmeson!~quassel@> has joined #yocto01:00
*** kmccombe <kmccombe!> has joined #yocto01:01
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC01:02
-YoctoAutoBuilder- build #150 of minnow is complete: Success [build successful] Build details are at
*** ausjke <ausjke!~xxiao@> has quit IRC01:20
*** Jefro <Jefro!> has joined #yocto01:38
*** ka6sox is now known as zz_ka6sox01:39
*** notinreallife <notinreallife!> has quit IRC01:40
*** kmccombe <kmccombe!> has quit IRC01:44
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:51
*** mulhern <mulhern!> has quit IRC01:58
*** Jefro <Jefro!> has quit IRC01:59
*** silviof3 <silviof3!> has joined #yocto02:01
*** silviof2 <silviof2!> has quit IRC02:03
-YoctoAutoBuilder- build #293 of nightly-arm-lsb is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #292 of nightly-multilib is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #134 of minnow-lsb is complete: Success [build successful] Build details are at
*** [simar|on] <[simar|on]!~simar@> has joined #yocto02:37
*** [simar|on] <[simar|on]!~simar@> has quit IRC02:38
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC02:39
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto02:40
*** [simar|on] <[simar|on]!~simar@> has joined #yocto02:46
*** mulhern <mulhern!> has joined #yocto02:50
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC02:51
-YoctoAutoBuilder- build #292 of nightly-ppc-lsb is complete: Success [build successful] Build details are at
*** andyross <andyross!> has joined #yocto03:04
*** [simar|o1] <[simar|o1]!> has joined #yocto03:06
*** [simar|on] <[simar|on]!~simar@> has quit IRC03:09
*** [simar|o1] <[simar|o1]!> has quit IRC03:11
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto03:11
*** [simar|on] <[simar|on]!> has joined #yocto03:11
*** Jay7x <Jay7x!jay@> has joined #yocto03:11
*** forcev <forcev!> has joined #yocto03:12
*** pidge_ <pidge_!> has joined #yocto03:13
*** jjardon_ <jjardon_!uid723@gateway/web/> has joined #yocto03:13
*** roxell_ <roxell_!> has joined #yocto03:13
*** pidge <pidge!> has quit IRC03:13
*** Jay7 <Jay7!jay@> has quit IRC03:13
*** challinan_ <challinan_!> has quit IRC03:13
*** mitz <mitz!> has quit IRC03:13
*** roxell <roxell!~roxell@linaro/roxell> has quit IRC03:13
*** erbo <erbo!> has quit IRC03:13
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC03:13
*** jjardon <jjardon!uid723@gateway/web/> has quit IRC03:13
*** erbo <erbo!> has joined #yocto03:14
*** jjardon_ is now known as jjardon03:14
*** mitz__ <mitz__!> has joined #yocto03:14
*** ftonello <ftonello!> has quit IRC03:17
*** ftonello <ftonello!> has joined #yocto03:17
otaviosgw_: there?03:18
otavioI am looking at u-boot build failure you reported (fw-utils) and am curious how it end being built03:19
*** [simar|o1] <[simar|o1]!> has joined #yocto03:22
otaviosgw_: is it a world build?03:23
otaviopidge_: do you have the build number which got the u-boot-fw-utils failure?03:25
*** [simar|on] <[simar|on]!> has quit IRC03:25
otaviothe bug is
yoctiBug 5223: major, High, 1.5 M5, anders, NEW , [autobuilder] u-boot-fw-utils does not build correctly03:25
otavioFound it03:27
*** [simar|on] <[simar|on]!~simar@> has joined #yocto03:34
*** zenlinux__ is now known as zenlinux03:35
*** [simar|o1] <[simar|o1]!> has quit IRC03:38
*** [simar|o1] <[simar|o1]!~simar@> has joined #yocto03:40
*** [simar|on] <[simar|on]!~simar@> has quit IRC03:41
*** Jefro <Jefro!> has joined #yocto03:41
*** Jefro <Jefro!> has quit IRC03:43
otaviosgw_: I sent the u-boot-fw-utils fix03:44
otaviozeddii: any clue about the ppc failure? I started a perf build in all my machines to see if any reproduce the issue.03:45
*** [simar|on] <[simar|on]!> has joined #yocto03:47
*** mulhern <mulhern!> has quit IRC03:48
*** mulhern <mulhern!> has joined #yocto03:48
*** [simar|o1] <[simar|o1]!~simar@> has quit IRC03:50
*** andyross <andyross!> has quit IRC04:01
*** andyross <andyross!> has joined #yocto04:04
*** [simar|o1] <[simar|o1]!> has joined #yocto04:09
*** [simar|on] <[simar|on]!> has quit IRC04:13
-YoctoAutoBuilder- build #295 of nightly-x86 is complete: Success [build successful] Build details are at
*** [simar|on] <[simar|on]!~simar@> has joined #yocto04:32
*** ynezz <ynezz!> has joined #yocto04:33
*** amarsman <amarsman!> has quit IRC04:35
*** [simar|o1] <[simar|o1]!> has quit IRC04:36
*** Satrukaan <Satrukaan!> has joined #yocto04:41
*** [simar|o1] <[simar|o1]!> has joined #yocto04:41
*** [simar|on] <[simar|on]!~simar@> has quit IRC04:44
*** Satrukaan <Satrukaan!> has quit IRC04:45
*** amarsman <amarsman!> has joined #yocto04:50
*** mihai <mihai!~mihai@> has quit IRC04:54
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto04:55
*** mulhern <mulhern!> has quit IRC04:59
*** [simar|on] <[simar|on]!~simar@> has joined #yocto05:11
-YoctoAutoBuilder- build #270 of nightly-fsl-arm is complete: Success [build successful] Build details are at
*** [simar|o1] <[simar|o1]!> has quit IRC05:14
*** [simar|on] <[simar|on]!~simar@> has quit IRC05:15
*** [simar|on] <[simar|on]!> has joined #yocto05:16
*** wgao <wgao!~wgao@> has quit IRC05:18
*** andyross <andyross!> has quit IRC05:19
*** sameo <sameo!samuel@nat/intel/x-inmvtrqqzhkkvzgr> has joined #yocto05:22
*** agust <agust!> has joined #yocto05:34
*** [simar|o1] <[simar|o1]!~simar@> has joined #yocto05:35
*** [simar|on] <[simar|on]!> has quit IRC05:39
*** sameo <sameo!samuel@nat/intel/x-inmvtrqqzhkkvzgr> has quit IRC05:40
-YoctoAutoBuilder- build #268 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at
*** tor <tor!> has joined #yocto05:50
*** [simar|on] <[simar|on]!> has joined #yocto05:52
*** [simar|o1] <[simar|o1]!~simar@> has quit IRC05:55
*** smartin <smartin!~smartin@> has joined #yocto05:56
*** zecke <zecke!> has joined #yocto06:08
*** mihai <mihai!~mihai@> has joined #yocto06:14
*** zeeblex <zeeblex!apalalax@nat/intel/x-paxdefzfsifvlsnv> has joined #yocto06:14
*** eballetbo <eballetbo!> has joined #yocto06:41
*** BjornArnelid <BjornArnelid!5be58d0a@gateway/web/freenode/ip.> has joined #yocto06:45
BjornArnelidGood morning.06:45
*** ant_work <ant_work!> has joined #yocto06:51
*** [simar|o1] <[simar|o1]!~simar@> has joined #yocto06:55
*** [simar|on] <[simar|on]!> has quit IRC06:58
*** [simar|on] <[simar|on]!> has joined #yocto07:00
*** [simar|o1] <[simar|o1]!~simar@> has quit IRC07:00
*** [simar|on] <[simar|on]!> has quit IRC07:08
*** Zagor <Zagor!> has joined #yocto07:09
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto07:09
*** florian <florian!> has joined #yocto07:14
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:14
*** panda84kde <panda84kde!> has joined #yocto07:21
*** mckoan|away is now known as mckoan07:25
mckoangood morning07:25
*** bluelightning <bluelightning!~paul@> has joined #yocto07:31
*** bluelightning <bluelightning!~paul@> has quit IRC07:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:31
bluelightningmorning all07:31
ant_workgm folks07:34
*** likewise <likewise!> has joined #yocto07:35
ant_workRP: I'm still struggling with the hardcoded paths to target_sysroot. May I ask you to comment on this by chance?
*** hno <hno!~hno@squid/developer/hno> has quit IRC07:42
*** hno <hno!~hno@squid/developer/hno> has joined #yocto07:43
RPant_work: we do have a sysroot per machine but that does not mean things installed into the sysroot are machine specific07:45
*** fpaut <fpaut!> has joined #yocto07:45
RPant_work: the problem is the klcc scripts?07:46
ant_workyes :/07:47
RPant_work: think about how we solve this with the gcc binaries - we pass in --sysroot to them through cflags07:47
RPant_work: could you pass in a --sysroot option to klcc ?07:47
ant_workklibc and klcc-cross recipes are built with standard flags07:49
ant_workand in fact klcc-cross scripts points to the right binaries under /sysroots/i686-linux/usr/bin/armvXXX07:50
ant_workthe problem is the last part of it07:50
ant_workwhere it teach the builds where the klibc headers (extra headers plus stuff) are07:50
ant_workhere I get references to the target sysroot07:51
ant_worksee includedir ->
ant_workthe switch is $(INSTALLDIR)07:55
*** Saur <Saur!pkj@nat/axis/x-ugznixvllmwewsjj> has quit IRC08:01
ant_workRP: 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?08:01
*** spice <spice!> has joined #yocto08:02
RPant_work: you point them at the headers in the sysroot. when the sysroot changes, it needs to look in the new sysroot08:03
RPyou have to specify this to the compiler08:03
RPjust like we do with gcc-cross08:03
ant_workI'm sorry I can't follow.. all I can do is mangle  oe_runmake 'INSTALLDIR=${STAGING_DIR_TARGET}${target_libdir}/klibc' klcc08:07
ant_workklcc i's not a binary08:07
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC08:09
*** eballetbo <eballetbo!> has quit IRC08:11
*** Saur <Saur!pkj@nat/axis/x-dacbyvzugvuhrjcj> has joined #yocto08:15
*** JimBaxter <JimBaxter!> has joined #yocto08:22
*** roric__ <roric__!> has quit IRC08:22
*** roric <roric!> has quit IRC08:24
*** eballetbo <eballetbo!> has joined #yocto08:25
ant_workRP: 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 puppy08:25
*** BjornArnelid <BjornArnelid!5be58d0a@gateway/web/freenode/ip.> has quit IRC08:26
spiceHi 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?08:27
*** elbc <elbc!2e12602e@gateway/web/freenode/ip.> has quit IRC08:28
rburtonspice: that generally means udev is waiting for the right mount to appear08:28
rburtonspice: have you been experimenting with systemd?08:29
spicenot yet, I just tried to build core-image-base with default settings, except IMAGE_FSTYPES += "live"08:32
spice to get the iso file.08:32
spiceI found this article via google, that says this was fixed in 4.0.1 ...
rburtonhm the embedded initramfs should definitely have the mount rules08:38
rburtonspice: you can check, go to tmp/work/[your machine]/core-image-minimal-initramfs/1.0-r0/rootfs08:39
rburtonspice: there should be etc/udev/rules.d/automount.rules08:39
ant_workquestion: is the initramfs built?08:40
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto08:43
*** amarsman <amarsman!> has quit IRC08:43
lpapphmm, I wonder how the unpack task can fail when I can unpack the tar.xz fine manually?08:44
RPant_work: ok, how about you just create a machine specific part which takes a stored script and sets the sysroot correctly for that machine?08:46
RPant_work: Right now I simply don't have the time, we should talk about it after the release08:47
*** W1N9Zr0 <W1N9Zr0!> has quit IRC08:53
*** W1N9Zr0 <W1N9Zr0!> has joined #yocto08:53
ant_workRP: 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, thx08:54
*** belen <belen!Adium@nat/intel/x-rlwtuaursffxjmbg> has joined #yocto08:56
*** roric <roric!> has joined #yocto08:57
lpappfile -> foo.tar.xz: POSIX tar archive08:59
lpappwhy is yocto struggling with it?08:59
lpapp(to unpack)08:59
rburtonlpapp: without seeing the unpack log its hard to say08:59
lpappfoo.tar.xz | tar x --no-same-owner -f - failed with return value 209:00
rburtonlpapp: right09:00
rburtonthat's it09:00
lpappmanually running tar, it works fine.09:00
rburtonyour filename is tar.xz09:00
rburtonbut its not09:00
rburtonits a .tar09:00
lpappI do not follow.09:00
rburtonits not compressed09:00
lpapptar xvpf foo.tar.xz works just fine.09:00
lpappso yocto should uncompress it without any issues, too.09:01
rburton.xz means "this file has been compressed with xz"09:01
rburtonat no point in your tar command do you specify uncompressing09:02
rburtonbitbake is seeing .tar.xz, and attempting to uncompress09:02
lpappnot sure what you mean.09:02
lpappyocto should run tar xvpf09:02
lpappand that should work.09:02
lpappgit archive --prefix=foo-0.1/ -o foo.tar.xz HEAD -> moreover, I do not see how this could generate non xz.09:02
lpappit used to work in the path... I wonder what channged... o_O09:02
rburtonbecause you didn't compress it09:02
rburtonthat writes a .tar09:02
rburtongit-archive writes a tarball09:03
rburtonit does not also compress it09:03
lpappI am not sure I follow09:04
lpappI used the same the command as before.09:04
lpappand it worked fine with yocto as well without bothering.09:04
rburtonyou must have done something different09:05
rburtongit-archive produces an uncompressed tarball09:05
rburtonbut you're calling it .tar.xz09:05
rburtonwhich bitbake understandably considers to be a xz-compressed tarball09:05
rburtonso tries to uncompress it09:05
rburtonand fails09:05
rburtonbecause its not compressed09:05
rburtonas git-archive --help shows, pipe git-archive through xz or gzip or bzip209:06
lpappgit archive is supposed to provide a compressed tarball, name 'xz' format.09:06
lpappbut even if git archive fails, Yocto should not.09:06
lpappnot sure why git archive fails though.09:06
lpapprburton: seems git cannot produce xz at all... that is a weird surprise.09:12
rburtonas i said, git archive doesn't compress09:12
lpappanyway, it worked before with exactly the same command before copying the file to the yocto tree.09:12
lpappso how did it work before?09:12
rburtonyou did something differently09:12
lpappI did exactly the same.09:12
rburtonanywya, does it matter?  just pipe git-archive through xz and you'll be sorted09:12
Guest31240Hi, How quick question ... How to replace this in bitbake recipe for yocto?09:13
Guest31240fakeroot do_install() {09:13
lpappwell, it matters.09:13
lpappit used to work....09:13
lpappI would understand why it does not work anymore....09:13
spicerburton: i will have a look09:17
Guest31240hi how to replace fakeroot do_install() { in yocto. It doesnt find recipe for fakeroot-native09:22
spicerburton: I see two non commented lines in automount.rules:09:22
spiceSUBSYSTEM=="block", ACTION=="add"    RUN+="/etc/udev/scripts/"09:22
spiceSUBSYSTEM=="block", ACTION=="remove"    RUN+="/etc/udev/scripts/"09:22
*** likewise <likewise!> has quit IRC09:23
rburtonspice: so in that case, maybe your initramfs kernel doesn't know how to mount your media or access your device09:23
gonzzorIf 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?09:24
ant_workrburton: spice: is the kernel really embedding the initramfs?09:24
gonzzorAdded to the rootfs and removed using a image postprocess command and put into it's correct container?09:24
spiceant_work: how do I verify that?09:25
ant_workwell, check the size or the presence of the cpio.(gz:lzma) in kernel workdir under linux/usr09:26
lpapprburton: think I found the root cause.09:26
lpappI had the tar.xz git setting in my config09:26
lpappnot this time.09:26
spiceant_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.cfg09:27
ant_workah, ok, then it is not embedded09:27
ant_workI have right now issues with the old way of embedding initramfs, settting INITRAMFS_IMAGE09:28
ant_workI thougth you're maybe impacted but I see those image uses plain old initrd09:29
lpapprburton: file format still not recognized for unpacking... what the ... hack ? :)09:29
bluelightningGuest31240: fakeroot-native should be provided by pseudo-native09:29
*** Krz_ <Krz_!c0c6972c@gateway/web/freenode/ip.> has joined #yocto09:30
rburtonlpapp: run file on the tarball, check it matches the filename09:30
bluelightningGuest31240: to be precise, virtual/fakeroot-native should be provided by pseudo-native09:31
bluelightningGuest31240: do_install is already marked fakeroot btw, so that shouldn't be necessary in the recipe anyway09:32
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC09:33
Krz_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 status09:40
Krz_any idea?09:41
Krz_the error comes from v4l2apps/v4l-utils_0.8.809:42
*** mankku <mankku!> has quit IRC09:42
*** ant_work <ant_work!> has quit IRC09:42
*** ant___ <ant___!> has joined #yocto09:42
*** boz_v1 <boz_v1!> has quit IRC09:43
lpapprburton: thanks.09:47
Guest31240thx bluelightning09:48
*** dv_ <dv_!> has quit IRC09:49
*** gjohnson <gjohnson!> has quit IRC09:49
*** boz_v1 <boz_v1!> has joined #yocto09:52
spiceant_work: rburton: Any ideas what I can do to debug my non working LiveCD?09:53
*** dv_ <dv_!> has joined #yocto09:55
*** ant___ <ant___!> has quit IRC09:56
*** mankku <mankku!> has joined #yocto09:57
spicerburton: ant_work: Another idea: Is there a possibility to build an initrd only LiveCD?09:58
lpapphmm, what is the reason of having ./tmp/deploy/rpm/i586/ but not ./tmp/deploy/rpm/arm ?10:00
lpappwhere can I find the rpm packages for my arm board?10:00
rburtonlpapp: if there's not there, then maybe you removed package_rpm from your PACKAGE_CLASSES10:01
lpapprburton: hmm, yeah, it was changed to package_ipk10:02
lpappnot that I see opkg packages?10:02
rburtonthe directory will be ipkg10:03
lpappI do not have such a folder.10:03
rburtonsorry, ipk.10:03
rburton$ ls /data/poky-master/tmp/deploy/10:04
rburtonimages  ipk  licenses  sdk10:04
rburton^ mine10:04
lpappok, now I have it after rebuild, thanks.10:06
lpappis there a --prefix option with ipkg if I wanna install my package into /opt/foo ?10:06
lpappor if I wanna have such a thing, I need to use rpm?10:06
rburtonlpapp: why not build your package so that it installs into /opt/foo directly10:06
lpapprburton: because others may want to install it usually.10:07
rburtonnot sure if ipk has that option10:08
rburtonit does kinda break any hard-coded paths in the files10:08
lpapprpm has --prefix at least.10:09
rburtonsure. but any hard-coded paths will be incorrect.10:10
lpappinstall -d ${D}${bindir} and install -m 0755 ${WORKDIR}/foo-0.1/foo/foo ${D}${bindir}/10:10
lpappI have this, yet my rpm packages are empty. :(10:10
lpappShouldn't at least my "foo" binary inside?10:10
rburtondid you set FILES_${PN}?10:11
lpappwe do not use hard coded paths in our software.10:11
lpappbut I think install should be fine to the generic locations.10:11
lpappas the default class content takes care of the usual paths.10:11
rburtonthen yes, the default should have caught that.  in the work directory for that package you'll image, package, packages-split10:11
rburtonsee if anything is in those10:12
rburton(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)10:12
lpapprburton: yes, it is in that folder.10:15
lpappI used rpm -l to list the content.10:15
lpapphope that is the right command to check if there is anything inside.10:15
*** Stygia <Stygia!> has joined #yocto10:16
rburtonrpm -qpl, isn't it?10:17
lpappah, ok.10:17
lpappmy mistake then. :-)10:17
lpappI thought -l would be fine.10:17
spicerburton: 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?10:17
lpappthe list the content.10:17
lpapprburton: what is the best practice for creating a bundled package?10:18
lpappi.e. putting the openssl, etc libraries into the package.10:18
lpappis it possible without putting those into the archive?10:19
*** Krz_ <Krz_!c0c6972c@gateway/web/freenode/ip.> has quit IRC10:22
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto10:23
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto10:23
*** BjornArnelid <BjornArnelid!53fa9d78@gateway/web/freenode/ip.> has joined #yocto10:25
*** Krz_ <Krz_!c0c69725@gateway/web/freenode/ip.> has joined #yocto10:26
lpapprburton: hmm, the distributed rpm by core-image-minimal does not have the --prefix option. :(10:28
lpappit seems to be coming from busybox? rpm10:29
lpappBusyBox v1.20.2 (2012-11-16 01:53:09 GMT) multi-call binary.10:29
lpappstrange, my desktop busybox does not contain rpm... what is the origin of this then?10:29
lpappyep, it is busybox.10:32
lpappalthough it is a chopped variant (not supporting prefix :(10:32
rburtonour defconfig disables that, so presumably that's your busybox10:33
lpappoh, packages-split seems to be already stripped.10:34
*** Jay7x <Jay7x!jay@> has quit IRC10:44
lpappis 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?10:45
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC10:46
*** zecke <zecke!> has quit IRC10:54
*** forcev is now known as FunkyPenguin10:56
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto10:57
*** e8johan_ <e8johan_!~quassel@> has joined #yocto11:01
*** e8johan <e8johan!> has quit IRC11:01
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC11:08
RPlpapp: I don't think it makes much difference to Yocto if you do that :)11:09
RPlpapp: it sounds reasonable11:09
spicerburton: 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!11:10
lpappRP: OK, thanks.11:10
*** kmccombe <kmccombe!> has joined #yocto11:15
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto11:16
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:29
*** blitz00 <blitz00!stefans@nat/intel/x-epjnoefzhewohqbh> has joined #yocto11:31
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto11:31
*** mshakeel <mshakeel!~mshakeel@> has left #yocto11:32
*** Anusko <Anusko!~jcf@> has quit IRC11:33
*** Anusko <Anusko!~jcf@> has joined #yocto11:34
*** walters <walters!> has quit IRC11:37
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC11:38
*** zecke <zecke!> has joined #yocto11:46
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto11:47
*** spice <spice!> has quit IRC11:49
*** acidfu <acidfu!~nib@> has joined #yocto11:54
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto11:54
*** Anusko <Anusko!~jcf@> has quit IRC11:55
*** TuTizz <TuTizz!~TuTizz@> has quit IRC12:01
*** mshakeel <mshakeel!~mshakeel@> has joined #yocto12:01
Krz_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.12:05
bluelightningKrz_: is this a recipe or a bbappend?12:07
Krz_bluelightning: bbappend12:07
*** likewise <likewise!> has joined #yocto12:07
bluelightningKrz_: did you also extend FILESEXTRAPATHS in the bbappend?12:07
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto12:07
Krz_bluelightning: no, I just added SRC_URI line12:07
Krz_bluelightning: pointing to my patch12:08
bluelightningKrz_: right, you need to do FILESEXTRAPATHS_prepend := "${THISDIR}/files:"12:09
Krz_bluelightning: works like a charm, thanks12:11
bluelightningKrz_: np12:12
*** kmccombe <kmccombe!> has quit IRC12:15
*** kmccombe <kmccombe!> has joined #yocto12:18
*** kmccombe <kmccombe!> has quit IRC12:22
*** scot_ <scot_!~scot@> has joined #yocto12:26
*** padge_ <padge_!> has joined #yocto12:28
*** BjornArnelid <BjornArnelid!53fa9d78@gateway/web/freenode/ip.> has quit IRC12:28
*** mthalmei_away is now known as mthalmei12:34
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC12:34
*** vmeson <vmeson!~quassel@> has quit IRC12:35
*** vmeson <vmeson!~quassel@> has joined #yocto12:37
*** tinti_ <tinti_!~tinti@> has joined #yocto12:40
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto12:40
*** Jay7 <Jay7!jay@> has joined #yocto12:41
*** mthalmei is now known as mthalmei_away12:42
*** elmi82 <elmi82!> has joined #yocto12:46
*** roric_ <roric_!> has joined #yocto12:48
*** mshakeel <mshakeel!~mshakeel@> has quit IRC12:49
*** kmccombe <kmccombe!> has joined #yocto12:49
*** mshakeel <mshakeel!~mshakeel@> has joined #yocto12:51
*** gmacario <gmacario!> has joined #yocto12:52
*** elbc <elbc!2e12602e@gateway/web/freenode/ip.> has joined #yocto13:02
elbcrburton:  hi ! I succeeded in building gstreamer1.0 plugins ! hiwever the pipe failed : it seems that a 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 !13:05
*** roric_ <roric_!> has quit IRC13:07
rburtonelbc: mesa probably built it, have a look at packages in your deploy with mesa in their name13:07
elbci have done a find . -name gbm_gallium_drm.so13:09
elbcand nothing13:09
elbcthe package ligbm1 is present and installed on the image but is not providing the /usr/lib/gbm_gallium_drm.so13:10
rburtonthere might be a mesa-driver-gallium-something13:12
rburtonby default we don't build gallium though13:12
elbcrburton:  ok thanks but how to build without gallium and to make gstreamer1.0 working under wayland ?13:14
rburtonelbc: no idea, sorry.13:15
rburtonhaven't tried that yet13:15
elbcok thank you anyway !13:15
*** mulhern <mulhern!> has joined #yocto13:16
*** walters <walters!walters@nat/redhat/x-czevttnefvmapamz> has joined #yocto13:18
*** cascardo <cascardo!cascardo@nat/ibm/x-kecxioqsrhgdgwgi> has joined #yocto13:21
*** e8johan_ <e8johan_!~quassel@> has quit IRC13:21
*** walters <walters!walters@nat/redhat/x-czevttnefvmapamz> has quit IRC13:23
*** e8johan <e8johan!> has joined #yocto13:30
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto13:35
*** ant_work <ant_work!> has joined #yocto13:41
*** mulhern <mulhern!> has quit IRC13:45
*** gjohnson <gjohnson!> has joined #yocto13:45
otaviosgw_1: perf fix for ppc sent13:56
*** volker_ <volker_!> has joined #yocto13:56
*** volker <volker!> has quit IRC13:56
*** belen <belen!Adium@nat/intel/x-rlwtuaursffxjmbg> has quit IRC13:57
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto14:01
*** bluelightning_ <bluelightning_!~paul@> has quit IRC14:01
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto14:01
*** belen <belen!~Adium@> has joined #yocto14:02
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC14:03
*** sameo <sameo!~samuel@> has joined #yocto14:03
*** mihai <mihai!~mihai@> has quit IRC14:09
Krz_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?14:12
JaMait would be best to send patch to meta-oe converting gtk+ dependency to PACKAGECONFIG14:13
JaMathen you can have only very small .bbappend or just line in config disabling gtk+ dependency for your build14:14
*** wv <wv!> has joined #yocto14:14
wvhello, I want to bitbake core-image-web-kiosk for my imx53qsb14:15
wvthis works14:15
Krz_JaMa: can you give me some pointers on how to do that? I don't have much experience with PACKAGECONFIG14:15
wvbut I also want to add gstreamer1.0 with all plugins14:15
wvI do this by passing IMAGE_INSTALL_append = " gstreamer1.0 gstreamer1.0-plugins-base etc..." to my local.conf14:16
wvI think they are getting build, but I don't see all plugins in my rootfs14:16
wvI only have the libav and omx plugins available14:17
wveven the gstreamer0.10 which is apparantly build standard with this bitbake doesn't provide these plugins14:17
*** nitink1 <nitink1!~nitink@> has joined #yocto14:18
*** nitink <nitink!nitink@nat/intel/x-ctgrrbekcbtblcbm> has quit IRC14:18
kergothwv: the plugins are packaged in a very granular fashion, gstreamer1.0-plugins-base will only install the 'base' plugins14:19
wvyes, I know, with the thing that I don't see them via gst-inspect1.014:21
wveven when I should have added them via IMAGE_INSTALL_append14:21
Krz_JaMa: PACKAGECONFIG does not support 'EXTRA_OECMAKE' and I need to remove '-DWITH_GTK=ON' from that variable...14:23
bluelightning_Krz_: PACKAGECONFIG will add to EXTRA_OECMAKE if the recipe inherits cmake14:24
*** sameo <sameo!~samuel@> has quit IRC14:24
Krz_bluelightning_: in documentation PACKAGECONFIG is described as: EXTRA_OECONF, EXTRA_OECONF, DEPENDS, RDEPENDS14:25
Krz_bluelightning_: if recipe inherits cmake where do I put my EXTRA_OECMAKE ?14:25
bluelightning_Krz_: it happens automatically14:28
bluelightning_Krz_: the documentation is perhaps deficient in not mentioning that it'll add to EXTRA_OECMAKE automatically if the recipe inherits cmake14:29
bluelightning_(instead of EXTRA_OECONF, that is)14:29
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has quit IRC14:30
JaMaKrz_: 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)14:32
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC14:34
*** likewise <likewise!> has quit IRC14:36
*** belen <belen!~Adium@> has quit IRC14:37
*** belen <belen!~Adium@> has joined #yocto14:38
*** mulhern <mulhern!> has joined #yocto14:41
*** mckoan is now known as mckoan|away14:42
wvIs it possible that I have somewhere a filter which prevents me in adding these gstreamer1.0-plugins-base, good etc?14:42
wv(rather new to yocto)14:43
*** ArunKumar <ArunKumar!~SnowWhite@> has joined #yocto14:48
TuTizzHave 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?14:56
*** wmcdevel <wmcdevel!> has joined #yocto14:57
*** joeythesaint <joeythesaint!~jjm@> has quit IRC14:57
*** bluelightning1 <bluelightning1!~paul@> has joined #yocto14:57
*** bluelightning1 is now known as bluelightning14:57
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto14:57
frayTuTizz I don't have one, but I can help you..14:59
frayif 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..14:59
frayMUCH easier to share and maintain14:59
TuTizzyes this is it, I creating a new product.15:01
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC15:01
TuTizzso I should create a new recipe, for example I want qt4e and openssh15:02
*** andyross <andyross!> has joined #yocto15:02
frayyou can 'require' an existing image recipe, and then start modifying from that..  or copying it and make changes, etc..15:02
frayit should be as simple as adding the packages (not recipes) that you want installed to the IMAGE_INSTALL (think that is right) variable15:03
TuTizzok, a good start should be extend core-image-minimal15:03
wmcdevel@TuTizz: for openssh, you'll want to add ssh-server-openssh to your IMAGE_FEATURES ... that will cause it to be picked up15:03
frayif you are trying for a small image,t hen yes that is a perfect starting point..15:04
fraycore-image-basic (or is it core-image-core) is a good point if you want discrete (not busybox) command line apps15:04
frayalways try to build from small UP to what you want..15:04
wmcdevelif you want more than busybox :)15:04
frayit's much more difficult to start with something too big and build "down"15:05
*** dvhart <dvhart!~dvhart@> has joined #yocto15:05
Krz_bluelightning: JaMa: my point is what's the syntax for PACKAGECONFIG in recipe inheriting cmake15:05
fraythe 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 functionality15:06
TuTizzqt4e-demo-image run on my imx6, (I don't want the demo so I kill it then start my own application)15:06
TuTizzok lets talk about packagegroup15:06
Krz_bluelightning: JaMa: I presume it's PACKAGECONFIG[xyz] = "EXTRA_OECMAKE, EXTRAOECMAKE, DEPENDS, RDEPENS", am I right?15:07
fraypackagegroup-core-boot -- things required to 'boot' a typical system15:07
TuTizzif I want qt4e without the demo, I can extend core-image-basic with qt4-embedded_4.8.5.bb15:07
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto15:08
fray..  what you can do is:15:08
fraycreate a new recipe15:08
frayrequire core-image-basic.bb15:08
frayIMAGE_INSTALL += "qt4-embedded"15:09
fraythere is a packagegroupe though..  packagegroup-core-qt and packagegroup-core-qt4e15:09
bluelightningKrz_: yes that's correct for recipes that inherit cmake15:09
fraythat would add additional things usually needed for qt/qte15:09
Krz_bluelightning: great, thanks15:09
TuTizzthen bitbake myRecipe15:10
TuTizzAnother information, where should I put my new recipe? In meta directory? In meta-imx6?15:17
fraybest practice is to create a new customer layer for your recipes..15:20
fraythen place them in there..15:20
fraybasically create a new directory..  'meta-local' for instance..15:21
fraythen inside of there you need a conf/layer.conf15:21
fraylook at meta-yocto/conf/layer.conf as an example..15:22
fraycopy that file, and then replace 'yocto' with 'local'15:22
fray(remove the LAYERVERSION_yocto = "2" it's not needed for your local layer)15:22
fray(or set it to '1')15:22
fraythen as you create recipes.. just place them under 'recipes-<category>/<recipe>/<recipe>.bb15:23
*** wv <wv!> has quit IRC15:25
wmcdevelTuTizz: 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.15:25
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC15:25
frayyup.. the stuff I am telling you should all be covered..15:26
fraybut get in the habit of saving your work to recipes and in you own 'layer' right away..15:26
frayit will pay off in the long run with code you can share with others, and an easier way to manage things in an SCM..15:26
JaMajust 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-image15:26
fray(you just need to store your layer and perhaps configuration files in the SCM, instead of your whole project)15:26
frayJaMa, it's global.. but you can use the overrides to play some games.. as well as the whitelisting15:27
JaMatrue, but I cannot use e.g. image-name as _pn override, so the global flag isn't very useful for my use-case15:29
*** mihai <mihai!~mihai@> has joined #yocto15:29
JaMafor 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)15:29
wmcdevelTuTizz: 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: ... I really like how they set up their project, and it gives example of custom layers, customized recipes, and a customized distro.15:30
frayya, can't do that15:30
*** hollisb <hollisb!> has joined #yocto15:30
frayyou can do it based on global flags for debug and such15:30
TuTizzok thank you very much wmcdevel and fray, I am more confident now, I will try it. (and re-read the section 5.1)15:31
wmcdevelTuTizz: you're most welcome15:31
frayno problem..15:32
frayJaMa, you can do stuff like look for 'DEBUG_BUILD' = 115:33
frayvs a FULL_OPTIMIZATION build that kind of thing15:33
JaMaare you saying that I can build devel-image with DEBUG_BUILD = 1 and normal-image with DEBUG_BUILD = 0? I don't think so15:36
frayyou can.. it'll rebuild15:37
elbcrburton:  I have configured the 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)15:37
fraythe FULL and DEBUG optimizations are differnt15:37
JaMathat's exactly what I don't want :)15:37
JaMaI can use uninstall feature in worst case to maintain list of incompatible packages and remove them after image is built15:38
JaMaor just carefully keep dependency trees for images separate so that any incompatible package won't leak into normal image15:39
frayyou can also use the new PACKAGE_EXCLUDE functionality to prevent packages from being installed15:40
*** joeythesaint <joeythesaint!~jjm@> has quit IRC15:40
frayset PACKAGE_EXCLUDE = "..." in the production image that you -never- want installed on the target and it'll prevent them from 'leaking in' due to dependencies15:40
kergothguh, BUILD_CFLAGS is exported, so ends up in the task deps of *target* recipes15:40
*** elmi82 <elmi82!> has quit IRC15:40
fraythats because of apps building local 'helpers' and such..15:41
fraybut it might make sense to avoid that..15:41
kergothyeah, but the output doesn't change, thats internal build use15:41
kergothso while it's technically used, it might not be best to include it in the signature.. hmm15:41
frayit could affect the packaging or sysroot.. but I'm not sure if thats a real concern..15:41
kergothat this point we can't share target sstates across different build hosts anymore, since we had to explicitly add -march=<arch> to our builds, as we're building on centos5 with a 4.5 native toolchain15:43
fray(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)15:43
frayin fact I'm pretty sure that is the case15:43
fraythe -march= is only needed on the -really- old compiler(s)15:44
*** ArunKumar <ArunKumar!~SnowWhite@> has quit IRC15:44
kergothcentos 5 uses a really old compiler, at least according to poky's sanity.bbclass checks :)15:45
* kergoth looks into some sort of workaround until we can pursue a longer temr fix15:46
frayI thought latest centos 5 worked.. maybe not15:46
*** fpaut is now known as fpaut_15:46
frayyou can always use the ${HOST_MARCH} -- exclude HOST_MARCH, set HOST_MARCH = '-march=' when necessary15:46
kergothwe've had to work around a number of problems over time, even when using the buildtools tarball15:47
kergothgood point, that'd work as a workaround, thanks15:47
kergothdidn't think about that15:47
frayif you do that, I'd like to see the patch.. we may have to do the same.. :)15:47
*** drasko <drasko!> has joined #yocto15:47
draskoHi all. How to remove package source with bitbake?15:48
Krz_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 ?15:49
frayorder int he bblayers.conf does matter..15:49
bluelightningKrz_: bbappends are applied in priority order, but always after the recipe15:49
frayso does the file priority.. but I believe the file priority only matters if you have two files of identical names.. (.conf, .bb... NOT .bbappend)15:49
draskoIs there a command to bitbake to remove package source from download directory?15:49
frayahh so it does also affect application order of bbappends15:50
*** belen <belen!~Adium@> has quit IRC15:50
fraysee #oe.. bitbake -c cleanall <recipe>15:50
elbcrburton: if you have any solution don't hesitate to tell me about. thank you again15:50
fraydoes clean, cleansstate as well15:50
bluelightningfray: it didn't way back when bbappends were first introduced, but it was changed to do it quite a while ago15:50
fraydoes layer order matter still?15:51
frayI thought it did affect something15:51
kergothlayer order in bblayers affects bbpath, which affects .conf/.bbclass priority15:52
bluelightningfray: the layer order will affect how BBPATH gets constructed; but that's only about how conf/classes are found15:52
fraygotcha.. so I had it backwards..15:52
fraylayer order is the .conf/.bbclass and other 'files', while priority is recipe and bbappend15:52
*** belen <belen!~Adium@> has joined #yocto15:52
*** sameo <sameo!~samuel@> has joined #yocto15:55
draskois 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.15:56
*** cascardo <cascardo!cascardo@nat/ibm/x-kecxioqsrhgdgwgi> has left #yocto15:57
ndecdrasko: looking at the log file?15:57
ndecor the 'run' script15:58
draskondec: no way for this to be printed on console during the execution?15:58
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC15:58
*** zenlinux_ <zenlinux_!> has joined #yocto16:01
ndecdrasko: there -d for debug level. but i dont use it too much16:01
draskondec: I am looking at the log...16:01
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto16:02
*** nrossi <nrossi!~nrossi@> has quit IRC16:04
draskobut 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...16:05
*** nrossi <nrossi!~nrossi@> has joined #yocto16:05
draskoAnd observe if download is stuck16:05
fraykergoth FYI, we're adding the -march via a BUILD_CFLAGS_append.. and for some reason it doesn't appear to be changing the checksum16:05
fraylitterally if we detect a broken host.. we add the following to the local.conf -- BUILD_CFLAGS_append = " -march=<arch>"16:06
ndecdrasko: 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.16:07
fraywe'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 issue16:07
kergothhuh, interesting. i just did a diffsig between two target sstates from our 32 bit and 64 bit automated builds and saw BUILD_CFLAGS change16:11
* kergoth shrugs16:11
frayI've got someone running a comparison for us..16:12
frayhe was doing CentOS 5 and Ubuntu 12.0416:12
fraypossible the _append misses the checksum for some odd rason16:12
frayer.. reason16:13
*** ArunKumar <ArunKumar!~SnowWhite@> has joined #yocto16:13
*** Stygia <Stygia!> has quit IRC16:16
draskojoin #xenomai16:20
kergothwe're pulling in at the moment. not pretty, but gets the job done for us for now16:21
draskoAnybody has idea why Yocto breaks  EXTRA_OECONF += "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\"16:27
draskoin this way, adding ' between the words?16:27
*** amarsman <amarsman!> has joined #yocto16:27
draskoThis confuses ./configure tool16:27
fraykergoth ya, what we have is an external script (that writes the local.conf)..16:27
frayit runs three checks.. does gcc work w/o -march=.. if not, does gcc -march=native work?, if not does -march=<host> work?16:28
*** mr_science <mr_science!> has joined #yocto16:28
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:28
frayhen sets the BUILD_CFLAGS_append = " -march=<value>"  based on the results of the last two tests..16:28
fray(if neither work, an error is generated)  ;)16:28
draskofray, no I explicitly added this16:29
draskoEXTRA_OECONF += "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\"16:29
draskoin the .bb file16:29
*** gmacario <gmacario!> has quit IRC16:29
fraydrasko sorry was talking about kergoths issue16:29
frayfor the CFLAGS thing.. w/o the \" (inline quotes) the CFLAGS could get seperated into multiple "arguments" causing the shell to blow up16:30
draskobut it has \"16:32
draskoThe whole line is : "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\" --build=x86_64-linux-gnu --host=arm-linux-gnueabihf"16:32
draskoas needed here :
draskochapter 3.4. Building for ARM16:33
fraywhen it gets interpreted by the shell it comes out as:16:33
fray...configure <values> CFLAGS="-march=armv7-a -mfpu=vfp3\" LDFLAGS="-march=armv7-a -mfpu=vfp3" --build=x86_64-linux-gnu --host=arm-linux-gnueabihf16:34
fraythat is trying to pass specific CFLAG and LDFLAG vlaues into configure..16:34
fraynothing more16:34
draskobut why?16:35
draskoline seems correct16:35
*** mulhern <mulhern!> has quit IRC16:35
fraymost likely to avoid configure from setting it's own (incorrect) CFLAGS and LDFLAGS.. but I don't know why for that specific app16:36
*** eballetbo <eballetbo!> has quit IRC16:36
drasko"CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\" --build=x86_64-linux-gnu --host=arm-linux-gnueabihf"16:36
draskoso, this line normally is correct?16:36
frayit's not incorrect.. if it does the right thing or not, I don't know for that app16:36
draskofor the app it works16:37
draskoI can compile by hand16:37
draskohowever, bitbake separates "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\""16:37
draskointo separate words16:37
frayI can only guess because configure was implemented "poorly" for cross compiling16:37
fraythat was an errant message.. sorry16:38
fraybitbake SHOULD pass the values of EXTRA_OECONF -directly- to the shell..16:38
frayand the shell or configure may decided to expand it16:38
draskoadding these CFLAGS and LDFLAGS to configure - it is needed for build16:38
frayyou can see what is passed by looking at the tmp/work/<arch>/<recipe>/<version>/temp/run.do_configure.<pid.16:38
draskoso, can I pass these values to bitbke for build?16:39
draskomaybe that will do the trick?16:39
*** mulhern <mulhern!> has joined #yocto16:39
fraythe '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..16:40
fraythe only way to see for sure is to look at the runfile16:40
*** ArunKumar <ArunKumar!~SnowWhite@> has quit IRC16:42
*** khem1 <khem1!> has quit IRC16:43
draskoon the line 18 looks like bitbake passes wrong parameters to configure after all16:44
*** kmccombe <kmccombe!> has quit IRC16:44
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC16:44
frayvalues look fine, prior to the actual call into configure16:44
fraythen something (shell?) is breaking it up16:45
fraysorry, I'm not sure why..16:45
draskofrom my point of view first call to the shell is on line 1816:45
draskofirst call to configure16:45
draskobefore that bitbake was echoing what it will do16:46
draskoand reall call to configure happens on line 816:46
frayya.. and something is wrong there16:46
frayprior to that you can see that it's quoted16:46
draskothis is echo16:46
frayone possibility is to change the recipe to:16:46
draskoand then when configure is actually called16:46
draskoit is called wrongly16:47
frayEXTRA_OECONF += 'CFLAGS="...." LDFLAGS="..."'16:47
fraythen you can avoid the \16:47
draskoI am trying this right now16:47
draskohowever seems like bitbake bug16:47
*** seebs <seebs!> has quit IRC16:47
fraybitbake doesn't do the parsing.. the shell does16:48
draskowhich would say that bitbake passes line like this to configure: 'CFLAGS="-march=armv7-a' '-mfpu=vfp3"'16:49
draskoand hopes that shell will parse this correctly...16:50
frayit -should- pass CFLAGS="..." to the shell..16:50
draskobut on line 18 we see that it did not16:50
fraythe shell should see the " and group until the next quote w/ no shell argument expansion16:50
fraycorrect.. it didn't do that.. I don't know why16:50
*** seebs <seebs!> has joined #yocto16:51
fraybitbake 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.<pid> file..16:52
*** dany <dany!> has quit IRC16:52
frayit then calls /bin/sh and executes the script16:52
*** amarsman <amarsman!> has quit IRC16:56
*** amarsman <amarsman!> has joined #yocto16:57
*** kmccombe <kmccombe!> has joined #yocto16:59
draskoOK, with single quetes it is advancing a bit16:59
*** panda84kde <panda84kde!> has quit IRC17:00
draskohowever I have a probelm: includedir=/usr/include is automatically passed by bitbake17:00
draskoAnd then configure shouts : configure:2361: error: Using /usr/include as includedir is not supported. Please change your --prefix or specify another --includedir17:00
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC17:01
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto17:01
frayyour EXTRA_OECONF should pass then --include=${includedir}/${BPN}    (for instance)   this is fairly common17:02
*** belen <belen!~Adium@> has quit IRC17:07
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto17:07
*** sameo <sameo!~samuel@> has quit IRC17:08
*** belen <belen!Adium@nat/intel/x-wcivblipjhdlxpzv> has joined #yocto17:10
draskofray:this worked, thanks17:11
draskocan you tell me why, however?17:11
fraydiffernent programs take different interpretations of what --include= should contain..17:11
fraygenerally it's supposed to be the location (on the target fs) of where to install the headers..17:12
draskoand what is ${includedir}/${BPN}?17:12
fraymany 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 subdir17:12
frayincludedir == /usr/include17:12
*** ausxxh <ausxxh!~szaus18@> has joined #yocto17:12
frayBPN == recipe name17:12
frayso --  ${BPN} = 'foo'17:13
draskothanks a lot!17:13
frayno problem17:14
ant_workjwessel: any hint about embedding initramfs 'old-style'?17:18
ant_workjwessel: I can't even get the 'new-style' working :/17:18
jwesselWhat is "the old style" ?17:18
ant_workembed on first pass17:19
jwesselPerhaps you can send me your local.conf17:19
ant_workI simply cannot trigger the bundle_initramfs task17:19
jwesseland build target and can fix it.17:19
ant_workis standard17:19
ant_workI'll try on qemuarm to ease up debugging17:19
ant_worknote: is oe-core default, not Poky !17:20
jwesselok, 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?17:21
ant_worknot really17:21
ant_workI have tried to inject the cpio in our linux-yocto17:21
ant_workjust adding the INITRAMFS variables17:21
ant_workand trying to embed core-image-minimal17:22
ant_workwell, I did build core-image-base and the core-image-minimal wasn't even built17:22
wmcdevelant_work: is the cpio something created as part of your build or a static file that you are adding?17:22
ant_worknote we always build th ekernel in our bsp17:22
ant_workfor every image17:23
jwesselFor example, I have in my local.conf:17:24
jwesselINITRAMFS_IMAGE_BUNDLE = "1"17:24
jwesselINITRAMFS_IMAGE = "core-image-minimal-initramfs"17:24
ant_workhm.. I put th plain "core-image-minimal"17:24
jwesselWhat happens is that in the final stage the bzIamge gets re-linked to have the initramfs build in.17:24
jwesselI just do bitbake core-image-minimal in this case.17:25
*** zenlinux_ <zenlinux_!> has quit IRC17:25
*** belen <belen!Adium@nat/intel/x-wcivblipjhdlxpzv> has quit IRC17:25
ant_workjwessel: I have nothing against the two passes17:25
jwesselSo you want to build core-image-minimal and then wrap it into a single binary?17:25
ant_workno, usually I embed a very very small cpio17:26
ant_workI just tried to reproduce what you were aiming for17:26
ant_worka linux-yocto embeding a big image17:26
ant_workwhithout setting CONFIG_INITRAMFS_SOURCE in my cfg17:27
jwesselWell if you have a image recipe that creates your "small cpio" you can just specify it.17:27
ant_workjwessel: somehow only specifying INITRAMFS_TASK triggers the build17:27
ant_workbut the do_bundle_initramfs seems not run so I don't have the copy_initramfs() -> my patch to kernel.bbclass17:29
jwesselThe initramfs task is separate from the bundling.17:29
jwesselThe kernel's do configure depends on the intramfs task.17:29
ant_workyes, that's the old, proven, way17:29
jwesselIn that case you would need to specify where your image is.17:30
jwesselWhat you are asking for is the ability to specify a specific cpio image that got built in a specific location right?17:30
ant_workI just want to specify the cpio image without path, like it was17:31
ant_workit is an image known to bitbake17:31
ant_workis in BBFILES17:31
ant_workthe point is that it resides in deploy dir17:31
ant_workso in one way or other you have to copy it in /usr17:32
ant_workyour code:17:32
ant_workcp ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ${B}/usr/.17:32
jwesselThat is the part I was looking at.17:32
ant_workbut in my tests, this funtion is never called17:32
ant_workthe task is not run17:33
jwesselThe function is only called if you have INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE set.17:33
ant_workI'd expect too17:33
ant_workbtw the image is17:34
ant_workno renames, anything17:34
ant_workbut EXTRA_IMAGEDEPENDS = ""17:34
ant_workjwessel: once at home I'll send you my full setup17:36
ant_workthx for your time17:36
*** ant_work <ant_work!> has quit IRC17:36
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC17:41
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:43
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:52
*** padge_ <padge_!> has quit IRC17:54
*** joaohf <joaohf!> has quit IRC17:57
*** smartin_ <smartin_!> has joined #yocto17:58
draskofray: interestingly, trying : "CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3"" works17:59
*** zz_ka6sox is now known as ka6sox17:59
draskoso, Bitbake exports this to the shell CFLAGS="-march=armv7-a -mfpu=vfp3"17:59
draskoas seen in run.do_configure17:59
draskoHowever, doing "CFLAGS=\"-march=armv7-a -mfpu=vfp3\" LDFLAGS=\"-march=armv7-a -mfpu=vfp3\""18:00
draskoBitbake exports CFLAGS=\"-march=armv7-a -mfpu=vfp3\"18:01
draskoLooks like it takes first quote, goes to the last, and takes everything in between literally...18:01
*** YoctoNewbie <YoctoNewbie!dc562822@gateway/web/freenode/ip.> has joined #yocto18:04
YoctoNewbiehi there18:05
wmcdevelquick question for the gurus ... I'm making a BSP for a board, and I have a custom ts.conf and 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 go in meta-mini6410-bsp/recipes-graphics/tslib/mini6410, where mini6410 == ${MACHINE}?18:08
kergoththat's one option, yes, if you set FILESEXTRAPATHS_prepend := "${THISDIR}:"18:11
*** joaohf <joaohf!> has joined #yocto18:11
sgw_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 example18:13
wmcdevelcool. anything else I would need to override in the bbappend with "_mini6410 at the end?18:13
wmcdevelok ... yeah, don't know why I didn't think of that - that's exactly the setup I'm trying to get. :)18:14
wmcdevelthat'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 you18:16
*** kmccombe <kmccombe!> has quit IRC18:28
*** joaohf <joaohf!> has quit IRC18:30
wmcdevelanother 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.18:37
wmcdevelat 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.18:38
*** kmccombe <kmccombe!> has joined #yocto18:39
*** mulhern <mulhern!> has quit IRC18:42
*** joaohf <joaohf!> has joined #yocto18:43
*** roric_ <roric_!> has joined #yocto18:47
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC18:48
*** drasko_ <drasko_!> has joined #yocto18:49
*** YoctoNewbie <YoctoNewbie!dc562822@gateway/web/freenode/ip.> has quit IRC19:07
*** wmcdevel <wmcdevel!> has quit IRC19:21
*** wmcdevel <wmcdevel!> has joined #yocto19:22
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:26
*** seebs <seebs!> has quit IRC19:27
*** joaohf <joaohf!> has quit IRC19:28
*** seebs <seebs!> has joined #yocto19:37
*** joeythesaint <joeythesaint!~jjm@> has quit IRC19:40
*** joaohf <joaohf!> has joined #yocto19:40
*** mr_science <mr_science!> has joined #yocto19:45
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto19:45
*** zeeblex <zeeblex!apalalax@nat/intel/x-paxdefzfsifvlsnv> has left #yocto19:53
*** nitink1 <nitink1!~nitink@> has quit IRC20:06
*** nitink <nitink!nitink@nat/intel/x-gvhttbjekpukmxcl> has joined #yocto20:07
*** eren <eren!~eren@unaffiliated/eren> has quit IRC20:08
*** amarsman <amarsman!> has quit IRC20:13
*** amarsman <amarsman!> has joined #yocto20:17
*** amarsman <amarsman!> has quit IRC20:18
*** nitink <nitink!nitink@nat/intel/x-gvhttbjekpukmxcl> has quit IRC20:21
*** sameo <sameo!~samuel@> has joined #yocto20:30
-YoctoAutoBuilder- build #258 of nightly is complete: Exception [exception interrupted] Build details are at
*** tor <tor!> has quit IRC20:35
*** ArunKumar <ArunKumar!~SnowWhite@> has joined #yocto20:41
-YoctoAutoBuilder- build #42 of nightly-qa-extras is complete: Failure [failed Building Images Running Sanity Tests Building Images_1 Running Sanity Tests_1] Build details are at
-YoctoAutoBuilder- build #2 of nightly-qa-pam is complete: Failure [failed Building Images Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #2 of nightly-qa-skeleton is complete: Failure [failed Building Images Running Sanity Tests] Build details are at
*** Krz_ <Krz_!c0c69725@gateway/web/freenode/ip.> has quit IRC20:59
*** kspr <kspr!> has joined #yocto21:00
-YoctoAutoBuilder- build #271 of nightly-fsl-arm is complete: Failure [failed Building Images Building Toolchain Images Building Toolchain Images_1 Building Images_1 Building Images_2 Publishing Artifacts] Build details are at
-YoctoAutoBuilder- build #151 of minnow is complete: Failure [failed Building Images Publishing Artifacts] Build details are at
ksprHi there :)21:02
ksprWhen 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?21:03
-YoctoAutoBuilder- build #2 of nightly-qa-logrotate is complete: Failure [failed Building Images Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #68 of eclipse-plugin-kepler is complete: Exception [exception interrupted] Build details are at
-YoctoAutoBuilder- build #307 of nightly-intel-gpl is complete: Exception [exception Building Images] Build details are at
-YoctoAutoBuilder- build #272 of nightly-oecore is complete: Exception [exception Building Images] Build details are at
seebskspr, I'm not totally sure, but I think all the bbappends apply in some order.21:04
*** ArunKumar <ArunKumar!~SnowWhite@> has quit IRC21:04
ksprseebs, ok, thanks. Trying to find some docs on this.. not easy :P21:05
evanpkspr: what do you mean by "revision of .bbappend"?21:05
ksprevanp, I mean, if I have multiple .bbappend files, with the PR incremented..21:06
-YoctoAutoBuilder- build #107 of buildtools is complete: Exception [exception interrupted] Build details are at
-YoctoAutoBuilder- build #298 of poky-tiny is complete: Exception [exception interrupted] Build details are at
evanpkspr: I'm pretty sure the .bbappends apply in layer priority order21:06
evanpkspr: which has nothing to do with what variables they do or do not contain assignments to, of course21:06
ksprOkay, 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 itself21:07
*** [simar|on] <[simar|on]!> has joined #yocto21:08
-YoctoAutoBuilder- build #296 of build-appliance is complete: Exception [exception interrupted] Build details are at
-YoctoAutoBuilder- build #298 of nightly-x86-lsb is complete: Exception [exception interrupted] Build details are at
-YoctoAutoBuilder- build #295 of nightly-non-gpl3 is complete: Exception [exception interrupted] Build details are at
evanpkspr: 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 file21:09
-YoctoAutoBuilder- build #293 of nightly-ppc-lsb is complete: Exception [exception interrupted] Build details are at
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC21:10
ksprevanp, okay, great. So it is the layer priority that defines the order, and not the PR21:10
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto21:10
evanpkspr: not sure if .bbappends in earlier layers affect .bbs in later layers....21:10
ksprevanp, which means that an older PR could override a newer one, if the layer order dictates it.21:11
ksprevanp, okay :)21:11
evanpkspr: 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 described21:11
evanpkspr: yes, that's right21:12
ksprevanp, right, okay :)21:12
*** roxell_ <roxell_!> has quit IRC21:17
*** roxell <roxell!~roxell@linaro/roxell> has joined #yocto21:17
*** zecke <zecke!> has quit IRC21:17
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-ncrbeepnvazpxzhu> has quit IRC21:18
*** kmccombe <kmccombe!> has quit IRC21:19
*** drasko_ <drasko_!> has quit IRC21:20
*** smartin_ <smartin_!> has quit IRC21:23
*** roric_ <roric_!> has quit IRC21:24
*** khem1 <khem1!> has joined #yocto21:30
*** sameo <sameo!~samuel@> has quit IRC21:34
*** mulhern <mulhern!> has joined #yocto21:41
*** Jay7 <Jay7!jay@> has quit IRC22:00
*** el_robin <el_robin!> has quit IRC22:02
ksprHmm, 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.22:03
mranostayqemu recipe get broken?22:04
rburtonmranostay: pull, was fixed22:04
* rburton blames emacs!22:04
*** el_robin <el_robin!~el_robin@2a01:e0b:1:124:3c7c:66ec:30c8:530f> has joined #yocto22:04
*** [simar|o1] <[simar|o1]!> has joined #yocto22:06
*** [simar|on] <[simar|on]!> has quit IRC22:10
* mranostay converts rburton to the church of the vim22:10
*** mulhern <mulhern!> has quit IRC22:11
*** [simar|on] <[simar|on]!> has joined #yocto22:11
*** JimBaxter <JimBaxter!> has quit IRC22:12
*** [simar|o1] <[simar|o1]!> has quit IRC22:12
rburtonmranostay: then you'll have patches that don't apply because there's random :w:w:q:q! in the middle22:13
Crofton|workrburton, would you like us to slap him around sum?22:14
*** tomz <tomz!> has quit IRC22:14
*** tomz <tomz!> has joined #yocto22:15
rburtonnever encountered the militant arm of the emacs league ;)22:15
*** ant_home <ant_home!> has joined #yocto22:18
*** tomz1 <tomz1!> has joined #yocto22:20
*** tomz <tomz!> has quit IRC22:20
mr_scienceokay, dumb question time...22:24
mr_sciencewhere do i look for the packaging/versioning guidelines?22:24
mr_scienceie, what's legal for a pre-release package version?22:25
mr_sciencesomething like libfoo_1.2.0_pre122:25
mr_scienceor should it be libfoo_1.2.0_rc122:26
kergothbest off doing 1.1.0+1.2.0_pre1 or so, so it sorts after 1.1.0 but before 1.2.022:26
kergothafaik anyway22:26
mr_scienceit's undefined then?22:27
*** vmeson <vmeson!~quassel@> has quit IRC22:27
*** vmeson <vmeson!~quassel@> has joined #yocto22:29
*** [simar|o1] <[simar|o1]!~simar@> has joined #yocto22:31
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC22:33
*** [simar|on] <[simar|on]!> has quit IRC22:34
*** agust <agust!> has quit IRC22:34
*** wmcdevel <wmcdevel!> has left #yocto22:38
*** [simar|on] <[simar|on]!~simar@> has joined #yocto22:40
otaviomr_science: nooooooooooooooooooooooooooooo; emacs is the way! lol22:42
otaviooops; mranostay it was to you heh22:42
*** [simar|o1] <[simar|o1]!~simar@> has quit IRC22:43
mr_sciencelisp freak...22:47
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC22:48
mr_sciencedamn, shot myself in the foot on that one...22:48
*** dvhart <dvhart!~dvhart@> has quit IRC22:49
mranostaymr_science: every time you use emacs god kills a kitten :P22:51
JaMaand a dog when VIM is used?22:52
*** nitink <nitink!~nitink@> has joined #yocto22:52
*** Jefro <Jefro!> has joined #yocto22:52
rburtonsounds about right22:52
JaMaI don't care about animals, I just want to edit recipes22:52
mr_scienceso what happens if i use nano?  does the universe implode?22:52
rburtonno no, don't be silly22:53
rburtonhamsters die22:53
JaMano, your pen1s gets a bit smaller :)22:53
mr_sciencenot touching that one...22:53
ant_homemc can also open ipk archives and inspect the files22:54
JaMathat would be aweful22:54
JaMaah you meant you're not touching nano editor, right? :)22:54
* mranostay goes back to work22:54
* JaMa goes back to watching "0: gcc-4.8.1-r0 do_compile (pid 26914)" line22:54
JaMa1 beer on that it will fail again22:55
JaMaand it just did, /me wins a beer from his own fridge (sigh), someone building gcc for armv4t and seeing this?22:56
JaMa| /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 stubs22:56
JaMa| /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 output22:56
*** notinreallife <notinreallife!> has joined #yocto22:57
*** pidge_ <pidge_!> has quit IRC22:57
*** Gintaro_ <Gintaro_!> has joined #yocto23:00
*** Gintaro <Gintaro!> has quit IRC23:00
*** khem1 <khem1!> has quit IRC23:00
seebsJaMa, 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".23:06
seebsI think. My memory is fuzzy.23:06
-YoctoAutoBuilder- build #43 of nightly-qa-extras is complete: Success [build successful] Build details are at
*** seebs <seebs!> has quit IRC23:07
JaMait looks like I've seen it too before, is from 4 months ago23:08
RPkergoth: have you ever actually read the output of "bitbake --help" recently? Its scary :/23:10
*** seebs <seebs!> has joined #yocto23:11
RPkergoth: things that are completely obsolete, plain wrong or using really old terminology. Thought I was done fixing it, then found more problems...23:11
Crofton|workno one reads docs :)23:12
JaMaRP: would you accept patch disabling thumb in gcc at this point?23:12
RPJaMa: for armv4 only?23:12
JaMaRP: I've sent RFC long time ago and now I've discovered that it's still needed (build running to verify)23:12
JaMaRP: yes, I can change it to armv4 only23:13
JaMathe problem is triggered only on armv4t23:13
RPJaMa: I'd need to see the patch tbh23:13
RPWe've had a horrible set of build failures recently :(23:13
JaMa 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 list23:14
RPCrofton|work: A new user correctly filed a bug complaining it was confusing23:14
Crofton|workI'd like to see us get past build failures and work on failures of running systems to do useful stuff23:14
JaMaif it builds, it's good; if it boots, it's perfect23:15
RPJaMa: oh, I see what you mean. If you make that armv4t only we can probably get it in...23:15
RPCrofton|work: a lot of the problem were the automated boot testing ;-)23:15
Crofton|workit is annoying when people build images that do not quite work out of the box23:16
Crofton|workok gotta run and eat23:16
RPwell, I say were. I'm hoping this build is good23:16
Crofton|workw can save this idea for the next release23:16
RPCrofton|work: what, building working images? :)23:16
JaMaand for 1.7 we can sell them in paper boxes :)23:20
*** andyross <andyross!> has quit IRC23:23
*** andyross <andyross!> has joined #yocto23:24
ant_homeJaMa, all normal for armv4 here23:25
*** ant_home <ant_home!> has quit IRC23:26
*** kspr <kspr!> has quit IRC23:26
*** Jay7 <Jay7!jay@> has joined #yocto23:30
*** kmccombe <kmccombe!> has joined #yocto23:34
-YoctoAutoBuilder- build #3 of nightly-qa-skeleton is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #3 of nightly-qa-pam is complete: Success [build successful] Build details are at
*** [simar|o1] <[simar|o1]!> has joined #yocto23:43
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC23:46
*** [simar|on] <[simar|on]!~simar@> has quit IRC23:46
*** [simar|o1] <[simar|o1]!> has quit IRC23:47
*** [simar|on] <[simar|on]!~simar@> has joined #yocto23:48
*** andyross <andyross!> has quit IRC23:58

Generated by 2.11.0 by Marius Gedminas - find it at!