**** BEGIN LOGGING AT Wed Jul 02 03:00:00 2014 Jul 02 07:29:33 I was hoping someone could explain this part of the manual to me: Jul 02 07:29:45 RDEPENDS ==> ..."Here, the dependency is such that the do_build task for recipe "a" depends on the do_package_write task of recipe "b"...." Jul 02 07:30:37 Q1? what is this do_build? Jul 02 07:31:23 Q2? why does it not extend the concept of DEPENDS which makes more sense: Jul 02 07:31:35 DEPENDS ===> ..."Here, the dependency is such that the do_configure task for recipe "a" depends on the do_populate_sysroot task of recipe "b"..." Jul 02 07:32:06 Sometimes I need the bahaviour of DEPENDS plus the runtime dependency Jul 02 07:32:34 but that do_build is confusing me... Jul 02 07:33:43 Does it make sense to specify a config like DEPENDS = "foo" \ RDEPENDS = "foo" Jul 02 07:35:00 yes Jul 02 07:35:06 if "foo" isn't a lib Jul 02 07:35:15 or if it's a lib that gets dlopen()ed Jul 02 07:35:37 only proper libs get added automagically to RDEPENDS Jul 02 07:49:04 pompomJuice, the RDEPENDS = "foo" should be RDEPENDS_pkg = "foo", the pkg is one of the final generated bin packages (.rpm, .deb or .ipk) from the recipe Jul 02 07:49:58 aah ok Jul 02 07:51:02 so I am correct in assuming that if you want DEPENDS functionality is not supersede by RDEPENDS, but complimented. Jul 02 07:51:32 I will have to go fix some recipes then Jul 02 07:52:16 I dont have dlopen scenarios so I will fallback on the automagic stuff instead with DEPENDS Jul 02 07:52:58 I guess you also would want to use it if you have a version runtime dependency like RDEPENDS ="foo (>= 1.1)" Jul 02 07:53:13 anyone seen this before? http://lists.openembedded.org/pipermail/openembedded-core/2014-July/093888.html Jul 02 07:53:41 erbo Jul 02 07:53:55 that is one of the issues I have with the OE/bitbake system Jul 02 07:54:25 it builds native packages using the OS's toolchain instead of a native toolchain that comes with OE like lenaro Jul 02 07:54:48 I would really like to know why it was architected this way Jul 02 07:55:13 since I sometimes get issues between machines because the one decided to install a different compiler than the other... Jul 02 07:56:08 pompomJuice: I guess it's a similar issue, but in this case mesa is for the target environment and should definately not use the version from the host Jul 02 07:56:52 well if any of those recipies have a requirement on some foo-native package then you are open for host descrepency issues. Jul 02 07:57:14 those are really annoying Jul 02 07:57:15 pompomJuice: yep, that does feel a bit strange Jul 02 07:59:44 and by native toolchain I do mean the native sysroots parts aswell Jul 02 08:00:12 My best guess would be it saves OE from download all kinds of other crap that it could get for free on the host Jul 02 08:00:25 since build times are a huge issue Jul 02 08:00:42 huge build times require you to adjust your problem solving tactics... really pesky Jul 02 08:00:43 this means that sources need patching, not that bitbake is wrong ;) Jul 02 08:01:19 well for example Jul 02 08:01:29 Mono wont build on a host wihtout mcs installed Jul 02 08:01:38 so no amount of patching is going to fix that Jul 02 08:01:56 one build server works, the other is broken... 5 hours later you realize you need mcs on the host Jul 02 08:02:30 sometime you can control this using the ASSUME_PROVIDED options Jul 02 08:02:43 well, this is also risky Jul 02 08:03:22 th epoint is, the recipes should only look in sysroot, not in /usrt of th ebuildhost Jul 02 08:03:39 exception are just some -initial Jul 02 08:04:36 most probably you need to patch the 'configure' step Jul 02 08:05:02 Hi Jul 02 08:05:48 i need to create different cachae files for a task for same module based on a condition Jul 02 08:05:55 is it possible? Jul 02 08:10:53 ant_work: yep.. I looked at configure.ac and it looks like it uses pkg-config --prefix wayland-client to try to find the prefix to use for locating wayland-scanner, and the .pc file in target sysroot has prefix=/usr Jul 02 09:20:12 erbo: pkgconfig in OE honors sysroot (it should ;). There is a specific wrapper for the -native recipes which do poke in buildhost sysroot Jul 02 09:21:51 otherwise target sysroot is used Jul 02 09:30:21 ant_work: yes, but the .pc file in the target sysroot has prefix=/usr. I guess in order for it to work it would need to contain prefix=/path/to/sysroot/usr/ Jul 02 09:45:20 erbo: check the configure output around http://cgit.freedesktop.org/mesa/mesa/tree/configure.ac#n1536 Jul 02 09:45:54 (seems correctly using $PKG_CONFIG fwiw) Jul 02 09:49:48 I'm not the autofoo expert btw ;) Jul 02 09:50:12 afair /usr/{lib,include} paths are mangled by pkg-config using Jul 02 09:50:12 PKG_CONFIG_SYSROOT_DIR Jul 02 09:50:24 see defs in bitbake.conf Jul 02 10:29:40 ant_work: thanks for the hints, will look at that Jul 02 11:04:06 ant_work: hmm, on yet another machine I see that configure actually find the correct wayland-scanner from the sysroot while on two others it finds the ones in /usr/bin.. Will have to try to figure out why Jul 02 11:06:02 ah, the machine where it find the right one don't have a /usr/bin/wayland-scanner Jul 02 11:48:14 hello, Im wondering how can I load oot module at kernel boot ? I tried using MACHINE_EXTRA_* but it doesn't seems to work Jul 02 12:07:42 erbo: :/ the other way around could have more sense, i.e. missing dependencies Jul 02 12:08:06 then the patch search is borked? Jul 02 12:08:13 *path search Jul 02 12:58:34 ant_work: hi, could you help me with OE a bit? Jul 02 13:07:08 sure Jul 02 13:07:26 what's the problem? Jul 02 13:10:50 anarsoul: ? Jul 02 13:10:59 ant_work: I'm trying to patch opie_taskbar recipe, by adding this patch: http://pastebin.archlinux.fr/518697 Jul 02 13:11:31 but for some reason oe can't apply it, however I can apply it manually without any issue Jul 02 13:12:05 how do I trace directory from which bitbake invokes "patch" and arguments to it? Jul 02 13:12:10 line ending issues? Jul 02 13:12:46 koen: hm, patch is generated using git diff, so I don't think so Jul 02 13:14:12 it could be wrong strip level for patch, I already tried some variations Jul 02 13:14:49 hm, normally I do a git commit and use the format'ed patch Jul 02 13:15:12 what is S (source dir?) Jul 02 13:15:30 how do I check? Jul 02 13:16:27 recipe is here: http://cgit.openembedded.org/cgit.cgi/meta-opie/tree/recipes-opie/opie-taskbar/opie-taskbar_git.bb?h=master Jul 02 13:16:42 I'm just adding another patch file to SRC_URI Jul 02 13:38:44 ah, S is ${WORKDIR}/launcher, that's why it fails... Jul 02 13:54:56 anarsoul: are you trying to remove the initial calibration? Jul 02 13:55:08 nope Jul 02 13:55:53 trying to fix calibration issue in opie, it calibrates screen incorrectly in qemu Jul 02 13:55:55 afaik it is hardcode now, I don't remember which recipe I patched to disable it atm Jul 02 13:56:05 yes, I se Jul 02 13:56:17 do you think are just the offsets? Jul 02 13:56:39 ant_work: ts_calibrate works just fine, and the only difference is this offset Jul 02 13:56:52 I have somewhere the log of the calibration Jul 02 13:57:19 somehow it failed on some devices and was ok on others Jul 02 13:57:23 yep Jul 02 13:57:29 it's ok on real hardware Jul 02 13:57:39 so I guessed it was the rotation but afair it resulted ok Jul 02 13:57:49 (the transformations) Jul 02 13:57:53 but fails on qemu (touchscreen is emulated a bit differently from real hw) Jul 02 13:57:59 ah Jul 02 13:58:48 maybe the 'new' kernel ts-drivers have different output Jul 02 13:58:54 on real hw Jul 02 13:59:08 maybe Jul 02 14:00:32 i.e. on collie the ucbxxx driver changed Jul 02 14:03:34 for sure it was ok on the models with CONFIG_TOUCHSCREEN_ADS7846 last I've tried Jul 02 14:03:48 that one was also reworked Jul 02 14:09:12 nope, offset doesn't fix it... Jul 02 14:57:06 anarsoul: I should have the calibration logs somewhere Jul 02 14:57:22 afair the values ending in pointercal are bogus Jul 02 14:58:05 afair is ok immediately after the calibration but wrong after reboot/restart reading pointercal Jul 02 15:12:42 ant_work: they aren't ok, I've tested them with ts_test Jul 02 15:12:52 and they differ a lot from values produced by ts_calibrate Jul 02 15:14:26 there is some wrong transformation Jul 02 15:15:27 but code is same. Jul 02 15:16:31 ah, it's not Jul 02 15:17:37 it changed bottom right to left and vice versa Jul 02 15:18:03 hmm. maybe that as well. Can't remember offhand Jul 02 15:18:09 both broken afais Jul 02 16:01:36 ant_work: raw coordinates are wrong... Jul 02 16:02:01 ah, that's the driver then Jul 02 16:02:43 nope Jul 02 16:02:45 https://dpaste.de/tSMz Jul 02 16:03:17 it looks like coordinates are divided by 2 somewhere in qte Jul 02 16:03:30 but only if touchscreen is not calibrated Jul 02 16:03:31 :\ Jul 02 16:03:54 now *that's* a handy feature... Jul 02 16:05:33 I can't find my logs online but are pretty similar iirc Jul 02 16:07:07 bbl **** ENDING LOGGING AT Thu Jul 03 03:00:00 2014