**** BEGIN LOGGING AT Fri Aug 02 02:59:59 2013 Aug 02 03:48:41 khem, same failure with 1.6rc1, so I bisected with in the 1.4->1.5 range and came up with that commit. Aug 02 05:10:04 hi yocto. i m getting error of "cannot find -lm" while compiling gcc-4.7.2. but in sysroot lib directory, there is no libm file.anyway to fix this? Aug 02 05:10:26 i m using poky distro for at91sam9x5 soc. Aug 02 05:12:20 my machine.conf at http://pastebin.com/CegDy8Q0 Aug 02 05:13:35 my local.conf at http://pastebin.com/5QfxyKVw Aug 02 05:26:44 sorry my local.conf at http://pastebin.com/Si0kqnUA Aug 02 06:57:18 hi, i'm unable to compile perl und libxml-parser-perl-native for armv7a, @perl, i get some error about miniperl not being found. i thought miniperl got replaced by a full perl implementation? Aug 02 07:30:00 is it possible to put the tarball next to the recipe? Aug 02 07:30:02 or insides files? Aug 02 07:36:09 morning Aug 02 07:36:35 qt5 question Aug 02 07:36:58 i ahve modified qt5-versions.inc to use version 5.1.0 (default is 5.0.2) Aug 02 07:37:05 now i need to include that file, but where? Aug 02 08:00:42 morning all Aug 02 08:01:32 is there a recipe finder service Aug 02 08:04:20 lpapp: there is indeed: http://layers.openembedded.org/layerindex/recipes/ Aug 02 08:04:43 ok, nginx is not available. :( Aug 02 08:05:23 coincidentally someone was asking about that the other day, I don't know if they started working on one Aug 02 08:07:15 it was mr_science in #oe Aug 02 08:09:13 and uwsgi ? Aug 02 08:11:29 haven't heard any discussion about that one Aug 02 08:11:54 all hail the layer index Aug 02 08:12:01 whoever wrote that was a life-saver Aug 02 08:28:13 rburton: bah, humbug :) Aug 02 08:38:16 rburton: yet the author ignored the users and did not write a proper qt frontend Aug 02 08:39:17 some people eh Aug 02 08:39:24 anyway, should have been gtk+ Aug 02 08:40:29 what is the benefit of a qt frontend anyway Aug 02 08:41:33 rburton: gtk is not cross-platform. Aug 02 08:41:51 ant_work: I could have written a qt frontend, it might have been qt2 though ;) Aug 02 08:55:09 what do I need to check into the repostory for the downloads to work? Aug 02 08:55:27 sstate-cache and tmp as well? Aug 02 08:56:01 what are you trying to do? Aug 02 08:56:28 as I wrote above, check downloads into the repository. Aug 02 08:56:59 just the downloads directory then Aug 02 08:57:08 tmp is where the builds happen, and will be giant and frequently changing Aug 02 08:57:42 and yes, sstate-cache is incredibly useful to share between multiple machines if you can. that's not "downloads" though, but intermediate-stage build objects. Aug 02 08:58:10 i.e. compiled libraries it can use to build a sysroot from Aug 02 09:02:17 rburton: we have some tmp committed already, and that is why I was wondering. Aug 02 09:02:22 probably I can remove it all. Aug 02 09:11:22 rburton: is that correct, then? Aug 02 09:14:48 and I probably do not need "cache" either? Aug 02 09:15:08 nor bitbake.lock? Aug 02 09:16:05 what about pseudodone? Aug 02 09:17:28 lpapp: remove all the 3 above and tmp- Aug 02 09:17:40 I keep only downloads Aug 02 09:17:57 ant_work: why don't you keep sstate? Aug 02 09:18:16 I do prefer build from scratch Aug 02 09:18:29 why? Aug 02 09:18:47 soemtimes I increase by hand the revision of my dev recipes Aug 02 09:18:59 so those would always be preferred Aug 02 09:19:21 and build from scratch just takes couple of hours Aug 02 09:19:29 ok, I will check in for now as is, and I can remove later. Aug 02 09:19:35 that is a lot Aug 02 09:19:48 I build it within 40 minutes. Aug 02 09:19:52 but I use core-image-minimal Aug 02 09:20:29 lpapp: I build core-image-base and core-image-sato Aug 02 09:20:46 k Aug 02 09:20:48 on rather old hw Aug 02 09:21:12 that makes sense, then. Aug 02 09:21:16 on the last partition of the disk :/ Aug 02 09:22:14 lpapp: build from sstate-cache takes just 5 mins Aug 02 09:22:49 ant_work: does that matter it is the last partition? Aug 02 09:23:02 swap is already slow, no? Aug 02 09:24:22 it's never swapping, it's just the disk is slower on last part Aug 02 09:25:23 lpapp: pseudodone is the stamp that says its done building pseudo Aug 02 09:25:33 the bitbake cache is a cache of the parse tree Aug 02 09:25:44 both of which clearly shouldnt be persisted anywhere Aug 02 09:27:16 yeah Aug 02 09:27:25 ant_work: any benchmark how much? Aug 02 09:27:31 (if any) Aug 02 09:27:36 depends on the disk etc etc Aug 02 09:27:40 lpapp: I can provide later Aug 02 09:39:12 ant_work: k, please do not forget it as you got me curious. :-) Aug 02 09:39:18 llpapp: http://superuser.com/questions/159890/does-the-order-of-partitions-matter Aug 02 09:40:14 lpapp: I was obliged to keep Win$ on my hackintosh and it needed to be installed on first part of the second hdd Aug 02 09:40:40 lpapp: otherwise I'd set first partition of second disk for that Aug 02 09:41:13 lpapp: before you ask: raid is not an option in my case... Aug 02 09:51:38 hi everyone. Aug 02 09:51:56 i have some issues with inconsistent library dependencies Aug 02 09:52:12 on poky 9.0.1 Aug 02 09:52:17 ant_work: interesting. Aug 02 09:52:29 ant_work: it is not something I heard programmers talking about when optimizing stuff. Aug 02 09:52:48 well, lets' hope HDD are the past ;) Aug 02 09:53:10 precisely: libfm depends on libicuuc.so.50 and gtk.sato depends on libicuuc.so.51 Aug 02 09:53:26 both won't shut up when i feed them the other version Aug 02 09:54:15 and i don't know, how to modify the depends of libfm to be happy with .51 Aug 02 09:54:25 which should work in practice, i think. Aug 02 09:54:55 can someone tell me, whether this is a good idea, and if, how to modify this dependency? Aug 02 09:56:18 dRp3pP3r: same problem as before, you need to rebuild libfm Aug 02 09:56:21 that should have happened :( Aug 02 09:57:14 well, tried so, but didn't work. btw: the solution didn't work for libtasn1 as well. i had to downgrade to libtasn1_3.2, which provides libtasn1.so.6 as needed by gnutls Aug 02 09:57:28 i mean libtasn1.so.3 Aug 02 09:57:38 .6 is provided by libtasn1_3.3 Aug 02 09:58:01 the problem with icu is, that both versions are needed Aug 02 09:58:12 so downgrading is not an option this time... Aug 02 09:58:47 the problem is that at some point you upgraded icu and libfm didn't rebuild Aug 02 09:59:01 (or you've downgraded icu and gtk+ didn't rebuild) Aug 02 09:59:26 ok, makes sense, than a rebuild should solve. Aug 02 10:00:10 give me a minute, it's working :) Aug 02 10:05:42 rburton: unsubscribed from oe. If you need me, cc. Aug 02 10:11:12 btw, I had a question this morning about local tarballs. Aug 02 10:15:38 rburton: you were right. that worked. Aug 02 10:15:45 thanks. :) Aug 02 10:16:03 dRp3pP3r_: would love to know why these rebuilds are not happening automatically. what release are you using? Aug 02 10:16:40 todays snapshot of master for both, poky and oe Aug 02 10:16:49 huh, *really* should work then Aug 02 10:17:30 hm. git-pulled them two hours ago. Aug 02 10:18:35 do i see it correctly, that the root of the problem is a lower-level library is updated, but some libraries that depend on further mentioned lib don't. so they get their depends messed up? Aug 02 10:26:09 rburton: http://cgit.openembedded.org/meta-openembedded/commit/?id=47f3975a6a009bf61d4c8f61e1b70a5eeaee873b Aug 02 10:27:16 any ideas? Aug 02 10:27:29 lpapp: sorry, missed the question. Aug 02 10:27:57 dRp3pP3r_: that normally happens if the packages don't include the dependencies, so check that. gnutls/tasn i'm pretty sure do though. Aug 02 10:28:04 ant_work: ? Aug 02 10:28:04 Hello Aug 02 10:28:16 rburton: https://www.yoctoproject.org/irc/%23yocto.2013-08-02.log.html#t2013-08-02T07:30:00 Aug 02 10:28:33 ant_work: oh god what's that do_compile_append doing. i'm scared to look. Aug 02 10:28:45 lpapp: yes Aug 02 10:28:58 SRC_URI is a list of stuff Aug 02 10:28:58 ok. include the dependecies? what do you mean? Aug 02 10:29:02 local, git, http, whatever. Aug 02 10:29:22 dRp3pP3r_: the DEPENDS field. should be working for the packages you're seeing problems with though. :( Aug 02 10:29:56 rburton: I guess the right one is openembedded-core/tree/meta/recipes-support/icu/icu.inc Aug 02 10:29:57 How can I bring header only recipes into an image? I tried with glm, and when adding glm-dev to a packagegroup it complaints: "Can't install glm-dev-0.9.4.4-r1@cortexa9hf_vfp_neon: no package provides glm = 0.9.4.4-r1" which is true, but there won't be a library or so.. Aug 02 10:30:13 rburton: hm. ok. for now it works. if i come across such stuff again, i'll further investigate. thanks a lot. Aug 02 10:30:27 Thinking about a fake package. is there a better way? Aug 02 10:30:55 simon_b: RDEPENDS_${PN}-dev = "" Aug 02 10:31:11 simon_b: a -dev package by default depends on the "main" package, but you don't want that Aug 02 10:31:51 rburton: thank you. trying that. Aug 02 10:31:54 rburton: libfm does not depend on libicu, according to libfm_1.1.0.bb Aug 02 10:32:18 dRp3pP3r_: probably something else does, and that should have got rebuilt. Aug 02 10:32:19 but gnutls does depend on libtasn1, yes Aug 02 10:32:25 maybe. Aug 02 10:32:46 anyway, have a nce day :) Aug 02 11:24:23 rburton: is there any example out there? Aug 02 11:49:04 lpapp: of using a tarball in SRC_URI? just use a file: url. Aug 02 11:49:16 file://mytarball.tar.gz Aug 02 11:49:23 rburton: yes, any existing example would be welcome. Aug 02 11:49:31 rburton: yeah, and where to put the file actually ... Aug 02 11:49:48 same rules as patches Aug 02 11:49:54 so files/ or PN/ or PN-PV/ Aug 02 11:50:17 there is literally no difference as far as the fetching logic is concerned here Aug 02 11:50:23 tarballs get extracted, patches get applied Aug 02 13:18:30 how can I conveniently get all build-essentials RPMs installed onto my target host (Gumstix Overo)? tracking down each required dependent RPM seems hopeless.. Aug 02 13:25:14 khem: gcc fix looks good :) Aug 02 13:29:01 ErkiS: I mentioned this yesterday - packagegroup-core-buildessential will pull in all the necessary packages Aug 02 13:34:09 bluelightning, I also answered yesterday :) - getting ERROR: Nothing PROVIDES 'packagegroup-core-buildessential' Aug 02 13:34:26 ErkiS: which version of the build system are you using? Aug 02 13:37:27 bluelightning - not sure how to check this? last git commit is 2806646a263527ec0487ea160afd4bdc0a3c1703 Aug 02 13:40:00 ErkiS: ah, that's in danny (1.3)... packagegroup-core-buildessential wasn't added until the release after i.e. dylan (1.4) Aug 02 13:40:10 ErkiS: it's a pretty trivial recipe though, you could just add it on top Aug 02 13:40:40 ErkiS: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb Aug 02 13:41:27 thank you, will try :) Aug 02 13:41:47 ErkiS: apologies for missing your reply yesterday Aug 02 13:43:08 no problemo Aug 02 13:45:16 do I need to configure the target system in some way as well? the resulting RPM is tiny and doing "rpm -ivh packagegroup-core-buildessential-1.0-r0.all.rpm" complains about a number of missing dependencies Aug 02 13:47:08 ok, so bitbake can handle .tar.xz Aug 02 13:48:33 is it a good practice to have one .bb per recipe? Aug 02 13:48:47 I mean one type of .bb (might be separate version variants) Aug 02 13:48:48 ErkiS: erm, rpm doesn't automatically install dependencies Aug 02 13:48:54 because u-boot is going against that principle for instance. Aug 02 13:49:16 lpapp: yes, I noted that when we discussed this previously Aug 02 13:49:20 lpapp: I don't know why that is Aug 02 13:49:42 is it a good practice Aug 02 13:49:49 the convention is to just have one unless there is a bleeding edge git or old gplv2 version Aug 02 13:50:12 err... I think you are misunderstanding the situation. Aug 02 13:50:24 I do not refer to the versions at all, I think that is fine. Aug 02 13:50:31 what is not fine is foo.bb Aug 02 13:50:34 foo-bar.bb Aug 02 13:50:37 foo-baz.bb, etc. Aug 02 13:50:52 right, and if you recall I explained why at least one of these additional ones is needed Aug 02 13:51:06 bluelightning, so back to my original question - how can I *conveniently* get all required RPMs installed? :) Aug 02 13:51:10 I tried installing all listed dependencies one by one, until I ran into an absurd circular dependency where perl-module-carp depends on perl-module-exporter, which depends on perl-module-exporter-heavy, which depends on perl-module-carp and perl-module-exporter Aug 02 13:51:48 bluelightning: that is irrelevant Aug 02 13:51:49 ErkiS: in danny we provided zypper as a front-end to resolve and install dependencies Aug 02 13:51:54 lpapp: no, it isn't Aug 02 13:51:55 the question is, whether or not it is a good practice. Aug 02 13:51:59 yep. Aug 02 13:52:29 lpapp: it's pretty much required, because you want to build the mkimage tool for the host (native) and the actual bootloader for the target Aug 02 13:52:44 bluelightning: you could you different recipe folders, really. Aug 02 13:52:53 bluelightning: aha, so I should upgrade my yocto. is 1.3 -> 1.4 upgrade painless? Aug 02 13:53:24 ErkiS: depends, for me, it is not. Aug 02 13:53:27 it is painful. Aug 02 13:53:32 lpapp: we'd rather keep u-boot derived recipes in the same folder; there are plenty of other examples where we do the same thing Aug 02 13:53:37 but I use external toolchains, etc. Aug 02 13:53:47 ErkiS: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration Aug 02 13:54:26 ErkiS: as noted, in 1.4 we moved from zypper to smart, but largely the same functionality is provided Aug 02 13:55:15 * lpapp does not understand the smart thingie Aug 02 13:56:38 bluelightning: ah, sorry, I misread you. so if I install zypper, that should help me installing the rest? Aug 02 13:57:40 what about opkg Aug 02 13:58:02 opkg has new maintainer :) Aug 02 13:58:42 ErkiS: it should yes Aug 02 13:59:06 JaMa: I did not hear that news...? Aug 02 13:59:15 I mean that is probably the best for embedded? Aug 02 13:59:47 lpapp: typical embedded applications, if you need a package manager at all, yes Aug 02 14:00:10 bluelightning: unfortunately, zypper is telling me that 'gumstix' and 'Angstrom' repositories are invalid (File '/repodata/repomd.xml' not found on medium 'http://package-cache.gumstix.org/') Aug 02 14:00:13 bluelightning: Paul Barker volunteered on opkg-devel ML and is now merging pending patches Aug 02 14:00:29 JaMa: great, that is very good news Aug 02 14:00:56 at some point I was subscribed to that list, not sure why I'm not anymore... Aug 02 14:01:09 it did not have a maintainer?! Aug 02 14:01:37 the last maintainer wasn't really active over the last few years no Aug 02 14:01:50 he did do quite a lot of work on it before then though Aug 02 14:02:32 I got couple of patches (all from oe-core) merged few months ago, but there was no development and no plans for new release Aug 02 14:03:19 mostly it just works; but there are a few rough edges... the libopkg API rework never got properly finished for example Aug 02 14:03:28 AFAIK Aug 02 14:04:06 it is written in c. :( Aug 02 14:08:06 why is it better than other package managers Aug 02 14:08:10 what makes it minimal Aug 02 14:08:24 * lpapp used to hav a package manager written in qt Aug 02 14:08:26 have* Aug 02 14:12:09 JaMa: oh that's excellent news. i wonder if he'll fill in all the TODO bits ;) Aug 02 14:12:27 lpapp: vastly less memory usage is the main reason Aug 02 14:12:29 I also wonder if it is that good, why it is not the default for Yocto. Aug 02 14:12:33 rburton: ? Aug 02 14:12:40 less memory usage means less stuff to deal with I guess? Aug 02 14:12:44 but is that really good? Aug 02 14:13:05 more like it is designed to use a little ram, instead of apt which assumes it can just fill ram with everything Aug 02 14:13:11 (and thus can't be used on systems with low ram) Aug 02 14:13:16 (ditto rpm) Aug 02 14:13:41 not sure what that means. Aug 02 14:14:06 of course if you're not putting the package manager on the target itself, then it doesn't matter. Aug 02 14:15:06 du -sh `which pacman` Aug 02 14:15:07 108K /usr/bin/pacman Aug 02 14:15:14 I would call that lightweight. Aug 02 14:15:24 and pacman is designed to use very small amount of RAM, too. Aug 02 14:15:29 so again, why did we need opkg? Aug 02 14:16:26 lpapp: because pacman didn't exist when opkg was written. Aug 02 14:16:38 | POD document had syntax errors at /usr/bin/core_perl/pod2man line 71. Aug 02 14:16:38 | make: *** [install_docs] Error 1 Aug 02 14:16:38 | ERROR: oe_runmake failed Aug 02 14:16:39 at the time opkg was written, both rpm and dpkg would OOM on the typical target Aug 02 14:16:39 | ERROR: Function failed: do_install ( Aug 02 14:16:49 rburton: are you actually sure Aug 02 14:16:51 Hello yocto community. I've read that yocto has systemd support but I can't find any documentation on how to enable it. Could anyone point to some instructions or throw me some hints? Aug 02 14:16:53 pacman started very early. Aug 02 14:17:00 at least 7-8 years ago Aug 02 14:17:20 sorry, 11.5 Aug 02 14:17:26 when 1.0 was released. Aug 02 14:17:33 so probably 12-13 years ago when it started. Aug 02 14:18:20 if i'm wrong then i'm sorry, i wasn't around when opkg was created. Aug 02 14:18:29 if you want to write a layer to use pacman, go for it Aug 02 14:18:39 you can do that in a standalone layer no problem Aug 02 14:19:37 I do not feel the need for opkg, personally. Aug 02 14:19:45 if there had been a project with such goals in mind, already. Aug 02 14:20:02 don't use it then Aug 02 14:20:05 linux is about choice :) Aug 02 14:20:08 it has to have some project mission which differs from pacman Aug 02 14:20:15 pacman has been written in C, as well. Aug 02 14:20:21 tstableford: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#selecting-an-initialization-manager Aug 02 14:20:31 rburton: it is not about that. Aug 02 14:20:39 I just dislike when I see projects reinventing the wheel. Aug 02 14:20:59 lpapp: welcome to the other side of "choice" Aug 02 14:21:28 in yocto *right now* there is rpm, deb and opkg. deb doesn't work that great. some people demand rpm, some people refuse rpm, so use opkg. Aug 02 14:21:32 how can I disable the doc generation globally? Aug 02 14:21:38 if you want to write a pacman layer and prove how great it is, then do so. Aug 02 14:22:06 rburton: write a layer for an unsupported OS? Nice joke. Aug 02 14:22:27 people would associate pacman with arch. Aug 02 14:22:32 lpapp: so why are we discussing this then? it sounded like you wanted to use pacman. Aug 02 14:22:37 and if they see, arch is banned, they would not use pacman. Aug 02 14:22:46 so then what is the point really if it gets no users. Aug 02 14:22:52 rburton: no Aug 02 14:23:00 rburton: I wanted to understand the existence of opkg Aug 02 14:23:22 I still do not understand though. :) Aug 02 14:23:56 lpapp: opkg has many users; it's in use not just by OpenEmbedded but also by OpenWRT and other unrelated projects Aug 02 14:24:09 so, how can I ban doc for Yocto? Aug 02 14:24:30 lpapp: it derives from ipkg which has been around since 2002 and possibly earlier Aug 02 14:24:33 bluelightning: but _why_ was it born in the first place when there was such a project with such a goal in mind? Aug 02 14:24:39 thanks bluelightning Aug 02 14:25:13 lpapp: what recipe, and what release? Aug 02 14:25:15 lpapp: I don't know, perhaps you can ask florian ;) Aug 02 14:25:24 rburton: all Aug 02 14:25:41 lpapp: re-phrase your question: why was pacman born when dpkg/rpm/ipkg/more already existed? Aug 02 14:25:50 lpapp: "because" is the usual answer Aug 02 14:26:22 because each one considers itself "better" by some metric Aug 02 14:26:35 rburton: because it is lightweight Aug 02 14:26:40 meant for a very thin system Aug 02 14:26:47 it has a lot better design. Aug 02 14:26:55 and it does not have a bloated interface. Aug 02 14:27:07 and it is a lot easier to deal with for packagers Aug 02 14:28:12 and it was also fully community driven. Aug 02 14:28:55 another try: how can I disable the docs? Aug 02 14:29:03 fully and globally for yocto Aug 02 14:29:32 lpapp: there is no such global switch, that I know of Aug 02 14:30:03 sucks Aug 02 14:30:13 so there is another build failure in dylan, then. Aug 02 14:30:22 which I cannot even disable. :( Aug 02 14:30:23 we have disabled documentation for some troublesome recipes on an individual basis Aug 02 14:30:38 please do that for openssl as well. Aug 02 14:31:20 lpapp: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ea886ed79d7f10d2f8392398e65138f5da04a892 Aug 02 14:31:29 http://patchwork.openembedded.org/patch/52387/ Aug 02 14:31:42 yeah, why on earth did it not make it into dylan sigh Aug 02 14:32:30 it's in the dylan branch already, queued for 1.4.2 Aug 02 14:33:16 yeah for ages Aug 02 14:33:22 so it is useless for dylan users. Aug 02 14:33:50 or not, as the case may be Aug 02 14:34:15 sure, I should wait here sitting for weeks Aug 02 14:34:18 or months for it to get released. Aug 02 14:35:39 lpapp: have you considered tracking the dylan git branch? Aug 02 14:35:59 ? Aug 02 14:40:33 anyway, this sounds like a new feature request Aug 02 14:40:47 I would like to be able to say that I do not wanna any kind of docs. Aug 02 14:40:58 and that is globally... it is an embedded board... doc would make no sense. Aug 02 14:41:10 worst case scenario a local.conf entry. Aug 02 14:41:20 lpapp: the docs won't get installed unless you ask for them Aug 02 14:41:27 (doc-pkgs image feature) Aug 02 14:41:38 I do not wanna _build_ them,even. Aug 02 14:41:40 potentially useful in sdk builds though Aug 02 14:41:46 why would I build them if I do not wanna install them? Aug 02 14:41:59 and have no any intention to use them. Aug 02 14:53:44 * rburton cheers at sstate Aug 02 15:33:02 ERROR: Function failed: bar: LIC_FILES_CHKSUM points to an invalid file: /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/tmp/work/armv5te-foo-linux-gnueabi/bar/0.1-r0/bar-0.1/COPYRIGHT Aug 02 15:33:06 why is it like that? Aug 02 15:33:09 I have the COPYRIGHT in PN Aug 02 15:36:26 is it mandatory to have do_make/install sections? Aug 02 15:37:34 there are defaults in base.bbclass, so effectively no Aug 02 15:37:45 how can I avoid that error? Aug 02 15:38:25 presumably your LIC_FILS_CHKSUM is wrong Aug 02 15:38:27 pastebin? Aug 02 15:39:07 you may want to use ${WORKDIR} if the path is wrong Aug 02 15:39:18 but it does not suggest any correct. Aug 02 15:39:19 i.e. if you use a relative path, it uses ${S} as the root Aug 02 15:39:28 ? Aug 02 15:39:36 I have been told PN, files, etc are looked up by default. Aug 02 15:39:49 they are Aug 02 15:39:55 and the fetch/unpack worked Aug 02 15:40:02 because LIC_FILES_CHKSUM happens after that Aug 02 15:40:30 so why would I need WORKDIR then? Aug 02 15:40:47 i'm entirely guessing because you're not giving any context Aug 02 15:40:56 ? Aug 02 15:41:05 context is simply file://COPYRIGHT Aug 02 15:41:14 nothing magical. Aug 02 15:41:17 and the file isn't at the path it says its looking at? Aug 02 15:41:21 I wonder why I need the WORKDIR Aug 02 15:41:24 right Aug 02 15:41:42 it works without that for SRC_URI Aug 02 15:41:45 so your LIC_FILES_CHKSUM has just file://COPYRIGHT in a LIC_FILES_CHKSUM,? Aug 02 15:41:49 why do I need for the other one? Aug 02 15:41:50 yes Aug 02 15:41:54 ;md5... Aug 02 15:41:58 without WORKDIR Aug 02 15:42:07 that's a relative path, so the implicit base is $S Aug 02 15:42:14 which is WORKDIR/PN-PV by default Aug 02 15:42:18 which is why its looking where it's looking Aug 02 15:42:26 but that's not where the file went Aug 02 15:42:45 so your LIC_FILES_CHKSUM needs to be file://${WORKDIR}/COPYRIGHT Aug 02 15:43:17 (because it's not in $S, which is the default) Aug 02 15:45:02 lpapp: did that help? Aug 02 15:47:52 Hum... anyone know why when I try to run bitbake, I get stuck at "Parsing recipes: 99% |#...| ETA: 00:00:00" Aug 02 15:48:10 (this is w/ danny) Aug 02 15:49:20 and I end up with a couple of zombie python processes Aug 02 15:50:04 rburton: I think it would be simpler if we did not always need to put WORKDIR in there. Aug 02 15:50:06 Garibaldi|work: huh. try deleting build/cache Aug 02 15:50:23 lpapp: needing WORKDIR puts you in the 1% of recipes Aug 02 15:50:34 99% of the time, you're checksumming a file in an extracted tarball Aug 02 15:50:48 which is why the root for relative paths is $S Aug 02 15:50:48 rburton: all our custom files are like this though. Aug 02 15:50:57 lpapp: that's fine, use ${WORKDIR} Aug 02 15:51:06 I would not like to, in the future Aug 02 15:51:54 the alternative is to use ${WORKDIR} as the default, and fix 728 mentions in oe-core Aug 02 15:52:16 rburton: didn't help :-( Aug 02 15:52:23 lpapp: there has to be a default root for relative paths, and the one that works for 700 mentions is preferable to the one that works for about 9 mentions Aug 02 15:52:25 rburton: I think there should be an in-between solution. Aug 02 15:52:27 Garibaldi|work: huh Aug 02 15:52:38 rburton: btw, if I do not use do_compile/install Aug 02 15:52:43 apparently nothing gets built. :( Aug 02 15:52:50 even though the default "make" should be fine! Aug 02 15:53:22 lpapp: the default do_compile will run make if it can find a normal makefile Aug 02 15:53:27 lpapp: but you'll need to install yourself still Aug 02 15:54:08 rburton: I do not even find a binary in the work dirt. Aug 02 15:54:10 dir.* Aug 02 15:54:35 lpapp: check the log, it will either show you it running make, or saying "nothing to compile" Aug 02 15:54:36 lpapp: Almost all open source projects that provide a LICENSE or COPYING file have that file reside in the "top-level" of their source tree, which is ${S} in oe-core, therefore our default lookup path for the LIC_FILE_CHECKSUM is to be relative to ${S} Aug 02 15:54:43 lpapp: if that happens then it couldn't find the makefile Aug 02 15:55:17 sgw_: yes, so? Aug 02 15:55:19 lpapp: (base.bbclass has the default functions) Aug 02 15:55:28 sgw_: I would like to have the option to simplify my job. Aug 02 15:55:48 rburton: where is the log file? Aug 02 15:55:55 lpapp: workdir/temp/ Aug 02 15:56:01 heh, I hate our automatic "magic" we put in place to try to keep recipes small. it would have been better to have the base bbclass do_compile error out indicating hte user has to do something, and then add a make class, then it'd at least be explicit, and you woudln't get into a case where oyur software didn't build, but do_compile succeeded, and no package is produced Aug 02 15:56:14 oh well, a bit late to do much about that Aug 02 15:56:22 kergoth: i've long suspected a "make" class is needed Aug 02 15:56:46 rburton: yeah, but which file? Aug 02 15:56:55 our default EXTRA_OEMAKE is anothe rpet peeve of mine, even though i'm the one that created it Aug 02 15:57:00 the -e stuff is.. ugh Aug 02 15:57:26 lpapp: the log files are the ones called "log.*". then the name reflects the task that was running. Aug 02 15:58:14 rburton: no compile task. Aug 02 15:58:56 log.do_cleanall log.do_cleanall.17386 log.do_cleansstate log.do_cleansstate.17385 log.task_order run.do_cleanall.17386 run.do_cleansstate.17385 Aug 02 15:59:34 might be best to see your recipe then Aug 02 16:00:15 rburton: nothing after SRC_URI Aug 02 16:00:23 as the usual make && make install is sufficient. Aug 02 16:00:29 I should have no code for default stuff. Aug 02 16:00:37 "make install" isn't "usual", so you'll have to code that Aug 02 16:00:48 as i said, see base.bbclass for the defaults. Aug 02 16:00:51 that sounds bad Aug 02 16:00:54 no, it doesn't Aug 02 16:00:59 yes, it does. Aug 02 16:01:40 actually any package manager I have used managed to put everything into the package by default. Aug 02 16:01:47 without explicitly specifying. Aug 02 16:01:59 Yocto is the first weird stuff not following that. Aug 02 16:02:04 * rburton shrugs Aug 02 16:02:34 sounds like a feature request. Aug 02 16:02:38 an important one. Aug 02 16:02:39 dpkg doesn't by default. if you tell it you're using "automake" it will. Aug 02 16:02:43 just like oe Aug 02 16:03:05 dpkg actually does. Aug 02 16:03:07 lpapp: there isn't a universal way of doing re-rooted installs, so there really isn't much point Aug 02 16:03:23 there is much point. Aug 02 16:03:29 to avoid the boilerplate hell. Aug 02 16:03:33 one line. Aug 02 16:03:51 it does not matter how many. Aug 02 16:03:53 anyway, kernels to kick Aug 02 16:03:59 if it can be automated, it should be. Aug 02 16:04:13 also, even compile does not work off-hand. :( Aug 02 16:05:29 what boilerplate do people need to put into do_compile to do the default stuff? Aug 02 16:05:31 "make"? Aug 02 16:08:01 * lpapp is currently blocked due to this Aug 02 16:08:18 the default do_compile calls make. you can see the logic in base.bbclass. Aug 02 16:08:42 why is it not working then? Aug 02 16:09:02 the most common cause of do_compile doing nothing when you have a makefile is having S set incorrectly (or the default doesnt match reality), or you're trying to build something autotools and forgot to inherit autotools, so no makefile was created Aug 02 16:10:15 how can I get more verbose stuff from bitbake for this? Aug 02 16:11:46 temp/ is useless Aug 02 16:11:52 and temp/../foo/ is empty. Aug 02 16:12:43 wow, COPYRIGHT files have different checksums, as in really? Aug 02 16:12:45 that reminds me, we shouldn't be auto-creating S if it doesn't exist. better to fail uot with a 'this path we looked for doesn't exist, aiee' than to create and use an empty directory, and end up doing nothing quietly Aug 02 16:13:25 "No generic license file exists for: Propriate in any provider" -> what is this warning? Aug 02 16:14:29 bitbake foo -c cleanall -> does not rebuilt it either. Aug 02 16:14:34 what is going on? o_O Aug 02 16:16:30 so what more can I do? Aug 02 16:16:55 if I run make on the host, it just works Aug 02 16:17:20 does it uncompress the tar.xz at all? Aug 02 16:17:24 how can I make sure? Aug 02 16:17:43 lpapp: look in the workdir? Aug 02 16:17:51 ? Aug 02 16:17:57 what do you think I have been doing? Aug 02 16:18:11 lpapp: what do you have in there? Aug 02 16:18:32 see above, nothing, really. Aug 02 16:18:41 an emptyfolder and a few useless temp/ entries. Aug 02 16:18:48 empty folder* Aug 02 16:18:57 tar.xz is not supported?! Aug 02 16:19:06 kind of sounds like it has not been unpacked Aug 02 16:20:00 why does it not support .tar.xz? Aug 02 16:20:20 tar xvpf just uncompresses it fine. Aug 02 16:21:42 and even if it does not support that, shouldn't it complain? Aug 02 16:23:20 also, why do I get a license warning here and not for other packages with the exactly same COPYRIGHT file?! Aug 02 16:23:29 this is all chaotic. :-) Aug 02 16:24:02 lpapp: it most certainly does support tar.xz; if you look you'll see a number of recipes that point to tar.xz files Aug 02 16:24:21 lpapp: the license warning is based upon the value of LICENSE not LIC_FILES_CHKSUM Aug 02 16:46:31 Is there a way to specify one file that should not be stripped? without either debug symbols for or an unstripped copy of libthead_db.1.so Aug 02 16:46:56 core files from a system are highly likely to not be able to get all thread information. Aug 02 16:47:17 Place that file on the end system and all crash dumps are able to be debugged in all threads. Aug 02 16:47:25 have you tried installing the debug package? Aug 02 16:47:58 ie, foo-dbg for whatever you're trying to debug... Aug 02 16:48:47 Of course the system debugging the crash has the debug symbols. The system producing the core (think end user crash dump analysis) seems to also need that one file. Aug 02 16:49:30 and what you need isn't in another -dbg package? Aug 02 16:50:10 bluelightning: I looked yesterday, however that is the only reason I can come up with. Aug 02 16:50:13 otherwise i think it would take some jiggering of the recipe Aug 02 16:50:17 Seems it is a problem with the way threading is done. However, without an unstripped version of that file ulimit -c unlimited and then sftping the resulting core when the dump is seen ends up with a dump with only one thread. Aug 02 16:50:32 bluelightning: but you are of course more than welcome to suggest alternative bug options. Aug 02 16:50:56 lpapp: without seeing the recipe itself I can't tell what might be going on Aug 02 16:51:09 mr_science, so are you saying install the debug symbols on the system doing the debugging or install them on the end device? Aug 02 16:51:10 bluelightning: I pretty much pasted the recipe here already. Aug 02 16:51:31 blloyd: in some case it seems like you need both Aug 02 16:51:32 LICENSE = "Propriate" Aug 02 16:51:39 what should that contain instead? Aug 02 16:51:57 though i am not the remote debugging expert... Aug 02 16:52:16 lpapp: "Proprietary" or "CLOSED" Aug 02 16:52:28 lpapp: note that CLOSED will completely disable LIC_FILES_CHKSUM Aug 02 16:52:30 still need to work through and document some of that stuff for our current classic build... Aug 02 16:53:03 bluelightning: too bad it is not documented. Aug 02 16:53:18 lpapp: it was last I checked Aug 02 16:53:37 it's a limitation of gcc, and it's dealing exclusively with the libthread.so.debug file. gcc can't use a copy that doesn't have symbols available. Aug 02 16:53:42 blloyd: see if installing the -dbg packages to your (non-target) sysroot does what you need Aug 02 16:53:55 bluelightning: not in the reference, nor in the development manual. Aug 02 16:53:56 lpapp: yep, in the reference manual in two separate places Aug 02 16:53:59 not in the current. Aug 02 16:54:00 nope Aug 02 16:54:03 it doesn't. I already have the dbg symbols Aug 02 16:54:04 lpapp: yep Aug 02 16:54:14 blloyd: in both places? Aug 02 16:54:27 lpapp: 3.4.1.1. Specifying the LIC_FILES_CHKSUM Variable and the variable glossary entry for LIC_FILES_CHKSUM Aug 02 16:54:29 bluelightning: not in the current, no. Aug 02 16:54:33 lpapp: yes in the current Aug 02 16:54:49 bluelightning: nope Aug 02 16:55:06 could you please show where Proprietary is mentioned? Aug 02 16:55:08 I must be blind. Aug 02 16:55:09 for everything. For target, I can add the single file. Already discussed with gcc group. Basically, they suggest putting the symbols back into that file. Aug 02 16:55:19 lpapp: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#usingpoky-configuring-LIC_FILES_CHKSUM Aug 02 16:55:40 bluelightning: I do not see the word there. Aug 02 16:55:44 can you paste the sentence? Aug 02 16:55:47 lpapp: Proprietary isn't but then there's not any special behaviour associated with it Aug 02 16:55:49 Thus my question: is there a way to say don't strip this file? I missed it if there is. Aug 02 16:55:51 blloyd: then it sounds like you need a new recipe to build/install an unstripped version Aug 02 16:55:53 lpapp: unlike CLOSED Aug 02 16:56:10 bluelightning: then why do you recommend something without special meaning? Aug 02 16:56:14 I need a special meaning. Aug 02 16:56:31 blloyd: yes there is, but i don't think it soes just a single file Aug 02 16:56:36 clearly, Propriate and Proprietary are not the same, so some special meaning has to be there. Aug 02 16:56:39 *does Aug 02 16:57:21 sounds like a bugreport entry. Aug 02 16:57:27 recipe wide, or PACKAGES wide? Aug 02 16:57:30 lpapp: I assumed that "Propriate" was a mistake and what was meant was "Proprietary"; which happens to be a convention that some use Aug 02 16:57:31 you can specify nostrip in a recipe, not sure if there's a way to nostrip a single lib Aug 02 16:57:33 also, how can I debug the uncompression issue? Aug 02 16:57:51 lpapp: I'd be looking at log.do_unpack Aug 02 16:57:59 anyway I have to go in about 5 seconds Aug 02 16:58:44 blloyd: one sec, looking at the busybox recipe Aug 02 16:59:55 blloyd: there is nothing like that. Aug 02 17:00:00 blloyd: sorry about that. Aug 02 17:00:21 rburton: what can I check in for the CI to have the proper bblayers.conf thingie? Aug 02 17:00:37 without our own layer, there was nothing to be checked in before, and that made the CI generate correct stuff. Aug 02 17:00:43 but we cannot use default anymore. Aug 02 17:00:54 and my checked in layers conf is well ... /home/lpapp/etc... :) Aug 02 17:03:29 blloyd: try this Aug 02 17:04:19 in the recipe use PACKAGE_STRIP = "no" Aug 02 17:04:24 rburton: some bitbake variable to the conf path? Aug 02 17:04:31 or at least to the build folder path? Aug 02 17:04:38 mr_science: hi, how are you Aug 02 17:04:43 mr_science: what is the situation with nginx Aug 02 17:04:48 you could try PACKAGE_STRIP_package-name = "no" and package that single file separately Aug 02 17:05:37 seems kinda weird to have to do that, so maybe i'm missing something... Aug 02 17:06:26 lpapp: haven't had a chance to build it yet, but hopefully i'll have a working version in my rpi layer this weekend Aug 02 17:07:09 ls Aug 02 17:07:19 gah, sorry Aug 02 17:07:24 looking for vorlons? Aug 02 17:07:36 :-) Aug 02 17:09:30 lpapp: i'll do it as a single commit so it should be easy to cherry-pick, format a patch, etc Aug 02 17:17:09 mr_science: I wanted to do it today. Aug 02 17:17:18 mr_science: but if you can do it this weekend, that is better. Aug 02 17:17:24 I can concentrate on other stuff. :p Aug 02 17:17:55 yeah, i gotta make an upgrade and re-release our hardware test image Aug 02 17:18:19 good luck to that. Aug 02 17:18:20 so tomorrow is way better for that stuff... Aug 02 17:18:28 take your time. Aug 02 17:18:40 I will not do anything at the weekend other than playing music anyway. :) Aug 02 17:19:06 i need to put on some new strings Aug 02 17:19:26 thanks for reminding me i have more stuff to do... ;) Aug 02 17:19:48 guitar? Aug 02 17:19:56 nothing else before coffee tho... Aug 02 17:20:38 yeah, i haven't done much lately but i bought a used ovation from one of the quality guys Aug 02 17:24:13 anyone here knowing if there is a bitbake variable holding the path to the build folder or the config folder in the build dir? Aug 02 17:24:22 to put that into bblayers.conf Aug 02 17:24:32 or even the poky project root, etc? Aug 02 17:24:39 so that it can work on any machine after a checkout? Aug 02 17:29:34 is there a page somewhere with the bitbake variables? Aug 02 17:30:17 of course I could use $PWD/../../meta-foo or so, but $PROJECT_ROOT/meta-foo would be neater Aug 02 17:32:11 lpapp: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-variables-glos Aug 02 17:33:01 sgw_: thanks. Aug 02 17:33:12 I actually think that mentioning a path is pretty useless in there. Aug 02 17:33:25 why doesn't it just take the meta-foo stuff? Aug 02 17:33:32 it is very unlikely people will refer outside poky... Aug 02 17:40:15 TOPDIR Aug 02 17:40:16 This variable is the Build Directory. BitBake automatically sets this variable. The OpenEmbedded build system uses the Build Directory when building images. Aug 02 17:40:26 this is almost good, but it would be nice to get the one upper, i.e. projectroot. Aug 02 17:45:31 ${TOPDIR}/../meta -> so, that is the best I can come up with, but it is still ugly. :-) Aug 02 17:53:36 s/friday/fartday/ Aug 02 17:54:09 did i say that out loud? Aug 02 17:54:29 I would even claim that if I do not specify a path, it should pick up from the "default". Aug 02 17:54:42 the oe script will know what the project root is after all. Aug 02 18:21:59 rburton: I'm still stuck on this problem with bitbake hanging on 'parsing recipes' at 99% with 00:00:00 remaining Aug 02 18:22:53 I threw --verbose and a few -Ds in there, and the last thing I see is DEBUG: BB .../core-image-base.bb:8: inheriging .../core-image.bbclass Aug 02 18:23:27 I did see: DEBUG: while parsing populate_sdk_ipk, unable to handle non-literal command '${POPULATE_SDK_POST_HOST_COMMAND}' Aug 02 18:23:48 but it's not clear to me that that's a failure Aug 02 18:25:02 and I get two python zombies that were once associated with the run Aug 02 18:27:04 and ctrl-C doesn't work Aug 02 18:27:12 I have to kill the python processes Aug 02 18:30:20 (or if anyone else has any ideas) Aug 02 18:31:32 hum, now I caused it and got no zombie processes Aug 02 18:31:40 but all of the pythong processes are in a Sleep state Aug 02 18:31:45 S+ or Sl+ Aug 02 18:35:11 lpapp: just for your unlikely case. I have a setup of parentdir/{poky,meta-mycompany,meta-testing}. Note it is OUTSIDE the poky for reference to two metas. I also put the build directory at /embeddedtmp, which is a separate disk, so TOPDIR has nothing at all in relation to the poky directory.... Aug 02 18:35:32 at should be under, oh, well. Aug 02 18:36:20 Garibaldi|work ya, I'e seen the same ctrl-c behavior in the past.. Aug 02 18:36:37 it was being worked on at one point, but with Richard on vacation, I'm not sure how much it's being looked at right now.. Aug 02 18:36:58 we're also trying to track/reproduce another problem that looks like bitbake is just hanging (appears to be waiting forever for a socket) Aug 02 18:37:11 but reproducing this is really difficult, and nothing we've done has been it reliably reproduced Aug 02 18:39:52 Garibaldi|work: master branch or another? Aug 02 18:49:06 this is danny Aug 02 18:49:42 what's killing me is I can't find the commit in my local repo where it started failing Aug 02 18:49:47 it's almost like it's something external Aug 02 18:51:30 it doesn't always stop at the same place either Aug 02 18:51:37 at least in terms of the debug output Aug 02 18:51:50 I guess it could be related to there being multiple processes Aug 02 18:52:03 let me try giving it just one process w/ one thread Aug 02 18:55:11 yeah, looks like it's still doing multithreading behind the scenes Aug 02 18:58:40 ahh, ya problems I'm having are all master Aug 02 19:10:35 i love our u-boot config... Aug 02 19:10:45 Autoboot in 1 seconds, type ctrl-C to interrupt Aug 02 19:10:53 gotta be quick... Aug 02 19:11:18 and no, i was not asked to grammar-check the output... Aug 02 19:22:31 speaking of which, my u-boot change did not enter the mailing list. :( Aug 02 19:22:46 it is dropped after git send-email if I am not subscribed? :( Aug 02 19:31:49 nice... Aug 02 19:32:13 * mr_science has found a new boot failure mode Aug 02 21:46:06 has anyone else notice bitbake responds terribly to ^C early on in the build process now that it restarts itself? Aug 02 21:46:17 hangs up and i ahve to ^Z and kill %1 and pkill -f bitbake to clean up the mess Aug 02 21:48:07 I have not been super happy with bitbake's ^C handling in general. I would, in general, prefer a best effort at "stop running now, that includes child processes". I virtually never want "please continue all the things you're doing now, just don't start new ones". Aug 02 21:48:42 agreed. Aug 02 21:48:48 end up just hammering ^C until it goes away Aug 02 21:49:16 And then there's still a ton of stuff running in the background, frequently. Aug 02 21:49:20 we've worked on it in the past, and changing the server to stop responding to ^C made things more deterministic, but the UI should do a better job of responding to it Aug 02 21:49:43 well, in the past bitbake itself did okay, but when it was spawned by the shell wrapper, it didn't always get the signal, in my experience Aug 02 21:49:46 * kergoth shrugs Aug 02 21:49:46 Basically, I don't object to an interrupt handler trying to do some sort of cleanup, but the cleanup's priority should be "kill everything as fast as possible" more than "shut down gracefully over time". Aug 02 21:49:49 Ahh, that would make sense. Aug 02 21:50:15 i had a script that called bitbake and tried to respond gracefully, i had to make the fscking thing try to forcibly kill it and every child it had open at hte time Aug 02 21:50:18 heh Aug 02 21:50:40 https://github.com/kergoth/oe-test-scripts/blob/master/bb_test.py#L48-L62 Aug 02 21:50:59 i should have checked advanced programming in the unix environment to freshen up though Aug 02 21:51:02 he Aug 02 21:51:05 h Aug 02 21:53:02 seebs: heh, i think python's treatment of the signal as an exception is not ideal. what good is an exception that can show up anywhere, at any time? kind of a pain to handle without making it racey before / after the handled block Aug 02 21:53:55 course, you can have the same concerns with a signal handler, so many it's not an issue, though its more common to 'handle and recover' from exceptions than from an exceptional signal :) Aug 02 21:54:01 s/many/maybe/ Aug 02 21:54:08 * kergoth shrugs Aug 02 21:56:31 Signal handlers strike me as logically a genuinely global thing -- something where it makes sense to be able to specify at a high level that no matter what any other code thinks it might do with the signal, this code here gets it. Aug 02 21:56:48 Basically, exceptions arise from code execution and propagate up, signals arise externally and propagate down. Aug 02 21:57:51 generally you can only do certain things in a signal handler, its an entirely different context, hiding that behind a generic mechanism to cross that boundary seems questionable, if convenient Aug 02 21:57:55 anyway... Aug 02 21:57:56 heh Aug 02 21:58:31 i think interruption of the initial bitbake psuedo build before its self restart seems to cause problems. it doesn't always stop the second build from running, as though something swallowed the interruption entirely Aug 02 21:58:44 * kergoth 'll have to open a bug Aug 02 22:25:09 kergoth: if it's not too late to jump in on the signal handling topic... i think i would be nice if there were better handling for ^Z (SIGTSTP) too Aug 02 22:25:58 it would be nice if ^Z stopped the build immediately instead of the "keep doing what you're doing, just don't start anything new" behaviour (IMHO) Aug 02 22:29:10 you'd think itd propogate the stop down to its children Aug 02 22:35:22 from the cmdline it _looks_ like ^Z stops the build, but looking at the processes (and CPU usage) you can tell the current tasks are still working away Aug 02 22:37:02 * kergoth nods Aug 02 22:37:20 at a guess, it stops the UI, since the UI is still attached to the tty, but the forked off server process continues along merrily Aug 02 22:37:30 * kergoth shrugs **** ENDING LOGGING AT Sat Aug 03 03:00:00 2013