**** BEGIN LOGGING AT Mon Dec 07 02:59:58 2015 Dec 07 07:48:23 I setup a build in Jenkins, and Package Versions are going backwards. What is the Proper way to handle versioning in this case? Dec 07 07:50:33 I have set PRSERV_HOST = "localhost:0" in my local.conf, and I build on the same machine as Jenkins and one other dev. Perhaps that is the issue? Dec 07 07:50:39 Oh, and good morning. Dec 07 09:48:43 tasslehoff: localhost:0 means run a PR server instance on the fly... with a local database Dec 07 09:49:30 tasslehoff: you have buildhistory enabled right? presumably that's how you're determining the version is going backwards? Dec 07 09:50:48 bluelightning: I did not know I had it, but bitbake -eee says I do :) Dec 07 09:51:23 bluelightning: is that server then only for my builds in the current working copy, or shared be the different users on the same machine? Dec 07 09:51:35 tasslehoff: the former Dec 07 09:51:48 tasslehoff: are you perhaps sharing the buildhistory directory between those builds though? Dec 07 09:52:10 if so it would account for the errors Dec 07 09:53:40 bluelightning: no, but I'm building for two different machines. can't see anything else that could cause it. Dec 07 10:02:52 hi; I'm currently dumbfounded: bitbake that used to work now complains about no valid MACHINE being set, although I both export the right machine, and have it in my build/conf/local.conf Dec 07 10:02:57 any idea? Dec 07 10:04:07 missing layers where this machine is defined? Dec 07 10:04:48 fsdun: that's why I stressed the "used to work" part :( Dec 07 10:05:31 you might use bb to show MACHINE Dec 07 10:05:42 fsdun: can you give me a hint on how to do that? Dec 07 10:08:03 bitbake -e |grep ettus-e300 (which is my MACHINE) shows a lot Dec 07 10:19:09 funkylab, https://github.com/kergoth/bb Dec 07 10:19:51 fsdun: bitbake -e | less and search for "unset MACHINE" Dec 07 10:20:13 then you'll find the history of how it has been set (or not set) Dec 07 10:22:32 fsdun: thanks! Dec 07 10:24:00 bluelightning's approach showed that machine is, in fact, set correctly Dec 07 10:24:01 hm Dec 07 10:39:04 fsdun: bitbakes now Dec 07 10:39:48 I thought the fix I had submitted for the oe-init-build-env script was upstreamed, because that file changed, but it wasn't. Dec 07 10:40:14 does anyone have an idea how to submit a patch to oe-core that has a higher probability of ending up in oe-core Dec 07 10:40:16 ? Dec 07 10:43:07 ah waiit Dec 07 10:43:15 maybe crofton just hasn't updated his branch Dec 07 10:43:21 which I'm using Dec 07 10:44:06 nope Dec 07 16:11:42 hello, are there any plans/examples of embedded pypy support in oe? Dec 07 16:23:38 hello, are there any examples/plans for embedded pypy support? Dec 07 17:07:26 try grep yet? Dec 07 18:53:19 to answer myself, it you don't want -dev -dbg packages, set PACKAGES explicitly ... Dec 07 18:59:14 out of curiosity, why would you not want them? not shipping any binaries? Dec 07 19:04:36 kergoth: I am creating recipes from a remote debian repository, so I have separate recipes for say libc and libc-dev Dec 07 19:05:17 that sounds like a horrible idea, but good luck :P Dec 07 19:05:23 kergoth: if libc create libc-dev itself as well, I have two of them... Dec 07 19:05:47 kergoth: why? Dec 07 19:06:57 trying to convert one distro into another is almost always a recipe for pain. naming conventions, etc are all different. metadata formatting is different, .. Dec 07 19:08:44 kergoth: depends a bit of the scope I guess, I just want to deploy applications without having to support multiple distros, since that scales badly... Dec 07 19:09:24 if you're trying to combine binaries from debian with anything built by us, that's even more likely to fail due to binary compatibility issues between distros Dec 07 19:10:55 kergoth: I only build the applications, toolchain and middleware is installed in the rootfs from a binary source Dec 07 19:14:39 kergoth: I should have placed a dot there: I only build the applications. The toolchain and middleware is installed in the rootfs from a binary source Dec 07 20:03:46 kergoth: fun, see https://github.com/jhofstee/meta-bin-deb/tree/master/meta-raspbian/install-raspbian-armhf Dec 07 20:05:02 ah, interesting. so the baseline of the system is raspbian from binaries, and then you build your stuff from source on top of that instead of the oe-core baseline? Dec 07 20:05:24 that does seem like an interesting approach, particularly if you're concerned about unnecessary rebuilds of the core, and don't nee dto rebuild any core components Dec 07 20:06:28 is that recipe construction manual or scripted? Dec 07 20:06:32 kergoth: exactly, and you only ship the application, the libraries themselves are not shipped, only build against... (so you get build time problems instead of runtime ones) Dec 07 20:06:58 kergoth: Dec 07 20:07:10 kergoth: I have a python script creating them... Dec 07 20:07:40 You could probably extend recipetool's create command to handle such a case Dec 07 20:07:55 just as another possibility Dec 07 20:11:39 kergoth: I am aware I can do many funny things, you could for example create them dynamically etc ... Dec 07 20:13:15 kergoth: but since this is not the most common thing to do, and I am not that familiar with python or OE internals I have a separate script at the moment creating bb files. A bit easier for the moment... Dec 07 20:14:01 jeroen_: I assume you are familiar with meta-debian already? Dec 07 20:15:26 moto-time: yes, but it has quite a different goal.. Dec 07 20:15:39 ok. Just checking ;) Dec 07 20:17:11 my goal is to deploy _applications_ with simple dependencies by reusing OE software meta's. I do _not_ want to change the debian image, just make it easy to ship application for them... Dec 07 20:19:24 their goals is to get old, but stable software and be able to customize them.. Dec 07 20:21:27 I'm curious if your approach can be extended to beagleboards :) Dec 07 20:25:24 kergoth: https://github.com/jhofstee/meta-bin-deb/blob/master/scripts/create_meta.py Dec 07 20:33:58 for the record the script is WIP and needs a fake apt config setup (I don't want target packages in my host). just to get an idea that it is not millions line of code to create them.. Dec 07 20:40:28 moto-timo: I guess so, it can also be extended to OE itself, read the generated packages back and only compile the additional applications instead of compiling everything... Dec 07 20:41:43 moto-timo: with an external toolchain and some host tools / libs, bitbake takes 3 min something to build a simple application for a given feed... Dec 07 20:42:22 jeroen_: interesting... I am starting to work on X15 support, but the base image is debian ;0 Dec 07 20:42:57 jeroen_: watching your project on github :) Dec 07 20:56:24 moto-timo: keep in mind that it is a pet project, AS IS and doesn't guarantee to do something useful or something at all ;) Dec 07 20:57:19 jeroen_: sounds just like mine :) **** ENDING LOGGING AT Tue Dec 08 03:00:16 2015