| *** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto | 00:01 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 00:01 | |
| *** sjolley1 <sjolley1!sjolley@nat/intel/x-lgabdllihzxynbbg> has joined #yocto | 00:05 | |
| *** sjolley <sjolley!sjolley@nat/intel/x-oiyamnhfxnkvwzia> has quit IRC | 00:07 | |
| *** mario-go` is now known as mario-goulart | 00:20 | |
| *** Guest19944 <Guest19944!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 00:35 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 00:43 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 00:45 | |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC | 01:48 | |
| *** Crofton|work <Crofton|work!~balister@pool-108-44-82-131.ronkva.east.verizon.net> has quit IRC | 01:48 | |
| *** sullical_ <sullical_!~sullical@134.134.139.76> has quit IRC | 01:48 | |
| *** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC | 01:48 | |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto | 01:57 | |
| *** Crofton|work <Crofton|work!~balister@pool-108-44-82-131.ronkva.east.verizon.net> has joined #yocto | 01:57 | |
| *** sullical_ <sullical_!~sullical@134.134.139.76> has joined #yocto | 01:57 | |
| *** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto | 01:57 | |
| *** joran_ <joran_!4cb28f38@gateway/web/freenode/ip.76.178.143.56> has quit IRC | 02:19 | |
| *** joran_ <joran_!4cb28f38@gateway/web/freenode/ip.76.178.143.56> has joined #yocto | 02:23 | |
| joran_ | im so confused why isnt my do_install running in my recipe? | 02:23 |
|---|---|---|
| joran_ | https://gist.github.com/anonymous/c7ab0078c60644f3f81e | 02:24 |
| 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 #yocto | 03: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 rpms | 03:01 |
| joran_ | i can see all the .o files in my workdir | 03:02 |
| *** hsychla <hsychla!~hsychla@pd95c9392.dip0.t-ipconnect.de> has quit IRC | 03:04 | |
| *** GunsNRose <GunsNRose!~GunsNRose@110.184.145.105> has joined #yocto | 03:04 | |
| *** hsychla_ <hsychla_!~hsychla@port-87-193-170-219.static.qsc.de> has quit IRC | 03:04 | |
| *** hsychla_ <hsychla_!~hsychla@pd95c9392.dip0.t-ipconnect.de> has joined #yocto | 03:17 | |
| *** Nilesh_ <Nilesh_!~minda@61.246.136.195> has joined #yocto | 03:32 | |
| *** sameo <sameo!samuel@nat/intel/x-wxyvgfqwnlcsomam> has joined #yocto | 03:34 | |
| *** GunsNRose_ <GunsNRose_!~GunsNRose@110.184.145.105> has joined #yocto | 03:36 | |
| *** Jefro1 <Jefro1!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 03:38 | |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC | 03:44 | |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto | 03:44 | |
| *** GunsNRose <GunsNRose!~GunsNRose@110.184.145.105> has quit IRC | 03:56 | |
| *** sjolley1 <sjolley1!sjolley@nat/intel/x-lgabdllihzxynbbg> has quit IRC | 04:11 | |
| *** Nitin <Nitin!~nakamble@192.55.54.36> has quit IRC | 04:46 | |
| *** sjolley <sjolley!~sjolley@134.134.139.74> has joined #yocto | 04:53 | |
| *** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has quit IRC | 04:54 | |
| *** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has joined #yocto | 04:57 | |
| *** melonipoika <melonipoika!~quassel@91-158-65-146.elisa-laajakaista.fi> has joined #yocto | 04:59 | |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC | 05:02 | |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto | 05:02 | |
| *** [Sno] <[Sno]!~Sno]@p578b540c.dip0.t-ipconnect.de> has quit IRC | 05:12 | |
| *** lyang0 <lyang0!~lyang001@1.202.252.122> has quit IRC | 05:13 | |
| *** sameo <sameo!samuel@nat/intel/x-wxyvgfqwnlcsomam> has quit IRC | 05:19 | |
| *** lyang0 <lyang0!~lyang001@1.202.252.122> has joined #yocto | 05:21 | |
| *** agust <agust!~agust@p4FDE7025.dip0.t-ipconnect.de> has joined #yocto | 05:25 | |
| *** khem <khem!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has quit IRC | 05:35 | |
| *** stunpix_ <stunpix_!~Stunpix@46.119.72.244> has joined #yocto | 06:09 | |
| *** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto | 06:11 | |
| *** fabo <fabo!~fabo@linaro/fabo> has quit IRC | 06:13 | |
| *** fabo <fabo!~fabo@a91-152-78-194.elisa-laajakaista.fi> has joined #yocto | 06:13 | |
| *** fabo <fabo!~fabo@linaro/fabo> has joined #yocto | 06:13 | |
| *** cristianiorga <cristianiorga!cristianio@nat/intel/x-yguqupebibqqbkor> has joined #yocto | 06:21 | |
| olani | joran_: 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 |
| olani | joran_: 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 IRC | 06:45 | |
| *** tasslehoff <tasslehoff!~Tasslehof@ti0260a430-0477.bb.online.no> has joined #yocto | 06:49 | |
| tasslehoff | After 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 |
| tasslehoff | I suspect I have no knowledge about SAVANNAH_GNU_MIRROR | 06:53 |
| tasslehoff | aaah, nevermind. had forgotten to change to daisy after cloning. | 06:57 |
| *** LetoThe2nd <LetoThe2nd!~jd@unaffiliated/letothe2nd> has quit IRC | 06:59 | |
| *** kroon <kroon!~kroon@193.15.174.198> has joined #yocto | 06:59 | |
| *** [Sno] <[Sno]!~Sno]@pd956d8ef.dip0.t-ipconnect.de> has joined #yocto | 07:03 | |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has joined #yocto | 07:04 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto | 07:06 | |
| *** stunpix_ <stunpix_!~Stunpix@46.119.72.244> has quit IRC | 07:07 | |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto | 07:08 | |
| *** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-jvfcyaxrrqqldrrk> has joined #yocto | 07:11 | |
| *** jbrianceau_away is now known as jbrianceau | 07:11 | |
| *** TobSnyder1 <TobSnyder1!~schneider@ip92343918.dynamic.kabel-deutschland.de> has joined #yocto | 07:13 | |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has quit IRC | 07:15 | |
| *** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has joined #yocto | 07:20 | |
| *** wrd <wrd!~Thunderbi@212.27.69.217> has joined #yocto | 07:21 | |
| *** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has quit IRC | 07:22 | |
| *** roxell <roxell!~roxell@linaro/roxell> has quit IRC | 07:22 | |
| *** W1N9Zr0 <W1N9Zr0!~w1n9zr0@2605:6400:20:895b:22:0:1c4:4d6a> has joined #yocto | 07:23 | |
| *** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 07:26 | |
| *** LetoThe2nd <LetoThe2nd!~jd@unaffiliated/letothe2nd> has joined #yocto | 07:30 | |
| *** florian_kc is now known as florian | 07:30 | |
| *** ant_work <ant_work!~ant__@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:31 | |
| *** roric <roric!~roric@83.140.117.51> has joined #yocto | 07:46 | |
| lpapp | I 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 |
| lpapp | I 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 #yocto | 08:00 | |
| lpapp | here you can see the debug log from bitbake fwiw: http://paste.kde.org/pl8cke94m | 08:01 |
| olani | lpapp: Try bitbake -c unpack foo | 08:03 |
| olani | lpapp: 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 #yocto | 08:06 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 08:10 | |
| lpapp | olani: 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/205 | 08:22 | |
| *** AlexVaduva <AlexVaduva!c1ca1642@gateway/web/freenode/ip.193.202.22.66> has quit IRC | 08:28 | |
| *** olani <olani!user@nat/axis/x-pcytcqfnkmocsvrc> has quit IRC | 08:28 | |
| *** bluelightning <bluelightning!~paul@83.217.123.106> has joined #yocto | 08:30 | |
| *** bluelightning <bluelightning!~paul@83.217.123.106> has quit IRC | 08:30 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:30 | |
| bluelightning | morning all | 08:30 |
| lpapp | how would I go about solving this? NOTE: multiple providers are available for runtime packagegroup-foo-dbg (packagegroup-foo-dbg, packagegroup-foo) | 08:32 |
| lpapp | NOTE: consider defining a PREFERRED_PROVIDER entry to match packagegroup-foo-dbg | 08:32 |
| lpapp | my -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 |
| bluelightning | lpapp: other than not having multiple runtime providers, you can't right now: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6149 | 08:33 |
| yocti | Bug 6149: normal, Medium, 1.7, paul.eggleton, NEW , Setting PREFERRED_PROVIDER to select between multiple runtime providers does not work | 08:33 |
| lpapp | bluelightning: ok, so I should put the shared part into a shared include file? | 08:34 |
| bluelightning | no, that won't accomplish anything | 08:34 |
| bluelightning | what are you trying to do exactly? | 08:34 |
| lpapp | bluelightning: well, I have two images, one debug and one non-debug | 08:35 |
| *** olani <olani!user@nat/axis/x-narxbrbkygdpjqje> has joined #yocto | 08:35 | |
| lpapp | the debug image is almost the same, except that it gets the -git version of our software. | 08:35 |
| lpapp | and built with -O0 -g -DDEBUG, etc. | 08:35 |
| lpapp | why wouldn't that accomplish anything? | 08:35 |
| lpapp | then, I would not include the non-dbg image into the -dbg anymore, just the shared part. | 08:35 |
| lpapp | so there could be no clashing stuff IMHO | 08:36 |
| bluelightning | if you just don't call it -dbg you won't have the problem | 08:36 |
| lpapp | the image, the packagegroup, both or what exactly? | 08:37 |
| lpapp | (and why will I not have the problem then?) | 08:37 |
| lpapp | bluelightning: ^ | 08:40 |
| bluelightning | the packagegroup | 08:40 |
| bluelightning | because they then will not overlap... | 08:40 |
| lpapp | bluelightning: what do you mean by overlap? | 08:45 |
| lpapp | bitbake only checks if the _names_ overlap, and not the actual package list? | 08:45 |
| bluelightning | what is in PACKAGES goes into RPROVIDES, and that gets checked | 08:46 |
| lpapp | I am not sure I follow. | 08:48 |
| *** EddyLaiTW <EddyLaiTW!~eddylai@61-231-113-247.dynamic.hinet.net> has joined #yocto | 08:48 | |
| lpapp | I guess the solution is to wipe everything away and wait 2 hours. :/ | 08:49 |
| lpapp | but it is so frustrating to do this all the time for so many issues. | 08:50 |
| *** wrd <wrd!~Thunderbi@212.27.69.217> has quit IRC | 08:52 | |
| *** wrd <wrd!~Thunderbi@212.27.69.217> has joined #yocto | 08:53 | |
| lpapp | bluelightning: 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 |
| lpapp | I 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@77.107.122.34> has joined #yocto | 09:00 | |
| lpapp | and IMAGE_FEATURES += "dbg-pkgs" + description. | 09:03 |
| *** stuartw__ <stuartw__!~stuartw@77.107.122.34> has quit IRC | 09:04 | |
| *** jaro123_ <jaro123_!2e242307@gateway/web/freenode/ip.46.36.35.7> has joined #yocto | 09:06 | |
| jaro123_ | hello | 09:06 |
| lpapp | bluelightning: yeah, strange, I am still getting the warning, although the -dbg image now only contains the -dbg package group, not both. | 09:06 |
| lpapp | is 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 |
| olani | lpapp: 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 |
| bluelightning | lpapp: wiping things out will not solve this, you'll just get the same error again | 09:07 |
| lpapp | olani: 1) It is not my bugreport 2) OK, well, I will rename it to -git then. | 09:07 |
| lpapp | bluelightning: nope, because I would type bitbake foo-core-image-dbg | 09:07 |
| bluelightning | olani is correct, the -dbg name is the source of your problems (as I pointed out half an hour ago) | 09:08 |
| lpapp | it worked yesterday; why I am getting this is because I made the SDK out of the normal image first now. | 09:08 |
| lpapp | bluelightning: I do not agree that it should be the source of the problem. | 09:08 |
| olani | lpapp: Not a good choice either. Use -debug. | 09:08 |
| lpapp | IMHO, Yocto should fix it up. It is completely good to have dbg images and hence package groups | 09:08 |
| lpapp | What 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 |
| lpapp | and 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 |
| lpapp | they _do_ need to be separate builds from the ground up. | 09:09 |
| lpapp | you 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 |
| bluelightning | there is nothing wrong with the use case, it's solely about the naming | 09:10 |
| lpapp | naming should match the use case IMHO | 09:10 |
| bluelightning | packagegroups already have handling for -dbg packages though, unless you override PACKAGES | 09:10 |
| lpapp | olani: 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 |
| bluelightning | so your naming clashes with that | 09:10 |
| lpapp | (I simply will not, I can guarantee that, and I will struggle) | 09:11 |
| lpapp | there oughta be a way that I can tell Yocto, _this_ is the dbg stuff that I cooked together. | 09:11 |
| lpapp | and not what it thinks it is. | 09:12 |
| olani | lpapp: 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 #yocto | 09:13 | |
| lpapp | bluelightning: 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 |
| lpapp | bluelightning: non-stripped != debug. | 09:13 |
| bluelightning | what do you mean by debug? | 09:13 |
| lpapp | -g -DDEBUG -O0 at the very least. | 09:14 |
| bluelightning | do you mean, you have the symbols such that gdb can display proper backtraces? | 09:14 |
| lpapp | it seems that Yocto has a fundamental flaw of thinking debug is equal to non-stripped release binaries. | 09:14 |
| lpapp | I 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 |
| bluelightning | could you answer my question please? | 09:17 |
| lpapp | I think I did: 10:13 < lpapp> -g -DDEBUG -O0 at the very least. | 09:17 |
| bluelightning | so -DDEBUG means no, then | 09:18 |
| bluelightning | we don't have any explicit handling for this kind of situation, no | 09:18 |
| lpapp | that is my main problem, yeah. | 09:18 |
| lpapp | I will submit a bugreport for it... | 09:18 |
| bluelightning | could we? possibly, yes, but it would be outside of what we understand with the -dbg packaging we currently have, that is only for debugging symbols | 09:18 |
| lpapp | it is crucial for cooking proper debug environment. | 09:19 |
| lpapp | without this, it is painful to make a nice debugging environment which is essential for maintaining software. | 09:19 |
| bluelightning | if you want to implement that, you're more than welcome to do so | 09:19 |
| *** belen <belen!Adium@nat/intel/x-aqokqxiuybjhtktg> has quit IRC | 09:19 | |
| lpapp | is there a better workaround than calling it -debug? | 09:20 |
| lpapp | I 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 #yocto | 09:20 | |
| lpapp | and I cannot use git either ... | 09:20 |
| olani | lpapp: 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 |
| olani | lpapp: 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 |
| lpapp | are you saying that this flaw cannot be worked around "nicely"? | 09:45 |
| lpapp | I 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 |
| lpapp | explaining this* | 09:46 |
| *** stunpix_ <stunpix_!~Stunpix@46.119.72.244> has joined #yocto | 09:48 | |
| lpapp | I will call it -git for now for sanity and let us see if it breaks at some point... thanks. | 09:49 |
| lpapp | should I also rename the image from foo-dbg or it is only for the packagegroup here? | 09:51 |
| lpapp | bluelightning: ^ | 09:51 |
| bluelightning | I can't be sure, but since the image recipe doesn't do any packaging it shouldn't theoretically be an issue | 09:51 |
| olani | lpapp: We do use an image recipe ending in -dbg. That works. | 09:52 |
| lpapp | ERROR: Nothing PROVIDES 'foo-image-core-dbg' | 09:52 |
| lpapp | my dbg image does not work anymore? | 09:53 |
| lpapp | ah, sorry, core-image, not image-core | 09:53 |
| *** stunpix_ <stunpix_!~Stunpix@46.119.72.244> has quit IRC | 09:53 | |
| lpapp | :-) | 09:53 |
| lpapp | bluelightning: olani ok, thanks, I will leave it there. | 09:53 |
| lpapp | so why is the -dbg image still not created in ./tmp/work/foo-foo-linux-gnueabi/? | 09:56 |
| lpapp | olani: bluelightning ^ | 09:56 |
| lpapp | I 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 |
| lpapp | I only have the foo image populated in there. | 09:57 |
| bluelightning | what is your bitbake command line? | 09:58 |
| lpapp | bitbake foo-dbg where foo-dbg is the dbg image name. | 09:58 |
| lpapp | foo-core-image-dbg to be fair, but yeah | 09:59 |
| lpapp | I also tried bitbake -c cleansstate foo-core-image-dbg; bitbake foo-core-image-dbg | 09:59 |
| lpapp | do_rootfs is running fwiw. | 10:00 |
| lpapp | how can I force to populate it? | 10:02 |
| bluelightning | there shouldn't need to be any forcing | 10:04 |
| *** joran_ <joran_!4cb28f38@gateway/web/freenode/ip.76.178.143.56> has quit IRC | 10:04 | |
| lpapp | bluelightning: ok, so what is the problem then? | 10:04 |
| bluelightning | no idea | 10:04 |
| bluelightning | if it's running do_rootfs then it is building the image | 10:04 |
| lpapp | it is finishing without issues. | 10:04 |
| bluelightning | bitbake -e foo-dbg | grep ^WORKDIR= if you're unsure as to where the work directory is ending up... | 10:05 |
| lpapp | I know where it ends up based on the last successful builds. | 10:05 |
| lpapp | it ought to be beside the foo image, but let me confirm that. | 10:05 |
| lpapp | tmp/work/foo-foo-linux-gnueabi/foo-core-image-dbg/1.0-r0 | 10:06 |
| lpapp | I see only pseudo, temp and foo-core-image-dbg-1.0 there, but the last one is an empty directory. | 10:06 |
| lpapp | this is the image recipe content, fwiw: http://paste.kde.org/prst69mup | 10:07 |
| lpapp | and the .inc file only has things like these: http://paste.kde.org/pad324bx3 | 10:08 |
| lpapp | bluelightning: olani do you see any issues with those short files? | 10:29 |
| bluelightning | nothing at a glance | 10:29 |
| *** RzR <RzR!~RzR@82.236.136.171> has joined #yocto | 10:30 | |
| lpapp | bluelightning: ok, thanks. | 10:30 |
| lpapp | RzR: hi there! | 10:30 |
| RzR | hi there didnt know you were hacking on y! | 10:30 |
| RzR | btw, i am not | 10:31 |
| lpapp | RzR: well, I am not hacking on Yocto, just using it. | 10:31 |
| *** fenrig <fenrig!5ee22386@gateway/web/freenode/ip.94.226.35.134> has joined #yocto | 10:33 | |
| fenrig | Hi | 10:34 |
| *** slips <slips!~quassel@mail.tomra.no> has joined #yocto | 10:35 | |
| fenrig | I'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 #yocto | 10:41 | |
| *** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto | 10:42 | |
| lpapp | RzR: 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/182 | 10:51 | |
| *** ddom <ddom!~ddom@p4FFD9115.dip0.t-ipconnect.de> has joined #yocto | 10:51 | |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC | 10:51 | |
| fenrig | Nobody 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/209 | 10: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/207 | 10:55 | |
| lpapp | bluelightning: can you tell me a workaround? | 10:55 |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto | 10:55 | |
| lpapp | bluelightning: how to enforce the generation? | 10:55 |
| bluelightning | lpapp: I don't know what the problem is... | 10:55 |
| lpapp | bluelightning: how to pin that down? | 10:55 |
| bluelightning | read logs for the image, add debug messages ... | 10:56 |
| lpapp | bluelightning: which log is interesting in this case? | 10:58 |
| lpapp | do_rootfs or something else? | 10:58 |
| bluelightning | well, log.do_rootfs I would have thought, since that's where the actual image construction happens... | 10:58 |
| lpapp | ok, well, I am wiping stuff away as I cannot find anything. Let us hope it works afterwards. | 11:08 |
| bluelightning | I'm almost positive that won't help, but up to you | 11:10 |
| lpapp | well, it used to work. | 11:11 |
| lpapp | and since there is no better idea, I do not have anything to lose either. | 11:12 |
| *** tmpsantos <tmpsantos!~tmpsantos@192.198.151.43> has joined #yocto | 11:14 | |
| soderstrom | lpapp: What is you goal? If you just ignore all the problems. What are you trying to achieve? | 11:14 |
| lpapp | soderstrom: 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 |
| soderstrom | lpapp: Instead of focusing on the problems, maybe you can take a step back and focus on task at hand? | 11:19 |
| lpapp | meh | 11:20 |
| *** microd <microd!~cobra-adm@amper.esg.de> has joined #yocto | 11:20 | |
| soderstrom | That is why I am asking, what is your goal? What are you trying to do? Can you explain it? | 11:22 |
| lpapp | https://bugzilla.yoctoproject.org/show_bug.cgi?id=6636 | 11:25 |
| yocti | Bug 6636: normal, Undecided, ---, saul.wold, NEW , Yocto does not understand what a debug package might really be | 11:25 |
| lpapp | soderstrom: it is all said above. I do not have time to reiterate it, sorry. | 11:26 |
| lpapp | nor actual interest since the rebuild already started anyway. | 11:27 |
| RzR | lpapp: there are work in progress on that ... but I just came here to find someone who had similar issues w/ gst | 11:31 |
| lpapp | RzR: what issue ? | 11:32 |
| RzR | lpapp: allways diplomatic | 11:32 |
| RzR | lpapp: something w/ Qt+gst+libva | 11:32 |
| RzR | totally unrelated to yocto project ;) | 11:33 |
| T0mW | Does bitbake -c cleanstate <recipe> remove / reset tthe stored sstate-cache info ? Like it never really happened? | 11:36 |
| lpapp | you mean cleansstate? | 11:37 |
| T0mW | I've done -c clean but then seen the sstate-cache restore the build data instead of doing an actual rebuild. | 11:37 |
| T0mW | lpapp: yeah | 11:37 |
| lpapp | yeah, cleansstate, not clean. | 11:37 |
| T0mW | Wondering how to do that without a -c cleanall | 11:38 |
| lpapp | bitbkake -c cleansstate <recipe> | 11:38 |
| lpapp | or you can just force whatever action you wish to do again AFAIK. | 11:38 |
| T0mW | yes, ok, greate. | 11:38 |
| T0mW | yes, ok, great. | 11:38 |
| T0mW | no 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/186 | 11:47 | |
| *** fenrig <fenrig!5ee22386@gateway/web/freenode/ip.94.226.35.134> has quit IRC | 11:54 | |
| lpapp | bluelightning: hmm, yeah, it is still empty, grrr. | 11:56 |
| lpapp | I am so confused; it is likely because of the shared content separation. I will revert that change. | 11:57 |
| *** LocutusOfBorg1 <LocutusOfBorg1!~Gianfranc@93.48.227.228> has joined #yocto | 12:03 | |
| lpapp | bluelightning: the "fun" thing is that ./tmp/deploy/images is populated, just not the root fs ... | 12:08 |
| *** Nilesh_ <Nilesh_!~minda@61.246.136.195> has quit IRC | 12:15 | |
| lpapp | shouldn'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.76.178.143.56> has joined #yocto | 12:23 | |
| bluelightning | it won't be solely because of the inc file | 12:23 |
| joran_ | hey guys | 12: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 rpms | 12:23 |
| lpapp | bluelightning: 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 -dbg | 12:24 |
| olani | joran_: In the image dir (${D}) you can see all installed files. If | 12:24 |
| olani | that looks correct check the dirs in packages-split. Maybe the main | 12:24 |
| olani | package (with the same name as the recipe) is empty? Then you need to | 12:24 |
| olani | use a FILES_${PN] += ".." to make sure the file ends up in the correct | 12:24 |
| olani | package. The rpm and package splitting is not done by the do_install | 12:24 |
| olani | task, that only installs your files in ${D}. | 12:24 |
| joran_ | hey olani cool your still here | 12:24 |
| joran_ | ok checking noww | 12:25 |
| joran_ | thanks :) | 12:25 |
| lpapp | bluelightning: hmm, may it be due to rm_work? | 12:27 |
| bluelightning | lpapp: oh... yes, that would do it | 12:29 |
| lpapp | yes, I tested it. | 12:29 |
| lpapp | what is the best practice to exclude that rule for the debug image only? | 12:30 |
| joran_ | so {workdir}/image/usr/bin is empty | 12:30 |
| joran_ | {workdir} contains all the .o files | 12:31 |
| joran_ | im an idiot I think I found it ... | 12:33 |
| joran_ | dang I feel dumb sometimes | 12:34 |
| *** jkridner <jkridner!~jkridner@rrcs-64-183-219-162.sw.biz.rr.com> has joined #yocto | 12:34 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 12:34 | |
| joran_ | its cause it was named something other than its bitbake recipe name in the qmake file | 12:34 |
| joran_ | so the file was there all along I just didnt see it cause i was looking for the wrong name | 12:35 |
| bluelightning | lpapp: add it to RM_WORK_EXCLUDE | 12: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/207 | 12:41 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 12:41 | |
| *** ddalex <ddalex!~ddalex@83.217.123.106> has joined #yocto | 12:44 | |
| lpapp | bluelightning: is it ok to do that in the -dbg image recipe? | 12:47 |
| bluelightning | lpapp: AFAICT yes | 12:48 |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has quit IRC | 12:48 | |
| *** Nilesh_ <Nilesh_!~minda@61.246.136.195> has joined #yocto | 12:54 | |
| lpapp | bluelightning: I will test it, thanks. | 12:55 |
| *** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC | 13:08 | |
| aimetis0 | khem: 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 #yocto | 13:10 | |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC | 13:13 | |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto | 13:14 | |
| *** ivanstojanovic <ivanstojanovic!~evo@vpn.anton-paar.com> has joined #yocto | 13:26 | |
| ivanstojanovic | hi | 13:26 |
| ivanstojanovic | does anyone have experience with QtGstreamer on imx6? | 13:27 |
| ivanstojanovic | I 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 working | 13:30 |
| *** sjolley <sjolley!~sjolley@134.134.139.74> has quit IRC | 13:30 | |
| *** AndersD <AndersD!~anders@c83-252-255-124.bredband.comhem.se> has quit IRC | 13:38 | |
| *** tasslehoff <tasslehoff!~Tasslehof@ti0260a430-0477.bb.online.no> has quit IRC | 13:44 | |
| *** kroon <kroon!~kroon@193.15.174.198> has quit IRC | 13:48 | |
| *** sjolley <sjolley!~sjolley@134.134.139.76> has joined #yocto | 13:49 | |
| *** joran_ <joran_!4cb28f38@gateway/web/freenode/ip.76.178.143.56> has quit IRC | 13:52 | |
| *** _rink <_rink!~rink@gloom.codethulu.net> has joined #yocto | 13:59 | |
| _rink | hi all! | 13:59 |
| _rink | anyone here maintainer of dosfstools ? | 13:59 |
| _rink | or knowledgable about it? | 13:59 |
| bluelightning | _rink: I'm the maintainer, though I haven't done much maintenance with it lately | 14:00 |
| bluelightning | I think there is a reason we're stuck on an older version but I don't remember offhand what it is | 14:00 |
| _rink | gplv3 maybe? | 14:00 |
| *** Nilesh_ <Nilesh_!~minda@61.246.136.195> has quit IRC | 14:00 | |
| bluelightning | that could be it yes | 14:00 |
| _rink | Well | 14:01 |
| Crofton|work | we can add a v3 version, just need to keep the v2 one | 14:01 |
| _rink | there's a pretty annoying but in it, causing it to die due to memory corruption while repating a filesystem | 14:01 |
| _rink | I made a patch based on the fedora core (i think it was) bug report | 14:02 |
| _rink | and added a tiny change based on their git history | 14:02 |
| * _rink unsure if that is acceptable to include ? | 14:02 | |
| _rink | the fix is quite trivial if you know what the problem is | 14:02 |
| bluelightning | is the patch against the GPLv2 version though? | 14:03 |
| _rink | yes | 14:03 |
| bluelightning | ok, as long as it doesn't break anything I think it should be acceptable | 14:05 |
| _rink | hmmm | 14:06 |
| _rink | https://bugzilla.redhat.com/show_bug.cgi?id=674095 is where I got the patch from where I based my work on | 14:06 |
| yocti | Bug 674095: was not found. | 14:06 |
| _rink | the patch there is incomplete | 14:06 |
| _rink | but this patch eppears to be against 3.0.9-4.fc14 | 14:07 |
| _rink | [not that the code has changed] - and the author does not say anything about licensing | 14:07 |
| bluelightning | ah, in that case we may have a problem | 14:08 |
| _rink | yeah, thought was much. | 14:08 |
| bluelightning | because 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 author | 14:08 |
| _rink | however, the patch there is incomplete | 14:09 |
| _rink | I 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 patch | 14:09 | |
| fray_ | morning... | 14:12 |
| 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 #yocto | 14:16 | |
| _rink | bluelightning, 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 header | 14:17 |
| _rink | okay, i'll get back to you on this :) | 14:17 |
| *** jaro123_ <jaro123_!2e242307@gateway/web/freenode/ip.46.36.35.7> has quit IRC | 14:26 | |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 14:29 | |
| *** kevin_t <kevin_t!~Thunderbi@46.18.96.46> has quit IRC | 14:30 | |
| *** kevin_t <kevin_t!~Thunderbi@46.18.96.46> has joined #yocto | 14:31 | |
| *** [Sno] <[Sno]!~Sno]@pd956d8ef.dip0.t-ipconnect.de> has quit IRC | 14:31 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto | 14:31 | |
| *** EddyLaiTW <EddyLaiTW!~eddylai@61-231-113-247.dynamic.hinet.net> has quit IRC | 14:34 | |
| lpapp | bluelightning: does -c cleansstate make sense on images? | 14:35 |
| bluelightning | not really, do_rootfs isn't an sstate task | 14:35 |
| lpapp | say, I want to comment the debug-without-src option in my local conf, and regenerate the image respectively? | 14:35 |
| lpapp | what am I supposed to do to achieve that? | 14:36 |
| bluelightning | it should be able to tell by itself if rebuilding the image is necessary | 14:36 |
| bluelightning | if it can't, that is a bug; you can work around it by doing e.g. bitbake -C rootfs imagename | 14:36 |
| lpapp | bluelightning: I wonder if debug-without-src actually is more relevant to the individual packages than the image creation. | 14:38 |
| bluelightning | it should flow from those to the image in terms of the signature changing | 14:38 |
| lpapp | bluelightning: ok, thanks. | 14:42 |
| lpapp | bluelightning: 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.114.199.128.146> has joined #yocto | 14:53 | |
| *** dduri <dduri!72c78092@gateway/web/freenode/ip.114.199.128.146> has quit IRC | 14:56 | |
| aimetis0 | Does anyone know how to put files into tmp/sysroot folder? | 15:00 |
| lpapp | aimetis0: what files? | 15:01 |
| aimetis0 | just some lib files | 15:01 |
| lpapp | it is automatically done if you are doing the right things. | 15:01 |
| *** fusman <fusman!~fahad@110.93.212.98> has quit IRC | 15:02 | |
| aimetis0 | lpapp: I have two mono packages. Packages A needs some libs built by Package B. I don't know how to put libs in sysroot | 15:02 |
| lpapp | ah, like that, I do not know. | 15:03 |
| aimetis0 | lpapp: I listed Package B as depends in Package A recipe but there is nothing in the sysroot | 15:04 |
| aimetis0 | lpapp: but do you know generally how we can put files into sysroot manually regardless of mono? | 15:06 |
| aimetis0 | I heard it has something to do with sysroot staging | 15:09 |
| lpapp | no, but why would you like to get it to there? | 15:10 |
| lpapp | 0x44ad26ec in select () at ../sysdeps/unix/syscall-template.S:81 | 15:12 |
| lpapp | 81 ../sysdeps/unix/syscall-template.S: No such file or directory. | 15:12 |
| lpapp | I keep getting this with Yocto, when debugging inside, why? | 15:12 |
| ant_work | aimetis0: there is maybe some renaming? | 15:13 |
| aimetis0 | lpapp: 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_work | you are talking about 'libs' | 15:13 |
| ant_work | aimetis0: copying and pasting: | 15:14 |
| ant_work | * DEPENDS = "b" in recipe "a" will translate to a's do_configure task depending | 15:14 |
| ant_work | on recipe b's do_populate_sysroot task | 15:14 |
| *** manuel__ <manuel__!~manuel_@p57921144.dip0.t-ipconnect.de> has joined #yocto | 15:14 | |
| aimetis0 | ant_work: Yes, but it is needed in the build time | 15:15 |
| ant_work | ofc, at configure stage it is expected the headers are staged | 15:15 |
| ant_work | I'm talking about build, not runtime | 15:15 |
| ant_work | DEPENDS means a build-time dependency | 15:16 |
| ant_work | I guess the lib is gettin grenamed and it is not found... | 15:16 |
| aimetis0 | ant_work: I declared DEPENDS in recipe but it didn't put anything in the sysroot | 15:17 |
| ant_work | pls verify | 15:17 |
| aimetis0 | ant_work: I am wondering if I need to write the do_populate_sysroot function | 15:19 |
| *** roxell <roxell!~roxell@c-853670d5.07-21-73746f28.cust.bredbandsbolaget.se> has joined #yocto | 15:19 | |
| *** roxell <roxell!~roxell@linaro/roxell> has joined #yocto | 15:19 | |
| ant_work | aimetis0: don't go off-track ;) | 15:19 |
| ant_work | pls inspect the WORKDIR of the packages and check how these are built and packaged | 15:20 |
| *** khem` <khem`!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has joined #yocto | 15:21 | |
| aimetis0 | ant_work: Yes, the dependency is built and packed in its workdir | 15:22 |
| ant_work | aimetis0: what is the exact error you get? Can you paste it? | 15:22 |
| lpapp | bluelightning: hey, why is Yocto not installing eglibc-source properly? | 15:23 |
| lpapp | I think that is why I see the above error. | 15:23 |
| aimetis0 | ant_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 |
| aimetis0 | ant_work: it seems that it still could not find the libs it depends | 15:26 |
| *** wrd <wrd!~Thunderbi@212.27.69.217> has quit IRC | 15:28 | |
| ant_work | what's th eexpected library then? | 15:28 |
| aimetis0 | ant_work: the DeviceAutoDiscovery.dll is expected and it is built by the recipe "discover-devices.bb". | 15:29 |
| *** cbzx <cbzx!~cbzx@99.224.76.14> has joined #yocto | 15:29 | |
| ant_work | what do the logs of above recipe say? Is it a private recipe? | 15:30 |
| ant_work | (google doesn't know about it) | 15:31 |
| aimetis0 | ant_work: yes, it is a private recipe | 15:31 |
| *** TobSnyder1 <TobSnyder1!~schneider@ip92343918.dynamic.kabel-deutschland.de> has quit IRC | 15:31 | |
| ant_work | check the logs, each task has one | 15:32 |
| *** sameo <sameo!~samuel@192.55.54.40> has joined #yocto | 15:33 | |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC | 15:34 | |
| *** khem` <khem`!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has quit IRC | 15:35 | |
| aimetis0 | ant_work: the situation is that discover-devices.bb builds the dll and the dll is need by decoder-service.bb. Both recipes are private recipes | 15:35 |
| *** cbzx <cbzx!~cbzx@99.224.76.14> has quit IRC | 15:35 | |
| *** cbzx <cbzx!~cbzx@99.224.76.14> has joined #yocto | 15:36 | |
| aimetis0 | ant_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 dll | 15:37 |
| ivanstojanovic | Hi 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 IRC | 15:41 | |
| ant_work | aimetis0: 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 sysroot | 15:45 |
| ant_work | the logs in workdir/recipe/tmp should help you | 15:46 |
| *** roric <roric!~roric@83.140.117.51> has quit IRC | 15:46 | |
| aimetis0 | ant_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 into | 15:47 |
| aimetis0 | the source folder, and start to build decoder-service | 15:47 |
| aimetis0 | ant_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.exe | 15:50 |
| ant_work | Can you tell what kind of Distro/Image are you building? | 15:51 |
| aimetis0 | ant_work: cortexa9hf-vfp-neon, I guess | 15:52 |
| *** khem` <khem`!~khem@c-98-207-177-218.hsd1.ca.comcast.net> has joined #yocto | 15:53 | |
| ant_work | ok, it is a final image for <target> | 15:53 |
| *** khem` is now known as khem | 15:53 | |
| ant_work | hi khem | 15:53 |
| khem | Hello | 15:53 |
| ivanstojanovic | hello :) | 15:54 |
| aimetis0 | ant_work: decoder-service and discover-devices are mono projects | 15:54 |
| ant_work | aimetis0: then you have one specific sysroot for <target> machine | 15:54 |
| ant_work | you can verify its path inspecting the log. and run. files under /tmp | 15:55 |
| aimetis0 | ant_work: I checked the tmp/sysroot folder and there are three subfolders, imx6qsabresd imx6qsabresd-tcbootstrap x86_64-linux | 15:55 |
| *** kevin_t <kevin_t!~Thunderbi@46.18.96.46> has quit IRC | 15:55 | |
| *** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has quit IRC | 15:55 | |
| ant_work | first one is <target>, second is temporary, ignore it, third is -native, the build-host | 15:56 |
| aimetis0 | ant_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_work | pls check what has been installed in sysroot/imx6qsabresd/usr | 15:57 |
| *** jbrianceau is now known as jbrianceau_away | 15:58 | |
| aimetis0 | ant_work: just one folder called crossscripts under sysroot/imx*/usr/bin | 15:58 |
| ant_work | hm.. then /include, .. /lib... look around | 15:59 |
| ant_work | the logs should point you to the right path | 15:59 |
| aimetis0 | ant_work: I did a complete search in sysroot folder and there is nothing | 16:00 |
| ant_work | are you then building a -native recipe? | 16:01 |
| ant_work | where did the recipe put the files? | 16:01 |
| *** cbzx <cbzx!~cbzx@99.224.76.14> has quit IRC | 16:01 | |
| aimetis0 | ant_work: what is a -native recipe? | 16:01 |
| ant_work | what does install and populate_sysroot say? | 16:01 |
| ant_work | pls read the logs thoroughfully | 16:02 |
| ant_work | heh, new word ! | 16:02 |
| ant_work | thoroughly | 16:02 |
| aimetis0 | ant_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@46.18.96.46> has joined #yocto | 16:03 | |
| *** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has joined #yocto | 16:03 | |
| aimetis0 | ant_work: the install log only has two lines: DEBUG: Executing shell function do_install DEBUG: Shell function do_install finished | 16:05 |
| ant_work | check the run. file as well | 16:05 |
| aimetis0 | ant_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/bin | 16: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/211 | 16:07 | |
| -YoctoAutoBuilder- build #206 of nightly-x86 is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/206 | 16:07 | |
| -YoctoAutoBuilder- build #212 of build-appliance is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/build-appliance/builds/212 | 16: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/205 | 16: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/208 | 16: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/205 | 16: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/205 | 16: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/213 | 16: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/204 | 16:07 | |
| ant_work | so as you see it goes indeed in ${D}${bindir} | 16:08 |
| aimetis0 | ant_work: yes | 16: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/202 | 16:08 | |
| ant_work | now I maybe see the problem...I'd not put that in bindir | 16:08 |
| -YoctoAutoBuilder- build #185 of nightly-rpm is complete: Failure [failed] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-rpm/builds/185 | 16:08 | |
| ant_work | try libdir | 16:08 |
| lpapp | fray_: ping | 16:09 |
| fray_ | yup | 16:09 |
| aimetis0 | ant_work: you mean I need to change the install path from bindir to libdir? | 16:09 |
| ant_work | aimetis0: or adjust the other recipe to point to the right dir...maybe it i not in path | 16:09 |
| ant_work | maybe | 16:09 |
| kergoth | Anyone seen the 'cpio' image fstype working but cpio.gz not? I'm guessing it could be related to the COMPRESS_CMD stuff | 16:10 |
| kergoth | also, 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 eyes | 16:10 | |
| ant_work | kergoth: .gz and .lzma ok in meta-handheld | 16:10 |
| fray_ | I've had reports in the past it didn't work -- but those turned out to be kernel configuration | 16:10 |
| aimetis0 | ant_work: do you need to see the populate_sysroot log. and run. files as well? | 16:10 |
| lpapp | fray_: was it you with whom I discussed gdb issues? I cannot recall. | 16:11 |
| fray_ | probably | 16:11 |
| lpapp | fray_: 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@39.42.77.113> has joined #yocto | 16:13 | |
| fray_ | no, the source folders are relative to the debug image.. | 16:13 |
| fray_ | so the system should resolve those automatically | 16: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_work | aimetis0: check out the STAGING_ vars in conf/bitbake.conf | 16: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/206 | 16:16 | |
| lpapp | fray_: well, I am getting no such file or directory in gdb | 16:16 |
| fray_ | on which, the source? | 16:16 |
| lpapp | yes | 16:17 |
| fray_ | is it showing you the '/usr/src/debug/recipe/...'? | 16:17 |
| fray_ | and this is cross? | 16:17 |
| ant_work | kergoth: fwiw we use INITRAMFS_FSTYPES | 16:17 |
| lpapp | fray_: I think .debug/foo is found, but that does not contain the source. | 16:17 |
| lpapp | fray_: 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 |
| lpapp | fray_: 81 ../sysdeps/unix/syscall-template.S: No such file or directory. | 16:19 |
| lpapp | 906 src/foo.c: No such file or directory. | 16:19 |
| lpapp | src/foo.c is my own file. | 16:19 |
| fray_ | ahh.. ok.. there will be some sources that are not available | 16:19 |
| fray_ | Did you compile this using OE, or directly with the compiler? | 16:19 |
| *** Nitin <Nitin!nakamble@nat/intel/x-fopiihskbnavrlby> has joined #yocto | 16:20 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 16:20 | |
| lpapp | fray_: bitbake foo-core-image-dbg | 16: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 GDB | 16:20 |
| lpapp | ./tmp/work/foo-foo-linux-gnueabi/foo-core-image-dbg/1.0-r0/rootfs/usr/src/debug/foo/AUTOINC+0c2cbe33e653afa335ca25156d293552001228fa-r0/git/src/foo.c | 16: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/204 | 16:20 | |
| lpapp | fray_: 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 |
| lpapp | fray_: 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 source | 16:21 |
| lpapp | but 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 |
| lpapp | ok, 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 info | 16: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 IRC | 16: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 avaialble | 16:22 |
| lpapp | fray_: 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 |
| lpapp | fray_: how to do that? | 16:24 |
| fray_ | I'll look quickly.. | 16:24 |
| lpapp | readelf -a foo | grep -i dwarf -> gives no results. | 16:25 |
| lpapp | --dwarf-depth=N Do not display DIEs at depth N or greater | 16:25 |
| lpapp | --dwarf-start=N Display DIEs starting with N, at the same depth | 16:25 |
| lpapp | or deeper | 16:25 |
| fray_ | not foo, the .debug version.. | 16:25 |
| lpapp | do not worry, that is foo | 16:25 |
| lpapp | .debug/foo | 16:25 |
| lpapp | with the long pa th | 16:25 |
| fray_ | still looking for the right option | 16:27 |
| fray_ | readelf --debug-dump .debug/foo | 16:27 |
| fray_ | look at the output for | 16:28 |
| *** phantoxe <phantoxe!~destroy@2001:5c0:1400:b::392b> has quit IRC | 16:28 | |
| fray_ | DW_AT_comp_dir and DW_AT_name | 16:28 |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 16:28 | |
| fray_ | the -dir- entry specifies the directory of the debug source, while the -name- is the filepath within that directory | 16:28 |
| lpapp | too bloated output | 16:28 |
| lpapp | anyway, it shows the right directory. | 16:29 |
| lpapp | yet the source is unavailable. | 16:29 |
| fray_ | from a busybox I had handy: | 16:29 |
| fray_ | <18> DW_AT_name : ../sysdeps/i386/start.S | 16: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/csu | 16: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/appletli | 16:30 |
| fray_ | b.c | 16:30 |
| fray_ | <212> DW_AT_comp_dir : (indirect string, offset: 0x26c): /usr/src/debug/busybox/1.22.1-r32/busybox-1.22.1 | 16:30 |
| lpapp | I do not know why Yocto is generating wrong .debug/foo | 16:31 |
| lpapp | it 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 path | 16:31 |
| lpapp | path changed? Wait, what? | 16:32 |
| lpapp | I 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 |
| lpapp | ok, 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 issue | 16: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 |
| lpapp | yes | 16:34 |
| lpapp | yet, 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 item | 16: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 |
| lpapp | I already use set sysroot | 16:35 |
| lpapp | https://sourceware.org/ml/gdb/2014-08/msg00077.html | 16:36 |
| 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/212 | 16:36 | |
| fray_ | looking at that email.. the syscall-template.S won't be found.. you need to ignore that | 16:37 |
| lpapp | well, all I can say is that it does not work. | 16:37 |
| fray_ | however the src/bar.c should be | 16:37 |
| lpapp | well, 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 load | 16:38 |
| fray_ | again, it should be referencing the two DWARF entries to build a full path and referencing it inside of the sysroot | 16:38 |
| lpapp | too 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 else | 16:38 |
| lpapp | well, can I say that I am extremely annoyed? | 16:40 |
| lpapp | as an end user I expected this just to work. :( | 16:40 |
| lpapp | I 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 IRC | 16:40 | |
| fray_ | or figure out why it's not working and lets get it fixed.. | 16:41 |
| lpapp | I 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 wrong | 16:41 |
| lpapp | I think I will work it around anyhow; and I am letting Don Quixote stay in his book. | 16:42 |
| lpapp | fray_: 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 #yocto | 16:47 | |
| lpapp | fray_: is this OK? | 16:47 |
| fray_ | I don't see anything obviously wrong with it | 16:49 |
| *** fusman1 <fusman1!~fahad@39.42.87.49> has joined #yocto | 16:50 | |
| lpapp | fray_: and with the gdb command? | 16:50 |
| *** fusman <fusman!~fahad@39.42.77.113> has quit IRC | 16:53 | |
| lpapp | fray_: 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 IRC | 16:56 | |
| *** manuel___ <manuel___!~manuel_@p57921144.dip0.t-ipconnect.de> has joined #yocto | 16: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 loading | 16:57 |
| *** Kwarf_ <Kwarf_!~Kwarf@h-253-185.a158.priv.bahnhof.se> has joined #yocto | 16:58 | |
| *** Kwarf <Kwarf!~Kwarf@h-253-185.a158.priv.bahnhof.se> has quit IRC | 16:58 | |
| lpapp | fray_: I do not know how to print that out. | 16:58 |
| lpapp | sysroot is obviously good, yeah. | 16:58 |
| *** [Sno] <[Sno]!~Sno]@static-87-79-200-121.netcologne.de> has joined #yocto | 17:01 | |
| *** microd <microd!~cobra-adm@amper.esg.de> has quit IRC | 17:04 | |
| *** ddom <ddom!~ddom@p4FFD9115.dip0.t-ipconnect.de> has quit IRC | 17:04 | |
| *** tmpsantos <tmpsantos!~tmpsantos@192.198.151.43> has quit IRC | 17:08 | |
| *** Kwarf_ <Kwarf_!~Kwarf@h-253-185.a158.priv.bahnhof.se> has quit IRC | 17:11 | |
| lpapp | fray_: btw, why shall I ignore the first warning anyhow? Shouldn't Yocto be able to generate that properly? | 17:19 |
| lpapp | fray_: 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 don | 17:26 |
| fray_ | we don't know the path to the GCC support files.. | 17:26 |
| lpapp | why 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 references | 17:29 |
| lpapp | it 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 IRC | 17: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 system | 17:29 |
| lpapp | so 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 files | 17:32 |
| fray_ | (might affect a small piece of glibc as well) | 17:32 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 17:33 | |
| lpapp | well, anyway, if you do not have more ideas, will you have time to try to reproduce it any soon? | 17:33 |
| *** sameo <sameo!~samuel@192.55.54.40> has quit IRC | 17: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 |
| lpapp | I 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 |
| lpapp | well, 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 |
| lpapp | it has been three days now that I am trying to get this gdb(server) thing work without much success. | 17:36 |
| lpapp | have been trying* | 17:36 |
| lpapp | it is getting out-of-order now so that I need to find workarounds. | 17:36 |
| *** belen <belen!Adium@nat/intel/x-oxhhljznayqunolb> has quit IRC | 17:38 | |
| lpapp | I think someone should blog about how to use gdbserver with Yocto successfully. | 17:38 |
| lpapp | I 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 frame | 17:46 |
| lpapp | the yprm is not enough for this | 17:47 |
| lpapp | yes, 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/208 | 17:47 | |
| *** MDR <MDR!~mdrustad@134.134.139.70> has joined #yocto | 17:47 | |
| *** MDR <MDR!~mdrustad@134.134.139.70> has quit IRC | 17: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 #yocto | 17:53 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 18:01 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 18:06 | |
| *** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-jvfcyaxrrqqldrrk> has quit IRC | 18:08 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-fopiihskbnavrlby> has quit IRC | 18:14 | |
| *** imphil_ <imphil_!~philipp@2001:a60:113b:6701:21d:9ff:fe33:c8f3> has joined #yocto | 18:22 | |
| *** cbzx <cbzx!~cbzx@99.224.76.14> has joined #yocto | 18:24 | |
| *** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has joined #yocto | 18:31 | |
| *** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto | 18:31 | |
| *** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has quit IRC | 18:31 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 18:31 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-styurkedzrjtqlcy> has joined #yocto | 18:31 | |
| *** Nitin1 <Nitin1!nakamble@nat/intel/x-intemqncifdtcjby> has joined #yocto | 18:34 | |
| *** sameo <sameo!samuel@nat/intel/x-kqtmbgfknhaxutpx> has joined #yocto | 18:36 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-styurkedzrjtqlcy> has quit IRC | 18:36 | |
| *** fusman1 <fusman1!~fahad@39.42.87.49> has quit IRC | 18:41 | |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 18:42 | |
| *** sameo <sameo!samuel@nat/intel/x-kqtmbgfknhaxutpx> has quit IRC | 18:45 | |
| *** sameo <sameo!~samuel@192.55.55.37> has joined #yocto | 18:46 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has quit IRC | 18:51 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto | 18:51 | |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 18:56 | |
| *** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 18:57 | |
| *** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has joined #yocto | 18:57 | |
| *** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has quit IRC | 19:14 | |
| *** [Sno] <[Sno]!~Sno]@static-87-79-200-121.netcologne.de> has quit IRC | 19:46 | |
| *** ant__ <ant__!~andrea@host69-169-dynamic.56-82-r.retail.telecomitalia.it> has joined #yocto | 20:14 | |
| *** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC | 20:23 | |
| *** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto | 20:23 | |
| *** stunpix_ <stunpix_!~Stunpix@46.119.72.244> has joined #yocto | 20:27 | |
| *** [Sno] <[Sno]!~Sno]@p578b540c.dip0.t-ipconnect.de> has joined #yocto | 20:39 | |
| *** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC | 20:50 | |
| *** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto | 20:58 | |
| *** stunpix_ <stunpix_!~Stunpix@46.119.72.244> has quit IRC | 21:15 | |
| *** theguy <theguy!~theguy@S0106602ad07d0544.gv.shawcable.net> has joined #yocto | 21:19 | |
| theguy | Hey everybody | 21:19 |
| theguy | Can anyone help me figure out why my LCD is shutting off after 15 minutes? | 21:19 |
| *** Nitin <Nitin!~nakamble@134.134.137.71> has joined #yocto | 21:21 | |
| *** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has joined #yocto | 21:24 | |
| *** Nitin1 <Nitin1!nakamble@nat/intel/x-intemqncifdtcjby> has quit IRC | 21:24 | |
| *** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has quit IRC | 21:24 | |
| *** Nitin <Nitin!~nakamble@134.134.137.71> has quit IRC | 21:34 | |
| kroon | theguy, console driver blanking automatically maybe ? | 21:35 |
| paulg | setterm -blank 0 | 21:37 |
| paulg | and see what happens. | 21:37 |
| *** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC | 21:41 | |
| theguy | My system doesn't have setterm. I was hoping to solve the problem without it if possible? | 21:44 |
| theguy | This is what I've tried so far: | 21:45 |
| kroon | theguy, look for "blank" under /sys/class/graphics | 21:45 |
| theguy | ok I'll look | 21:46 |
| *** RzR <RzR!~RzR@82.236.136.171> has quit IRC | 21:46 | |
| theguy | There's no "blank" under /sys/class/graphics | 21:46 |
| kroon | oh | 21:46 |
| theguy | oh there is under /sys/class/graphics/fb0 | 21:46 |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC | 21:47 | |
| theguy | I've tried echo 0 > /sys/class/graphics/fb0/blank | 21:47 |
| theguy | I've also tried: | 21:47 |
| theguy | passing consoleblank=0 to bootargs | 21:47 |
| theguy | modifying drivers/tty/vt/vt.c with static int blankinterval = 0; | 21:47 |
| theguy | echo -e -n '\033[9]' > /dev/tty1 | 21:48 |
| theguy | without any effect | 21:48 |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto | 21:50 | |
| kroon | i had the same problem.. i ended up unbinding the driver vtcon | 21:50 |
| kroon | apparently, after rechecking my history | 21:51 |
| *** sullical_ <sullical_!~sullical@134.134.139.76> has quit IRC | 21:51 | |
| theguy | Oh, can you elaborate a little bit? What does that driver do? | 21:52 |
| kroon | but it sounds like it might not do the trick in your case | 21:52 |
| kroon | vtcon, virtual console | 21:52 |
| kroon | it was responsible for blanking during no activity | 21:52 |
| kroon | echo 0 > /sys/class/vtconsole/vtcon1/bind | 21:53 |
| theguy | Thanks! I'll give that a try | 21:53 |
| *** EddyLaiTW <EddyLaiTW!~eddylai@61-231-113-247.dynamic.hinet.net> has joined #yocto | 21:54 | |
| theguy | Just 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 goes | 21:56 |
| *** theguy <theguy!~theguy@S0106602ad07d0544.gv.shawcable.net> has quit IRC | 22:00 | |
| *** bfederau <bfederau!~quassel@service.basyskom.com> has quit IRC | 22:01 | |
| *** bfederau <bfederau!~quassel@service.basyskom.com> has joined #yocto | 22:01 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 22:02 | |
| *** sameo <sameo!~samuel@192.55.55.37> has quit IRC | 22:03 | |
| *** Nitin <Nitin!~nakamble@134.134.139.76> has joined #yocto | 22:07 | |
| *** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has quit IRC | 22:10 | |
| *** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has quit IRC | 22:17 | |
| *** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has joined #yocto | 22:21 | |
| *** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has quit IRC | 22:25 | |
| *** sullical <sullical!~sullical@192.55.54.40> has joined #yocto | 22:26 | |
| *** ant__ <ant__!~andrea@host69-169-dynamic.56-82-r.retail.telecomitalia.it> has quit IRC | 22:29 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has quit IRC | 22:34 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto | 22:34 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC | 22:38 | |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has quit IRC | 22:44 | |
| *** Sput <Sput!~sputnick@quassel/developer/sput> has joined #yocto | 22:44 | |
| *** besquive <besquive!~besquive@198.145.38.126> has joined #yocto | 22:47 | |
| *** undertaker27 <undertaker27!a2610932@gateway/web/freenode/ip.162.97.9.50> has joined #yocto | 23:06 | |
| *** cbzx <cbzx!~cbzx@99.224.76.14> has quit IRC | 23:06 | |
| *** sjolley <sjolley!~sjolley@134.134.139.76> has quit IRC | 23:07 | |
| *** agust <agust!~agust@p4FDE7025.dip0.t-ipconnect.de> has quit IRC | 23:12 | |
| *** undertaker27 <undertaker27!a2610932@gateway/web/freenode/ip.162.97.9.50> has quit IRC | 23:13 | |
| *** besquive <besquive!~besquive@198.145.38.126> has quit IRC | 23:14 | |
| *** besquive <besquive!~besquive@198.145.38.126> has joined #yocto | 23:16 | |
| *** hsychla__ <hsychla__!~hsychla@port-87-193-170-219.static.qsc.de> has joined #yocto | 23:16 | |
| *** hsychla_ <hsychla_!~hsychla@pd95c9392.dip0.t-ipconnect.de> has quit IRC | 23:19 | |
| *** hsychla__ <hsychla__!~hsychla@port-87-193-170-219.static.qsc.de> has quit IRC | 23:23 | |
| *** hsychla__ <hsychla__!~hsychla@pd95c9392.dip0.t-ipconnect.de> has joined #yocto | 23:23 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 23:27 | |
| *** EddyLaiTW <EddyLaiTW!~eddylai@61-231-113-247.dynamic.hinet.net> has quit IRC | 23:35 | |
| *** imphil_ <imphil_!~philipp@2001:a60:113b:6701:21d:9ff:fe33:c8f3> has quit IRC | 23:36 | |
| *** Nitin <Nitin!~nakamble@134.134.139.76> has quit IRC | 23:52 | |
| *** sjolley <sjolley!~sjolley@134.134.139.76> has joined #yocto | 23:55 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!