**** BEGIN LOGGING AT Mon Jan 27 03:00:00 2014 Jan 27 05:33:12 hi all i have build ubi and ext2 and tar.zx rootfs, when i use rootfs.ubi it is working fine but at the same time i used to create ubi manualy by passing this command but kernel get panic, please see http://pastebin.com/uGRhAwXq Jan 27 09:42:44 morning all Jan 27 12:04:00 there was some traffic in regards irssi recipe which I created first and then someone modified a bit Jan 27 12:04:09 I think it didn't eventually get pushed, am I right? Jan 27 12:04:25 didn't find it in neither poky/ nor meta-oe/ Jan 27 12:07:53 Xz: it was merged in meta-oe Jan 27 12:09:44 bluelightning: yeah, you are right - on master Jan 27 12:09:50 bluelightning: I was looking on dylan Jan 27 12:10:04 bluelightning: who do I talk to put it to dylan as well? Jan 27 12:10:43 bluelightning: as I remember you are responsible for poky's dylan, right? :) Jan 27 12:10:58 Xz: yes, but that's just OE-Core / bitbake, not meta-oe Jan 27 12:11:59 Xz: the meta-oe dylan maintainer is Eric Bénard Jan 27 12:12:43 Xz: you should post the patch that got merged with [dylan] in the subject to the openembedded-devel list and CC him Jan 27 12:13:21 bluelightning: I better note it down Jan 27 12:13:23 bluelightning: thanks Jan 27 12:15:27 bluelightning: adding '--subject=[dylan]' to git send-email does the job? Jan 27 12:24:00 Xz: --subject-prefix="dylan][PATCH" Jan 27 12:24:27 bluelightning: do you remember all that or use scripts? ^_^ Jan 27 12:24:44 Xz: usually I rely on my bash history ;) Jan 27 12:24:52 but that one I remember Jan 27 12:25:19 bluelightning: bash history can fool - especially if you switch between master/dylan branches Jan 27 12:25:29 bluelightning: but do not open that can of worms again Jan 27 12:45:58 Hi there! Jan 27 12:47:27 I've got a recipe for some X binary video drivers. It needs xserver-xorg-extension-extmod and xserver-xorg-extension-dbe but if I put it in the RDEPENDS of the recipe, they are not included in the image. What am I doing wrong ? Jan 27 12:56:07 Hello JaMa: the commit 775d77e482f1ea203c78003cccd2547075fd720f brakes my build (I don't have that particular version of gstreamer) Jan 27 12:57:05 is there any other way to handle the versions instead of hardcoding it in the DPENDS? Jan 27 12:57:36 (of course I can just revert that commit on my own branch, but wonder if others are seing this too) Jan 27 12:58:34 melonipoika: gstreamer-1.0 is in oe-core master. you should probably switch to meta-qt5 dora branch if you're not using it with oe-core master. Jan 27 13:02:37 thanks rburton, will try that Jan 27 13:09:14 melonipoika: yes as rburton says, meta-qt5/master is for oe-core/master Jan 27 13:09:46 if you want to use newer qt5 you need to make necessary adjustments to keep it compatible with your other layers Jan 27 13:10:40 for this specific case doing something like faad8d1df1aee67f9d1a7e9ea3c13f92d04baf8e in qtmultimedia would be nice if you're interested Jan 27 13:12:49 thanks JaMa. I am testing now whether dora branch works OK for us. We are using oe-core/danny Jan 27 13:13:01 will take a loog that in qtmultimedia Jan 27 13:17:12 OK, so dora branch doesn't build with my set up Jan 27 13:18:49 but 57709a4ee2213a3c352b9cedce1d4b16a1b35042 works OK. Will see if I can implement something like what was done in qtmultimedia for the qtwebkit recipe Jan 27 13:47:04 rburton: bluelightning hi Jan 27 13:47:14 so how do people manage the SDK for different software releases? Jan 27 13:47:35 how will they know which SDK "version" relates to a given software release for reproducability? Jan 27 13:47:56 different release branches in the software repository, and a checked in SDK version into that branch, and it would vary in different branches? Jan 27 14:58:24 is anyone on opensuse 13.1? Jan 27 15:28:17 halstead: ping Jan 27 16:03:12 is there any documentation available about wic? Jan 27 16:03:21 what happened to rburton and bluelightning ? :D Not working today? :d Jan 27 16:03:31 lpapp: busy working today Jan 27 16:03:36 ok. Jan 27 16:03:41 sadly, irc isn't my job. Jan 27 16:04:10 as for wic, the list has everything and if it isn't there, ask tom. Jan 27 16:04:45 list means? Jan 27 16:04:55 mailing list? Jan 27 16:05:00 some list in the documentation? Jan 27 16:05:06 list in the software itself? Jan 27 16:08:39 lpapp: there was an extensive post on the oe-core mailing list Jan 27 16:08:59 jackmitchell: I do not follow that list... have a link? Jan 27 16:09:01 wic is still _very_ experimental as far as I'm aware Jan 27 16:09:27 I don't, if you google wic oe-core something will probably come up Jan 27 16:10:15 so what is the point of it? Jan 27 16:10:19 to abstract out the bootloaders? Jan 27 16:11:08 > The name 'wic' comes from 'oeic' with the 'oe' diphthong promoted to Jan 27 16:11:09 > the letter 'w', because 'oeic' is impossible to remember or pronounce. Jan 27 16:11:11 heh, fum. Jan 27 16:11:13 fun.* Jan 27 16:11:43 lpapp: all in the email, I know nothing more than what is said there Jan 27 16:12:41 yes, but perhaps others know. Jan 27 16:12:47 AFAICT, the email I am reading does not explain it... Jan 27 16:14:09 the key is "experimental". if you're going to help hack on it, email tomz. if you're not, step away. Jan 27 16:15:54 well, I do not even understand what it tries to resolve. :) Jan 27 16:16:04 so naturally, I cannot contribute respectively. Jan 27 16:16:28 lpapp: http://lists.openembedded.org/pipermail/openembedded-core/2013-September/084821.html Jan 27 16:16:33 is that the email you are reading? Jan 27 16:16:58 !3847 Jan 27 16:17:05 !bug 3847 Jan 27 16:17:06 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3847 enhancement, High, 1.5.1, tom.zanussi, VERIFIED FIXED, New partitioning description and tooling Jan 27 17:01:22 when creating my image recipe, in which recipe the /etc/network/interfaces is being populated ? Jan 27 17:01:37 init-ifupdown provides the default interfaces file Jan 27 17:01:42 formerly was in netbase Jan 27 17:02:16 thank you a lot kergoth ! Jan 27 17:02:23 np Jan 27 17:02:44 its quite common to bbappend init-ifupdown to provide a custom default for particular machines in bsp layers Jan 27 17:04:38 ok ! nice ! :-) Thank you Jan 27 17:04:42 halstead: ping for when you're around Jan 27 17:05:44 pidge, I'm here. Jan 27 17:07:02 is it possible to know which package will be built when building an image ? Jan 27 17:08:00 weebet: recipes yes, packages no (before building, that is) Jan 27 17:08:45 weebet: bitbake -g imagename will produce a pn-buildlist file which is a list of the recipes that will be built Jan 27 17:08:56 bluelighting Thank you a lot ! Jan 27 17:11:15 there is a app called 'at' ported some time ago from openembedded classic to openembedded-core Jan 27 17:11:42 it does not compile now with uclibc however in openembedded classic there is a patch to make it working Jan 27 17:12:06 the patch is called: at-3.1.12-0007-getloadavg-fix.patch Jan 27 17:12:18 current version of at in openembedded-core is 3.1.13 Jan 27 17:12:48 can I just take that patch and push to openembedded-core? Or should I recreate it and change name to *3.1.13* ? Jan 27 17:16:51 Xz: the patch probably doesn't need renaming Jan 27 17:17:13 (if it still applies cleanly) Jan 27 17:17:36 bluelightning: it does apply - nobody changed file it applies on since Jan 27 17:17:57 rburton: still around? Jan 27 17:17:59 Xz: great, should be OK to just add it then, assuming the recipe still builds Jan 27 17:18:16 bluelightning: defo builds under uclibc - will check with eglibc as well Jan 27 17:18:43 ant_work: in meeting, email? Jan 27 17:19:14 take your time Jan 27 17:19:35 no hurry here Jan 27 17:20:20 ant_work: will likely be AFK afterwards so mail might be best ;) Jan 27 17:20:37 writing ;) Jan 27 17:49:06 bluelightning: hey have you seen my question? Jan 27 17:49:14 about the SDK release tracking? What is the best practice out there? Jan 27 17:49:32 I guess just set an appropriate version on the SDK via SDK_VERSION Jan 27 17:49:33 I guess it is not just me who would like to able to reproduce any software release? Jan 27 17:49:49 bluelightning: the issue is not that part. Jan 27 17:50:02 bluelightning: say, you have a company software "foo" version 0.1. Jan 27 17:50:18 it was built with SDK version "0.2" (example) Jan 27 17:50:36 how would you keep track of all this information so that you can reproduce it anytime? Jan 27 17:50:51 it being the "foo" application version 0.1. Jan 27 17:51:01 I would say don't do that... the SDK is for use outside of the build system to accelerate app development Jan 27 17:51:19 once it's time to build the reproducible product image, then use a recipe to build the software within the build system Jan 27 17:51:51 if you start mixing things, then you have problems like the one you're describing Jan 27 17:55:32 bluelightning: but how would you develop a certain version? Jan 27 17:55:36 to release a bugfix release? Jan 27 17:55:51 you would need to know which SDK corresponds to 0.1 if you wanna create a 0.1.1 bugfix release. Jan 27 17:56:19 lpapp: if you're building entirely from the build system then it's up to whatever version control mechanisms you use Jan 27 17:56:24 the SDK shouldn't come into it Jan 27 17:56:45 bluelightning: SDK is good for developing, which you need to do when debugging a bug. Jan 27 17:57:15 so the 0.1.1 release would be built within Yocto, but the actual development would be done outside. Jan 27 17:57:35 so what is the general mechanism to map the SDK version to the app version? Jan 27 17:58:23 bluelightning: also, note that it is not necessarily maps to the Yocto layer version cause you may just send opkg-s rather than brand new images for an application update. Jan 27 17:58:36 mapping* Jan 27 18:03:37 I guess not many people care about reproducability. Jan 27 18:18:18 lpapp: I personally never release applications but product releases; and this is tracked with respective hashes of all apps included, layers and like. The SDK is build from this PDK. So I always know that the app version X included in product W is able to be build/debugged by SDK of product W in PDK version W Jan 27 18:20:18 that is a different use case. Jan 27 18:20:54 not sure what PDK is though? Jan 27 18:21:13 Platform Development Kit Jan 27 18:21:50 I do not know what that is. Jan 27 18:22:22 You can infer from the name. You are a smart guy ... Jan 27 18:24:16 I really cannot. Jan 27 18:26:24 lpapp: see for example https://github.com/Freescale/fsl-community-bsp-platform (I think that's what otavio mean). You have a platform file (default.xml) with "pointers" to other repositories. Jan 27 18:27:20 how is this relevant to my case? Jan 27 18:27:23 So, for each PDK release, you have a set of repositories and their corresponding VCS status at that release. Jan 27 18:34:43 lpapp: you have reproducability. Jan 27 18:35:18 I have a problem in 'do_rootfs': Collected errors: Jan 27 18:35:18 | * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-sdk: Jan 27 18:35:21 | * pkgconfig * ldd * Jan 27 18:35:36 | * opkg_install_cmd: Cannot install package packagegroup-core-sdk. Jan 27 18:35:56 (uclibc image:)) Jan 27 18:36:10 any ideas what should I check? Jan 27 18:36:28 mario-goulart: for a different use case... Jan 27 18:36:35 I am interested in my use case... ;-) Jan 27 18:43:37 mario-goulart: PDK feels more like the Yocto project basically, with your own layer. Jan 27 18:45:37 mario-goulart: is that a correct assumption? Jan 27 18:47:51 lpapp: in some sense, yes. It basically is a way to manage a set of VCS repositories that compose a "platform" (and you what to version the "platform"). Jan 27 18:48:31 mario-goulart: yes, but that sounds like a bit overkill for keeping to release an application... Jan 27 18:53:17 ok, figured that out - just need to skip both for uclibc Jan 27 18:53:34 is there any way I can make that variable triggering only for uclibc build: RDEPENDS_packagegroup-core-buildessential Jan 27 18:53:37 ? Jan 27 18:54:05 like RDEPENDS_packagegroup-core-buildessential_append_libc-uclibc ? Jan 27 19:09:58 I did RDEPENDS_packagegroup-core-buildessential_libc-uclibc = " Jan 27 19:10:14 works for uclibc Jan 27 19:10:22 good question how would it behave with eglibc Jan 27 19:56:42 Xz: did you get an answer to your question? Jan 27 19:56:47 kergoth: around? Jan 27 19:58:37 Hi folks, at do_compile() time, I'm trying to run python to pre-compile some .py files into .pyo files before I install them. It looks like it's picking up the python executable from my environment, but it fails saying it can't import the 'runpy' module. The python from my environment has runpy.pyand my local sysroot (tmp/sysroots/x86_64-linux/) has runpy.py Jan 27 19:59:40 is there some where else this file should be? Jan 27 20:00:27 Also, I'm using 'python -m compileall' to compile, is there a better approach? Jan 27 20:13:19 mario-goulart: so the question still stands for single apps Jan 27 20:29:43 any ideas? :-) Jan 27 20:33:11 I don't know Python well enough to know if what I'm doing is even reasonable. The package is a company internal thing that they don't want to release the source to, so I'm looking to install only pre-compiled artifacts. Jan 27 20:43:15 is it possible to create dependencies on a version ? ( if recipe A V1 need recipe B V1, but the new recipe A V2 needs recipe B V2, if I build recipe A V1 I want to build recipe B V1, not the newest V2 ) Jan 27 21:05:03 weebet: at a simple level you can DEPEND on PN-PV however bitbake doesn't do well in untangling the versions Jan 27 21:06:02 RP thank you, I did not figured this out ! Jan 27 21:09:40 weebet: I wouldn't celebrate yet because as I said, it doesn't work that well :/ Jan 27 21:30:13 laptop fan's a-whining and cpus cranking away at about 95 C Jan 27 21:30:50 i love doing a full oe-classic build on this machine... Jan 27 21:30:52 RP: somewhat, whats up Jan 27 21:34:38 kergoth: I'm pondering the -S option and whether we should make it take a parameter Jan 27 21:35:20 kergoth: It doesn't look like its a good idea to do that and allow it to work without a parameter as it could get confused with target names :/ Jan 27 21:41:16 Hi folks. I have a recipe that uses 'python' in do_compile, but the python I get there is python from my environment. Should it be using one from my sysroot? Jan 27 21:42:09 Garibaldi|work: did you innerit pythonnative ? Jan 27 21:42:17 inherit Jan 27 21:42:32 no, I DEPENDS = "python" Jan 27 21:43:05 ah, I see Jan 27 21:43:09 ok, I'll try that -- thanks! Jan 27 21:45:12 beautiful Jan 27 21:45:19 RP: thanks again Jan 27 21:48:44 Garibaldi|work: np, glad it got you working :) Jan 27 21:49:45 yeah, I had done the DEPENDS += "python-native" -- I didn't know about the other variables :-) Jan 27 21:50:28 Garibaldi|work: its so we don't end up mixing half of the native python with the sysroot one or worse... Jan 27 21:50:51 yeah, I thought python might be a special case Jan 27 23:06:06 lpapp: just add the repository for your single app to the manifest file. Jan 28 00:53:14 mario-goulart: I do not follow. Jan 28 01:01:14 halstead: where has the main autobuilder gone? Jan 28 01:01:42 halstead: if we manage to find it, we could use a build of master after all the changes that just went in... Jan 28 01:01:47 * RP -> Zzzz Jan 28 01:54:54 RP, ab-master restarted and new nightly in progress. **** ENDING LOGGING AT Tue Jan 28 02:59:59 2014