**** BEGIN LOGGING AT Wed Nov 01 02:59:57 2006 Nov 01 03:00:33 At the moment, "diff defconfig loft_defconfig" does not give me a small set of differences. e.g. why is Bluetooth module support not allowed in the loft config? (that's a rhetorical example) Nov 01 03:00:59 <[g2]> GPSFan ok (in summary), so your board running my kernel tweaked for Avila (mach) works, but we don't know why your kernel doesn't ? Nov 01 03:01:58 Similarly for CONFIG_USB_YEALINK - the Loft config is denying people the opportunity to plug in USB phones into a Loft. Nov 01 03:02:01 <[g2]> rwhitby I added the loft_defconfig for guys like GPSFan, Kaloz, nbd and other that want to build for Avila Nov 01 03:02:01 [g2]: that's basically it. all the other peripherials on the board work on my kernel. haven't tested them on your's yet. Nov 01 03:02:22 We don't want divergences like that to persist unless they are conscious divergences Nov 01 03:02:43 btw. do you have any code to keep kernel configs for different targets in sync? Nov 01 03:02:53 [g2]: right - my point is we need to do that in a way which reduces divergence to *only* the things you are intending to diverge on. Nov 01 03:02:53 <[g2]> rwhitby well as soon as the Loft/Avila goes up stream I'll put a loft_defconfig in mainline Nov 01 03:03:58 [g2]: so are the Bluetooth and Yealink divergences intentional, or are they examples of unintended divergence? Nov 01 03:04:25 <[g2]> rwhitby 99% of the avila line has no USB host controller Nov 01 03:04:51 <[g2]> it's CF and 4 minipcis Nov 01 03:04:51 For example, Debian handle this by having a common defconfig, which is overridden by arch-specific, which is overridden by mach-specific Nov 01 03:05:21 <[g2]> that's the other thing 99% of the users run BE Nov 01 03:05:50 [g2]: LE / BE - our kernel svn repo is endian agnostic Nov 01 03:05:59 Why do you state that point? Nov 01 03:06:21 <[g2]> because you mention the Debian kernel issue Nov 01 03:06:35 <[g2]> and BE and Debian don't mix Nov 01 03:06:51 I mentioned Debian as an example of how to structure specificity in defconfigs Nov 01 03:06:52 <[g2]> ARM/XScale and Debian may not mix Nov 01 03:07:34 <[g2]> as in the ARM/XScale arch has issues with the 95% rule Nov 01 03:08:22 <[g2]> but back to the kernel topic at hand Nov 01 03:08:22 [g2]: forget Debian. it was only an example of how to *structure* defconfig fragments to prevent divergence Nov 01 03:08:22 (prevent divergence in unintended areas) Nov 01 03:08:22 divergence is fine, as long as it is intended. Nov 01 03:08:54 ok, how about CONFIG_VIDEO_DEV - are there not CF or miniPC video devices? Nov 01 03:08:54 <[g2]> which brings us back to the main point of the default defconfig Nov 01 03:09:07 * nbd would like to see some scripts that allow you to run menuconfig on a kernal and help you keep the config in sync with other targets at the same time Nov 01 03:09:12 was CONFIG_VIDEO_DEV intended or unintended? Nov 01 03:09:27 nbd: such scripts exist in Debian today Nov 01 03:09:30 <[g2]> nbd that's interesting Nov 01 03:09:50 (which is why I brought Debian up as an example - they've been doing this for years) Nov 01 03:09:51 <[g2]> rwhitby that's using the debian kernel model Nov 01 03:10:15 i definitely need to check out the debian stuff then Nov 01 03:10:28 because when our list of targets get longer, we need to keep them in sync somehow Nov 01 03:10:35 but also categorize them at the same time Nov 01 03:10:39 [g2]: the nslu2-linux kernel SVN repo model is intended to reduce divergence between targets (preferably to zero) Nov 01 03:10:48 because some devices don't have pci or usb, so it doesn't make sense to build those parts Nov 01 03:10:53 it needs to be modularized somehow Nov 01 03:10:55 That's why we have a Makefile which uses a single defconfig to build N targets Nov 01 03:12:00 If we're going to build completely differently configured kernels for different targets, then the Makefile should be structured *completely* differently (i.e. building the kernel N times, rather than building it once and prepending a shim for each of N targets) Nov 01 03:12:29 in openwrt we want to support as many devices as possible from the same kernel config Nov 01 03:12:40 so most stuff is put in modules Nov 01 03:12:54 If we need to make that change, then so be it. But we need to make it in a conscious manner, not just by forking the defconfig and not changing anything else in the repo to match the new paradigm. Nov 01 03:12:56 but keeping things in sync between completely different targets is the hard part Nov 01 03:13:12 nbd: same for nslu2-linux - support as many different targets from the same kernel Nov 01 03:13:27 because we have targets like ar7 that have neither pci nor usb Nov 01 03:13:37 yet things like netfilter should be similar Nov 01 03:13:45 <[g2]> nbd and you span kernel version too Nov 01 03:13:46 that is the hard part for me Nov 01 03:13:57 [g2]: i don't think that's important Nov 01 03:14:02 we intend to phase out the 2.4 stuff over time Nov 01 03:14:12 and we only use one 2.6 version for all targets currently Nov 01 03:14:21 with a large set of generic patches Nov 01 03:14:53 mwester: so that's why I'd prefer not to see a dsmg600_defconfig appear in the repo until we have collectively worked out what paradigm we are going with, and then modified everything to match that paradigm. Nov 01 03:15:54 makes sense Nov 01 03:16:03 <[g2]> rwhitby up until now (very recently) the kernel size was maxed at 1M which drove the kernel configuration Nov 01 03:16:13 [g2]: agreed. We are past that limitation now. Nov 01 03:16:49 [g2]: don't get me wrong - I'm not saying anything done up to now was wrong, I'm just asking us to discuss what we do in the future. Nov 01 03:17:25 (we did all the work to remove the 1MB barrier *specifically* so that we could have common kernels) Nov 01 03:18:11 <[g2]> so regarding common kernels Nov 01 03:18:43 yep - what's your thoughts on that topic? Nov 01 03:18:50 I'm ok with whatever we do as long as we make sure we're not make life more difficult for those using the more "feature-full" systems, or on the flip-side, making poor use of memory for those using the small systems... Nov 01 03:18:52 <[g2]> I see it as a kitchen sink for anything that's ever worked once or just stuff ppl are playing with Nov 01 03:19:12 <[g2]> versus, a kernel for a specific purpose (like the openwrt kernel) Nov 01 03:20:02 mwester: agreed - e.g. we can add support for as many modules as we like, but compiling stuff into a kernel needs more thought Nov 01 03:20:12 <[g2]> so the current kernel is built with the "plug-in" module model and very little verification is done on the modules Nov 01 03:20:36 [g2]: yep. we leave testing of modules up to the users. Nov 01 03:21:05 <[g2]> well that's often the difference between working and non-working kernels Nov 01 03:21:12 do you have any common packaging system for kernel modules? Nov 01 03:21:29 for turning them into ipkg files with proper description, files for automatically loading modules, etc? Nov 01 03:21:49 <[g2]> nbd OE automatically builds the ipkg files Nov 01 03:21:50 [g2]: there is a certain set of modules required to boot - we test them Nov 01 03:22:15 <[g2]> rwhitby sure, but that's like 10% Nov 01 03:22:27 <[g2]> or 20% the most important 20% Nov 01 03:22:35 <[g2]> that are used 80% of the time Nov 01 03:23:04 [g2]: if you're going into regression testing, that's a different (and important) topic. Nov 01 03:23:21 but (as far as I can see) does not affect the topic at hand. Nov 01 03:23:37 <[g2]> rwhitby right. That's where just about at. Full automated regression testing Nov 01 03:24:19 [g2]: yes, but that's a separate topic which is needed irrespective of the kernel paradigm Nov 01 03:24:30 so let's not muddy the two together Nov 01 03:25:30 <[g2]> the nslu2-linux kernel repo is a simply a "water cooler" to discuss kernel issues regarding ixp4xx kernels Nov 01 03:26:18 yes, and includes a defconfig which is intended to include as much as possible (either compiled in, or as supported modules) into a single kernel to be tested across a range of devices. Nov 01 03:26:25 <[g2]> we are the "Blue collar" "Everyman's" IXP4xx kernel team Nov 01 03:27:36 <[g2]> rwhitby s/tested across/built across/ Nov 01 03:27:47 well, built and booted Nov 01 03:28:02 not fully tested by any means Nov 01 03:28:11 <[g2]> not even loaded Nov 01 03:28:24 pardon? Nov 01 03:28:37 <[g2]> modprobe all the modules Nov 01 03:28:52 <[g2]> literally loading the modules into kernel memory Nov 01 03:29:06 right Nov 01 03:29:22 So is the issue then a defconfig containing *tested* stuff versus a defconfig containing "buildable" stuff? Nov 01 03:29:23 perhaps we should have an initramfs in the kernel repo which does that Nov 01 03:29:28 mwester: no Nov 01 03:29:49 I'm confused then (but I'm butting in anyway :) ) Nov 01 03:30:02 we can't dream of having the time to test everything we put in our defconfigs Nov 01 03:30:12 not butting in - it's an open discussion Nov 01 03:30:52 <[g2]> mwester it's about trying to define the common goals and focus Nov 01 03:30:53 Agreed; we can't test everything, but what is the quality metric that permits something to be in the defconfig? Nov 01 03:31:23 it builds, and if it's involved in booting or ssh, then it's been tested on at least one platform :-) Nov 01 03:31:34 <[g2]> or something like since we have a second stage loader, can we remove all the shims from the Makefile ? Nov 01 03:31:44 (and then tested on all platforms eventually Nov 01 03:32:02 [g2]: yes, when we have second stage bootloader support on all platforms, we should be able to remove the shims Nov 01 03:32:21 (I think we're close to that point, but just need to do some more implementation) Nov 01 03:34:18 <[g2]> rwhitby so a real question is what avila support (if any) will the makefile have ? Nov 01 03:34:42 anyway, back to the topic at hand - whether we want to continue the paradigm of "one kernel for all", or move to a paradigm of "one kernel for each" for the nslu2-linux svn kernel repo. Note that this does not affect what each platform sends upstream, nor does it affect what each platform does for production builds. Nov 01 03:35:36 [g2]: I'd like to have support for avila in the single kernel we build, such that our kernel patches can be tested by booting them on an avila board with a defconfig which doesn't need to match the production defconfig or the upstream defconfig Nov 01 03:36:52 <[g2]> rwhitby ok well I think we just double check the endian issues and you may have already fixed that Nov 01 03:37:58 [g2]: nod Nov 01 03:38:06 <[g2]> after 19+ things are totally sane regarding the libata Nov 01 03:38:58 <[g2]> so in my mind the only issues is the MAC support and the MTD notifier for micro code loading Nov 01 03:39:16 <[g2]> and both of those fall in the open IXP driver area Nov 01 03:39:48 right. we would like to present a united front to l-a-k on the way we handle those things. e.g. submit patches for five platforms at once in those areas. Nov 01 03:40:35 <[g2]> I think the united front approach is the rift part I spoke about earlier Nov 01 03:40:43 <[g2]> regarding l-a-k Nov 01 03:40:55 ok, what's the rift? Nov 01 03:41:32 <[g2]> my take is l-a-k is a patchocracy Nov 01 03:42:31 <[g2]> and they want ppl to do a lot of homework Nov 01 03:43:01 <[g2]> the don't want to spend much time discussing possibilities Nov 01 03:43:06 * VoodooZ thinks the gurus should get a survey out there to see what people want/need as opposed to trying to make it everything for everybody. my 0x02$ Nov 01 03:43:17 is the rift between nslu2-linux and l-a-k, or within nslu2-linux ? Nov 01 03:44:04 <[g2]> rwhitby have we heard anything back on the 50+ e-mails to deepak ? Nov 01 03:44:07 [g2]: agreed - l-a-k says they want discussion before patches, but really they only enter a discussion once patches are submitted. Nov 01 03:44:15 [g2]: not a single reply Nov 01 03:44:28 <[g2]> that's what I'm talking about Nov 01 03:44:52 <[g2]> both the no replay, and the only really comment on patches Nov 01 03:45:00 <[g2]> s/replay/reply/ Nov 01 03:45:01 [g2] meant: both the no reply, and the only really comment on patches Nov 01 03:45:03 right, that's why our strategy is to prototype *our* preferred solution in our svn kernel repo, and then push patches Nov 01 03:45:22 (and not wait for a reply which won't come until we submit a patch) Nov 01 03:45:27 <[g2]> which is how we got into this mess Nov 01 03:45:34 ?? Nov 01 03:45:39 what mess? Nov 01 03:45:43 <[g2]> that's exactly what I was doing with the ixp4xx Nov 01 03:46:11 <[g2]> and blaster8 got upset about what was supposed to be in the repo and what isn't Nov 01 03:46:33 we've already sorted out that misunderstanding of the purpose of our svn kernel repo Nov 01 03:46:44 night Nov 01 03:46:47 <[g2]> night Nov 01 03:47:03 <[g2]> so now we are sorting out the future goals and direction Nov 01 03:47:11 <[g2]> at least between u Nov 01 03:47:13 <[g2]> us Nov 01 03:51:01 yes Nov 01 03:51:53 there is no problem with loft_defconfig sitting there today. we're discussing whether it stays separate, or whether we merge it back with defconfig (by changing defconfig to match it in the areas of MAC and firmware) Nov 01 03:52:09 (and creating patches for the other platforms) Nov 01 03:53:59 <[g2]> I put the loft_defconfig in there for the ppl testing on the avila platform Nov 01 03:54:50 <[g2]> it's nice to be able to track the changes and working versions Nov 01 03:55:02 [g2]: agreed. and now we're discussing how to bring the avila platform into the mainstream with the other platforms Nov 01 03:55:27 (by moving the other platforms to the same level of functionality that the avila platform now has) Nov 01 03:57:47 <[g2]> so my goal is the same a it was nearly 2.5 years ago Nov 01 03:58:06 <[g2]> to get to the point of a dl kernel.org make loft_defconfig and run Nov 01 03:58:24 <[g2]> run a freshly minit kernel Nov 01 03:58:31 <[g2]> s/minit/minted/ Nov 01 03:58:32 [g2] meant: run a freshly minted kernel Nov 01 03:58:49 yep, same goal for nslu2 and other platforms too Nov 01 03:59:17 we've been holding back on sending defconfig upstream until we have a stable defconfig Nov 01 04:01:55 <[g2]> well it's been a busy day. More BE regression testing tomorrow Nov 01 04:02:23 <[g2]> right now there's just GPSFan's built issue Nov 01 04:02:29 <[g2]> s/built/build/ Nov 01 04:02:30 [g2] meant: right now there's just GPSFan's build issue Nov 01 04:02:43 <[g2]> and that's on a non-OE toolchain Nov 01 04:03:10 <[g2]> I do need to try 4.1.1 also Nov 01 04:04:14 <[g2]> time for some sleep Nov 01 04:04:30 <[g2]> I'll check the logs in the AM Nov 01 04:04:44 <[g2]> nite all Nov 01 04:06:28 [g2]: night. I had a few thoughts about my problem. I'll talk to you about them tomorrow.. Nov 01 04:31:31 03bzhou * r4351 10optware/trunk/make/erl-escript.mk: added erl-escript Nov 01 05:14:02 03bzhou * r4352 10optware/trunk/Makefile: grouped erlang packages in ERLANG_PACKAGES, promoted erl-escript Nov 01 06:20:55 03bzhou * r4353 10optware/trunk/make/erl-escript.mk: erl-escript: use gnu make syntax Nov 01 06:54:18 03bzhou * r4354 10optware/trunk/make/erl-escript.mk: erl-escript: stable SITE Nov 01 08:03:44 hi all. Nov 01 08:03:53 hi Nov 01 08:05:48 I have my nslu2 unslung on usb flash mem, but I cobbled together an old laptop drive and usb interface. Nov 01 08:06:00 it's detected and formated fine. Nov 01 08:06:17 how do I move from the flash to the hdd ? Nov 01 08:06:27 can I unsling again ? Nov 01 08:07:40 yep Nov 01 08:08:58 can Ijust copy everything from the flash to the hdd, switch off, change hdd slot and boot ? Nov 01 08:09:25 I'm expecting not. Nov 01 08:15:53 actually, you probably can if get all the partitions and hidden files right Nov 01 08:16:02 but easiest is just to unsling and then copy data across Nov 01 08:16:48 right, so boot with just the hdd and unsling, add flash and copy what I need ? Nov 01 08:17:00 yep Nov 01 08:25:40 dev//sdb1 does that sound right ? Nov 01 08:27:48 ack, whatever, I'm gonna hose it. Nov 01 08:47:04 Somethings not right. Nov 01 08:52:16 format failed. Nov 01 09:13:45 woo. worked. Nov 01 09:13:56 bit odd, the hdd doesn;t seem to work in port 1. Nov 01 09:38:46 hi all Nov 01 09:43:55 morning, likewise Nov 01 10:40:24 blaster8: hi there Nov 01 10:40:32 hi Nov 01 10:40:44 how's your custom board going? Nov 01 10:42:37 blaster8: boards, actually. 80% has been routed of one board, 50% of the other Nov 01 10:42:52 (not my part of the involvement, though) Nov 01 10:43:08 ok, so still in development Nov 01 10:44:16 yes, the board we currently have (which is 99% done, a final proto is in the works) will probably remain a test board and not an end product. Nov 01 10:44:42 ok, understood Nov 01 10:45:32 blaster8: I am trying to test the NPE GPL driver but still wrestling with OE/bitbake stuff... Nov 01 10:45:37 ? Nov 01 10:45:49 Which kernel version are you trying to build? Nov 01 10:46:17 2.6.18 Nov 01 10:46:43 what problems are you having? Nov 01 10:46:46 blaster8: I am working off the www.openembedded.org monotone repo. Nov 01 10:46:52 ok Nov 01 10:47:30 If you'd like some advice/help I'm happy to try Nov 01 10:47:39 blaster8: bitbake that loops indefinitely across these 3 lines: Nov 01 10:47:41 NOTE: ixp4xx-kernel (2.6.18-r1.534) already staged but upgrading to 2.6.17-r5.5 to satisfy kernel-module-ixp4xx-qmgr Nov 01 10:47:42 NOTE: ixp4xx-kernel (2.6.18-r1.534) already staged but upgrading to 2.6.17-r5.5 to satisfy kernel-image-2.6.17 Nov 01 10:47:44 NOTE: ixp4xx-kernel (2.6.18-r1.534) already staged but upgrading to 2.6.17-r5.5 to satisfy kernel-image- Nov 01 10:48:07 can you remove tmp/ directory and try the build again from scratch? Nov 01 10:48:47 I already did, I can do that, it will bring me two to three hours ahead though. Nov 01 10:49:22 so, you've tried a build from scratch and are still coming up with the same problem Nov 01 10:49:58 are you sure you're not specifying kernel-image-2.6.17 somewhere? Nov 01 10:51:42 blaster8: I'll try a clean build just to be sure, while I work on other stuff :-) Nov 01 10:52:17 it's probably best to check your configuration then run a clean build Nov 01 10:55:53 do you have one or two ethernet macs on your custom board? Nov 01 10:56:57 on the 99% finished one, 2 Nov 01 10:57:03 hmm Nov 01 10:57:21 are you building the ixp4xx-npe package? Nov 01 11:00:39 you will need to alter it to package both the npe-b and npe-c microcode Nov 01 11:06:13 blaster8: we'll need that for the fsg-3 as well Nov 01 11:06:22 indeed Nov 01 11:06:40 probably best to include both in the default image, given how tiny they are Nov 01 11:06:59 NAiL: can you fix this up, if I explain what to do? Nov 01 11:07:01 blaster8: currently only b is packages? Nov 01 11:07:08 yes Nov 01 11:07:20 ok, I'll listen in if you explain. Nov 01 11:07:21 :-) Nov 01 11:07:56 I added ixp4xx-mcgrab as a package to OE, but maybe it's already in there? Nov 01 11:08:16 I'm at work for another four hours or so Nov 01 11:08:16 OK, at the moment the header file at http://www.hohnstaedt.de/ixp_npe/IxNpeMicrocode.h specifies extracting the NPE-C Crypto support image Nov 01 11:08:28 which would be fine, but we are not downloading the crypto support version of the Microcode file Nov 01 11:09:24 so we need a patch for the Microcode header file which undefines the crypto NPE image and defines the last NPE-C image Nov 01 11:09:30 'IX_NPEDL_NPEIMAGE_NPEC_ETH_LEARN_FILTER_SPAN_FIREWALL' Nov 01 11:10:16 then a bit of magic in the bitbake file to copy the newly created NPE-C image to the right place for staging, and job's done Nov 01 11:18:37 So, http://www.rafb.net/paste/results/k8dN4k47.html for the diff Nov 01 11:20:11 <[g2]> morning blaster8 like|lunch Nov 01 11:20:35 like|lunch: that's the one Nov 01 11:21:36 <[g2]> blaster8 dunno if you caught the logs, but all is running both BE and LE for .19-rc3 for me Nov 01 11:21:45 is it working now? Nov 01 11:22:36 <[g2]> everything is working for me, GPSFan still has build issue, but my kernel works on his hw Nov 01 11:22:44 what build issue? what gcc ver? Nov 01 11:23:21 <[g2]> build issues as in his version doesnt' work with the ethernet properly Nov 01 11:23:29 ? Nov 01 11:23:39 that's probably the microcode, from the log I saw Nov 01 11:24:06 he should try with up-to-date microcode rather than extracting from Redboot Nov 01 11:24:32 <[g2]> blaster8 it works with his microcode and my kernel Nov 01 11:24:47 ok, fair enough Nov 01 11:24:51 which GCC version? Nov 01 11:25:07 <[g2]> I'm gcc 3.4.x and he's 4.1.1 iirc Nov 01 11:25:14 4.1.1? Nov 01 11:25:24 <[g2]> gcc 4.1.1 Nov 01 11:25:29 that's what SlugOS is using atm Nov 01 11:26:01 <[g2]> he's got his own tool chain, so it's quite possible he's missing a patch Nov 01 11:26:19 sounds likely Nov 01 11:26:36 <[g2]> I'm just giving you the update Nov 01 11:36:04 ? Nov 01 11:44:22 <[g2]> blaster8 I was just giving you the status update on activitiess Nov 01 11:44:26 ok Nov 01 11:44:44 I've got the ixp4xx-npe package packaging NPE-C microcode too Nov 01 11:45:16 <[g2]> the current code doesn't pull the crypto stuff does it ? Nov 01 11:45:25 <[g2]> current being our repo Nov 01 11:47:27 no Nov 01 11:47:32 it's a pain to download from intel Nov 01 11:48:45 gtg Nov 01 11:51:23 NAiL: http://pastebin.ca/raw/232561 Nov 01 11:53:44 morning. Nov 01 11:54:00 wow lots of discussion going on. me like. Nov 01 11:55:37 blaster8: ok, I'll look into it after work Nov 01 13:55:06 [g2]: hello Nov 01 13:55:23 <[g2]> likewise hey Nov 01 14:01:48 <[g2]> VoodooZ ping Nov 01 14:57:14 [g2]: morning.. Nov 01 15:00:15 <[g2]> GPSFan hey Nov 01 15:00:59 [g2]: I tried changing my config to add the other machine defined (loft, ixdp425, etc) like your config. I changed my mach-types back to it's original config and added a shim at the start of the kernel binary (again like yours). It built ok and runs, but has the same ehternet issue as before. Nov 01 15:01:29 btw I'm using gcc 3.4.5 Nov 01 15:07:39 [g2] GPSFan: hi! Nov 01 15:08:04 [g2]: can you send me your .config? Nov 01 15:08:38 dwery: g'day Nov 01 15:09:00 <[g2]> dwery which .config for BE ? Nov 01 15:09:11 yes Nov 01 15:09:41 <[g2]> dwery lemme power on the box, but I think it's identical to the one in the repo Nov 01 15:09:44 ok Nov 01 15:09:59 <[g2]> I'll double check Nov 01 15:25:23 <[g2]> dwery things a different Nov 01 15:25:33 <[g2]> are Nov 01 15:26:01 ok Nov 01 15:26:07 pong Nov 01 15:26:27 [g2]: any significant difference? Nov 01 15:26:57 <[g2]> dwery are you looking to test BE ? Nov 01 15:27:36 <[g2]> as I've got a very tiny script that creates a jffs2 busybox rootfs Nov 01 15:27:45 No, I want to check if there's anything that can lead an explanation to my USB problems Nov 01 15:28:27 <[g2]> dwery 1.1 or 2.0 issues ? Nov 01 15:28:33 both of them Nov 01 15:28:54 [g2]: what's up? Nov 01 15:28:57 <[g2]> have you run the usb monitor stuff ? Nov 01 15:29:04 <[g2]> do see all the usb transactions ? Nov 01 15:29:10 <[g2]> s/do/to/ Nov 01 15:29:11 [g2] meant: to see all the usb transactions ? Nov 01 15:29:33 nope. I get intermittent glitches Nov 01 15:29:53 so I was starting from .config before going deeper Nov 01 15:30:33 <[g2]> VoodooZ did you see the nanocom and minicom ? http://www.digilentinc.com/Products/Detail.cfm?Prod=NANOCON&Nav1=Products&Nav2=Embedded Nov 01 15:31:02 [g2]: no but I will check it out right away. Nov 01 15:31:37 nice Nov 01 15:31:52 It the analog of the RoboStix for the gumstix. Nov 01 15:32:04 s/It/It's/ Nov 01 15:32:04 VoodooZ meant: It's the analog of the RoboStix for the gumstix. Nov 01 15:32:14 <[g2]> VoodooZ sometime I'd like to take about those boards a little Nov 01 15:32:36 [g2]: progress! I took my kernel tree and just made zImage using loft_defconfig-be renamed to .config. I than added the shim, and THE ETHERNET WORKS! Nov 01 15:32:59 take or talk? Nov 01 15:33:04 <[g2]> talk Nov 01 15:33:07 hehe Nov 01 15:33:11 <[g2]> thx Nov 01 15:33:22 GPSFan: well done Nov 01 15:33:23 Why? you interested in using one or making one? Nov 01 15:33:24 GPSFan: congrats! Nov 01 15:33:33 <[g2]> GPSFan great news Nov 01 15:33:35 can you diff your old config to this one please Nov 01 15:33:46 and give a report of the previous error Nov 01 15:33:48 me too, please paste Nov 01 15:34:24 [g2]: yeah, there are soooooo many subtle config options. I'll get a diff to my old one to see what it was. Nov 01 15:35:33 I'am glad almost everything works now Nov 01 15:35:40 except my USB, of course Nov 01 15:36:07 [g2]: you had something related to the temperature on your punch list, right? Nov 01 15:36:11 <[g2]> GPSFan that's what testing/verification is all about Nov 01 15:36:21 [g2]: ;>) Nov 01 15:37:48 blaster8: at first glance there are tons of differences. mostly due to my config not building lots of things that [g2]'s config builds as modules. it will take a bit of cleaning up before it's obvious what the true differences are. Nov 01 15:38:17 there will be loads of differences - if you post it raw we can get through most of them quickly Nov 01 15:39:12 blaster8: sounds good to me. pastebin comming up in scant minutes.. Nov 01 15:39:18 thanks Nov 01 15:45:34 [g2]: digilent have nice little boards. Nov 01 15:46:00 For my robots I just breadboard my own though as I like it cheap. Nov 01 15:46:40 blaster8: first it the diff between the configs (the 08:43 works, the 07:11 doesn't): http://pastebin.ca/232828 second is the log of the boot and first ping: http://pastebin.ca/232825 Nov 01 15:47:29 could we have a universal diff - pretty please :) Nov 01 15:48:01 <[g2]> GPSFan you used the loft-defconfig-be file I e-mailed you yesterday right? Nov 01 15:48:19 <[g2]> loft_defconfig-be Nov 01 15:48:27 blaster8: sorry, I'm not really a programmer and I need a little help with how to diff that. [g2] yes that's what I used. Nov 01 15:48:41 diff -u oldconfig newconfig Nov 01 15:49:01 blaster8: comming up Nov 01 15:51:07 blaster8: http://pastebin.ca/232836 Nov 01 15:51:44 rats It's backwards..as2!@#$!@% Nov 01 15:51:53 future reference, it's best to do diff -u Originalfile Newfile Nov 01 15:52:48 <[g2]> blaster8 http://www.giantshoulderinc.com/loft Nov 01 15:53:22 ? I see a directory with nothing in it Nov 01 15:53:36 <[g2]> refresh Nov 01 15:54:09 better Nov 01 15:54:13 http://pastebin.ca/232840 Nov 01 15:54:46 I've got to run off for most of the rest of the day, cu later... Nov 01 15:55:02 ok, thanks Nov 01 15:59:20 [g2]: do you have a link to the issue that GPSFan had? Nov 01 16:00:09 <[g2]> blaster8 it's in the logs from yesterday, the ARP issue Nov 01 16:01:19 <[g2]> dwery I'm guessing you saw the defconfig file Nov 01 16:01:59 [g2]: the pastebin? will check in a few mins Nov 01 16:02:23 <[g2]> dwery no the full defconfig file on my website Nov 01 16:02:50 no, haven't got it yet. will do Nov 01 16:03:01 <[g2]> nod just fyi Nov 01 16:19:58 [g2]: recompiling with a few changes Nov 01 16:23:07 it seems it's working Nov 01 16:24:02 I enabled the three options under EHCI Nov 01 16:24:05 now running bonnie++ Nov 01 16:24:23 rc4 is out Nov 01 16:26:09 and tested? :) Nov 01 16:27:51 compiling :) Nov 01 16:28:30 <[g2]> dwery so the USB 2.0 is working for you now ? Nov 01 16:28:43 it seems so Nov 01 16:28:52 I'll let bonnie run for a while Nov 01 16:28:52 <[g2]> excellent Nov 01 16:29:21 <[g2]> can you post/e-mail the diffs EHCI diffs between the working/non-working config ? Nov 01 16:29:23 what's missing next? it seems everything is working Nov 01 16:29:41 <[g2]> dwery rc4 testing :) Nov 01 16:29:48 I addedCONFIG_USB_EHCI_SPLIT_ISO=y Nov 01 16:29:48 CONFIG_USB_EHCI_ROOT_HUB_TT=y Nov 01 16:29:48 CONFIG_USB_EHCI_TT_NEWSCHED=y Nov 01 16:30:52 <[g2]> dwery the only think I know of is the calibration on the temperature module Nov 01 16:31:05 <[g2]> is that open ? Nov 01 16:31:07 I forgot there was a calibration... Nov 01 16:31:24 <[g2]> I don't mean calibration, I mean conversion Nov 01 16:31:29 conversion? Nov 01 16:31:42 <[g2]> the 4500 versus 45c Nov 01 16:31:50 that it's done by sensors/lm-sensors Nov 01 16:32:02 the driver will report the value in millidegree celsius as per specs Nov 01 16:32:03 <[g2]> is everything currently working fine ? Nov 01 16:32:03 conflagration Nov 01 16:32:15 'a large destructive fire' Nov 01 16:32:18 hmm, perhaps not Nov 01 16:32:28 barnseenio: :-D Nov 01 16:32:32 <[g2]> :) Nov 01 16:32:47 <[g2]> milli or centi ? Nov 01 16:33:15 milli Nov 01 16:33:34 <[g2]> so shouln't it be 45000 ? Nov 01 16:34:14 yes. and I think it is. you are getting 4500? Nov 01 16:35:51 crikey what you guys upto? Nov 01 16:35:57 rocket science? Nov 01 16:36:10 putting a slug in space? Nov 01 16:37:53 rc4 seems fine too Nov 01 16:38:34 that meand that when .19 will be out we will be ready for upstream push of relevant patches, knowing that our kernel base is doing fine Nov 01 16:38:39 s/meand/means/ Nov 01 16:38:41 dwery meant: that means that when .19 will be out we will be ready for upstream push of relevant patches, knowing that our kernel base is doing fine Nov 01 16:39:16 <[g2]> dwery any reason not to move to rc4 ? Nov 01 16:39:34 none Nov 01 16:39:50 <[g2]> can you push ? Nov 01 16:40:38 sure Nov 01 16:40:43 how's the temperature? Nov 01 16:41:39 <[g2]> I haven't checked the temperature Nov 01 16:41:44 doh! it's already 2.6.19-rc4 in svn/KERNEL :) Nov 01 16:42:05 <[g2]> outside it's really pretty and like 65F Nov 01 16:42:28 I've got 15C outside Nov 01 16:43:13 <[g2]> dwery looks like things are in good shape Nov 01 16:43:40 <[g2]> I still need to verify the temp reading, but other than that I think there are no open issues Nov 01 16:44:53 ok Nov 01 16:45:30 once I'll have my new shelf completed I'll move to the NAS100d to see if still works Nov 01 16:46:26 other than that, I'am still playing with my new epson driver for SANE and twiggling some datamatrix barcodes for optical documents archiving.. Nov 01 17:10:45 37F outside here. Nov 01 17:17:34 <[g2]> out to eat Nov 01 17:25:41 03bzhou * r4355 10optware/trunk/make/py-selector.mk: py-selector: upstream upgrade to 0.8.9 Nov 01 17:58:55 I've just tried the same kernel on the NSLU2: Nov 01 17:58:57 0xb0000050-0xb0000450 : "RedBoot" Nov 01 17:58:57 mtd: partition "RedBoot" is out of reach -- disabled Nov 01 18:08:56 http://rafb.net/paste/results/pTSuHX92.html Nov 01 19:36:35 03bzhou * r4356 10optware/trunk/make/sendmail.mk: sendmail: use LOGNAME instead of USER so cron autobuild also have the env variable Nov 01 19:38:27 03bzhou * r4357 10optware/trunk/Makefile: promoted sendmail Nov 01 19:55:02 eno: patch doesn't work, after configure the define looks like -DCLAMAV_tmpdir=/opt/tmp instead of -DCLAMAV_tmpdir="/opt/tmp" Nov 01 19:55:24 have already tried some variants without success Nov 01 20:18:31 trying mc_grab on the nslu2.. Nov 01 20:39:56 gda_: -DCLAMAV_tmpdir=\"/opt/tmp\" ? Nov 01 20:42:51 eno: that was the first that I have tried ;) Nov 01 20:44:59 gda_: -DCLAMAV_tmpdir=\\\"/opt/tmp\\\" ? Nov 01 20:45:09 eno: okay you get then -DCLAMAV_tmpdir="/opt/tmp", but anyway it breaks with: Nov 01 20:45:23 others.c:401: error: parse error before '/' token Nov 01 20:47:44 eno: -DCLAMAV_tmpdir=\\\"/opt/tmp\\\": configure: error: C compiler cannot create executables Nov 01 20:59:14 gda_: k, try the following: Nov 01 20:59:28 leave CLAMAV_CPPFLAGS empty Nov 01 21:00:07 for configure CPPFLAGS="$(STAGING_CPPFLAGS) $(CLAMAV_CPPFLAGS)" Nov 01 21:00:31 for $(CLAMAV_BUILD_DIR)/.built target Nov 01 21:00:41 $(MAKE) -C $(CLAMAV_BUILD_DIR) \ Nov 01 21:00:41 CPPFLAGS="$(STAGING_CPPFLAGS) $(CLAMAV_CPPFLAGS) -DCLAMAV_tmpdir=\\\"/opt/tmp\\\"" Nov 01 21:00:48 it should work Nov 01 21:01:44 it just the configure went thru too many quote/escape Nov 01 21:01:58 eno: am trying Nov 01 21:02:57 eno: it builds at least Nov 01 21:06:07 eno: clamscan works Nov 01 21:06:43 cool Nov 01 21:08:08 freshclam works now too Nov 01 21:08:25 eno: am trying to check in, but hangs Nov 01 21:08:30 03gda * r4358 10optware/trunk/make/clamav.mk: clamav uses now /opt/tmp instead of /tmp Nov 01 21:09:41 i read somewhere openbsd spamd is pretty good Nov 01 21:15:51 eno: where? amavisd is very flexible Nov 01 21:16:56 http://en.wikipedia.org/wiki/Spamd Nov 01 21:17:37 I'm looking at spamd for my personal use right now ... comparing it against spamassassin Nov 01 21:18:07 oh, sorry. I'm looking at dspam - something different. Nov 01 21:19:27 rwhitby: spamasssassin does a great job for me. I run it on two dedicated servers processing emails from my mx Nov 01 21:19:32 eno: spamd is useless for me, I don't have an open smtp server, I get my mails with fetchmail Nov 01 21:20:06 rwithby: amavisd uses spamassassin and can use dspam too Nov 01 21:26:27 interesting error message: Nov 01 21:26:31 Nov 1 19:38:43 diskstation user.err synousbdisk: USB disk is polled out. Nov 01 21:55:32 ' doh! it's already 2.6.19-rc4 in svn/KERNEL :)' Nov 01 21:55:39 thank you, I'm here all week Nov 01 21:55:41 :p Nov 01 21:55:50 :) Nov 01 21:55:57 blaster8: does USB work fine for you? Nov 01 21:56:06 no hardware here Nov 01 21:56:13 no usb ports on the hardware I do have Nov 01 21:56:14 right. I forgot Nov 01 21:56:30 we need to get that verified - are you having trouble on the NSLU2? Nov 01 21:56:35 yes Nov 01 21:56:46 it boots fine but hangs later Nov 01 21:56:55 no messages on the serial port Nov 01 21:57:05 not good at all Nov 01 21:57:17 how are you implicating usb? Nov 01 21:57:35 when I use nfsroot it works fine Nov 01 21:57:53 flash boot? Nov 01 21:58:07 did not tried Nov 01 21:58:13 I'am now recompiling for nfsroot Nov 01 21:58:21 and will launch bonnie++ on the usb hd Nov 01 21:59:23 thanks Nov 01 21:59:30 [g2] will also use bonnie++ Nov 01 21:59:37 try compiling kernel with no usb support and flash booting, too Nov 01 21:59:37 on the loft, I thinl Nov 01 21:59:48 I do not have any flash root Nov 01 21:59:53 (or just rmmod the usb modules...) Nov 01 22:00:00 dwery: slugos? Nov 01 22:00:30 nope. But given that when booting from nfs everything is ok, I'd say USB is the problem Nov 01 22:01:38 i guess so Nov 01 22:03:32 We would need someone else with an NSLU2 to test Nov 01 22:03:52 <[g2]> dwery is this just rc4 or rc3 too ? Nov 01 22:04:06 I'am running rc4 but had problems with rc3 too Nov 01 22:04:35 <[g2]> dwery your USB has never been really happy right ? Nov 01 22:04:44 right Nov 01 22:04:50 <[g2]> that's just the Loft board Nov 01 22:05:06 I had problems both with the loft and the nslu2 Nov 01 22:05:17 with two different enclosures and one usb net adapter Nov 01 22:05:50 <[g2]> which usb net adapter ? Nov 01 22:05:55 rtl8150 Nov 01 22:06:00 <[g2]> ah Nov 01 22:06:06 <[g2]> I've got some linksys ones Nov 01 22:06:24 I'd say the problem is at usb layer Nov 01 22:08:22 <[g2]> well I'm wondering why you are the only one that seems to be seeing it Nov 01 22:08:45 <[g2]> both the loft and nslu2 were up on external hds 24/7 for 180 days + Nov 01 22:08:59 which kernel? Nov 01 22:09:14 my production nlsu2 was working just fine with an older kernel Nov 01 22:09:14 <[g2]> probably .15 and 16 Nov 01 22:09:46 <[g2]> my local box is up for nearly 100 days on an external microdrive too Nov 01 22:10:38 <[g2]> ok 61 days right now Nov 01 22:10:46 <[g2]> I forgot about the last power outage Nov 01 22:11:22 * [g2] turned off the UPS to stop the incessant beeping Nov 01 22:12:12 :) Nov 01 22:12:18 I was too on .15 or .16 Nov 01 22:16:46 I AM STUPID. Nov 01 22:17:19 indeed? Nov 01 22:17:40 <[g2]> dwery ?? Nov 01 22:17:46 let me finish a couple of tests and I'll tell you.. Nov 01 22:17:50 * blaster8 is stupid too, but tends to keep it quiet Nov 01 22:18:03 d'oh Nov 01 22:18:14 <[g2]> if dwery is stupid, I _must_ be the village idiot Nov 01 22:18:30 :) Nov 01 22:20:25 well, I was booting with mem=64mb in the cmdline Nov 01 22:20:47 that's why I always pushed for memory autodetection Nov 01 22:20:50 disk caching Nov 01 22:22:29 pushing you over the 32MB limit Nov 01 22:22:33 yep Nov 01 22:22:41 I hate loosing time this way Nov 01 22:23:11 still, better than losing time trying to diagnose the issue Nov 01 22:24:14 now recompiling for usb boot Nov 01 22:27:18 night all Nov 01 22:27:24 night! Nov 01 22:27:25 <[g2]> nite blaster8 Nov 01 22:39:43 [g2]: everything seems stable now Nov 01 22:39:52 I'm compiling a reduced size kernel for the flash Nov 01 22:40:20 has any progress been made on making an lzma loader? Nov 01 22:40:45 [g2]: just got back, the rtc needs UIE_EMUL turned on in the config. I had it on in mine and the rtc woked. I didn't have a chance to check it this morning when I gou your config up. Nov 01 22:41:05 if not, i might give it a shot as soon as i have a kernel working on my board Nov 01 22:41:14 nbd: lzma? Nov 01 22:41:25 dwery: better compression Nov 01 22:41:30 !! Nov 01 22:41:32 nice! Nov 01 22:41:47 we mostly use lzma loaders for our mips targets Nov 01 22:42:09 on the nslu2 I have the 1MB limit which is way too low Nov 01 22:42:10 and it makes things a lot smaller than gzipped stuff Nov 01 22:42:16 it could really benefit of lzma Nov 01 22:42:22 dwery: the 1MB limit has been solved Nov 01 22:42:27 doh! Nov 01 22:42:31 (using apex as a second stage bootloader) Nov 01 22:42:39 I stay away for a couple of month and see what happens :) Nov 01 22:42:54 even if the limit is gone, it would still be useful in order to not waste so much precious flash space :) Nov 01 22:42:54 tbm has a working implementation in his latest debian-installer images Nov 01 22:43:04 we just need to update OE to do the same Nov 01 22:43:05 * nbd wants his systems to run completely from flash Nov 01 22:43:10 can apex use the ixp4xx ethernet? Nov 01 22:43:24 dwery: marc is looking into that Nov 01 22:43:29 ok Nov 01 22:43:32 (and sharing the microcode partition) Nov 01 22:43:45 apex now has an fis directory driver Nov 01 22:43:48 nice. Nov 01 22:43:54 and what happened to LudeBoot? Nov 01 22:44:20 and support for skip regions, to skip over the 16 byte header which is necessary in the middle of a > 1MB kernel Nov 01 22:44:36 I consider LudeBoot to be superceded as soon as APEX has network support Nov 01 22:45:45 ack Nov 01 22:47:51 nbd: so lzma is already in the kernel Nov 01 22:47:52 ? Nov 01 22:48:27 dwery: no. we usually make a binary image out of the kernel, lzma-compress it and link it with the loader Nov 01 22:48:39 ah Nov 01 22:50:00 how does lzma compare against bzip2? Nov 01 22:51:58 I've read the man page :) Nov 01 22:52:21 i think lzma is better than bzip2 Nov 01 22:52:38 and it might be faster at decompression too, but i don't know that for sure Nov 01 22:52:49 anyway, we use it for squashfs as well Nov 01 22:56:04 I will be happy to test your loader Nov 01 22:56:31 i don't have one for arm yet Nov 01 22:56:43 in fact i don't even have an arm board up and running yet Nov 01 22:56:59 but since i've messed with the loader stuff before, i could try porting it Nov 01 22:58:01 you don't have an arm board at all? Nov 01 23:02:01 dwery: the board that i have is not running yet Nov 01 23:02:08 dwery: currently in the middle of a long jtag operation Nov 01 23:02:16 ok Nov 01 23:04:00 [g2]: what's the status about the mac loading from eeprom/flash for the ixp4xx driver? Nov 01 23:05:49 <[g2]> dwery I haven't looked at lennert's example for the ep93xx Nov 01 23:06:02 dwery: there's an implementation for the loft, and we need to port that to our other targets Nov 01 23:06:27 I can try doing it for the nslu2 Nov 01 23:06:39 that'd be sweet Nov 01 23:07:58 What do people think about putting the microcode in the SysConf partition on the NSLU2? Nov 01 23:08:24 (since that's not flashed on an upgrade) Nov 01 23:08:26 is the svn down? Nov 01 23:08:32 nope Nov 01 23:08:34 it works now. Nov 01 23:08:52 <[g2]> rwhitby the bigger question is where are you going to get the microcode Nov 01 23:09:16 [g2]: it will be installed with a SlugOS image from slug-firmware.net, just like today Nov 01 23:09:18 <[g2]> meaning the RedBoot microcode is not compatible with the open NPE driver Nov 01 23:09:19 03azummo * r546 10kernel/trunk/patches/2.6.19/39-ixp4xx-net-driver-mtd-load-fw.patch: Fixed microcode function detection Nov 01 23:09:50 <[g2]> dwery what part did you fix ? Nov 01 23:10:01 yep, we can forget about RedBoot microcode - Christian has said he will not support the older version Nov 01 23:10:05 it handles microcodes with func == 0x00 Nov 01 23:10:14 So we put a new copy in flash separately Nov 01 23:11:12 have all our 3x- patches been sent to Christian for inclusion in the next version of his driver? Nov 01 23:11:15 <[g2]> rwhitby I understand what and why you are doing it Nov 01 23:11:56 <[g2]> I just asked where you were planning to get the updated microcode from Nov 01 23:12:28 <[g2]> I guess the click-through will continue to be there Nov 01 23:12:48 From Intel, then distributed as part of a full 8MB SlugOS image on slug-firmware.net with a click-through license, and flashed into a separate partition (which might be SysConf) Nov 01 23:13:38 then any image given to reflash (SlugOS) or flash-kernel (Debian) doesn't need to have the microcode in it, and can therefore be freely distributed and can comply with the DFSG. Nov 01 23:13:52 [g2]: is loading mac working fine for you? Nov 01 23:14:14 <[g2]> dwery last time I had the patch in Nov 01 23:14:23 <[g2]> well a couple patches Nov 01 23:14:42 <[g2]> the eeprom notifier and an updated ixmac_open Nov 01 23:15:26 <[g2]> the ixmac_open won't be acceptable to netdev and we need to come up with a different patch Nov 01 23:16:14 why it is not acceptable? Nov 01 23:16:54 <[g2]> tweaking the MAC on if open is a bad idea I hear Nov 01 23:17:05 <[g2]> s/if/interface/ Nov 01 23:17:06 [g2] meant: tweaking the MAC on interface open is a bad idea I hear Nov 01 23:17:49 <[g2]> I think blaster8 was relaying what Christian said Nov 01 23:18:12 ok Nov 01 23:18:37 any solution? Nov 01 23:19:02 <[g2]> no I haven't looked deeply into it yet Nov 01 23:19:05 <[g2]> I've been testing BE Nov 01 23:19:18 <[g2]> and .19-rc3 Nov 01 23:20:48 <[g2]> I'm toying with whether changning the makefile support for the Loft to not patch the machine ID at all Nov 01 23:21:13 <[g2]> several of my boxes have a custom RedBoot which passes the right machine I'D Nov 01 23:22:00 <[g2]> I may just reflash them all as the memory arg is passed correctly too Nov 01 23:22:25 <[g2]> then the machine ID and mem= wouldn't need to be set at all Nov 01 23:22:38 <[g2]> dwery you know what a pain that mem= can be :) Nov 01 23:23:02 :-D Nov 01 23:29:09 [g2]: if not in open() I don't know where to check for the mac Nov 01 23:37:20 03azummo * r547 10kernel/trunk/patches/2.6.19/42-nslu2-mtd-load-mac.patch: Read NSLU2 mac address from RedBoot Nov 01 23:37:23 rwhitby: it's not in the series Nov 01 23:52:22 ok, my production slug is back online Nov 01 23:52:43 I should find that old program that used the beeper of networked machines as midi instruments Nov 01 23:57:46 03azummo * r548 10kernel/trunk/patches/2.6.19/ (40-scsi-idle.patch series): Nov 01 23:57:46 Given the changes to the SCSI subsystem, the interface Nov 01 23:57:46 that is used by this patch will not work anymore Nov 01 23:57:46 and the patch will never be accepted in the kernel. Nov 01 23:57:46 It should eventually be re-implemented using Nov 01 23:57:47 the SGIO facility. Nov 02 00:10:32 hey dumfrac Nov 02 00:12:12 hi rwhitby-away Nov 02 00:12:42 I wasn't having a go at you for using bleeding edge. Just letting Martin know that he doesn't need to worry about it. Nov 02 00:13:22 yes, I know Nov 02 00:14:17 I'm now trying to figure out why we can't control the LEDs using the Debian kernel - the control works with OpenSlug Nov 02 00:15:06 I was going to append my comment about being bleeding edge with "Heck, I'm running a hacked version of apex :-)" Nov 02 00:16:54 I had neglected to point this out to Martin, so it was good that you clarified the situation - btw, the flash-kernel patched worked Nov 02 00:17:38 bbl - my wife just got home Nov 02 00:56:35 rwhitby: how do I find out which openembedded (?) package provides the leds control program (/usr/bin/leds) for the Slug ? Nov 02 00:56:58 look in Packages.filelist in the feed Nov 02 00:57:29 my guess is slugos-init Nov 02 00:58:23 ok - where do I find Packages.filelist ? I have never worked with the openembedded packages Nov 02 00:58:52 I've never used the openembedded packages Nov 02 01:07:29 dumfrac: for me it's under /data/slug/head/openslug/tmp/deploy/ipk/Packages.filelist Nov 02 01:07:57 remember 'locate' is your friend! :) Nov 02 01:09:01 thanks VoodooZ - but I don't have the repository checked out - I'm working on getting Debian etch functional so I don't use the openembedded packages :-) Nov 02 01:09:10 dumfrac: in the feed on ipkg.nslu2-linux.org Nov 02 01:09:35 thanks rwhitby Nov 02 01:09:36 http://ipkg.nslu2-linux.org/feeds/slugos-lag/cross/unstable/Packages.filelist Nov 02 01:09:41 oh sorry. Nov 02 01:09:54 Try http://ipkg.nslu2-linux.org/feeds/slugos-lag/cross/stable/Packages.filelist instead Nov 02 01:10:04 that's ok VoodooZ Nov 02 01:10:37 thanks rwhitby - I had started looking in http://www.openembedded.org/filebrowser/org.openembedded.dev Nov 02 01:11:35 http://www.openembedded.org/filebrowser/org.openembedded.dev/packages/slugos-init/files Nov 02 02:25:15 [g2]: what was it you wanted to discuss about the AVR based boards **** ENDING LOGGING AT Thu Nov 02 02:59:57 2006