**** BEGIN LOGGING AT Sat Jul 26 02:59:56 2008 Jul 26 07:15:04 .join #tailor Jul 26 07:15:14 doh Jul 26 07:16:18 pigeon: doh Jul 26 07:19:12 pb_: g'day! Jul 26 07:19:20 g'day :-) Jul 26 07:19:33 how's things? Jul 26 07:20:43 yeah, pretty good. summer here now :-) Jul 26 07:20:55 got my parents-in-law coming over this evening for a barbecue. Jul 26 07:21:02 ah Jul 26 07:21:10 pretty much winter here now Jul 26 07:21:56 03khem 07org.oe.dev * r18c98c8c... 10/ (4 files in 3 dirs): Jul 26 07:21:56 1. Bump up the SVN revision. Jul 26 07:21:56 2. Recommend libgcc unconditionally for eglibc based images as its all nptl. Jul 26 07:22:21 heh, right, I guess it would be Jul 26 07:26:18 hm, I wonder what the chances of a successful mtn pull are. Jul 26 07:26:40 * pb_ tries Jul 26 07:27:53 7/3103 revs. I guess that's not so bad Jul 26 07:28:05 hmm Jul 26 07:28:13 i've been only using the git repo now Jul 26 07:28:34 (assuming you're talking about oe) Jul 26 07:38:40 oh, right Jul 26 07:38:48 I don't know how to use the git repo Jul 26 07:39:12 305/3103 now. monotone is really going at quite a pace this morning :-) Jul 26 08:33:03 Crofton: following yesterday's discussion (python-native), well it sorts out in angstrom you cannot change DEPLOY_DIR_PSTAGE Jul 26 08:33:32 I had DEPLOY_DIR_PSTAGE = "/oe/build/pstage" when python-native failed Jul 26 08:34:59 (see thesing commit 2008-07-24) Jul 26 08:35:02 bbl Jul 26 09:19:17 morning all Jul 26 09:23:19 XorA|gone, RP, hrw|gone, mickey|zzZZzz: could you please comment on my "kernel.bbclass and collie changes" RFC? I want to go on improving stuff asap. ;) I'd like to get an Ack for (at least) the device-table-minimal change from some of you before I go on. Jul 26 09:41:06 thesing: I shall try and check it out later today Jul 26 09:41:15 thesing: Id love to get my collie out of the cupbaord :-) Jul 26 09:43:38 hi thesing Jul 26 09:43:42 hi XorA|gone Jul 26 09:43:42 thesing: The device-table change is fine Jul 26 09:43:51 hi RP Jul 26 09:44:33 thesing: have you actually ever rebuilt after changing DEPLOY_DIR_PSTAGE ? Jul 26 09:45:11 That or move DEPLOY_DIR/pstage to its new destination Jul 26 09:45:17 seems some packages dont agree :-/ Jul 26 09:45:26 python-native for one... Jul 26 09:46:00 I think it only works 100% in Poky Jul 26 09:46:30 packaged staging should work just as well in OE as it does in poky Jul 26 09:46:48 I can retry, but did already twice... Jul 26 09:47:06 ant__: What exactly isn't working? Jul 26 09:47:30 look at oestats Jul 26 09:47:41 some tasks seem skipped Jul 26 09:48:08 http://tinderbox.openembedded.net/packages/python-native/ Jul 26 09:48:12 yes, thats the point of packaged staging? Jul 26 09:48:24 no, from scratch Jul 26 09:48:31 was failing Jul 26 09:48:58 with packages in the pstage directory? Jul 26 09:49:06 look e.g at my build of 2008-07-12 Jul 26 09:49:26 * XorA|gone might have a problem with collie, can it only flash from CF card? Jul 26 09:50:12 and of 2008-07-25 failed) Jul 26 09:51:01 ant__: I can't see what you mean, can you give me an exact link? Jul 26 09:53:41 thesing: Actually there is another problem with that device-minimal file - the mtdblock major device number is dynamically allocated - it can vary :/ Jul 26 09:54:08 er, I mean mmcblock Jul 26 09:54:48 * XorA|gone fixed that problem in altbook Jul 26 09:54:58 RP: I'll rebuild now for you :-) Jul 26 09:54:58 you can read the device number in sysfs luckilly Jul 26 09:55:33 yes, thats where udev gets it from Jul 26 09:55:55 thesing: You probably want something like mdev in your initfs Jul 26 09:56:54 mdev is good and all you need is /dev/null to run it Jul 26 09:57:12 and if you already using busybox its free Jul 26 09:57:41 err...busybloat is too big Jul 26 09:58:50 I use klibc ash. ant the initramfs is small enough atm. Jul 26 09:59:17 yes, without busybox Jul 26 09:59:51 yes 98 KB Jul 26 10:01:29 the kernel with initramfs is 862 KB so there is some space left. I think I could save 70 K by disabling zlib support in kexec. Jul 26 10:01:59 on c7x0/akita we could better use the 7Mb mtd1... Jul 26 10:02:13 probably on other models soon Jul 26 10:02:30 (if you missed it http://www.pdaxrom.org/?q=node/240) Jul 26 10:03:25 rebuilding, bbl Jul 26 10:21:09 03khem 07org.oe.dev * rb86db14f... 10/ (4 files in 3 dirs): Jul 26 10:21:09 Fix horribly broken util-linux-ng 2.14 for uclibc. It also needs a new config option in .config of uclibc to enable Jul 26 10:21:09 UCLIBC_HAS_PROGRAM_INVOCATION_NAME=y Jul 26 10:21:09 UCLIBC_HAS___PROGNAME=y Jul 26 10:21:09 These should be enabled in uclibc.distro files. I will seek permission to add those if not we can always fix util-linux-ng to define __progname. Jul 26 11:08:51 heh, my mtn pull has completed Jul 26 11:08:55 yay Jul 26 11:09:27 pb_: Having significantly contributed to global warming? :) Jul 26 11:09:52 yah, probably. Jul 26 11:10:02 I guess oe should have some scheme for making people buy carbon credits whenever they check out Jul 26 11:10:14 heh Jul 26 11:13:28 anyone using ppc_405 here? Jul 26 11:52:48 florian: good morning Jul 26 11:52:50 mickeyl: good morning Jul 26 11:53:06 hi all Jul 26 11:53:52 * florian has a short break from cutting grass in the garden Jul 26 11:54:13 good morning pb_ Jul 26 12:54:08 mickeyl: what became of the "generic" distro? Jul 26 12:54:25 "minimal" Jul 26 12:54:37 aha Jul 26 12:54:38 thanks Jul 26 13:03:36 mickeyl: oh, by the way, I solved my mmc problem on s3c2412. it seems to be working well now. :-) Jul 26 13:07:24 ah, cool. congrats Jul 26 13:08:55 my main remaining issue now is that something is awfully wrong with gettimeofday(). Jul 26 13:09:10 sometimes time goes backwards, and even when it goes in the right direction it goes at the wrong rate. Jul 26 13:09:45 not sure if this latter thing is related to the cpufreq stuff or not, but it seems like it might be. Jul 26 13:10:31 presumably you're not seeing either of those issues on your platform with the openmoko kernel, right? Jul 26 13:12:24 pb_: we dont use cpufreq Jul 26 13:12:41 yeah, I know Jul 26 13:12:52 pb_: but I havent seen anything like that Jul 26 13:13:25 I assume the 2412 has the same insane clocking architecture of the 2410/2442 Jul 26 13:13:37 yes, it's basically the same. Jul 26 13:13:48 not sure why you call it "insane" though, it's never struck me as much crazier than most Jul 26 13:14:29 just bugs me that changing the clock means re-tuning every IO unit Jul 26 13:14:51 if you're not seeing the gettimeofday() thing then that does seem to indicate that cpufreq is likely to be the culprit for the speed thing. Jul 26 13:14:53 * XorA|gone is sure the design guys could do better than that Jul 26 13:15:15 the going-backwards thing is more of a mystery, though, I wouldn't have thought cpufreq would be likely to be implicated in that one. Jul 26 13:15:40 some wierd timer wrapping bug? Jul 26 13:16:03 I think I had this on the s3c2410 at one point back in 2.4 days and it turned out that gettimeoffset() was just plain wrong. but, if that was the case here, it ought to affect all s3c24xx platforms equally. Jul 26 13:16:52 our main kernel guy unfortuneately doesnt hang on irc Jul 26 13:16:55 as for the clock speed changing thing, if there's only one PLL then you don't really have a lot of choice in the matter. Jul 26 13:17:46 I guess the designers could have included a separate pll for the i/o system, but that would have required a whole pile of extra synchronisers as well as the pll and its control logic. Jul 26 13:18:54 or, alternately, you could have one master high-speed pll with separate divisors for the core and peripherals. iirc, that's approximately what intel did with the pxa255. the drawback of that approach is that you either have to have a really high clock rate for the main pll, or you have to accept fairly poor granularity in cpu speed adjustment. Jul 26 13:21:12 I guess Jul 26 13:21:30 Im probably just biased due to the annoying inability of s3c to generate an audio clock Jul 26 13:21:47 unless you chose a suitable core cpu speed Jul 26 13:21:50 actually, I guess, if you were just doing it for power saving, you could just have a shift register to mask out clock cycles to the core. Jul 26 13:22:44 i.e. drop every fifth tick or something. that way your cpu speed would be "bursty", and it wouldn't help with timing (so no DVS) but you would still get the dynamic power saving Jul 26 13:23:16 pb_: you should be in cpu design :-D Jul 26 13:23:24 XorA|gone: well, we just run our audio clocks at whatever rate the s3c24xx can produce, and resample in software to the right bit rate. Jul 26 13:23:41 on the '2410 we end up running at 49512kHz. I think it's a bit less on the 2412, something like 48.8kHz. Jul 26 13:23:46 * mwester finds it annoying that the s3c is seemingly unable to generate clocks for standard UART speeds when the main CPU clock is running slower than max Jul 26 13:24:06 mwester: the later s3cs are much better than the old ones at that Jul 26 13:24:22 they have a new divisor system that lets you divide by fractional amounts rather than just integers Jul 26 13:24:26 Im sure ben dooks told me he uses and audio codec to generate UART clocks for s3c Jul 26 13:24:58 yah, very likely Jul 26 13:25:45 and, of course, your old employer has a good line in codecs that will run from a single 12MHz source, which of course the s3c24xx can give you from the usb pll. Jul 26 13:26:50 pb_: heh heh Jul 26 13:28:06 seriously though, in probably 95% of modern applications there is no need to be too wedded to a "traditional" audio clock rate. Jul 26 13:28:54 unless you're doing spdif output or something of that nature, you might as well just pick a speed that's convenient for your clocking architecture and use whatever falls out. you're almost certainly going to end up needing to resample at least some input rates, and once you have that capability you might as well just resample everything. Jul 26 13:30:31 we do have a couple of platforms with spdif out, and on those you really do need to run at 48kHz otherwise people laugh at you. but, those customers who can afford the DIT can afford a crystal and a counter IC to make the 48kHz clock. :-) Jul 26 13:31:23 bbiab, wife needs help with the lawnmower Jul 26 13:49:54 awesome, a wife that mows lawns! Jul 26 13:50:56 * XorA|gone wants one of those Jul 26 13:50:58 * mwester wondered at that too Jul 26 13:56:37 heh :-) Jul 26 13:58:51 crumbs, I had forgotten how hot my laptop gets when an oe build is running Jul 26 14:02:52 oh, one other question for you openmoko dudes: what compiler do you use for your kernels? Jul 26 14:03:14 I tried to upgrade from gcc-3.4 to gcc-4.3 the other day but had to revert because the newer one seemed to be miscompiling ALSA in some weird way Jul 26 14:21:10 arm-angstrom-linux-gnueabi-gcc (GCC) 4.1.2 Jul 26 14:21:22 (sorry for the delay; was trying to fix the wife's car) Jul 26 14:30:13 okay, thanks Jul 26 14:30:47 I'll give that a go, see if it works any better Jul 26 14:31:11 4.3 gives me a significantly smaller binary size than 3.4, which is a bonus because I have a fixed partition size for my kernel. Jul 26 14:31:32 unfortunately we picked the partition size to suit 2.4 and didn't anticipate the extent to which 2.6 would be bigger :-} Jul 26 14:32:26 right now we are obliged to have a load of stuff as modules, which is a pain because of the extra boot-up time it causes. Jul 26 14:35:13 Heh - the openmoko kernel is also full of modules, but for no apparent reason that I can tell -- the core hardware is not likely to change, so I don't understand the benefit of having things like the USB, audio, bluetooth, etc drivers all be modules. Jul 26 14:36:02 yeah, I would have thought you'd be better off compiling all of those in statically Jul 26 14:36:43 on our system, using busybox insmod at least, it seems to take something on the order of 100-200ms to load each module. so, ten modules adds two seconds to your boot time right away. Jul 26 14:37:05 I'm not sure if this is busybox specific suckage or if module-init-tools would be just as bad. Jul 26 14:39:43 conversely though, we have another issue where the s3c2410-ohci driver seems to pause for about a second during bootup while it does its bus enumeration. I keep meaning to try putting that as a module instead to see if we can load it in the background and eliminate this delay. Jul 26 14:44:25 Ah, now that might be a valuable reason for a module. Jul 26 14:47:36 mwester: audio is a module so I can load/unload it when working on it :-) Jul 26 14:47:48 mwester: I expect it to be built in on final release Jul 26 15:15:03 hm, my laptop has cooled off. build must have crashed. Jul 26 15:15:10 heh Jul 26 15:15:27 ah yes, gcc-cross-kernel failed do_stage Jul 26 15:15:28 doh Jul 26 15:20:06 hi pb Jul 26 15:20:22 hi woglinde Jul 26 15:49:09 mickeyl: would you by any chance have a moment to run a little test program on your openmoko system, just to confirm whether it has the same odd gettimeofday behaviour that I see on mine? Jul 26 15:49:47 sure thing. give me a binary and I run it Jul 26 15:50:10 http://copper.reciva.com/pb/checktime.c is the source code. I don't think I have the technology to make eabi binaries right now. Jul 26 15:50:35 just let it run for a couple of minutes and see if you get any output Jul 26 15:56:50 03mickeyl 07org.oe.dev * rc7176a0f... 10/ (1 packages/efl1/ecore_cvs.bb): ecore cvs catch up with changed option (from Openmoko) Jul 26 15:56:55 03mickeyl 07org.oe.dev * raeb1ac8a... 10/ (3 files in 2 dirs): Jul 26 15:56:55 update EFL due to important VKBD fixes. sorry guys. Jul 26 15:56:55 Note: considering to switch to download from E git... Jul 26 16:06:43 pb_: running... Jul 26 16:07:12 gm all Jul 26 16:08:00 we package cc1 in cpp_* package Jul 26 16:08:13 I think cc1 should be part of gcc Jul 26 16:08:49 cpp seems like preprocessor package but cc1 is real compiler that gcc driver calls Jul 26 16:09:29 but I see same packaging on ubuntu too so we are consistent with debian like distros Jul 26 16:09:57 khem: nowadays, cc1 and cpp are basically the same binary. Jul 26 16:10:05 there hasn't been a standalone cpp since about gcc 3.4 Jul 26 16:10:31 so, if you want cpp, you need to install cc1 Jul 26 16:10:32 mickeyl: thanks Jul 26 16:10:52 doesn't seem to put anything out yet... Jul 26 16:10:54 still running Jul 26 16:11:18 ok, great, I guess that means you probably don't have the bug. Jul 26 16:11:26 now I just need to find out how your kernel is different to mine :-) Jul 26 16:11:28 pb_: in the packages cpp is a different binary then cc1 Jul 26 16:13:00 khem: right, but it's just a driver binary (like gcc). it execs cc1 to do the real work. Jul 26 16:13:20 but cpp invokes cc1 Jul 26 16:13:42 so somehow if we make cc1 part of cpp package is not correct because even gcc needs it Jul 26 16:13:51 gcc depends on cpp Jul 26 16:14:07 pb_: it does not for target package Jul 26 16:14:10 or at least, it should do. I haven't checked whether that's actually the case in oe. Jul 26 16:14:35 khem: ah, then that is a bug. Jul 26 16:14:39 yes it should do so but it seems not to be doing that for target gcc Jul 26 16:14:47 if you look at debian or the like, gcc there does have a hard dependency on cpp. Jul 26 16:15:11 the easy fix would be just to add that dependency. maybe a better fix would be to put cc1 in its own package and have the two drivers (i.e. gcc and cpp) depend on that rather than each other. Jul 26 16:15:11 pb_: yeah I see I think we need same. Jul 26 16:15:59 though, actually, I guess users would probably have an expectation that "ipkg install gcc" would allow them to use cpp, so perhaps the straightforward dependency is best after all Jul 26 16:16:57 pb_: yeah I agree Jul 26 16:17:14 I do not know why cpp is a separate package at all Jul 26 16:17:32 historical reasons, basically Jul 26 16:17:41 thought so Jul 26 16:17:48 there are some programs (e.g. xrdb) which use cpp as a general preprocessor and don't need the compiler itself Jul 26 16:17:56 hmm Jul 26 16:18:13 in the days when cpp was actually a standalone preprocessor and didn't require cc1, it made sense to avoid installing the whole mass of the compiler if all you wanted to do was preprocess. Jul 26 16:18:18 anyway I have to umpire a local cricket game today so I am out today :) Jul 26 16:18:43 nowadays it's probably a bit more marginal: you could make a reasonable argument that cpp should just be folded into the main gcc package and the latter should Provide: cpp. Jul 26 16:19:03 but I don't think the status quo does any harm, so there doesn't seem much benefit in making that change either. Jul 26 16:19:13 khem: okay, enjoy Jul 26 16:19:43 I have my in-laws visiting in about 40 minutes so I will be off soon as well :-} Jul 26 16:19:46 yeah I think a dependency should be enough Jul 26 16:20:12 pb_: cool enjoy your gettogether Jul 26 16:40:50 03pb 07org.oe.dev * ree301efd... 10/ (1 packages/gcc/gcc-cross-kernel.inc): gcc-cross-kernel: make installdirs before install-common Jul 26 16:49:25 re laibsch Jul 26 16:49:39 re Jul 26 16:49:51 won't be long, though Jul 26 16:50:09 * Laibsch needs to restart gnome a couple of time for testing Jul 26 17:04:35 hi diego Jul 26 17:04:50 diego sorry I fighted with wesnoth the last 2 day Jul 26 17:05:02 but I will look at apr today Jul 26 17:18:03 Laibsch: could you test the new collie stuff? Jul 26 17:18:20 not yet Jul 26 17:18:21 sorry Jul 26 17:18:28 the CF card is acting up Jul 26 17:18:45 I think I can get it to function for flashing by repartitioning Jul 26 17:18:52 but I need to do my taxes Jul 26 17:21:10 Thats of course more important. Especially if you get money back ;) Jul 26 17:29:01 ~oedoc Jul 26 17:29:08 ~doc Jul 26 17:29:09 Documentation can be found at http://digium.com/index.php?menu=documentation or http://www.digium.com/handbook-draft.pdf or http://www.voip-info.org/wiki-Asterisk or http://www.asteriskdocs.org or http://www.oreilly.com/catalog/asterisk Jul 26 18:20:59 03mickeyl 07org.oe.dev * rcc5c410b... 10/ (4 files in 3 dirs): illume svn enable keyboard Jul 26 20:11:06 * * OE Bug 4455 has been created by robert.piasek(AT)member.fsf.org Jul 26 20:11:08 * * wpa-supplicant cant be run on-demend by dbus Jul 26 20:11:11 * * http://bugs.openembedded.net/show_bug.cgi?id=4455 Jul 26 20:20:04 RP: still around? Jul 26 20:21:14 03thebohemian 07org.oe.dev * r3f2ba265... 10/ (1 packages/classpath/classpath-native.inc): Jul 26 20:21:14 classpath-native.inc: Jul 26 20:21:14 - add JAVAC export to fix building newer classpath(-native) versions Jul 26 20:21:19 03woglinde2 07org.oe.dev * r7aae2d25... 10/ (5 files in 2 dirs): ecj: update to version 3.3.2 Jul 26 20:21:24 03woglinde2 07org.oe.dev * r5ae815d0... 10/ (1 packages/classpath/classpath-initial_0.93.bb): (log message trimmed) Jul 26 20:21:24 classpath-initial: fix libtool2 error Jul 26 20:21:24 * when compiling with libtool2 config.rpath is needed and fix this error Jul 26 20:21:24 libtool: link: unsupported hardcode properties Jul 26 20:21:26 libtool: link: See the libtool documentation for more information. Jul 26 20:21:28 libtool: link: Fatal configuration error. Jul 26 20:21:30 * config.rpath is coming from gettext so let depend on it Jul 26 20:21:38 whaha Jul 26 20:21:45 robert Jul 26 20:28:41 wasn't this intended? Jul 26 20:29:23 you both fixed the same error? Jul 26 20:29:30 no Jul 26 20:29:39 but the timing was funny Jul 26 20:29:48 luckily is was no the same error Jul 26 20:31:10 thesing: I think the problems come changing TMPDIR (like angstrom does) and not DEPLOY_PSTAGE_DIR Jul 26 20:31:16 http://www.pastebin.ca/1083734 Jul 26 20:31:22 http://www.pastebin.ca/1083738 Jul 26 20:32:46 if I let TMPDIR = "/oe/build/tmp/${DISTRO}" Jul 26 20:32:58 like it was all automagically works ! Jul 26 20:33:34 this seems to lead to problems: TMPDIR = "/oe/${DISTRO}-tmp/" Jul 26 20:34:23 just another question, BBPATH=/oe/:/oe/build/:/oe/org.openembedded.dev/ Jul 26 20:34:45 no idea looks the same for me. Jul 26 20:34:45 the first element (/oe/) is only in angstrom... Jul 26 20:35:06 dev instructions Jul 26 20:35:23 ~seen rschuster Jul 26 20:35:26 rschuster is currently on #oe (6h 44m 50s), last said: 'nevermind found it in the gnu make manual :)'. Jul 26 20:35:40 I'd hope somebody would sanitize the things ?here Jul 26 20:36:48 woglinde: I am here Jul 26 20:37:10 woglinde: hey my dear, how did you set BBPATH? Jul 26 20:37:11 robert I fixed the libtool problem Jul 26 20:37:26 woglinde: I saw your patch Jul 26 20:37:37 for classpath Jul 26 20:38:06 woglinde: but for me it looks like it only contains a change to the PR. Jul 26 20:38:16 woglinde: wrote you a mail (your uni address) Jul 26 20:38:23 rschuster pull again Jul 26 20:38:32 had to merge Jul 26 20:38:40 because you pushed your fix the same time Jul 26 20:39:14 woglinde: yeah this is funny Jul 26 20:39:18 ant export BBPATH=/devel/arm/build:/devel/arm/org.openembedded.dev Jul 26 20:39:31 woglinde: btw you have updated ecj which also funny Jul 26 20:39:32 ok, thx, no oeroot Jul 26 20:39:33 rschuster first I thought you found out yourself Jul 26 20:39:47 the libtool fix Jul 26 20:39:50 woglinde: I have a patch that adds ecj 3.4 also :) Jul 26 20:39:57 hehe Jul 26 20:40:02 obsolete now Jul 26 20:40:05 and another one that builds openjdk's language tools Jul 26 20:40:23 well, you have 3.2.2, I have 3.4 :) Jul 26 20:40:50 openjdk's language tools contains sun-javac, javadoc and so on Jul 26 20:41:12 nope should be 3.4 too Jul 26 20:41:14 hm Jul 26 20:41:33 args Jul 26 20:41:37 didnot commit it Jul 26 20:41:42 did you? Jul 26 20:41:59 woglinde: no, I didnt Jul 26 20:42:05 okay let me commit it Jul 26 20:42:06 woglinde: perhaps you forgot mtn add? Jul 26 20:42:09 no Jul 26 20:42:12 mtn commit Jul 26 20:42:14 woglinde: strange Jul 26 20:42:18 *g* Jul 26 20:42:25 kill mtn ! Jul 26 20:42:31 first I pushed 3.3 -> 3.3.2 in Jul 26 20:42:33 right so Jul 26 20:42:45 now I will 3.3.2 -> 3.4 if you dont mind Jul 26 20:42:54 ant thats not a mtn prolem Jul 26 20:43:10 woglinde: every other day there is a problem Jul 26 20:43:15 ??? Jul 26 20:43:19 nope Jul 26 20:43:24 last time our patches crossed Jul 26 20:43:31 my layout Jul 26 20:43:37 yes but thats not a mtn problem Jul 26 20:43:38 your commit Jul 26 20:44:19 rschuster should I commit now? Jul 26 20:44:39 woglinde: yeah, please commit Jul 26 20:44:46 woglinde: I am not planning to do it Jul 26 20:45:01 woglinde: the patches are on a different machine anyway Jul 26 20:45:24 (forgot to take my mtn key to work where I created the patches) Jul 26 20:46:07 okay Jul 26 20:46:20 I hope I can play with your beagleboard a little bit Jul 26 22:20:58 03woglinde2 07org.oe.dev * r175ebb88... 10/ (5 files in 2 dirs): ecj: update to version 3.4 Jul 26 22:28:41 03pb 07org.oe.dev * r7509e3e8... 10/ (1 packages/xorg-lib/libx11-native_1.0.1.bb): libx11-native_1.0.1: actually use 1.0.1 tarball, not 1.1.1 Jul 26 22:28:47 wow Jul 26 22:28:52 push from pb Jul 26 22:34:20 heh Jul 26 22:34:23 second one today :-) **** ENDING LOGGING AT Sun Jul 27 02:59:57 2008