**** BEGIN LOGGING AT Wed Jul 13 02:59:57 2011 Jul 13 09:32:48 Hmm, the locking code doesn't exactly perform very well :/ Jul 13 13:41:06 or maybe it does. We "lose" about 86 seconds on do_package lock contention over a build Jul 13 13:41:27 which isn't so bad all things considered Jul 13 14:22:31 morning folks Jul 13 14:23:04 RP__: I see oe-core has an outdated device_table-minimal. Do you think it would be possible to import the extended versions from oe-dev? FWIW initscripts will overwrite with own device-table and the rest of the work is done by udev. Jul 13 14:23:47 We lack devices in the initramfs and if we relay on devtmpfs we have to skip support for older kernels. Jul 13 14:23:57 morning dvhart Jul 13 14:24:37 ant_work, how old? Jul 13 14:24:56 eh.. 2007 Jul 13 14:25:07 kernel version? Jul 13 14:25:24 well, anything below 2.6.32 iirc Jul 13 14:25:24 if it's pre 2.6.16, we don't really support it anyway Jul 13 14:25:33 ok Jul 13 14:26:07 I meant device-tables file is of 2007 :) Jul 13 14:33:11 I'm now wondering how many recipes are in fact using it and fwiw the device_table.txt provided by initscripts need some purge Jul 13 14:34:20 and, well, what was the point of overwriting it? Jul 13 14:36:12 ant_work, could you write up your thoughts/suggestions and send to the list? Jul 13 14:36:21 ant_work, I can't look into it just now Jul 13 14:36:31 yes, I've found a couple of dinosaurs Jul 13 14:36:58 thanks Jul 13 14:37:02 yw Jul 13 15:21:54 Hmm.. I just noticed.. some of the man pages we produce are compressed and some aren't.. we'll likely need to clean that up at some point.. :P Jul 13 15:39:30 fray: right. file a low priority bug ;-) Jul 13 15:40:05 do we have a sanity check/class that takes care of documentation compression for us? this certainly seems like something to centralize.. Jul 13 15:42:08 fray: Likely we need to add something to the base_do_install function or similar Jul 13 15:42:08 1238 Jul 13 15:42:13 or a do_install postfunc Jul 13 15:42:28 ya, I was thinking do_install postfunc.. with a switch to enable/disable compression.. Jul 13 15:42:41 I'd just compress them tbh Jul 13 15:42:44 and a sanity check that matches the compression setting Jul 13 15:43:04 I've been on systems where they didn't want hte man pages compressed.. (I'm not entirely sure why.. but thats what they wanted) Jul 13 15:43:38 Good Morning ! Jul 13 15:44:05 fray: I'm a little wary of adding too many switches, is that really a common usecase? Jul 13 15:44:14 the other thing we need to do, once we start compressing man pages, is ensure that the data stamps are not recorded in them.. otherwise we'll get file conflicts Jul 13 15:44:25 (there is a switch to gzip to do that) Jul 13 15:44:38 fray: please note in the bug ;-) Jul 13 15:44:42 hi nitink Jul 13 15:44:43 Honestly, I'm not sure.. the default should be to compress them of course Jul 13 15:44:51 Hi RP__ Jul 13 15:45:16 fray: I've updated rpurdie/ml with some cleanup of the multilib stuff Jul 13 15:45:49 trying to find the option.. Jul 13 15:45:54 RP__ I noticed some changes a bit ago Jul 13 15:46:34 fray: I was looking at http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml&id=81a52db9a6e32620d3cc1ae559179a64960f9dcf Jul 13 15:47:19 ya, bit messy.. but it works and shows the info we need at the rootfs step Jul 13 15:47:37 Two questions - is it really necessary to change package_update_index_rpm() as much or could we just set rpmarchs="${PACKAGE_ARCHS} ${MULTILIB_ARCHS}"? Jul 13 15:48:16 fray: and does your MULTILIBS_ARCH match the one Lianhao added to compute automatically in package.bbclass? Jul 13 15:48:27 it was.. let me try to explain.. (I have to look at the code and remember why) Jul 13 15:48:45 fray: if it is, fine, I was just looking at it and couldn't quite see why Jul 13 15:49:32 * RP__ suspects we need to take a look at the PACKAGE_ARCHS variable a little more Jul 13 15:49:51 * RP__ is also unhappy with the way some of the tune files are working but doesn't see how to fix it :/ Jul 13 15:50:16 happy to listen to tune issues and suggest answers (if I have any) Jul 13 15:50:39 I've been trying lib32 and lib64 builds with qemux86 as my base machine. This gets TARGET_CC_ARCH = "--march=i586" Jul 13 15:51:00 That blows up if you try and call gcc with that and -m64 Jul 13 15:51:03 ok.. the stuff was split out because as part of the generate of the index, we also generate a solver configuration file.. Jul 13 15:51:12 the solver configuration file is different for each multilib. Jul 13 15:51:29 Now obviously my config is bogus but I'm wondering if the system can/should be helping me a little more Jul 13 15:51:42 If we don't do that, then RPM uses -all- available packages in it's solution matrix.. first found wins.. the problem is when we ask for bash, and we build bash-32 and bash-64 which do we actually want? Jul 13 15:52:00 The RPM way of doing this (on a traditional system) is that we install bash for the base system, and only install the alternative if asked to Jul 13 15:52:09 fray: Traditionally, I'd say the first listed in PACKAGE_ARCHS Jul 13 15:52:12 you can't tell the solver this.. so you run the solver in multiple passes Jul 13 15:52:53 RPM's internal resultion favors a solution based on the arch of the package matching the arch of the requester.. the preferred arch always wins.. Jul 13 15:53:02 preferred arch is 64-bit by default Jul 13 15:53:36 so if you have foo-64 and foo-32 both requiring bash.. foo-64 will see that bash-64 is selected. foo-32 will see that bash-32 is selected.. the resolver code kicsk and ONLY bash-64 is installed.. Jul 13 15:53:40 likely not what was desired.. Jul 13 15:53:48 (that assumes the 32-bit is the default ARCH) Jul 13 15:54:42 so the changes build multiple solver resources. The resolution is then default (32-bit) arches.. We then resolve the alternative, using the 32-bit resolution as input.. Jul 13 15:54:51 (at least thats the intent, if the code doesnt work that way it was a mistake) Jul 13 15:59:05 looking at the package_update_index_rpm function.. looks like the only reason for this was the generation of the "${RPMCONF_TARGET_BASE}-${archvar}.conf" file. That file lists the location of solvedb for each of the ${archvar} types.. before there was only one configurationf ile.. (for the base config) Jul 13 15:59:50 if we delayed generation of that file, the original function could like exist without modification.. (note I don't really like the SDK changes that are there either.. they really duplicate the xisting code..) that whole thing is a mess Jul 13 16:00:12 yes, I think we need to refactor this stuff Jul 13 16:00:37 and the sdk stuff should be able to benefit from some of the mutlilib improvements Jul 13 16:01:56 so anyway.. the point of this patch is really that we need to know all of the "ARCHS" for each of the multilibs.. and a way to understand the prefix for the multilibs so we can re-write them.. Jul 13 16:02:03 if we have that... we can do whatever we need to on the back ends Jul 13 16:02:56 (and what i have there won't work in a tri-arch system.. so it has to be fixed to deal with that as well) Jul 14 01:35:37 hi jiajun1, sgw sends me your way re poky/oe-core and the qemu test images Jul 14 01:36:12 Tartarus: Hi tartarus, welcome to use it. Anything I could help you? Jul 14 01:36:36 in oe-core, it doesnt seem to know root pw Jul 14 01:36:45 have to zap the pw from console before the tests pass Jul 14 01:38:39 Sorry, do you mean you need to enter root passwd to create tap for QEMU creation? Jul 14 01:39:17 no, i mean on the target Jul 14 01:43:31 gen'ing some logs, sorry Jul 14 01:48:23 In my testing, target image does not require any passwd, so i just enter a "\r" in my code Jul 14 01:48:51 yes, if you could give me some logs, it would be helpful Jul 14 01:49:44 Have you run them on oe-core too? Jul 14 01:49:47 Or just the poky tree? Jul 14 01:49:53 (and I'm using core-image-sato atm) Jul 14 01:54:11 I did not try oe-core before, I could have a try quickly Jul 14 01:55:26 jiajun1: OK, here's my "works" http://pastebin.com/Yq3RQsgp and here's my fails: http://pastebin.com/FJjXJ7r6 Jul 14 01:55:31 and I can throw the whole log file somewhere if needed Jul 14 02:00:05 Tartarus: are you able to ssh on target when the failure comes up? Does the target need passwd? Jul 14 02:00:36 yes, it needs a pw Jul 14 02:00:40 and I don't know what it is Jul 14 02:00:45 this is just stock oe-core Jul 14 02:05:55 I need have a check with sgw, wait a moment Jul 14 02:09:03 k, no rush, thanks Jul 14 02:16:32 Tartarus: jiajun1 and I are on the phone, I think I just figured it Jul 14 02:16:43 ok Jul 14 02:19:18 Tartarus: zap_root_passwd ring a bell for you? Jul 14 02:37:14 yeah, i think I even just now added it, but shouldn't that be in by default for tests so they work? or is that a local testing mod I skipped over on the wiki page? Jul 14 02:47:29 Tartarus re siteinfo stuff.. the dynamic stuff came from us at WR.. i wrote the original version Jul 14 02:54:50 Tartarus: I need to figure out what's different there, let me dig into the autobuilder setup. **** ENDING LOGGING AT Thu Jul 14 02:59:57 2011