Friday, 2013-09-06

*** Jefro <Jefro!~jefro@> has joined #yocto00:10
*** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has joined #yocto00:12
*** davest <davest!~Adium@> has quit IRC00:16
*** davest <davest!~Adium@> has joined #yocto00:16
*** Jefro <Jefro!~jefro@> has quit IRC00:19
*** Jefro <Jefro!~jefro@> has joined #yocto00:26
*** davest <davest!~Adium@> has quit IRC00:34
*** davest <davest!~Adium@> has joined #yocto00:35
*** Jefro <Jefro!~jefro@> has quit IRC00:51
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto00:56
*** davest <davest!~Adium@> has quit IRC00:59
*** joeythesaint <joeythesaint!> has joined #yocto01:00
*** davest <davest!~Adium@> has joined #yocto01:08
*** davest <davest!~Adium@> has quit IRC01:19
*** davest <davest!~Adium@> has joined #yocto01:31
-YoctoAutoBuilder- build #280 of nightly-world is complete: Success [build successful] Build details are at
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC02:12
*** Daemon404 <Daemon404!> has joined #yocto02:14
*** davest <davest!~Adium@> has quit IRC02:15
*** davest <davest!~Adium@> has joined #yocto02:35
*** joeythesaint <joeythesaint!> has quit IRC02:46
*** zz_ka6sox is now known as ka6sox02:51
*** davest <davest!~Adium@> has quit IRC02:55
-YoctoAutoBuilder- build #281 of nightly-multilib is complete: Success [build successful] Build details are at
*** uvan <uvan!~uvan@> has joined #yocto03:17
*** uvan <uvan!~uvan@> has left #yocto03:18
*** uvan <uvan!~uvan@> has joined #yocto03:21
*** [simar|school] <[simar|school]!~simar@> has joined #yocto03:24
*** behanw <behanw!~behanw@> has quit IRC03:32
*** ka6sox is now known as zz_ka6sox03:58
*** SidH_ <SidH_!~SidH_@> has joined #yocto04:10
*** andyross <andyross!> has joined #yocto04:25
*** amarsman <amarsman!> has quit IRC04:26
*** andyross <andyross!> has quit IRC04:28
*** zz_ka6sox is now known as ka6sox04:31
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC04:33
*** amarsman <amarsman!> has joined #yocto04:40
*** andyross <andyross!> has joined #yocto04:42
*** Jefro <Jefro!> has joined #yocto04:54
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto04:55
*** ka6sox is now known as zz_ka6sox05:07
*** andyross <andyross!> has quit IRC05:10
*** mbelisko <mbelisko!> has joined #yocto05:13
*** Jefro <Jefro!> has quit IRC05:30
*** [simar|school] <[simar|school]!~simar@> has quit IRC05:43
*** blitz00 <blitz00!~stefans@> has joined #yocto05:45
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto05:45
*** zecke <zecke!> has joined #yocto05:57
*** swex <swex!~swex@> has quit IRC06:00
*** swex <swex!~swex@> has joined #yocto06:01
*** kbart <kbart!~KBart@> has joined #yocto06:05
-YoctoAutoBuilder- build #257 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at
*** pirut <pirut!~Pirut@> has quit IRC06:26
*** pirut <pirut!~Pirut@> has joined #yocto06:29
*** elmi82 <elmi82!> has joined #yocto06:32
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:35
*** Zagor <Zagor!> has joined #yocto06:39
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto06:39
*** mshakeel <mshakeel!~mshakeel@> has quit IRC06:40
*** mshakeel <mshakeel!~mshakeel@> has joined #yocto06:43
*** SidH_ <SidH_!~SidH_@> has quit IRC06:51
*** vicky <vicky!~vicky@> has joined #yocto06:51
*** SidH_ <SidH_!~SidH_@> has joined #yocto06:51
vickyhow to remove debug package creation in bb file?06:52
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06:52
*** eballetbo <eballetbo!> has joined #yocto07:07
*** mike <mike!c2881242@gateway/web/freenode/ip.> has joined #yocto07:08
*** mike is now known as Guest4291407:08
*** panda84kde <panda84kde!> has joined #yocto07:09
*** slaine <slaine!~slaine@> has joined #yocto07:09
*** mihai <mihai!~mihai@> has joined #yocto07:09
*** uvan <uvan!~uvan@> has quit IRC07:10
*** florian_kc <florian_kc!> has joined #yocto07:10
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:10
*** uvan <uvan!~uvan@> has joined #yocto07:10
*** n01 <n01!> 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!> has joined #yocto07:18
*** gaby <gaby!> has quit IRC07:25
*** vicky <vicky!~vicky@> has quit IRC07:27
*** ant_work <ant_work!> has joined #yocto07:27
*** dany <dany!> has quit IRC07:28
*** dany <dany!> has joined #yocto07:30
*** roric <roric!> has quit IRC07:34
*** gaby <gaby!> has joined #yocto07:36
*** vicky <vicky!~vicky@> has joined #yocto07:39
vickyany idea guys?07:40
*** gaby <gaby!> has quit IRC07:40
*** gaby <gaby!> has joined #yocto07:41
*** amarsman <amarsman!> has quit IRC07:43
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC07:44
lpappvicky: check the class how it works.07:45
*** roric <roric!> 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!> has joined #yocto07:52
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto07:52
*** amarsman <amarsman!> has joined #yocto07:54
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC07:57
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto07:57
vickylpapp: Sorry for ask this question? Hw to check the class?07:57
*** sameo <sameo!~samuel@> has joined #yocto07:57
*** amarsman <amarsman!> has quit IRC07:58
lpappvicky: meta/classes08:06
*** Anusko <Anusko!~anusko@> has joined #yocto08:11
*** JimBaxter <JimBaxter!> has joined #yocto08:18
*** magthe <magthe!~magnus@> 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!> has quit IRC08:50
*** kergoth <kergoth!> 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!> has joined #yocto08:52
*** bluelightning <bluelightning!> 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!> 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!> has joined #yocto09:01
*** swex_ <swex_!~swex@> has joined #yocto09:02
*** swex <swex!~swex@> 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!> 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@> has quit IRC09:43
magtheant_work: thanks for the tip... that does make more sense09:46
*** melonipoika <melonipoika!> has joined #yocto09:46
*** magthe <magthe!~magnus@> 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
RPant_work: so its at least partially working ok10:02
*** Anusko_ <Anusko_!~anusko@> 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@> has joined #yocto10:03
*** _alex_kag_ <_alex_kag_!~alex_kag@> 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@> 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
*** 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!> 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!> 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
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
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
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@> has quit IRC10:54
*** behanw <behanw!> has joined #yocto10:56
*** drasko <drasko!> 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@> 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!> 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@> has joined #yocto11:11
rburtondrasko: i suspect your meta-recipe needs updating11:12
draskorburton, probably... How to do this?11:13
*** e8johan <e8johan!> 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@> 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!> has joined #yocto11:26
*** SidH_ <SidH_!~SidH_@> has quit IRC11:37
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!> 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!> 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!> has quit IRC12:02
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto12:03
*** RP <RP!> 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!> has joined #yocto12:08
*** cfo215 <cfo215!> has joined #yocto12:10
Guest42914RP: did you get that last question?12:12
*** amarsman <amarsman!> has joined #yocto12:13
*** magthe <magthe!~magnus@> has joined #yocto12:15
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:17
*** zecke <zecke!> has quit IRC12:18
*** dany <dany!~Thunderbi@> 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!> has joined #yocto12:22
n01guys, with a linux-yocto-custom can I use a SRC_URI on http:// ?12:24
*** bluelightning <bluelightning!> has joined #yocto12:26
*** bluelightning <bluelightning!> 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!> 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@> 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!> 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!> has quit IRC13:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:22
*** mulhern <mulhern!> has joined #yocto13:23
*** kbart <kbart!~KBart@> has quit IRC13:24
*** mihai <mihai!~mihai@> has quit IRC13:25
*** roric <roric!> 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
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.> has joined #yocto13:33
ndecthat's different ;-)13:33
draskobitbake cpuburn -v13:33
draskoERROR: Nothing PROVIDES 'cpuburn'13: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
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 :
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
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
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@> has quit IRC13:41
*** cfo215 <cfo215!> has quit IRC13:41
ndecyeah, i was wondering that.13:41
*** cfo215 <cfo215!> has joined #yocto13:41
*** Anusko_ <Anusko_!~anusko@> has joined #yocto13:41
*** cfo215 <cfo215!> 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
*** B4gder <B4gder!> 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
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
StygiaMake sense?13:46
*** vicky <vicky!~vicky@> 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, 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.> has quit IRC13:57
*** cfo215 <cfo215!> has joined #yocto13:58
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC14:02
*** mulhern <mulhern!> has quit IRC14:02
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto14:02
*** _alex_kag <_alex_kag!~alex_kag@> has quit IRC14:07
*** zecke <zecke!> has joined #yocto14:09
*** Net147 <Net147!> has joined #yocto14:13
*** munch <munch!> 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!> has joined #yocto14:22
*** gjohnson <gjohnson!4542f923@gateway/web/freenode/ip.> has joined #yocto14:26
*** mbelisko <mbelisko!> has quit IRC14:26
*** elmi82 <elmi82!> 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
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
*** flyn378 <flyn378!80db310e@gateway/web/freenode/ip.> 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!> has joined #yocto14:58
*** andyross <andyross!> has joined #yocto14:59
*** amarsman <amarsman!> has quit IRC15:07
*** cfo215 <cfo215!> has quit IRC15:17
*** Anusko_ <Anusko_!~anusko@> has quit IRC15:22
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:23
*** Anusko_ <Anusko_!~anusko@> has joined #yocto15:23
*** Net147 <Net147!> has quit IRC15:36
*** panda84kde <panda84kde!> has quit IRC15:38
*** mulhern <mulhern!> has quit IRC15:40
*** ant_work <ant_work!> has quit IRC15:42
*** davest <davest!Adium@nat/intel/x-gfuwtwsizjhnqdht> has joined #yocto15:45
*** _alex_kag <_alex_kag!~alex_kag@> has joined #yocto15:51
*** mulhern <mulhern!> has joined #yocto15:53
*** dv_ <dv_!> has quit IRC15:58
*** mckoan is now known as mckoan|away15:58
*** galak <galak!> has joined #yocto16:14
*** Stygia <Stygia!> has quit IRC16:23
*** zz_ka6sox is now known as ka6sox16:25
*** n01 <n01!> has quit IRC16:26
*** acidfu <acidfu!~nib@> has joined #yocto16:28
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto16:28
*** flyn378 <flyn378!80db310e@gateway/web/freenode/ip.> has quit IRC16:30
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:35
*** Krz <Krz!c0c69725@gateway/web/freenode/ip.> 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@> 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!> 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!> has joined #yocto17:00
* mr_science wonders where's the meta-ribs layer to go with meta-chicken...17:02
*** dvhart <dvhart!> 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
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 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!> 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!> 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!> has quit IRC17:17
*** sakoman <sakoman!> has joined #yocto17:19
*** sakoman <sakoman!> has left #yocto17:19
*** mulhern <mulhern!> 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!> has quit IRC17:23
*** francois99 <francois99!> 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.> has quit IRC17:31
-YoctoAutoBuilder- build #124 of minnow-lsb is complete: Failure [failed Building Images] Build details are at
*** cfo215 <cfo215!> has joined #yocto17:37
cfo215Is there any reason my binaries generated by meta-toolchain-qte have '/usr/local/oecore-x86_64' harcoded in them?  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
*** seebs <seebs!> has quit IRC17:48
*** seebs <seebs!> has joined #yocto17:51
*** amarsman <amarsman!> 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_!> 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
cfo215looking at my build log in Netbeans, the culprit is ' "/usr/bin/gmake" -f nbproject/ 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!> 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
*** zecke <zecke!> has joined #yocto18:24
*** drasko <drasko!> has quit IRC18:28
*** slaine <slaine!~slaine@> 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
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC18:41
*** Anusko_ <Anusko_!~anusko@> has quit IRC18:44
*** Anusko_ <Anusko_!~anusko@> has joined #yocto18:45
*** galak <galak!> has quit IRC18:50
*** alex_kag_ <alex_kag_!~alex_kag@> has joined #yocto18:54
*** _alex_kag <_alex_kag!~alex_kag@> has quit IRC18:54
*** JimBaxter <JimBaxter!> has quit IRC18:54
*** smartin_ <smartin_!> has joined #yocto18:54
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC18:55
*** JimBaxter <JimBaxter!> has joined #yocto18:58
*** JimBaxter <JimBaxter!> has quit IRC19:02
*** cfo215 <cfo215!> has quit IRC19:14
*** hollisb <hollisb!> has quit IRC19:28
*** smartin__ <smartin__!> has joined #yocto19:31
-YoctoAutoBuilder- build #140 of minnow is complete: Failure [failed Building Images] Build details are at
*** smartin <smartin!> has quit IRC19:32
*** tpepper <tpepper!> has joined #yocto19:52
*** tpepper <tpepper!> 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@> has quit IRC20:10
RPkergoth: I figured out the problem with _remove  btw20:13
RPkergoth: processing unexpanded data :/20:13
kergothheh, oops20:13
RPgah, ignore the other bits20:16
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto20:16
RP is better :)20:17
*** mulhern <mulhern!> has quit IRC20:28
*** zecke <zecke!> 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_!> has quit IRC21:05
*** smartin <smartin!> has joined #yocto21:06
*** hollisb <hollisb!> 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
mr_sciencekhem: not on the west coast21: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!> has joined #yocto21:25
*** smartin <smartin!> has quit IRC21:30
*** ant_home <ant_home!~andrea@> has joined #yocto21:34
*** davest1 <davest1!~Adium@> 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@> has quit IRC21:46
*** sameo <sameo!~samuel@> 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@> has joined #yocto22:01
*** davest <davest!~Adium@> has quit IRC22:05
*** davest <davest!Adium@nat/intel/x-fazwgbatnirkftuj> has joined #yocto22:10
*** darknighte__ <darknighte__!~Thunderbi@> has joined #yocto22:20
*** mulhern <mulhern!> has joined #yocto22:24
*** sameo <sameo!~samuel@> has quit IRC22:37
*** seebs <seebs!> has quit IRC22:41
*** dvhart <dvhart!> has quit IRC22:42
*** seebs <seebs!> 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_!> 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!> has quit IRC23:09
*** alex_kag_ <alex_kag_!~alex_kag@> has quit IRC23:23
*** andyross <andyross!> has quit IRC23:26
*** darknighte__ <darknighte__!~Thunderbi@> has quit IRC23:32
*** darknighte is now known as darknighte_znc23:37
*** hollisb <hollisb!> has quit IRC23:47
-YoctoAutoBuilder- build #282 of nightly-ppc is complete: Success [build successful] Build details are at
*** davest <davest!~Adium@> has joined #yocto23:49
*** ant_home <ant_home!~andrea@> has quit IRC23:53
*** munch <munch!> has quit IRC23:54

Generated by 2.11.0 by Marius Gedminas - find it at!