Friday, 2013-08-16

*** walters <walters!> has joined #yocto00:00
*** mulhern <mulhern!~mulhern@> has joined #yocto00:18
*** seebs <seebs!> has joined #yocto00:21
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC00:22
*** _julian_ <_julian_!> has joined #yocto00:32
*** _julian <_julian!> has quit IRC00:35
brmRP: Sorry got disconnected ... yes I agree sysroot sounds wrong00:36
*** davest1 <davest1!~Adium@> has quit IRC00:37
evanpcjosephson: build/tmp/deploy/images, where "build" is your build dir and possibly really is "build"00:37
*** seebs <seebs!> 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!> has joined #yocto00:42
*** Jefro <Jefro!> 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!> has joined #yocto00:50
*** feydrautha <feydrautha!~user@> has joined #yocto00:54
*** feydrautha <feydrautha!~user@> has joined #yocto00:55
*** blloyd_ <blloyd_!> has quit IRC00:58
*** mulhern <mulhern!~mulhern@> has quit IRC01:16
*** mulhern <mulhern!> has joined #yocto01:19
*** feydrautha <feydrautha!~user@> has quit IRC01:29
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:36
*** behanw <behanw!> has quit IRC01:57
*** seebs <seebs!> has joined #yocto02:01
*** silviof2 <silviof2!> has joined #yocto02:01
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has quit IRC02:04
*** mulhern <mulhern!> 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.> has quit IRC02:20
*** simar_ <simar_!~simar@> has joined #yocto02:24
*** Jefro <Jefro!> has joined #yocto02:27
*** simar <simar!~simar@> has quit IRC02:27
*** Jefro <Jefro!> has quit IRC02:30
*** zenlinux <zenlinux!> has joined #yocto02:47
nerdboybrm: not played with that...03:04
*** andyross <andyross!> 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!> has left #yocto03:23
*** brm <brm!6f45f8a8@gateway/web/freenode/ip.> 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
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_!> 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.> has quit IRC04:07
*** klinger_ <klinger_!> has joined #yocto04:16
*** Satrukaan <Satrukaan!> has joined #yocto04:20
*** Satrukaan <Satrukaan!> has quit IRC04:25
*** alex_kag <alex_kag!~alex_kag@> has joined #yocto04:49
*** zecke <zecke!> has joined #yocto05:09
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has quit IRC05:17
*** agust <agust!> has joined #yocto05:23
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has joined #yocto05:28
*** andyross <andyross!> has quit IRC05:35
*** Jefro <Jefro!> has joined #yocto05:48
*** Jefro <Jefro!> has quit IRC05:50
*** Squix <Squix!> has joined #yocto06:34
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:34
*** smartin <smartin!> has joined #yocto06:44
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06:50
*** slaine <slaine!~slaine@> has joined #yocto07:04
*** Zagor <Zagor!> has joined #yocto07:07
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto07:07
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto07:13
*** TuTizz <TuTizz!~TuTizz@> 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 =>
nerdboyhopefully it's not too out of date...07:32
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC07:38
*** rogerzhou <rogerzhou!~rogerzhou@> 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@> has joined #yocto07:52
*** _alex_kag <_alex_kag!~alex_kag@> has joined #yocto07:53
*** alex_kag <alex_kag!~alex_kag@> has quit IRC07:53
*** _alex_kag is now known as alex_kag07:53
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC07:58
*** sameo <sameo!~samuel@> has joined #yocto08:03
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC08:10
-YoctoAutoBuilder- build #218 of nightly is complete: Failure [failed] Build details are at
*** bluelightning <bluelightning!~paul@> has joined #yocto08:11
*** bluelightning <bluelightning!~paul@> has quit IRC08:11
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:11
*** gmacario <gmacario!~gmacario@> has joined #yocto08:15
bluelightningmorning zecke, all08:22
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto08:23
zeckehi. :)08:27
*** Stygia <Stygia!> has joined #yocto08:29
*** florian_kc is now known as florian08:30
*** honschu <honschu!> has joined #yocto08:30
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto08:30
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC08:33
*** JimBaxter <JimBaxter!> has joined #yocto08:40
*** cjosephson <cjosephson!> has quit IRC08:43
*** cjosephson <cjosephson!> has joined #yocto08:44
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC08:45
*** Garen <Garen!~garen@> has quit IRC08:58
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto09:02
*** belen <belen!Adium@nat/intel/x-ooxfbtkerrvwpzqk> has joined #yocto09:12
*** JaMa <JaMa!> has quit IRC09:17
*** rogerzhou <rogerzhou!~rogerzhou@> 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@> has joined #yocto09:39
*** JimBaxter <JimBaxter!> has quit IRC09:46
*** B4gder <B4gder!> has quit IRC09:56
*** belen <belen!Adium@nat/intel/x-ooxfbtkerrvwpzqk> has quit IRC09:59
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto10:02
*** alex_kag <alex_kag!~alex_kag@> has quit IRC10:02
*** Krz <Krz!c0c69724@gateway/web/freenode/ip.> has joined #yocto10:04
*** JimBaxter <JimBaxter!> has joined #yocto10:04
*** ka6sox is now known as ka6sox-away10:16
*** panda84kde <panda84kde!> has joined #yocto10:16
*** belen <belen!~Adium@> has joined #yocto10:32
*** JaMa <JaMa!> 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
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!> has quit IRC11:00
*** mario-goulart <mario-goulart!> 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
JaMathere is script to benchmark which value works best for your hardware11:20
JaMagoogle for bb-matrix11:20
*** belen <belen!~Adium@> 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@> has joined #yocto11:22
Crofton|work ?11:22
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@> 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!> has quit IRC11:36
*** amarsman <amarsman!> 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!> 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?
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!> has quit IRC12:07
*** Stygia <Stygia!> has joined #yocto12:07
lpapp -> 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
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
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
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.> 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
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!> has joined #yocto12:29
lpappbluelightning: is that simple to fix?12:30
bluelightningI don't know if the /lib/ 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/* 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}/* ${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}/* ${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!> has quit IRC12:40
lpappbluelightning: ?12:40
lpappERROR: QA Issue: external-sourcery-toolchain: Files/directories were installed but not shipped /lib/
lpappstill getting it.12:41
lpapplibdir might not be working then ...12:41
bluelightningah right, of course. ${libdir} is /usr/lib not /lib12:41
bluelightning${base_libdir} is what you'd need there12: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
*** 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
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!> 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:
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
*** amarsman <amarsman!> 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!> 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
Net147you got the bug report number?13:33
zeddiiI'll track it down. I'm 3 minutes late for a meeting :)13: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
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 .. 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
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
*** jukkar <jukkar!jukka@nat/intel/x-jsopvmlqrmfmooyu> has quit IRC13:51
*** jukkar <jukkar!~jukka@> has joined #yocto13:52
*** _alex_kag_ <_alex_kag_!~alex_kag@> 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!> 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!> has joined #yocto14:11
*** Squix <Squix!> has quit IRC14:19
*** slaine <slaine!~slaine@> 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!> has quit IRC14:29
*** Net147 <Net147!> 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!> 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!> 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
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!> 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
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
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
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@> 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!> has joined #yocto15:44
*** jackmitchell <jackmitchell!> has quit IRC15:44
*** cfo215_ <cfo215_!4473ad42@gateway/web/freenode/ip.> has joined #yocto15:45
*** amarsman <amarsman!> 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
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
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|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
sgw_cfo215_: and if you cut and paste the "invalid file" the COPYING file is really there at that path?16:17
*** galak <galak!> 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@> has joined #yocto16:28
bluelightningcfo215_: I'd suggest naming your recipe as and then you shouldn't need to set S, and your package version will be correct as well16:30
*** sameo <sameo!~samuel@> 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!> 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
*** challinan <challinan!> 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@> 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.
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!> 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-
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):
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!> has joined #yocto16:52
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC16:54
cfo215_bluelightning: 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!> 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
*** belen <belen!~Adium@> has quit IRC17:05
*** Stygia <Stygia!> has quit IRC17:05
flynn278Crofton|work yes, meta-xilnix17: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 -
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:  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
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!> 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
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!> 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
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.> has quit IRC17:32
-YoctoAutoBuilder- build #254 of nightly-non-gpl3 is complete: Failure [failed Building Images] Build details are at
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!> 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
*** mulhern <mulhern!> has joined #yocto17:49
-YoctoAutoBuilder- build #222 of nightly-fsl-ppc-lsb is complete: Failure [failed Building Images] Build details are at
-YoctoAutoBuilder- build #253 of nightly-ppc-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at
*** Krz <Krz!c0c69724@gateway/web/freenode/ip.> 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
-YoctoAutoBuilder- build #66 of buildtools is complete: Success [build successful] Build details are at
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
*** 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
*** mulhern <mulhern!> has quit IRC18:13
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto18:16
-YoctoAutoBuilder- build #28 of eclipse-plugin-kepler is complete: Success [build successful] Build details are at
mr_scienceka6sox: ?18:26
*** dvhart <dvhart!~dvhart@> has joined #yocto18:28
-YoctoAutoBuilder- build #247 of nightly-x86-64-lsb is complete: Failure [failed Building Images] Build details are at
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
*** Jefro <Jefro!> has joined #yocto18:48
*** mulhern <mulhern!> has joined #yocto18:49
*** swex_ <swex_!~swex@> has quit IRC18:58
mranostayhi Jefro18:58
*** swex_ <swex_!~swex@> has joined #yocto19:00
*** zecke <zecke!> has quit IRC19:13
*** JimBaxter <JimBaxter!> has quit IRC19:13
-YoctoAutoBuilder- build #251 of nightly-world is complete: Failure [failed Building Images] Build details are at
*** Crofton|work <Crofton|work!> has quit IRC19:13
*** Crofton|work <Crofton|work!> has joined #yocto19:18
*** mulhern <mulhern!> has quit IRC19:25
*** mulhern <mulhern!> 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
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!> has quit IRC20:08
*** Jefro <Jefro!> has joined #yocto20:17
*** andyross <andyross!> has quit IRC20:20
*** walters <walters!> has joined #yocto20:21
*** nitink <nitink!nitink@nat/intel/x-qqgizzeqxdugsujg> has quit IRC20:23
*** galak <galak!> has quit IRC20:23
*** smartin <smartin!> has quit IRC20:26
*** flynn278 <flynn278!80db310e@gateway/web/freenode/ip.> has quit IRC20:26
-YoctoAutoBuilder- build #253 of nightly-multilib is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #250 of nightly-x86-64 is complete: Failure [failed Running Sanity Tests] Build details are at
*** j8 <j8!~IceChat9@> has quit IRC20:29
*** mulhern <mulhern!> has quit IRC20:31
*** mulhern <mulhern!> 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!> has quit IRC20:56
*** mulhern <mulhern!> has joined #yocto20:59
*** andyross <andyross!> has joined #yocto21:06
-YoctoAutoBuilder- build #255 of nightly-mips is complete: Failure [failed Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #256 of nightly-x86 is complete: Success [build successful] Build details are at
*** nitink <nitink!nitink@nat/intel/x-jjjvdtclunapsdtk> has quit IRC21:19
*** nitink1 <nitink1!~nitink@> has joined #yocto21:19
*** mulhern <mulhern!> has quit IRC21:28
b1gtunaHas anyone successfully configured remote debugging through the ADT? Using USB serial port on a board?21:33
*** Guest90294 <Guest90294!> has left #yocto21:57
*** agust <agust!> has quit IRC22:01
*** jzhang <jzhang!~jzhang@> 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
-YoctoAutoBuilder- build #219 of nightly is complete: Success [build successful] Build details are at
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
-YoctoAutoBuilder- build #260 of poky-tiny is complete: Failure [failed Building Images Publishing Artifacts] Build details are at
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.> 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
b1gtunajzhang: awesome. ty22:49
b1gtunajzhang: glad i asked. It's not something in the manual22:50
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.> 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@> has quit IRC23:01
*** nitink <nitink!nitink@nat/intel/x-mhkqqtxtuodstyoi> has joined #yocto23:01
*** Jefro <Jefro!> has quit IRC23:11
*** mulhern <mulhern!> has joined #yocto23:12
*** Jefro <Jefro!> has joined #yocto23:13
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC23:22
*** sameo <sameo!~samuel@> has joined #yocto23:24
*** hollisb <hollisb!> has quit IRC23:24
*** joeythesaint <joeythesaint!> has quit IRC23:32
*** seebs <seebs!> has quit IRC23:40
*** seebs <seebs!> has joined #yocto23:41
*** mulhern <mulhern!> has quit IRC23:42
*** munch <munch!> has joined #yocto23:46

Generated by 2.11.0 by Marius Gedminas - find it at!