Tuesday, 2014-08-19

*** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto00:01
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC00:01
*** sjolley1 <sjolley1!sjolley@nat/intel/x-lgabdllihzxynbbg> has joined #yocto00:05
*** sjolley <sjolley!sjolley@nat/intel/x-oiyamnhfxnkvwzia> has quit IRC00:07
*** mario-go` is now known as mario-goulart00:20
*** Guest19944 <Guest19944!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC00:35
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC00:43
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto00:45
*** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC01:48
*** Crofton|work <Crofton|work!~balister@pool-108-44-82-131.ronkva.east.verizon.net> has quit IRC01:48
*** sullical_ <sullical_!~sullical@> has quit IRC01:48
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC01:48
*** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto01:57
*** Crofton|work <Crofton|work!~balister@pool-108-44-82-131.ronkva.east.verizon.net> has joined #yocto01:57
*** sullical_ <sullical_!~sullical@> has joined #yocto01:57
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto01:57
*** joran_ <joran_!4cb28f38@gateway/web/freenode/ip.> has quit IRC02:19
*** joran_ <joran_!4cb28f38@gateway/web/freenode/ip.> has joined #yocto02:23
joran_im so confused why isnt my do_install running in my recipe?02:23
joran_I guess its running im just not getting an installable rpm from it :(02:39
*** hsychla_ <hsychla_!~hsychla@port-87-193-170-219.static.qsc.de> has joined #yocto03:00
joran_can anyone tell my why the do_install step here https://gist.github.com/anonymous/c7ab0078c60644f3f81e does not generate an rpm? only the -dbg and -dev rpms03:01
joran_i can see all the .o files in my workdir03:02
*** hsychla <hsychla!~hsychla@pd95c9392.dip0.t-ipconnect.de> has quit IRC03:04
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto03:04
*** hsychla_ <hsychla_!~hsychla@port-87-193-170-219.static.qsc.de> has quit IRC03:04
*** hsychla_ <hsychla_!~hsychla@pd95c9392.dip0.t-ipconnect.de> has joined #yocto03:17
*** Nilesh_ <Nilesh_!~minda@> has joined #yocto03:32
*** sameo <sameo!samuel@nat/intel/x-wxyvgfqwnlcsomam> has joined #yocto03:34
*** GunsNRose_ <GunsNRose_!~GunsNRose@> has joined #yocto03:36
*** Jefro1 <Jefro1!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC03:38
*** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC03:44
*** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto03:44
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC03:56
*** sjolley1 <sjolley1!sjolley@nat/intel/x-lgabdllihzxynbbg> has quit IRC04:11
*** Nitin <Nitin!~nakamble@> has quit IRC04:46
*** sjolley <sjolley!~sjolley@> has joined #yocto04:53
*** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has quit IRC04:54
*** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has joined #yocto04:57
*** melonipoika <melonipoika!~quassel@91-158-65-146.elisa-laajakaista.fi> has joined #yocto04:59
*** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC05:02
*** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto05:02
*** [Sno] <[Sno]!~Sno]@p578b540c.dip0.t-ipconnect.de> has quit IRC05:12
*** lyang0 <lyang0!~lyang001@> has quit IRC05:13
*** sameo <sameo!samuel@nat/intel/x-wxyvgfqwnlcsomam> has quit IRC05:19
*** lyang0 <lyang0!~lyang001@> has joined #yocto05:21
*** agust <agust!~agust@p4FDE7025.dip0.t-ipconnect.de> has joined #yocto05:25
*** khem <khem!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has quit IRC05:35
*** stunpix_ <stunpix_!~Stunpix@> has joined #yocto06:09
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto06:11
*** fabo <fabo!~fabo@linaro/fabo> has quit IRC06:13
*** fabo <fabo!~fabo@a91-152-78-194.elisa-laajakaista.fi> has joined #yocto06:13
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto06:13
*** cristianiorga <cristianiorga!cristianio@nat/intel/x-yguqupebibqqbkor> has joined #yocto06:21
olanijoran_: In the image dir (${D}) you can see all installed files.  If that looks correct check the dirs in packages-split.  Maybe the main package (with the same name as the recipe) is empty? Then you need to use a FILES_${PN] += ".." to make sure the file ends up in the correct package.  The rpm and package splitting is not done by the do_install task, that only installs your files in ${D}.06:32
olanijoran_: Also note that you probably can replace your do_install task with 'EXTRA_OEMAKE += "INSTALL_ROOT=${D}"'06:34
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC06:45
*** tasslehoff <tasslehoff!~Tasslehof@ti0260a430-0477.bb.online.no> has joined #yocto06:49
tasslehoffAfter I dragged in meta-oe it seems that I get errors like "The URL: '${SAVANNAH_GNU_MIRROR}/gpsd/gpsd-3.7.tar.gz' is invalid and cannot be interpreted"06:53
tasslehoffI suspect I have no knowledge about SAVANNAH_GNU_MIRROR06:53
tasslehoffaaah, nevermind. had forgotten to change to daisy after cloning.06:57
*** LetoThe2nd <LetoThe2nd!~jd@unaffiliated/letothe2nd> has quit IRC06:59
*** kroon <kroon!~kroon@> has joined #yocto06:59
*** [Sno] <[Sno]!~Sno]@pd956d8ef.dip0.t-ipconnect.de> has joined #yocto07:03
*** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has joined #yocto07:04
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto07:06
*** stunpix_ <stunpix_!~Stunpix@> has quit IRC07:07
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto07:08
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-jvfcyaxrrqqldrrk> has joined #yocto07:11
*** jbrianceau_away is now known as jbrianceau07:11
*** TobSnyder1 <TobSnyder1!~schneider@ip92343918.dynamic.kabel-deutschland.de> has joined #yocto07:13
*** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has quit IRC07:15
*** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has joined #yocto07:20
*** wrd <wrd!~Thunderbi@> has joined #yocto07:21
*** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has quit IRC07:22
*** roxell <roxell!~roxell@linaro/roxell> has quit IRC07:22
*** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has joined #yocto07:23
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:26
*** LetoThe2nd <LetoThe2nd!~jd@unaffiliated/letothe2nd> has joined #yocto07:30
*** florian_kc is now known as florian07:30
*** ant_work <ant_work!~ant__@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto07:31
*** roric <roric!~roric@> has joined #yocto07:46
lpappI do not get Yocto.... I am saying bitbake -c cleansstate foo; bitbake -c fetch foo, yet the git directory is empty. What may be going on?!07:56
lpappI even tried forcing the fetch with bitbake, but no joy... What more can I do to get the stuff fetched?07:57
*** phantoxe <phantoxe!~destroy@2001:5c0:1400:b::392b> has joined #yocto08:00
lpapphere you can see the debug log from bitbake fwiw: http://paste.kde.org/pl8cke94m08:01
olanilpapp: Try bitbake -c unpack foo08:03
olanilpapp: fetch downloads to ${DL_DIR}, unpack then unpacks/clones/whatever to ${S}08:06
*** dse <dse!~d.s.e@2001:a60:1424:ca01:d825:80f5:6d95:effd> has joined #yocto08:06
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto08:10
lpappolani: ah, great, thank you.08:12
-YoctoAutoBuilder- build #205 of poky-tiny is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/20508:22
*** AlexVaduva <AlexVaduva!c1ca1642@gateway/web/freenode/ip.> has quit IRC08:28
*** olani <olani!user@nat/axis/x-pcytcqfnkmocsvrc> has quit IRC08:28
*** bluelightning <bluelightning!~paul@> has joined #yocto08:30
*** bluelightning <bluelightning!~paul@> has quit IRC08:30
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:30
bluelightningmorning all08:30
lpapphow would I go about solving this? NOTE: multiple providers are available for runtime packagegroup-foo-dbg (packagegroup-foo-dbg, packagegroup-foo)08:32
lpappNOTE: consider defining a PREFERRED_PROVIDER entry to match packagegroup-foo-dbg08:32
lpappmy -dbg image inherits the non-dbg image cause that sets up some stuff... hence the packagegroup-foo thing... shall I move the shared parts out into a common file, or shall I use that PREFERRED_PROVIDER, or what is the best practice?08:33
bluelightninglpapp: other than not having multiple runtime providers, you can't right now: https://bugzilla.yoctoproject.org/show_bug.cgi?id=614908:33
yoctiBug 6149: normal, Medium, 1.7, paul.eggleton, NEW , Setting PREFERRED_PROVIDER to select between multiple runtime providers does not work08:33
lpappbluelightning: ok, so I should put the shared part into a shared include file?08:34
bluelightningno, that won't accomplish anything08:34
bluelightningwhat are you trying to do exactly?08:34
lpappbluelightning: well, I have two images, one debug and one non-debug08:35
*** olani <olani!user@nat/axis/x-narxbrbkygdpjqje> has joined #yocto08:35
lpappthe debug image is almost the same, except that it gets the -git version of our software.08:35
lpappand built with -O0 -g -DDEBUG, etc.08:35
lpappwhy wouldn't that accomplish anything?08:35
lpappthen, I would not include the non-dbg image into the -dbg anymore, just the shared part.08:35
lpappso there could be no clashing stuff IMHO08:36
bluelightningif you just don't call it -dbg you won't have the problem08:36
lpappthe image, the packagegroup, both or what exactly?08:37
lpapp(and why will I not have the problem then?)08:37
lpappbluelightning: ^08:40
bluelightningthe packagegroup08:40
bluelightningbecause they then will not overlap...08:40
lpappbluelightning: what do you mean by overlap?08:45
lpappbitbake only checks if the _names_ overlap, and not the actual package list?08:45
bluelightningwhat is in PACKAGES goes into RPROVIDES, and that gets checked08:46
lpappI am not sure I follow.08:48
*** EddyLaiTW <EddyLaiTW!~eddylai@61-231-113-247.dynamic.hinet.net> has joined #yocto08:48
lpappI guess the solution is to wipe everything away and wait 2 hours. :/08:49
lpappbut it is so frustrating to do this all the time for so many issues.08:50
*** wrd <wrd!~Thunderbi@> has quit IRC08:52
*** wrd <wrd!~Thunderbi@> has joined #yocto08:53
lpappbluelightning: I will try out moving the shared part into foo-core-image.inc and include that both in the release and debug images.08:58
lpappI think pretty much the whole foo-core-image.inc must be shared, except IMAGE_INSTALL += " packagegroup-foo" since that will be IMAGE_INSTALL += " packagegroup-foo-dbg" in the dbg image.09:00
*** stuartw__ <stuartw__!~stuartw@> has joined #yocto09:00
lpappand IMAGE_FEATURES += "dbg-pkgs" + description.09:03
*** stuartw__ <stuartw__!~stuartw@> has quit IRC09:04
*** jaro123_ <jaro123_!2e242307@gateway/web/freenode/ip.> has joined #yocto09:06
lpappbluelightning: yeah, strange, I am still getting the warning, although the -dbg image now only contains the -dbg package group, not both.09:06
lpappis there a way to gently wipe the main image away to be able to generate the debug without losing all the separate package builds?09:07
olanilpapp: I just read your bug report and I think your problem is that you have packagegroups and/or recipes that have names ending in -dbg.  Each recipe/packagegroup may create a package (rpm-file) that is names ${PN}-dbg.  Common practice in most linux distributions I believe.  These names clash, thus the warning.  Or maybe I just misunderstand everything :)09:07
bluelightninglpapp: wiping things out will not solve this, you'll just get the same error again09:07
lpappolani: 1) It is not my bugreport 2) OK, well, I will rename it to -git then.09:07
lpappbluelightning: nope, because I would type bitbake foo-core-image-dbg09:07
bluelightningolani is correct, the -dbg name is the source of your problems (as I pointed out half an hour ago)09:08
lpappit worked yesterday; why I am getting this is because I made the SDK out of the normal image first now.09:08
lpappbluelightning: I do not agree that it should be the source of the problem.09:08
olanilpapp: Not a good choice either.  Use -debug.09:08
lpappIMHO, Yocto should fix it up. It is completely good to have dbg images and hence package groups09:08
lpappWhat is wrong about creating a debug image? As far as I understand, that is the right way of getting a debugable image after all, so why does Yocto not accept the right way?09:09
lpappand creating -dbg stuff automatically out of release does not make any sense to me since release is not built with the right flags (obviously).09:09
lpappthey _do_ need to be separate builds from the ground up.09:09
lpappyou cannot just get debug stuff out of a non-debug build, or I may have missed something the last ten years in software development :)09:10
bluelightningthere is nothing wrong with the use case, it's solely about the naming09:10
lpappnaming should match the use case IMHO09:10
bluelightningpackagegroups already have handling for -dbg packages though, unless you override PACKAGES09:10
lpappolani: why not a good choice? -debug, I would _rather_ not use it. How will I know the difference between -debug and -dbg half a year later?09:10
bluelightningso your naming clashes with that09:10
lpapp(I simply will not, I can guarantee that, and I will struggle)09:11
lpappthere oughta be a way that I can tell Yocto, _this_ is the dbg stuff that I cooked together.09:11
lpappand not what it thinks it is.09:12
olanilpapp: I think -git can be used as a package version suffix in some cases.  It might not clash in this case.09:12
*** belen <belen!Adium@nat/intel/x-aqokqxiuybjhtktg> has joined #yocto09:13
lpappbluelightning: let me ask you this question: if the release image is not built with -g -O0 for obvious reasons (sparing space), how will PG have handling for -dbg the way that I can debug the image properly?09:13
lpappbluelightning: non-stripped != debug.09:13
bluelightningwhat do you mean by debug?09:13
lpapp-g -DDEBUG -O0 at the very least.09:14
bluelightningdo you mean, you have the symbols such that gdb can display proper backtraces?09:14
lpappit seems that Yocto has a fundamental flaw of thinking debug is equal to non-stripped release binaries.09:14
lpappI think that should be addressed, otherwise we developers will be locked out from proper debugging, or at least we need to apply sub-optimal workarounds.09:15
lpapp(or at least Yocto should use those flags automatically for -dbg, although different projects might prefer different flags... which means it should be possible that the developer tells Yocto what -dbg means)09:16
bluelightningcould you answer my question please?09:17
lpappI think I did: 10:13 < lpapp> -g -DDEBUG -O0 at the very least.09:17
bluelightningso -DDEBUG means no, then09:18
bluelightningwe don't have any explicit handling for this kind of situation, no09:18
lpappthat is my main problem, yeah.09:18
lpappI will submit a bugreport for it...09:18
bluelightningcould we? possibly, yes, but it would be outside of what we understand with the -dbg packaging we currently have, that is only for debugging symbols09:18
lpappit is crucial for cooking proper debug environment.09:19
lpappwithout this, it is painful to make a nice debugging environment which is essential for maintaining software.09:19
bluelightningif you want to implement that, you're more than welcome to do so09:19
*** belen <belen!Adium@nat/intel/x-aqokqxiuybjhtktg> has quit IRC09:19
lpappis there a better workaround than calling it -debug?09:20
lpappI already see my colleagues asking for explanation what the difference is between -debug and -dbg, rightfully though...09:20
*** belen <belen!Adium@nat/intel/x-oxhhljznayqunolb> has joined #yocto09:20
lpappand I cannot use git either ...09:20
olanilpapp: Package names ending in -dbg are reserved by the system, you cannot add any yourself.  It's no more complicated than that.  It can't be the first time you have happened across reserved identifiers.09:23
olanilpapp: I'm not sure about -git, maybe that works.  I just wouldn't recommend it as '-git' is added as part of the version string in some cases.09:27
lpappare you saying that this flaw cannot be worked around "nicely"?09:45
lpappI would hate spending my time explaning to this to developers why it is called -debug and hear the complaints that it is confusing since I would agree with them.09:46
lpappexplaining this*09:46
*** stunpix_ <stunpix_!~Stunpix@> has joined #yocto09:48
lpappI will call it -git for now for sanity and let us see if it breaks at some point... thanks.09:49
lpappshould I also rename the image from foo-dbg or it is only for the packagegroup here?09:51
lpappbluelightning: ^09:51
bluelightningI can't be sure, but since the image recipe doesn't do any packaging it shouldn't theoretically be an issue09:51
olanilpapp: We do use an image recipe ending in -dbg.  That works.09:52
lpappERROR: Nothing PROVIDES 'foo-image-core-dbg'09:52
lpappmy dbg image does not work anymore?09:53
lpappah, sorry, core-image, not image-core09:53
*** stunpix_ <stunpix_!~Stunpix@> has quit IRC09:53
lpappbluelightning: olani ok, thanks, I will leave it there.09:53
lpappso why is the -dbg image still not created in ./tmp/work/foo-foo-linux-gnueabi/?09:56
lpappolani: bluelightning ^09:56
lpappI do not get the warning, yet it is not created for bitbake foo-dbg, I even tried -c cleansstate before that just in case.09:57
lpappI only have the foo image populated in there.09:57
bluelightningwhat is your bitbake command line?09:58
lpappbitbake foo-dbg where foo-dbg is the dbg image name.09:58
lpappfoo-core-image-dbg to be fair, but yeah09:59
lpappI also tried bitbake -c cleansstate foo-core-image-dbg; bitbake foo-core-image-dbg09:59
lpappdo_rootfs is running fwiw.10:00
lpapphow can I force to populate it?10:02
bluelightningthere shouldn't need to be any forcing10:04
*** joran_ <joran_!4cb28f38@gateway/web/freenode/ip.> has quit IRC10:04
lpappbluelightning: ok, so what is the problem then?10:04
bluelightningno idea10:04
bluelightningif it's running do_rootfs then it is building the image10:04
lpappit is finishing without issues.10:04
bluelightningbitbake -e foo-dbg | grep ^WORKDIR= if you're unsure as to where the work directory is ending up...10:05
lpappI know where it ends up based on the last successful builds.10:05
lpappit ought to be beside the foo image, but let me confirm that.10:05
lpappI see only pseudo, temp and foo-core-image-dbg-1.0 there, but the last one is an empty directory.10:06
lpappthis is the image recipe content, fwiw: http://paste.kde.org/prst69mup10:07
lpappand the .inc file only has things like these: http://paste.kde.org/pad324bx310:08
lpappbluelightning: olani do you see any issues with those short files?10:29
bluelightningnothing at a glance10:29
*** RzR <RzR!~RzR@> has joined #yocto10:30
lpappbluelightning: ok, thanks.10:30
lpappRzR: hi there!10:30
RzRhi there didnt know you were hacking on y!10:30
RzRbtw, i am not10:31
lpappRzR: well, I am not hacking on Yocto, just using it.10:31
*** fenrig <fenrig!5ee22386@gateway/web/freenode/ip.> has joined #yocto10:33
*** slips <slips!~quassel@mail.tomra.no> has joined #yocto10:35
fenrigI'm using the BeagleBoneBlack, I want to add an spi module to the system and like to write an kernel module for it (with sockets!!!!). But I need to know how to efficiently modify the device tree from within (openembedded/yocto/poky), can I integrate this in the recipe of my kernel module?10:35
*** AndersD <AndersD!~anders@c83-252-255-124.bredband.comhem.se> has joined #yocto10:41
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto10:42
lpappRzR: do you wanna build Tizen with Yocto ?10:45
-YoctoAutoBuilder- build #182 of nightly-deb is complete: Failure [failed Running Sanity Tests_1] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-deb/builds/18210:51
*** ddom <ddom!~ddom@p4FFD9115.dip0.t-ipconnect.de> has joined #yocto10:51
*** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC10:51
fenrigNobody used yocto/openembedded when they had to modify the device tree?10:53
-YoctoAutoBuilder- build #209 of nightly-fsl-ppc-lsb is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/builds/20910:54
-YoctoAutoBuilder- build #207 of minnow-lsb is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/minnow-lsb/builds/20710:55
lpappbluelightning: can you tell me a workaround?10:55
*** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto10:55
lpappbluelightning: how to enforce the generation?10:55
bluelightninglpapp: I don't know what the problem is...10:55
lpappbluelightning: how to pin that down?10:55
bluelightningread logs for the image, add debug messages ...10:56
lpappbluelightning: which log is interesting in this case?10:58
lpappdo_rootfs or something else?10:58
bluelightningwell, log.do_rootfs I would have thought, since that's where the actual image construction happens...10:58
lpappok, well, I am wiping stuff away as I cannot find anything. Let us hope it works afterwards.11:08
bluelightningI'm almost positive that won't help, but up to you11:10
lpappwell, it used to work.11:11
lpappand since there is no better idea, I do not have anything to lose either.11:12
*** tmpsantos <tmpsantos!~tmpsantos@> has joined #yocto11:14
soderstromlpapp: What is you goal? If you just ignore all the problems. What are you trying to achieve?11:14
lpappsoderstrom: that sounds a bit non-constructive, but of course, you are more than welcome not to "ignore" the problem and provide suggestion!11:16
lpapp(fwiw I am not paid by Intel or anyone else for working on Yocto, and that is good that way)11:18
soderstromlpapp: Instead of focusing on the problems, maybe you can take a step back and focus on task at hand?11:19
*** microd <microd!~cobra-adm@amper.esg.de> has joined #yocto11:20
soderstromThat is why I am asking, what is your goal? What are you trying to do? Can you explain it?11:22
yoctiBug 6636: normal, Undecided, ---, saul.wold, NEW , Yocto does not understand what a debug package might really be11:25
lpappsoderstrom: it is all said above. I do not have time to reiterate it, sorry.11:26
lpappnor actual interest since the rebuild already started anyway.11:27
RzRlpapp: there are work in progress on that ... but I just came here to find someone who had similar issues w/ gst11:31
lpappRzR: what issue ?11:32
RzRlpapp: allways diplomatic11:32
RzRlpapp: something w/ Qt+gst+libva11:32
RzRtotally unrelated to yocto project ;)11:33
T0mWDoes bitbake -c cleanstate <recipe> remove / reset tthe stored sstate-cache info ?  Like it never really happened?11:36
lpappyou mean cleansstate?11:37
T0mWI've done -c clean but then seen the sstate-cache restore the build data instead of doing an actual rebuild.11:37
T0mWlpapp: yeah11:37
lpappyeah, cleansstate, not clean.11:37
T0mWWondering how to do that without a -c cleanall11:38
lpappbitbkake -c cleansstate <recipe>11:38
lpappor you can just force whatever action you wish to do again AFAIK.11:38
T0mWyes, ok, greate.11:38
T0mWyes, ok, great.11:38
T0mWno coffee yet this morning.11:38
-YoctoAutoBuilder- build #186 of nightly-ipk is complete: Failure [failed Running Sanity Tests_1] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-ipk/builds/18611:47
*** fenrig <fenrig!5ee22386@gateway/web/freenode/ip.> has quit IRC11:54
lpappbluelightning: hmm, yeah, it is still empty, grrr.11:56
lpappI am so confused; it is likely because of the shared content separation. I will revert that change.11:57
*** LocutusOfBorg1 <LocutusOfBorg1!~Gianfranc@> has joined #yocto12:03
lpappbluelightning: the "fun" thing is that ./tmp/deploy/images is populated, just not the root fs ...12:08
*** Nilesh_ <Nilesh_!~minda@> has quit IRC12:15
lpappshouldn't do_rootfs generate an error or at least a warning if it cannot create the rootfs?12:20
*** joran_ <joran_!4cb28f38@gateway/web/freenode/ip.> has joined #yocto12:23
bluelightningit won't be solely because of the inc file12:23
joran_hey guys12:23
joran_can anyone tell my why the do_install step here https://gist.github.com/anonymous/c7ab0078c60644f3f81e does not generate an rpm? only the -dbg and -dev rpms12:23
lpappbluelightning: would you like to see the do_rootfs log? I cannot spot anything obvious out of it, even though I see some errors in there, but nothing new.12:24
joran_I can see in the image directory it builds all the .o files ... but all I can find in terms of binaries are the -dev and -dbg12:24
olanijoran_: In the image dir (${D}) you can see all installed files.  If12:24
olanithat looks correct check the dirs in packages-split.  Maybe the main12:24
olanipackage (with the same name as the recipe) is empty? Then you need to12:24
olaniuse a FILES_${PN] += ".." to make sure the file ends up in the correct12:24
olanipackage.  The rpm and package splitting is not done by the do_install12:24
olanitask, that only installs your files in ${D}.12:24
joran_hey olani cool your still here12:24
joran_ok checking noww12:25
joran_thanks :)12:25
lpappbluelightning: hmm, may it be due to rm_work?12:27
bluelightninglpapp: oh... yes, that would do it12:29
lpappyes, I tested it.12:29
lpappwhat is the best practice to exclude that rule for the debug image only?12:30
joran_so {workdir}/image/usr/bin is empty12:30
joran_{workdir} contains all the .o files12:31
joran_im an idiot I think I found it ...12:33
joran_dang I feel dumb sometimes12:34
*** jkridner <jkridner!~jkridner@rrcs-64-183-219-162.sw.biz.rr.com> has joined #yocto12:34
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto12:34
joran_its cause it was named something other than its bitbake recipe name in the qmake file12:34
joran_so the file was there all along I just didnt see it cause i was looking for the wrong name12:35
bluelightninglpapp: add it to RM_WORK_EXCLUDE12:40
-YoctoAutoBuilder- build #207 of nightly-x86-64-lsb is complete: Failure [failed BuildImages BuildImages_1] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/builds/20712:41
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC12:41
*** ddalex <ddalex!~ddalex@> has joined #yocto12:44
lpappbluelightning: is it ok to do that in the -dbg image recipe?12:47
bluelightninglpapp: AFAICT yes12:48
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has quit IRC12:48
*** Nilesh_ <Nilesh_!~minda@> has joined #yocto12:54
lpappbluelightning: I will test it, thanks.12:55
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC13:08
aimetis0khem: I checked the sysroot folder and there is nothing. In the recipe, I installed these libs in /usr/bin but I cannot find them in tmp/sysroot/<machine>/usr/bin. I guess I must miss something.13:09
*** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto13:10
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC13:13
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto13:14
*** ivanstojanovic <ivanstojanovic!~evo@vpn.anton-paar.com> has joined #yocto13:26
ivanstojanovicdoes anyone have experience with QtGstreamer on imx6?13:27
ivanstojanovicI am trying to add video support on imx6...I managed to deploy gstreamer1.x, gst-play-1.0 works with big-bucks-bunny, QT5 works, but I'm struggling to get QtGStreamer example working13:30
*** sjolley <sjolley!~sjolley@> has quit IRC13:30
*** AndersD <AndersD!~anders@c83-252-255-124.bredband.comhem.se> has quit IRC13:38
*** tasslehoff <tasslehoff!~Tasslehof@ti0260a430-0477.bb.online.no> has quit IRC13:44
*** kroon <kroon!~kroon@> has quit IRC13:48
*** sjolley <sjolley!~sjolley@> has joined #yocto13:49
*** joran_ <joran_!4cb28f38@gateway/web/freenode/ip.> has quit IRC13:52
*** _rink <_rink!~rink@gloom.codethulu.net> has joined #yocto13:59
_rinkhi all!13:59
_rinkanyone here maintainer of dosfstools ?13:59
_rinkor knowledgable about it?13:59
bluelightning_rink: I'm the maintainer, though I haven't done much maintenance with it lately14:00
bluelightningI think there is a reason we're stuck on an older version but I don't remember offhand what it is14:00
_rinkgplv3 maybe?14:00
*** Nilesh_ <Nilesh_!~minda@> has quit IRC14:00
bluelightningthat could be it yes14:00
Crofton|workwe can add a v3 version, just need to keep the v2 one14:01
_rinkthere's a pretty annoying but in it, causing it to die due to memory corruption while repating a filesystem14:01
_rinkI made a patch based on the fedora core (i think it was) bug report14:02
_rinkand added a tiny change based on their git history14:02
* _rink unsure if that is acceptable to include ?14:02
_rinkthe fix is quite trivial if you know what the problem is14:02
bluelightningis the patch against the GPLv2 version though?14:03
bluelightningok, as long as it doesn't break anything I think it should be acceptable14:05
_rinkhttps://bugzilla.redhat.com/show_bug.cgi?id=674095 is where I got the patch from where I based my work on14:06
yoctiBug 674095: was not found.14:06
_rinkthe patch there is incomplete14:06
_rinkbut this patch eppears to be against 3.0.9-4.fc1414:07
_rink[not that the code has changed] - and the author does not say anything about licensing14:07
bluelightningah, in that case we may have a problem14:08
_rinkyeah, thought was much.14:08
bluelightningbecause the patch was intended for a newer version, we have to assume the license is the same in the absence of some explicit statement to the contrary from the author14:08
_rinkhowever, the patch there is incomplete14:09
_rinkI could e-mail the author and ask if it's okay to use his 3 lines as gplv2 ?14:09
* _rink notes, seems like a lot of work for such a silly patch14:09
bluelightning_rink: it is a bit of a pain I agree; we're not left with much of a choice given the license incompatibility though :(14:15
*** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto14:16
_rinkbluelightning, well, I'd be willing to do the legwork to get the patch in the tree; should I just e-mail the original author and ask if he agrees with my pathc (which is based on his) being licensed as GPLv2 ?14:16
bluelightning_rink: yes, that would be great if you could do that, hopefully they say yes and then we can include their statement in the patch header14:17
_rinkokay, i'll get back to you on this :)14:17
*** jaro123_ <jaro123_!2e242307@gateway/web/freenode/ip.> has quit IRC14:26
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto14:29
*** kevin_t <kevin_t!~Thunderbi@> has quit IRC14:30
*** kevin_t <kevin_t!~Thunderbi@> has joined #yocto14:31
*** [Sno] <[Sno]!~Sno]@pd956d8ef.dip0.t-ipconnect.de> has quit IRC14:31
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto14:31
*** EddyLaiTW <EddyLaiTW!~eddylai@61-231-113-247.dynamic.hinet.net> has quit IRC14:34
lpappbluelightning: does -c cleansstate make sense on images?14:35
bluelightningnot really, do_rootfs isn't an sstate task14:35
lpappsay, I want to comment the debug-without-src option in my local conf, and regenerate the image respectively?14:35
lpappwhat am I supposed to do to achieve that?14:36
bluelightningit should be able to tell by itself if rebuilding the image is necessary14:36
bluelightningif it can't, that is a bug; you can work around it by doing e.g. bitbake -C rootfs imagename14:36
lpappbluelightning: I wonder if debug-without-src actually is more relevant to the individual packages than the image creation.14:38
bluelightningit should flow from those to the image in terms of the signature changing14:38
lpappbluelightning: ok, thanks.14:42
lpappbluelightning: anyway, I was pretty stupid using this option since the sources will be on the host anyway, so the more the merrier.14:42
*** dduri <dduri!72c78092@gateway/web/freenode/ip.> has joined #yocto14:53
*** dduri <dduri!72c78092@gateway/web/freenode/ip.> has quit IRC14:56
aimetis0Does anyone know how to put files into tmp/sysroot folder?15:00
lpappaimetis0: what files?15:01
aimetis0just some lib files15:01
lpappit is automatically done if you are doing the right things.15:01
*** fusman <fusman!~fahad@> has quit IRC15:02
aimetis0lpapp: I have two mono packages. Packages A needs some libs built by Package B. I don't know how to put libs in sysroot15:02
lpappah, like that, I do not know.15:03
aimetis0lpapp: I listed Package B as depends in Package A recipe but there is nothing in the sysroot15:04
aimetis0lpapp: but do you know generally how we can put files into sysroot manually regardless of mono?15:06
aimetis0I heard it has something to do with sysroot staging15:09
lpappno, but why would you like to get it to there?15:10
lpapp0x44ad26ec in select () at ../sysdeps/unix/syscall-template.S:8115:12
lpapp81      ../sysdeps/unix/syscall-template.S: No such file or directory.15:12
lpappI keep getting this with Yocto, when debugging inside, why?15:12
ant_workaimetis0: there is maybe some renaming?15:13
aimetis0lpapp: because the libs built by Package B is the build time depends of Package A and others. I heard the only way to share them in the build time to put them into the sysroot and list the Package B in the recipes that demand them.15:13
ant_workyou are talking about 'libs'15:13
ant_workaimetis0: copying and pasting:15:14
ant_work* DEPENDS = "b" in recipe "a" will translate to a's do_configure task depending15:14
ant_workon recipe b's do_populate_sysroot task15:14
*** manuel__ <manuel__!~manuel_@p57921144.dip0.t-ipconnect.de> has joined #yocto15:14
aimetis0ant_work: Yes, but it is needed in the build time15:15
ant_workofc, at configure stage it is expected the headers are staged15:15
ant_workI'm talking about build, not runtime15:15
ant_workDEPENDS means a build-time dependency15:16
ant_workI guess the lib is gettin grenamed and it is not found...15:16
aimetis0ant_work: I declared DEPENDS in recipe but it didn't put anything in the sysroot15:17
ant_workpls verify15:17
aimetis0ant_work: I am wondering if I need to write the do_populate_sysroot function15:19
*** roxell <roxell!~roxell@c-853670d5.07-21-73746f28.cust.bredbandsbolaget.se> has joined #yocto15:19
*** roxell <roxell!~roxell@linaro/roxell> has joined #yocto15:19
ant_workaimetis0: don't go off-track ;)15:19
ant_workpls inspect the WORKDIR of the packages and check how these are built and packaged15:20
*** khem` <khem`!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has joined #yocto15:21
aimetis0ant_work: Yes, the dependency is built and packed in its workdir15:22
ant_workaimetis0: what is the exact error you get? Can you paste it?15:22
lpappbluelightning: hey, why is Yocto not installing eglibc-source properly?15:23
lpappI think that is why I see the above error.15:23
aimetis0ant_work: WebDeviceDiscovery/DeviceDiscoveryImpl.cs(7,7): error CS0246: The type or namespace name `DeviceAutoDiscovery' could not be found. Are you missing an assembly reference?15:25
aimetis0ant_work: it seems that it still could not find the libs it depends15:26
*** wrd <wrd!~Thunderbi@> has quit IRC15:28
ant_workwhat's th eexpected library then?15:28
aimetis0ant_work: the DeviceAutoDiscovery.dll is expected and it is built by the recipe "discover-devices.bb".15:29
*** cbzx <cbzx!~cbzx@> has joined #yocto15:29
ant_workwhat do the logs of above recipe say? Is it a private recipe?15:30
ant_work(google doesn't know about it)15:31
aimetis0ant_work: yes, it is a private recipe15:31
*** TobSnyder1 <TobSnyder1!~schneider@ip92343918.dynamic.kabel-deutschland.de> has quit IRC15:31
ant_workcheck the logs, each task has one15:32
*** sameo <sameo!~samuel@> has joined #yocto15:33
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC15:34
*** khem` <khem`!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has quit IRC15:35
aimetis0ant_work: the situation is that discover-devices.bb builds the dll and the dll is need by decoder-service.bb. Both recipes are private recipes15:35
*** cbzx <cbzx!~cbzx@> has quit IRC15:35
*** cbzx <cbzx!~cbzx@> has joined #yocto15:36
aimetis0ant_work: I listed discover-devices as dependency of decoder-service. I guess the problem is decoder-services.bb just doesn't know where to get the dll15:37
ivanstojanovicHi guys, I have a qtmultimedia related question. As far as I can see, qtmultimedia uses GStreamer's xvimagesink for a video support. Why is that hard-coded? I want to use it with e.g. imxeglvivsink. How should I achieve it?15:40
*** dse <dse!~d.s.e@2001:a60:1424:ca01:d825:80f5:6d95:effd> has quit IRC15:41
ant_workaimetis0: I'm sorry to say that but I'd need a crystal ball...first I wonder what you're doing with a .dll (emulator?), second I cannot guess what is installed in the machine sysroot15:45
ant_workthe logs in workdir/recipe/tmp should help you15:46
*** roric <roric!~roric@> has quit IRC15:46
aimetis0ant_work: in recipe decoder-service, I have put "DEPENDS += discover-devices" and decoder-service.bb expects the dll gets placed in the <package>/src folder. I guess I need to write the do_configure function to place the dll there in the decoder-service recipe. The problem is how do I ask discover-devices.bb to put the dll in sysroot or somewhere else and let decoder-service to get it, put into15:47
aimetis0the source folder, and start to build decoder-service15:47
aimetis0ant_work: the dll is just a shared dynamic library. It is built by discover-devices.bb and it is used by decoder-service.bb to build decoder-service.exe15:50
ant_workCan you tell what kind of Distro/Image are you building?15:51
aimetis0ant_work: cortexa9hf-vfp-neon, I guess15:52
*** khem` <khem`!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has joined #yocto15:53
ant_workok, it is a final image for <target>15:53
*** khem` is now known as khem15:53
ant_workhi khem15:53
ivanstojanovichello :)15:54
aimetis0ant_work: decoder-service and discover-devices are mono projects15:54
ant_workaimetis0: then you have one specific sysroot for <target> machine15:54
ant_workyou can verify its path inspecting the log. and run. files under /tmp15:55
aimetis0ant_work: I checked the tmp/sysroot folder and there are three subfolders, imx6qsabresd  imx6qsabresd-tcbootstrap  x86_64-linux15:55
*** kevin_t <kevin_t!~Thunderbi@> has quit IRC15:55
*** yzhao2 <yzhao2!~yzhao2@> has quit IRC15:55
ant_workfirst one is <target>, second is temporary, ignore it, third is -native, the build-host15:56
aimetis0ant_work: log. and run. files are stored in ~/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/discover-devices/git-r0/temp/15:57
ant_workpls check what has been installed in sysroot/imx6qsabresd/usr15:57
*** jbrianceau is now known as jbrianceau_away15:58
aimetis0ant_work: just one folder called crossscripts under sysroot/imx*/usr/bin15:58
ant_workhm.. then /include, .. /lib... look around15:59
ant_workthe logs should point you to the right path15:59
aimetis0ant_work: I did a complete search in sysroot folder and there is nothing16:00
ant_workare you then building a -native recipe?16:01
ant_workwhere did the recipe put the files?16:01
*** cbzx <cbzx!~cbzx@> has quit IRC16:01
aimetis0ant_work: what is a -native recipe?16:01
ant_workwhat does install and populate_sysroot say?16:01
ant_workpls read the logs thoroughfully16:02
ant_workheh, new word !16:02
aimetis0ant_work: I put the dll in ${bindir}, "install -m 0775 ${S}/DeviceDiscovery/obj/Debug/DeviceAutoDiscovery.dll ${D}${bindir}"16:03
*** kevin_t <kevin_t!~Thunderbi@> has joined #yocto16:03
*** yzhao2 <yzhao2!~yzhao2@> has joined #yocto16:03
aimetis0ant_work: the install log only has two lines: DEBUG: Executing shell function do_install DEBUG: Shell function do_install finished16:05
ant_workcheck the run. file as well16:05
aimetis0ant_work:  install -m 0775 ~/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/discover-devices/git-r0/git//DeviceDiscovery/obj/Debug/DeviceAutoDiscovery.dll ~/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/discover-devices/git-r0/image/usr/bin16:07
-YoctoAutoBuilder- build #211 of nightly-x86-64 is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/21116:07
-YoctoAutoBuilder- build #206 of nightly-x86 is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/20616:07
-YoctoAutoBuilder- build #212 of build-appliance is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/build-appliance/builds/21216:07
-YoctoAutoBuilder- build #205 of nightly-qa-logrotate is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/20516:07
-YoctoAutoBuilder- build #208 of nightly-qa-skeleton is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/builds/20816:07
-YoctoAutoBuilder- build #205 of nightly-qa-pam is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-pam/builds/20516:07
-YoctoAutoBuilder- build #205 of nightly-fsl-ppc is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc/builds/20516:07
-YoctoAutoBuilder- build #213 of nightly-intel-gpl is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/21316:07
-YoctoAutoBuilder- build #204 of nightly-fsl-arm-lsb is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm-lsb/builds/20416:07
ant_workso as you see it goes indeed in ${D}${bindir}16:08
aimetis0ant_work: yes16:08
-YoctoAutoBuilder- build #202 of nightly-ppc-lsb is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/builds/20216:08
ant_worknow I maybe see the problem...I'd not put that in bindir16:08
-YoctoAutoBuilder- build #185 of nightly-rpm is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-rpm/builds/18516:08
ant_worktry libdir16:08
lpappfray_: ping16:09
aimetis0ant_work: you mean I need to change the install path from bindir to libdir?16:09
ant_workaimetis0: or adjust the other recipe to point to the right dir...maybe it i not in path16:09
kergothAnyone seen the 'cpio' image fstype working but cpio.gz not? I'm guessing it could be related to the COMPRESS_CMD stuff16:10
kergothalso, looks like IMAGE_FSTYPES was never added to the do_rootfs vardeps when things were split into oe.image (yet another missing variable dep..)16:10
* kergoth rolls eyes16:10
ant_workkergoth: .gz and .lzma ok in meta-handheld16:10
fray_I've had reports in the past it didn't work -- but those turned out to be kernel configuration16:10
aimetis0ant_work: do you need to see the populate_sysroot log. and run. files as well?16:10
lpappfray_: was it you with whom I discussed gdb issues? I cannot recall.16:11
lpappfray_: so apart from -s and -e, I will also need to specify -directory/-d to the source folders that Yocto generates on the image, yeah?16:11
*** fusman <fusman!~fahad@> has joined #yocto16:13
fray_no, the source folders are relative to the debug image..16:13
fray_so the system should resolve those automatically16:13
fray_basically the binary has a reference in it to the .debug version, which GDB (on the target) should be able to read automatically.. on the cross side, it should get the reference as well and load.. otherwise you have to load the first .debug manually..16:15
fray_withint he debug symbols is the dwarf information, the dwarf information is written to be '/usr/src/<recipe>/<files>'..16:15
ant_workaimetis0: check out the STAGING_ vars in conf/bitbake.conf16:15
fray_GDB cross should reference teh /usr/src based on the debug root..16:15
fray_while GDB on the target will just use the path and find the source files directly..16:16
-YoctoAutoBuilder- build #206 of poky-tiny is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/20616:16
lpappfray_: well, I am getting no such file or directory in gdb16:16
fray_on which, the source?16:16
fray_is it showing you the '/usr/src/debug/recipe/...'?16:17
fray_and this is cross?16:17
ant_workkergoth: fwiw we use INITRAMFS_FSTYPES16:17
lpappfray_: I think .debug/foo is found, but that does not contain the source.16:17
lpappfray_: I am using gdbserver and gdb.16:18
fray_correct, but it should contain the dwarf references to /usr/src/debug.. which path is it saying "/no such file or directory' to?16:18
lpappfray_: 81      ../sysdeps/unix/syscall-template.S: No such file or directory.16:19
lpapp906     src/foo.c: No such file or directory.16:19
lpappsrc/foo.c is my own file.16:19
fray_ahh.. ok.. there will be some sources that are not available16:19
fray_Did you compile this using OE, or directly with the compiler?16:19
*** Nitin <Nitin!nakamble@nat/intel/x-fopiihskbnavrlby> has joined #yocto16:20
*** seebs <seebs!~seebs@home.seebs.net> has quit IRC16:20
lpappfray_: bitbake foo-core-image-dbg16:20
fray_if you compiled with OE, it build the -dbg package and moved all of the references.. if you build this one item by hand, the reference won't be moved and you'll have to add an additional source search path to GDB16:20
-YoctoAutoBuilder- build #204 of nightly-qa-extras is complete: Failure [failed BuildImages Running Sanity Tests BuildImages_1 Running Sanity Tests_1] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-qa-extras/builds/20416:20
lpappfray_: I am only using bitbake, nothing outside of it in this experiment.16:21
fray_the syscall-template.S and a few others usually won't be available to you.. these files are not available to the code that does the redirect..16:21
lpappfray_: if I specify -d ./tmp/work/foo-foo-linux-gnueabi/foo-core-image-dbg/1.0-r0/rootfs/usr/src/debug/foo/AUTOINC+0c2cbe33e653afa335ca25156d293552001228fa-r0/git/src/ for gdb, it can see the source16:21
lpappbut it cannot find it by default ...16:21
fray_ok, then check the log files for the build of your app..  check that there are no warnings or errors from the do_package step that were missed..16:21
fray_the debugedit program should have written the references directly..16:21
lpappok, well, apparently it did not then.16:21
fray_The other thing you can do is use readelf and dump the dwarf information.  You should see the source references in the dwarf info16:21
fray_debugedit will give diagnostics on not being able to find (and thus not rewrite) specific debug files..16:22
*** ant_work <ant_work!~ant__@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC16:22
fray_those won't be available in the -dbg file... like I said, the syscall one is usually the case.. since that is inherited from the libgcc.a... but your .c file should be avaialble16:22
lpappfray_: no sign of warnings and errors.16:22
fray_then check the readelf output for the dwarf symbols (of the .debug file) and see what the source references are..16:23
lpappfray_: how to do that?16:24
fray_I'll look quickly..16:24
lpappreadelf -a foo | grep -i dwarf -> gives no results.16:25
lpapp  --dwarf-depth=N        Do not display DIEs at depth N or greater16:25
lpapp  --dwarf-start=N        Display DIEs starting with N, at the same depth16:25
lpapp                         or deeper16:25
fray_not foo, the .debug version..16:25
lpappdo not worry, that is foo16:25
lpappwith the long pa th16:25
fray_still looking for the right option16:27
fray_readelf --debug-dump .debug/foo16:27
fray_look at the output for16:28
*** phantoxe <phantoxe!~destroy@2001:5c0:1400:b::392b> has quit IRC16:28
fray_DW_AT_comp_dir  and   DW_AT_name16:28
*** seebs <seebs!~seebs@home.seebs.net> has joined #yocto16:28
fray_the -dir- entry specifies the directory of the debug source, while the -name- is the filepath within that directory16:28
lpapptoo bloated output16:28
lpappanyway, it shows the right directory.16:29
lpappyet the source is unavailable.16:29
fray_from a busybox I had handy:16:29
fray_    <18>   DW_AT_name        : ../sysdeps/i386/start.S16:29
fray_    <30>   DW_AT_comp_dir    : /home/mhatle/git/oss/oe-core/build-toolchain-sdk/tmp-eglibc/work/i586-windriver-linux/lib5-eglibc/2.19-r0/eglibc-2.19/libc/csu16:29
fray_in that case, it's a file that was outside of the sources for busybox.. so it didn't get rewritten as it can't find the file..16:30
fray_... but in the following case, it did ...16:30
fray_    <20e>   DW_AT_name        : (indirect string, offset: 0x511): libbb/appletli16:30
fray_    <212>   DW_AT_comp_dir    : (indirect string, offset: 0x26c): /usr/src/debug/busybox/1.22.1-r32/busybox-1.22.116:30
lpappI do not know why Yocto is generating wrong .debug/foo16:31
lpappit surely does not work.16:31
fray_whats 'wrong' with it?  You said the path changed -- but GDB isn't finding it?16:31
fray_in the example above..  the first case can't be resolved.. there is no way around that..16:31
fray_the second case worked fine and it was rewritten and the file is available at that path16:31
lpapppath changed? Wait, what?16:32
lpappI am just saying that I cannot browse the source code since gdb cannot find it.16:32
fray_I understadn that.. the dwarf symbols are what tell GDB what to browse..16:32
fray_if the dwarf info is wrong, GDB won't find it..16:32
lpappok, so it is wrong then, or the issue is elsewhere.16:32
fray_so start with is the dwarf correct or not.. if it's correct.. then there is a different issue16:32
fray_So is the DW_AT_comp_dir of your foo.c  correct (as it would appear on the target filesystem)?16:33
fray_format is  /usr/src/debug/<recipe>/<version>/<path>16:33
lpappyet, gdb does not find it, regardless.16:34
fray_if the path is written properly.. and then you verify the file  DW_AT_comp_dir/DW_AT_name exists in the -dbg package..  then we know the files are correct, and it's a GDB configuration item16:34
fray_Inside of GDB there is a 'set substitute-path' option, that will allow you to tell GDB to replace '/usr/src' with your local rootfs path...  try that..16:35
lpappI already use set sysroot16:35
fray_you will have to determine what the path that the cross-gdb is trying to read is..  I don't have a simple way to reproduce this at this time.. (I don't have any rootfs or targets confgiured to try it)16:36
-YoctoAutoBuilder- build #212 of nightly-non-gpl3 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-non-gpl3/builds/21216:36
fray_looking at that email..  the syscall-template.S won't be found.. you need to ignore that16:37
lpappwell, all I can say is that it does not work.16:37
fray_however the src/bar.c should be16:37
lpappwell, it is not.16:37
fray_HOWEVER, I would have expected GDB to say '/usr/src/debug/recipe/ver/path/src/bar.c"16:37
fray_and since it did not, I don't know what path it's trying to load16:38
fray_again, it should be referencing the two DWARF entries to build a full path and referencing it inside of the sysroot16:38
lpapptoo many "should be" :)16:38
fray_thats what it -should- be doing, if it's not, I don't know if it's a GDB bug, or something else16:38
lpappwell, can I say that I am extremely annoyed?16:40
lpappas an end user I expected this just to work. :(16:40
lpappI guess the workaround is to put shitload of -d parameters into the gdb command, but it is uncool.16:40
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC16:40
fray_or figure out why it's not working and lets get it fixed..16:41
lpappI have no any idea why it does not work, nor any clue what to look for, whatsoever.16:41
fray_sysroot + dwarf symbols.. and/or the path substitution should resolve everything.. again if it doesn't something is wrong16:41
lpappI think I will work it around anyhow; and I am letting Don Quixote stay in his book.16:42
lpappfray_: http://paste.kde.org/poejyt397 -> this is the dwarf thingie.16:46
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto16:47
lpappfray_: is this OK?16:47
fray_I don't see anything obviously wrong with it16:49
*** fusman1 <fusman1!~fahad@> has joined #yocto16:50
lpappfray_: and with the gdb command?16:50
*** fusman <fusman!~fahad@> has quit IRC16:53
lpappfray_: the thing is that I do not even know what or where to debug to pin this issue down... it just looks so esoteric ...16:55
*** manuel__ <manuel__!~manuel_@p57921144.dip0.t-ipconnect.de> has quit IRC16:56
*** manuel___ <manuel___!~manuel_@p57921144.dip0.t-ipconnect.de> has joined #yocto16:56
* lpapp is wiping stuff away again to see if that fixes it ....16:57
fray_all I can suggest is to have GDB (debug?) print out the path it's looking for.. but the sysroot is obviously working with the binary bits.. since they're loading16:57
*** Kwarf_ <Kwarf_!~Kwarf@h-253-185.a158.priv.bahnhof.se> has joined #yocto16:58
*** Kwarf <Kwarf!~Kwarf@h-253-185.a158.priv.bahnhof.se> has quit IRC16:58
lpappfray_: I do not know how to print that out.16:58
lpappsysroot is obviously good, yeah.16:58
*** [Sno] <[Sno]!~Sno]@static-87-79-200-121.netcologne.de> has joined #yocto17:01
*** microd <microd!~cobra-adm@amper.esg.de> has quit IRC17:04
*** ddom <ddom!~ddom@p4FFD9115.dip0.t-ipconnect.de> has quit IRC17:04
*** tmpsantos <tmpsantos!~tmpsantos@> has quit IRC17:08
*** Kwarf_ <Kwarf_!~Kwarf@h-253-185.a158.priv.bahnhof.se> has quit IRC17:11
lpappfray_: btw, why shall I ignore the first warning anyhow? Shouldn't Yocto be able to generate that properly?17:19
lpappfray_: also, will you be able to verify this today or tomorrow whether it works for you?17:24
fray_no, the referenced item is coming from gcc.. we don17:26
fray_we don't know the path to the GCC support files..17:26
lpappwhy not?17:27
fray_thus it can't be automatically determined.. and the .S files are rarely needed for debugging..17:27
fray_gcc static files (libgcc.a) are set into the .a archive at GCC build time, along with the couple of .o files that are always linked in..17:27
fray_since they are all .o references they can't be investigated and rewritten using the standard debugedit program.  So there is no way to interogate and replace the dwarf symbols.17:28
fray_the files though are rarely used for any regular debug purpose, as they're the _start (pre main), _end and syscall type info..17:28
fray_everything else (dynamically linked) will have the .debug and related rewritten and access to those files via the debugedit rewrite of the dwarf references17:29
lpappit may be useful at times, e.g. mixing the toolchain.17:29
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC17:29
fray_yes, the files themselves are likely visible to the system, but one recipe doesn't know how to get the debug of another recipe.. it's a limitation of the system17:29
lpappso why not fix the system then?17:30
fray_1) it's not worth it, as those files generally aren't used to debug..  2) it's never cause me an issue.. so I havn't bothered to change it..  3) it's never caused any of my customers an issue.. so I've never bothered to fix it..17:31
fray_if you need it.. suggest a fix.... but the fix itself will be in the gneeration of the gcc libgcc.a.. not in your recipe or the standard package processing.. it's very unique to this one set of early files17:32
fray_(might affect a small piece of glibc as well)17:32
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:33
lpappwell, anyway, if you do not have more ideas, will you have time to try to reproduce it any soon?17:33
*** sameo <sameo!~samuel@> has quit IRC17:33
fray_I'm not sure.. I would like to make sure this is working in the next few weeks.. but I don't know when I will get to it at this point..  (I've got a lot of product planning and personal things going on right now.. so my time is pretty limited for the next couple weeks)17:34
lpappI am probably not doing anything magical in here, just standard Yocto, so it is probably easy to reproduce.17:34
fray_yes, like I said, what you are doing should work, as far as I can tell..17:34
lpappwell, the workaround for the whole gdbserver mess in Yocto is to mount a network filesystem and use full gdb on the target.17:35
lpapp(well, mess in my case, might not be for others)17:35
lpappit has been three days now that I am trying to get this gdb(server) thing work without much success.17:36
lpapphave been trying*17:36
lpappit is getting out-of-order now so that I need to find workarounds.17:36
*** belen <belen!Adium@nat/intel/x-oxhhljznayqunolb> has quit IRC17:38
lpappI think someone should blog about how to use gdbserver with Yocto successfully.17:38
lpappI could not find any good tutorial about it step-by-step.17:38
lpapp(which is kind of surprising since debugging is a very important part of the software development process)17:39
fray_at one point there were instructions.. last time I looked was around YP 1.0 - 1.2 time frame17:46
lpappthe yprm is not enough for this17:47
lpappyes, there are some standalone commands, but nothing like a step-through guide with a dummy example.17:47
-YoctoAutoBuilder- build #208 of minnow-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/minnow-lsb/builds/20817:47
*** MDR <MDR!~mdrustad@> has joined #yocto17:47
*** MDR <MDR!~mdrustad@> has quit IRC17:49
lpapp(and as the practice shows that is not enough)17:49
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto17:53
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC18:01
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:06
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-jvfcyaxrrqqldrrk> has quit IRC18:08
*** Nitin <Nitin!nakamble@nat/intel/x-fopiihskbnavrlby> has quit IRC18:14
*** imphil_ <imphil_!~philipp@2001:a60:113b:6701:21d:9ff:fe33:c8f3> has joined #yocto18:22
*** cbzx <cbzx!~cbzx@> has joined #yocto18:24
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has joined #yocto18:31
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto18:31
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has quit IRC18:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:31
*** Nitin <Nitin!nakamble@nat/intel/x-styurkedzrjtqlcy> has joined #yocto18:31
*** Nitin1 <Nitin1!nakamble@nat/intel/x-intemqncifdtcjby> has joined #yocto18:34
*** sameo <sameo!samuel@nat/intel/x-kqtmbgfknhaxutpx> has joined #yocto18:36
*** Nitin <Nitin!nakamble@nat/intel/x-styurkedzrjtqlcy> has quit IRC18:36
*** fusman1 <fusman1!~fahad@> has quit IRC18:41
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC18:42
*** sameo <sameo!samuel@nat/intel/x-kqtmbgfknhaxutpx> has quit IRC18:45
*** sameo <sameo!~samuel@> has joined #yocto18:46
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has quit IRC18:51
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto18:51
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC18:56
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto18:57
*** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has joined #yocto18:57
*** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has quit IRC19:14
*** [Sno] <[Sno]!~Sno]@static-87-79-200-121.netcologne.de> has quit IRC19:46
*** ant__ <ant__!~andrea@host69-169-dynamic.56-82-r.retail.telecomitalia.it> has joined #yocto20:14
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC20:23
*** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto20:23
*** stunpix_ <stunpix_!~Stunpix@> has joined #yocto20:27
*** [Sno] <[Sno]!~Sno]@p578b540c.dip0.t-ipconnect.de> has joined #yocto20:39
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC20:50
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto20:58
*** stunpix_ <stunpix_!~Stunpix@> has quit IRC21:15
*** theguy <theguy!~theguy@S0106602ad07d0544.gv.shawcable.net> has joined #yocto21:19
theguyHey everybody21:19
theguyCan anyone help me figure out why my LCD is shutting off after 15 minutes?21:19
*** Nitin <Nitin!~nakamble@> has joined #yocto21:21
*** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has joined #yocto21:24
*** Nitin1 <Nitin1!nakamble@nat/intel/x-intemqncifdtcjby> has quit IRC21:24
*** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has quit IRC21:24
*** Nitin <Nitin!~nakamble@> has quit IRC21:34
kroontheguy, console driver blanking automatically maybe ?21:35
paulgsetterm -blank 021:37
paulgand see what happens.21:37
*** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC21:41
theguyMy system doesn't have setterm.  I was hoping to solve the problem without it if possible?21:44
theguyThis is what I've tried so far:21:45
kroontheguy, look for "blank" under /sys/class/graphics21:45
theguyok I'll look21:46
*** RzR <RzR!~RzR@> has quit IRC21:46
theguyThere's no "blank" under /sys/class/graphics21:46
theguyoh there is under /sys/class/graphics/fb021:46
*** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC21:47
theguyI've tried echo 0 > /sys/class/graphics/fb0/blank21:47
theguyI've also tried:21:47
theguypassing consoleblank=0 to bootargs21:47
theguymodifying drivers/tty/vt/vt.c with static int blankinterval = 0;21:47
theguyecho -e -n '\033[9]' > /dev/tty121:48
theguywithout any effect21:48
*** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto21:50
krooni had the same problem.. i ended up unbinding the driver vtcon21:50
kroonapparently, after rechecking my history21:51
*** sullical_ <sullical_!~sullical@> has quit IRC21:51
theguyOh, can you elaborate a little bit? What does that driver do?21:52
kroonbut it sounds like it might not do the trick in your case21:52
kroonvtcon, virtual console21:52
kroonit was responsible for blanking during no activity21:52
kroonecho 0 > /sys/class/vtconsole/vtcon1/bind21:53
theguyThanks! I'll give that a try21:53
*** EddyLaiTW <EddyLaiTW!~eddylai@61-231-113-247.dynamic.hinet.net> has joined #yocto21:54
theguyJust rebuilding the system now so can't test immediately, but I'll try and sign on here again tomorrow and let you know how it goes21:56
*** theguy <theguy!~theguy@S0106602ad07d0544.gv.shawcable.net> has quit IRC22:00
*** bfederau <bfederau!~quassel@service.basyskom.com> has quit IRC22:01
*** bfederau <bfederau!~quassel@service.basyskom.com> has joined #yocto22:01
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:02
*** sameo <sameo!~samuel@> has quit IRC22:03
*** Nitin <Nitin!~nakamble@> has joined #yocto22:07
*** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has quit IRC22:10
*** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has quit IRC22:17
*** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has joined #yocto22:21
*** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has quit IRC22:25
*** sullical <sullical!~sullical@> has joined #yocto22:26
*** ant__ <ant__!~andrea@host69-169-dynamic.56-82-r.retail.telecomitalia.it> has quit IRC22:29
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has quit IRC22:34
*** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto22:34
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC22:38
*** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC22:44
*** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto22:44
*** besquive <besquive!~besquive@> has joined #yocto22:47
*** undertaker27 <undertaker27!a2610932@gateway/web/freenode/ip.> has joined #yocto23:06
*** cbzx <cbzx!~cbzx@> has quit IRC23:06
*** sjolley <sjolley!~sjolley@> has quit IRC23:07
*** agust <agust!~agust@p4FDE7025.dip0.t-ipconnect.de> has quit IRC23:12
*** undertaker27 <undertaker27!a2610932@gateway/web/freenode/ip.> has quit IRC23:13
*** besquive <besquive!~besquive@> has quit IRC23:14
*** besquive <besquive!~besquive@> has joined #yocto23:16
*** hsychla__ <hsychla__!~hsychla@port-87-193-170-219.static.qsc.de> has joined #yocto23:16
*** hsychla_ <hsychla_!~hsychla@pd95c9392.dip0.t-ipconnect.de> has quit IRC23:19
*** hsychla__ <hsychla__!~hsychla@port-87-193-170-219.static.qsc.de> has quit IRC23:23
*** hsychla__ <hsychla__!~hsychla@pd95c9392.dip0.t-ipconnect.de> has joined #yocto23:23
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:27
*** EddyLaiTW <EddyLaiTW!~eddylai@61-231-113-247.dynamic.hinet.net> has quit IRC23:35
*** imphil_ <imphil_!~philipp@2001:a60:113b:6701:21d:9ff:fe33:c8f3> has quit IRC23:36
*** Nitin <Nitin!~nakamble@> has quit IRC23:52
*** sjolley <sjolley!~sjolley@> has joined #yocto23:55

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