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