**** BEGIN LOGGING AT Wed Jun 14 02:59:56 2006 Jun 14 06:03:43 v8jlene: your docu is high-quality! Jun 14 06:09:30 morning Jun 14 06:48:15 hrw: morning Jun 14 06:50:53 morning Jun 14 07:16:28 hey zecke Jun 14 07:17:01 hey Jun 14 07:37:47 morning Jun 14 07:58:33 morning Jun 14 07:59:01 Heyas Jun 14 08:02:35 hey hrw|work Jun 14 08:02:38 hey NAbyss Jun 14 08:04:26 good morning Jun 14 08:36:09 ljp: hi, are you there? Jun 14 08:47:11 goxboxlive: he lives in Australia, so he probably sleeps now Jun 14 08:48:17 :-) Jun 14 09:03:13 gvimdiff with 2 files can be not easy.... both has ~200000 lines and 15-20M in size.. Jun 14 09:16:31 hi Liam Jun 14 09:17:59 hey Marcin Jun 14 09:38:07 morning all Jun 14 09:39:14 hi RP Jun 14 09:41:49 hey RP Jun 14 09:43:05 hey RP Liam Jun 14 09:44:22 Hey XorA Jun 14 10:45:03 RP: thx for mail on linux-fbdev about logo on rotated console. I had this on my todo list but forgot to send Jun 14 10:45:38 ~seen koen Jun 14 10:45:53 koen was last seen on IRC in channel #oe, 7d 15h 47m 30s ago, saying: 'no idea'. Jun 14 10:46:07 wow, that is a long time ago. Jun 14 10:46:14 Is koen on vacation? Jun 14 10:46:52 I just read he got accepted for Google SoC which I think is great. I'd like to congratulate here. What will he be working on? Jun 14 10:48:43 Laibsch: populate staging with packages Jun 14 11:09:53 ARGH... Jun 14 11:10:11 SRC_URI_append_MACHINE should work - right? Jun 14 11:11:04 found. fscking ' ' Jun 14 11:23:46 hrw|work: I do not understand "populate staging with packages". Will that be his assignment for SoC? Jun 14 11:24:16 hrw|work: I did a little debugging on it last night, as you'll gather :) Jun 14 11:24:32 Laibsch: now we do not have control over do_stage() thing Jun 14 11:24:56 RP: r35 is coming for kernel Jun 14 11:25:03 hi zecke Jun 14 11:25:46 Laibsch: idea is to have packaged staging/cross so it will be easier to control it, share with others etc Jun 14 11:26:45 hrw|work: I'm working on the changes. I'd like to get the logos working properly first before I push it... Jun 14 11:27:21 RP: my change is small - getting logo patch applied at all Jun 14 11:27:35 RP: rotated models has logo disabled of course Jun 14 11:31:57 RP: .dev: "linux-openzaurus: REALLY apply logo patches" Jun 14 11:32:29 RP: .oz354x got r34 from .dev and "linux-openzaurus: REALLY apply logo patches" (which is r35) Jun 14 11:41:42 hrw|work: ok. I'll hopefully be able to debug the logo issue a bit more tonight :) Jun 14 11:42:39 RP: great Jun 14 12:00:20 Laibsch: basically, you could do it that way: instead of directly putting something into STAGING_DIR at do_stage() time, you could put that into a XZY-dev.ipkg, and then install the -dev.ipkg into staging Jun 14 12:00:46 Laibsch: that way you can give the *.dev.ipks to someone else, who can re-create the staging without OE Jun 14 12:01:31 hrw|work: btw, Germany will win! :-) Jun 14 12:01:56 schurig: sadly this approach has issues Jun 14 12:02:10 zecke: absolute paths? Jun 14 12:02:10 schurig: with libtool, pkg-config and toolchain :( Jun 14 12:02:30 schurig: yupp. You would require/force a file layout... Jun 14 12:03:07 schurig: as usual - polish football team never win with german in past Jun 14 12:04:20 hi all Jun 14 12:08:23 zecke: so here is your patch - after reading (http://www.handhelds.org/hypermail/oe-commits/18/1835.html) I think it is not in openempedded style but it fits my needs. just add it fix it your self or let it broken. here are the simpad.conf diff (http://pastebin.com/708333) and here( http://pastebin.com/708334) the local.config.sampe patch. because I have unscrewed my pcmcia to cf adaper to look inside I can't test any image at the moment. but it bu Jun 14 12:09:39 morning Jun 14 12:09:50 poland - grmny Jun 14 12:09:53 3:1 Jun 14 12:09:54 ;p Jun 14 12:10:45 wishful thinking Jun 14 12:11:06 mr_nice: please use bugs.openembedded.org Jun 14 12:11:10 mr_nice: and unified diffs Jun 14 12:11:30 besides, i have since fixed simpad.conf Jun 14 12:11:33 just needs someone to test Jun 14 12:12:41 o.. mickeyl Jun 14 12:13:58 mickeyl:I am willing to test it Jun 14 12:14:10 good Jun 14 12:14:18 only thing to do is set ZKERNEL_VERSION Jun 14 12:14:19 lol Jun 14 12:14:30 "2.4" for 2.4, "2.6" for 2.6 Jun 14 12:14:34 go and watch RoboCup... Jun 14 12:15:02 zecke : do you have a url to watch it ? Jun 14 12:15:04 who's playing? Jun 14 12:15:13 robocup.zdf.de Jun 14 12:15:18 thanks Jun 14 12:15:21 stream2 (mid size) Jun 14 12:15:31 Philipps against a portugese team... Jun 14 12:15:37 they play bad... Jun 14 12:17:04 my bitbake is busy at the moment but after that I will test it. Jun 14 12:17:24 mickeyl: we should do s/ZKERNEL_VERSION/something nicer.. Jun 14 12:18:47 hrw|work: I'm open for recommendations. Jun 14 12:18:53 I think a describing text over the variable will do it Jun 14 12:19:16 MACHINE_KERNEL_VERSION = "2.6" ? Jun 14 12:19:45 that would indicate the relationship to MACHINE setting Jun 14 12:19:52 or MACHINE_KERNEL only? Jun 14 12:20:01 that would be inconsistent with DISTRO_VERSION then Jun 14 12:21:12 well if it is discribed in the comment above the varialbe the name isn't that importent but MACHINE_KERNEL_VERSION sounds good Jun 14 12:21:24 why does phillip suck so much? Jun 14 12:21:34 no improvement on their robots in the last five years Jun 14 12:22:02 hrw|work: MACHINE_KERNEL_VERSION ok for you? Jun 14 12:24:40 ciao I will go out now. Jun 14 12:24:46 hrw|work: btw, i have finally settled on using wordpress for my new site. the decision took long, but after evaluating all the alternatives, WP looks like the best compromise to me - if not writing my own Jun 14 12:25:25 which also means I'll start blogging again soon Jun 14 12:25:49 MACHINE_KERNEL_VERSION is mych better Jun 14 12:26:05 s/mych/much Jun 14 12:26:34 k, i'll do it now Jun 14 12:26:41 hi Jun 14 12:26:53 but MACHINE_KERNEL_MAJOR_VERSION = "2.4" is more decriptive but also suxx more Jun 14 12:27:05 mickel: how to get this message ibotmail? Jun 14 12:27:08 descriptive Jun 14 12:27:13 mr_nice: botmail read Jun 14 12:27:14 botmail read Jun 14 12:27:19 botmail read Jun 14 12:27:21 hrw|work: heh, yeah, it's a bit long :) Jun 14 12:27:23 sorry Jun 14 12:27:25 mom Jun 14 12:27:25 mr_nice: msg to ibot Jun 14 12:27:30 ibot: tell mr_nice about botmail Jun 14 12:27:31 ;P Jun 14 12:28:48 mickeyl: I'm doing probably something with Django and a hand-made Blog :-) Jun 14 12:28:57 ibot: botmail read Jun 14 12:28:59 mickeyl: but MACHINE_* is more correct than current situation Jun 14 12:29:09 is it a command? Jun 14 12:29:15 mickeyl: atleast it is kind of namespace Jun 14 12:29:26 hi schurig. yeah, i had my handcoded for long, but now i'm looking for something more integrated Jun 14 12:29:27 a now it has worked Jun 14 12:29:28 mr_nice: /query ibot and use help command Jun 14 12:29:28 thx Jun 14 12:29:36 hrw|work: *nod*. we have to enforce some more namespace changes Jun 14 12:29:41 ciao Jun 14 12:29:45 mickeyl: I wanted something with Sqlite, programmable in a sane language (python) and where I can upload the changed pages to my static-pages-only-webspace-provider Jun 14 12:30:29 mickeyl: MACHINE_HAS_BT kind too? Jun 14 12:31:16 hrw|work: yes. i think we will want more stuff like this to describe MACHINE features eventually Jun 14 12:31:32 + a bit of logic to select the appropriate task packages Jun 14 12:31:34 mickeyl: and sub-dependencies on them etc... Jun 14 12:31:37 *nod* Jun 14 12:32:08 mickeyl: if MACHINE_HAS_PCMCIA OR MACHINE_HAS_CF then { MACHINE_HAS_BT=1; MACHINE_HAS_WIFI=1; etc} Jun 14 12:32:53 hrw|work: if coded sanely this would allow for better customized results without requiring too much fiddling with OE recipes by developers Jun 14 12:32:59 mickeyl: maybe in the gentoo way, e.g. USE += Bluetooth, USE += GSM :-) Jun 14 12:33:17 ya, perhaps :) Jun 14 12:34:01 mickeyl: I had this idea in the old age, when we had a brainstorming page on openzaurus.org about OE. At that time, some people didn't like the idea, so it was never pursued. Jun 14 12:34:42 schurig: ya, that's when we were still in the more-or-less-everything-is-a-handheld-mode. We have widened our scope since then. Jun 14 12:35:25 Jun 14 12:35:26 configurations: use MACHINE_KERNEL_VERSION whenever your MACHINE setting supports more than one major kernel version. Jun 14 12:35:28 Jun 14 12:35:52 the idea behind gentoo's USE variable is that variouse ebuild check for values in it and then use that for decisions. Mostly to specify options to ./configure, but it can be used for other things as well. Jun 14 12:36:58 schurig: "USE += gnutls -= openssl"? Jun 14 12:37:05 brb Jun 14 12:37:10 is ebuild emitting different names for the packages then? I don't think we want OE to emit same package names with different configurations Jun 14 12:37:21 mickeyl: no, it doesn't Jun 14 12:37:30 that's a problem in my opinion. Jun 14 12:37:33 mickeyl: no, gentoo has no packages :) Jun 14 12:37:48 no? ok, never seen it :) Jun 14 12:38:00 zecke: yes, gentoo HAS packages, it can generate binary, installable packages. It's just that no-one uses them. Jun 14 12:38:35 mickeyl: the problem is that (when I used Gentoo the last time, 1 1/2 years ago) it had about 500 different USE variables for everything. Jun 14 12:39:12 mickeyl: Some packages, e.g. Qt, would check for 10 different ones. It's not convenient to add the values of all 10 used "USE" variables to the Qt package ... Jun 14 12:39:25 ya, that doesn't sound appealing Jun 14 12:40:28 mickeyl: but I guess that USE= is mostly in machine.conf, then the machine specific IPK extension would be enought. If the USE is in a distro.conf, then we don't care, because IPKs of different distros are in different feeds anyway. Jun 14 12:40:47 and if the USE= is in local.conf, then the user is making his own IPKs and he knows what he's doing (hopefully) Jun 14 12:41:32 with "machine specific IPK extension" I mean busybox_1.23_mnci.ipk, as opposed to armv5te or arm, or all. Jun 14 12:41:55 yeah Jun 14 12:42:12 re Jun 14 12:42:15 wb Jun 14 12:43:40 I created a meta file in packages/meta containing all of the programs I want to build into my rootfs, everything is working well, I just want to verify that I'm using RDEPENDS and DEPENDS correctly as I have read some postings stating people are not always using them correctly. I'm putting the programs I want to be added into the RDEPENDS (boa, vim..) Jun 14 12:43:58 Gerrath: thats correct way Jun 14 12:44:06 my DEPENDS is task-bootstrap Jun 14 12:44:34 Gerrath: put task-bootstrap into RDEPENDS and it will appear in DEPENDS automatically Jun 14 12:44:57 hrw|work, so I really do not need the DEPENDS variable. Jun 14 12:45:07 Gerrath: exactly Jun 14 12:45:16 Rather than this USE idea, why not split the packages into tasks. Machines can then just say something like MACHINE_TASKS = "pcmcia bt cf" ? Jun 14 12:45:18 hrw|work, so what do you put into DEPENDS then? Jun 14 12:45:28 Gerrath: do not use it Jun 14 12:46:05 hrw|work, ok, good I wanted to get this straight because I'm going to post an example on a support website and I do not want to miss-lead people. Jun 14 12:46:15 Gerrath: gerrath-image.bb = inherit image_ipk, set image_name, RDEPENDS='list of stuff', IPKG_INSTALL='${RDEPENDS}' Jun 14 12:46:26 Gerrath: well then help on the user manual Jun 14 12:46:28 Gerrath: and then usual stuff like DESCRIPTION etc Jun 14 12:46:32 Gerrath: and point the support site to the manual Jun 14 12:47:02 RP: yes, that's the other alternative. We'll have to chose one eventually. Jun 14 12:47:03 zecke, I plan on it, I'm spending a lot of time getting up to speed now but once I'm there I hope to contribute as much as I can :) Jun 14 12:47:22 zecke, I already pointed the site to the manual Jun 14 12:47:29 good :) Jun 14 12:48:52 mickeyl: I'm in favour of the latter as I suspect it can be simpler and avoids people confusing it with gentoo Jun 14 12:49:48 hrw|work, when you refered to set image_name, that is the same as "export IMAGE_BASENAME = "my_image_name"? Jun 14 12:49:59 yes Jun 14 12:50:36 RP: yes it's simpler, but also less capable. the USE thing is more generic and is more leaning towards package features than machine features. We could start with the MACHINE_TASK thing and then see whether we want to have the USE stuff as well Jun 14 12:51:32 * emte is confused Jun 14 12:51:47 why would you rdepends on task-bootstrap? Jun 14 12:52:02 that seems to violate it's purpose Jun 14 12:52:21 mickeyl: I'm not sure how one is more or less capable. Have you an example of something you can do with one but not the other? Jun 14 12:53:10 emte: if I want task-bootstrap in image then I RDEPEND on it Jun 14 12:53:33 emte: or not.. /me confused Jun 14 12:53:53 images do RDEPEND on task-bootstrap so as they get built :) Jun 14 12:54:15 images don't generate packages so you never actually see an RDEPEND on task-bootstrap in the image Jun 14 12:54:16 RP: well, it's probably rather a matter of intention than of capability. MACHINE_TASK += ssl sounds odd to me whereas USE += ssl sounds like something that's evaluated and taken into account for EXTRA_OECONF. Jun 14 12:54:42 RP: it's more a matter of what we want it to stand for Jun 14 12:54:51 morning Jun 14 12:54:55 Boling's postulate: Jun 14 12:54:55 If you're feeling good, don't worry. You'll get over it. Jun 14 12:54:58 i was under the impression that rdepends was now only currently to be used to denote actual package rdeps Jun 14 12:55:04 as part of the cleanup Jun 14 12:55:22 mickeyl: I'd say ssl is more of a distro option and should be handled elsewhere, perhaps based on rootfs size Jun 14 12:55:36 (rootfs size being a machine property) Jun 14 12:55:41 right Jun 14 12:55:54 mickeyl: BUILD_TASKS = MACHINE_TASKS + DISTRO_TASKS? Jun 14 12:55:55 mickeyl: DISTRO_TASKS :) Jun 14 12:56:04 yeha! Jun 14 12:56:08 :) Jun 14 12:56:09 that would make sense Jun 14 12:56:28 time to unify stuff like GPE_MACHINE_CLASS ROOTFS_SIZE USE_DEVFS USE_VT Jun 14 12:56:38 RP: ping Jun 14 12:56:38 i always found we use too many seemingly unrelated machine vars Jun 14 12:56:56 i'll be glad to see these going away and being unified Jun 14 12:56:59 mickeyl: USE_DEVFS should die - its a distro option and familar only Jun 14 12:57:04 rwhitby-away: pong Jun 14 12:57:22 collie: MACHINE_TASKS = "bt qvga wlan cf keyboard" Jun 14 12:57:34 RP: I'm refreshing the nslu2-linux LEDs patches against 2.6.17-rc6, and I've got a situation where there was a "lock" field which was used in ledtrig-cpu.c, but that field doesn't appear in the structure any more. Do you know anything about that? Jun 14 12:57:51 MACHINE_ROOTFS_SIZE = 14000000 Jun 14 12:58:24 rwhitby-away: I rejigged the patches in mainline after akpm pointed out a potential deadlock. There was one I decided was totally unneeded after the rewrite Jun 14 13:00:30 talking about LEDs. Would a patch making an extra attribute for the trigger-brightness value being accepted? Jun 14 13:01:03 i.e. for a lot of PWM LEDs i don't want them to be triggered with full power Jun 14 13:02:02 mickeyl: That gets very tricky. Is it a per LED or a per trigger option? :-/ Jun 14 13:02:09 RP: this is the patch in question: http://trac.nslu2-linux.org/kernel/file/trunk/patches/2.6.17/951-ixp4xx-leds-cpu-activity.patch Jun 14 13:02:27 RP: it's per LED since it would be an extra sysfs attribute Jun 14 13:02:43 foo-amber/trigger_brightness Jun 14 13:02:56 that only is present when a trigger is chosen Jun 14 13:03:03 unrelated to the brightness value Jun 14 13:03:06 mickeyl: or even - collie: MACHINE_TASKS = "qvga cf bt wlan keyboard irda serial apm backlight" - so irda-utils will get into, same with bluez-utils, wireless-tools, pcmcia-manager, apmd, bl, keymaps, lszrz (for serial/irda/bt) Jun 14 13:03:07 RP: search for led->lock in that patch Jun 14 13:03:41 hrw|work: yeah. something like that Jun 14 13:03:56 RP: do I re-add the lock field in my patch, or is there another way to do that? Jun 14 13:04:15 RP: first patch for problem sent ;) Jun 14 13:06:32 cya later Jun 14 13:09:10 i have a problem with pxafb. newer releases discourage setting LCCR3_HSP|LCCR3_VSP|LCCR3_PCD in LCC3. On my LCD I have a strange line appearing when I don't set these. Do I need to adjust a margin or should I just set the values and ignore pxafb moaning about illegal bits? Jun 14 13:10:42 rwhitby: You don't need this lock field Jun 14 13:11:01 RP: I'm all ears ... Jun 14 13:12:52 RP: do I just remove the locks altogether, or do I use something else as the argument? Jun 14 13:13:18 rwhitby: I'm trying to work out if this code is safe... Jun 14 13:13:32 ok, thx. Jun 14 13:13:37 * rwhitby stands by ... Jun 14 13:13:56 rwhitby: Basically, trigger.leddev_list_lock will protect against LED removal so you never need anything other than that Jun 14 13:14:14 rwhitby: But the question is are there any code paths where it isn't held? Jun 14 13:14:39 RP: it's not my patch, and I haven't looked at the code, so I can't answer that. Jun 14 13:14:50 I'm just playing a dumb patch refresher at the moment :-) Jun 14 13:15:29 rwhitby: Also, that lock is taken as a write lock in interrupt context so the code can deadlock Jun 14 13:16:09 RP: what's the worst that can happen if I just remove those lock and unlock calls? Jun 14 13:16:34 rwhitby: Worst case the locking is bad and the kernel crashes Jun 14 13:16:52 However its unlikely Jun 14 13:17:27 RP: may I add this conversation to the bug report which I'll send to jbowler? Jun 14 13:17:38 rwhitby: yes Jun 14 13:17:59 rwhitby: I need time to work out what that patch needs which I haven't got atm. I'll try and look at it tonight if you like though Jun 14 13:18:28 RP: that would be much appreciated. Would you like svn write access so you can test it? Jun 14 13:19:15 Hello... is this channel for hardware as well as software embedded development? Jun 14 13:19:43 mimizukujin, depending on the question #elinux might be a better place Jun 14 13:20:31 Well, I've got this old LCD module that I'm thinking of trying to turn into an ebook-reader for cheap. I really don't have any idea where to begin, though. Jun 14 13:20:33 rwhitby: Maybe in due course. I'm working towards playing with the nslu2 :) Jun 14 13:20:45 rwhitby: The OZ kernel also needs a logo fix tonight :) Jun 14 13:20:50 mimizukujin, try #linux Jun 14 13:20:57 Ok. Thanks. Jun 14 13:21:05 er #elinux they may be able to better answer the question Jun 14 13:21:28 * mimizukujin will idle here for a bit too, if it's ok. Jun 14 13:21:36 np Jun 14 13:23:35 RP: further info on svn repo write access sent by email ... Jun 14 13:25:56 rwhitby: Thanks. I'll have a look at that later on Jun 14 13:26:07 RP: thx. no great hurry. Jun 14 13:27:07 I use the following in a cronjob to keep my OE up to date. Jun 14 13:27:09 pidof monotone; if [ "${?}" != 0 ]; then cd /usr/src/openembedded/org.openembedded.dev && quilt pop -a && nice monotone update; cd ../org.openembedded.oz354x; quilt pop -a && monotone update; fi Jun 14 13:27:49 quilt pop -a is there to remove patches I applied to OE. (I prefer it to straight monotone) Jun 14 13:28:59 "quilt pop -a &&" is not working correctly since it will also return a non-zero state when there were no patches applied to be removed, not only when removing an applied patch failed. Jun 14 13:29:14 Anybody have a suggestion how to deal with this? Jun 14 13:29:56 Laibsch, does it return different non-zero state? Jun 14 13:30:09 I am not sure. Jun 14 13:30:32 It returns 2 when there was no patch applied to be removed. Jun 14 13:30:37 well, try to see into it, maybe this is where you can branch Jun 14 13:30:41 I can't find the error code doc for quilt. Jun 14 13:30:59 Laibsch, well, quiltp pop -a ; echo $? ;-) Jun 14 13:32:13 No, that is only the last error code. Jun 14 13:32:22 I need a reference of codes Jun 14 13:32:36 What does 0, 1, 2, 3, etc. really mean. Jun 14 13:34:11 The last, which means the one from quilt pop Jun 14 13:34:23 just check it right after quilt pop command. Jun 14 13:38:05 Still need a document where it says 2 is used in situation xy and 1 is used in situation ab. That is what I am talking about. Jun 14 13:38:33 Laibsch: Use the source, Luke. Jun 14 13:41:07 rwhitby: I cannot spot the obivous file where to look for it. Jun 14 13:57:05 Laibsch, grep is your friend, then. Jun 14 14:02:10 polyonymous: doesn't look like there is a single file where it is documented. Or I am using the wrong grep words to filter. Jun 14 14:03:07 not documented, used. In fact, if I knew your answers I'd tell you, but I don't use quilt so I don't feel like digging the source myself... Jun 14 14:40:39 Hi all ! Jun 14 14:40:48 hi Ifaistos Jun 14 14:42:29 hrw|work : Hi. It looks like most of the OE people like footbal :) Jun 14 14:42:45 hrw|work : Very quite these days... Jun 14 14:42:58 I piss on football Jun 14 14:43:32 heh - wait until poland vs germany - most of this room will be on one side or the other Jun 14 14:43:59 CosmicPenguin: who will be on poland side? (not me) Jun 14 14:44:12 ok, I guess they'll just be on the germany side then Jun 14 14:44:12 australia vs brazil will be a laugh.. see how many points we lose by Jun 14 14:44:33 CosmicPenguin: polish football team never win with germans Jun 14 14:44:36 bet it will be less then the US vs CZ Jun 14 14:46:11 i'm for poland Jun 14 14:46:16 that is Jun 14 14:46:19 if they don't play against us Jun 14 14:46:32 mickeyl: o.. suprised me Jun 14 14:46:44 i'm for poland because of you :) Jun 14 14:47:04 funny that you aren't interested Jun 14 14:47:04 heh Jun 14 14:47:35 mickeyl: I prefer basket or athletics over football Jun 14 14:47:55 kick him out of the channel :) Jun 14 14:48:15 wow - basketball? Jun 14 14:48:17 really? Jun 14 14:48:47 the guys in the office these past few days talk about football and how much many the bet on each game... Jun 14 14:49:30 If they are right by the end of the games...they should be millionairs :/ Jun 14 14:49:36 and stop working.... Jun 14 14:49:52 but i have this funny feeling they will still be here :) Jun 14 14:50:07 heh Jun 14 14:51:55 om a more serius matter... Does anyone know a way to "debug" udev ? Actually what happens when it runs Jun 14 14:52:07 hi what about something oe specific ;) , I try to compile microwindow within the dreambox distro, I changed the VTSWITCH to N but now I have this strange error I dont understand: Jun 14 14:52:07 mipsel-linux-ld: cannot open output file /opt/dreambox/build/tmp/work/microwindows-0.90-r0/microwindows-0.90/src/lib/: Is a directory Jun 14 14:52:07 Could someone explain what this means ??? Jun 14 14:52:15 Ifaistos: there is a flag you can turn on Jun 14 14:52:19 Ifaistos: udevmonitor IIRC Jun 14 14:52:47 hi Jun 14 14:53:28 Oh - heh - I didn't know about udevmonitor Jun 14 14:53:29 slick Jun 14 14:54:03 I can't do DDC, tux Jun 14 14:55:06 CIA-9: gammu: upgraded to 1.07.00 (.dev .oz354x) Jun 14 14:55:23 sorry - wrong room Jun 14 15:01:09 CoreDump|afk: Interesting. Thanks. Jun 14 15:01:52 Ifaistos: np ;) Jun 14 15:03:20 CoreDump|home: gpe-dm start on runlevel 2 and 5 - I will change it to 5 only Jun 14 15:03:50 FYI intresting read -> How udev works http://vrfy.org/log/ Jun 14 15:04:15 hrw: thanks Jun 14 15:05:17 Ifaistos: http://vrfy.org/log/recent-state-of-udev.html even Jun 14 15:06:55 Ifaistos: remember that udev rules parser change from version to version... Jun 14 15:25:40 CIA-9: opie-mediummount: do not show during First start wizard (.dev .oz354x) Jun 14 15:26:29 CIA-9: gpe-dm: start only on runlevel 5 (runlevel 2 is for NoGUI start) (.oz354x) Jun 14 15:28:14 unixlite.org Jun 14 15:28:21 * pb__ gnashes teeth at the mention of gpe-dm runlevel changes Jun 14 15:28:33 haeh? Jun 14 15:29:12 not that it matters in .oz354x, of course. hrw is welcome to do whatever he wants in that branch. Jun 14 15:31:00 pb__: out of interest, why should gpe-dm start in runlevel 2? Jun 14 15:31:05 ***mace goes home for soccer, ciao Jun 14 15:31:05 pb__: or is gpe-dm bad? Jun 14 15:31:46 pb__: oz has altboot on all devices and runlevel 2 is set as nogui one (CoreDump decision months ago). some users complain about gpe-dm starting on this level so changed Jun 14 15:31:47 zecke: in some distros (notably debian and familiar) runlevel 2 is the default. Jun 14 15:32:19 please, not that discussion again... Jun 14 15:32:29 no, no discussion :) Jun 14 15:32:33 jist curious Jun 14 15:35:18 zecke: http://oe.pastebin.com/708700 - can you look Jun 14 15:35:20 ? Jun 14 15:36:28 hrw|work: hmm Jun 14 15:37:24 1st FirstUse is normally used a readBoolEntry Jun 14 15:37:29 zecke: check taken from opie-language Jun 14 15:37:53 I'm looking at core/launcher/main.cpp Jun 14 15:38:09 lol Jun 14 15:38:23 another "Do not apply, this patch is wrong" kind of application... Jun 14 15:39:19 hrw: omg, that bug you just "fixed" is years old. I kinda gave up hope on ever seeing that heh Jun 14 15:40:01 hmm Jun 14 15:40:04 CoreDump|home: I had idea how to fix it for some time Jun 14 15:40:21 ~praise hrw Jun 14 15:40:23 All hail hrw! Jun 14 15:40:44 doesn't this patch show an empty dialog/window? Jun 14 15:41:10 zecke: not here - but I can check with clean image Jun 14 15:43:22 hmm Jun 14 15:43:42 mmh Jun 14 15:43:47 did you see documentlist.cpp? Jun 14 15:44:22 zecke: see - same as opie-language Jun 14 15:44:33 zecke: copy/paste all over the opie... Jun 14 15:44:40 and this test fails twice? Jun 14 15:44:58 I see the 'restart after changing the language'-bubble Jun 14 15:45:01 and we can mediums... Jun 14 15:45:42 lol Jun 14 15:45:56 let us fix documentlist.cpp instead Jun 14 15:46:42 zecke: ok - I can look at it during Friday probably. now will leave that fix which I show Jun 14 15:46:53 default value is '42' == 0 Jun 14 15:47:17 hmmm Jun 14 15:47:27 strange Jun 14 15:47:57 hrw|work: Friday sounds good ( I have my exam at 10h ) Jun 14 15:48:11 afterwards I will feel les... Jun 14 15:48:14 anyway cya later Jun 14 15:49:57 cu all Jun 14 16:10:06 Well i havent had any qustions here for over two weeks now, so i feel free to ask now. I am building for the HTC Universal, and i am trying to build a Opioe-kdepim-image but it breaks at kdepimpi. Here is the output. : http://pastebin.com/708786 Jun 14 16:10:41 It is the dev branch, bitbake 1.4.3 Jun 14 16:11:00 run! Jun 14 16:11:17 kresources/resource.h:28:20: qmutex.h: Ingen slik fil eller filkatalog Jun 14 16:11:22 heh Jun 14 16:11:31 The error is "Ingnen slik fill eller filkatalog" Jun 14 16:11:33 Ingen slik fil eller filkatalog = No such file or directory Jun 14 16:11:52 and you built QtE MT? Jun 14 16:11:57 Ah, it sounded like disk full to me ;-) Jun 14 16:12:23 yes i am, should i rather build witout MT? Jun 14 16:12:30 goxboxlive: just asking Jun 14 16:12:45 goxboxlive: open kresources/resource.h and paste it please Jun 14 16:14:01 today I tried to add task-gpe-base to my opie installation and run gpe... The thing went berserk about alignment traps ;-) Jun 14 16:14:38 lol Jun 14 16:14:58 * zecke needs airconditioning Jun 14 16:15:14 what are those traps, btw? something like word operation not on the word boundary? Jun 14 16:15:35 yes Jun 14 16:15:51 *-word access Jun 14 16:15:59 Aha... Jun 14 16:16:19 Now how come it does so much to me and, probably, works for others? compiler problem? Jun 14 16:16:38 http://lxr.linux.no/source/Documentation/arm/mem_alignment Jun 14 16:16:47 Thank you Jun 14 16:16:49 polyonymous: what platform, compiler, libc? Jun 14 16:17:07 .dev oz Jun 14 16:17:44 Well, supposedly unstable, I'm trying to understand things here rather than find someone to blame it on :) Jun 14 16:17:44 that doesn't say anything :) Jun 14 16:17:58 I guess this means xscale+glibc Jun 14 16:18:02 spitz, glibc, gcc don't-remember what Jun 14 16:18:18 so it is either a compiler bug, or just cosmic energy... Jun 14 16:18:30 heh - I love how uclibc says "finally finished compiling" Jun 14 16:18:47 I don't think a 5 minute build qualifies for "finally" Jun 14 16:18:55 That's what I'm trying to figure. Is gcc heavily affected by cosmic penguin... erm.. energy? :) Jun 14 16:19:34 polyonymous: did you compile the stuff yourself? Jun 14 16:19:42 polyonymous: use a gpe binary, run it Jun 14 16:20:00 polyonymous: save the address of the pc, use addr2line on the binary (unstripped) Jun 14 16:20:06 polyonymous: disassemble it etc... Jun 14 16:20:21