**** BEGIN LOGGING AT Wed Jun 17 02:59:59 2015 Jun 17 05:24:56 RP: are you the one to ping about backporting a build fix in fido? (http://lists.openembedded.org/pipermail/openembedded-core/2015-June/105964.html) Jun 17 07:59:50 erbo: joshuagl is the person you want for fido Jun 17 08:01:52 zuz: sounds like you have gcc 5 on your build system which is known to have issues with fido :/ Jun 17 08:19:46 hi, quick question: what is the best way to make a minor change to the kernel source and rebuild the kernel and image, without overwriting the edits with a fetch? Jun 17 08:20:06 i just need to put some debug prints in a driver, and don't want to build a patch etc Jun 17 08:32:27 <_4urele_> ionte, when i need to test some lines, i modify directly the tmp/work/*/linux-*/git/.../ Jun 17 08:33:20 <_4urele_> ionte, then I launch bitbake -f -c compile Jun 17 08:33:52 <_4urele_> ionte, then you can bitbake your image again, it will update the kernel and build a new image Jun 17 08:34:51 morning all Jun 17 08:35:04 <_4urele_> hi bluelightning Jun 17 08:41:01 _4urele_: thanks! Jun 17 08:42:09 hello everyone Jun 17 08:42:30 I have a problem whilst building the minimal image: http://paste.pound-python.org/show/ZaiH9WDA6bDLKnAawbYS/ Jun 17 08:42:41 could somebody take a look and help to resolve this issue? Jun 17 08:43:32 437 line Jun 17 08:44:55 Ox4: looks like meta-sourcery is broken for your usecase Jun 17 08:51:02 LetoThe2nd: ok, I will try to switch to the more stable version Jun 17 08:52:12 LetoThe2nd: thank you Jun 17 09:10:42 RP: yes my hunch is it's the reorganization of tc- libs in ncurses Jun 17 09:11:09 Good news is GCC 5.1.0 works fine with master as of June 15 Jun 17 09:14:14 wow Jun 17 09:14:21 as I see they have sourcery-sstate-fixes branch Jun 17 09:50:24 I have another one issue: http://dpaste.com/199CRW8.txt Jun 17 09:54:11 Hi! I'm stuck with kernel compilation on Yocto. I need to use gcc-4.4 to compile kernel 2.6.32.13 but poky-daisy seems to use an other gcc version. Any clue on how to solve this ? Jun 17 09:54:52 Hi ! I would like to use my own recipes-devtools (binutils-cross, gcc-cross , etc). So i override binutils-cross_2.25.bb by a .bbappend file. It fetch my own files & directory on /git pointed by S variable. But just before to do do_configure() It seems that inherits autotools ("i'm not sure") override some files ( config.guess config.sub autom4te.cache/) . Do you have any suggestion ? I will try to patch it, seems good ? Jun 17 09:56:37 <_4urele_> mie_, if i understood well this is normal, I think do_configure, reconfigure everything:) Jun 17 09:57:20 <_4urele_> so it replaces "config.guess config.sub autom4te.cache/, configure"... and so on (if i'm not wrong Jun 17 09:57:43 _4urele_: yes Jun 17 09:57:55 dbozec: you shouldn't need such an old gcc - just patch your kernel so it can build properly with a recent gcc Jun 17 09:59:03 <_4urele_> mie_, maybe you should modify your configure.ac? Jun 17 09:59:11 bluelightning: I'm importing an old project in Yocto, so I got the kernel archive on kernel.org. Where can I find such a patch ? Jun 17 09:59:59 dbozec: you would need to look through the kernel.org kernel commits for changes relating to gcc from 2.6.32.13 onwards Jun 17 10:00:54 bluelightning : thank you, I'll take a look on that Jun 17 10:00:56 dbozec: if it's for ARM you will need these two at least: http://lists.openembedded.org/pipermail/openembedded-core/2015-April/104352.html Jun 17 10:01:20 bluelightning : no, it's for i386 Jun 17 10:01:25 ah ok Jun 17 10:01:33 should be a bit simpler then AIUI Jun 17 10:03:27 ok, thank you Jun 17 10:03:56 fortunately 2.6.32 is in fact the oldest that recent glibc will support ;) Jun 17 10:05:17 although that's for glibc 2.20+ so that wouldn't be a factor until after dizzy IIRC Jun 17 10:05:39 the idea is to import the actual project with 2.6.32 then to move to a newer kernel version in the next months :) Jun 17 10:06:29 fair enough :) Jun 17 10:55:42 RP: thanks! Jun 17 10:56:12 joshuagl: have you seen http://lists.openembedded.org/pipermail/openembedded-core/2015-June/105964.html ? Jun 17 10:58:12 erbo: yup, I even have a partial reply drafted somewhere in this stack of windows Jun 17 10:58:18 :) Jun 17 10:58:21 erbo: already queued in my fido-next branch http://cgit.openembedded.org/openembedded-core-contrib/commit/?h=joshuagl/fido-next&id=cb25b8ffc531e1deb7eaf087aba56ffea3638fa0 Jun 17 10:58:32 ah, awesome. thanks! Jun 17 10:58:58 np. Just need to get a succesful autobuilder run before I request a merge Jun 17 11:59:13 Hi all Jun 17 12:01:49 Using the meta-intel and I'm having issues with and old celeron/M unit. Which is the best way to build a bsp based for this unit? use the tune-i586.inc/x86-base.inc instead the intel-core232-common.inc? Jun 17 12:08:39 <_4urele_> hi all Jun 17 12:09:08 <_4urele_> is it possible to build a package without installing it (just building the rpm for example) Jun 17 12:11:08 <_4urele_> I mean automatically like with "IMAGE_INSTALL" Jun 17 12:13:19 bitbake [recipe] Jun 17 12:15:21 <_4urele_> rburton, i knew someone will say this I would like to add some packages to rpms during the build (some tools like valgrind gdb and so on) Jun 17 12:15:59 bitbake myimage my-package-group-that-lists-everything-id-like-to-build Jun 17 12:29:16 <_4urele_> rburton, ok thx rburton Jun 17 12:30:09 if you don't actually want a packagegroup to be created for runtime use, you can "inherit meta" and set DEPENDS to point to the recipes to be built instead Jun 17 12:32:32 <_4urele_> bluelightning, thx! looks like what I was looking for Jun 17 12:41:50 bluelightning: I continue to wonder if that class should exist... Jun 17 12:42:23 RP: we don't use it like this in the core, but I can see it being useful for this use case Jun 17 12:43:28 i.e. if you have more than a few things you want built, perhaps for populating a feed, and would rather not have to explicitly mention them all on the command line Jun 17 12:46:37 bluelightning: agreed, I've just never liked the name of that class Jun 17 12:49:36 RP: right, perhaps "recipegroup" ? Jun 17 12:50:40 hmm, what is the best way to exclude certain binaries from the generated SDK? Jun 17 12:50:56 some binaries that go into the image are not necessary to build applications with the platform. Jun 17 12:51:00 hi Jun 17 12:51:45 bluelightning: ooh useful Jun 17 12:54:56 such metaness Jun 17 12:57:13 hi guys, have anyone tried to add perl to yocto via meta/recipes-devtools/perl? Jun 17 12:57:28 bluelightning: yes, something like that would be better Jun 17 13:01:20 rburton: RP: news about the piglit fix? Jun 17 13:01:31 otavio: its in mut Jun 17 13:02:21 rburton: it should be send upstream, as well Jun 17 13:02:35 rburton: are you in touch with the maintainer? Jun 17 13:03:39 after creating the rootfs the modules for perl such as GetOpt.pm are missing. what must i do to include this modules in my build/rootfs? Jun 17 13:04:37 ueni: perl-modules will pull them all in Jun 17 13:05:08 thank you. i will try that Jun 17 13:13:00 pidge, halstead_: Just posted a patch to python which gives a 25% parsing speedup. We might have to consider that for the autobuilder and using a standalone python tarball... Jun 17 13:13:18 it likely speeds up do_package too Jun 17 13:25:14 RP: we can get it installed when we get a buildtools build with the patch Jun 17 13:31:48 pidge: Looks like my test was flawed, the fast python is actually the ubuntu one and ours is a lot slower. Now I want to know why... Jun 17 13:31:59 otavio: done already :) Jun 17 13:32:26 rburton: ? merged? Jun 17 13:33:33 otavio: upstream, yes, and patch in mut updated Jun 17 13:33:36 * rburton goes Jun 17 13:54:33 anyone any idea for my question? :) Jun 17 13:56:21 <_4urele_> lpapp, write an image recipe, and a new distro if needed? Jun 17 13:56:45 <_4urele_> which image are you using? Jun 17 13:57:47 lpapp: there was a thread here relating to this: https://lists.yoctoproject.org/pipermail/yocto/2015-June/025115.html Jun 17 13:58:00 short answer is it's complicated Jun 17 13:58:26 having said that the poster was experiencing behaviour that wasn't immediately explainable Jun 17 14:46:35 bluelightning: it is very important for me Jun 17 14:46:45 bluelightning: I do not want to give proprietary binaries with the SDK Jun 17 14:46:59 those our apps, but others can develop software based on our platform Jun 17 14:47:05 it would only be that, but also licensing issues Jun 17 14:47:13 so I really want to get rid of certain apps that we wrote. Jun 17 14:47:24 and provide only the libraries that we wrote and meant for application developers. Jun 17 14:47:33 lpapp: PACKAGE_EXCLUDE_COMPLEMENTARY ought to provide what you want there I would think Jun 17 14:47:39 _4urele_: custom image, based on core-image-minimal Jun 17 14:47:43 or whichever the smallest is :) Jun 17 14:48:16 we don't have anything else for filtering the contents of the SDK right now that I know of Jun 17 14:49:22 lpapp: the other very straightforward solution is you simply create a separate image that does not have the items in it that you don't want, and use that as your image target when building the SDK Jun 17 14:57:50 bluelightning: any near future plans to improve this? Jun 17 14:59:23 lpapp: it's pretty much the first time someone has asked about it, so I don't think anyone had thought it was needed... Jun 17 14:59:42 lpapp: is there a reason why a separate image recipe won't work? Jun 17 15:03:05 bluelightning: too much work Jun 17 15:03:27 I guess the easiest option would be to be able to exclude packages, no? Jun 17 15:04:37 er - even if all that recipe does is require your original one and uses _remove to remove the unwanted packages from IMAGE_INSTALL ? Jun 17 15:05:09 PACKAGE_EXCLUDE_COMPLEMENTARY effectively does that, but of course it will not help you if there is a dependency pulling in the package Jun 17 15:12:05 bluelightning: remember that we use daisy. Jun 17 15:12:39 lpapp: the separate image will still work there Jun 17 15:12:40 was that feature backported into 1.6.3? Guess not? Jun 17 15:13:35 PACKAGE_EXCLUDE_COMPLEMENTARY was in 1.6.3, as it happens Jun 17 15:16:15 cool Jun 17 15:39:52 bluelightning: have you got a ticket for documenting that variable? Jun 17 15:40:24 lpapp: probably not, it's on my own docs todo list I think Jun 17 15:41:06 you mean I shall not create one for you? Jun 17 15:41:30 sure, you can if you wish, but it will eventually get taken care of even if not Jun 17 15:41:59 ok, I will skip it then, just do not leave it out please :) Jun 17 16:05:16 bluelightning: I am still unsure if it is really that variable that I need. Jun 17 16:05:24 bluelightning: I would like to keep the binaries for the "normal" image. Jun 17 16:06:06 Also, I would not know how to use that variable. I cannot find an example for it in daisy. Jun 17 16:07:20 lpapp: then you are not on 1.6.3 Jun 17 16:07:25 use a separate image Jun 17 16:07:30 it's the simplest solution Jun 17 16:07:55 I am on 1.6.3. Jun 17 16:08:07 I can see ../meta/lib/oe/package_manager.py:522: exclude = self.d.getVar('PACKAGE_EXCLUDE_COMPLEMENTARY', True) Jun 17 16:08:11 but I cannot see /example/ use. Jun 17 16:08:15 right, then support for it is there Jun 17 16:08:15 this is the implementation. Jun 17 16:08:30 no, you wouldn't expect any, it's not required for anything in OE-Core Jun 17 16:09:20 I will have some difficulty to use it then :) Jun 17 16:09:22 I'll grant you it's undocumented but we've discussed that Jun 17 16:09:33 it's a straight list of packages, just like IMAGE_INSTALL Jun 17 16:09:48 brb Jun 17 16:10:03 but that means the normal image would be truncated, too? Jun 17 16:13:45 if so, does that mean that I have to create an SDK recipe separately from the image? Jun 17 18:02:33 bluelightning: ? Jun 17 18:05:19 must've missed your last message sorry Jun 17 18:05:29 unfortunately I need to leave to get my train, should be back later Jun 17 18:05:40 have a nice ride home Jun 17 18:29:42 what's the proper way to handle out-of-tree kernel module recipies? is there an existing meta-something where such would land? Jun 17 18:55:45 any idea why devicetree is built for kernel 3.16 with meta-raspberrypi (fido), even though it should be disabled by default for all kernels before 3.18?? Jun 17 19:02:10 RP: that 'no such file or directory' issue, it was indeed the missing depends. https://gist.github.com/kergoth/92bbcf3129181dca22dc or similar might be worthwhile to avoid the long traceback with no info about what the first fakeroot task is (the culprit) Jun 17 19:02:28 hello there any one currently active? Jun 17 19:04:10 active? Jun 17 19:05:15 https://github.com/MentorEmbedded/meta-sourcery/blob/master/classes/package_qa_sourcery.bbclass was the culprit — had the fakeroot flag set without the necessary dependency Jun 17 19:05:28 https://github.com/MentorEmbedded/meta-sourcery/pull/77/files fixed it Jun 17 19:07:54 kergoth: i was going to say, we should fix the core so the dependency gets generated automatically surely Jun 17 19:08:54 that would be nice, yes, i thought about that too, just not sure how it'd be best implemented Jun 17 19:10:50 hmm Jun 17 19:12:35 'fakeroot-provider' or something like that, then just add that dep? Jun 17 19:47:29 Hmm, I should add a check like https://github.com/MentorEmbedded/meta-sourcery/blob/master/classes/package_qa_sourcery.bbclass but against the rootfs after its constructed, via a postprocess hook, to immediately spot the ownership issues introduced by postinsts Jun 17 19:49:56 kergoth: yes, and you should send that other test to oe-core too :) Jun 17 19:50:36 yeah, planning on it. the only reason its' in meta-sourcery is I kept getting nailed by the external recipes cp -a'ing external files in without sanitizing the ownership :) Jun 17 20:24:54 rburton: can piglit patch to be merged today? Jun 17 20:25:58 otavio: my MUT broke in interesting ways, constructing a subset for the AB to test now actually (with the piglit fix in) Jun 17 20:26:31 rburton: ok; I am awaiting for this to be able to get master-next fully build here Jun 17 21:52:28 RP or halstead_, around? I would like to upload a shiny new layer to contrib so I can show it off to the list and such. Jun 17 21:52:49 Thanks to a very clever friend, I have renamed the bootloader manager to "bootlace", so the layer is now meta-bootlace. Jun 17 21:53:19 seebs, I'm around. What do you need in order to push the layer? Jun 17 21:54:03 Mostly a clue. I don't think I've added a layer to the git server before and don't know whether I need special permissions or something. Jun 17 21:57:39 seebs, As far as I know you can just push to poky-contrib if you want to put the code up there. If you want a new repo at http://git.yoctoproject.org you need to request it via e-mail to RP. (CC me) Jun 17 21:58:25 Does it ever become a problem that lots of totally unrelated trees end up in poky-contrib? Jun 17 21:59:50 I never look there since I do not use Poky Jun 17 22:00:52 seebs: it can be mildly annoying but we'd just do a pruning cycle... Jun 17 22:01:03 Fair enough. Jun 17 22:01:30 seebs, Yeah we eventually move them to http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib-archive/ if they aren't active to keep the size down. Jun 17 22:02:36 Okay, pushed there for now so people can see it and discuss it. **** ENDING LOGGING AT Thu Jun 18 02:59:59 2015