**** BEGIN LOGGING AT Tue Nov 19 03:00:00 2013 Nov 19 08:10:49 Hi Nov 19 08:11:23 is there any variable to use force provides in a bb file? Nov 19 08:12:21 like two bitbake file provide same thing, i want to copy only from one bb file to rootgs image, what variable do i use? Nov 19 08:27:17 pt local.conf PREFFERED_PROVIDER_foo Nov 19 08:27:36 pt both recipes have to provide a virtual Nov 19 08:30:56 hi Nov 19 08:31:01 But that file is already provided by package * Nov 19 08:31:12 how to solve above error?? Nov 19 08:31:20 ? Nov 19 08:33:52 while generating rootfs for some files i am getting Package accounts wants to install file /abc.txt But that file is already provided by package xyz Nov 19 08:35:28 check_data_file_clashes while generating rootfs Nov 19 08:38:03 woglinde thanks for the info Nov 19 08:38:50 can we use require/*/*/.conf file in our a bitbake recipe (bb file) Nov 19 08:42:51 boost that is in opkg code Nov 19 08:44:56 good morning Nov 19 08:52:35 pt thats not a good style Nov 19 08:53:03 boost12 what are the packages? Nov 19 08:53:17 boost12 use pastebin to show the problem Nov 19 08:57:50 hi all Nov 19 08:58:04 morning all Nov 19 09:09:30 hi silvio_ Nov 19 09:12:10 I get these warning after removing syslogd from my busybox defconfig: http://pastebin.com/WQfL4EA7 Nov 19 09:12:24 to be ignored? Nov 19 09:13:54 tasslehoff yes Nov 19 09:14:06 maybee bbappend is to overkill to fix the warning Nov 19 09:15:42 sysroots/x86_64-linux/usr/lib/python2.7/site-packages/libxml2mod.so: undefined symbol: PyUnicodeUCS4_AsUTF8String Nov 19 09:16:19 I take it's saying libxml2-native has end up linked against the python2.7 on my debian instead of the one in the sysroot? Nov 19 09:18:57 suihkulokki ldd is your friend Nov 19 09:21:04 ldd seems to point to libpython and libxml2 under the sysroot, so seems not the case Nov 19 09:22:30 suihkulokki at which state you get the error? Nov 19 09:23:23 when building, mesa, but it is also reproducible by just using python from sysroot and typing import libxml2 Nov 19 09:26:47 suihkulokki hm best is to write to the oe-core ml Nov 19 10:31:35 morning all Nov 19 10:32:20 morning Nov 19 10:32:51 hey anarsoul Nov 19 10:56:33 hi bluelightning, anarsoul, all Nov 19 10:56:43 hi mckoan Nov 19 11:29:18 hi all Nov 19 11:31:10 hi pb_ Nov 19 12:00:02 Hi khem. Do you have any recollections wrt to cross-compilation support in old chromium versions? We have a customer that needs chromium 18. I've been trying to cross-compile it using OE, but it looks rather painful. Nov 19 12:00:25 doesn't meta-browser have chromium 18? Nov 19 12:00:52 No. I think it started with 19, and now it is 29. Nov 19 13:33:24 18? Nov 19 13:42:58 indeed Nov 19 14:25:52 pb_: have you tried your kernel+compressed_cpio runtime? Nov 19 15:15:00 ant_work: yes Nov 19 15:24:51 pb_: I've lost much time seeking for inexistent kernel bugs... Nov 19 15:32:04 :-( Nov 19 15:32:31 that is frustrating. Nov 19 15:35:09 hi everyone Nov 19 15:35:53 recently, I created a new recipe named kmod-asix to build an updated (and fixed) version of a usb-to-ethernet driver as a module Nov 19 15:36:29 pb_: then the compression options are not making sense Nov 19 15:36:31 however, the build process already creates a package with the outdated driver for the same device Nov 19 15:36:44 so I end up with two packages including the same .ko file Nov 19 15:37:05 pb_: as the INITRAMFS_FSTYPES Nov 19 15:37:28 if I try to installed the "fixed" and updated driver by entering opkg install kmod-asix after the kernel-modules meta-package is installed, I get a "can't overwrite file" error Nov 19 15:38:00 if I pass the force-overwrite command line option, the updated driver can be installed, but I need to be able to do that without user interaction Nov 19 15:38:19 is there a way to "replace" the code for a given driver that is built as a module? Nov 19 15:39:13 what I would like to do is not to have to create a new package (in my case kmod-asix.ipk) and instead replace the code that is built when creating the kernel-module-asix.ipk package Nov 19 15:39:24 any idea how to do that? Nov 19 15:40:25 jgi: well...patch the kernel? Nov 19 15:41:37 or just turn the broken driver off in your kconfig? Nov 19 15:42:00 failing that you could declare the new one as Replace:ing the old one which would make opkg allow it to overwrite the existing files. **** BEGIN LOGGING AT Tue Nov 19 15:44:20 2013 Nov 19 15:44:24 ant_work: I mean do they usually follow the same build convention? Nov 19 15:45:14 jgi: a kernel driver is just a C file Nov 19 15:45:22 pb_: but if I turn the broken driver off, then the kernel wouldn't be able to load the "fixed" .ko file right? Nov 19 15:45:51 er, why not? Nov 19 15:47:52 pb_: I know almost nothing about how kernel modules are loaded, I thought the kernel had to know at build time that some code can be loaded as module to be able to do so at run time Nov 19 15:48:37 ant_work: in my case the updated driver is actually 2 C files built with a Makefile Nov 19 15:48:40 you do need to enable support for loadable modules (generically) when you build the kernel, but you don't need to tell it in advance which particular modules you plan on loading. Nov 19 15:48:50 pb_: ok, excellent Nov 19 15:49:26 so if I disable the outdated driver, how can I include the updated driver's package in the kernel-modules meta-package? Nov 19 15:50:06 RRECOMMENDS_append_kernel-modules = "..."? Nov 19 15:54:10 pb_: ok, is there any doc about RRECOMMENDS somewhere? Nov 19 15:54:45 probably in the yocto user manual and/or the bitbake manual Nov 19 16:09:44 pb_: also isn't it RRECOMMENDS_kernel-modules_append instead of RRECOMMENDS_append_kernel-modules? Nov 19 16:20:22 jgi yes Nov 19 16:38:37 can I put rm_work in USER_CLASSES? Nov 19 16:40:07 what is USER_CLASSES? Nov 19 16:40:59 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-USER_CLASSES Nov 19 16:41:49 ah silly me Nov 19 16:41:51 this suggets I can Nov 19 16:41:55 alread used it Nov 19 16:41:59 it's just added to INHERIT, afaik there's no reasno you couldn't put it there, *shrug* Nov 19 16:43:11 * woglinde wonders why adding systemd feature in poky results in recompiling gcc-cross Nov 19 16:44:13 woglinde: stuff using DISTRO_FEATURES will rebuild when distro features changes, even if the feature they care about isn't affected Nov 19 16:44:15 woglinde: distro feature change -> rebuild everything Nov 19 16:44:16 unfortunately Nov 19 16:44:23 there's a bug for that :) Nov 19 16:44:57 ah okay Nov 19 16:45:17 i was thinking about ahcking a workaround for that, DISTRO_FEATURES_ == "boolean value" created based on DISTRO_FEATURES at ConfigParsed or so Nov 19 16:45:25 then recipe uses that variable instead Nov 19 16:45:30 * kergoth shrugs Nov 19 16:45:42 os there a tsc thing today? Nov 19 16:46:50 kergoth, I ask to avoid confusing the end user by using USER_CLASSES and INHERIT i the same local.conf Nov 19 16:47:08 also, I will now define users versus develoerps Nov 19 16:47:18 users us rm_work, developers do not :) Nov 19 16:47:29 kergoth: i was thinking a function to check distro features and the cache magic then can know what features are checked for (then again, i don't know how the hashes work) :) Nov 19 16:51:31 rburton: possible, but would involve intermediate variables like i suggested under the hood, or bitabke would need to special case it Nov 19 16:51:34 koen: if we're still doing them every two weeks (alternating between this channel and not) then yes Nov 19 16:52:07 kergoth: sounds like a decent enough plan. on the other hand, how often does DISTRO_FEATURES actually change? Nov 19 16:52:37 good question. though at this point even rearranging teh order of the elements will rebuild the universe :\ Nov 19 16:53:26 even adding a space would do that right? Nov 19 16:53:54 yeah, I think so Nov 19 16:56:40 ouch Nov 19 16:57:04 kergoth: maybe a good first step would be finish that list type support in bitbake? Nov 19 16:57:11 probably, yes Nov 19 16:57:13 at least then it can be treated as a set instead of a string Nov 19 16:57:15 but, again, I can't really imagine that people go around adding spaces to that variable just for laughs. Nov 19 16:57:41 pb_: its incredibly frustrating when you end up re-arrnging the order and have to go to an early lunch though Nov 19 16:57:50 yes, giving it proper set semantics would certainly help with that. Nov 19 16:58:23 not that I ever object to an early lunch myself :-} Nov 19 16:58:30 good I started the discussion Nov 19 16:58:50 is there a way to rebuild kernel modules packages? Nov 19 16:59:32 pb_: more annoying is when my nightly cron builds and my normal builds have a distro features that differ in whitespace or order Nov 19 16:59:51 right, I can see that would be annoying Nov 19 17:00:09 how does that end up happening, though? Nov 19 17:00:28 surely poky doesn't have some sort of randomizer built in to its distro_features, does it? Nov 19 17:00:45 ha, no, just different modifications to local.conf Nov 19 17:01:03 my local.conf is a maze of mostly-commented-out distro_feature assignments Nov 19 17:01:12 ah, fair enough Nov 19 17:01:26 and my overnight builds has a similar setup, but unless i get the order right i can't re-use sstate Nov 19 17:03:51 rburton: didn't we switch to sorting distro features a few months ago? Nov 19 17:05:19 jgi hm dont thinks so you need to recompile whole kernel Nov 19 17:05:41 pb_: as you wanted to temporary disable rm_work, why don't you use -c build? Maybe you can disable it by setting BB_DEFAULT_TASK from local.conf with some override? Nov 19 17:05:57 koen: really? didn't notice that. Nov 19 17:12:06 JaMa: oh, yeah, that's not a bad idea. Nov 19 17:14:27 btw how are people solving passing LOADADDR variable for kernel 3.12+? Nov 19 17:14:37 currently I'm using this in my kernel recipe: Nov 19 17:14:38 +# needed for make uImage Nov 19 17:14:38 +KERNEL_EXTRA_ARGS = "LOADADDR=${UBOOT_LOADADDRESS}" Nov 19 17:15:00 * pb_ "solves" this by not using uImage and not using kernel 3.12 :-} Nov 19 17:15:56 but, if newer kernels need that, there doesn't seem any obvious reason that kernel.bbclass couldn't add that to its own KERNEL_EXTRA_ARGS. Nov 19 17:16:06 * JaMa feeling presure from both sides :) current systemd recipe no longer works with 2.6.* kernels Nov 19 17:16:40 so for dora I've downgraded systemd older release which didn't need 3.0 with cgroup.procs Nov 19 17:16:49 but for master I need newer kernels Nov 19 17:17:41 pb_: I even have patch for that, but some people can say that setting UBOOT_LOADADDRESS on e.g. x86 platform doesn't make sense Nov 19 17:18:04 pb_: The autobuilder just hit that strange populate_sysroot task issue Nov 19 17:18:29 so I can add it with override, but currently KERNEL_EXTRA_ARGS. is using weak assignment, so some people can complain that their setting is no longer respected Nov 19 17:18:55 RP: my colleague Mike has been looking at that today. he's going to send a couple of patches which seem to be related, though I don't think we have an actual fix for it yet. Nov 19 17:19:01 RP: I can reproduce it quite often, so if you have something to test I can do Nov 19 17:19:51 moin Nov 19 17:20:07 if I understood what Mike told me correctly, there is a bug in kernel.bbclass which causes do_populate_sysroot's setscene to fail if gcc isn't already in the sysroot (because it now tries to run "make scripts"). Nov 19 17:21:10 and, if you fix that so that it has a dependency on gcc so that "make scripts" works, you then get the populate_sysroot crash every time. Nov 19 17:23:00 on a tangent, it seems as though we are making scripts rather more often than is strictly necessary. module.bbclass already does that before do_compile() so I don't entirely understand why the kernel feels the need to do it in an sstate_postfunc as well. Nov 19 17:23:31 pb_: ah, I know that problem and yes, I have some concerns about this. The autobuilder failure looks different though Nov 19 17:23:49 pb_: It was Bruce who added that make scripts so we probably need his input Nov 19 17:24:09 pb_: making a setscene depend on gcc-cross is not really acceptable Nov 19 17:24:27 righto Nov 19 17:25:01 is the autobuilder failure the same one where it runs do_compile(), do_bundle_initramfs() and then do_populate_sysroot without do_install? Nov 19 17:26:01 pb_: yes Nov 19 17:26:28 pb_: having run do_populate_sysroot_setscene successfully Nov 19 17:29:34 right, I think that's the same behaviour we're seeing. if do_populate_sysroot_setscene fails (and so bitbake decides to rerun the real task) then you don't get the crash. Nov 19 17:30:26 pb_: I think there is something odd about the sstate coverage (or lack of coverage) of the do_bundle_initramfs task Nov 19 17:30:32 yeah Nov 19 18:10:54 pb_: FWIW there is a line in the debug log " logger.debug(1, 'Not skipping task %s due to setsceneverify', task)" and it elects to run populate_sysroot but apparently not its dependencies Nov 19 18:11:07 pb_: I'll poke further later... Nov 19 18:11:10 or tomorrow Nov 19 18:11:19 woglinde: thanks, however bitbake -c clean virtual/kernel; bitbake virtual/kernel doesn't seem to rebuild kernel modules Nov 19 18:11:43 RP: ok, cool, thanks Nov 19 18:12:10 so what is the preferred way of logging something in bb python blocks? Nov 19 18:12:12 bb.log() ? Nov 19 18:12:22 or logger.debug() ? Nov 19 18:13:08 bb.{note,warn,error,fatal,debug} are generally the mechanisms in that context, at least that' sthe convention Nov 19 21:45:40 pb_: so I tried adding RRECOMMENDS_kernel-modules_append = " kmod-asix" to my kmod-asix recipe, rebuilt the kernel and kernel modules, and when I use opkg info kernel-modules with the newly generated .ipk packages, I don't see my kmod-asix package in the list of packages for the kernel-modules meta-package Nov 19 21:45:52 pb_: any idea of what I'm missing? Nov 19 21:46:52 RRECOMMENDS_pn-kernel-modules_append Nov 19 21:47:12 and you need to set it somewhere more global (so that kernel recipe sees it Nov 19 21:47:39 it's quite ugly, why don't you install kmod-asix by some packagegroup instead? Nov 19 21:48:24 JaMa: what do you mean by a packagegroup? a meta package? Nov 19 21:49:11 and my RRECOMMENDS_pn-kernel-modules_append wasn't correct, sorry, lack of coffee Nov 19 21:51:39 jgi: e.g. meta/recipes-core/packagegroups/packagegroup-core-boot.bb which respects MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS Nov 19 22:00:17 JaMa: but then a package-group isn't represented by an ipk package right? is it just used to configure the finale system image? Nov 19 22:11:31 jgi: it is Nov 19 22:21:58 JaMa: ok interesting, thank you for the tip Nov 19 22:28:55 pb_: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118 is the problem I think... Nov 19 23:48:25 RP: seems to help, I did 3 builds in scenario where it was failing and all passed Nov 19 23:50:07 JaMa: kernel builds never work from sstate due to that initramfs task though Nov 19 23:50:38 JaMa: that is a different issue I guess though Nov 19 23:55:30 yes, but it was failing in populate_sysroot with exactly the same metadata (except bitbake change) before and now it doesn't Nov 19 23:55:42 so it's an improvement for sure, thanks for it :) **** ENDING LOGGING AT Wed Nov 20 02:59:58 2013