Friday, 2013-09-06

*** Jefro <Jefro!~jefro@205.154.63.43> has joined #yocto00:10
*** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has joined #yocto00:12
*** davest <davest!~Adium@134.134.139.76> has quit IRC00:16
*** davest <davest!~Adium@134.134.139.76> has joined #yocto00:16
*** Jefro <Jefro!~jefro@205.154.63.43> has quit IRC00:19
*** Jefro <Jefro!~jefro@205.154.63.43> has joined #yocto00:26
*** davest <davest!~Adium@134.134.139.76> has quit IRC00:34
*** davest <davest!~Adium@134.134.139.76> has joined #yocto00:35
*** Jefro <Jefro!~jefro@205.154.63.43> has quit IRC00:51
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto00:56
*** davest <davest!~Adium@134.134.139.76> has quit IRC00:59
*** joeythesaint <joeythesaint!~jjm@198-84-238-35.cpe.teksavvy.com> has joined #yocto01:00
*** davest <davest!~Adium@134.134.139.76> has joined #yocto01:08
*** davest <davest!~Adium@134.134.139.76> has quit IRC01:19
*** davest <davest!~Adium@134.134.139.76> has joined #yocto01:31
-YoctoAutoBuilder- build #280 of nightly-world is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-world/builds/28001:45
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC02:12
*** Daemon404 <Daemon404!~who_knows@host86-145-130-143.range86-145.btcentralplus.com> has joined #yocto02:14
*** davest <davest!~Adium@134.134.139.76> has quit IRC02:15
*** davest <davest!~Adium@134.134.139.76> has joined #yocto02:35
*** joeythesaint <joeythesaint!~jjm@198-84-238-35.cpe.teksavvy.com> has quit IRC02:46
*** zz_ka6sox is now known as ka6sox02:51
*** davest <davest!~Adium@134.134.139.76> has quit IRC02:55
-YoctoAutoBuilder- build #281 of nightly-multilib is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-multilib/builds/28103:01
*** uvan <uvan!~uvan@118.69.219.197> has joined #yocto03:17
*** uvan <uvan!~uvan@118.69.219.197> has left #yocto03:18
*** uvan <uvan!~uvan@118.69.219.197> has joined #yocto03:21
*** [simar|school] <[simar|school]!~simar@69.166.24.103> has joined #yocto03:24
*** behanw <behanw!~behanw@216.58.123.51> has quit IRC03:32
*** ka6sox is now known as zz_ka6sox03:58
*** SidH_ <SidH_!~SidH_@61.95.193.239> has joined #yocto04:10
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto04:25
*** amarsman <amarsman!~marsman@52489B71.cm-4-1c.dynamic.ziggo.nl> has quit IRC04:26
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC04:28
*** zz_ka6sox is now known as ka6sox04:31
*** _alex_kag_ <_alex_kag_!~alex_kag@93.84.109.218> has quit IRC04:33
*** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has joined #yocto04:40
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto04:42
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto04:54
*** _alex_kag_ <_alex_kag_!~alex_kag@178.124.29.38> has joined #yocto04:55
*** ka6sox is now known as zz_ka6sox05:07
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC05:10
*** mbelisko <mbelisko!~mbelisko@81.89.61.168.vnet.sk> has joined #yocto05:13
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC05:30
*** [simar|school] <[simar|school]!~simar@69.166.24.103> has quit IRC05:43
*** blitz00 <blitz00!~stefans@192.198.151.44> has joined #yocto05:45
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto05:45
*** zecke <zecke!~ich@p5099b351.dip0.t-ipconnect.de> has joined #yocto05:57
*** swex <swex!~swex@217.197.253.123> has quit IRC06:00
*** swex <swex!~swex@217.197.253.123> has joined #yocto06:01
*** kbart <kbart!~KBart@213.197.143.19> has joined #yocto06:05
-YoctoAutoBuilder- build #257 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm-lsb/builds/25706:16
*** pirut <pirut!~Pirut@134.134.139.72> has quit IRC06:26
*** pirut <pirut!~Pirut@134.134.139.72> has joined #yocto06:29
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto06:32
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC06:35
*** Zagor <Zagor!~bjst@sestofw01.enea.se> has joined #yocto06:39
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto06:39
*** mshakeel <mshakeel!~mshakeel@110.93.212.98> has quit IRC06:40
*** mshakeel <mshakeel!~mshakeel@110.93.212.98> has joined #yocto06:43
*** SidH_ <SidH_!~SidH_@61.95.193.239> has quit IRC06:51
*** vicky <vicky!~vicky@122.165.223.135> has joined #yocto06:51
*** SidH_ <SidH_!~SidH_@61.95.193.238> has joined #yocto06:51
vickyhow to remove debug package creation in bb file?06:52
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto06:52
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto07:07
*** mike <mike!c2881242@gateway/web/freenode/ip.194.136.18.66> has joined #yocto07:08
*** mike is now known as Guest4291407:08
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto07:09
*** slaine <slaine!~slaine@84.203.137.218> has joined #yocto07:09
*** mihai <mihai!~mihai@80.97.15.150> has joined #yocto07:09
*** uvan <uvan!~uvan@118.69.219.197> has quit IRC07:10
*** florian_kc <florian_kc!~fuchs@port-217-146-132-69.static.qsc.de> has joined #yocto07:10
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:10
*** uvan <uvan!~uvan@118.69.219.197> has joined #yocto07:10
*** n01 <n01!~n01@host225-0-static.96-5-b.business.telecomitalia.it> has joined #yocto07:11
*** florian_kc is now known as florian07:13
*** mckoan|away is now known as mckoan07:13
mckoangood morning07:14
*** e8johan <e8johan!~quassel@194-237-7-146.customer.telia.com> has joined #yocto07:18
*** gaby <gaby!~gaby@lse.epita.fr> has quit IRC07:25
*** vicky <vicky!~vicky@122.165.223.135> has quit IRC07:27
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto07:27
*** dany <dany!~Thunderbi@sestofw01.enea.se> has quit IRC07:28
*** dany <dany!~Thunderbi@sestofw01.enea.se> has joined #yocto07:30
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has quit IRC07:34
*** gaby <gaby!~gaby@lse.epita.fr> has joined #yocto07:36
*** vicky <vicky!~vicky@122.165.223.135> has joined #yocto07:39
vickyany idea guys?07:40
*** gaby <gaby!~gaby@lse.epita.fr> has quit IRC07:40
*** gaby <gaby!~gaby@lse.epita.fr> has joined #yocto07:41
*** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has quit IRC07:43
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC07:44
lpappvicky: check the class how it works.07:45
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has joined #yocto07:48
*** zeeblex <zeeblex!apalalax@nat/intel/x-mtdyixwwvzfqxtnk> has joined #yocto07:51
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC07:52
*** jkridner <jkridner!~jkridner@c-98-250-142-42.hsd1.mi.comcast.net> has joined #yocto07:52
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto07:52
*** amarsman <amarsman!~marsman@52489B71.cm-4-1c.dynamic.ziggo.nl> has joined #yocto07:54
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC07:57
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto07:57
vickylpapp: Sorry for ask this question? Hw to check the class?07:57
*** sameo <sameo!~samuel@192.55.54.41> has joined #yocto07:57
*** amarsman <amarsman!~marsman@52489B71.cm-4-1c.dynamic.ziggo.nl> has quit IRC07:58
lpappvicky: meta/classes08:06
*** Anusko <Anusko!~anusko@62.159.77.165> has joined #yocto08:11
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto08:18
*** magthe <magthe!~magnus@193.15.95.2> has joined #yocto08:22
magtheadding "uboot" to IMAGE_FSTYPES did not have the effect I had hoped: packaging my rootfs.cpio (core-image-minimal/poky-tiny) image with mkimage... any pointers on how to achieve what I'm trying to do?08:25
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto08:33
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC08:36
nrossimagthe: i think you want "cpio.u-boot" as the IMAGE_FSTYPES value08:41
nrossimagthe and "cpio.gz.u-boot" if you want it gzipped08:41
rburtonvicky: i think setting INHIBIT_PACKAGE_DEBUG_SPLIT="1" in your recipe will do that for a single recipe08:43
rburtonvicky: assuming that's what you want08:43
*** belen <belen!Adium@nat/intel/x-hdytnuliaucrbevz> has joined #yocto08:44
magthenrossi: yes indeed, that sorted it, thanks!08:44
nrossirburton: i think "INHIBIT_PACKAGE_DEBUG_SPLIT" only inhibits the spliting the of elf files into pkg and pkg-dbg, it wont prevent the creation of pkg-dbg if there are FILES set to be added to the dbg package08:45
rburtonnrossi: damn. i can never remember how to control the debug stuff.08:46
nrossirburton: I think its dependent on how the inherit classes will distribute the debug files. Some recipes manually specific debug files and others rely on things like autotools.bbclass08:47
magtheanother question about IMAGE_FSTYPES: where in my build setup should I set it?08:48
magthein most examples it's set/modified in the machine config, but that is read before the distro config and poky-tiny sets IMAGE_FSTYPES using '='08:49
*** kergoth <kergoth!~kergoth@covenant.kergoth.com> has quit IRC08:50
*** kergoth <kergoth!~kergoth@covenant.kergoth.com> has joined #yocto08:50
nrossimagthe: You can override/append it whereever you wish. using "IMAGE_FSTYPES_append =" or "IMAGE_FSTYPES +="08:50
nrossimagthe: normally its in the distro.conf or machine.conf, but you can also override it from your local.conf08:51
*** bluelightning <bluelightning!~paul@188.29.67.238.threembb.co.uk> has joined #yocto08:52
*** bluelightning <bluelightning!~paul@188.29.67.238.threembb.co.uk> has quit IRC08:52
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:52
nrossimagthe: Also poky-tiny should probably be setting it using a lazy set "?="08:53
magthenrossi: I did put it in my machine.conf first, but that was overwritten by the poky-tiny.conf (at least according to bitbake -e)08:53
magthenrossi: ah, yes... that would make more sense indeed08:53
magthenrossi: currently I'm overriding the strictness in poky-tiny.conf by using a derived distro of my own08:54
nrossimagthe: have you tried an immediate variable set? "IMAGE_FSTYPES := ..." cant remember if that will resolve poky-tiny being strict08:56
magthenrossi: no... I'll try it right away08:56
nrossimagthe: alternatively you can always just make it override specific. e.g. "IMAGE_FSTYPES_machinename = ..."08:58
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto08:58
*** kergoth <kergoth!~kergoth@covenant.kergoth.com> has quit IRC09:00
magthenrossi: nope, immediate set won't override it... I'll try the specific override instead to see what happens09:00
*** kergoth <kergoth!~kergoth@covenant.kergoth.com> has joined #yocto09:01
*** swex_ <swex_!~swex@88.210.24.25> has joined #yocto09:02
*** swex <swex!~swex@217.197.253.123> has quit IRC09:03
magthenrossi: yes, a specific override works fine... that's nicer than introducing a dummy distro09:04
nrossimagthe: if you want to be tricking you can make the override for the distro "_poky-tiny" i think the distro name gets populated into the "OVERRIDES" variable09:05
ant_workafaik we stil lhave the _local override09:05
RPvicky: DEBUG_FLAGS = "" (or in local.conf DEBUG_FLAGS_pn-<foo> = "")09:09
ant_workmagthe: and for cpio's and stuff (initramfs) maybe you should use that in your image:  IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"09:09
ant_workRP: hi there09:11
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto09:26
RPhi ant_work09:27
ant_workRP: I'm very dubious about the klcc-cross recipe. It works but I'm sure it is machine-specific as it is because its prefix relates to target_sysroot :/09:31
RPant_work: cross recipes are usually tune specific09:35
RPant_work: does it end up in the TUNE_PKGARCH workdir?09:35
RPant_work: biggest issue is the one I mentioned, the need for a relative symlink09:35
ant_workRP: the point to build against libc-headers insted of kernel was to have arch-specific09:35
RPant_work: did you fix that?09:35
ant_workyes but there are hardcodes in the klcc.cross script09:36
RPant_work: aren't they relocated by the sstate code?09:36
ant_workwhat's scary, tools are referring to ii686 and the libs to qemuarm sysroot09:36
RPhmm, that sound odd09:37
ant_workRP: it's surely my bad ;)09:37
RPant_work: I really don't know it well enough to comment :(09:37
ant_workif youhave 2 mins I'll fwd an e-mail I sent to Khem09:37
RPant_work: the fact it is installing binaries into i686 makes sense, all cross recipes do that so don't worry09:41
RPant_work: Equally, paths in scripts should be found and relocate automagically by the sstate code09:41
*** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC09:41
RPant_work: To test, build something with klcc on machine A, then switch to a different machine, "Bitbake klcc-cross" there and see if klcc works in its new location09:42
RPI guess a full test would be MACHINE=A bitbake klcc-cross; <test> ; MACHINE=A bitbake klcc-cross -c clean; repeat for MACHINE=B09:43
*** uvan <uvan!~uvan@118.69.219.197> has quit IRC09:43
magtheant_work: thanks for the tip... that does make more sense09:46
*** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has joined #yocto09:46
*** magthe <magthe!~magnus@193.15.95.2> has quit IRC09:48
ant_workRP: I'm afk here but I did the test, even for machine of the same arch. klibc is not rebuilt, klcc is09:52
ant_workRP: and the klcc-cross in sstate-cache does contains the hardcodes (it's a perl script, I just inspect it)09:53
RPant_work: hmm, that doesn't sound so good then09:54
ant_workRP: what I then did was to verify with readelf the produced klcc-shared binaries and these were ok09:56
ant_workRP: linking to exec_prefix/lib/klibc on target09:57
ant_workRP: I feel I'm in the 'preverted' kind of setups blamed here ;)10:01
ant_workhttp://www.zytor.com/pipermail/klibc/2013-August/003463.html10:02
RPant_work: so its at least partially working ok10:02
*** Anusko_ <Anusko_!~anusko@62.159.77.165> has joined #yocto10:02
ant_workRP: yep, no autobuilder failures10:02
ant_workRP: and good binaries10:02
ant_work..but it is machine-specific as it is :/10:02
ant_workI feel there must be a way to use a single copy of the linux-libc-headers10:03
*** _alex_kag <_alex_kag!~alex_kag@178.124.23.158> has joined #yocto10:03
*** _alex_kag_ <_alex_kag_!~alex_kag@178.124.29.38> has quit IRC10:03
RPant_work: I told you how to do that, you need to use a relative symlink10:03
ant_workis done10:04
*** Anusko <Anusko!~anusko@62.159.77.165> has quit IRC10:04
ant_workbut is relative to target sysroot10:04
*** eren <eren!~eren@unaffiliated/eren> has quit IRC10:04
RPant_work: that doesn't make sense10:05
ant_workhttp://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/klibc/klibc-2.0.2/klibc-linux-libc-dev.patch10:05
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto10:05
SaurDoes anyone know about a problem with , e.g., ${DATETIME} having different values depending on whether a task is running fakerooted or not?10:05
RPant_work: so that will work both at build time and on the target. What is the problem?10:06
RPant_work: there is only one copy of linux-libc-headers?10:06
ant_workthe problem are the vars in klcc-cross10:06
ant_workRP: one each sysroot10:07
RPant_work: ok, what do those look like?10:07
ant_work ... /qemuarm/...10:08
SaurThe problem we experienced what that a task that we added (do_kimage) which uses the rootfs image ouput from the do_rootfs failed because it couldn't find the image. This was due to do_rootfs being fakerooted and do_kimage not being it.10:08
*** Daemon404 <Daemon404!~who_knows@host86-145-130-143.range86-145.btcentralplus.com> has quit IRC10:08
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto10:08
RPSaur: I can guess that is due to the bitbake-worker changes10:08
ant_workRP. the variable controlling those is INSTALLDIR10:08
RPSaur: the fakeroot env will have a different time to the non-fakeroot one :/10:08
RPant_work: so can't you make these relative too?10:09
SaurRP: I assumed something like that. It seems a bit troublesome though that variables have different values like that...10:09
SaurThe workaround in this casewas easy by making do_kimage fakerooted as well, but it seems wrong somehow...10:09
*** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has joined #yocto10:09
RPSaur: The only answer I can think of offhand is to special case DATETIME in bitbake...10:10
RPSaur: a bit like http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=e63c5775732055a32b417c01fb68711f33ff4ac310:11
SaurRP: ${DATE} and ${TIME} I guess is more appropriate, but yes10:11
RPSaur: right10:11
SaurRP: Sounds about right10:11
RPSaur: I'll take a patch...10:12
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto10:12
SaurRP: I'll see if I can figure it out. ;)10:12
lpappJaMa: hi, where should uthash go inside meta-oe, which recipe group?10:12
JaMalpapp: what depends on it? looks like something for -support or -extended10:14
SaurRP: Hmm, seems ${DATE} and ${TIME} get their values from time.gmtime() in bitbake.conf today. How would that need to change for this to work for the new worker setup?10:15
RPSaur: I'd just read the value of them from the cooker configuration and pass that into the workers10:15
RPSaur: i.e. just do what BUILDNAME does10:16
SaurRP: Ok, sounds simple enough. Will try that...10:16
JaMaRP: FYI: that pseudo/procps issue looks like race-condition in runstrip calls10:16
RPJaMa: oh, interesting. I'm not sure how that happens but it sounds possible10:18
lpappJaMa: our software. :-)10:19
lpappJaMa: IMO, linked list and hash with C macros are pretty useless... but people use it for some reason.10:20
JaMaRP: hopefully I'll know more after next rebuild is finished10:23
lpappJaMa: I will push it to recipes-support, then.10:23
JaMalpapp: ok10:24
lpappJaMa: thanks.10:24
vickyI m really struggling with this dbg package.10:28
vickyHere is my story10:29
vickyi dont need the dbg package of my custom qt application10:29
vickyhow to avoid the dbg package of the qt app in bb file?10:29
lpappvicky: have you checked the class?10:30
lpappand how FILES works?10:30
vickyyes10:31
RPvicky: did you try DEBUG_FLAGS ?10:31
RPvicky: the -dbg package will still be there but should become near empty10:31
lpappPACKAGES = "${PN}-staticdev ${PN}-dev ${PN}-dbg ${PN}-doc ${PN}"10:31
lpappyou should probably modify that variable.10:31
lpappbut what is your use case, anyway?10:32
vickyi will post the bb file10:32
lpappwhy?10:33
vickyI already tried with PACKAGES = "${PN}-staticdev ${PN}-dev ${PN}-dbg ${PN}-doc ${PN}"10:35
vickybut it says " rdepends on dbg"10:36
lpappwhy don't you start with what you tried?10:38
lpappwhat else have you tried?10:38
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has quit IRC10:54
*** zeddii <zeddii!~ddez@128.224.252.2> has quit IRC10:54
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto10:56
*** drasko <drasko!~drasko@11-96-190-109.dsl.ovh.fr> has joined #yocto10:59
draskohi all. I have put a number of recipes in the dir recipes-test in my meta-test dir. How can I now force all these recipes to be compiled?10:59
draskoFor example, I have iperf in meta-test/recipes-test, nad I can see it compiling when I say : bitbake iperf.11:00
draskoBut I have other tools in the same recipes dir, and I want to compile them all in one go11:01
draskoHow to achieve that?11:01
RPvicky: Did you try DEBUG_FLAGS?11:01
rburtondrasko: you can make a meta-recipe that depends on all the other recipes11:01
draskoso, there is no an instruction to bitbake to compile all from one dir?11:02
draskolike bitbake recipes-test/*11:02
lpappdrasko: you can be using -b11:03
lpappbut you still need to supply recipes rather than folders, though, so you need to align your pattern.11:04
rburtonthe caveat there is that -b ignores dependencies11:04
draskolpapp, normally I have a metarecipe11:04
lpappdrasko: bitbake metarecipe then.11:05
draskoBBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb11:05
draskoI have thios in my layer.conf11:05
draskoI thought abot this11:05
draskoand normally it compiles all other recipe-* folders in this meta layer11:05
draskoexcept the one I just added11:05
draskomaybe somethig has to be forced for recompilation?11:05
draskoOr I have to do clean of the project?11:06
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has joined #yocto11:06
rburtonif there's no need to rebuild, it won't rebuild11:06
lpappdrasko: you could write a python script for doing this with os.walk, pretty quickly.11:06
*** zeddii <zeddii!~ddez@128.224.252.2> has joined #yocto11:07
draskoWhat I do not understand is how it does all other recipe-* dirs11:07
draskoand this one that I just added stays untouched11:07
draskoeven when in layer.conf of this layer11:07
draskoI have BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb11:07
draskoAny ideas why this folder is avoided? I think that it is because it is last added, and noclean was done...11:09
*** dany <dany!~Thunderbi@sestofw01.enea.se> has quit IRC11:09
rburtonif you've already built them, then asking them to be rebuilt won't do anything.  is that what's happening?11:09
rburtonyou can prove that by picking one that it's not building, do bitbake [the package] -ccleansstate, and trying again11:09
draskorburton, they were neve built11:09
rburtonhow are you depending on them in your meta-package?11:10
draskothey have been added to meta layer after the project has been completely built11:10
rburtonBBFILES just controls what files bitbake parses11:10
draskorburton, where to find this?11:11
*** dany <dany!~Thunderbi@79.102.201.106> has joined #yocto11:11
rburtondrasko: i suspect your meta-recipe needs updating11:12
draskorburton, probably... How to do this?11:13
*** e8johan <e8johan!~quassel@194-237-7-146.customer.telia.com> has quit IRC11:14
rburtonwell if you have a meta-recipe that builds everything, you need to add more dependencies to it11:14
draskoNo I do not have metarecipe11:14
draskoI have only lines in layer.conf11:14
draskothat build every other recipe-* folders11:14
rburtonno it doesn't11:14
draskoexcept the one I just added11:14
rburtonwhat do you ask bitbake to build?11:15
draskorburton, you mean - packages that are build from these folders are defined elsewhere?11:15
rburtonno, i mean when you ask bitbake to build something, it will build just what it needs11:15
rburtonunless you do bitbake world, which will build *everything*11:15
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC11:16
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto11:18
draskorburton, could it be that the list of packages is given in IMAGE_INSTALL and only these are compiled? Since non of packages from the dir meta-test I added to the layer is not in the IMAGE_INSTALL variable, none of them is compiled. Is this correct?11:20
rburtondrasko: yes11:20
rburtonif your asking it to build an image it will compile everyhting needed to build that image11:20
rburtonit won't build stuff that isn't required11:20
*** e8johan <e8johan!~quassel@194-237-7-146.customer.telia.com> has joined #yocto11:26
*** SidH_ <SidH_!~SidH_@61.95.193.238> has quit IRC11:37
Guest49245Hi11:40
Guest49245What is the best way to do this? I need to sign the linux uImage and dtb files and uboot files..11:41
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has joined #yocto11:42
Guest49245bluelightning : do you have any ideas11:42
Guest49245can it be done by creating a class that addsa function to the image?11:43
Guest49245rburton : do you have any idea on this?11:47
bluelightningGuest49245: not my area of expertise I'm afraid, but someone else here should be able to help with that11:47
Guest49245bluelightning : ok np11:48
Guest49245bluelightning : do you have any suggestions whom would know..?11:49
StygiaGuest42914, Do you mean signing the image so it would be accepted by a "HAB" system or something?11:49
Guest42914Stygia : I don't know what HAB system is. Basically certain files e.g. uImage, *.dtb . uboot files need to be signed . So I have a exe that run over them and create new file with new extension11:54
Guest42914I am wondering what is best approach to do this11:55
RPGuest42914: A class adding a function or appending to an existing function would seem like a good way to start11:55
RPthere are varios POSTPROCESS type variables11:56
*** volker <volker!~quassel@host-80-81-19-29.customer.m-online.net> has quit IRC11:56
StygiaHAB = Highly Assured Boot.11:57
StygiaGuest42914, Signed by PGP, then?11:57
Guest42914Stygia : its not pgp but something similar I guess11:58
StygiaGuest42914, Well if you have the program locally, and you know which files to sign, do something like do_install_append and then manually sign the files there?11:59
Guest42914RP: Atm I have a class which adds a function . The class is then included to the uboot , linux recipes. and it takes the files in the deploydir and does the operation. dont think that is best way though11:59
RPGuest49245: what is the problem?11:59
Guest42914RP: If I need to sign something executables that are in a recipe then it won't work.12:00
Guest42914RP: I am wondering if I can do it somehow in the image recipe itself.12:01
RPGuest49245: well, you can globally inherit the class (INHERIT += "xxx" from conf) and then do_install_append() of whatever12:01
RPGuest49245: or modify PACKAGEFUNCS12:01
RPGuest49245: lots of options12:01
RPGuest49245: See the various image class hooks. You can modify the image contents12:02
*** e8johan <e8johan!~quassel@194-237-7-146.customer.telia.com> has quit IRC12:02
*** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto12:03
*** RP <RP!~richard@dan.rpsys.net> has quit IRC12:04
Guest42914RP : where does do_install install . Its the variable common to all recipes?12:06
Guest42914RP: and what do you mean by image class hooks?12:06
*** RP <RP!~richard@dan.rpsys.net> has joined #yocto12:08
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has joined #yocto12:10
Guest42914RP: did you get that last question?12:12
*** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has joined #yocto12:13
*** magthe <magthe!~magnus@193.15.95.2> has joined #yocto12:15
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:17
*** zecke <zecke!~ich@p5099b351.dip0.t-ipconnect.de> has quit IRC12:18
*** dany <dany!~Thunderbi@79.102.201.106> has quit IRC12:21
RPGuest42914: I guess not12:21
Guest42914RP : where does do_install install . Its the variable common to all recipes?12:21
Guest42914 RP: and what do you mean by image class hooks?12:21
*** dany <dany!~Thunderbi@sestofw01.enea.se> has joined #yocto12:22
n01guys, with a linux-yocto-custom can I use a SRC_URI on http:// ?12:24
*** bluelightning <bluelightning!~paul@188.29.67.172.threembb.co.uk> has joined #yocto12:26
*** bluelightning <bluelightning!~paul@188.29.67.172.threembb.co.uk> has quit IRC12:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto12:26
RPGuest42914: yes, it is common, to ${D}12:38
RPGuest42914: if you look at image.bbclass and the other classes that get included there are references to things like ROOTFS_POSTPROCESS or something like that and similar12:38
Guest42914alright I take a look. thanks RP12:39
*** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC12:40
ant_workRP: about my doubt inheriting cross in the recipe after one include: the evaluation is postponed isn't?12:41
RPant_work: order does matter with include12:42
RPant_work: but its unlikely to be an issue12:42
ant_workso after the line include I have to expect the vars are mangled for cross. only after that12:43
cfo215kergoth, thanks for you help yesterday, I applied "echo 'TOOLCHAIN_TARGET_TASK_append_pn-meta-toolchain-qte = " console-image"' >>conf/local.conf" and bit baked the image using -c populate_sdk.  Unforunately, it didn't work as expected.  It did not add the Qt specific exports to the generated environment-setup... file12:43
*** magthe <magthe!~magnus@193.15.95.2> has quit IRC12:44
ant_workyou see, the recipe is a split-off of the main one just to install the klcc as crosscompiler and not for compiling on target12:44
cfo215kergoth, no big deal, I'll merge the files together for now.  I just wanted to bring it to your attention so whoever takes care of those things can be notified.12:46
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has quit IRC12:48
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC12:48
ant_workRP: probably I have to verify prefix=${exec_prefix} in the recipe after inheriting cross12:48
ant_workRP: I'd say even better to redeclare it12:49
*** zeeblex <zeeblex!apalalax@nat/intel/x-mtdyixwwvzfqxtnk> has left #yocto12:54
cfo215kergoth, I spoke too soon.  It didn't add the meta-toolchain-qte excecutables (qmake, moc, etc.) to sysroots/x86_64-angstromsdk-linux/usr/bin either.  I think I'll work with my original plan and just merge the directories together.13:16
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC13:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:22
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has joined #yocto13:23
*** kbart <kbart!~KBart@213.197.143.19> has quit IRC13:24
*** mihai <mihai!~mihai@80.97.15.150> has quit IRC13:25
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has quit IRC13:29
draskoHI all, I am comming to the probelm I mentioned : I added the recipe in my meta layer, but it is not seen by bitbake13:29
mbeliskodrasko: did you add your layer to conf/bblayers.conf?13:30
draskoIn my meta layer I have local.conf line like this : BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb13:30
draskolayer is present in conf/bblayers.conf13:31
draskoThe project has been built before13:31
draskothen I added some more recipes13:31
draskonow they are not seen13:31
ndecin which folder did you put it?13:31
draskoI have an impression that clean must be donem but I would like to avoid this13:31
ndecrecipe parsing should not have anything to do with13:32
ndeccleaning13:32
draskondec, yocto/meta-test13:32
ndechow do you know it is not parsed?13:32
draskothe packets are not being built13:32
*** Krz <Krz!c0c6972b@gateway/web/freenode/ip.192.198.151.43> has joined #yocto13:33
ndecthat's different ;-)13:33
draskobitbake cpuburn -v13:33
draskoERROR: Nothing PROVIDES 'cpuburn'13:33
ndecok13:33
KrzHi guys, I'm using dylan-9.0.1, uclibc. Have no idea, why it produces sth like that under work/: 0.9.33+gitAUTOINC+946799cd0ce0c6c803c9cb173a84f4d607bde350-r8.413:33
ndecwhat the full path of your recipe?13:33
Krzshouldn't this just be 'uclibc-versionABC' ? instead of git SHA?13:34
draskoyocto/meta-test/recipes-benchmark/cpuburn/13:34
ndecKrz:  if the recipe uses git, no13:34
ndecdo you see meta-test when you run bitbake-layers show-layers13:35
draskondec, yes13:35
draskoI do see it13:36
ndechmm. any chance you can share the content of the .bb file?13:37
draskoTrying to give .bb file directly to bitbake -b gives : ERROR: Nothing PROVIDES ...13:37
Krzndec: doesnn't AUTOINC mean the latest and greatest commit?13:37
draskoit is actually this folder : https://github.com/dirtybit/gumstix-yocto/tree/master/meta-openembedded/meta-oe/recipes-benchmark13:38
draskoI took it whole and I put it in my meta-test layer13:38
draskoso I want to build all these benchmarking tools and include them in my image13:38
ndecdrasko: you build for which host?13:39
draskoARM13:39
ndecwhat does COMPATIBLE_HOST mean, actually?13:40
draskoI have no idea13:40
draskoanyway, other packages do not have this13:40
draskobut still they do not build13:40
Stygiandec, I don't know, as such, but it looks like it would indicate which HOST's are compatible with the recipe/13:40
Stygia?13:40
StygiaIf the naming is name I'd say that answer was obvious. But it might not be.13:41
Stygia*is sane13:41
*** Anusko_ <Anusko_!~anusko@62.159.77.165> has quit IRC13:41
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has quit IRC13:41
ndecyeah, i was wondering that.13:41
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has joined #yocto13:41
*** Anusko_ <Anusko_!~anusko@62.159.77.165> has joined #yocto13:41
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has quit IRC13:42
StygiaDon't take my word for it, though, I don't actually know. :)13:43
draskondec, my excuse, looks like other tools do build13:43
StygiaJust seemed like a qualified guess.13:43
draskoThen it must be this COMPATIBLE_HOST13:43
ndecdrasko: try removing the COMPATIBLE_HOST? honestly, i don't quite undestand what it does.13:43
Stygiahttps://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html13:43
*** B4gder <B4gder!~daniel@sestofw01.enea.se> has quit IRC13:43
ndeci read that. but still i don't understand ;-)13:43
StygiaSearch "COMPATIBLE_HOST"13:43
StygiaAh, heh.13:43
StygiaThen, I'm right, how about that? :)13:43
StygiaThat's how I read the explaination anyway.13:43
StygiaSeems like a whitelist of known hosts supported by the recipe.13:44
StygiaYup.13:44
StygiaUnless I truly suck at English that's exactly what COMPATIBLE_HOST is -> A list of hosts with which the recipe is compatible13:44
ndecthe part i don't get is " one or more targets (when the recipe is non-native)"13:45
ndeci guess the recipe is non-native in drasko case.13:45
StygiaThat means AFAIK that the RE matches one or more possible architectures the recipe can be compiled on when it is not being cross-complied.13:46
Stygia*compiled13:46
StygiaMake sense?13:46
*** vicky <vicky!~vicky@122.165.223.135> has quit IRC13:47
ndecKrz: no, AUTOINC, means that you used SRCREV with a commit.13:48
ndeclooking at dylan, looks like you are using uclibc_git.bb, which has a DEFAULT_PREFERENCE='-1'. so something must be changing it.13:48
ndecthat you used SRVREV in PV, i meant.13:49
*** Krz <Krz!c0c6972b@gateway/web/freenode/ip.192.198.151.43> has quit IRC13:57
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has joined #yocto13:58
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC14:02
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has quit IRC14:02
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto14:02
*** _alex_kag <_alex_kag!~alex_kag@178.124.23.158> has quit IRC14:07
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto14:09
*** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto14:13
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto14:15
rburtonkhem: do you have a good reason to install the systemd rpm macros?14:21
rburtonotherwise i'll delete them whilst i'm working on that recipe14:21
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has joined #yocto14:22
*** gjohnson <gjohnson!4542f923@gateway/web/freenode/ip.69.66.249.35> has joined #yocto14:26
*** mbelisko <mbelisko!~mbelisko@81.89.61.168.vnet.sk> has quit IRC14:26
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC14:29
gjohnsonThe following line shows up in a bb file and I don't understand how to interpret it PACKAGECONFIG[gles2] = "-opengl es2 -eglfs,,virtual/libgles2 virtual/egl"14:30
rburtongjohnson: see PACKAGECONFIG under http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-P14:31
gjohnsonrburton: Thanks for the link, I figured that is what was happening.  How do I enable the virtual/libgles2 and virtual/egl features?  Should these features be enabled based on other packages I have added to my image?14:34
rburtonthose are virtual packages which should be provided by your GL library14:35
rburtonmesa is the default14:35
gjohnsonrburton: so I am using the imx6 and the gpu library has PROVIDES += "virtual/wayland-egl virtual/libgl virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2" but for some reason that PACKAGECONFIG[gles2] is not being set.14:37
rburtonyou'll need to ensure that gles2 is in the main PACKAGECONFIG= statement14:37
ndecyou might need to do PACKAGECONFIG_<recipe> += "gles2", i suspect.14:37
ndecor even PACKAGECONFIG-pn_<recipe>14:39
gjohnsonAh, ok I think I understand.  So if my recipe is qtbase I should set PACKAGECONFIG_qtbase += "gles2"?  Also where is the best place to put that?14:40
ndecor you could have a .bbappend file for qtbase and add PACKAGECONFIG += 'gles2'14:41
ndeci did it with a .bbappend for qt5 , for our layers.14:42
ndecif not in a .bbappend, i think the right syntax would be PACKAGECONFIG_pn-qtbase14:42
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has quit IRC14:43
gjohnsonndec: That sounds like a good plan for me too then.  I created my own layer for my company so it should be easy to add the bbappend.  Just so I understand where would the PACKAGECONFIG_pn-qtbase assignment go?  Also what does the pn stand for?14:43
ndecpn for package name14:44
ndeci believe the best place for PACKAGECONFIG_pn-qtbase would be in a distro or machine .conf file14:44
ndecit cannot be in a .bb file in fact, as it's used in qtbase recipe.14:44
ndecso, either .conf with pn_qtbase, or without <pn>  and in qtbase_xxx.bbappend14:45
gjohnsonndec: so the _pn part indicates that the following text is the package name?14:45
ndecyes14:45
*** flyn378 <flyn378!80db310e@gateway/web/freenode/ip.128.219.49.14> has joined #yocto14:46
gjohnsonndec: Another question since you are also using the qt5 layer, my opengl libraries aren't being installed before qtbase is built. did you see this same issue?14:47
ndecisn't that becase you were missing this PACKAGECONFIG?14:47
ndecthat line14:48
ndecPACKAGECONFIG[gles2] = "-opengl es2 -eglfs,,virtual/libgles2 virtual/egl"14:48
gjohnsonprobably, I will try getting that set and see if it solves my issue.  Thank you for the help.14:48
ndecwill do 2 things: 1) add -opengl es2 -eglfs to the configure options.14:48
ndec2) add virtual/libgles2 virtual/egl to DEPENDS14:48
gjohnsonok, that will for sure fix my issue then14:48
ndecyou should check the documentation for PACKAGECONFIG, this is there.14:48
ndecyou can even do something when it's not defined (the flag). that's that the 2nd argument is for (empty in this example)14:49
ndecbut for example, here14:49
ndecPACKAGECONFIG[tslib] = "-tslib,-no-tslib,tslib"14:49
gjohnsonthanks, I did but I think I read it backwards.  I thought you need to have the depends then it will add the configure option14:50
ndecyou see that it would set -no-tslib to configure when NOT set.14:50
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC14:50
gjohnsonyeah, that makes sense to me now.  Thanks again for the explanation.14:50
*** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto14:58
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto14:59
*** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has quit IRC15:07
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has quit IRC15:17
*** Anusko_ <Anusko_!~anusko@62.159.77.165> has quit IRC15:22
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:23
*** Anusko_ <Anusko_!~anusko@62.159.77.165> has joined #yocto15:23
*** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC15:36
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC15:38
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has quit IRC15:40
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC15:42
*** davest <davest!Adium@nat/intel/x-gfuwtwsizjhnqdht> has joined #yocto15:45
*** _alex_kag <_alex_kag!~alex_kag@93.84.109.218> has joined #yocto15:51
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has joined #yocto15:53
*** dv_ <dv_!~quassel@chello080108009040.14.11.vie.surfer.at> has quit IRC15:58
*** mckoan is now known as mckoan|away15:58
*** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has joined #yocto16:14
*** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has quit IRC16:23
*** zz_ka6sox is now known as ka6sox16:25
*** n01 <n01!~n01@host225-0-static.96-5-b.business.telecomitalia.it> has quit IRC16:26
*** acidfu <acidfu!~nib@24.37.17.210> has joined #yocto16:28
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto16:28
*** flyn378 <flyn378!80db310e@gateway/web/freenode/ip.128.219.49.14> has quit IRC16:30
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:35
*** Krz <Krz!c0c69725@gateway/web/freenode/ip.192.198.151.37> has joined #yocto16:40
Krzafter doing bitbake <myimage> -c populate_sdk I have .sh script - toolchain16:41
Krzhow can I obtain the tarball which is inside?16:41
KrzI think there is some recipe creating this .sh script from tarball (I need this tarball)16:41
sgw_krz, why don't you want to use the script, since the script handles installing it correctly and deals with some path relocation?16:43
*** belen <belen!Adium@nat/intel/x-hdytnuliaucrbevz> has quit IRC16:43
Krzsgw_: are you telling me, that tarball will not be usefull at all without relocation?16:44
sgw_Krz: yes16:44
sgw_Krz: I don't remember everything the script does, it's possible that tarball *might* work if installed in the /opt/poky dir (assuming your doing a poky distro build), but I won't guarantee it.16:46
Krzsgw_: why do we need path relocations? what for exactly?16:47
Krzsgw_: basically my background is - we have a zip with IDE inside and xCompiler toolchain will be part of that. So far there is no installation process involved. That's why I need just a tarball16:48
*** sameo <sameo!~samuel@192.55.54.41> has quit IRC16:49
mr_sciencewow, i really thought that was going to need some kind of hairy-ass autotools patch...16:49
* mr_science thanks the GNU devs for providing useful configure options16:49
sgw_Krz: there are a number of things the script does to setup the environment correctly and tweak binaries to have the right dynamic library patch, you can see the python script in scripts/relocate_sdk.py16:52
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has quit IRC16:52
sgw_Krz: this allows it to be installed as non-root user16:52
Krzsgw_: but at the end of the day xCompiler is just bunch of binaries. I should be able to just untar them and using proper flags (e.g. gcc sysroot=/abc/def). That's my understanding of xCompiler16:53
Krzsgw_: will take a look at relocate_sdk.py16:53
kergothheh, we should really start a project to improve path relocatability of software in general so we can stop having to do such hacks16:55
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has joined #yocto17:00
* mr_science wonders where's the meta-ribs layer to go with meta-chicken...17:02
*** dvhart <dvhart!~dvhart@static-50-53-95-223.bvtn.or.frontiernet.net> has joined #yocto17:05
JaMamr_science: :)17:05
*** eren <eren!~eren@unaffiliated/eren> has quit IRC17:06
mr_sciencefinally found the layer index17:07
RPKrz: see the trick I played in meta-mingw17:07
RPKrz: SDK_PACKAGING_FUNC = "do_compile" from http://git.yoctoproject.org/cgit.cgi/meta-mingw/tree/conf/machine-sdk/x86_64-mingw32.conf17:08
RPReading that back, I really should have better documented why/how that works :/17:08
RPKrz: if you just want binaries you can untar, you might need to stop using our own dynamic linker and libc17:09
mr_sciencekergoth: i'm looking at your external-sourcery-toolchain.bb recipe17:10
KrzRP: poky already creates tarball in the meantime and later removes that, am I right?17:11
RPKrz: instead you'd need to build them against the lowest common denominator you want them to run on, a bit like the osx sysroot17:11
mr_scienceif i set CSL_VER_MAIN to the old version we're using for classic builds, i should be able to build a hardfloat version?17:11
RPKrz: right, and that variable stops the tarball being turned into the script17:11
KrzRP: will try that for Linux17:11
RPKrz: well, see above, I can tell you right now you will have the problem I mention17:12
KrzRP: what do you mean by 'the lowest common denominator' ?17:12
RPKrz: sysroot needs to have the oldest libc and dynamic loader you want to support17:13
RPa binary linked against libc X may not work with libc X-117:13
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has joined #yocto17:13
KrzRP: right, I get your point now17:14
RPKrz: this is why we ship our own loader and libc, then we truly can run on near enough anything17:15
RPKrz: the cost is having to run the script at unpack time17:15
RPthere is no way to do the dynamic loader path dynamically17:16
KrzRP: where do I find/change libc version for sysroot?17:16
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has quit IRC17:16
RPKrz: you'd have to provide a sysroot of the thing you want to compile against17:16
RPKrz: there isn't a simple way to do this, you're trying to do something the system isn't setup to do atm17:17
*** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has quit IRC17:17
*** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has joined #yocto17:19
*** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has left #yocto17:19
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has joined #yocto17:20
kergothmr_science: it extracts the versions from the toolchain, it doesn't build one, or use that as input for anything17:21
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has quit IRC17:23
*** francois99 <francois99!~francois9@78-33-60-6.static.enta.net> has quit IRC17:26
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC17:28
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto17:29
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto17:29
*** Krz <Krz!c0c69725@gateway/web/freenode/ip.192.198.151.37> has quit IRC17:31
-YoctoAutoBuilder- build #124 of minnow-lsb is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/minnow-lsb/builds/12417:36
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has joined #yocto17:37
cfo215Is there any reason my binaries generated by meta-toolchain-qte have '/usr/local/oecore-x86_64' harcoded in them?  http://pastebin.com/jYxFuT3m  I'm wondering if that's not part of my Qt in Netbeans problem.  I didn't install the toolkit to the default location:17:39
cfo215...which is /usr/local/oecore-x86_6417:40
cfo215I have mine installed in ~/opt/angstrom-qte.17:40
Crofton|workuse the defaults Luke :)17:45
Crofton|workbbl17:45
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC17:48
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto17:51
*** amarsman <amarsman!~marsman@52489B71.cm-4-1c.dynamic.ziggo.nl> has joined #yocto17:53
cfo215Crofton|work, sure, I'll go with that.17:55
Crofton|workworth a try17:55
Crofton|workI thought the toolchains were supposed to be relocatable17:55
*** dv_ <dv_!~quassel@chello080108009040.14.11.vie.surfer.at> has joined #yocto17:58
cfo215Crofton|work, Nope.. Still not finding the -I (includes) that should have come from the QMAKESPEC file.  I think the environment variables in the files aren't being parsed properly by Netbeans.  Oh, well, back to the drawing board.18:14
cfo215Crofton|work.  The reason I know this is because if I create a Makefile using qmake from the shell, make is very happy.18:15
cfo215Crofton|work, so ians, same problem as before when I installed into my own folders...18:16
frayok18:19
cfo215looking at my build log in Netbeans, the culprit is ' "/usr/bin/gmake" -f nbproject/Makefile-Debug.mk QMAKE=/usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/qmake SUBPROJECTS= .clean-conf ' which generates the Makefile for the Netbeans project.18:19
cfo215actually that's reading the files... been a long day.  the automagically get created by netbeans.18:21
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC18:22
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:23
-YoctoAutoBuilder- build #281 of nightly-world is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-world/builds/28118:24
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto18:24
*** drasko <drasko!~drasko@11-96-190-109.dsl.ovh.fr> has quit IRC18:28
*** slaine <slaine!~slaine@84.203.137.218> has quit IRC18:38
-YoctoAutoBuilder- build #282 of nightly-multilib is complete: Failure [failed Running Sanity Tests_2 Building Images_4] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-multilib/builds/28218:39
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC18:41
*** Anusko_ <Anusko_!~anusko@62.159.77.165> has quit IRC18:44
*** Anusko_ <Anusko_!~anusko@62.159.77.165> has joined #yocto18:45
*** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has quit IRC18:50
*** alex_kag_ <alex_kag_!~alex_kag@93.84.109.218> has joined #yocto18:54
*** _alex_kag <_alex_kag!~alex_kag@93.84.109.218> has quit IRC18:54
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC18:54
*** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has joined #yocto18:54
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC18:55
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto18:58
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC19:02
*** cfo215 <cfo215!~cfo215@mail.abemblem.com> has quit IRC19:14
*** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has quit IRC19:28
*** smartin__ <smartin__!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto19:31
-YoctoAutoBuilder- build #140 of minnow is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/minnow/builds/14019:32
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC19:32
*** tpepper <tpepper!~tpepper@vato.org> has joined #yocto19:52
*** tpepper <tpepper!~tpepper@vato.org> has left #yocto19:53
seebsA followup on yesterday's experiments: BBFILES and BBPATH both work only with fairly simple variable expansions.19:59
seebsSo if you do something like FOO_mips = "1.2" FOO_i586 = "1.3", you can't use ${FOO} in BBFILES/BBPATH, and it also won't work using hyphens and ${FOO-${TARGET_ARCH}}.20:00
seebsSo I have to either modify recipes to make the right ones show up, or change bblayers.conf to pick up only the version of a particular layer I want, so that'll have to be a configuration-time thing.20:00
*** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC20:10
RPkergoth: I figured out the problem with _remove  btw20:13
RPkergoth: processing unexpanded data :/20:13
kergothheh, oops20:13
RPkergoth: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip76&id=50b4ecbdface9a76ffe260a383009093c702d3b120:16
RPgah, ignore the other bits20:16
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto20:16
RPhttp://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip76&id=28b56920f3f1ac84bf01747522c71515532d8233 is better :)20:17
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has quit IRC20:28
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC20:33
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC20:37
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto20:40
*** davest <davest!Adium@nat/intel/x-gfuwtwsizjhnqdht> has quit IRC20:53
*** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has quit IRC21:05
*** smartin <smartin!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has joined #yocto21:06
*** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto21:06
mr_sciencesomebody needed an extra espresso this afternoon...21:12
khemmr_science: its beer time21:17
-YoctoAutoBuilder- build #293 of nightly-x32 is complete: Failure [failed Building Images Running Sanity Tests Running Sanity Tests_1] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x32/builds/29321:17
mr_sciencekhem: not on the west coast21:20
mr_scienceyet...21:20
khemI am on west coast21:20
khemand its about the time :) TGIF21:20
mranostaydepends on the company :)21:20
mr_sciencetearly shift?21:21
mr_science*early even21:21
khemit starts at 3 so got some time to empty tanks :)21:21
mr_sciencekhem: what organization?21:22
khemJuniper Networks ? looking for a change ? let me know :)21:22
*** zeddii_home <zeddii_home!~zeddii_ho@CPE002369bcfa62-CMbcc810032faf.cpe.net.cable.rogers.com> has joined #yocto21:25
*** smartin <smartin!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has quit IRC21:30
*** ant_home <ant_home!~andrea@87.13.50.37> has joined #yocto21:34
*** davest1 <davest1!~Adium@134.134.137.73> has joined #yocto21:35
mr_sciencenow you're making me want a guinness...21:42
*** darknighte_znc is now known as darknighte21:44
*** davest1 <davest1!~Adium@134.134.137.73> has quit IRC21:46
*** sameo <sameo!~samuel@192.55.54.42> has joined #yocto21:53
mr_scienceuh-huh, now we're cookin' with gas...21:56
mr_sciencegot a buildable sdk target with gnutls321:56
*** davest <davest!~Adium@134.134.137.73> has joined #yocto22:01
*** davest <davest!~Adium@134.134.137.73> has quit IRC22:05
*** davest <davest!Adium@nat/intel/x-fazwgbatnirkftuj> has joined #yocto22:10
*** darknighte__ <darknighte__!~Thunderbi@75.108.35.90> has joined #yocto22:20
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has joined #yocto22:24
*** sameo <sameo!~samuel@192.55.54.42> has quit IRC22:37
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC22:41
*** dvhart <dvhart!~dvhart@static-50-53-95-223.bvtn.or.frontiernet.net> has quit IRC22:42
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto22:42
* mr_science goes to get a face trim...22:44
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC22:44
*** phdeswer_ <phdeswer_!~phdeswer@a88-113-104-180.elisa-laajakaista.fi> has joined #yocto22:52
*** davest <davest!Adium@nat/intel/x-fazwgbatnirkftuj> has quit IRC22:52
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-eojzthpiulnqlaxn> has quit IRC22:59
*** mulhern <mulhern!~mulhern@c-67-186-188-203.hsd1.ma.comcast.net> has quit IRC23:09
*** alex_kag_ <alex_kag_!~alex_kag@93.84.109.218> has quit IRC23:23
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC23:26
*** darknighte__ <darknighte__!~Thunderbi@75.108.35.90> has quit IRC23:32
*** darknighte is now known as darknighte_znc23:37
*** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has quit IRC23:47
-YoctoAutoBuilder- build #282 of nightly-ppc is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-ppc/builds/28223:48
*** davest <davest!~Adium@134.134.139.72> has joined #yocto23:49
*** ant_home <ant_home!~andrea@87.13.50.37> has quit IRC23:53
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC23:54

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!