**** BEGIN LOGGING AT Wed Oct 26 02:59:58 2005 Oct 26 08:12:06 dwery: I think we may need to just submit all the patches together, I just realised that one of the ones I submitted yesterday has a header file dependency and we can't really test the patches in isolation. Oct 26 08:36:00 03hrw 07org.openembedded.dev * r99d54dcf... 10/packages/opie-notes/ (opie-notes_0.3.bb opie-notes_0.4.bb): Oct 26 08:36:00 opie-notes: upgraded to 0.4 Oct 26 08:36:00 - this version check does Documents/text/plain exist and create it if not Oct 26 08:55:01 jbowler: what patch was that? Oct 26 09:02:15 25-nslu2-arch-reset (patch to system.h) Oct 26 11:57:42 mm busy. Oct 26 12:11:43 03ccsmart 07org.openembedded.dev * r64c32008... 10/packages/bogofilter/files/volatiles: bogofilter: add write acces for group filter to /var/spool/filter Oct 26 12:40:28 ~convert 119 euros to USD Oct 26 12:47:47 approx. 150 Oct 26 13:08:32 jbowler: you mean the two patches I sent plus the one you sent yesterday? Oct 26 13:10:28 I sent three yesterday, no I mean that it's difficult to send the patches individually because of the interdependencies. Oct 26 13:11:28 If we send the whole collection then it looks like akpm will just put them into -mm automatically - then we have a full working NSLU2 kernel in the mm patchset (at least). Oct 26 13:13:04 can i be annoying and ask why vsftpd will not let users login that were created through the web interface? Oct 26 13:23:07 jbowler: ack. the problem in sending the nslu2 patchset is that nslu2-io.c won;t be accepted... Oct 26 13:23:35 ( i mean the one with the actual led code, can't remember if is -io.c right now) Oct 26 13:23:51 dwery: why not? Oct 26 13:24:09 it doesn't follow kernel coding guidelines Oct 26 13:24:56 stylistic or because of the way it does things? Oct 26 13:25:01 both of them Oct 26 13:25:14 it took me and Jean about three days of work Oct 26 13:25:18 to correct x1205.c Oct 26 13:25:31 to be appropriate for the kernel Oct 26 13:25:52 and it was quite correct from the start. Oct 26 13:27:07 you may want to send a collection of the nslu2 unrelated ones anyway Oct 26 13:27:09 so nslu2-io.c is just the LED driver, right, and the proposal was to put that into drivers/char/... as an independent character driver, why isn't it possible to simply leave the patch for nslu2-io.c out of the set? (I.e. so that everything works but the LEDs) Oct 26 13:27:24 well, it's possible :) Oct 26 13:28:32 That will solve the base problem then - that the board level stuff isn't in the kernel, so submitting board level patches is difficult... Oct 26 13:29:22 should we send the nslu2 and non-nslu2 parts combined? Oct 26 13:30:33 I don't think so - I guess everything board-level could be one patch (just glue the existing ones together), but non-nslu2 stuff should be separate. I'm just saying I believe we should get all we can into the system. Oct 26 13:31:20 ok. i'll give one more review to the nslu2 specific parts and then send them. Oct 26 13:32:02 Then thing here is that so far as I can see the ones already submitted haven't been submitted in the correct way, so akpm has not seen them. Oct 26 13:32:51 Also, I don't see a separate patch for the LED driver - it seems to be included in nslu2-general.patch Oct 26 13:34:24 what's tghe correct way for the ones we sent? Oct 26 13:35:47 Send them to all the mailing lists named in SubmittingPatches (that includes the -developers list), include the right Signed-off-by - probably you and me is adequate 'cause we can assert that the copyright can be passed on, make sure the patches are localised enough not to cause akpm to barf. Oct 26 13:36:54 And make sure the subject line is correct, because I think they are running mail filters so don't even read things if they have the wrong subject line. Oct 26 13:37:48 50-nslu2-arch.patch is ok, but should be combined with the patch for nslu2.h Oct 26 13:38:10 ok. can you do that for the non nslu2 ones? Oct 26 13:39:20 Yes - how about if I reconfig the nslu2-general.patch too (move rtc and -io out). Oct 26 13:40:16 It looks like the RTC should be in the arch-ixp4xx directory, not a separate driver. Oct 26 13:40:56 ok. the rtc will go in drivers/char/ with other rtcs.. I'm working on that Oct 26 13:41:11 i've generalized it Oct 26 13:41:30 Ok, then it needs to be a separate patch anyway if you are changing it. Oct 26 13:41:36 yes Oct 26 13:43:23 So I'll convert nslu2-general into nslu2-arch (add nslu2.h), nslu2-rtc.patch and nslu2-io.patch, bring the CVS directory up to date then submit everything up to and including nslu2-arch (not rtc, not io). Oct 26 13:43:40 After making sure it does actually build and work without those. Oct 26 13:45:31 that would be perfect Oct 26 13:46:09 I can sign off everything !nslu2, I'll need a sign off from you on nslu2-arch when I've got it right ('cause some of your changes are in there.) Oct 26 13:48:33 I'll just re-submit the copy-from patch (with sign off as before) but Ccing it to linux-kernel Oct 26 13:49:08 no problem, I hereby declare you have the right to add a Sign-off by me on all the nslu2 patches :) Oct 26 13:50:20 ok, that helps - it's apparently so that they don't violate the GPL/commercial copyrights (we're just asserting the right to release the code to them) Oct 26 13:51:03 I'll do this after the slugos release to monotone, which should happen in a few minutes... Oct 26 13:51:13 ack Oct 26 13:52:18 I've got a few fixes for the compiler warnings rwhitby-asleep identified too, but they're 'trivial' (by the SubmittingPatches definition) Oct 26 14:11:02 03jbowler 07org.openembedded.dev * r9434b671... 10/ (33 files in 10 dirs): Oct 26 14:11:02 slugos, openslug, ucslugc: move to new slugos base distro in openslug 3.0, ucslugc 3 Oct 26 14:11:02 - all the nslu2-???.conf files are now slugos-???.conf and slugos has been made Oct 26 14:11:02 - the base for both openslug and ucslugc. OpenSlug now enables thumb interwork. Oct 26 14:20:09 03jbowler * 10kernel/2.6.14/ (5 files): Oct 26 14:20:09 Fix the nslu2-arch-reset patch so that it doesn't break kernel builds in Oct 26 14:20:09 the absence of the NSLU2 machine patches. Oct 26 14:20:09 Fix various warning messages. Oct 26 14:20:09 Fix a build break in the -mm1 kernel (not NSLU2 specific). Oct 26 15:31:01 03noodles 07org.openembedded.dev * r42b1c101... 10/packages/ppp/ (ppp-2.4.3/pppoatm-makefile.patch ppp_2.4.3.bb): ppp-2.4.3: Build pppoatm plugin as package ppp-oa. Oct 26 17:11:35 03jbowler 07org.openembedded.dev * ra179fb1d... 10/packages/linux/ (8 files in 2 dirs): Oct 26 17:11:36 nslu2-kernel: split nslu2 patches in 2.6.14-rc5 Oct 26 17:11:36 - the nslu2-arch and nslu2-general patches are now split into nslu2-arch, Oct 26 17:11:36 - with all the board level support, and nslu2- for each of the Oct 26 17:11:36 - separable drivers. This is to make them ready for pushing upstream. Oct 26 17:11:49 03jbowler * 10kernel/2.6.14/ (7 files): Oct 26 17:11:49 Split nslu2-arch and nslu2-general into core board support (now in Oct 26 17:11:49 nslu2-arch) and the individual drivers. Oct 26 17:11:49 Updated the later patches to match 2.6.14-rc5 (line number/date changes) Oct 26 17:13:17 dwery: the checkin above is of the split patches. I've verified the full patch set and the set up to 50-nslu2-arch (+90-ixp4xx-pci-le), the latter boots fine but no LEDs or buzzer (or, I guess, RTC, but that is less obvious). Oct 26 17:14:55 This stuff is ready to go, but I want to make sure rwhitby-away doesn't have see any problems with this approach. What I anticipate is that we will have everything up to (and including) 50-nslu2-arch in the mm patch set almost immediately. Oct 26 17:30:51 03jbowler 07org.openembedded.dev * r5b3b75d6... 10/packages/linux/nslu2-kernel_2.6.14-rc5.bb: nslu2-kernel: bump PR, add back patches erroneously removed for testing in 2.6.14-rc5 Oct 26 17:34:25 jbowler-away, dwery: I fully support the split patchset that you are both collaborating on. Upstream in -mm is a great step towards upstream in Linus' tree. Oct 26 17:34:32 dwery: 30-i2c-x1205.patch is failing on mm1, apparently because at least some part of it is already in mm1. Oct 26 17:35:50 just one requirement: that the full set of patches (split however you want to split them) works for debian kernels. Oct 26 17:36:13 (i.e. we can have it so some of the patches are not applied for the -mm build) Oct 26 17:36:52 Yes, the full set will be unchanged from what we had yesterday - it's just rearranged... Oct 26 17:37:00 bbl, supper Oct 26 18:00:58 jbowler-away: excellent, thanks. Oct 26 18:01:04 back later Oct 26 23:25:57 03jbowler 07org.openembedded.dev * r6cd6b3c1... 10/packages/linux/ (2 files in 2 dirs): nslu2-kernel: add MM kernel to verify patches in 2.6.14-rc5-mm1 Oct 27 01:35:56 03koen 07org.openembedded.dev * r23edc089... 10/packages/gpe-su/gpe-su_0.19.bb: gpe-su: add 0.19 Oct 27 01:45:50 03koen 07org.openembedded.dev * rf2e0bbc6... 10/conf/distro/preferred-gpe-versions-2.7.inc: preferred-gpe-versions-2.7: prefer gpe-su 0.19 Oct 27 02:06:28 Hm, so I want to change a kernel config (I want /proc/config.gz) - do I then edit openembedded/packages/linux/openslug-kernel-2.6.14-rc5/defconfig ? Oct 27 02:33:25 http://www.intel.com/Please-Read-The-BB-File/IPL_ixp400AccessLibrary-2_0.zip is missing Oct 27 02:34:58 but that's ok, I found it Oct 27 02:41:36 geh.. how do I tell "make openslug" that the above archive is already downloaded? **** ENDING LOGGING AT Thu Oct 27 02:59:56 2005