**** BEGIN LOGGING AT Fri Mar 28 02:59:59 2014 Mar 28 07:56:48 morning Mar 28 09:34:33 morning all Mar 28 09:42:56 morning paul Mar 28 09:44:03 I'll celebrate with a bottle of champagne when #4102 gets fixed Mar 28 09:50:58 morning all Mar 28 10:08:19 mornin Mar 28 10:27:16 hi everybody! Mar 28 10:27:16 I've one quick question: is it possible to build with kernel-headers 2.4 and what parts would fail? Mar 28 10:28:26 ildar: we have removed support for 2.4 quite a while ago; we assume 2.6+ in a large number of places by now Mar 28 10:30:16 bluelightning: thank you for your attention. What do you mean by "support"? Besides libc what is dependent on kernel? Mar 28 10:30:45 I guess it is some low-level staff like iptables etc. Mar 28 10:30:50 ildar: udev, various other parts of userspace Mar 28 10:30:51 but core? Mar 28 10:31:00 eeeh! Mar 28 10:31:09 yeah, udev/systemd Mar 28 10:31:14 then what? Mar 28 10:31:23 basically we haven't concerned ourselves with what might be incompatible since we removed 2.4 support, since we did not need to Mar 28 10:31:43 I got the point, thanks Mar 28 10:32:41 so I may try to build core with SysV init and _may_ be successful? Mar 28 10:32:57 like anything in software, it wouldn't be impossible, but by now I think it will be quite a battle... Mar 28 10:33:07 And what is the minimum 2.6 version supported ? Mar 28 10:33:18 I see Mar 28 10:33:20 thanks Mar 28 10:35:50 hmm, how would I go around the following: I'd like to define a global variable in my local.conf which I could later use to SRC_URI_append and do some other things on it, but its not quite clear to me how I can make this variable understood in the way that I could do the appending; or maybe there is another mechanism I should use? Mar 28 10:36:04 ildar: FYI, udev 182 (what we use in master with sysvinit) requires a 2.6.34 kernel at minimum Mar 28 10:36:54 Jin^eLD: not sure I'm following, what's the use case? Mar 28 10:37:15 bluelightning: let's say my image has a special configuration which is a build time thing Mar 28 10:37:26 this configuration should be considered across various recipes Mar 28 10:37:48 bluelightning: I guess a particular recipe can imply a lower version, right? Mar 28 10:37:49 so basically I should be able to build my distro with this setting on or off Mar 28 10:38:18 and I am looking for a way to cleanly do that, i.e. introduce my own local.conf variable on which I could build my special cases in the recipes... Mar 28 10:39:33 ildar: if you supply older versions of udev and other components that are kernel-dependent, sure it could be made to work with older versions; then you may have trouble with building the kernel with modern gcc as well Mar 28 10:39:49 ildar: that will require patches to the kernel source Mar 28 10:40:21 Jin^eLD: that sounds a lot like a DISTRO_FEATURES item to me Mar 28 10:40:31 yep, sure. Mar 28 10:41:29 ildar: just out of curiosity, is this for something commercial, or for a hobby project? Mar 28 10:41:38 bluelightning: ok let me have a look at those, thanks for the hint Mar 28 10:41:52 although right now I am not anymore sure if its actually a distro or a machine features thing that I am trying to do... Mar 28 10:42:40 non-commercial. I am considering to build HTC MAX 4G (aka Quartz) image. Mar 28 10:42:56 ildar: ah ok Mar 28 10:42:57 it has a kernel patch Mar 28 10:43:06 only that Mar 28 10:54:18 bluelightning: how are IMAGE_FEATURES handled with multimachine configurations? i.e. if machine1 has this feature set and machine2 not? will this be detected and will packages that depend on specific image features set their package arch? or is what I am describing invalid? Mar 28 11:02:56 bluelightning: from the manual it seems that all "features" only control what should go into the image and what not, but they are not meant to influence configurations/builds of particular recipes? do I understand that part correctly? Mar 28 11:03:24 Jin^eLD: IMAGE_FEATURES is used at the image level, so that will be perfectly fine - however, IMAGE_FEATURES must not be used to modify build-time configuration because then you can't influence it from the image and you can't have two different versions of the same package for different images anyway (unless you create separate differently named variants) Mar 28 11:03:32 Jin^eLD: right, correct Mar 28 11:04:32 hmm, and what would I use for build time configuration? Mar 28 11:05:15 I have a same distro for two machines, and some packages need to be configured differently, also at build time.. that's what I am trying to figure out now :) what the best way would be... Mar 28 11:07:55 Jin^eLD: it depends on whether it's just about how the machines are used (in which case, two separate distros with different DISTRO_FEATURES) or some specific aspect of the machines themselves (in which case use and set MACHINE_FEATURES) Mar 28 11:09:59 its the usage... but somehow wanted to avoid having to extra distros since the changes in configuration are minimal Mar 28 11:10:21 so I guess I'll have to go with machine features, allthough distro features would be logically more correct... Mar 28 11:10:29 thanks Mar 28 11:31:37 Hi. I'd like to report a bug for this receipe https://github.com/openembedded/meta-oe/blob/master/meta-networking/recipes-support/ntp/ntp.inc. What's the best place do it? Yocto bugzilla? Mar 28 11:33:46 diego_r: we don't track issues in meta-openembedded layers within the yocto project; the best alternative is the openembedded-devel mailing list Mar 28 11:34:25 bluelightning: thanks. Mar 28 11:35:59 JaMa: hi. You're aware that in master-next you merged my v2 patches, not v3, right? Mar 28 11:40:39 diego_r: yes I haven't updated it yet Mar 28 11:41:19 diego_r: master-next is what is currently tested on jenkins and it will take some time to finish Mar 28 11:41:30 ok, the important is that you didn't that by mistake Mar 28 11:41:39 diego_r: after that I merge OK changes to master and update master-next with new or update ones Mar 28 11:42:03 JaMa: I see Mar 28 11:42:15 thanks for explaining the process Mar 28 11:43:05 you're welcome and thanks for warning sometimes I do overlook newer version on ML (especially when patchwork doesn't pick it) but this time it's ok Mar 28 12:59:03 Is this example from sstate-cache-management.sh correct "--stamps-dir=build1/tmp/stamps,build2/tmp/stamps" ? I did "--stamps-dir=build/tmp-eglibc/stamps", but I seem to have wiped out to much, since I need to rebuild a lot now.. Mar 28 13:05:52 kroon: master or dora? Mar 28 13:11:24 JaMa, master Mar 28 13:57:21 or is it because I run "cleanup-workdir" aswell ? Mar 28 14:10:09 or wipe-sysroot Mar 28 14:12:46 I guess wipe-sysroot removes the stamps, and therefore sstate-cache-management.sh will remove the sstate files Mar 28 14:36:53 kroon: yes :) Mar 28 14:43:37 gotta learn things the hard way :) Mar 28 15:19:00 but something still aint right. I run sstate-cache-management with --remove-duplicated Mar 28 15:19:21 cleanup-workdir Mar 28 15:19:33 and then sstate-cache-management with --stamps-dir Mar 28 15:44:25 so I do: 1) bitbake virtual/kernel - kernel is compiled. 2) bitbake virtual/kernel again - nothing needs to be done. 3) sstate-cache-management.sh --remove-duplicated 4) sstate-cache-management.sh --stamps-dir 5) bitbake virtual/kernel - eglibc + kernel + other stuff needs to be rebuilt Mar 28 15:44:51 Are those rebuilds supposed to happen ? Mar 28 16:00:38 I spoke to soon, only eglibc gets rebuild Mar 28 16:02:00 kroon: I wouldn't think that is expected, no Mar 28 16:02:11 JaMa: are you still using this script? Mar 28 16:04:00 well, eglibc, and some other smaller package tasks seem to trigger Mar 28 16:04:48 but eglibc is re-compiled each time I do "sstate-cache-management.sh --stamps-dir" Mar 28 16:11:08 linux-libc-headers wants to get rebuilt after doing a --stamps-dir Mar 28 16:12:35 bluelightning: yes Mar 28 16:13:16 Any good docs or pointers on how to debug why this is happening ? Mar 28 16:14:44 kroon: well, it sounds like it's deleting more stamps than it should Mar 28 16:15:15 I have to admit that I don't use the script and haven't looked at its code, so I'm not sure I could advise on specifics Mar 28 16:19:09 kroon: just read the code and compare stamps directory before and after cleanup Mar 28 16:19:27 kroon: you can also check last changes from me in it Mar 28 16:19:43 kroon: I've fixed some issues but maybe not all, but it works much better for me than in dora Mar 28 16:20:12 ok thanks, ill have a look later tonight, gotta run now Mar 28 17:22:34 so sstate-cache-management.sh --stamps-dir removes linux-libc-headers xxx_package.tgz and xxx_package.tgz.siginfo Mar 28 18:16:03 kroon: and that file exists in stamps directory? Mar 28 18:21:43 JaMa, well.. in stamps/ I do have a ".do_package.sigdata.70d7805a67f858c6b0b97853ad9d1542", with the same hash value as in the files that sstate-cache-managment wants to remove Mar 28 18:22:10 ./cortexa9hf-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.10-r0.do_package.sigdata.70d7805a67f858c6b0b97853ad9d1542 Mar 28 18:22:28 Thats the only file with that hash in stamps/ Mar 28 18:27:25 kroon: can you try: find sstate-cache -name 'sstate*.tgz' | grep ".*/sstate:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:[^:]*:70d7805a67f858c6b0b97853ad9d1542_.*" Mar 28 18:31:13 JaMa, aha.. that line gives me no output. but if I s|sstate-cache|sstate-cache/|, I do get a hit. And did I mention that my "sstate-cache" is actually a symlink... Mar 28 18:33:26 kroon: ah see line 337 in script Mar 28 18:33:34 it's checking for .siginfo. not .sigdata. Mar 28 18:37:27 JaMa, aha. changing .siginfo to .sigdata leads to that the files are not being removed Mar 28 18:37:55 so the fact that sstate-cache was a symlink wasnt the problem ? Mar 28 18:38:09 looks like my fault in commit ec881997c748ed8bfb3fc75797367ce3599bd5b4 Mar 28 18:39:19 symlink was only problem for the find command I gave you, if you set --cache-dir with trailing slash than it shouldn't cause problems in script Mar 28 18:40:22 but if you're going to send fix for .siginfo then adding another check for sstate-cache being symlink and passed without trailing slash would be nice Mar 28 18:41:06 :-) Mar 28 18:41:18 * kroon looks away, whisteling Mar 28 18:41:55 well.. ill see what I can do, but i dont fully grasp it Mar 28 18:42:22 should I do it instead? Mar 28 18:43:07 JaMa, yeah, I'd appreciate it, instead going through 1-2 reviews, with me doing stupid things.. Mar 28 18:43:19 ok Mar 28 18:43:50 JaMa, I can file a bug for it in case we forget it Mar 28 18:45:26 I'm doing the change right now Mar 28 18:45:34 so not needed, just review and test it when sent to ML Mar 28 18:45:58 JaMa, great, thanks Mar 28 18:55:35 kroon: btw check for symlink isn't needed because there is | xargs readlink -e applied to supplied param Mar 28 18:57:15 JaMa, ok Mar 28 19:17:08 kroon: hmm there are 2 other interesting issues Mar 28 19:17:32 I hope I didn't open a can of worms.. Mar 28 19:18:04 what are the problems ? Mar 28 19:24:49 you did, but I've already known about it :) Mar 28 19:25:10 with --stamps-dir it didn't remove some files which it should Mar 28 19:25:22 with duplicite it was removing some files which it shouldn't Mar 28 19:30:46 ouch :-) Mar 28 19:31:37 how much fun would the world be without things that needed improvements Mar 28 19:32:27 http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/sstate-management Mar 28 19:32:32 see 4 changes there Mar 28 19:42:40 JaMa, will test it as soon as my build finishes Mar 28 19:53:48 kroon: maybe it still removes a bit too much, because I see python rebuilding Mar 28 19:54:57 JaMa, ok. ill make the rm -f's into echo's before trying Mar 28 19:57:15 you can use --debug to see them before rm Mar 28 20:49:01 this works, right? do_install_native-sdk () { Mar 28 20:49:09 JaMa, I'm not seeing any rebuilds now, after running both --stamps and --remove-duplicates Mar 28 20:50:56 JaMa, and the total size of sstate-cache/ is now at a respectable 2.5G, compared to 23G Mar 28 20:51:14 kroon: for me it also worked in 2nd test Mar 28 20:51:47 kroon: problem is to test all combinations (some sstate archives downloaded instead of built locally etc), but still looks like reasonable improvement again Mar 28 20:55:55 JaMa, hmm ok, I'm unable to test building with external sstate-archives Mar 28 20:58:07 (reason for 23G->2.5G is that I never ran --stamp-dir before, only --remove-duplicated) Mar 28 21:08:23 so I need to make a special do_install for swig, but only for the sdk Mar 28 21:08:43 will do_install_nativesdk only run for sdk's? Mar 28 21:08:57 Crofton: it would yes Mar 28 21:09:00 cool Mar 28 21:09:16 cmakes swig detection looks for swig2.0 before swig Mar 28 21:09:32 so on distros that have that file, it detects host swig, not sdk swig Mar 28 22:26:18 a hint maybe... how do I properly enforce PACKAGE_ARCH = "all" for multimachine builds? I figured that the "trying to install files into a shared area when those files already exist" warning is happening with all packages which I have set to "all" arch... Mar 28 22:49:51 Jin^eLD: do all MACHINEs have same signature for those allarch recipes? Mar 28 22:50:02 Jin^eLD: and use inherit allarch instead of setting PACKAGE_ARCH directly Mar 28 22:51:38 Heh, multimachine builds do get a crapton of those warnings nowadays, i don't even bother with multimachine anymore, just leverage sstate and deal with the additional overehad Mar 28 22:51:40 overhead Mar 28 22:52:59 :) Mar 28 22:53:07 JaMa: thanks for the allarch hint Mar 28 22:53:18 I did not quite understand the part about signatures? Mar 28 22:55:32 kergoth: so those warnings are not "too terrible" so to speak? Mar 28 22:55:37 :) Mar 28 22:57:24 actually that "inherit allarch" thing solved the problem Mar 28 23:00:46 Jin^eLD: check sstate-diff-machine.sh script Mar 28 23:01:00 thx Mar 28 23:01:32 sometimes recipes set allarch and then have different signatures for different MACHINEs or TUNE_PKGARCHs which is worse than leaving them with default PACKAGE_ARCH (TUNE_PKGARCH) Mar 28 23:01:48 there is couple examples of this in oe-core :/ Mar 28 23:03:55 where does that script live, can't find it? although I have to admit I'm using poky.. Mar 28 23:04:09 "signature" is what exactly? the machine arch string in the ipk's? Mar 28 23:07:47 metadata is checksummed. this is included in the stamps, so they rebuild when metadata changes, and is included in the sstate archives, so determines when the cache is used Mar 28 23:07:58 this is known as a checksum or signature Mar 28 23:08:26 Jin^eLD: oe-core/scripts Mar 28 23:08:37 kergoth: ah, ok thanks for the explanation Mar 28 23:09:26 JaMa: found it, thanks, I guess I did not have a core checkout Mar 28 23:09:50 Jin^eLD: everything in oe-core is also in poky, you don't need a separate clone Mar 28 23:09:56 look in poky/scripts/ Mar 28 23:10:12 if the metadata differs from one machine to another, then it's not really safe to use allarch. e.g. if there's a machine specific patch, logic, etc. i'm guessing this is what jama wants you to check into Mar 28 23:11:36 yes that or even just dependency on something which is TUNE_PKGARCH or MACHINE_ARCH Mar 28 23:11:43 kergoth: indeed... I seem to embarassingly suck at grepping... Mar 28 23:12:16 because then you have nice "allarch" package which should be shared by all MACHINEs, but it's actually rebuilt every time you change the MACHINE (which is quite often in multimachine builds) Mar 28 23:13:39 JaMa: well, its not a big deal, although it of course would be nicer to completely share it.. but I guess there is no real workaround? or would that package have to reset TUNE_PKGARCH in the recipe? Mar 28 23:14:08 I have some recipes with a bunch of shell scripts, so wanted to have them as "all" Mar 28 23:15:04 if you add 'RDEPENDS_${PN} = "bash"' then even when you're packaging the same shell scripts Mar 28 23:15:13 it will depend on bash which is TUNE_PKGARCH Mar 28 23:15:27 and cause the rebuilds Mar 28 23:16:18 so it's compromise, you can a) drop bash dependency and assume user will know what's needed Mar 28 23:16:45 b) package them once per TUNE_PKGARCH (no big deal, because it's small package and quickly "built") Mar 28 23:17:12 c) add SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "your-shell-package->bash" Mar 28 23:17:22 to mark this dependency as ABISAFE Mar 28 23:17:30 c) sounds a bit scary, no? :) Mar 28 23:18:09 not if you know what you're doing Mar 28 23:18:22 I use it for many packages Mar 28 23:19:41 it means something like "I need some bash, but I don't care how it was built, which version it is etc" Mar 28 23:20:01 I see... Mar 28 23:20:24 thanks once more Mar 29 00:21:56 c) is likely the best, most accurate solution, since that really is a valid case of all depending on arch Mar 29 00:22:05 * kergoth wonders if that's in an faq anywhere Mar 29 00:23:04 I guess I'll have to go over all noarch packages I have and apply that where appropriate Mar 29 00:57:52 nite **** ENDING LOGGING AT Sat Mar 29 03:00:00 2014