**** BEGIN LOGGING AT Wed Feb 02 02:59:58 2011 Feb 02 04:44:29 Whee, adding qt4 images and getting like 75% working finally pushed my job out to as long a build time as I was hoping Feb 02 04:44:37 more stuff fixed next time, heh Feb 02 04:57:28 Tartarus, I took care of that thing you emailed about. Feb 02 07:13:21 XorA: can you add to topic that tinderbox is down administratively? Feb 02 07:16:13 Jay7, you here? Feb 02 07:16:20 ka6sox-away: yes Feb 02 07:16:45 okay we fixed a number of things...lets try again when you are ready. Feb 02 07:17:03 we can do one attempt right now :) Feb 02 07:17:42 lemme get the mysql probe going. Feb 02 07:17:50 or I'll have some more time after 30 min Feb 02 07:18:03 kk Feb 02 07:18:12 do your thing...I'll get setup Feb 02 07:18:17 ok Feb 02 07:42:32 Jay7, this: http://webos-internals.pastebin.com/U8JV2evS Feb 02 07:42:42 is whats killing oe_stats Feb 02 07:42:58 its looking thru a log that has 15MILLION records. Feb 02 07:43:35 if oestats_task.log isn't indexed, it has to scan the entire 15 million record table EVERY TIME a query like that runs.... Feb 02 07:44:06 so, use a simple index should speed things up a bunch. Feb 02 07:44:14 hm.. Feb 02 07:44:40 I think we can safely delete pre-2009 data Feb 02 07:44:55 at least logs Feb 02 07:45:45 rick-home meet Jay7 Feb 02 07:45:51 hi jay Feb 02 07:45:56 rick-home: hey Feb 02 07:45:59 rick-home, is working on a index to help this Feb 02 07:46:05 cool Feb 02 07:46:10 no, fran is working on it. Feb 02 07:46:14 :) Feb 02 07:46:42 The stats package is doing a bunch of queries where they have a where clause like "where log = "logs/340930.log" or some such. Feb 02 07:46:53 but the tasks table has 15 million + records in it Feb 02 07:46:59 and the log field wasn't indexed Feb 02 07:47:16 so the sql server had to sequentially scan the entire 15 million record table for every query. Feb 02 07:47:22 which was "bad." Feb 02 07:47:34 well.. making index on log field may be good idea from this PoV Feb 02 07:48:29 but imho we should have 'year-maintenance' task for oestats DB Feb 02 07:48:41 to remove old stuff at least Feb 02 07:48:46 yes, since it took a query that took over 2 minutes to a query that took under 300 milli-seconds. Feb 02 07:49:14 rick-home: can you make SELECT min(timestamp) FROM oestats_task? Feb 02 07:49:16 and my thread count on the server immediately cut by half once the index was complete. Feb 02 07:49:37 sure. Feb 02 07:49:42 we can make that. Feb 02 07:49:43 why? Feb 02 07:50:06 I just wish to know how old data is stored in DB now Feb 02 07:50:43 rick-home, can you do that directly from phpmyadmin? Feb 02 07:50:45 2010-08-02 14:10:57 Feb 02 07:50:52 iirc someone said that only 3 months history is kept in oestats Feb 02 07:51:05 hm.. looking reasonable Feb 02 07:51:08 that would not be correct JaMa|Wrk Feb 02 07:51:14 4months Feb 02 07:51:30 five Feb 02 07:51:37 oh right Feb 02 07:51:39 wow.. Feb 02 07:51:51 3million records/month Feb 02 07:51:59 ka6sox-away: testing initiative Feb 02 07:52:06 15M rows in 5 months looks like we're pretty active with oestats Feb 02 07:52:21 that was reason Feb 02 07:52:32 Jay7, understand. Feb 02 07:52:45 well.. Feb 02 07:52:47 don't think that oestats was designed for this big. Feb 02 07:53:04 we should review sql queries produced by django-oestats Feb 02 07:53:13 and may be make some indexes Feb 02 07:53:23 can any one help me how to run oe image on qemu emulator? Feb 02 07:53:28 btw Feb 02 07:53:39 this indexing should help a bunch it seems. Feb 02 07:53:41 rick-home: what is storage type of DB? MyISAM? Feb 02 07:53:58 we should try to migrate to innodb Feb 02 07:54:03 we have both innoDB and MyISAM. Feb 02 07:54:34 at least this should solve that table breakages Feb 02 07:54:46 yes, myisam and innodb Feb 02 07:54:48 iirc yours are already innodB but I'd have to look again. Feb 02 07:54:54 innodb shouldn't require manual repair Feb 02 07:54:59 nope Feb 02 07:55:26 oestats is MyIsam? Feb 02 07:55:45 no Feb 02 07:55:48 it's innodb Feb 02 07:56:07 ok Jay7 here's my next trouble query... Feb 02 07:56:09 SELECT DISTINCT `oestats_package`.`status` FROM `oestats_package` ORDER BY `oestats_package`.`status` ASC Feb 02 07:56:45 another field w/o index? Feb 02 07:57:01 ah.. distinct.. Feb 02 07:57:13 but status isn't indexed.... Feb 02 07:57:24 well.. create it :) Feb 02 07:57:31 I will I will. Feb 02 07:57:34 :-) Feb 02 07:57:49 to clear situation - I'm not oestats devel ;) Feb 02 07:58:01 I'm just trying to understand and improve it :) Feb 02 07:58:29 me too, since I don't want my mysql server barfing Feb 02 07:59:04 btw, I have heard some talks about DISTINCT vs GROUP BY and DISTINCT was slower Feb 02 07:59:10 not sure about engine Feb 02 07:59:18 the jet profiler explanation of that query said "Join size 1,238,235 (Very Bad Very Slow) Feb 02 07:59:56 ORM's :( Feb 02 08:00:13 Once we add the index, it returns 4 rows in umder 100 ms. Feb 02 08:00:53 ok, inserts I can't do much about.... Feb 02 08:01:28 SELECT `oestats_package`.`id`, `oestats_package`.`timestamp`, `oestats_package`.`build_id`, `oestats_package`.`name`, `oestats_package`.`version`, `oestats_package`.`revision`, `oestats_package`.`depends`, `oestats_package`.`status`, `oestats_package`.`qalog` FROM `oestats_package` WHERE `oestats_package`.`qalog` = 'logs/qa/663769.txt' ORDER BY `oestats_package`.`timestamp` DESC Feb 02 08:01:46 guess what? Feb 02 08:01:54 heh :) Feb 02 08:01:57 not indexed? Feb 02 08:03:08 selected from 1.2 million records by sequential scan of the table... Feb 02 08:03:44 now returns 1 row in under 0.004 seconds Feb 02 08:03:56 does this all need to be coded into the package? Feb 02 08:04:38 we need to export the table definitions and they need to put them in the package... Feb 02 08:05:13 yes, good idea Feb 02 08:05:27 SELECT DISTINCT `oestats_build`.`status` FROM `oestats_build` ORDER BY `oestats_build`.`status` ASC Feb 02 08:06:06 this is not rocket science..... Feb 02 08:06:18 good morning Feb 02 08:06:27 good morning mckoan Feb 02 08:06:47 Jay7, can you do that? Feb 02 08:07:00 and another select distinct.... on package name Feb 02 08:07:23 ka6sox-away: I think I will import oe-stats code into OE contrib tree Feb 02 08:07:29 then make all fixes there Feb 02 08:07:35 if no one will complain against Feb 02 08:07:41 Jay7, good plan.. Feb 02 08:07:49 needs updating Feb 02 08:07:55 since it is so large. Feb 02 08:08:29 15M records without index is hard on SQL server. Feb 02 08:08:48 timestamp = models.DateTimeField(auto_now_add=True, db_index=True) Feb 02 08:08:57 hm.. some fields should have index Feb 02 08:12:07 Jay7 I would suggest doing a search for select distinct in the source and ensuring that the correct indexes are there. Feb 02 08:12:14 and same for where clauses. Feb 02 08:12:22 and both sides of joins. Feb 02 08:12:31 rick-home: there is django ORM inside.. Feb 02 08:12:34 so.. Feb 02 08:13:03 but models.py should have this anyway Feb 02 08:13:14 ((( that sentence was in inner-geekish, I only speak OUTER geekish. ))) Feb 02 08:13:17 :-) Feb 02 08:14:12 it has python-django code mixed in. Feb 02 08:14:26 I'll prefer having plain SQL queries Feb 02 08:14:39 it's easier to understand and optimize Feb 02 08:14:40 nodnod Feb 02 08:14:46 (for me at least) Feb 02 08:14:52 you don't have anything to do with the actual tinderbox code do you? Feb 02 08:15:15 rick-home, nope Feb 02 08:15:20 just trying to help Feb 02 08:15:21 darn Feb 02 08:15:32 well..it can be upstreamed. Feb 02 08:16:14 rick-home: I will Feb 02 08:16:15 :-) that package does clever things like "Select * from tasks" -- which returns 15 million records. Feb 02 08:16:28 but not sure about results ;) Feb 02 08:17:06 Jay7, it looks like it was designed for single dev not entire team beating and regressing. Feb 02 08:17:15 ka6sox-away: yeah Feb 02 08:18:13 Jay7 -- one more note: you mentioned the difference between group by and distinct. Feb 02 08:18:36 I have one example from stats where it would make a big difference. Feb 02 08:18:38 SELECT DISTINCT `oestats_package`.`name` FROM `oestats_package` ORDER BY `oestats_package`.`name` ASC Feb 02 08:18:48 turning that into Feb 02 08:19:07 SELECT `oestats_package`.`name` FROM `oestats_package` group BY `oestats_package`.`name` Feb 02 08:19:12 would speed it up a LOT Feb 02 08:19:16 oh Feb 02 08:19:31 well.. Feb 02 08:19:46 the distinct and the order using the same element, caused it to slow down a bunch. Feb 02 08:20:12 rick-home: was this on indexed field? Feb 02 08:20:17 yep Feb 02 08:20:20 ok Feb 02 08:20:21 name was indexed. Feb 02 08:20:30 well, it is now. Feb 02 08:20:30 I'll mark this somewhere :) Feb 02 08:22:08 ka6sox we're holding steady now at about 10 to 12 threads, with no slow queries with stats running. Feb 02 08:22:24 okay thats normal... Feb 02 08:22:31 cool Feb 02 08:22:38 we have oestats working again :) Feb 02 08:22:55 but it needs to be "updated' in the package. Feb 02 08:22:58 tweaking the sql server buffers and such helped a lot. Feb 02 08:23:22 and then, using jet profiler to find the "problem children" queries. Feb 02 08:23:42 can you please dump current DB scheme? Feb 02 08:23:46 if you've never used that, I can not reccomend it enough. Feb 02 08:23:53 to be used as reference later Feb 02 08:25:20 Jay7 http://pastebin.com/erJVRDc5 Feb 02 08:27:16 rick-home: thanks! Feb 02 08:28:02 ka6sox-away, rick-home: thank you for fixing oestats :) Feb 02 08:28:19 Jay7, I just stood back and watched the magic Feb 02 08:28:50 Jay7 you cool with what we did? and why? Feb 02 08:28:51 also your wiki should be happier with 60,000 less robot hits/day Feb 02 08:29:01 oh yeah, that. Feb 02 08:29:14 I added a bit to your robots.txt file..... Feb 02 08:29:30 (as in, made it five times as long) Feb 02 08:29:38 oestats isn't for robots anyway Feb 02 08:29:49 Jay7, this was for wiki Feb 02 08:29:52 no no, the WIKI's robots.txt Feb 02 08:29:53 ah Feb 02 08:29:59 ok then :) Feb 02 08:30:04 googlebot was hitting recent changes 6000 times a day Feb 02 08:30:11 googlebot seemed to LOVE you Feb 02 08:30:21 I blocked everything except actual ARTICLES Feb 02 08:30:38 so, REAL content is indexed, but everything else is skipped. Feb 02 08:33:10 Jay7, so all the changes are you okay with? Feb 02 08:33:18 yes, sure Feb 02 08:34:55 ka6sox fran seems stable at this point. Feb 02 08:35:59 turning stats on increased the ram use a bit, but it's not horrible. I really think we're going to be ok now. Feb 02 08:36:20 If I could find the tinderbox guy and have a few choice words, we'ld be all set. Feb 02 08:36:26 okay so is this all our problem children? Feb 02 08:36:33 for tonight, yes Feb 02 08:36:34 load will be raised when all autobuilders will see that oestats is online again :) Feb 02 08:36:48 Jay7 load on the sql server? Feb 02 08:36:54 yes Feb 02 08:36:58 hmmmmm Feb 02 08:37:04 Jay7, with indexing that should help Feb 02 08:37:09 we'll watch it overnight and see what happens. Feb 02 08:37:16 not very high anyway Feb 02 08:37:25 oestats-client is doing only POST -> inserts Feb 02 08:37:43 yeah. Inserts just aren't very optimizable Feb 02 08:37:47 we have indexed some fields, so additional load to maintain indexes will happens Feb 02 08:37:50 they ALWAYS go to disk Feb 02 08:38:05 but anyway, sql server was killed by selects :) Feb 02 08:38:28 the load to maintain the indexes is nothing compaired to the load to handle non-indexed selects in 15 million records Feb 02 08:38:36 yeah, sure Feb 02 08:39:00 ok, then have a good night sir. Feb 02 08:39:13 good night :) Feb 02 08:54:30 Jay7: try to get a dump of the mysql tables/queries of oestats Feb 02 08:54:39 ant_work: have already :) Feb 02 08:54:51 I mean mysql dump Feb 02 08:55:04 imho you don't need innodb for that. that's for transactions, etc. Feb 02 08:55:17 myisam is way faster for such queries Feb 02 08:55:19 queries are generated by django's ORM Feb 02 08:55:35 yea, structure of db & indexes need review Feb 02 08:55:42 ant_work: myisam is good for select Feb 02 08:55:51 sure Feb 02 08:56:12 but it is failing easily and need manual repair Feb 02 08:56:34 it depends... Feb 02 08:57:03 anyway, good job ;) Feb 02 08:58:47 btw, we can migrate to PostgreSQL Feb 02 08:58:55 move to something NoSQL then :) SQL is pretty overkill for such project Feb 02 08:58:57 that is good side of ORMs :) Feb 02 09:00:07 with NoSQL you don't even need any ORM, it's schema-less anyway Feb 02 09:00:15 I am going to talk to the Postgres guys @ SCALE next month. Feb 02 09:00:57 the issue is that too many things need a SQL server....all the mediawikis etc use it. Feb 02 09:01:27 oh, mediawiki, that's quite heavy also Feb 02 09:03:07 yup...try having 20 mediawikis beating up on your server. Feb 02 09:03:47 and THEN something unindexed doing 15million record selects Feb 02 09:04:00 unindexed, fun Feb 02 09:05:01 what's in those 15M records? Feb 02 09:05:05 packages? Feb 02 09:05:15 probably build messages. Feb 02 09:05:24 let me look @ the query Feb 02 09:05:24 ah Feb 02 09:06:10 http://webos-internals.pastebin.com/U8JV2evS Feb 02 09:07:13 the where was the killer I think I read. Feb 02 09:08:34 681 builds in there. Feb 02 09:10:26 it can be the join and order(s) also Feb 02 09:10:41 some of the joins were ugly Feb 02 09:10:52 btw. did you tried to run that query with EXPLAIN? Feb 02 09:11:01 or how it's called Feb 02 09:11:18 ynezz: rick-home was profiled it Feb 02 09:11:30 ok then :) Feb 02 09:11:45 but right now we can only create indexes :) Feb 02 09:11:58 http://pastebin.com/erJVRDc5 Feb 02 09:12:05 thats the schema Feb 02 09:12:31 I can dump the server out too. Feb 02 09:14:55 okay things are improved...there is more to do but things aren't going to fall down and go boom anymore Feb 02 09:15:11 that's good :) Feb 02 09:15:33 looking at it, I wonder why it's not ordering by id, but by timestamp, the id might be faster Feb 02 09:15:49 ynezz, tinderbox.oe.org would start a series of queries that lasted over 20minutes before the page would load. Feb 02 09:16:17 when the SQL server fell over there were over 300 of those series in the queue. Feb 02 09:16:47 no wonder Feb 02 09:17:32 http://munin.nas-admin.org//nas-admin.org/fran/mysql_threads.html Feb 02 09:17:55 the big mountiantop on the weekly was tinderbox. Feb 02 09:19:57 hm, munin looks good Feb 02 09:21:02 without munin it would be hard to manage 22 VMs Feb 02 09:25:01 64DB, 3,102 tables. Feb 02 09:25:59 22 VMs, it's on one box? Feb 02 09:26:11 3 Feb 02 09:26:36 3 physical machines. Feb 02 09:27:09 hopefully controlled by ganeti soon. Feb 02 09:27:15 setting up drbd now... Feb 02 09:29:35 01:30 here..time for some sleep. Feb 02 09:29:36 nite Feb 02 09:29:53 Jay7, thanks for the help...I sleep now Feb 02 09:30:11 nite Feb 02 09:30:17 ka6sox-away: nite Feb 02 09:55:06 hi hrw Feb 02 09:57:31 hm.. Feb 02 09:57:40 hi jay7 Feb 02 09:57:41 anybody know people from jay-tech.de? Feb 02 09:57:43 hi woglinde Feb 02 09:58:05 my site is jay-tech.ru and people here sometimes asking me for support Feb 02 09:59:05 seems I should place banner on site about 'I have no official relations with jay-tech.de' Feb 02 10:00:43 ;D Feb 02 10:01:05 like OESF from Japan has nothing common with oesf forums Feb 02 10:01:24 jay7 yes Feb 02 10:02:06 or I should contact with jay-tech.de and talk about contracted support ;) Feb 02 10:02:19 haha Feb 02 10:03:22 woglinde: so, do you know some people from jay-tech.de? Feb 02 10:05:57 no Feb 02 10:06:00 hi effem Feb 02 10:06:09 ah, ok Feb 02 10:06:27 well.. let's contact via site then.. Feb 02 10:06:54 maybee they wil set there laywes than on the way Feb 02 10:07:03 and you may loose your domain Feb 02 10:07:09 laywers Feb 02 10:07:55 woglinde: no problem, I'll register other ;) Feb 02 10:08:28 but people should have support Feb 02 10:17:40 http://dudeism.com ROTFL Feb 02 10:49:40 how do I enable testlab directory creation ? Feb 02 10:53:21 I wonder why I have conf/distro/include/angstrom.inc:INHERIT += "testlab" but is not generated Feb 02 11:17:41 looks like gdb-cross install its binaries into the target filesystem Feb 02 11:17:52 is it normal? Feb 02 11:26:24 hi, how can I add a custom /etc/fstab file for my machine? Feb 02 11:27:02 hello Feb 02 11:30:52 Helio_2000: look into recipes/initscripts Feb 02 11:31:09 opn: welcome Feb 02 11:31:24 ok, thanks Feb 02 12:38:13 hi obi Feb 02 12:38:31 hi woglinde! Feb 02 12:39:43 mckoan|away: Helio_2000: why not base-files? Feb 02 12:42:06 hi, tyring to get an angstrom build for the mini6410 working. I am new to all this but I have OE setup and building cleanly, I am having problems with the rootfs mounting during boot. Feb 02 12:43:36 has anyone managed a successful build for the mini6410? I was following the steps outlined in http://fl0rian.wordpress.com/2010/09/22/mini6410-getting-started-with-free-software/ Feb 02 12:46:17 I have looked at the mini6410.conf (/conf/machine/) and checked the MKUBIF_ARGS and UBINIZE_ARGS and they seem ok for my board. I am not sure if the conf files that are currently part of the OE repo are set up for the 1gb nand device. Feb 02 12:47:10 ? Feb 02 12:47:24 what happens at boot time? Feb 02 12:47:32 use pastebin Feb 02 12:47:35 astebin Feb 02 12:47:39 ~pastebin Feb 02 12:47:39 [~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude. Feb 02 12:51:27 http://pastebin.com/k3DR6UhT Feb 02 12:55:37 padraig does it have buildin nand? Feb 02 12:55:45 maybee try with jffs2 first Feb 02 12:55:51 or maybee its corrupted Feb 02 12:57:22 hi mickeyl Feb 02 12:57:40 woglinde, sorry about this but I pasted a bootlog from a previous problem, this is the right one http://pastebin.com/k3DR6UhT Feb 02 13:01:25 does the IMAGE_FSTYPES in local.conf overwrite the one in conf/machine/mini6410.conf or append to it Feb 02 13:02:51 for the mini6410 it is IMAGE_FSTYPES = "tar.bz2 ubi" and I have tried IMAGE_FSTYPES = "ext3 jffs2" for the local.conf a while ago but I still had problems Feb 02 13:03:06 hm Feb 02 13:09:55 I was wondering has anyone had a sucessful build and boot with a 1gb mini6410 with the mini6140.conf file currently in the repository Feb 02 13:12:19 padraig there arent many mini's user Feb 02 13:14:00 re Feb 02 13:14:14 re florian Feb 02 13:16:08 padraig: I got your mail but didn't manage to answer yet... Feb 02 13:16:18 Hi florian Feb 02 13:16:31 That is no problem, whenever you get a chance Feb 02 13:21:55 thanks for the blog post, It was the only place I could find the first steps for OE and the mini6410, sorry but I think I sent you an older copy of the bootlog, the right bootlog is here http://pastebin.com/QycWV1Ms Feb 02 13:42:51 JaMa|Wrk: you were right, it's easier with base-files Feb 02 14:25:26 thanks for your help woglinde Feb 02 14:32:23 03Stefan Schmidt 07master * rf45a17f8fd 10openembedded.git/recipes/connman/connman_0.68.bb: connman_0.68: Update configure options and enable ofono plugin Feb 02 14:32:29 03Stefan Schmidt 07master * r81702dbf42 10openembedded.git/recipes/wpa-supplicant/ (2 files in 2 dirs): Feb 02 14:32:32 wpa-supplicant_0.7.3: Enable the new DBUS API and bump PR. Feb 02 14:32:32 The new dbus API is needed for at least connman >= 0.68 maybe others as well. Feb 02 14:43:04 OK, qt 4.6.3 + -xmlpatterns seems to trigger some pretty stupid bug in the qt configure system (it's not seeing that OE_QMAKE_CXX is set in the env and thus failing to configure) Feb 02 14:43:16 Moving libqt4xmlpatterns to RRECOMMENDS in the task instead Feb 02 14:47:23 padraig has quit....too bad Feb 02 14:48:08 gm Feb 02 14:48:44 hey likewise Feb 02 14:53:43 Jin^eLD: hi there Feb 02 14:56:59 hi Feb 02 14:57:03 about ubifs Feb 02 14:57:24 with the help of JaMa I found the correct args for the nokia900 Feb 02 14:57:40 do I need to include a dmesg log before the ubinize and mkubifs args Feb 02 14:57:41 ? Feb 02 15:53:05 03Mike Westerhof 07org.openembedded.dev * r5a86c62884 10openembedded.git/recipes/meta/slugos-packages.bb: Feb 02 15:53:05 SlugOS: slugos-pacakges.bb - change kexec back to kexec-tools Feb 02 15:53:05 (DEPENDS requires the recipe name, not the package name) Feb 02 15:53:05 Signed-off-by: Mike Westerhof Feb 02 16:06:50 good morning (or afternoon) Feb 02 16:08:43 I am messing with a wl1273 module on a cortex a8 platform. I am having trouble getting OE to build the driver. I can build it by hand but the recipe is fighting me. Feb 02 16:08:55 I have a question about the variable ${STAGING_KERNEL_DIR} Feb 02 16:09:14 it reports a different value than the actual directory with the kernel Feb 02 16:10:15 actually never mind Feb 02 16:23:20 Jay7 -- found another one. :-) Feb 02 16:45:04 03Tom Rini 07master * r2049a96f9d 10openembedded.git/recipes/perl/perl-rdepends_5.8.8.inc: Feb 02 16:45:04 perl-rdepends_5.8.8.inc: Remove orphaned file Feb 02 16:45:04 Signed-off-by: Tom Rini Feb 02 16:45:16 03Tom Rini 07master * rdd1762e8c7 10openembedded.git/recipes/help2man/ (help2man_1.36.4.bb help2man_1.38.2.bb): Feb 02 16:45:16 help2man: Update for using our perl-native Feb 02 16:45:16 Now that we have perl-native going early, we want to wait for Feb 02 16:45:16 it to be done, along with autoconf/automake. But that's just Feb 02 16:45:17 race prevention as we still don't want to re-run autoconf. Feb 02 16:45:17 Signed-off-by: Tom Rini Feb 02 16:45:26 03Tom Rini 07master * rf1b8330946 10openembedded.git/recipes/automake/automake.inc: Feb 02 16:45:26 automake: Updates for taking advantage of our own perl Feb 02 16:45:26 We don't need to modify what perl is used since we always mangle Feb 02 16:45:26 the results to use /usr/bin/env perl. Feb 02 16:45:26 Signed-off-by: Tom Rini Feb 02 16:45:27 03Tom Rini 07master * rc82877715f 10openembedded.git/recipes/autoconf/autoconf.inc: Feb 02 16:45:28 autoconf: Clean up slightly our mangle for /usr/bin/env Feb 02 16:45:28 Signed-off-by: Tom Rini Feb 02 16:51:04 hm.. Feb 02 16:51:11 rick-work: fix it! :) Feb 02 16:51:22 Jay7 did Feb 02 16:51:26 still finding more. Feb 02 16:51:42 you got an email I can get you the eventual structure too? Feb 02 16:51:54 Tartarus: ping Feb 02 16:52:15 rick-work: not sure.. send it to jay4mail at gmail com Feb 02 16:52:23 done Feb 02 16:52:48 still trying to get googlebot to quit banging on the wiki Feb 02 17:10:18 does anybody know why Angstrom doesn't generate any testlab directory under tmp/deploy/images/MACHINE ? Feb 02 17:13:06 JaMa|Off: you're right Feb 02 17:17:36 mckoan, does it still inherit the right class? Feb 02 17:24:15 Tartarus: I have conf/distro/include/angstrom.inc:INHERIT += "testlab" but is not generated Feb 02 17:26:35 od Feb 02 17:26:36 d Feb 02 17:28:56 Jay7 Good news. Mysql server held up well all night. Feb 02 17:29:10 Jay7 and I think I have the robots.txt fixed this time. Feb 02 17:40:32