**** BEGIN LOGGING AT Thu Dec 14 02:59:57 2006 Dec 14 05:23:27 03bzhou * r4674 10optware/trunk/ (make/cherokee.mk sources/cherokee/old_uclibc_tm_gmtoff.patch): cherokee: patch to workaround old uclibc tm_gmtoff problem for wl500g Dec 14 06:16:21 Oleg now wants to depricate "wl500g" and point users to "oleg" feed. Dec 14 06:32:10 oleo_: so we're providing both - and he can include whichever he wants in the firmware he releases :-) Dec 14 06:33:07 He realised that uClibc 0.9.19 is really old :) and want to switch. Dec 14 06:34:13 No I am trying to upgrade toolchain a little bit and maybe a little bit more to see if some issues were fixed since my summer work on it Dec 14 06:34:22 s/no/Now/ Dec 14 06:43:42 But before change to "oleg" I think I would be nice to upgrade a bit. Dec 14 06:45:14 This means upgrading uClibc from 0.9.28 to 0.9.29 whic is not official yet! Dec 14 06:45:50 Right now I a mtrying just to aling hunks on toolchain. uClibc will come later. Dec 14 06:47:52 yeah, it would be great if we can discontinue wl500g feed, uclibc too old, lots of special cases Dec 14 06:48:50 I agree. It will look nicer. Dec 14 06:49:31 excellent. Let's plan to do that then. Dec 14 06:51:51 Toolchain upgrade will be done today if time permits. This will not invalidate uClibc feeds. More subtla change is uClibc upgrade. Maybe over weekend. Dec 14 06:52:09 oleo_: the latest r4570 scripts/optware-autoclean.pl handles autoclean of subpackages correctly Dec 14 06:52:28 that should address the issue you raised a while ago Dec 14 06:53:06 rwhitby: by the way, a while ago we were talking about how to keep kernel configs of different targets in sync, right? Dec 14 06:53:14 yep Dec 14 06:53:18 rwhitby: for openwrt i have written a small utility now that can make working with config files easier Dec 14 06:53:19 I would like to change package name "uclibc" to "libuclibc" to prevent package name clash with "OpwnWRT" Dec 14 06:53:37 oleo_: ok Dec 14 06:53:49 nbd: is it in the openwrt svn? Dec 14 06:54:08 yes, but it's undocumented at the moment Dec 14 06:54:45 it's just a small utility that can 'add' and 'subtract' config files, and also list all variables that were changed between two config files Dec 14 06:54:53 ignoring all variables that no longer appear Dec 14 06:55:12 so we can keep a common template for all architectures and a smaller diff for the actual target Dec 14 06:55:33 and the useful part of this is that you can reverse the process and generate this diff from a kernel config file and the template Dec 14 06:55:50 scripts/config.pl ? Dec 14 06:55:52 so we can add a wrapper for make menuconfig in the future Dec 14 06:55:53 yes Dec 14 06:56:34 it's still a bit rough, but it has helped me a lot with the upgrade to linux 2.6.19 that i'm currently working on Dec 14 06:57:25 nbd: are you working on openwrt on ixp4xx? Dec 14 06:57:41 not at the moment Dec 14 06:57:44 but i do want to work on it Dec 14 06:58:17 it would be interesting to get openwrt running on nslu2 and nas100d (which has wireless and hard disk) Dec 14 06:58:26 yeah Dec 14 06:58:38 nslu2 with a zd1211 usb wireless key plugged in Dec 14 06:58:59 i think kaloz will do most of the work on maintaining our ixp4xx port Dec 14 06:59:00 I can test and help develop on both those platforms. Dec 14 06:59:10 great Dec 14 07:01:30 this kernel upgrade really is a bit of work Dec 14 07:01:35 lots of stuff changed between 2.6.17 and 2.6.19 Dec 14 07:17:09 zd1211rw (the in-kernel driver) might not work on armeb Dec 14 07:17:15 should work on armel though Dec 14 07:39:34 03bzhou * r4675 10optware/trunk/ (Makefile make/libmpeg2.mk): added and promoted libmpeg2 Dec 14 09:55:05 does etch beep when it finishes starting? Dec 14 09:56:29 I've reimaged my slug for the 2nd time today and it never seems to get a network connection after doing the debinstall Dec 14 09:57:03 drive thrashes for a bit then there is nothing but the ethernet light flickering a bit Dec 14 10:15:17 so much for debian. retry with slugos Dec 14 11:05:32 how long do you wait for it to boot? Dec 14 11:15:53 40 mins twice Dec 14 11:18:56 and it never touched /var/log even after turning on logging Dec 14 12:09:54 I need to rename uclibc package to a) libuclibc b) optuclibc c) opt-uclibc Dec 14 12:10:04 Any suggestions? Dec 14 12:40:01 oleo: c Dec 14 12:40:30 makes it clearer that it is a flavour Dec 14 12:41:05 placid_ , tnx Also mine favorite. Dec 14 12:41:47 oleo: anytime. I like doing this really technical stuff 8') Dec 14 12:42:18 I decided to bite the bullet and upgrade from unslung to debian yesterday Dec 14 12:43:24 di never came back after reboot and after wading through slugos/le install I seem to be in the same situation Dec 14 12:43:45 although the status light is slowly blinking orange rather than solid Dec 14 12:44:44 I used tune2fs to turnoff fsck but I wondering whether it is doing it anyway because it had already started Dec 14 12:45:11 ah. gunna leave it for 8 hours Dec 14 12:45:45 I am using wl500g Deluxe. The only thing that bothers me is poor USB performance. Dec 14 15:08:52 03blaster8 * r611 10kernel/trunk/patches/2.6.19/ (00-linux-2.6.19.1.patch series): Update to 2.6.19.1 Dec 14 15:15:10 03blaster8 * r612 10kernel/trunk/ (53 files in 3 dirs): Add broken 2.6.20-rc1, see updated README file Dec 14 15:57:16 03bzhou * r4676 10optware/trunk/make/nginx.mk: nginx: 0.5.0 -> 0.5.3 Dec 14 16:14:19 Does anyone know how I can write a new kernel to flash from debian? Just use dd? Dec 14 17:41:37 03blaster8 * r613 10kernel/trunk/ (9 files in 3 dirs): Clean up VT6421 PATA Support Dec 14 18:09:58 03blaster8 * r614 10kernel/trunk/ (4 files in 2 dirs): Update to 2.6.18.5 Dec 14 20:01:10 ck Dec 14 20:03:53 NAiL: there is a "flash-kernel" script Dec 14 20:04:24 I wish there was a "work after install" script Dec 14 20:04:45 have spent three days trying to get a flavour of debian running on my slug Dec 14 20:04:45 placid_: you're gonna need a serial port Dec 14 20:04:59 other possibility is a hung RTC Dec 14 20:05:09 it appears to boot, the drive thrashs for a while then nothing Dec 14 20:05:14 tried removing the battery temporarily? Dec 14 20:05:19 no Dec 14 20:05:24 that would be the fsck cause the time is way out Dec 14 20:05:41 hmm ok Dec 14 20:06:06 take out battery for a minute, then try reinstalling debian, reformatting the disk. Dec 14 20:06:13 I've just left it for 8 hours so I would have thought fsck would be finished and I used tune2fs to turn off check at boot Dec 14 20:06:28 datestamps on files don't look too bad Dec 14 20:06:45 but at this point I'll try anything! Dec 14 20:06:46 when the RTC hung on mine, it fsck's on every one of three boots (for different reasons) Dec 14 20:06:59 but a serial port would tell you for certain Dec 14 20:07:04 k Dec 14 20:08:23 the light appears to be cycling from orange to red back to black Dec 14 20:10:59 rwhitby: I've flashed it with dd ;) Dec 14 20:11:31 are you using rc1? Dec 14 20:11:33 on nslu2? Dec 14 20:11:55 if so, then dd of the kernel won't work due to the skip region required Dec 14 20:12:17 me? Dec 14 20:12:18 No, I Dec 14 20:12:27 I'm trying to get my n2100 working Dec 14 20:12:35 I'm having problems getting the network up Dec 14 20:12:40 the rest works like a charm :-D Dec 14 20:15:50 dd will be fine then Dec 14 20:18:35 03rwhitby * r81 10debian/trunk/patches/kernel/2.6.19/ (nas100d-support.patch series): Patches accepted upstream Dec 14 20:50:01 rwhitby: as a fellow aussie, which serial mod did you find easiest Dec 14 20:51:16 placid_: the usb phone cable Dec 14 20:51:38 03blaster8 * r615 10kernel/trunk/patches/2.6.20/ (5 files in 2 dirs): Update 2.6.20-rc1 - compiles with no ixp_npe (& dsm-g600/fsg-3) support Dec 14 21:01:52 03rwhitby * r82 10debian/trunk/Makefile: Fixed | -> || in Makefile Dec 14 21:02:41 03blaster8 * r616 10kernel/trunk/patches/2.6.20/defconfig: Update 2.6.20-rc1 defconfig Dec 14 22:16:45 03osas * r4677 10optware/trunk/make/asterisk-gui.mk: asterisk-gui: gui interface for asterisk_1.4 Dec 14 22:18:31 03osas * r4678 10optware/trunk/Makefile: asterisk-gui: ready for testing Dec 15 00:05:34 osas: could you added svn rev to asterisk-gui version? Dec 15 00:08:12 it is there: ASTERISK_GUI_SVN_REV=166 Dec 15 00:08:35 or do you want it to be exposed via the package name? Dec 15 00:09:29 I expect to move away from the SVN once the 1.4 get's out of beta Dec 15 00:09:59 I want to add a new asterisk package: asterisk-beta Dec 15 00:11:17 for 1.4-beta Dec 15 00:11:46 once 1.4 gets out of beta, we can remove the beta package and merge it into official asterisk Dec 15 00:12:15 like this, ppl can use either official 1.2 asterisk or beta 1.4 Dec 15 00:44:49 osas: i prefer something like 0.0.0svn166 Dec 15 00:45:53 I can do that Dec 15 00:46:12 I would like to create a new asterisk package: asterisk-beta Dec 15 00:46:21 to add asterisk-beta, we need to make sure the package conflicts with asterisk Dec 15 00:46:34 this will conflict with existing asterisk and asterisk-sounds Dec 15 00:46:44 or to make sure the files are non-overlapping Dec 15 00:47:00 and ppl can use either asterisk or asterisk-beta Dec 15 00:47:07 ideally we just want to maintain 1 asterisk Dec 15 00:47:15 in the feed Dec 15 00:47:25 asterisk-gui does not interfere with the official asterisk Dec 15 00:47:36 i'm fine if you check in an asterisk-beta.mk in optware svn Dec 15 00:47:46 once 1.4 gets out of beta, asterisk-beta will merge into asterisk Dec 15 00:48:18 but i have some concern regarding having both asterisk and asterisk-beta in the feed Dec 15 00:48:51 and since asterisk-gui is in beta to, I would like to keep it as is (and migrate out of svn to wget once it is becoming official) Dec 15 00:49:02 what kind of concerns? Dec 15 00:50:04 once 1.4 gets out of beta, we will have only two packages: asterisk and asterisk-gui Dec 15 00:50:19 today we have asterisk and asterisk-sounds Dec 15 00:50:19 beta does not belong in a package name Dec 15 00:50:27 I agree Dec 15 00:51:02 but how should I differenciate between the 1.2 and 1.4-beta without breaking existing 1.2 systems? Dec 15 00:51:10 asterisk14 is a more appropriate package name Dec 15 00:51:45 I see ... Dec 15 00:51:48 also ipkg is not good at handling package renaming Dec 15 00:51:58 well, do we want to maintain a 1.2 and a 1.4 branch? Dec 15 00:52:58 it won't be a rename (asterisk-beta will be removed and asterisk will be upgraded to official 1.4) Dec 15 00:53:25 unless we want to maintain 1.2 and create a separate package for 1.4 Dec 15 00:54:12 I'm thinking that some users may want to stay with 1.2 (stability) for a while before switching to an official 1.4 Dec 15 00:54:41 I was about to send an e-mail to the list to gather more input ... Dec 15 00:54:44 in that case, if some one is willing to maintain both ... Dec 15 00:55:04 we should have asterisk12 and asterisk14 Dec 15 00:55:05 I don't want to break something :) Dec 15 00:55:45 i'm faced similar situations before, in postgresql (8.0 -> 8.1) and python (2.4 -> 2.5) Dec 15 00:56:00 I see Dec 15 00:56:19 in the case of postgresql, i decided to force upgrade to 8.1 Dec 15 00:56:29 * osas just finished validating the asterisk-betab package :p Dec 15 00:56:34 and in the case of python, i now maintain both 2.4 and 2.5 Dec 15 00:56:56 I think it make sense to maintain both 1.2 and 1.4 Dec 15 00:57:14 right now, 1.2 => asterisk and asterisk-sounds Dec 15 00:57:21 then let's do that Dec 15 00:57:38 1.4 => asterisk14 and asterisk-gui Dec 15 00:57:46 sounds good Dec 15 00:57:58 I don't like asterisk14 :p Dec 15 00:58:05 any idea for another name? Dec 15 00:58:31 it will look odd: asterisk14-1.4.0 Dec 15 00:58:55 only if the stable feed and unstable feed are different Dec 15 00:59:36 but again, we need to introduce a process for promoting packages from unstable to stabel Dec 15 01:00:15 life will not always be perfect Dec 15 01:00:24 well, I gues that at some point in time, both will be in stabel Dec 15 01:00:39 re: life will not always be perfect: true :) Dec 15 01:00:55 i know you don't like the name, but can you live with it? Dec 15 01:01:05 just like i live with python25-2.5.0 ? Dec 15 01:01:06 I can Dec 15 01:01:37 I hope that I won't need to rename the package again Dec 15 01:01:52 cuz right now i have asterisk-beta ready :p Dec 15 01:02:09 and it takes some time to compile and validate the build :p Dec 15 01:02:23 I will go with asterisk14 Dec 15 01:02:38 should I rename asterisk-gui to asterisk14-gui? Dec 15 01:02:38 thank you Dec 15 01:02:41 np Dec 15 01:03:03 just to avoid confusions (1.2 vs 1.4) Dec 15 01:03:12 do what you think is appropriate Dec 15 01:03:33 i'm for renaming to asterisk14-gui Dec 15 01:03:39 today we have the asterisk for 1.2 Dec 15 01:03:50 the "brand" name Dec 15 01:03:56 I think it make sense Dec 15 01:03:59 ok Dec 15 01:04:03 I will do it Dec 15 01:04:06 cool Dec 15 01:04:20 I don't know what will be in 1.6 :p Dec 15 01:04:36 thx for your input :) Dec 15 01:04:42 it's fine in terms of build, i'll promote it as soon as you're ready Dec 15 01:04:48 oh ... so back to gui Dec 15 01:05:04 do you realy want the svn rev in the name? Dec 15 01:05:22 I expect to have a separate tar ball once it is stable Dec 15 01:05:27 to be clear, svn rev is part of the VERSION Dec 15 01:05:30 like for sounds in 1.2 Dec 15 01:05:58 what I'm saying is that today there's no tarball for it Dec 15 01:06:12 but I expect to have one once it becomes stable Dec 15 01:06:32 and in that case, we will need to remove the svn from the package name Dec 15 01:06:43 look at make/template-cvs.mk, when we don't have tarball, we should have cvs-date or svn-rev in _VERSION Dec 15 01:07:34 yeah, there were a couple of packages that went thru svn -> tarball process Dec 15 01:08:11 so you are sayint to update _only_ the ASTERISK_GUI_VERSION from 0.0.0 to svn166? Dec 15 01:08:38 the autoclean script won't know a package has changed without _VERSION change Dec 15 01:08:38 let's summarize: Dec 15 01:08:55 asterisk and asterisk-sounds stay where they are Dec 15 01:09:21 for 1.4, let's create asterisk14 and asterisk14-gui Dec 15 01:09:39 asterisk14-gui will have svn rev in ASTERISK_GUI_VERSION Dec 15 01:09:50 until it has a released tarball Dec 15 01:10:02 ok Dec 15 01:10:55 I will do that Dec 15 01:11:39 and I will remove asterisk-gui Dec 15 01:12:25 yes, and we'll deal with 1.6 when the time arrives Dec 15 01:13:07 maybe at that time we can discontinue the support of asterisk 1.2 Dec 15 01:14:10 heh Dec 15 01:14:31 thx again for your input Dec 15 01:15:20 the users will thank you for maintaining two versions Dec 15 01:17:14 once the procedure is implemented, it should be pretty easy to maintain it **** ENDING LOGGING AT Fri Dec 15 02:59:57 2006