**** BEGIN LOGGING AT Sun Jun 12 23:59:57 2005 Jun 13 08:22:24 <[g2]> jacques, ping Jun 13 08:23:50 <[g2]> jacques, I just put a TZ=EST5EDT4 and export it in my profile Jun 13 08:24:01 <[g2]> then my TZ correct for me in openslug Jun 13 08:24:14 <[g2]> python tests pass 244 and 4 failed Jun 13 08:24:19 <[g2]> I can send you the log Jun 13 08:24:24 <[g2]> or post it on the wiki Jun 13 08:27:36 damn, missed him Jun 13 08:56:42 wb [g2] Jun 13 08:56:49 those python results sound like mine Jun 13 08:56:57 I got: Jun 13 08:57:06 249 tests OK. Jun 13 08:57:06 3 tests failed: Jun 13 08:57:06 test_mimetools test_random test_urllib2 Jun 13 08:57:06 38 tests skipped: Jun 13 08:57:08 ... Jun 13 08:57:15 5 skips unexpected on linux2: Jun 13 08:57:15 test_tcl test_dbm test_gdbm test_locale test_bsddb Jun 13 08:58:52 <[g2]> 244 tests OK. Jun 13 08:58:52 <[g2]> 4 tests failed: Jun 13 08:58:52 <[g2]> test_ioctl test_mimetools test_random test_urllib2 Jun 13 08:58:52 <[g2]> 42 tests skipped: Jun 13 08:59:05 test_ioctl hmm Jun 13 09:01:28 <[g2]> jbowler, jacques did you hear beewoolie got the booting the kernel from jffs2 working last night ? Jun 13 09:01:44 yeah I saw, that's fantastic news Jun 13 09:02:32 Yes, I saw it in the log - sent a response saying that reading SysConf isn't necessary for openslug (openslug works fine if sysconf is all zeros.) Jun 13 09:05:11 <[g2]> 9 skips unexpected on linux2: Jun 13 09:05:12 <[g2]> test_dbm test_bz2 test_gdbm test_bsddb test_zipimport test_gzip Jun 13 09:05:12 <[g2]> test_tcl test_zlib test_locale Jun 13 09:05:43 <[g2]> jbowler, Jun 13 09:05:58 <[g2]> I guess the rtc logging is still in there Jun 13 09:06:02 <[g2]> raw x1205 read data - sec-45 min-58 hr-95 mday-13 mon-05 year-05 wday-01 y2k-20 Jun 13 09:06:02 <[g2]> rtc_time output data - sec-45 min-58 hr-15 mday-13 mon-05 year-105 wday-01 epoch-1900 rtc_epoch-2000 Jun 13 09:06:02 <[g2]> x1205_sync_rtc exit (RTC in sync) Jun 13 09:28:01 logging: yes, I think the kernel is still being built with debugging. Probably should leave the stuff in there until it's been proved in a release. Jun 13 09:28:56 <[g2]> jbowler, what's "proved" ? Jun 13 09:29:17 <[g2]> I've been running for many days probably a week or more if you count reboots Jun 13 09:30:57 It hasn't been in a release - so you and I and probably two or three other people (NAiL maybe) have tried it, but that's only a few cases. Jun 13 09:31:33 Still, it's cluttering up the log in an annoying fashion, so I could remove the most verbose stuff. Jun 13 09:32:47 <[g2]> jbowler, maybe you're wondering about the non NTP case Jun 13 09:37:00 The user has to ipkg install NTP, so non-NTP is the default. Still we can be pretty sure nothing touchs the RTC, because before the fixes it would eventually crash the kernel if it was used... Jun 13 09:37:17 (nothing else touchs the RTC) Jun 13 09:37:36 I havent been installing ntp, but I've been using hwclock to write to the rtc Jun 13 09:38:21 jacques: that happens automagically now (see the links to /etc/init.d/hwclock.sh in /etc/rc?.d) Jun 13 09:39:55 It seemd to be required with NTP too - it didn't seem that the clock was getting written (maybe an extra step was necessary, beyond setting the RTC?) Jun 13 09:40:41 export TZ=PST8PDT works fine for me. I think this should be in a file somewhere in /etc, but I've never managed to work out which one ;-) Jun 13 09:42:39 [g2]: configuration: look at /etc/default/conffiles in the latest builds. /etc/profile should definately be in there... Jun 13 09:42:57 And the current /etc/profile has OPIEpoo in it. Jun 13 09:45:51 timezone: daylight saving time: until about 10 years ago this was determined by act of parliament in the UK. Likewise other countries used things like the christian easter, determined by extremely complex rules! So the localtime stuff can handle the complex rules for each country whereas the built-in glibc stuff is, I believe, more limited. Jun 13 09:46:07 Also uclibc may be even more restricted (if it has anything built in.) Jun 13 09:47:12 <[g2]> actually when I was googleing for the TZ stuff it was mentioned for uClibc and busybox Jun 13 09:50:04 Hum, glibc doesn't take any notice of /etc/TZ Jun 13 09:51:22 The link http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html would seem to be authoritative. Jun 13 09:54:25 Though I seem to remember when that was being proposed (X/Open) the UK was still on the 632-old-farts-in-a-big-room rule ;-) Jun 13 09:58:22 Ok, openslug things to do, my list has: Jun 13 09:58:41 1) Make any adds to /etc/default/conffiles (known add: /etc/profile, /etc/timezone) Jun 13 09:58:55 2) Reduce excessive log messages from x1205_rtc.c Jun 13 09:59:44 3) Make a startup script for packages/nis (not required for a release, but I think it's desireable.) Jun 13 10:00:38 4) Write the wiki pages about how to use the binary and source releases. Jun 13 10:00:52 5) Add to the devio manual (more examples) Jun 13 10:01:30 * [g2] hugs jbowler :) Jun 13 10:01:39 (1) and (2) to be done before a release, (3) if possible, (4) and (5) are ongoing... Jun 13 10:02:27 <[g2]> 4 is important too Jun 13 10:03:14 Yes, it's really (0), but I have to write code every page or so of writing text ;-) Jun 13 10:03:52 <[g2]> sounds like a good plan ! Jun 13 10:04:06 <[g2]> I hope you don't feel like I'm pressuring you at all Jun 13 10:04:20 <[g2]> I really do appreciate all the help and work you are doing Jun 13 10:05:03 No pressure, it helps to write things down 'cause then I know I've achieved something. Jun 13 10:05:24 <[g2]> well I think we've achieve a tremendous amount Jun 13 10:05:48 Yes, openslug has come a very long way in 6 months. Jun 13 10:05:49 * [g2] breaks arm while slapping himself on the back :) Jun 13 10:06:28 <[g2]> it's kinda a little personal dream come true for me Jun 13 10:06:59 <[g2]> complete build linux build system and firmware from the ground up Jun 13 10:08:31 I've been running 2.4.22-xfs on a very old OE rootfs for 6 months (uptime currently 91days), my aim is for that to be replaced by a full openslug system ASAP. Jun 13 10:09:04 <[g2]> running on a slug ? Jun 13 10:09:37 Yes - both old and new are NSLU2. Jun 13 10:09:51 <[g2]> excellent Jun 13 10:10:10 Periodically the old one hangs, because my home directories are NFS exports... Jun 13 10:11:01 <[g2]> have you experience any concerns with openslug and NFS ? Jun 13 10:11:37 Not the new setup - I haven't used it enough. When I swap the systems though I will detect any problems ;-) Jun 13 10:11:50 <[g2]> ok Jun 13 10:13:16 <[g2]> jbowler, what do you think of setting noirqdebug and enabling a count of the errors ? Jun 13 10:14:18 I don't know; I'm certain something needs to be done about the irq26 problem, but I don't know what. Jun 13 10:15:26 Seaching my /var/log/messages for irq I find: Jun 13 10:15:27 Jun 12 08:10:49 (none) user.warn kernel: enable_irq(22) unbalanced from c00111d0 Jun 13 10:15:27 Jun 12 08:10:49 (none) user.warn kernel: enable_irq(29) unbalanced from c00111d8 Jun 13 10:15:53 Jun 12 08:10:49 (none) user.info kernel: ehci_hcd 0000:00:01.2: EHCI Host Controller Jun 13 10:15:54 Jun 12 08:10:49 (none) user.info kernel: ehci_hcd 0000:00:01.2: irq 26, pci mem 0x48002000 Jun 13 10:15:54 Jun 12 08:10:49 (none) user.info kernel: ehci_hcd 0000:00:01.2: new USB bus registered, assigned bus Jun 13 10:15:54 Jun 12 08:10:49 (none) user.info kernel: ehci_hcd 0000:00:01.2: park 0 Jun 13 10:15:55 Jun 12 08:10:49 (none) user.info kernel: ehci_hcd 0000:00:01.2: USB 2.0 initialized, EHCI 1.00, driv Jun 13 10:16:23 (likewise irq 28, 27) then: Jun 13 10:16:24 Jun 12 08:10:50 (none) user.warn kernel: irq26: nobody cared Jun 13 10:16:54 I only have one disk, a Maxtor OneTouch II on /dev/sda Jun 13 10:17:55 And that "nobody cared" was the only one after the ReiserFS stuff had been called to mount the /var partition (the last of the three: / /usr /var) Jun 13 10:19:10 Surely it has to be a bug in ehci_hcd? Jun 13 10:19:13 <[g2]> I've gotten dozens of those errors when natively building python, zope3, apachce, php5 etc.... however they all seem to run fin Jun 13 10:19:40 <[g2]> it's something in there or the interrupt handling Jun 13 10:19:59 <[g2]> I really wish lennert's slug wasn't toasted Jun 13 10:21:28 Oh, there's another release issue - mysql is still building 4.1.10a, but that's easy to fix in the SVN tree (by changing it to 4.1.12) Jun 13 10:21:31 same here - I get tons of those errors while native building, but they seem to be cosmetic Jun 13 10:22:25 The production of the error messages must impact performance. Jun 13 10:22:51 <[g2]> jbowler, exactly... that's why I think we should change it to a counter in the kernel Jun 13 10:22:56 well I never get more than one every 5-10 seconds or so Jun 13 10:23:34 <[g2]> I wonder if that's related to the samba crashes Jun 13 10:24:15 I wonder whether the low rate is because something throttles the output in the kernel or because of low probability Jun 13 10:26:41 <[g2]> I think it's load based Jun 13 10:55:53 <[cc]smart> jbowler: if i understood right, you created the new openslug boot concept and scripts in /boot, that correct ? Jun 13 10:56:24 <[g2]> [cc]smart, that's correct Jun 13 10:56:53 <[cc]smart> :) wanted to ask him about the redirection / .recovery creation Jun 13 10:57:07 <[g2]> nod. He'll probably be back later Jun 13 12:01:41 Back now, temporarily Jun 13 12:02:09 [cc]smart: redirection? Jun 13 12:08:02 <[cc]smart> yes, stdout redirection Jun 13 12:08:12 <[cc]smart> never saw a redirection like :> before Jun 13 12:08:15 <[cc]smart> :) Jun 13 12:08:40 <[cc]smart> anyways, meanwhile i reported my findings in http://bugs.openembedded.org/show_bug.cgi?id=86 Jun 13 12:09:30 <[cc]smart> so it's probably easier now to verify that way if i just didn't get it right or if my suggestion makes sense Jun 13 12:09:54 The ":" is the colon command. Does nothing but be there. Jun 13 12:10:33 <[cc]smart> colon command ? Jun 13 12:10:48 It's actually a shell built in. In fact it is unnecessary in those contexts, but it is if you do something like "if :" Jun 13 12:11:04 Try this: (multiple lines): Jun 13 12:11:06 if >/dev/null Jun 13 12:11:07 then Jun 13 12:11:08 fi Jun 13 12:11:13 But: Jun 13 12:11:16 if :>/dev/null Jun 13 12:11:16 thne Jun 13 12:11:18 fi Jun 13 12:11:24 works (when spelled correctly) Jun 13 12:12:11 Um, both of them work now in bash. Old sh syntax problems I suspect... Jun 13 12:12:11 <[cc]smart> ok, git it Jun 13 12:13:05 I.e. I learnt to do this with the Bourne shell (sh.c, later sh1.c,sh2.c,sh3.c,sh4.c,sh5.c) and it had some weirdness (though less than csh). Jun 13 12:14:16 What was the question about /.recovery? Jun 13 12:15:31 <[cc]smart> in principle, it's there and i don't expect it. now the assumptions are that it's per se intended that it appears there... is that right ?... and so on. it's all in the report now, so the question is if a fix is needed for script of for my understanding of it. Jun 13 12:16:46 <[cc]smart> s/of for/or for/ Jun 13 12:17:24 Boot didn't complete. It's removed by /etc/rc?.d/S??rmrecovery in the user run levels, so if the boot fails to run to completion the system will boot into flash next time. One of the things to add to the binary how to, but since it's not in the release yet it would just be confusing. Jun 13 12:20:37 <[cc]smart> i cannot see this file on myslug Jun 13 12:21:02 <[cc]smart> i can see /etc/init.d/rmrecovery but not the links Jun 13 12:22:16 <[cc]smart> i will update the report accordingly Jun 13 12:22:21 They don't exist on the ffs2 flash file system (and /.recovery should not get created there), they're created by turnup on a file system (including memstick). Jun 13 12:22:47 I.e. turnup -i should create them. Jun 13 12:24:18 Yes, flash, memstick and nfs are all creating them (setup_files in turnup). flash and ram do not, but ram is created new each time so it doesn't matter. Jun 13 12:26:13 <[cc]smart> i have the feeling the init script concept of rmrecovery has a tendecy of either outsmarting the user or in the other case, possibly removing the .recovery file when not inteded. Jun 13 12:26:35 <[cc]smart> but actually, i don't have a better suggestion either right now. Jun 13 12:27:07 <[cc]smart> cause i see you saying correctly that a completed, successfull swivel does not necessarily make a good boot Jun 13 12:28:03 <[cc]smart> but then, after all init scripts ran successfully you may still be out of luck if no tty started succesfully or sth. similar Jun 13 12:29:54 That's not how it works. The script runs at the end of the user runlevel, so unless the boot hangs the /.recovery will be removed. If the boot hangs the user can't log in. It's not reliable - it may get removed when the system is still unuseable (no network), but I can't see a way of proving that the system is useable... Jun 13 12:30:28 <[cc]smart> maybe, this tries to catch problems it really shouldn't have to care about and a successfull swivel would be enough, keeping the logic contained Jun 13 12:31:59 The question here is how you managed to lose the /etc/rc?.d/S??rmrecovery links - that's symptomatic of a more serious problem. Jun 13 12:32:15 <[cc]smart> i didn't lose them Jun 13 12:32:21 <[cc]smart> i didn't create them Jun 13 12:32:25 <[cc]smart> i didn't use turnup Jun 13 12:32:29 <[cc]smart> i didn't know turnup Jun 13 12:32:38 but you used the boot scripts... Jun 13 12:32:42 <[cc]smart> question: should i have to know about turnup ? Jun 13 12:32:53 <[cc]smart> yes i did Jun 13 12:33:05 <[cc]smart> i saw the /boot scriptzs, i saw /linuxrc and i counted Jun 13 12:33:20 There's no need to user turnup, you can write your own boot scripts, but you've got to get them right ;-) Jun 13 12:33:21 <[cc]smart> there was no doku available and i did what was obvious Jun 13 12:33:32 <[cc]smart> creating a /linuxrc that fits the script Jun 13 12:33:38 UTSL Jun 13 12:33:40 <[cc]smart> correct Jun 13 12:34:06 <[cc]smart> but then, removing /.recovery via /etc/rcX seems a bit.. unuausual :) Jun 13 12:34:18 find / -type -f -print | xargs egrep rmrecovery (may have to install xargs) Jun 13 12:34:21 <[cc]smart> nothing wrong about it, but contained logic is more typoical Jun 13 12:34:41 See rmnologin Jun 13 12:34:44 <[cc]smart> yes, sure. you can always find a way, when you know beforehand what you're looking for Jun 13 12:35:04 <[cc]smart> but typically, you don't grep your whol HD for a guessword Jun 13 12:35:57 Well, I wouldn't use that find run, because I know /linuxrc -> /sbin/init -> /etc/rcS, /etc/rc Jun 13 12:36:10 But if you don't then the find will work. Jun 13 12:36:16 <[cc]smart> the way i described my findings shows that what i would have expected istha the script itself remvoes /.recovery after it's done it's work Jun 13 12:36:27 It does Jun 13 12:36:54 <[cc]smart> not in the way i tried to describe Jun 13 12:36:54 "The script" is what used to be /etc/init Jun 13 12:37:27 <[cc]smart> taking the twist of init, you could say EVERYTHING until shutdown is run by the boot script. Jun 13 12:37:46 Necessarily the boot process is split into separte files because init must be process 1, therefore everything must be exec'ed. Jun 13 12:38:14 <[cc]smart> yes, i know. i made a sufggestion earlier on a modification to the previous startup script. Jun 13 12:38:18 <[cc]smart> aka switchbox Jun 13 12:38:28 Yes, you are correct - everything is a child of process 1 (directly or indirectly). So it would have been possible to implement 'shutdown' by having init exit. Jun 13 12:38:38 <[cc]smart> but that leads away from the original deal. Jun 13 12:39:11 <[cc]smart> user needs to know the /etc/init.d/rmrecovery script to behave correctly if not using turnup Jun 13 12:39:36 That would be cleaner, but it's a hack of a hack of a hack of a 30 year old academic toy... Jun 13 12:39:55 <[cc]smart> no you lost me :) Jun 13 12:39:58 AT&T tried to clean it up in SVR4, but it's still untidy, to say the least... Jun 13 12:40:00 <[cc]smart> s/no/now/ Jun 13 12:40:31 Ok, what I'm saying is that you are correct: the encapsulation of the user processes sucks; Jun 13 12:41:01 To be nice and neat init should exit to shutdown or reboot the system. The exit code of init should cause the kernel to halt or loop as appropriate. Jun 13 12:41:48 But it doesn't - the halt or reboot commands seem to actually cause the kernel to do a reset, regardless of whatever is hanging around ;-) in user land. Jun 13 12:41:56 <[cc]smart> ah about init. i mean, i'm still trying to find sth. attractive to go about rmrecovery. Jun 13 12:42:47 <[cc]smart> well, maybe i get an idea overnight. Jun 13 12:42:55 Yes, but to do that you have to find a way of dealing with the need for init to remain process 1 and for the pivot_root stuff to work without closing open files. Jun 13 12:43:31 That's 30 year legacy (well, init==1 is). Jun 13 12:43:49 <[cc]smart> .recovery is on the target FS not source, so should be no killer. Jun 13 12:43:49 Hum, I wonder what MACH does... Jun 13 12:44:43 /.recovery is created in /boot/disk, which necessarily exec's init, so it can't remove it... Jun 13 12:45:46 <[cc]smart> before it execs it finished mounting and checking, thus could remove before exec Jun 13 12:45:47 It could be done inside /etc/rcS and /etc/rc, but the way init is structured there is no container for (/etc/rcS,/etc/rc 5) Jun 13 12:45:53 <[cc]smart> if this is a good idea Jun 13 12:45:59 <[cc]smart> which is what i don't know right now Jun 13 12:46:03 <[cc]smart> but possibly think Jun 13 12:46:23 Hum. Maybe it could be done from inittab... Jun 13 12:46:56 On balance I think it's a solution to a specific instance of a problem which is global - rmnologin being the other obvious example. Jun 13 12:47:00 <[cc]smart> yes, that might be an option Jun 13 12:47:14 <[cc]smart> cause it also means that init started ok Jun 13 12:47:52 <[cc]smart> but how do you know it's script created .recovery and not user created .recovery ? Jun 13 12:47:56 The solution, pre-SVR4, in later versions of RISCiX was to make /etc/rc #!/bin/make That still works I think ;-) Jun 13 12:48:14 <[cc]smart> cause what i fear also is that user gets pissed cause he wants his manually created .recovery to stay Jun 13 12:48:49 No, /.recovery is reserved to mean 'do not use this disk'. It doesn't matter whether the system or the user said that. Jun 13 12:49:46 (There's no way of removing it once it's there, other than manually, well 'userually') Jun 13 12:49:46 <[cc]smart> ah yes, right. it would stay on that target disk cause it's not survied until init Jun 13 12:51:23 <[cc]smart> so maybe using inittab is simple and and steady, but then, why not having /etc/init.d/rmrecovary constantly linked right from the start ? could also be done. Jun 13 12:52:00 <[cc]smart> effect should be the same... Jun 13 12:53:20 Good point, I'm not sure why I had turnup do it. I think hysterical raisins - I made turnup do a lot of script hackery originally, then I gave up and replaced the OE packages/initscripts with packages/initscripts-openslug. Jun 13 12:54:12 <[cc]smart> so essence would be now, whatever way, make it permanent Jun 13 12:54:37 <[cc]smart> maybe inittab even, personally i feel this would be cleaner Jun 13 12:54:54 <[cc]smart> is this the way i should update the report ? Jun 13 12:57:09 <[cc]smart> better i'd leave the method open and point out the idea of making the recovery remove permanent Jun 13 12:57:40 Sure, or fix it - installing rmnorecovery in packages/initscripts-openslug and removing the relevant lines from turnup seems fine. Jun 13 12:58:10 <[cc]smart> well, i've got no dev access anyways, and since i tried to get into OE early, i'm burned to fear OE :) Jun 13 12:59:23 Ah, well, if you have dev access to oe you could push all the nslu2 changes. No, I didn't say that did I? Must have been my evil twin. Jun 13 12:59:23 <[cc]smart> so my was and is reporting via bugs or whatever Jun 13 13:00:23 Try it, bk commit and bk send me the result. Jun 13 13:00:23 <[cc]smart> ah, no any write access except for thge wiki pages i mean Jun 13 13:00:42 <[cc]smart> ah, local bk Jun 13 13:00:54 <[cc]smart> got no clue of that either but could try that at least Jun 13 13:01:11 <[cc]smart> stil then, i'd have to (once more) try and find my way into OE Jun 13 13:01:34 <[cc]smart> i'm ok at linux and shell, even pythn, but OE got me the creeps with so many undocumented variables Jun 13 13:03:09 ... where did you get the 'boot' scripts from? They're not in OpenSlug-1.12 Jun 13 13:04:16 <[cc]smart> yes, i use bk to pull from the server. and meanwhile, once remebered that this is how bk works, i realized i can "commit" locally.... you speak to a cvs/svn user... :D Jun 13 13:04:34 <[cc]smart> but i never really got bk and didn't feel the gravity around it. Jun 13 13:06:28 <[cc]smart> am perfectly happy with svn resolving the "move" issue an such Jun 13 13:06:39 Well, ok, it's all in openembedded/packages/openslug-init. turnip is in there along with initscripts/rmrecovery. The .bb file runs update-rc.d to put the initscripts links in (except it doesn't for rmrecovery.) Jun 13 13:07:28 It's probably just a simple bk edit on the relevant files, test, then bk citool. Jun 13 13:08:01 <[cc]smart> so i'll close the report, specifying the the existing rmrecovery init scripts where meant to remove /.recovery, and that these for ease of use have been made permant in /etc/rc[23].d Jun 13 13:08:12 <[cc]smart> that correct ? Jun 13 13:08:40 <[cc]smart> ah, you told me where stuff is. Jun 13 13:08:56 <[cc]smart> ok, i'll not that and report back oncei checked over them. Jun 13 13:09:02 <[cc]smart> s/not/note/ Jun 13 13:09:04 Where's the report (what's the number)? In slugbug the correct procedure is to move the state down one at a time: assigned->fixed in this case. Jun 13 13:09:28 <[cc]smart> http://bugs.openembedded.org/show_bug.cgi?id=86 Jun 13 13:09:35 It only gets closed when we're sure it's fixed and the fix is correct. Jun 13 13:10:23 Ah, try: http://slugbug.nslu2-linux.org It's as with the bkbits.net stuff - we don't look at the OE bug database... Jun 13 13:11:34 <[cc]smart> er, it's confusing a bit... where to put which and why it's separated. but that's politics prolly and i want to get into that. Jun 13 13:11:56 <[cc]smart> s/i want/i DONt want/ Jun 13 13:11:59 Hence my comments about merging back into oe-devel ;-) Jun 13 13:12:42 <[cc]smart> ok, i noted the position description for the scripts and i'll come back about it, but for now, a nap i sude :) Jun 13 13:13:09 <[cc]smart> s/i sude/is due/ Jun 13 13:13:16 <[cc]smart> n8 Jun 13 13:53:05 Hmm.. I'm having a little problem compiling packages under Openembedded and the OE Wiki is less than helpful. Problem is: Using "inherit autotools" to do a configure, but the system generates a new configure first from configure.in but does not expand the macros in aclocal.m4 which cause syntax errors in configure. Jun 13 13:53:28 (if that made any sense :-) ) Jun 13 22:52:41 bob_tm: inherit autotools normally ends up regenerating everything from configure.ac, but it just uses standard autoconf stuff. Look at the comment on line 90 of openembedded/classes/autotools.bbclass and the following if test -e lines... Jun 13 22:53:31 I.e. it is probably rm -f'ing aclocal.m4, then trying to use configure.in without it. Jun 13 22:54:15 jbowler: That sounds like a good theory. **** ENDING LOGGING AT Mon Jun 13 23:59:56 2005