**** BEGIN LOGGING AT Tue Jul 05 23:59:56 2005 Jul 06 00:10:52 i tried to compile the bluez-utils./-libs combo but did not get an ipkg when building the lib package - is this intended? Jul 06 00:14:19 obviously not - checked the other meta bb's Jul 06 00:20:23 got an image; but it does not work straight away; i need to create some device nodes and setup environment ; add few env variables, load some modules; how do i ensure this gets done automatically by bitbake. where should i make these conf entries ? Jul 06 00:23:03 eJumbo: there should be a package that does this for you - base-files, I think. Jul 06 00:23:48 morning folks Jul 06 00:24:39 eJumbo: look into meta/task-bootstrap and what it depends on Jul 06 00:27:23 base-files is a package which consists of basic files like in /etc issue, nsswitch.conf things like that. Jul 06 00:28:52 when i enable tslib. for tslib to work i need 2 device node in /dev/input/event0 and /dev/input/event1. and some TSLIB_XXX env. variables need to be there at startup. but i dont find any. how do i ensure these are already there when image is created ? Jul 06 00:35:38 eJumbo: consider using udev ? Jul 06 00:37:18 morning Jul 06 00:37:59 eJumbo: look how it is done for other devices Jul 06 00:42:24 too many files; atleast where it is done ?. directory ? Jul 06 00:43:06 already oe is ported to my device ; omap 5912. but it does not do that. i dont know why ?. Jul 06 00:44:18 eJumbo: openembedded/packages/tslib/tslib/*/ Jul 06 00:44:51 omap5912osk/ has ts.conf and tslib.sh Jul 06 00:46:09 yes Jul 06 00:46:27 but why the devices nodes are not created in /dev/input Jul 06 00:46:42 it is not done there at tslib/ Jul 06 00:49:12 eJumbo: why are not created is a thing which you should talk with other omap5912osk developers not with OE devs - maybe your board config is wrong or something in OE is not yet complete.. iirc here are only 2-3 persons with that board Jul 06 00:50:30 fine Jul 06 00:53:14 what i meant was when the filesystem is created; in dev directory ; how does oe know what devices to be created; i know this is created on the fly may be; but from where oe picks up the device names to be created ? Jul 06 00:53:40 /etc/device_table.txt Jul 06 00:54:02 See /etc/init.d/devices Jul 06 00:54:50 (The image creation command might use a different table though). Jul 06 00:56:38 which /etc. there is no file system at all. i am creating a new image. how does image creation utility know what devices exists on the image. this is different for different boards; it depends on configuration of kernel and drivers i need. this may change. how oe knows this device node must be created if say tslib is selected. where is this info embedded in ? Jul 06 00:57:01 i hope u get my question. this is about how oe really works ? Jul 06 00:58:09 It's in a text file, input to the 'makedevs' command (at least). This may or may not be used in creation of the image and the same file may or may not be copied into the image - it depends on the image. Jul 06 00:58:31 E.g. the image may have an empty /dev directory. Jul 06 00:59:51 jbowler-away: check packages/initscripts/*/device_table.txt Jul 06 01:00:28 I know what's in there, it isn't always the file which is used. Jul 06 01:00:39 yes. Jul 06 01:00:53 all entries dont end up in ur filesystem. Jul 06 01:01:08 In particular check in 'files' ;-) Jul 06 01:04:16 classes/image_ipk.bbclass is where some of the work happens, bbimage, however, is also important (and it's not in OE) Jul 06 01:08:26 morning all Jul 06 01:11:08 hi rp Jul 06 01:11:21 RP: weirdness of battery: Jul 06 01:12:05 RP: I left work with 70-80% of battery, goes home, attached AC and my Z restarted when I turn it on an hour later Jul 06 01:15:26 hrw|work: RP lardman and I have also noticed 2.6.12-mm1 doesnt actually power down the Z in suspend Jul 06 01:15:35 morning btw Jul 06 01:15:56 ;( Jul 06 01:16:58 and I can say one about pcmcia hotplug in 2.6.12-mm1 Jul 06 01:17:08 It suxx with out-of-kernel modules Jul 06 01:17:49 hostap does not define supported card list so it cannot be modprobed by pcmcia hotplug (pcmciautils instead of pcmcia-cs) Jul 06 01:19:21 RP: Morning. Jul 06 01:19:51 * XorA boggles Jul 06 01:20:10 linus was always against building support card lists and the such into the kernel what changed! Jul 06 01:20:32 v10:20 hrw@work:hrw$ gcc --version Jul 06 01:20:32 gcc (GCC) 4.0.1 20050701 (prerelease) (Debian 4.0.0-12) Jul 06 01:20:36 finally... Jul 06 01:24:06 a strange problem of glibc-2.3.5+cvs20050627.bb Jul 06 01:24:24 when I do: for r in ${rpcsvc}; do h=`echo $r|sed -e's,\.x$,.h,'`; rpcgen -h $r -o $h; done Jul 06 01:24:45 it reports: cannot find any C preprocessor (cpp) Jul 06 01:24:45 rpcgen: C preprocessor failed with exit code 1 Jul 06 01:25:20 I have to specify cpp path for rpcgen with option -Y Jul 06 01:26:11 in fact, cpp is a symblic link to cpp-4.0 in /usr/bin Jul 06 01:26:44 what's wrong? Jul 06 01:40:14 i have given IMAGE_FSTYPES="jffs2" but i dont get a jffs2 file at all. all i get is a .ext2.gz Jul 06 01:40:27 i mean image with file system ? Jul 06 01:41:04 checked distro conf and machine conf? Jul 06 01:42:33 morning boys and gals Jul 06 01:42:45 hi mickeyl Jul 06 01:43:10 morning mickeyl Jul 06 01:43:13 mickeyl: gals like GAL16V4? Jul 06 01:43:41 hrw|work: I remeber programming GALS :-) Jul 06 01:43:43 FYI: monotone.vanille.de was down since yesterday 21:00 up to today 10:30 because of our router crashing. It's up again Jul 06 01:43:49 hrw|work: hehe :) Jul 06 01:44:01 XorA: I never did it but know chips Jul 06 01:44:02 now I fail to program wifes! Jul 06 01:44:09 XorA: sucker ;) Jul 06 01:44:23 ~lart bitbake cache Jul 06 01:44:23 * ibot shoves a crumpet down bitbake cache's throat, happy now?! Huh? Want some JAM with that? Jul 06 01:44:30 hrw|work: GALS were sweet, a whole wodge of TTL logic all compressed into one little chip Jul 06 01:44:36 ups.. lart udev.inc Jul 06 01:44:36 hrw|work: did not understand what u said ? Jul 06 01:44:56 mickeyl, this mean anything to you? Jul 06 01:44:59 File "/home/packages/nslu2/mtn/unslung/bitbake//bin/bbimage", line 23, in ? Jul 06 01:44:59 from bb import * Jul 06 01:44:59 AttributeError: 'module' object has no attribute 'make' Jul 06 01:45:06 eJumbo: look into config of used distro and used machine - they have higher pri then local.conf Jul 06 01:45:11 mickeyl: Good morning. Jul 06 01:45:45 what the hell is dreambox ? Jul 06 01:45:58 mickeyl: I've seen your comments about w100 qte driver still not being suspend/resume safe. Jul 06 01:46:17 ade|desk: another distro which want to have branch of OE Jul 06 01:46:53 mickeyl: I have to say that I've not worked on that for some time. We need to define a way to make this. Jul 06 01:47:24 mickeyl: Technically, from the driver, there's no problem, I think. But we need to set the way to inform the driver about the suspend/resume events. Jul 06 01:47:29 03mickeyl * r272 10bitbake/lib/bb/__init__.py: remove last trace of make.py Jul 06 01:47:34 mickeyl: Perhaps using apm_proxy Jul 06 01:48:05 mickeyl: But at what level should this events enter, qte? qpe?, opie itself? Jul 06 01:48:08 Sirfred|work: i'd say lets start with 20W100Suspend Jul 06 01:48:12 and 20W100Resume Jul 06 01:48:27 into /etc/apm.d/suspend respectively /etc/apm.d/resume Jul 06 01:48:45 would that work to begin with? Jul 06 01:48:50 mickeyl: And what will make these scripts? Jul 06 01:48:52 mickeyl: Mmm Jul 06 01:49:08 mickeyl: Send a qcop event , perhaps? Jul 06 01:49:15 mickeyl: it seems like bitbake bbimage still uses make.py, at least we are seeing errors: Jul 06 01:49:16 Sirfred|work: these scripts will do whatever necessary Jul 06 01:49:28 mickeyl: That's the problem. I'm not sure of the best way to implement it. Jul 06 01:49:45 jbowler-away: see my last bitbake commit Jul 06 01:49:54 mickeyl: Whatever necessary is 'all the qte process should be informed about the change' Jul 06 01:51:05 mickeyl: All the proccesses using the qte w100 driver must reattatch, and the one being the qws server has to reinit the card. Jul 06 01:51:16 ~spell reattatch Jul 06 01:51:17 possible spellings for reattatch: reattach reteach reattached reattaches attach restitch rematch retouch reattain attache retch reattaching Jul 06 01:51:20 Sirfred|work: ok, that sounds like we want to do the following: Jul 06 01:51:31 a) two scripts into apm which send qcop signals Jul 06 01:51:43 b) patch launcher to listen for returnFromSuspend Jul 06 01:53:15 mickeyl: Is that all? Jul 06 01:53:29 i think so Jul 06 01:53:39 mickeyl: How are all the qte clients informed that way? Jul 06 01:53:39 but actually i have no idea what to do with the w100, so if there's something missing, tell me :) Jul 06 01:53:51 mickeyl: The problem is that all the clients need to be informed. Jul 06 01:53:59 Sirfred|work: why and how Jul 06 01:54:22 mickeyl: Well, to be honest, I'm not sure at all if the clients need to reattach, but I think so. Jul 06 01:54:42 i'd surprised if they would need to do that Jul 06 01:54:44 mickeyl: The problem is that the w100 state is stored by the AtiCore driver in a shared memory segment. Jul 06 01:55:24 mickeyl: So, all the processes using the qte driver are "attatched", meaning they are sharing a shared memory segment with the process that inited the AtiCore driver. Jul 06 01:55:42 mickeyl: The first process attatching is the one that inits that shmem segment. Jul 06 01:55:58 mickeyl: As far as the qte process acting as server reinits the w100, the shmem will change. Jul 06 01:56:10 mickeyl: And the other procesess shared memory segment is no longer valid. Jul 06 01:56:27 ~spell processes Jul 06 01:56:28 'processes' may be spelled correctly Jul 06 01:56:36 Good to know Jul 06 01:56:41 hmm ok, that's unfortunate but doesn't sound like a problem. for sure the qws process has a list of attached clients right? Jul 06 01:57:05 mickeyl: Not sure. Jul 06 01:57:18 mickeyl: But I won't bet anything on that Jul 06 01:58:16 mickeyl: You said we had to patch launcher to get that returnFromSuspend qcop message. Jul 06 01:58:40 mickeyl: So, if no launcher is running (for whatever reason) ... Jul 06 01:58:54 mickeyl: Isn't that scheme too tied to the way opie works today? Jul 06 02:00:01 mickeyl: I mean that perhaps it would be better just to pass that signals to the underlying qte level, simplifying, we only need the qws server to make one thing and the non qws server qteapps to make another. Jul 06 02:00:26 mickeyl: I don't see the reason to involve the launcher into this. Jul 06 02:00:49 for (ClientIterator it = client.begin(); it != client.end(); ++it ) Jul 06 02:00:49 delete *it; Jul 06 02:01:02 mickeyl: Where's that code located? Jul 06 02:01:02 s/delete *it/notifyReattach Jul 06 02:01:17 qwindowsystem_qws.cpp Jul 06 02:01:27 mickeyl: Great. That will be useful to our quest. Jul 06 02:02:22 mickeyl: I see it, on the destructor. Jul 06 02:02:22 if you can do it on qws level, it'd be even better Jul 06 02:02:36 mickeyl: Well, I'm not sure if all the qcop messages reach this level. Jul 06 02:02:38 mickeyl: Do you know? Jul 06 02:03:15 not offhand. they have to pass it of course, because the qcopenvelope unix socket is implemented in qte Jul 06 02:04:09 mickeyl: It seems that in qapplication_qws.cpp is something like a queue and a process method. Jul 06 02:04:40 void QWSDisplayData::fillQueue() Jul 06 02:04:46 mickeyl: But I'm not sure at all. Jul 06 02:05:33 mickeyl: What is supposed to be the incoming message, a QWSEvent::QCopMessage ? Jul 06 02:05:47 i have no idea as well Jul 06 02:05:51 i never had to poke on that level Jul 06 02:06:22 mickeyl: Well, if the messages are getting this level, I think it could be easy. Jul 06 02:06:27 s/getting/reaching Jul 06 02:06:29 within the command process, it looks like you can intercept it easily Jul 06 02:06:32 QWSCommand::QCopSend Jul 06 02:06:43 mickeyl: Where's that? Jul 06 02:07:00 1412 Jul 06 02:07:10 right in the command dispatcher Jul 06 02:07:51 mickeyl: Hmm, isn't this for sending out commands? Jul 06 02:08:22 *shrug* would need to add some debug out Jul 06 02:08:37 mickeyl: Sorry, but I don't clearly understand how this mess of QWS channels and commands and responses works. Jul 06 02:08:57 mickeyl: Yes, I will make that. Just add some debug and see where are my messages being received. Jul 06 02:09:05 pcmciautils 005 are available - will add it later Jul 06 02:09:28 mickeyl: Another BC break will be needed, the QWSDisplay should provide methods to resume/suspend. Jul 06 02:09:32 Sirfred|work: heh no problem. there are problably just two or three people in the world who ever had to look at that level Jul 06 02:09:49 Sirfred|work: yeah, I agree. Jul 06 02:09:53 hrw|work: cool Jul 06 02:10:20 mickeyl: I suppose they are locked up in some lunatic asylum. Jul 06 02:10:29 Sirfred|work: hehe, definitly Jul 06 02:10:58 then again, i'm not sure if the X server is any better on that level Jul 06 02:11:00 mickeyl: I'll make a reservation. Jul 06 02:11:03 :)) Jul 06 02:11:28 mickeyl: Well, I'm thinking lately that perhaps kdrive is the way to go. Jul 06 02:11:57 mickeyl: From my point of view, I got involved into this because a SDL game refused to run at a decent speed. Jul 06 02:12:10 Sirfred|work: it _is_ the way to go, however Opie 1.2.x / QtE will stay around for quite a while, so we really should get it done :) Jul 06 02:12:12 mickeyl: After fixing this, SDL-qte driver should need also to be fixed. Jul 06 02:12:21 dtl1_cs patch sent to author Jul 06 02:12:58 mickeyl: But with a decent accelerated kdrive, I'm sure the SDL x driver is better at using accelerated features from the underlying level that SDL qte one. Jul 06 02:13:28 mickeyl: Because SDL qte driver uses intensively QDirectPainter, so... Jul 06 02:14:35 mickeyl: Well, I looked at it in my dark SHARP days, perhaps it changed. Jul 06 02:15:04 mickeyl: When is the new oz release scheduled? Jul 06 02:16:45 hmm I got 4x NOTE: Not creating empty archive for udev-utils-005-r0 Jul 06 02:16:47 Sirfred|work: I'm targetting Mid August Jul 06 02:16:57 NOTE: package pcmciautils-005-r0: task do_build: completed Jul 06 02:17:13 mickeyl: I'm going on holidays the next week. Jul 06 02:17:39 mickeyl: Do you think that other than the suspend/resume issue, the driver is working fine? Have you tested it? Jul 06 02:18:25 Sirfred|work: no, i didn't have time to test the latest incarntion. Jul 06 02:18:31 incarnition, even Jul 06 02:18:45 i think there's still the bug where small pixmaps are swallowed Jul 06 02:19:00 hmm.. I will drop usage of bitbake interactive Jul 06 02:19:01 i'll get back to you after having tested the latest version Jul 06 02:19:04 hrw|work: nooo Jul 06 02:19:43 mickeyl: I didn't touch anything about that, I didn't noticed it in my tests. Jul 06 02:20:17 Sirfred|work: try setting Windows style and then open light-n-power. you see the arrows in the spinboxes are missing Jul 06 02:20:30 does touching my machine conf file do a full build ? Jul 06 02:20:43 mickeyl: Hmm, are the pixmaps very little? Jul 06 02:20:55 Sirfred|work: yep Jul 06 02:21:06 mickeyl: http://pastebin.ca/17012 contra http://pastebin.ca/17013 Jul 06 02:21:12 mickeyl: perhaps some "clever" alignment algorithm of my invention is the guilty. Jul 06 02:21:27 mickeyl: I'll take a look at it, this evening I expect. Jul 06 02:22:14 hrw|work: ya, i see, something in file*** seems to be broken. I'll look into that asap Jul 06 02:22:25 ok. sooner or later my dtl1_cs patch will be added into mainline Jul 06 02:23:07 excellent Jul 06 02:23:11 we need to send more things upstream Jul 06 02:23:25 RP: I will add that into 2.6.12-mm1.bb Jul 06 02:26:01 if I want to commit one file (from few changed) should I use "monotone commit file1 --message ''"? Jul 06 02:26:10 or there is "monotone ci"? Jul 06 02:26:28 there is ci Jul 06 02:26:43 alias for commit ;) Jul 06 02:33:25 03hrw 07org.openembedded.dev * r1bd3062a... 10/packages/linux/linux-openzaurus_2.6.12-mm1.bb: added dtl1_cs patch to get Socket CF+ Rev.E autoloaded with pcmciautils (patch sent upstream) Jul 06 02:33:26 03hrw 07org.openembedded.dev * r6ce955f2... 10/packages/ (2 files in 2 dirs): added pcmciautils 005 Jul 06 02:33:37 hrw: thanks :) Jul 06 02:35:43 RP: no Jul 06 02:35:46 problemo Jul 06 02:36:05 RP: thats my card so my business tohave it working Jul 06 02:36:56 hrw|work: Its often a driving factor :) Jul 06 02:37:04 now sysfsutils 1.3.0 Jul 06 02:38:15 NOTE: package sysfsutils-1.3.0-r0: task do_build: completed Jul 06 02:39:19 monotone: note: this revision creates divergence Jul 06 02:39:19 monotone: note: you may (or may not) wish to run 'monotone merge' Jul 06 02:39:22 heh.. Jul 06 02:39:57 s/or may not// Jul 06 02:39:58 :) Jul 06 02:39:58 merged Jul 06 02:40:10 mickeyl: you forgot about () :) Jul 06 02:40:33 heh Jul 06 02:40:37 i always do that Jul 06 02:40:43 who needs brackets... Jul 06 02:41:05 "monotone: note: you may () wish to run 'monotone merge'" looks strange then Jul 06 02:41:24 in two minutes CIA-4 will say something Jul 06 02:41:43 oe-commits@handhelds.org now online Jul 06 02:41:55 ML? Jul 06 02:42:01 yep Jul 06 02:42:09 some people requested that Jul 06 02:42:20 guys; my oe was working fine. built gpe, bootstrap-image it worked. i went to openembedded/conf/machine/omap5912osk.conf and added a new field IMAGE_FSTYPE="jffs2 tar" and did a bitbake. now i am getting a compilation error: please see http://pastebin.ca/17017 does changing a field in that file cause this ? Jul 06 02:42:23 good idea it is Jul 06 02:42:43 mickeyl: http://www.kernel.org/pub/linux/utils/kernel/pcmcia/howto.html Jul 06 02:43:11 eJumbo: wipe tmpdir and retry? Jul 06 02:43:56 mickeyl, Sirfred|work: On the w100 driver issue, if work goes the way I'd like it to, perhaps we can add suspend/resume hooks which preserve the shared memory data? It should be technically possible... Jul 06 02:44:02 its going to take ages to get it built ? Jul 06 02:44:18 what's the problem i dont get it ? Jul 06 02:44:20 hrw|work: ah, that's handy. /me prints out Jul 06 02:44:59 RP: Anyway, the shared data information would be outdated. Jul 06 02:45:09 RP: As long as the w100 losts its state on suspend. Jul 06 02:45:20 RP: I'd love to see that happen rather than all the fiddlings on three uncoupled software layers Jul 06 02:45:24 hrw|work : is there any solution ? Jul 06 02:45:43 Sirfred|work: I'm thinking these functions we'd add would save the needed w100 state Jul 06 02:45:44 03hrw 07org.openembedded.dev * r837e5daa... 10/packages/sysfsutils/sysfsutils_1.3.0.bb: added sysfsutils 1.3.0 Jul 06 02:45:54 eJumbo: what package gave that error? Jul 06 02:46:10 eJumbo: always try to put whole output into pastebin Jul 06 02:47:14 RP: You mean to do that on kernel side? Jul 06 02:47:49 Sirfred|work: No, I mean we could add a couple of functions to atilib Jul 06 02:48:25 I know which registers the kernel restores. We can restore the rest in userspace Jul 06 02:48:37 mickeyl: does oe-commit is registered on gmane? Jul 06 02:48:56 RP: Well, we only need that way to go into the qte server on suspend/restore. The client process shouldn't need to reattach. Jul 06 02:48:58 please see for the error: http://pastebin.ca/17018 Jul 06 02:49:36 RP: The approximation is similar from the qte point of view, so going from the first proposal to this one would be easy. Jul 06 02:49:37 eJumbo: that glibc is known to compile for arm Jul 06 02:50:08 hrw|work: is he talking 2.3.5+cvsXXXXXX Jul 06 02:50:23 hrw|work: not yet. someone should do that Jul 06 02:50:28 RP: Even, with the first proposal we only need to perform some actions on resume, not on suspend, if I'm not wrong. Jul 06 02:50:32 XorA: no - 2.3.2+cvs20040726 Jul 06 02:50:47 NOTE: package glibc-2.3.2+cvs20040726: failed Jul 06 02:50:58 hrw|work: ah ok, 2.3.5-XXXX compiles on one machine of mine and not other, must be reliant on something host side Jul 06 02:51:04 but it was working earlier ? Jul 06 02:51:21 good morning pb_ Jul 06 02:54:33 my setup was ok. working fine. i built both gpe-image and bootstrap image and worked fine. no issues. i changed IMAGE_FSTYPE in my machine.conf file and then gave a bitbake and why does it cause the error now ? Jul 06 02:55:57 ~lart interactive bitbake once more Jul 06 02:55:58 * ibot keeps mailing interactive bitbake once more free America Online CDs until he drowns Jul 06 02:57:02 mmh Jul 06 02:57:10 * mickeyl starts a short bbshell hacking session Jul 06 02:57:30 filerebuild generate broken packages Jul 06 02:57:39 udev without /etc/ for example Jul 06 02:58:26 there's just something wrong with the per package metadata handling which is responsible for all problems we have with file*** Jul 06 03:00:36 hrw|work: what do i do now ?. is there any way to resolve this error ? Jul 06 03:01:12 eJumbo: I would retry probably Jul 06 03:01:49 i did i get an error : http://pastebin.ca/17020 Jul 06 03:02:38 eJumbo: rebuild linux-libc-headers? Jul 06 03:04:45 shall i remove related dir from tmpdir/work ? Jul 06 03:07:10 eJumbo: bitbake -cclean linux-libc-headers will do it Jul 06 03:07:50 mickeyl: good morning Jul 06 03:09:35 ok. zaurus rebooting - will check udev 060, sysfsutils 1.3.0, pcmciautils 005 on it Jul 06 03:11:25 bleeding edge Jul 06 03:11:33 jffs2.fsck has problems during each reboot.. even after "reboot" from cmdline ;( Jul 06 03:12:21 booted without problems Jul 06 03:12:46 and without udev Jul 06 03:17:12 crumbs, where did you get fsck for jffs2 from? I didn't realise there even was such a thing. Jul 06 03:17:26 it certainly shouldn't be necessary to fsck a jffs2 partition at bootup. Jul 06 03:17:56 pb_: by jffs2.fsck I meant those messages before init started Jul 06 03:18:29 http://pastebin.ca/17022 Jul 06 03:19:55 hrw|work: get a new error this time : http://pastebin.ca/17023 Jul 06 03:20:14 hrw|work: You get this if the write buffer isn't synced and you reboot Jul 06 03:20:30 I suspect the sync command might be broken again as I've been seeing a lot of these errors as well Jul 06 03:20:56 RP: ok Jul 06 03:21:39 eJumbo: I'm not glibc expert.. this version builds for me Jul 06 03:40:59 03florian 07org.openembedded.dev * r43b1e944... 10/packages/maemo/nokia770-init_1.0.bb: Fix firmware links. Jul 06 03:48:24 morning Jul 06 03:48:45 hi reenoo Jul 06 03:48:55 hey hrw|work Jul 06 04:17:53 mickey|lunch: Do you think this syntax is correct: qcop QPE/System 'hideInputMethod()' Jul 06 04:18:12 mickey|lunch: I'm not getting the expected result, is there any qcop script in the system known to work? Jul 06 04:18:55 mickey|lunch: That last change to bitbake seems to have broken it :-/ Jul 06 04:20:38 mickey|lunch: http://pastebin.ca/17029 Jul 06 04:21:10 The bitburn revision Jul 06 04:22:59 mickey|lunch: I was able to debug the messages reaching the QWSServer. I'm seeing the QCopMessages on a rotation, for example, but when I try with the qcop client I only get a Identify event and nothing more. Jul 06 04:25:19 RP: could you enable INPUT_UINPUT in 2.6/c7x0? it can be used with kbdd to use external keyboards Jul 06 04:25:47 hrw|work: Isn't it already a module? Jul 06 04:25:57 If not, yes, it should be :) Jul 06 04:26:20 RP: keybdev is also lacking but I didnt found it yet Jul 06 04:26:27 hrw|work: What kind of external keyboards can be used with the c7x0 ? Jul 06 04:27:26 Sirfred|work: currently dont know as kbdd is rather ipaq oriented - but should allow to use some serial or irda ones after tweaking configs/code Jul 06 04:27:37 hrw|work: ok Jul 06 04:28:35 OT: Has anybody tested one of those "light keyboards". Ones where the keyboard is projected using light on a surface. Jul 06 04:28:48 CONFIG_INPUT_KEYBDEV looks like 2.4 only anyway Jul 06 04:28:49 I wonder how good they work. Jul 06 04:29:00 Sirfred|work: friend told me that it was too slow Jul 06 04:30:00 hrw|work: A pitty Jul 06 04:31:29 I'm downgrading udev to 058 Jul 06 04:35:26 hrw|work: What's wrong with 060? Jul 06 04:36:21 RP: does not start on my husky Jul 06 04:36:40 hrw|work: Ah :-/ Jul 06 04:36:52 hmm.. 058 also weird Jul 06 04:36:59 wtf... Jul 06 04:38:02 again etc/init.d/devices;( Jul 06 04:41:33 mickey|lunch: I've fixed it after straceing qcop. My QTDIR was not pointing to the right location, but no message was shown because I think qcop installs a message handler that disables all tracing. Jul 06 04:52:36 if what files i must modify if i want an jffs2 image. my local.conf file has that but, i always get an ext2 image. my machine .conf and distro .conf dont have IMAGE_FSTYPE variable at all ? Jul 06 04:54:42 eJumbo: IMAGE_FSTYPE(S)="jffs2" Jul 06 04:55:54 hi BigAl Jul 06 04:55:56 my local.conf has it. but always i get an .ext2.gz image Jul 06 04:56:07 eJumbo: what machine/distro? Jul 06 04:56:13 omap5912 Jul 06 04:56:28 generic distro ? Jul 06 04:57:01 generic distro has IMAGE_FSTYPES = "ext2.gz" Jul 06 04:57:09 thats why you get ext2.gz only Jul 06 04:57:29 I told you that distro and machine conf has higher pri then local.conf Jul 06 04:58:03 comment IMAGE_FSTYPES in openembedded/conf/distro/generic.conf Jul 06 04:58:42 done that. Jul 06 05:00:02 i have given a bitbake now. and it is starting all over again. i have also included an IMAGE_FSTYPE in machine .conf file. Jul 06 05:00:19 NO Jul 06 05:00:21 i dont know why it is building tool chain all over again ?. Jul 06 05:00:29 add image_fstype only in local.conf Jul 06 05:00:44 thats local/distro setting NOT machine related Jul 06 05:01:16 modifying (or touching) machine .conf does it make bitbake to build the tool chain ? Jul 06 05:01:24 all over again ?. Jul 06 05:01:41 03mickeyl * r273 10bitbake/bin/bitbake: add missing self to find_bbfiles() and get_bbfile() Jul 06 05:01:59 RP: that should fix it Jul 06 05:04:08 whats TARGET_FPU="Soft" ; does it build libsoftfloat ?. Jul 06 05:05:21 lunch time Jul 06 05:09:56 Crofton: why TARGET_FPU is NOT "Soft" in openomap distro ? Jul 06 05:12:59 <__law__> http://bugs.openembedded.org/show_bug.cgi?id=134 :-) Jul 06 05:14:13 is it just me or is org.openembedded.dev currently unmerged? Jul 06 05:14:21 and is there a way to merge without using emacs? ;) Jul 06 05:26:55 mickey|lecture: thanks Jul 06 05:30:18 tmbinc: install 'meld' Jul 06 05:30:28 getting some vague errors: please see http://pastebin.ca/17031 Jul 06 05:30:32 meld is a nice 3-way merge tool based on python-gnome Jul 06 05:30:49 ok i'll try, thanks Jul 06 05:30:49 i dont know what happening and why it is happening ? Jul 06 05:31:34 hrw|work, mickeyl: We have a problem with 2.6.12 - mtd corruption. The mtd people have confirmed that much - no idea what's wrong yet though Jul 06 05:32:56 RP: i also faced a jffs2 corruption problem. if i write any data or remove a file. after next reboot i get ino missing or CRC errors ?. Jul 06 05:33:33 eJumbo: If you don't sync, that's normal. If you do sync before rebooting, its a sign of the current problem Jul 06 05:34:28 i have a battery. and also i used to shutdown or reboot. so sync should happen right ? Jul 06 05:34:55 depends on your shutdown scripts ;-) Jul 06 05:35:15 using only provided by oe Jul 06 05:35:47 I'm not sure what oe actually does tbh. Most of the time I reboot by syncing and then rebooting using SysRq Jul 06 05:35:49 eJumbo: you will sometimes get CRC errors on bootup if the jffs2 write buffer was not fully flushed before rebooting (typically because it contained GC data). That is harmless. Jul 06 05:36:10 The blocks with the CRC errors will eventually be erased and reused, at which point the errors will go away. Jul 06 05:36:47 RP: ;( Jul 06 05:36:53 RP: Do you know if the problem still in 2.6.12.2? Jul 06 05:37:20 mickeyl: how to told monotone to use something other then meld for it? I dont want to install half of gnome libs just to get one tool running Jul 06 05:37:28 hrw|work: no idea, sorry. Jul 06 05:37:36 ok Jul 06 05:37:44 hrw|work: there's a hook somewhere. check in reference manual Jul 06 05:37:59 get_merge_tool or so Jul 06 05:38:07 RP: disabling i/o schedulers other then CFQ gives 100K free in kernel_image Jul 06 05:38:35 NAiL: The problem might not be in 2.6.12 - it may from from the -mm tree which has mtd cvs Jul 06 05:38:42 it may come from Jul 06 05:38:49 aha Jul 06 05:39:44 I meant the Zaurus 2.6.12 tree which includes -mm in the comment above. Sorry for the confusion :) Jul 06 05:40:28 getting an error while building : http://pastebin.ca/17031 Jul 06 05:41:15 <[g2]> RP is it the mtd layer or mtd-utils ? Jul 06 05:41:55 [g2]: Its in the kernel jffs2 or mtd code Jul 06 05:42:22 <[g2]> RP thx... that's was I was afraid of Jul 06 05:45:17 eJumbo: why are you trying to build gcc-snapshot? Jul 06 05:45:22 It sounds like that .bb file is out of date. Jul 06 05:45:38 dont know it downloaded by itself and doing it ?. Jul 06 05:47:26 03tmbinc 07org.openembedded.dreambox * r7005f81e... 10/packages/tuxbox/ (15 files in 3 dirs): adding tuxbox (dvb) libraries, tools Jul 06 05:47:36 History: my system was working fine. built an gpe-image and worked fine. since it was giving me a .ext2 filesystem. i changed FS_IMAGETYPE to "jffs2" in machine .conf file (which i have remove now) and gave a bitbake and then i am getting these errors Jul 06 05:48:18 i dont know why one change to machine .conf file has caused my oe setup to corrupt. Jul 06 05:49:02 i am desperately waiting for some suggestions and advices ?. i dont want to built it all over again and have taken a backup becuase of the size involved. Jul 06 05:49:08 mickeyl: why is viewmtn constantly complaining "'module' object has no attribute 'monotone'"? is it you changing something or some other problem? Jul 06 05:50:03 try reloading it Jul 06 05:50:10 mod_python sometimes acts odd Jul 06 05:50:15 force reload with your browser Jul 06 05:50:28 ok Jul 06 05:52:55 03tmbinc 07org.openembedded.dreambox * rbcc127d3... 10/ (42 files in 23 dirs): Jul 06 05:52:55 propagate from branch 'org.openembedded.dev' (head d770ca43ebb6406692cd960c33f11791c1a25c95) Jul 06 05:52:55 to branch 'org.openembedded.dreambox' (head 7005f81e78151e6b8f2506ad8f2febf5667e01de) Jul 06 05:52:55 pb_ : snapshots .bb files are not out of date. do u know what should i do to resolve my problem. Jul 06 05:53:53 hmm bummer, now I'm getting that server problem again Jul 06 05:53:59 ~lart mod_python and viewmtn Jul 06 05:54:00 * ibot DoSes mod_python and viewmtn Jul 06 05:56:47 ~lart c7x0 battery Jul 06 05:56:47 * ibot gets a hotmal account and SPAMs c7x0 battery Jul 06 05:58:17 now I have discharged husky Jul 06 06:06:27 eJumbo: what do you mean by "not out of date"? Jul 06 06:06:35 if it is trying to use f77, it is out of date by definition. Jul 06 06:12:08 weird logic by kdepimpi authors: Jul 06 06:12:12 When saving data KA/Pi did consume a lot of memory for the data parsing during the save process. Jul 06 06:12:16 This is fixed. Jul 06 06:12:18 Example: Jul 06 06:12:21 Before saving a 600k file KA/Pi did consume 21.7 Meg of Ram. Jul 06 06:12:24 When saving KA/Pi did consume 28.6 Meg of Ram. That causes a crash on the Zaurus because there was no memeory left in the system. Jul 06 06:12:26 Now KA/Pi is consuming on saving the same data 22.0 Meg of Ram during the save process. Jul 06 06:12:30 22M to save 600K file?? Jul 06 06:12:50 kdepimpi.inc doesn't seem to be correct Jul 06 06:12:58 see comment to #133 Jul 06 06:13:50 ok Jul 06 06:15:20 2.1.13 released so its good time to fix it for me Jul 06 06:15:37 *nod* Jul 06 06:15:44 mickeyl: but why it works not from interactive? Jul 06 06:16:05 here it doesn't work at all Jul 06 06:16:22 which is the behaviour i would expect Jul 06 06:16:28 ok Jul 06 06:16:29 could it be that zautrix changed source after release ? Jul 06 06:18:03 hmm wait Jul 06 06:18:20 no i see the file Jul 06 06:18:39 *sigh* a lot of strange this happening here lately Jul 06 06:18:43 things, even Jul 06 06:20:42 * mickeyl redownloads kdepimpi source Jul 06 06:22:18 hmm.. 'mt rename' does not rename without commit? Jul 06 06:22:32 yes Jul 06 06:22:45 weird Jul 06 06:22:51 see manual Jul 06 06:23:00 mt rename Jul 06 06:23:00 pb_: Its date (24th June) : Date i built OE Successfully. My CVSDATE is CVSDATE=20050619 I have set it there because i dont want oe to download everytime ? Jul 06 06:23:02 then move by hand Jul 06 06:23:04 then commit Jul 06 06:23:09 ah.. Jul 06 06:23:30 weird a bit Jul 06 06:25:22 'lo Jul 06 06:26:02 pb_: waiting for ur response Jul 06 06:27:38 hi marcan Jul 06 06:27:44 hi mickeyl Jul 06 06:34:23 hello marcan Jul 06 06:35:02 hi Jul 06 06:36:09 is this an CVSDATE issue ?. oe is trying to build gcc-snapshot-cross-20050619: i dont know why ?. Jul 06 06:37:20 can anyone tell me that ?. i built it 2 weeks back and changed CVSDATE to an old one when i got an error; so the build was successful. now with the same cvsdate; the build is failing Jul 06 06:39:12 eJumbo: you don't want gcc-snapshot, stick with a known-good version. specify a "PREFERRED_VERSION_gcc-cross = "3.4.4"" somewhere (machine config makes sense, for example) Jul 06 06:39:38 03tmbinc 07org.openembedded.dreambox * rd471b807... 10/packages/busybox/ (busybox-1.00/nptl_task.patch busybox_1.00.bb): add nptl support to busybox Jul 06 06:39:38 03tmbinc 07org.openembedded.dreambox * r861b4547... 10/packages/freetype/ (freetype-2.0.9/install.mk.patch freetype_2.0.9.bb): add freetype 2.0.9 Jul 06 06:39:39 03tmbinc 07org.openembedded.dreambox * r9696fb93... 10/packages/mrouted/ (mrouted-3.9.diff mrouted.bb): add mrouted Jul 06 06:39:40 (or whatever version of gcc you want to use :) Jul 06 06:41:10 were there any recent patch changes or updates in the repo? if so then any cvs date you choose doesnt matter unless you choose one that works by shear luck Jul 06 06:43:11 emte: its like this: i was building oe 2 weeks back and when i got into a build error: someone in this forum suggested please change the CVSDATE to ... i did that change and it worked. now i am using the same cvs date and i dont know why its not working ? Jul 06 06:43:46 tmbinc: local conf or distro conf are better place Jul 06 06:44:22 hrw|work: well, i have a distribution running on both mips and ppc, and some toolchain combination work fine for ppc, but not for mips (and vice-versa) Jul 06 06:44:22 freetype 2.0.9? Jul 06 06:44:30 tmbinc: ah.. Jul 06 06:44:40 thus distri config isn't good, at least for me Jul 06 06:44:49 eJumbo: the fact that it is dated June 24 doesn't indicate that its contents are up to date. Jul 06 06:44:56 03tmbinc 07org.openembedded.dreambox * rbe305d33... 10/packages/timezones/timezones-alternative.bb: add timezones-alternative, a different version of timezone data, more suitable for some applications Jul 06 06:45:01 03tmbinc 07org.openembedded.dreambox * r0856b0f1... 10/packages/swig/ (swig-native_cvs.bb swig_cvs.bb): add swig, swig-native Jul 06 06:45:01 and local.conf is problematic as users should not have to edit their local(!) settings to make the stuff compiling Jul 06 06:45:13 but, irrespective of that, it shouldn't be using gcc-snapshot anyway. YOu'll need to establish why that is happening. Jul 06 06:45:38 nokia770 changeset is d770.... ;) Jul 06 06:46:04 pb_: i really dont know how to resolve this problem and need ur advice Jul 06 06:46:15 hehe Jul 06 06:47:09 i dont know what make oe to get that gcc-snapshot ? Jul 06 06:47:45 hrw|work: yes, we're using 2.0.9 as a.) it still using the old api, and b.) the rendering looks different, and i was not able to reconfigure the newer versions it to look like 2.0.9 (yes, i know about the hinting issues, i tried both the patented parser and the integrated re-hinter. i still have some screenshots somewhere, in case you dont believe ;) Jul 06 06:48:50 tmbinc: ok - you wanted better version, you added it and we will get nice update Jul 06 06:49:54 hrw|work: well, i'm not going to propagate it to .dev, unless somebody else needs it :) i agree that at the least the upgraded api should be fixed in our application, but that's really not our priority right now. Jul 06 06:51:50 sure Jul 06 06:59:33 eJumbo: my point is that you almost certainly don't _want_ gcc-snapshot. You need to establish why it is not using a released gcc appropriate to your platform. Jul 06 06:59:49 if you are on x86, that'd be gcc-4.0.0; if you are on ARM, that would be gcc-3.4.4+csl. Jul 06 07:00:31 pb_: currently no news about EABI/arm? Jul 06 07:06:09 mickeyl: fileunpack would be great Jul 06 07:06:49 hrw|work: *nod*. i'll add fileunpack, filefetch, filepatch just for the sake of completeness Jul 06 07:07:20 #133 is valid, i'm currently looking into it Jul 06 07:07:37 ok Jul 06 07:07:38 hrw|work: no, sorry. I have been too busy to chase Dan for the bits we need. Jul 06 07:07:55 pb_: thx Jul 06 07:08:07 * mickeyl headache Jul 06 07:08:11 too much bb lowlevel code Jul 06 07:09:08 heh Jul 06 07:11:37 heh.. now even filerebuild kdepimpi_2.1.13.bb fails Jul 06 07:33:21 * CosmicPenguin taps his foot waiting for IT to open the monotone port Jul 06 07:34:18 RP: http://pastebin.ca/17038 Jul 06 07:35:13 hrw|work: Did I not check that in? :-/ Jul 06 07:35:21 03hrw 07org.openembedded.dev * r7d47cbc2... 10/packages/kdepimpi/ (6 files in 2 dirs): updated kdepimpi to 2.1.13 Jul 06 07:35:30 I've just cloned again btw, and it's not there Jul 06 07:35:47 RP: it looks like Jul 06 07:36:17 It'll have forgotten to add it... Jul 06 07:38:10 This is going to involve a pull so it's going to be a while... Jul 06 07:48:01 RP: have you got an URL for the patch? - if so I'll grab it manually and continue my build Jul 06 07:48:24 Its pushed now Jul 06 07:48:33 cool, thanks Jul 06 07:48:54 http://www.rpsys.net/openzaurus/temp/fixstretchblit.patch Jul 06 07:50:37 03rpurdie 07org.openembedded.dev * rf790dcaf... 10/packages/sharp-binary-only/sharp-aticore-oss-1.0.1/fixstretchblit.patch: Update atilib to avoid a segfault Jul 06 07:53:00 proti: ping Jul 06 07:53:28 proti: before filing a bug report to a concrete file look at the history of the file!!! Jul 06 07:53:57 proti: ask yourself when question (this applies to your original patch as well) Jul 06 07:53:59 RP: Sorry, I commented to you that fixstretchblit.patch was missing, but probably you didn't see my message and then, I used the patch you sent me and forgot the thing. Jul 06 07:54:15 proti: what happens if you write a shared dictionary to disk Jul 06 07:54:36 proti: and is it still shared when you unpickle the data? Jul 06 07:54:54 Sirfred: I'd just forgotten to monotone add it. Too busy worrying about creating accidental branches etc :) Jul 06 07:55:03 proti: in the case of unpickling you've two dict instances which obviously wastes memory Jul 06 07:55:29  Jul 06 07:56:46 proti: so you might save time and memory when initially parsing Jul 06 07:56:52 zecke: shared dict is not written on disk. Jul 06 07:57:03 proti: but you waste memory and time when reading from disk... Jul 06 07:57:31 proti: what shared dict? Jul 06 07:59:53 hi zecke Jul 06 08:01:00 zecke: this shared. -> What happens if you write a shared dictionary to disk Jul 06 08:01:28 The only shared dict was the make.cfg dict. Jul 06 08:03:10 zecke: What I am wasting ? Can you give me an example please. Jul 06 08:06:06 proti: you parse make.cfg Jul 06 08:06:22 proti: then you want to parse a package description and give make.cfg as the base Jul 06 08:06:33 proti: you do not want to deepcopy it but link it Jul 06 08:06:41 proti: the file is going to be pickled Jul 06 08:06:53 proti: so you will write two dicts (dict in dict) to disk Jul 06 08:07:37 zecke: No. See pickle_prep. Jul 06 08:08:05 I delink it and store in _data an explicit name 'cfg'. Jul 06 08:08:49 One dict written. And a reference to the dataSet inside. Jul 06 08:09:10 * mickeyl dances a jig Jul 06 08:09:32 hrw|work: thanks a lot! your bug report helped me to find a logic error hidden deep inside the shell Jul 06 08:09:47 mickeyl: your welcome Jul 06 08:11:42 zecke: When unpickle, I look at the _data attribute and if it exists, I relink the dataSet to the correct parent in unpickle_prep. Jul 06 08:14:34 Only 1 case here the "cfg" dataSet. I did another implementation where every .bb bbclass and include file were a dataSet and you could have several level of links. In this case, I used the "f" from pkgdata to keep the link with the original file. But I had too much side effects everywhere due to bb files specification. Jul 06 08:15:41 What you do in a bb file can have big impact on the include files. Jul 06 08:25:10 bluez-lib-2.16.bb does not create an ipkg - anyone know why? Jul 06 08:28:01 cu all Jul 06 08:35:59 seems bluez-lib does not populate the image directory - shouldn't this be performed by the pkgconfig inheritance? Jul 06 08:39:11 no, pkgconfig doesn't have anything to do with imaging. Jul 06 08:39:20 what exactly is not happening for you? Jul 06 08:40:28 the ipkg is not being built Jul 06 08:40:43 thus bluez-utils cannot be included in my image Jul 06 08:41:05 what does the bitbake output look like? Jul 06 08:41:06 bluez-lib installs in the staging dirs fine, though Jul 06 08:41:29 just recompiled, it says ipkg refuses to build an empty pkg Jul 06 08:41:49 are those the exact words? Jul 06 08:42:12 03mickeyl * r274 10bitbake/lib/bb/shell.py: Jul 06 08:42:12 Shell: grab a deepcopy from the initial cooker data to reuse Jul 06 08:42:12 it in file**** commands. Otherwise we would pollute Jul 06 08:42:12 cooker.configuration.data (i.e. do_configure_append() appending Jul 06 08:42:12 multiple times). This fixes BitBake bug #133 Jul 06 08:42:27 right. Jul 06 08:42:44 and i checked back - the image/ subdir contains only pkgconfig data, no libs Jul 06 08:45:52 how odd Jul 06 08:45:59 let me see if I can check out an up-to-date tree to take a look Jul 06 08:47:00 ok, thanks Jul 06 08:47:57 interestingly, the lib HAS been installed into /bluezßlib-2.16/install/bluez-libs/usr/lib/ Jul 06 08:48:54 s/ß/-/ Jul 06 08:56:32 pb_, I puild for an XScale board - could this matter? Jul 06 09:06:47 proti: are you confident your impl looked like this? Jul 06 09:07:02 zecke: Like what ? Jul 06 09:07:16 pb_, think I found it: the package name is different! Jul 06 09:07:24 the cfg description ? Jul 06 09:07:56 Yes it always worked like this since I supported the cache files. Jul 06 09:08:36 proti: that wasn't in your cow patches right? Jul 06 09:08:58 zecke: Yes they were in the cow patches and bbcow too. Jul 06 09:09:20 proti: how did you find out you got pickled? Jul 06 09:10:06 pb_: libbluetooth1_2.16-r0_armv5te.ipk is being built... will change the dependency of bluez-utils and try again Jul 06 09:11:30 or can I define an alias? Jul 06 09:11:43 zecke: When pickle, I was calling the pickle_prep just before the dump and when unpickle, I did the reverse. I'm looking in my patches to check where the call are done. Jul 06 09:13:31 zecke: It is in pickle_oe and unpickle_oe. See http://www.frankengul.org/cow/cow8a.patch Jul 06 09:15:35 zecke: I agree that this was missing from bbcow patch. My mistake. Sorry. Jul 06 09:18:49 Ok the calls are missing from pickle_bb and unpickle_bb in my bbcow.patch. Jul 06 09:30:36 mickeyl: Bug #133, why don't you do a createCopy of the dataSet instead of the deepcopy ? Jul 06 09:39:08 ibot: help Jul 06 09:39:32 * koobla_home leaves Jul 06 09:39:50 pb_: must be leaving - bye! Jul 06 09:45:20 ibot: botmail for zecke: You were correct, calls were lost in the move from oe to bb. Sorry for the mistake. Jul 06 09:53:26 ibot: botmail for Luke-Jr: hi Jul 06 09:53:36 o.o Jul 06 10:09:09 proti: because i'm ignorant about dataSet. Sounds like a good idea though Jul 06 10:15:16 mickeyl: I didn't had a close look of the problem but it seems to be a task for a dataSet. Look in the base.bbclass:base_do_unpack() for an example how to use it. Jul 06 10:15:28 k Jul 06 10:15:36 FYI: monotone 0.20 is out Jul 06 10:15:49 uh oh Jul 06 10:15:51 don't upgrade all Jul 06 10:15:55 - 0.19 clients cannot talk to 0.20 servers, and vice-versa. Jul 06 10:15:59 mickeyl: Does it improves the speed ? Jul 06 10:16:07 no idea, i didn't try Jul 06 10:16:16 My pull takes hours (literally). Jul 06 10:16:17 vanille.de will have to stay a while on 0.19 Jul 06 10:16:28 because of my adjusted viewmtn and ciabot_monotone.py Jul 06 10:16:55 I long for a 0.19 with speed improvement. Jul 06 10:17:24 then try: Jul 06 10:17:30 checkout f56500ddd113aa716173f6d94db5d59c88bdc201 Jul 06 10:17:39 and apply all the patches from http://lists.gnu.org/archive/html/monotone-devel/2005-07/msg00015.html Jul 06 10:17:45 and apply all the patches from http://lists.gnu.org/archive/html/monotone-devel/2005-07/msg00014.html Jul 06 10:17:53 i'd be interested in a tarball if you get it to compile Jul 06 10:18:05 Ok I will try. Jul 06 10:18:18 excellent. note the application order as discussed in note the apply order Jul 06 10:18:27 s/note the apply order/http://lists.gnu.org/archive/html/monotone-devel/2005-07/msg00016.html/ Jul 06 10:18:59 One funny thing. To get the modified monotone with speed improvement, you have to pull the monotone .db. Jul 06 10:19:04 First Jul 06 10:19:19 It took me the night. Jul 06 10:19:44 heh Jul 06 10:19:47 want to grab it from me? Jul 06 10:20:13 vanille.de/temp/monotone.db Jul 06 10:20:17 grabbed two days ago Jul 06 10:20:21 said revision should be included Jul 06 10:20:37 I have it now. I will try on my amd64. it's faster. The venerable U60 I run is showing its age. Jul 06 10:21:14 Ok, will grab and try thanks for the info mickeyl. Jul 06 10:21:17 bbl Jul 06 10:22:31 mickeyl: I suppose than no kernel logs are stored on opie after a reboot, aren't they? Jul 06 10:23:22 right. syslog writes in a ring buffer Jul 06 10:23:28 in-memory Jul 06 10:23:42 Mm. Jul 06 10:23:52 mickeyl: My husky is suspending only at once. Jul 06 10:24:28 mickeyl: The next time I try to suspend it just gets freezed. The wifi card blinking, everything frozen, no way to know what's happening. Jul 06 10:24:44 sounds like you need a serial cable Jul 06 10:25:21 mickeyl: I supposed that only USB cables existed. Jul 06 10:25:34 mickeyl: So, there's a kernel console via serial? Jul 06 10:25:43 Sirfred: yes. Jul 06 10:26:04 a kernel console and even a TTY if you want to have that Jul 06 10:26:10 mickeyl: For my cute husky? Jul 06 10:26:16 for all Zaurus models Jul 06 10:26:20 even with the same cable Jul 06 10:26:26 (unbelievable, if you know Sharp) Jul 06 10:26:44 I never would suspect it. Jul 06 10:27:14 Hmm, the machine has come back to life Jul 06 10:28:25 mickeyl: Where could I find one of those cables? I assume that there's nothing to do with the USB one, right? Jul 06 10:29:20 the usb cable plugs in the same port, but has a different end (of course) Jul 06 10:29:30 several vendors sell those cable Jul 06 10:29:35 e.g. trisoft.de Jul 06 10:29:58 mickeyl: I will take a look, thanks. Jul 06 10:30:04 np Jul 06 10:30:15 <[g2]> is monotone in OE yet ? Jul 06 10:30:16 mickeyl: I wonder if I should test all this stuff using a bleeding edge opie image. Jul 06 10:31:04 mickeyl: I'm just changing only the minimal components on a 3.5.3 Jul 06 10:31:43 Sirfred: I think it'd be better to use a current one,. Jul 06 10:31:48 mickeyl: Well, more than changing, just copying them on an SD and playing with LD_LIBRARY_PATH to force loading my testing libs. Perhaps this is not the best way. Jul 06 10:32:06 [g2]: not yet Jul 06 10:32:33 <[g2]> mickeyl, it'd be great to have patches like you mentioned above avialable to all Jul 06 10:34:33 Now it's even not able to suspend, it only says: Jul 06 10:34:34 power.c: device-level power management is not supported yet Jul 06 10:34:35 power: requesting system suspend... Jul 06 10:34:38 And nothing more. Jul 06 10:35:31 03zecke123 * r275 10bitbake/ (MANIFEST setup.py): Jul 06 10:35:31 bitbake/ Jul 06 10:35:31 Update MANIFEST and setup.py to cope with the removal Jul 06 10:35:31 of make.py and bbread and add utils.py to the MANIFEST Jul 06 10:37:54 device-level power management? d'oh. never seen that one Jul 06 10:39:15 heh Jul 06 10:39:47 And: Jul 06 10:39:48 # apm --suspend Jul 06 10:39:48 apm: Device or resource busy Jul 06 10:40:00 looks like a kernel bug Jul 06 10:40:07 check dmesg for oops Jul 06 10:40:50 mickeyl: Nothing. Jul 06 10:41:24 mickeyl: After that strange message from power.c, the CF card disconnected and connected (it happens a lot, perhaps is my AP), and everything seems to work. Jul 06 10:42:11 mickeyl: But apm seems to be frozen. Jul 06 10:43:17 bummer. sounds like a reboot is necessary Jul 06 10:43:58 FYI (sharpzdc_cs.o): FYI: http://lists.gpl-violations.org/pipermail/legal/2005-July/000385.html Jul 06 10:44:24 sounds like someone finally takes an attempt to get sources Jul 06 10:48:19 mickeyl: This trisoft site is buggy. I cannot understand this english Jul 06 10:48:33 mickeyl: Is the Z-Thincable Stecker, what I'm looking for? Jul 06 10:48:55 48 euro Jul 06 10:49:13 Sure they made it of gold to improve connectivity Jul 06 10:50:55 heh Jul 06 10:51:14 mickeyl: honestly, that "any #include will make the stuff derived work" won't force any companies to give out sources, but instead use windows ce for the next time they build a PDA. but that's probably only my own opinion, partly influenced by being employed by a company which builds an open source system around a (relatively) small binary-only driver (of course not *containing* any GPL'ed work, but surely using #includes) Jul 06 10:51:37 Sirfred: http://www.serialio.com/products/adaptors/ZThinCable.htm manufacture it Jul 06 10:52:13 tmbinc: in principle i agree. in this case it's absolutely nuts. it's a minimal driver for a lousy camera and there's really no reason to close source that Jul 06 10:52:46 yes sure Jul 06 10:52:47 $34.95 here, sensible cheaper. Jul 06 11:21:56 proti: sorry I was forced to leave the lab... Jul 06 11:22:10 actually it burned down and I decided to leave... (just kidding) Jul 06 11:23:04 proti: but I still think putting a different make.cfg under an cached bbfile is dangerous Jul 06 11:23:09 kidding? Jul 06 11:23:16 it burned down and you decided not to leave? Jul 06 11:24:19 03mickeyl * r276 10bitbake/ (ChangeLog lib/bb/shell.py): Jul 06 11:24:20 Shell: Jul 06 11:24:20 - use shlex to parse command lines as a special service to hrw: Now you can say 'setvar FOO "this is a test"' :) Jul 06 11:24:20 - use a command queue in the main loop to unify offline (from startup file) and online processing Jul 06 11:24:20 - add some changes for 1.3.2. Could anyone fill in changes for 1.3.1 ? Jul 06 11:25:04 mickeyl: ping Jul 06 11:25:54 mickeyl: 131 or 132 Jul 06 11:26:05 mickeyl: I would think 132 is more natural? Jul 06 11:26:13 mickeyl: but if I do bitbake foo -cfetch Jul 06 11:26:20 mickeyl: I want it to fetch all source files Jul 06 11:30:21 zecke: yep. i think we should rather leave it like that and fix 131 Jul 06 11:30:35 zecke: he who is using -c should know what he is doing Jul 06 11:35:08 mickeyl: A question. I've seen that /tmp is a tmpfs mounted on /var Jul 06 11:35:42 mickeyl: Is that filesystem conserved after a suspend/resume cycle ? Jul 06 11:35:53 absolutely Jul 06 11:35:55 it's RAM Jul 06 11:36:05 mickeyl: I'm having trouble with qcop execing after resuming. Jul 06 11:36:20 mickeyl: It says it's not able to find the unix socket of qte. Jul 06 11:36:39 mickeyl: Then, perhaps it's my qws server that is dying. Jul 06 11:36:43 uh oh. sounds like you somehow managed to destroy your image Jul 06 11:36:52 i never seen that Jul 06 11:37:22 mickeyl: Well, the unix socket is created when the qte acting as server starts Jul 06 11:37:39 mickeyl: Perhaps it's just that my server is dying and so qcop is not able to connect to it. Jul 06 11:37:52 SirFred: yes, that's sounds likely Jul 06 11:38:02 Sirfred: tried running it with -nodaemon and looking for output ? Jul 06 11:38:25 mickeyl: Yes, I see a segfault. Jul 06 11:38:42 mickeyl: But I thought that it was because apm was not calling qcop to resume. Jul 06 11:38:52 mickeyl: So, my driver can segfault. Jul 06 11:38:57 i think so Jul 06 11:39:13 qcop wouldn't segfault if it can't find the socket Jul 06 11:39:16 mickeyl: Thanks. I will take a look with more time to all this. Jul 06 11:39:24 mickeyl: No, it just fails silently. Jul 06 11:39:37 anyway I'm building a recent image to confirm rotation working for me Jul 06 11:39:54 mickeyl: but if my driver tries to paint something before qcop sends the aboutToResume(), I'm died. Jul 06 11:40:22 Sirfred: yeah, this is race condition :/ Jul 06 11:41:03 which is why I'm very nervous about implementing it in user space Jul 06 11:56:00 ~lart Trolltech Jul 06 11:56:01 * ibot beats Trolltech senseless with a 50lb Unix manual Jul 06 11:56:43 ~lart gcc for not inlining this method Jul 06 11:56:43 * ibot DoSes gcc for not inlining this method Jul 06 12:05:44 hrw|gone: ping Jul 06 12:19:27 evening Jul 06 12:25:38 hi reenoo_ Jul 06 12:25:39 03mickeyl * r277 10bitbake/lib/bb/shell.py: Jul 06 12:25:39 Shell: Jul 06 12:25:39 - experimental support for glob expression (wildcards) in command 'build' Jul 06 12:25:39 - add new command 'match ' to see what matches against the expression Jul 06 12:26:27 hrw|gone: here are your wildcards. let me know how it goes and I'll enable it for more commands Jul 06 12:32:26 hey mickey|tv Jul 06 12:41:03 mickey|tv: what is shlex? Jul 06 12:54:00 pb_: unbelievable my prof soldered a max232 board for me Jul 06 12:54:11 pb_: and atleast 'echo' (shortening one side) works now Jul 06 12:54:13 zecke: wow, your prof rules Jul 06 12:54:43 ot:prof as abreviation for professor is not so common I guess? Jul 06 12:54:47 I guess that's why he's the prof. Jul 06 12:55:04 pb_: oh no in germany it is common Jul 06 12:55:21 http://www.mi.fu-berlin.de/kvv/?dozent=30 Jul 06 12:55:27 lecturers he is currently giving Jul 06 12:55:30 zecke: I think it's common enough, though maybe not so much here in the UK. Jul 06 12:55:54 BTW: it works with 100nF caps Jul 06 12:56:21 he means 1UF just comes from people copy and pasting data sheets... Jul 06 12:57:08 my next excercise is to create the serial cable without a maxim Jul 06 12:57:48 zecke: here in England, only department heads are called "Professor"; you wouldn't normally use an expression like "my prof". Jul 06 12:57:57 zecke: aha. Jul 06 12:59:02 pb_: hehe an we use 'Dean' for head of the computer department Jul 06 12:59:36 pb_: but actually he is head of the e-engineering cs group/deparment Jul 06 13:02:24 pb_: what would you call joe random instructor? Jul 06 13:02:50 ha and I can send chars to the pda Jul 06 13:03:09 here, 'dean' refers to the head of the college itself... Jul 06 13:03:18 'head' for the head =p Jul 06 13:03:19 treke: "lecturer", and you'd addres them as "Dr Gilbert". Jul 06 13:03:36 all of them? Jul 06 13:03:44 kind of a strange title Jul 06 13:03:46 yeah, all our lecturers are named Gilbert. Jul 06 13:03:49 lol Jul 06 13:03:58 heh Jul 06 13:04:00 :p Jul 06 13:04:18 we also have "reader", which is a slightly more senior position. Jul 06 13:05:00 and "senior lecturer", I guess, which is somewhere between a lecturer and a reader. Jul 06 13:06:05 There isn't any such thing as an assistant/associate professor: you're either a professor or (more commonly, of course) you're not. Jul 06 13:07:30 zecke: very good Jul 06 13:14:17 unbelievable it is working Jul 06 13:14:21 now to the easy part Jul 06 13:15:01 heh Jul 06 13:15:10 get the kernel ported Jul 06 13:15:27 ah, that's a small matter of software. Jul 06 13:16:25 I try the gödelnumbers which describe a linux kernel Jul 06 13:16:29 and use the one that works best Jul 06 13:23:10 your new platform is based on a turing machine? very good. Jul 06 13:23:27 pb_: everything is based on a turing machine ;) Jul 06 13:23:36 pb_: this is why software patents are totally absurd Jul 06 13:23:48 Patent \in \Sigma^{*} ; Jul 06 13:25:51 03freyther 07org.openembedded.dev * r1856e8cf... 10/packages/module-init-tools/ (module-init-tools-cross_3.1.bb module-init-tools_3.1.bb): Jul 06 13:25:51 SILENT Jul 06 13:25:51 use quotes to follow KEY = "value" scheme to prepare for a Jul 06 13:25:51 new bitbake parser Jul 06 13:26:26 * pb_ goes back to reading the "montavista sucks" thread on linux-arm-kernel Jul 06 13:27:29 zecke: what does "SILENT" mean? Jul 06 13:28:07 pb_: hehe Nicolas vs. Russel Jul 06 13:28:38 pb_: IMHO having two syscall interfaces suck anyway Jul 06 13:29:05 it does, but being stuck with the old syscall interface forever would suck even more Jul 06 13:29:35 pb_: Something mickeyl has to honor ;) In kde one can mark commits with CVS_SILENT and not everyone gets mailed and the subject is altered (to be filtered better) Jul 06 13:30:01 ah, I see Jul 06 13:30:10 I can't figure this quilt-native issue I'm having out. http://pastebin.com/308524 Jul 06 13:31:23 micropal: bitbake -b openembedded/packages/quilt/quilt-native_0.39.bb -cclean Jul 06 13:31:28 micropal: bitbake -b openembedded/packages/quilt/quilt-native_0.39.bb -cfetch -f Jul 06 13:31:36 micropal: what happens if you do that? Jul 06 13:31:46 pb_: did you see my h1940 (tslib.sh) answer? Jul 06 13:34:21 no errors, the output is here http://pastebin.com/308530 Jul 06 13:37:10 zecke: yeah, thanks, I saw that Jul 06 13:39:01 re Jul 06 13:39:23 yeah, that did the trick, but do I have to do that for each package? It stopped at config_savanna.something now. Jul 06 13:40:07 zecke: presumably the h1940 crew should be using QWS_IPAQ or whatever it was. Jul 06 13:40:30 I hadn't realised that qt/e was built differently for every platform. Jul 06 13:41:10 * pb_ joins in with the sucky syscall thread Jul 06 13:41:30 * RP decides to keep out of it Jul 06 13:41:39 * RP is annoyed with rmk for ignoring an email... Jul 06 13:42:11 zecke: shlex offers a .split() method that uses shell like lexing. it offers some more, but split() will do for now Jul 06 13:42:42 * mickeyl wishes someone would mediate. A split in the core arm team is the last thing we need Jul 06 13:43:06 I don't know enough about it... Jul 06 13:43:15 * chouimat|bored is away: trip to the beer store Jul 06 13:44:14 micropal: wait Jul 06 13:44:20 micropal: where is the result of fetch? Jul 06 13:44:33 it checked it out of cvs Jul 06 13:44:52 ok, I'll put it on pastibin in a moment Jul 06 13:44:57 micropal: pastebin your classes/base.bbclass Jul 06 13:45:28 I have to say rmk's I've stated my position and I'm not listening to anyone else now approach is beginning to annoy me... Jul 06 13:46:24 well, irritate anyway... Jul 06 13:46:40 * zecke waits for the next digest to arrive Jul 06 13:47:34 http://folk.uio.no/alexawo/base.bbclass Jul 06 13:47:58 micropal: no from openembedded ;) Jul 06 13:50:11 What? Is it a wrong base.bbclass file? Jul 06 13:51:02 RP: welcome to the wide wonderful world of Linux on ARM Jul 06 13:51:59 ah ok Jul 06 13:52:29 zecke: linking cfg is not really dangerous. If one of the cfg file is modified, then all cache files are reparsed. Jul 06 13:52:33 micropal: got the right one? Jul 06 13:52:40 yes Jul 06 13:52:53 just refresh Jul 06 13:53:24 micropal: looks like an old base.bbclass, your oe snapshot could be old? Jul 06 13:53:55 mickeyl: viewmtn is olverloaded again? Jul 06 13:54:40 micropal: http://monotone.vanille.de/viewmtn/getfile.py?id=d1393cc170e74b6317bacc7f1843e09c96584778&path=classes/base.bbclass Jul 06 13:54:45 micropal: do the diff ;) Jul 06 13:54:46 I'm using anoncvs@cvs.handhelds.org:2401/cvs is it out of date? Jul 06 13:54:54 likely Jul 06 13:55:05 micropal: http://monotone.vanille.de/ Jul 06 13:55:57 03freyther 07org.openembedded.dev * r88ea9c75... 10/ (3 files in 3 dirs): Jul 06 13:55:57 Clean up (begin): Jul 06 13:55:57 Use ${palmtopdir} instead of hardcoding /opt/QtPalmtop. This eases Jul 06 13:55:57 to switch the default opie location once we want it Jul 06 13:55:57 (/usr, /opt/Qtopia /home/sweat/home) Jul 06 14:03:30 help, my bitbake gpe-image failed at gnu-config-native-0.1cvs20050331-r3 Jul 06 14:04:08 I'm on debian sarge and just pulled oe from the main monotone server today Jul 06 14:04:39 fyliu: pastebin your local.conf Jul 06 14:05:05 how to pastebin? Jul 06 14:05:11 ~pastebin Jul 06 14:05:12 methinks pastebin is a place to paste your stuff without flooding the channel - try http://pastebin.ca Jul 06 14:05:28 zecke: viemtn isn't overloaded, it's just buggy. Or my apache server is broken, I have no idea, I'm not exactly a good webmaster :/ Jul 06 14:06:08 randomly pressing reload on different links seem to always fix it, but I agree it lacks something towards satisfaction :D Jul 06 14:06:19 ~lart mod_python Jul 06 14:06:19 * ibot raises middle finger to mod_python Jul 06 14:07:24 in the meantime you better use http://ewi546.ewi.utwente.nl/tmp/viewmtn/ Jul 06 14:07:32 obviously koen is a better apache-configurator :) Jul 06 14:07:33 ~lart people for serving zImage CRLF encoded Jul 06 14:07:35 * ibot dumps 42 tons of dirt, manure, and fish heads on people for serving zImage CRLF encoded Jul 06 14:08:34 Too light a punishment Jul 06 14:08:35 micropal: heh, handhelds.org anoncvs is about six months out of date Jul 06 14:10:19 http://pastebin.ca/17074 Jul 06 14:11:35 I'm trying to build for ipaq 5550 Jul 06 14:11:45 fyliu: DISTRO = "familiar-0.8.2" is the key Jul 06 14:12:02 fyliu: old distros can only be built reliable at the date they we're tagged Jul 06 14:12:15 fyliu: use familiar-0.8.3 please Jul 06 14:12:21 ok Jul 06 14:12:23 zecke: I wonder why we keep those old DISTRO.conf files around on the trunk. Jul 06 14:12:40 * reenoo_ was just about to raise the same question Jul 06 14:12:52 I think it would cause less confusion if they lived only on the branch or tag where they can actually be used. Jul 06 14:13:51 the plan is to break them after tagging Jul 06 14:13:54 and hi all Jul 06 14:14:17 hi koen|ewi Jul 06 14:14:25 "break them"? Jul 06 14:14:44 koen|ewi: why not just delete them? Jul 06 14:14:56 deleting them would do too Jul 06 14:14:58 keeping broken files around seems like a strange plan Jul 06 14:15:07 reenoo_: make bitabke display a big fat warining Jul 06 14:15:12 well, deliberately broken files. Jul 06 14:15:16 hey koen|ewi Jul 06 14:15:22 just move them after tagging Jul 06 14:15:28 s/move/remove/ Jul 06 14:15:33 no Jul 06 14:15:36 move Jul 06 14:15:42 keep history and stuff Jul 06 14:15:49 uhm... we have a SCM, you remember ? Jul 06 14:16:11 yeah. and monotone allows you to move files doesn't it? Jul 06 14:16:37 since you have to grab an old revision anyway to be sure, i don't see the point in moving Jul 06 14:16:48 * reenoo_ shrugs Jul 06 14:16:50 pb_: me too Jul 06 14:17:16 koen|ewi: can you share your apache configuration with me? apparantly yours is more solid than mine Jul 06 14:17:26 mickeyl: we could abuse as a SCM as well Jul 06 14:17:41 mickeyl: he could get us back-ups (diffs from day to day) Jul 06 14:18:06 who needs backups :D Jul 06 14:18:13 just do it again Jul 06 14:18:43 mickeyl: yeah one is supposed to remember stuff Jul 06 14:18:49 mickeyl: history is pretty much per file. I don't see a point in having to dig up old files just to check why a change was introduced. Jul 06 14:18:52 fyliu: sorry for the confusion Jul 06 14:19:21 reenoo_: no digging needed, you've it in your monotone db Jul 06 14:19:50 zecke: nevermind. Jul 06 14:19:51 reenoo_: well, the point is that if you want to build said config, then you have to dig out the old files anyway. keeping it around, moved under obsolete or not, just makes false promises Jul 06 14:20:48 besides that there is plenty of things we can do better when releasing a distribution Jul 06 14:20:50 mickeyl: moving as in 'bk mv familiar-x.y.z.conf familiar-x.y.z+1.conf' Jul 06 14:20:52 a) provide sdk Jul 06 14:21:17 reenoo_: ah that's what you mean. Jul 06 14:21:18 b) provide preconfigured oe+bitbake to build packages Jul 06 14:21:42 reenoo_: now that makes sense Jul 06 14:21:43 reenoo_: tag, release, mv, commit Jul 06 14:21:53 zecke: right Jul 06 14:22:17 reenoo_: agreed, I do not want to lose history when one can preserve it easily Jul 06 14:22:44 * mickeyl follows the EABI/ABI thread with a really really worried face Jul 06 14:22:59 mickeyl: url? Jul 06 14:23:00 which thread? Jul 06 14:23:10 hold on, i'll grab it for you Jul 06 14:23:55 it starts with http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-June/029639.html Jul 06 14:24:07 mickeyl: The monotone patches seems to be for HEAD. Tries to modify Changelog with dates from July. Jul 06 14:24:20 two weeks later RMK and nico are throwing mutt against each other Jul 06 14:24:36 proti: do you have a tarball for me? :) Jul 06 14:25:30 Not yet. Jul 06 14:28:06 http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-July/030036.html :/ Jul 06 14:29:36 rmk is forking the kernel again? Jul 06 14:29:52 i hope not Jul 06 14:30:03 hollow barrels make the loudest sounds... Jul 06 14:30:27 hope you're right Jul 06 14:30:54 as I always do, I refer to the ttySA situation Jul 06 14:31:37 mickeyl: How about calling the current openzaurus distro file openzaurus-current.conf btw? Jul 06 14:32:00 When it comes to release you can copy it, and delete it :) Jul 06 14:32:29 RP: i'll think about it. i would rather call it openzaurus-snapshot.conf though Jul 06 14:33:04 mickeyl: Just an idea. I've probably spent too much time with slackware-current :) Jul 06 14:33:09 hehe Jul 06 14:36:01 03koen 07org.openembedded.dev * rd5919dcd... 10/conf/distro/ (familiar-0.8.0.conf familiar-0.8.1.conf familiar-0.8.2.conf): Remove stale familiar distro configs Jul 06 14:36:09 proti: if you've a patch I would like to see it Jul 06 14:36:28 proti: but I do not know if changing the main configuration is a good idea Jul 06 14:37:10 proti: one does not know how many variables got 'shadowed' already Jul 06 14:37:35 proti: or how many calculations get wrong as they operate half on shadowed and half on new variables Jul 06 14:38:15 zecke: Not so many as you think. But you can always find a case that don't work. Jul 06 14:39:55 zecke: I prepare a patch. Hold a few minutes. Jul 06 14:43:26 mickeyl: how would you write a lexer in python? Jul 06 14:43:38 mickeyl: how would you use yacc in python/for python? Jul 06 14:45:02 zecke: there's a python glue module for bison Jul 06 14:45:05 pybison or something Jul 06 14:46:54 zecke: no idea on both questions Jul 06 14:47:21 as for writing a lexer, if you want to do it by hand then I guess it's no different in python to any other language. Jul 06 14:47:26 parsers and databases are the areas that I've never been motivated to look into Jul 06 14:47:49 * chouimat|bored is back. Jul 06 14:47:53 zecke: i thought the C based parser would've been a promising approach. it was nearly finished wasn't it? Jul 06 14:47:55 I don't know if there's any flex-type tool for python. Jul 06 14:48:30 http://www.nedbatchelder.com/text/python-parsers.html Jul 06 14:48:33 gives a good overview Jul 06 14:49:53 pb_: I would like to use a generated parser Jul 06 14:50:15 mickeyl: bitbake c parser is okay, it need some quirks Jul 06 14:50:21 zecke: parser, or lexer? Jul 06 14:50:26 pb_: both ;) Jul 06 14:50:42 ah :-) Jul 06 14:51:06 plex and pybison interface with lex and bison Jul 06 14:51:08 pb_: tokenizing our bbfiles by hand shouldn't be too hard Jul 06 14:51:10 lexing, at least for bitbake, is straightforward enough that you might as well do it by hand Jul 06 14:51:11 fwiw Jul 06 14:51:16 pb_: hehe Jul 06 14:51:26 it's not as if a .bb file contains many different types of token Jul 06 14:52:03 then I guess something like pybison would be a good way to create the parser. Jul 06 14:52:06 zecke: if in doubt, wrap generated C code in a python extension. obviously you could do that with the existing bitbake C parser too Jul 06 14:52:10 or one of the other tools from that page that mickey mentioned. Jul 06 14:53:31 reenoo_: yah, that seems to be basically what pybison does Jul 06 14:54:01 pb_: ah, ok. Jul 06 14:54:42 I would be most happy to not have any C in bitbake 1.x Jul 06 14:55:17 zecke: I imagine the C parser is also valid C++, if that makes you feel better about it Jul 06 14:55:58 pb_: sadly not Jul 06 14:56:21 ah, that's too bad Jul 06 14:56:45 yeah the C++ band-aid doesn't help here Jul 06 15:01:40 zecke: FYI, there is a Python compiler written in Python called pyc... Jul 06 15:03:04 http://students.ceid.upatras.gr/~sxanth/pyc/ Jul 06 15:04:26 mickeyl: is there a way to fetch the oe source for oz 3.5.3? Jul 06 15:06:03 andersee: bitbake opie-image -cfetch Jul 06 15:06:06 andersee: download the tagged oe tree and then set your DISTRIBUTION to OPENZAURUS-3.5.3 Jul 06 15:06:20 hmm... too slow. ya, what treke and zecke said Jul 06 15:06:45 we have released a oe snapshot for 3.5.3 didn't we? Jul 06 15:07:00 andersee:I'm not really involved in the source issues Jul 06 15:07:49 ah righto Jul 06 15:07:50 http://openzaurus.org/official/unstable/3.5.3/sdk/openembedded-oz3.5.3.tar.bz2 Jul 06 15:07:55 that contains the oe tree from 3.5.3 Jul 06 15:08:06 now just grab the matching bitbake and issue the -cfetch Jul 06 15:10:56 cool Jul 06 15:11:58 some files may fail unless you set CVS_TARBALL_STASH = http://oesources.org/sources/current Jul 06 15:12:04 into local.conf Jul 06 15:12:17 ok Jul 06 15:12:22 that's our mirror for the case of the disappearing upstream :) Jul 06 15:12:29 good plan Jul 06 15:12:35 * mickeyl wanders into bed Jul 06 15:12:37 g'night folks Jul 06 15:12:38 * andersee should do that for the uClibc buildroot Jul 06 15:12:43 mickeyl: good night Jul 06 15:12:44 'night mickeyl Jul 06 15:12:47 night Jul 06 15:12:52 'night mickeyl Jul 06 15:13:55 'night mickey|zzZZzz Jul 06 15:14:12 Is there any reason glibc 2.3.2 would fail for arm? Jul 06 15:14:22 "fail" in what way? Jul 06 15:14:25 It fails on | checking how to run the C preprocessor... arm-linux-gcc -E Jul 06 15:14:26 | configure: error: C preprocessor "arm-linux-gcc -E" fails sanity check Jul 06 15:14:40 not that I can think of, but 2.3.2 is way old. Jul 06 15:14:54 I know. I need it for various reasons Jul 06 15:14:58 you could check config.log for more clues Jul 06 15:16:16 It looks like its failing to find things like stdio.h :-/ Jul 06 15:17:10 and/or gcc doesn't like the -qlanglvl=ansi option? Jul 06 15:17:28 Maybe I need an older gcc to match? (I'm using 3.4.3) Jul 06 15:19:56 zecke: Will finish tomorrow. tired and zzz now. Jul 06 15:20:00 nigh Jul 06 15:20:38 Actually the above is ok. The error is elsewhere :-/ Jul 06 15:23:19 'night all Jul 06 16:11:14 pb_: The glibc test is unable to find the assert.h header file despite it being in the include directory. I suspect a path problem - any ideas where to look? Jul 06 16:12:07 RP: add -verbose to the gcc command line to find out where it's searching. Jul 06 16:19:50 bitbake gpe-image is failing at linux-jlime-sh3-2.6.11 for me Jul 06 16:20:22 saying cc1: error: invalid option 'l' Jul 06 16:23:23 can someone suggest a hint? looks like it's using the compiled toolchain arm-linux-gcc to compile Jul 06 16:36:58 fyliu: Are you after a jlime kernel? If not, you probably have MACHINE set incorrectly Jul 06 16:42:13 I don't know what a jilime kernel is, so I guess I don't need one Jul 06 16:42:31 I set MACHINE = "h3900" Jul 06 16:42:57 for h5550 Jul 06 16:45:52 http://pastebin.ca/17085 Jul 06 17:26:27 fyliu: For some reason its rejecting the kernel it should be building. You need to work out why Jul 06 17:26:43 You don't have spaces in local.conf before any of the variables? Jul 06 17:40:23 maybe I should clean out the temp directory Jul 06 17:40:47 I had DISTRO set to 0.8.2 on an earlier build Jul 06 20:03:47 * emte is tired Jul 06 20:03:57 hey raster you there? Jul 06 20:04:31 was wondering if anyone wrote a sort of vnc with ecore Jul 06 20:05:00 would be nice to use the ecore server live in both the desktop and the pda at the same time ... Jul 06 20:06:03 guess it would require convincing it to "pass through" all input or something ... Jul 06 20:12:40 * emte contemplates Jul 06 22:05:50 facing a problem : http://pastebin.com/308739 yesterday i faced the same problem so i removed the TMPDIR and started all over again. i am facing the same problem again. i dont know why oe is taking gcc-snapshot. need ur advice Jul 06 22:06:44 how do analyse and isolate the problem ?. any ideas ? this is happening while building bootstrap-image for my target ? Jul 06 22:10:03 zecke:ping Jul 06 23:41:02 <__law__> is monotone.vanille.de down? **** ENDING LOGGING AT Wed Jul 06 23:59:56 2005