Friday, 2013-08-16

*** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has joined #yocto00:00
*** mulhern <mulhern!~mulhern@24.128.153.12> has joined #yocto00:18
*** seebs <seebs!~seebs@174-20-243-249.mpls.qwest.net> has joined #yocto00:21
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:22
*** _julian_ <_julian_!~quassel@x2f15f70.dyn.telefonica.de> has joined #yocto00:32
*** _julian <_julian!~quassel@x2f0a33e.dyn.telefonica.de> has quit IRC00:35
brmRP: Sorry got disconnected ... yes I agree sysroot sounds wrong00:36
*** davest1 <davest1!~Adium@134.134.139.72> has quit IRC00:37
evanpcjosephson: build/tmp/deploy/images, where "build" is your build dir and possibly really is "build"00:37
*** seebs <seebs!~seebs@174-20-243-249.mpls.qwest.net> has quit IRC00:40
brmRP: So the manual says sysroot must point to my root filesystem .. but all I have in the image directory is a brm-image-beaglebone.tar.xz file, so how do I get the tools to break it out somewhere?00:40
*** rtollert <rtollert!~rtollert@client-74-216.natinst.com> has joined #yocto00:42
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC00:47
brmRP: Got it !!! As you say it should have been  ... /sysroots/beaglebone .. conbfures fine now and built binary, Yay .. now all I have to do is get it to talk to my target board.00:47
*** joeythesaint <joeythesaint!~jjm@198-84-238-35.cpe.teksavvy.com> has joined #yocto00:50
*** feydrautha <feydrautha!~user@184.70.21.10> has joined #yocto00:54
*** feydrautha <feydrautha!~user@184.70.21.10> has joined #yocto00:55
*** blloyd_ <blloyd_!~blloyd@mobile-166-137-147-112.mycingular.net> has quit IRC00:58
*** mulhern <mulhern!~mulhern@24.128.153.12> has quit IRC01:16
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto01:19
*** feydrautha <feydrautha!~user@184.70.21.10> has quit IRC01:29
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto01:36
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC01:57
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto02:01
*** silviof2 <silviof2!~silviof@ppp-93-104-181-187.dynamic.mnet-online.de> has joined #yocto02:01
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has quit IRC02:04
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC02:06
brmAnyone know how I use runqemu-extract-sdk with a rootfs.tar.xz file instead of what it expects .... tar.bz2 ?02:07
brmi am asking cause when I run qemu from eclipse it is complaining about where I told it to find the kernel02:16
*** darknighte is now known as darknighte_znc02:20
*** brm <brm!da653619@gateway/web/freenode/ip.218.101.54.25> has quit IRC02:20
*** simar_ <simar_!~simar@128.224.252.2> has joined #yocto02:24
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto02:27
*** simar <simar!~simar@128.224.252.2> has quit IRC02:27
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC02:30
*** zenlinux <zenlinux!~sgarman@c-71-59-178-152.hsd1.wa.comcast.net> has joined #yocto02:47
nerdboybrm: not played with that...03:04
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto03:04
nerdboyeither it just doesn't support xz decompression or there's a setting somewhere for that...03:05
nerdboyi assume it's supposed to make an image and extract the rootfs then boot it?03:06
*** zenlinux <zenlinux!~sgarman@c-71-59-178-152.hsd1.wa.comcast.net> has left #yocto03:23
*** brm <brm!6f45f8a8@gateway/web/freenode/ip.111.69.248.168> has joined #yocto03:33
brmback again: Anyone know how I use runqemu-extract-sdk with a rootfs.tar.xz file instead of what it expects .... tar.bz2 ?03:36
nerdboyproxy must've hiccuped again...03:40
brmhuh?03:51
nerdboydidn't see a part message so i was answering you with useless crap03:51
nerdboydidn't miss anything...03:51
brmso do you have an answer?03:52
nerdboynot really, i was just asking what it was supposed to do03:53
nerdboyas in "make an image and extract the rootfs then boot it?"03:53
brmwell it is mean't to produce a rootfs that you can use with qemu03:54
nerdboythen it would need to make an image file with the rootfs on it03:54
brmI have a roots.tar.xv that is decompressed onto an SD card to use on real hardware, that works fine03:54
brmnow I want to use the rootfs with quemu03:55
brmthe example given shows runquemu-extract-sdk only used with .bz2 images03:56
nerdboythere's a bbclass in the rpi layer that adds sdimg as a build output03:57
brmi am not using a rpi ... beaglebone03:57
nerdboyright, but it should be not-too-difficult to add it to the bb layer03:58
nerdboyjust a thought...03:58
brmI have allready run the rootfs.tar.xz image on the target board, so you are saying I need some other rootfs image?03:58
nerdboyis runquemu-extract-sdk a shell script?03:58
nerdboythe tarball is not an image03:59
nerdboyit's a rootfs tarball03:59
brmsorry, did not bben image,03:59
brmI mean't that the tarball is decompresssed onto the SD card .. I couls just as well decomp that on my PC04:00
*** klinger_ <klinger_!~klinger@e181049127.adsl.alicedsl.de> has quit IRC04:00
nerdboythe rpi bbclass creates the image file and extracts the rootfs for you04:00
nerdboyyou just dd the image to card and expand it to whatever size you need04:01
nerdboyanyway, if runquemu-extract-sdk is a script of some kind, did you look to see if you can pass it any options?04:02
nerdboy*useful options04:02
brmwill do .. cheers04:03
nerdboyor edit it if there's no compression option...04:04
brmwill do ... not on that machine at the moment ... will check it out .. thanks04:05
*** brm <brm!6f45f8a8@gateway/web/freenode/ip.111.69.248.168> has quit IRC04:07
*** klinger_ <klinger_!~klinger@f053234237.adsl.alicedsl.de> has joined #yocto04:16
*** Satrukaan <Satrukaan!~Thunderbi@192-0-149-234.cpe.teksavvy.com> has joined #yocto04:20
*** Satrukaan <Satrukaan!~Thunderbi@192-0-149-234.cpe.teksavvy.com> has quit IRC04:25
*** alex_kag <alex_kag!~alex_kag@178.124.20.132> has joined #yocto04:49
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto05:09
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has quit IRC05:17
*** agust <agust!~agust@p4FC46512.dip0.t-ipconnect.de> has joined #yocto05:23
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has joined #yocto05:28
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC05:35
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto05:48
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC05:50
*** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has joined #yocto06:34
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC06:34
*** smartin <smartin!~smartin@ANantes-655-1-161-176.w90-59.abo.wanadoo.fr> has joined #yocto06:44
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto06:50
*** slaine <slaine!~slaine@84.203.137.218> has joined #yocto07:04
*** Zagor <Zagor!~bjst@sestofw01.enea.se> has joined #yocto07:07
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto07:07
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto07:13
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC07:13
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto07:13
alex_kaghello, is it bug? : mfw_isink requre  libgstfsl-0.10 for work, but only gst-fsl-plugin-dev  and gst-fsl-plugin-dbg contain it...07:15
nerdboyalex_kag: maybe a lib packaging issue?07:24
nerdboydoes it work if you install the -dev package?07:24
alex_kagim waiting building image07:27
nerdboythis describes the packaging guidelines => http://www.embeddedlinux.org.cn/OEManual/recipes_packages.html07:32
nerdboyhopefully it's not too out of date...07:32
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC07:38
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto07:42
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC07:48
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto07:48
*** silviof2 is now known as silviof07:50
*** _alex_kag_ <_alex_kag_!~alex_kag@176.60.171.132> has joined #yocto07:52
*** _alex_kag <_alex_kag!~alex_kag@178.124.20.132> has joined #yocto07:53
*** alex_kag <alex_kag!~alex_kag@178.124.20.132> has quit IRC07:53
*** _alex_kag is now known as alex_kag07:53
*** _alex_kag_ <_alex_kag_!~alex_kag@176.60.171.132> has quit IRC07:58
*** sameo <sameo!~samuel@192.55.54.40> has joined #yocto08:03
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC08:10
-YoctoAutoBuilder- build #218 of nightly is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/21808:10
*** bluelightning <bluelightning!~paul@83.217.123.106> has joined #yocto08:11
*** bluelightning <bluelightning!~paul@83.217.123.106> has quit IRC08:11
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:11
*** gmacario <gmacario!~gmacario@91.80.63.53> has joined #yocto08:15
zecke\08:21
bluelightningmorning zecke, all08:22
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto08:23
zeckehi. :)08:27
*** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has joined #yocto08:29
*** florian_kc is now known as florian08:30
*** honschu <honschu!~honschu@p549E852E.dip0.t-ipconnect.de> has joined #yocto08:30
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto08:30
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC08:33
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto08:40
*** cjosephson <cjosephson!~cjosephso@107-0-144-3-ip-static.hfc.comcastbusiness.net> has quit IRC08:43
*** cjosephson <cjosephson!~cjosephso@207.47.42.180.static.nextweb.net> has joined #yocto08:44
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC08:45
*** Garen <Garen!~garen@69.76.17.207> has quit IRC08:58
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto09:02
*** belen <belen!Adium@nat/intel/x-ooxfbtkerrvwpzqk> has joined #yocto09:12
*** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has quit IRC09:17
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC09:26
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has left #yocto09:32
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC09:33
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto09:39
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC09:46
*** B4gder <B4gder!~daniel@sestofw01.enea.se> has quit IRC09:56
*** belen <belen!Adium@nat/intel/x-ooxfbtkerrvwpzqk> has quit IRC09:59
*** _alex_kag_ <_alex_kag_!~alex_kag@178.124.22.24> has joined #yocto10:02
*** alex_kag <alex_kag!~alex_kag@178.124.20.132> has quit IRC10:02
*** Krz <Krz!c0c69724@gateway/web/freenode/ip.192.198.151.36> has joined #yocto10:04
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto10:04
otavioMorning10:05
*** ka6sox is now known as ka6sox-away10:16
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto10:16
*** belen <belen!~Adium@134.134.139.76> has joined #yocto10:32
*** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has joined #yocto10:38
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto10:41
lpapphi, what is the best of handling BB_NUMBER_THREADS to be the accurate number for each PC including CI?10:42
lpappway*10:42
lpappMAKEFLAGS can be used for PARALLEL_MAKE10:42
lpappas the local.conf is pretty much the same otherwise, we just check that in.10:43
lpappthe only non-portable bit so far is BB_NUMBER_THREADS.10:43
JaMabluelightning: hi, is "classes/terminal: fix pseudo exiting when launching devshell" also needed for master or already in Saul's queue?10:55
ndecJaMa: 'classes/terminal' is a fix for a problem in dylan only.10:58
ndeccf. devshell was broken 2 days ago.10:58
*** mario-goulart <mario-goulart!~user@email.parenteses.org> has quit IRC11:00
*** mario-goulart <mario-goulart!~user@email.parenteses.org> has joined #yocto11:01
JaMaok, I was just surprised that it does apply in master too11:01
Crofton|worklpapp, BB_NUMBER_THREADS is likely very dependent on exact machine setup, including disks etc11:18
lpappCrofton|work: which is exactly the reason for my question how to solve it.11:18
lpappparallel is a standard MAKEFLAGS stuff.11:19
Crofton|workI think most people use empircal methodas11:19
Crofton|workempirical methods :)11:19
lpapplike ?11:19
Crofton|workguessing :)11:19
lpapp??11:20
JaMathere is script to benchmark which value works best for your hardware11:20
JaMagoogle for bb-matrix11:20
*** belen <belen!~Adium@134.134.139.76> has quit IRC11:20
lpappyou are probably misunderstanding the question.11:21
lpappCrofton|work: probably you, too.11:21
lpappCrofton|work: I know what to put in there, but I do not know _how_11:22
*** belen <belen!~Adium@134.134.137.75> has joined #yocto11:22
Crofton|work10137826836773073751511:22
Crofton|workurg11:22
Crofton|workhttps://plus.google.com/101378268367730737515/posts/KLURPQuGyJw ?11:22
JaMahttp://wiki.webos-ports.org/wiki/OE_benchmark11:23
lpappit is still irrelevant.11:23
lpappwhat you probably do not understand is the fact, once you put a value in there (No matter what), it will be device specific.11:23
lpappand that will not be working across multiple platforms and setups unlike MAKEFLAGS for the parallel stuff.11:24
lpappso pretty much, what people will need is the equivalence of MAKEFLAGS for threads.11:24
JaMayou can run the benchmark on every machine you care about and put right value in variable in /etc/profile or whatever11:26
bluelightningthis is one of the reasons site.conf exists11:26
lpappbluelightning: except that as I suggested many times, it will not help unless you have an out of the build (i.e. global setting)11:28
lpappor even out of repository for that matter.11:28
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC11:28
JaMamost people have out of the build "setup" repos11:29
lpapplet me repeat: _out of the repository_11:30
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC11:30
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto11:30
lpappthere are just more and more global stuff I would like to set up.11:32
lpappit is not getting less, just more, and it is scary IMO yocto does not address this.11:32
lpapphmm, why is oe-core building gtk-doc?11:36
lpappgtk is not really like core, yeah?11:36
lpapp(especially the doc)11:36
*** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has quit IRC11:36
*** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has joined #yocto11:37
lpappis there an option to switch gtk off, or a "more minimal" image than core-image-minimal?11:37
lpapphmm, so it is not possible to check out the meta-networking layer separately? :(11:47
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto11:51
JaMameta-networking is the only exception where it is possible11:55
lpappwell, it is just a subdirectory, really.11:57
lpappin openembedded11:57
lpappit is not any different in there tha others.11:57
JaMait is also separate repository on github12:00
JaMayou can find e-mail about it on oe-devel ML, in last 1-3 weeks12:01
lpappcan anyone help with this pod2man issue? http://paste.kde.org/~lpapp/p158554ad/12:02
lpappwell, that repository is read only.12:02
lpappso contribution would not be possible in there.12:03
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto12:07
*** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC12:07
*** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has joined #yocto12:07
lpapphttp://lists.openembedded.org/pipermail/openembedded-core/2013-June/080341.html -> seems no one cherry picked it yet ...12:09
lpappwhy not?12:09
bluelightninglpapp: local configuration is not supposed to be put into a repository12:14
bluelightninglpapp: yes, it has been cherry-picked12:15
bluelightninghttp://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dylan&id=d3c465dc1e6b956e4636d016e06ffcb881c9003012:15
lpappbluelightning: then it is not the right fix.12:16
lpappbluelightning: for my issue, that is.12:16
lpappso any idea for my issue?12:16
bluelightningthat's a different question then12:16
bluelightningwhich version are you actually using? the 1.4.1 release?12:17
lpappmaster12:18
lpappbluelightning: ^12:20
bluelightningright, I guess I was confused by "poky-dylan-9.0.1" in your paste12:21
bluelightningif you're using master then not sure, sorry12:22
lpappoops12:22
lpappyou might be right ...12:22
lpappsorry, you are right.12:22
lpappwe are using 9.0.1 poky indeed.12:22
lpappok, that sucks.12:22
lpapphope there will be a 9.0.2 soon...12:22
bluelightningyep, it's imminent12:23
bluelightninglast patchset just got merged, final build should be over the weekend and QA testing will happen next week12:23
*** flynn278 <flynn278!80db310e@gateway/web/freenode/ip.128.219.49.14> has joined #yocto12:24
lpappbluelightning: do you know why gtk stuff is needed for core stubb, even if stub?12:24
bluelightningI suspect because some upstream gtk-doc-using stuff just breaks without gtk-doc, so we have to stub it rather than disabling it12:25
bluelightningbut I actually don't know for usre12:25
bluelightningsure12:25
lpappbluelightning: http://paste.kde.org/~lpapp/p345c2aca/12:26
lpappbluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=498812:29
yoctiBug 4988: normal, Medium, Future, kergoth, NEW , QA fatal errors for the external Code Sourcery toolchain.12:29
lpappkergoth: any progress on fixing that simple one? ^12:29
*** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto12:29
lpappbluelightning: is that simple to fix?12:30
bluelightningI don't know if the /lib/libssl.so.1.0.0 is actually needed12:31
lpappbluelightning: means?12:32
bluelightningmeaning I don't know if it's needed... not sure how to put it any other way12:32
bluelightningif it is, add a spec that picks it up to FILES_<appropriate package name>12:32
bluelightningif not, in do_install(_append?) just rm ${D}/lib/libssl.so.* and rmdir /usr/libexec12:33
Net147if I create xf86-video-nouveau and xf86-video-ati recipes, should it go into oe-core or meta-oe?12:33
lpappbluelightning: which recipe?12:34
bluelightninglpapp: the one it's reporting the issue with, external-sourcery-toolchain.bb12:34
lpappbluelightning: so meta-sourcery, right?12:34
bluelightninglpapp: from the path, it looks like that's the one you're building, yes12:35
bluelightningNet147: good question12:35
lpappbluelightning: why haven't you used ${libdir}12:36
bluelightninglpapp: ${libdir} could be used sure, depends on whether the installation is using ${libdir} already or just hardcoding /lib12:37
Net147bluelightning: I am looking to add it for use with NVIDIA ION and AMD E-350 platforms. as a sideeffect it would also support desktop/laptop ATI/NVIDIA graphics too.12:37
lpappbluelightning: rm -r ${D}${libdir}/libssl.so.* ${D}/usr/libexec12:37
bluelightningnormally we use ${libdir} because we're fully controlling the build process, here I'm not so sure since this is dealing with precompiled binaries12:37
lpappthat one?12:37
bluelightninglpapp: looks like it should work yes12:38
lpappbluelightning: but how can it work for others?12:38
bluelightninglpapp: others?12:38
lpappbluelightning: other people12:39
lpappah you meant this: rm -r ${D}${libdir}/libssl.so* ${D}/usr/libexec12:39
lpappnote the so*, not so.*12:39
lpappsince it is just libssl.so12:40
bluelightninglpapp: well yes but arguably if you have deleted the real library then you probably don't want any symlinks to it to be present either if they exist...12:40
bluelightningNet147: searching through recipes it looks like we've added additional drivers in other layers rather than in the core ; there are two in meta-oe (geode and glamo) for example12:40
*** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC12:40
lpappbluelightning: ?12:40
lpappERROR: QA Issue: external-sourcery-toolchain: Files/directories were installed but not shipped /lib/libssl.so.1.0.012:41
lpappstill getting it.12:41
lpapplibdir might not be working then ...12:41
bluelightningah right, of course. ${libdir} is /usr/lib not /lib12:41
lpapp./tmp/sysroots/beagleboard/usr/include/eglibc-locale-internal-armv7a-vfp-neon-poky-linux-gnueabi/lib/libssl.so.1.0.012:41
bluelightning${base_libdir} is what you'd need there12:41
lpapp./tmp/sysroots/beagleboard/lib/libssl.so.1.0.012:41
lpappyes12:41
lpappso with dot or without?12:42
bluelightningI'd say without because of what I've said above12:42
bluelightningif there aren't any other files matching of course then the issue is moot12:42
lpappWARNING: QA Issue: No GNU_HASH in the elf binary: '/home/lpapp/Projects/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/packages-split/nscd/usr/sbin/nscd'12:43
lpappbluelightning: http://paste.kde.org/~lpapp/p9e792937/12:43
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC12:45
*** jkridner <jkridner!~jkridner@nat/ti/x-aqxqwzwqordkumfe> has joined #yocto12:45
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto12:45
Net147bluelightning: so I should target meta-oe then?12:46
bluelightningNet147: going by the current placement of recipes, it would seem so yes; I don't know if much in the way of deliberate organisation has gone into that though12:47
bluelightninglpapp: I guess add INSANE_SKIP_nscd += "ldflags"12:48
lpappbluelightning: I would like to solve it, not work around.12:48
Net147bluelightning: well if oe-core is to only have graphics driver recipes for only the hardware platforms that it is actively tested with, then that makes sense12:48
bluelightninglpapp: I don't think there is any way to properly solve it since that issue has been precompiled into the binaries that that recipe is just packaging12:49
lpappbluelightning: gosh12:49
lpappbluelightning: you understand it is a suboptimal step for people involved?12:49
KrzI want to debug do_populate_sdk function in poky/meta/classes/populate_sdk_base.bbclass, is there any echo/print function I can use there?12:50
bluelightninglpapp: is that issue present in the modern version of the toolchain?12:50
lpappbluelightning: same with that line, too12:51
bluelightninglpapp: I'm not in charge of maintaining meta-sourcery...12:51
lpappbluelightning: http://paste.kde.org/~lpapp/p93009aa6/12:51
bluelightningKrz: depends if it's a shell function or a python function you want to debug within12:52
bluelightningKrz: for python functions, bb.warn() can be useful for quick debug messages; long term you'd add bb.debug() and then just look at the task log or increase verbosity12:52
Krzbluelightning: fakeroot python do_populate_sdk() { - looks like python for me:)12:52
bluelightningKrz: for shell tasks you can just echo or use bbwarn/bbdebug/etc. but those messages won't come out to the build terminal, only the logs12:53
bluelightningKrz: right, ok12:53
bluelightninglpapp: odd error, never seen that one before... you might want to have a look at the spec file it has generated12:55
lpappbluelightning: which file ?12:56
*** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has quit IRC12:56
bluelightninglpapp: there should be a single .spec file in the workdir for the recipe12:57
lpappbluelightning: which recipe13:00
bluelightningthe one that the error is about...13:00
lpappI have no idea what that is ...13:01
bluelightningwhich recipe is indicated in the error at the end of your paste?13:01
lpappno clue.13:02
lpappmaybe cs13:03
lpappcat ./tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/external-sourcery-toolchain.spec | wgetpaste13:03
lpappYour paste can be seen here: http://bpaste.net/show/123550/13:03
bluelightninglpapp: eww.. look at the lines after %package -n gdbserver13:06
bluelightningI think that's where the problem lies...13:06
lpappbluelightning: if you say so ...13:06
lpappbluelightning: not sure what to do with it ...13:07
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto13:07
Net147which task in linux-yocto is responsible for integrating the bsp kernel config fragments into .config?13:08
Net147so I can force it to generate the .config again with new changes in bsp kernel config13:09
bluelightningNet147: not sure, perhaps do_kernel_configme ? I'm not an expert in that area at all13:12
Net147bluelightning: that's what I tried first, it didn't work13:13
bluelightningah ok, not sure then13:13
bluelightningany changes ought to be picked up automatically I would have thought...13:14
Net147bluelightning: only if recipe changes13:14
bluelightningzeddii is probably the best person to help debug any issues13:14
bluelightning(with linux-yocto)13:14
Net147it seems like it is done in do_patch13:16
Net147do_unpack -> kernel_checkout -> do_patch -> ..13:16
zeddiido_patch builds the meta-series, which is where the fragments are detected. do_configme processes the meta-series and finalizes the config.13:17
Net147zeddii: so bitbake -C patch virtual/kernel?13:18
zeddiithat won't config the kernel, no.13:18
zeddiiit's the configme13:18
Net147-C configme?13:18
zeddiibitbake -c kernel_configme linux-yocto13:19
Net147zeddii: testing...13:19
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto13:20
lpappbluelightning: got a clue?13:20
bluelightninglpapp: not on this issue, no13:20
lpappbluelightning: too bad ...13:20
Net147zeddii: the .config file still not correct13:21
zeddiiyou really aren't giving me anything to go on13:21
zeddiiI assure you that it works, so there's something you are doing that I don't know about.13:22
bluelightninglpapp: looks like it tries to auto-determine the correct version and fails because the gdb binary can't be run (missing ncurses?)13:22
Net147zeddii: okay, I just need to wait for build to complete I think13:23
Net147zeddii: looks correct now13:23
zeddiiconfigme runs before do_configure13:23
bluelightninglpapp: maybe a DEPENDS on ncurses-native would help?13:23
zeddiiso depending on what you were looking for, that might have been the problem.13:23
bluelightninglpapp: (a complete guess)13:23
lpappbluelightning: for a toolchain? :O13:23
bluelightninglpapp: clearly the gdb binary has a shared library dependency on it...13:24
lpappDEPENDS += "${@base_conditional('PREFERRED_PROVIDER_linux-libc-headers', PN, '', 'linux-libc-headers', d)}"13:24
lpapphow to extend this line ?13:24
bluelightningjust add stuff before the closing quote, or put another line underneath it doing DEPENDS += "whatever-value-you-want"13:25
lpappbluelightning: do I need to clean up before retry13:27
lpapp(same error)13:27
lpappeven with -c cleanall13:27
bluelightningwell, I don't know13:28
bluelightningclearly it needs ncurses and can't find it13:28
lpappwell, adding to DEPENDS does not help.13:28
lpappand rerunning bitbake stunnel13:29
Net147zeddii: what I am doing is I have a kernel already built. then I enable a new kernel option in meta-custom-bsp/recipes-kernel/linux/files/custom.cfg and do bitbake -C kernel_configme virtual/kernel13:29
bluelightningI did say that was a guess13:29
KrzIn my Yocto build I have the directory with whole bunch of broken symlinks: /dev/shm/kmsywula/tmp/work/i586-poky-linux-uclibc/meta-toolchain/1.0-r7/sdk/image/opt/my-tiny/1.4.1/sysroots/i586-poky-linux-uclibc/usr/src/debug/uclibc/0.9.33+gitAUTOINC+946799cd0ce0c6c803c9cb173a84f4d607bde350-r8.4/git/include/bits13:29
Krzdo you know who is responsible for building this ?13:30
zeddiiNet147, right, so in that case, you need to prop them back to WORKDIR and that's the patch phase, it collects up the bits and pieces.13:30
Net147zeddii: so I was right I need to do -C patch instead13:30
zeddiiyup.13:30
*** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has joined #yocto13:32
Net147perhaps the build system can be improved to detect changes in the .cfg even if there are no changes in the recipes?13:33
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto13:33
zeddiiI have something open for that in 1.5, so looking into it!13:33
zeddiiNet147, are you on master ?13:33
Net147yes13:33
Net147you got the bug report number?13:33
zeddiiI'll track it down. I'm 3 minutes late for a meeting :)13:34
zeddii413:34
zeddiiheh13:34
zeddiiNet147, one other quick question, you had that .cfg file listed in the SRC_URI, right ?13:34
zeddiiif so, that should hit the checksum when you modified it, just a matter of re-running the right phases after that.13:35
Net147zeddii: custom.scc has "kconfig hardware custom.cfg"13:35
Net147zeddii: and I changed custom.cfg13:36
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-cymidptunsucfyrj> has joined #yocto13:36
lpappbluelightning: thanks anyway ...13:36
lpapp:)13:36
zeddiiNet147, ok, that's good too. that's right what I'm looking into. will let you know that bug number.13:36
zeddiiyou can drop me an email at bruce.ashfield@windriver.com .. so I don't forget.13:37
Net147zeddi: thanks13:37
bluelightninglpapp: if you want to hack around it for the time being you could just hardcode CSL_VER_GDB to some value instead of letting it try to obtain it from the non-working binary13:38
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC13:39
*** jkridner <jkridner!~jkridner@nat/ti/x-lguoiaqqayymlyci> has joined #yocto13:40
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto13:40
lpappbluelightning: plenty of issues around the toolchain.13:40
lpappperhaps it will be better to switch to the internal within a few years.13:41
bluelightningthe internal toolchain is certainly what we use to test the system and how many people use it13:41
lpappthe only problem is that it does not make any sense to rebuilt it all the time ...13:42
lpapprebuild*13:42
lpappit would slow the CI down significantly.13:42
JaMathat;s what sstate is for :)13:43
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC13:44
bluelightningindeed13:46
*** jukkar <jukkar!jukka@nat/intel/x-jsopvmlqrmfmooyu> has quit IRC13:51
*** jukkar <jukkar!~jukka@134.134.139.74> has joined #yocto13:52
*** _alex_kag_ <_alex_kag_!~alex_kag@178.124.22.24> has quit IRC14:02
lpappbluelightning: ?14:03
lpappbluelightning: you do not wanna check in sstates into the repository, I guess.14:03
bluelightningyou don't, no14:03
lpappbluelightning: then how would that solve the CI's issue?14:03
bluelightninghave a shared sstate cache mirror that each builder points to using SSTATE_MIRRORS14:04
lpappbluelightning: are you saying a sstate cache does not ever change?14:08
lpappwhat if I add new packages, remove existing, modify dependencies, etc.14:08
bluelightninglpapp: if the inputs don't change14:08
lpappthe states are changing, and hence the jobs ...14:08
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC14:08
bluelightningyes, and therefore the signature will change and the task will be re-run instead of having its output extracted from sstate14:09
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto14:11
*** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has quit IRC14:19
*** slaine <slaine!~slaine@84.203.137.218> has quit IRC14:21
lpappbluelightning: but that would mean we need to be careful to keep sync with the server.14:23
lpappand that is an additional hassle.14:23
lpappand a potential places for errors.14:23
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC14:29
*** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC14:29
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto14:40
bluelightninglpapp: not sure how you get potential places for errors14:45
lpappbluelightning: forget sync?14:46
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC14:46
bluelightningthen it would just rebuild instead of restoring from sstate and give you the same result...14:46
bluelightningit's a build time saving mechanism, nothing more14:46
lpappit is critical on CI ...14:47
lpappwhether it is one hour or two ...14:47
lpappit is not a "subtle feature"14:48
lpappIOW, it is a blocker.14:48
bluelightningusing shared state you can reduce the build time significantly for the items that haven't changed since the last build14:48
bluelightningwhat is a blocker?14:48
lpappbuilding slowly.14:48
lpappsince that slows down the merges etc etc etc...14:49
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto14:50
bluelightningyes, so try using shared state to resolve that...14:50
lpappbut it can get error prone easily ...14:50
lpappunlike an external toolchain installed once...14:50
bluelightningno, I don't think it can14:56
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto14:56
lpappbluelightning: what if you forget to sync up?15:01
bluelightningI just answered that question15:02
Krzcan you use sstate when changing from eglibc to uclibc?15:02
lpappbluelightning: you need to update.15:02
lpappbluelightning: which means you can forget it15:03
lpappbluelightning: which means the slow might get an uncool regression.15:03
lpappslow = build*15:03
bluelightninglpapp: no, it won't15:03
bluelightningKrz: in theory yes but I don't know if anyone has tested that15:04
lpappbluelightning: sure, it will.15:04
lpappor I do not understand the magic.15:04
bluelightninglpapp: all of the inputs go into a checksum, which is used to fetch the shared state package (tarball). If one of the inputs have changed, the checksum will be different -> the old output will not be re-used15:04
lpappbluelightning: so there will be no speed up ...15:05
lpappso it will slow down ...15:05
bluelightningno15:05
bluelightningit's unlikely you will always be changing everything at once15:05
bluelightningthus, there will be large numbers of tasks whose inputs are unchanged15:06
lpappbluelightning: sure, we will.15:06
lpappi.e. yocto update15:06
bluelightningall of those that do not change can be extracted from sstate instead of being built15:06
lpapppretty much everything changes with a yocto update ...15:06
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto15:07
*** davest <davest!Adium@nat/intel/x-cnnpioozrsrpupms> has joined #yocto15:11
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has quit IRC15:13
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC15:14
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC15:16
*** cargo23 <cargo23!~esmith@sf-nat.sourcefire.com> has joined #yocto15:21
lpappbluelightning: why are bitbake recipes so complicated many times?15:27
lpappI mean, some packages on other distributions are simpler in the sense that config, make, install, etc are the default.15:28
Crofton|workepic way around autorev at parse time :)15:28
Crofton|workhttps://github.com/Xilinx/meta-xilinx/blob/master/recipes-kernel/linux/linux-xlnx-dev.bb15:28
lpapphere, it seems the environment and those steps require quite a bit of customization.15:28
lpappCrofton|work: you work for Xilinx ?15:28
Crofton|workme? no15:28
Crofton|workjust a consumer15:28
lpappok15:28
bluelightninglpapp: I guess one reason would be that many of those other distros don't cross-compile15:29
lpappbluelightning: cannot that be avoided by putting the boilerplate into a central place ?15:29
bluelightninglpapp: we do that, see meta/classes/*15:29
zeddiiCrofton|work, same trick we play with linux-yocto-dev :P So I approve15:30
Crofton|workheh15:30
lpappbluelightning: then why still so much customization in most of the recipes ?15:30
Crofton|workI'm not certain I'd encourage that in a customer facing bsp :)15:30
Crofton|workgah, they are using PR in a kernel recipe15:31
KrzFinding whole bunch of broken symlinks on poky-dylan9.0.1: /build/kmsywula/yocto_build/tmp/work/i586-poky-linux-uclibc/uclibc find -L -type l15:31
bluelightninglpapp: we'd have to get more specific15:31
Krzit does not look valid at all, and that's 100% upstreamed code15:31
bluelightninglpapp: in order to answer the question15:31
Crofton|workI need to send them a patch to add machineoverrides to each SRC_URI line15:32
lpappbluelightning: ok, I will become specific at home during the weekend if you wish.15:32
bluelightningkhem: can you help Krz with uclib stuff ^?15:32
Crofton|workand it is a bitch addding a driver in your custom hardware linux-yocto recipe15:32
*** nitink <nitink!~nitink@134.134.137.73> has quit IRC15:34
Crofton|workwould SRC_URI_${MACHINE} += "foo" work?15:36
Crofton|workor is this crossing the streams :)15:37
Krzbroken symlinks were not found yet is because populate_sdk/tar_sdk tars whole package without --hard-dereference; I believe that should be default flag15:37
*** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto15:44
*** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC15:44
*** cfo215_ <cfo215_!4473ad42@gateway/web/freenode/ip.68.115.173.66> has joined #yocto15:45
*** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has quit IRC15:50
kergothbluelightning: i'll take a closer look at that tslib patch sometime today, sorry for the delay15:51
Krzups, i meant tar -h (the other is for hardlinks)15:54
bluelightningkergoth: no worries... I think we may be safe without it, but of course you would be able to tell for sure15:55
kergoththat's not necessarily true, i'm admittedly pretty rusty at this, i need to think about handing off tslib maintainance to someone with hardware that has an actual touchscreen :)15:56
kergothah, didn't see your latest reply, if it's working on mips, i'm in favor of just pushing the update and dealing with any potential problems if and when they appear15:59
kergothheh15:59
Crofton|workzeddii, have you dealt with builds that contain multiple bsp's each using a .bbappend to modify the kernel?16:01
zeddiiyup. plenty. lots of stacked layers around here.16:02
Crofton|workso I would be correct in assuming that you need to use a machien override in your SRC_URI's that you append?16:04
Crofton|worksince all the linux-yocto bbappnds will stack in some order16:04
zeddiiyah, if they are changing things that are really board specific. we control the order, and of course drive most changes into a git tree (versus patches), but they should be tagged machine specific.16:05
Crofton|workyeah, there are loads of patches against 3.816:06
Crofton|workand there is the epic line16:06
Crofton|workhttps://github.com/Xilinx/meta-xilinx/blob/master/recipes-kernel/linux/linux-yocto_3.8.bbappend#L1016:06
cfo215_Hi All: I'm trying to bitbake my recipe and it keeps puking.  I get "Recipe file does not have license file information (LIC_FILES_CHKSUM)",  I have "LIC_FILES_CHKSUM = 'file://COPYING;md5=bb3ca60759f3202f1ae42e3519cd06bc"' in my recipe16:06
Crofton|workwhich mandates everyone have the ${KMACHINE}-standard.scc file16:06
*** nitink <nitink!nitink@nat/intel/x-qqgizzeqxdugsujg> has joined #yocto16:07
cfo215_its a GPLv3 license and i generated the md5 on my machine from the COPYING file in the source tarball, which is local to my machine.16:07
sgw_cfo215_: can you paste both your recipe and the full error text to pastebin or the like16:07
cfo215_sgw_: will do. w116:08
sgw_cfo215_: or recipe snipet16:08
zeddiiCrofton|work, yah, they can have those patches, they just need to make that ${KMACHINE}-standard.scc  be something you can override, or they should put their machine name in there and you inherit it .. then add, how ever you like.16:09
Crofton|workyeah16:09
Crofton|workI added my own bbappend, and it blew up because I do not use that name16:10
Crofton|workthe only way I can see making that line work is add a SRC_URI line for each machine they have in the layer16:10
cfo215_sgw_:http://pastebin.com/jFBrLvND16:13
sgw_cfo215_: and if you cut and paste the "invalid file" the COPYING file is really there at that path?16:17
*** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has joined #yocto16:22
cfo215_sgw_: no the file isn't there... I don't quite understand how it all works (yet).  I thought the bb system would extract the tarball to inspect the COPYING file.16:24
cfo215_COPYING is just the standard GPLv3 boilerplate text.16:24
bluelightningcfo215_: it will, it's just a matter of ensuring S points to the right directory and then LIC_FILES_CHKSUM should match up with that (since that will be the current working dir when that is checked)16:25
bluelightningcfo215_: looking at what you're doing in do_install I wonder if S should be set to "${WORKDIR}/phidget21"16:26
cfo215_bluelightning: i'll comment it out and see what happens.16:28
*** _alex_kag_ <_alex_kag_!~alex_kag@178.126.67.243> has joined #yocto16:28
bluelightningcfo215_: I'd suggest naming your recipe as libphidget_2.1.8.20130723.bb and then you shouldn't need to set S, and your package version will be correct as well16:30
*** sameo <sameo!~samuel@192.55.54.40> has quit IRC16:30
sgw_cfo215_: when you are in ${S}, are there files there at all?  if you cd .. from ${S} what directories exist?  or what does the tarball contain for it's root16:30
bluelightningcfo215_: (since it defaults to being derived from the filename)16:30
*** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has quit IRC16:30
kergothwe should really change it so ${S} doesn't get autocreated if it doesn't exist, but thats the default behavior of 'dirs'..16:32
kergothheh16:32
*** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto16:33
cfo215_bluelightning: same results.  I do suspect something though... testing again.16:34
bluelightningkergoth: yes, I agree16:35
*** feydrautha <feydrautha!~user@184.70.21.10> has joined #yocto16:37
seebskergoth: If I wanted to submit some patches to meta-sourcery, would I use the yocto contrib tree, or some other tree, or just send you patches?16:39
cfo215_bluelightning:  I tried remvoving the PR variable, but got some error, just with r0 instead of r1 in the file path.16:39
bluelightningcfo215_: right, changing PR won't help here16:40
sgw_cfo215_: could the files be in phigets/phidget21/COPYING?  It would be helpful to know the top directory of your tarball.16:41
kergothseebs: its easiest to open pull requests against the github repository, thats where we're doing our main development, and mirroring to the yocto repository. https://github.com/MentorEmbedded/meta-sourcery16:42
seebsOkay.16:42
seebsWhat toolchains would you normally test that against? I know my patches work with ours, but they're not quite the standard/default.16:43
cfo215_sgw_:bluelightning: /media/toshiba-usb3/work/test/setup-scripts/sources/meta-epic/recipes-epic/phidgets/files/libphidget_2.1.8.20130723.tar.gz  ALSO: ./configure depends on libusb if that matters.16:43
cfo215_sgw_:bluelightning: libusb-dev (sources) that is...16:45
bluelightningcfo215_: I'm just testing a modified version of this recipe here16:45
sgw_cfo215_: that's your tarball, what's the top level directory inside the tarball?16:45
KrzI compared the broken symlinks to Yocto 1.3 and it was everything fine there :(. Looks like some nasty thing introduced in Yocto 1.4.1. It is only present in uclibc build, eglibc is fine.16:47
*** mthalmei_away <mthalmei_away!~mthalmei@ex4.michisoft.net> has quit IRC16:47
KrzIs anybody out there using uclibc? Looks like it is not well used16:47
bluelightningkhem is the uclibc expert16:48
bluelightninghe may not be around, not sure16:48
cfo215_ sgw_:bluelightning: libphidget-2.1.8.2013072316:48
Krzbluelightning: maybe email?16:49
*** ka6sox-away is now known as ka6sox16:49
sgw_cfo215_: then you should not need to set $S if you have named your recipe as bluelightning suggests then the "right" thing should happen when it unpacks16:49
bluelightningcfo215_: try this instead (cleaned up, and build-tested): http://pastebin.com/fRkNFZF416:50
Krzbluelightning: i'm not sure about the impact, but there is whole bunch of header files missing after installing sdk (due to broken symlinks)16:50
bluelightningcfo215_: it's an autotooled piece of software so "inherit autotools" is needed, and that pretty much takes care of everything16:50
*** mthalmei_away <mthalmei_away!~mthalmei@ex4.michisoft.net> has joined #yocto16:52
*** _alex_kag_ <_alex_kag_!~alex_kag@178.126.67.243> has quit IRC16:54
cfo215_bluelightning: http://pastebin.com/SW5NLSwU for results.  couldn't fetch16:56
bluelightningcfo215_: right, you need to name it libphidget_2.1.8.20130723.bb16:57
cfo215_bluelightning: sorry, didn't do that16:58
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto16:59
cfo215_bluelightning: in the local.conf and change the name of the diretory too?  I got "ERROR: Nothing PROVIDES 'phidgets'" when I bitbaked it.17:01
bluelightningcfo215_: right, the recipe and package produced will now be called "libphidget"17:01
cfo215_bluelightning: sorry ment to say bblayers.conf17:01
bluelightningshouldn't need to change bblayers.conf though17:01
bluelightningjust bitbake libphidget17:02
flynn278Crofton|work, if you have success let me know I am starting to do the same thing with that same file.17:04
Crofton|workurg? Which file?17:04
Crofton|workmeta-xilnix17:05
flynn278Crofton17:05
*** belen <belen!~Adium@134.134.137.75> has quit IRC17:05
*** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC17:05
flynn278Crofton|work yes, meta-xilnix17:05
Crofton|workk17:05
Crofton|workin gnuradio dev call atm17:05
Crofton|workgoing to make a patch to override things17:05
*** belen <belen!Adium@nat/intel/x-qmhfevzmknjkzcub> has joined #yocto17:08
cfo215_bluelightning: I got: "NOTE: Tasks Summary: Attempted 1147 tasks of which 1133 didn't need to be rerun and all succeeded." but can't seem to find the *.ipk file in deploy.17:09
bluelightningcfo215_: I think it will be called libphidget21-0 (due to debian renaming)17:10
bluelightningcfo215_: you should definitely be able to find it with find tmp/deploy/ipk -name "*phidget*"17:11
b1gtunaADT installer site is offline - http://downloads.yoctoproject.org/releases/yocto/yocto-1.4/adt_installer17:13
cfo215_bluelightning: /media/toshiba-usb3/work/test/setup-scripts/build/tmp-angstrom_v2012_12-eglibc/deploy/ipk/armv7a-vfp-neon/libphidget21-dev_2.1.8.20130723-r0_armv7a-vfp-neon.ipk !!! Yeah !!! Thanks for all your help.17:13
bluelightningcfo215_: no worries... if you feel like sending a patch to add that recipe to meta-oe that would be awesome ;)17:14
Crofton|workflynn278, are you on the meta-xilnix list?17:15
cfo215_bluelightning: Unfortunately Phidgets doesn't expose their source on github.  if you try to download their drivers the link is: http://www.phidgets.com/docs/OS_-_Linux#Quick_Downloads  Also, kernel 2.6 or newer is required and should be added to the recipe17:17
cfo215_bluelightning:  which is why I used a local tarball.17:17
bluelightningcfo215_: if the recipe actually depends on the kernel itself you can add virtual/kernel to DEPENDS17:17
flynn278Crofton|work, yes I am on the meta-xilnix list17:17
bluelightningcfo215_: the URL I have there works but who knows if they will break it by removing old tarballs17:17
bluelightningcfo215_: could always ask them to not do that... or add the tarballs to the OE source mirror17:18
cfo215_bluelightning: who do I contact at Yocto/OE to start the ball rolling.17:23
bluelightningcfo215_: which, to get the tarball uploaded you mean? or to submit the patch?17:23
cfo215_bluelightning: yes and yes.17:24
cfo215_bluelightning: on an other note:... I hope the find the bastards doing teh DoS on GitHub and string them up by the balls... assuming they have them...17:25
bluelightningcfo215_: for the tarball, you can talk to ka6sox (Tom King, ka6sox at gmail)17:26
b1gtunaMay I get some help setting ADT/Toolchain? If my machine type is beagleboard/overo, what's the recommended way of setting the dev environment up? It looks like the auto-installer only gives arm, x86, x86_64, ppc, mips  as options.17:26
bluelightningcfo215_: for the patch, see http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded17:26
cfo215_bluelightning: thanks17:26
bluelightningcfo215_: and it would be the meta-oe layer within the meta-openembedded repository that this recipe would best go into17:26
cfo215_bluelightning: thanks again.17:27
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC17:27
bluelightningcfo215_: ah, I wasn't aware that github was being DDOS'd... that might explain the recent failures I've had fetching from there17:27
bluelightningcfo215_: np17:27
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC17:28
*** mr_science <mr_science!~sarnold@net-cf9a4e91.cst.impulse.net> has joined #yocto17:29
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:29
cfo215_bluelightning: Last to days.  the current status is "Everything working normally" per https://status.github.com/17:29
bluelightningb1gtuna: you can build an companion SDK for your image by doing bitbake -c populate_sdk imagename, if that helps17:29
b1gtunabluelightning: And I should get beagle/overo as the target architectures?17:30
*** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has quit IRC17:30
mr_sciencehow is that different than building the standard meta-sdk target?17:30
cargo23Newb question:  What is wrong with this line? CONFIGUREOPTS := "${@d.getVar('CONFIGUREOPTS', True).replace('--with-libtool-sysroot=$SDKTARGETSYSROOT', ' ')}"17:30
bluelightningb1gtuna: you need to set MACHINE appropriately to match that yes17:30
cfo215_bluelightning: Thanks for all your help.  Now I'm onto the 1-Wire SDK libraries...  unless someone has already done that?17:30
* mr_science missed the laed-up to that one...17:30
b1gtunabluelightning: hmm ok that helps. I tried the method already, but perhaps I missed something. Thanks always!17:31
bluelightningb1gtuna: the difference from meta-toolchain is that the target portion of the SDK will contain the right stuff to match up with the image, if the image contains additional libraries17:31
bluelightningb1gtuna: but if you don't care about that, meta-toolchain will work just as well17:31
mr_scienceah17:31
b1gtunabluelightning: ah I see. Not sure why the ADT manual discourages bitbaking populate_sdk17:31
bluelightningcfo215_: I was sure someone had...17:31
b1gtunabluelightning: coolio, gracias17:31
cargo23The line compiles fine, but it doesn't match, so I'm failing to eliminate the --with-libtool-sysroot option to configure.17:32
bluelightningb1gtuna: I think that the very latest in-development version of the manual has more of a pointer to doing it that way17:32
cfo215_bluelightning:  I'll do some digging and see what I find.17:32
cfo215_bluelightning:  thanks again.17:32
b1gtunabluelightning: great! Will do some more reading too17:32
*** cfo215_ <cfo215_!4473ad42@gateway/web/freenode/ip.68.115.173.66> has quit IRC17:32
-YoctoAutoBuilder- build #254 of nightly-non-gpl3 is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-non-gpl3/builds/25417:33
cargo23nvrm... I got it, I needed ${STAGING_DIR_TARGET} instead of $SDK...17:35
mr_sciencebluelightning: does that produce equivalent output?  ie, the poky sdk archive?17:36
mr_sciencethe bitbake -c populate_sdk thing...17:37
mr_sciencei guess we'll see when it's done...17:38
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC17:39
bluelightninghmm, I was going to say to cfo215 that the one-wire stuff just got moved to a new layer (meta-filesystems)17:41
*** belen <belen!Adium@nat/intel/x-qmhfevzmknjkzcub> has quit IRC17:42
-YoctoAutoBuilder- build #256 of nightly-arm-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-arm-lsb/builds/25617:45
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto17:49
-YoctoAutoBuilder- build #222 of nightly-fsl-ppc-lsb is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-ppc-lsb/builds/22217:50
-YoctoAutoBuilder- build #253 of nightly-ppc-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-ppc-lsb/builds/25317:51
*** Krz <Krz!c0c69724@gateway/web/freenode/ip.192.198.151.36> has quit IRC17:51
bluelightningmulhern: FYI, meta-perl just got created in the meta-openembedded repository17:52
mulhernbluelightning: Thanks for the heads up.17:52
bluelightningmulhern: I talked to Stygia as well, hopefully he will submit his block of recipes soon17:52
* bluelightning -> home17:53
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:53
* mr_science -> two weeks off starting Monday17:53
-YoctoAutoBuilder- build #94 of minnow-lsb is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/minnow-lsb/builds/9417:53
-YoctoAutoBuilder- build #66 of buildtools is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/buildtools/builds/6617:55
mr_sciencetime to install the oldest kid into his new dorm room again...17:56
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC17:58
ka6soxI guess he is gone17:59
-YoctoAutoBuilder- build #256 of nightly-x86-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86-lsb/builds/25617:59
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto18:09
-YoctoAutoBuilder- build #265 of nightly-mips-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-mips-lsb/builds/26518:09
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC18:13
*** _alex_kag_ <_alex_kag_!~alex_kag@178.126.67.243> has joined #yocto18:16
-YoctoAutoBuilder- build #28 of eclipse-plugin-kepler is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/eclipse-plugin-kepler/builds/2818:16
mr_scienceka6sox: ?18:26
*** dvhart <dvhart!~dvhart@134.134.139.72> has joined #yocto18:28
-YoctoAutoBuilder- build #247 of nightly-x86-64-lsb is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86-64-lsb/builds/24718:31
otaviosgw_: I fixed a regression in linux-dtb; I added you in Cc18:36
*** davest <davest!Adium@nat/intel/x-cnnpioozrsrpupms> has quit IRC18:38
*** davest <davest!Adium@nat/intel/x-obfgjxtpwfqjzoek> has joined #yocto18:41
-YoctoAutoBuilder- build #224 of nightly-fsl-arm-lsb is complete: Failure [failed Building Images Building Images_1 Building Images_2] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm-lsb/builds/22418:42
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto18:48
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto18:49
*** swex_ <swex_!~swex@178.17.197.110> has quit IRC18:58
mranostayhi Jefro18:58
*** swex_ <swex_!~swex@88.210.27.94> has joined #yocto19:00
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC19:13
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC19:13
-YoctoAutoBuilder- build #251 of nightly-world is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-world/builds/25119:13
*** Crofton|work <Crofton|work!~balister@pool-71-171-32-225.ronkva.east.verizon.net> has quit IRC19:13
*** Crofton|work <Crofton|work!~balister@pool-71-171-32-225.ronkva.east.verizon.net> has joined #yocto19:18
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC19:25
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto19:27
seebsAre there any other meta-sourcery users around? I am working on some stuff, and seek use cases to try out and make sure I haven't broken them.19:35
*** ka6sox is now known as ka6sox-away19:40
JaMaseebs: Hi, I was testing those changing file atributes a bit more and I can reproduce it with external 32bit toolchain even on 32bit builder19:46
seebsInteresting!19:46
seebsHmm. I wonder -- are any of the toolchain binaries statically linked?19:46
seebsBecause pseudo can't defeat statically-linked binaries.19:47
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC19:47
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto19:48
JaMalet me check19:49
JaMaseebs: yes, e.g. ranlib c++ objdump ld.bfd objcopy strip g++ ar nm ld as gcc ldconfig sln cc1 lto-wrapper cc1plus lto1 collect2 fixincl c++filt .. are all statically linked19:53
JaMaseebs: also it seems independent from paralelism (both BB_THREADS and PARALLEL_MAKE) as it happens even with -j1 and one BB_THREAD19:56
Jefromranostay belated howdy19:57
seebsYeah, that would do it. d'oh20:03
seebsWe don't have a plan, really, for static binaries. That is the one glaring weakness in pseudo's design; it has to intercept calls through providing symbols that get taken instead of the libc symbols.20:03
seebsThere's mechanisms for intercepting syscalls, but they're a lot harder.20:04
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC20:08
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto20:17
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC20:20
*** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has joined #yocto20:21
*** nitink <nitink!nitink@nat/intel/x-qqgizzeqxdugsujg> has quit IRC20:23
*** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has quit IRC20:23
*** smartin <smartin!~smartin@ANantes-655-1-161-176.w90-59.abo.wanadoo.fr> has quit IRC20:26
*** flynn278 <flynn278!80db310e@gateway/web/freenode/ip.128.219.49.14> has quit IRC20:26
-YoctoAutoBuilder- build #253 of nightly-multilib is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-multilib/builds/25320:26
-YoctoAutoBuilder- build #250 of nightly-x86-64 is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86-64/builds/25020:27
*** j8 <j8!~IceChat9@199.44.250.3> has quit IRC20:29
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC20:31
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto20:40
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:42
*** davest <davest!Adium@nat/intel/x-obfgjxtpwfqjzoek> has quit IRC20:42
*** nitink <nitink!nitink@nat/intel/x-jjjvdtclunapsdtk> has joined #yocto20:51
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC20:56
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto20:59
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto21:06
-YoctoAutoBuilder- build #255 of nightly-mips is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-mips/builds/25521:09
-YoctoAutoBuilder- build #256 of nightly-x86 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86/builds/25621:14
*** nitink <nitink!nitink@nat/intel/x-jjjvdtclunapsdtk> has quit IRC21:19
*** nitink1 <nitink1!~nitink@134.134.137.73> has joined #yocto21:19
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC21:28
b1gtunaHas anyone successfully configured remote debugging through the ADT? Using USB serial port on a board?21:33
*** Guest90294 <Guest90294!~trz@c-68-53-177-94.hsd1.in.comcast.net> has left #yocto21:57
*** agust <agust!~agust@p4FC46512.dip0.t-ipconnect.de> has quit IRC22:01
*** jzhang <jzhang!~jzhang@134.134.139.70> has joined #yocto22:07
bluelightningb1gtuna: jzhang might be able to help with ADT questions22:19
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-cymidptunsucfyrj> has quit IRC22:20
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-xgwqwobajhcopfkh> has joined #yocto22:21
*** eren <eren!~eren@unaffiliated/eren> has quit IRC22:29
-YoctoAutoBuilder- build #255 of nightly-non-gpl3 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-non-gpl3/builds/25522:31
-YoctoAutoBuilder- build #219 of nightly is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/21922:31
b1gtunabluelightning: thanks I was just watching her presentations on ADT stuff. Helping a lot22:32
-YoctoAutoBuilder- build #267 of nightly-intel-gpl is complete: Failure [failed Building Images Building Images_1] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-intel-gpl/builds/26722:35
-YoctoAutoBuilder- build #260 of poky-tiny is complete: Failure [failed Building Images Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/poky-tiny/builds/26022:36
b1gtunajzhang: I'm trying ADT/Eclipse. I can't remote debug the Hello World example because my remote target doesn't have sftp subsystem. Should I enable tools-sdk or dev-pkgs in EXTRA_IMAGE_FEATURES?22:37
b1gtunajzhang: ah, tcf-agent is what i need22:40
jzhangb1gtuna: which image are u using?22:41
*** kuemo <kuemo!b2c0b9f5@gateway/web/freenode/ip.178.192.185.245> has joined #yocto22:42
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC22:42
b1gtunajzhang: It's gumstix-xfce-image from meta-gumstix22:46
jzhangb1gtuna: include eclipse-debug, that'll give u gdbserver, tcf-agent and openssh-sftp-server22:46
b1gtunajzhang: as EXTRA_IMAGE_FEATURES?22:46
jzhangyes22:48
b1gtunajzhang: awesome. ty22:49
b1gtunajzhang: glad i asked. It's not something in the manual22:50
jzhangnp:)22:51
jzhangbtw, once you enable the eclipse debugging, use ssh connection which is much more stable than tcf22:52
b1gtunajzhang: great ty22:52
*** kuemo <kuemo!b2c0b9f5@gateway/web/freenode/ip.178.192.185.245> has quit IRC22:52
jzhangu r welcome, have fun...22:53
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC22:54
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto22:59
*** nitink1 <nitink1!~nitink@134.134.137.73> has quit IRC23:01
*** nitink <nitink!nitink@nat/intel/x-mhkqqtxtuodstyoi> has joined #yocto23:01
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC23:11
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto23:12
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto23:13
*** _alex_kag_ <_alex_kag_!~alex_kag@178.126.67.243> has quit IRC23:22
*** sameo <sameo!~samuel@192.55.54.42> has joined #yocto23:24
*** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has quit IRC23:24
*** joeythesaint <joeythesaint!~jjm@198-84-238-35.cpe.teksavvy.com> has quit IRC23:32
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC23:40
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto23:41
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC23:42
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto23:46

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