**** BEGIN LOGGING AT Wed Jan 04 02:59:57 2006 Jan 04 03:01:34 linnuxxy: you cannot on that model Jan 04 03:07:06 was gdbm-native one of the packages broken by all the autotools stuff recently? Jan 04 03:11:07 hay XorA ! happy new year ! Jan 04 03:11:10 XorA: It was changed, yes - are you seeing issues? Jan 04 03:11:12 hey alan|xchat Jan 04 03:11:22 RP: yes, it doesnt stage with a libtool error Jan 04 03:12:04 morning all Jan 04 03:12:16 03koen 07org.oe.oz354fam083 * r693c6bfc... 10/packages/ (5 files in 5 dirs): Jan 04 03:12:16 gpe 2.7: add more bits: Jan 04 03:12:16 * gpe-what 0.41 Jan 04 03:12:16 * gpe-sketchbook 0.2.9 Jan 04 03:12:16 * libeventdb 0.18 Jan 04 03:12:16 * gpe-bluetooth 0.48 Jan 04 03:12:32 hi Dirk Jan 04 03:12:52 hi Richard Jan 04 03:13:47 XorA: That .bb file is actually broken and this highlights another serious issue... Jan 04 03:14:38 oe is brocken /usr/bin/install: cannot stat `/develop/tripledragon/dm7025/build/tmp/work/mc-4.6.0-r0/mc-4.6.0/doc/es/mc.hlp.es': No such file or directory Jan 04 03:14:42 RP: Ive only been skim reading the autotools stage stuff so not really upto speed, I was hoping dust would settle before I returned to work Jan 04 03:15:06 XorA: Some patches still need to be reverted or fixed Jan 04 03:15:16 I think this issue pushes me towards reverting... Jan 04 03:15:33 currently a gpe-image cannot be built Jan 04 03:15:51 The problem is the behaviour before and after ph5's patch isn't the same, particularly for native builds... Jan 04 03:16:54 well at least the stable/unstable branching is working :-) Jan 04 03:17:08 otherwise things would be a lot more hairy Jan 04 03:19:22 Nix-niX: update to up-to-date repo or to repo few days old or use branch .oz354fam083 Jan 04 03:19:40 Nix-niX: .dev branch is now broken a bit probably Jan 04 03:25:28 hrw|work, thx Jan 04 03:32:21 MT_OPENEMBEDDED_BRANCH="org.openembedded.dreambox" Jan 04 03:32:31 is broken Jan 04 03:33:20 Nix-niX: ah. you use .dreambox one.. Jan 04 03:33:34 yes Jan 04 03:38:32 03koen 07org.oe.oz354fam083 * r0c6f0fb5... 10/packages/gpe-clock/gpe-clock_0.22.bb: gpe-clock: add 0.22 Jan 04 03:38:37 03koen 07org.oe.oz354fam083 * rc617690d... 10/packages/libcontactsdb/libcontactsdb_0.1.bb: libconontactsdb: add 0.1, needed for gpe-contactgs 0.43 Jan 04 03:38:41 03koen 07org.oe.oz354fam083 * re339c0fb... 10/packages/gpe-contacts/gpe-contacts_0.43.bb: gpe-contacts: add 0.43 Jan 04 03:38:44 03koen 07org.oe.oz354fam083 * r4c4729c2... 10/packages/libgpewidget/libgpewidget_0.106.bb: libgpewidget: add 0.106 Jan 04 03:38:49 03koen 07org.oe.oz354fam083 * rc2cd4828... 10/conf/distro/preferred-gpe-versions-2.7.inc: gpe 2.7: update to latest plan according to http://handhelds.org/hypermail/familiar-dev/6/0637.html Jan 04 03:46:25 I've just fixed .dev (hopefully) Jan 04 03:47:15 very good Jan 04 03:51:13 03rpurdie 07org.oe.dev * r2822701f... 10/ (114 files in 71 dirs): Revert the changes from revisions 65af73a95a851d2e8c3cf2f523f1acc488be0208, 28f020502e7dcf566733f474864c62156895baec, 7de90a055904c4af8890dd5ae8c192bfd41b3fa1 Jan 04 03:57:39 hello, can anybody tell me wht i need to do to get past this problem whilst building gcc-cross ? oninline.h:121: error: cannot convert 'const __ctype_touplow_t*' to 'const int*' ive been stuck here for weeks now ;( Jan 04 03:58:19 03koen 07org.oe.oz354fam083 * r5c1fd2e2... 10/packages/gpe-todo/gpe-todo_0.55.bb: gpe-todo: add 0.55 Jan 04 04:14:07 * france is back (gone 120:28:08) Jan 04 04:16:02 03koen 07org.oe.oz354fam083 * r667ca80c... 10/packages/gpe-contacts/gpe-contacts_0.43.bb: gpe-contacts: depends on libcontactsdb (building from scratch is very usefull ;)) Jan 04 04:16:13 <_law_> koen|away, why to you update oz354fam083 only? Jan 04 04:25:06 03koen 07org.oe.dev * r6bdeaf09... 10/packages/liboil/liboil_0.3.6.bb: liboil: add 0.3.6, liboil is a library of simple functions that are optimized for various CPUs. Jan 04 04:30:56 03koen 07org.oe.dev * rde0628c1... 10/packages/liboil/liboil_0.3.6.bb: liboill 0.3.6: add do_stage, which will hopefully not get dissapproved Jan 04 04:52:20 hi ! does anyone know of any good low level protocol simulator. (SoC related stuff) Jan 04 04:55:25 morning lrg Jan 04 04:55:41 morning pb__ Jan 04 04:56:11 yeah morning to all Jan 04 04:56:13 hi ! does anyone know of any good low level protocol simulator. (SoC related stuff) Jan 04 04:56:59 I'm not sure what you mean by a "protocol simulator". Can you be more specific? Jan 04 05:01:35 I wish to simulate it. Im not sure Opnet of NS2 does that Jan 04 05:01:44 pb_: so what do u think ? Jan 04 05:02:00 guys/gals any leads/pointer would be appreciated ? Jan 04 05:05:18 03koen 07org.oe.dev * ra3a85ad4... 10/packages/gpe-contacts/gpe-contacts_0.43.bb: gpe-contacts: add 0.43 Jan 04 05:05:59 Jenna: sorry, I don't understand exactly what you want to simulate. Jan 04 05:06:58 are you talking about network protocol simulation? Jan 04 05:07:42 pb_: actually it would be network protocol but only on chip, instead of being on the datalinklayer Jan 04 05:08:11 so what would be a good place to start/test/verify/simulate the work Jan 04 05:10:25 I guess the on-chip nature shouldn't make much difference. So, yeah, something like opnet or ns-2 is probably what you need. I've never used either of those, though. Jan 04 05:10:59 are there open source simulator I could go for ? Jan 04 05:11:17 and yeah do u know any other irc channel related to this stuff Jan 04 05:15:02 pb__: u there ? Jan 04 05:16:14 You are looking for an opnet replacement? Jan 04 05:16:46 yeah. is there any ? Jan 04 05:16:49 Unfortunately I don't know of an open source replacement Jan 04 05:17:49 You would think someone has at least tried Jan 04 05:18:00 and this is way off topic for #oe :) Jan 04 05:19:14 I thought since its somewhat related to h/w, I would atleast get some lead from the gurus here Jan 04 05:19:58 no one has any ideas on my problem? I found mention of it related to gcc-uclibc-cross from kergoth in google cache, but the original site is gone and i not found any solution Jan 04 05:24:03 sri, haven't seen that one Jan 04 05:24:30 * france is away: Away Jan 04 06:19:06 * france is back (gone 00:54:36) Jan 04 06:28:33 hey Jan 04 06:29:33 hi zecke Jan 04 06:30:13 anyone have experiance with boa embedded server? Jan 04 06:30:26 i have some problem there! Jan 04 06:30:46 linnuxxy: You might have better luck in a channel specialising in webservers.. not sure what's around though Jan 04 06:31:51 03koen 07org.oe.oz354fam083 * r5d813f88... 10/packages/meta/gpe-image.bb: gpe-image: Remove dillo2 to save some space Jan 04 06:32:19 nobody is using boa except in embedded apps Jan 04 06:35:45 linnuxxy: i have boa on a gumstix, not used it yet tho Jan 04 06:36:41 heh... thats help much Jan 04 06:36:55 hail zecke Jan 04 06:37:20 i can execute cgi bin Jan 04 06:38:10 when i try to access cgi pages i got "403 ForbiddenYour client does not have permission to get URL /test.cgi from this server." Jan 04 06:42:08 is the cgi bin readable by the user boa is running as ? Jan 04 06:42:41 yes Jan 04 06:43:30 boa is working as nobody user.. the cgi is owned by nobody user Jan 04 06:48:29 morning Jan 04 07:08:05 linnuxxy: does the cgi have to be +x not just +r and if so is it? Jan 04 07:08:37 yes ofcourse Jan 04 07:09:25 even i chmod it 777 just for test Jan 04 07:09:48 and i made their owner is nobody.nogroup Jan 04 07:10:18 2 sces, i now some1 devloping some cgi for gumstix, dunno if he has hosted it from boa yet Jan 04 07:10:19 coz boa is running nobody user... as i ps aux|grep boa it Jan 04 07:11:05 even i tested thttpd... i got simillar error Jan 04 07:12:19 no reply atm, Jan 04 07:52:47 hi lrg Jan 04 07:53:31 hey greentux Jan 04 07:53:33 hi greentux Jan 04 07:53:38 and lrg :) Jan 04 07:53:47 hi greentux Jan 04 07:53:54 hey RP and hrw|work :) Jan 04 07:53:59 hi rp hi hrw|work Jan 04 07:54:26 which tool i can use for test the micro? (on konsole).... the headset works very nice Jan 04 07:55:11 greentux, you can try arecord -c 1 -f DAT > out.wav to catpure mono 48k Jan 04 07:55:47 lrg: not -c 0 ? Jan 04 07:56:05 greentux, iirc c is number of channels Jan 04 07:56:43 greentux, another good thing to do is:- arecord -c1 -f DAT | aplay Jan 04 07:56:52 lrg: ok thought card number Jan 04 07:57:24 lrg: soc logs to the konsole while playing... :) Jan 04 07:57:25 greentux, ah, that's alsamixer... and now I think about it a bit confusing :-\ Jan 04 07:58:20 lrg: ok, will build alsatools (arecord?) Jan 04 07:59:06 greentux, iirc it's in the same .ipkg as aplay Jan 04 07:59:42 hi Liam. News about wm9712? Jan 04 07:59:54 hi Dirk Jan 04 08:00:49 do13: Sorry, I've been a bit busy with customer support over the holidays. I'm now back at the office and a little quiter so I'll send you a patch in the next hour :) Jan 04 08:01:28 do13: suspend/resume is working in the wm9712, but i need to think about the pxa bug a bit more Jan 04 08:01:48 lrg: Thanks Jan 04 08:17:06 <[lala]> alsa-utils-aplay is the correct pkg name Jan 04 08:48:03 lrg: checked the micro, but cant hear something... mmmh Jan 04 08:50:43 greentux: try and enable the alc to left chn, differential to line 1, input pga to differential and max the gain on the mic. Jan 04 08:51:40 greentux: unfortunately, i can't send an alsa config as i've changed the driver and controls so it wouldnt work on your setup. I also don't have my borzoi with me today. :( Jan 04 08:52:09 greentux: I can't even say it will work atm, until I can test... Jan 04 08:53:47 greentux: a stand alone mic, line input and hp work atm :) Jan 04 08:56:53 the mixer is confusing but i am trying... Jan 04 08:57:21 greentux: i know, we will be simplyfying soon with a config file Jan 04 08:57:50 there are some ALC capture settings, but cant set to "left" Jan 04 08:58:13 greentux: alc capture function ? Jan 04 08:58:29 iirc it has off, left, right and stereo as options Jan 04 08:58:30 alc capture attack time ... Jan 04 08:59:27 greentux: it might be best to wait until i can get my headset :( Jan 04 08:59:56 pga.. cant find :) Jan 04 09:00:36 ok left pga mux... thats? Jan 04 09:01:09 i think so, it's difficult to remember without my borzoi here Jan 04 09:02:02 jack ti mic or headset? Jan 04 09:03:35 don't understand Jan 04 09:03:43 afternoon Jan 04 09:03:59 jack function to MIC or HEADSET? Jan 04 09:04:11 afternoon reenoo_ Jan 04 09:04:23 hi lrg Jan 04 09:04:27 greentux: ah, jack function to headset Jan 04 09:05:50 greentux: does playback work when the jack function is headset ? Jan 04 09:06:22 greentux: it did with my headphones... Jan 04 09:07:29 yes Jan 04 09:07:47 greentux: cool, we are half way there :) Jan 04 09:08:03 in the record i can hear a "chirp" at start and beginning... Jan 04 09:08:36 greentux: can you check the dpm status when jack is headset. you should see mic bias as "on" Jan 04 09:08:51 how check dpm status? Jan 04 09:09:21 cat /sys/devices/platform/soc-audio/dpm Jan 04 09:09:55 mi cbias off Jan 04 09:10:36 ah, that looks like the problem. I'll fix this and test when I get my headset. Jan 04 09:10:37 sorry Jan 04 09:10:44 mic bias is on WHILE arecord :) Jan 04 09:11:09 greentux: ah, sorry, forgot to mention that a stream must be active first Jan 04 09:11:27 greentux: ok, this narrows it down to alsamixer settings. Jan 04 09:11:52 greentux: can i ssh into your borzoi ? Jan 04 09:13:18 not ATM... Jan 04 09:13:30 the aply/arecord say "Stereo"... Jan 04 09:13:38 thats the problem? used with -c1 Jan 04 09:14:25 lrg: the "line" means line in or out? Jan 04 09:14:44 ok, that looks like a bug then. I should get my headset by the start of next week. so hopefully we can have it working by the ned of next week. Jan 04 09:14:57 greentux: line is "line in" Jan 04 09:15:04 on borzoi Jan 04 09:16:54 just a moment... ssh Jan 04 09:17:30 lrg: Have you tested the mic bias control on cxx00 (its external to the one in the wm8750 remember)? Jan 04 09:18:08 RP: yes, I've added it as an external dpm widget, so it comes on by default. Jan 04 09:18:37 lrg: ok, fair enough :) Jan 04 09:29:35 RP: reading diffs right now which turns out to be rather confusing. have all do_stage() functions been reinstated now? Jan 04 09:30:23 reenoo_: Not all of jbowlers changes have but the ones most likely to be problematic have Jan 04 09:30:38 reenoo_: I'll try and verify nothing's changed with the remaining ones... Jan 04 09:30:50 and in doing so develop a script for testing such things... Jan 04 09:31:27 well. I still fail to see the reason for this vendetta. Jan 04 09:31:48 vendetta ? Jan 04 09:31:57 reenoo_: Its simple - it allows us to switch to the new autostaging at some point Jan 04 09:32:33 RP: jbowler's let's modify autotools_do_stage so we can link foo to bar? Jan 04 09:32:41 that's highly bogus Jan 04 09:33:01 reenoo_: We're not talking about the same thing evidently... Jan 04 09:33:26 quite likely Jan 04 09:33:27 reenoo_: You've read my staging propsal on oe@ ? Jan 04 09:34:29 well. in case you haven't noticed. you can introduce new tasks to do what you want Jan 04 09:34:37 cu all Jan 04 09:34:43 cu hrw|work Jan 04 09:34:47 there's no need to touch a single do_stage() Jan 04 09:35:31 cu hrw|work Jan 04 09:36:20 reenoo_: converting them to use autotools staging is a good move for improving the metadata *as long as nothing gets lost along the way*. Jan 04 09:37:27 no it's not. it introduces a shitload of changes people will have to verify. and the packages Makefiles aren't any more reliable than a do_stage(). most upstream Makefiles are highly bogus. Jan 04 09:38:08 it only applies to those packages which have sane Makefiles Jan 04 09:40:14 reenoo_: What you're suggesting is basically we never change anything as we might have to verify those changes. Lets just freeze .dev and be done with it Jan 04 09:41:08 I really don't get this "people will have to verify" thing.Hopefully people will make the changes correctly, esp if we can help them, prove the changes result in the same staging Jan 04 09:42:48 come up with a good reason why you need to touch hundreds of do_stage() functions and I'll be all for it Jan 04 09:43:57 reenoo_: How else do you plan for us to switch to new staging and to confirm things are working along the way without a gradual conversion of indvidual files? Jan 04 09:45:34 again, why do you need to touch any do_stage() to put staging under packaging control? Jan 04 09:46:18 becuase any alternative leaves two copies of staging functions. When two copies of anything exist, it invariably leads to bitrot in one or the other or better still both Jan 04 09:46:49 having a do_otherstage sounds like a recipe for confusion Jan 04 09:46:53 add a task before do_stage() that changes variables, have do_stage() do it's job, collect what it's installed in a package and install that Jan 04 09:47:13 in a task after do_stage() Jan 04 09:47:59 or, preferrably, use library and -dev packages as Koen and Phil suggested (like me before) Jan 04 09:48:22 really, there should be no need even for that. You'd just need to make a class that switches off do_stage() and instead implements staging by unpacking the ${PN} and ${PN}-dev packages. Jan 04 09:48:38 then, intrepid users can test the new stuff easily by adding that class to INHERIT, and everyone else can not care. Jan 04 09:48:52 even better Jan 04 09:49:02 Leaving two code paths and ample oppertunity for bitrot Jan 04 09:49:08 pb__: now thats a sweet solution Jan 04 09:50:01 If reenoo_'s arguments are consitent, he should now complain about the fact the -dev packages might contain differences to what's currently staged... Jan 04 09:50:11 no Jan 04 09:50:33 Then I totally fail to understand what the problem is Jan 04 09:50:35 using and fixing -dev packages has been a goal for more than a year now Jan 04 09:53:06 I'll be happy to accept all sorts of breakage if that's done in a separate class so others aren't affected and can continue to work with/on OE Jan 04 09:54:07 and in the meantime anyone working with this new class won't be able to build images for the foreseeable future until every bug is fixed Jan 04 09:54:18 nobody will work on such a system Jan 04 09:55:18 even that isn't true: semi-intrepid users could maintain a whitelist of packages that are known to work with the new scheme, and only enable the new bits for those packages. Jan 04 09:55:34 there's no fundamental reason that the two staging schemes can't coexist. Jan 04 09:56:37 or, conversely, one could maintain a blacklist of packages that have intractable difficulty with the new system and disable it for those ones. Jan 04 09:57:15 There's no fundamental reason we can't convert exsting packages to new staging system either Jan 04 09:58:14 There's certainly no reason you _can't_, but reenoo is correct that there are reasons why it might not be desirable. Jan 04 09:58:51 Any solution might result in breakage and hence not be desireable Jan 04 10:00:44 I've had enough of the issue and am tempted just to forget the whole thing and let someone else deal with it tbh (like several other things I've suggested trying to fix). Jan 04 10:00:56 Perhaps I should fork OE :) Jan 04 10:05:06 cu Jan 04 10:25:14 pb__: didn't you add task names to OVERRIDES once? Jan 04 10:31:18 I did, but I have a feeling that I was compelled to undo that change because of some unforeseen (and undesirable) side effect. Jan 04 10:35:24 hmm Jan 04 10:35:42 I was thinking along the lines of STAGING_DIR_do_stage Jan 04 10:38:41 oh, here we go Jan 04 10:38:47 data.setVar('OVERRIDES', 'task_%s:%s' % (item, old_overrides), localdata) Jan 04 10:39:21 so, STAGING_DIR_task_do_stage is probably what you want. Jan 04 10:41:25 right. and if that fails due to side effects a do_stage_prepend() should do the job Jan 04 10:42:19 yup, or that Jan 04 12:09:28 RP: I hope my message to oe@ helps clarify things a bit Jan 04 12:11:59 grrrr perl doesn't compile Jan 04 12:39:59 so, in case anybody was curious, I wrote a small example of how you could prototype a package-based staging system without needing to make any gratuitous edits to existing .bb files. Jan 04 12:40:35 http://handhelds.org/~pb/breakage.bbclass is the class in question. you'd need to put that in your classes directory, say INHERIT += "breakage" in your local.conf, and watch your staging area explode in smoke and flames. Jan 04 12:40:49 yay! Jan 04 12:40:58 not that I necessarily recommend anyone to actually try that, but the point is that only people who opt in to the breakage will experience it. Jan 04 12:41:03 :) Jan 04 12:41:54 * reenoo_ has a look at it Jan 04 12:42:24 pb_: You've only written the easy bit though. I had something similar yesterday I was playing with :) Jan 04 12:42:45 oh, sure. Someone else will have to write the code that actually does the work. Jan 04 12:42:48 pb_: we need to hook you up with a SCM that works for you! Jan 04 12:43:09 * RP has plans to implement a git trial Jan 04 12:43:16 All I was trying to demonstrate is that you don't need to go around butchering hundreds of .bb files in order to do this stuff. Jan 04 12:43:28 RP: I'm compiling darcs (actually ghc first) Jan 04 12:44:08 RP: then you have plans to go completely insane? Jan 04 12:44:15 I don't think this was actally ever in question. It was just seen that converting to use the autotools_stage_all() function was a nice interime steo as it told us the packages in question had working make installs Jan 04 12:44:17 Becuase thats what you need to do to even begin to understand git Jan 04 12:44:43 RP: given that the packages can produce output, I don't really understand why that was ever in questin. Jan 04 12:44:43 CosmicPenguin: I implemented the git fetcher in bitbake so its too late for that ;-) Jan 04 12:44:48 or, indeed, in question. Jan 04 12:45:00 pb_: So all our -dev packages work? Jan 04 12:45:21 RP: oh, that was you? I've been meaning to try to beat that up Jan 04 12:45:35 No, but it's not at all obvious to me how changing do_stage() will help with that problem. Jan 04 12:45:37 CosmicPenguin: Its fragile but does work if you're nice to it :) Jan 04 12:45:46 RP: agreed - stgit is decent Jan 04 12:45:57 If you're worried that "make install" doesn't work and the -dev packages are broken, you need to be looking at do_install. Jan 04 12:45:59 it makes life a bit easier, at least for me Jan 04 12:46:33 mithro: hey Jan 04 12:46:43 CosmicPenguin: I've not actually tried that. I must get around to it at some point :) Jan 04 12:46:43 mithro: do you have some pointers to DARCS and security? Jan 04 12:46:58 RP: how is 'push' handled with git nowadays? Jan 04 12:46:58 pb_: I agree with your e-mail, but I'm worried about trying to explain to my end-users why their development environment is carrying around N MB of useless (to them) binaries Jan 04 12:47:20 pb_: do_install is currently known to work well for the packages themselves but not for -dev. Swiching the do_stage methods to use thje install targets would start to show weaknesses in the -dev handling Jan 04 12:47:33 RP: the only gotcha is that you can't push a tree managed with stgit, because the hashes keep changing Jan 04 12:47:49 so you have to merge your stgit managed tree into another tree, and then push that Jan 04 12:48:22 zecke: yes Jan 04 12:48:42 CosmicPenguin: N isn't a big number. I doubt most people will see more than about 50MB of extra files, and I find it fairly hard to believe that many people will care about that much space. Jan 04 12:49:00 CosmicPenguin: Pulling with git was as far as I ever got - the main objective was a zaurus -git kernel building from OE and I moved to other things once I had that Jan 04 12:49:20 pb_: well, the main issue there would be downloading development environments over less then T1s Jan 04 12:49:24 CosmicPenguin: and, as I said in my mail, you know where the files live. If you want to get rid of them, you can just "rm -r" the right directory. Jan 04 12:49:30 zecke: yes and no, i'm not really an expert Jan 04 12:49:36 pb_: but generally I agree with you - but the people here have found the most incredible reasons to hate OE Jan 04 12:49:49 but you can run darcs without any more security then subversion/cvs has Jan 04 12:49:55 zecke: I'm not 100% sure which is why I'd want to set up a test system Jan 04 12:50:02 or you can use a signing of patches system (like GPG) Jan 04 12:50:18 zecke: I really want to do it using ssh though which means we're going to need a virtual machine to host the SCM :-/ Jan 04 12:50:28 mithro: okay signing. What happens if someone revokes his GnuPG key? Jan 04 12:51:06 RP: HTTP/1.1 (through ssl) might be more friendly to firewalled people? Jan 04 12:51:30 RP: it would, but it seems to me that it'd be a better use of time to (1) write the package-based staging infrastructure; (2) use it, and switch off do_stage; (3) fix any resulting breakage; and (4) if necessary, remove the obsolete do_stage methods. Jan 04 12:51:35 RP: do you know of some group that audited git? Jan 04 12:51:36 zecke: I'm told it doesn't work too well (locking is tricky for example) Jan 04 12:52:02 I find it hard to believe that changing do_stage is the right thing to do, when our aim is to get rid of it altogether. Jan 04 12:52:32 zecke: what normally happens when a person revokes his GnuPG key..... Jan 04 12:52:40 and particularly not if this is going to expose other people to a pile of collateral damage that they might not have been expecting. Jan 04 12:52:45 pb_: my point exactly... Jan 04 12:52:49 CosmicPenguin: heh. oh well. Jan 04 12:52:56 pb_: no worries Jan 04 12:53:05 pb_: I guess this comes down to different people's views of the migration path. We don't dispute the end goal. I'm not going to convert any packages but I'm not going to stop anyone else. I might help with a new autostage class. Jan 04 12:53:16 (nobody can sign anything with that key) Jan 04 12:53:49 If others feel the need to stop people changing do_stage, they can feel free but I'm keeping out of it Jan 04 12:54:50 The problem we now has is we have no leader for OE so nobody to give a final yes/no ... Jan 04 12:57:41 heh Jan 04 12:57:45 come back, kergoth, all is forgiven Jan 04 12:58:21 we should promote Phil to that position ;) Jan 04 12:58:41 kergoth's advantage was he'd done enough for the project for us to forgive any breakage and he has a reasonably thick skin :) Jan 04 12:59:43 Whilst I'm happy making changes to the Zaurus 2.6 machines and the kernels, the OE core isn't really something I have authority over and I'm not sure anyone else has either :-/. Jan 04 12:59:51 mithro: well, probably best to choose a leader who actually has write access to the tree. which is good, in a way, because it narrows down the field to about 14 candidates. Jan 04 13:00:42 pb_: write access is easy to give ;) Jan 04 13:01:09 mithro: I suspect pb_ doesn't like monotone though (I can't say I do much either) Jan 04 13:01:23 Especially after the joke that is the disappoval command... Jan 04 13:02:14 what is disapproval? Jan 04 13:02:32 it supposedly reverts a commit Jan 04 13:02:43 the occasional blowups, the db incompatibilities between versions, lack of non-trivial branching/merging, ... Jan 04 13:03:02 * reenoo_ sighs Jan 04 13:03:53 from the outside it looks like a disaster to me Jan 04 13:04:08 mithro: from the inside I'd say it is as well Jan 04 13:04:28 but we can't complain as koen will tell us nobody has setup an alternative which is true Jan 04 13:05:17 Alternatives are few and far between, and falling rapidlyl Jan 04 13:05:55 As far as I know, anyone is welcome to put together an alternative. Jan 04 13:06:08 * mithro would try both Mercurial and Darcs if I had time Jan 04 13:06:16 but i have my own projects to worry about Jan 04 13:09:41 Is Mercurial still in development? I thought the lead developer got trapped by McVoy Jan 04 13:11:58 CosmicPenguin: very much so Jan 04 13:12:08 it's been picked up by Intel and the Xen guys Jan 04 13:12:29 Ahh, cool Jan 04 13:12:36 Stupid news websites only report the bad shit Jan 04 13:12:38 never the good news Jan 04 13:13:01 git push appears to mainly work via ssh and most other transports look broken according to google Jan 04 13:14:21 hire Jan 04 13:14:30 off topic : is US or UK the gen 06 is holiday ? Jan 04 13:14:44 hi hrw Jan 04 13:15:21 gremlin[it]: I don't understand what gen means? Jan 04 13:15:22 gremlin[it]: not a US holiday Jan 04 13:15:35 RP: January Jan 04 13:15:47 ah, not in the UK then Jan 04 13:15:59 gremlin[it]: not in PL too Jan 04 13:16:18 RP : January ... Jan 04 13:18:33 ok thanks ... for us is the closing holiday for xmas period ... (when mage reach jesus if i remember correct) ... anyway was just to give the next patch a 'name' :) Jan 04 13:19:04 gremlin[it]: Epiphany... :) Jan 04 13:19:07 (Three Kings day too) Jan 04 13:19:14 Also Orthadox Christmas Eve Jan 04 13:19:20 Orthodox even Jan 04 13:19:50 http://www.earthcalendar.net/_php/lookup.php?mode=date&m=1&d=6&y=2006 Jan 04 13:19:58 mhh nice ;) Jan 04 13:20:48 asic3 was in which ipaq models? Jan 04 13:21:44 h1900, h3900, hx4700 Jan 04 13:21:59 oh, and h4100/h4300 Jan 04 13:22:22 pb_: what needs to happen to win you for OE development again? Jan 04 13:22:27 thx Jan 04 13:23:14 pb_: h5500 too? Jan 04 13:23:55 hrw: no, all the h5x00 units use samcop Jan 04 13:24:05 thx Jan 04 13:24:21 zecke: mm, interesting question. unfortunately, using a different scm would certainly be part of it. Jan 04 13:24:44 pb_: ln -s monotone foo-scm won't cut it I guess? Jan 04 13:24:56 heh Jan 04 13:25:03 no, I fear I would see through that deception Jan 04 13:25:36 pb_: Would just the scm help or are there other factors? Jan 04 13:25:55 zecke: I guess it's true what they say about never knowing what you've got until it's gone. I never expected I would have fond memories of bitkeeper. Jan 04 13:26:01 heh Jan 04 13:26:01 pb_: using a hardlink instead? Jan 04 13:26:33 zecke: ah no, I store all my binaries on vfat filesystems to avoid such deception Jan 04 13:26:55 good choiche Jan 04 13:27:08 pb_: heh. I believe I said round about the same during the SCM introduction I gave at univerity. Jan 04 13:27:18 Somebody is going to google that from the ibot logs some day, and its going to hit slashdot Jan 04 13:27:29 "open source guru Phill Blundell uses VFAT!!!" Jan 04 13:28:31 CosmicPenguin: "And loves bitkeeper" :) Jan 04 13:28:32 pb_: well what requirements other than being able to pull/clone more fast do you have? Jan 04 13:29:21 zecke: basically just that, plus generally less all-round flakiness. Jan 04 13:30:29 pb_: using darcs would allow you to pull darcs and git ;) Jan 04 13:30:34 admittedly bitkeeper did also destroy my local repositories from time to time, which was irritating enough, but I get the impression that monotone takes this to a whole other level. Jan 04 13:31:04 the thing that's most infuriating about monotone, I guess, is that the ostensible reason for using it is due to its wonderful peer-to-peer nature, but I don't really derive any benefit from that aspect of it. Jan 04 13:31:40 personally I would be quite content with a traditional centralised SCM system. Jan 04 13:31:41 pb_: to some degree true Jan 04 13:31:57 pb_: I want to do svn diff when I'm on the road Jan 04 13:32:07 pb_: but I want to do check-in's as well Jan 04 13:32:32 being able to svn diff locally is a very big plus... Jan 04 13:32:35 * florian_ would be able to live with this too. Jan 04 13:32:51 Is UML still the choice of VM these days? Jan 04 13:33:01 RP: Xen? Jan 04 13:33:04 zecke: yeah, being able to do checkins would certainly be a bonus, but just being able to do diffs solves 75% of my problems. Jan 04 13:33:36 RP: Xen seems to be flavour of the month, if you want to do Linux-on-Linux. It's a bit more intrusive than UML though. Jan 04 13:33:50 pb_: I want: fast pull, local diff, local ci's Jan 04 13:34:14 pb_: but I also want to trust the data (security) ;) Jan 04 13:34:25 zecke: I want: fast pull, local diff, file integrity, and fewer hectoring emails from koen. Jan 04 13:34:48 zecke: how about using svk (locally) for added features? Jan 04 13:34:50 bbl Jan 04 13:35:04 zecke: and storing gpg signatures in svn attributes? Jan 04 13:35:13 Hmm. Xen isn't an option - too intrusive... Jan 04 13:35:22 reenoo_: I have not used svk Jan 04 13:35:34 reenoo_: do you have an automatic generation of signatures in place? Jan 04 13:35:49 RP: in that case, yeah, uml is probably your best option Jan 04 13:36:02 pb_: I guess for hosting a database on hh.org it will need to use trusted infrastructure? ssh? Jan 04 13:38:20 Ciao all Jan 04 13:38:35 reenoo_: also you have pointed out that cherry picking is nice to have/wanted Jan 04 13:38:48 reenoo_: would that be a requirement as well? Jan 04 13:38:53 ~lart kmail authors for lack of threads in app Jan 04 13:38:53 * ibot gives kmail authors a "free" copy of Windows and then charges double for "Upgrades" for lack of threads in app Jan 04 13:38:54 zecke: no. but that shouldn't be difficult to implement. lots of applications store additional information in svn that way. Jan 04 13:39:32 RP: tell your boss figment rocks! Jan 04 13:40:35 zecke: yeah, I guess so Jan 04 13:40:36 hi pigi Jan 04 13:40:43 hi pb_ Jan 04 13:40:58 zecke: cherry picking is not a strong requirement for me. Jan 04 13:42:00 zecke: it would be nice to have, but working branching/merging *that people understand* will not make it neccessary. Jan 04 13:43:51 zecke: will do :) Jan 04 13:44:14 We don't have cherry picking and never have had - a working SCM without it would be better than monotone :) Jan 04 13:44:43 RP: to tell you the truth I'm not too unhappy with monotone but open for alternatives Jan 04 13:45:16 hmm darcs can not copy directories? Jan 04 13:45:21 zecke: Try disaproving a commit, then tell me that :) Jan 04 13:46:19 RP: might be true Jan 04 13:47:31 zecke: I don't know. I do however know that montone can't copy *anything* Jan 04 13:47:48 zecke: monotone bug #13810 Jan 04 13:48:09 question: I want to connect from one Z to another via irda. c760 has getty on ttyS1, collie has opie-console conected to ttyS1 but it does not work. what did I forgot? Jan 04 13:48:32 hrw: connecting the cable? Jan 04 13:48:41 hrw: is it using the same baud-rate? Jan 04 13:48:44 heh Jan 04 13:49:08 I guess irda and cables don't go together that well ;) Jan 04 13:49:12 zecke: ttyS1 are irda on both and both 115200. I know that I lack knowledge there Jan 04 13:51:02 Is there not some irda command needed to turn on the IR? Jan 04 13:51:17 * RP is clueless when it comes to irda... Jan 04 13:53:36 reenoo_: to sum up the monotone discussion (as far as I'm concerned anyway): monotone was supposed to replace cvs for gcc. gcc has moved to svn now. I believe we should learn from that. Jan 04 13:54:28 reenoo_: 'g'-'m' implies we should switch to 's'+('g'-'m')? Jan 04 13:55:00 france: ping ;) Jan 04 13:55:10 ~herring zecke Jan 04 13:55:11 * ibot whacks zecke on the side of the head with a large red herring named alfred Jan 04 13:55:29 I've not seen anyone actually say they like monotone which says something... Jan 04 13:55:50 RP: I like monotone ;) Jan 04 13:56:05 RP: I still trust it enough to store my data ;) Jan 04 13:57:12 reenoo_: can I use stuff like websvn/viewcsv on top of svk? Jan 04 13:57:12 zecke: This can only mean you're going a bit mad ;-) Jan 04 13:58:09 zecke: AIUI svk is just a layer on top of svn. so, you should be able to use those with one of the distributed underlying svn tree Jan 04 13:58:15 s Jan 04 13:59:53 got it ;) Jan 04 14:00:43 btw - tinylogin getty display password request on host not on client Jan 04 14:01:58 hrw: What did you have to do to get it working out of interest? Jan 04 14:02:16 * RP might actually try irda on the zaurus kernels one of these days :) Jan 04 14:04:03 RP: irattach on both to /dev/ttyS1 (standard). then 'getty 115200 ircomm0' on host and connect to /dev/ircomm0 on client Jan 04 14:04:14 now I need setconsole Jan 04 14:06:44 busybox 1.1.0-pre1 contain it (and many more) Jan 04 14:09:04 Seesh - we're on 1.1.0-pre1? I need to pay more attention Jan 04 14:09:06 To summarize the SCM talk: If either git, darcs, svn+svk is performing reasonable well it is very likely that we switch?! Jan 04 14:09:37 That all depends on how we announce the trial, and provide upgrade paths to external projects (like dreambox etc) Jan 04 14:10:04 zecke: That sums up the position as I see it Jan 04 14:10:53 what is really important for me is: We should not punish current contributors Jan 04 14:11:41 zecke: punishment is continuing to use monotone ;-) (but yes, I see the serious point) Jan 04 14:11:42 CosmicPenguin: we are not Jan 04 14:12:07 CosmicPenguin: More like 1.0.0 iirc... Jan 04 14:12:19 s/we/busybox/ Jan 04 14:12:24 zecke: yeah. although, personally, I'd prefer svn+svk since the svn's on-disk format is unlikely to change (and even if, migration can be done in two commands). Jan 04 14:12:52 RP: lol Jan 04 14:13:09 CosmicPenguin: it has e2fsprogs, less, fuser build-in Jan 04 14:13:34 zecke: as far as darcs is concerned, I'm not comfortable with how it relies on ghc which is pain to port or use on less-frequently used platforms during upgrades Jan 04 14:13:41 pb_: how is the POSIX command called to list all groups? (it is not getgroups) Jan 04 14:13:57 reenoo_: I'm compiling ghc for the last 5 hours ;) Jan 04 14:14:13 zecke: getent group? Jan 04 14:15:49 reenoo_: POSIX.? wise please ;) Jan 04 14:16:12 zecke: we've had serious issues with the sparc port of 6.4 Jan 04 14:16:39 zecke: at work that is Jan 04 14:16:44 zecke: I guess you need to use getgrent(). Jan 04 14:16:50 pb_, is it logical that if package foo (has) replace(d) bar (partially), then bar depends on foo ? Jan 04 14:17:01 pb_: thanks Jan 04 14:17:07 Pigi: I don't think so Jan 04 14:17:10 Pigi: heh Jan 04 14:17:40 good, then I have found another. But basically it seems logical: xserver-common replace ( partially ) gpe-session-scripts. Jan 04 14:18:03 Now, if I remove xserver-common, gpe-session-script does not work no more Jan 04 14:18:40 _alwin_: ping. What is apr doing in subversion? Jan 04 14:18:44 It's even more logical with gpe-dm ( which is replaced by xsession-common ) Jan 04 14:18:50 yeah, I guess that's true. I don't think dpkg enforces that relationship, though, and I guess ipkg shouldn't either. Jan 04 14:19:35 but it doesn't sound too bad.... it could protect the users from breaking too much things... Jan 04 14:19:52 true Jan 04 14:20:30 then I should have a testing environment for the "replaces" trouble. Who is so brave to test it ? Jan 04 14:20:41 <_alwin_> zecke: puh, as i know it is the main interface between apache and subversion and subversion uses the memory allocation stuff of apr Jan 04 14:25:48 france: The only group handling I found in svn (searching for grp.h and the functions) did not show any use of a fixed sized array to store group names Jan 04 14:25:58 france: this means svn should be safe for usage within hh.org Jan 04 14:30:39 would importing a repo corresponding to a 2GB svn dump be of interest as a test? Jan 04 14:30:40 hehe - same shit, different SCM Jan 04 14:30:41 classic Jan 04 14:31:14 reenoo_: I would use cvs2svn on the CVSROOT from bitmover and tailor Jan 04 14:31:29 reenoo_: I will mail admin@handhelds.org and ask for permission to start a svn test drive Jan 04 14:33:10 <_alwin_> zecke: remember, svn may using groups via apache and stuff, thats why apr. Jan 04 14:33:47 _alwin_: I would like to use svn without apache (over ssh) Jan 04 14:34:05 <_alwin_> zecke: eg., you may store groups for instance in sql-databases and so on - no runtime problems anymore with big arrays, same as cvs using the system groups Jan 04 14:34:42 <_alwin_> zecke: thats ok, svn may use apache features even when not using http but svn+ssh Jan 04 14:36:16 <_alwin_> with new svn 1.3 it seems to work perfect. Jan 04 14:41:24 anyone has a gpe-sessions-scripts.ipk and gpe-dm.ipk from 0.8.2 ? Jan 04 14:44:22 Pigi: uh, can't you get them from the feed? Jan 04 14:44:59 for gpe-dm yes, but it seems that in 0.8.2 feed the gpe-sessions-scripts is only for collie. Jan 04 14:45:11 oh, right Jan 04 14:45:20 that one should be fine for testing ipkg Jan 04 14:45:27 the collie and h3600 packages are (iirc) identical anyway Jan 04 14:45:28 yeah Jan 04 14:49:46 zecke: well. I'm running this now. Jan 04 14:51:35 zecke: fwiw, users/groups on the project server I run at university are in ldap/kerberos (funky group names too due to windows...) Jan 04 14:51:54 zecke: haven't had any issues with svn yet Jan 04 14:53:47 reenoo_: I remember france mentioned hh.org is running a patched glibc, cvs due the group handling Jan 04 14:54:21 reenoo_: I have mailed hh.org admins and asked to allow me doing a svn test drive Jan 04 14:54:27 Does anyone know why the umountfs script is not symlinked in rc0.d and rc6.d? The commands to do that are in the initscripts .bb, but commented out. Jan 04 14:54:53 reenoo_: well svnk test cases fail :} Jan 04 14:55:01 they're necessary to get local filesystems umounted cleanly Jan 04 15:06:46 zecke: that is unfortunate Jan 04 15:09:20 0.99.155 is officially out. Good luck ;) Jan 04 15:09:27 heh Jan 04 15:11:09 opie-pm still memleaks with libipkg? Jan 04 15:11:51 hi hrw !. I didn't notice memleaks in ipkg with valgrind. Jan 04 15:13:39 so it's really a PITA ( is that right ? ) cause valgrind don't show memleaks and opie-pm do .... Jan 04 15:14:14 and bug which has over year is still Jan 04 15:14:47 hrw, I would really be glad to fix if i could have some more pointer, really. Jan 04 15:15:39 Pigi: I know. ;( Jan 04 15:16:13 maybe a testcase...or eventually a valgrinding from opie side..... Jan 04 15:17:17 Pigi: testcase was simple: run opie-pm on 64M device, select 10 pacakges to remove/install and go - sooner or later die. Jan 04 15:17:52 but you told me that the same 10 packages, installed by ipkg itself don't give a trouble, am I right ? Jan 04 15:18:21 I dunno nothing about opie or ( even worst ) cpp, so it's really hard for me to hunt this bug Jan 04 15:18:23 does anyone know a small setup that can run oe ? something the size of a phone or something Jan 04 15:20:05 it's that time, now. I'll wait for bugs in bugzilla for 0.99.155. Jan 04 15:20:09 nite all Jan 04 15:20:14 n8 pigi Jan 04 15:20:52 webmind: I know that koen run OE on slug but its larger then cellphone.. Jan 04 15:22:33 how big is ? Jan 04 15:23:03 ~google linksys nslu2 Jan 04 15:23:05 good nite Jan 04 15:23:31 'night zecke Jan 04 15:23:45 https://www.datacareservices.com/franca.com/htdocs/slug/ < -that slug ? Jan 04 15:24:11 ~nslu2 Jan 04 15:24:13 hmm... nslu2 is a Linksys network storage device. It runs linux and features an ixp4xx processor, and is hackable. See http://www.linksys.com/products/product.asp?grid=35&scid=43&prid=640, http://www.nslu2-linux.org/ Jan 04 15:24:17 OT: http://www.angelina-merkel.de/ Jan 04 15:24:20 that one Jan 04 15:24:43 ah Jan 04 15:24:53 that won't fit :( Jan 04 15:24:54 ~stab zecke Jan 04 15:24:56 * ibot runs at zecke with an origami Swiss Army knife, and inflicts a nasty paper cut. Jan 04 15:25:09 zecke: thanks for sharing... Jan 04 15:25:55 reenoo_: fell in love already? Jan 04 15:26:16 absolutely Jan 04 15:26:53 (it was just posted on our RoboCup mailing list...) Jan 04 15:26:53 I guess the picture on the front page will haunt me in my dreams already Jan 04 15:27:02 reenoo_: then try http://www.angelina-merkel.de/angelina.pdf Jan 04 15:37:53 cu Jan 04 15:40:44 Yay, pxa27x-hcd patches look like they might make post 2.6.15 :) Jan 04 15:43:51 good nite Jan 04 16:07:31 heya folks Jan 04 16:07:36 ~seen koen Jan 04 16:07:47 koen was last seen on IRC in channel #handhelds.org, 5d 1h 46m 57s ago, saying: 'but I now notice the @frumar.it'. Jan 04 16:08:36 ~botmail for koen hiya koen i updated it http://bugs.openembedded.org/show_bug.cgi?id=540 and also submitted the gpe-login.patch upstream as you asked. Jan 04 16:08:59 ttfn - back to #htc-blueangel.... Jan 04 16:29:54 heya folks. Jan 04 16:30:31 anyone know what i'm supposed to put in local.conf to do an opie-image bitbake build? i have a gpe-image successfully built, with ozfam083 and all that. Jan 04 16:30:57 lkcl: Just run 'bitbake opie-image' Jan 04 16:34:43 Has all the dust settled from the staging changes? I'm wondering if it's safe to update yet. Jan 04 16:39:04 thanks, NAbyss - i was just wondering because when i tried that a couple of days ago, it died with a compile error: i'm using thingy. an amd64 system to do the building on Jan 04 16:43:54 mreimer: I think so.. I did a pull last night (about 10 hours ago).. opie-image and zaurus-updater compiled successfully Jan 04 16:44:02 thanks NAbyss Jan 04 16:44:21 np Jan 04 16:46:53 ta NAbyss back to #htc-blueangel will try it again, let you know what happens. Jan 04 17:00:06 mreimer: the worst stuff has been reverted. there are still some related changes left though. Jan 04 17:00:51 fwiw, opie is probably largely unaffected by this Jan 04 17:04:09 <[lala_]> i'm still unable to build gpe-image from .dev for oz-unstable ... still atk configure stage does break, though differently as the day before Jan 04 17:04:46 <[lala_]> i did a clean build, meaning wiping tmp Jan 04 17:05:25 <[lala_]> could someone else try to build it? maybe it's just me :) Jan 04 17:05:38 [lala_]: reenoo advised me that you need to change DISTRO="familiar-0.8.3" to DISTRO="familiar-dev" - have you already done that? Jan 04 17:06:02 <[lala_]> i'm using openzaurus-dev, yes Jan 04 17:06:15 <[lala_]> openzaurus-unstable that is Jan 04 17:06:47 <[lala_]> opie-image builds fine Jan 04 17:07:33 i built gpe-image yesterday - first time in 8 days - with reenoo's advice. Jan 04 17:11:44 <[lala_]> did you use the latest version of oe or were you building with an older local copy? Jan 04 17:12:13 <[lala_]> it has worked for me before as well, but not with the latest changes Jan 04 17:12:27 i did a monotone update yesterday at the same time, too. Jan 04 17:13:32 <[lala_]> thats pretty odd then Jan 04 17:14:18 well. unless you wipe tmp chances are all files are still in staging Jan 04 17:14:37 take a look at bugs.openembedded.org ? 540 Jan 04 17:14:47 there are a _stack_ of things i had to do to get a build working. Jan 04 17:14:54 spelling mistakes Jan 04 17:15:07 SRC_URIs with things that might be the wrong way round Jan 04 17:15:20 autotootls instead of autotools was one of the spelling mistakes Jan 04 17:15:37 the SRC_URI changes sound more like a bug in the fetcher code Jan 04 17:15:49 gnu_config is downloading from cvs.savannah.nongnu.org rather than cvs.sv.nongnu.org Jan 04 17:16:28 yeh - i switched the order and put the pserver bit before the module to be fetched and it works - the other way round it doesn't. Jan 04 17:16:37 *shrug* Jan 04 17:16:41 <[lala_]> renoo: i did wipe my tmp as i clearly stated :-) Jan 04 17:17:14 [lala_]: best leave a comment in bugzilla Jan 04 17:17:34 btw, if anyone's interested, cr2 has managed to get haret.exe compiled up on gnu tools instead of wince or wince under wine. Jan 04 17:17:36 http://jornada820.sf.net/files/gnuharet.exe Jan 04 17:17:48 it _doesn't_ have the graphical bootloader (i don't think) Jan 04 17:17:59 but he's adding a _stack_ load more commands, including "dump wince" Jan 04 17:18:12 and support for pxa27x extra GPIO lines Jan 04 17:18:20 and dumping of asic3 i think is in there, too. Jan 04 17:21:23 lkcl: sounds cool Jan 04 17:21:30 * reenoo_ heads off to bed for now Jan 04 17:21:32 'night all Jan 04 17:21:40 night Jan 04 17:21:44 HaRET(10)# dump asic3gpio Jan 04 17:21:44 A3GPIO# D S A IN | A3GPIO# D S A IN | A3GPIO# D S A IN | A3GPIO# D S A IN Jan 04 17:21:44 ------------------+-------------------+-------------------+------------------ Jan 04 17:21:44 0 I 1 0 RE FE | 16 I 1 0 FE | 32 O 0 1 | 48 O 1 2 Jan 04 17:21:45 1 I 1 1 | 17 I 1 0 FE | 33 O 1 2 | 49 O 1 2 Jan 04 17:21:49 etc.... Jan 04 17:22:32 lkcl: cool Jan 04 18:06:00 lkcl, you were able to build gpe-image using the dev tree? Jan 04 18:06:20 fyliu : yes i was. Jan 04 18:06:44 no problems. well - no problems after i patched a few things Jan 04 18:06:54 and got advice from reenoo Jan 04 18:07:12 but i just tried opie-image Jan 04 18:07:30 I was able to do it with the oz354fam083 branch but not the dev Jan 04 18:07:37 and it stuffs up: uicmoc-native-2.3.10-r0/ Jan 04 18:07:38 oh yes. Jan 04 18:07:40 yes, of course. Jan 04 18:07:48 yes - i used oz354fam083. Jan 04 18:07:52 and also dev. Jan 04 18:08:15 i put both in. got lots of 3-way merge problems when i did a monotone update. ignored those. Jan 04 18:09:10 you put both of them in the same directory? Jan 04 18:09:26 yeh, with opie i'm getting compile errors uicmoc-native-2.3.10/r0/qt-2.3.10/include/qxml:462 warning class QXmlDeclHandler has virtual functions but non-vurtial destructor. and a whole lot of other ones like that. Jan 04 18:09:58 and kernel/qmemorymanager_qws.h: In constructor QSMCacheItemPtr 129 and 130 error cast from 'char*' to 'int' loses precision Jan 04 18:10:08 i guess that this is because i'm compiling on an amd64 system... Jan 04 18:10:51 I saw your bug report but unfortunately I don't know enough to help you Jan 04 18:11:00 ah well :) Jan 04 18:11:46 I was just curious when I saw you using org.openembedded.dev/packages... in your local.conf Jan 04 18:12:26 i did? i just blindly do things and if it works i carry on... :) Jan 04 18:13:25 well... making that a long instead of an int seems to have done the trick. it's an AMD64 thing: char* is 64-bit, int is 32-bit... *sigh*. Jan 04 18:13:31 BBFILES := "/home/lkcl/oe2/org.openembedded.dev/packages/*/*.bb" Jan 04 18:13:31 from your attached file Jan 04 18:13:54 whoops... more of them. ah this is going to be fun... Jan 04 18:14:44 #handhelds.org Jan 04 18:49:55 okay - i got a compile of uicmov-native-2.3.10-r0. a very _hacked_ version, going through and replacing (int) with (long) typecasts in several places Jan 04 18:54:49 well that looks like i can leave it safely running overnight, now... maybe :) Jan 04 21:13:55 ibot Jan 04 21:58:15 okay, another amd64-specific compile error patch, this time on uicmoc3-native-3.3.x-r1 Jan 04 21:58:27 http://bugs.openembedded.org/show_bug.cgi?id=574 Jan 04 21:59:30 i haven't done a "proper" job - i'm not interested in "proper" jobs i'm interested in "quickest way to get it working". if "quickest" turns out at some point in the future to actually need "proper" then obviously i'll tackle it, if someone else hasn't. Jan 04 22:00:52 but those two hack-patches have at least allowed me to carry on building bitbake opie-image for the blueangel, on an amd64 system. hurrah. back to bed, come back in a few hours, see if it worked :) Jan 04 22:02:20 hey btw if anyone's interested: yes, both the himalaya and the blueangel can make phonecalls, but because we're not intialising the i2c bus correctly, the mic doesn't work on the himalaya and there's a hacked version of haret which allows sound to be played on the blueangel, so wince gets the uda1380 initialised for you ... :) Jan 04 22:02:52 it's all very horrible but it works. ick :) Jan 05 01:04:08 morning all ! Jan 05 01:14:09 good morning Jan 05 01:14:54 re Jan 05 01:17:09 i have problem with running cgi script with boa www server Jan 05 01:19:15 or even thttpd Jan 05 01:20:44 all the $ENV{ is empty Jan 05 01:35:58 linnuxxy: this is not a distribution support channel. this channel exists for those using bitbake and oe to build distributions. if you're having a problem building boa with oe, then people here will help you. beyond that, it's unlikely Jan 05 01:40:49 you are helping so much kergoth... thank you Jan 05 01:43:01 in the future i'd recommend reading the topic of channels you join Jan 05 01:43:07 will avoid problems Jan 05 01:50:15 morning Jan 05 01:50:45 morning XorA Jan 05 01:51:37 XorA : do u know abt cgi with boa or thttpd? Jan 05 01:57:25 linnuxxy: I have thttpd installed but havent tried cgi with it Jan 05 01:57:50 linnuxxy: I used to run both years ago on x86 servers, but my memory is vague Jan 05 01:58:28 where should i fowrword my question? Jan 05 01:58:57 linnuxxy: I would look on the respective mailing lists for those apps, I assume you are running from OE compiled stuff? Jan 05 01:59:10 linnuxxy: have you checked the .bb files that cgi capability is enabled Jan 05 02:00:15 what .bb file? Jan 05 02:01:08 linnuxxy: the build recipe oe uses Jan 05 02:01:31 the cgi is working fine.... only the $ENV{} is all empty Jan 05 02:02:05 linnuxxy: then you should check the respective websites, we only build from the source Jan 05 02:11:22 i think the problem is in the microperl Jan 05 02:12:03 linnuxxy: never heard of microperl Jan 05 02:12:15 morning Jan 05 02:12:34 morning all Jan 05 02:12:44 hey RO Jan 05 02:12:48 s/RO/RP Jan 05 02:13:03 microperl is a lightwight perl version Jan 05 02:14:01 morning RP Jan 05 02:18:13 <[lala]> morning all Jan 05 02:18:35 <[lala]> greentux: i have an opie-image now, gpe-image is still complicated Jan 05 02:18:54 [lala]: ok... when do u arrive? Jan 05 02:19:05 <[lala]> in about 10-15 minutes i guess Jan 05 02:19:22 fine Jan 05 02:19:42 <[lala]> anything important going on? Jan 05 02:22:13 [lala]: no.. Jan 05 02:28:43 hi,all Jan 05 02:31:46 whether the x86 also has a opie-image simple to spitz's? Jan 05 02:31:58 s/simple/similar Jan 05 02:32:38 oyo: you can probably roll your own with a little work Jan 05 02:34:18 Xora : are you aware of any installer for a x86 image ? Jan 05 02:37:01 morning all Jan 05 02:37:36 morning Dirk Jan 05 02:37:36 morning Jan 05 02:37:40 and hrw|work Jan 05 02:38:44 * hrw|work builds 2.6.15 with mmc.patch from lakml Jan 05 02:38:49 hi Richard and Marcin Jan 05 02:38:50 greentux_alt: ping Jan 05 02:38:57 hi Dirk Jan 05 02:39:11 hrw|work: Which mmc patch is that? Jan 05 02:39:21 [PATCH][RFC] MMC CMD1 problem. Jan 05 02:39:34 2006-01-05 10:20 - fresh mail Jan 05 02:39:35 XorA:Does oe can build one ? Jan 05 02:39:46 small change in command timeouts Jan 05 02:40:06 hrw|work: pong, just a minute Jan 05 02:40:22 oyo: machine=x86;bitbake opie-image and you will get it Jan 05 02:40:46 hum , thank hrw :-) Jan 05 02:43:14 hrw|work: That's interesting... Jan 05 02:43:44 RP: yep Jan 05 02:44:02 XorA: "dd if=initrd.ext2 of=/dev/hda1" requires a working linux station... i think i'll try to find a way to include initrd on a bootable cd, and maybe there is a way to make a script for the installation... Jan 05 02:44:20 RP: if this wont help I will probably send card to rmk for some time Jan 05 02:46:50 hrw|work: ok. The trouble with bugs like that is they can take up a lot of time with no guaranteed fix :-/ Jan 05 02:47:20 RP: and I think that he will resolve it sooner then I :) Jan 05 02:47:58 hrw|work: perhaps, if he has time to work on it :) Jan 05 02:48:34 hrw: you around? Can I get a copy of your ipkg.cfg? Jan 05 02:48:45 packageman just ran out of ram and ipkg went haywire Jan 05 02:48:54 it deleted all the packages i had on there Jan 05 02:49:04 so now i need to reflash cuz its bricked Jan 05 02:49:16 it was like packagename=nil Jan 05 02:49:18 and kept scrolling Jan 05 02:50:43 RP: led_trigger_register_simple("sharpsl-charge"... in sharpsl_pm_probe doesn't register the led-trigger is this a known issue? I'am using rc5-r3. Or is this fixed in newer patches? Jan 05 02:50:51 df00z: http://ewi546.ewi.utwente.nl/tmp/hrw/oz-3.5.4-rc-poodle/ipkg.conf Jan 05 02:51:21 RP: ofcourse Jan 05 02:51:56 Thanks Jan 05 02:52:36 god, when will they come out with non volatile wear-free solid state SD cards Jan 05 02:52:43 i need a swap file Jan 05 02:53:14 df00z: and when linuxpda could use any SD/MMC card... Jan 05 02:53:30 Hm? Jan 05 02:53:38 SDIO? that wont happen Jan 05 02:53:53 no one is gonna write drivers, and i think most Zauruses don't even have all the pins hooked up Jan 05 02:54:33 i dont wanna put a swap file on my SD card Jan 05 02:54:36 itl wear it out :( Jan 05 02:54:51 do13_: That has always worked as far as I know? Jan 05 02:55:12 df00z: Most Zaurii hardware can support it acatually Jan 05 02:55:15 df00z: I have sd card which c760 does not like Jan 05 02:56:06 RP: Really? Hrm. Jan 05 02:56:27 I wonder how hard it would be to make an SD - USB mass storage adapter, or SD - CF storage Jan 05 02:56:28 lol Jan 05 02:56:52 df00z: in which way 'make an SD - USB mass storage adapter'? Jan 05 02:58:24 a PCB that would take the SD card requests and translate them to how a USB keydrive is accessed Jan 05 02:58:42 df00z: modprobe g_file_storage with proper params Jan 05 02:58:49 RP: Ahh ok found it: default_trigger in leds/tosa.c must be "sharpsl-charge" not "charge". This was also wrong in your old spitz.c:) Jan 05 02:59:03 do13_: Ah, I did fix that bug :) Jan 05 02:59:04 <[lala]> re Jan 05 02:59:12 what is g_file_storage Jan 05 02:59:39 df00z: usb gadget mass storage Jan 05 02:59:44 do13_: It was originally called charge but I decided it was too generic and renamed it but forgot to update spitz.c the first time around ... Jan 05 02:59:54 RP:) **** ENDING LOGGING AT Thu Jan 05 02:59:59 2006