**** BEGIN LOGGING AT Sat Jun 18 23:59:56 2005 Jun 19 14:11:46 [g2]: I'm pretty satisfied with 2.6.12 - seems to work fine with glibc and uclibc (flash, nfs and disk root), how do you feel about me checking it in to the default build? Jun 19 14:13:51 I'd feel better if serial boot messages worked Jun 19 14:14:12 RP said they don't have this issue on zaurus Jun 19 14:16:16 The messages are in the syslog, and the serial works, so it's some kind of hookup problem Jun 19 14:16:30 I gree it is minor Jun 19 14:16:33 agree Jun 19 14:17:42 openzaurus is also using the MM1 kernel (at least that's the only thing which is checked in) Jun 19 14:17:59 hmmmmm Jun 19 14:18:20 There's linux-epia_2.6.12.bb Jun 19 14:19:08 well epia is x86 Jun 19 14:20:52 <[g2]> jbowler-away, I've got a 2.6.12 mostly ready to go also Jun 19 14:21:18 how does it differ from jbowler-away's ? Jun 19 14:21:21 <[g2]> I'm writing something up on the wiki right now for you guys on my thoughts Jun 19 14:21:43 <[g2]> Well I ported the 2.6.11.2 to a 2.6.12 in bb Jun 19 14:21:53 <[g2]> It looked like he just had a couple patch files Jun 19 14:22:02 <[g2]> which may be a better way to go Jun 19 14:22:28 <[g2]> I didn't get a chance to see exactly what he did Jun 19 14:22:41 Hum, on collie CONFIG_PRINTK=y is not set, but it's not IXP4XX Jun 19 14:22:58 <[g2]> for the serial ? Jun 19 14:23:15 <[g2]> I'd like to fix the serial in the kernel before the release Jun 19 14:23:35 No, it's just a new CONFIG option in the 'minimise the size of the kernel' set Jun 19 14:23:59 <[g2]> ok. Jun 19 14:24:07 <[g2]> So serial is still an open issue Jun 19 14:24:30 [g2]: the serial itself is not a problem, the problem is output to the serial from within the kernel (as opposed to applications) Jun 19 14:26:33 <[g2]> jbowler-away, nod. that's what I mean Jun 19 14:26:58 <[g2]> if it's broken in the kernel then we just need to fix it Jun 19 14:27:30 [g2]: can you try my latest xscale-reset.patch on APEX? This still locks up RedBoot, but it might work with APEX (the change is in both nslu2-kernel_2.6.12 and openslug-kernel_2.6.11.2) Jun 19 14:28:05 serial: do you see the problem with your 2.6.12 (rc6?) Jun 19 14:29:26 <[g2]> I saw it in rc4/rc5 and I think the release Jun 19 14:31:11 Hum, in pxa-serial-hack.patch: pxa-serial-hack.patch: .cons = SERIAL8250_CONSOLE, Jun 19 14:31:51 And not a single one of those defconfigs have CONFIG_SERIAL_8250 built in to the kernel Jun 19 14:37:37 jacques: the zaurus stuff seems to use a non-8250 serial driver and select that as the console. Jun 19 14:39:17 <[g2]> jbowler-away, jacques take a peek at http://www.nslu2-linux.org/wiki/OpenSlug/OpenSlugChangeLog Jun 19 14:40:47 <[g2]> I should have liked to the known problems page from there Jun 19 14:40:59 <[g2]> I'll fix that next time I edit it Jun 19 14:41:03 <[g2]> rsn Jun 19 14:41:26 That looks good. Jun 19 14:42:51 <[g2]> jbowler-away, can you add some of the stuff you did last week under Week 24 ? Jun 19 14:44:27 I'm inclined to drop the shutdown -r problem from the release criteria for openslug-2.0 - it's the only remaining issue and there are a significant number of people having problems which are solved between 1.12 and 2.0 Jun 19 14:44:44 <[g2]> I'm fine with that Jun 19 14:45:05 Ok, then we should make a release. Jun 19 14:45:43 <[g2]> let's just fix the kernel serial issue, switch to 2.6.12, glibc 2.3.5 and test for a couple days and release that as 2.0 Jun 19 14:46:00 Those weren't on the release criteria... Jun 19 14:47:06 <[g2]> how do you guys like the name "solstice' for the release ? Jun 19 14:47:51 <[g2]> jbowler-away, do you want to wait for 2.6.12 and 2.3.5 for a 2.1 release ? Jun 19 14:47:57 <[g2]> dinner calls Jun 19 14:48:01 <[g2]> bbiab Jun 19 14:48:02 Yes Jun 19 14:48:03 <[g2]> sorry Jun 19 14:48:13 <[g2]> ok I'm fine with that Jun 19 14:48:26 <[g2]> I've been tagging some local releases Jun 19 14:48:46 Ok, what's the tag for 2.0? I.e. what name? Jun 19 14:51:55 dang, ipkg_0.99.151.bb got in before I could tag it... Jun 19 14:55:00 I'd be happy if we could make the noirqdebug easily configurable on build - I still like to see them Jun 19 14:55:17 easily == in local.conf Jun 19 14:55:56 I vote for "CountryTime" Jun 19 14:58:10 jacques: do you know where the 'issue' and 'issue.net' files get generated? Jun 19 14:59:16 hmm, not offhand - I've never looked Jun 19 14:59:44 Some magic in base-files apparently... Jun 19 15:00:08 sounds right Jun 19 15:00:17 Yes, it's in the build step. Jun 19 15:00:40 Just DISTRO_VERSION. Jun 19 15:03:53 Ok, it's in changeset 1.3580 Jun 19 15:09:48 bk pull, then: bk clone -rOpenSlug-2.0-beta Jun 19 15:38:04 <[g2]-dinner> jbowler-away, actually there's a hard link options that saves a bunch of space Jun 19 15:39:41 good to see you guys went straight to 2.0 - My plan to convert the world to sensible version incrementing is working :-) Jun 19 15:39:52 <[g2]-dinner> :0 Jun 19 15:39:54 <[g2]-dinner> :) Jun 19 15:42:46 [g2]: I know, I forgot it. "bk relink " fixes the problem. Jun 19 15:43:20 I've got openslug an osuclibc builds going now (with a local.conf copied from the SVN template) Jun 19 15:43:26 <[g2]> if you've got the disk space it doesn't matter Jun 19 15:43:42 jbowler-away: if you're adventerous enough to create a script to update the svn repo, please feel free :-) Jun 19 15:45:33 I will, I almost had one before. Jun 19 15:45:58 I'm going to re-download too - I haven't tested for missing downloads for a couple of weeks. Jun 19 15:48:32 bitbake revision is 265 Jun 19 15:50:08 jbowler-away: I might not be able to test it for a couple of days. I have Treo650 firmware and WL500g firmware to update first (both of which are production devices). Jun 19 15:51:30 I'd wait until it is in the SVN repo (at least the trunk) anyway. My tests now are to ensure that the stuff in bk is sane from a build point of view. Jun 19 15:51:58 Since we have a bk tag we're isolated from oe changes unless something major is required. Jun 19 15:52:07 <[g2]> nod. Jun 19 15:54:32 <[g2]> jbowler-away, in the future we may want to use stuff like -rc1 for the tags Jun 19 15:55:02 [g2]: please don't Jun 19 15:55:08 I figured it was an rc because it is in bk... Jun 19 15:55:15 if it changes, just bump the version again Jun 19 15:55:39 * rwhitby-away never understood why people felt compelled to release a version with a .0 on the end Jun 19 15:55:55 The bk tag can be moved, it's only when the SVN release occurs that stuff gets frozen. Jun 19 15:56:01 especially cause I usually don't use something with a .0 on the end :-) Jun 19 15:56:26 increment early, and increment often Jun 19 15:56:47 <[g2]> to me the point is tracking a specific snapshot and using a somewhat understandable name Jun 19 15:57:09 <[g2]> OpenSlug-X.Y-Beta-rcN makes total sense to me Jun 19 15:57:21 <[g2]> but I may just be wierd :) Jun 19 15:57:45 [g2]: it's just a number. everything is a release candidate until something is actually released. and then you know it is released cause it is under the svn releases branch Jun 19 15:58:31 <[g2]> rwhitby-away, you're assuming that the SVN branch is the master then Jun 19 15:58:55 no, I'm saying that the SVN releases branch is the master for releases Jun 19 15:59:04 bk is the master for non-releases Jun 19 15:59:31 <[g2]> right and I'm saying a tag in bk should produce the identical files for a given release Jun 19 15:59:54 yes, and I fully agree. that's why I say to increment the version if something changes after you have tagged. Jun 19 15:59:57 <[g2]> so svn OpenSlug 2.0 -beta release == bk tag ...... Jun 19 16:00:04 fully agree Jun 19 16:00:38 <[g2]> so the only difference we have is you want to migrate X.Y number and I want to migrate rc-x number Jun 19 16:00:38 and if something changes, it will just be 2.1 instead of 2.0 Jun 19 16:01:10 yep. the reason why I don't like rc-1 is that it is putting forward a commitment that you may not be able to keep Jun 19 16:01:22 <[g2]> the problem with that is by targeting functionality with a given release then it's out of sync with the wiki pages Jun 19 16:01:46 only target number.X, never number.number Jun 19 16:01:50 <[g2]> the "c" is just a candidate not a commitment Jun 19 16:02:41 <[g2]> personally, I'm on the 1-4 major releases a year plan Jun 19 16:02:47 <[g2]> more like 1 to 2 Jun 19 16:02:57 <[g2]> so I'm all up for using minor numbers Jun 19 16:03:11 <[g2]> but that's just my preference Jun 19 16:03:28 why are people so afraid of incrementing the major number? what's wrong with OpenSlug 3456.24 ? Jun 19 16:03:39 <[g2]> I care more about tracking targets which I think we're beginning to do Jun 19 16:03:59 yep, and incrementing the major version more often makes that easier. Jun 19 16:04:08 foo functionality is targeted for 4.x or 5.x Jun 19 16:04:17 bar functionality won't be in until 6.x Jun 19 16:04:42 then you have the freedom to release lots of 5.x, 5.y, 5.z versions to get that foo functionality right before the release Jun 19 16:04:58 (sorry, not the first release in that sentence should have been tag) Jun 19 16:05:13 s/not // Jun 19 16:06:07 target N.x releases (and don't specify the x). then use the .x to identify intermediate checkpoints so that the alpha testers or people building from source can refer to a specific version for reporting bugs. Jun 19 16:06:43 <[g2]> to me... (just me) there are two ways to target releases (one by functionality, one by date) Jun 19 16:07:02 by date doesn't make sense to me for a volunteer project Jun 19 16:07:24 I'm not going to be held to a date unless I am paid :-) Jun 19 16:07:31 <[g2]> tell that to gentoo 2005.0, 2005.1, ... Jun 19 16:07:49 <[g2]> a date can just be a cutoff point Jun 19 16:08:26 but what's the point? you should just release a new major version when new functionality is there, and let the users decide whether they want to update to it or not Jun 19 16:08:42 <[g2]> easy the point is churn Jun 19 16:08:53 if it's too frequent for them, then they just skip versions Jun 19 16:09:02 no-one is forcing them to upgrade Jun 19 16:10:55 anyway, it looks like we're not going to reach a consensus on this one ... Jun 19 16:11:20 <[g2]> speaking of consensus.... did you see the native compile how to ? Jun 19 16:11:37 so you know my strong preference, and as the OpenSlug release managers you can choose to ignore it :-) Jun 19 16:11:47 nope, didn't see that Jun 19 16:12:21 <[g2]> http://www.nslu2-linux.org/wiki/HowTo/OpenSlugNativeCompileEnvironment Jun 19 16:13:08 <[g2]> we do need to think about package management a little if we're going to support the ipkg releases which was what your point was Jun 19 16:16:14 did we prove that a fatslug cannot run bitbake? Jun 19 16:16:30 <[g2]> it probably can Jun 19 16:16:36 <[g2]> but I don't think it should run bitbake Jun 19 16:17:10 <[g2]> whole point is stuff than *can't* be built with bitbake needs to be natively compiled Jun 19 16:17:10 so 1) or 3) then? Jun 19 16:17:56 good point - I was thinking of stuff that can be built native with bitbake, but won't build cross Jun 19 16:18:31 but you're right - there may be stuff that bitbake plain can't even build native. but i haven't come across anything like that yet Jun 19 16:18:41 cross yes, native no. Jun 19 16:19:27 <[g2]> the only (real) reason for natvie is because it doesn't build cross easily or properly Jun 19 16:19:39 (or at least, yes I have see stuff in bitbake that won't build cross for us, but I haven't seen anything yet which wouldn't build native, and which taking it out of the bitbake environment would make it any easier to build native) Jun 19 16:20:13 <[g2]> right Jun 19 16:20:18 agreed. the only reason for native is when it doesn't build cross Jun 19 16:20:26 <[g2]> right Jun 19 16:20:32 <[g2]> or it's much easier Jun 19 16:20:45 but what are you thinking of which won't build native under bitbake (as bitbake does not imply cross or native) Jun 19 16:21:13 (we just happen to only be using it cross at the moment in OpenSlug) Jun 19 16:21:42 <[g2]> like apache 2.x Jun 19 16:21:52 <[g2]> it's just not in OE Jun 19 16:22:29 <[g2]> and interesting idea is to run bitbake *just* for the packaging natively Jun 19 16:22:47 right, but it's easy to add apache 2.x to bitbake and compile it natively Jun 19 16:23:24 bitbake doesn't imply the compiler - you can run it either with cross compiler or native compiler Jun 19 16:23:53 adding something to bitbake for native compilation is as easy as wrapping a build shell script around an existing apache makefile Jun 19 16:24:20 (actually, it's adding something to OE, not bitbake) Jun 19 16:24:21 <[g2]> On the 425 dev board on loan with 256MB and 533Mhz running bitbake makes sense, but on the slug it doesn't to me unless just using it for packaging and some config Jun 19 16:25:14 [g2]: I don't understand what you think bitbake does other than just provide a compile script for the normal native compilation process to use, and then package up the result of the normal native compilation process? Jun 19 16:25:33 (and all the memory overhead of dependency tracking and stuff) Jun 19 16:25:46 anyway, gotta go. Jun 19 16:25:48 back later Jun 19 16:25:51 <[g2]> precisely the point "all the memory overhead" Jun 19 16:26:10 ok, I can agree with that. Jun 19 16:26:16 you suffer the memory overhead whatever you do Jun 19 16:26:40 If bitbake runs at all it can do everything - in fact packaging is the most python intensive part. Jun 19 16:26:55 <[g2]> bitbake and the 550ish bb's for OpenSlug is just not light-weight Jun 19 16:27:10 It's 135 for a full openslug build Jun 19 16:27:32 <[g2]> I've go 500+ for openslug openslug-packages unslung Jun 19 16:28:05 <[g2]> s/go/got Jun 19 16:29:09 <[g2]> for native package creation we're trading normal environments versus a custom build system Jun 19 16:31:10 Ok, the exact number of .bb files bitbake has to parse to build openslug-packages with uclibc is 124. Jun 19 16:33:38 For a complete, minimal, build system able to build a complete root file system (no kernel) bitbake needs to parse 22 bb files. Jun 19 16:34:06 That includes a native gcc and native tools (binutils, autoconf etc) Jun 19 16:36:04 Stopping the tool build, which is clearly highly desireable, requires some kind of hackery, but I suspect PREFERRED_PROVIDERS could do it (i.e. fake out the provider for gcc-cross). Jun 19 16:40:49 [g2]: the openslug-native distro would explicitly list only the native packages it was building in the BBFILES, so it wouldn't have any additional packages overhead Jun 19 16:41:11 jbowler-away: I already use an external toolchain for wl500g firmware builds. Jun 19 16:41:26 so the number of .bb files could be as small as 1 Jun 19 16:54:43 <[g2]> so given a native tool chain install, we should be able to run an apache / php bb file natively and it'd only be like 3 .bb's Jun 19 16:55:01 <[g2]> libxm2, php5, and apache right ? Jun 19 16:56:24 <[g2]> ok 4 cause python didn't fully build cross Jun 19 17:05:59 [g2]-in-and-out: that's my working assumption to be tested :-) Jun 19 17:25:12 <[g2]-in-and-out> rwhitby-away, if it's only a handful of bb files then that would be a good assumption if it works Jun 19 17:25:51 <[g2]-in-and-out> an important thing to do is get the python cross fully fixed then ppl wouldn't have to build that natively Jun 19 17:26:24 I was wondering that chicken and egg problem earlier too Jun 19 17:26:32 but I gave up on thinking. Jun 19 17:27:33 <[g2]-in-and-out> python cross may work well enough for bitbake but I haven't tried Jun 19 17:27:45 <[g2]-in-and-out> it wasn't good enough for Zope3 and schoolbell Jun 19 23:50:25 jacques: bin/sh is busybox, which could be static, but I suspect the problem is usr/sbin/chroot, which is also busybox Jun 19 23:51:31 I'm trying to exec the initrd one after pivot_root - and it needs the (in this case) uclibc shared libraries. Jun 19 23:51:52 aha Jun 19 23:52:57 I suspect I should try the new root one first - when I did this originally it was in 'bootbox' and that had a static busybox. Jun 19 23:54:04 Ok, this doesn't block OpenSlug-2.0 - hardly anyone will try to boot into a rootfs without the original .so's Jun 19 23:54:32 no, I wouldn't consider it a blocker at all Jun 19 23:59:51 exec'ing the new rootfs one fixes the problem **** ENDING LOGGING AT Sun Jun 19 23:59:56 2005