irclog2html for #oe on 20050706

00:02.09*** join/#oe chouimat (~dieu@chouinard.developer.kde)
00:31.41*** join/#oe hufnus (~slonsiki@m391536d0.tmodns.net)
01:10.27*** join/#oe noclouds (~mhfan@60.166.166.227)
01:22.01*** join/#oe [g2] (~g2@g2.nslu2-linux)
01:39.34*** join/#oe offroadgeek (~offroadge@offroadgeek.sustaining.supporter.pdpc)
01:43.39*** join/#oe hue (~hue@218.20.51.108)
01:55.08*** join/#oe hufnus (~slonsiki@m391536d0.tmodns.net)
02:09.31[g2]Ironnads -- that just makes me LOL every time I read that
02:09.39NAiLhaha
02:09.45NAiL[g2]: bzzt
02:10.28[g2]hehe
02:21.59[g2]I'm looking for some direction on getting Apache 2.0 and PHP5 in OE
02:22.28[g2]I've got the built natively on OpenSlug and I'd like to get them working cross
02:22.32*** join/#oe hue_ (~hue@218.20.235.147)
02:22.57[g2]however, my libtool-fu and oe-fu are lacking
02:23.03*** join/#oe raster (~raster@vagw.valinux.co.jp)
02:26.48treke|homedwww
03:03.16*** join/#oe hue_ (~hue@218.20.51.108)
03:15.10Luke-Jrmonotone: network exception: failed to connect: No route to host
03:15.10Luke-JrO.o
03:16.04Luke-Jrtreke: since when did BitMover GPL it?
03:29.11*** join/#oe dkey (nobody@193.170.48.236)
03:39.18*** join/#oe hue__ (~hue@219.137.146.149)
04:03.38*** join/#oe hufnus (~slonsiki@m7d1e36d0.tmodns.net)
04:13.09*** join/#oe gnufan (~mhfan@60.166.170.248)
04:53.52*** join/#oe Jenna (~cherryRed@s4.http-tunnel.com)
04:54.49*** part/#oe Jenna (~cherryRed@s4.http-tunnel.com)
05:16.12*** join/#oe __law__ (~law@mail.stiftadmont.at)
05:17.41*** join/#oe pelt9834 (peltkore@213-175.69-92-cpe.cableone.net)
05:18.41*** part/#oe pelt9834 (peltkore@213-175.69-92-cpe.cableone.net)
05:25.34*** join/#oe Jenna (~cherryRed@s4.http-tunnel.com)
05:26.41*** join/#oe hufnus (~slonsiki@m7d1e36d0.tmodns.net)
05:26.52*** part/#oe Jenna (~cherryRed@s4.http-tunnel.com)
05:41.18*** join/#oe ideal (~idealm_@222.66.46.90)
06:10.18*** join/#oe gnufan (~mhfan@60.166.173.115)
06:24.52*** join/#oe Jenna (~cherryRed@s4.http-tunnel.com)
06:28.28jacquesmonotone.vanille.de monotone server appears to be down
06:35.06Sirfred|workMorning
06:35.52*** join/#oe emme (~emme@manin.usr.dico.unimi.it)
06:45.11*** join/#oe koobla (~chatzilla@wall4.soft.uni-linz.ac.at)
06:46.25kooblahi all!
06:49.26*** join/#oe hufnus (~slonsiki@m7d1e36d0.tmodns.net)
06:50.51kooblawhy are the monotone repositories down?
07:10.52kooblai tried to compile the bluez-utils./-libs combo but did not get an ipkg when building the lib package - is this intended?
07:14.18kooblaobviously not - checked the other meta bb's
07:17.56*** join/#oe eJumbo (~Mr@203.196.146.243)
07:20.23eJumbogot 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 ?
07:23.03kooblaeJumbo: there should be a package that does this for you - base-files, I think.
07:23.33*** join/#oe ade|desk (~adavey@194.200.143.249)
07:23.48ade|deskmorning folks
07:24.39kooblaeJumbo: look into meta/task-bootstrap and what it depends on
07:26.45*** join/#oe minipanda (~zhanght@221.122.51.131)
07:27.24eJumbobase-files is a package which consists of basic files like in /etc issue, nsswitch.conf things like that.
07:28.52eJumbowhen 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 ?
07:32.00*** join/#oe Ironnads (~Ironnads@host81-134-63-96.in-addr.btopenworld.com)
07:35.38ade|deskeJumbo: consider using udev ?
07:37.18hrw|workmorning
07:37.59hrw|workeJumbo: look how it is done for other devices
07:42.24eJumbotoo many files; atleast where it is done ?. directory ?
07:43.06eJumboalready oe is ported to my device ; omap 5912. but it does not do that. i dont know why ?.
07:44.18hrw|workeJumbo: openembedded/packages/tslib/tslib/*/
07:44.51hrw|workomap5912osk/ has ts.conf and tslib.sh
07:46.09eJumboyes
07:46.27eJumbobut why the devices nodes are not created in /dev/input
07:46.42eJumboit is not done there at tslib/
07:46.42*** join/#oe hufnus (~slonsiki@m228636d0.tmodns.net)
07:49.12hrw|workeJumbo: 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
07:50.30eJumbofine
07:53.14eJumbowhat 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 ?
07:53.40jbowler-away<PROTECTED>
07:54.02jbowler-awaySee /etc/init.d/devices
07:54.50jbowler-away(The image creation command might use a different table though).
07:56.38eJumbowhich /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 ?
07:57.01eJumboi hope u get my question. this is about how oe really works ?
07:58.09jbowler-awayIt'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.
07:58.31jbowler-awayE.g. the image may have an empty /dev directory.
07:59.51hrw|workjbowler-away: check packages/initscripts/*/device_table.txt
08:00.28jbowler-awayI know what's in there, it isn't always the file which is used.
08:00.39eJumboyes.
08:00.53eJumboall entries dont end up in ur filesystem.
08:01.08jbowler-awayIn particular check in 'files' ;-)
08:03.40*** join/#oe pH5 (~ph5@e178225014.adsl.alicedsl.de)
08:04.16jbowler-awayclasses/image_ipk.bbclass is where some of the work happens, bbimage, however, is also important (and it's not in OE)
08:05.28*** join/#oe moa (~cedric@freeway.rd.francetelecom.com)
08:08.26RPmorning all
08:11.08hrw|workhi rp
08:11.20hrw|workRP: weirdness of battery:
08:12.04hrw|workRP: I left work with 70-80% of battery, goes home, attached AC and my Z restarted when I turn it on an hour later
08:15.26XorAhrw|work: RP lardman and I have also noticed 2.6.12-mm1 doesnt actually power down the Z in suspend
08:15.35XorAmorning btw
08:15.56hrw|work;(
08:16.58hrw|workand I can say one about pcmcia hotplug in 2.6.12-mm1
08:17.08hrw|workIt suxx with out-of-kernel modules
08:17.49hrw|workhostap does not define supported card list so it cannot be modprobed by pcmcia hotplug (pcmciautils instead of pcmcia-cs)
08:19.21Sirfred|workRP: Morning.
08:20.10XorAlinus was always against building support card lists and the such into the kernel what changed!
08:20.32hrw|workv10:20 hrw@work:hrw$ gcc --version
08:20.32hrw|workgcc (GCC) 4.0.1 20050701 (prerelease) (Debian 4.0.0-12)
08:20.36hrw|workfinally...
08:24.06huea strange problem of glibc-2.3.5+cvs20050627.bb
08:24.24huewhen I do: for r in ${rpcsvc}; do h=`echo $r|sed -e's,\.x$,.h,'`; rpcgen -h $r -o $h; done
08:24.45hueit reports: cannot find any C preprocessor (cpp)
08:24.45huerpcgen: C preprocessor failed with exit code 1
08:25.20hueI have to specify cpp path for rpcgen with option -Y
08:26.11huein fact, cpp is a symblic link to cpp-4.0 in /usr/bin
08:26.44huewhat's wrong?
08:38.54*** join/#oe mickey|theater (~mickey@deneb.tm.informatik.uni-frankfurt.de)
08:40.14eJumboi have given IMAGE_FSTYPES="jffs2" but i dont get a jffs2 file at all. all i get is a .ext2.gz
08:40.27eJumboi mean image with file system ?
08:41.04hrw|workchecked distro conf and machine conf?
08:42.33mickeylmorning boys and gals
08:42.45hrw|workhi mickeyl
08:43.09XorAmorning mickeyl
08:43.13hrw|workmickeyl: gals like GAL16V4?
08:43.40XorAhrw|work: I remeber programming GALS :-)
08:43.43mickeylFYI: monotone.vanille.de was down since yesterday 21:00 up to today 10:30 because of our router crashing. It's up again
08:43.48mickeylhrw|work: hehe :)
08:44.01hrw|workXorA: I never did it but know chips
08:44.02XorAnow I fail to program wifes!
08:44.09hrw|workXorA: sucker ;)
08:44.23hrw|work~lart bitbake cache
08:44.30XorAhrw|work: GALS were sweet, a whole wodge of TTL logic all compressed into one little chip
08:44.36hrw|workups.. lart udev.inc
08:44.36eJumbohrw|work: did not understand what u said ?
08:44.56jacquesmickeyl, this mean anything to you?
08:44.59jacques<PROTECTED>
08:44.59jacques<PROTECTED>
08:44.59jacquesAttributeError: 'module' object has no attribute 'make'
08:45.06hrw|workeJumbo: look into config of used distro and used machine - they have higher pri then local.conf
08:45.11Sirfred|workmickeyl: Good morning.
08:45.45ade|deskwhat the hell is dreambox ?
08:45.58Sirfred|workmickeyl: I've seen your comments about w100 qte driver still not being suspend/resume safe.
08:46.16hrw|workade|desk: another distro which want to have branch of OE
08:46.53Sirfred|workmickeyl: I have to say that I've not worked on that for some time. We need to define a way to make this.
08:47.24Sirfred|workmickeyl: 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.
08:47.29CIA-403mickeyl * r272 10bitbake/lib/bb/__init__.py: remove last trace of make.py
08:47.34Sirfred|workmickeyl: Perhaps using apm_proxy
08:48.05Sirfred|workmickeyl: But at what level should this events enter, qte? qpe?, opie itself?
08:48.08mickeylSirfred|work: i'd say lets start with 20W100Suspend
08:48.12mickeyland 20W100Resume
08:48.27mickeylinto /etc/apm.d/suspend respectively /etc/apm.d/resume
08:48.45mickeylwould that work to begin with?
08:48.50Sirfred|workmickeyl: And what will make these scripts?
08:48.52Sirfred|workmickeyl: Mmm
08:49.08Sirfred|workmickeyl: Send a qcop event , perhaps?
08:49.15jbowler-awaymickeyl: it seems like bitbake bbimage still uses make.py, at least we are seeing errors:
08:49.16mickeylSirfred|work: these scripts will do whatever necessary
08:49.28Sirfred|workmickeyl: That's the problem. I'm not sure of the best way to implement it.
08:49.45mickeyljbowler-away: see my last bitbake commit
08:49.54Sirfred|workmickeyl: Whatever necessary is 'all the qte process should be informed about the change'
08:51.05Sirfred|workmickeyl: All the proccesses using the qte w100 driver must reattatch, and the one being the qws server has to reinit the card.
08:51.16Sirfred|work~spell reattatch
08:51.20mickeylSirfred|work: ok, that sounds like we want to do the following:
08:51.31mickeyla) two scripts into apm which send qcop signals
08:51.43mickeylb) patch launcher to listen for returnFromSuspend
08:53.15Sirfred|workmickeyl: Is that all?
08:53.29mickeyli think so
08:53.39Sirfred|workmickeyl: How are all the qte clients informed that way?
08:53.39mickeylbut actually i have no idea what to do with the w100, so if there's something missing, tell me :)
08:53.51Sirfred|workmickeyl: The problem is that all the clients need to be informed.
08:53.58mickeylSirfred|work: why and how
08:54.22Sirfred|workmickeyl: Well, to be honest, I'm not sure at all if the clients need to reattach, but I think so.
08:54.42mickeyli'd surprised if they would need to do that
08:54.44Sirfred|workmickeyl: The problem is that the w100 state is stored by the AtiCore driver in a shared memory segment.
08:55.24Sirfred|workmickeyl: 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.
08:55.42Sirfred|workmickeyl: The first process attatching is the one that inits that shmem segment.
08:55.58Sirfred|workmickeyl: As far as the qte process acting as server reinits the w100, the shmem will change.
08:56.10Sirfred|workmickeyl: And the other procesess shared memory segment is no longer valid.
08:56.27Sirfred|work~spell processes
08:56.36Sirfred|workGood to know
08:56.41mickeylhmm ok, that's unfortunate but doesn't sound like a problem. for sure the qws process has a list of attached clients right?
08:57.05Sirfred|workmickeyl: Not sure.
08:57.18Sirfred|workmickeyl: But I won't bet anything on that
08:58.16Sirfred|workmickeyl: You said we had to patch launcher to get that returnFromSuspend qcop message.
08:58.40Sirfred|workmickeyl: So, if no launcher is running (for whatever reason) ...
08:58.54Sirfred|workmickeyl: Isn't that scheme too tied to the way opie works today?
09:00.01Sirfred|workmickeyl: 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.
09:00.26Sirfred|workmickeyl: I don't see the reason to involve the launcher into this.
09:00.49mickeylfor (ClientIterator it = client.begin(); it != client.end(); ++it )
09:00.49mickeyl<PROTECTED>
09:01.01Sirfred|workmickeyl: Where's that code located?
09:01.02mickeyls/delete *it/notifyReattach
09:01.17mickeylqwindowsystem_qws.cpp
09:01.27Sirfred|workmickeyl: Great. That will be useful to our quest.
09:02.22Sirfred|workmickeyl: I see it, on the destructor.
09:02.22mickeylif you can do it on qws level, it'd be even better
09:02.36Sirfred|workmickeyl: Well, I'm not sure if all the qcop messages reach this level.
09:02.38Sirfred|workmickeyl: Do you know?
09:03.15mickeylnot offhand. they have to pass it of course, because the qcopenvelope unix socket is implemented in qte
09:04.09Sirfred|workmickeyl: It seems that in qapplication_qws.cpp is something like a queue and a process method.
09:04.40Sirfred|workvoid QWSDisplayData::fillQueue()
09:04.46Sirfred|workmickeyl: But I'm not sure at all.
09:05.33Sirfred|workmickeyl: What is supposed to be the incoming message, a QWSEvent::QCopMessage ?
09:05.47mickeyli have no idea as well
09:05.51mickeyli never had to poke on that level
09:05.54*** join/#oe Jenna (~cherryRed@209.8.233.104)
09:06.15*** part/#oe Jenna (~cherryRed@209.8.233.104)
09:06.22Sirfred|workmickeyl: Well, if the messages are getting this level, I think it could be easy.
09:06.27Sirfred|works/getting/reaching
09:06.29mickeylwithin the command process, it looks like you can intercept it easily
09:06.32mickeylQWSCommand::QCopSend
09:06.43Sirfred|workmickeyl: Where's that?
09:07.00mickeyl1412
09:07.10mickeylright in the command dispatcher
09:07.51Sirfred|workmickeyl: Hmm, isn't this for sending out commands?
09:08.22mickeyl*shrug* would need to add some debug out
09:08.37Sirfred|workmickeyl: Sorry, but I don't clearly understand how this mess of QWS channels and commands and responses works.
09:08.57Sirfred|workmickeyl: Yes, I will make that. Just add some debug and see where are my messages being received.
09:09.04hrw|workpcmciautils 005 are available - will add it later
09:09.28Sirfred|workmickeyl: Another BC break will be needed, the QWSDisplay should provide methods to resume/suspend.
09:09.32mickeylSirfred|work: heh no problem. there are problably just two or three people in the world who ever had to look at that level
09:09.49mickeylSirfred|work: yeah, I agree.
09:09.53mickeylhrw|work: cool
09:10.19Sirfred|workmickeyl: I suppose they are locked up in some lunatic asylum.
09:10.29mickeylSirfred|work: hehe, definitly
09:10.58mickeylthen again, i'm not sure if the X server is any better on that level
09:11.00Sirfred|workmickeyl: I'll make a reservation.
09:11.03mickeyl:))
09:11.28Sirfred|workmickeyl: Well, I'm thinking lately that perhaps kdrive is the way to go.
09:11.57Sirfred|workmickeyl: From my point of view, I got involved into this because a SDL game refused to run at a decent speed.
09:12.10mickeylSirfred|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 :)
09:12.12Sirfred|workmickeyl: After fixing this, SDL-qte driver should need also to be fixed.
09:12.21hrw|workdtl1_cs patch sent to author
09:12.58Sirfred|workmickeyl: 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.
09:13.28Sirfred|workmickeyl: Because SDL qte driver uses intensively QDirectPainter, so...
09:14.35Sirfred|workmickeyl: Well, I looked at it in my dark SHARP days, perhaps it changed.
09:15.04Sirfred|workmickeyl: When is the new oz release scheduled?
09:16.45hrw|workhmm I got 4x NOTE: Not creating empty archive for udev-utils-005-r0
09:16.47mickeylSirfred|work: I'm targetting Mid August
09:16.57hrw|workNOTE: package pcmciautils-005-r0: task do_build: completed
09:17.13Sirfred|workmickeyl: I'm going on holidays the next week.
09:17.23*** join/#oe lardman (~lardman@138.38.73.178)
09:17.38Sirfred|workmickeyl: Do you think that other than the suspend/resume issue, the driver is working fine? Have you tested it?
09:18.10*** join/#oe Jenna (~cherryRed@209.8.233.104)
09:18.25mickeylSirfred|work: no, i didn't have time to test the latest incarntion.
09:18.31mickeylincarnition, even
09:18.45mickeyli think there's still the bug where small pixmaps are swallowed
09:18.55*** part/#oe Jenna (~cherryRed@209.8.233.104)
09:19.00hrw|workhmm.. I will drop usage of bitbake interactive
09:19.01mickeyli'll get back to you after having tested the latest version
09:19.04mickeylhrw|work: nooo
09:19.43Sirfred|workmickeyl: I didn't touch anything about that, I didn't noticed it in my tests.
09:20.17mickeylSirfred|work: try setting Windows style and then open light-n-power. you see the arrows in the spinboxes are missing
09:20.30eJumbodoes touching my machine conf file do a full build ?
09:20.43Sirfred|workmickeyl: Hmm, are the pixmaps very little?
09:20.55mickeylSirfred|work: yep
09:21.06hrw|workmickeyl: http://pastebin.ca/17012 contra http://pastebin.ca/17013
09:21.11Sirfred|workmickeyl: perhaps some "clever" alignment algorithm of my invention is the guilty.
09:21.27Sirfred|workmickeyl: I'll take a look at it, this evening I expect.
09:22.14mickeylhrw|work: ya, i see, something in file*** seems to be broken. I'll look into that asap
09:22.25hrw|workok. sooner or later my dtl1_cs patch will be added into mainline
09:23.07mickeylexcellent
09:23.11mickeylwe need to send more things upstream
09:23.25hrw|workRP: I will add that into 2.6.12-mm1.bb
09:26.01hrw|workif I want to commit one file (from few changed) should I use "monotone commit file1 --message ''"?
09:26.10hrw|workor there is "monotone ci"?
09:26.28hrw|workthere is ci
09:26.43hrw|workalias for commit ;)
09:33.25CIA-403hrw 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)
09:33.26CIA-403hrw 07org.openembedded.dev * r6ce955f2... 10/packages/ (2 files in 2 dirs): added pcmciautils 005
09:33.37RPhrw: thanks :)
09:35.43hrw|workRP: no
09:35.46hrw|workproblemo
09:36.05hrw|workRP: thats my card so my business tohave it working
09:36.56RPhrw|work: Its often a driving factor :)
09:37.04hrw|worknow sysfsutils 1.3.0
09:38.15hrw|workNOTE: package sysfsutils-1.3.0-r0: task do_build: completed
09:39.18hrw|workmonotone: note: this revision creates divergence
09:39.18hrw|workmonotone: note: you may (or may not) wish to run 'monotone merge'
09:39.22hrw|workheh..
09:39.57mickeyls/or may not//
09:39.58mickeyl:)
09:39.58hrw|workmerged
09:40.10hrw|workmickeyl: you forgot about () :)
09:40.33mickeylheh
09:40.37mickeyli always do that
09:40.43mickeylwho needs brackets...
09:41.05hrw|work"monotone: note: you may () wish to run 'monotone merge'" looks strange then
09:41.24hrw|workin two minutes CIA-4 will say something
09:41.42mickeyloe-commits@handhelds.org now online
09:41.55hrw|workML?
09:42.01mickeylyep
09:42.09mickeylsome people requested that
09:42.21eJumboguys; 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 ?
09:42.23hrw|workgood idea it is
09:42.43hrw|workmickeyl: http://www.kernel.org/pub/linux/utils/kernel/pcmcia/howto.html
09:43.11hrw|workeJumbo: wipe tmpdir and retry?
09:43.56RPmickeyl, 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...
09:44.02eJumboits going to take ages to get it built ?
09:44.18eJumbowhat's the problem i dont get it ?
09:44.20mickeylhrw|work: ah, that's handy. /me prints out
09:44.59Sirfred|workRP: Anyway, the shared data information would be outdated.
09:45.08Sirfred|workRP: As long as the w100 losts its state on suspend.
09:45.20mickeylRP: I'd love to see that happen rather than all the fiddlings on three uncoupled software layers
09:45.24eJumbohrw|work : is there any solution ?
09:45.43RPSirfred|work: I'm thinking these functions we'd add would save the needed w100 state
09:45.44CIA-403hrw 07org.openembedded.dev * r837e5daa... 10/packages/sysfsutils/sysfsutils_1.3.0.bb: added sysfsutils 1.3.0
09:45.54hrw|workeJumbo: what package gave that error?
09:46.10hrw|workeJumbo: always try to put whole output into pastebin
09:47.14Sirfred|workRP: You mean to do that on kernel side?
09:47.49RPSirfred|work: No, I mean we could add a couple of functions to atilib
09:48.25RPI know which registers the kernel restores. We can restore the rest in userspace
09:48.37hrw|workmickeyl: does oe-commit is registered on gmane?
09:48.56Sirfred|workRP: Well, we only need that way to go into the qte server on suspend/restore. The client process shouldn't need to reattach.
09:48.58eJumboplease see for the error: http://pastebin.ca/17018
09:49.36Sirfred|workRP: The approximation is similar from the qte point of view, so going from the first proposal to this one would be easy.
09:49.37hrw|workeJumbo: that glibc is known to compile for arm
09:49.44*** join/#oe pb_ (~pb@2002:5246:d929:1:20a:5eff:fe00:391e)
09:50.08XorAhrw|work: is he talking 2.3.5+cvsXXXXXX
09:50.23mickeylhrw|work: not yet. someone should do that
09:50.28Sirfred|workRP: Even, with the first proposal we only need to perform some actions on resume, not on suspend, if I'm not wrong.
09:50.32hrw|workXorA: no - 2.3.2+cvs20040726
09:50.47hrw|workNOTE: package glibc-2.3.2+cvs20040726: failed
09:50.58XorAhrw|work: ah ok, 2.3.5-XXXX compiles on one machine of mine and not other, must be reliant on something host side
09:51.04eJumbobut it was working earlier ?
09:51.21mickeylgood morning pb_
09:54.33eJumbomy 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 ?
09:55.57hrw|work~lart interactive bitbake once more
09:57.02mickeylmmh
09:57.30hrw|workfilerebuild generate broken packages
09:57.39hrw|workudev without /etc/ for example
09:58.26mickeylthere's just something wrong with the per package metadata handling which is responsible for all problems we have with file***
10:00.36eJumbohrw|work: what do i do now ?. is there any way to resolve this error ?
10:01.12hrw|workeJumbo: I would retry probably
10:01.49eJumboi did i get an error : http://pastebin.ca/17020
10:02.38hrw|workeJumbo: rebuild linux-libc-headers?
10:03.10*** join/#oe Camelot (~Anon@ppp947.adelaide.on.net.au)
10:04.45eJumboshall i remove related dir from tmpdir/work ?
10:06.36*** join/#oe hue (~hue@218.20.51.108)
10:07.09hrw|workeJumbo: bitbake -cclean linux-libc-headers will do it
10:07.50pb_mickeyl: good morning
10:09.35hrw|workok. zaurus rebooting - will check udev 060, sysfsutils 1.3.0, pcmciautils 005 on it
10:11.25mickeylbleeding edge
10:11.33hrw|workjffs2.fsck has problems during each reboot.. even after "reboot" from cmdline ;(
10:12.21hrw|workbooted without problems
10:12.46hrw|workand without udev
10:17.12pb_crumbs, where did you get fsck for jffs2 from?  I didn't realise there even was such a thing.
10:17.26pb_it certainly shouldn't be necessary to fsck a jffs2 partition at bootup.
10:17.55hrw|workpb_: by jffs2.fsck I meant those messages before init started
10:18.29hrw|workhttp://pastebin.ca/17022
10:19.55eJumbohrw|work: get a new error this time : http://pastebin.ca/17023
10:20.13RPhrw|work: You get this if the write buffer isn't synced and you reboot
10:20.30RPI suspect the sync command might be broken again as I've been seeing a lot of these errors as well
10:20.37*** join/#oe Virusmaster (~Thomas@p549CC90B.dip.t-dialin.net)
10:20.56hrw|workRP: ok
10:21.39hrw|workeJumbo: I'm not glibc expert.. this version builds for me
10:33.33*** join/#oe gnufan (~mhfan@60.166.163.120)
10:36.03*** join/#oe maisheri (~hiteshm@rasbtnlChn-static-252.184.145.203.touchtelindia.net)
10:36.22*** join/#oe tmbinc (tmbinc@dsl-084-059-201-041.arcor-ip.net)
10:40.59CIA-403florian 07org.openembedded.dev * r43b1e944... 10/packages/maemo/nokia770-init_1.0.bb: Fix firmware links.
10:47.58*** join/#oe reenoo (~r@wlan-client-252.informatik.uni-bremen.de)
10:48.24reenoomorning
10:48.45hrw|workhi reenoo
10:48.55reenoohey hrw|work
10:49.52*** part/#oe Camelot (~Anon@ppp947.adelaide.on.net.au)
10:53.10*** join/#oe mhfan (~mhfan@60.166.163.247)
11:04.01*** join/#oe TransAm (~TransAm@210.168.243.43)
11:16.51*** join/#oe mhfan (~mhfan@60.166.164.83)
11:17.53Sirfred|workmickey|lunch: Do you think this syntax is correct: qcop QPE/System 'hideInputMethod()'
11:18.12Sirfred|workmickey|lunch: I'm not getting the expected result, is there any qcop script in the system known to work?
11:18.55RPmickey|lunch: That last change to bitbake seems to have broken it :-/
11:20.38RPmickey|lunch: http://pastebin.ca/17029
11:21.10Sirfred|workThe bitburn revision
11:22.59Sirfred|workmickey|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.
11:23.13*** part/#oe eJumbo (~Mr@203.196.146.243)
11:25.19hrw|workRP: could you enable INPUT_UINPUT in 2.6/c7x0? it can be used with kbdd to use external keyboards
11:25.47RPhrw|work: Isn't it already a module?
11:25.57RPIf not, yes, it should be :)
11:26.20hrw|workRP: keybdev is also lacking but I didnt found it yet
11:26.27Sirfred|workhrw|work: What kind of external keyboards can be used with the c7x0 ?
11:27.26hrw|workSirfred|work: currently dont know as kbdd is rather ipaq oriented - but should allow to use some serial or irda ones after tweaking configs/code
11:27.36Sirfred|workhrw|work: ok
11:28.34Sirfred|workOT: Has anybody tested one of those "light keyboards". Ones where the keyboard is projected using light on a surface.
11:28.48hrw|workCONFIG_INPUT_KEYBDEV looks like 2.4 only anyway
11:28.48Sirfred|workI wonder how good they work.
11:29.00hrw|workSirfred|work: friend told me that it was too slow
11:30.00Sirfred|workhrw|work: A pitty
11:31.29hrw|workI'm downgrading udev to 058
11:33.56*** join/#oe [g2] (~g2@g2.nslu2-linux)
11:35.26RPhrw|work: What's wrong with 060?
11:36.21hrw|workRP: does not start on my husky
11:36.39RPhrw|work: Ah :-/
11:36.52hrw|workhmm.. 058 also weird
11:36.59hrw|workwtf...
11:38.02hrw|workagain etc/init.d/devices;(
11:39.05*** join/#oe mrz80 (1000@caledonia.cns.ufl.edu)
11:41.33Sirfred|workmickey|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.
11:51.25*** join/#oe eJumbo (~Mr@203.196.146.243)
11:52.36eJumboif 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 ?
11:54.33*** join/#oe Jenna (~cherryRed@209.8.233.99)
11:54.42hrw|workeJumbo: IMAGE_FSTYPE(S)="jffs2"
11:55.44*** join/#oe BigAl (~bigal@220-253-116-248.ACT.netspace.net.au)
11:55.54hrw|workhi BigAl
11:55.56eJumbomy local.conf has it. but always i get an .ext2.gz image
11:56.07hrw|workeJumbo: what machine/distro?
11:56.13eJumboomap5912
11:56.28eJumbogeneric distro ?
11:57.01hrw|workgeneric distro has IMAGE_FSTYPES = "ext2.gz"
11:57.09hrw|workthats why you get ext2.gz only
11:57.29hrw|workI told you that distro and machine conf has higher pri then local.conf
11:58.03hrw|workcomment IMAGE_FSTYPES in openembedded/conf/distro/generic.conf
11:58.42eJumbodone that.
12:00.02eJumboi have given a bitbake now. and it is starting all over again. i have also included an IMAGE_FSTYPE in machine .conf file.
12:00.18hrw|workNO
12:00.21eJumboi dont know why it is building tool chain all over again ?.
12:00.29hrw|workadd image_fstype only in local.conf
12:00.44hrw|workthats local/distro setting NOT machine related
12:01.16eJumbomodifying (or touching) machine .conf does it make bitbake to build the tool chain ?
12:01.24eJumboall over again ?.
12:01.41CIA-403mickeyl * r273 10bitbake/bin/bitbake: add missing self to find_bbfiles() and get_bbfile()
12:01.59mickey|lunchRP: that should fix it
12:02.35*** join/#oe gints|gone (~gints@195.244.141.102)
12:04.08eJumbowhats TARGET_FPU="Soft" ; does it build libsoftfloat ?.
12:05.10*** join/#oe cvs_ (cvs@crash48.student.utwente.nl)
12:05.21hrw|worklunch time
12:06.28*** join/#oe hue_ (~hue@219.137.146.149)
12:09.56eJumboCrofton: why TARGET_FPU is NOT "Soft" in openomap distro ?
12:12.59__law__http://bugs.openembedded.org/show_bug.cgi?id=134 :-)
12:13.56*** join/#oe Jenna (~cherryRed@209.8.233.99)
12:14.13tmbincis it just me or is org.openembedded.dev currently unmerged?
12:14.21tmbincand is there a way to merge without using emacs? ;)
12:15.17*** part/#oe Jenna (~cherryRed@209.8.233.99)
12:26.55RPmickey|lecture: thanks
12:30.18mickey|lecturetmbinc: install 'meld'
12:30.28eJumbogetting some vague errors: please see http://pastebin.ca/17031
12:30.32mickeylmeld is a nice 3-way merge tool based on python-gnome
12:30.49tmbincok i'll try, thanks
12:30.49eJumboi dont know what happening and why it is happening ?
12:31.33RPhrw|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
12:32.56eJumboRP: 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 ?.
12:33.33RPeJumbo: If you don't sync, that's normal. If you do sync before rebooting, its a sign of the current problem
12:34.28eJumboi have a battery. and also i used to shutdown or reboot. so sync should happen right ?
12:34.55RPdepends on your shutdown scripts ;-)
12:35.15eJumbousing only provided by oe
12:35.47RPI'm not sure what oe actually does tbh. Most of the time I reboot by syncing and then rebooting using SysRq
12:35.48pb_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.
12:36.10pb_The blocks with the CRC errors will eventually be erased and reused, at which point the errors will go away.
12:36.47hrw|workRP: ;(
12:36.52NAiLRP: Do you know if the problem still in 2.6.12.2?
12:37.20hrw|workmickeyl: 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
12:37.28mickeylhrw|work: no idea, sorry.
12:37.36hrw|workok
12:37.44mickeylhrw|work: there's a hook somewhere. check in reference manual
12:37.59mickeylget_merge_tool or so
12:38.07hrw|workRP: disabling i/o schedulers other then CFQ gives 100K free in kernel_image
12:38.35RPNAiL: The problem might not be in 2.6.12 - it may from from the -mm tree which has mtd cvs
12:38.42RPit may come from
12:38.49NAiLaha
12:39.44RPI meant the Zaurus 2.6.12 tree which includes -mm in the comment above. Sorry for the confusion :)
12:40.24*** join/#oe Laibsch (~leggewie@G117a.g.pppool.de)
12:40.28eJumbogetting an error while building : http://pastebin.ca/17031
12:41.15[g2]RP is it the mtd layer or mtd-utils ?
12:41.55RP[g2]: Its in the kernel jffs2 or mtd code
12:42.22[g2]RP thx... that's was I was afraid of
12:45.17pb_eJumbo: why are you trying to build gcc-snapshot?
12:45.22pb_It sounds like that .bb file is out of date.
12:45.38eJumbodont know it downloaded by itself and doing it ?.
12:47.18*** join/#oe stevenh (~xev@65.167.23.2)
12:47.26CIA-403tmbinc 07org.openembedded.dreambox * r7005f81e... 10/packages/tuxbox/ (15 files in 3 dirs): adding tuxbox (dvb) libraries, tools
12:47.36eJumboHistory: 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
12:48.18eJumboi dont know why one change to machine .conf file has caused my oe setup to corrupt.
12:49.03eJumboi 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.
12:49.08tmbincmickeyl: why is viewmtn constantly complaining "'module' object has no attribute 'monotone'"? is it you changing something or some other problem?
12:50.03mickeyltry reloading it
12:50.10mickeylmod_python sometimes acts odd
12:50.15mickeylforce reload with your browser
12:50.28tmbincok
12:52.55CIA-403tmbinc 07org.openembedded.dreambox * rbcc127d3... 10/ (42 files in 23 dirs):
12:52.55CIA-4propagate from branch 'org.openembedded.dev' (head d770ca43ebb6406692cd960c33f11791c1a25c95)
12:52.55CIA-4<PROTECTED>
12:52.55eJumbopb_ : snapshots .bb files are not out of date. do u know what should i do to resolve my problem.
12:53.53mickeylhmm bummer, now I'm getting that server problem again
12:53.59mickeyl~lart mod_python and viewmtn
12:56.47hrw|work~lart c7x0 battery
12:58.17hrw|worknow I have discharged husky
13:06.27pb_eJumbo: what do you mean by "not out of date"?
13:06.35pb_if it is trying to use f77, it is out of date by definition.
13:08.58*** join/#oe zinga (~arnaudb@186.80-203-227.nextgentel.com)
13:12.08hrw|workweird logic by kdepimpi authors:
13:12.12hrw|workWhen saving data KA/Pi did consume a lot of memory for the data parsing during the save process.
13:12.15hrw|workThis is fixed.
13:12.18hrw|workExample:
13:12.21hrw|work<PROTECTED>
13:12.24hrw|work<PROTECTED>
13:12.26hrw|work<PROTECTED>
13:12.30hrw|work22M to save 600K file??
13:12.50mickeylkdepimpi.inc doesn't seem to be correct
13:12.58mickeylsee comment to #133
13:13.24*** join/#oe noclouds (~mhfan@60.166.167.12)
13:13.49hrw|workok
13:15.20hrw|work2.1.13 released so its good time to fix it for me
13:15.37mickeyl*nod*
13:15.44hrw|workmickeyl: but why it works not from interactive?
13:16.05mickeylhere it doesn't work at all
13:16.22mickeylwhich is the behaviour i would expect
13:16.28hrw|workok
13:16.29mickeylcould it be that zautrix changed source after release ?
13:16.40*** join/#oe minipanda (~zhanght@219.236.30.59)
13:18.03mickeylhmm wait
13:18.20mickeylno i see the file
13:18.39mickeyl*sigh* a lot of strange this happening here lately
13:18.43mickeylthings, even
13:22.18hrw|workhmm.. 'mt rename' does not rename without commit?
13:22.31mickeylyes
13:22.45hrw|workweird
13:22.51mickeylsee manual
13:23.00mickeylmt rename
13:23.00eJumbopb_: 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 ?
13:23.02mickeylthen move by hand
13:23.04mickeylthen commit
13:23.08hrw|workah..
13:23.30hrw|workweird a bit
13:24.59*** join/#oe marcan (1337@85.Red-83-53-2.pooles.rima-tde.net)
13:25.22marcan'lo
13:26.02eJumbopb_: waiting for ur response
13:27.38mickeylhi marcan
13:27.44marcanhi mickeyl
13:34.23hrw|workhello marcan
13:35.02marcanhi
13:36.02*** join/#oe chouimat|Zzzz (~dieu@r2351064.cidc.net)
13:36.09eJumbois this an CVSDATE issue ?. oe is trying to build gcc-snapshot-cross-20050619: i dont know why ?.
13:37.20eJumbocan 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
13:39.12tmbinceJumbo: 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)
13:39.38CIA-403tmbinc 07org.openembedded.dreambox * rd471b807... 10/packages/busybox/ (busybox-1.00/nptl_task.patch busybox_1.00.bb): add nptl support to busybox
13:39.38CIA-403tmbinc 07org.openembedded.dreambox * r861b4547... 10/packages/freetype/ (freetype-2.0.9/install.mk.patch freetype_2.0.9.bb): add freetype 2.0.9
13:39.39CIA-403tmbinc 07org.openembedded.dreambox * r9696fb93... 10/packages/mrouted/ (mrouted-3.9.diff mrouted.bb): add mrouted
13:39.40tmbinc(or whatever version of gcc you want to use :)
13:41.10emtewere 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
13:43.11eJumboemte: 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 ?
13:43.46hrw|worktmbinc: local conf or distro conf are better place
13:44.22tmbinchrw|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)
13:44.22hrw|workfreetype 2.0.9?
13:44.29hrw|worktmbinc: ah..
13:44.40tmbincthus distri config isn't good, at least for me
13:44.49pb_eJumbo: the fact that it is dated June 24 doesn't indicate that its contents are up to date.
13:44.56CIA-403tmbinc 07org.openembedded.dreambox * rbe305d33... 10/packages/timezones/timezones-alternative.bb: add timezones-alternative, a different version of timezone data, more suitable for some applications
13:45.00CIA-403tmbinc 07org.openembedded.dreambox * r0856b0f1... 10/packages/swig/ (swig-native_cvs.bb swig_cvs.bb): add swig, swig-native
13:45.01tmbincand local.conf is problematic as users should not have to edit their local(!) settings to make the stuff compiling
13:45.13pb_but, irrespective of that, it shouldn't be using gcc-snapshot anyway.  YOu'll need to establish why that is happening.
13:45.38hrw|worknokia770 changeset is d770.... ;)
13:46.04eJumbopb_: i really dont know how to resolve this problem and need ur advice
13:46.15mickeylhehe
13:47.09eJumboi dont know what make oe to get that gcc-snapshot ?
13:47.45tmbinchrw|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 ;)
13:48.50hrw|worktmbinc: ok - you wanted better version, you added it and we will get nice update
13:49.54tmbinchrw|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.
13:51.49hrw|worksure
13:57.39*** join/#oe noclouds (~mhfan@60.166.168.1)
13:59.32pb_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.
13:59.49pb_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.
14:00.31hrw|workpb_: currently no news about EABI/arm?
14:06.09hrw|workmickeyl: fileunpack would be great
14:06.49mickeylhrw|work: *nod*. i'll add fileunpack, filefetch, filepatch just for the sake of completeness
14:07.19mickeyl#133 is valid, i'm currently looking into it
14:07.37hrw|workok
14:07.38pb_hrw|work: no, sorry.  I have been too busy to chase Dan for the bits we need.
14:07.55hrw|workpb_: thx
14:08.10mickeyltoo much bb lowlevel code
14:09.08pb_heh
14:11.37hrw|workheh.. now even filerebuild kdepimpi_2.1.13.bb fails
14:27.46*** join/#oe mithro (~tim@212.129.242.85)
14:28.46*** join/#oe gints (~gints@195.244.141.102)
14:34.18hrw|workRP: http://pastebin.ca/17038
14:35.13RPhrw|work: Did I not check that in? :-/
14:35.21CIA-403hrw 07org.openembedded.dev * r7d47cbc2... 10/packages/kdepimpi/ (6 files in 2 dirs): updated kdepimpi to 2.1.13
14:35.30lardman|workI've just cloned again btw, and it's not there
14:35.47hrw|workRP: it looks like
14:36.17RPIt'll have forgotten to add it...
14:38.10RPThis is going to involve a pull so it's going to be a while...
14:48.01lardman|workRP: have you got an URL for the patch? - if so I'll grab it manually and continue my build
14:48.24RPIts pushed now
14:48.33lardman|workcool, thanks
14:48.54RPhttp://www.rpsys.net/openzaurus/temp/fixstretchblit.patch
14:50.37CIA-403rpurdie 07org.openembedded.dev * rf790dcaf... 10/packages/sharp-binary-only/sharp-aticore-oss-1.0.1/fixstretchblit.patch: Update atilib to avoid a segfault
14:52.55*** join/#oe zecke (freyther@bielefeld.mi.fu-berlin.de)
14:53.00zeckeproti: ping
14:53.27zeckeproti: before filing a bug report to a concrete file look at the history of the file!!!
14:53.57zeckeproti: ask yourself when question (this applies to your original patch as well)
14:53.59SirfredRP: 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.
14:54.15zeckeproti: what happens if you write a shared dictionary to disk
14:54.36zeckeproti: and is it still shared when you unpickle the data?
14:54.54RPSirfred: I'd just forgotten to monotone add it. Too busy worrying about creating accidental branches etc :)
14:55.03zeckeproti: in the case of unpickling you've two dict instances which obviously wastes memory
14:55.29zecke
14:56.46zeckeproti: so you might save time and memory when initially parsing
14:56.52protizecke: shared dict is not written on disk.
14:57.03zeckeproti: but you waste memory and time when reading from disk...
14:57.31zeckeproti: what shared dict?
14:57.58*** join/#oe Jenna (~cherryRed@209.8.233.107)
14:58.30*** part/#oe Jenna (~cherryRed@209.8.233.107)
14:59.32*** part/#oe ade|desk (~adavey@194.200.143.249)
14:59.53pb_hi zecke
15:01.00protizecke: this shared. -> What happens if you write a shared dictionary to disk
15:01.28protiThe only shared dict was the make.cfg dict.
15:03.04*** join/#oe dhr (~hugh@CPE00606767ed59-CM000f9fa81660.cpe.net.cable.rogers.com)
15:03.09protizecke: What I am wasting ? Can you give me an example please.
15:06.06zeckeproti: you parse make.cfg
15:06.22zeckeproti: then you want to parse a package description and give make.cfg as the base
15:06.33zeckeproti: you do not want to deepcopy it but link it
15:06.40zeckeproti: the file is going to be pickled
15:06.53zeckeproti: so you will write two dicts (dict in dict) to disk
15:07.20*** join/#oe tigrux (~tigrux@dsl-200-67-236-216.prod-empresarial.com.mx)
15:07.37protizecke: No. See pickle_prep.
15:08.05protiI delink it and store in _data an explicit name 'cfg'.
15:08.49protiOne dict written. And a reference to the dataSet inside.
15:09.31mickeylhrw|work: thanks a lot! your bug report helped me to find a logic error hidden deep inside the shell
15:09.47hrw|workmickeyl: your welcome
15:11.42protizecke: When unpickle, I look at the _data attribute and if it exists, I relink the dataSet to the correct parent in unpickle_prep.
15:14.34protiOnly 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.
15:15.41protiWhat you do in a bb file can have big impact on the include files.
15:23.17*** join/#oe koobla_home (~chatzilla@cm49-137.liwest.at)
15:25.10koobla_homebluez-lib-2.16.bb does not create an ipkg - anyone know why?
15:25.45*** join/#oe zecke__ (fakeuser@p54BD088A.dip0.t-ipconnect.de)
15:26.47*** join/#oe micropal (ident@40.80-202-64.nextgentel.com)
15:28.01hrw|workcu all
15:32.23*** join/#oe gnufan (~mhfan@60.166.169.76)
15:35.59koobla_homeseems bluez-lib does not populate the image directory - shouldn't this be performed by the pkgconfig inheritance?
15:39.11pb_no, pkgconfig doesn't have anything to do with imaging.
15:39.19pb_what exactly is not happening for you?
15:40.28koobla_homethe ipkg is not being built
15:40.43koobla_homethus bluez-utils cannot be included in my image
15:41.05pb_what does the bitbake output look like?
15:41.06koobla_homebluez-lib installs in the staging dirs fine, though
15:41.29koobla_homejust recompiled, it says ipkg refuses to build an empty pkg
15:41.49pb_are those the exact words?
15:42.12CIA-403mickeyl * r274 10bitbake/lib/bb/shell.py:
15:42.12CIA-4Shell: grab a deepcopy from the initial cooker data to reuse
15:42.12CIA-4it in file**** commands. Otherwise we would pollute
15:42.12CIA-4cooker.configuration.data (i.e. do_configure_append() appending
15:42.12CIA-4multiple times). This fixes BitBake bug #133
15:42.27koobla_homeright.
15:42.43koobla_homeand i checked back - the image/ subdir contains only pkgconfig data, no libs
15:45.51pb_how odd
15:45.59pb_let me see if I can check out an up-to-date tree to take a look
15:47.00koobla_homeok, thanks
15:47.57koobla_homeinterestingly, the lib HAS been installed into <workdir>/bluezßlib-2.16/install/bluez-libs/usr/lib/
15:48.54koobla_homes/ß/-/
15:56.32koobla_homepb_, I puild for an XScale board - could this matter?
16:02.03*** join/#oe zap (~zap@217.170.93.9)
16:06.47zeckeproti: are you confident your impl looked like this?
16:07.02protizecke: Like what ?
16:07.16koobla_homepb_, think I found it: the package name is different!
16:07.24protithe cfg description ?
16:07.55protiYes it always worked like this since I supported the cache files.
16:08.36zeckeproti: that wasn't in your cow patches right?
16:08.58protizecke: Yes they were in the cow patches and bbcow too.
16:09.20zeckeproti: how did you find out you got pickled?
16:10.06koobla_homepb_: libbluetooth1_2.16-r0_armv5te.ipk is being built... will change the dependency of bluez-utils and try again
16:11.30koobla_homeor can I define an alias?
16:11.43protizecke: 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.
16:13.31protizecke: It is in pickle_oe and unpickle_oe. See http://www.frankengul.org/cow/cow8a.patch
16:15.35protizecke: I agree that this was missing from bbcow patch. My mistake. Sorry.
16:18.44protiOk the calls are missing from pickle_bb and unpickle_bb in my bbcow.patch.
16:28.38*** join/#oe ar_ (~ar@port-ip-213-211-233-149.reverse.mdcc-fun.de)
16:30.36protimickeyl: Bug #133, why don't you do a createCopy of the dataSet instead of the deepcopy ?
16:37.50*** join/#oe incinerator (~incinerat@82-41-24-164.cable.ubr04.edin.blueyonder.co.uk)
16:39.08protiibot: help
16:39.50koobla_homepb_: must be leaving - bye!
16:45.20protiibot: botmail for zecke: You were correct, calls were lost in the move from oe to bb. Sorry for the mistake.
16:48.17*** join/#oe andersee (~andersee@codepoet.org)
16:53.26Luke-Jribot: botmail for Luke-Jr: hi
16:53.36Luke-Jro.o
16:54.30*** join/#oe koobla_home (~Simon@cm49-137.liwest.at)
17:08.32*** join/#oe mallum (~mallum@host81-154-53-195.range81-154.btcentralplus.com)
17:09.09mickeylproti: because i'm ignorant about dataSet. Sounds like a good idea though
17:15.16protimickeyl: 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.
17:15.24*** join/#oe koobla_home (~Simon@cm49-137.liwest.at)
17:15.28mickeylk
17:15.36mickeylFYI: monotone 0.20 is out
17:15.49mickeyluh oh
17:15.51mickeyldon't upgrade all
17:15.55mickeyl- 0.19 clients cannot talk to 0.20 servers, and vice-versa.
17:15.59protimickeyl: Does it improves the speed ?
17:16.07mickeylno idea, i didn't try
17:16.16protiMy pull takes hours (literally).
17:16.17mickeylvanille.de will have to stay a while on 0.19
17:16.28mickeylbecause of my adjusted viewmtn and ciabot_monotone.py
17:16.55protiI long for a 0.19 with speed improvement.
17:17.24mickeylthen try:
17:17.30mickeylcheckout f56500ddd113aa716173f6d94db5d59c88bdc201
17:17.39mickeyland apply all the patches from http://lists.gnu.org/archive/html/monotone-devel/2005-07/msg00015.html
17:17.45mickeyland apply all the patches from http://lists.gnu.org/archive/html/monotone-devel/2005-07/msg00014.html
17:17.53mickeyli'd be interested in a tarball if you get it to compile
17:18.05protiOk I will try.
17:18.18mickeylexcellent. note the application order as discussed in note the apply order
17:18.27mickeyls/note the apply order/http://lists.gnu.org/archive/html/monotone-devel/2005-07/msg00016.html/
17:18.59protiOne funny thing. To get the modified monotone with speed improvement, you have to pull the monotone .db.
17:19.04protiFirst
17:19.19protiIt took me the night.
17:19.44mickeylheh
17:19.47mickeylwant to grab it from me?
17:20.13mickeylvanille.de/temp/monotone.db
17:20.17mickeylgrabbed two days ago
17:20.21mickeylsaid revision should be included
17:20.37protiI have it now. I will try on my amd64. it's faster. The venerable U60 I run is showing its age.
17:21.07*** join/#oe micropal_ (ident@40.80-202-64.nextgentel.com)
17:21.14protiOk, will grab and try thanks for the info mickeyl.
17:21.17protibbl
17:22.30Sirfredmickeyl: I suppose than no kernel logs are stored on opie after a reboot, aren't they?
17:23.21mickeylright. syslog writes in a ring buffer
17:23.27mickeylin-memory
17:23.42SirfredMm.
17:23.52Sirfredmickeyl: My husky is suspending only at once.
17:24.28Sirfredmickeyl: The next time I try to suspend it just gets freezed. The wifi card blinking, everything frozen, no way to know what's happening.
17:24.44mickeylsounds like you need a serial cable
17:25.21Sirfredmickeyl: I supposed that only USB cables existed.
17:25.33Sirfredmickeyl: So, there's a kernel console via serial?
17:25.43mickeylSirfred: yes.
17:26.04mickeyla kernel console and even a TTY if you want to have that
17:26.09Sirfredmickeyl: For my cute husky?
17:26.16mickeylfor all Zaurus models
17:26.19mickeyleven with the same cable
17:26.26mickeyl(unbelievable, if you know Sharp)
17:26.44SirfredI never would suspect it.
17:27.14SirfredHmm, the machine has come back to life
17:28.25Sirfredmickeyl: Where could I find one of those cables? I assume that there's nothing to do with the USB one, right?
17:29.20mickeylthe usb cable plugs in the same port, but has a different end (of course)
17:29.30mickeylseveral vendors sell those cable
17:29.35mickeyle.g. trisoft.de
17:29.58Sirfredmickeyl: I will take a look, thanks.
17:30.04mickeylnp
17:30.16Sirfredmickeyl: I wonder if I should test all this stuff using a bleeding edge opie image.
17:30.16[g2]is monotone in OE yet ?
17:31.04Sirfredmickeyl: I'm just changing only the minimal components on a 3.5.3
17:31.42mickeylSirfred: I think it'd be better to use a current one,.
17:31.47Sirfredmickeyl: 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.
17:32.06mickeyl[g2]: not yet
17:32.33[g2]mickeyl, it'd be great to have patches like you mentioned above avialable to all
17:34.33SirfredNow it's even not able to suspend, it only says:
17:34.34Sirfredpower.c: device-level power management is not supported yet
17:34.34Sirfredpower: requesting system suspend...
17:34.38SirfredAnd nothing more.
17:34.44*** join/#oe micropal (ident@40.80-202-64.nextgentel.com)
17:35.31CIA-403zecke123 * r275 10bitbake/ (MANIFEST setup.py):
17:35.31CIA-4bitbake/
17:35.31CIA-4<PROTECTED>
17:35.31CIA-4<PROTECTED>
17:37.54mickeyldevice-level power management? d'oh. never seen that one
17:39.15CosmicPenguinheh
17:39.47SirfredAnd:
17:39.48Sirfred# apm --suspend
17:39.48Sirfredapm: Device or resource busy
17:40.00mickeyllooks like a kernel bug
17:40.07mickeylcheck dmesg for oops
17:40.50Sirfredmickeyl: Nothing.
17:41.24Sirfredmickeyl: 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.
17:42.11Sirfredmickeyl: But apm seems to be frozen.
17:43.17mickeylbummer. sounds like a reboot is necessary
17:43.58mickeylFYI (sharpzdc_cs.o): FYI: http://lists.gpl-violations.org/pipermail/legal/2005-July/000385.html
17:44.20*** join/#oe qfh (~qfh@ppp-82-135-5-118.mnet-online.de)
17:44.24mickeylsounds like someone finally takes an attempt to get sources
17:48.19Sirfredmickeyl: This trisoft site is buggy. I cannot understand this english
17:48.33Sirfredmickeyl: Is the Z-Thincable Stecker, what I'm looking for?
17:48.55Sirfred48 euro
17:49.13SirfredSure they made it of gold to improve connectivity
17:50.54mickeylheh
17:51.08*** join/#oe man-di_ (~man-di@dyndsl-080-228-195-008.ewe-ip-backbone.de)
17:51.14tmbincmickeyl: 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)
17:51.37mickeylSirfred: http://www.serialio.com/products/adaptors/ZThinCable.htm manufacture it
17:52.12mickeyltmbinc: 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
17:52.46tmbincyes sure
17:52.46Sirfred$34.95 here, sensible cheaper.
17:54.03*** join/#oe incinerator (~incinerat@82-41-24-164.cable.ubr04.edin.blueyonder.co.uk)
17:56.17*** join/#oe [cc]smart (~smart@gw.ptr-62-65-149-158.customer.ch.netstream.com)
18:04.47*** join/#oe darkschneider (~gab@213-140-6-96.fastres.net)
18:21.36*** join/#oe zecke (~ich@83-169-171-16-dynip.superkabel.de)
18:21.56zeckeproti: sorry I was forced to leave the lab...
18:22.10zeckeactually it burned down and I decided to leave... (just kidding)
18:23.05zeckeproti: but I still think putting a different make.cfg under an cached bbfile is dangerous
18:23.09trekekidding?
18:23.16trekeit burned down and you decided not to leave?
18:24.19CIA-403mickeyl * r276 10bitbake/ (ChangeLog lib/bb/shell.py):
18:24.20CIA-4Shell:
18:24.20CIA-4- use shlex to parse command lines as a special service to hrw: Now you can say 'setvar FOO "this is a test"' :)
18:24.20CIA-4- use a command queue in the main loop to unify offline (from startup file) and online processing
18:24.20CIA-4- add some changes for 1.3.2. Could anyone fill in changes for 1.3.1 ?
18:25.04zeckemickeyl: ping
18:25.54zeckemickeyl: 131 or 132
18:26.05zeckemickeyl: I would think 132 is more natural?
18:26.13zeckemickeyl: but if I do bitbake foo -cfetch
18:26.20zeckemickeyl: I want it to fetch all source files
18:30.21mickeylzecke: yep. i think we should rather leave it like that and fix 131
18:30.35mickeylzecke: he who is using -c should know what he is doing
18:35.08Sirfredmickeyl: A question. I've seen that /tmp is a tmpfs mounted on /var
18:35.42Sirfredmickeyl: Is that filesystem conserved after a suspend/resume cycle ?
18:35.53mickeylabsolutely
18:35.55mickeylit's RAM
18:36.05Sirfredmickeyl: I'm having trouble with qcop execing after resuming.
18:36.20Sirfredmickeyl: It says it's not able to find the unix socket of qte.
18:36.39Sirfredmickeyl: Then, perhaps it's my qws server that is dying.
18:36.43mickeyluh oh. sounds like you somehow managed to destroy your image
18:36.52mickeyli never seen that
18:37.21Sirfredmickeyl: Well, the unix socket is created when the qte acting as server starts
18:37.39Sirfredmickeyl: Perhaps it's just that my server is dying and so qcop is not able to connect to it.
18:37.52mickeylSirFred: yes, that's sounds likely
18:38.02mickeylSirfred: tried running it with -nodaemon and looking for output ?
18:38.25Sirfredmickeyl: Yes, I see a segfault.
18:38.42Sirfredmickeyl: But I thought that it was because apm was not calling qcop to resume.
18:38.52Sirfredmickeyl: So, my driver can segfault.
18:38.57mickeyli think so
18:39.12mickeylqcop wouldn't segfault if it can't find the socket
18:39.16Sirfredmickeyl: Thanks. I will take a look with more time to all this.
18:39.24Sirfredmickeyl: No, it just fails silently.
18:39.37mickeylanyway I'm building a recent image to confirm rotation working for me
18:39.54Sirfredmickeyl: but if my driver tries to paint something before qcop sends the aboutToResume(), I'm died.
18:40.21mickeylSirfred: yeah, this is race condition :/
18:41.03mickeylwhich is why I'm very nervous about implementing it in user space
18:45.58*** join/#oe treke- (~ggilbert@tinman.treke.net)
18:49.28*** join/#oe treke (~ggilbert@tinman.treke.net)
18:56.00zecke~lart Trolltech
18:56.43zecke~lart gcc for not inlining this method
19:05.44mickeylhrw|gone: ping
19:17.42*** join/#oe reenoo (~r@p5489CB70.dip.t-dialin.net)
19:19.27reenoo_evening
19:21.43*** join/#oe BCS (~Vesuvius@cpc1-staf2-3-0-cust62.brhm.cable.ntl.com)
19:25.38mickeylhi reenoo_
19:25.39CIA-403mickeyl * r277 10bitbake/lib/bb/shell.py:
19:25.39CIA-4Shell:
19:25.39CIA-4- experimental support for glob expression (wildcards) in command 'build'
19:25.39CIA-4- add new command 'match <providers|files> <globexpr>' to see what matches against the expression
19:26.27mickeylhrw|gone: here are your wildcards. let me know how it goes and I'll enable it for more commands
19:32.26reenoo_hey mickey|tv
19:32.52*** join/#oe dyoung-zzzz (~dyoung@dyoung.nslu2-linux)
19:37.13*** part/#oe dyoung-zzzz (~dyoung@dyoung.nslu2-linux)
19:41.03zeckemickey|tv: what is shlex?
19:45.49*** join/#oe dyoung (~dyoung@dyoung.nslu2-linux)
19:50.20*** join/#oe pb_ (~pb@2002:5168:d274:1:a00:1fff:fe06:93c)
19:50.38*** join/#oe Ken|JLimeX (~Ken@h79n2fls31o1105.telia.com)
19:54.00zeckepb_: unbelievable my prof soldered a max232 board for me
19:54.11zeckepb_: and atleast 'echo' (shortening one side) works now
19:54.13pb_zecke: wow, your prof rules
19:54.43zeckeot:prof as abreviation for professor is not so common I guess?
19:54.47pb_I guess that's why he's the prof.
19:55.04zeckepb_: oh no in germany it is common
19:55.21zeckehttp://www.mi.fu-berlin.de/kvv/?dozent=30
19:55.27zeckelecturers he is currently giving
19:55.30pb_zecke: I think it's common enough, though maybe not so much here in the UK.
19:55.54zeckeBTW: it works with 100nF caps
19:56.21zeckehe means 1UF just comes from people copy and pasting data sheets...
19:57.08zeckemy next excercise is to create the serial cable without a maxim
19:57.48pb_zecke: here in England, only department heads are called "Professor"; you wouldn't normally use an expression like "my prof".
19:57.57pb_zecke: aha.
19:59.03zeckepb_: hehe an we use 'Dean' for head of the computer department
19:59.36zeckepb_: but actually he is head of the e-engineering cs group/deparment
20:02.24trekepb_: what would you call joe random instructor?
20:02.50zeckeha and I can send chars to the pda
20:03.09Luke-Jrhere, 'dean' refers to the head of the college itself...
20:03.18Luke-Jr'head' for the head =p
20:03.19pb_treke: "lecturer", and you'd addres them as "Dr Gilbert".
20:03.35trekeall of them?
20:03.44trekekind of a strange title
20:03.46pb_yeah, all our lecturers are named Gilbert.
20:03.49Luke-Jrlol
20:03.58reenoo_heh
20:04.00treke:p
20:04.18pb_we also have "reader", which is a slightly more senior position.
20:05.00pb_and "senior lecturer", I guess, which is somewhere between a lecturer and a reader.
20:06.05pb_There isn't any such thing as an assistant/associate professor: you're either a professor or (more commonly, of course) you're not.
20:07.30pb_zecke: very good
20:13.05*** join/#oe tmbinc (tmbinc@dsl-084-059-219-053.arcor-ip.net)
20:14.17zeckeunbelievable it is working
20:14.21zeckenow to the easy part
20:15.01pb_heh
20:15.10zeckeget the kernel ported
20:15.27pb_ah, that's a small matter of software.
20:16.25zeckeI try the gödelnumbers which describe a linux kernel
20:16.30zeckeand use the one that works best
20:23.10pb_your new platform is based on a turing machine?  very good.
20:23.27zeckepb_: everything is based on a turing machine ;)
20:23.36zeckepb_: this is why software patents are totally absurd
20:23.48zeckePatent \in \Sigma^{*} ;
20:25.51CIA-403freyther 07org.openembedded.dev * r1856e8cf... 10/packages/module-init-tools/ (module-init-tools-cross_3.1.bb module-init-tools_3.1.bb):
20:25.51CIA-4SILENT
20:25.51CIA-4use quotes to follow KEY = "value" scheme to prepare for a
20:25.51CIA-4new bitbake parser
20:27.28pb_zecke: what does "SILENT" mean?
20:28.07zeckepb_: hehe Nicolas vs. Russel
20:28.38zeckepb_: IMHO having two syscall interfaces suck anyway
20:29.05pb_it does, but being stuck with the old syscall interface forever would suck even more
20:29.35zeckepb_: 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)
20:30.01pb_ah, I see
20:30.10micropalI can't figure this quilt-native issue I'm having out. http://pastebin.com/308524
20:31.23zeckemicropal: bitbake -b openembedded/packages/quilt/quilt-native_0.39.bb -cclean
20:31.28zeckemicropal: bitbake -b openembedded/packages/quilt/quilt-native_0.39.bb -cfetch -f
20:31.36zeckemicropal: what happens if you do that?
20:31.46zeckepb_: did you see my h1940 (tslib.sh) answer?
20:34.21micropalno errors, the output is here http://pastebin.com/308530
20:37.10pb_zecke: yeah, thanks, I saw that
20:39.01protire
20:39.23micropalyeah, that did the trick, but do I have to do that for each package? It stopped at config_savanna.something now.
20:40.07pb_zecke: presumably the h1940 crew should be using QWS_IPAQ or whatever it was.
20:40.30pb_I hadn't realised that qt/e was built differently for every platform.
20:42.11mickeylzecke: shlex offers a .split() method that uses shell like lexing. it offers some more, but split() will do for now
20:43.06RPI don't know enough about it...
20:44.14zeckemicropal: wait
20:44.20zeckemicropal: where is the result of fetch?
20:44.33micropalit checked it out of cvs
20:44.52micropalok, I'll put it on pastibin in a moment
20:44.57zeckemicropal: pastebin your classes/base.bbclass
20:45.28RPI 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...
20:46.24RPwell, irritate anyway...
20:47.17*** join/#oe fyliu (~fyliu@lenert44.ucsd.edu)
20:47.34micropalhttp://folk.uio.no/alexawo/base.bbclass
20:47.59zeckemicropal: no from openembedded ;)
20:50.11micropalWhat? Is it a wrong base.bbclass file?
20:51.02CosmicPenguinRP: welcome to the wide wonderful world of Linux on ARM
20:51.59micropalah ok
20:52.29protizecke: linking cfg is not really dangerous. If one of the cfg file is modified, then all cache files are reparsed.
20:52.33zeckemicropal: got the right one?
20:52.40micropalyes
20:52.53micropaljust refresh
20:53.24zeckemicropal: looks like an old base.bbclass, your oe snapshot could be old?
20:53.55zeckemickeyl: viewmtn is olverloaded again?
20:54.40zeckemicropal: http://monotone.vanille.de/viewmtn/getfile.py?id=d1393cc170e74b6317bacc7f1843e09c96584778&path=classes/base.bbclass
20:54.45zeckemicropal: do the diff ;)
20:54.46micropalI'm using anoncvs@cvs.handhelds.org:2401/cvs is it out of date?
20:54.54zeckelikely
20:55.05zeckemicropal: http://monotone.vanille.de/
20:55.57CIA-403freyther 07org.openembedded.dev * r88ea9c75... 10/ (3 files in 3 dirs):
20:55.57CIA-4Clean up (begin):
20:55.57CIA-4<PROTECTED>
20:55.57CIA-4<PROTECTED>
20:55.57CIA-4<PROTECTED>
21:03.30fyliuhelp, my bitbake gpe-image failed at gnu-config-native-0.1cvs20050331-r3
21:04.08fyliuI'm on debian sarge and just pulled oe from the main monotone server today
21:04.39zeckefyliu: pastebin your local.conf
21:05.05fyliuhow to pastebin?
21:05.11zecke~pastebin
21:05.11ibotmethinks pastebin is a place to paste your stuff without flooding the channel - try http://pastebin.ca
21:05.27mickeylzecke: 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 :/
21:06.08mickeylrandomly pressing reload on different links seem to always fix it, but I agree it lacks something towards satisfaction :D
21:06.19mickeyl~lart mod_python
21:07.24mickeylin the meantime you better use http://ewi546.ewi.utwente.nl/tmp/viewmtn/
21:07.32mickeylobviously koen is a better apache-configurator :)
21:07.34zecke~lart people for serving zImage CRLF encoded
21:08.35CosmicPenguinToo light a punishment
21:08.35pb_micropal: heh, handhelds.org anoncvs is about six months out of date
21:10.19fyliuhttp://pastebin.ca/17074
21:11.35fyliuI'm trying to build for ipaq 5550
21:11.45zeckefyliu: DISTRO = "familiar-0.8.2" is the key
21:12.02zeckefyliu: old distros can only be built reliable at the date they we're tagged
21:12.15zeckefyliu: use familiar-0.8.3 please
21:12.20fyliuok
21:12.23pb_zecke: I wonder why we keep those old DISTRO.conf files around on the trunk.
21:12.52pb_I think it would cause less confusion if they lived only on the branch or tag where they can actually be used.
21:13.51koen|ewithe plan is to break them after tagging
21:13.54koen|ewiand hi all
21:14.17reenoo_hi koen|ewi
21:14.25reenoo_"break them"?
21:14.44pb_koen|ewi: why not just delete them?
21:14.56koen|ewideleting them would do too
21:14.58pb_keeping broken files around seems like a strange plan
21:15.07koen|ewireenoo_: make bitabke display a big fat warining
21:15.12pb_well, deliberately broken files.
21:15.16mickeylhey koen|ewi
21:15.22reenoo_just move them after tagging
21:15.28mickeyls/move/remove/
21:15.33reenoo_no
21:15.36reenoo_move
21:15.42reenoo_keep history and stuff
21:15.49mickeyluhm... we have a SCM, you remember ?
21:16.11reenoo_yeah. and monotone allows you to move files doesn't it?
21:16.37mickeylsince you have to grab an old revision anyway to be sure, i don't see the point in moving
21:16.50zeckepb_: me too
21:17.16mickeylkoen|ewi: can you share your apache configuration with me? apparantly yours is more solid than mine
21:17.26zeckemickeyl: we could abuse as a SCM as well
21:17.41zeckemickeyl: he could get us back-ups (diffs from day to day)
21:18.06mickeylwho needs backups :D
21:18.12mickeyljust do it again
21:18.43zeckemickeyl: yeah one is supposed to remember stuff
21:18.49reenoo_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.
21:18.52zeckefyliu: sorry for the confusion
21:19.21zeckereenoo_: no digging needed, you've it in your monotone db
21:19.50reenoo_zecke: nevermind.
21:19.51mickeylreenoo_: 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
21:20.48zeckebesides that there is plenty of things we can do better when releasing a distribution
21:20.50reenoo_mickeyl: moving as in 'bk mv familiar-x.y.z.conf familiar-x.y.z+1.conf'
21:20.52zeckea) provide sdk
21:21.17mickeylreenoo_: ah that's what you mean.
21:21.18zeckeb) provide preconfigured oe+bitbake to build packages
21:21.42mickeylreenoo_: now that makes sense
21:21.43zeckereenoo_: tag, release, mv, commit
21:21.44*** part/#oe BCS (~Vesuvius@cpc1-staf2-3-0-cust62.brhm.cable.ntl.com)
21:21.53reenoo_zecke: right
21:22.18zeckereenoo_: agreed, I do not want to lose history when one can preserve it easily
21:22.59reenoo_mickeyl: url?
21:23.00koen|ewiwhich thread?
21:23.10mickeylhold on, i'll grab it for you
21:23.55mickeylit starts with http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-June/029639.html
21:24.07protimickeyl: The monotone patches seems to be for HEAD. Tries to modify Changelog with dates from July.
21:24.20mickeyltwo weeks later RMK and nico are throwing mutt against each other
21:24.36mickeylproti: do you have a tarball for me? :)
21:25.30protiNot yet.
21:28.06mickeylhttp://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-July/030036.html :/
21:29.36koen|ewirmk is forking the kernel again?
21:29.52mickeyli hope not
21:30.03koen|ewihollow barrels make the loudest sounds...
21:30.27mickeylhope you're right
21:30.54koen|ewias I always do, I refer to the ttySA situation
21:31.37RPmickeyl: How about calling the current openzaurus distro file openzaurus-current.conf btw?
21:32.00RPWhen it comes to release you can copy it, and delete it :)
21:32.29mickeylRP: i'll think about it. i would rather call it openzaurus-snapshot.conf though
21:33.03RPmickeyl: Just an idea. I've probably spent too much time with slackware-current :)
21:33.09mickeylhehe
21:36.01CIA-403koen 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
21:36.09zeckeproti: if you've a patch I would like to see it
21:36.28zeckeproti: but I do not know if changing the main configuration is a good idea
21:37.10zeckeproti: one does not know how many variables got 'shadowed' already
21:37.35zeckeproti: or how many calculations get wrong as they operate half on shadowed and half on new variables
21:38.15protizecke: Not so many as you think. But you can always find a case that don't work.
21:38.29*** join/#oe duck (~duck@mg.acegroup.cc)
21:39.55protizecke: I prepare a patch. Hold a few minutes.
21:43.26zeckemickeyl: how would you write a lexer in python?
21:43.38zeckemickeyl: how would you use yacc in python/for python?
21:45.02pb_zecke: there's a python glue module for bison
21:45.05pb_pybison or something
21:46.54mickeylzecke: no idea on both questions
21:47.21pb_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.
21:47.26mickeylparsers and databases are the areas that I've never been motivated to look into
21:47.53mickeylzecke: i thought the C based parser would've been a promising approach. it was nearly finished wasn't it?
21:47.55pb_I don't know if there's any flex-type tool for python.
21:48.30mickeylhttp://www.nedbatchelder.com/text/python-parsers.html
21:48.33mickeylgives a good overview
21:49.53zeckepb_: I would like to use a generated parser
21:50.15zeckemickeyl: bitbake c parser is okay, it need some quirks
21:50.20pb_zecke: parser, or lexer?
21:50.26zeckepb_: both ;)
21:50.42pb_ah :-)
21:51.06mickeylplex and pybison interface with lex and bison
21:51.08zeckepb_: tokenizing our bbfiles by hand shouldn't be too hard
21:51.10pb_lexing, at least for bitbake, is straightforward enough that you might as well do it by hand
21:51.11mickeylfwiw
21:51.16zeckepb_: hehe
21:51.26pb_it's not as if a .bb file contains many different types of token
21:52.03pb_then I guess something like pybison would be a good way to create the parser.
21:52.06reenoo_zecke: if in doubt, wrap generated C code in a python extension. obviously you could do that with the existing bitbake C parser too
21:52.10pb_or one of the other tools from that page that mickey mentioned.
21:53.31pb_reenoo_: yah, that seems to be basically what pybison does
21:54.00reenoo_pb_: ah, ok.
21:54.41zeckeI would be most happy to not have any C in bitbake 1.x
21:55.17pb_zecke: I imagine the C parser is also valid C++, if that makes you feel better about it
21:55.58zeckepb_: sadly not
21:56.20pb_ah, that's too bad
21:56.45zeckeyeah the C++ band-aid doesn't help here
22:01.40Luke-Jrzecke: FYI, there is a Python compiler written in Python called pyc...
22:03.03Luke-Jrhttp://students.ceid.upatras.gr/~sxanth/pyc/
22:04.26anderseemickeyl: is there a way to fetch the oe source for oz 3.5.3?
22:06.03zeckeandersee: bitbake opie-image -cfetch
22:06.06trekeandersee: download the tagged oe tree and then set your DISTRIBUTION to OPENZAURUS-3.5.3
22:06.20mickeylhmm... too slow. ya, what treke and zecke said
22:06.45mickeylwe have released a oe snapshot for 3.5.3 didn't we?
22:07.00mickeylandersee:I'm not really involved in the source issues
22:07.49mickeylah righto
22:07.50mickeylhttp://openzaurus.org/official/unstable/3.5.3/sdk/openembedded-oz3.5.3.tar.bz2
22:07.55mickeylthat contains the oe tree from 3.5.3
22:08.06mickeylnow just grab the matching bitbake and issue the -cfetch
22:10.56anderseecool
22:11.58mickeylsome files may fail unless you set CVS_TARBALL_STASH = http://oesources.org/sources/current
22:12.04mickeylinto local.conf
22:12.17anderseeok
22:12.22mickeylthat's our mirror for the case of the disappearing upstream  :)
22:12.29anderseegood plan
22:12.37mickeylg'night folks
22:12.43pb_mickeyl: good night
22:12.44koen|ewi'night mickeyl
22:12.47anderseenight
22:12.52reenoo_'night mickeyl
22:13.55RP'night mickey|zzZZzz
22:14.12RPIs there any reason glibc 2.3.2 would fail for arm?
22:14.21pb_"fail" in what way?
22:14.25RPIt fails on | checking how to run the C preprocessor... arm-linux-gcc -E
22:14.26RP| configure: error: C preprocessor "arm-linux-gcc -E" fails sanity check
22:14.40pb_not that I can think of, but 2.3.2 is way old.
22:14.54RPI know. I need it for various reasons
22:14.58pb_you could check config.log for more clues
22:16.16RPIt looks like its failing to find things like stdio.h :-/
22:17.10RPand/or gcc doesn't like the -qlanglvl=ansi option?
22:17.28RPMaybe I need an older gcc to match? (I'm using 3.4.3)
22:19.56protizecke: Will finish tomorrow. tired and zzz now.
22:19.59protinigh
22:20.38RPActually the above is ok. The error is elsewhere :-/
22:23.19reenoo_'night all
22:30.09*** join/#oe ar_ (~ar@port-ip-213-211-233-149.reverse.mdcc-fun.de)
22:41.29*** join/#oe marcan (1337@85.Red-83-53-2.pooles.rima-tde.net)
22:43.15*** join/#oe hufnus (~slonsiki@mcc3b36d0.tmodns.net)
22:58.39*** part/#oe fyliu (~fyliu@lenert44.ucsd.edu)
23:07.57*** join/#oe fyliu (~fyliu@lenert44.ucsd.edu)
23:11.14RPpb_: 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?
23:12.07pb_RP: add -verbose to the gcc command line to find out where it's searching.
23:19.49fyliubitbake gpe-image is failing at linux-jlime-sh3-2.6.11 for me
23:20.21fyliusaying cc1: error: invalid option 'l'
23:23.23fyliucan someone suggest a hint? looks like it's using the compiled toolchain arm-linux-gcc to compile
23:35.10*** join/#oe JustinP (~papercran@c-67-169-167-134.hsd1.ca.comcast.net)
23:36.58RPfyliu: Are you after a jlime kernel? If not, you probably have MACHINE set incorrectly
23:42.13fyliuI don't know what a jilime kernel is, so I guess I don't need one
23:42.31fyliuI set MACHINE = "h3900"
23:42.57fyliufor h5550
23:45.52fyliuhttp://pastebin.ca/17085

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with blootbot logs, split per channel, etc.