**** BEGIN LOGGING AT Wed Jul 20 23:59:56 2005 Jul 21 04:45:54 I had a strange experience after flashing the latest monotone OpenSlug - the month is wrong again (August instead of July). Maybe I adjusted it last time because at that point there was (as I recall) a bug where months were counter from "1" instead of zero. Anyone here that can verify that? Jul 21 05:01:47 ingeba, I got August too Jul 21 05:02:26 hanjo_: Did you manually adjust it one month on a previous Openslug release or did you just upgrade to Openslug once? Jul 21 05:03:14 no, this is a clean flash Jul 21 05:04:53 I had that too, but I didnt think much of it Jul 21 05:29:44 hanjo: Clean flash means nothing - it will remain in the RTC if adjusted. Jul 21 05:31:59 there was some fiddling on the x1205.c RTC driver code a while ago. Jul 21 05:32:21 not sre the current status of that. Jul 21 05:32:36 dyoung-zzzz: Was I right in recalling this being a known problem once? Jul 21 05:33:38 Yes. Jul 21 05:34:03 Ah - I will check slugbug and add if not present Jul 21 05:34:05 I slapped a quick hack fix to it, but I think jbowler fixed it for real after that. Jul 21 05:34:21 so I dunno if my hack was backed out or.. ?? Jul 21 05:36:00 Are there separate branches now? I flashed 2.6.12.2-r0 Jul 21 05:36:20 should be r3/. Jul 21 05:36:37 r3 is latest at least. Jul 21 05:36:56 Ok - strange. Last successful pull was yesterday. Jul 21 05:37:16 Pull from monotone? Jul 21 05:37:56 Yes Jul 21 05:38:06 (with version 0.20) Jul 21 05:38:26 I may have misunderstood. Jul 21 05:38:49 Will it not do a pull when just typing make in the new make system? Jul 21 05:39:15 make update Jul 21 05:39:33 I dunno offhand if it does it automagically... Jul 21 05:40:22 looks l ike it does. Jul 21 05:40:23 Well - as long as SVN is down there is not much I can do, it seems, but the output was much the same. Jul 21 05:40:41 ... up to the point of berlios giving "connection refused" Jul 21 05:41:39 you should be able to cd openembedded; monotone pull; cd ../openslug; make Jul 21 05:41:56 since berlios is busted.... Jul 21 05:42:26 Yeah . that works. Jul 21 05:42:50 Hmm. Jul 21 05:42:51 Nothing new in the kernel it seems. Jul 21 05:43:58 more openembedded/packages/linux/nslu2-kernel_2.6.12.2.bb Jul 21 05:44:03 Mine is r3. Jul 21 05:45:42 That is perhaps just the revion number locally for you? Jul 21 05:45:53 You have made 3 revs of the kernel. Jul 21 05:46:03 No, because thats the one that jbowler pushed a couplel days ago. Jul 21 05:46:31 Hmmm... . Jul 21 05:46:33 slug@ali ~/nslu2/openslug/openembedded/packages $ more linux/openslug-kernel_2.6.12.2.bb Jul 21 05:46:33 whats your head? Jul 21 05:46:34 # OpenSlug Kernel for NSLU2 Jul 21 05:46:36 # Jul 21 05:46:37 # The only purpose to this is to allow the openslug kernel to Jul 21 05:46:39 # have an openslug specific defconfig - in openslug-kernel-${PV} Jul 21 05:46:41 include nslu2-kernel_${PV}.bb Jul 21 05:46:50 yeah, thats right. Jul 21 05:46:59 more openembedded/packages/linux/nslu2-kernel_2.6.12.2.bb Jul 21 05:47:22 slug@ali ~/nslu2/openslug/openembedded/packages $ more linux/nslu2-kernel_2.6.12.2.bb Jul 21 05:47:24 # Kernel for NSLU2 Jul 21 05:47:25 PR = r0 Jul 21 05:47:27 include nslu2-kernel.inc Jul 21 05:47:40 try re-pulling. Jul 21 05:47:44 and tell me your head. Jul 21 05:48:03 45523d76f8ab21f3cf758dddb065ea69352fdda6 rwhitby@nslu2-linux.org 2005-07-19T20:19:04 Jul 21 05:48:06 is mine Jul 21 05:49:02 How do I tell? Jul 21 05:49:16 monotone heads Jul 21 05:49:27 monotone head Jul 21 05:49:30 4a6487d7641810cd75596f7570db658e7374d8bd rwhitby@nslu2-linux.org 2005-07-14T16:31:17 Jul 21 05:49:36 14! Jul 21 05:50:03 wow, thats like years in slugtime! Jul 21 05:50:09 :-) Jul 21 05:50:34 anyhow, therein lies the discrepancy. Jul 21 05:51:54 Indeed, but why? Jul 21 05:52:07 do you get any useful message when you cd openembedded; monotone pull ? Jul 21 05:52:40 monotone: warning: doing anonymous pull Jul 21 05:52:41 monotone: connecting to monotone.nslu2-linux.org Jul 21 05:52:43 monotone: rebuilding merkle trees ... Jul 21 05:52:44 monotone: read from fd 4 (peer monotone.nslu2-linux.org) closed OK after goodbye Jul 21 05:52:46 monotone: bytes in | bytes out | certs in | revs in | revs written Jul 21 05:52:48 monotone: 219 | 542 | 0 | 0 | 0 Jul 21 05:55:04 what directory are you doing this from? Jul 21 05:55:16 nslu2/openembedded Jul 21 05:55:30 weird. Jul 21 05:55:38 No files changed since July 15th. Jul 21 05:55:39 and y0ur head is still the 7/14 one? Jul 21 05:55:43 Yes Jul 21 05:56:12 okay cd ..; make update-master Jul 21 05:56:32 monotone head Jul 21 05:56:40 Same Jul 21 05:56:46 a90fbc8b2f604b7532428b3ccc4abbcd588dd741 rwhitby@nslu2-linux.org 2005-07-19T18:43:09 Jul 21 05:56:58 cc91df51dc068d2433e770fb9fa673e7aaa95e4e rwhitby@nslu2-linux.org 2005-07-14T19:57:00 Jul 21 05:57:09 do you have a MT directory in your home directory? Jul 21 05:57:28 No, just in the nslu2 dir Jul 21 05:57:47 contains log, options and revision Jul 21 05:58:30 Hmm. Jul 21 05:58:31 Perhaps the database is messed up locally? Jul 21 05:58:36 Could be. Jul 21 05:58:46 I would try starting over. Jul 21 05:59:09 Ok - do I have to delete all or just the monotone stuff (it takes a day to recompile it all) Jul 21 05:59:27 (so the tmp dir would be nice to keep) Jul 21 05:59:56 well, first give it a try in a new directory, like nslu2-2 or something and see if it pulls the right head. Jul 21 06:00:05 Good idea. Will do. Jul 21 06:00:11 assuming that works, you can probably move your tmp directory over. Jul 21 06:00:18 Got to free some space first. Jul 21 06:00:19 since not all that much has changed since the 14 Jul 21 06:00:34 you can at least save rebuilding the toolchain Jul 21 06:00:55 the monotone database should be < 30MB Jul 21 06:01:21 Ok - just deleted the (very) old OE openslug build dir. Jul 21 06:03:34 How do I copy my key? Jul 21 06:05:30 monotone pubkey ingeba@someplace.com > pubkey Jul 21 06:05:34 monotone read pubkey Jul 21 06:05:45 Great! 23MB so far on the new pull Jul 21 06:06:01 (same for priv key then I guess) Jul 21 06:06:04 then do the same with privkey Jul 21 06:06:06 right. Jul 21 06:06:30 added benefit is you now have your keyset as files so you can/should save them someplace. Jul 21 06:07:03 Just as I can/should go to sleep. :-) Jul 21 06:07:45 dyoung-zzzz: Rest assured that rwhitby have made me back it up to almost every medium known to man :-) Jul 21 06:07:58 dyoung-zzzz: Thanks for your help - good night! Jul 21 06:08:20 np, I'll stick around for a bit to see if it worked out for you. Jul 21 06:13:03 The pull hanged so I had to restart. Jul 21 06:13:35 it ,may not have been a hang Jul 21 06:13:45 ..hanged or hung... this transitive/intransitivity thingy.... Jul 21 06:13:45 it waits a long time after it's got the data Jul 21 06:13:57 Ok - 23.2 MB - did that sound about right? Jul 21 06:14:24 hung. Jul 21 06:14:27 hi, is the new openslug beta already on berlios? Jul 21 06:14:41 yes, but you can't get to it Jul 21 06:14:52 connection refused Jul 21 06:14:54 (it's in SVN) Jul 21 06:15:10 dyoung-zzzz: It stopped at the same place - so it was probably just normal Jul 21 06:15:27 it can take a looooong time at that place for a new pull Jul 21 06:15:44 on a fresh pull it may take as long as 25min on a normal x86, or as long as 2 days on a slug. :-) Jul 21 06:16:00 :-o Jul 21 06:16:10 2 days.... Jul 21 06:16:13 normal being 2GHz or better Jul 21 06:16:19 is there a way to tell monotone to go update "down" to the 2.3 release tag? Jul 21 06:16:32 s/go// Jul 21 06:16:51 yes - use the t: specifier for the OpenSlug-2.3-beta tag Jul 21 06:17:03 Well, mine is "almost normal" then - it's kind of chilly here in Norway today, so 99%CPU for 25 mins may help... Jul 21 06:18:29 monotone --db=/path/to/db co --revision=t:OpenSlug-2.3-beta OpenSlug-2.3-beta Jul 21 06:18:47 thx Jul 21 06:18:55 --branch=org.openembedded.nslu2-linux Jul 21 06:19:34 :) ahh, the good old CVS days Jul 21 06:22:44 does this sound ok? Jul 21 06:22:47 monotone: expanded to '94612cda9b64223716ba5b9c5dadc1fa29d554af' Jul 21 06:24:19 yup Jul 21 06:24:31 http://monotone.vanille.de/viewmtn/revision.psp?id=94612cda9b64223716ba5b9c5dadc1fa29d554af Jul 21 06:24:49 cool Jul 21 06:24:59 I have to learn this monotone stuff Jul 21 10:33:54 NAiL: My man - is there anything I can do when berlios is down? I need to fetch bitbake and this is taking all day. No status page in sight on berlios, though. Jul 21 10:36:02 ingeba: No idea actually. I could pack it up and send you Jul 21 10:36:21 I will wait patiently then :-) Jul 21 10:36:33 * ingeba goes out to make yet another cup of coffee Jul 21 12:58:10 hi folks. I want to compile screen(1) for the slug, but I don't see a bb file for it in the openembedded/packages/ directory of the 2.0 source tarball. Jul 21 12:58:28 is there someplace else I could look for a bb file, or should I just make my own? Jul 21 12:58:56 i.e. is what's in openembedded/packages/ all that there is in openembedded? Jul 21 12:59:52 basically Jul 21 13:00:47 okay, thanks. I'll go grab the screen source and see if I can get it working.. Jul 21 13:01:01 brilliant Jul 21 13:01:23 I can add it to the official dist if it works. I'd like screen too. Jul 21 13:01:31 Hmm.. I know *someone* ran screen on a slug Jul 21 13:02:13 might've been compiled natively though Jul 21 13:10:29 NAiL: how about atleast some empty Packages.gz in cross/2.4-beta and native/2.4-beta? :-) Jul 21 13:10:42 DaKa2: Considered that, yes :P Jul 21 13:10:47 Gimme a couple of secs Jul 21 13:11:04 NAiL: Are you sure it was openslug - screen is in optware Jul 21 13:11:19 ingeba: no, not entirely sure about that Jul 21 13:11:35 I know it was used to run torrents on Unslung Jul 21 13:12:42 DaKa2: Check if you get any errors now Jul 21 13:13:01 great Jul 21 13:13:12 NAiL: any reason there is a 2.2-beta in native? Jul 21 13:13:40 (just checking :-) Jul 21 13:13:46 DaKa2: nope, it's a leftover IIRC. Trying to sort out the feeds now ;) Jul 21 13:14:07 because there is a 2.3-beta in cross :-) Jul 21 13:14:21 Yes, and that is correct :) Jul 21 13:14:32 yep :) Jul 21 13:14:57 now that is fixed Jul 21 13:15:04 :) Jul 21 13:15:14 There's a few feeds I have to keep track of at the moment you see Jul 21 13:15:31 And right now, not everything is pushed as it should be Jul 21 13:16:28 hehe Jul 21 13:17:32 btw, actually the 2.4-beta feed shouldn't really be there. Jul 21 13:17:59 hm.. actually, no.. or, depends.. Jul 21 13:18:19 No, the 2.4 feed shouldn't exist until there is a 2.4 release Jul 21 13:18:33 kindof Jul 21 13:18:42 hm.. yes.. Jul 21 13:19:04 I have yet to decide how to handle that Jul 21 13:19:18 should the *-feed.conf point to unstable in monotome then? Jul 21 13:19:39 or should 2.4-beta be there, and symlinked to unstable untill release? Jul 21 13:19:56 no, unstable is always a separate feed from stable Jul 21 13:20:11 evening Jul 21 13:20:18 but in the conf file in monotone, I think it should be only unstable Jul 21 13:20:21 mickeyl: evening Jul 21 13:20:34 mickeyl: evening Jul 21 13:20:45 NAiL: probably the best solution Jul 21 13:21:04 DaKa2: yeah Jul 21 13:21:16 do you guys have any recommendation for cheapo USB audio and USB gfx cards to pair with a slug? Jul 21 13:21:59 and I like that you put them in two didfferent files under /etc/ipkg/, especially since I already do that with my own feeds Jul 21 13:22:01 not yet. Someone is getting a yoga (which I think was a audio device) and will be trying to get that to work Jul 21 13:22:23 one of the core devs, that is Jul 21 13:22:35 DaKa2: How's that done? Jul 21 13:23:02 ? Jul 21 13:23:40 two files Jul 21 13:24:01 I'm kinda short on testing slugs at the moment Jul 21 13:24:17 yes, you have the two feeds in /etc/ipkg/cross-feed.conf and native-feed.conf, I have daka-feed and local-feed too Jul 21 13:24:31 ah, neat. So that's how it handles it Jul 21 13:24:39 brilliant, actually Jul 21 13:24:41 ahh, automagic stuff :-) Jul 21 13:24:47 yes Jul 21 13:24:52 I just add a line to openslug.conf Jul 21 13:25:02 nice Jul 21 13:25:07 FEED_URIS_append_linux += "cross##http://ipkg.nslu2-linux.org/feeds/openslug/cross/${DISTRO_VERSION}" Jul 21 13:25:15 That is the cross-feed.conf then Jul 21 13:25:18 that means I could add my own to local.conf! WOHO! Jul 21 13:25:28 yup Jul 21 13:25:58 I just keep learning ;) Jul 21 13:26:17 NAiL: are you happy with 2.3? Jul 21 13:27:36 ypserv doesn't compile, missing sources or something I guess Jul 21 13:27:55 but anything else is gtg Jul 21 13:27:58 Hum... what's the error (it worked fine for me) Jul 21 13:28:06 hang on, restarting build Jul 21 13:29:06 I have been seeing a lot of cases where I get a compile error - gcc finds some string like "fnt" invalid (where "int" should be), I'd assumed I was getting local disk errors or hitting problems with two ccache's in // Jul 21 13:29:17 If I just redo the build it works... Jul 21 13:30:13 it can't find the sources anywhere Jul 21 13:30:31 NOTE: package ypserv-2.17-r0: task do_fetch: failed Jul 21 13:30:49 Ok, let me have a look at the site. Jul 21 13:32:05 2.18 is the latest, but it says "only tested on Linux with glibc 2.x" - implying that other builds should use 2.17 Jul 21 13:32:41 Which, of course, isn't on the web site... Jul 21 13:33:15 Neither is ypbind-mt_1.18 Jul 21 13:33:42 Or pwdutils_2.6 Jul 21 13:35:19 g'night Jul 21 13:37:36 NAiL: they are in: ftp://ftp.kernel.org/pub/linux/utils/net/NIS/OLD/... my idea here is to fix them in the SVN tree and leave monotone as is and leave the release number as '2.3' Jul 21 13:38:17 Because it is a never ending task - something else might have disappeared or moved by the time the binary image is made. Jul 21 13:40:31 jbowler: yes Jul 21 13:45:24 NAiL: how about an empty Packages.gz in native/unstable too :-) Jul 21 13:49:24 DaKa2: sure ;) Jul 21 13:49:59 done Jul 21 13:50:08 fantastic :-) Jul 21 13:50:31 how about actually putting some native packages there? :P Jul 21 13:51:40 DaKa2: feel free to make them :P Jul 21 13:51:44 I have Jul 21 13:51:52 http://david.thg.se/saker/openslug/native/unstable/ Jul 21 13:51:58 brilliant Jul 21 13:52:06 needs some testing Jul 21 13:52:16 of course, it's unstable ;) Jul 21 13:52:28 But if it works, I'm a happy man :D Jul 21 13:52:28 and I dont know about the packaging, same way debian packages it Jul 21 13:52:39 or, almost Jul 21 13:52:45 thanks a lot man Jul 21 13:53:06 it still needs some documentation on how, me and [g2] are working on that Jul 21 13:53:42 brilliant Jul 21 13:56:18 DaKa2: Could you put all those files in a tarball? Jul 21 13:56:34 sure Jul 21 13:56:57 http://david.thg.se/saker/openslug/native/unstable-perl.tar.gz Jul 21 13:57:00 there Jul 21 13:57:02 thx Jul 21 14:00:47 and finally the update-alternatives work is progressing Jul 21 14:01:54 for me working versions of busybox, gawk, and binutils are done http://david.thg.se/saker/openslug/update-alternatives/ Jul 21 14:02:00 just another 10 packages needs changing Jul 21 14:02:16 and someone else have to look at that, especially busybox Jul 21 14:02:29 its not really clean and readable Jul 21 14:05:31 I'm not gonna undertake that until I get up to scratch with what it is you're actually doing Jul 21 14:05:35 I can do that. Jul 21 14:05:46 :) Jul 21 14:08:31 Perl is in the feed Jul 21 14:10:45 nice, now just that needs some testing Jul 21 14:11:56 I won't get around to testing much until next week probably Jul 21 14:12:48 I'll try to test it some more later Jul 21 15:20:38 only coreutils, util-linux, sed, grep, tar and console-tools left to do Jul 21 15:21:58 hm, "connection refused" Jul 21 15:22:28 berlios? Jul 21 15:23:22 mm Jul 21 15:53:02 NAiL: 2.4 should be a symlink to unstable until 2.4 is released, at which time it becomes a copy. Jul 21 15:54:01 and we should not upload native packages to a public feed until they can be built using an automated system. No manually built packages in the feeds please. Jul 21 15:54:32 (we can certainly have a private feed that we developers use to bootstrap the native build process) Jul 21 15:55:39 ok, who are going to run the native build host? Jul 21 15:56:34 and does it has to (at first) be integrated completly in the master makefile and monotone repo? Jul 21 16:18:11 the official native build host will be in the build farm with the rest of the build machines Jul 21 16:18:28 it's called "banana" and was bought with the last round of donations Jul 21 16:19:16 ahh, so, who will set it up, mine and g2's plans are almost complete Jul 21 16:19:46 and yes, the build process has to be in a repo somewhere (it could be in a CVS repo if necessary) so that it can be automatically repeated by others. We don't release anything to the public which can't be independently replicated Jul 21 16:20:35 well, NAiL is the openslug feed manager, so I expect either he will do it, or he will delegate Jul 21 16:20:53 ah, well cvs, thats good, wouldn't want to run monotone on the slug Jul 21 16:22:02 well, talk of an openslug native feed is premature, because the decision on the openslug native build infrastructure hasn't been made yet anyway ... Jul 21 16:22:20 I'm still waiting for [g2] and NAiL to get back to me on that one. Jul 21 16:22:53 yep.. hm.. wonder where [g2] is.. Jul 21 16:23:18 outside, taking a leak :) Jul 21 16:24:09 Basically, we need an exact description of what needs to be done to the slug (from new) to make it a native build host (and to have as much of that automated as possible). Then we need a repo which contains the openslug native build infrastructure (when it is decided what that is), and a Makefile which builds all the openslug native packages automatically and then rsyncs them to the feed. Jul 21 16:24:46 That's the criteria for getting things into the official ipkg.nslu2-linux.org feeds. Jul 21 16:24:51 hm, yet another build system? Jul 21 16:25:05 no, its still bitbake Jul 21 16:25:29 kolla_: hopefully not. The alternatives are 1) Optware ported to openslug, 2) Bitbake/OE, 3) new build syste, Jul 21 16:25:59 I believe [g2] and DaKa2 are in the process of proving #2 to be viable Jul 21 16:26:01 and 2) is the most probable, because both g2 and me has it working Jul 21 16:26:29 portage is fine by me :) Jul 21 16:26:41 I should probably start documenting what I have done.. Jul 21 16:26:53 kolla_: well, show us a working proof of concept for portage and we'll consider it :-) Jul 21 16:27:28 try #gentoo-embedded :) Jul 21 16:27:29 DaKa2: even better - put it in the Master Makefile infrastructure Jul 21 16:27:46 that was my thought.. later on Jul 21 16:27:58 DaKa2: do we have your mt key yet? Jul 21 16:28:44 rwhitby: I'be buildt the lot on my slug already, twice, with portage.. both glibc and uclibc Jul 21 16:28:44 hm.. no, I've been feeling kind of good not having access there, no risk of be breaking something :-) Jul 21 16:29:00 DaKa2: my thoughts were to have some subdirs under /home/slug/oe-symlinks/native Jul 21 16:29:21 yep, I have oe-symlinks-native now Jul 21 16:29:40 Have you been able to get bitbake to run on a native package and it's dependencies, and what's the largest number of parsed bb files it can handle on a slug. Jul 21 16:29:55 it can parse the entire oe-symlinks Jul 21 16:29:58 ok, can you change that to oe-symlinks/native/... instead ? then we don't need to create a new repo. Jul 21 16:30:03 but it takes some time Jul 21 16:30:19 swap is nice Jul 21 16:30:24 I'll change that, but.. that is in svn right? still no subversion on the slug Jul 21 16:30:35 I buildt glibc on the slug, no problem Jul 21 16:30:43 did you see the idea about mini-symlink trees which only contained the deps for each native package? Jul 21 16:30:51 I have svn on the slug Jul 21 16:31:00 kolla_: packaged up as a .bb? Jul 21 16:31:11 no, again.. gentoo Jul 21 16:31:32 rwhitby: hm. no.. but that seems kind of smart, depending on how many native packages we will get Jul 21 16:32:12 DaKa2: my idea was to have oe-symlinks/native// Jul 21 16:32:36 and to use as many pre-installed dependencies from cross-compilation as possible Jul 21 16:32:40 rwhitby: the way I have done it is not using any of the -native packages, and telling bb not to build them, and then I've just installed them from the feed Jul 21 16:32:58 I guess this is stepping on toes, but I dont like neither ipkg nor bitbake very much Jul 21 16:33:06 but.. ignore me Jul 21 16:33:38 I really like bitbake, there are so many ways to override things and inherit stuff, but sure, it has some flaws Jul 21 16:33:58 ipkg feels like home to me :-) apt-get ,-) Jul 21 16:34:06 and cross fingers :P Jul 21 16:34:49 kolla_: not ignoring - just haven't personally heard from the gentoo guys since we sent a slug over there many months ago. Is there a status page somewhere so I can get up to date ? Jul 21 16:35:35 I expect we will end up with Unslung, OpenSlug, DebianSlug and GentooSlug ... Jul 21 16:35:57 we should at least attempt to make the binaries interoperable between the last three ... Jul 21 16:36:02 rwhitby: I doubt it, vapier found some bug with uclibc at some point and is backtracking Jul 21 16:36:03 and maybe someone will make NetBSDSlug Jul 21 16:36:37 kolla_: but you have gentoo working on the slug? Jul 21 16:36:41 the slug will be replaced with a new toy soon enough ;) Jul 21 16:36:59 rwhitby: inside a chroot currently, but yes Jul 21 16:37:22 but I'm switching from uclibc back to glibc Jul 21 16:37:34 unlike the rest... Jul 21 16:38:30 yeah, I've never seen the point of uclibc on the slug ... Jul 21 16:40:16 I just need to find out why portage is currently exitin on openslug.. I bet it's busybox somewhere Jul 21 16:40:32 DaKa2: yeah, just installing the -native packages is the right approach Jul 21 16:41:14 yes, and that also means that the symlinks dir doesn't need to be so big Jul 21 16:41:40 on the downside is you have to keep track of what packages to install Jul 21 16:41:45 DaKa2: can you write something up in wiki/OpenSlug/NativeDevelopment ? If I can replicate what you are doing, then I can help automate it. Jul 21 16:41:59 Im just about to Jul 21 16:42:01 DaKa2: create a task-openslug-native.bb to track them for you Jul 21 16:42:55 BTW, you should get mt access - you can't break anything if you use the Master Makefile Jul 21 16:44:16 oh well, guess so, what should I do? Jul 21 16:46:45 first generate a key with an id which is an email address which is recognisably related to your IRC details (i.e. daka2@somewhere or dkarlstrom@somewhere or something like that). then export the key and burn the private and public parts to a CD and print them out on paper. Then send the public part to me. Jul 21 16:47:31 and dammit, big dammit... for this update-alternatives thing I have to go mess in the glibc packages, because of the glibc subpackage sln, with one file... Jul 21 16:48:08 rwhitby: ok, I guess daka@thg.se is ok (I really should use the nick DaKa here, but its registred..) Jul 21 16:48:18 yeah, that's fine Jul 21 16:49:09 I have registered "kolla", but there's some other dork using it still Jul 21 16:50:25 if you registered it and know the password, then you can bump the other dude Jul 21 16:50:32 rwhitby: I havn't quite got this yet, do I just have to run monotone genkey daka@thg.se, or do I ahve to create some local db first? Jul 21 16:50:46 DaKa2: it needs to be done in a db. Jul 21 16:50:54 you can add it to an existing db Jul 21 16:51:56 monotone --db=monotone/nslu2-linux.db genkey daka@thg.se ? Jul 21 16:52:00 yep Jul 21 16:52:01 rwhitby: really.. neat :) Jul 21 16:53:26 rwhitby: so I guess you want the public part: bdfc9f9ad8431af60318fe67b49bd91ebbeadc09 daka@thg.se Jul 21 16:53:46 yep, but I need the whole thing, not just the fingerprint Jul 21 16:54:00 ok.. lets see here Jul 21 16:54:12 mt pubkey id > DaKa2-pub,key Jul 21 16:54:16 and privkey for the other Jul 21 16:54:47 those are the ones you need to save on non-volatile media. If you loose privkey, then you cannot use that id ever again in monotone Jul 21 16:55:37 ahh, fun Jul 21 16:56:22 sent Jul 21 16:57:25 and on a cd Jul 21 16:57:39 and will get printed when I get access to one Jul 21 17:00:06 added Jul 21 17:00:16 back later ... Jul 21 17:00:30 nice, then I just have to read up on the commands.. Jul 21 17:02:26 An alternative to one directory of symlinks/package is one .conf file per package which explicitly lists the directories required - i.e. instead of BBFILES = "whereever/packages/*/*.bb" do BBFILES = "wherever/bin-utils/*.bb wherever/gcc/*.bb" and so on. Jul 21 17:03:38 That can be pulled from, a line in local.conf like 'include ${PACKAGE}.conf' where 'PACKAGE' is a shell environment variable. Jul 21 17:03:51 jbowler: very true. which do you guys prefer? Jul 21 17:04:16 how many native packages do you think there will be? Jul 21 17:04:38 between 10 and 50 Jul 21 17:04:57 if there are no more than 50 a single dir with them all works Jul 21 17:05:24 bitbake is not that slow when parsing Jul 21 17:05:43 Memory use hardly goes up with number of parsed files either. Jul 21 17:05:49 (Not now...) Jul 21 17:06:16 And a much smaller version of bitbake is in the works (with a much faster parser I believe.) Jul 21 17:06:54 OK, so what's the best way forward for native package symlinks then? Jul 21 17:07:19 (and symlinks in general - do we just replace oe-symlinks with a conf file somewhere?) Jul 21 17:08:05 I would replace the symlinks with a conf file, or maybe a smaller number of conf files, but then that's what I already do for my own builds. Jul 21 17:08:45 jbowler: if you can check that in, then we will convert to it. Jul 21 17:09:05 another good related question is where the bb and config files should be kept Jul 21 17:09:11 I can check in a conf file or I could check in the 'freeze' program which auto-generates it, or both. Jul 21 17:09:18 we need to make a bitbake ipk, and then we don't need svn on the slug any more for the native environment. Jul 21 17:09:53 So long as no packages need to retrieve using svn. Jul 21 17:10:04 jbowler: do we check in the conf file in OE somewhere, and then check in the freeze program in master makefile ./scripts ? Jul 21 17:10:25 Yes, I think so. Jul 21 17:10:28 actually, svn for the slug is probably close - someone is working on .bb files for it. Jul 21 17:39:07 jbowler, rwhitby-away: I've added what I do to run bitbake to the end of http://www.nslu2-linux.org/wiki/HowTo/OpenSlugNativeCompileEnvironment , all of that could be put into the makefile and cvs/tarball/something Jul 21 17:41:19 DaKa2: can bitbake be run in place instead of installing it (like we do in the Master Makefile) ? Jul 21 17:41:29 that should work Jul 21 17:42:38 should we just create an openslug-native.conf distro? Jul 21 17:42:46 I was thinking about that Jul 21 17:42:52 then all the local.conf stuff could go in the one place for everyone Jul 21 17:43:16 and we could manage BBFILES in there and not need symlinks Jul 21 17:43:50 seems good Jul 21 17:44:18 and you have the privs to do that now :-) Jul 21 17:44:41 as well as adding package/meta/task-openslug-native.bb ... ;-) Jul 21 17:44:52 ahh, dammit... I knew there was a reason.... Jul 21 17:44:59 (which should be an easy copy of openslug-packages.bb) Jul 21 17:45:40 nslu2-linux is a vortex that we actively suck people in to :-) Jul 21 17:45:54 there is still the issue of getting the stuff from monotone to the slug, running monotone is not a good option.. Jul 21 17:46:52 yeah, that might have to be an rsync of a database from nudi or something ... Jul 21 17:47:19 it's only the initial pull which is the big problem? Is a co from a local db manageable? Jul 21 17:47:43 bbiab Jul 21 17:48:20 well, jbowler was the one running monotone on the slug, I think Jul 21 17:49:34 I tried copying over my database and ran monotone on that, forgot to run it with time, but I don't think it took that long Jul 21 17:50:09 but I could guess just checking the daily 20-40 revs would take some time Jul 21 17:50:13 rwhitby-away: it's only the pull which is the problem. Jul 21 17:51:04 That's correct - I sync my NSLU2 database every 10 minutes to avoid getting multiple revisions at once. Jul 21 17:53:15 is there anyway to put an almost always uptodate nslu2-linux.db somewhere where everybody can access it? Jul 21 17:55:24 http://ewi546.ewi.utwente.nl/OE/OE.db.bz2 Jul 21 17:55:53 I'm not sure how often that is updated, but OE is always up-to-date with nslu2-linux Jul 21 17:56:03 (That's because I sync to both every 10 minutes ;-)\ Jul 21 17:59:43 It's pretty trivial to automate this; while true; do monotone --db=snapshot.db sync; cp snapshot.db temp.db; bzip2 temp.db; mv temp.db.bz2 snapshot.db.bz2; done Jul 21 18:00:30 (Just have to put it on the web server somewhere.) Jul 21 18:10:20 jbowler: did you feel like looking at the whole update-alternatives thing? :-) http://david.thg.se/saker/openslug/update-alternatives/ , just util-linux, coreutils and console-tools left, I'll probably get them done tomorrow Jul 21 18:11:32 as I said, things need to be cleaned up, especially busybox, and the long lines should probably get expanded too.. Jul 21 18:11:47 but they work for me :) Jul 21 18:12:34 DaKa2: can probably shorten task-openslug-native.bb to just openslug-native.bb Jul 21 18:12:55 then we can make openslug-packages do different things depending on whether the distro is "openslug" or "openslug-native" Jul 21 18:12:58 ok, thats alot better Jul 21 18:13:09 and therefore not require a separate openslug-packages-native.bb Jul 21 18:13:58 DaKa2: can you run monotone diff and put the output, together with the revision (from MT/revision) into a file? (Then I can just patch it onto a tree of my own). Jul 21 18:14:23 ooh, rain, bbiab Jul 21 18:15:05 rwhitby-away: what will openslug-native.bb be good for then? if it can be put in openslug-packages.bb? Jul 21 18:15:25 or did I miss something? Jul 21 18:15:36 openslug-native.bb will be the ipk you need to install on the slug itself to get everything you need for the native build tools Jul 21 18:15:49 ahh Jul 21 18:15:56 it replaces OpenSlugDevInst.sh Jul 21 18:16:09 Then I understand Jul 21 18:17:00 and with that I think we've covered your recipe in http://www.nslu2-linux.org/wiki/HowTo/OpenSlugNativeCompileEnvironment. openslug-native for the first bit, Master Makefile for the second bit, and the openslug-native distro for the third bit Jul 21 18:17:52 and the master makefile will pull it all together, detect that you're running it on a slug, and do the Right Thing (TM) Jul 21 18:18:13 (e.g. copy a monotone db instead of pulling it) Jul 21 18:18:22 yes, it would end up with: 1. setup swap, 2. ipkg install openslug-native, 3. add user, 4. wget makefile Jul 21 18:18:37 yep, that's the grand plan Jul 21 18:18:53 and after that, we are ready to push the result to the official native feed Jul 21 18:20:22 right, we have to use my perl packages for the first build, that would be to build perl and put that in the feed Jul 21 18:20:46 my perl bb needs to be cleaned up too.. Jul 21 18:21:32 yes, we need your feed to bootstrap the process Jul 21 18:25:28 ok, back later. Thanks DaKa2 - this is really pushing the native feed process forward! Jul 21 18:25:33 Oh, and the packaging of perl probably needs to be discussed.. Jul 21 18:25:38 :-) Jul 21 18:26:00 ok - can you discuss that in #oe when the core devs there are about - I expect they want it cleaned up too Jul 21 18:26:16 I just put all the modules in perl-module for now, having 800 packages was not good Jul 21 18:26:23 ahh, [g2]! Jul 21 18:26:39 <[g2]> you've been talking about me :) Jul 21 18:26:46 <[g2]> hey gueys Jul 21 18:26:47 hehe... yes... Jul 21 18:26:58 hey :-) everybody just left Jul 21 18:27:03 <[g2]> I'm just finishinig up reading the openslug log Jul 21 18:27:23 DaKa2: openslug-modules is a good starting point, and may well be the ending point too :-) Jul 21 18:27:31 oops - I meant perl-modules Jul 21 18:27:46 I would really want that as the ending point :-) Jul 21 18:28:13 there could be a more granular set as well, that perl-modules depends upon ... Jul 21 18:28:47 but we'll leave that decision up to a discussion between the #oe and #nslu2-linux devs Jul 21 18:29:21 yes, debian has perl-base, that contains perl and the base modules, and then the package perl that just depends on perl-base and perl-modules with the rest of the modules Jul 21 18:29:30 yep Jul 21 18:29:59 <[g2]> well given that for now anyone who install perl is running off a non-jffs2 rootfs or at least mounted another partition, I'd say start with the monolith Jul 21 18:30:02 [g2]: how far did you read? to where you just entered? Jul 21 18:30:35 <[g2]> from Jul 21 18:30:38 <[g2]> Jul 21 04:45:54 I had a strange experience after flashing the latest monotone OpenSlug - the month is wrong again (August instead of July). Maybe I adjusted it last time because at that point there was (as I recall) a bug where months were counter from "1" instead of zero. Anyone here that can verify that? Jul 21 18:30:38 <[g2]> Jul 21 05:01:47 ingeba, I got August too Jul 21 18:30:38 <[g2]> J Jul 21 18:31:09 <[g2]> to now Jul 21 18:31:19 ahh, good Jul 21 18:31:38 what do you think so far? Jul 21 18:31:49 <[g2]> all pretty good Jul 21 18:31:52 The busybox bb looks good. Jul 21 18:32:05 <[g2]> I'd really like to see the smaller/faster bitbake :) Jul 21 18:32:28 <[g2]> I'm with DaKa2 on the parsing the full list is good enough for now Jul 21 18:32:38 jbowler: good, that took lots of time :-) Jul 21 18:32:51 Im just about to try monotone diff Jul 21 18:32:54 <[g2]> currently I wouldn't create the different conf files, but I'd like to see that in action Jul 21 18:33:09 It much simplifies things that update-alternatives doesn't care if the links exist. Jul 21 18:33:59 jbowler: yes, it has to register the links anyway, incase the other package providing them gets removed Jul 21 18:34:00 I think separate conf files, which implies a separate bb run for each compile, will potentially slow things down. Jul 21 18:34:50 yes, parsing many files once, should be faster, since it takes close to no memory Jul 21 18:34:55 I'll wait for the diff on the other files - the obvious changes (adds of update-alternatives) look good, but I find a diff easier to read. Jul 21 18:35:26 I was stupid and ran make update.. something I havn't done for two days Jul 21 18:35:47 just 85 revs in Jul 21 18:35:51 On conf files if I put the 'freeze' stuff in (to read a list of BBFILES rather than symlinks) it would be easy to add per-package confs later if required. Jul 21 18:36:00 [g2]: I suggest we put a partial list of bb files in openslug-native.conf, and have bitbake parse them Jul 21 18:36:36 we can use freeze to create that list of bb files in openslug-native.conf ? Jul 21 18:37:03 freeze just works out what .bb file corresponds to each tmp/work/pn-pv-r0 directory. Jul 21 18:38:32 so we could have the full and partial paths in openslug-native.conf (with one commented out), and then if you want to add a new package then you just uncomment the full path, build the package, then use freeze to update the other bbfiles line with the new dependencies Jul 21 18:38:41 <[g2]> isn't the a pretent option on bitbake ? Jul 21 18:39:04 <[g2]> that'll tell you all the packages you need also right ? Jul 21 18:39:19 I edit the list by hand - add packages/foo/*.bb - when I want to try a new package. Jul 21 18:39:33 <[g2]> rwhitby-away, so I'm assuming that's the conf to be run on the native builds right ? Jul 21 18:39:37 yes Jul 21 18:40:05 <[g2]> how does the name armeb-native.conf sound ? Jul 21 18:40:13 the master makefile will set up your local.conf to use DISTRO=openslug or DISTRO=openslug-native depending on whether it is running on the slug or not Jul 21 18:40:38 ah, [g2] is thinking of loft too. ok, let's see how we can genericise it Jul 21 18:41:01 <[g2]> well loft, openslug, snaxslug, .... Jul 21 18:41:13 You know it can be 'armeb' if the .conf doesn't contain the word 'openslug' Jul 21 18:41:34 But I think it actually has to be nslu2-native.conf Jul 21 18:41:45 <[g2]> IMHO I think we are really verging on distro management Jul 21 18:41:58 (because you have to include the machine) Jul 21 18:42:09 [g2]: we are already into multiple distro management a while back ... Jul 21 18:42:47 [g2]: I think you are thinking of a meta/armeb-native.bb file which has all the packages listed in it. Jul 21 18:43:00 but then that doesn't make sense either. Jul 21 18:43:01 <[g2]> right Jul 21 18:43:14 If the native build doesn't include any kernel modules maybe it can be xscale specific not nslu2 specific. Jul 21 18:43:21 cause another armeb distro will need other packages to be able to build on it Jul 21 18:43:25 <[g2]> it's really an OE/armeb/cross limit issue Jul 21 18:43:51 <[g2]> doesn't really have anything to do with nslu2/ixp4xx/loft/.... Jul 21 18:43:59 <[g2]> rv0xx Jul 21 18:44:01 so armeb-native.bb contains all those packages which cannot be built with the OE armeb/cross compilation system? Jul 21 18:44:23 rwhitby-away: why would openzaurus, for example, need to build things native which build cross ok for nslu2? Jul 21 18:44:35 <[g2]> to at least 80-90% complete Jul 21 18:45:03 Oh... ok - so the idea is that foo-native is just those packages required for foo Jul 21 18:45:08 hang on, that's not right either. openslug-native.bb is the list of packages which need to be installed on the target device to be able to run a particular distro's native build infrastructure. Jul 21 18:45:42 openslug-native.conf is the OE distro configuration required to build packages natively on the openslug distro native build infrastructure and tools Jul 21 18:45:56 so both of them are openslug-dependent Jul 21 18:46:02 <[g2]> OK..Done Jul 21 18:46:35 what's done? Jul 21 18:46:48 Where is the ASSUME_PROVIDED? Jul 21 18:46:49 <[g2]> let's just fry that one fish Jul 21 18:47:01 <[g2]> openslug-native.conf Jul 21 18:47:17 assume_provided must be in openslug-native.conf cause it is part of the openslug native build infrastructure Jul 21 18:47:45 and it would be different for each distro, unless you used some sort of virtual thing to make it inherit from a generic one Jul 21 18:47:52 <[g2]> it'll greatly simplify things if we keep openslug.conf and openslug-native.conf in lock-step Jul 21 18:48:22 I expect openslug-native.conf will include openslug.conf and then just override some things Jul 21 18:48:30 Ok, that's what I was assuming. So everything in ASSUME_PROVIDED is also in RDEPENDS? Jul 21 18:49:07 <[g2]> well dependencies are an issue Jul 21 18:49:08 yes, and those rdepends are satisfied by ipkg install openslug-native on the target device Jul 21 18:49:28 I don't think there is anything useful in openslug.conf for openslug-native.conf - is even DISTRO_VERSION useful? Jul 21 18:50:27 <[g2]> DaKa2 did you see jbowler's note about your perl ipk not having the right depends when he tired ipk installing it on a uClibc based openslug ? Jul 21 18:50:50 hm.. no.. Jul 21 18:51:18 <[g2]> this is somethe will have to learn a little more about Jul 21 18:51:22 perl was missing the glibc (libc6) depend, so ipkg installed it on a uclibc system... Jul 21 18:51:38 ah Jul 21 18:51:49 perl doesn't work on uclibc? Jul 21 18:51:59 <[g2]> the ASSUME_PROVIDED probably overrode that or ignored it Jul 21 18:52:23 <[g2]> sure perl works on uClibc Jul 21 18:52:24 DaKa2: I would expect it to, if compiled for uclibc. Jul 21 18:52:34 DaKa2's feed is glibc, right? Jul 21 18:52:42 Yes. Jul 21 18:52:49 Yes.. Jul 21 18:53:02 <[g2]> openslug is only glibc right ? Jul 21 18:53:18 maybe things in ASSUME_DEPENDS don't get put in the dependencies in the ipk ? Jul 21 18:53:21 So I shouldn't have pulled an openslug feed onto a non-openslug system, but I spoke with a test engineer once and some of it rubbed off. Jul 21 18:53:37 <[g2]> heh Jul 21 18:53:44 DEPENDS != RDEPENDS Jul 21 18:53:50 RDEPENDS goes into the ipk. Jul 21 18:54:09 <[g2]> DEPENDS is compile dependencies Jul 21 18:54:17 But the normal .so RDEPENDS comes by parsing the executable (ELF) Jul 21 18:54:18 <[g2]> RDEPENDS is run-time dependencies Jul 21 18:54:23 right. I should have said: "Maybe the automatically generated RDEPENDS does not include stuff in ASSUME_DEPENDS" Jul 21 18:54:42 dunno - maybe it's just a bug :-) Jul 21 18:54:53 That would be odd, a bug I would say. Jul 21 18:55:03 Might be a feature. Jul 21 18:55:20 But maybe the .so parsing isn't working - is depmod there? Jul 21 18:55:29 Sorry, not depmod... Jul 21 18:55:45 objdump, decobj, something like that. Jul 21 18:56:26 I believe if it errors out bitbake just ignores it. Jul 21 18:58:24 <[g2]> BTW I did some power measurements today Jul 21 18:59:08 <[g2]> non-turbo and turbo slugs were running around 35-38 mA on the 120 side Jul 21 18:59:40 <[g2]> it was around 65-66 with a USB2.0 flash stick plugged Jul 21 18:59:46 <[g2]> that's around 7.8 W Jul 21 19:00:50 <[g2]> the P4 idles around 1.15A Jul 21 19:02:55 <[g2]> rwhitby-away, do you know if the PS is linear or switching ? Jul 21 19:03:14 Do you know what the low voltage side was at? Jul 21 19:04:06 <[g2]> I haven't tested that yet Jul 21 19:04:45 <[g2]> but I think I've got an extra supply around so I'll split that line and see what the DC side measures Jul 21 19:04:57 <[g2]> DC/LV Jul 21 19:05:12 [g2]: depends on your wall-wart doesn't it? Jul 21 19:05:28 <[g2]> sure.... Jul 21 19:05:32 I've run it from both transformer-style wallwarts and switching wallwarts Jul 21 19:06:17 I think 35mA must be a switching one. Jul 21 19:06:18 <[g2]> are you 120 or 220 down under ? Jul 21 19:06:24 240 Jul 21 19:06:45 It's the phase which matters with the transformer though - need to use a power meter? Jul 21 19:07:13 <[g2]> I measure in-line Jul 21 19:07:23 I.e. high current doesn't necessarily mean high power, IIRC Jul 21 19:07:41 <[g2]> P = VI right ? Jul 21 19:08:07 Only if V and I are in phase. Jul 21 19:08:21 integral (i.v) dt ? Jul 21 19:08:53 Transformer loads are inductive unless under load themselves. Jul 21 19:09:04 <[g2]> well household stuff in the states is 1 phase :) Jul 21 19:09:34 No, the phase of the V sine wave vs that of the I sine wave. The supply company just mandates the V. Jul 21 19:09:56 Put an inductive load on it and it may take current but it won't take power - your power meter won't go round. Jul 21 19:10:28 <[g2]> I was measuring current in-line Jul 21 19:10:35 (But I asked about the DC side mainly because I figure there's a lot of heat in the PSU, whatever it is). Jul 21 19:11:15 <[g2]> I do want to know that also, but I'm interested in the total too Jul 21 19:11:27 <[g2]> cause that's what we pay for Jul 21 19:11:47 <[g2]> maybe rwhitby-away has solar power Jul 21 19:12:14 If he did he wouldn't ever plug in a wallwart - people with solar just don't do that... Jul 21 19:12:46 They also get up at 6am and go to bed at 8pm round here :-) Jul 21 19:13:10 jbowler: some time later, diff and revision are at http://david.thg.se/saker/openslug/update-alternatives/ , I think Jul 21 19:14:04 17k diff Jul 21 19:14:44 I would avoid commenting out things on continuation lines - it might work today but zecke has made significant changes to the parser. Jul 21 19:15:14 ah.. Jul 21 19:15:42 <[g2]> jbowler, so what's the latest up date on the bitbake ng ? Jul 21 19:15:47 <[g2]> or improvements Jul 21 19:16:10 What I have comes from the OE logs - and I haven't looked at those for a couple of days. Jul 21 19:16:30 When I looked it seemed like things were going fine and that it would be ready real-soon-now Jul 21 19:18:19 Daka2: on binutils (at least) I think it would be better to do all the links by update-alternatives. I think it's better to be consistent - though the OE guys might think otherwise. Jul 21 19:19:22 I was thinking about that too... there are no other packages providing the other files Jul 21 19:19:53 But there might be, then it would be troublesome just having some in update-alternatives. Jul 21 19:20:07 yes... Jul 21 19:20:20 It can be argued either way. Jul 21 19:20:32 I like consistency.. so.. Jul 21 19:21:09 ... avoids wife's favourite quote... Jul 21 19:21:29 will bb make a package with just a preinst and no files? Jul 21 19:22:19 It might fail - it uses tar and that isn't happy on empty archives. Jul 21 19:23:02 I kindof guessed that.. Jul 21 19:23:44 Also 'not creating empty archive for...' Jul 21 19:24:08 I need to put some file in there then.. but what? Jul 21 19:24:46 DaKa2: which package? Jul 21 19:24:55 Well, what happens with openslug-packages? Jul 21 19:25:06 rwhitby-away: binutils-symlinks Jul 21 19:25:21 its all symlinks, that really should be using update-alternatives Jul 21 19:25:50 was that one already there, or did we add it? Jul 21 19:26:06 not that I can see why the symlinks shouldn't be in the main package Jul 21 19:26:10 its already there Jul 21 19:26:12 jbowler: what's the wife's favourite quote? Jul 21 19:27:01 Oh, ok... "a foolish consistency is the hobgoblin of small minds" Jul 21 19:28:06 DaKa2: the symlinks aren't in the main package so that cross-build tools can be installed. Jul 21 19:28:17 DaKa2: the symlinks package is there because some people don't like to have the non-prefixed names for those tools Jul 21 19:28:23 I.e. to avoid zapping the real build-system 'ar' and so on. Jul 21 19:28:29 ah.. Jul 21 19:28:35 yeah, what he said :-) Jul 21 19:29:03 Why don't you try it with no symlinks? It might work... Jul 21 19:30:31 dammit.. why did I just clear my tmp... Jul 21 19:31:17 it'll take some time to try.. Jul 21 19:31:56 Ok, I'm going to sync to your revision and try with that patch. Jul 21 19:32:02 you could always install the symlinks as foo.binutils (a symlink to somewhere else) and then use update alternatives to symlink those symlinks Jul 21 19:32:20 yes, its just uglier than it has to be Jul 21 19:32:21 so then the package would at least contain the renamed symlinks Jul 21 19:32:53 or, I just use update-alternatives on the conflicting files... Jul 21 19:40:12 bbl Jul 21 19:46:15 I should get some sleep.. bbl Jul 21 19:46:23 night guys Jul 21 19:47:20 <[g2]> nite Jul 21 19:54:02 In OpenSlug-2.3-beta I'm getting a miscompile on vlan-1.8 - I'll investigate later. Jul 21 19:56:19 Ok, it's bad - it is using build system include files in a cross-compile. Jul 21 19:56:56 <[g2]> bad vlan-1.8, no no no.... Jul 21 19:57:47 NAiL: ping Jul 21 19:58:06 NAiL: the feeds dirs on sf.net need to have g+w on all of them. Jul 21 19:58:26 ## You may need to change this linux/include part. Jul 21 19:58:26 CCFLAGS = -g -D_GNU_SOURCE -Wall -I${HOME}/linux/include Jul 21 19:58:35 <[g2]> anyone know anything about the 433Mhz wireless weather gizmos ? **** ENDING LOGGING AT Thu Jul 21 23:59:57 2005