**** BEGIN LOGGING AT Fri Mar 06 02:59:58 2015 Mar 06 03:01:38 Crofton|work: um, it shouldn't do that? Mar 06 07:56:47 good morning Mar 06 10:21:03 does 1.7.1 have a package/dependency problem with harfbuzz? has anyone experience "check_data_file_clashes: Package libharfbuzz0 wants to install file /usr/lib/libharfbuzz.so.0 But that file is already provided by package * harfbuzz" ? Mar 06 10:28:00 oooh, forget it Mar 06 10:28:05 it's an artefact of my upgrade path Mar 06 10:32:36 but another weird thing is, it seems that PRINC is gone, however changes in my .bbappend do not get picked up automatically Mar 06 10:32:43 although I am running prserver Mar 06 10:39:41 doh, I should not do any things in the morning Mar 06 10:39:53 my .bbappend did not get appended at all since I mixed up directories Mar 06 10:39:58 forget it, sorry again ;) Mar 06 10:40:10 * Jin^eLD thinks he should take a nap Mar 06 10:46:26 morning all Mar 06 10:47:03 mornin Mar 06 11:00:23 hi mago Mar 06 11:04:45 woglinde: morning! i have done some more investigation regarding the warnings i got with meta-java yesterday. it seems like oe-core/../autotools.bbclass is the thing that emits the warnings. It tries to read these sstate manifests for populate_sysroot in order to find the aclocal files. When it can't find the file, it emits the warning. Based on the package name, it looks for different manifest files. If the Mar 06 11:04:47 package is native (e.g ends with -native), it will look for manifest-${BUILD_ARCH}-..., otherwise it looks for manifest-${MACHINE}-... In the meta-java case, for example for cacao-initial, it will therefore look for manifest-${MACHINE} and this doesn't exist. I think the problem is that our initial packages doesn't end with -native. I will try renaming cacao-initial to cacao-initial-native and see if the warnings Mar 06 11:04:49 disappear. Mar 06 11:05:15 Has anything mahorly changed in bitbake recently Mar 06 11:05:26 I'm getting basic python parsing errors Mar 06 11:05:39 File "/home/jack/Work/oe-core.git/bitbake/bin/bitbake", line 275 Mar 06 11:05:39 raise exc_info[1], None, exc_info[2] Mar 06 11:05:39 ^ Mar 06 11:05:39 SyntaxError: invalid syntax Mar 06 11:05:49 mago hm good idea Mar 06 11:06:10 ah, my bad Mar 06 11:06:13 this goes for -bootstrap packages also, they should probably be called -bootstrap-native Mar 06 11:06:19 I'm still defaulting to python3 Mar 06 11:06:40 mago hm why is inherit navtive not working anymore? Mar 06 11:06:50 I thought this declares the packages as native Mar 06 11:07:17 mago so maybe the fix should be in oe Mar 06 11:11:08 woglinde: i don't think inherit native will automatically create a -native package for you, if you want that, you probably have to BBCLASSEXTEND ="native", right? so even if cacao-initial inherits native, there will never be an actual package called cacao-initial-native, even though cacao-initial will build for the host. Mar 06 11:11:33 and that's exactly what the autotools.bbclass stuff needs, it doesn't actually KNOW if a package is native or not, it just checks for -native prefix in the package name Mar 06 11:12:44 so perhaps the problem is in the detection of native packages in autotools.bbclass, but i feel like im out on thin ice here.. Mar 06 11:25:24 is there a way to force a PR increase via a bbappend even if there were no changes? in eaerlier days I'd just bump PRINC but that does not work now anymore? Mar 06 11:28:04 oh, actually PRINC still works but produces deprecated waning; but I guess the question still remains what is the way to do such things in the future? Mar 06 11:29:31 prserver doesnt allow this Mar 06 11:29:56 that's why I am asking... Mar 06 11:29:57 why do you want to bump PR when nothing changed Mar 06 11:30:12 sounds backwards Mar 06 11:30:36 well, in this particular case its practical for testing purposes, I am not sure if my defconfig busybox changes were picked up, changed something and now trying again Mar 06 11:30:49 or can I be sure they did not get picked up if the package was not automatically bumped? :) Mar 06 11:31:06 and I'm testing via a live update Mar 06 11:31:11 from a debug server Mar 06 11:31:14 hence the bumping Mar 06 11:31:56 it should but then you clean force build it too Mar 06 11:32:07 and then opkg upgrade Mar 06 11:32:10 when I force clean and build its not bumped Mar 06 11:32:17 will fetch it from server again and reinstall Mar 06 11:32:52 uuh.. rather not with busybox :) its easy to end up in a situation when you have to reflash if reinstall messes up, happened to me a couple of times Mar 06 11:33:41 --force-reinstall Mar 06 11:33:50 yes, that was the evil one :) Mar 06 11:34:06 I do not know what happened but at least twice I ended up without busybox at all :) Mar 06 11:34:24 hmm Mar 06 11:34:34 doesnt happen here Mar 06 11:34:55 but anyway... I modified the defconfig, it gets placed into ${WORKDIR} intead of the regular one, but when i devshell after do_compile - the .config does not have my changes Mar 06 11:35:32 and I wonder why... the main .bb in the poky layer does some sedding but on other things Mar 06 11:49:05 is it possible to disable GPLv3 package on the target but still compile the native ones ? Mar 06 11:56:12 mago_ you understand me wrong if a package inherit native oe should put the resulting packages to the list of native packages Mar 06 11:57:22 woglinde: yeah, I agree.. but autotools.bbclass doesn't seem to look at this list, it just inspects the package name. Where is this list anyway? Mar 06 11:57:40 mago thats what I feared Mar 06 11:57:49 there is none Mar 06 11:58:12 so the classes looks at hardcoded spezific suffixes Mar 06 11:58:27 woglinde: don't you think it makes sense anyway to make sure the native recipes are prefixed with -native? it seems to be more or less de facto Mar 06 11:58:43 (even though the issue is with oe-core) Mar 06 11:59:20 mago but thanks for looking it all up Mar 06 11:59:33 yes if there is no otherway please make a patch to rename the recipes Mar 06 11:59:41 okay, will do Mar 06 13:59:12 guys...help me out please. I am modifying busybox defconfig, I tried adding my own in .bbappend, I tried modifying the original recipe in poky - the changes I make there are just not taken, when I devshell after do_compile: the defconfig in ${WORKDIR} is correct, but .config in ${S} is something totally different Mar 06 13:59:15 how is this possible? Mar 06 14:52:19 apparently make oldconfig that is being run wipes the setting out Mar 06 14:53:56 you're better off just adding a cnfig fragment to tweak the defconfig hte way you want than overriding it, but either will work Mar 06 14:54:09 we used to override the defconfig in meta-mentor as of two days ago before finally switching to fragments Mar 06 14:54:18 echo CONFIG_FOO=y >foo.cfg, SRC_URI += "file://foo.cfg" Mar 06 14:55:19 and who will know that my foo.cfg should be processed? Mar 06 14:55:25 or do I need another rule to do a merge_config.sh? Mar 06 14:55:32 in configure append or similar? Mar 06 14:56:37 but the problem I actually encounter is that my changes in the file are fine, and then oe_runmake oldconfig gets called Mar 06 14:56:41 and this wipes out my setting somehow Mar 06 14:56:57 aaah Mar 06 14:57:01 find_cfgs() Mar 06 14:57:07 will handle the override automatically Mar 06 14:57:09 thanks, let me try Mar 06 14:58:15 Jin^eLD: the busybox recipe in oe-core already uses it Mar 06 14:58:25 same for linux-yocto Mar 06 15:18:13 kergoth: cool, thanks again, it worked fine when I used the separate .cfg Mar 06 15:20:20 np Mar 06 15:20:25 less to maintain that way anyway :) Mar 06 15:20:31 easy to diverge when overriding a file Mar 06 15:22:04 yep, thats true Mar 06 15:23:28 i only just dug into our busybox config.. it'd been hanging around getting tweaked since like 2007, yet the actual # of changes was small Mar 06 15:23:31 heh Mar 06 15:25:58 well I had a bit of hard time diffing our full blown config vs OEs config and extracting a meaningful diff :) Mar 06 15:26:13 it also seems the order and positioning of some things has changed so not that easy to diff then Mar 06 15:26:28 but surely a .cfg with overrides where only what is needed is really there makes much more sense Mar 06 15:34:41 what i did was walked through our history back to where it started, checked the oe-core config as of that date vs ours, then walked our changes to the file from then on to see what we added from beginning to end Mar 06 15:34:50 then i took that list and checked to see what we really actually give a crap about anymore Mar 06 15:37:07 well, last part is the hardest ;) Mar 06 15:37:28 I once removed something by accident which broke things Mar 06 15:38:58 yeah.. especially when not all the commits reference bug numbers and whatnot Mar 06 15:39:05 oh well, only so much you can do Mar 06 15:40:57 :) Mar 06 16:16:34 otavio, would this satisfy you wrt to sip and python-sip, http://pastebin.com/XC1xGA0K Mar 06 16:18:38 Crofton|work: sure; thx for looking at it Mar 06 16:18:47 np Mar 06 16:18:52 it was educational Mar 06 16:18:54 Crofton|work: I was just concerned about upgrade path Mar 06 16:18:58 :) Mar 06 16:19:15 yeah, and looking back it makes sense to split build time from runtime support Mar 06 16:24:54 Crofton|work: one more thing Mar 06 16:25:06 Crofton|work: see if pythin-sip has all need rdepends on it Mar 06 16:25:18 Crofton|work: so it makes easier its use Mar 06 16:25:37 I think it is other things that need the python-sip rdepends Mar 06 16:28:51 I suspect the shared lib code will find the RDEPENDS? Mar 06 16:28:57 let me rebuild pyqt Mar 06 16:29:34 maybe not, epend might be for import of the python Mar 06 16:29:52 Crofton|work: shlibs will do most of it Mar 06 16:29:58 checking Mar 06 16:30:14 dpkg -I does the trick ;) Mar 06 16:40:39 I'm not a deb guy Mar 06 16:40:52 It look slike we need to set RDEPENDS on python-sip Mar 06 16:41:23 I thinnk anything that uses PyQT will have a runtime depend on the python sip moduilles, since what I read is they are runtime support? Mar 06 16:57:18 Crofton|work: I didn't follow you Mar 06 17:36:46 JaMa: why is soci recipe held ? Mar 06 17:37:03 are there any build/run issues with it Mar 06 17:44:01 khem`: didn't I reply in e-mail? Mar 06 17:44:22 JaMa: Hmm I might have missed it Mar 06 17:44:33 whats the issue if you can just brief me Mar 06 17:44:40 IIRC undeterministic dependencies Mar 06 17:45:01 ah no, many installed-vs-shipped Mar 06 17:45:12 in /usr/lib64 for qemux86-64 Mar 06 17:45:27 hmm ok thanks Mar 06 17:45:41 if u can point to the ml reply Mar 06 17:45:46 since I have cleaned my sandbox Mar 06 17:45:51 I might not see it Mar 06 17:46:04 * khem` is following 0 message inbox policy now **** ENDING LOGGING AT Sat Mar 07 02:59:58 2015