| 00:08.51 | *** join/#oe Geo_KM (n=keith@bh02i525f01.au.ibm.com) |
| 00:14.19 | jsun_ | cool - DISTRO=familiar worked! |
| 00:15.28 | *** join/#oe dkey| (n=dkey@L0001P13.dipool.highway.telekom.at) |
| 00:15.54 | florian | hmm... i'd suggest to use familiar-unstable instead |
| 00:17.09 | jsun_ | florian, unfortunately that one failed. :( |
| 00:18.01 | *** join/#oe wrobbie (n=rob@cm17.sigma183.maxonline.com.sg) |
| 00:27.47 | florian | jsun: oops |
| 00:28.59 | CIA-2 | 03pH5 07org.oe.dev * rc1e403c3... 10/packages/tslib/tslib_cvs.bb: tslib_cvs: add support for blueangel, closes #516 |
| 00:32.53 | *** join/#oe Geo_KM (n=keith@bh02i525f01.au.ibm.com) |
| 01:17.33 | *** join/#oe tmbinc (i=XXX@dslb-082-083-086-153.pools.arcor-ip.net) |
| 01:21.04 | *** join/#oe molivier (n=omougin@d05m-213-44-28-24.d4.club-internet.fr) |
| 01:21.34 | *** part/#oe molivier (n=omougin@d05m-213-44-28-24.d4.club-internet.fr) |
| 01:22.31 | *** join/#oe Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
| 02:00.16 | *** join/#oe paran (n=fdafd@222.114.147.209) |
| 02:00.42 | paran | hello |
| 02:03.11 | *** join/#oe idealm (n=ideal@218.82.61.122) |
| 02:19.45 | *** join/#oe mrz80 (n=scotsman@n128-227-11-104.xlate.ufl.edu) |
| 02:27.58 | tmbinc | did anyone stumble across the "bits" directory, which recently appeared in the glibc CVS, and causes configure to fail? it looks like a server problem, as the "cvs content changed" (older checkouts, with the same CVSDATE, do not contain that directory) |
| 02:28.47 | tmbinc | or somebody tried to move a cvs directory in "the incorrect" (not that there were any correct) way |
| 03:06.43 | *** join/#oe mjc (n=mjc@c-66-176-174-150.hsd1.fl.comcast.net) |
| 03:14.33 | *** join/#oe gerwinin (n=gerwin@ip5457b30e.direct-adsl.nl) |
| 03:22.35 | *** join/#oe mjc (n=mjc@c-66-176-174-150.hsd1.fl.comcast.net) |
| 03:25.29 | gerwinin | I compiled a distri for epia boards anyone a suggestion for a name ? |
| 03:31.32 | emte | O-Sepia :P |
| 03:31.38 | *** join/#oe aquadran_ (i=pablo@scummvm/undead/aquadran) |
| 03:31.54 | gerwinin | emte good idea :) |
| 03:32.07 | gerwinin | Let me check if the domain is still free |
| 03:32.28 | emte | photo( |
| 03:32.31 | emte | ** |
| 03:32.55 | gerwinin | Maybe a stupid question but I want to release the sources as well any ideas what the best way is to do that ? |
| 03:33.10 | emte | that is how OE works ... |
| 03:33.22 | emte | or do you mean images>? |
| 03:33.44 | gerwinin | The images I have an idea I just made an image that you can put directly on the cf |
| 03:34.06 | emte | for release? |
| 03:34.17 | emte | now i am not sure what your asking |
| 03:34.48 | gerwinin | I was wondering if I should point people for the sources just at oe or that I should make an iso image for the sources |
| 03:35.09 | gerwinin | Do you get now a bit what I mean ? |
| 03:35.11 | emte | just at OE if you want development and maintainance help |
| 03:35.35 | emte | otherwise people will walk with it and possibly not recontribute |
| 03:35.53 | gerwinin | Okay good idea , I will release first the pabx and stunserver |
| 03:36.28 | gerwinin | the version with an xserver still needs some development and I need to choose if I want to go with opie , gpe or something else |
| 03:36.34 | emte | as for release type stuff you could ask france for a pointerpage from hh.org |
| 03:36.48 | gerwinin | Okay |
| 03:37.06 | emte | and whoever admins the OE page as well |
| 03:37.16 | emte | exposure always helps |
| 03:37.17 | *** join/#oe wrobbie (n=rob@cm17.sigma183.maxonline.com.sg) |
| 03:37.30 | gerwinin | Emte what is the best desktop environment to bundle you think ? (gpe, opie , or something else) |
| 03:37.54 | emte | both really ... |
| 03:38.06 | emte | there are dedicated fans to both opie and gpe |
| 03:38.17 | emte | gpe sorley needs more developers tho |
| 03:38.23 | emte | sorley* |
| 03:38.31 | emte | bah i still cant spell it |
| 03:38.38 | gerwinin | Yeah I am a bit worried with the mouse support |
| 03:38.51 | emte | ? |
| 03:38.58 | gerwinin | Because people mostly don't have the money to buy a touchscreen |
| 03:39.24 | gerwinin | Do opie and gpe both have support for hid based devices ? |
| 03:39.36 | emte | some level i bleive |
| 03:39.40 | emte | belive* |
| 03:39.53 | emte | how much i am unsure |
| 03:40.35 | gerwinin | I will check this because that is my biggest worry , as long as that is passed than it will be okay , because the other things I have already pretty much working |
| 03:42.19 | gerwinin | I am waiting now for my 19 inch mini-itx rack cases to come :) |
| 03:43.18 | emte | lol |
| 03:51.04 | *** join/#oe mjc (n=mjc@c-66-176-174-150.hsd1.fl.comcast.net) |
| 03:57.51 | *** join/#oe Geo_KM (n=keith@bh02i525f01.au.ibm.com) |
| 04:17.10 | france | emte: e-mail admin@handhelds.org or france@handhelds.org |
| 04:24.25 | *** join/#oe mjc_ (n=mjc@c-66-176-174-150.hsd1.fl.comcast.net) |
| 04:43.44 | *** join/#oe RP (i=1000@tim.rpsys.net) |
| 04:44.25 | *** join/#oe Geo_KM (n=keith@bh02i525f01.au.ibm.com) |
| 04:52.00 | *** join/#oe GeoKM (n=keith@bh02i525f01.au.ibm.com) |
| 05:33.38 | paran | does anybody know how to build libdvbpsi |
| 06:00.12 | emte | france, i think you mean gerwinin not i |
| 06:00.16 | *** join/#oe mjc (n=mjc@c-66-176-174-150.hsd1.fl.comcast.net) |
| 06:00.29 | emte | gerwinin, e-mail admin@handhelds.org or france@handhelds.org |
| 06:23.21 | *** join/#oe _david (n=david@dsl092-068-235.bos1.dsl.speakeasy.net) |
| 06:30.45 | *** join/#oe _law_ (n=law@mail.stiftadmont.at) |
| 07:33.30 | *** join/#oe koobla (n=Simon@wall4.soft.uni-linz.ac.at) |
| 07:36.44 | *** join/#oe gremlin[it] (n=gremlin@194-177-126-80.f4.ngi.it) |
| 07:43.43 | *** join/#oe alan|home (n=alan@ARouen-152-1-71-50.w83-202.abo.wanadoo.fr) |
| 08:14.42 | *** join/#oe dkey| (n=dkey@L0004P26.dipool.highway.telekom.at) |
| 08:15.31 | alan|home | morning |
| 08:22.05 | *** join/#oe ar_ (n=ar@port-ip-213-211-231-121.reverse.mdcc-fun.de) |
| 08:26.46 | *** join/#oe ar_ (n=ar@port-ip-213-211-231-121.reverse.mdcc-fun.de) |
| 08:28.59 | *** join/#oe theturtle (n=theturtl@guiness.lifl.fr) |
| 08:29.47 | df00z | hrw: you around? |
| 08:32.11 | *** join/#oe oce_ (i=nobody@kaivos.nette.fi) |
| 08:43.22 | *** join/#oe cedric (n=cedric@LAubervilliers-151-11-32-8.w193-251.abo.wanadoo.fr) |
| 09:01.03 | *** join/#oe greentux (n=m@ip-217-18-177-18.reverse.dsi.net) |
| 09:01.16 | *** join/#oe Timelord (n=TL@4.78.4.43) |
| 09:12.13 | RP | morning all |
| 09:13.32 | greentux | morning RP |
| 09:25.56 | *** join/#oe gints (n=gints@195.244.141.102) |
| 09:37.11 | greentux | ~seen lrg |
| 09:38.07 | ibot | lrg <n=liamg@212.20.225.130> was last seen on IRC in channel #oe, 10d 20h 45m 11s ago, saying: 'hey Spyro '. |
| 09:38.07 | greentux | ~seen lrg|home |
| 09:38.14 | ibot | lrg|home <n=liam@exize.demon.co.uk> was last seen on IRC in channel #oe, 1d 21h 11m 23s ago, saying: '~lart Stella Artois for my headache'. |
| 09:38.30 | *** join/#oe mithro (n=tim@dle92.neoplus.adsl.tpnet.pl) |
| 09:39.04 | hrw|work | morning |
| 09:39.08 | hrw|work | df00z: pong |
| 09:41.41 | *** join/#oe bam_ (n=bam@pool-71-108-67-15.lsanca.dsl-w.verizon.net) |
| 09:45.31 | df00z | Ah |
| 09:45.40 | df00z | Sup? I got your message earlier |
| 09:45.48 | df00z | i tried to build OZ 3.5.4 last night |
| 09:45.51 | df00z | it fails on glibc-cvs |
| 09:45.59 | df00z | | ./bits/endian.h:13:2: #error Machine byte order unknown. |
| 09:46.07 | df00z | NOTE: package glibc-2.3.5+cvs20050627-r1: task do_compile: started |
| 09:46.11 | df00z | ERROR: function do_compile failed |
| 09:46.12 | hrw|work | df00z: I prepared image for you already |
| 09:46.25 | hrw|work | df00z: you fscked someting in configuration |
| 09:46.29 | df00z | Right, I'll prolly try it out |
| 09:46.55 | df00z | distro = openzaurus-3.5.4 |
| 09:47.00 | df00z | should it just be "openzaurus" ? |
| 09:47.14 | df00z | Err, whoops |
| 09:47.19 | df00z | machine = collie supposed to be poodle |
| 09:47.31 | NAbyss | df00z: there's a patch you need for it.. let me dig up the url |
| 09:47.37 | NAbyss | I had the same issue 2 days ago |
| 09:47.41 | df00z | Ah |
| 09:47.47 | NAbyss | http://zoo.weinigel.se/n30/downloads/glibc.patch |
| 09:47.59 | NAbyss | then just: |
| 09:48.09 | NAbyss | cd org.openembedded.dev/ && patch -p1 < ../glibc.patch |
| 09:48.21 | df00z | thanks |
| 09:48.24 | NAbyss | np |
| 09:48.43 | NAbyss | I'm still trying to get the bugger going with 2.6.. it's somewhat of a challenge. |
| 09:48.55 | df00z | What machine? |
| 09:48.59 | hrw|work | df00z: use openzaurus-unstable or better use branch |
| 09:49.26 | df00z | hrw: kk |
| 09:50.06 | NAbyss | df00z: c3100.. borzoi |
| 09:50.28 | hrw|work | mickey|dinner: oz 3.5.4 conf in branch has 3.5.3 in feed_uris? |
| 10:12.12 | *** join/#oe do13_ (i=do13@antilope.in-berlin.de) |
| 10:12.18 | do13_ | morning all |
| 10:12.45 | hrw|work | hi Dirk |
| 10:13.09 | do13_ | hey marcin |
| 10:14.05 | do13_ | RP: ping |
| 10:15.08 | *** join/#oe ade|desk (n=adavey@194.200.143.249) |
| 10:19.00 | *** join/#oe zinga (n=arnaudb@186.80-203-227.nextgentel.com) |
| 10:21.29 | *** join/#oe mithro (n=tim@dle92.neoplus.adsl.tpnet.pl) |
| 10:22.35 | ade|desk | morning all |
| 10:24.07 | RP | do13_: pong |
| 10:25.32 | do13_ | RP: morning. I have a small patch for sharpsl_pm. http://www.do13.de/oz/temp/sharpsl_pm-do-r0.patch |
| 10:27.27 | RP | do13_: That looks good to me. Does this mean you're making progress with tosa pm/charging? |
| 10:28.03 | do13_ | RP: First steps. I hope this doesn't breaks corgi and friends. |
| 10:29.50 | RP | 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 : |
| 10:29.52 | RP | :) |
| 10:30.05 | do13_ | :) |
| 10:30.52 | RP | do13_: Does tosa's battery levels actually differ for the bl and none bl case? |
| 10:31.16 | RP | I know the c7x0 had code for this but the actual data structures had the same values so I ended up merging them... |
| 10:31.31 | do13_ | RP: Yep. It's different. also on poodle |
| 10:31.53 | alan|home | RP: did you find what is wrong with matchbox-wm_svn ? i didn't |
| 10:31.58 | do13_ | RP: SHARPSL_CHARGE_ON_VOLT and others are different on tosa, I'll move these into sharpsl_pm.machinfo |
| 10:33.10 | RP | do13_: ok, that sounds good. Does tosa use a different battery out of interest? |
| 10:33.50 | RP | 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) |
| 10:34.56 | do13_ | RP: tosa has another battery and another ADC (maybe other Vref) so the values are different |
| 10:35.00 | alan|home | the 750 has a 950mAh flat battery. I think the same as 700 |
| 10:35.25 | hrw|work | 5500/700/750 has 950mAh, 5600/760/860 has 1700mAh iirc |
| 10:35.26 | RP | alan|home: I'm afraid I never understood you svn issue |
| 10:35.40 | gints | moin |
| 10:35.42 | CIA-2 | 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. |
| 10:35.47 | CIA-2 | 03jbowler 07org.oe.dev * r97eb37ff... 10/packages/binutils/ (3 files): binutils: change do_stage to use autotools_stage_all in binutils.inc |
| 10:35.52 | CIA-2 | 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): |
| 10:35.53 | CIA-2 | glib: change to use autotools_stage_all in native 2.6.5 and 2.8.2 |
| 10:35.53 | CIA-2 | <PROTECTED> |
| 10:35.53 | CIA-2 | <PROTECTED> |
| 10:35.57 | CIA-2 | 03jbowler 07org.oe.dev * r7170376c... 10/packages/jpeg/ (jpeg-6b/install.patch jpeg-native_6b.bb jpeg_6b.bb): |
| 10:35.57 | CIA-2 | jpeg: change to use autotools_stage_all in 6b |
| 10:35.57 | CIA-2 | <PROTECTED> |
| 10:35.59 | CIA-2 | <PROTECTED> |
| 10:36.01 | CIA-2 | <PROTECTED> |
| 10:36.03 | CIA-2 | 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 |
| 10:36.08 | CIA-2 | 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 |
| 10:36.12 | CIA-2 | 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 |
| 10:36.16 | CIA-2 | 03jbowler 07org.oe.dev * rc6edb078... 10/packages/ (5 files in 4 dirs): |
| 10:36.16 | CIA-2 | setpwc, mdadm, wakelan, xinetd: inhibit autotools staging (not required) |
| 10:36.18 | CIA-2 | <PROTECTED> |
| 10:36.20 | CIA-2 | <PROTECTED> |
| 10:36.22 | CIA-2 | <PROTECTED> |
| 10:36.24 | CIA-2 | <PROTECTED> |
| 10:36.26 | CIA-2 | 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): |
| 10:36.29 | CIA-2 | ipkg: change do_stage to use autotools_stage_all in ipkg.inc |
| 10:36.31 | CIA-2 | <PROTECTED> |
| 10:36.33 | CIA-2 | <PROTECTED> |
| 10:36.35 | CIA-2 | 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 |
| 10:36.38 | CIA-2 | 03jbowler 07org.oe.dev * r5dc2d236... 10/packages/puppy/puppy_1.11.bb: puppy: inhibit autotools stage in puppy 1.11 |
| 10:36.41 | CIA-2 | 03jbowler 07org.oe.dev * r068f4de8... 10/packages/popt/popt_1.7.bb: popt: change do_stage to use autotools_stage_all in 1.7 |
| 10:36.44 | CIA-2 | 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 |
| 10:36.47 | CIA-2 | 03jbowler 07org.oe.dev * rd53f3239... 10/packages/nfs-utils/nfs-utils_1.0.6.bb: nfs-utils: inhibit autotools stage in 1.0.6 |
| 10:36.50 | CIA-2 | 03jbowler 07org.oe.dev * r1c28b19a... 10/packages/ncftp/ncftp_3.1.9.bb: ncftp: inhibit autotools stage in 3.1.9 |
| 10:36.53 | CIA-2 | 03jbowler 07org.oe.dev * r71628c75... 10/packages/lzo/lzo_1.08.bb: lzo: change do_stage to use autotools_stage_all in 1.08 |
| 10:36.56 | CIA-2 | 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 |
| 10:36.59 | CIA-2 | 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 |
| 10:37.04 | CIA-2 | 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 |
| 10:37.05 | gints | patch rain |
| 10:37.08 | CIA-2 | 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 |
| 10:37.12 | CIA-2 | 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 |
| 10:37.16 | CIA-2 | 03jbowler 07org.oe.dev * rc47b56a3... 10/ (3 files in 2 dirs): slugos-packages: add klibc to build (meta package) |
| 10:37.20 | CIA-2 | 03pH5 07org.oe.dev * rfbc22e24... 10/packages/ (15 files in 15 dirs): autotooled packages: remove redundant do_stage |
| 10:37.25 | CIA-2 | 03pH5 07org.oe.dev * rcd6d972f... 10/packages/gpe-autostarter/ (2 files in 2 dirs): gpe-autostarter-0.11: dbus-0.60 support |
| 10:38.00 | alan|home | RP: well... there may be an error in the bb file as i cannot retrieve sources when bitbaking matchbox-wm_svn.bb |
| 10:39.04 | df00z | NAbyss: its still giving me that error, do i need to bitbake clean glibc? |
| 10:39.11 | df00z | glibc-2.3.5+cvs20050627-r1 |
| 10:40.38 | do13_ | 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) |
| 10:41.16 | *** join/#oe zap (n=zap@217.170.93.196) |
| 10:43.32 | RP | 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 |
| 10:43.36 | RP | (rather than apm) |
| 10:45.05 | RP | unless we can handle tosa as a special case some other way... (is the charging code similar enough to warrent the array?) |
| 10:46.27 | RP | alan|home: I think others would be reporting the problem if the issue as in the .bb file? |
| 10:47.22 | hrw|work | RP: do we have any example how to use git fetcher? |
| 10:47.47 | hrw|work | NOTE: package linux-openzaurus-2.6.15-r0: task do_patch: completed |
| 10:48.16 | RP | hrw|work: I have an openzaurus-it .bb file... |
| 10:48.58 | CIA-2 | 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 |
| 10:49.12 | hrw|work | RP: I would like to create linux-collie_2.6-git.bb |
| 10:49.48 | RP | hrw|work: http://www.rpsys.net/openzaurus/temp/linux-openzaurus_git.bb is an example from a while back |
| 10:50.19 | hrw|work | thx |
| 10:52.00 | do13_ | RP: Tosa has 2 different batteries: main / jacket battery and backup battery. Main and jacket battery can be independenly charged |
| 10:52.43 | NAbyss | df00z: yeah, you'll need to clean it up |
| 10:52.54 | RP | do13_: What I mean is whether the chargers and battery reading methods are similar enough to fit the same framework or not? |
| 10:53.38 | hrw|work | NOTE: package linux-openzaurus-2.6.15-r0: task do_build: completed |
| 10:54.31 | hrw|work | RP: how does hh.org kernel resolved it? they have ipaq with external jackets (maybe not in 2.6 yet) |
| 10:55.37 | *** join/#oe alan|xchat (n=alan@ARouen-152-1-94-104.w86-199.abo.wanadoo.fr) |
| 10:56.09 | do13_ | RP: Yep. battery reading uses the same method for all three batteries (backup battery needs no temp measurement). |
| 10:56.28 | do13_ | RP: If I have basic tosa pm/charging we can think about multiple batteries. :) |
| 11:01.07 | RP | do13_: Agreed. Getting the main one working first would be good :) |
| 11:01.26 | RP | We're slowly heading into the position of needing to replace apm... |
| 11:03.39 | RP | I hadn't realised 2.6.15 was out. Time to start merging things I guess... |
| 11:03.57 | hrw|work | RP: small mmc changes after rc7 |
| 11:04.51 | CIA-2 | 03pH5 07org.oe.dev * r886d4fc3... 10/packages/linux/handhelds-pxa-2.6_cvs.bb: handhelds-pxa-2.6: empty kernel-image package for hx4700 |
| 11:08.09 | RP | hrw|work: I don't think the pxa can handle 1024 block size cards anyway... |
| 11:21.47 | *** join/#oe cedric (n=cedric@LAubervilliers-151-11-32-8.w193-251.abo.wanadoo.fr) |
| 11:26.22 | *** join/#oe hrw|work (n=hrw@host-ip170-158.crowley.pl) |
| 11:30.02 | hrw|work | RP: 2.6.15 booted on my husky |
| 11:33.43 | hrw|work | shit.. by mistake I put 1G card into collie and 64M one into husky case... |
| 11:38.21 | df00z | heheh |
| 11:39.50 | RP | hrw|work: I'd be interested to know if sound is working - I tested c3000 with 2.6.15-rc7 but not c760 yet |
| 11:43.38 | hrw|work | RP: speaker works |
| 11:43.59 | hrw|work | aplay u8_m22050 |
| 11:44.34 | RP | hrw|work: That's good :). Hoepfully it will auto mute when you insert headphones... |
| 11:44.50 | RP | Eventually userspace will have that control but that's not happening quite yet |
| 11:47.22 | hrw|work | hmm.. opie-alsamixer.... |
| 11:49.30 | RP | hrw|work: We're going to need something like that soon enough :) |
| 11:51.39 | NAbyss | 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) |
| 11:52.31 | RP | NAbyss: That's intentional |
| 11:53.20 | NAbyss | RP: Ah.. is 2.6 known to boot on the 3100? Mine fades to white shortly after the console stuff scrolls past |
| 11:53.41 | RP | NAbyss: Did you use a kernel from the branch or .dev? |
| 11:53.46 | NAbyss | RP: .dev |
| 11:54.00 | RP | 2.6 should work fine on the 3100 :-/ |
| 11:54.27 | NAbyss | Hmm.. I'll try building the image again |
| 11:54.27 | RP | Was it a bootstrap image? I've heard reports of them being prone to doing that... |
| 11:54.48 | NAbyss | Twas opie-kdepim-image, IIRC |
| 11:55.28 | RP | It does this on every boot or did you just boot it once? |
| 11:56.10 | NAbyss | 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 |
| 11:57.38 | RP | Which kernel version is this? |
| 11:57.51 | RP | The empty flash messages should be harmless... |
| 11:58.08 | NAbyss | linux-openzaurus_2.6.14+2.6.15-rc5.bb |
| 11:58.44 | RP | I'd try reflashing and reloading hdimage1.tgz onto the microdrive... |
| 11:59.52 | NAbyss | okies.. just to clarify, which targets should I be building for the 3100? |
| 12:00.23 | NAbyss | oz.org doesn't have all that much detail on the 3100, only the 3000 |
| 12:06.05 | RP | You need an hdimage1.tgz, zimage.bin and updater.sh |
| 12:06.11 | RP | You don't need an initrd.bin |
| 12:06.19 | NAbyss | ahh, that'd do it then |
| 12:06.36 | RP | no hdimage1.tgz? |
| 12:06.41 | NAbyss | I had it the other way around |
| 12:06.50 | NAbyss | initrd, but no hdimage |
| 12:06.56 | RP | That wouldn't work :) |
| 12:07.09 | NAbyss | Yeah.. worked for 2.4, but not .6 :) |
| 12:07.15 | RP | Where are the confusing instructions? |
| 12:07.28 | RP | 2.6 is very different |
| 12:07.39 | NAbyss | 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 |
| 12:07.55 | NAbyss | Was using that as a vague guide.. I've a friend with a C3000 talking me through it |
| 12:07.55 | RP | You might need repartition the microdrive to get 2.6 working btw |
| 12:08.25 | NAbyss | Yeah, I just noticed that article.. any suggestion as to size? |
| 12:08.28 | NAbyss | 100mb-ish? |
| 12:08.32 | RP | yes |
| 12:08.41 | RP | its needs to fit your rootfs |
| 12:10.45 | NAbyss | Should I keep the 3 partitions? If so.. what's the second used for? |
| 12:11.00 | RP | The second becomes /home |
| 12:11.11 | RP | The third becomes /media/hdd |
| 12:11.18 | NAbyss | ahh |
| 12:11.33 | RP | Or you can merge them and use a custom fstab... |
| 12:12.11 | NAbyss | Yeah, I'm thinking it might be best to keep it relatively standard |
| 12:12.21 | RP | Its usually easier... |
| 12:13.15 | NAbyss | Yeah |
| 12:15.18 | hrw|work | someone know simple small alsa mixer? amixer is 50K code |
| 12:18.36 | hrw|work | http://www.oesf.org/forums/index.php?showtopic=16884 - someone want use pdax as base for prototype devboard... |
| 12:22.41 | *** join/#oe cedric (n=cedric@LAubervilliers-151-11-32-8.w193-251.abo.wanadoo.fr) |
| 12:22.58 | do13_ | RP: On corgi headphone detection is send via keyboard driver to userspace? |
| 12:25.50 | *** join/#oe linnuxxy (n=dave@210.5.196.22) |
| 12:26.29 | RP | do13_: That's the idea although I think the hooks in the sound driver have been accidently removed by lrg |
| 12:26.44 | linnuxxy | i need an embedded web server ... should support server side script? any recommandations? |
| 12:26.48 | RP | do13_: I'll probably move the switch detection code into the input driver eventually |
| 12:27.10 | linnuxxy | ssl is prefered also |
| 12:27.34 | hrw|work | linnuxxy: thttpd, boa, tiny-httpd? |
| 12:28.13 | linnuxxy | which one do u recommand? |
| 12:28.54 | linnuxxy | i think boa does not support server side scripting?! |
| 12:30.02 | *** join/#oe reenoo_ (n=r@p5489D8C3.dip.t-dialin.net) |
| 12:30.10 | reenoo_ | morning |
| 12:30.15 | RP | hi reenoo_ |
| 12:30.23 | reenoo_ | hey RP |
| 12:30.42 | *** join/#oe mrz80 (i=1000@caledonia.cns.ufl.edu) |
| 12:33.34 | linnuxxy | what about hydra web server? |
| 12:33.38 | linnuxxy | is it ok? |
| 12:36.21 | hrw|work | linnuxxy: I cannot recommend. |
| 12:36.45 | *** join/#oe idealm (n=ideal@218.82.61.122) |
| 12:37.05 | *** join/#oe zecke (n=freyther@essen.mi.fu-berlin.de) |
| 12:37.43 | pb__ | hail zecke |
| 12:38.11 | zecke | hey |
| 12:38.18 | *** join/#oe CIA-4 (i=cia@flapjack.navi.cx) |
| 12:38.22 | zecke | Fear my Mickeyl-Mouse Power |
| 12:38.25 | *** join/#oe gerwin (n=gerwin@ip5457b30e.direct-adsl.nl) |
| 12:38.29 | gerwin | Lo |
| 12:38.55 | gerwin | I keep on having timeouts and stuff on gnu-config |
| 12:39.09 | linnuxxy | i have built a toolchain for armv5b-softfloat (could used for IXP420 for example) can i contribute with this pre-built toolchain somewhere? |
| 12:39.10 | zecke | gerwin: are you firewalled? |
| 12:39.44 | zecke | linnuxxy: we do not have places for that yet. Due multiple reasons I guess |
| 12:40.02 | hrw|work | gerwin: rm -rf CVS_DIR/gnu-config and refetch |
| 12:41.46 | gerwin | hrw and zecke thanks |
| 12:42.04 | gerwin | Zecke: I got some opie questions (for my epia project) |
| 12:42.24 | zecke | gerwin: sure, either ask now or mail me :) |
| 12:42.51 | gerwin | Zecke: I managed to get opie running but I am wondering how the hid support is |
| 12:43.21 | gerwin | Zecke: I cannot get my hid mouse working |
| 12:43.30 | zecke | gerwin: Keyboard+Mouse or something else? |
| 12:44.17 | zecke | linnuxxy: If #OE would distribute toolchains we would need to have the source and tools that were used to build the toolchain |
| 12:44.45 | zecke | 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 |
| 12:45.50 | *** join/#oe alan|xchat (n=alan@ARouen-152-1-91-239.w86-199.abo.wanadoo.fr) |
| 12:47.40 | gerwin | Zecke: mouse via usb hid and keyboard via ps2 |
| 12:48.49 | zecke | gerwin: keyboard should just work |
| 12:49.03 | zecke | gerwin: and to see a mouse pointer you will need to recompile QtE |
| 12:49.09 | zecke | gerwin: we have thrown that out there |
| 12:54.03 | gerwin | zecke: okay I will do my very best |
| 12:54.31 | gerwin | zecke: I will ask france to make a project page |
| 12:55.12 | gerwin | zecke: I am making now a 120 dollar pc for one of my friends who is handicapped and who cannot afford an expensive pc |
| 12:57.40 | *** join/#oe lrg|home (n=liam@exize.demon.co.uk) |
| 12:57.49 | RP | hi lrg|home |
| 12:57.58 | lrg|home | hi RP, got your email |
| 12:58.39 | lrg|home | RP: I think this may be a madplay problem as aplay and arecord seem to work fine. |
| 12:58.56 | gerwin | zecke: I still got the problem with gnu-config :( |
| 12:59.08 | RP | 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 :) |
| 12:59.11 | lrg|home | RP: I'll need to give it a try on my PC as well |
| 12:59.43 | RP | I have noticed the keyboard driver hooks seem to have dropped out the alsa patches btw |
| 13:00.06 | RP | Not a problem as nothing's using them yet :) |
| 13:00.58 | lrg|home | RP: ah, that's most likely my fault. I did some reorg and have probably misplaced them :( |
| 13:01.19 | gerwin | zecke: Another problem I am solving now is a problem with grub that didn't want to compile in my old builds |
| 13:01.39 | greentux | hi lrg|home |
| 13:01.49 | lrg|home | hi greentux |
| 13:01.51 | RP | lrg|home: I still want to put that interrupt code into the keyboard driver eventually anyway,,, |
| 13:02.10 | lrg|home | RP: ok, np |
| 13:02.19 | greentux | lrg|home: do you know how the 3.5mm connector is used? (ground, had, mic)? |
| 13:02.54 | lrg|home | greentux: it should be a stereo connector with ground, left hp and mic |
| 13:03.04 | RP | I think tip is the mic, and the headset is the ring with ground being the base but I'm not 100% sure... |
| 13:03.16 | hrw|work | ~lart kgpg |
| 13:03.16 | greentux | ok. will check that tom. |
| 13:04.06 | lrg|home | I'll be able to reorder my headset tomorrow. This time I'll get the right thing..... |
| 13:04.48 | greentux | lrg|home: :) dos the alsamixer loads some useful defaults at startup? |
| 13:04.53 | zecke | gerwin: even after deleting the source code? |
| 13:04.57 | pb__ | hi lrg |
| 13:05.08 | lrg|home | hi pb__ |
| 13:05.22 | zecke | linnuxxy: but please ask on oe@handhelds.org to kick off a discussion if OE should host/provide prebuilt toolchains |
| 13:05.24 | lrg|home | greentux: not yet, it's something thats being worked on |
| 13:05.44 | greentux | aaahhhh. :) |
| 13:06.01 | *** join/#oe ar_ (n=ar@port-ip-213-211-231-121.reverse.mdcc-fun.de) |
| 13:06.27 | lrg|home | 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 |
| 13:06.28 | linnuxxy | ok i will do |
| 13:06.35 | RP | greentux: The only defaults that need to be changed are turning on the left and right mixer |
| 13:06.43 | hrw|work | greentux: script is easy for it |
| 13:07.07 | greentux | RP: i know, was only intersted in further development. |
| 13:07.22 | greentux | hrw|work: can u send me example? |
| 13:07.30 | hrw|work | greentux: case start: alsactl restore; card stop: alsactl store; - kind of |
| 13:08.33 | greentux | hrw|work: ok, but the user should have some ready profiles (better vor OE acceptance) |
| 13:09.05 | RP | greentux: Yes, we should have a default config file installed |
| 13:09.05 | hrw|work | greentux: sure - I'm saying about script which I use now |
| 13:14.06 | gerwin | zecke: it works now I need to change something in my bb file |
| 13:30.52 | gerwin | 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 |
| 13:30.52 | *** join/#oe oris_wolfbane (n=oris@82-38-121-195.cable.ubr01.hali.blueyonder.co.uk) |
| 13:31.34 | zecke | gerwin: KPhone's OSS code can be improved very much |
| 13:32.10 | *** join/#oe [lala] (n=lala@ip-217-18-177-18.reverse.dsi.net) |
| 13:32.37 | [lala] | hi, and a happy new year :) |
| 13:33.36 | hrw|work | hi lala |
| 13:33.53 | [lala] | i have the feeling that the autotools_stage_all stuff did break some packages, didn't it? ;-) |
| 13:33.58 | [lala] | hi hrw |
| 13:34.12 | gerwin | zecke: there is another really cool sip client in oe |
| 13:34.15 | [lala] | after setserial less is the next package which want to do staging |
| 13:35.01 | zecke | gerwin: linphone? |
| 13:35.46 | greentux | gerwin: you mean minisip... |
| 13:37.28 | *** join/#oe do13_ (i=do13@antilope.in-berlin.de) |
| 13:39.23 | [lala] | should a INHIBIT_AUTO_STAGE = 1 in the .bb file fix the issue? |
| 13:39.38 | CIA-4 | 03pH5 07org.oe.dev * r7de90a05... 10/packages/setserial/setserial_2.17.bb: setserial-2.17: overwrite autotools' do_stage with an empty one |
| 13:40.15 | [lala] | or is an empty do_stage() the proposed way? |
| 13:42.18 | hrw|work | iirc there was something like IGNORE_AUTO_STAGE |
| 13:42.24 | chouimat | morning |
| 13:42.50 | reenoo_ | arguably, autotools.bbclass is currently broken |
| 13:43.20 | reenoo_ | anything done there shouldn't break .bbs inheriting it |
| 13:44.07 | reenoo_ | adding INHIBIT_AUTO_STAGE to possibly hundreds of .bbs is just plain wrong |
| 13:44.16 | *** join/#oe marcan (i=1337@8.Red-83-36-94.dynamicIP.rima-tde.net) |
| 13:45.11 | [lala] | hrw|work: i have seen both - some packages have INHIBIT_AUTO_STAGE set, others have empty do_stage() |
| 13:45.51 | [lala] | but doing staging as default for all packages seems not very desireable to me ... i agree with renoo_ |
| 13:51.37 | gerwin | zecke: no I think it was some called sipphone or something it was with video |
| 13:53.11 | *** join/#oe Mardy (n=mardy@adsl-130-110.38-151.net24.it) |
| 13:53.23 | Mardy | hi all |
| 13:53.45 | RP | 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 :-( |
| 13:54.05 | reenoo_ | RP: writing mail to oe@ right now. |
| 13:54.39 | reenoo_ | RP: personally I'd just disapprove all related changesets |
| 13:54.45 | RP | 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... |
| 13:55.01 | RP | reenoo_: I'll second that in this case as this isn't right... |
| 14:09.59 | reenoo_ | RP: sent. please reply. |
| 14:11.23 | RP | reenoo_: will do |
| 14:11.37 | reenoo_ | RP: thanks |
| 14:12.18 | zecke | reenoo_: do you happen to know any research about static code analysis? |
| 14:13.06 | reenoo_ | zecke: not offhand. what language? |
| 14:13.25 | zecke | reenoo_: Java would be fine. I would prefer C++ though |
| 14:14.13 | reenoo_ | ah, hmm |
| 14:14.46 | zecke | reenoo_: don't worry. I just hoped for the lucky shot ;) |
| 14:14.57 | zecke | I do not know how to fill my report with content :} |
| 14:15.25 | reenoo_ | 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) |
| 14:15.40 | reenoo_ | to detect buffer overflows and stuff |
| 14:15.54 | zecke | reenoo_: that would be of personal interest for me |
| 14:16.06 | zecke | reenoo_: you mean ''treelang''? |
| 14:16.37 | reenoo_ | zecke: I'm afraid I don't know any details |
| 14:17.37 | reenoo_ | I'll /msg you his mail address |
| 14:26.07 | *** join/#oe CosmicPenguin (n=nobody@aus-ext-proxy02.amd.com) |
| 14:26.17 | *** join/#oe alan|laptop (n=alan@ARouen-152-1-91-239.w86-199.abo.wanadoo.fr) |
| 14:27.02 | *** join/#oe idealm (n=ideal@218.82.61.122) |
| 14:42.35 | *** join/#oe mithro (n=tim@dle92.neoplus.adsl.tpnet.pl) |
| 14:47.00 | zecke | reenoo_: thanks |
| 14:47.33 | mithro | hey zecke |
| 14:47.48 | mithro | going to Krakow in 2 hours |
| 14:48.59 | hrw|work | mithro: when into Poznan?? |
| 14:49.14 | zecke | mithro: hey |
| 14:49.20 | zecke | mithro: did you catch the train? |
| 14:49.25 | *** join/#oe iclem (n=clement@iclem.net) |
| 14:50.51 | RP | reenoo_: reply sent |
| 14:52.05 | *** join/#oe mithro_ (n=tim@djw176.neoplus.adsl.tpnet.pl) |
| 14:52.57 | mithro_ | anyway as I was saying |
| 14:53.18 | RP | rday wants to help with the tosa 2.6 kernel :) |
| 14:53.48 | mithro | I can't figure out why my SSH connects but hangs on setting up an interactive prompt |
| 14:53.48 | hrw|work | ;) |
| 14:54.08 | zecke | RP: should I send him the Project Tosa then? |
| 14:54.20 | RP | zecke: he has one! |
| 14:54.40 | zecke | mithro: some one changed your ssh config in a way you can only run certain apps? |
| 14:54.50 | [lala] | atk seems to be broken, because glib-2.0 doesnt stage share/glib-2.0 anymore |
| 14:55.03 | RP | zecke: Just keep in mind his track record ;-) |
| 14:55.29 | mithro | zecke: not that i can see |
| 14:55.33 | zecke | RP: at least he compiles twice a day and changes his local.conf more often |
| 14:55.56 | zecke | mithro: try executing /bin/sh ;) |
| 14:56.25 | do13_ | RP: I'll sell my zaurus:) |
| 14:56.28 | mithro | zecke: already tried that |
| 14:58.37 | mithro | even doing a /bin/echo doesn't work |
| 14:59.19 | mithro | any ideas? |
| 14:59.24 | zecke | do13_: hehe |
| 14:59.27 | zecke | mithro: sadly no |
| 14:59.31 | mithro | #debian had no ideas :/ |
| 15:00.29 | mithro | it's seems to die at the allocating terminal part |
| 15:01.29 | emte | mithro, clinet-server version conflict? |
| 15:01.51 | *** join/#oe Timelord (n=TL@4.78.4.43) |
| 15:02.33 | mithro | i've tried reinstalling openssh, lsh works fine but that is a bitc |
| 15:03.41 | *** join/#oe oris_wolfbane (n=oris@82-38-121-195.cable.ubr01.hali.blueyonder.co.uk) |
| 15:04.32 | mithro | it hangs here |
| 15:04.34 | mithro | <PROTECTED> |
| 15:04.34 | mithro | <PROTECTED> |
| 15:09.53 | mithro | the weird thing is that it was working at zeckes house |
| 15:10.01 | mithro | and I can't think of any changes since then |
| 15:10.06 | zecke | just one word... owned |
| 15:10.26 | *** join/#oe iclem_ (n=clement@iclem.net) |
| 15:10.48 | mithro | but how did they own me between your house and here? :P |
| 15:11.21 | RP | mithro: I think zecke means possessed :) |
| 15:11.56 | mithro | RP: i think he means 0\/\/n3d |
| 15:12.16 | Crofton | Thanks for clarifying the staging changes situation |
| 15:12.28 | zecke | mithro: I have no idea. I do not think you have a break in |
| 15:13.25 | mithro | zecke: neither do I, but i can't think of any other possible problem |
| 15:15.52 | *** join/#oe iclem__ (n=clement@iclem.net) |
| 15:21.05 | zecke | mithro: using telnet is not a option right? |
| 15:21.33 | mithro | yeah |
| 15:28.18 | *** join/#oe gremlin[it] (n=gremlin@ppp-27-45.25-151.libero.it) |
| 15:30.47 | mithro | RRP: why? |
| 15:30.47 | reenoo_ | 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" |
| 15:30.48 | RP | mithro: see oe@ |
| 15:31.26 | RP | reenoo_: I know what you mean. I think we just live without the PR change and get is disapproved before more damage gets done... |
| 15:31.45 | RP | I'm not building anything until it gets changed... |
| 15:31.54 | gremlin[it] | hi RP :) |
| 15:32.05 | reenoo_ | RP: ok. are you going to do it then? |
| 15:33.19 | RP | reenoo_: I guess so. Its not going to make me popular though :) |
| 15:35.12 | mithro | damn, the self compiled ssh also exhibits the same problems |
| 15:35.58 | *** part/#oe greentux (n=m@ip-217-18-177-18.reverse.dsi.net) |
| 15:39.44 | *** join/#oe kergoth (n=kergoth@c-24-118-213-150.hsd1.mn.comcast.net) |
| 15:40.43 | *** join/#oe pattieja (n=jpattie@65.59.202.15) |
| 15:41.25 | pb__ | morning kergoth |
| 15:41.51 | reenoo_ | RP: hehe. right. I guess I haven't made myself popular with what I sent to oe@ either. so, let's share the pain ;) |
| 15:41.59 | reenoo_ | hey kergoth |
| 15:43.57 | ade|desk | reenoo_ , RP : seems like the sane option to me |
| 15:44.08 | zecke | kergoth: welcome |
| 15:44.12 | RP | reenoo_: I'll disapprove all the autotools changes except the position change of inherit native in coreutils as that change looks ok to me |
| 15:45.05 | *** join/#oe stevenh (n=lews@65.167.23.2) |
| 15:45.05 | RP | actually it probably breaks things :-/ |
| 15:45.09 | *** join/#oe alan|laptop (n=alan@ARouen-152-1-27-117.w83-115.abo.wanadoo.fr) |
| 15:45.10 | hrw|work | reenoo_: for me you look like 'hey guys - you fscked something here and here - do it like this or this' |
| 15:46.16 | reenoo_ | hrw|work: the point being? |
| 15:47.27 | RP | done. The coreutils change is ok (I think). |
| 15:47.57 | [lala] | as to me i cannot build neither opie- nor gpe-image atm |
| 15:48.07 | reenoo_ | RP: yeah. inherit native must come after include foo.bb |
| 15:48.28 | [lala] | gpe breaks with atk |
| 15:48.38 | [lala] | opie breaks with konq-embedded |
| 15:49.35 | reenoo_ | 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 |
| 15:50.54 | hrw|work | reenoo_: in positive way I mean |
| 15:51.11 | reenoo_ | hrw|work: ok, sorry. |
| 15:51.18 | hrw|work | reenoo_: np |
| 15:51.25 | reenoo_ | hrw|work: I guess I should have a break or something... |
| 15:52.25 | hrw|work | reenoo_: I also dont like to put untested things (happens sometimes anyway) |
| 15:53.00 | hrw|work | btw - can someone look at #524? |
| 16:10.26 | *** join/#oe chii (i=chii@freenode/bot/chii) |
| 16:11.36 | *** join/#oe chii (i=chii@freenode/bot/chii) |
| 16:12.36 | *** join/#oe alan|laptop (n=alan@ARouen-152-1-74-90.w86-192.abo.wanadoo.fr) |
| 16:13.16 | *** join/#oe chii (i=chii@freenode/bot/chii) |
| 16:18.39 | RP | Hmm. I'm not sure the disapprove worked :-/ |
| 16:20.08 | hrw|work | RP: disapprove;commit? |
| 16:21.43 | reenoo_ | just disapprove should do. not sure what's going on there |
| 16:22.01 | *** join/#oe minipanda (n=zhanght@219.236.21.70) |
| 16:22.26 | *** part/#oe minipanda (n=zhanght@219.236.21.70) |
| 16:22.34 | RP | I just used disapprove and some things have disappeared from my tree, some haven't :-/ |
| 16:23.04 | RP | I guess we need viewmtn to be able to see what's going on now.. |
| 16:25.25 | hrw|work | cu |
| 16:28.17 | reenoo_ | RP: oh, dear. I believe I've had that before. this will be a pain to revert manually :/ |
| 16:30.29 | RP | reenoo_: You mean disapprove is actually borken? :-( |
| 16:31.07 | reenoo_ | RP: may have been my fault. I don't know. |
| 16:33.15 | reenoo_ | RP: IIRC monotone got confused due to merging |
| 16:33.45 | RP | reenoo_: Yes, looking at monotone log, that would appear to be the case here. Any tips on resolving this? |
| 16:36.52 | reenoo_ | no, sorry :( |
| 16:37.09 | reenoo_ | I just copied the file in question back in last time |
| 16:37.14 | reenoo_ | http://www.handhelds.org/hypermail/oe-commits/6/0601.html |
| 16:37.22 | reenoo_ | http://www.handhelds.org/hypermail/oe-commits/6/0602.html |
| 16:39.49 | RP | reenoo_: The number of files in this disapprove is going to make this a lot more tricky... |
| 16:42.08 | RP | Basically it did 2 merges after the disapproves which look to have broken things... |
| 16:48.17 | reenoo_ | have you pushed your changes already? |
| 16:48.49 | reenoo_ | or tried to do so rather |
| 16:49.52 | reenoo_ | nice. the server on vanille.de is down again |
| 16:50.08 | RP | reenoo_: yes. I checked a couple of files which worked so I assumed it was all ok... |
| 16:51.37 | RP | hmm. and I'm now out of diskspace :-/ |
| 16:54.55 | *** join/#oe mgoebl (n=matthias@ppp-62-245-211-12.mnet-online.de) |
| 17:01.00 | *** join/#oe Crofton (n=balister@hc6521d1e.dhcp.vt.edu) |
| 17:04.55 | *** join/#oe Titeuf (n=Titeuf@2m01.net) |
| 17:05.51 | *** join/#oe ar_ (n=ar@port-ip-213-211-231-121.reverse.mdcc-fun.de) |
| 17:11.22 | RP | reenoo_: It seems to have correctly disapproved the two small changesets and messed up the big one... |
| 17:11.39 | RP | by messed up, read totally failed to apply |
| 17:12.59 | RP | so it could be worse... |
| 17:14.38 | reenoo_ | gotta go. sorry |
| 17:18.40 | RP | koen|away: ping? |
| 17:20.04 | *** join/#oe pH5 (n=ph5@e178211014.adsl.alicedsl.de) |
| 17:20.41 | pH5 | good evening all |
| 17:20.58 | RP | hi pH5 |
| 17:21.59 | RP | You've read oe@? |
| 17:22.20 | pH5 | reenoo sparked quite a discussion there. I've just started. |
| 17:23.42 | RP | 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... |
| 17:24.23 | *** join/#oe dj_segfault (n=david@packardhell.aptima.com) |
| 17:24.37 | *** join/#oe alan__ (n=alan@ARouen-152-1-56-173.w83-199.abo.wanadoo.fr) |
| 17:29.18 | pH5 | hm. there are two things going on at once here. |
| 17:29.18 | pH5 | 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. |
| 17:30.11 | pH5 | RP: i like your proposal to add an autotools_stage class. if the goal is to make this the default after some transition phase. |
| 17:31.51 | RP | pH5: That would be the idea |
| 17:33.09 | RP | The problem is that for something as important as autotools we can't change the behaviour which is what your patch does... |
| 17:35.25 | pH5 | I didn't expect (and didn't experience in my test builds) those packages with broken Makefiles that are worked around in do_install. |
| 17:36.54 | pH5 | 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. |
| 17:37.18 | RP | ok, we just need to be careful. Someone should have realised this when you proposed the idea... |
| 17:38.56 | RP | Eventually, one of the aims is to put staging under control of the package manager and perhaps to use the -dev packages directly |
| 17:41.07 | pH5 | I know. Just when will this happen? |
| 17:41.26 | RP | When someone gets around to impelmenting it :-( |
| 17:42.04 | pH5 | That's the problem. If only we could do this in little steps. |
| 17:43.21 | RP | 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 |
| 17:44.05 | RP | If we can mark all the sane packages and have them using a new method of staging we have something to convert to |
| 17:45.04 | RP | 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 |
| 17:45.19 | pH5 | Fine. So how do we create consensus that adding another bbclass is a good interim solution :-) |
| 17:48.55 | RP | pH5: Probably by doing it :) |
| 17:49.53 | RP | 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 |
| 17:51.06 | pH5 | oh, there will be :) |
| 17:52.23 | RP | pH5: I've not seen any objections yet and most of the main contributors have commented or at least read the mails |
| 17:52.45 | RP | Yes, they can see other ways of doing it but that's not an objection as such ;-) |
| 17:52.58 | ade|desk | 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 |
| 17:53.41 | RP | ade|desk: That does bother me but when you consider the out of tree .bb files, it gets tricky... |
| 17:54.10 | RP | and yes, out of tree .bb files do exist. I have a few personal ones and I know OH has some as well |
| 17:54.11 | ade|desk | else in several months time we end up with autotools_new and then autotools_new_new etc |
| 17:55.00 | RP | Once we convert to the new autotools, we can perhaps rename. |
| 17:56.26 | pH5 | 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. |
| 17:56.50 | ade|desk | 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 |
| 17:57.37 | pH5 | otoh we might end up with autotools and autotools_new forever, if people lose interest. |
| 17:57.45 | RP | Well, I'd happily see autotools renamed to autotools_legacy or something... |
| 17:58.05 | RP | but only once we have a replacement ready and tested with a few packages |
| 17:58.56 | RP | 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 |
| 17:59.29 | *** join/#oe _law_ (n=_law_@213.173.86.202) |
| 18:00.21 | pH5 | 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 |
| 18:01.12 | pb__ | pH5: heh, indeed |
| 18:01.17 | pH5 | s/packages/recipes/, some were different versions of the same package. |
| 18:04.40 | RP | 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 :) |
| 18:05.26 | pH5 | Are we sure that the dev package has everything needed for staging? |
| 18:05.40 | pH5 | I.e. will we fish our files out of image/ or install/package-dev/ |
| 18:08.22 | RP | libs could be tricky as they're not in the -dev package iirc |
| 18:08.33 | pb__ | 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. |
| 18:09.06 | RP | If not, it could be argued the packages packaging is wrong :) |
| 18:09.40 | pH5 | Great, there's our first little step. |
| 18:11.08 | pb__ | "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. |
| 18:11.48 | RP | pb__: agreed |
| 18:12.42 | pb__ | pH5: heh. for a first little step, that's a pretty big one. |
| 18:13.30 | pb__ | admittedly it's probably not all that much actual work, but package-based staging has been a seemingly unattainable goal for many months |
| 18:15.28 | pH5 | but this means we'd have to run do_package before do_stage, right |
| 18:15.41 | pb__ | right |
| 18:16.00 | RP | pH5: The class can handle changes like this |
| 18:19.11 | *** join/#oe uv1 (n=kvirc@p5089214D.dip0.t-ipconnect.de) |
| 18:21.00 | pb__ | 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. |
| 18:23.54 | RP | I'd suggest creating a new method after packaging and making do_stage a null method |
| 18:24.56 | *** part/#oe berend (n=berend@chasin.xs4all.nl) |
| 18:26.51 | pb__ | reenoo_: wb |
| 18:27.00 | reenoo_ | re |
| 18:27.12 | reenoo_ | 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 |
| 18:27.27 | pb__ | right |
| 18:27.48 | *** join/#oe alan__ (n=alan@ARouen-152-1-23-113.w83-115.abo.wanadoo.fr) |
| 18:27.49 | pb__ | there's clearly no point in eliminating existing do_stage functions that are working fine |
| 18:27.59 | reenoo_ | right |
| 18:28.00 | pH5 | reenoo_: ack, nobody wants to just remove working functions |
| 18:28.30 | reenoo_ | pH5: well. that's what Koen, John Bowler and you have been doing the last couple of days. |
| 18:29.09 | reenoo_ | in other news, intrusive changes like these are they reason why people make use of branches |
| 18:29.19 | reenoo_ | s/they/the |
| 18:29.22 | RP | 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... |
| 18:29.57 | reenoo_ | RP: there's no automated way to do regression testing for this |
| 18:29.59 | pH5 | 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. |
| 18:30.00 | RP | and I understand how difficult it is to check what's going on... |
| 18:30.08 | pb__ | 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. |
| 18:30.49 | pH5 | 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) |
| 18:31.09 | pb__ | yeah, that was a bit weird and unforeseen |
| 18:31.32 | pb__ | What exactly were the problems that showed up in those cases? |
| 18:31.55 | pb__ | 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. |
| 18:32.18 | pH5 | they install files without checking for the directories first |
| 18:32.59 | pb__ | oh, right, so autotools just needs to make those directories itself. |
| 18:33.14 | pb__ | 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. |
| 18:33.30 | pb__ | The interaction between native.bbclass (for example) and autotools.bbclass is a bit more tricky though. |
| 18:35.18 | pb__ | 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. |
| 18:35.28 | reenoo_ | 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. |
| 18:35.41 | pH5 | pb__: yes, like coreutils-native |
| 18:37.46 | RP | reenoo_: To be fair, those changes have been committed by jbowler - pH5's changes mostly just removed do_stage(autotools_stage_all) |
| 18:38.04 | pb__ | bbl |
| 18:38.33 | reenoo_ | pH5: my appologies then |
| 18:38.37 | pH5 | reenoo_: no offence taken. anyway, at least the corutils-native and setserial issues were my fault. |
| 18:39.13 | reenoo_ | corutils-native was actually buggy regardless of your changes |
| 18:39.34 | reenoo_ | inherit native has to happen after include foo.bb |
| 18:40.14 | *** join/#oe oris_wolfbane (n=oris@82-38-121-195.cable.ubr01.hali.blueyonder.co.uk) |
| 18:42.42 | reenoo_ | pH5, RP: so, how do we proceed then? create an autotools_<insert favourite name here>.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) |
| 18:43.11 | RP | pH5: yes |
| 18:43.38 | pH5 | reenoo_: sounds reasonable. |
| 18:44.10 | RP | We then go and change all those packages to use the new autotools_foobar at which point we can delete the do_stage functions |
| 18:45.02 | pH5 | RP: what about your cset disapproval? |
| 18:45.11 | reenoo_ | RP: personally, I'd like to avoid that as there's no way to review such a large scale change |
| 18:45.50 | reenoo_ | RP: I'd prefer to leave working .bbs alone until we have sanboxing/package management of the staging area |
| 18:46.33 | RP | reenoo_: We're talking about packages who's do_stage consists of calling just calling autotools_stage_all |
| 18:46.34 | reenoo_ | RP: you could do automated checks to sanity check the do_stage() changes once we have that |
| 18:46.49 | reenoo_ | RP: ah, sorry |
| 18:47.08 | reenoo_ | I still had the jbowler style diffs in mind |
| 18:47.21 | RP | reenoo_: I agree we leave the more complex changes until later and this does raise the jbowler diffs |
| 18:47.39 | pH5 | that way we'll hopefully work around the chicken&egg problem that is putting staging under package management control. |
| 18:47.51 | RP | If he has been carefully checking things we might be ok - I note he has made comments about some installs being broken |
| 18:48.16 | RP | pH5 hopefully, yes |
| 18:49.23 | pH5 | the problem with jbowlers' glib-2.0 change at least was the dumb autotools_stage_all only installing aclocal/ from usr/share/ |
| 18:50.33 | reenoo_ | 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 |
| 18:51.59 | _law_ | usbnet doesnt work with latest kernel :-( |
| 18:52.23 | *** join/#oe alan__ (n=alan@ARouen-152-1-60-115.w83-199.abo.wanadoo.fr) |
| 18:52.24 | RP | _law_: Which machine? |
| 18:52.36 | _law_ | husky |
| 18:52.57 | RP | _law_: ok, I think I can guess why - try removing the usb*rndis* patch... |
| 18:53.22 | _law_ | RP: ok i?ll try |
| 18:54.10 | _law_ | usb0: register 'cdc_subset' at usb-0000:00:10.0-1.4, Linux Device, 1a:48:e8:ce:22:7a |
| 18:54.11 | _law_ | NETDEV WATCHDOG: usb0: transmit timed out |
| 18:54.11 | _law_ | usb0: no IPv6 routers present |
| 18:55.49 | RP | Although that rndis patch shouldn't touch cdc codepaths :-/ |
| 18:56.15 | RP | You can try removing it and if that fails I'll have to do some testing... |
| 18:57.28 | RP | reenoo_: I don't think its pointless waste of effort as proper package managing of staging has some advantages in the future |
| 19:06.00 | *** join/#oe [lala] (n=lala@p54B381FB.dip0.t-ipconnect.de) |
| 19:06.33 | reenoo_ | RP: no, I was referring to jbowler's changes only. the earlier we get package managing of the staging area the better :) |
| 19:07.47 | *** join/#oe gremlin[it] (n=gremlin@194-185-170-112.f4.ngi.it) |
| 19:18.01 | *** join/#oe lkcl (n=lkcl@bb-87-82-4-146.ukonline.co.uk) |
| 19:18.11 | *** join/#oe CosmicPenguin (n=nobody@aus-ext-proxy01.amd.com) |
| 19:18.16 | lkcl | heya folks |
| 19:18.39 | lkcl | hi renoo: thanks for the advice about the bitbake build. i get to try it in a few mins :) |
| 19:52.41 | reenoo_ | lkcl: no problem. and good luck then. |
| 19:54.48 | *** join/#oe jbowler (n=jbowler@nslu2-linux/jbowler) |
| 19:58.32 | *** join/#oe _alwin_ (n=ral@cable-81-173-131-62.netcologne.de) |
| 20:02.33 | *** join/#oe mrz80 (i=1000@caledonia.cns.ufl.edu) |
| 20:02.35 | RP | reenoo_: Rather than correct this disapproval business, its going to be nearly as easy to press on and start autotools_new... |
| 20:04.06 | reenoo_ | RP: I was of the impression you had pushed your changes already, didn't you? |
| 20:04.40 | reenoo_ | err.. that doesn't look quite right. I hope you get the idea anyway ;) |
| 20:05.01 | RP | 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 |
| 20:05.37 | RP | 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... |
| 20:06.52 | reenoo_ | well. there are around 23 changesets to be reverted |
| 20:07.20 | RP | Yes, but I hadn't started on them (thankfully) |
| 20:07.32 | RP | I'd also like to ask jbowler exactly how was was testing them |
| 20:07.59 | RP | jbowler: ping? |
| 20:08.26 | reenoo_ | judging from bugs.oe.org they went in more or less untested (partly anyway). |
| 20:09.05 | RP | yes :-/ |
| 20:09.12 | RP | true... |
| 20:14.07 | *** join/#oe oris_wolfbane (n=oris@82-38-121-195.cable.ubr01.hali.blueyonder.co.uk) |
| 20:16.16 | reenoo_ | I'll assist with sorting the disapproves out once I'm done with this assignment. later all |
| 20:17.03 | *** join/#oe alan|laptop (n=alan@ARouen-152-1-82-199.w86-195.abo.wanadoo.fr) |
| 20:18.50 | *** join/#oe darkschneider (n=gab@213-140-6-96.ip.fastwebnet.it) |
| 20:20.37 | pH5 | 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? |
| 20:23.05 | pH5 | http://en.pastebin.ca/35644 |
| 20:24.33 | RP | pH5: We're not going to have an autotools_do_stage in autotools.bbclass (that was already reverted) |
| 20:25.05 | RP | This was one of the problems as it introduced a change in behaviour |
| 20:25.38 | pH5 | ah, I thought the exporting part did the change |
| 20:26.02 | RP | Well, that as well but since we're going to be altering it, it may as well be in the new class |
| 20:26.17 | pH5 | RP: ok. and you did already push the reverted revision? |
| 20:26.18 | pb_ | pH5: yes, the "EXPORT_FUNCTIONS" is the significant bit |
| 20:26.32 | pb_ | just having a function named "autotools_do_stage" is harmless in itself. |
| 20:27.26 | RP | pH5: The disaproval has gone badly wrong. That change was reverted and the setserial one but nothing else was touched |
| 20:27.52 | pH5 | RP: whether I pull from monotone or ewi546, I'm still at rev. 7de90a055904c4af8890dd5ae8c192bfd41b3fa1 |
| 20:28.54 | RP | pH5: Really? If so, the approval never made it in. No multiple heads or anything? |
| 20:29.17 | RP | That would be handy as I can start again :) |
| 20:29.39 | pH5 | monotone: branch 'org.openembedded.dev' is currently merged: |
| 20:29.39 | pH5 | 7de90a055904c4af8890dd5ae8c192bfd41b3fa1 pH5@openembedded.org 2006-01-03T13:20:44 |
| 20:29.57 | *** join/#oe malfimalfi (n=malte@dslb-084-059-006-124.pools.arcor-ip.net) |
| 20:31.22 | jbowler | 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. |
| 20:32.08 | jbowler | 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. |
| 20:32.39 | RP | jbowler: So you never actually did a comparision of what make install installed compared to what was listed in do_stage? |
| 20:32.50 | jbowler | 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. |
| 20:33.08 | jbowler | RP: yes, not in all instances |
| 20:33.31 | RP | jbowler: Why are we seeing bugs then? :-/ |
| 20:33.40 | jbowler | What bugs? |
| 20:33.47 | pH5 | 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. |
| 20:33.57 | RP | #570 |
| 20:34.19 | pH5 | because my autotools_stage_all only installs aclocal/ from usr/share/ currently |
| 20:34.28 | jbowler | Ah - the glib, ipkg and binutils I were fine against the packages I tried, but glib-2.0 is the most difficult. |
| 20:35.14 | jbowler | 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... |
| 20:35.48 | pH5 | RP: what about this: http://en.pastebin.ca/35646 |
| 20:35.49 | jbowler | RP: do you have a URL for that bug report? |
| 20:36.16 | RP | http://bugs.openembedded.org/show_bug.cgi?id=570 |
| 20:36.33 | pH5 | eh. |
| 20:36.56 | pH5 | <PROTECTED> |
| 20:37.13 | jbowler | RP: ok, I know about this and I thought I had got it right. |
| 20:37.18 | RP | pH5: I was going to say :) |
| 20:37.34 | RP | pH5: Yes, that looks good |
| 20:38.38 | RP | pH5: Can you revert the change to setserial and then change all the packages mentioned in revision 65af73a95a851d2e8c3cf2f523f1acc488be0208 to use this new class please? |
| 20:39.31 | RP | jbowler: The conern we have is whether we're losing metadata with these staging changes :-/ |
| 20:41.13 | RP | 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... |
| 20:42.25 | jbowler | 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 |
| 20:43.46 | jbowler | I.e. specifically the following lines (in native) which I removed and checked were wrong: |
| 20:43.48 | jbowler | - install -d ${STAGING_DATADIR}/glib-2.0/gettext/po |
| 20:43.48 | jbowler | - install -m 0755 mkinstalldirs ${STAGING_DATADIR}/glib-2.0/gettext/ |
| 20:43.48 | jbowler | - install -m 0644 po/Makefile.in.in ${STAGING_DATADIR}/glib-2.0/gettext/po/ |
| 20:44.08 | jbowler | Which is really weird because I definately remember checking them... |
| 20:45.19 | jbowler | RP: you seem to be saying you want to revert all of my changes because I got one wrong. |
| 20:46.22 | RP | 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 |
| 20:47.02 | RP | If you didn't check this in all cases though, it leaves us open to further bugs which is why I'm worried |
| 20:48.02 | pH5 | RP: I'm building a patch currently. |
| 20:48.04 | jbowler | 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. |
| 20:48.54 | RP | build testing isn't really enough for this though :-/ |
| 20:48.55 | jbowler | pH5: I am concerned that the default for 'inherit autotools' has changed from not staging to staging, that's pretty much untestable I think. |
| 20:49.20 | pH5 | jbowler: right, that was an error. that's why we'll change it back asap. |
| 20:49.25 | jbowler | RP: do you have an example of something which has broken in some place other than the build? |
| 20:49.31 | RP | jbowler: which is why I tried to disapprove those changes and why pH5 Is correcting that now |
| 20:49.56 | RP | jbowler: no, but you also haven't proven that all files that were staged are still staged... |
| 20:50.21 | jbowler | 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. |
| 20:51.42 | pH5 | jbowler: It's quite possible that those glib/atk changes only show up with gtk 2.8 or something like this |
| 20:51.42 | jbowler | 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. |
| 20:52.39 | RP | jbowler: Don't think I'm suggesting it lightly :-/ |
| 20:52.53 | jbowler | 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. |
| 20:53.04 | jbowler | RP: don't think I'm taking it lightly. |
| 20:53.29 | reenoo_ | jbowler: what exactly is the advantage in removing carefully hand crafted do_stage() functions? |
| 20:54.29 | jbowler | 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. |
| 20:55.03 | jbowler | renoo_: hand crafted do_stage circumvents stuff which should be in the package make install rune, so it is bound to go wrong eventually. |
| 20:56.02 | jbowler | 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. |
| 20:56.58 | RP | 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... |
| 20:56.59 | jbowler | 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). |
| 20:57.58 | jbowler | 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. |
| 20:58.35 | RP | jbowler: Its not builds I want checked - its whether all the files that get staged before still get staged. This is the important point |
| 20:58.43 | jbowler | 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! |
| 20:58.55 | RP | Whether things build or not afterwards is one test of this but its not conclusive |
| 20:59.29 | jbowler | RP: ok, I can check that too. |
| 20:59.39 | jbowler | (At least for the last set of changes it's fairly trivial). |
| 21:00.12 | RP | jbowler: If we're checking that in future (and can confirm the other packages didn't change anything in that respect), I'm happy |
| 21:01.37 | reenoo_ | 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 |
| 21:01.56 | *** join/#oe florian (n=fuchs@p50839808.dip0.t-ipconnect.de) |
| 21:02.14 | florian | re |
| 21:02.29 | jbowler | reenoo_: there's a gain because the latter (package control) won't work unless the format (autotools_do_stage) also works. |
| 21:02.57 | RP | reenoo_: If its confirmed the same files get staged, that is classed as review and verify... |
| 21:03.11 | RP | reenoo_: packaging can't happen without the do_stage functions being converted |
| 21:03.47 | reenoo_ | RP: is there an automated way to diff staging before/after? I don't think we have that sort of regression testing right now. |
| 21:04.11 | jbowler | reenoo_: I'm diffing two build trees (one before, one after). |
| 21:04.23 | RP | reenoo_: No, but you can do it manually which is what I'm asking for |
| 21:04.44 | reenoo_ | jbowler: I'm not talking about you. I'm talking about me and every other OE user out there. |
| 21:05.58 | RP | reenoo_: Do you personally test and verify every change to the OE tree? I'm beginning to lose the plot here... |
| 21:06.31 | *** join/#oe lkcl (n=lkcl@bb-87-82-4-146.ukonline.co.uk) |
| 21:06.52 | reenoo_ | RP: for changes that are likely to cause breakage, yes (as time permits, obviously) |
| 21:06.55 | jbowler | 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. |
| 21:07.24 | jbowler | 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. |
| 21:07.28 | jbowler | Testing staging is a nightmare... |
| 21:07.45 | jbowler | (That's why it needs to be fixed to per-package staging). |
| 21:08.07 | RP | jbowler: and you tested your previous commits with that method? |
| 21:08.19 | kergoth | clean package. overriding the staging variables. build package. clean package again. override them to something else. diff the two temporary staging directories. |
| 21:08.41 | kergoth | er, throw a "modify package" after the build package, and add a build package after the first clean package |
| 21:08.44 | kergoth | i cant type |
| 21:09.14 | jbowler | RP: no - it was only when you suggested it above that I realised it would work and be more reliable. |
| 21:09.44 | jbowler | I was doing clean builds, but I wasn't diffing the staging directory. |
| 21:10.08 | RP | jbowler: ok, I just wanted to be sure before I try and test them :) |
| 21:10.10 | jbowler | That's why I only hacked things I knew were being used somewhere else... |
| 21:10.29 | RP | as kergoth says, we can actually test this by playing with bitbake variables |
| 21:10.55 | alan|laptop | good night all ! |
| 21:11.08 | jbowler | In this case I believe the glib-2.0 and ipkg changes should be reverted. |
| 21:11.29 | jbowler | Actually, glib-2.0 can be fixed, but I seem to have damaged libipkg. |
| 21:11.33 | RP | kergoth: we need you back :) |
| 21:12.27 | _law_ | RP: without patch usbnetwork works |
| 21:13.08 | RP | _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 :) |
| 21:14.00 | reenoo_ | 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). |
| 21:15.07 | jbowler | 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. |
| 21:16.00 | jbowler | After all, the point here is to get to somewhere where staging is per-package, and no package revision maintenance is required. |
| 21:16.38 | RP | 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... |
| 21:17.43 | pH5 | RP: I sent a mail with patches to the oe list |
| 21:17.51 | jbowler | 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). |
| 21:18.52 | reenoo_ | 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. |
| 21:19.07 | reenoo_ | jbowler: I'm just trying to avoid further misunderstandings |
| 21:19.38 | jbowler | ok, I'll put that into an email. |
| 21:20.43 | reenoo_ | thanks. that will allow us to make a decision which way we want to go and which type of changes to apply |
| 21:20.58 | RP | jbowler: I have to admit I don't understand your ideas on how staging should be managed in the future... |
| 21:21.05 | *** part/#oe lkcl (n=lkcl@bb-87-82-4-146.ukonline.co.uk) |
| 21:22.08 | RP | pH5: Your first patch was corrupt |
| 21:22.17 | jbowler | RP: I'll explain that too |
| 21:22.50 | pH5 | gnn. it's the one from pastebin. |
| 21:23.03 | RP | 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)? |
| 21:23.18 | jbowler | For the moment these changes should be reverted too: |
| 21:23.31 | jbowler | ipkg e16cffcf452086640211ee23d9ec8188163f1b83 |
| 21:24.06 | jbowler | sysfsutils 97dc9b1bab1e50b43f23ce37062529fa51c369c9 (not sure about this one, but something seems to have got lost) |
| 21:24.36 | RP | jbowler: reverting is going to need to be done manually by diff as monotone disapprove appears to just totally trash your local repository :-/ |
| 21:24.54 | reenoo_ | RP: which patches exactly? I haven't received anything from oe@ yet if that's where pH5 has sent them :/ |
| 21:25.03 | jbowler | Eh? Want me to try that? It's worked before for me. |
| 21:25.19 | jbowler | glib: b10c7a501f6606abe1b6a425dbb75912e858ae9f |
| 21:25.33 | *** part/#oe _law_ (n=_law_@213.173.86.202) |
| 21:25.33 | RP | jbowler: it apparently depends on whether anything was merged since the changes were added |
| 21:25.35 | jbowler | binutils: 97eb37ffc8cf19126ddc1bb342fc10727fecf64a |
| 21:25.46 | jbowler | RP: I have no merges since any of those revisions |
| 21:25.59 | jbowler | Want me to try...? |
| 21:26.23 | jbowler | Incidentally, I am in sync with ewi too. |
| 21:26.32 | RP | jbowler: I'm not sure its worth the risk - a diff might be safer - up to you though... |
| 21:26.51 | jbowler | Ok, I'll copy my db first then monotone-viz/difftree the result. |
| 21:26.59 | RP | jbowler: ok |
| 21:27.41 | RP | What with my local db being corrupted and the power failures taking out my persistent desktop, I'm not doing well today :) |
| 21:28.29 | RP | reenoo_: The mail was addresses to you and me with oe@ as the cc: |
| 21:28.43 | jbowler | Disapprove does produce an immediate branch/merge from the disapproved revision, so you have to be careful... |
| 21:29.05 | jbowler | I.e. IIRC it should be done LIFO |
| 21:30.06 | jbowler | I'm going to take out libgphoto2 because that shows up in my list of diffs - revision 40cd64edf16241a37663807e311fba8e23f0d258 in addition to the above. |
| 21:31.43 | reenoo_ | RP: that's a bit odd. haven't received anything. nothing in spam or virus folders either... |
| 21:35.11 | jbowler | 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. |
| 21:35.13 | RP | reenoo_: I've forwarded them - hh.org doesn't appear to have seen them yet either as they're not in the list archives |
| 21:35.58 | RP | jbowler: That figures. Who knows what state my local db is in now :-/ |
| 21:37.01 | jbowler | every disapprove creates a new head, so it's in hydra state ;-) |
| 21:37.49 | jbowler | Pull the snapshot from OE, start again... |
| 21:38.13 | jbowler | (If in doubt, cp the db and hack on that - this is what I'm doing at the moment.) |
| 21:38.34 | RP | jbowler: Indeed :) |
| 21:47.06 | *** join/#oe dfoley (n=dfoley@h24-207-7-221.primesignal.com) |
| 21:48.07 | *** join/#oe wingel (n=wingel@2-1-3-15a.ens.sth.bostream.se) |
| 21:50.26 | *** join/#oe malfi (n=malte@dslb-084-059-006-124.pools.arcor-ip.net) |
| 21:55.13 | *** join/#oe lamikr (n=chatzill@aragorn.kortex.jyu.fi) |
| 21:59.48 | jbowler | RP, renoo, pH5: you guys don't want the changes to remove do_stage, correct? I.e. revision 7de90a055904c4af8890dd5ae8c192bfd41b3fa1 should go? |
| 22:00.11 | jbowler | (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.) |
| 22:00.42 | jbowler | Sorry, wrong rev number... let me look: |
| 22:01.11 | reenoo_ | 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. |
| 22:01.21 | jbowler | I mean: fbc22e245906dac5ce180f67a0c621f7a2db1a28 "remove redundant do_stage" |
| 22:01.32 | reenoo_ | jbowler: yeah, those have to go as well |
| 22:02.04 | jbowler | reenoo_: eh, well, like I said before... |
| 22:02.24 | RP | jbowler: Yes, they can go too. I think pH5 can rediff accordingly |
| 22:02.52 | pH5 | reenoo_, RP: did you get a look at my diffs? |
| 22:03.04 | RP | pH5: fine with me... |
| 22:03.12 | RP | reenoo_: I forwarded the mails to you btw |
| 22:03.59 | reenoo_ | 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. |
| 22:04.00 | RP | pH5: You might want to hold off commiting until jbowler is finished as you're going to conflict (or just hold off diff 3) |
| 22:04.52 | pH5 | no problem, I'll commit when everyone is satisfied. |
| 22:06.42 | jbowler | 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). |
| 22:13.32 | Nix-niX | tmbinc, ?? |
| 22:20.20 | tmbinc | Nix-niX: hm? |
| 22:21.18 | Nix-niX | can join #nixkapirtsnicht |
| 22:31.04 | *** join/#oe dyoung-away (n=dyoung@nslu2-linux/dyoung) |
| 22:48.41 | *** join/#oe iclem_ (n=clement@iclem.net) |
| 22:53.05 | *** join/#oe moa_ (n=moa@APuteaux-154-1-6-232.w83-199.abo.wanadoo.fr) |
| 22:58.02 | CIA-4 | 03tmbinc 07org.oe.dreambox * rdc98c6c1... 10/packages/python/ (6 files in 2 dirs): remove manually merged files to workaround monotone bug #13831 |
| 22:58.08 | CIA-4 | 03tmbinc 07org.oe.dreambox * rd4315873... 10/packages/enigma2/enigma2.bb: enigma2: update enigma2 |
| 23:09.36 | *** join/#oe fyliu (n=WIISARD@803632cf.dynamic.ucsd.edu) |
| 23:14.33 | *** join/#oe Geo_KM (n=keith@bh02i525f01.au.ibm.com) |
| 23:17.26 | *** join/#oe andersee (n=andersee@codepoet.org) |
| 23:20.32 | RP | kergoth: Your idea about changing staging has a flaw - think about binaries like libtool being searched for in staging/bin :-/ |
| 23:23.07 | pb_ | mm, is libtool needed during staging? |
| 23:23.51 | pb_ | iirc, most packages' "make install" rules don't involve calling libtool again. |
| 23:24.42 | pb_ | in any case, you could override PATH to point back to the "real" staging area. |
| 23:24.56 | kergoth | RP: 99% of all packages use libtool as generated by their configure scripts, not the one we installed into staging with libtool-cross |
| 23:25.04 | kergoth | afaik just specific cases like libjpeg do the latter |
| 23:26.04 | reenoo_ | 'night all |
| 23:26.31 | RP | kergoth: Why did I choose libjpeg to play with :) |
| 23:26.41 | kergoth | haha |
| 23:26.44 | kergoth | murphy |
| 23:27.01 | RP | typical... |
| 23:27.04 | pH5 | good night |
| 23:27.05 | *** part/#oe pH5 (n=ph5@e178211014.adsl.alicedsl.de) |
| 23:28.53 | RP | 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) |
| 23:31.26 | pb_ | 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. |
| 23:32.23 | kergoth | pb_: they want to hire me! woot. |
| 23:32.25 | kergoth | :D |
| 23:32.34 | pb_ | kergoth: awesome! congratulations. |
| 23:32.34 | CosmicPenguin | nice |
| 23:33.14 | kergoth | :) thanks |
| 23:33.29 | RP | kergoth: excellent! (which company is this?) |
| 23:33.47 | kergoth | a company out in arizona thats working on land warrior (wearable computing for soldiers) |
| 23:33.48 | kergoth | cool stuff |
| 23:33.55 | *** join/#oe CosmicPenguin (n=nobody@aus-ext-proxy02.amd.com) |
| 23:34.10 | CosmicPenguin | wow |
| 23:34.12 | CosmicPenguin | X reset on me |
| 23:34.12 | RP | very cool :) |
| 23:34.44 | pb_ | yeah, x resets rule. |
| 23:44.58 | jbowler | 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? |
| 23:48.30 | *** join/#oe chouimat (n=dieu@kde/developer/chouinard) |
| 23:51.40 | *** join/#oe oris_wolfbane (n=oris@82-38-121-195.cable.ubr01.hali.blueyonder.co.uk) |