| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 00:01 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 00:05 | |
| *** sameo <sameo!samuel@nat/intel/x-tetlhmiwjemdbjlq> has quit IRC | 00:09 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-tuzmlaanwvmtfddj> has quit IRC | 00:18 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-jwarwcnsqbvjydeb> has joined #yocto | 00:18 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 00:23 | |
| *** _julian <_julian!~quassel@x2f10944.dyn.telefonica.de> has joined #yocto | 00:23 | |
| *** _julian_ <_julian_!~quassel@x2f09d9c.dyn.telefonica.de> has quit IRC | 00:23 | |
| *** scot <scot!~scot@130.164.62.183> has quit IRC | 00:49 | |
| *** seebs <seebs!~seebs@173-8-118-198-Minnesota.hfc.comcastbusiness.net> has joined #yocto | 00:52 | |
| *** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto | 00:52 | |
| *** jmpdelos <jmpdelos!~polk@71-34-159-151.clsp.qwest.net> has quit IRC | 00:55 | |
| *** jmpdelos <jmpdelos!~polk@71-34-152-86.clsp.qwest.net> has joined #yocto | 00:55 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 01:14 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 01:20 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-jwarwcnsqbvjydeb> has quit IRC | 01:26 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-rruaafrlkwastvux> has joined #yocto | 01:26 | |
| *** dany <dany!~Thunderbi@sestofw01.enea.se> has quit IRC | 01:32 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 01:32 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-rruaafrlkwastvux> has quit IRC | 01:38 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-qqmcnlwdpytaemdi> has joined #yocto | 01:38 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 01:40 | |
| *** seebs <seebs!~seebs@173-8-118-198-Minnesota.hfc.comcastbusiness.net> has quit IRC | 01:54 | |
| *** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto | 02:01 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 02:02 | |
| *** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC | 02:04 | |
| *** bozojoe <bozojoe!4475c643@gateway/web/freenode/ip.68.117.198.67> has quit IRC | 02:06 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-qqmcnlwdpytaemdi> has quit IRC | 02:07 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 02:19 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 02:21 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 02:22 | |
| *** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC | 02:38 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 03:05 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 03:14 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 03:15 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 03:15 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 03:21 | |
| *** musdem <musdem!~Zack@CPE98fc11766960-CM0026f3a1cd6d.cpe.net.cable.rogers.com> has joined #yocto | 03:26 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 03:26 | |
| *** musdem <musdem!~Zack@CPE98fc11766960-CM0026f3a1cd6d.cpe.net.cable.rogers.com> has quit IRC | 03:27 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 03:39 | |
| *** amarsman <amarsman!~marsman@52489B71.cm-4-1c.dynamic.ziggo.nl> has quit IRC | 03:52 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 03:56 | |
| *** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has joined #yocto | 04:03 | |
| *** jmpdelos <jmpdelos!~polk@71-34-152-86.clsp.qwest.net> has quit IRC | 04:03 | |
| *** scot <scot!~scot@130.164.62.183> has joined #yocto | 04:03 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 04:08 | |
| lpapp | sgw_: well, someone said that before (otavio) they are not needed anymore | 04:09 |
|---|---|---|
| *** alex_kag <alex_kag!~alex_kag@93.84.75.157> has joined #yocto | 04:13 | |
| lpapp | sgw_: and everyone was suggesting before to remove the previous versions, so I followed the suggestions. | 04:13 |
| *** alex_kag <alex_kag!~alex_kag@93.84.75.157> has quit IRC | 04:13 | |
| lpapp | sgw_: if you have any problem with all this, give an exact instruction ASAP what you would like to see, otherwise I would not be happy with getting u-boot blocked for 1.5 because following others' suggestions. | 04:15 |
| *** jmpdelos <jmpdelos!~polk@174-22-191-159.clsp.qwest.net> has joined #yocto | 04:16 | |
| *** Leon <Leon!~Leon@76.78.7.187> has joined #yocto | 04:17 | |
| *** Leon is now known as Guest34618 | 04:17 | |
| *** mihai <mihai!~mihai@188.27.93.142> has quit IRC | 04:18 | |
| *** LiangC <LiangC!~Leon@76.78.7.187> has quit IRC | 04:19 | |
| lpapp | jackmitchell: any critics about u-boot getting in? ^ I pleased your nit. :) | 04:25 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 04:38 | |
| *** smartin <smartin!~smartin@109.190.87.20> has joined #yocto | 04:41 | |
| *** jkridner <jkridner!~jkridner@nat/ti/x-intivwdmtzuogbbj> has joined #yocto | 04:44 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 04:44 | |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 04:50 | |
| *** alex_kag <alex_kag!~alex_kag@178.124.31.217> has joined #yocto | 04:51 | |
| *** zeeblex <zeeblex!~apalalax@134.134.137.73> has joined #yocto | 04:53 | |
| *** Guest34618 <Guest34618!~Leon@76.78.7.187> has quit IRC | 04:58 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 05:17 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 05:20 | |
| *** nitink <nitink!nitink@nat/intel/x-iynyedvfqqerjzfs> has joined #yocto | 05:21 | |
| *** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has joined #yocto | 05:33 | |
| *** vicky <vicky!~vicky@122.165.223.135> has joined #yocto | 05:43 | |
| vicky | "bitbake linux-yocto-custom -c deploy " not installing modules into the final image. | 05:44 |
| vicky | I tried bitbake linux-yocto-custom. The same. | 05:45 |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 05:50 | |
| mihai | halstead: ping | 06:13 |
| tf | vicky: building an individual package does not do anything to an image | 06:13 |
| halstead | mihai, pong | 06:16 |
| *** silviof1 is now known as silviof | 06:20 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 06:34 | |
| *** W1N9Zr0 <W1N9Zr0!~W1N9Zr0@24-246-93-30.cable.teksavvy.com> has quit IRC | 06:35 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 06:35 | |
| sgw_ | lpapp: I guess first question is did you build and test for the Poky BSP set that use u-boot? | 06:35 |
| tf | kergoth: I use the rt2800usb with rpi, havn't built a fresh images for ages though | 06:38 |
| sgw_ | khem: you still awake? | 06:39 |
| sgw_ | khem: I am having email issues, so can't reply to email right now | 06:39 |
| lpapp | sgw_: no | 06:42 |
| sgw_ | lpapp: so you don't know if they will boot correctly with this update? | 06:42 |
| lpapp | correct | 06:43 |
| *** W1N9Zr0 <W1N9Zr0!~W1N9Zr0@24-246-93-30.cable.teksavvy.com> has joined #yocto | 06:44 | |
| sgw_ | lpapp with out confirmation that the key Poky BSPs boot correctly, I can not accept this version of the patch, if you wish to submit a version that adds just the newer version of u-boot we can look at that, that way we ensure all the current bsps still work correctly. | 06:44 |
| sgw_ | lpapp: you understand the importance of having the core BSPs continue to work, I am sure. | 06:45 |
| *** orhan89 <orhan89!a7cd1668@gateway/web/freenode/ip.167.205.22.104> has joined #yocto | 06:45 | |
| lpapp | sgw_: you understand that it is not related to the bsp? | 06:46 |
| *** Zagor <Zagor!~bjst@sestofw01.enea.se> has joined #yocto | 06:46 | |
| *** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto | 06:46 | |
| lpapp | u-boot is just a loader, it loads whatever you give to it ... | 06:46 |
| lpapp | it does not differentiate ... | 06:46 |
| tf | lpapp: uh? u-boot is inherently related to bsp | 06:46 |
| lpapp | no | 06:46 |
| *** Net147 <Net147!~Net147@60-241-181-112.static.tpgi.com.au> has joined #yocto | 06:46 | |
| lpapp | it loads the firmware you supply. | 06:47 |
| lpapp | if one firmware works, I do not see how it could not work with other, really. | 06:47 |
| sgw_ | lpapp: what tf said, yes, there have been a varitey of issues with the loader since it may not support the hardware correctly | 06:47 |
| B4gder | it is a probably a matter of what you define BSP to be | 06:47 |
| Net147 | line 187: 30554 Segmentation fault (core dumped) opkg-cl -f $INSTALL_CONF_IPK -o $INSTALL_ROOTFS_IPK --force_postinstall --prefer-arch-to-version update | 06:47 |
| Net147 | any ideas? | 06:47 |
| *** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has quit IRC | 06:47 | |
| lpapp | sgw_: well, my firmware loads so if the poky stuff does not, poky is doing something wrong anyway | 06:48 |
| *** orhan89 <orhan89!a7cd1668@gateway/web/freenode/ip.167.205.22.104> has quit IRC | 06:49 | |
| sgw_ | lpapp: I think you just made my point, the older version of u-boot does not work for you, so you update it, but will the newer version work correctly for the core Poky BSPs, that has to be tested by the person either maintaining it or the person updating it. If you have not tested it with the Core BSPs then I can not take the patch, since it might break those BSPs | 06:50 |
| lpapp | sgw_: you do not follow. | 06:51 |
| lpapp | u-boot works just fine with my firmware, and it is hardly firmware related. If it is, the firmware is wrong. | 06:51 |
| lpapp | not to mention I have _never_ said older u-boot does not work for me. | 06:52 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 06:52 | |
| sgw_ | lpapp, sorry I did not mean to imply that you said that. I was inferring since you needed to update the firmware. I will happily accept a good patch that adds the new version until someone how has the hardware (I do not) can test that it will work and then remove the older versions. | 06:54 |
| lpapp | why are people suggesting different things on the mailing list than you are claiming now? | 06:55 |
| sgw_ | lpapp: case in point, if I build with the MACHINE="mpc8315e-rdb", I get the following messages and this concerns me. | 06:56 |
| sgw_ | NOTE: preferred version v2012.04% of u-boot not available (for item u-boot) | 06:56 |
| sgw_ | NOTE: versions of u-boot available: v2013.07+gitAUTOINC+62c175fbb8 | 06:56 |
| sgw_ | NOTE: Resolving any missing task queue dependencies | 06:56 |
| lpapp | sgw_: that would concern you anyway because there has been no 2012.04 | 06:57 |
| lpapp | so fix your broken stuff. :) | 06:57 |
| *** dany <dany!~Thunderbi@sestofw01.enea.se> has joined #yocto | 06:58 | |
| tf | lpapp: that's not the point, the point is you have not tested your patch | 06:58 |
| lpapp | tf: that is the point sgw_ brought up | 06:59 |
| lpapp | tf: that is totally untrue | 06:59 |
| lpapp | tf: I *did* test the patch many times. | 06:59 |
| tf | lpapp: on all the supported HW? | 06:59 |
| lpapp | yes, I went to the other cities to buy supported hardwares for fun... hell no. | 06:59 |
| lpapp | but of course, that does not mean others who wrote it works, they did not test it. | 07:00 |
| tf | lpapp: so you have not tested the patch; you are submitting patch for a bsp-specific component, you can't just test it on one random board | 07:00 |
| sgw_ | lpapp: OE-Core strives to have the latest versions where appropriate, there are situations where we need to maintain older versions of certain recipes for compatibility and licensing | 07:01 |
| lpapp | tf, you are not making sense, sorry. | 07:01 |
| bluelightning | lpapp: I'm afraid that he is | 07:01 |
| lpapp | tf: first of all, I take it insult to call our board "random", secondly, have you read what I wrote above? Have you read what people wrote on the ml? You are few weeks later with your insults. | 07:02 |
| lpapp | late* | 07:02 |
| sgw_ | lpapp: Your right, I have to apologize, we have a PREFERED_VERSION setting for the mpc8315e-rdb that is for the lack of a better work bogus at this point. I am not sure why this has not been seen in the past and will need to check into this. | 07:02 |
| sgw_ | bluelightning: morning! | 07:03 |
| lpapp | sgw_: exactly, make sure you do not blame others before verifying your stuff being working. | 07:03 |
| bluelightning | sgw_: morning... you're up late | 07:04 |
| bluelightning | lpapp: still doesn't mean this patch can be accepted prior to testing on the supported hardware | 07:04 |
| lpapp | bluelightning: it does not make any sense to accuse others "not testing just random" stuff when they are actually doing the work. Meanwhile, tf has not presented any work done in the area, so how come does he come to insult? | 07:04 |
| sgw_ | lpapp: my point still stands though, the person that updates a key recipe such as this need to test it on the appropriate hardware, not just your hardware, we need to ensure that the bsps continue to work | 07:04 |
| lpapp | sgw_: what can I say, if you do not trust others saying it works, you have to test it yourself. | 07:05 |
| lpapp | but then do not expect others will trust your saying either. | 07:05 |
| bluelightning | lpapp: you're making out that this is simple and testing on one piece of hardware is enough, sorry but it just isn't | 07:06 |
| lpapp | bluelightning: no, you are totally disregarding any prior history even though it is mentiond several times. | 07:06 |
| bluelightning | lpapp: you know what happened the first time we tried to flash an updated u-boot onto MPC8315E-RDB? it didn't work, and the device was effectively bricked. | 07:07 |
| lpapp | what is not enough is your unwillingness to dig into the existing context before making such claims. | 07:07 |
| sgw_ | lpapp: I have been working with a number of contributors and I do some testing locally, but I do not have all the hardware to test before I create the Consolidated Pull Request, so I have to rely on the submitter to have done some testing. I asked you what testing you did regarding the bsps and you answered that you had not. That's enough for me to be concerned. | 07:07 |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:07 | |
| lpapp | sgw_: I will repeat the gazillionth time for last: | 07:08 |
| lpapp | others wrote it can be removed and only updated because it has been tested and works. | 07:08 |
| lpapp | sgw_: if you do not trust others, you will have to test everything yourself, and you will slow the project significantly. | 07:08 |
| lpapp | anyway, it is your call... if you do not trust the people, you do not. | 07:09 |
| lpapp | not much we can do. | 07:09 |
| sgw_ | And I believe that that it was also mentioned some concern about reason that the older version were around for a reason as bluelightning stuggests above. | 07:09 |
| lpapp | really, it is impossible to collaborate. | 07:10 |
| sgw_ | lpapp: I have said above that I would accept a good patch that adds the new version of u-boot and we can work out later if it will work with all core/reference hardware. Then we can remove the older versions | 07:10 |
| lpapp | when I update it without deleting, I am offended. | 07:10 |
| lpapp | when I please people, I am insultd. | 07:10 |
| lpapp | offended* | 07:10 |
| lpapp | well, I do not need this. | 07:10 |
| lpapp | reject it and I do not care. | 07:11 |
| sgw_ | lpapp: have I insulted/offended you? I am telling you what I would accept for this patch | 07:11 |
| lpapp | so far both of my ways were offended ... what the heck can I do more | 07:11 |
| lpapp | nothing, if people do not like me, they do not like me. | 07:11 |
| erbo | it feels like this discussion is getting a little more "heated" then neccessary | 07:12 |
| erbo | nobody is out to insult the other | 07:12 |
| lpapp | sgw_: just tell me, lpapp we do not accept patches from you. | 07:13 |
| lpapp | and I do not waste my time to try to hlep. | 07:13 |
| lpapp | help.* | 07:13 |
| lpapp | erbo: saying "random stuff" for someone's board with a lot of effort put into is insulting in my book. | 07:16 |
| sgw_ | lpapp: I did not say that, I will accept a good patch from you, if you provide an additional recipe for the latest u-boot and it compiles correctly and is tested, I will accept it. We accept patches from the community all the time, and sometime we get broken patches and need to have revisions, and sometimes we commit changes that need further fixes after committing due to oversights. | 07:17 |
| lpapp | sgw_: this topic is way beyond the technical aspects | 07:17 |
| lpapp | sgw_: I uploaded a, then people argued for no any reason, then I made up my mind by giving up my way to please them, and submitting !a, now it is rejected with additional offense. | 07:18 |
| sgw_ | lpapp: I am not accepting your current patch because it is not tested on the core/reference bsps. | 07:18 |
| lpapp | it *is* tested | 07:18 |
| lpapp | you do not accept it is, does not make your saying true. | 07:18 |
| sgw_ | lpapp is it tested on the core/refernce bsps? | 07:19 |
| * lpapp has already replied to that million times | 07:19 | |
| erbo | lpapp: but do you really think that the intention was to insult? | 07:19 |
| lpapp | erbo: whether it was or not, it is what it is. | 07:20 |
| tf | lpapp: there has been nothing insulting said ... yet | 07:20 |
| lpapp | in short: I submitted !a, people argued, I fully disagreed, but I gave up my way to please them even though I thought they were technically wrong, and then submitting !a, I am again argued about it that what I was thinking is right, is the right thing. | 07:21 |
| ant_work | sgw_: I'm unsure I found a bug wrt sstate packing relative symlinks. RP usually touches this class. Any python specialist around? | 07:21 |
| ant_work | http://paste.debian.net/28756 | 07:21 |
| lpapp | what can *anyone* do more? | 07:22 |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 07:22 | |
| lpapp | I submitted a, people argued* | 07:22 |
| *** rikroled <rikroled!~tbn@84.55.160.118> has joined #yocto | 07:22 | |
| lpapp | tf: in your opinion... | 07:23 |
| ant_work | lpapp: I've seen you did quickly fix the stunnel recipe. good | 07:25 |
| lpapp | ant_work: ? | 07:26 |
| ant_work | EXTRA_OECONF += "--with-ssl='${STAGING_INCDIR}' --disable-fips | 07:27 |
| *** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has joined #yocto | 07:27 | |
| ant_work | hi JaMa | 07:27 |
| lpapp | ant_work: syntax error | 07:28 |
| lpapp | JaMa: have you seen my email | 07:28 |
| ant_work | argh, I did not even try to build, thinking it was already fixed :/ | 07:28 |
| lpapp | about the qt5 license errors | 07:29 |
| lpapp | ant_work: it was fixed, but what you have just written is not a correct syntax. Missing the double quote at the end. | 07:29 |
| ant_work | oh, right. c&p | 07:29 |
| lpapp | ant_work: still not sure it is the perfect way to build it, but it is building now at lesat. | 07:29 |
| lpapp | least.* | 07:29 |
| *** melonipoika_ <melonipoika_!~quassel@ip050-115.seclan.com> has joined #yocto | 07:29 | |
| *** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC | 07:30 | |
| sgw_ | lpapp: I just want to be clear, I have been giving you a consistent message in my email to you on 8/3, so I am saying the same thing here in IRC. I am asking about what testing you did to ensure we do not break the release or those bsps. | 07:31 |
| lpapp | sgw_: I am not interested anymore. | 07:31 |
| lpapp | sgw_: I have better things to do than wasting my time for going nowhere arguing with contributions. | 07:31 |
| ant_work | JaMa: with this patch I fixed the symlinks to linux-libc-headers in the sstate of klibc (checked on eglibc-initial which was initially not failing) | 07:32 |
| ant_work | JaMa: http://paste.debian.net/28756 | 07:33 |
| lpapp | JaMa: meta-qt5 master head is still broken? | 07:33 |
| lpapp | or why am I getting those errors? | 07:33 |
| RP | ant_work: I suspect you're calling the class incorrectly, probably an extra "/" somewhere there shouldn't be one | 07:35 |
| ant_work | hi RP | 07:35 |
| RP | ant_work: I'd be surprised if we hadn't noticed that problem for as long | 07:36 |
| ant_work | I checked the log.do_populate_sstate with debug | 07:36 |
| ant_work | there it needs a ../more | 07:36 |
| ant_work | I'm sorry I don't have the buildsystem here... | 07:36 |
| ant_work | rP.. err.. log.do_populate_sysroot ofc | 07:37 |
| RP | ant_work: which recipe an was this with master? | 07:38 |
| ant_work | fresh pull after your gcc changes | 07:38 |
| ant_work | note that the paths in the ipk package are ok (hardcoded) | 07:38 |
| RP | ant_work: I've not merged those yet? | 07:38 |
| RP | ant_work: which recipe are you building? | 07:39 |
| ant_work | it's klibc | 07:39 |
| RP | ant_work: ok, can you reproduce this with something in core? | 07:39 |
| ant_work | I tested eglibc-initial | 07:39 |
| ant_work | it's a bit different but packages the symlinks to asm asm-generic and linux as well | 07:40 |
| ant_work | oh, RP, .. and there is a slash too much in the expanded sstate paths, i.e. ../../../..//sysroots/ blah | 07:41 |
| vicky | tf: I did "bitbake image" that also results the same | 07:41 |
| *** sameo <sameo!samuel@nat/intel/x-hyfdlkgbghsvcudy> has joined #yocto | 07:42 | |
| ant_work | RP: this second issue is maybe 0109a3623a19f9ae289952a4f054e53c3eca4eaa | 07:42 |
| ant_work | but let's it for afterwards | 07:43 |
| tf | vicky: are the modules you want getting packaged? | 07:43 |
| vicky | No. I want getting them installed into images | 07:44 |
| tf | vicky: I get that, but are the packages getting generated (the ipk, rpm, or whatever you are using)? | 07:44 |
| tf | you can check by looking into the tmp/deploy/<pkgfmt>/<platform> directory | 07:45 |
| RP | ant_work: I just installed some packages with relative symlinks and they do appear ok (e.g. the libexec files in gcc-cross) | 07:47 |
| ant_work | RP: have you checked the number of ../ iterations in the logs? | 07:48 |
| RP | ant_work: I checked in the sysroot whether the right files were created | 07:49 |
| ant_work | RP: somehow klibc fails without the patch and eglibc-initial did not fail after the patch | 07:49 |
| ant_work | RP: I get broken symlinks after build from sstate, that's how I found it | 07:51 |
| RP | ant_work: I'm now confused. You're saying it breaks after the patch in klibc ? | 07:51 |
| ant_work | nothing breaks | 07:52 |
| ant_work | klibc breaks without | 07:52 |
| RP | ant_work: oh, the patch you mean your patch | 07:52 |
| ant_work | yes, sorry | 07:52 |
| ant_work | we just set KLIBCKERNELSRC=${STAGING_DIR_TARGET}${exec_prefix} | 07:52 |
| RP | ant_work: when did it start breaking? | 07:52 |
| ant_work | JaMa's autobuilder discovered it | 07:53 |
| ant_work | at least 3 months ago | 07:55 |
| ant_work | initially there were other issues, patched | 07:55 |
| ant_work | then strange failures due to broken /asm /asm-generic and /linux symlinks to linux-libc-headers(-dev) | 07:56 |
| ant_work | honestly I never reproduced those on my host... | 07:56 |
| ant_work | but I do see the broken symlinks after klibc is extracted from sstate | 07:56 |
| RP | ant_work: which links are broken exactly? | 07:57 |
| ant_work | asm asm-generic linux | 07:57 |
| ant_work | http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/klibc/klibc-2.0.2/klibc-linux-libc-dev.patch | 07:58 |
| Net147 | no one getting this when building image with latest master? line 187: 30554 Segmentation fault (core dumped) opkg-cl -f $INSTALL_CONF_IPK -o $INSTALL_ROOTFS_IPK --force_postinstall --prefer-arch-to-version update | 07:59 |
| Net147 | I am thinking in http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=feae7a0107ced2d5e88972247d5ef53aa43a5af1 maybe exclude_list is uninitialized? | 08:01 |
| ant_work | RP: exactly, what is failing in JaMa's builds are the -klibc packages linking to the klibc's copy of the headers. That's because klibc sstate package is bad | 08:02 |
| tf | Net147: check if the struct is zeroed on allocation or not | 08:04 |
| *** swex__ <swex__!~swex@217.197.254.102> has quit IRC | 08:04 | |
| RP | ant_work: ok. I'm looking at trying to reproduce. What puzzles me is that eglibc-initial does not get corrupted. So your fix would break eglibc-initial | 08:04 |
| *** swex__ <swex__!~swex@217.197.254.102> has joined #yocto | 08:05 | |
| ant_work | strangely not...I did rebuild it... | 08:05 |
| RP | ant_work: it would only break when installed from sstate | 08:06 |
| ant_work | but pls add debug and check the do_populate_sysroot messages | 08:06 |
| RP | ant_work: ah, and eglibc-initial is a bad example since it recreates its symlink (see eglibc-initial.inc) | 08:06 |
| ant_work | heh | 08:07 |
| RP | It does this since the symlinks exit the sysroot and re-enter which breaks when you change machines | 08:07 |
| ant_work | there are not many recipes packaging symlinks to linux-libc-headers-dev | 08:08 |
| jackmitchell | lpapp: I have no issues with it now, as long as it builds and works in your usecase that seems enough for me, as (I believe) most BSP's specifically set the u-boot version, so it wouldn't make much of a difference apart from having the latest version available in the core | 08:09 |
| lpapp | jackmitchell: I removed the other versions as requested. | 08:09 |
| lpapp | jackmitchell: but again, I do not care anymore. I withdrew it | 08:10 |
| jackmitchell | however, I don't answer when QA goes pear shaped ;) | 08:10 |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 08:11 | |
| RP | ant_work: ok, this is not due to a length issue | 08:11 |
| *** dany <dany!~Thunderbi@sestofw01.enea.se> has quit IRC | 08:11 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:12 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 08:12 | |
| RP | ant_work: it breaks since you exit the sysroot and re-enter it | 08:12 |
| *** dany <dany!~Thunderbi@192.36.1.230> has joined #yocto | 08:13 | |
| lpapp | jackmitchell: means? | 08:16 |
| RP | ant_work: the issue is when you build for one machine, save it to sstate, then in the next build you build for a different machine of the same tune | 08:16 |
| Net147 | tf: doesn't seem to be zeroed at all | 08:17 |
| ant_work | well, each has its /sysroot/foo isn't? | 08:17 |
| *** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 08:18 | |
| jackmitchell | lpapp: I was saying, I don't mind it going in; but I don't have people getting annoyed with me when the Quality Assessment procedure breaks, especially so close to the feature freeze | 08:20 |
| jackmitchell | so I'm maybe not quite as critical ;) | 08:20 |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 08:22 | |
| tf | Net147: I think you are right, the struct is statically allocated, and there is no memset, afaict | 08:23 |
| ant_work | RP: all the path substitutions done in sstate are referring to dirs under /sysroot/qemuarm. Not in sysroot/armv5-... | 08:23 |
| RP | ant_work: you are right, there is something wrong with the symlink handling. I can only assume we don't have any packages making absolute symlinks | 08:24 |
| JaMa | lpapp: meta-qt5/master doesn't have your broken commit anymore, so no, it's not broken | 08:24 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 08:25 | |
| RP | ant_work: In fact these symlinks are broken anyway as they'd not work in any klibc-dev package on target | 08:25 |
| lpapp | JaMa: it is not related to my commit in any way possible. | 08:25 |
| lpapp | JaMa: it is master which is broken actually | 08:25 |
| lpapp | qtserialport *is* not in charge of setting generic qt5 license stuff.. it should only set its own | 08:25 |
| ant_work | RP: once fixed they work because on target we have linux-libc-headers (dependency of klibc) | 08:26 |
| ant_work | linux-libc-headers-dev is the package providing those exactly | 08:26 |
| RP | ant_work: look in the klibc-dev.ipk file and you'll see a asm-generic -> /media/build1/poky/build/tmp/sysroots/qemux86/usr/include/asm-generic | 08:27 |
| ant_work | RP: once we used kernel source to build klibc. Debian moved using linux-libc-headers. For me, there is the advantage that klibc is arch-specific that way but maybe something is wrong... | 08:27 |
| RP | ant_work: we don't fix up absolute symlinks in the .ipk | 08:27 |
| JaMa | lpapp: yes it should set correct one, but it doesn't so it's qtserialport fault | 08:28 |
| JaMa | lpapp: you said that you've tested qtserialport change, but sent wrong version accidentally <- I don't think so, when you don't even know how to set LIC_FILES_CHKSUM correctly | 08:29 |
| JaMa | https://github.com/meta-qt5/meta-qt5/commit/54d1f81e8410c69b659be8608a9b3273554492e9 this is the fix | 08:30 |
| JaMa | ant_work: I haven't seen it yet, but good work hunting that issues, thanks! | 08:31 |
| lpapp | JaMa: I have no any idea what you mean. | 08:32 |
| lpapp | it worked properly last time, and setting the checksum is explicitly not the task for qtserialport as no other recipes do so either. | 08:32 |
| JaMa | that isn't correct | 08:33 |
| *** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC | 08:34 | |
| lpapp | JaMa: you might wanna check qtsensors then. | 08:34 |
| lpapp | you might be surprised. | 08:34 |
| lpapp | or qtjsbackend, etc. | 08:35 |
| Net147 | tf: okay. I have patched it. will test if it fixes and submit patch within an hour or so. | 08:35 |
| lpapp | actually, even qtdeclarative. Yeah, none of those is really setting the license thingie. | 08:35 |
| *** honschu <honschu!~honschu@p549E8CA7.dip0.t-ipconnect.de> has joined #yocto | 08:36 | |
| *** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto | 08:36 | |
| *** Net147 <Net147!~Net147@60-241-181-112.static.tpgi.com.au> has quit IRC | 08:36 | |
| JaMa | lpapp: because they have the same as default value, qtserialport does not | 08:36 |
| lpapp | JaMa: ? | 08:37 |
| lpapp | it should have no any difference. | 08:37 |
| JaMa | sigh | 08:37 |
| lpapp | perhaps I kinda know it as the qtserialport maintainer. :) | 08:38 |
| lpapp | I copied the same stuff from the rest of qtbase. | 08:38 |
| lpapp | so if there is any difference in openembedded, it is a bug in openembedded. | 08:39 |
| JaMa | I don't have time to teach you to compare 2 files and this isn't right channel to do it, sorry | 08:40 |
| *** dany <dany!~Thunderbi@192.36.1.230> has quit IRC | 08:43 | |
| RP | ant_work: that code is just completely broken :/ | 08:44 |
| RP | It happens to work for one particular directory level | 08:44 |
| *** blitz00_ <blitz00_!stefans@nat/intel/x-auuzqpauluvztdbv> has joined #yocto | 08:45 | |
| ant_work | RP: ah, see, I was under sysroot-destdir/lib/klibc/include as pwd | 08:46 |
| lpapp | JaMa: there is no any need to compare and teach that, as you are wrong. | 08:46 |
| *** dany <dany!~Thunderbi@79.102.125.34> has joined #yocto | 08:46 | |
| lpapp | open up the qtsensors, qtdeclarative, etc files and tell others where you find license information. | 08:46 |
| RP | ant_work: klibc is broken as well mind ;-) | 08:47 |
| ant_work | yes..if as you say the path in the ipk are not relative... | 08:47 |
| *** mitz_ <mitz_!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 08:48 | |
| lpapp | can anyone see what JaMa means by having license checksums in this and similar files? https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtsensors_5.1.0.bb | 08:48 |
| JaMa | lpapp: sorry I'm going ot ignore you again, because this is waste of my time | 08:48 |
| *** Anusko <Anusko!~anusko@62.159.77.165> has quit IRC | 08:48 | |
| lpapp | nice maintainer behavior... ignoring people asking for clarification ... | 08:49 |
| *** Anusko <Anusko!~anusko@62.159.77.165> has joined #yocto | 08:49 | |
| lpapp | anyone, can anyone else see what JaMa means? He is not willing to clarify it. | 08:49 |
| lpapp | anyway* | 08:49 |
| *** mitz_ <mitz_!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 08:50 | |
| JaMa | this isn't asking.. this is arguing about your broken change, complaining that master is broken even when it's not and NOT reading what I wrote to you | 08:50 |
| *** belen <belen!Adium@nat/intel/x-bgyncwiuoedmdmhb> has joined #yocto | 08:50 | |
| JaMa | lpapp: learn to use bitbake -e and you'll find where they get LIC_FILES_CHKSUM | 08:51 |
| ant_work | RP: imagine that right those days thers is an hot topit like [klibc] Build problems: klibc with Linux 3.10.7 | 08:51 |
| lpapp | JaMa: it is a different layer than bitbake -e | 08:51 |
| JaMa | ? | 08:52 |
| *** dany <dany!~Thunderbi@79.102.125.34> has quit IRC | 08:54 | |
| lpapp | JaMa: I think I found the main reason for it. | 08:57 |
| lpapp | QtSerialPort is developed by me and a russian guy, and we discarded the custom Digia stuff from the license headers. | 08:57 |
| JaMa | so you finally learned to compare 2 files, good | 08:58 |
| lpapp | no, I finally found the reason for an obscure issue. | 08:58 |
| JaMa | and it cost me 20 minutes and ruined breakfast | 08:58 |
| lpapp | you are very lucky a very obscure issue is figured out in 20 minutes. | 08:59 |
| lpapp | people occasionally spend weeks with such issues. | 08:59 |
| JaMa | it's problem for 1 minute if you just diff the files as I said before | 09:00 |
| eren | JaMa: relax. If you were here in Passau I would like to order you a weissbier to make you calm :) | 09:00 |
| RP | ant_work: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip76&id=677189826214b569b589c213eb8b0d56cf3f6aa7 | 09:00 |
| JaMa | eren: :) | 09:00 |
| eren | JaMa: are there any somewhat mechanical work (like PKGCONFIG variables) left? It seems that newbies can handle the job | 09:02 |
| ant_work | RP: great, thx | 09:02 |
| *** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 09:02 | |
| RP | ant_work: I've mailed it out | 09:02 |
| RP | ant_work: quite amazing how broken that code was | 09:02 |
| JaMa | eren: yes, many, but sometimes PACKAGECONFIG variables aren't so mechanical | 09:02 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 09:03 | |
| JaMa | eren: there is list of issues in "State of bitbake world" thread if you know about any newbie willing to help | 09:03 |
| eren | well, I am | 09:03 |
| eren | :P | 09:03 |
| *** florian_kc is now known as florian | 09:03 | |
| eren | I am a little done with ALIX3D3 BSP, I guess I can do some packaging work | 09:04 |
| BCMM | JaMa: where is this list of issues? | 09:05 |
| JaMa | eren: BCMM: http://lists.openembedded.org/pipermail/openembedded-core/2013-August/082530.html | 09:07 |
| BCMM | thanks | 09:07 |
| lpapp | ant_work: the devs were asking how to improve the build system for stunnel | 09:07 |
| eren | thanks, and the problem is which of these were fixed | 09:08 |
| lpapp | ant_work: I guess the improvement would be if they did not depend on with-ssl. | 09:08 |
| eren | I guess there is no list for it? I will simply look at master commits | 09:08 |
| lpapp | yocto usually uses the prefix stuff for the autotools configure? | 09:08 |
| JaMa | eren: BCMM: I have pending patch for firefox which will replace firefox with nss in some autodetected dependencies, but other than that all are free for you :) | 09:09 |
| ant_work | RP: I'll try the patch to the class and regarding klibc well, I'm still confused but I see the probable issue | 09:09 |
| JaMa | I'll send updated list in 20hours or so, new build is running since yesterday | 09:09 |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto | 09:09 | |
| ant_work | RP: +export prefix = $(INST) | 09:10 |
| BCMM | JaMa: i'm afraid i just wanted to read it in case it contained stuff i should know to use it | 09:10 |
| ant_work | RP: -export prefix = /usr | 09:10 |
| BCMM | JaMa: i'm very unfamiliar with the project at the moment | 09:10 |
| ant_work | RP: ant for the lib export INST = "${D}" | 09:10 |
| eren | JaMa: okkie, I will look at the available configuration option, and disable/enable them with PACKAGECONFIG | 09:10 |
| JaMa | eren: thanks a lot, you can see many examples from last patchsets I've sent | 09:11 |
| eren | yep, most of them are quite straightforward | 09:11 |
| ant_work | RP: "INSTALLROOT is some sort of DESTDIR: it’s a præfix only present | 09:11 |
| ant_work | at *file installation* time but n̲o̲t̲ at runtime." | 09:11 |
| JaMa | eren: small advice: it's good to start with failing recipes (min builds) | 09:11 |
| ant_work | RP: so the puzzle is to combine prefix and INSTALLROOT | 09:12 |
| *** dany <dany!~Thunderbi@sestofw01.enea.se> has joined #yocto | 09:12 | |
| eren | JaMa: oh, I was going to start from this file: http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/log.world.20130808_230701.log/dependency-changes.warn | 09:12 |
| *** tanamo <tanamo!cb7dac02@gateway/web/freenode/ip.203.125.172.2> has quit IRC | 09:12 | |
| JaMa | eren: feel free to send patches one-by-one instead of bigger pull requests, this way we'll know what's done and I'll integrate them into jenkins build to give you confirmation later | 09:13 |
| JaMa | eren: you can start from dependency-changes.warn but it's possible that it doesn't contain complete list, because some deps weren't built | 09:14 |
| eren | JaMa: okkie, OE-Core with master branch. I will build core-image-minimal for qemu86 | 09:14 |
| eren | with distro set to poky? | 09:14 |
| eren | ah no, you use DISTRO_VERSION = "oe-core.0" | 09:15 |
| JaMa | eren: I use distro-less config, but most of these dependency issues aren't DISTRO specific | 09:15 |
| JaMa | so you can use any distro you like to fix them | 09:15 |
| eren | okkie | 09:16 |
| JaMa | e.g. last time I was using distro without x11 DISTRO_FEATURE, so I've missed all these issues found now :) | 09:16 |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 09:17 | |
| *** AndersD <AndersD!~anders.da@pc-193-235-91-228.norrkoping.se> has joined #yocto | 09:23 | |
| *** AndersD is now known as Guest96104 | 09:23 | |
| *** Guest96104 <Guest96104!~anders.da@pc-193-235-91-228.norrkoping.se> has quit IRC | 09:28 | |
| *** AndersD` <AndersD`!~anders.da@pc-193-235-91-228.norrkoping.se> has joined #yocto | 09:28 | |
| *** AndersD` <AndersD`!~anders.da@pc-193-235-91-228.norrkoping.se> has left #yocto | 09:28 | |
| *** AndersD` <AndersD`!~anders.da@pc-193-235-91-228.norrkoping.se> has joined #yocto | 09:30 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 09:30 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 09:31 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 09:35 | |
| *** jackmitchell <jackmitchell!~Thunderbi@217.34.104.101> has left #yocto | 09:37 | |
| *** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has quit IRC | 09:45 | |
| lpapp | sgw_: my last try.. I spent one hour with u-boot update to figure out all the git shortcomings. | 09:48 |
| lpapp | if this does not make you happier either, and do not appreciate the contribution, there is little to nothing, I can do more. | 09:48 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 09:54 | |
| *** bluelightning <bluelightning!~paul@83.217.123.106> has joined #yocto | 09:56 | |
| *** bluelightning <bluelightning!~paul@83.217.123.106> has quit IRC | 09:56 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:56 | |
| *** zecke <zecke!~ich@p5099b351.dip0.t-ipconnect.de> has joined #yocto | 09:58 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 10:01 | |
| *** smartin <smartin!~smartin@109.190.87.20> has quit IRC | 10:02 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 10:07 | |
| -YoctoAutoBuilder- build #273 of nightly-x32 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x32/builds/273 | 10:13 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 10:15 | |
| BCMM | anybody else using the raspberry pi bsp? | 10:27 |
| lpapp | BCMM: sure | 10:27 |
| *** vicky <vicky!~vicky@122.165.223.135> has quit IRC | 10:28 | |
| BCMM | lpapp: i'm trying to work out what causes the SD card image to get made. I know it's in sdcard_image-rpi.bbclass, but i don't understand what causes that to execute. | 10:29 |
| BCMM | since rpi-hwup-image is just "include recipes-core/images/core-image-minimal.bb" + kernel modules | 10:31 |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 10:34 | |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has joined #yocto | 10:39 | |
| Net147 | how would I keep debugging symbols when building native recipes? | 10:41 |
| lpapp | how often is the layers.openembedded.org list updated? | 10:56 |
| bluelightning | the recipe information for each layer is updated roughly every 3 hours | 11:00 |
| bluelightning | if you mean the list of layers, new layers must be added manually | 11:00 |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC | 11:05 | |
| bluelightning | but anyone can submit a new layer, no login required | 11:05 |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto | 11:08 | |
| BCMM | is there some way to set LICENCES for a whole layer? i've basically copied a short image to my layer, and it's saying "this recipe does not have the LICENSE field set", even though the nearly-identical recipe in the original layer builds fine | 11:11 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 11:14 | |
| BCMM | just adding LICENSE = "GPL" makes it say "Recipe file does not have license file information (LIC_FILES_CHKSUM)" | 11:17 |
| bluelightning | BCMM: this is an image recipe? | 11:17 |
| BCMM | yeah | 11:17 |
| bluelightning | BCMM: it doesn't by any chance do "include ...." somewhere? | 11:17 |
| BCMM | bluelightning: yeah | 11:17 |
| bluelightning | right, that'll be the problem | 11:17 |
| bluelightning | the include directive does not error out when the file doesn't exist | 11:18 |
| bluelightning | I guess in your case the file pointed to by the include directive can't be found, and that file would have contained LICENSE | 11:18 |
| BCMM | ah, and if what i'm including is in a different layer, i need to put some sort of path in? | 11:18 |
| bluelightning | plus the "inherit image" if that's not specified in the recipe | 11:18 |
| bluelightning | honestly, I'd suggest writing a proper image recipe that doesn't pull in stuff via "include..." | 11:19 |
| bluelightning | image recipes are almost always trivial | 11:19 |
| BCMM | i think i've got the problem - it worked in it's original layer by includign files in the same dir. i just needed to put in the path to use it in a differnet layer | 11:20 |
| BCMM | bluelightning: and thanks, i'll think about writing the image recipe from scratch - is there a nice resource somewhere on how to do that? | 11:21 |
| bluelightning | BCMM: there's http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage | 11:21 |
| bluelightning | BCMM: you can also have a look at the image recipes in the core (find meta -name "core-image*.bb") | 11:22 |
| lpapp | it is not recommended to put git versions of the layers into the git poky repository in third-party projects? Can that cause any issues? | 11:31 |
| *** mulhern <mulhern!~mulhern@ip-64-134-65-211.public.wayport.net> has joined #yocto | 11:33 | |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 11:33 | |
| lpapp | rburton: hmpf | 11:33 |
| lpapp | rburton: ${COREBASE} -> you mentioned previously it is not used like that. | 11:34 |
| lpapp | but apparently, it is ? | 11:34 |
| lpapp | meta/conf/layer.conf | 11:34 |
| lpapp | but also in a lot of recipes. | 11:35 |
| lpapp | and classes. | 11:35 |
| lpapp | erm... hmm ? bitbake core-image-minimal | 11:42 |
| lpapp | Unable to find conf/bblayers.conf | 11:42 |
| lpapp | BitBake must be run from within your build directory: /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build | 11:42 |
| lpapp | I am trying to run bitbake core-image-minimal exactly from that folder. What is up with this? | 11:43 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 11:44 | |
| *** blitz00_ <blitz00_!stefans@nat/intel/x-auuzqpauluvztdbv> has quit IRC | 11:45 | |
| *** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC | 11:45 | |
| lpapp | I tried to delete everything in the build folder, except local.conf but still getting that; so weird. | 11:47 |
| mihai | lpapp: source oe-init-build-env again | 11:48 |
| lpapp | mihai: tried that, too. | 11:48 |
| eren | lpapp: close the terminal session, re-open it, cd into that dir and source oe-init-build-env | 11:59 |
| eren | I experienced it even if bitbake directory is present | 12:00 |
| lpapp | bitbake directory? | 12:00 |
| -YoctoAutoBuilder- build #103 of minnow-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/minnow-lsb/builds/103 | 12:01 | |
| lpapp | eren: http://paste.kde.org/~lpapp/p40aa0656/ | 12:01 |
| lpapp | all I did to the previous working version, I tried to add a bblayer.conf sample to my layer. | 12:02 |
| lpapp | to get that generated properly for . oe-s... | 12:02 |
| lpapp | . oe-init-build-env | 12:02 |
| lpapp | so with my own bsp layer. | 12:03 |
| mihai | lpapp: maybe you're missing conf/bblayers.conf, or you're using one from 1.4 with master, or from master with 1.4 | 12:04 |
| lpapp | mihai: I am not missing it. | 12:05 |
| mihai | remove bblayers.conf and source again, that should recreate a valid one | 12:05 |
| lpapp | mihai: that is what I did when got this. | 12:05 |
| lpapp | I removed, I sourced the oe init, and then I tried to run bitbake core-image-minimal | 12:05 |
| mihai | lpapp: you also have an unknown DISTRO set in local.conf, 'foo' according to your paste | 12:06 |
| lpapp | mihai: yeah, not sure why. | 12:07 |
| lpapp | I have not changed the distro name, whatsoever. | 12:07 |
| lpapp | I only added an example bblayers.conf to the bsp/distro layer. | 12:07 |
| lpapp | and fwiw, my sample is not taken into account. | 12:10 |
| lpapp | the bblayers.conf is still generated out of the yocto sample. Why? How can I override that? | 12:10 |
| mihai | lpapp: it's generated only when it doesn't exist | 12:13 |
| lpapp | yes, which should mean I should get it generated out of my layer when I remove. | 12:13 |
| lpapp | but it is generated out of the Yocto layer; so weird. Why is it like that? | 12:13 |
| lpapp | anyone any idea how to debug the bblayers.conf generation issue? | 12:23 |
| Guest37012 | can you print you bblayers.conf | 12:30 |
| Guest37012 | *your | 12:30 |
| -YoctoAutoBuilder- build #233 of nightly-fsl-ppc is complete: Failure [failed Building Toolchain Images_1 Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-ppc/builds/233 | 12:32 | |
| *** mulhern <mulhern!~mulhern@ip-64-134-65-211.public.wayport.net> has quit IRC | 12:32 | |
| lpapp | Guest37012: ? | 12:32 |
| lpapp | Guest37012: as I already wrote, it is the same as the meta-yocto stuff | 12:33 |
| lpapp | except the COREBASE replacement with the actual path of course. | 12:33 |
| lpapp | the problem is clearly that it is missing my meta-foo line | 12:34 |
| lpapp | if I add that manually, I am not getting the error. | 12:34 |
| lpapp | so the question is: why cannot I override the meta-yocto sample with my own sample? | 12:34 |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 12:34 | |
| lpapp | shouldn't that the be automatically happening? | 12:34 |
| *** mulhern <mulhern!~mulhern@ip-64-134-65-211.public.wayport.net> has joined #yocto | 12:35 | |
| mihai | lpapp: yes, the setup script does that | 12:36 |
| *** mulhern <mulhern!~mulhern@ip-64-134-65-211.public.wayport.net> has quit IRC | 12:37 | |
| lpapp | then something is fishy. | 12:37 |
| lpapp | are there e xamples out there with layers providing their sample on _top_ of meta-yocto, and _not_ without | 12:38 |
| mihai | lpapp: you could override it with TEMPLATECONF=meta-foo/conf . where bblayers.conf.sample and local.conf.sample must exist | 12:38 |
| lpapp | how does oe decide which sample to take for the generation? | 12:38 |
| mihai | lpapp: see scripts/oe-setup-builddir | 12:38 |
| lpapp | d'uh | 12:39 |
| lpapp | it is hard coded if not specified | 12:39 |
| lpapp | i.e. fall back to meta-yocto | 12:39 |
| mihai | yup | 12:40 |
| lpapp | so everyone who wanna have the own sample has to define it. | 12:40 |
| lpapp | that is why I asked for examples with other bsp layers | 12:40 |
| * lpapp goes check meta-raspberry | 12:40 | |
| mihai | you can use OECORELAYERCONF just for the bblayers conf sample | 12:40 |
| lpapp | I would like to see what others use | 12:41 |
| lpapp | so that I can just follow without reinventing my own way. | 12:41 |
| lpapp | so the next step is to find an example out there. | 12:41 |
| *** tomz <tomz!~trz@c-68-53-177-94.hsd1.in.comcast.net> has joined #yocto | 12:46 | |
| -YoctoAutoBuilder- build #259 of nightly-x86-64 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86-64/builds/259 | 12:46 | |
| *** tomz is now known as Guest62601 | 12:46 | |
| lpapp | mihai: do you know an example layer doing this? | 12:47 |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 12:48 | |
| Guest37012 | silly question. But did you copy the new bblayer.conf file to build directory | 12:49 |
| lpapp | Guest37012: ? | 12:49 |
| Guest37012 | You created the bblayers.conf file from the sample one and you copied that to the build directory right | 12:50 |
| lpapp | is there an openembedded lxr? | 12:50 |
| lpapp | for browsing recipe stuff easily with an indexer? | 12:50 |
| mihai | lpapp: i'm not aware of any layers using that | 12:51 |
| lpapp | Guest37012: no | 12:51 |
| lpapp | Guest37012: I copied the meta-yocto sample, and I copied that to my layer | 12:51 |
| lpapp | and I added one line containing the name of my layer. | 12:52 |
| lpapp | mihai: https://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html -> OECORELAYERCONF is undocumented. | 12:53 |
| lpapp | mihai: so is TEMPLATECONF | 12:54 |
| lpapp | looks like I need to create an issue on the tracker to improve those. | 12:54 |
| Guest37012 | I copied the /meta-yocto/conf/bblayers.conf.sample to ./build/conf/bblayer.confg | 12:54 |
| lpapp | it seems to be an essential feature. | 12:54 |
| Guest37012 | and added my layer to that | 12:54 |
| lpapp | Guest37012: huh, why would you do that ? | 12:54 |
| lpapp | that would epically fail on CI, and for others without manual intervention _everywhere_ | 12:55 |
| bluelightning | lpapp: neither are variables in the same sense as variables listed in the reference | 12:56 |
| lpapp | bluelightning: please, when you write such claims, write a full sentence containing the reasoning etc, not just statements. | 12:56 |
| *** zeeblex <zeeblex!~apalalax@134.134.137.73> has left #yocto | 12:57 | |
| lpapp | to avoid the useless "why?" iterations. | 12:57 |
| Guest37012 | The bblayer.conf just defines the location of the stuff and you own layer . | 12:57 |
| bluelightning | lpapp: they aren't bitbake variables, they're environment vars used only in the setup script, I figured that would be pretty obvious | 12:57 |
| lpapp | Guest37012: please read my comment on that carefully. | 12:57 |
| Guest37012 | ok sorry I was only trying to help. | 12:57 |
| lpapp | Guest37012: you do not wanna _everyone_ to manually generate those. It should just work (tm), and that is what COREBASE is for, after all. | 12:58 |
| lpapp | no doubt, but the point still has to be understood. ;-) | 12:58 |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 12:58 | |
| lpapp | bluelightning: it is not "pretty obvious". | 12:58 |
| Stygia | Hey question, how do I build PACKAGE-misc? I need to get openssl.cnf in my image, and the recipe has it in FILES_${PN}-misc, however, while I can build 'openssl' I can't build 'openssl-misc'. How am I supposed to do this? | 12:58 |
| *** mebrown <mebrown!~michael_e@99-23-196-16.lightspeed.austtx.sbcglobal.net> has quit IRC | 12:58 | |
| lpapp | and it should *definitely* be in the layer creation documentation as it is a core fundation. | 12:59 |
| lpapp | bluelightning: unless you tell me a better way. | 12:59 |
| bluelightning | Stygia: openssl-misc is a package rather than a build-time target... "openssl" is the build time target | 12:59 |
| erbo | Stygia: the openssl recipe should generate the openssl-misc package (I think) | 12:59 |
| lpapp | otherwise I am tempted to stay it is a blocker for people as they cannot guess what needs to be done for this. | 12:59 |
| lpapp | say* | 12:59 |
| erbo | Stygia: there's a difference between packages and recipes, even though they often have a one 2 one mapping | 13:00 |
| Stygia | bluelightning, Ah, hmm. So how do I get ti to include openssl.cnf? When my image includes openssl there isn't an openssl.cnf included as part of the image. | 13:00 |
| Stygia | Although it is mentioned in the recipe in FILES_${PN}-misc | 13:00 |
| lpapp | also, can anyone please let me know how to create an own sample to just work | 13:01 |
| erbo | Stygia: you image need to install openssl-misc | 13:01 |
| lpapp | there is two variables aforementioned, and no one has written yet how to actually do it in the practice .... where to put, and what exactly, etc. | 13:01 |
| lpapp | this is now blocking me. | 13:01 |
| bluelightning | Stygia: sure, I guess that package is not installed by default; you could just add it to your IMAGE_INSTALL (or RDEPENDS_${PN} / RRECOMMENDS_${PN} of another recipe, depending on the situation) | 13:01 |
| bluelightning | lpapp: typically people do not do what you're trying to do I guess | 13:01 |
| * lpapp is go to create a bugreport | 13:02 | |
| lpapp | bluelightning: actually developers suggested to do this. | 13:02 |
| lpapp | this is the correct way of creating an own layer. | 13:02 |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has quit IRC | 13:02 | |
| *** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has quit IRC | 13:02 | |
| Stygia | erbo, But running 'bitbake openssl-misc' simply says that no recipe provides it? Is it an RPROVIDES/should I add it to conf/local.conf? | 13:02 |
| bluelightning | lpapp: it's not related to creating your own layer | 13:03 |
| erbo | Stygia: but that is not for adding it to the image, you need to (as bluelightning said) add it to e.g. IMAGE_INSTALL for your image | 13:03 |
| Stygia | erbo, Yes, sorry, I missed his comemnt. | 13:03 |
| Stygia | *comment. Saw it just now, I'll try that. | 13:03 |
| Stygia | Thanks. :) | 13:03 |
| *** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto | 13:03 | |
| erbo | np :) | 13:04 |
| bluelightning | lpapp: if I understand correctly it's about the desire to have a default bblayers.conf created that points to your layer, that's not the same thing | 13:04 |
| lpapp | bluelightning: no | 13:04 |
| lpapp | bluelightning: it is related to layer creation | 13:04 |
| bluelightning | lpapp: since I've never had to do what you're doing and have created many layers, perhaps you would care to explain then | 13:04 |
| *** Derzzle <Derzzle!~Derzzle@199.59.107.73> has joined #yocto | 13:05 | |
| lpapp | bluelightning: I already did above several times. | 13:05 |
| lpapp | perhaps you would care to read then. | 13:05 |
| erbo | lpapp: you come on as quite aggressive in you communication style | 13:05 |
| *** Derzzle <Derzzle!~Derzzle@199.59.107.73> has quit IRC | 13:06 | |
| eren | JaMa: mpg123 error is caused by default distro features. Something strange is going on | 13:07 |
| Stygia | lpapp, I'm gonna agree with erbo here, every single time I've seen you, frankly, you act like a dick to people. | 13:07 |
| eren | ${@bb.utils.contains('DISTRO_FEATURES', 'alsa', '--with-default-audio=alsa', '', d)} \ | 13:07 |
| lpapp | erbo: I think the same about several people in here without mentioning such personal stuff explicitly. | 13:07 |
| Stygia | lpapp, I suspect you would fin it over at ##perl | 13:08 |
| lpapp | erbo: so please... be civil. | 13:08 |
| eren | ${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', '--with-default-audio=pulse', '', d)} \ | 13:08 |
| lpapp | and get back on track with the technical stuff. | 13:08 |
| eren | these should be mutually exclusive | 13:08 |
| *** Derzzle <Derzzle!~Derzzle@199.59.107.73> has joined #yocto | 13:09 | |
| erbo | lpapp: I just want the channel to stay friendly | 13:09 |
| lpapp | erbo: then be civil, and discuss technical stuff, not insulting others. | 13:10 |
| lpapp | just like on a normal channel ... | 13:10 |
| erbo | lpapp: come on, that was not an insult | 13:10 |
| lpapp | and do not start emotional wars when you know exactly many people jump on with different opinions. | 13:10 |
| lpapp | stay on the technical stuff... and no, disagreeing is not agressive at all. | 13:10 |
| lpapp | bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5043 | 13:10 |
| yocti | Bug 5043: normal, Undecided, ---, saul.wold, NEW , Extend the layer creation documentation with own bblayers sample creation | 13:10 |
| eren | JaMa: however, default distro vars as set in meta/conf/distro/include/default-distrovars.inc enable all the options. So, alsa and pulseaudio gets passed to mpg123 | 13:11 |
| lpapp | bluelightning: I hope that clarifies. | 13:11 |
| erbo | lpapp: I'm not starting any emotional wars. | 13:11 |
| erbo | anyway, have a nice weekend.. I think this is a good time for me to leave for the day | 13:12 |
| tf | alsa and pulse are not mutually exclusive | 13:12 |
| lpapp | erbo: thanks, you too. | 13:12 |
| JaMa | eren: I think best course of action is to convert the options to PACKAGECONFIGs and then use DISTRO_FEATURES only to select default PACKAGECONFIG | 13:12 |
| JaMa | eren: and take pulseaudio to have precedence if both are enalbed | 13:13 |
| Stygia | tf, On an unrelated note, what, they aren't? Doesn't pulse implement/handle the alsa stuff if its there? | 13:13 |
| JaMa | e.g. PACKAGECONFIG_ALSA = "${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}" | 13:13 |
| Stygia | tf, How would it work having two sound servers at once? I have pulse (on debian) and assumed it just handled all the stuff.p | 13:13 |
| JaMa | PACKAGECONFIG = "${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', '--with-default-audio=pulse', '${PACKAGECONFIG_ALSA}', d)} | 13:14 |
| Stygia | tf, ... obviously not your job to explain that to me, heh, I'm just curious to understand things like this. | 13:14 |
| tf | Stygia: see http://en.wikipedia.org/wiki/PulseAudio | 13:15 |
| JaMa | or of course if --with-default-audio allows multiple options you can pass them through another variable | 13:16 |
| Stygia | tf, Fair enough. :) | 13:16 |
| JaMa | tf: but we were talking about alsa/pulse support in mpg123, not alsa/pulse in general | 13:16 |
| tf | JaMa, sure, but the distro feature is broader than mpg123 | 13:17 |
| tf | JaMa: as you suggested, if both are present in the distro_features, give precendence to pulse | 13:17 |
| tf | I think that's the right solution | 13:18 |
| JaMa | I think this "15:09:27 < eren> these should be mutually exclusive" was about mutually exclusive configure options, not making DISTRO_FEATURES to be exclusive | 13:18 |
| tf | ok, my bad | 13:18 |
| JaMa | np | 13:18 |
| eren | JaMa: tf right | 13:19 |
| eren | JaMa: ah, I see that you used that technique in sox package | 13:19 |
| eren | ok, we are enabling PACKAGECONFIG ??= accordingly to distro features | 13:19 |
| eren | and write PACKAGECONFIG[alsa] = ... to enable configuration and dependencies | 13:20 |
| Net147 | JaMa: I have recipes for xf86-video-ati and xf86-video-nouveau. do these look ok to you? http://pastebin.com/37gQv3ct | 13:21 |
| eren | JaMa: the above PACKAGECONFIG fragments you proposed didn't make sense for me :/ | 13:21 |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 13:26 | |
| JaMa | Net147: just 2 nitpicks: 1) is LICENSE set by xorg-driver-video.inc correct? 2) you can drop PR (it's still a bit confusing when there is INC_PR in .inc ignored by .bb files, but probably better without) | 13:27 |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 13:27 | |
| JaMa | Net147: otherwise definitely good enough for ML review :) I wonder if rburton had something with nouveau when adding genericx86 | 13:28 |
| eren | what's the difference between ${@base_contains(...)} and ${@bb.utils.contains(...)} ? | 13:28 |
| Net147 | JaMa: it's for meta-openembedded not oe-core | 13:29 |
| Net147 | JaMa: though I wonder if it's feasible to support them in oe-core in the future | 13:29 |
| bluelightning | eren: interesting, I was not aware of that apparent duplication | 13:29 |
| JaMa | eren: there are actually 3 "contains" variants | 13:29 |
| JaMa | oe.utils.contains | 13:29 |
| JaMa | base_contains (calls oe.utils.contains) | 13:29 |
| JaMa | bb.utils.contains (same code as oe.utils.contains) | 13:29 |
| JaMa | copy&pasted from https://bugzilla.yoctoproject.org/show_bug.cgi?id=3890 | 13:30 |
| yocti | Bug 3890: enhancement, Medium, 1.4, richard.purdie, VERIFIED FIXED, @contains does not create vardep automatically | 13:30 |
| bluelightning | eren: the functions are exactly the same, FWIW | 13:30 |
| eren | okkie | 13:30 |
| eren | strange :) | 13:30 |
| eren | JaMa: I handled PACKAGECONFIG with your code snippet | 13:30 |
| eren | trying the build | 13:30 |
| JaMa | eren: great | 13:30 |
| bluelightning | eren: it could be that base_contains was in OE first and then it was needed in bitbake, but for compatibility it couldn't be removed from OE | 13:30 |
| lpapp | bluelightning: you still did not get the idea? | 13:31 |
| bluelightning | lpapp: I've read the bug report | 13:31 |
| lpapp | bluelightning: "So for layers, you can provide a bblayers.conf.sample in your distro. That | 13:31 |
| lpapp | uses ##COREBASE## which is substituted during oe-init-build-env with the | 13:32 |
| lpapp | bluelightning: from rburton. | 13:32 |
| lpapp | correct paths. | 13:32 |
| lpapp | In bblayers.conf you can't use ${COREBASE} as that's provided by the meta | 13:32 |
| lpapp | layer, which hasn't been parsed yet." | 13:32 |
| lpapp | so I just followed what he wrote, pretty much. | 13:32 |
| * lpapp feels again like a hated person. :) | 13:32 | |
| eren | bluelightning: thanks. is it safe to continue with base_contains, or switch to bb.utils.contains? | 13:32 |
| eren | is there a plan to remove duplicates? | 13:32 |
| Net147 | JaMa: as for the license, i'm not sure what MIT-X really means | 13:32 |
| lpapp | when I have ideas, they are rejected, when I follow what others write, I am rejected. :) | 13:32 |
| bluelightning | eren: totally safe, I don't see that ever going away (maybe it will end up just calling the bb.utils version though internally) | 13:33 |
| lpapp | so back to the problem at hand, does anyone know what the proper way is to add the layer bblayers.conf sample? | 13:33 |
| JaMa | Net147: you can compare the text in LIC_FILES_CHKSUM file with shared MIT-X text, but to be honest sometimes it's not very clear to me how big difference is allowed to consider it the same license | 13:33 |
| eren | so, what's the "d" at the end of the function call? | 13:33 |
| eren | for example: "${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}" | 13:33 |
| bluelightning | lpapp: I don't think there is a well-defined method, because most people haven't tended to do that in the past AFAIK | 13:34 |
| JaMa | eren: "data" variable | 13:34 |
| bluelightning | eren: that's the datastore, it's how that function is able to read from the variable whose name you pass (in this case DISTRO_FEATURES) | 13:34 |
| lpapp | bluelightning: perhaps not because this feature is missng | 13:34 |
| lpapp | missing*, or was undocumented. | 13:35 |
| lpapp | that is a good reason why people found workarounds. | 13:35 |
| Net147 | JaMa: there is only MIT license in common-licenses | 13:35 |
| lpapp | and got used to that, but systematically, it is not good. | 13:35 |
| JaMa | Net147: meta/conf/licenses.conf:SPDXLICENSEMAP[MIT-X] = "MIT" | 13:35 |
| eren | bluelightning: ah, then while bitbake is parsing all the stuff, it fills datastore "d" | 13:36 |
| eren | thanks | 13:36 |
| bluelightning | lpapp: I think most people are comfortable creating/modifying their own bblayers.conf or they have scripts that do that already | 13:36 |
| lpapp | bluelightning: do you see how problematic that is architecturally? | 13:36 |
| bluelightning | lpapp: not that it wouldn't be worth improving this | 13:36 |
| bluelightning | lpapp: not really, no | 13:36 |
| lpapp | "most people do the custom stuff on their own" | 13:37 |
| lpapp | you do not see this a problem, really? | 13:37 |
| bluelightning | we're not talking about something huge that everyone has to write | 13:37 |
| lpapp | it does not matter really how much | 13:37 |
| bluelightning | it's a small config file that the user just adds one or two lines to | 13:37 |
| lpapp | if it is one line, it is 1000 lines for 1000 people. | 13:37 |
| lpapp | if everyone only writes once. | 13:37 |
| lpapp | compared to be written once. | 13:37 |
| bluelightning | I said already, it would be worth improving, but I think you make it out to be more of a problem than it is | 13:38 |
| lpapp | not to mention how error prone when forgotten ... I had to understand the issue for hours if not days. | 13:38 |
| lpapp | the problem is that, you ignore all the improvement options I say, and when you summarize those well ... that is where it is now. | 13:38 |
| lpapp | I really do not see why everyone would write all this manually when it can be automated pretty easily with a minor documentation. | 13:39 |
| lpapp | actually how big problem it is, is not presented better than showing the use case of CI failing without it and manual intervention as well. | 13:40 |
| lpapp | how can you do a nice CI without it? | 13:41 |
| lpapp | you have to adjust your git hook or so. | 13:41 |
| lpapp | and that is ... errr, painful when you do not even have access. | 13:41 |
| bluelightning | you can put whatever you need into automated build scripts | 13:41 |
| lpapp | sure, you would not need Yocto either. | 13:41 |
| lpapp | you could write your own script. | 13:42 |
| bluelightning | heh, because that's completely the same thing. | 13:42 |
| lpapp | it is | 13:42 |
| lpapp | Yocto is getting features like this to make it handier. | 13:42 |
| lpapp | this is one of those building stones. | 13:42 |
| eren | oh, I added pulseaudio dependency and now there are extra 1500 tasks to do :) | 13:43 |
| bluelightning | I'm not blocking anything here | 13:43 |
| Net147 | JaMa: looks somewhat like MIT license. and it's MIT license in other distributions. I sent to ML for review | 13:43 |
| bluelightning | just saying, if you say you can't do anything without this feature, I think that's overstating the nature of the issue | 13:43 |
| eren | gettext-native, util-linux, expat-native.. | 13:43 |
| JaMa | lpapp: I think best first step towards more friendly channel would be to admit that even you're sometimes incorrect and double check your statements before starting to argue with people who honestly have more experience with this project and were trying to give you good advise... | 13:44 |
| bluelightning | that's pretty much all I'm going to say about the matter as I have work to do this afternoon | 13:44 |
| lpapp | bluelightning: to give another example, can you show me any small patch going in that could not be solved by the client? | 13:44 |
| lpapp | JaMa: please focus on technical topics in a technical channel. | 13:45 |
| lpapp | JaMa: and no, technical disagreeing is not about friendliness, or not, and it is rude to put anyone with "unfriendly" markers because they do not breath the same flute as you do. | 13:46 |
| *** mebrown <mebrown!~michael_e@99-23-196-16.lightspeed.austtx.sbcglobal.net> has joined #yocto | 13:46 | |
| eren | lpapp: well, I guess this is a technical channel where technical issues can be discussed | 13:46 |
| *** sameo <sameo!samuel@nat/intel/x-hyfdlkgbghsvcudy> has quit IRC | 13:47 | |
| JaMa | lpapp: agreed, so next time please skip 10:47:37 < lpapp> JaMa: there is no any need to compare and teach that, as you are wrong. | 13:47 |
| lpapp | eren: yes, I agree. | 13:47 |
| lpapp | JaMa: you were wrong there. | 13:47 |
| lpapp | I described why... because you claimed that qtsensors and others have license files, meanwhile they do not. | 13:47 |
| lpapp | check their recipes. | 13:48 |
| JaMa | I wrote their recipes FFS | 13:48 |
| lpapp | then why would you claim any comparison? | 13:48 |
| lpapp | also, check your comment before that ... it was not slightly rude about "teaching". | 13:48 |
| eren | lpapp: are you thinking of contributing to this project, in any way? | 13:49 |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has quit IRC | 13:49 | |
| lpapp | it is not useful to tell a newcomer "I do not have time to teach you n00b" | 13:49 |
| JaMa | because you incorrectly claimed that you as qtserialport maintainer are using exatly the same license files as other qt 5.1. modules | 13:49 |
| lpapp | eren: I have done that. | 13:49 |
| lpapp | JaMa: that was correct at the point of merge. | 13:49 |
| JaMa | 10:39:58 < lpapp> I copied the same stuff from the rest of qtbase. | 13:49 |
| lpapp | that is correct. | 13:49 |
| lpapp | and that is still correct. | 13:49 |
| lpapp | perhaps this time you wanna know better than the author of the module? | 13:49 |
| eren | oh please, this is going really personal | 13:50 |
| lpapp | that is why I tried to mention several times already to get back to the technical stuff... | 13:50 |
| JaMa | that's why I said you should compare them.. | 13:50 |
| lpapp | JaMa: you said that for the recipes | 13:50 |
| lpapp | at least that is how I got. | 13:50 |
| lpapp | so perhaps you were unclear. | 13:51 |
| lpapp | but how is that my mistake? :) | 13:51 |
| *** mebrown <mebrown!~michael_e@99-23-196-16.lightspeed.austtx.sbcglobal.net> has quit IRC | 13:51 | |
| lpapp | and you could have told me that what you wanted to compare as it was not clear to me. | 13:52 |
| lpapp | I even told you I compared the recipes. | 13:52 |
| lpapp | why didn't you tell me not to compare those rather than "I do not have time to teach you, it is time waste, and ruined my breakfast" | 13:52 |
| JaMa | why should I want you to compare recipes? Misunderstanding on your end isn't my fault, I'm not paid to hand hold you when adding LIC_FILES_CHKSUM into the recipe | 13:53 |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 13:53 | |
| lpapp | and I am the aggressive, when you are taking such comments. :) | 13:53 |
| lpapp | well, to clarify the situation? | 13:53 |
| lpapp | to avoid the misunderstanding ? | 13:53 |
| lpapp | to avoid the frustration which you seem to get in? | 13:53 |
| *** mebrown <mebrown!~michael_e@99-23-196-16.lightspeed.austtx.sbcglobal.net> has joined #yocto | 13:55 | |
| lpapp | in general, it is a good advice to be as verbose as possible, especially when talking to new people. | 13:55 |
| lpapp | Also, when a license files are not changed every day, and when I did it was the same, so it was a natural guess that they should be the same, which means to compare recipes whether there is any difference. | 13:56 |
| lpapp | Also, license files are not* (at least not in the Qt Project anyhow) | 13:56 |
| eren | bluelightning: I've requested wiki username and it seems that there is a review process | 13:57 |
| lpapp | so for me with qt serialport maintainer hat, this was the natural context... | 13:57 |
| bluelightning | eren: we had a problem with spammers unfortunately :( | 13:58 |
| eren | bluelightning: ah I see, could you enable that if possible? :) | 13:58 |
| eren | I would like to add some keywords for pages to find easier | 13:58 |
| eren | I cannot, again, find your decent patch sending article | 13:58 |
| bluelightning | eren: hmm, I'm not sure if I have access to do that | 13:59 |
| bluelightning | eren: I think Jefro handles that stuff, I can certainly ping him when he comes online | 13:59 |
| bluelightning | eren: is it this one? http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded | 14:00 |
| eren | ah yes | 14:00 |
| eren | :/ | 14:00 |
| lpapp | sgw_: any problem with the new u-boot version ? | 14:00 |
| eren | https://wiki.yoctoproject.org/wiki/Contribution_Guidelines , this includes nice commit log reference | 14:01 |
| eren | linking the articles would be useful | 14:01 |
| lpapp | bluelightning: I do not have access to the CI server, so it is blocking as I wrote before. | 14:01 |
| bluelightning | lpapp: which CI server? | 14:01 |
| lpapp | ours. | 14:01 |
| bluelightning | lpapp: you can't tell the folks who do to do what is needed? or provide a script that they can run which you can edit? | 14:02 |
| lpapp | no, we are not time millionaires. :) | 14:02 |
| lpapp | I kinda have access and if I tried very hard I could do it, but then it is not worth the problem anymore what we are trying to solve. | 14:02 |
| lpapp | so what we are trying to solve is blocked either way. | 14:02 |
| bluelightning | to write a simple script to create the necessary configuration shouldn't require millions of anything... | 14:03 |
| lpapp | you might rethink that if you start thinking a bit out-of-the-box. | 14:03 |
| *** alex_kag <alex_kag!~alex_kag@178.124.31.217> has quit IRC | 14:04 | |
| lpapp | I know it is hard to drop the "got used to" hackarounds, but they dropping them are for good. | 14:04 |
| lpapp | but dropping* | 14:04 |
| *** nitink <nitink!nitink@nat/intel/x-iynyedvfqqerjzfs> has quit IRC | 14:05 | |
| lpapp | what you are suggesting is that many CI machines (hope many projects using CI nowadays) which are having limited access only by a handful of people if any, should be hacked because a minor addition is too much. | 14:07 |
| bluelightning | I didn't say it was too much | 14:07 |
| lpapp | + many developers all around for sure. | 14:07 |
| bluelightning | in fact I said this could be improved | 14:07 |
| lpapp | yeah, after a lot of arguing... | 14:08 |
| lpapp | probably because I mentioned rburton's name. :) | 14:08 |
| bluelightning | well if we argue about who is arguing we'll be here all day | 14:08 |
| JaMa | I agree that there are a lot more important tasks for bluelightning and other developers to work on | 14:08 |
| tf | bluelightning: /ignore is such a nice feature of irc ... | 14:09 |
| lpapp | bluelightning: no, I just feel that what I propose is dropped by default because I claim even if it makes sense like here. | 14:10 |
| lpapp | and I would like to get rid of this atmosphere for once and all. | 14:10 |
| *** AndersD` <AndersD`!~anders.da@pc-193-235-91-228.norrkoping.se> has quit IRC | 14:11 | |
| lpapp | JaMa: like mesa: inherit gettext ? | 14:12 |
| JaMa | yes exactly like mesa: inherit gettext | 14:13 |
| lpapp | yes, that is hit by so many people ... | 14:13 |
| lpapp | when gettext is installed by default nowadays pretty much by everyone. :) | 14:13 |
| lpapp | I guess different people have different priorities... | 14:14 |
| JaMa | yes "bitbake mesa" failing every time when someone builds it in clean tmpdir is bad | 14:14 |
| -YoctoAutoBuilder- build #262 of nightly-multilib is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-multilib/builds/262 | 14:15 | |
| lpapp | except that people will not do that usually. | 14:15 |
| lpapp | as they have images anyways, and it is very likely that something else pulls in. | 14:15 |
| JaMa | you would change your mind after seeing many random failures when building image or even world with few recipes missing or autodetecting dependencies | 14:16 |
| lpapp | and how could it block anyone anyways? | 14:16 |
| lpapp | you can always install it | 14:17 |
| lpapp | unlike a CI server access, etc. | 14:17 |
| *** mihai <mihai!~mihai@188.27.93.142> has joined #yocto | 14:17 | |
| JaMa | and random failures are worse then writing one line in layer.conf | 14:17 |
| lpapp | show me random failures caused by this | 14:17 |
| lpapp | at least 11 times in a team like in a 10-sized developer team + CI. | 14:17 |
| JaMa | read "State of bitbake world" e-mails I'm sending for last couple of months | 14:17 |
| lpapp | with limited access to make it harder. | 14:18 |
| -YoctoAutoBuilder- build #274 of nightly-mips-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-mips-lsb/builds/274 | 14:18 | |
| lpapp | I would be very suprirsed if anyone here used "bitbake mesa" regularly in a fresh clean environment. | 14:18 |
| lpapp | Also, why would it be random failure? | 14:19 |
| *** sameo <sameo!samuel@nat/intel/x-dxxxfwyilekalalw> has joined #yocto | 14:19 | |
| lpapp | you get an error message at the gettext include. | 14:19 |
| JaMa | I'm surprised that people are using CI servers where they don't have any access.. | 14:19 |
| JaMa | lpapp: because sometimes gettext is built before mesa pulled by something else, sometimes it isn't | 14:19 |
| lpapp | I do not think that is the case anywhere in the world. | 14:20 |
| lpapp | so I wonder how you came to the strange conclusion. :) | 14:20 |
| lpapp | ? Actually the state graph for the same stuff is pretty consistent. | 14:20 |
| JaMa | sorry but I don't have time for this discussion | 14:20 |
| lpapp | haha | 14:20 |
| lpapp | alright. | 14:20 |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC | 14:21 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 14:22 | |
| JaMa | this channels should be about technical issues not your assumtions and surprises | 14:22 |
| *** djszapi <djszapi!d42c13e4@gateway/web/freenode/ip.212.44.19.228> has joined #yocto | 14:22 | |
| Crofton|work | JaMa, he left | 14:22 |
| djszapi | Crofton|work: 1) I am here 2) Log is public, so just go ahead and say if you have anything to say. If you wanna address people, do it in front of them. | 14:23 |
| *** djszapi is now known as lpapp_ | 14:24 | |
| Crofton|work | lpapp_, I was just pointing out that he was speaking to no one, in case he missed the leave message | 14:24 |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has quit IRC | 14:25 | |
| *** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has quit IRC | 14:25 | |
| lpapp_ | ok, thanks. :) | 14:25 |
| *** sameo <sameo!samuel@nat/intel/x-dxxxfwyilekalalw> has quit IRC | 14:28 | |
| lpapp_ | I think the problem is that with TEMPLATECONF, it is too late in the process to put into local.conf because it is probably necessary for the oe init script. | 14:28 |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC | 14:28 | |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto | 14:28 | |
| lpapp_ | it would be nice to have something in the local.conf instead, for instance. | 14:29 |
| lpapp_ | same limitation with OECORELAYERCONF | 14:30 |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 14:30 | |
| bluelightning | local.conf doesn't exist before the oe-init-build-env script is run... | 14:34 |
| lpapp_ | that is fine | 14:34 |
| lpapp_ | it can be added later, too. | 14:34 |
| lpapp_ | oh, now I got it. | 14:34 |
| lpapp_ | that would require a separate process then. | 14:34 |
| lpapp_ | then the idea is to generate it with bitbake. | 14:35 |
| lpapp_ | i.e. if no bblayers.conf present, the oe init stuff could be rerun. | 14:35 |
| lpapp_ | behind the scene. | 14:35 |
| lpapp_ | or at least the part of it responsible for that generation, and if that does not work, issue the usual error. | 14:36 |
| -YoctoAutoBuilder- build #265 of nightly-x86 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86/builds/265 | 14:36 | |
| *** B4gder <B4gder!~daniel@rockbox/developer/bagder> has quit IRC | 14:43 | |
| -YoctoAutoBuilder- build #260 of nightly-world is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-world/builds/260 | 14:46 | |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has quit IRC | 14:49 | |
| lpapp_ | otavio: can you take yet another look at my u-boot change? | 14:50 |
| lpapp_ | uvan is not here now to do so. | 14:50 |
| *** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has joined #yocto | 14:51 | |
| otavio | lpapp_: yes; I can give it a test | 14:55 |
| otavio | lpapp_: which targets did you try? | 14:56 |
| lpapp_ | otavio: my own custom. | 14:56 |
| lpapp_ | it is an arm. | 14:56 |
| lpapp_ | regular omap stuff from ti. | 14:56 |
| otavio | lpapp_: and did you check if beable, for example, keep working? | 14:56 |
| lpapp_ | for my board, yes. | 14:56 |
| otavio | beagle heh | 14:57 |
| lpapp_ | of course. :) | 14:57 |
| lpapp_ | no, I do not have a beagle here. | 14:57 |
| otavio | lpapp_: the fwutils issue is fixed? | 14:57 |
| lpapp_ | otavio: yes, I deleted it. :D | 14:57 |
| lpapp_ | http://patches.openembedded.org/patch/56317/ | 14:57 |
| lpapp_ | otavio: at least I do not need it, and it is a new version addition without removing the old anyway. | 14:58 |
| lpapp_ | I do not even understand the purpose of that package to be honest. | 14:58 |
| lpapp_ | usually you need a u-boot image, and then the mkutils for creating uImage with the Linux kernel make command... | 14:58 |
| lpapp_ | and for me, both are covered. | 14:58 |
| otavio | lpapp_: fwutils is for use in target | 14:58 |
| lpapp_ | yeah, I thought so. What exactly for though? | 14:59 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 15:00 | |
| otavio | lpapp_: no | 15:01 |
| otavio | lpapp_: it is for host use | 15:01 |
| lpapp_ | oh, I read host actually. :p | 15:01 |
| otavio | lpapp_: so you can check env and set env for it | 15:01 |
| lpapp_ | I am blind. | 15:01 |
| lpapp_ | anyway, I have not needed it to get an u-boot + linux kernel. | 15:02 |
| lpapp_ | a* | 15:02 |
| otavio | lpapp_: yse but for updating you need | 15:02 |
| lpapp_ | otavio: updating what | 15:02 |
| lpapp_ | you mean like over tftp? | 15:02 |
| otavio | lpapp_: I built it here and it built fine | 15:02 |
| lpapp_ | with my previous change? | 15:02 |
| otavio | lpapp_: no; for updating u-boot version | 15:02 |
| lpapp_ | oh, that is not critical for me. | 15:03 |
| lpapp_ | I use openocd for that. | 15:03 |
| lpapp_ | also, you can update it from the target. | 15:03 |
| lpapp_ | or the host needs this special stuff for that? | 15:03 |
| lpapp_ | anyway, it does not build for me and uvan. | 15:03 |
| otavio | lpapp_: the point is not for you. The point is for OE-Core. It is wrong to not keep them in sync | 15:03 |
| lpapp_ | ? | 15:03 |
| lpapp_ | it is kept in sync. | 15:03 |
| lpapp_ | the old versions are preserved. | 15:03 |
| otavio | lpapp_: u-boot-fw-utils, u-boot-mkimage and u-boot ought to be same versions and provide same versions | 15:04 |
| lpapp_ | as I said, people usually do not need it. | 15:04 |
| lpapp_ | in other words: it should not block people using u-boot. | 15:04 |
| otavio | lpapp_: as I said this does not mean you can ignore it. | 15:04 |
| lpapp_ | as for incremental improvement, well you are welcome to get the compilation error fixed. | 15:05 |
| lpapp_ | we could not do that with uvan. | 15:05 |
| lpapp_ | sure, I can., | 15:05 |
| lpapp_ | actually, that stuff is not even present on my distribution, and many people still use u-boot just fine. | 15:05 |
| otavio | lpapp_: Sure; keep the recipe update in your layer than ;-) | 15:05 |
| lpapp_ | that would be silly. | 15:05 |
| lpapp_ | because that would mean many people will do the same recurring job. | 15:06 |
| lpapp_ | which is the whole point of open embedded in the first place :-) | 15:06 |
| otavio | lpapp_: Well; I won't ack it until fw-utils is done. | 15:06 |
| lpapp_ | to avoid that nightmare. | 15:06 |
| otavio | lpapp_: you can convince other people to ack it. Not me. | 15:06 |
| lpapp_ | sure, I did not ask for your ack. | 15:06 |
| lpapp_ | uvan was already more than happy without it. | 15:06 |
| lpapp_ | I only asked you to test it if you have time. | 15:07 |
| otavio | lpapp_: I won't try it as I know it works. I use it in meta-fsl-arm | 15:07 |
| lpapp_ | and for that matter constructivity ... you know... appreciation, and suggestion for improvements. | 15:07 |
| otavio | lpapp_: so when you get fw-utils done we an fix. | 15:07 |
| lpapp_ | how do you know my recipe works if you do not try? | 15:07 |
| otavio | lpapp_: The patch is good. I checked | 15:07 |
| lpapp_ | fw-utils will not get done. | 15:07 |
| lpapp_ | lol | 15:07 |
| lpapp_ | testing != review | 15:08 |
| *** fitzsim <fitzsim!~user@nat/cisco/x-vqtxcuxceuveugjj> has joined #yocto | 15:08 | |
| otavio | lpapp_: So I fear it won't be accepted. | 15:08 |
| lpapp_ | fw-utils is a pain in the arse according to my and uvan's experience. | 15:08 |
| lpapp_ | sure, it will. | 15:08 |
| lpapp_ | you are the first one unhappy with it... ;-) | 15:08 |
| otavio | lpapp_: :-) | 15:08 |
| lpapp_ | (for no apparent reason so far) | 15:08 |
| lpapp_ | not to mention, fw-utils is already not in sync in other accepted variants anyway | 15:09 |
| otavio | Well, I have said my opinion. the guys to convince are other. | 15:09 |
| lpapp_ | probably for the exact same reason. | 15:09 |
| lpapp_ | mkutils and uboot are fine to boot any linux stuff | 15:09 |
| lpapp_ | and even update over ftp | 15:09 |
| lpapp_ | including u-boot. | 15:10 |
| lpapp_ | to be honest I still do not get why anyone would need fw-utils. :D | 15:10 |
| lpapp_ | I can update u-boot without it. | 15:11 |
| lpapp_ | so what does it help with update again? | 15:11 |
| otavio | So an image, change u-boot env, for example | 15:11 |
| lpapp_ | you can change that fine without it, too. | 15:12 |
| otavio | Really? how? | 15:12 |
| lpapp_ | two ways: | 15:12 |
| lpapp_ | 1) openocd | 15:13 |
| lpapp_ | 2) tftp | 15:13 |
| otavio | Did you read the word *image* ? | 15:13 |
| otavio | So it is *build image time* change. | 15:13 |
| otavio | Not run time | 15:13 |
| lpapp_ | that you can always do at build time. | 15:14 |
| lpapp_ | of course. | 15:14 |
| otavio | How? I mean /image/ not patching u-boot | 15:14 |
| -YoctoAutoBuilder- build #262 of nightly-ppc is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-ppc/builds/262 | 15:14 | |
| lpapp_ | you can always patch u-boot, and it is quite simple with .bbappend | 15:15 |
| lpapp_ | as for the tool, sec. | 15:15 |
| lpapp_ | otavio: the tool is called bitbake. ;-) | 15:26 |
| *** alex_kag <alex_kag!~androirc@134.17.72.86> has joined #yocto | 15:29 | |
| lpapp_ | or simply udev itself at runtime. | 15:29 |
| lpapp_ | u-boot* | 15:29 |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 15:34 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 15:40 | |
| *** rikroled <rikroled!~tbn@84.55.160.118> has quit IRC | 15:43 | |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto | 15:50 | |
| *** zenlinux_ <zenlinux_!~sgarman@173-8-218-204-Oregon.hfc.comcastbusiness.net> has joined #yocto | 15:52 | |
| -YoctoAutoBuilder- build #261 of nightly-arm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-arm/builds/261 | 15:53 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 15:58 | |
| *** lpapp_ <lpapp_!d42c13e4@gateway/web/freenode/ip.212.44.19.228> has quit IRC | 15:58 | |
| lpapp | I wonder what might be the reason for a software to build as ELF32, and not ARM | 15:58 |
| lpapp | it is built like this in the Makefile apparently, lib: $(lib_OBJ) $(CC) $(CPPFLAGS) $(CFLAGS) -shared -Wl,-soname=$(SONAME) -o $(LIB) $(lib_OBJ) $(foo) $(LDFLAGS) | 15:59 |
| fray | ARM should be ELF32.. but ARM -abi- adds additional expectations about ELF32, which often times firmware shouldn't be using | 15:59 |
| fray | no idea if you are building firmware though | 15:59 |
| lpapp | ok, it is x86, not arm | 16:00 |
| lpapp | no | 16:00 |
| fray | then is it simply using the wrong compiler? | 16:00 |
| lpapp | well, it has CC=gcc | 16:00 |
| -YoctoAutoBuilder- build #256 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86-64-lsb/builds/256 | 16:00 | |
| lpapp | but that should not be a problem as far as it is not recursive, right? | 16:00 |
| fray | ya, wrong compiler, unless you are building a helper app | 16:00 |
| lpapp | ? | 16:01 |
| lpapp | I have been told here that should not matter | 16:01 |
| lpapp | as oe overrides that if not recursive. | 16:01 |
| fray | OE passes appropriate values for the toolchain.. -however- if the app doesn't listen to the value, then it's going to use the wrong compiler.. | 16:01 |
| *** _alex_kag_ <_alex_kag_!~alex_kag@93.84.75.157> has joined #yocto | 16:01 | |
| lpapp | and it does not work even on my x86_64 fwiw. | 16:02 |
| lpapp | and CC=gcc should. | 16:02 |
| fray | only if the host/target happen to have compatible ABIs, libraries and libc versions would it perhaps work | 16:02 |
| RP | fray: we have -e in our make flags so our CC value overrides CC=gcc in the makefile | 16:02 |
| JaMa | anyone seen "include /absolute/path/foo.inc" behaving like "require", parsing failing when the file doesn't exist? | 16:03 |
| *** blitz00 <blitz00!stefans@nat/intel/x-bgpjbngcrmcnkoav> has joined #yocto | 16:03 | |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto | 16:03 | |
| fray | RP, I've seen instances where makefiels ahve 'CC := gcc' where it hasn't overridden it.. | 16:03 |
| fray | it's fairly rare these days, but it happens | 16:03 |
| RP | JaMa: no | 16:03 |
| RP | fray: probably not a top level makefile? | 16:03 |
| fray | don't remember if it was a top level file or not | 16:03 |
| *** alex_kag <alex_kag!~androirc@134.17.72.86> has quit IRC | 16:04 | |
| *** _alex_kag_ is now known as alex_kag | 16:04 | |
| ndec | RP: about make -e, .. do you know why we do MAKEFLAGS= too? | 16:04 |
| ndec | as a consequence the -e is not passed to recurive makefiles | 16:05 |
| ndec | any specific reason? | 16:05 |
| RP | ndec: no, you'd have to ask someone from the start of the project like kergoth or pb_ over on #OE | 16:05 |
| ndec | ok. thx | 16:07 |
| lpapp | ndec: please let me know if you figure out anything important about that. if I may ask. | 16:12 |
| ndec | about? | 16:12 |
| lpapp | recursive stuff | 16:12 |
| lpapp | MAKEFLAGS= | 16:12 |
| ndec | ah. sure. | 16:13 |
| kergoth | ndec: we do that intentionally, because often the toplevel makefile wants to alter variables it gets. if we passed it into submakes, the env would override the toplevel makefile additions, iirc. e.g. CFLAGS += "-Wfoo" | 16:14 |
| kergoth | ndec: but I regret including -e at all, better to be explicit with variable passing via EXTRA_OEMAKE= | 16:14 |
| lpapp | fray: the right compiler is used for compilation. | 16:15 |
| ndec | kergoth: ok. i admit that my problem with that choice, is that I am integrating bad components, with wrongly writtent makefiles... | 16:18 |
| ndec | written | 16:18 |
| lpapp | people should not write makefiles nowadays. | 16:18 |
| kergoth | highly recommend redefining EXTRA_OEMAKE to pass things in explicitly, and patch the makefiles to suck less | 16:18 |
| ndec | in our case the top level just 'recurse' and the sub makefile expects to set CFLAGS ;-) | 16:18 |
| *** Anusko <Anusko!~anusko@62.159.77.165> has quit IRC | 16:19 | |
| ndec | lpapp: yeah, i know.. ;-) | 16:19 |
| ndec | i don't write makefile, but have to read and use them! | 16:19 |
| *** Anusko <Anusko!~anusko@62.159.77.165> has joined #yocto | 16:19 | |
| lpapp | yes, it is a non-rewarding job, I guess. | 16:19 |
| lpapp | not rewarding enough IMHO. :) | 16:20 |
| RP | ndec: you can override the default | 16:20 |
| ndec | i know. | 16:20 |
| ndec | but then i don't get the default CFLAGS from env ;-) | 16:21 |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has quit IRC | 16:27 | |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has joined #yocto | 16:28 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 16:28 | |
| abelloni | otavio: I hope this time it will please you ;) | 16:30 |
| kergoth | ndec: EXTRA_OEMAKE = "'CC=${CC}' 'CFLAGS=${CFLAGS}'...." will do, or override it to remove the MAKEFLAGS= | 16:30 |
| kergoth | ndec: either should do | 16:31 |
| kergoth | i'm a fan of the former, despite the verbosity, because it's explicit, and indicates a minimal knowledge of the buildsystem in question, sicne you have to know what variables it actually obeys for it to make any sense | 16:31 |
| kergoth | but either way will work :) | 16:31 |
| ndec | hmm. it's funny because I did something like this pass extra variables, and patched the makefile... but just didn't realize i could simply pass CFLAGS directly.. i will check back, maybe i can have a nicer solution .thx | 16:32 |
| JaMa | RP: I've found the difference for relative/absolute path, it's in bitbake/lib/bb/parse/__init__.py:def resolve_file(fn, d) | 16:32 |
| JaMa | RP: when fn isn't abs, it uses which and returns IOError when it's not found, which is catched by calling handle function correctly | 16:33 |
| JaMa | RP: when it is abs, it just returns fn and OSError returned a bit later from bb.parse.mark_dependency(d, abs_fn) in BBHandler.py | 16:33 |
| RP | JaMa: so we need to trap that in the include case | 16:33 |
| lpapp | hmm, so it is weird ... | 16:34 |
| lpapp | I have a /path/to/the/temp/package/src/core/foo/bar.c include baz.h in the same directory, but the build does not find that | 16:34 |
| JaMa | RP: I was thinking about returning IOError from resolve_file | 16:34 |
| lpapp | why is it like that? The cwd is something else during the build or what? | 16:34 |
| lpapp | needless to say, the header included from the same folder should be found naturally. | 16:35 |
| lpapp | ah, it is included as <foo/baz.h> | 16:36 |
| lpapp | that is bizarro. | 16:36 |
| ndec | JaMa: 'by mistake' i started my build outside of my chroot (on debian/sid), and hence noticed that qtbase-native fails to build on sid. fyi. | 16:36 |
| lpapp | so is that possible oe is trying to override this? CPPFLAGS = -I./ -m32 | 16:37 |
| JaMa | ndec: can you share the log? | 16:37 |
| ndec | yep. | 16:37 |
| lpapp | (which is in the Makefile) | 16:37 |
| lpapp | that would explain the dropping of the include path in CWD. | 16:37 |
| JaMa | ndec: someone reported native qmake trying to load gui module, but IIRC it was building for him | 16:37 |
| otavio | abelloni: sorry by being picky ! :-) | 16:37 |
| *** belen <belen!Adium@nat/intel/x-bgyncwiuoedmdmhb> has quit IRC | 16:37 | |
| lpapp | or if it is executed in the wrong directory. | 16:38 |
| lpapp | abelloni: people are picky in this project... I think we just need to get used to it ... hard stuff to do so. | 16:38 |
| lpapp | when you come from a pragmatic culture. | 16:38 |
| RP | JaMa: I don't quite follow :/ | 16:39 |
| bluelightning | lpapp: if you think us picky, maybe you haven't tried sending anything to the kernel ;) | 16:39 |
| RP | JaMa: I see the code you mean but I don't understand the fix. Where is the exception caught in the include case? | 16:39 |
| ndec | JaMa: http://pastebin.com/yJdF9vrz | 16:39 |
| lpapp | bluelightning: I was writing kernel drivers for 1-2 years. | 16:39 |
| lpapp | professionally in full time. | 16:39 |
| lpapp | maybe 2-3. | 16:39 |
| lpapp | (including security framework where people are notoriously picky) | 16:40 |
| lpapp | hmm, the "./" include path seems to be dropped from the compilation line ... why is that? I guess OE is dropping it ... how can I avoid OE droppipng it? | 16:41 |
| lpapp | dropping* | 16:41 |
| otavio | lpapp: the fw-utils build failure makes sense indeed | 16:42 |
| otavio | lpapp: I am fixing it and will send a full u-boot upgrade when done | 16:42 |
| ndec | lpapp: check the run.do_compile.<pid> script to see all the variables that OE sets before calling make | 16:43 |
| abelloni | otavio: it is actually a good thing. The series are quite better now. | 16:45 |
| lpapp | otavio: heh, so no credit for me at all for the many days work | 16:45 |
| lpapp | I think it is over a month now. :) | 16:45 |
| lpapp | that would be lovely. | 16:45 |
| abelloni | otavio: it would be good if it could make it for 1.5 though | 16:45 |
| otavio | lpapp: I will add your credit in the commit log | 16:45 |
| otavio | abelloni: fsl-arm stuff? | 16:45 |
| lpapp | otavio: it is not the same but anyway | 16:45 |
| abelloni | yeah, fsl-arm | 16:46 |
| lpapp | the real open source way would be to extend my work. | 16:46 |
| lpapp | not redoing stuff and put someone into the "brackets". | 16:46 |
| *** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has quit IRC | 16:47 | |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto | 16:48 | |
| JaMa | RP: I've sent RFC with patch to bitbake-devel | 16:48 |
| lpapp | otavio: not to mention we will not probably wait for you as there are various ways to solve your issue anyway, and this has to be in very soon.l | 16:48 |
| lpapp | soon.* | 16:48 |
| lpapp | not to miss the freeze. | 16:48 |
| JaMa | RP: in both cases it should be caught in ConfHandler.py:include() | 16:48 |
| otavio | abelloni: it should be fine I guess | 16:48 |
| lpapp | ndec: ok, I will check that. | 16:48 |
| lpapp | ndec: NOTE: make -j 8 -e MAKEFLAGS= -C foo, that is all. | 16:50 |
| lpapp | ndec: does that mean CPPFLAGS is dropped? | 16:50 |
| JaMa | RP: but it was catching only IOError and not OSError, with this resolve_file change it's always IOError and we don't need to call mark_dependenci in BBHandler.py for it to fail | 16:50 |
| lpapp | sgw_: have you tested the u-boot change btw? Please do not miss the freeze ... | 16:51 |
| RP | JaMa: shouldn't we change it to catch both OSError and IOError? | 16:51 |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has left #yocto | 16:52 | |
| JaMa | RP: it looks cleaner to me, to let resolve_file doing the same when resolving non-existent file | 16:53 |
| *** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has joined #yocto | 16:53 | |
| JaMa | RP: and resolve_file is used only from 2 places ConfHandler and BBHandler, so it should be quite safe | 16:54 |
| lpapp | is there a way to tell OE/Bitbake/Yocto/whatever_the_term_is to respect the CPPFLAGS? | 16:54 |
| lpapp | it should really never ever drop it. | 16:54 |
| lpapp | it is set for a reason. | 16:54 |
| RP | JaMa: I suspect we should add OSError to include() as well, for boiler plate | 16:57 |
| RP | (er, to make the code robust) | 16:57 |
| RP | JaMa: please send a patch though | 16:57 |
| JaMa | OK, I'll send v2 which will also add OSError | 16:57 |
| ndec | lpapp: if CPPFLAGS is not set in the env (e.g. in run.do_compile) then what ever is in the makefile will be used. | 16:58 |
| lpapp | ndec: then why don't I see that include path in the compilation line even though I see without Yocto? | 16:59 |
| ndec | i don't know ;-) | 16:59 |
| lpapp | exactly, so something is fishy around Yocto | 17:00 |
| *** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has quit IRC | 17:00 | |
| lpapp | and I would like to understand what. | 17:00 |
| ndec | does your makefile use CPPFLAGS in the command line? | 17:00 |
| lpapp | ? | 17:01 |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto | 17:02 | |
| ndec | well, you should print CPPFLAGS to see its value, it might give some hints. | 17:03 |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has quit IRC | 17:03 | |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto | 17:03 | |
| lpapp | ndec: print where? | 17:05 |
| ndec | from the makefil | 17:05 |
| ndec | makefile | 17:05 |
| lpapp | not sure I follow. | 17:06 |
| ndec | you are debugging your build, right? you think CPPFLAGS does not have the right value. so i think you should print it, to see what's the value is. that might give a clue about what is going on. | 17:08 |
| lpapp | I still do not follow you | 17:08 |
| lpapp | 1) Print where 2) Why print inside the makefile 3) how. | 17:08 |
| ndec | echo ${CPPFLAGS} | 17:09 |
| lpapp | it will print out what is internally there I believe. | 17:09 |
| lpapp | that will not still tell us why it is not passed to the compiler though. | 17:09 |
| ndec | if you do that from the Makefile, it will print its value. | 17:09 |
| lpapp | I have no idea where to put or/and how it would be different to what CPPFLAGS is set in there. | 17:10 |
| lpapp | also, makefile will not help anyway as redownload will drop it. | 17:11 |
| lpapp | yeah, nothing is printed as I expected. | 17:12 |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 17:13 | |
| lpapp | I put a line like that after all: foo, but nothing is printed. | 17:14 |
| lpapp | anything else I can try? | 17:14 |
| * lpapp remembers who painful it is to write software without cmake | 17:15 | |
| lpapp | how* | 17:15 |
| ndec | what do you mean nothing is printed? if you added an 'echo' it is printed somewhere | 17:15 |
| lpapp | nope, it is not. | 17:16 |
| erbo | you can always do echo "HERECOMESCPPFLAGS" before the echo ${CPPFLAGS} to make it easy to find it in the log | 17:16 |
| lpapp | I already did that... so, nothing is printed. | 17:16 |
| lpapp | any further clue? | 17:16 |
| *** zecke <zecke!~ich@p5099b351.dip0.t-ipconnect.de> has quit IRC | 17:16 | |
| ndec | you checked the log? | 17:17 |
| lpapp | yes | 17:17 |
| ndec | log.do_compile? | 17:17 |
| lpapp | yes | 17:17 |
| ndec | did the task run? | 17:17 |
| ndec | if you had compiled already, it wouldn't run again. | 17:18 |
| ndec | since it doesn't know you changed the makefile | 17:18 |
| ndec | bitbake -fc compile <recipe> | 17:18 |
| ndec | would force it | 17:18 |
| lpapp | did not help... it is not printed. | 17:19 |
| erbo | but the "herecomes" part is printed? | 17:19 |
| ndec | and you put in the 'echo' in a target which is executed by the makefile? | 17:20 |
| lpapp | ndec: I have put it as I said. | 17:20 |
| lpapp | ndec: all: lib echo "TEST THIS STUFF: ${CPPFLAGS}" | 17:21 |
| ndec | you said 'i put a line after all' ;-) now i get it. | 17:21 |
| lpapp | right | 17:21 |
| lpapp | anyway, it is not printed. | 17:21 |
| * lpapp cannot hate Makefiles more and the people using it when cmake has been existing for a decade now | 17:22 | |
| *** Anusko <Anusko!~anusko@62.159.77.165> has quit IRC | 17:22 | |
| -YoctoAutoBuilder- build #265 of nightly-x86-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86-lsb/builds/265 | 17:24 | |
| ndec | that's weird. i just did the same thing here. and my echo is printed. | 17:24 |
| lpapp | right, so any idea? | 17:24 |
| ndec | in log.do_compile | 17:24 |
| ndec | no. | 17:24 |
| lpapp | so this is an unsolvable issue? :D | 17:25 |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 17:25 | |
| ndec | nothing is unsolvable. | 17:26 |
| lpapp | well, ideas are welcome. | 17:26 |
| lpapp | how to tell oe not to drop cppflags | 17:26 |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 17:27 | |
| *** pidge <pidge!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has joined #yocto | 17:29 | |
| lpapp | the yocto reference manual has no entry about CPPFLAGS. | 17:30 |
| lpapp | the project development manual either. | 17:30 |
| lpapp | Looks like another important missing documentation. | 17:30 |
| *** Bhawna <Bhawna!~arunkr24@123.201.34.10> has joined #yocto | 17:30 | |
| ndec | lpapp: i confirm that CPPFLAGS is cleared in my case too. if i set it in my makefile, and print it, it's empty. if i do the same with any other variable name it's printed. | 17:32 |
| lpapp | ndec: :( | 17:33 |
| *** ka6sox is now known as ka6sox-away | 17:33 | |
| lpapp | so, I guess it is a blocker again | 17:33 |
| lpapp | not much I can do without documentation. | 17:33 |
| lpapp | I will just make a report to clarify this behavior and possible solutions in the documentation. | 17:33 |
| Bhawna | I am a newbie from India... and beggining with the yocto project | 17:35 |
| ndec | lpapp: ok,it's set in bitbake.conf, so in the 'env', so with -e it will be ignored in the makefile. | 17:35 |
| ndec | there must be a reason. | 17:35 |
| ndec | but i don't know. | 17:36 |
| Bhawna | i have created my Git repo of Poky, and have till now followed the instructions in the quickstart guide | 17:36 |
| Bhawna | the problem comes when i invoke the command | 17:36 |
| ndec | lpapp: temp workaround set CPPFLAGS in the .bb file | 17:36 |
| bluelightning | probably because most upstream makefiles set inappropriate values for cross-compilation for things such as CPPFLAGS and CFLAGS | 17:36 |
| lpapp | Bhawna: which command? | 17:36 |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 17:36 | |
| lpapp | bluelightning: why punish people who do set correct values? | 17:37 |
| lpapp | ndec: I am creating a bugreport anyway | 17:37 |
| lpapp | ndec: this should be documented. | 17:37 |
| bluelightning | lpapp: I'm not intimately familiar with the whys and wherefores, just pointing out a possible explanation | 17:37 |
| Bhawna | bitbake -k core-image-sato | 17:37 |
| *** davest <davest!Adium@nat/intel/x-khipcgupybapjkoi> has joined #yocto | 17:38 | |
| lpapp | Bhawna: what problem? | 17:38 |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has quit IRC | 17:38 | |
| Bhawna | i would post the error message here | 17:38 |
| ndec | use pastebin. | 17:38 |
| Bhawna | ERROR: Error parsing configuration files | 17:38 |
| Bhawna | Traceback (most recent call last): | 17:39 |
| Bhawna | File "/home/temp/Yocto/poky/bitbake/lib/bb/cookerdata.py", line 221, in CookerDataBuilder.parseBaseConfiguration(): | 17:39 |
| Bhawna | try: | 17:39 |
| Bhawna | > self.parseConfigurationFiles(self.prefiles, self.postfiles) | 17:39 |
| lpapp | Bhawna: paste.kde.org | 17:39 |
| mihai | ping | 17:40 |
| *** simar_ <simar_!~simar@128.224.252.2> has joined #yocto | 17:41 | |
| lpapp | ndec: EXTRA_OEMAKE will not work? | 17:41 |
| lpapp | CPPFLAGS=${CPPFLAGS} ? | 17:41 |
| lpapp | mihai: pong | 17:41 |
| ndec | yes, it should. | 17:41 |
| Bhawna | lpapp: http://goo.gl/lg1OuJ | 17:41 |
| mihai | lpapp: thanks :) | 17:41 |
| Bhawna | lpapp: thanks, i didnt know such a thing existed | 17:42 |
| *** simar_ is now known as su | 17:42 | |
| lpapp | Bhawna: no worries.. do you have proper permissions? | 17:42 |
| *** su is now known as insmod | 17:42 | |
| *** insmod <insmod!~simar@128.224.252.2> has left #yocto | 17:43 | |
| Bhawna | yeah... i ran the Source command as root, but after that i did a Chmod on the Parent Directory | 17:43 |
| lpapp | bluelightning: ndec https://bugzilla.yoctoproject.org/show_bug.cgi?id=5046 | 17:43 |
| yocti | Bug 5046: normal, Undecided, ---, scott.m.rifenbark, NEW , Document that CPPFLAGS override behavior and possible workaround | 17:43 |
| * lpapp is adding Scott. | 17:43 | |
| mranostay | Bhawna: as root? | 17:43 |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 17:44 | |
| mranostay | building source as root is a really bad idea | 17:44 |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 17:44 | |
| bluelightning | Bhawna: don't run the setup script or the build as root, use your normal user account | 17:44 |
| Stygia | Hey. Question, if I have a recipe in meta-openembeddd, and then a .bbappend file in meta-COMPANY, and I want to append to SRC_URI to include one file.... do I need to specify the entire relative path to my own layer? Because when building the recipe complains that the cannot be found, in spite of it being in the proper subfolder for the _company_ layer, while the recipe itself is in meta-openembedded. | 17:44 |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has quit IRC | 17:44 | |
| bluelightning | er | 17:45 |
| JaMa | RP: it's not caused by your latest gcc-cross changes (because I've seen the same error yesterday) but have you seen this error before: | 17:45 |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has joined #yocto | 17:45 | |
| bluelightning | I was about to answer... | 17:45 |
| JaMa | | /OE/oe-core/tmp-eglibc/work-shared/gcc-4.8.1-r0/gcc-4.8.1/gcc/calls.c:1230:9: error: 'STACK_CHECK_MAX_VAR_SIZE' was not declared in this scope | 17:45 |
| Bhawna | okay, Bluelighting, i understood the error, will sure improve upon that | 17:45 |
| JaMa | khem: ^ | 17:45 |
| Stygia | Sorry, if someone replied to me just now I missed it, closed Xchat by accident. | 17:45 |
| lpapp | ndec: I tried this: EXTRA_OEMAKE = "'CFLAGS=${CFLAGS}' 'CPPFLAGS=${CPPFLAGS}'" | 17:45 |
| bluelightning | Stygia: you need to set FILESEXTRAPATHS - see other bbappends | 17:45 |
| lpapp | ndec: with bitbake foo -c cleanall | 17:46 |
| lpapp | and then bitbake foo | 17:46 |
| lpapp | ndec: but it did not help. :( | 17:46 |
| Stygia | bluelightning, FILESEXTRAPATH_prepend or just FILESEXTRAPATH will do? | 17:46 |
| lpapp | ndec: and the include paths are still not passed. | 17:47 |
| lpapp | so apprently that assumption is wrong. | 17:47 |
| ndec | lpapp: sure... sorry... | 17:47 |
| ndec | you can't do that. not sure why i told you it was okay... | 17:47 |
| lpapp | any, as in /any/ to get the Makefile respected? | 17:47 |
| bluelightning | Stygia: FILESEXTRAPATHS_prepend is the best way, then other bbappends for the same recipe that do the same can work if any exist | 17:47 |
| lpapp | /any/ way* | 17:47 |
| Stygia | bluelightning, Thanks dude. :) | 17:47 |
| lpapp | bluelightning: why does the buildsystem try to be a smart ass? :o | 17:48 |
| ndec | because CPPFLAGS is already cleared when calling the makefile. | 17:48 |
| lpapp | or whatever the English term is for being smart. | 17:48 |
| lpapp | too smart. | 17:48 |
| bluelightning | lpapp: I gave you all I can guess already | 17:48 |
| * lpapp is not a native speaker | 17:48 | |
| lpapp | bluelightning: you did not give any workaround | 17:49 |
| lpapp | you just tried to guess why it is disrespectful towards the software's buildsystem. | 17:49 |
| lpapp | at least I do not find any. | 17:49 |
| lpapp | if you had done, please repaste. | 17:49 |
| cetola | I have a question about udev caching in dylan. I added a RRECOMMENDS += "udev-cache" to my bbappend file and it seems work fine, save 1 issue. | 17:50 |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 17:51 | |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has joined #yocto | 17:51 | |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 17:51 | |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 17:52 | |
| lpapp | ndec: is it just me or you do not find a proposal for this issue in the documentation? | 17:53 |
| cetola | The udev init script is not writing the file "/dev/shm/udev.cache" unless the file "$DEVCACHE" exists. However, the udev-cache script tried to move "/dev/shm/udev.cache" before it has created the tar file ($DEVCACHE). | 17:53 |
| ndec | lpapp: what? | 17:53 |
| *** dvhart <dvhart!dvhart@nat/intel/x-nmhttjdbycaljxfo> has joined #yocto | 17:53 | |
| otavio | lpapp: I fixed fw-utils | 17:53 |
| lpapp | ndec: explanation, you know, what users can read and use. | 17:53 |
| otavio | lpapp: all build fine now | 17:53 |
| lpapp | otavio: I do not care as I do not use it. ;) | 17:53 |
| ndec | lpapp: i believe i know what documentation mean. though i am not native speaker neither. | 17:54 |
| ndec | lpapp: i gave you a workaround that works, btw. | 17:54 |
| lpapp | ndec: what workaround? | 17:55 |
| otavio | lpapp: Mind to take a look at http://pastebin.com/7xRTDA9A (specially the commit log) so I can send it to ml? | 17:55 |
| lpapp | otavio: as I already said I am not happy with your way of working about it | 17:56 |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has quit IRC | 17:56 | |
| ndec | lpapp: read the backlog , i won't repeat ;-) | 17:56 |
| lpapp | I think it is more respectful to make an incremental change for what *you* did. | 17:56 |
| otavio | lpapp: no problem, the unhappyness is mutual | 17:56 |
| otavio | lpapp: I did all the upgrade path | 17:56 |
| lpapp | and not take others' work, and then put them into brackets. | 17:56 |
| otavio | lpapp: you did not | 17:56 |
| lpapp | ndec: I do not think you mentioned any particular really. | 17:57 |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has joined #yocto | 17:57 | |
| lpapp | you mentioned using CPPFLAGS which I already did. | 17:57 |
| lpapp | it did not work,. | 17:57 |
| lpapp | work.* | 17:58 |
| ndec | [19:40:03] <ndec> lpapp: temp workaround set CPPFLAGS in the .bb file | 17:59 |
| lpapp | 18:55 < lpapp> you mentioned using CPPFLAGS which I already did. | 17:59 |
| lpapp | otavio: not to mention your change is totally wrong. ;) | 18:01 |
| otavio | lpapp: really? | 18:02 |
| otavio | lpapp: why? | 18:02 |
| lpapp | Yes, really. Others explicitly asked not to remove the old versions. | 18:02 |
| *** LiangC <LiangC!~Leon@76.78.7.187> has joined #yocto | 18:02 | |
| ndec | lpapp: look. i have tested this workaround before giving it to you. if you set the variable in the .bb it will work. you must be doing something wrong. | 18:02 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 18:02 | |
| lpapp | unless you test it on all the reference platforms which I believe you could not do in this short while. | 18:02 |
| ndec | that said, it's friday night here. have a good weekend. | 18:02 |
| lpapp | ndec: it does not work for several reasons. | 18:02 |
| lpapp | bye I guess. | 18:03 |
| otavio | abelloni: Why you did not update the barebox recipe? | 18:03 |
| lpapp | otavio: oh, and taking the credit in the commit is respectless towards me, but also kde. | 18:04 |
| lpapp | not only* | 18:04 |
| lpapp | as I was using the kde address for this. | 18:04 |
| lpapp | no one will ever check commit logs when doing statistics, etc. | 18:05 |
| lpapp | so yeah, just be aware of that, I will mention this publicly, too. | 18:05 |
| lpapp | but this change would need decent work still. | 18:05 |
| lpapp | especially since git is limited in certain ways. | 18:05 |
| lpapp | so I hope at least mine can make it by the freeze. | 18:06 |
| lpapp | not sure when sgw_ builds the stuff for that.. maybe Saturday or Sunday? | 18:06 |
| *** bluelightning <bluelightning!~paul@83.217.123.106> has joined #yocto | 18:06 | |
| *** bluelightning <bluelightning!~paul@83.217.123.106> has quit IRC | 18:06 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 18:06 | |
| otavio | lpapp: you said it is wrong ... how wrong? | 18:07 |
| cetola | ah, nevermind, I found a bug report for this udev issue in OE | 18:07 |
| otavio | lpapp: all work for me | 18:07 |
| lpapp | I already wrote. | 18:07 |
| lpapp | anyway, I am off to cycling to home. | 18:08 |
| otavio | lpapp: good; I e-mailed it to mailing list so you're free to comment on this. Enjoy your way to home. | 18:10 |
| lpapp | otavio: it is rejected by default | 18:10 |
| lpapp | since it was rejected this morning already. | 18:10 |
| lpapp | others explicitly asked me to not remove other stuff | 18:11 |
| lpapp | if it is not tested on all the reference platform | 18:11 |
| lpapp | which I highly doubt you did in 1-2 hours when you were unable to even check the log for 1-2 weeks. | 18:11 |
| lpapp | or run a build command. | 18:11 |
| lpapp | and yes, I will definitely comment on the unfairness towards contributors. | 18:11 |
| lpapp | I have not seen anyone the last 5-6 years at least taking such things from other people, especially when explicitly asked. At least, we have not done in the linux kernel, qt, and kde. | 18:12 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 18:17 | |
| *** LiquidL <LiquidL!~lab@wsip-98-189-25-196.oc.oc.cox.net> has joined #yocto | 18:18 | |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC | 18:23 | |
| Stygia | What's the right way to do multiple do_install_prepend's without overwritting the other ones? | 18:25 |
| Stygia | I need to do a do_install_prepend in a bbappend but I don't want to overwrite the one in the recipe itself. | 18:25 |
| Stygia | do_install_prepend_prepend? | 18:25 |
| bluelightning | Stygia: they'll always stack and not overwrite eachother | 18:25 |
| Stygia | bluelightning, Fantastic then. :) | 18:25 |
| bluelightning | :) | 18:26 |
| bluelightning | (with _prepend / _append, that is) | 18:26 |
| bluelightning | bbl, heading home | 18:26 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 18:27 | |
| *** reeve <reeve!81c0aafa@gateway/web/freenode/ip.129.192.170.250> has quit IRC | 18:27 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 18:33 | |
| lpapp | otavio: also, you are aware of that you can make suggestions for patches, too? | 18:37 |
| otavio | lpapp: yes and you said you didn't care about fw-utils | 18:37 |
| lpapp | especially for new contributors not to demotivate them with not involving them? | 18:37 |
| Stygia | We have a bbappend file in our own layer. This bbappend adds to FILESEXTRAPATH, and then we need to do something like do_install_prepend to install a file to the proper location - This file will then later be parsed by the do_install_append function in the main recipe. However, it seems that in our bbappend ${THISDIR}${PN} resolves to the location of the main recipe (in meta-openembedded instead of in meta-COMPANY), instead of the | 18:38 |
| Stygia | bbappend. How do I get the location of the file that my bbappend adds to SRC_URI so I can run an install on it? | 18:38 |
| lpapp | no, you said you would create a change. | 18:38 |
| lpapp | regardless I care or not. | 18:38 |
| lpapp | anyway, I will leave it with Jeff to handle it. Apparently, my questions, nor my contribution is welcome. | 18:38 |
| lpapp | fwiw, I have been trying to get my first contribution for over a month now. | 18:38 |
| lpapp | in* | 18:39 |
| Stygia | do_install fails with the file not being present, as my do_install_prepend in the bbappend looks for the file in a path relative to the original recipe. | 18:39 |
| Stygia | Obviously hardcoding the relative path is not desirable. | 18:39 |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC | 18:40 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 18:41 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 18:42 | |
| -YoctoAutoBuilder- build #235 of nightly-fsl-arm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm/builds/235 | 18:43 | |
| Stygia | Is there some way to find the path of the current bbappend as a special variable? | 18:43 |
| kergoth | THISDIR if expanded immediately refers to the currently parsed file's dir | 18:44 |
| kergoth | which is why FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" and the like is used, and works | 18:44 |
| kergoth | otherwise it'd have no way to locate the file:// files relative to the bbappend | 18:44 |
| Stygia | kergoth, But in my bbappend, I have a do_install_prepend. That runs this command: install -m 0777 ${THISDIR}/${PN}/DigiCertHighAssuranceCA-3.crt ${D}/usr/share/ca-certificates | 18:45 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 18:45 | |
| Stygia | kergoth, Then during the build stage, do_install fails complaining that the file is missing - Showing the full expanded path as being the location of the original recipe instead of my bbappend | 18:45 |
| Stygia | kergoth, It does work fine in my FILESEXTRAPATH, though, that stopped it complaining about the file missing. But now I want to install the file to that location before the actual recipe kicks in | 18:46 |
| *** musdem <musdem!~zack@CPE98fc11766960-CM0026f3a1cd6d.cpe.net.cable.rogers.com> has joined #yocto | 18:46 | |
| kergoth | you shouldn't be doing that | 18:47 |
| kergoth | add the file to SRC_URI using file:// and install it from ${WORKDIR} | 18:47 |
| kergoth | file://DigiCertHighAssuranceCA-3.crt, then do the aforementioned FILESEXTRAPATHS_prepend, then install it from WORKDIR | 18:48 |
| *** acidfu <acidfu!~nib@24.37.17.210> has joined #yocto | 18:48 | |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto | 18:48 | |
| *** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC | 18:48 | |
| kergoth | THISDIR only expands to the currently parsed file. since values aren't expanded until they're used, the reference in the task isn't expanded until after the recipe completes parsing, at which time it refers to the path by the recipe itself, not the bbappend | 18:48 |
| kergoth | := with FILESEXTRAPATHS forces immediate expansion, which is why that works | 18:48 |
| *** zenlinux_ <zenlinux_!~sgarman@173-8-218-204-Oregon.hfc.comcastbusiness.net> has quit IRC | 18:49 | |
| *** flynn378 <flynn378!80db310e@gateway/web/freenode/ip.128.219.49.14> has quit IRC | 18:54 | |
| Stygia | kergoth, Alright, makes sense. Thanks, I'll try and update the paths. | 18:54 |
| kergoth | np | 18:57 |
| Stygia | kergoth, Was workdir, indeed. :) Thanks. | 18:57 |
| *** swex <swex!~swex@178.17.199.158> has joined #yocto | 18:58 | |
| *** swex__ <swex__!~swex@217.197.254.102> has quit IRC | 19:01 | |
| kergoth | np | 19:02 |
| *** LiangC <LiangC!~Leon@76.78.7.187> has quit IRC | 19:02 | |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has quit IRC | 19:04 | |
| ftonello_ | any idea when yocto 1.5 will be released? | 19:04 |
| *** dvhart <dvhart!dvhart@nat/intel/x-nmhttjdbycaljxfo> has quit IRC | 19:04 | |
| kergoth | there's a release schedule / calendar on the wiki | 19:08 |
| *** flynn378 <flynn378!80db310e@gateway/web/freenode/ip.128.219.49.14> has joined #yocto | 19:10 | |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has quit IRC | 19:14 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 19:21 | |
| *** zack__ <zack__!~zack@CPE98fc11766960-CM0026f3a1cd6d.cpe.net.cable.rogers.com> has joined #yocto | 19:24 | |
| *** zack__ <zack__!~zack@CPE98fc11766960-CM0026f3a1cd6d.cpe.net.cable.rogers.com> has joined #yocto | 19:24 | |
| *** zack__ <zack__!~zack@CPE98fc11766960-CM0026f3a1cd6d.cpe.net.cable.rogers.com> has joined #yocto | 19:25 | |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has joined #yocto | 19:28 | |
| *** mike <mike!5b99cbbc@gateway/web/freenode/ip.91.153.203.188> has joined #yocto | 19:35 | |
| *** mike is now known as Guest93651 | 19:35 | |
| Guest93651 | Can anybody offer some tips for creating kernel recipes ? | 19:36 |
| Guest93651 | Have recipe which gets kernel from a git repo | 19:36 |
| Guest93651 | it works fine | 19:36 |
| Guest93651 | how I want to be able to reuse the recipe but change the branch | 19:37 |
| Guest93651 | however it says that it cant find the recipe when I compile it | 19:38 |
| Guest93651 | sorry .. | 19:38 |
| Guest93651 | it seems to checkout same git recipe even though I set different version in distro | 19:38 |
| Guest93651 | ??? | 19:39 |
| Guest93651 | anybody? | 19:40 |
| Guest93651 | anybody with experience creating kernel recipes for multiple branches of kernel | 19:40 |
| Guest93651 | ?? | 19:40 |
| Guest93651 | Is anybody listening? | 19:42 |
| *** amarsman <amarsman!~marsman@52489B71.cm-4-1c.dynamic.ziggo.nl> has joined #yocto | 19:42 | |
| *** amarsman <amarsman!~marsman@52489B71.cm-4-1c.dynamic.ziggo.nl> has joined #yocto | 19:43 | |
| Guest93651 | aaahhhh | 19:44 |
| * mranostay facepalms | 19:45 | |
| Guest93651 | can anybody offer some information please on my question? | 19:46 |
| lpapp | Guest93651: have you checked the kernel documentation? | 19:48 |
| Guest93651 | I have n't found the yocto documentation useful | 19:49 |
| Guest93651 | in this regard | 19:49 |
| lpapp | Guest93651: have you seen this, KBRANCH ?= "master" | 19:49 |
| *** dv_ <dv_!~quassel@chello080108009040.14.11.vie.surfer.at> has quit IRC | 19:50 | |
| Guest93651 | I have removed that | 19:51 |
| Guest93651 | I am using linux-dtb.inc and inherit kernel in recipe | 19:51 |
| Guest93651 | so I dont think kbranch is needed | 19:51 |
| lpapp | kbranch is not needed when you need a custom branch? o_O | 19:52 |
| *** dv_ <dv_!~quassel@chello080108009040.14.11.vie.surfer.at> has joined #yocto | 19:53 | |
| Guest93651 | I think so | 19:54 |
| Guest93651 | anyway first recipe declares that... | 19:54 |
| Guest93651 | and in other recipes... I just require origional recipe and set the git branch I want | 19:55 |
| Guest93651 | but it doesnt get the branch I want | 19:55 |
| Guest93651 | when I set preferred version in distro | 19:55 |
| zeddii | Guest93651, you question is with the git fetcher. you need to specify the branch in the SRC_URI if you are just using the stock kernel.bbclass support. | 20:03 |
| *** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has joined #yocto | 20:03 | |
| *** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has quit IRC | 20:03 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:03 | |
| Guest93651 | the SRC_URI has the branch set .. like | 20:04 |
| Guest93651 | SRC_URI = "git... ;branch =${BRANCH} | 20:04 |
| Guest93651 | so when I reuse that recipe I just change the branch variable | 20:05 |
| zeddii | yep. that's what you are saying isn't working ? | 20:05 |
| Guest93651 | but it always seem to check same git branch | 20:06 |
| cbab | can anyone explain the process by which patches sent on the openembedded-core get merged in yocto? how does it work? | 20:06 |
| zeddii | Guest93651, it checks out a SRCREV not a branch. | 20:07 |
| zeddii | are you changing SRCREV ? | 20:07 |
| zeddii | the branch tells the fetcher where to look to trigger an update, i.e. if the local copy in your download is out of sync with the branch you are tracking. | 20:08 |
| zeddii | (btw: I'm not a fetcher expert, but I get by :) | 20:08 |
| Guest93651 | I not doing anything setting for SRCREV | 20:09 |
| zeddii | cbab, it's a pull model. You send a patch to the openembedded-core@lists.openembedded.org mailing list, someone reviews, or a maintainer picks them up themselves, they are tested and then merged by Richard into the right place. | 20:09 |
| zeddii | Guest93651, without seeing your recipe, I can't say more. But if you are really building a git based recipe, you must have a SRCREV set somewhere, it won't work otherwise. | 20:09 |
| cbab | zeddii: okay great thanks! I was also wondering is there any policy for recipe update version? I want to update libfoo 2.0.0 to 2.0.1 | 20:11 |
| zeddii | there's a maintainers file for meta-yocto at least (which overlaps oe-core recipes). meta-yocto/conf/distro/include/maintainers.inc | 20:12 |
| Guest93651 | I think I have it set to AUTOREV. I must check that | 20:12 |
| zeddii | in there you'll see if you should send an update to someone in particular, or ping to see if they are updating, etc. | 20:12 |
| zeddii | cbab, but as for timing, when the yocto project is in a stabilization phases, updates tend to be asked to wait. and coincidentally, it's just heading into one on Sunday :) | 20:13 |
| cbab | zeddii: okay I see, I maintain packages for the lttng project and was wondering if oe needed any help updating the recipes in oe-core :) | 20:14 |
| cbab | is there a preference for tarball over git for recipes? | 20:15 |
| *** Guest93651 <Guest93651!5b99cbbc@gateway/web/freenode/ip.91.153.203.188> has quit IRC | 20:19 | |
| zeddii | cbab, ah cool. We do update our lttng packages to track periodically already, currently Laurentiu Palcu <laurentiu.palcu@intel.com> takes care of it, and I do parts in the kernel (via LTSI and others), not that everything can be out of tree .. it is easier in some ways now :) | 20:20 |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 20:21 | |
| zeddii | cbab, it depends on the project. git is good for most cases. easier for active development as far as I'm concerned. | 20:21 |
| cbab | zeddii: alright, I'm asking because I was wondering why the module recipe had the _git suffix and not the others recipes even though they are checking out from git | 20:24 |
| cbab | also I made sure that we pushed upstream one of the oustanding patch for lttng-ust: http://bugs.lttng.org/projects/lttng-ust/repository/revisions/b2684aaa292bb9e4f42fde2a57b0be175363a5bd | 20:25 |
| *** sameo <sameo!~samuel@192.55.54.40> has joined #yocto | 20:28 | |
| *** reeve <reeve!81c0aafa@gateway/web/freenode/ip.129.192.170.250> has joined #yocto | 20:29 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 20:31 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 20:33 | |
| *** Bhawna <Bhawna!~arunkr24@123.201.34.10> has quit IRC | 20:35 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 20:36 | |
| reeve | seebs: yesterday you're syaing revision 39, "Use converting codecs when grabbing rpm output through sys.std{out,err}.". Can you point me to the commit sha or log link? I couldn't find it | 20:37 |
| reeve | revision 398 * | 20:37 |
| reeve | geeze, revision 389* | 20:38 |
| zeddii | cbab, it's a convention, but not all recipes that use git have _git in their name. | 20:38 |
| seebs | reeve: It's from the smartpm repository, but I don't have that machine handy to look it up. Look for the smartpm repository, which I think is bazaar or something. | 20:39 |
| reeve | seebs: I'm on dylan branch, so do I have that change? | 20:40 |
| cbab | zeddii: alright, thanks for answering my questions :) I'll send patches to the maintainers perhaps after the stabilization phase | 20:40 |
| reeve | seebs: when you say smartpm repo, what does it mean? Another git server? | 20:40 |
| seebs | I mean the source repository used by the smartpm project, which is using some other source control system I am not very familiar with. | 20:41 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 20:41 | |
| seebs | https://code.launchpad.net/~smartpm/smart/trunk | 20:41 |
| bluelightning | we should probably try to convince them to switch to git | 20:43 |
| reeve | thanks, I'll look at it | 20:43 |
| bluelightning | I don't think it will be too hard a sell to be honest | 20:43 |
| Bagder | launchpad projects tend to be bzr, right? | 20:44 |
| bluelightning | right | 20:44 |
| bluelightning | development on smart was funded by canonical for a time | 20:45 |
| bluelightning | (a few years ago) | 20:45 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 20:49 | |
| Bagder | right "Funded Smart development up to November of 2009" it says in the README | 20:50 |
| Bagder | as a curl hacker I'm happy to see they use pycurl =) | 20:50 |
| bluelightning | code-wise it's fairly clean | 20:51 |
| bluelightning | somewhat lacking in debug mode output though sadly | 20:52 |
| bluelightning | I might try to improve that in 1.6 | 20:52 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 20:56 | |
| abelloni | otavio: you mean 2013.08 is not recent enough ? | 20:57 |
| otavio | abelloni: no; I mean removing the old one from fsl-arm | 20:58 |
| *** ka6sox-away is now known as zz_ka6sox-away | 21:03 | |
| abelloni | oh | 21:11 |
| abelloni | tha fact is that the qsb had quite a lot of patches to get it working | 21:12 |
| abelloni | I'm not sure if everything made it to the mainline | 21:12 |
| abelloni | probably though | 21:12 |
| abelloni | but I don't have any imx53/imx6 boards anymore | 21:12 |
| abelloni | so I couldn't check | 21:12 |
| abelloni | Eric was supposed to ship a board or two but I guess mor important things came up | 21:13 |
| *** ant_home <ant_home!~andrea@host118-229-dynamic.20-79-r.retail.telecomitalia.it> has joined #yocto | 21:14 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 21:14 | |
| otavio | abelloni: humm | 21:15 |
| *** reeve <reeve!81c0aafa@gateway/web/freenode/ip.129.192.170.250> has quit IRC | 21:26 | |
| -YoctoAutoBuilder- build #274 of nightly-x32 is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x32/builds/274 | 21:31 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 21:43 | |
| *** musdem <musdem!~zack@CPE98fc11766960-CM0026f3a1cd6d.cpe.net.cable.rogers.com> has quit IRC | 21:46 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 21:50 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 21:56 | |
| *** zz_ka6sox-away is now known as ka6sox | 21:59 | |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 22:00 | |
| jwessel | Any one around who knows something about the PR server? | 22:07 |
| JaMa | mr wiki | 22:07 |
| * jwessel is trying diagnose why it hangs while using "bitbake -e" | 22:07 | |
| jwessel | Seems like this will be fairly tricky to debug. | 22:07 |
| JaMa | https://wiki.yoctoproject.org/wiki/PR_Service | 22:07 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 22:08 | |
| JaMa | are you sure it's PR server hanging? | 22:08 |
| jwessel | I am fairly certain. | 22:08 |
| jwessel | #39 Frame 0x5347070, for file /space/jw/6/small/qemux86/bitbake/lib/prserv/serv.py, line 91, in work_forever ( | 22:09 |
| jwessel | That calls into: #35 Frame 0x6d61130, for file /usr/lib/python2.7/logging/__init__.py, line 1140, in info (self=<BBLogger(name='BitBake.PRserv', parent=<BBLogger(name='BitBake', parent=<RootLogger(name='root', parent=None, handlers=[], level=30, disabled=0, propagate=1, filters=[]) | 22:09 |
| JaMa | and are you running standalone PR server or starting it with bitbake? | 22:09 |
| jwessel | And it is ultimately blocked on a semaphore deep in the guts of python. | 22:09 |
| jwessel | It starts automatically with bitbake. | 22:09 |
| jwessel | The line 91 is: | 22:09 |
| jwessel | logger.info("Started PRServer with DBfile: %s, IP: %s, PORT: %s, PID: %s" % | 22:10 |
| jwessel | (self.dbfile, self.host, self.port, str(os.getpid()))) | 22:10 |
| jwessel | So it didn't really get about doing its work. NOTE this is some kind of race condition because I have to put the machine under a fairly significant load to get this to happen. | 22:10 |
| JaMa | I would try to run separate PR server to divide the issue a bit | 22:10 |
| JaMa | maybe you're seeing the same as https://bugzilla.yoctoproject.org/show_bug.cgi?id=4338 | 22:11 |
| yocti | Bug 4338: normal, Medium, 1.5, richard.purdie, NEW , bitbake hangs forever before showing any output | 22:11 |
| JaMa | it also needs significant load to happen | 22:11 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 22:11 | |
| jwessel | Well as another data point, before we had the prserver activated, this never ever happened :-) | 22:12 |
| jwessel | JaMa: I am fairly certain these are closely related | 22:12 |
| jwessel | I was actually going to hit that other bug with the gdb sledge hammer when I got burned by this with a much greater frequency. | 22:13 |
| jwessel | The main bitbake is in the terminate cycle, since I can trace all the threads. So the logger is probably long gone at that point. | 22:15 |
| jwessel | Clearly the "bitbake -e", is not using the pr server in this instance. | 22:15 |
| JaMa | jwessel: are you running multiple bitbake processes on the same machine? | 22:18 |
| jwessel | Definitely | 22:18 |
| JaMa | jwessel: or can you reproduce it even with just one bitbake running? | 22:18 |
| RP | jwessel: hot or cold cache? | 22:19 |
| JaMa | I meant multiple independent builds | 22:19 |
| jwessel | I have not yet reproduced this with a single instance and just jacking up the load. | 22:19 |
| jwessel | All the builds are independent | 22:19 |
| JaMa | jwessel: good, the same here | 22:19 |
| JaMa | jwessel: and I also see it only after enabling PR service (btw there was similar issue https://bugzilla.yoctoproject.org/show_bug.cgi?id=3742) | 22:20 |
| yocti | Bug 3742: major, Medium, 1.4, richard.purdie, VERIFIED FIXED, bitbake hangs forever when PR serv is enabled | 22:20 |
| jwessel | Oh so this is already fixed somewhere? | 22:20 |
| JaMa | partially fixed | 22:21 |
| RP | jwessel: no, we found issues mixing threading and multiprocessing in some versions of python so we removed the use of threading | 22:21 |
| JaMa | RP's fix from 3742 fixed it for some time and some time later it started again only slightly different | 22:21 |
| jwessel | I am probably going to have to instrument it a bit. | 22:22 |
| JaMa | jwessel: how often do you see it? | 22:22 |
| RP | multiprocessing and threading in python 2 are full of bugs :( | 22:22 |
| RP | jwessel: do you have a good way to reproduce? | 22:22 |
| jwessel | I can see the main thread is blocked on terminate and doing a join for tearing things down. | 22:22 |
| jwessel | Yes, but it may only happen on my environment. | 22:22 |
| jwessel | I can reproduce it in < 5min. | 22:23 |
| JaMa | jwessel: btw what's your distro? | 22:23 |
| JaMa | jwessel: and are you using e.g. chroot for builds? | 22:23 |
| jwessel | Had to look... It was Ubuntu 12.04 | 22:23 |
| jwessel | I am not using any kind of chroot that I am aware of. | 22:23 |
| jwessel | RP: Basically I run "bitbake -e" in a loop and then I figure up my 30x30 builds in a different directory. | 22:24 |
| JaMa | OK, I was just looking for some similarities between our setups as we're probably the only two seeing this issue :) | 22:24 |
| jwessel | Each pass of the bitbake -e takes about 6 seconds and it never makes it to 100 passes. | 22:25 |
| RP | jwessel: does your bitbake -e loop clear the caches at all? | 22:25 |
| jwessel | nope. | 22:25 |
| jwessel | Straight reuse of the cache. | 22:25 |
| RP | jwessel: that is a helpful data point | 22:25 |
| * jwessel goes to inspect the third thread. | 22:25 | |
| jwessel | RP, you want to see the traces? | 22:25 |
| jwessel | I was planning on possibly sending them to you anyway. | 22:25 |
| RP | jwessel: each is starting its own PR server, there is no common shared one? | 22:25 |
| jwessel | There is definitely no common PR server. | 22:26 |
| RP | jwessel: I can take a look but I would warn you my brain is fried with the release freeze coming up | 22:26 |
| jwessel | No worries. | 22:26 |
| RP | been doing 20 things at once for too many hours | 22:26 |
| jwessel | Get some sleep then. | 22:26 |
| jwessel | Not like this problem is going away :-) | 22:26 |
| RP | jwessel: that will happen shortly :) | 22:26 |
| jwessel | I had figured you were gone long ago for the day, and I would chat with you on Monday about this one. | 22:27 |
| jwessel | I need to collect all the logs and stare at this a bit more anyway. | 22:27 |
| jwessel | how odd... | 22:28 |
| jwessel | The other thread is executing: def ping(self): | 22:29 |
| jwessel | return self.connection.ping() | 22:29 |
| RP | this stirs memories | 22:30 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 22:30 | |
| jwessel | So basically the PR server is trying to come online, bitbake forked it, and the ping, and the master guy is in terminate. | 22:30 |
| jwessel | With the high load, I could certainly see how this might happen. | 22:30 |
| RP | jwessel: yes, I think this sounds like a promising direction | 22:31 |
| jwessel | I'll have to study the code and the traces and perhaps add some instrumentation. | 22:31 |
| jwessel | At any rate the sledge hammer debug approach can at least trace the orphan. | 22:31 |
| jwessel | I couldn't get pdb attached before, so I am miles ahead of where I was previously at. | 22:32 |
| jwessel | I had to make some other changes too like using python-dbg, in order to get a usable debug env. | 22:32 |
| ant_home | RP: just checking EBUG: Replacing absolute path /oe/oe-core/build/tmp-eglibc/sysroots/qemuarm/usr/include/linux with relative path ./../../../../sysroots/qemuarm/usr/include/linux for /oe/oe-core/build/tmp-eglibc/sysroots/qemuarm-tcbootstrap/usr/include/linux | 22:32 |
| jwessel | RP: So perhaps I'll chat with you on Monday and share the findings and we can go from there, since you know quite a bit more about architecture of this stuff. | 22:33 |
| JaMa | jwessel: good work! | 22:33 |
| RP | jwessel: sounds good | 22:33 |
| ant_home | RP at first it should be ../ and not ./ isn't ? | 22:33 |
| ant_home | RP: rebuilding image right now after pull | 22:33 |
| RP | ant_home: no, that looks right | 22:33 |
| jwessel | With some instrumentation around the steps prior to terminate perhaps more information can be had. | 22:34 |
| ant_home | hm, is pwd in /include then ? | 22:34 |
| RP | ant_home: yesm the directory containing the link | 22:34 |
| jwessel | The picture of the dead lock is fairly obvious, but how we got here isn't (at least not to me yet). | 22:34 |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 22:35 | |
| ant_home | RP: http://paste.debian.net/29239/ | 22:35 |
| jwessel | Knowing how we fast path to the terminate routine will help. | 22:36 |
| ant_home | RP: ok then http://paste.debian.net/29240/ | 22:37 |
| jwessel | For reference the dead lock is basically this: The bitbake server started, forked the pr server, and finished quickly leaving us with with 3 processes. | 22:37 |
| jwessel | main process (A) is calling join in its terminate block to process (B) | 22:37 |
| RP | ant_home: you're in the target directory there, that makes no sense | 22:38 |
| jwessel | Process (B) is the ping to the PR server to see it is alive | 22:38 |
| jwessel | and it is blocked waiting for the ping to come back. | 22:38 |
| ant_home | RP: ? | 22:38 |
| jwessel | Process (C) is the PR server waiting to write a logger back to the main process | 22:38 |
| jwessel | The obvious choice here seems to remove the logger.() stuff or reset it or something... | 22:39 |
| RP | jwessel: like logger.info("PRServer: stopping...") ? :) | 22:40 |
| jwessel | logger.info("Started PRServer with DBfile: %s, IP: %s, PORT: %s, PID: %s" % | 22:41 |
| jwessel | (self.dbfile, self.host, self.port, str(os.getpid()))) | 22:41 |
| RP | jwessel: isn't logger going to a file? | 22:41 |
| jwessel | It is blocked at line 91 of serv.py | 22:41 |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 22:41 | |
| jwessel | If it is, it isn't working. | 22:41 |
| jwessel | RP: http://pastebin.com/jehv0FT3 | 22:43 |
| jwessel | RP frame 15 is the one where we call into the python "stuff" | 22:44 |
| RP | jwessel: I think logger.addHandler(streamhandler) might be the issue | 22:44 |
| RP | jwessel: we need to make that the *only* handler | 22:44 |
| *** mckoan|USA is now known as mckoan | 22:45 | |
| jwessel | Yes, I wasn't exactly sure how to get this thing partitioned away from the main bitbake after the fork. | 22:45 |
| *** mckoan is now known as mckoan|away | 22:46 | |
| *** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has quit IRC | 22:46 | |
| *** mckoan|away is now known as mckoan|USA | 22:46 | |
| jwessel | In theory it should log to its own file anyway in a separate place. | 22:46 |
| jwessel | Or from what ever build directory it started from. | 22:46 |
| jwessel | hmm.. Was that called in the right place? | 22:47 |
| jwessel | Because it should only open the file after the fork. | 22:47 |
| jwessel | RP: I'll take a look at it later. Off to get some dinner in my time zone. :-) | 22:48 |
| jwessel | Cheers and thanks for the advice. | 22:48 |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has quit IRC | 22:50 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 22:52 | |
| RP | jwessel: try adding a del logging.root.handlers[:] before the new addHandler | 22:54 |
| -YoctoAutoBuilder- build #142 of nightly-qa-systemd is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-qa-systemd/builds/142 | 22:56 | |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has quit IRC | 23:07 | |
| *** scot <scot!~scot@130.164.62.183> has quit IRC | 23:17 | |
| *** musdem <musdem!~Zack@CPE98fc11766960-CM0026f3a1cd6d.cpe.net.cable.rogers.com> has joined #yocto | 23:21 | |
| RP | jwessel: I'm not convinced the pr server is writing to the bitbake server for logging. Quite puzzling. Note there are two identical log messages | 23:31 |
| jwessel | I am not entirely sure what all happened. | 23:35 |
| jwessel | I queued the change you asked about and I'll get the results back after I get back from the mall. | 23:35 |
| jwessel | I believe a bit of instrumentation is in order now that I have a way to trace things. | 23:36 |
| RP | jwessel: I can make it hang with: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip76&id=26fad05c9d989fcfa0e6cb6bf643471f1b689e59 | 23:36 |
| RP | jwessel: the question would be why work_forever is exiting, could be some kind of error? | 23:37 |
| RP | anyhow, /me -> Zzzz | 23:37 |
| *** LiquidL <LiquidL!~lab@wsip-98-189-25-196.oc.oc.cox.net> has quit IRC | 23:38 | |
| RP | even just removing the work_forever makes it hang... | 23:39 |
| *** ftonello_ is now known as ftonello | 23:40 | |
| *** ant_home <ant_home!~andrea@host118-229-dynamic.20-79-r.retail.telecomitalia.it> has quit IRC | 23:42 | |
| jwessel | heh.. I can tell you why your patch hangs only because I had the other traces which I didn't send you ( I figure you'll see this msg later). | 23:43 |
| jwessel | The ping that the main bitbake launches will never complete. | 23:44 |
| *** sameo <sameo!~samuel@192.55.54.40> has quit IRC | 23:44 | |
| jwessel | So that subprocess will never reap and it will look like a hang. Because you never did the work forever the initial ping could not be completed. Allowing a provision for a ping timeout would solve that issue. | 23:44 |
| * jwessel leaves as well. | 23:44 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 23:54 | |
| *** alex_kag <alex_kag!~alex_kag@93.84.75.157> has quit IRC | 23:54 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!