Friday, 2013-08-23

*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:01
*** andyross <andyross!> has quit IRC00:05
*** sameo <sameo!samuel@nat/intel/x-tetlhmiwjemdbjlq> has quit IRC00:09
*** fitzsim <fitzsim!~user@nat/cisco/x-tuzmlaanwvmtfddj> has quit IRC00:18
*** fitzsim <fitzsim!~user@nat/cisco/x-jwarwcnsqbvjydeb> has joined #yocto00:18
*** mulhern <mulhern!> has joined #yocto00:23
*** _julian <_julian!> has joined #yocto00:23
*** _julian_ <_julian_!> has quit IRC00:23
*** scot <scot!~scot@> has quit IRC00:49
*** seebs <seebs!> has joined #yocto00:52
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto00:52
*** jmpdelos <jmpdelos!> has quit IRC00:55
*** jmpdelos <jmpdelos!> has joined #yocto00:55
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:14
*** mulhern <mulhern!> has quit IRC01:20
*** fitzsim <fitzsim!~user@nat/cisco/x-jwarwcnsqbvjydeb> has quit IRC01:26
*** fitzsim <fitzsim!~user@nat/cisco/x-rruaafrlkwastvux> has joined #yocto01:26
*** dany <dany!> has quit IRC01:32
*** mulhern <mulhern!> has joined #yocto01:32
*** fitzsim <fitzsim!~user@nat/cisco/x-rruaafrlkwastvux> has quit IRC01:38
*** fitzsim <fitzsim!~user@nat/cisco/x-qqmcnlwdpytaemdi> has joined #yocto01:38
*** mulhern <mulhern!> has quit IRC01:40
*** seebs <seebs!> has quit IRC01:54
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto02:01
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC02:02
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC02:04
*** bozojoe <bozojoe!4475c643@gateway/web/freenode/ip.> has quit IRC02:06
*** fitzsim <fitzsim!~user@nat/cisco/x-qqmcnlwdpytaemdi> has quit IRC02:07
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto02:19
*** smartin <smartin!> has joined #yocto02:21
*** smartin_ <smartin_!> has quit IRC02:22
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC02:38
*** seebs <seebs!> has joined #yocto03:05
*** smartin <smartin!> has quit IRC03:14
*** smartin <smartin!> has joined #yocto03:15
*** seebs <seebs!> has quit IRC03:15
*** seebs <seebs!> has joined #yocto03:21
*** musdem <musdem!> has joined #yocto03:26
*** zenlinux <zenlinux!> has joined #yocto03:26
*** musdem <musdem!> has quit IRC03:27
*** andyross <andyross!> has joined #yocto03:39
*** amarsman <amarsman!> has quit IRC03:52
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC03:56
*** amarsman <amarsman!> has joined #yocto04:03
*** jmpdelos <jmpdelos!> has quit IRC04:03
*** scot <scot!~scot@> has joined #yocto04:03
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto04:08
lpappsgw_: well, someone said that before (otavio) they are not needed anymore04:09
*** alex_kag <alex_kag!~alex_kag@> has joined #yocto04:13
lpappsgw_: and everyone was suggesting before to remove the previous versions, so I followed the suggestions.04:13
*** alex_kag <alex_kag!~alex_kag@> has quit IRC04:13
lpappsgw_: 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!> has joined #yocto04:16
*** Leon <Leon!~Leon@> has joined #yocto04:17
*** Leon is now known as Guest3461804:17
*** mihai <mihai!~mihai@> has quit IRC04:18
*** LiangC <LiangC!~Leon@> has quit IRC04:19
lpappjackmitchell: any critics about u-boot getting in? ^ I pleased your nit. :)04:25
*** smartin <smartin!> has quit IRC04:38
*** smartin <smartin!~smartin@> has joined #yocto04:41
*** jkridner <jkridner!~jkridner@nat/ti/x-intivwdmtzuogbbj> has joined #yocto04:44
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto04:44
*** mihai <mihai!~mihai@> has joined #yocto04:50
*** alex_kag <alex_kag!~alex_kag@> has joined #yocto04:51
*** zeeblex <zeeblex!~apalalax@> has joined #yocto04:53
*** Guest34618 <Guest34618!~Leon@> has quit IRC04:58
*** andyross <andyross!> has quit IRC05:17
*** zecke <zecke!> has joined #yocto05:20
*** nitink <nitink!nitink@nat/intel/x-iynyedvfqqerjzfs> has joined #yocto05:21
*** smartin_ <smartin_!> has joined #yocto05:33
*** vicky <vicky!~vicky@> has joined #yocto05:43
vicky"bitbake  linux-yocto-custom -c deploy " not installing modules into the final image.05:44
vickyI tried bitbake  linux-yocto-custom. The same.05:45
*** tor <tor!> has joined #yocto05:50
mihaihalstead: ping06:13
tfvicky: building an individual package does not do anything to an image06:13
halsteadmihai, pong06:16
*** silviof1 is now known as silviof06:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto06:34
*** W1N9Zr0 <W1N9Zr0!> has quit IRC06:35
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:35
sgw_lpapp: I guess first question is did you build and test for the Poky BSP set that use u-boot?06:35
tfkergoth: I use the rt2800usb with rpi, havn't built a fresh images for ages though06:38
sgw_khem: you still awake?06:39
sgw_khem: I am having email issues, so can't reply to email right now06:39
lpappsgw_: no06:42
sgw_lpapp: so you don't know if they will boot correctly with this update?06:42
*** W1N9Zr0 <W1N9Zr0!> has joined #yocto06: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.> has joined #yocto06:45
lpappsgw_: you understand that it is not related to the bsp?06:46
*** Zagor <Zagor!> has joined #yocto06:46
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto06:46
lpappu-boot is just a loader, it loads whatever you give to it ...06:46
lpappit does not differentiate ...06:46
tflpapp: uh? u-boot is inherently related to bsp06:46
*** Net147 <Net147!> has joined #yocto06:46
lpappit loads the firmware you supply.06:47
lpappif 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 correctly06:47
B4gderit is a probably a matter of what you define BSP to be06:47
Net147line 187: 30554 Segmentation fault      (core dumped) opkg-cl -f $INSTALL_CONF_IPK -o $INSTALL_ROOTFS_IPK --force_postinstall --prefer-arch-to-version update06:47
Net147any ideas?06:47
*** smartin_ <smartin_!> has quit IRC06:47
lpappsgw_: well, my firmware loads so if the poky stuff does not, poky is doing something wrong anyway06:48
*** orhan89 <orhan89!a7cd1668@gateway/web/freenode/ip.> has quit IRC06: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 BSPs06:50
lpappsgw_: you do not follow.06:51
lpappu-boot works just fine with my firmware, and it is hardly firmware related. If it is, the firmware is wrong.06:51
lpappnot to mention I have _never_ said older u-boot does not work for me.06:52
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06: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
lpappwhy 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+62c175fbb806:56
sgw_NOTE: Resolving any missing task queue dependencies06:56
lpappsgw_: that would concern you anyway because there has been no 2012.0406:57
lpappso fix your broken stuff. :)06:57
*** dany <dany!> has joined #yocto06:58
tflpapp: that's not the point, the point is you have not tested your patch06:58
lpapptf: that is the point sgw_ brought up06:59
lpapptf: that is totally untrue06:59
lpapptf: I *did* test the patch many times.06:59
tflpapp: on all the supported HW?06:59
lpappyes, I went to the other cities to buy supported hardwares for fun... hell no.06:59
lpappbut of course, that does not mean others who wrote it works, they did not test it.07:00
tflpapp: 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 board07: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 licensing07:01
lpapptf, you are not making sense, sorry.07:01
bluelightninglpapp: I'm afraid that he is07:01
lpapptf: 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
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
lpappsgw_: exactly, make sure you do not blame others before verifying your stuff being working.07:03
bluelightningsgw_: morning... you're up late07:04
bluelightninglpapp: still doesn't mean this patch can be accepted prior to testing on the supported hardware07:04
lpappbluelightning: 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 work07:04
lpappsgw_: what can I say, if you do not trust others saying it works, you have to test it yourself.07:05
lpappbut then do not expect others will trust your saying either.07:05
bluelightninglpapp: you're making out that this is simple and testing on one piece of hardware is enough, sorry but it just isn't07:06
lpappbluelightning: no, you are totally disregarding any prior history even though it is mentiond several times.07:06
bluelightninglpapp: 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
lpappwhat 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!> has joined #yocto07:07
lpappsgw_: I will repeat the gazillionth time for last:07:08
lpappothers wrote it can be removed and only updated because it has been tested and works.07:08
lpappsgw_: if you do not trust others, you will have to test everything yourself, and you will slow the project significantly.07:08
lpappanyway, it is your call... if you do not trust the people, you do not.07:09
lpappnot 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
lpappreally, 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 versions07:10
lpappwhen I update it without deleting, I am offended.07:10
lpappwhen I please people, I am insultd.07:10
lpappwell, I do not need this.07:10
lpappreject 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 patch07:11
lpappso far both of my ways were offended ... what the heck can I do more07:11
lpappnothing, if people do not like me, they do not like me.07:11
erboit feels like this discussion is getting a little more "heated" then neccessary07:12
erbonobody is out to insult the other07:12
lpappsgw_: just tell me, lpapp we do not accept patches from you.07:13
lpappand I do not waste my time to try to hlep.07:13
lpapperbo: 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
lpappsgw_: this topic is way beyond the technical aspects07:17
lpappsgw_: 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
lpappit *is* tested07:18
lpappyou 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 times07:19
erbolpapp: but do you really think that the intention was to insult?07:19
lpapperbo: whether it was or not, it is what it is.07:20
tflpapp: there has been nothing insulting said ... yet07:20
lpappin 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_worksgw_: I'm unsure I found a bug wrt sstate packing relative symlinks. RP usually touches this class. Any python specialist around?07:21
lpappwhat can *anyone* do more?07:22
*** ericben <ericben!> has quit IRC07:22
lpappI submitted a, people argued*07:22
*** rikroled <rikroled!~tbn@> has joined #yocto07:22
lpapptf: in your opinion...07:23
ant_worklpapp: I've seen you did quickly fix the stunnel recipe. good07:25
lpappant_work: ?07:26
ant_workEXTRA_OECONF += "--with-ssl='${STAGING_INCDIR}' --disable-fips07:27
*** JaMa <JaMa!> has joined #yocto07:27
ant_workhi JaMa07:27
lpappant_work: syntax error07:28
lpappJaMa: have you seen my email07:28
ant_workargh, I did not even try to build, thinking it was already fixed :/07:28
lpappabout the qt5 license errors07:29
lpappant_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_workoh, right. c&p07:29
lpappant_work: still not sure it is the perfect way to build it, but it is building now at lesat.07:29
*** melonipoika_ <melonipoika_!> has joined #yocto07:29
*** melonipoika <melonipoika!> has quit IRC07: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
lpappsgw_: I am not interested anymore.07:31
lpappsgw_: I have better things to do than wasting my time for going nowhere arguing with contributions.07:31
ant_workJaMa: 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
lpappJaMa: meta-qt5 master head is still broken?07:33
lpappor why am I getting those errors?07:33
RPant_work: I suspect you're calling the class incorrectly, probably an extra "/" somewhere there shouldn't be one07:35
ant_workhi RP07:35
RPant_work: I'd be surprised if we hadn't noticed that problem for as long07:36
ant_workI checked the log.do_populate_sstate with debug07:36
ant_workthere it needs a ../more07:36
ant_workI'm sorry I don't have the buildsystem here...07:36
ant_workrP.. err.. log.do_populate_sysroot ofc07:37
RPant_work: which recipe an was this with master?07:38
ant_workfresh pull after your gcc changes07:38
ant_worknote that the paths in the ipk package are ok (hardcoded)07:38
RPant_work: I've not merged those yet?07:38
RPant_work: which recipe are you building?07:39
ant_workit's klibc07:39
RPant_work: ok, can you reproduce this with something in core?07:39
ant_workI tested eglibc-initial07:39
ant_workit's a bit different but packages the symlinks to asm asm-generic and linux as well07:40
ant_workoh, RP, .. and there is a slash too much in the expanded sstate paths, i.e. ../../../..//sysroots/ blah07:41
vickytf: I did "bitbake image" that also results the same07:41
*** sameo <sameo!samuel@nat/intel/x-hyfdlkgbghsvcudy> has joined #yocto07:42
ant_workRP: this second issue is maybe  0109a3623a19f9ae289952a4f054e53c3eca4eaa07:42
ant_workbut let's it for afterwards07:43
tfvicky: are the modules you want getting packaged?07:43
vickyNo. I want getting them installed into images07:44
tfvicky: I get that, but are the packages getting generated (the ipk, rpm, or whatever you are using)?07:44
tfyou can check by looking into the tmp/deploy/<pkgfmt>/<platform> directory07:45
RPant_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_workRP: have you checked the number of ../ iterations in the logs?07:48
RPant_work: I checked in the sysroot whether the right files were created07:49
ant_workRP: somehow klibc fails without the patch and eglibc-initial did not fail after the patch07:49
ant_workRP: I get broken symlinks after build from sstate, that's how I found it07:51
RPant_work: I'm now confused. You're saying it breaks after the patch in klibc ?07:51
ant_worknothing breaks07:52
ant_workklibc breaks without07:52
RPant_work: oh, the patch you mean your patch07:52
ant_workyes, sorry07:52
ant_workwe just set KLIBCKERNELSRC=${STAGING_DIR_TARGET}${exec_prefix}07:52
RPant_work: when did it start breaking?07:52
ant_workJaMa's autobuilder discovered it07:53
ant_workat least 3 months ago07:55
ant_workinitially there were other issues, patched07:55
ant_workthen strange failures due to broken /asm /asm-generic and /linux symlinks to linux-libc-headers(-dev)07:56
ant_workhonestly I never reproduced those on my host...07:56
ant_workbut I do see the broken symlinks after klibc is extracted from sstate07:56
RPant_work: which links are broken exactly?07:57
ant_workasm asm-generic linux07:57
Net147no 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 update07:59
Net147I am thinking in maybe exclude_list is uninitialized?08:01
ant_workRP: 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 bad08:02
tfNet147: check if the struct is zeroed on allocation or not08:04
*** swex__ <swex__!~swex@> has quit IRC08:04
RPant_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-initial08:04
*** swex__ <swex__!~swex@> has joined #yocto08:05
ant_workstrangely not...I did rebuild it...08:05
RPant_work: it would only break when installed from sstate08:06
ant_workbut pls add debug and check the do_populate_sysroot messages08:06
RPant_work: ah, and eglibc-initial is a bad example since it recreates its symlink (see
RPIt does this since the symlinks exit the sysroot and re-enter which breaks when you change machines08:07
ant_workthere are not many recipes packaging symlinks to linux-libc-headers-dev08:08
jackmitchelllpapp: 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 core08:09
lpappjackmitchell: I removed the other versions as requested.08:09
lpappjackmitchell: but again, I do not care anymore. I withdrew it08:10
jackmitchellhowever, I don't answer when QA goes pear shaped ;)08:10
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto08:11
RPant_work: ok, this is not due to a length issue08:11
*** dany <dany!> has quit IRC08:11
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:12
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC08:12
RPant_work: it breaks since you exit the sysroot and re-enter it08:12
*** dany <dany!~Thunderbi@> has joined #yocto08:13
lpappjackmitchell: means?08:16
RPant_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 tune08:16
Net147tf: doesn't seem to be zeroed at all08:17
ant_workwell, each has its /sysroot/foo isn't?08:17
*** slaine <slaine!~slaine@> has joined #yocto08:18
jackmitchelllpapp: 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 freeze08:20
jackmitchellso I'm maybe not quite as critical ;)08:20
*** JimBaxter <JimBaxter!> has joined #yocto08:22
tfNet147: I think you are right, the struct is statically allocated, and there is no memset, afaict08:23
ant_workRP: all the path substitutions  done in sstate are referring to dirs under /sysroot/qemuarm. Not in sysroot/armv5-...08:23
RPant_work: you are right, there is something wrong with the symlink handling. I can only assume we don't have any packages making absolute symlinks08:24
JaMalpapp: meta-qt5/master doesn't have your broken commit anymore, so no, it's not broken08:24
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto08:25
RPant_work: In fact these symlinks are broken anyway as they'd not work in any klibc-dev package on target08:25
lpappJaMa: it is not related to my commit in any way possible.08:25
lpappJaMa: it is master which is broken actually08:25
lpappqtserialport *is* not in charge of setting generic qt5 license stuff.. it should only set its own08:25
ant_workRP: once fixed they work because on target we have linux-libc-headers (dependency of klibc)08:26
ant_worklinux-libc-headers-dev is the package providing those exactly08:26
RPant_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-generic08:27
ant_workRP: 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
RPant_work: we don't fix up absolute symlinks in the .ipk08:27
JaMalpapp: yes it should set correct one, but it doesn't so it's qtserialport fault08:28
JaMalpapp: 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 correctly08:29
JaMa this is the fix08:30
JaMaant_work: I haven't seen it yet, but good work hunting that issues, thanks!08:31
lpappJaMa: I have no any idea what you mean.08:32
lpappit worked properly last time, and setting the checksum is explicitly not the task for qtserialport as no other recipes do so either.08:32
JaMathat isn't correct08:33
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC08:34
lpappJaMa: you might wanna check qtsensors then.08:34
lpappyou might be surprised.08:34
lpappor qtjsbackend, etc.08:35
Net147tf: okay. I have patched it. will test if it fixes and submit patch within an hour or so.08:35
lpappactually, even qtdeclarative. Yeah, none of those is really setting the license thingie.08:35
*** honschu <honschu!> has joined #yocto08:36
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto08:36
*** Net147 <Net147!> has quit IRC08:36
JaMalpapp: because they have the same as default value, qtserialport does not08:36
lpappJaMa: ?08:37
lpappit should have no any difference.08:37
lpappperhaps I kinda know it as the qtserialport maintainer. :)08:38
lpappI copied the same stuff from the rest of qtbase.08:38
lpappso if there is any difference in openembedded, it is a bug in openembedded.08:39
JaMaI don't have time to teach you to compare 2 files and this isn't right channel to do it, sorry08:40
*** dany <dany!~Thunderbi@> has quit IRC08:43
RPant_work: that code is just completely broken :/08:44
RPIt happens to work for one particular directory level08:44
*** blitz00_ <blitz00_!stefans@nat/intel/x-auuzqpauluvztdbv> has joined #yocto08:45
ant_workRP: ah, see, I was under sysroot-destdir/lib/klibc/include as pwd08:46
lpappJaMa: there is no any need to compare and teach that, as you are wrong.08:46
*** dany <dany!~Thunderbi@> has joined #yocto08:46
lpappopen up the qtsensors, qtdeclarative, etc files and tell others where you find license information.08:46
RPant_work: klibc is broken as well mind ;-)08:47
ant_workyes..if as you say the path in the ipk are not relative...08:47
*** mitz_ <mitz_!> has quit IRC08:48
lpappcan anyone see what JaMa means by having license checksums in this and similar files?
JaMalpapp: sorry I'm going ot ignore you again, because this is waste of my time08:48
*** Anusko <Anusko!~anusko@> has quit IRC08:48
lpappnice maintainer behavior... ignoring people asking for clarification ...08:49
*** Anusko <Anusko!~anusko@> has joined #yocto08:49
lpappanyone, can anyone else see what JaMa means? He is not willing to clarify it.08:49
*** mitz_ <mitz_!> has joined #yocto08:50
JaMathis 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 you08:50
*** belen <belen!Adium@nat/intel/x-bgyncwiuoedmdmhb> has joined #yocto08:50
JaMalpapp: learn to use bitbake -e and you'll find where they get LIC_FILES_CHKSUM08:51
ant_workRP: imagine that right those days thers is an hot topit like [klibc] Build problems: klibc with Linux 3.10.708:51
lpappJaMa: it is a different layer than bitbake -e08:51
*** dany <dany!~Thunderbi@> has quit IRC08:54
lpappJaMa: I think I found the main reason for it.08:57
lpappQtSerialPort is developed by me and a russian guy, and we discarded the custom Digia stuff from the license headers.08:57
JaMaso you finally learned to compare 2 files, good08:58
lpappno, I finally found the reason for an obscure issue.08:58
JaMaand it cost me 20 minutes and ruined breakfast08:58
lpappyou are very lucky a very obscure issue is figured out in 20 minutes.08:59
lpapppeople occasionally spend weeks with such issues.08:59
JaMait's problem for 1 minute if you just diff the files as I said before09:00
erenJaMa: relax. If you were here in Passau I would like to order you a weissbier to make you calm :)09:00
JaMaeren: :)09:00
erenJaMa: are there any somewhat mechanical work (like PKGCONFIG variables) left? It seems that newbies can handle the job09:02
ant_workRP: great, thx09:02
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto09:02
RPant_work: I've mailed it out09:02
RPant_work: quite amazing how broken that code was09:02
JaMaeren: yes, many, but sometimes PACKAGECONFIG variables aren't so mechanical09:02
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto09:03
JaMaeren: there is list of issues in "State of bitbake world" thread if you know about any newbie willing to help09:03
erenwell, I am09:03
*** florian_kc is now known as florian09:03
erenI am a little done with ALIX3D3 BSP, I guess I can do some packaging work09:04
BCMMJaMa: where is this list of issues?09:05
JaMaeren: BCMM:
lpappant_work: the devs were asking how to improve the build system for stunnel09:07
erenthanks, and the problem is which of these were fixed09:08
lpappant_work: I guess the improvement would be if they did not depend on with-ssl.09:08
erenI guess there is no list for it? I will simply look at master commits09:08
lpappyocto usually uses the prefix stuff for the autotools configure?09:08
JaMaeren: 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_workRP: I'll try the patch to the class and regarding klibc well, I'm still confused but I see the probable issue09:09
JaMaI'll send updated list in 20hours or so, new build is running since yesterday09:09
*** Net147 <Net147!> has joined #yocto09:09
ant_workRP: +export prefix      = $(INST)09:10
BCMMJaMa: i'm afraid i just wanted to read it in case it contained stuff i should know to use it09:10
ant_workRP: -export prefix      = /usr09:10
BCMMJaMa: i'm very unfamiliar with the project at the moment09:10
ant_workRP: ant for the lib  export INST = "${D}"09:10
erenJaMa: okkie, I will look at the available configuration option, and disable/enable them with PACKAGECONFIG09:10
JaMaeren: thanks a lot, you can see many examples from last patchsets I've sent09:11
erenyep, most of them are quite straightforward09:11
ant_workRP: "INSTALLROOT is some sort of DESTDIR: it’s a præfix only present09:11
ant_workat *file installation* time but n̲o̲t̲ at runtime."09:11
JaMaeren: small advice: it's good to start with failing recipes (min builds)09:11
ant_workRP: so the puzzle is to combine prefix and INSTALLROOT09:12
*** dany <dany!> has joined #yocto09:12
erenJaMa: oh, I was going to start from this file:
*** tanamo <tanamo!cb7dac02@gateway/web/freenode/ip.> has quit IRC09:12
JaMaeren: 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 later09:13
JaMaeren: you can start from dependency-changes.warn but it's possible that it doesn't contain complete list, because some deps weren't built09:14
erenJaMa: okkie, OE-Core with master branch. I will build core-image-minimal for qemu8609:14
erenwith distro set to poky?09:14
erenah no, you use DISTRO_VERSION    = "oe-core.0"09:15
JaMaeren: I use distro-less config, but most of these dependency issues aren't DISTRO specific09:15
JaMaso you can use any distro you like to fix them09:15
JaMae.g. last time I was using distro without x11 DISTRO_FEATURE, so I've missed all these issues found now :)09:16
*** zecke <zecke!> has quit IRC09:17
*** AndersD <AndersD!> has joined #yocto09:23
*** AndersD is now known as Guest9610409:23
*** Guest96104 <Guest96104!> has quit IRC09:28
*** AndersD` <AndersD`!> has joined #yocto09:28
*** AndersD` <AndersD`!> has left #yocto09:28
*** AndersD` <AndersD`!> has joined #yocto09:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC09:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto09:31
*** ericben <ericben!> has joined #yocto09:35
*** jackmitchell <jackmitchell!~Thunderbi@> has left #yocto09:37
*** amarsman <amarsman!> has quit IRC09:45
lpappsgw_: my last try.. I spent one hour with u-boot update to figure out all the git shortcomings.09:48
lpappif 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 IRC09:54
*** bluelightning <bluelightning!~paul@> has joined #yocto09:56
*** bluelightning <bluelightning!~paul@> has quit IRC09:56
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:56
*** zecke <zecke!> has joined #yocto09:58
*** smartin_ <smartin_!> has joined #yocto10:01
*** smartin <smartin!~smartin@> has quit IRC10:02
*** panda84kde <panda84kde!> has joined #yocto10:07
-YoctoAutoBuilder- build #273 of nightly-x32 is complete: Success [build successful] Build details are at
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto10:15
BCMManybody else using the raspberry pi bsp?10:27
lpappBCMM: sure10:27
*** vicky <vicky!~vicky@> has quit IRC10:28
BCMMlpapp: 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
BCMMsince rpi-hwup-image is just "include recipes-core/images/" + kernel modules10:31
*** behanw <behanw!> has quit IRC10:34
*** Stygia <Stygia!> has joined #yocto10:39
Net147how would I keep debugging symbols when building native recipes?10:41
lpapphow often is the list updated?10:56
bluelightningthe recipe information for each layer is updated roughly every 3 hours11:00
bluelightningif you mean the list of layers, new layers must be added manually11:00
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC11:05
bluelightningbut anyone can submit a new layer, no login required11:05
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto11:08
BCMMis 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 fine11:11
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC11:14
BCMMjust adding LICENSE = "GPL" makes it say "Recipe file does not have license file information (LIC_FILES_CHKSUM)"11:17
bluelightningBCMM: this is an image recipe?11:17
bluelightningBCMM: it doesn't by any chance do "include ...." somewhere?11:17
BCMMbluelightning: yeah11:17
bluelightningright, that'll be the problem11:17
bluelightningthe include directive does not error out when the file doesn't exist11:18
bluelightningI guess in your case the file pointed to by the include directive can't be found, and that file would have contained LICENSE11:18
BCMMah, and if what i'm including is in a different layer, i need to put some sort of path in?11:18
bluelightningplus the "inherit image" if that's not specified in the recipe11:18
bluelightninghonestly, I'd suggest writing a proper image recipe that doesn't pull in stuff via "include..."11:19
bluelightningimage recipes are almost always trivial11:19
BCMMi 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 layer11:20
BCMMbluelightning: 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
bluelightningBCMM: there's
bluelightningBCMM: you can also have a look at the image recipes in the core (find meta -name "core-image*.bb")11:22
lpappit 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!> has joined #yocto11:33
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC11:33
lpapprburton: hmpf11:33
lpapprburton: ${COREBASE} -> you mentioned previously it is not used like that.11:34
lpappbut apparently, it is ?11:34
lpappbut also in a lot of recipes.11:35
lpappand classes.11:35
lpapperm... hmm ? bitbake core-image-minimal11:42
lpappUnable to find conf/bblayers.conf11:42
lpappBitBake must be run from within your build directory: /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build11:42
lpappI 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 IRC11:44
*** blitz00_ <blitz00_!stefans@nat/intel/x-auuzqpauluvztdbv> has quit IRC11:45
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has quit IRC11:45
lpappI tried to delete everything in the build folder, except local.conf but still getting that; so weird.11:47
mihailpapp: source oe-init-build-env again11:48
lpappmihai: tried that, too.11:48
erenlpapp: close the terminal session, re-open it, cd into that dir and source oe-init-build-env11:59
erenI experienced it even if bitbake directory is present12:00
lpappbitbake directory?12:00
-YoctoAutoBuilder- build #103 of minnow-lsb is complete: Success [build successful] Build details are at
lpappall I did to the previous working version, I tried to add a bblayer.conf sample to my layer.12:02
lpappto get that generated properly for . oe-s...12:02
lpapp. oe-init-build-env12:02
lpappso with my own bsp layer.12:03
mihailpapp: maybe you're missing conf/bblayers.conf, or you're using one from 1.4 with master, or from master with 1.412:04
lpappmihai: I am not missing it.12:05
mihairemove bblayers.conf and source again, that should recreate a valid one12:05
lpappmihai: that is what I did when got this.12:05
lpappI removed, I sourced the oe init, and then I tried to run bitbake core-image-minimal12:05
mihailpapp: you also have an unknown DISTRO set in local.conf, 'foo' according to your paste12:06
lpappmihai: yeah, not sure why.12:07
lpappI have not changed the distro name, whatsoever.12:07
lpappI only added an example bblayers.conf to the bsp/distro layer.12:07
lpappand fwiw, my sample is not taken into account.12:10
lpappthe bblayers.conf is still generated out of the yocto sample. Why? How can I override that?12:10
mihailpapp: it's generated only when it doesn't exist12:13
lpappyes, which should mean I should get it generated out of my layer when I remove.12:13
lpappbut it is generated out of the Yocto layer; so weird. Why is it like that?12:13
lpappanyone any idea how to debug the bblayers.conf generation issue?12:23
Guest37012can you print you bblayers.conf12:30
-YoctoAutoBuilder- build #233 of nightly-fsl-ppc is complete: Failure [failed Building Toolchain Images_1 Publishing Artifacts] Build details are at
*** mulhern <mulhern!> has quit IRC12:32
lpappGuest37012: ?12:32
lpappGuest37012: as I already wrote, it is the same as the meta-yocto stuff12:33
lpappexcept the COREBASE replacement with the actual path of course.12:33
lpappthe problem is clearly that it is missing my meta-foo line12:34
lpappif I add that manually, I am not getting the error.12:34
lpappso the question is: why cannot I override the meta-yocto sample with my own sample?12:34
*** behanw <behanw!> has joined #yocto12:34
lpappshouldn't that the be automatically happening?12:34
*** mulhern <mulhern!> has joined #yocto12:35
mihailpapp: yes, the setup script does that12:36
*** mulhern <mulhern!> has quit IRC12:37
lpappthen something is fishy.12:37
lpappare there e xamples out there with layers providing their sample on _top_ of meta-yocto, and _not_ without12:38
mihailpapp: you could override it with TEMPLATECONF=meta-foo/conf . where bblayers.conf.sample and local.conf.sample must exist12:38
lpapphow does oe decide which sample to take for the generation?12:38
mihailpapp: see scripts/oe-setup-builddir12:38
lpappit is hard coded if not specified12:39
lpappi.e. fall back to meta-yocto12:39
lpappso everyone who wanna have the own sample has to define it.12:40
lpappthat is why I asked for examples with other bsp layers12:40
* lpapp goes check meta-raspberry12:40
mihaiyou can use OECORELAYERCONF just for the bblayers conf sample12:40
lpappI would like to see what others use12:41
lpappso that I can just follow without reinventing my own way.12:41
lpappso the next step is to find an example out there.12:41
*** tomz <tomz!> has joined #yocto12:46
-YoctoAutoBuilder- build #259 of nightly-x86-64 is complete: Success [build successful] Build details are at
*** tomz is now known as Guest6260112:46
lpappmihai: do you know an example layer doing this?12:47
*** e8johan <e8johan!> has joined #yocto12:48
Guest37012silly question. But did you copy the new bblayer.conf file to build directory12:49
lpappGuest37012: ?12:49
Guest37012You created the bblayers.conf file from the sample one and you copied that to the build directory right12:50
lpappis there an openembedded lxr?12:50
lpappfor browsing recipe stuff easily with an indexer?12:50
mihailpapp: i'm not aware of any layers using that12:51
lpappGuest37012: no12:51
lpappGuest37012: I copied the meta-yocto sample, and I copied that to my layer12:51
lpappand I added one line containing the name of my layer.12:52
lpappmihai: -> OECORELAYERCONF is undocumented.12:53
lpappmihai: so is TEMPLATECONF12:54
lpapplooks like I need to create an issue on the tracker to improve those.12:54
Guest37012I copied the /meta-yocto/conf/bblayers.conf.sample to ./build/conf/bblayer.confg12:54
lpappit seems to be an essential feature.12:54
Guest37012and added my layer to that12:54
lpappGuest37012: huh, why would you do that ?12:54
lpappthat would epically fail on CI, and for others without manual intervention _everywhere_12:55
bluelightninglpapp: neither are variables in the same sense as variables listed in the reference12:56
lpappbluelightning: please, when you write such claims, write a full sentence containing the reasoning etc, not just statements.12:56
*** zeeblex <zeeblex!~apalalax@> has left #yocto12:57
lpappto avoid the useless "why?" iterations.12:57
Guest37012The bblayer.conf just defines the location of the stuff and you own layer .12:57
bluelightninglpapp: they aren't bitbake variables, they're environment vars used only in the setup script, I figured that would be pretty obvious12:57
lpappGuest37012: please read my comment on that carefully.12:57
Guest37012ok sorry I was only trying to help.12:57
lpappGuest37012: 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
lpappno doubt, but the point still has to be understood. ;-)12:58
*** mihai <mihai!~mihai@> has quit IRC12:58
lpappbluelightning: it is not "pretty obvious".12:58
StygiaHey 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!> has quit IRC12:58
lpappand it should *definitely* be in the layer creation documentation as it is a core fundation.12:59
lpappbluelightning: unless you tell me a better way.12:59
bluelightningStygia: openssl-misc is a package rather than a build-time target... "openssl" is the build time target12:59
erboStygia: the openssl recipe should generate the openssl-misc package (I think)12:59
lpappotherwise I am tempted to stay it is a blocker for people as they cannot guess what needs to be done for this.12:59
erboStygia: there's a difference between packages and recipes, even though they often have a one 2 one mapping13:00
Stygiabluelightning, 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
StygiaAlthough it is mentioned in the recipe in FILES_${PN}-misc13:00
lpappalso, can anyone please let me know how to create an own sample to just work13:01
erboStygia: you image need to install openssl-misc13:01
lpappthere 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
lpappthis is now blocking me.13:01
bluelightningStygia: 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
bluelightninglpapp: typically people do not do what you're trying to do I guess13:01
* lpapp is go to create a bugreport13:02
lpappbluelightning: actually developers suggested to do this.13:02
lpappthis is the correct way of creating an own layer.13:02
*** e8johan <e8johan!> has quit IRC13:02
*** challinan <challinan!> has quit IRC13:02
Stygiaerbo, 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
bluelightninglpapp: it's not related to creating your own layer13:03
erboStygia: 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 image13:03
Stygiaerbo, Yes, sorry, I missed his comemnt.13:03
Stygia*comment. Saw it just now, I'll try that.13:03
StygiaThanks. :)13:03
*** challinan <challinan!> has joined #yocto13:03
erbonp :)13:04
bluelightninglpapp: 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 thing13:04
lpappbluelightning: no13:04
lpappbluelightning: it is related to layer creation13:04
bluelightninglpapp: since I've never had to do what you're doing and have created many layers, perhaps you would care to explain then13:04
*** Derzzle <Derzzle!~Derzzle@> has joined #yocto13:05
lpappbluelightning: I already did above several times.13:05
lpappperhaps you would care to read then.13:05
erbolpapp: you come on as quite aggressive in you communication style13:05
*** Derzzle <Derzzle!~Derzzle@> has quit IRC13:06
erenJaMa: mpg123 error is caused by default distro features. Something strange is going on13:07
Stygialpapp, 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
lpapperbo: I think the same about several people in here without mentioning such personal stuff explicitly.13:07
Stygialpapp, I suspect you would fin it over at ##perl13:08
lpapperbo: so please... be civil.13:08
eren${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', '--with-default-audio=pulse', '', d)} \13:08
lpappand get back on track with the technical stuff.13:08
erenthese should be mutually exclusive13:08
*** Derzzle <Derzzle!~Derzzle@> has joined #yocto13:09
erbolpapp: I just want the channel to stay friendly13:09
lpapperbo: then be civil, and discuss technical stuff, not insulting others.13:10
lpappjust like on a normal channel ...13:10
erbolpapp: come on, that was not an insult13:10
lpappand do not start emotional wars when you know exactly many people jump on with different opinions.13:10
lpappstay on the technical stuff... and no, disagreeing is not agressive at all.13:10
yoctiBug 5043: normal, Undecided, ---, saul.wold, NEW , Extend the layer creation documentation with own bblayers sample creation13:10
erenJaMa: however, default distro vars as set in meta/conf/distro/include/ enable all the options. So, alsa and pulseaudio gets passed to mpg12313:11
lpappbluelightning: I hope that clarifies.13:11
erbolpapp: I'm not starting any emotional wars.13:11
erboanyway, have a nice weekend.. I think this is a good time for me to leave for the day13:12
tfalsa and pulse are not mutually exclusive13:12
lpapperbo: thanks, you too.13:12
JaMaeren: I think best course of action is to convert the options to PACKAGECONFIGs and then use DISTRO_FEATURES only to select default PACKAGECONFIG13:12
JaMaeren: and take pulseaudio to have precedence if both are enalbed13:13
Stygiatf, On an unrelated note, what, they aren't? Doesn't pulse implement/handle the alsa stuff if its there?13:13
JaMae.g. PACKAGECONFIG_ALSA = "${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}"13:13
Stygiatf, How would it work having two sound servers at once? I have pulse (on debian) and assumed it just handled all the stuff.p13:13
JaMaPACKAGECONFIG = "${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', '--with-default-audio=pulse', '${PACKAGECONFIG_ALSA}', d)}13:14
Stygiatf, ... obviously not your job to explain that to me, heh, I'm just curious to understand things like this.13:14
tfStygia: see
JaMaor of course if --with-default-audio allows multiple options you can pass them through another variable13:16
Stygiatf, Fair enough. :)13:16
JaMatf: but we were talking about alsa/pulse support in mpg123, not alsa/pulse in general13:16
tfJaMa, sure, but the distro feature is broader than mpg12313:17
tfJaMa: as you suggested, if both are present in the distro_features, give precendence to pulse13:17
tfI think that's the right solution13:18
JaMaI think this "15:09:27 < eren> these should be mutually exclusive" was about mutually exclusive configure options, not making DISTRO_FEATURES to be exclusive13:18
tfok, my bad13:18
erenJaMa: tf right13:19
erenJaMa: ah, I see that you used that technique in sox package13:19
erenok, we are enabling PACKAGECONFIG ??= accordingly to distro features13:19
erenand write PACKAGECONFIG[alsa] = ... to enable configuration and dependencies13:20
Net147JaMa: I have recipes for xf86-video-ati and xf86-video-nouveau. do these look ok to you?
erenJaMa: the above PACKAGECONFIG fragments you proposed didn't make sense for me :/13:21
*** ant_work <ant_work!> has quit IRC13:26
JaMaNet147: just 2 nitpicks: 1) is LICENSE set by 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!> has joined #yocto13:27
JaMaNet147: otherwise definitely good enough for ML review :) I wonder if rburton had something with nouveau when adding genericx8613:28
erenwhat's the difference between ${@base_contains(...)} and ${@bb.utils.contains(...)} ?13:28
Net147JaMa: it's for meta-openembedded not oe-core13:29
Net147JaMa: though I wonder if it's feasible to support them in oe-core in the future13:29
bluelightningeren: interesting, I was not aware of that apparent duplication13:29
JaMaeren: there are actually 3 "contains" variants13:29
JaMabase_contains (calls oe.utils.contains)13:29
JaMabb.utils.contains (same code as oe.utils.contains)13:29
JaMacopy&pasted from
yoctiBug 3890: enhancement, Medium, 1.4, richard.purdie, VERIFIED FIXED, @contains does not create vardep automatically13:30
bluelightningeren: the functions are exactly the same, FWIW13:30
erenstrange :)13:30
erenJaMa: I handled PACKAGECONFIG with your code snippet13:30
erentrying the build13:30
JaMaeren: great13:30
bluelightningeren: 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 OE13:30
lpappbluelightning: you still did not get the idea?13:31
bluelightninglpapp: I've read the bug report13:31
lpappbluelightning: "So for layers, you can provide a bblayers.conf.sample in your distro.  That13:31
lpappuses ##COREBASE## which is substituted during oe-init-build-env with the13:32
lpappbluelightning: from rburton.13:32
lpappcorrect paths.13:32
lpappIn bblayers.conf you can't use ${COREBASE} as that's provided by the meta13:32
lpapplayer, which hasn't been parsed yet."13:32
lpappso I just followed what he wrote, pretty much.13:32
* lpapp feels again like a hated person. :)13:32
erenbluelightning: thanks. is it safe to continue with base_contains, or switch to bb.utils.contains?13:32
erenis there a plan to remove duplicates?13:32
Net147JaMa: as for the license, i'm not sure what MIT-X really means13:32
lpappwhen I have ideas, they are rejected, when I follow what others write, I am rejected. :)13:32
bluelightningeren: 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
lpappso back to the problem at hand, does anyone know what the proper way is to add the layer bblayers.conf sample?13:33
JaMaNet147: 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 license13:33
erenso, what's the "d" at the end of the function call?13:33
erenfor example: "${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}"13:33
bluelightninglpapp: I don't think there is a well-defined method, because most people haven't tended to do that in the past AFAIK13:34
JaMaeren: "data" variable13:34
bluelightningeren: 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
lpappbluelightning: perhaps not because this feature is missng13:34
lpappmissing*, or was undocumented.13:35
lpappthat is a good reason why people found workarounds.13:35
Net147JaMa: there is only MIT license in common-licenses13:35
lpappand got used to that, but systematically, it is not good.13:35
JaMaNet147: meta/conf/licenses.conf:SPDXLICENSEMAP[MIT-X] = "MIT"13:35
erenbluelightning: ah, then while bitbake is parsing all the stuff, it fills datastore "d"13:36
bluelightninglpapp: I think most people are comfortable creating/modifying their own bblayers.conf or they have scripts that do that already13:36
lpappbluelightning: do you see how problematic that is architecturally?13:36
bluelightninglpapp: not that it wouldn't be worth improving this13:36
bluelightninglpapp: not really, no13:36
lpapp"most people do the custom stuff on their own"13:37
lpappyou do not see this a problem, really?13:37
bluelightningwe're not talking about something huge that everyone has to write13:37
lpappit does not matter really how much13:37
bluelightningit's a small config file that the user just adds one or two lines to13:37
lpappif it is one line, it is 1000 lines for 1000 people.13:37
lpappif everyone only writes once.13:37
lpappcompared to be written once.13:37
bluelightningI said already, it would be worth improving, but I think you make it out to be more of a problem than it is13:38
lpappnot to mention how error prone when forgotten ... I had to understand the issue for hours if not days.13:38
lpappthe 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
lpappI really do not see why everyone would write all this manually when it can be automated pretty easily with a minor documentation.13:39
lpappactually 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
lpapphow can you do a nice CI without it?13:41
lpappyou have to adjust your git hook or so.13:41
lpappand that is ... errr, painful when you do not even have access.13:41
bluelightningyou can put whatever you need into automated build scripts13:41
lpappsure, you would not need Yocto either.13:41
lpappyou could write your own script.13:42
bluelightningheh, because that's completely the same thing.13:42
lpappit is13:42
lpappYocto is getting features like this to make it handier.13:42
lpappthis is one of those building stones.13:42
erenoh, I added pulseaudio dependency and now there are extra 1500 tasks to do :)13:43
bluelightningI'm not blocking anything here13:43
Net147JaMa: looks somewhat like MIT license. and it's MIT license in other distributions. I sent to ML for review13:43
bluelightningjust saying, if you say you can't do anything without this feature, I think that's overstating the nature of the issue13:43
erengettext-native, util-linux, expat-native..13:43
JaMalpapp: 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
bluelightningthat's pretty much all I'm going to say about the matter as I have work to do this afternoon13:44
lpappbluelightning: to give another example, can you show me any small patch going in that could not be solved by the client?13:44
lpappJaMa: please focus on technical topics in a technical channel.13:45
lpappJaMa: 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!> has joined #yocto13:46
erenlpapp: well, I guess this is a technical channel where technical issues can be discussed13:46
*** sameo <sameo!samuel@nat/intel/x-hyfdlkgbghsvcudy> has quit IRC13:47
JaMalpapp: 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
lpapperen: yes, I agree.13:47
lpappJaMa: you were wrong there.13:47
lpappI described why... because you claimed that qtsensors and others have license files, meanwhile they do not.13:47
lpappcheck their recipes.13:48
JaMaI wrote their recipes FFS13:48
lpappthen why would you claim any comparison?13:48
lpappalso, check your comment before that ... it was not slightly rude about "teaching".13:48
erenlpapp: are you thinking of contributing to this project, in any way?13:49
*** e8johan <e8johan!> has quit IRC13:49
lpappit is not useful to tell a newcomer "I do not have time to teach you n00b"13:49
JaMabecause you incorrectly claimed that you as qtserialport maintainer are using exatly the same license files as other qt 5.1. modules13:49
lpapperen: I have done that.13:49
lpappJaMa: that was correct at the point of merge.13:49
JaMa10:39:58 < lpapp> I copied the same stuff from the rest of qtbase.13:49
lpappthat is correct.13:49
lpappand that is still correct.13:49
lpappperhaps this time you wanna know better than the author of the module?13:49
erenoh please, this is going really personal13:50
lpappthat is why I tried to mention several times already to get back to the technical stuff...13:50
JaMathat's why I said you should compare them..13:50
lpappJaMa: you said that for the recipes13:50
lpappat least that is how I got.13:50
lpappso perhaps you were unclear.13:51
lpappbut how is that my mistake? :)13:51
*** mebrown <mebrown!> has quit IRC13:51
lpappand you could have told me that what you wanted to compare as it was not clear to me.13:52
lpappI even told you I compared the recipes.13:52
lpappwhy 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
JaMawhy 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 recipe13:53
*** e8johan <e8johan!> has joined #yocto13:53
lpappand I am the aggressive, when you are taking such comments. :)13:53
lpappwell, to clarify the situation?13:53
lpappto avoid the misunderstanding ?13:53
lpappto avoid the frustration which you seem to get in?13:53
*** mebrown <mebrown!> has joined #yocto13:55
lpappin general, it is a good advice to be as verbose as possible, especially when talking to new people.13:55
lpappAlso, 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
lpappAlso, license files are not* (at least not in the Qt Project anyhow)13:56
erenbluelightning: I've requested wiki username and it seems that there is a review process13:57
lpappso for me with qt serialport maintainer hat, this was the natural context...13:57
bluelightningeren: we had a problem with spammers unfortunately :(13:58
erenbluelightning: ah I see, could you enable that if possible? :)13:58
erenI would like to add some keywords for pages to find easier13:58
erenI cannot, again, find your decent patch sending article13:58
bluelightningeren: hmm, I'm not sure if I have access to do that13:59
bluelightningeren: I think Jefro handles that stuff, I can certainly ping him when he comes online13:59
bluelightningeren: is it this one?
erenah yes14:00
lpappsgw_: any problem with the new u-boot version ?14:00
eren , this includes nice commit log reference14:01
erenlinking the articles would be useful14:01
lpappbluelightning: I do not have access to the CI server, so it is blocking as I wrote before.14:01
bluelightninglpapp: which CI server?14:01
bluelightninglpapp: 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
lpappno, we are not time millionaires. :)14:02
lpappI 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
lpappso what we are trying to solve is blocked either way.14:02
bluelightningto write a simple script to create the necessary configuration shouldn't require millions of anything...14:03
lpappyou might rethink that if you start thinking a bit out-of-the-box.14:03
*** alex_kag <alex_kag!~alex_kag@> has quit IRC14:04
lpappI know it is hard to drop the "got used to" hackarounds, but they dropping them are for good.14:04
lpappbut dropping*14:04
*** nitink <nitink!nitink@nat/intel/x-iynyedvfqqerjzfs> has quit IRC14:05
lpappwhat 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
bluelightningI didn't say it was too much14:07
lpapp+ many developers all around for sure.14:07
bluelightningin fact I said this could be improved14:07
lpappyeah, after a lot of arguing...14:08
lpappprobably because I mentioned rburton's name. :)14:08
bluelightningwell if we argue about who is arguing we'll be here all day14:08
JaMaI agree that there are a lot more important tasks for bluelightning and other developers to work on14:08
tfbluelightning: /ignore is such a nice feature of irc ...14:09
lpappbluelightning: no, I just feel that what I propose is dropped by default because I claim even if it makes sense like here.14:10
lpappand I would like to get rid of this atmosphere for once and all.14:10
*** AndersD` <AndersD`!> has quit IRC14:11
lpappJaMa: like mesa: inherit gettext ?14:12
JaMayes exactly like mesa: inherit gettext14:13
lpappyes, that is hit by so many people ...14:13
lpappwhen gettext is installed by default nowadays pretty much by everyone. :)14:13
lpappI guess different people have different priorities...14:14
JaMayes "bitbake mesa" failing every time when someone builds it in clean tmpdir is bad14:14
-YoctoAutoBuilder- build #262 of nightly-multilib is complete: Success [build successful] Build details are at
lpappexcept that people will not do that usually.14:15
lpappas they have images anyways, and it is very likely that something else pulls in.14:15
JaMayou would change your mind after seeing many random failures when building image or even world with few recipes missing or autodetecting dependencies14:16
lpappand how could it block anyone anyways?14:16
lpappyou can always install it14:17
lpappunlike a CI server access, etc.14:17
*** mihai <mihai!~mihai@> has joined #yocto14:17
JaMaand random failures are worse then writing one line in layer.conf14:17
lpappshow me random failures caused by this14:17
lpappat least 11 times in a team like in a 10-sized developer team + CI.14:17
JaMaread "State of bitbake world" e-mails I'm sending for last couple of months14:17
lpappwith limited access to make it harder.14:18
-YoctoAutoBuilder- build #274 of nightly-mips-lsb is complete: Success [build successful] Build details are at
lpappI would be very suprirsed if anyone here used "bitbake mesa" regularly in a fresh clean environment.14:18
lpappAlso, why would it be random failure?14:19
*** sameo <sameo!samuel@nat/intel/x-dxxxfwyilekalalw> has joined #yocto14:19
lpappyou get an error message at the gettext include.14:19
JaMaI'm surprised that people are using CI servers where they don't have any access..14:19
JaMalpapp: because sometimes gettext is built before mesa pulled by something else, sometimes it isn't14:19
lpappI do not think that is the case anywhere in the world.14:20
lpappso 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
JaMasorry but I don't have time for this discussion14:20
*** Net147 <Net147!> has quit IRC14:21
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto14:22
JaMathis channels should be about technical issues not your assumtions and surprises14:22
*** djszapi <djszapi!d42c13e4@gateway/web/freenode/ip.> has joined #yocto14:22
Crofton|workJaMa, he left14:22
djszapiCrofton|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|worklpapp_, I was just pointing out that he was speaking to no one, in case he missed the leave message14:24
*** e8johan <e8johan!> has quit IRC14:25
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has quit IRC14:25
lpapp_ok, thanks. :)14:25
*** sameo <sameo!samuel@nat/intel/x-dxxxfwyilekalalw> has quit IRC14: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 IRC14:28
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto14:28
lpapp_it would be nice to have something in the local.conf instead, for instance.14:29
lpapp_same limitation with OECORELAYERCONF14:30
*** e8johan <e8johan!> has joined #yocto14:30
bluelightninglocal.conf doesn't exist before the oe-init-build-env script is run...14:34
lpapp_that is fine14: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
*** B4gder <B4gder!~daniel@rockbox/developer/bagder> has quit IRC14:43
-YoctoAutoBuilder- build #260 of nightly-world is complete: Failure [failed Building Images] Build details are at
*** e8johan <e8johan!> has quit IRC14: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!> has joined #yocto14:51
otaviolpapp_: yes; I can give it a test14:55
otaviolpapp_: 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
otaviolpapp_: and did you check if beable, for example, keep working?14:56
lpapp_for my board, yes.14:56
otaviobeagle heh14:57
lpapp_of course. :)14:57
lpapp_no, I do not have a beagle here.14:57
otaviolpapp_: the fwutils issue is fixed?14:57
lpapp_otavio: yes, I deleted it. :D14: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
otaviolpapp_: fwutils is for use in target14:58
lpapp_yeah, I thought so. What exactly for though?14:59
*** andyross <andyross!> has joined #yocto15:00
otaviolpapp_: no15:01
otaviolpapp_: it is for host use15:01
lpapp_oh, I read host actually. :p15:01
otaviolpapp_: so you can check env and set env for it15:01
lpapp_I am blind.15:01
lpapp_anyway, I have not needed it to get an u-boot + linux kernel.15:02
otaviolpapp_: yse but for updating you need15:02
lpapp_otavio: updating what15:02
lpapp_you mean like over tftp?15:02
otaviolpapp_: I built it here and it built fine15:02
lpapp_with my previous change?15:02
otaviolpapp_: no; for updating u-boot version15: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
otaviolpapp_: the point is not for you. The point is for OE-Core. It is  wrong to not keep them in sync15:03
lpapp_it is kept in sync.15:03
lpapp_the old versions are preserved.15:03
otaviolpapp_: u-boot-fw-utils, u-boot-mkimage and u-boot ought to be same versions and provide same versions15: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
otaviolpapp_: 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
otaviolpapp_: 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
otaviolpapp_: Well; I won't ack it until fw-utils is done.15:06
lpapp_to avoid that nightmare.15:06
otaviolpapp_: 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
otaviolpapp_: I won't try it as I know it works. I use it in meta-fsl-arm15:07
lpapp_and for that matter constructivity ... you know... appreciation, and suggestion for improvements.15:07
otaviolpapp_: 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
otaviolpapp_: The patch is good. I checked15:07
lpapp_fw-utils will not get done.15:07
lpapp_testing != review15:08
*** fitzsim <fitzsim!~user@nat/cisco/x-vqtxcuxceuveugjj> has joined #yocto15:08
otaviolpapp_: 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
otaviolpapp_: :-)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 anyway15:09
otavioWell, 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 stuff15:09
lpapp_and even update over ftp15:09
lpapp_including u-boot.15:10
lpapp_to be honest I still do not get why anyone would need fw-utils. :D15:10
lpapp_I can update u-boot without it.15:11
lpapp_so what does it help with update again?15:11
otavioSo an image, change u-boot env, for example15:11
lpapp_you can change that fine without it, too.15:12
otavioReally? how?15:12
lpapp_two ways:15:12
lpapp_1) openocd15:13
lpapp_2) tftp15:13
otavioDid you read the word *image* ?15:13
otavioSo it is *build image time* change.15:13
otavioNot run time15:13
lpapp_that you can always do at build time.15:14
lpapp_of course.15:14
otavioHow? I mean /image/ not patching u-boot15:14
-YoctoAutoBuilder- build #262 of nightly-ppc is complete: Success [build successful] Build details are at
lpapp_you can always patch u-boot, and it is quite simple with .bbappend15:15
lpapp_as for the tool, sec.15:15
lpapp_otavio: the tool is called bitbake. ;-)15:26
*** alex_kag <alex_kag!~androirc@> has joined #yocto15:29
lpapp_or simply udev itself at runtime.15:29
*** slaine <slaine!~slaine@> has quit IRC15:34
*** Jefro <Jefro!> has joined #yocto15:40
*** rikroled <rikroled!~tbn@> has quit IRC15:43
*** hollisb <hollisb!> has joined #yocto15:50
*** zenlinux_ <zenlinux_!> has joined #yocto15:52
-YoctoAutoBuilder- build #261 of nightly-arm is complete: Success [build successful] Build details are at
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto15:58
*** lpapp_ <lpapp_!d42c13e4@gateway/web/freenode/ip.> has quit IRC15:58
lpappI wonder what might be the reason for a software to build as ELF32, and not ARM15:58
lpappit 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
frayARM should be ELF32.. but ARM -abi- adds additional expectations about ELF32, which often times firmware shouldn't be using15:59
frayno idea if you are building firmware though15:59
lpappok, it is x86, not arm16:00
fraythen is it simply using the wrong compiler?16:00
lpappwell, it has CC=gcc16:00
-YoctoAutoBuilder- build #256 of nightly-x86-64-lsb is complete: Success [build successful] Build details are at
lpappbut that should not be a problem as far as it is not recursive, right?16:00
frayya, wrong compiler, unless you are building a helper app16:00
lpappI have been told here that should not matter16:01
lpappas oe overrides that if not recursive.16:01
frayOE 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@> has joined #yocto16:01
lpappand it does not work even on my x86_64 fwiw.16:02
lpappand CC=gcc should.16:02
frayonly if the host/target happen to have compatible ABIs, libraries and libc versions would it perhaps work16:02
RPfray: we have -e in our make flags so our CC value overrides CC=gcc in the makefile16:02
JaMaanyone seen "include /absolute/path/" behaving like "require", parsing failing when the file doesn't exist?16:03
*** blitz00 <blitz00!stefans@nat/intel/x-bgpjbngcrmcnkoav> has joined #yocto16:03
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto16:03
frayRP, I've seen instances where makefiels ahve 'CC := gcc' where it hasn't overridden it..16:03
frayit's fairly rare these days, but it happens16:03
RPJaMa: no16:03
RPfray: probably not a top level makefile?16:03
fraydon't remember if it was a top level file or not16:03
*** alex_kag <alex_kag!~androirc@> has quit IRC16:04
*** _alex_kag_ is now known as alex_kag16:04
ndecRP: about make -e, .. do you know why we do MAKEFLAGS= too?16:04
ndecas a consequence the -e is not passed to recurive makefiles16:05
ndecany specific reason?16:05
RPndec: no, you'd have to ask someone from the start of the project like kergoth or pb_ over on #OE16:05
ndecok. thx16:07
lpappndec: please let me know if you figure out anything important about that. if I may ask.16:12
lpapprecursive stuff16:12
ndecah. sure.16:13
kergothndec: 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
kergothndec: but I regret including -e at all, better to be explicit with variable passing via EXTRA_OEMAKE=16:14
lpappfray: the right compiler is used for compilation.16:15
ndeckergoth: ok. i admit that my problem with that choice, is that I am integrating bad components, with wrongly writtent makefiles...16:18
lpapppeople should not write makefiles nowadays.16:18
kergothhighly recommend redefining EXTRA_OEMAKE to pass things in explicitly, and patch the makefiles to suck less16:18
ndecin our case the top level just 'recurse' and the sub makefile expects to set CFLAGS ;-)16:18
*** Anusko <Anusko!~anusko@> has quit IRC16:19
ndeclpapp: yeah, i know.. ;-)16:19
ndeci don't write makefile, but have to read and use them!16:19
*** Anusko <Anusko!~anusko@> has joined #yocto16:19
lpappyes, it is a non-rewarding job, I guess.16:19
lpappnot rewarding enough IMHO. :)16:20
RPndec: you can override the default16:20
ndeci know.16:20
ndecbut then i don't get the default CFLAGS from env ;-)16:21
*** sgw_ <sgw_!> has quit IRC16:27
*** sgw_ <sgw_!> has joined #yocto16:28
*** Jefro <Jefro!> has quit IRC16:28
abelloniotavio: I hope this time it will please you ;)16:30
kergothndec: EXTRA_OEMAKE = "'CC=${CC}' 'CFLAGS=${CFLAGS}'...." will do, or override it to remove the MAKEFLAGS=16:30
kergothndec: either should do16:31
kergothi'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 sense16:31
kergothbut either way will work :)16:31
ndechmm. 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 .thx16:32
JaMaRP: I've found the difference for relative/absolute path, it's in bitbake/lib/bb/parse/ resolve_file(fn, d)16:32
JaMaRP: when fn isn't abs, it uses which and returns IOError when it's not found, which is catched by calling handle function correctly16:33
JaMaRP: when it is abs, it just returns fn and OSError returned a bit later from bb.parse.mark_dependency(d, abs_fn) in BBHandler.py16:33
RPJaMa: so we need to trap that in the include case16:33
lpapphmm, so it is weird ...16:34
lpappI 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 that16:34
JaMaRP: I was thinking about returning IOError from resolve_file16:34
lpappwhy is it like that? The cwd is something else during the build or what?16:34
lpappneedless to say, the header included from the same folder should be found naturally.16:35
lpappah, it is included as <foo/baz.h>16:36
lpappthat is bizarro.16:36
ndecJaMa: '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
lpappso is that possible oe is trying to override this? CPPFLAGS = -I./ -m3216:37
JaMandec: can you share the log?16:37
lpapp(which is in the Makefile)16:37
lpappthat would explain the dropping of the include path in CWD.16:37
JaMandec: someone reported native qmake trying to load gui module, but IIRC it was building for him16:37
otavioabelloni: sorry by being picky ! :-)16:37
*** belen <belen!Adium@nat/intel/x-bgyncwiuoedmdmhb> has quit IRC16:37
lpappor if it is executed in the wrong directory.16:38
lpappabelloni: people are picky in this project... I think we just need to get used to it ... hard stuff to do so.16:38
lpappwhen you come from a pragmatic culture.16:38
RPJaMa: I don't quite follow :/16:39
bluelightninglpapp: if you think us picky, maybe you haven't tried sending anything to the kernel ;)16:39
RPJaMa: I see the code you mean but I don't understand the fix. Where is the exception caught in the include case?16:39
lpappbluelightning: I was writing kernel drivers for 1-2 years.16:39
lpappprofessionally in full time.16:39
lpappmaybe 2-3.16:39
lpapp(including security framework where people are notoriously picky)16:40
lpapphmm, 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
otaviolpapp: the fw-utils build failure makes sense indeed16:42
otaviolpapp: I am fixing it and will send a full u-boot upgrade when done16:42
ndeclpapp: check the run.do_compile.<pid> script to see all the variables that OE sets before calling make16:43
abelloniotavio: it is actually a good thing. The series are quite better now.16:45
lpappotavio: heh, so no credit for me at all for the many days work16:45
lpappI think it is over a month now. :)16:45
lpappthat would be lovely.16:45
abelloniotavio: it would be good if it could make it for 1.5 though16:45
otaviolpapp: I will add your credit in the commit log16:45
otavioabelloni: fsl-arm stuff?16:45
lpappotavio: it is not the same but anyway16:45
abelloniyeah, fsl-arm16:46
lpappthe real open source way would be to extend my work.16:46
lpappnot redoing stuff and put someone into the "brackets".16:46
*** walters <walters!> has quit IRC16:47
*** cetola <cetola!> has joined #yocto16:48
JaMaRP: I've sent RFC with patch to bitbake-devel16:48
lpappotavio: 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.l16:48
lpappnot to miss the freeze.16:48
JaMaRP: in both cases it should be caught in
otavioabelloni: it should be fine I guess16:48
lpappndec: ok, I will check that.16:48
lpappndec: NOTE: make -j 8 -e MAKEFLAGS= -C foo, that is all.16:50
lpappndec: does that mean CPPFLAGS is dropped?16:50
JaMaRP: 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 for it to fail16:50
lpappsgw_: have you tested the u-boot change btw? Please do not miss the freeze ...16:51
RPJaMa: shouldn't we change it to catch both OSError and IOError?16:51
*** cetola <cetola!> has left #yocto16:52
JaMaRP: it looks cleaner to me, to let resolve_file doing the same when resolving non-existent file16:53
*** galak <galak!> has joined #yocto16:53
JaMaRP: and resolve_file is used only from 2 places ConfHandler and BBHandler, so it should be quite safe16:54
lpappis there a way to tell OE/Bitbake/Yocto/whatever_the_term_is to respect the CPPFLAGS?16:54
lpappit should really never ever drop it.16:54
lpappit is set for a reason.16:54
RPJaMa: I suspect we should add OSError to include() as well, for boiler plate16:57
RP(er, to make the code robust)16:57
RPJaMa: please send a patch though16:57
JaMaOK, I'll send v2 which will also add OSError16:57
ndeclpapp: 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
lpappndec: then why don't I see that include path in the compilation line even though I see without Yocto?16:59
ndeci don't know ;-)16:59
lpappexactly, so something is fishy around Yocto17:00
*** galak <galak!> has quit IRC17:00
lpappand I would like to understand what.17:00
ndecdoes your makefile use CPPFLAGS in the command line?17:00
*** cetola <cetola!> has joined #yocto17:02
ndecwell, you should print CPPFLAGS to see its value, it might give some hints.17:03
*** cetola <cetola!> has quit IRC17:03
*** cetola <cetola!> has joined #yocto17:03
lpappndec: print where?17:05
ndecfrom the makefil17:05
lpappnot sure I follow.17:06
ndecyou 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
lpappI still do not follow you17:08
lpapp1) Print where 2) Why print inside the makefile 3) how.17:08
ndececho ${CPPFLAGS}17:09
lpappit will print out what is internally there I believe.17:09
lpappthat will not still tell us why it is not passed to the compiler though.17:09
ndecif you do that from the Makefile, it will print its value.17:09
lpappI have no idea where to put or/and how it would be different to what CPPFLAGS is set in there.17:10
lpappalso, makefile will not help anyway as redownload will drop it.17:11
lpappyeah, nothing is printed as I expected.17:12
*** eren <eren!~eren@unaffiliated/eren> has quit IRC17:13
lpappI put a line like that after all: foo, but nothing is printed.17:14
lpappanything else I can try?17:14
* lpapp remembers who painful it is to write software without cmake17:15
ndecwhat do you mean nothing is printed? if you added an 'echo' it is printed somewhere17:15
lpappnope, it is not.17:16
erboyou can always do echo "HERECOMESCPPFLAGS" before the echo ${CPPFLAGS} to make it easy to find it in the log17:16
lpappI already did that... so, nothing is printed.17:16
lpappany further clue?17:16
*** zecke <zecke!> has quit IRC17:16
ndecyou checked the log?17:17
ndecdid the task run?17:17
ndecif you had compiled already, it wouldn't run again.17:18
ndecsince it doesn't know you changed the makefile17:18
ndecbitbake -fc compile <recipe>17:18
ndecwould force it17:18
lpappdid not help... it is not printed.17:19
erbobut the "herecomes" part is printed?17:19
ndecand you put in the 'echo' in a target which is executed by the makefile?17:20
lpappndec: I have put it as I said.17:20
lpappndec: all: lib echo "TEST THIS STUFF: ${CPPFLAGS}"17:21
ndecyou said 'i put a line after all' ;-) now i get it.17:21
lpappanyway, it is not printed.17:21
* lpapp cannot hate Makefiles more and the people using it when cmake has been existing for a decade now17:22
*** Anusko <Anusko!~anusko@> has quit IRC17:22
-YoctoAutoBuilder- build #265 of nightly-x86-lsb is complete: Success [build successful] Build details are at
ndecthat's weird. i just did the same thing here. and my echo is printed.17:24
lpappright, so any idea?17:24
ndecin log.do_compile17:24
lpappso this is an unsolvable issue? :D17:25
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto17:25
ndecnothing is unsolvable.17:26
lpappwell, ideas are welcome.17:26
lpapphow to tell oe not to drop cppflags17:26
*** panda84kde <panda84kde!> has quit IRC17:27
*** pidge <pidge!> has joined #yocto17:29
lpappthe yocto reference manual has no entry about CPPFLAGS.17:30
lpappthe project development manual either.17:30
lpappLooks like another important missing documentation.17:30
*** Bhawna <Bhawna!~arunkr24@> has joined #yocto17:30
ndeclpapp: 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
lpappndec: :(17:33
*** ka6sox is now known as ka6sox-away17:33
lpappso, I guess it is a blocker again17:33
lpappnot much I can do without documentation.17:33
lpappI will just make a report to clarify this behavior and possible solutions in the documentation.17:33
BhawnaI am a newbie from India... and beggining with the yocto project17:35
ndeclpapp: ok,it's set in bitbake.conf, so in the 'env', so with -e it will be ignored in the makefile.17:35
ndecthere must be a reason.17:35
ndecbut i don't know.17:36
Bhawnai have created my Git repo of Poky, and have till now followed the instructions in the quickstart guide17:36
Bhawnathe problem comes when i invoke the command17:36
ndeclpapp: temp workaround set CPPFLAGS in the .bb file17:36
bluelightningprobably because most upstream makefiles set inappropriate values for cross-compilation for things such as CPPFLAGS and CFLAGS17:36
lpappBhawna: which command?17:36
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC17:36
lpappbluelightning: why punish people who do set correct values?17:37
lpappndec: I am creating a bugreport anyway17:37
lpappndec: this should be documented.17:37
bluelightninglpapp: I'm not intimately familiar with the whys and wherefores, just pointing out a possible explanation17:37
Bhawnabitbake -k core-image-sato17:37
*** davest <davest!Adium@nat/intel/x-khipcgupybapjkoi> has joined #yocto17:38
lpappBhawna: what problem?17:38
*** sgw_ <sgw_!> has quit IRC17:38
Bhawnai would post the error message here17:38
ndecuse pastebin.17:38
BhawnaERROR: Error parsing configuration files17:38
BhawnaTraceback (most recent call last):17:39
Bhawna File "/home/temp/Yocto/poky/bitbake/lib/bb/", line 221, in CookerDataBuilder.parseBaseConfiguration():17:39
Bhawna >            self.parseConfigurationFiles(self.prefiles, self.postfiles)17:39
lpappBhawna: paste.kde.org17:39
*** simar_ <simar_!~simar@> has joined #yocto17:41
lpappndec: EXTRA_OEMAKE will not work?17:41
lpappCPPFLAGS=${CPPFLAGS} ?17:41
lpappmihai: pong17:41
ndecyes, it should.17:41
mihailpapp: thanks :)17:41
Bhawnalpapp: thanks, i didnt know such a thing existed17:42
*** simar_ is now known as su17:42
lpappBhawna: no worries.. do you have proper permissions?17:42
*** su is now known as insmod17:42
*** insmod <insmod!~simar@> has left #yocto17:43
Bhawnayeah... i ran the Source command as root, but after that i did a Chmod on the Parent Directory17:43
lpappbluelightning: ndec
yoctiBug 5046: normal, Undecided, ---, scott.m.rifenbark, NEW , Document that CPPFLAGS override behavior and possible workaround17:43
* lpapp is adding Scott.17:43
mranostayBhawna: as  root?17:43
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC17:44
mranostaybuilding source as root is a really bad idea17:44
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto17:44
bluelightningBhawna: don't run the setup script or the build as root, use your normal user account17:44
StygiaHey. 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!> has quit IRC17:44
JaMaRP: 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!> has joined #yocto17:45
bluelightningI 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 scope17:45
Bhawnaokay, Bluelighting, i understood the error, will sure improve upon that17:45
JaMakhem: ^17:45
StygiaSorry, if someone replied to me just now I missed it, closed Xchat by accident.17:45
lpappndec: I tried this: EXTRA_OEMAKE = "'CFLAGS=${CFLAGS}' 'CPPFLAGS=${CPPFLAGS}'"17:45
bluelightningStygia: you need to set FILESEXTRAPATHS - see other bbappends17:45
lpappndec: with bitbake foo -c cleanall17:46
lpappand then bitbake foo17:46
lpappndec: but it did not help. :(17:46
Stygiabluelightning, FILESEXTRAPATH_prepend or just FILESEXTRAPATH will do?17:46
lpappndec: and the include paths are still not passed.17:47
lpappso apprently that assumption is wrong.17:47
ndeclpapp: sure... sorry...17:47
ndecyou can't do that. not sure why i told you it was okay...17:47
lpappany, as in /any/ to get the Makefile respected?17:47
bluelightningStygia: FILESEXTRAPATHS_prepend is the best way, then other bbappends for the same recipe that do the same can work if any exist17:47
lpapp/any/ way*17:47
Stygiabluelightning, Thanks dude. :)17:47
lpappbluelightning: why does the buildsystem try to be a smart ass? :o17:48
ndecbecause CPPFLAGS is already cleared when calling the makefile.17:48
lpappor whatever the English term is for being smart.17:48
lpapptoo smart.17:48
bluelightninglpapp: I gave you all I can guess already17:48
* lpapp is not a native speaker17:48
lpappbluelightning: you did not give any workaround17:49
lpappyou just tried to guess why it is disrespectful towards the software's buildsystem.17:49
lpappat least I do not find any.17:49
lpappif you had done, please repaste.17:49
cetolaI 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 IRC17:51
*** sgw_ <sgw_!> has joined #yocto17:51
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto17:51
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto17:52
lpappndec: is it just me or you do not find a proposal for this issue in the documentation?17:53
cetolaThe 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
ndeclpapp: what?17:53
*** dvhart <dvhart!dvhart@nat/intel/x-nmhttjdbycaljxfo> has joined #yocto17:53
otaviolpapp: I fixed fw-utils17:53
lpappndec: explanation, you know, what users can read and use.17:53
otaviolpapp: all build fine now17:53
lpappotavio: I do not care as I do not use it. ;)17:53
ndeclpapp: i believe i know what documentation mean. though i am not native speaker neither.17:54
ndeclpapp: i gave you a workaround that works, btw.17:54
lpappndec: what workaround?17:55
otaviolpapp: Mind to take a look at (specially the commit log) so I can send it to ml?17:55
lpappotavio: as I already said I am not happy with your way of working about it17:56
*** sgw_ <sgw_!> has quit IRC17:56
ndeclpapp: read the backlog , i won't repeat ;-)17:56
lpappI think it is more respectful to make an incremental change for what *you* did.17:56
otaviolpapp: no problem, the unhappyness is mutual17:56
otaviolpapp: I did all the upgrade path17:56
lpappand not take others' work, and then put them into brackets.17:56
otaviolpapp: you did not17:56
lpappndec: I do not think you mentioned any particular really.17:57
*** sgw_ <sgw_!> has joined #yocto17:57
lpappyou mentioned using CPPFLAGS which I already did.17:57
lpappit did not work,.17:57
ndec[19:40:03] <ndec> lpapp: temp workaround set CPPFLAGS in the .bb file17:59
lpapp18:55 < lpapp> you mentioned using CPPFLAGS which I already did.17:59
lpappotavio: not to mention your change is totally wrong. ;)18:01
otaviolpapp: really?18:02
otaviolpapp: why?18:02
lpappYes, really. Others explicitly asked not to remove the old versions.18:02
*** LiangC <LiangC!~Leon@> has joined #yocto18:02
ndeclpapp: 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 IRC18:02
lpappunless you test it on all the reference platforms which I believe you could not do in this short while.18:02
ndecthat said, it's friday night here. have a good weekend.18:02
lpappndec: it does not work for several reasons.18:02
lpappbye I guess.18:03
otavioabelloni: Why you did not update the barebox recipe?18:03
lpappotavio: oh, and taking the credit in the commit is respectless towards me, but also kde.18:04
lpappnot only*18:04
lpappas I was using the kde address for this.18:04
lpappno one will ever check commit logs when doing statistics, etc.18:05
lpappso yeah, just be aware of that, I will mention this publicly, too.18:05
lpappbut this change would need decent work still.18:05
lpappespecially since git is limited in certain ways.18:05
lpappso I hope at least mine can make it by the freeze.18:06
lpappnot sure when sgw_ builds the stuff for that.. maybe Saturday or Sunday?18:06
*** bluelightning <bluelightning!~paul@> has joined #yocto18:06
*** bluelightning <bluelightning!~paul@> has quit IRC18:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:06
otaviolpapp: you said it is wrong ... how wrong?18:07
cetolaah, nevermind, I found a bug report for this udev issue in OE18:07
otaviolpapp: all work for me18:07
lpappI already wrote.18:07
lpappanyway, I am off to cycling to home.18:08
otaviolpapp: good; I e-mailed it to mailing list so you're free to comment on this. Enjoy your way to home.18:10
lpappotavio: it is rejected by default18:10
lpappsince it was rejected this morning already.18:10
lpappothers explicitly asked me to not remove other stuff18:11
lpappif it is not tested on all the reference platform18:11
lpappwhich I highly doubt you did in 1-2 hours when you were unable to even check the log for 1-2 weeks.18:11
lpappor run a build command.18:11
lpappand yes, I will definitely comment on the unfairness towards contributors.18:11
lpappI 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 IRC18:17
*** LiquidL <LiquidL!> has joined #yocto18:18
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC18:23
StygiaWhat's the right way to do multiple do_install_prepend's without overwritting the other ones?18:25
StygiaI 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
bluelightningStygia: they'll always stack and not overwrite eachother18:25
Stygiabluelightning, Fantastic then. :)18:25
bluelightning(with _prepend / _append, that is)18:26
bluelightningbbl, heading home18:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:27
*** reeve <reeve!81c0aafa@gateway/web/freenode/ip.> has quit IRC18:27
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto18:33
lpappotavio: also, you are aware of that you can make suggestions for patches, too?18:37
otaviolpapp: yes and you said you didn't care about fw-utils18:37
lpappespecially for new contributors not to demotivate them with not involving them?18:37
StygiaWe 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 the18: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
lpappno, you said you would create a change.18:38
lpappregardless I care or not.18:38
lpappanyway, I will leave it with Jeff to handle it. Apparently, my questions, nor my contribution is welcome.18:38
lpappfwiw, I have been trying to get my first contribution for over a month now.18:38
Stygiado_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
StygiaObviously hardcoding the relative path is not desirable.18:39
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC18:40
*** JimBaxter <JimBaxter!> has quit IRC18:41
*** smartin_ <smartin_!> has quit IRC18:42
-YoctoAutoBuilder- build #235 of nightly-fsl-arm is complete: Success [build successful] Build details are at
StygiaIs there some way to find the path of the current bbappend as a special variable?18:43
kergothTHISDIR if expanded immediately refers to the currently parsed file's dir18:44
kergothwhich is why FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" and the like is used, and works18:44
kergothotherwise it'd have no way to locate the file:// files relative to the bbappend18:44
Stygiakergoth, 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-certificates18:45
*** smartin <smartin!> has joined #yocto18:45
Stygiakergoth, 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 bbappend18:45
Stygiakergoth, 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 in18:46
*** musdem <musdem!> has joined #yocto18:46
kergothyou shouldn't be doing that18:47
kergothadd the file to SRC_URI using file:// and install it from ${WORKDIR}18:47
kergothfile://DigiCertHighAssuranceCA-3.crt, then do the aforementioned FILESEXTRAPATHS_prepend, then install it from WORKDIR18:48
*** acidfu <acidfu!~nib@> has joined #yocto18:48
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto18:48
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC18:48
kergothTHISDIR 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 bbappend18:48
kergoth:= with FILESEXTRAPATHS forces immediate expansion, which is why that works18:48
*** zenlinux_ <zenlinux_!> has quit IRC18:49
*** flynn378 <flynn378!80db310e@gateway/web/freenode/ip.> has quit IRC18:54
Stygiakergoth, Alright, makes sense. Thanks, I'll try and update the paths.18:54
Stygiakergoth, Was workdir, indeed. :) Thanks.18:57
*** swex <swex!~swex@> has joined #yocto18:58
*** swex__ <swex__!~swex@> has quit IRC19:01
*** LiangC <LiangC!~Leon@> has quit IRC19:02
*** Stygia <Stygia!> has quit IRC19:04
ftonello_any idea when yocto 1.5 will be released?19:04
*** dvhart <dvhart!dvhart@nat/intel/x-nmhttjdbycaljxfo> has quit IRC19:04
kergoththere's a release schedule / calendar on the wiki19:08
*** flynn378 <flynn378!80db310e@gateway/web/freenode/ip.> has joined #yocto19:10
*** sgw_ <sgw_!> has quit IRC19:14
*** Jefro <Jefro!> has joined #yocto19:21
*** zack__ <zack__!> has joined #yocto19:24
*** zack__ <zack__!> has joined #yocto19:24
*** zack__ <zack__!> has joined #yocto19:25
*** sgw_ <sgw_!> has joined #yocto19:28
*** mike <mike!5b99cbbc@gateway/web/freenode/ip.> has joined #yocto19:35
*** mike is now known as Guest9365119:35
Guest93651Can anybody offer some tips for creating kernel recipes ?19:36
Guest93651Have recipe which gets kernel from a git repo19:36
Guest93651it works fine19:36
Guest93651how I want to be able to reuse the recipe but change the branch19:37
Guest93651however it says that it cant find the recipe when I compile it19:38
Guest93651sorry ..19:38
Guest93651it seems to checkout same git recipe even though I set different version in distro19:38
Guest93651anybody with experience creating kernel recipes for multiple branches of kernel19:40
Guest93651Is anybody listening?19:42
*** amarsman <amarsman!> has joined #yocto19:42
*** amarsman <amarsman!> has joined #yocto19:43
* mranostay facepalms19:45
Guest93651can anybody offer some information please on my question?19:46
lpappGuest93651: have you checked the kernel documentation?19:48
Guest93651I have n't found the yocto documentation useful19:49
Guest93651in this regard19:49
lpappGuest93651: have you seen this, KBRANCH ?= "master"19:49
*** dv_ <dv_!> has quit IRC19:50
Guest93651I have removed that19:51
Guest93651I am using and inherit kernel in recipe19:51
Guest93651so I dont think kbranch is needed19:51
lpappkbranch is not needed when you need a custom branch? o_O19:52
*** dv_ <dv_!> has joined #yocto19:53
Guest93651I think so19:54
Guest93651anyway first recipe declares that...19:54
Guest93651and in other recipes... I just require origional recipe and set the git branch I want19:55
Guest93651but it doesnt  get the branch I want19:55
Guest93651when I set preferred version in distro19:55
zeddiiGuest93651, 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!> has joined #yocto20:03
*** bluelightning <bluelightning!> has quit IRC20:03
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:03
Guest93651the SRC_URI has the branch set .. like20:04
Guest93651SRC_URI = "git... ;branch =${BRANCH}20:04
Guest93651so when I reuse that recipe I just change the branch variable20:05
zeddiiyep. that's what you are saying isn't working ?20:05
Guest93651but it always seem to check same git branch20:06
cbabcan anyone explain the process by which patches sent on the openembedded-core get merged in yocto? how does it work?20:06
zeddiiGuest93651, it checks out a SRCREV not a branch.20:07
zeddiiare you changing SRCREV ?20:07
zeddiithe 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
Guest93651I not doing anything setting for SRCREV20:09
zeddiicbab, it's a pull model. You send a patch to the 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
zeddiiGuest93651, 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
cbabzeddii: 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.120:11
zeddiithere's a maintainers file for meta-yocto at least (which overlaps oe-core recipes). meta-yocto/conf/distro/include/maintainers.inc20:12
Guest93651I think I have it set to AUTOREV. I must check that20:12
zeddiiin 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
zeddiicbab, 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
cbabzeddii: 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
cbabis there a preference for tarball over git for recipes?20:15
*** Guest93651 <Guest93651!5b99cbbc@gateway/web/freenode/ip.> has quit IRC20:19
zeddiicbab, ah cool. We do update our lttng packages to track periodically already, currently Laurentiu Palcu <> 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!> has quit IRC20:21
zeddiicbab, it depends on the project. git is good for most cases. easier for active development as far as I'm concerned.20:21
cbabzeddii: 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 git20:24
cbabalso I made sure that we pushed upstream one of the oustanding patch for lttng-ust:
*** sameo <sameo!~samuel@> has joined #yocto20:28
*** reeve <reeve!81c0aafa@gateway/web/freenode/ip.> has joined #yocto20:29
*** Jefro <Jefro!> has quit IRC20:31
*** Jefro <Jefro!> has joined #yocto20:33
*** Bhawna <Bhawna!~arunkr24@> has quit IRC20:35
*** mulhern <mulhern!> has joined #yocto20:36
reeveseebs: 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 it20:37
reeverevision 398 *20:37
reevegeeze, revision 389*20:38
zeddiicbab, it's a convention, but not all recipes that use git have _git in their name.20:38
seebsreeve: 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
reeveseebs: I'm on dylan branch, so do I have that change?20:40
cbabzeddii: alright, thanks for answering my questions :) I'll send patches to the maintainers perhaps after the stabilization phase20:40
reeveseebs: when you say smartpm repo, what does it mean? Another git server?20:40
seebsI 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 #yocto20:41
bluelightningwe should probably try to convince them to switch to git20:43
reevethanks, I'll look at it20:43
bluelightningI don't think it will be too hard a sell to be honest20:43
Bagderlaunchpad projects tend to be bzr, right?20:44
bluelightningdevelopment on smart was funded by canonical for a time20:45
bluelightning(a few years ago)20:45
*** smartin <smartin!> has quit IRC20:49
Bagderright "Funded Smart development up to November of 2009" it says in the README20:50
Bagderas a curl hacker I'm happy to see they use pycurl =)20:50
bluelightningcode-wise it's fairly clean20:51
bluelightningsomewhat lacking in debug mode output though sadly20:52
bluelightningI might try to improve that in 1.620:52
*** smartin <smartin!> has joined #yocto20:56
abelloniotavio: you mean 2013.08 is not recent enough ?20:57
otavioabelloni: no; I mean removing the old one from fsl-arm20:58
*** ka6sox-away is now known as zz_ka6sox-away21:03
abellonitha fact is that the qsb had quite a lot of patches to get it working21:12
abelloniI'm not sure if everything made it to the mainline21:12
abelloniprobably though21:12
abellonibut I don't have any imx53/imx6 boards anymore21:12
abelloniso I couldn't check21:12
abelloniEric was supposed to ship a board or two but I guess mor important things came up21:13
*** ant_home <ant_home!> has joined #yocto21:14
*** mulhern <mulhern!> has quit IRC21:14
otavioabelloni: humm21:15
*** reeve <reeve!81c0aafa@gateway/web/freenode/ip.> has quit IRC21:26
-YoctoAutoBuilder- build #274 of nightly-x32 is complete: Failure [failed Running Sanity Tests] Build details are at
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:43
*** musdem <musdem!> has quit IRC21:46
*** smartin <smartin!> has quit IRC21:50
*** smartin <smartin!> has joined #yocto21:56
*** zz_ka6sox-away is now known as ka6sox21:59
*** eren <eren!~eren@unaffiliated/eren> has quit IRC22:00
jwesselAny one around who knows something about the PR server?22:07
JaMamr wiki22:07
* jwessel is trying diagnose why it hangs while using "bitbake -e"22:07
jwesselSeems like this will be fairly tricky to debug.22:07
*** mulhern <mulhern!> has joined #yocto22:08
JaMaare you sure it's PR server hanging?22:08
jwesselI am fairly certain.22:08
jwessel#39 Frame 0x5347070, for file /space/jw/6/small/qemux86/bitbake/lib/prserv/, line 91, in work_forever (22:09
jwesselThat calls into: #35 Frame 0x6d61130, for file /usr/lib/python2.7/logging/, 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
JaMaand are you running standalone PR server or starting it with bitbake?22:09
jwesselAnd it is ultimately blocked on a semaphore deep in the guts of python.22:09
jwesselIt starts automatically with bitbake.22:09
jwesselThe line 91 is:22:09
jwessel"Started PRServer with DBfile: %s, IP: %s, PORT: %s, PID: %s" %22:10
jwessel                     (self.dbfile,, self.port, str(os.getpid())))22:10
jwesselSo 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
JaMaI would try to run separate PR server to divide the issue a bit22:10
JaMamaybe you're seeing the same as
yoctiBug 4338: normal, Medium, 1.5, richard.purdie, NEW , bitbake hangs forever before showing any output22:11
JaMait also needs significant load to happen22:11
*** mulhern <mulhern!> has quit IRC22:11
jwesselWell as another data point, before we had the prserver activated, this never ever happened :-)22:12
jwesselJaMa: I am fairly certain these are closely related22:12
jwesselI 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
jwesselThe 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
jwesselClearly the "bitbake -e", is not using the pr server in this instance.22:15
JaMajwessel: are you running multiple bitbake processes on the same machine?22:18
JaMajwessel: or can you reproduce it even with just one bitbake running?22:18
RPjwessel: hot or cold cache?22:19
JaMaI meant multiple independent builds22:19
jwesselI have not yet reproduced this with a single instance and just jacking up the load.22:19
jwesselAll the builds are independent22:19
JaMajwessel: good, the same here22:19
JaMajwessel: and I also see it only after enabling PR service (btw there was similar issue
yoctiBug 3742: major, Medium, 1.4, richard.purdie, VERIFIED FIXED, bitbake hangs forever when PR serv is enabled22:20
jwesselOh so this is already fixed somewhere?22:20
JaMapartially fixed22:21
RPjwessel: no, we found issues mixing threading and multiprocessing in some versions of python so we removed the use of threading22:21
JaMaRP's fix from 3742 fixed it for some time and some time later it started again only slightly different22:21
jwesselI am probably going to have to instrument it a bit.22:22
JaMajwessel: how often do you see it?22:22
RPmultiprocessing and threading in python 2 are full of bugs :(22:22
RPjwessel: do you have a good way to reproduce?22:22
jwesselI can see the main thread is blocked on terminate and doing a join for tearing things down.22:22
jwesselYes, but it may only happen on my environment.22:22
jwesselI can reproduce it in < 5min.22:23
JaMajwessel: btw what's your distro?22:23
JaMajwessel: and are you using e.g. chroot for builds?22:23
jwesselHad to look... It was Ubuntu 12.0422:23
jwesselI am not using any kind of chroot that I am aware of.22:23
jwesselRP: Basically I run "bitbake -e" in a loop and then I figure up my 30x30 builds in a different directory.22:24
JaMaOK, I was just looking for some similarities between our setups as we're probably the only two seeing this issue :)22:24
jwesselEach pass of the bitbake -e takes about 6 seconds and it never makes it to 100 passes.22:25
RPjwessel: does your bitbake -e loop clear the caches at all?22:25
jwesselStraight reuse of the cache.22:25
RPjwessel: that is a helpful data point22:25
* jwessel goes to inspect the third thread.22:25
jwesselRP, you want to see the traces?22:25
jwesselI was planning on possibly sending them to you anyway.22:25
RPjwessel: each is starting its own PR server, there is no common shared one?22:25
jwesselThere is definitely no common PR server.22:26
RPjwessel: I can take a look but I would warn you my brain is fried with the release freeze coming up22:26
jwesselNo worries.22:26
RPbeen doing 20 things at once for too many hours22:26
jwesselGet some sleep then.22:26
jwesselNot like this problem is going away :-)22:26
RPjwessel: that will happen shortly :)22:26
jwesselI had figured you were gone long ago for the day, and I would chat with you on Monday about this one.22:27
jwesselI need to collect all the logs and stare at this a bit more anyway.22:27
jwesselhow odd...22:28
jwesselThe other thread is executing:     def ping(self):22:29
jwessel        return
RPthis stirs memories22:30
*** andyross <andyross!> has quit IRC22:30
jwesselSo basically the PR server is trying to come online, bitbake forked it, and the ping, and the master guy is in terminate.22:30
jwesselWith the high load, I could certainly see how this might happen.22:30
RPjwessel: yes, I think this sounds like a promising direction22:31
jwesselI'll have to study the code and the traces and perhaps add some instrumentation.22:31
jwesselAt any rate the sledge hammer debug approach can at least trace the orphan.22:31
jwesselI couldn't get pdb attached before, so I am miles ahead of where I was previously at.22:32
jwesselI had to make some other changes too like using python-dbg, in order to get a usable debug env.22:32
ant_homeRP: 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/linux22:32
jwesselRP: 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
JaMajwessel: good work!22:33
RPjwessel: sounds good22:33
ant_homeRP at first it should be ../ and not ./ isn't ?22:33
ant_homeRP: rebuilding image right now after pull22:33
RPant_home: no, that looks right22:33
jwesselWith some instrumentation around the steps prior to terminate perhaps more information can be had.22:34
ant_homehm, is pwd in /include then ?22:34
RPant_home: yesm the directory containing the link22:34
jwesselThe 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!> has quit IRC22:35
jwesselKnowing how we fast path to the terminate routine will help.22:36
ant_homeRP: ok then
jwesselFor 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
jwesselmain process (A) is calling join in its terminate block to process (B)22:37
RPant_home: you're in the target directory there, that makes no sense22:38
jwesselProcess (B) is the ping to the PR server to see it is alive22:38
jwesseland it is blocked waiting for the ping to come back.22:38
ant_homeRP: ?22:38
jwesselProcess (C) is the PR server waiting to write a logger back to the main process22:38
jwesselThe obvious choice here seems to remove the logger.() stuff or reset it or something...22:39
RPjwessel: like"PRServer: stopping...") ? :)22:40
jwessel"Started PRServer with DBfile: %s, IP: %s, PORT: %s, PID: %s" %22:41
jwessel                     (self.dbfile,, self.port, str(os.getpid())))22:41
RPjwessel: isn't logger going to a file?22:41
jwesselIt is blocked at line 91 of serv.py22:41
*** seebs <seebs!> has joined #yocto22:41
jwesselIf it is, it isn't working.22:41
jwesselRP frame 15 is the one where we call into the python "stuff"22:44
RPjwessel: I think logger.addHandler(streamhandler) might be the issue22:44
RPjwessel: we need to make that the *only* handler22:44
*** mckoan|USA is now known as mckoan22:45
jwesselYes, 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|away22:46
*** challinan <challinan!> has quit IRC22:46
*** mckoan|away is now known as mckoan|USA22:46
jwesselIn theory it should log to its own file anyway in a separate place.22:46
jwesselOr from what ever build directory it started from.22:46
jwesselhmm.. Was that called in the right place?22:47
jwesselBecause it should only open the file after the fork.22:47
jwesselRP: I'll take a look at it later.   Off to get some dinner in my time zone.  :-)22:48
jwesselCheers and thanks for the advice.22:48
*** cetola <cetola!> has quit IRC22:50
*** Jefro <Jefro!> has quit IRC22:52
RPjwessel: try adding a del logging.root.handlers[:] before the new addHandler22:54
-YoctoAutoBuilder- build #142 of nightly-qa-systemd is complete: Success [build successful] Build details are at
*** hollisb <hollisb!> has quit IRC23:07
*** scot <scot!~scot@> has quit IRC23:17
*** musdem <musdem!> has joined #yocto23:21
RPjwessel: I'm not convinced the pr server is writing to the bitbake server for logging. Quite puzzling. Note there are two identical log messages23:31
jwesselI am not entirely sure what all happened.23:35
jwesselI queued the change you asked about and I'll get the results back after I get back from the mall.23:35
jwesselI believe a bit of instrumentation is in order now that I have a way to trace things.23:36
RPjwessel: I can make it hang with:
RPjwessel: the question would be why work_forever is exiting, could be some kind of error?23:37
RPanyhow, /me -> Zzzz23:37
*** LiquidL <LiquidL!> has quit IRC23:38
RPeven just removing the work_forever makes it hang...23:39
*** ftonello_ is now known as ftonello23:40
*** ant_home <ant_home!> has quit IRC23:42
jwesselheh..  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
jwesselThe ping that the main bitbake launches will never complete.23:44
*** sameo <sameo!~samuel@> has quit IRC23:44
jwesselSo 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 IRC23:54
*** alex_kag <alex_kag!~alex_kag@> has quit IRC23:54

Generated by 2.11.0 by Marius Gedminas - find it at!