**** BEGIN LOGGING AT Tue Jan 03 02:59:59 2006 Jan 03 03:11:50 morning all Jan 03 03:12:17 hi Dirk Jan 03 03:12:41 hey marcin Jan 03 03:13:37 RP: ping Jan 03 03:22:07 morning all Jan 03 03:23:38 do13_: pong Jan 03 03:25:04 RP: morning. I have a small patch for sharpsl_pm. http://www.do13.de/oz/temp/sharpsl_pm-do-r0.patch Jan 03 03:26:59 do13_: That looks good to me. Does this mean you're making progress with tosa pm/charging? Jan 03 03:27:35 RP: First steps. I hope this doesn't breaks corgi and friends. Jan 03 03:29:22 do13_: It looks sane enough to me and I'd think it will be fine. The code is a lot less of a minefield than it once was : Jan 03 03:29:24 :) Jan 03 03:29:36 :) Jan 03 03:30:23 do13_: Does tosa's battery levels actually differ for the bl and none bl case? Jan 03 03:30:48 I know the c7x0 had code for this but the actual data structures had the same values so I ended up merging them... Jan 03 03:31:02 RP: Yep. It's different. also on poodle Jan 03 03:31:24 RP: did you find what is wrong with matchbox-wm_svn ? i didn't Jan 03 03:31:30 RP: SHARPSL_CHARGE_ON_VOLT and others are different on tosa, I'll move these into sharpsl_pm.machinfo Jan 03 03:32:42 do13_: ok, that sounds good. Does tosa use a different battery out of interest? Jan 03 03:33:21 I know its the same battery in the 760, 1000, 3100 and 3000 and the 700 uses a smaller one that seems to behave the same way... (not sure what the 750 has) Jan 03 03:34:27 RP: tosa has another battery and another ADC (maybe other Vref) so the values are different Jan 03 03:34:32 the 750 has a 950mAh flat battery. I think the same as 700 Jan 03 03:34:56 5500/700/750 has 950mAh, 5600/760/860 has 1700mAh iirc Jan 03 03:34:58 alan|home: I'm afraid I never understood you svn issue Jan 03 03:35:11 moin Jan 03 03:35:14 03rpurdie 07org.oe.dev * rf7f53924... 10/packages/linux/linux-openzaurus_2.6.14+2.6.15-rc7.bb: linux-oz-2.6: Fix cxx00 MMC/SD bug where card could lock the system. Tweak LED patches, split cxx00 udc patches, fix minor pxa2xx pcmcia memory leak. Jan 03 03:35:19 03jbowler 07org.oe.dev * r97eb37ff... 10/packages/binutils/ (3 files): binutils: change do_stage to use autotools_stage_all in binutils.inc Jan 03 03:35:24 03jbowler 07org.oe.dev * rb10c7a50... 10/packages/glib-2.0/ (glib-2.0-native_2.6.5.bb glib-2.0_2.8.2.bb): Jan 03 03:35:24 glib: change to use autotools_stage_all in native 2.6.5 and 2.8.2 Jan 03 03:35:24 - do_stage calls autotools_stage_all, additional files still have Jan 03 03:35:24 - to be staged (most significantly glibconfig.h) Jan 03 03:35:29 03jbowler 07org.oe.dev * r7170376c... 10/packages/jpeg/ (jpeg-6b/install.patch jpeg-native_6b.bb jpeg_6b.bb): Jan 03 03:35:29 jpeg: change to use autotools_stage_all in 6b Jan 03 03:35:29 - native and cross changed. do_install is no longer required as Jan 03 03:35:31 - a patch has been added to fix the failure of the Makefile install Jan 03 03:35:33 - to create the target directory. Jan 03 03:35:35 03jbowler 07org.oe.dev * r2f06f49d... 10/packages/bluez/bluez-libs_2.21.bb: bluez-libs: change do_stage to use autotools_stage_all in 2.21 Jan 03 03:35:40 03jbowler 07org.oe.dev * rcc38fee3... 10/packages/cyrus-sasl/cyrus-sasl_2.1.19.bb: cyrus-sasl: change do_stage to use autotools_stage_all in 2.1.19 Jan 03 03:35:44 03jbowler 07org.oe.dev * r97dc9b1b... 10/packages/sysfsutils/sysfsutils_1.3.0.bb: sysfsutils: change do_stage to use autotools_stage_all in 1.3.0 Jan 03 03:35:47 03jbowler 07org.oe.dev * rc6edb078... 10/packages/ (5 files in 4 dirs): Jan 03 03:35:48 setpwc, mdadm, wakelan, xinetd: inhibit autotools staging (not required) Jan 03 03:35:50 - mdadm all - mdadm.inc Jan 03 03:35:52 - setpwc 0.9 Jan 03 03:35:53 - wakelan 1.1 Jan 03 03:35:56 - xinetd 2.3.13 Jan 03 03:35:58 03jbowler 07org.oe.dev * re16cffcf... 10/packages/ipkg/ (ipkg.inc ipkg_0.99.152.bb ipkg_0.99.153.bb ipkg_0.99.154.bb): Jan 03 03:36:01 ipkg: change do_stage to use autotools_stage_all in ipkg.inc Jan 03 03:36:03 - this changes all versions which use ipkg.inc, Jan 03 03:36:05 - 0.99.152 0.99.153 0.99.154 Jan 03 03:36:06 03jbowler 07org.oe.dev * rc8cec7f9... 10/packages/ (nail/nail_11.21.bb ssmtp/ssmtp_2.61.bb): ssmtp, nail: inhibit autotools stage in nail 11.21, ssmtp 2.61 Jan 03 03:36:09 03jbowler 07org.oe.dev * r5dc2d236... 10/packages/puppy/puppy_1.11.bb: puppy: inhibit autotools stage in puppy 1.11 Jan 03 03:36:13 03jbowler 07org.oe.dev * r068f4de8... 10/packages/popt/popt_1.7.bb: popt: change do_stage to use autotools_stage_all in 1.7 Jan 03 03:36:16 03jbowler 07org.oe.dev * rcc48e899... 10/packages/openobex/openobex_1.0.1.bb: openobex: change do_stage to use autotools_stage_all in 1.0.1 Jan 03 03:36:19 03jbowler 07org.oe.dev * rd53f3239... 10/packages/nfs-utils/nfs-utils_1.0.6.bb: nfs-utils: inhibit autotools stage in 1.0.6 Jan 03 03:36:22 03jbowler 07org.oe.dev * r1c28b19a... 10/packages/ncftp/ncftp_3.1.9.bb: ncftp: inhibit autotools stage in 3.1.9 Jan 03 03:36:25 03jbowler 07org.oe.dev * r71628c75... 10/packages/lzo/lzo_1.08.bb: lzo: change do_stage to use autotools_stage_all in 1.08 Jan 03 03:36:28 03jbowler 07org.oe.dev * r3db52ecf... 10/packages/libao/libao_0.8.6.bb: libao: change do_stage to use autotools_stage_all in 0.8.6 Jan 03 03:36:31 03jbowler 07org.oe.dev * r40cd64ed... 10/packages/libgphoto2/libgphoto2_2.1.6.bb: libgphoto2: change do_stage to use autotools_stage_all in 2.1.6 Jan 03 03:36:36 03jbowler 07org.oe.dev * r10d8222c... 10/packages/libid3tag/libid3tag_0.15.0b.bb: libid3tag: change do_stage to use autotools_stage_all in 0.15.0b Jan 03 03:36:37 patch rain Jan 03 03:36:40 03jbowler 07org.oe.dev * r615eba3b... 10/packages/libvorbis/libvorbis_1.0.1.bb: libvorbis: change do_stage to use autotools_stage_all in 1.0.1 Jan 03 03:36:44 03jbowler 07org.oe.dev * rb5e7f8ff... 10/packages/libmad/libmad_0.15.0b.bb: libmad: change do_stage to use autotools_stage_all in 0.15.0b Jan 03 03:36:48 03jbowler 07org.oe.dev * rc47b56a3... 10/ (3 files in 2 dirs): slugos-packages: add klibc to build (meta package) Jan 03 03:36:52 03pH5 07org.oe.dev * rfbc22e24... 10/packages/ (15 files in 15 dirs): autotooled packages: remove redundant do_stage Jan 03 03:36:56 03pH5 07org.oe.dev * rcd6d972f... 10/packages/gpe-autostarter/ (2 files in 2 dirs): gpe-autostarter-0.11: dbus-0.60 support Jan 03 03:37:32 RP: well... there may be an error in the bb file as i cannot retrieve sources when bitbaking matchbox-wm_svn.bb Jan 03 03:38:35 NAbyss: its still giving me that error, do i need to bitbake clean glibc? Jan 03 03:38:42 glibc-2.3.5+cvs20050627-r1 Jan 03 03:40:10 RP: After that we need to put the battery info in sharpsl_pm.machinfo into an array, because tosa has up to 3 batteries. (with 2 different bat_level tables) Jan 03 03:43:03 do13_: This is where the changes start to worry me a bit but yes, I can see the need. We'll need to think about a sysfs class for batteries at that point as well Jan 03 03:43:07 (rather than apm) Jan 03 03:44:37 unless we can handle tosa as a special case some other way... (is the charging code similar enough to warrent the array?) Jan 03 03:45:59 alan|home: I think others would be reporting the problem if the issue as in the .bb file? Jan 03 03:46:54 RP: do we have any example how to use git fetcher? Jan 03 03:47:19 NOTE: package linux-openzaurus-2.6.15-r0: task do_patch: completed Jan 03 03:47:48 hrw|work: I have an openzaurus-it .bb file... Jan 03 03:48:30 03pH5 07org.oe.dev * rc2095dad... 10/packages/gpe-beam/ (gpe-beam-0.2.8/dbus-new-api.patch gpe-beam_0.2.8.bb): gpe-beam-0.2.8: dbus-0.60 support Jan 03 03:48:44 RP: I would like to create linux-collie_2.6-git.bb Jan 03 03:49:20 hrw|work: http://www.rpsys.net/openzaurus/temp/linux-openzaurus_git.bb is an example from a while back Jan 03 03:49:51 thx Jan 03 03:51:31 RP: Tosa has 2 different batteries: main / jacket battery and backup battery. Main and jacket battery can be independenly charged Jan 03 03:52:15 df00z: yeah, you'll need to clean it up Jan 03 03:52:26 do13_: What I mean is whether the chargers and battery reading methods are similar enough to fit the same framework or not? Jan 03 03:53:09 NOTE: package linux-openzaurus-2.6.15-r0: task do_build: completed Jan 03 03:54:03 RP: how does hh.org kernel resolved it? they have ipaq with external jackets (maybe not in 2.6 yet) Jan 03 03:55:41 RP: Yep. battery reading uses the same method for all three batteries (backup battery needs no temp measurement). Jan 03 03:56:00 RP: If I have basic tosa pm/charging we can think about multiple batteries. :) Jan 03 04:00:39 do13_: Agreed. Getting the main one working first would be good :) Jan 03 04:00:58 We're slowly heading into the position of needing to replace apm... Jan 03 04:03:11 I hadn't realised 2.6.15 was out. Time to start merging things I guess... Jan 03 04:03:28 RP: small mmc changes after rc7 Jan 03 04:04:23 03pH5 07org.oe.dev * r886d4fc3... 10/packages/linux/handhelds-pxa-2.6_cvs.bb: handhelds-pxa-2.6: empty kernel-image package for hx4700 Jan 03 04:07:40 hrw|work: I don't think the pxa can handle 1024 block size cards anyway... Jan 03 04:29:34 RP: 2.6.15 booted on my husky Jan 03 04:33:15 shit.. by mistake I put 1G card into collie and 64M one into husky case... Jan 03 04:37:53 heheh Jan 03 04:39:22 hrw|work: I'd be interested to know if sound is working - I tested c3000 with 2.6.15-rc7 but not c760 yet Jan 03 04:43:09 RP: speaker works Jan 03 04:43:30 aplay u8_m22050 Jan 03 04:44:06 hrw|work: That's good :). Hoepfully it will auto mute when you insert headphones... Jan 03 04:44:21 Eventually userspace will have that control but that's not happening quite yet Jan 03 04:46:54 hmm.. opie-alsamixer.... Jan 03 04:49:02 hrw|work: We're going to need something like that soon enough :) Jan 03 04:51:11 Speaking about the kernel on the c3x00s.. I've noticed a discrepancy between 2.4 and 2.6's config files.. 2.6 appears to install to /dev/hda1, while 2.4 installs to /dev/mtdblock2 on the borzoi (c3100) Jan 03 04:52:02 NAbyss: That's intentional Jan 03 04:52:52 RP: Ah.. is 2.6 known to boot on the 3100? Mine fades to white shortly after the console stuff scrolls past Jan 03 04:53:13 NAbyss: Did you use a kernel from the branch or .dev? Jan 03 04:53:18 RP: .dev Jan 03 04:53:31 2.6 should work fine on the 3100 :-/ Jan 03 04:53:59 Hmm.. I'll try building the image again Jan 03 04:53:59 Was it a bootstrap image? I've heard reports of them being prone to doing that... Jan 03 04:54:20 Twas opie-kdepim-image, IIRC Jan 03 04:55:00 It does this on every boot or did you just boot it once? Jan 03 04:55:42 The first two boots it does it, then the third and subsequent boots complain about empty flash endlessly.. seems to me like the zImage might have been corrupted Jan 03 04:57:10 Which kernel version is this? Jan 03 04:57:22 The empty flash messages should be harmless... Jan 03 04:57:40 linux-openzaurus_2.6.14+2.6.15-rc5.bb Jan 03 04:58:16 I'd try reflashing and reloading hdimage1.tgz onto the microdrive... Jan 03 04:59:24 okies.. just to clarify, which targets should I be building for the 3100? Jan 03 04:59:55 oz.org doesn't have all that much detail on the 3100, only the 3000 Jan 03 05:05:36 You need an hdimage1.tgz, zimage.bin and updater.sh Jan 03 05:05:43 You don't need an initrd.bin Jan 03 05:05:50 ahh, that'd do it then Jan 03 05:06:08 no hdimage1.tgz? Jan 03 05:06:12 I had it the other way around Jan 03 05:06:22 initrd, but no hdimage Jan 03 05:06:28 That wouldn't work :) Jan 03 05:06:40 Yeah.. worked for 2.4, but not .6 :) Jan 03 05:06:47 Where are the confusing instructions? Jan 03 05:07:00 2.6 is very different Jan 03 05:07:11 It's not so much confusing instructions as lack of them.. http://www.openzaurus.org/wordpress/ only has a link on the left for the 3000 Jan 03 05:07:27 Was using that as a vague guide.. I've a friend with a C3000 talking me through it Jan 03 05:07:27 You might need repartition the microdrive to get 2.6 working btw Jan 03 05:07:57 Yeah, I just noticed that article.. any suggestion as to size? Jan 03 05:08:00 100mb-ish? Jan 03 05:08:04 yes Jan 03 05:08:13 its needs to fit your rootfs Jan 03 05:10:17 Should I keep the 3 partitions? If so.. what's the second used for? Jan 03 05:10:32 The second becomes /home Jan 03 05:10:43 The third becomes /media/hdd Jan 03 05:10:49 ahh Jan 03 05:11:05 Or you can merge them and use a custom fstab... Jan 03 05:11:43 Yeah, I'm thinking it might be best to keep it relatively standard Jan 03 05:11:53 Its usually easier... Jan 03 05:12:47 Yeah Jan 03 05:14:50 someone know simple small alsa mixer? amixer is 50K code Jan 03 05:18:08 http://www.oesf.org/forums/index.php?showtopic=16884 - someone want use pdax as base for prototype devboard... Jan 03 05:22:29 RP: On corgi headphone detection is send via keyboard driver to userspace? Jan 03 05:26:01 do13_: That's the idea although I think the hooks in the sound driver have been accidently removed by lrg Jan 03 05:26:16 i need an embedded web server ... should support server side script? any recommandations? Jan 03 05:26:20 do13_: I'll probably move the switch detection code into the input driver eventually Jan 03 05:26:42 ssl is prefered also Jan 03 05:27:06 linnuxxy: thttpd, boa, tiny-httpd? Jan 03 05:27:45 which one do u recommand? Jan 03 05:28:26 i think boa does not support server side scripting?! Jan 03 05:29:42 morning Jan 03 05:29:47 hi reenoo_ Jan 03 05:29:55 hey RP Jan 03 05:33:06 what about hydra web server? Jan 03 05:33:10 is it ok? Jan 03 05:35:53 linnuxxy: I cannot recommend. Jan 03 05:37:15 hail zecke Jan 03 05:37:43 hey Jan 03 05:37:53 Fear my Mickeyl-Mouse Power Jan 03 05:38:01 Lo Jan 03 05:38:26 I keep on having timeouts and stuff on gnu-config Jan 03 05:38:40 i have built a toolchain for armv5b-softfloat (could used for IXP420 for example) can i contribute with this pre-built toolchain somewhere? Jan 03 05:38:41 gerwin: are you firewalled? Jan 03 05:39:16 linnuxxy: we do not have places for that yet. Due multiple reasons I guess Jan 03 05:39:34 gerwin: rm -rf CVS_DIR/gnu-config and refetch Jan 03 05:41:18 hrw and zecke thanks Jan 03 05:41:36 Zecke: I got some opie questions (for my epia project) Jan 03 05:41:55 gerwin: sure, either ask now or mail me :) Jan 03 05:42:23 Zecke: I managed to get opie running but I am wondering how the hid support is Jan 03 05:42:53 Zecke: I cannot get my hid mouse working Jan 03 05:43:02 gerwin: Keyboard+Mouse or something else? Jan 03 05:43:49 linnuxxy: If #OE would distribute toolchains we would need to have the source and tools that were used to build the toolchain Jan 03 05:44:17 linnuxxy: and there is one pitfall for c++/stl the toolchain would need to sit in the same directory as you have used for building it Jan 03 05:47:12 Zecke: mouse via usb hid and keyboard via ps2 Jan 03 05:48:21 gerwin: keyboard should just work Jan 03 05:48:34 gerwin: and to see a mouse pointer you will need to recompile QtE Jan 03 05:48:41 gerwin: we have thrown that out there Jan 03 05:53:35 zecke: okay I will do my very best Jan 03 05:54:03 zecke: I will ask france to make a project page Jan 03 05:54:44 zecke: I am making now a 120 dollar pc for one of my friends who is handicapped and who cannot afford an expensive pc Jan 03 05:57:20 hi lrg|home Jan 03 05:57:30 hi RP, got your email Jan 03 05:58:11 RP: I think this may be a madplay problem as aplay and arecord seem to work fine. Jan 03 05:58:27 zecke: I still got the problem with gnu-config :( Jan 03 05:58:40 lrg|home: Just thought I'd let you know what was going on. I agree on the madplay issue - it just confused debugging a little bit :) Jan 03 05:58:42 RP: I'll need to give it a try on my PC as well Jan 03 05:59:14 I have noticed the keyboard driver hooks seem to have dropped out the alsa patches btw Jan 03 05:59:38 Not a problem as nothing's using them yet :) Jan 03 06:00:29 RP: ah, that's most likely my fault. I did some reorg and have probably misplaced them :( Jan 03 06:00:51 zecke: Another problem I am solving now is a problem with grub that didn't want to compile in my old builds Jan 03 06:01:11 hi lrg|home Jan 03 06:01:21 hi greentux Jan 03 06:01:23 lrg|home: I still want to put that interrupt code into the keyboard driver eventually anyway,,, Jan 03 06:01:42 RP: ok, np Jan 03 06:01:51 lrg|home: do you know how the 3.5mm connector is used? (ground, had, mic)? Jan 03 06:02:25 greentux: it should be a stereo connector with ground, left hp and mic Jan 03 06:02:36 I think tip is the mic, and the headset is the ring with ground being the base but I'm not 100% sure... Jan 03 06:02:47 ~lart kgpg Jan 03 06:02:48 * ibot puts kgpg into a headlock and administers a mighty noogie, rubbing half of kgpg's hair of Jan 03 06:02:48 ok. will check that tom. Jan 03 06:03:38 I'll be able to reorder my headset tomorrow. This time I'll get the right thing..... Jan 03 06:04:20 lrg|home: :) dos the alsamixer loads some useful defaults at startup? Jan 03 06:04:25 gerwin: even after deleting the source code? Jan 03 06:04:29 hi lrg Jan 03 06:04:40 hi pb__ Jan 03 06:04:54 linnuxxy: but please ask on oe@handhelds.org to kick off a discussion if OE should host/provide prebuilt toolchains Jan 03 06:04:56 greentux: not yet, it's something thats being worked on Jan 03 06:05:16 aaahhhh. :) Jan 03 06:05:59 greentux: I'm also thinking about creating alsa mixer profiles. i.e. you would have a good profile for headset and voip, another for mp3 etc Jan 03 06:06:00 ok i will do Jan 03 06:06:07 greentux: The only defaults that need to be changed are turning on the left and right mixer Jan 03 06:06:15 greentux: script is easy for it Jan 03 06:06:39 RP: i know, was only intersted in further development. Jan 03 06:06:54 hrw|work: can u send me example? Jan 03 06:07:01 greentux: case start: alsactl restore; card stop: alsactl store; - kind of Jan 03 06:08:05 hrw|work: ok, but the user should have some ready profiles (better vor OE acceptance) Jan 03 06:08:37 greentux: Yes, we should have a default config file installed Jan 03 06:08:38 greentux: sure - I'm saying about script which I use now Jan 03 06:13:38 zecke: it works now I need to change something in my bb file Jan 03 06:29:57 I tried some voip clients on ipaq and it didn't really work out , on the archos it worked perfectly and on the epia I got all kind of problems with the sound device Jan 03 06:31:06 gerwin: KPhone's OSS code can be improved very much Jan 03 06:32:09 <[lala]> hi, and a happy new year :) Jan 03 06:33:07 hi lala Jan 03 06:33:25 <[lala]> i have the feeling that the autotools_stage_all stuff did break some packages, didn't it? ;-) Jan 03 06:33:30 <[lala]> hi hrw Jan 03 06:33:44 zecke: there is another really cool sip client in oe Jan 03 06:33:47 <[lala]> after setserial less is the next package which want to do staging Jan 03 06:34:32 gerwin: linphone? Jan 03 06:35:18 gerwin: you mean minisip... Jan 03 06:38:55 <[lala]> should a INHIBIT_AUTO_STAGE = 1 in the .bb file fix the issue? Jan 03 06:39:10 03pH5 07org.oe.dev * r7de90a05... 10/packages/setserial/setserial_2.17.bb: setserial-2.17: overwrite autotools' do_stage with an empty one Jan 03 06:39:46 <[lala]> or is an empty do_stage() the proposed way? Jan 03 06:41:50 iirc there was something like IGNORE_AUTO_STAGE Jan 03 06:41:56 morning Jan 03 06:42:21 arguably, autotools.bbclass is currently broken Jan 03 06:42:52 anything done there shouldn't break .bbs inheriting it Jan 03 06:43:39 adding INHIBIT_AUTO_STAGE to possibly hundreds of .bbs is just plain wrong Jan 03 06:44:43 <[lala]> hrw|work: i have seen both - some packages have INHIBIT_AUTO_STAGE set, others have empty do_stage() Jan 03 06:45:22 <[lala]> but doing staging as default for all packages seems not very desireable to me ... i agree with renoo_ Jan 03 06:51:09 zecke: no I think it was some called sipphone or something it was with video Jan 03 06:52:54 hi all Jan 03 06:53:17 reenoo_: Given you seem to understand the autotools issue, could you have a word with pH5? His changes look to be getting a bit too broken :-( Jan 03 06:53:36 RP: writing mail to oe@ right now. Jan 03 06:54:11 RP: personally I'd just disapprove all related changesets Jan 03 06:54:17 He's just removed all the do_stage() functions which looks break the metadata quite badly as we loose the record of which files need staging... Jan 03 06:54:33 reenoo_: I'll second that in this case as this isn't right... Jan 03 07:09:31 RP: sent. please reply. Jan 03 07:10:55 reenoo_: will do Jan 03 07:11:09 RP: thanks Jan 03 07:11:50 reenoo_: do you happen to know any research about static code analysis? Jan 03 07:12:38 zecke: not offhand. what language? Jan 03 07:12:57 reenoo_: Java would be fine. I would prefer C++ though Jan 03 07:13:45 ah, hmm Jan 03 07:14:18 reenoo_: don't worry. I just hoped for the lucky shot ;) Jan 03 07:14:29 I do not know how to fill my report with content :} Jan 03 07:14:56 there's someone I know doing his diploma thesis on static analysis on gcc's intermediate language (not sure if the c++ frontend uses that) Jan 03 07:15:12 to detect buffer overflows and stuff Jan 03 07:15:26 reenoo_: that would be of personal interest for me Jan 03 07:15:38 reenoo_: you mean ''treelang''? Jan 03 07:16:08 zecke: I'm afraid I don't know any details Jan 03 07:17:09 I'll /msg you his mail address Jan 03 07:46:32 reenoo_: thanks Jan 03 07:47:05 hey zecke Jan 03 07:47:13 * mithro is in Warsaw atm Jan 03 07:47:20 going to Krakow in 2 hours Jan 03 07:48:23 * mithro is having problems with ssh however :/ Jan 03 07:48:30 mithro: when into Poznan?? Jan 03 07:48:46 mithro: hey Jan 03 07:48:52 mithro: did you catch the train? Jan 03 07:49:08 * hrw|work is from Poznan Jan 03 07:50:23 reenoo_: reply sent Jan 03 07:52:28 anyway as I was saying Jan 03 07:52:50 rday wants to help with the tosa 2.6 kernel :) Jan 03 07:53:00 * reenoo_ rotfl Jan 03 07:53:20 I can't figure out why my SSH connects but hangs on setting up an interactive prompt Jan 03 07:53:20 ;) Jan 03 07:53:40 RP: should I send him the Project Tosa then? Jan 03 07:53:52 zecke: he has one! Jan 03 07:54:12 mithro: some one changed your ssh config in a way you can only run certain apps? Jan 03 07:54:22 <[lala]> atk seems to be broken, because glib-2.0 doesnt stage share/glib-2.0 anymore Jan 03 07:54:35 zecke: Just keep in mind his track record ;-) Jan 03 07:55:01 zecke: not that i can see Jan 03 07:55:05 RP: at least he compiles twice a day and changes his local.conf more often Jan 03 07:55:28 mithro: try executing /bin/sh ;) Jan 03 07:55:57 RP: I'll sell my zaurus:) Jan 03 07:55:59 zecke: already tried that Jan 03 07:58:08 even doing a /bin/echo doesn't work Jan 03 07:58:51 any ideas? Jan 03 07:58:56 do13_: hehe Jan 03 07:58:59 mithro: sadly no Jan 03 07:59:03 #debian had no ideas :/ Jan 03 08:00:01 it's seems to die at the allocating terminal part Jan 03 08:01:01 mithro, clinet-server version conflict? Jan 03 08:02:05 i've tried reinstalling openssh, lsh works fine but that is a bitc Jan 03 08:04:04 it hangs here Jan 03 08:04:06 write(3, "\332@Z\223\232\373E\207\0%K\371\361\351.\342\261\26\245"..., 400) = 400 Jan 03 08:04:06 select(7, [3], [], NULL, NULL Jan 03 08:06:29 * mithro tries a distupgrade Jan 03 08:09:25 the weird thing is that it was working at zeckes house Jan 03 08:09:33 and I can't think of any changes since then Jan 03 08:09:37 just one word... owned Jan 03 08:10:20 but how did they own me between your house and here? :P Jan 03 08:10:53 mithro: I think zecke means possessed :) Jan 03 08:11:28 RP: i think he means 0\/\/n3d Jan 03 08:11:48 Thanks for clarifying the staging changes situation Jan 03 08:12:00 mithro: I have no idea. I do not think you have a break in Jan 03 08:12:56 zecke: neither do I, but i can't think of any other possible problem Jan 03 08:20:14 * mithro tries compiling from souce Jan 03 08:20:36 mithro: using telnet is not a option right? Jan 03 08:21:04 yeah Jan 03 08:28:30 * RP is tempted to dissaprove the autotools changes... Jan 03 08:29:41 RRP: why? Jan 03 08:29:48 RP: yah. I'm just a bit reluctant to clean up the mess others created since you will have to bump PR of all affected packages if you want to do it cleanly. then again I guess we can just as well tell people to do an "rm -rf $TMPDIR" Jan 03 08:30:11 mithro: see oe@ Jan 03 08:30:58 reenoo_: I know what you mean. I think we just live without the PR change and get is disapproved before more damage gets done... Jan 03 08:31:17 I'm not building anything until it gets changed... Jan 03 08:31:26 hi RP :) Jan 03 08:31:36 RP: ok. are you going to do it then? Jan 03 08:32:51 reenoo_: I guess so. Its not going to make me popular though :) Jan 03 08:34:44 damn, the self compiled ssh also exhibits the same problems Jan 03 08:40:57 morning kergoth Jan 03 08:41:23 RP: hehe. right. I guess I haven't made myself popular with what I sent to oe@ either. so, let's share the pain ;) Jan 03 08:41:30 hey kergoth Jan 03 08:43:29 reenoo_ , RP : seems like the sane option to me Jan 03 08:43:40 kergoth: welcome Jan 03 08:43:44 reenoo_: I'll disapprove all the autotools changes except the position change of inherit native in coreutils as that change looks ok to me Jan 03 08:44:37 actually it probably breaks things :-/ Jan 03 08:44:42 reenoo_: for me you look like 'hey guys - you fscked something here and here - do it like this or this' Jan 03 08:45:47 hrw|work: the point being? Jan 03 08:46:59 done. The coreutils change is ok (I think). Jan 03 08:47:29 <[lala]> as to me i cannot build neither opie- nor gpe-image atm Jan 03 08:47:39 RP: yeah. inherit native must come after include foo.bb Jan 03 08:47:59 <[lala]> gpe breaks with atk Jan 03 08:48:09 <[lala]> opie breaks with konq-embedded Jan 03 08:49:07 hrw|work: there are lots of people who have put a significant amount of work, time, and money into OE development. I guess you have to live with that fact that people will start screaming if you start breaking stuff like with the current autotools_stage_all() vendetta Jan 03 08:50:26 reenoo_: in positive way I mean Jan 03 08:50:42 hrw|work: ok, sorry. Jan 03 08:50:49 reenoo_: np Jan 03 08:50:57 hrw|work: I guess I should have a break or something... Jan 03 08:51:57 reenoo_: I also dont like to put untested things (happens sometimes anyway) Jan 03 08:52:32 btw - can someone look at #524? Jan 03 09:18:10 Hmm. I'm not sure the disapprove worked :-/ Jan 03 09:19:39 RP: disapprove;commit? Jan 03 09:21:15 just disapprove should do. not sure what's going on there Jan 03 09:22:06 I just used disapprove and some things have disappeared from my tree, some haven't :-/ Jan 03 09:22:36 I guess we need viewmtn to be able to see what's going on now.. Jan 03 09:24:56 cu Jan 03 09:27:49 RP: oh, dear. I believe I've had that before. this will be a pain to revert manually :/ Jan 03 09:28:19 * reenoo_ wished we were using a more mature "SCM" Jan 03 09:30:01 reenoo_: You mean disapprove is actually borken? :-( Jan 03 09:30:38 RP: may have been my fault. I don't know. Jan 03 09:32:47 RP: IIRC monotone got confused due to merging Jan 03 09:33:17 reenoo_: Yes, looking at monotone log, that would appear to be the case here. Any tips on resolving this? Jan 03 09:36:24 no, sorry :( Jan 03 09:36:40 I just copied the file in question back in last time Jan 03 09:36:46 http://www.handhelds.org/hypermail/oe-commits/6/0601.html Jan 03 09:36:54 http://www.handhelds.org/hypermail/oe-commits/6/0602.html Jan 03 09:39:21 reenoo_: The number of files in this disapprove is going to make this a lot more tricky... Jan 03 09:40:34 * reenoo_ nods :/ Jan 03 09:41:40 Basically it did 2 merges after the disapproves which look to have broken things... Jan 03 09:47:49 have you pushed your changes already? Jan 03 09:48:21 or tried to do so rather Jan 03 09:49:24 nice. the server on vanille.de is down again Jan 03 09:49:40 reenoo_: yes. I checked a couple of files which worked so I assumed it was all ok... Jan 03 09:51:08 hmm. and I'm now out of diskspace :-/ Jan 03 10:10:54 reenoo_: It seems to have correctly disapproved the two small changesets and messed up the big one... Jan 03 10:11:11 by messed up, read totally failed to apply Jan 03 10:12:31 so it could be worse... Jan 03 10:14:09 gotta go. sorry Jan 03 10:18:12 koen|away: ping? Jan 03 10:20:13 good evening all Jan 03 10:20:30 hi pH5 Jan 03 10:21:31 You've read oe@? Jan 03 10:21:52 reenoo sparked quite a discussion there. I've just started. Jan 03 10:23:14 pH5: ok. the bit about the disapproval isn't quite true as it doesn't appear to have worked. I'm seeing what state the repo is in before doing anything further... Jan 03 10:28:47 hm. there are two things going on at once here. Jan 03 10:28:47 some packages' do_stage were changed today so they don't work anymore. and there seem to be some packages with broken makefiles that don't like to be staged. Jan 03 10:29:42 RP: i like your proposal to add an autotools_stage class. if the goal is to make this the default after some transition phase. Jan 03 10:31:23 pH5: That would be the idea Jan 03 10:32:41 The problem is that for something as important as autotools we can't change the behaviour which is what your patch does... Jan 03 10:34:57 I didn't expect (and didn't experience in my test builds) those packages with broken Makefiles that are worked around in do_install. Jan 03 10:36:26 Actually I think we could make even those work with default autotools_do_stage if we don't run make install in autotools_stage_all but use the contents of the image/ dir from the do_install phase instead. Jan 03 10:36:50 ok, we just need to be careful. Someone should have realised this when you proposed the idea... Jan 03 10:38:28 Eventually, one of the aims is to put staging under control of the package manager and perhaps to use the -dev packages directly Jan 03 10:40:39 I know. Just when will this happen? Jan 03 10:40:58 When someone gets around to impelmenting it :-( Jan 03 10:41:36 That's the problem. If only we could do this in little steps. Jan 03 10:42:53 Don't get me wrong, I want this to work as much as you. We just can't risk breakage. This is where the new bbclass comes in Jan 03 10:43:37 If we can mark all the sane packages and have them using a new method of staging we have something to convert to Jan 03 10:44:36 One of the concerns are there are a lot of hidden tweaks in the do_stage functions and it would be a shame to lose that metadata Jan 03 10:44:51 Fine. So how do we create consensus that adding another bbclass is a good interim solution :-) Jan 03 10:48:26 pH5: Probably by doing it :) Jan 03 10:49:25 I'd mention you like the idea on the mailing list and then say you'll start implementing it on say Friday if there are no objections Jan 03 10:50:38 oh, there will be :) Jan 03 10:51:55 pH5: I've not seen any objections yet and most of the main contributors have commented or at least read the mails Jan 03 10:52:17 Yes, they can see other ways of doing it but that's not an objection as such ;-) Jan 03 10:52:30 is it possible to keep the class name as autotools for the new class and change the original class to autotools_bob and then sed sub all the metadata to use the autotools_bob and then slowly move to autotools as they are fixed thus ending with a known name class inherited like before Jan 03 10:53:13 ade|desk: That does bother me but when you consider the out of tree .bb files, it gets tricky... Jan 03 10:53:42 and yes, out of tree .bb files do exist. I have a few personal ones and I know OH has some as well Jan 03 10:53:43 else in several months time we end up with autotools_new and then autotools_new_new etc Jan 03 10:54:32 Once we convert to the new autotools, we can perhaps rename. Jan 03 10:55:58 I guess it's better to change autotools_stage.bbclass --> autotools.bbclass when everything is converted and the issue is known for a long time. Jan 03 10:56:22 RP: indeed out of tree .bb exist but changing from inherit autotools to inherit autotools_blob for a few out of tree bbs is not so bad and have an extra class Jan 03 10:57:09 otoh we might end up with autotools and autotools_new forever, if people lose interest. Jan 03 10:57:17 Well, I'd happily see autotools renamed to autotools_legacy or something... Jan 03 10:57:37 but only once we have a replacement ready and tested with a few packages Jan 03 10:58:28 so we create autotools_new and once we have a few (50? 100?) packages using it, we can do all the renaming in one go Jan 03 10:59:53 heh. considering my initial patch changed over 90 packages (all of them working), we perhaps shouldn't pin that name change to the number of packages Jan 03 11:00:44 pH5: heh, indeed Jan 03 11:00:49 s/packages/recipes/, some were different versions of the same package. Jan 03 11:04:12 pH5: Lets also try and aim a little higher so we only end up doing this once - perhaps the new class can use do_install and the resulting -dev package :) Jan 03 11:04:57 Are we sure that the dev package has everything needed for staging? Jan 03 11:05:12 I.e. will we fish our files out of image/ or install/package-dev/ Jan 03 11:07:54 libs could be tricky as they're not in the -dev package iirc Jan 03 11:08:05 well, obviously install/package-dev alone is not sufficient. But the combination of install/package and install/package-dev certainly should be sufficient in almost all cases. Jan 03 11:08:38 If not, it could be argued the packages packaging is wrong :) Jan 03 11:09:11 Great, there's our first little step. Jan 03 11:10:40 "wrong" is a bit judgemental; there might be packages that legitimately break their files into multiple subpackages. But those are pretty rare, and you could handle them manually. Jan 03 11:11:20 pb__: agreed Jan 03 11:12:13 pH5: heh. for a first little step, that's a pretty big one. Jan 03 11:13:02 admittedly it's probably not all that much actual work, but package-based staging has been a seemingly unattainable goal for many months Jan 03 11:15:00 but this means we'd have to run do_package before do_stage, right Jan 03 11:15:13 right Jan 03 11:15:32 pH5: The class can handle changes like this Jan 03 11:20:32 or, well, more accurately, you'd have to run do_package before do_ph5_eleet_autostage or whatever you call the new method. obviously you can't just flip around the order of the two existing methods without making more intrusive changes. Jan 03 11:23:26 I'd suggest creating a new method after packaging and making do_stage a null method Jan 03 11:26:23 reenoo_: wb Jan 03 11:26:32 re Jan 03 11:26:44 I agree that switching to a package manager controlled staging area is a worthy goal. just removing working do_stage() functions however has no advantage and causes a lot of breakage Jan 03 11:26:59 right Jan 03 11:27:21 there's clearly no point in eliminating existing do_stage functions that are working fine Jan 03 11:27:31 right Jan 03 11:27:32 reenoo_: ack, nobody wants to just remove working functions Jan 03 11:28:02 pH5: well. that's what Koen, John Bowler and you have been doing the last couple of days. Jan 03 11:28:41 in other news, intrusive changes like these are they reason why people make use of branches Jan 03 11:28:51 s/they/the Jan 03 11:28:54 reenoo_: If the autotools function does an equally good job, I'm not so sure I see the problem with that. As long as we're being careful to check that is the case... Jan 03 11:29:29 RP: there's no automated way to do regression testing for this Jan 03 11:29:31 reenoo_: I was pretty sure I only removed do_stage functions that either contained autotools_stage_all anyway or that were doing it the brute-force make install way. Jan 03 11:29:32 and I understand how difficult it is to check what's going on... Jan 03 11:29:40 If you actually check on a case-by-case basis that the effect is identical, sure, you can remove the do_stage. But you might as well save yourself the effort and just leave it alone. Jan 03 11:30:21 the packages that I broke had broken Makefiles with workarounds in do_install (that weren't applied during the make install called by do_stage) Jan 03 11:30:41 yeah, that was a bit weird and unforeseen Jan 03 11:31:04 What exactly were the problems that showed up in those cases? Jan 03 11:31:27 I couldn't immediately think of any obvious breakage that wouldn't also have occurred during the old autotools_stage_all() or "make install" approaches. Jan 03 11:31:50 they install files without checking for the directories first Jan 03 11:32:31 oh, right, so autotools just needs to make those directories itself. Jan 03 11:32:45 I still don't really understand why that wasn't a problem with the old arrangement, but at least it should be easy to fix. Jan 03 11:33:02 The interaction between native.bbclass (for example) and autotools.bbclass is a bit more tricky though. Jan 03 11:34:50 As Rene pointed out on the mailing list, there may be packages that rely (maybe unintentionally) on the fact that they get the do_stage() method from native.bbclass, and would break in weird ways if autotools.bbclass started providing one as well. Jan 03 11:35:00 pH5: I'm not saying it was all you. but changes removing perfectly working do_stage() functions have definitely been pushed into the repository. I'm sorry if I actually mixed something up there. Jan 03 11:35:13 pb__: yes, like coreutils-native Jan 03 11:37:18 reenoo_: To be fair, those changes have been committed by jbowler - pH5's changes mostly just removed do_stage(autotools_stage_all) Jan 03 11:37:34 * pb__ going home now Jan 03 11:37:36 bbl Jan 03 11:38:05 pH5: my appologies then Jan 03 11:38:09 reenoo_: no offence taken. anyway, at least the corutils-native and setserial issues were my fault. Jan 03 11:38:44 corutils-native was actually buggy regardless of your changes Jan 03 11:39:06 inherit native has to happen after include foo.bb Jan 03 11:42:14 pH5, RP: so, how do we proceed then? create an autotools_.bbclass, and revert the changesets that delete working do_stage() functions (i.e. not the brute force "make install" ones)? (that was actually my initial proposal) Jan 03 11:42:43 pH5: yes Jan 03 11:43:10 reenoo_: sounds reasonable. Jan 03 11:43:42 We then go and change all those packages to use the new autotools_foobar at which point we can delete the do_stage functions Jan 03 11:44:34 RP: what about your cset disapproval? Jan 03 11:44:43 RP: personally, I'd like to avoid that as there's no way to review such a large scale change Jan 03 11:45:21 RP: I'd prefer to leave working .bbs alone until we have sanboxing/package management of the staging area Jan 03 11:46:05 reenoo_: We're talking about packages who's do_stage consists of calling just calling autotools_stage_all Jan 03 11:46:06 RP: you could do automated checks to sanity check the do_stage() changes once we have that Jan 03 11:46:21 RP: ah, sorry Jan 03 11:46:40 I still had the jbowler style diffs in mind Jan 03 11:46:52 reenoo_: I agree we leave the more complex changes until later and this does raise the jbowler diffs Jan 03 11:47:11 that way we'll hopefully work around the chicken&egg problem that is putting staging under package management control. Jan 03 11:47:23 If he has been carefully checking things we might be ok - I note he has made comments about some installs being broken Jan 03 11:47:48 pH5 hopefully, yes Jan 03 11:48:55 the problem with jbowlers' glib-2.0 change at least was the dumb autotools_stage_all only installing aclocal/ from usr/share/ Jan 03 11:50:05 RP: yah. it's just that applying risky changes like these always requires review/testing. and since there's nothing to be gained here, that's a rather pointless waste of effort Jan 03 11:51:31 <_law_> usbnet doesnt work with latest kernel :-( Jan 03 11:51:56 _law_: Which machine? Jan 03 11:52:08 <_law_> husky Jan 03 11:52:29 _law_: ok, I think I can guess why - try removing the usb*rndis* patch... Jan 03 11:52:54 <_law_> RP: ok i?ll try Jan 03 11:53:42 <_law_> usb0: register 'cdc_subset' at usb-0000:00:10.0-1.4, Linux Device, 1a:48:e8:ce:22:7a Jan 03 11:53:43 <_law_> NETDEV WATCHDOG: usb0: transmit timed out Jan 03 11:53:43 <_law_> usb0: no IPv6 routers present Jan 03 11:55:20 Although that rndis patch shouldn't touch cdc codepaths :-/ Jan 03 11:55:47 You can try removing it and if that fails I'll have to do some testing... Jan 03 11:57:00 reenoo_: I don't think its pointless waste of effort as proper package managing of staging has some advantages in the future Jan 03 11:57:34 * RP needs to get food - will try and finish the patch to fix the repo afterwards Jan 03 12:06:05 RP: no, I was referring to jbowler's changes only. the earlier we get package managing of the staging area the better :) Jan 03 12:17:48 heya folks Jan 03 12:18:11 hi renoo: thanks for the advice about the bitbake build. i get to try it in a few mins :) Jan 03 12:52:14 lkcl: no problem. and good luck then. Jan 03 13:02:07 reenoo_: Rather than correct this disapproval business, its going to be nearly as easy to press on and start autotools_new... Jan 03 13:03:38 RP: I was of the impression you had pushed your changes already, didn't you? Jan 03 13:04:12 err.. that doesn't look quite right. I hope you get the idea anyway ;) Jan 03 13:04:33 reenoo_: I pushed the disapprove but it basically only knocked out two of the changes, the one to setserial and the one to autotools.bbclass itself Jan 03 13:05:09 So either I revert all the removals of mentions of autotools_stage_all or add a new bbclass and change those packages to use it... Jan 03 13:06:24 well. there are around 23 changesets to be reverted Jan 03 13:06:52 Yes, but I hadn't started on them (thankfully) Jan 03 13:07:04 I'd also like to ask jbowler exactly how was was testing them Jan 03 13:07:31 jbowler: ping? Jan 03 13:07:58 judging from bugs.oe.org they went in more or less untested (partly anyway). Jan 03 13:08:37 yes :-/ Jan 03 13:08:44 true... Jan 03 13:15:06 * reenoo_ heads off for more fun with prolog Jan 03 13:15:48 I'll assist with sorting the disapproves out once I'm done with this assignment. later all Jan 03 13:20:08 RP: if I create autotools_new.bbclass and have it EXPORT_FUNCTIONS do_stage, do I have to create an autotools_new_do_stage, or will it export the inherited autotools_do_stage? Jan 03 13:22:37 http://en.pastebin.ca/35644 Jan 03 13:24:05 pH5: We're not going to have an autotools_do_stage in autotools.bbclass (that was already reverted) Jan 03 13:24:37 This was one of the problems as it introduced a change in behaviour Jan 03 13:25:10 ah, I thought the exporting part did the change Jan 03 13:25:34 Well, that as well but since we're going to be altering it, it may as well be in the new class Jan 03 13:25:49 RP: ok. and you did already push the reverted revision? Jan 03 13:25:50 pH5: yes, the "EXPORT_FUNCTIONS" is the significant bit Jan 03 13:26:03 just having a function named "autotools_do_stage" is harmless in itself. Jan 03 13:26:58 pH5: The disaproval has gone badly wrong. That change was reverted and the setserial one but nothing else was touched Jan 03 13:27:24 RP: whether I pull from monotone or ewi546, I'm still at rev. 7de90a055904c4af8890dd5ae8c192bfd41b3fa1 Jan 03 13:28:26 pH5: Really? If so, the approval never made it in. No multiple heads or anything? Jan 03 13:28:48 That would be handy as I can start again :) Jan 03 13:29:11 monotone: branch 'org.openembedded.dev' is currently merged: Jan 03 13:29:11 7de90a055904c4af8890dd5ae8c192bfd41b3fa1 pH5@openembedded.org 2006-01-03T13:20:44 Jan 03 13:30:53 RP: those changes were tested by (1) only changing things which are actually staged in NSLU2 builds, (2) the other packages use the staged result. Jan 03 13:31:40 Since this is staging the only thing affected is packages which DEPEND on the build, so if those build the result is almost certainly correct. Jan 03 13:32:11 jbowler: So you never actually did a comparision of what make install installed compared to what was listed in do_stage? Jan 03 13:32:21 Actually, I can't see how it can be wrong, since I eyeballed the changes too and dealt with things which were not one of (1) libs, (2) incude headers or (3) m4 files. Jan 03 13:32:40 RP: yes, not in all instances Jan 03 13:33:03 jbowler: Why are we seeing bugs then? :-/ Jan 03 13:33:12 What bugs? Jan 03 13:33:19 jbowler: I don't know what reenoo meant with multiple packages going wrong, but at least the glib-2.0 change causes atk not to build here. Jan 03 13:33:29 #570 Jan 03 13:33:51 because my autotools_stage_all only installs aclocal/ from usr/share/ currently Jan 03 13:34:00 Ah - the glib, ipkg and binutils I were fine against the packages I tried, but glib-2.0 is the most difficult. Jan 03 13:34:45 That's where they are separate commits - because it may be necessary to back one or other out. Like I said, I tested them but there might still be bugs... Jan 03 13:35:20 RP: what about this: http://en.pastebin.ca/35646 Jan 03 13:35:21 RP: do you have a URL for that bug report? Jan 03 13:35:48 http://bugs.openembedded.org/show_bug.cgi?id=570 Jan 03 13:36:05 eh. Jan 03 13:36:28 http://en.pastebin.ca/35647 Jan 03 13:36:48 RP: ok, I know about this and I thought I had got it right. Jan 03 13:36:49 pH5: I was going to say :) Jan 03 13:37:06 pH5: Yes, that looks good Jan 03 13:38:10 pH5: Can you revert the change to setserial and then change all the packages mentioned in revision 65af73a95a851d2e8c3cf2f523f1acc488be0208 to use this new class please? Jan 03 13:39:03 jbowler: The conern we have is whether we're losing metadata with these staging changes :-/ Jan 03 13:40:45 reenoo would like to see them reverted until things have been properly compared which I can sympathise with. It really depends how carefully they've been checked... Jan 03 13:41:57 RP: look at the change I made... ok, it has a bug in it connected with gettext, but this isn't a general problem, it's specific to me not understanding glib-2.0 Jan 03 13:43:18 I.e. specifically the following lines (in native) which I removed and checked were wrong: Jan 03 13:43:20 - install -d ${STAGING_DATADIR}/glib-2.0/gettext/po Jan 03 13:43:20 - install -m 0755 mkinstalldirs ${STAGING_DATADIR}/glib-2.0/gettext/ Jan 03 13:43:20 - install -m 0644 po/Makefile.in.in ${STAGING_DATADIR}/glib-2.0/gettext/po/ Jan 03 13:43:40 Which is really weird because I definately remember checking them... Jan 03 13:44:51 RP: you seem to be saying you want to revert all of my changes because I got one wrong. Jan 03 13:45:54 jbowler: No, I'm just worried about how much attention you've paid. I accept mistakes happen. As long as you're saying you made sure all the files that were staged under autotools and just screwed up on this one, I'm happy enough to leave the changes Jan 03 13:46:34 If you didn't check this in all cases though, it leaves us open to further bugs which is why I'm worried Jan 03 13:47:34 RP: I'm building a patch currently. Jan 03 13:47:36 My test methodology was identical for everything - make the change only in places where it will be tested by the build (i.e. I didn't change do_stage in things which were not known to me to be used in other packages), build everything from scratch and make sure it all worked. Jan 03 13:48:25 build testing isn't really enough for this though :-/ Jan 03 13:48:27 pH5: I am concerned that the default for 'inherit autotools' has changed from not staging to staging, that's pretty much untestable I think. Jan 03 13:48:52 jbowler: right, that was an error. that's why we'll change it back asap. Jan 03 13:48:57 RP: do you have an example of something which has broken in some place other than the build? Jan 03 13:49:03 jbowler: which is why I tried to disapprove those changes and why pH5 Is correcting that now Jan 03 13:49:28 jbowler: no, but you also haven't proven that all files that were staged are still staged... Jan 03 13:49:53 RP: like I said, I tested all my changes with a methodology which seems fine, and you are suggesting reverting about a week (elapsed time) of work. Jan 03 13:51:14 jbowler: It's quite possible that those glib/atk changes only show up with gtk 2.8 or something like this Jan 03 13:51:14 So I think I'm going to leave you all to do this for a while. Pity, we were within a few edits of having package builds only stage the stuff they needed. Jan 03 13:52:11 jbowler: Don't think I'm suggesting it lightly :-/ Jan 03 13:52:25 pH5: no, I made a mistake. The gettext subdirectory isn't in my staging tree. I don't know how I made it but those lines I quoted above should definately have been left in. Jan 03 13:52:36 RP: don't think I'm taking it lightly. Jan 03 13:53:01 jbowler: what exactly is the advantage in removing carefully hand crafted do_stage() functions? Jan 03 13:54:01 reenoo_: the result doesn't wear out. If I move a package foo_1.0 to foo_1.1 then I have to recraft do_stage to deal with added headers/libraries/m4 files. Jan 03 13:54:35 renoo_: hand crafted do_stage circumvents stuff which should be in the package make install rune, so it is bound to go wrong eventually. Jan 03 13:55:34 The change (minus the change to automatically do_stage) allowed us to move package-by-package to a centralised do_stage which could then be adjusted globally. Jan 03 13:56:30 I think as a compromise I'll just make some checks on the packages that have changed and check they stage correctly. This is going to cost me time I don't have but such is life :-/. What I do want to see is people manually checking all the right files get installed into staging in future when converting... Jan 03 13:56:31 I'd changed enough packages to use autotools_do_stage to allow that function to be changed to stage to an intermediate directory, then we can use the intermediate to build the 'correct' staging directory for each package (based on DEPENDS). Jan 03 13:57:30 RP: thank you - that's what I'd hoped. I know NSLU2 builds work fine, but if we can check some others between us then that will catch any remaining problems. Jan 03 13:58:07 jbowler: Its not builds I want checked - its whether all the files that get staged before still get staged. This is the important point Jan 03 13:58:15 I'm still mystified by the glib-2.0 gettext problem - I was looking in the wrong place (it's i686, build sys, not arm, host sys) - I see the gettext m4 files in staging! Jan 03 13:58:27 Whether things build or not afterwards is one test of this but its not conclusive Jan 03 13:59:01 RP: ok, I can check that too. Jan 03 13:59:11 (At least for the last set of changes it's fairly trivial). Jan 03 13:59:44 jbowler: If we're checking that in future (and can confirm the other packages didn't change anything in that respect), I'm happy Jan 03 14:01:09 you're still missing the point. everyone seriously using OE will have to review and verify these changes even though there's no direct gain and no long term gain either since do_stage() will be made obsolete by putting staging under package managing control Jan 03 14:01:46 re Jan 03 14:02:01 reenoo_: there's a gain because the latter (package control) won't work unless the format (autotools_do_stage) also works. Jan 03 14:02:29 reenoo_: If its confirmed the same files get staged, that is classed as review and verify... Jan 03 14:02:43 reenoo_: packaging can't happen without the do_stage functions being converted Jan 03 14:03:19 RP: is there an automated way to diff staging before/after? I don't think we have that sort of regression testing right now. Jan 03 14:03:42 reenoo_: I'm diffing two build trees (one before, one after). Jan 03 14:03:55 reenoo_: No, but you can do it manually which is what I'm asking for Jan 03 14:04:16 jbowler: I'm not talking about you. I'm talking about me and every other OE user out there. Jan 03 14:05:30 reenoo_: Do you personally test and verify every change to the OE tree? I'm beginning to lose the plot here... Jan 03 14:06:24 RP: for changes that are likely to cause breakage, yes (as time permits, obviously) Jan 03 14:06:27 reenoo_: you must have two trees - you can't test any staging change without two trees, i.e. you must build the package in a clean tree to test. Jan 03 14:06:56 That's because if you make a change and it results in a file not getting installed in staging the old file will still be there. Jan 03 14:07:00 Testing staging is a nightmare... Jan 03 14:07:16 (That's why it needs to be fixed to per-package staging). Jan 03 14:07:39 jbowler: and you tested your previous commits with that method? Jan 03 14:07:51 clean package. overriding the staging variables. build package. clean package again. override them to something else. diff the two temporary staging directories. Jan 03 14:08:13 er, throw a "modify package" after the build package, and add a build package after the first clean package Jan 03 14:08:16 i cant type Jan 03 14:08:46 RP: no - it was only when you suggested it above that I realised it would work and be more reliable. Jan 03 14:09:16 I was doing clean builds, but I wasn't diffing the staging directory. Jan 03 14:09:40 jbowler: ok, I just wanted to be sure before I try and test them :) Jan 03 14:09:42 That's why I only hacked things I knew were being used somewhere else... Jan 03 14:10:00 as kergoth says, we can actually test this by playing with bitbake variables Jan 03 14:10:27 good night all ! Jan 03 14:10:40 In this case I believe the glib-2.0 and ipkg changes should be reverted. Jan 03 14:11:01 Actually, glib-2.0 can be fixed, but I seem to have damaged libipkg. Jan 03 14:11:05 kergoth: we need you back :) Jan 03 14:11:59 <_law_> RP: without patch usbnetwork works Jan 03 14:12:40 _law_: That doesn't entirely surprise me and it handy to know, thanks. I'll have to track down the problem now but that's a good start :) Jan 03 14:13:32 jbowler: I'd prefer them all to be reverted for now. send a technical proposal detailing your goals to oe@, so we can discuss how staging should be done (I believe there are two conflicting concepts right now). and then we can re-apply the changes once they have each received proper testing (i.e. diffing staging). Jan 03 14:14:39 renoo_: that's the argument I just had with RP, sure, you can revert them, but after spending a week on this I'll spend my time on something more productive. Jan 03 14:15:32 After all, the point here is to get to somewhere where staging is per-package, and no package revision maintenance is required. Jan 03 14:16:10 reenoo_: Lets see how quickly I can test them. I don't really want to see work wasted but we do need to be careful here... Jan 03 14:17:15 RP: I sent a mail with patches to the oe list Jan 03 14:17:23 Yes, and your test methodology is better (it's shown me four or five packages of concern, of which the ones I listed before, glib-2.0, ipkg and binutils) are the significant onese). Jan 03 14:18:24 jbowler: like I said. there are two different concepts for how staging should be done. installing library and -dev packages there and yours - which I don't think you've described by mail yet. I'd like to understand your concept and I believe others will be interested as well. Jan 03 14:18:39 jbowler: I'm just trying to avoid further misunderstandings Jan 03 14:19:10 ok, I'll put that into an email. Jan 03 14:20:15 thanks. that will allow us to make a decision which way we want to go and which type of changes to apply Jan 03 14:20:30 jbowler: I have to admit I don't understand your ideas on how staging should be managed in the future... Jan 03 14:21:40 pH5: Your first patch was corrupt Jan 03 14:21:49 RP: I'll explain that too Jan 03 14:22:22 gnn. it's the one from pastebin. Jan 03 14:22:35 Regardless of what we plan to do in the future, pH5's patches need to be applied, the sooner, the better IMO. Does anyone object to that (providing it is the one from pastebin)? Jan 03 14:22:50 For the moment these changes should be reverted too: Jan 03 14:23:03 ipkg e16cffcf452086640211ee23d9ec8188163f1b83 Jan 03 14:23:40 sysfsutils 97dc9b1bab1e50b43f23ce37062529fa51c369c9 (not sure about this one, but something seems to have got lost) Jan 03 14:23:49 jbowler: reverting is going to need to be done manually by diff as monotone disapprove appears to just totally trash your local repository :-/ Jan 03 14:24:26 RP: which patches exactly? I haven't received anything from oe@ yet if that's where pH5 has sent them :/ Jan 03 14:24:35 Eh? Want me to try that? It's worked before for me. Jan 03 14:24:51 glib: b10c7a501f6606abe1b6a425dbb75912e858ae9f Jan 03 14:25:05 jbowler: it apparently depends on whether anything was merged since the changes were added Jan 03 14:25:06 binutils: 97eb37ffc8cf19126ddc1bb342fc10727fecf64a Jan 03 14:25:18 RP: I have no merges since any of those revisions Jan 03 14:25:31 Want me to try...? Jan 03 14:25:55 Incidentally, I am in sync with ewi too. Jan 03 14:26:04 jbowler: I'm not sure its worth the risk - a diff might be safer - up to you though... Jan 03 14:26:23 Ok, I'll copy my db first then monotone-viz/difftree the result. Jan 03 14:26:31 jbowler: ok Jan 03 14:27:13 What with my local db being corrupted and the power failures taking out my persistent desktop, I'm not doing well today :) Jan 03 14:28:01 reenoo_: The mail was addresses to you and me with oe@ as the cc: Jan 03 14:28:15 Disapprove does produce an immediate branch/merge from the disapproved revision, so you have to be careful... Jan 03 14:28:37 I.e. IIRC it should be done LIFO Jan 03 14:29:38 I'm going to take out libgphoto2 because that shows up in my list of diffs - revision 40cd64edf16241a37663807e311fba8e23f0d258 in addition to the above. Jan 03 14:31:15 RP: that's a bit odd. haven't received anything. nothing in spam or virus folders either... Jan 03 14:34:43 RP: I remember how to do it now (having just reverted three revisions) - it's necessary to run monotone-viz and do the merges by direct specification of the revisions to avoid a spider web. Jan 03 14:34:45 reenoo_: I've forwarded them - hh.org doesn't appear to have seen them yet either as they're not in the list archives Jan 03 14:35:30 jbowler: That figures. Who knows what state my local db is in now :-/ Jan 03 14:36:33 every disapprove creates a new head, so it's in hydra state ;-) Jan 03 14:37:21 Pull the snapshot from OE, start again... Jan 03 14:37:45 (If in doubt, cp the db and hack on that - this is what I'm doing at the moment.) Jan 03 14:38:06 jbowler: Indeed :) Jan 03 14:59:20 RP, renoo, pH5: you guys don't want the changes to remove do_stage, correct? I.e. revision 7de90a055904c4af8890dd5ae8c192bfd41b3fa1 should go? Jan 03 14:59:43 (It's a lot easier to revert the revisions I did if I also remove those changes, and they are no-ops in both worlds.) Jan 03 15:00:14 Sorry, wrong rev number... let me look: Jan 03 15:00:43 jbowler: fwiw, I'd still like all changes in question to be reverted until you've described your plans and we've come to a conclusion. the changes aren't lost. we can re-apply them any time. Jan 03 15:00:53 I mean: fbc22e245906dac5ce180f67a0c621f7a2db1a28 "remove redundant do_stage" Jan 03 15:01:04 jbowler: yeah, those have to go as well Jan 03 15:01:36 reenoo_: eh, well, like I said before... Jan 03 15:01:56 jbowler: Yes, they can go too. I think pH5 can rediff accordingly Jan 03 15:02:24 reenoo_, RP: did you get a look at my diffs? Jan 03 15:02:36 pH5: fine with me... Jan 03 15:02:44 reenoo_: I forwarded the mails to you btw Jan 03 15:03:31 pH5, RP: not sure what's going on here. I haven't received any mail in ages. maybe there's something wrong with my mail provider. Jan 03 15:03:32 pH5: You might want to hold off commiting until jbowler is finished as you're going to conflict (or just hold off diff 3) Jan 03 15:04:23 no problem, I'll commit when everyone is satisfied. Jan 03 15:06:14 I'll be back in a bit. At present I have those revs I listed removed plus the do_stage one. If you want them all to go it will take about 24 hours probably (because it is rev-by-rev by hand). Jan 03 15:13:04 tmbinc, ?? Jan 03 15:19:52 Nix-niX: hm? Jan 03 15:20:50 can join #nixkapirtsnicht Jan 03 15:57:34 03tmbinc 07org.oe.dreambox * rdc98c6c1... 10/packages/python/ (6 files in 2 dirs): remove manually merged files to workaround monotone bug #13831 Jan 03 15:57:40 03tmbinc 07org.oe.dreambox * rd4315873... 10/packages/enigma2/enigma2.bb: enigma2: update enigma2 Jan 03 16:20:04 kergoth: Your idea about changing staging has a flaw - think about binaries like libtool being searched for in staging/bin :-/ Jan 03 16:22:39 mm, is libtool needed during staging? Jan 03 16:23:23 iirc, most packages' "make install" rules don't involve calling libtool again. Jan 03 16:24:14 in any case, you could override PATH to point back to the "real" staging area. Jan 03 16:24:28 RP: 99% of all packages use libtool as generated by their configure scripts, not the one we installed into staging with libtool-cross Jan 03 16:24:36 afaik just specific cases like libjpeg do the latter Jan 03 16:25:36 'night all Jan 03 16:26:03 kergoth: Why did I choose libjpeg to play with :) Jan 03 16:26:13 haha Jan 03 16:26:16 murphy Jan 03 16:26:33 typical... Jan 03 16:26:36 good night Jan 03 16:28:25 pb_: The path is hardcoded from $STAGING_BINDIR so PATH won't help. I've just picked a bad choice of package (although one I did want to test) Jan 03 16:30:58 I don't think there's any good reason for the package to be specifying a full path to binaries in the staging directory. That should probably be removed. Jan 03 16:31:56 pb_: they want to hire me! woot. Jan 03 16:31:57 :D Jan 03 16:32:06 kergoth: awesome! congratulations. Jan 03 16:32:06 nice Jan 03 16:32:46 :) thanks Jan 03 16:33:01 kergoth: excellent! (which company is this?) Jan 03 16:33:19 a company out in arizona thats working on land warrior (wearable computing for soldiers) Jan 03 16:33:20 cool stuff Jan 03 16:33:42 wow Jan 03 16:33:44 X reset on me Jan 03 16:33:44 very cool :) Jan 03 16:34:16 yeah, x resets rule. Jan 03 16:44:30 RP: I have a db now without the changes to binutils,ipkg,glib-2.0,gphoto2, sysfsutils and with the previously remove package do_stage, what's the conclusion? Should I sync this to ewi? Jan 03 17:06:37 jbowler: yes please Jan 03 17:08:21 RP: ok, I'm doing an incremental build to double check, since it is a revert it shouldn't be dropping anything from staging. I've bumped all the relevant PRs. Jan 03 17:08:36 (So that's a double bump, to ensure no one gets left with missing staging files). Jan 03 17:26:44 hello Jan 03 17:27:04 i'm trying to build an openzaurus distro Jan 03 17:27:16 and i have the following error with glibc: Jan 03 17:27:19 http://pastebin.com/489463 Jan 03 17:27:52 anybody have an idea of what's going wrong? Jan 03 17:47:38 http://zoo.weinigel.se/n30/downloads/glibc.patch Jan 03 17:47:48 hhhcz: Yes, there was a post to the oe mailing list about how to solve that Jan 03 17:48:06 a bit late maybe. apply that patch and all will be well. the patch contains a reference to the mailing list discussions. Jan 03 17:48:39 wingel: Has that patch been applied? Jan 03 17:49:08 no, I haven't really submitted it to anyone. Jan 03 17:51:59 I ought to do that I guess. :-) Jan 03 17:52:08 I'll apply it to .dev if you like... Jan 03 17:52:36 yes please. Jan 03 17:53:42 thanks wingel :) Jan 03 17:54:01 * wingel goes back to hacking USB firmware Jan 03 17:55:35 that's interesting! a firmware for which device? Jan 03 17:56:43 I'm just playing around with a Cypress FX2 chip. I'm really supposed to write a Linux driver for a device which uses that chip, but I don't have access to the real device, so right now I'm trying to write a test firmware for the chip. Jan 03 17:57:30 it's a really nice toy really, a Intel8051 processor with a USB2 interface. firmware is downloaded into the chip from the USB host, so it's a wonderful platform for hacking USB. Jan 03 17:57:54 i have bought an fx2+fpga card to play with :) Jan 03 17:58:02 indeed it's a very nice part Jan 03 17:58:06 Opal Kelly? Jan 03 17:58:09 yap Jan 03 17:58:11 yep Jan 03 17:58:29 I've got two of those too. I haven't had time to play much with them yet, but they look nice. Jan 03 17:58:41 i was the most interesting at the time i searched for such card Jan 03 17:58:59 unfortunately their firmware is closed source Jan 03 17:59:14 so i started to write my own Jan 03 18:00:03 yes, but it shouldn't be too hard to write a xilinx FPGA programmer. I've ported xilinx own playsvf stuff to two platforms so far, and I've written my own SVF JTAG programmer for both Xilinx and Altera chips. Jan 03 18:03:27 hhhcz: so how far have you come? Jan 03 18:03:57 in my firmware? Jan 03 18:04:51 i can download the fpga programming file Jan 03 18:05:39 i have not yet implemented any i/o between the fpga and usb for using after fpga download Jan 03 18:05:58 but i will be easy to add some basic i/o Jan 03 18:06:45 the hard part will be to get full speed streaming transferts working i gess Jan 03 18:07:17 are you using Keil or SDCC for the programming? Jan 03 18:07:34 Keil has a lot of nice tools to define waveforms, I think that'll be the hardest part. Jan 03 18:07:36 sdcc Jan 03 18:08:00 and the cypress tool to define the waveforms Jan 03 18:08:22 altough i find it not very intuitive Jan 03 18:08:55 it's almost easyer to define them by hand, with the reference manual Jan 03 18:09:45 are you working for a hardware manufacturer company? Jan 03 18:09:54 ok. I haven't come that far yet. I bought the Opal Kelly board before summer, but it's still in the antistatic bag. Jan 03 18:10:07 yes and no. I work as a freelance consultant. so it depends. Jan 03 18:10:25 i'm playing with it on my free time Jan 03 18:10:56 the FX2 stuff is for a customer that mainly writes software but they need an I/O interface to gather data. Jan 03 18:11:05 i hope to find a job in hardware design one day... Jan 03 18:11:49 I think it's a good niche job. There aren't all that many hardware jobs, but on the other hand, there are even fewer people who are good at it. Jan 03 18:12:25 I'm a programmer, not a hardware designer, but I can understand and review hardware. So I'm doing a lot of programming close to the hardware and in close cooperation with hardware designers. Jan 03 18:12:54 i have a degree in hardware design, but it was a lot more easyer to find a job in software programming after i graduated Jan 03 18:14:47 tough. it's always hard to find those jobs. Jan 03 18:16:52 03rpurdie 07org.oe.dev * rd5e1bc9b... 10/packages/glibc/glibc_2.3.5+cvs20050627.bb: glibc 2.3.5-cvx20050627: Add hack to work around the CVS breakage of the upstream repository Jan 03 18:17:40 RP: thanks Jan 03 18:25:25 RP: those changes are synced to ewi now. Jan 03 18:25:36 Revision ece0a6a55e4dd79fcabf7867d390f3eb6f6190af Jan 03 19:17:58 mickey|dinner: I'm finding that the fixed gnu-config URI (sv instead of savannah) doesn't work for me, it 404's with the following: Jan 03 19:17:59 NOTE: Update cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=20050701 Jan 03 19:18:00 CVS moved to cvs.savannah.[non]gnu.org Jan 03 19:18:00 Check http://savannah.gnu.org/forum/forum.php?forum_id=4168 for details. Jan 03 19:18:00 Anonymous access over SSH is replaced by the (more efficient) pserver. Jan 04 00:14:43 morning Jan 04 00:36:14 hi guys.. Jan 04 00:36:43 im looking for advices please Jan 04 00:37:02 i need cheep SBC support linux Jan 04 01:58:20 morning all Jan 04 02:00:02 good morning RP Jan 04 02:01:31 can i advice me a low cost SBC? Jan 04 02:02:12 SBC? Jan 04 02:02:19 **can u advice me a low cost SBC? Jan 04 02:02:27 Single Board Computer Jan 04 02:03:28 ahh Jan 04 02:03:40 linnuxxy: the loft looks okay Jan 04 02:03:42 linnuxxy: Not really. There are to many options available... Jan 04 02:04:12 a PDA which supports linux is also an idea Jan 04 02:04:19 ethernet no vedio and abt 50$ Jan 04 02:04:20 so are the Linux routers/NAS out there Jan 04 02:04:54 linnuxxy: maybe a Linksys wrt router? Jan 04 02:06:57 i belive you can pick one up for like $US33 Jan 04 02:07:09 Linksys does not sale SBC Jan 04 02:07:20 i believe Jan 04 02:07:54 linnuxxy: A linux router would turn into a good SBC though, as mithro says... Jan 04 02:09:23 linnuxxy: you arn't going to get a "real" SBC for that price, so you'll have to use some consumer hardware instead Jan 04 02:10:50 ok... how can i develop for this router.. does it support ssh? console? Jan 04 02:14:18 linnuxxy: they are linux boxes, just on a smaller scale Jan 04 02:15:47 i know.. does ssh or serial access to the linux is enable by default? Jan 04 02:16:04 did any1 here hacked these things? Jan 04 02:20:30 morning Jan 04 02:29:01 03jbowler 07org.oe.dev * r4971f280... 10/packages/binutils/ (3 files): disapproval of revision '97eb37ffc8cf19126ddc1bb342fc10727fecf64a' Jan 04 02:29:07 03jbowler 07org.oe.dev * r36675cca... 10/packages/glib-2.0/ (glib-2.0-native_2.6.5.bb glib-2.0_2.8.2.bb): disapproval of revision 'b10c7a501f6606abe1b6a425dbb75912e858ae9f' Jan 04 02:29:11 03jbowler 07org.oe.dev * r662a6178... 10/packages/binutils/ (3 files): Jan 04 02:29:12 explicit_merge of '4971f280898b867f9204503887a01d98da03a5fe' Jan 04 02:29:12 and '36675cca3be4193a8fa55cfa1dba9a78038b7d92' Jan 04 02:29:12 using ancestor '' Jan 04 02:29:12 to branch 'org.openembedded.dev' Jan 04 02:29:16 03jbowler 07org.oe.dev * r00f00d3a... 10/packages/sysfsutils/sysfsutils_1.3.0.bb: disapproval of revision '97dc9b1bab1e50b43f23ce37062529fa51c369c9' Jan 04 02:29:20 03jbowler 07org.oe.dev * r2ca40160... 10/packages/ (10 files in 6 dirs): Jan 04 02:29:20 explicit_merge of '662a617882f791ea9f9ca8aa0bd50f264d6c1db7' Jan 04 02:29:20 and '00f00d3a48aefe68a725e5e07c63fd5910f1b995' Jan 04 02:29:21 using ancestor '' Jan 04 02:29:23 to branch 'org.openembedded.dev' Jan 04 02:29:25 03jbowler 07org.oe.dev * rf0ed2703... 10/packages/ipkg/ (ipkg.inc ipkg_0.99.152.bb ipkg_0.99.153.bb ipkg_0.99.154.bb): disapproval of revision 'e16cffcf452086640211ee23d9ec8188163f1b83' Jan 04 02:29:31 03jbowler 07org.oe.dev * r67a7cd19... 10/packages/ (9 files in 6 dirs): Jan 04 02:29:33 explicit_merge of '2ca40160bd8dc53bfb886ca5453a2b26f9e2d358' Jan 04 02:29:35 and 'f0ed2703d9e7b7eeb29d9af8f8d842cef8e8a97a' Jan 04 02:29:37 using ancestor '' Jan 04 02:29:39 to branch 'org.openembedded.dev' Jan 04 02:29:43 03jbowler 07org.oe.dev * rd4bebe8b... 10/packages/libgphoto2/libgphoto2_2.1.6.bb: disapproval of revision '40cd64edf16241a37663807e311fba8e23f0d258' Jan 04 02:29:46 03jbowler 07org.oe.dev * rff8f93bf... 10/packages/ (17 files in 12 dirs): Jan 04 02:29:48 explicit_merge of '67a7cd199ed48c512b8405c701f22fe1fd94bd17' Jan 04 02:29:50 and 'd4bebe8bd4a495c716a9547b0a5aabad739ab5b8' Jan 04 02:29:52 using ancestor '' Jan 04 02:29:54 to branch 'org.openembedded.dev' Jan 04 02:29:57 03jbowler 07org.oe.dev * rd8cdf621... 10/ (15 files in 9 dirs): Jan 04 02:29:58 explicit_merge of 'ff8f93bf075f5225452de6de0f7feb3aa1174889' Jan 04 02:30:00 and 'c47b56a3ef9d7d425411c60ff6fef2a174b20ea6' Jan 04 02:30:02 using ancestor '' Jan 04 02:30:04 to branch 'org.openembedded.dev' Jan 04 02:30:12 03jbowler 07org.oe.dev * r11923cb9... 10/packages/ (15 files in 15 dirs): disapproval of revision 'fbc22e245906dac5ce180f67a0c621f7a2db1a28' Jan 04 02:30:19 morning Jan 04 02:30:48 03jbowler 07org.oe.dev * r12e4d92e... 10/packages/ (9 files in 4 dirs): Jan 04 02:30:49 explicit_merge of 'd8cdf62120af403fb6e212a637f07ee6bec94b05' Jan 04 02:30:49 and '11923cb95e906cb69ddced31b2fe3e5a10ab53b0' Jan 04 02:30:49 using ancestor '' Jan 04 02:30:49 to branch 'org.openembedded.dev' Jan 04 02:30:53 hi hrw|work Jan 04 02:31:01 03jbowler 07org.oe.dev * r9d518c78... 10/packages/ (28 files in 23 dirs): Jan 04 02:31:02 explicit_merge of '12e4d92e98860b8d7e48bdb73bfd9efb0e0a7c21' Jan 04 02:31:02 and '7de90a055904c4af8890dd5ae8c192bfd41b3fa1' Jan 04 02:31:02 using ancestor '' Jan 04 02:31:02 to branch 'org.openembedded.dev' Jan 04 02:31:10 03jbowler 07org.oe.dev * rece0a6a5... 10/packages/ (9 files in 5 dirs): binutils, glib, ipkg, libgphoto2, sysfsutils: bump PR Jan 04 02:31:21 hrw: OE built OZ last night, I wanna try my own custom kernel (user suspend off) Jan 04 02:31:35 i built the 255 kernel Jan 04 02:31:53 RP: I will change a bit 3100 install guide Jan 04 02:32:13 s/initrd.img/initrd.bin Jan 04 02:33:27 is there a similar project of the linksys linux for D-Link? Jan 04 02:33:35 hrw|work: oops, thanks - the c3000 may also need adjustment Jan 04 02:33:55 I updated the C3000 page with details on both 2.4 and 2.6 kernels as well Jan 04 02:44:56 RP: fixed as well Jan 04 02:45:57 hrw|work: Thanks for spotting that Jan 04 02:48:32 np Jan 04 02:48:59 so is it same on #oe yet? Jan 04 02:49:05 s/same/safe/ Jan 04 02:49:28 XorA: safe? Jan 04 02:49:39 email list was getting a little heated recently Jan 04 02:50:19 I think most people are in fact in agreement on most things Jan 04 02:52:54 hrw|work: does altboot support 2.6 c7x0 devices yet? Jan 04 02:53:27 XorA: dont know Jan 04 02:55:43 i have Linksys BEFSR81 router ... can i install linux on it and then develop my own apps? **** ENDING LOGGING AT Wed Jan 04 02:59:57 2006