**** BEGIN LOGGING AT Mon Nov 18 02:59:59 2013 Nov 18 10:11:31 hi, is there a 'shortcut' or script to force to regenerate Packages file in tmp/deploy/ipk without rebuilding the entire image? Nov 18 10:21:19 ndec: bitbake package-index Nov 18 10:37:52 rburton: thanks! Nov 18 10:45:20 good morning Nov 18 11:28:38 hi all Nov 18 11:28:54 morning pb_ Nov 18 11:29:18 morning pb_ Nov 18 11:31:07 good morning intel Nov 18 11:31:31 GOOD MORNING PB_ Nov 18 11:31:34 heh Nov 18 11:32:27 i hope that doesn't count as speaking in public as intel Nov 18 11:35:56 morning all Nov 18 11:38:45 hi JaMa Nov 18 15:26:40 rburton, what do you needa native numpy recipe for? Nov 18 15:28:09 Crofton|work: piglit Nov 18 15:28:14 just sent that bit Nov 18 15:28:34 oh, hm, maybe that configure hackery needs to be class-target only Nov 18 15:29:27 piglit is funny, check out the license statement Nov 18 15:29:29 weird, just seemed odd to me :) Nov 18 15:29:58 piglit generates vast numbers of tests at compile time use mako and numpy Nov 18 15:31:08 * koen stabs numpy Nov 18 15:31:52 koen: agreed Nov 18 15:32:29 I hate how you have to uninstall things like BLAS from your host to get it to build Nov 18 15:32:35 then again, it's a python module Nov 18 15:33:58 koen: your "ugly ugly hack" in numpy's configure_prepend would need to be made target-only if the recipe was nativeized, right? Nov 18 15:35:43 I think so Nov 18 16:43:13 rburton: hi, i see you mentioned piglit... are you working on a recipe for piglit? Nov 18 16:44:19 apparently he sent it in already Nov 18 16:44:54 ndec: sent to meta-oe already Nov 18 16:46:54 oh. ok. i will check the list. Nov 18 16:55:16 koen: agreed on the numpy issue Nov 18 16:55:29 problem: opencv seems to have a dependency on numpy Nov 18 18:54:32 hi everyone Nov 18 18:54:48 I built a new kernel with some drivers compiled as modules instead of as built-in Nov 18 18:55:36 however, when bitbake generates ipk packages for the kernel and for the kernel modules, the kernel package doesn't depend on the kernel modules Nov 18 18:55:45 is there a way to do this? Nov 18 19:03:27 jgi: RDEPEND_${PN} maybe? Nov 18 19:04:10 mr_science: yes, but I'd like the dependencies to be generated automatically, as there are thousands of modules packages Nov 18 19:04:41 jgi: it generate sa kernel-modules package. if you want all the modules, install that Nov 18 19:04:41 jgi: use "kernel-modules" which pulls all of them Nov 18 19:04:49 haven't really looked at that much yet, so ... Nov 18 19:04:58 kergoth: :) Nov 18 19:05:00 :) Nov 18 19:05:50 damn, you should write that smile 3 seconds later :) Nov 18 19:06:00 s/you/I/ Nov 18 19:06:00 JaMa, kergoth: ok, now will kernel-modules only contain the modules I configured as modules in my defconfig file? Or will it contain all modules, even those that I chose not to use? Nov 18 19:06:12 in poky all i've done so far is extend the kernel config to enable rt_group_sched Nov 18 19:06:25 should play around with that more Nov 18 19:06:30 jgi: only enabled in defconfig Nov 18 19:06:40 jgi: other modules aren't built so cannot be included Nov 18 19:07:14 JaMa, kergoth: excellent, that should be good enough Nov 18 19:07:26 JaMa, kergoth, mr_science: thank you guys for your input! Nov 18 19:07:27 jgi: kernel-modules deps are dynamically generated, when it splits up the kernel-module-* packages Nov 18 19:07:30 np Nov 18 19:08:08 another question: IIRC, kernel doesn't depend on kernel-modules, why is that? Nov 18 19:08:22 jgi: sane default :) Nov 18 19:08:44 people like smaller images and "extra" modules can be installed with package manager Nov 18 19:09:25 machine configs can also add few more mandatory modules to RRECOMMENDS Nov 18 19:09:58 e.g. om-gta02.conf:MACHINE_EXTRA_RRECOMMENDS = " ... " Nov 18 19:10:02 it's the same reason we provide such granular packaging to begin with. more control Nov 18 19:10:13 and flexibility, for that matter Nov 18 19:13:13 ok but then if I configure my new kernel to load a bunch of drivers as modules, I have to make sure, using custom code, that these modules will be installed when I create the image or if someones install the new kernel package Nov 18 19:20:54 kergoth, JaMa: is that the way to do this? I just want to make sure I'm using it as designed Nov 18 19:22:04 kergoth, JaMa: my use case is that I upgrade the system remotely, without user interaction. If I upgrade the kernel package, I want to make sure all potential new modules dependencies are installed as well. Nov 18 19:23:18 kergoth, JaMa: upgrading kernel *and* kernel-modules every time is good enough for me. Adding an additional dependency between kernel and kernel-modules as you mentioned would be fine too Nov 18 19:26:14 I'd suggest upgrading both, to reduce the delta between what you h ave and upstream, but either would do Nov 18 19:28:44 kergoth: that's a good point Nov 18 19:29:17 kergoth, JaMa: thank you again guys, it should allow me to get the ball rolling Nov 18 19:29:18 the less yo have to maintain yourself in the long term, but lighter your overhead, and the less you have to bring forward every time you upgrade :) Nov 18 19:29:34 * kergoth is always trying to minimize our layers, not always successfully Nov 18 20:11:23 * pb_ stabs rm_work Nov 18 20:13:37 pb stab it hard Nov 18 20:13:54 yeah Nov 18 20:14:30 * pb_ tries to think of an easy way to disable it Nov 18 20:15:08 I guess I could just add an environment variable to turn it off, or something. Nov 18 20:16:46 i'm guessing you don't want to remove the inherit due tot he change to the task graph? Nov 18 20:17:08 yeah, ideally not. Nov 18 20:17:43 also, it's inherited from a file that we keep under revision control, and it's a pain for me to keep carrying around a local modification to that. Nov 18 20:18:10 have to stash every time I want to rebase, and remember to unstash afterwards (which inevitably I forget), etc Nov 18 20:18:50 if on dora or newer, could always use INHERIT_remove Nov 18 20:18:58 oh yes, right Nov 18 20:18:58 but thats a fair point, i hate keeping around local modimfications too Nov 18 20:19:08 pb_: what's wrong when using it? Nov 18 20:19:21 thats assuming bitbake does a finalize on the config metadata boefre it grabs INHERIT :) Nov 18 20:19:48 JaMa: it deletes all the files that I want to look at :-} Nov 18 20:19:58 ok :) Nov 18 20:24:34 Hi Guys, anyone have experience with cannman and wifi Nov 18 20:26:21 I have to do an "ifup wlan0" to get the interface up, i should not have to right? Nov 18 20:27:11 sorry that's "connman" not cannman Nov 18 20:29:54 hm, this stupid kernel.do_populate_sysroot problem still plagues me Nov 18 20:30:22 or, more accurately, it plagues my jenkins. if only I could make it happen in my local builds I guess I would have more chance of debugging it. Nov 18 20:31:08 sort of seems like it's got to be a bitbake bug, maybe I should try bisecting it. Nov 18 20:37:23 man, i hate issues like that. we have one of those, at random, only for jenkins, bitbake doesn't pick up the correct vardeps for a shel function and then edoesn't emit functions it needs to run :| Nov 18 20:37:30 pb_: something like this one? Nov 18 20:37:31 Exception: OSError: [Errno 2] No such file or directory: '/OE/build/oe-core/tmp-eglibc/work/qemux86_64-oe-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/image/usr/src/kernel' Nov 18 20:37:59 *** 0093: if (os.stat(src).st_dev == os.stat(dst).st_dev): Nov 18 20:37:59 JaMa: yeah, very like that. seems that bitbake is running do_populate_staging without having done do_install first. Nov 18 20:38:39 I have it quite often lately on one builder Nov 18 20:38:43 kergoth: yeah, we've had a few like that. total pita. Nov 18 20:38:53 and you're right, last task finished before do_populate_sysroot is do_compile Nov 18 20:40:00 yeah, exactly. if you check "bitbake g", it has do_install as a dependency. but, of course, when I run bitbake by hand it works, so it's unclear whether the -g output matches what jenkins is actually seeing. Nov 18 20:40:25 yikes, that's worrisome, that shouldn't even be possible Nov 18 20:40:34 it only happens with the kernel, which is weird. Nov 18 20:41:02 since, afaict, the kernel doesn't do anything very special with staging. Nov 18 20:42:08 bitbake's complexity makes debugging such things hard. it's tough to hold a sufficient mental model without nicer abstraction layers, imo Nov 18 20:42:15 heh Nov 18 20:42:21 as far as I can see, there is only one place in the system that does "addtask do_populate_sysroot" (in staging.bbclass) and that one does clearly as "... after do_install". Nov 18 20:42:28 do I hear a desire to clean up bitbake? Nov 18 20:42:37 kergoth: right Nov 18 20:42:56 the code that deals with runqueues and dependencies is quite impenetrable Nov 18 20:43:51 it's not hard to believe that there might be bugs, but the ay it's written makes it quite hard to say where they might be. Nov 18 20:43:55 it's one thing if something is reproducible, but if not, you need to be able to examine the paths in your head and come up with possible causes Nov 18 20:43:58 * kergoth nods Nov 18 20:44:33 it kinda makes sense that such type of code can easily become unreadable Nov 18 20:44:52 yeah Nov 18 20:45:00 since it involves a nontrivial amount of thread synchronization and dependency tracking Nov 18 20:45:16 one day last week I was seriously considering starting an effort to rewrite bitbake in C++ or something Nov 18 20:45:31 hear, hear. c++ to make it clearer :D Nov 18 20:46:00 (although c++11 can be quite readable, if used correctly..) Nov 18 20:46:54 yeah. well, it was mostly bitbake's slow performance that was irking me on that particular day, though I suspect in reality that the metadata now outweighs bitbake itself in terms of number of lines of python code that get executed during a build Nov 18 20:47:18 Oh I feel like that pretty often too, usually at the end of the day, just want to throw it out a window and start again Nov 18 20:47:36 of course, with c++ you have the problem that you need to build something Nov 18 20:47:52 well, that's what we have gcc for. Nov 18 20:48:25 and, after all, gcc itself is c++ nowadays. whatever's good enough for those guys is good enough for us, I guess. Nov 18 20:48:49 Go might a decent option too Nov 18 20:48:58 * dv_ mentions D Nov 18 20:49:34 Go would be cute, but I don't think you can rely on everyone having it installed. Nov 18 20:49:37 Recently I've been mulling over the possibility of just replacing a particular component. I want to create a standalone fetch tool that do_fetch calls to do the heavy lifting, and ditch our legacy fetch bits from bitbake entirely Nov 18 20:49:51 true, but you could always distribute binaries, they're static after all Nov 18 20:49:55 lots of options Nov 18 20:50:06 and, of course, some people might fear that using go will mean that google owns all their source code. Nov 18 20:50:15 language really isn't the important bit, i think, so much as giving more thought to the design up front Nov 18 20:50:30 yeah Nov 18 20:50:49 what bugs me most is how intertwined the components and modules are Nov 18 20:50:55 it makes it tough to evolve over time Nov 18 20:51:21 maybe we could focus on separating and making bitbake's pieces more self contained, and then we could replace bits piecemeal easier Nov 18 20:51:29 I actually think D would be a nice choice here. its a very powerful language, native execution, garbage collector, very flexible, suffers from the chicken-egg syndrom atm Nov 18 20:51:37 pb_: i own pretty much all of our jenkins builds, but it's oe-classic Nov 18 20:51:47 * kergoth ponders Nov 18 20:52:00 if you have some data to look at i can take a look later Nov 18 20:52:02 kergoth: yeah, that's certainly true also. Nov 18 20:52:26 mr_science: if you're on oe-classic then I doubt you would see the same issue. Nov 18 20:52:26 it'd make it much easier to wrap our heads around, too. god, try separating cooker/runqueue/taskdata sometime Nov 18 20:52:29 * kergoth shudders Nov 18 20:53:03 possibly, but hard (for me) to know with more info Nov 18 20:53:27 my problem is, when i start thinking about things like this, there's this dillemma about whether to just replace it with something entirely compatible, evole it, or change how it works in a more fundamental way Nov 18 20:53:32 that do_populate_sysroot thing only started happening with my most recent update of bitbake and oe-core. we've been using oe-core for years (literally) prior to that without seeing it. Nov 18 20:53:38 kergoth: is bitbake the no.1 problem in oe these days? Nov 18 20:53:39 i have both a jenkins "job" script and a separate build script for each one Nov 18 20:53:41 for example, i love that oe-lite has packages as the primary artifact, and the binary pakcages are used to construct the sysroots Nov 18 20:53:49 the only one that Nov 18 20:54:03 dv_: that's tough to say, i think, there's a lot of pieces involved Nov 18 20:54:05 kergoth: a drop-in replacement makes more sense Nov 18 20:54:08 's weird is the sdk build (wihtout building an image first) Nov 18 20:54:46 but assume you write such a replacement in c++, or go, or d, or whatever. how do you deal with the python blocks inside the recipes? Nov 18 20:54:50 dv_: another thing i'd like to see, is removing some of the bitbake implementation details from the metadata. avoid using addtask in recieps and the like, and instead provide more hooks between tasks up front, so the recipes can be more declarative. just define variables nad functions and that's it Nov 18 20:55:00 well, python is quite embeddable, it'd be doable Nov 18 20:55:07 kergoth: right, that rocks. on the other hand, as I've started to get more sensitive to build time, I've started to go off the idea of either doing per-recipe sysroots or building the sysroot from packages. Nov 18 20:55:14 well, that part sounds reasonable Nov 18 20:55:17 ok, in c++ there is boost.python for example ... (although I am not a fan of involving too much of boost) Nov 18 20:55:57 if you have time to describe your build setup at some point, maybe we can come up with a decent workaround Nov 18 20:56:14 if it doesn't solve itself after an update... Nov 18 21:00:59 damn, i set the trap in the other channel... Nov 18 21:31:00 how tiresome, just broke another phone. I seem to be getting through them at quite a rate just now. Nov 18 21:31:12 if this carries on I'm going to have to exhume my openmoko gta01 or something. Nov 18 21:32:37 damn, i'll trade you three phones fro that one... Nov 18 21:32:42 *for **** ENDING LOGGING AT Tue Nov 19 02:59:59 2013