**** BEGIN LOGGING AT Mon Nov 02 02:59:59 2015 Nov 02 08:13:12 morning all Nov 02 08:17:56 good morning bluelightning, all Nov 02 08:18:06 morning mckoan Nov 02 09:57:11 mornin Nov 02 13:07:18 gm all, I am back on the east coast Nov 02 13:11:22 Crofton|work: welcome back home Nov 02 14:41:11 hi! I am seeing some "File name too long" issues in my CI builds.. they are coming from opkg somehow, e.g. http://pastebin.com/D4P3wKvw. i am not sure where precisely this is coming from. Nov 02 14:41:38 where is the file name size 'restriction' coming from? Nov 02 14:44:37 each system has some kind of limitation for max path Nov 02 14:45:10 what do you mean by 'system' ? host distro? Nov 02 14:45:13 yes Nov 02 14:46:31 I believe this may have been discussed recently Nov 02 14:46:40 * bluelightning goes to find it Nov 02 14:46:42 adelcast, ^^^ Nov 02 14:46:48 search for PATH_MAX Nov 02 14:47:56 what is odd though is that path is only 472 characters, which is USUALLY under the max.. Nov 02 14:47:57 https://lists.yoctoproject.org/pipermail/yocto/2015-October/027057.html Nov 02 14:47:59 what is your filesystem? Nov 02 14:48:29 looks like a fix has been sent to the opkg mailing list, but we probably haven't set up to build with it included Nov 02 14:48:31 ahh-ha! symlinks got it Nov 02 14:48:36 fray: well.. i don't know, i need to check..it's on the linaro autobuilders.. Nov 02 14:48:46 fabo: koen : do you know? Nov 02 14:49:02 see bluelightning post.. same issue Nov 02 14:49:06 with explanation Nov 02 14:50:56 ndec: shorten the build path or include the opkg patch Nov 02 15:00:49 koen: fray : ok, i found the okpg patches, they've been added to the 0.3.x branch.. but it's not clear to me what I need to done once I have these patches though.. Nov 02 15:10:30 which upstream project provides gnu-configize? Nov 02 15:10:52 hrw: gnu-config ? Nov 02 15:10:57 thx Nov 02 15:16:03 ndec: adding them to opkg-native.bb should do the trick Nov 02 15:17:04 koen: we don't need any other configuration in OE? Nov 02 15:18:16 doesn't look like it from reading that thread Nov 02 15:18:30 shortening the buildpath won't hurt, though Nov 02 15:19:52 koen: well. it's a matrix job in jenkins.. i can't really shorten it easily.. Nov 02 15:25:28 ndec: at home I defined a custom workspace in /build/jenkins on each node Nov 02 15:25:33 that cuts it down a bit Nov 02 15:25:56 but it's likely not an option for serious setups Nov 02 15:26:10 koen: is the linaro setup a serious one ? ;-) Nov 02 15:26:28 it has docker slaves :) Nov 02 15:27:20 ok.. i asked on the thread.. i need to go for now.. will try later. but it looks like something we might need to add in OE.. Nov 02 15:48:13 ndec: https://groups.google.com/forum/#!topic/opkg-devel/UzDigiuKBcs Nov 02 15:50:01 the patches are on the opkg mailing list...the three middle patches are the ones that will fix the symlinks filenames. I asked Paul to do a small modification to one of the patches, that's why I haven't pulled them in the opkg repo yet Nov 02 15:50:27 once I get the modified version, we need to add them to the opkg recipe Nov 02 15:53:48 OK. I will give them a try.. Thx Nov 02 15:54:12 np Nov 02 15:54:55 I was actually not looking at the right patches.. That's why I was confused! Nov 02 16:35:00 BTW a few people last week were questioning how useful prelinker was.. I just compared memory usage immediately after booting 'core-image-base' (with systemd) Nov 02 16:35:12 The prelinker saves 380k of memory.. Nov 02 16:35:53 Mem: 248920 20788 228132 196 752 Nov 02 16:35:56 vs Nov 02 16:36:04 Mem: 248920 20408 228512 196 732 Nov 02 16:36:24 (2nd and 3rd column are 'used' and 'free', in k) Nov 02 16:36:49 (this is qemuppc) Nov 02 16:38:04 so almost a 2% saving Nov 02 16:39:58 on a larger memory system, probably doesn't matter.. on a small system.. it sure will Nov 02 16:40:25 ...and this is just after booting, the system isn't really "doing anything" yet Nov 02 16:40:48 (I'm surprised honestly it's that big.. I wasn't expecting 380k of COW pages due to relocations) Nov 02 16:45:45 BTW I was wrong.. that is syvinit mode.. not systemd.. Nov 02 16:48:12 1837k difference of core-image-sato -- (running in nographic mode) Nov 02 17:24:01 FYI. core-image-sato w/ systemd.. the savings due to prelink is 864k.. (less then sysvinit.. I'm actually surprised by that) Nov 02 17:24:20 (after I finish validating this stuff.. I'm going to need to go back and collect the statistics for real..) Nov 02 17:25:14 fray, 864k over the whole fs image size? which is ... ? Nov 02 17:25:27 that is memory used during boot until login Nov 02 17:25:37 oh, ok. Nov 02 17:25:39 NON systemd requires 864k more ram Nov 02 17:25:52 this is effectively a count of "perminent" COW pages (due to services, init, etc..) Nov 02 17:26:14 'er.. not non-systemd.. non-prelink with systemd is what I meant Nov 02 17:26:29 yea, figured that was what you meant. Nov 02 17:27:27 I'm a bit surprised that sysvinit required more memory (COW) then systemd.... but systemd requires more overall memory.. Nov 02 17:27:31 interesting result Nov 02 17:28:24 guessing sysvinit has more fork/exec activity than systemd... Nov 02 17:28:30 ya.. Nov 02 17:28:41 but the COW pages are cleared when whatever was executed is freed.. Nov 02 17:28:51 so there are more COW pages -not- freed in sysvinit then systemd Nov 02 17:30:08 (I need to figure out how to get bootchart working on this and compare memory and performance.. as well as put in a wrapper that starts collecting LD load statistics) Nov 02 17:30:25 then I can get some better data as to how prelink affects the entire boot process Nov 02 17:43:26 hmm, I have a question about packages that provide same stuff; assuming I have two packges which exlcude each other via RREPLACES/RCONFLICTS and both would install a script that has the same name; when building I get an error "recipe is trying to install files into a shared area when those files already exist" Nov 02 17:43:46 what's the solution for this? Nov 02 17:43:54 and is there one at all? Nov 02 17:48:45 even though they are conflicts like tha you need to use the update-alternatives mechanism to avoid the QA Nov 02 17:49:10 Jin^eLD: RREPLACES and RCONFLICTS are only for packaging, that doesn't cover how these overlaps might be handled in the sysroot Nov 02 17:50:15 ok so thta means for sysroot - update alternatives would be the correct solution? Nov 02 17:55:48 I'm actually not sure alternatives help within the sysroot Nov 02 17:56:15 they do.. cause in order to use it, you can't have duplicate filenames.. ;) Nov 02 17:56:58 ah, heh Nov 02 17:57:19 fray: well, not quite, alternatives work in the way that you do not have duplicate filenames, ist just that alternatives link you the files appropriately Nov 02 17:57:41 it could solve this particular problem though because I would be forced to rename my script and define alternative rules for it Nov 02 17:57:44 fray: but do we actually have logic to actually run update-alternatives on the build host so that symlinks are set up? Nov 02 17:57:59 I know how they work, I'm just saying how they fix the sysroot issue.. same principle.. one ends up the filename (via link), and hte rest have unique names Nov 02 17:58:21 bluelighting the update-alternatives won't be run in the sysroot (I think), but the names will be unique. preventing errors.. Nov 02 17:58:36 this is only an issue if two packaged are trying to provide the same header or the same shared library.. Nov 02 17:58:43 (which can happen for some odd OpenGL type cases) Nov 02 18:00:32 /away Nov 02 18:01:46 thanks for the hint btw, will try it out now Nov 02 18:16:27 systemd - core-image-sato - prelink saves 560k of ram on 'after startup' Nov 02 18:16:33 'er.. qemuarm Nov 02 19:41:30 and MIPS64 is 1504k savings using prelink on a systemd - core-image-sato..... Nov 02 19:44:25 fray, speaking of prelink, how would I best disable it to test if it fixes ppc boot issues? Nov 02 19:51:11 in your local.conf, remove "image-prelink" from USER_CLASSES Nov 02 19:51:32 and there is a chance it will.. I've got a fix (in testing) that adjusts the gcc setting to make ti work properly Nov 02 19:52:07 (reminds me, I likely should add a commit that makes the image-prelink refuse to go, if the user has uses the bssplt) Nov 02 19:52:21 ...even though the prelinker SHOULDN'T trigger failures... :P **** ENDING LOGGING AT Tue Nov 03 02:59:58 2015