**** BEGIN LOGGING AT Sun May 11 02:59:56 2008 May 11 07:55:35 silly question (never used OE), bitbake is writte in python? May 11 07:55:39 written even May 11 08:30:20 czr, yes May 11 08:30:35 diego71_, thanks May 11 10:20:39 hi steliosk May 11 12:07:23 hello :) May 11 12:07:59 short question (with most likely a long answer) how do I make a full backup of the Windows CE on my SIMpad, so I can later get back to it as it was? May 11 12:09:27 is there some documentation? wherE? May 11 12:15:15 TheCount: this is probably the wrong channel for that question May 11 12:15:31 XorA|gone: okay, where would you recommend asking? :) May 11 12:15:48 #simpad, #angstrom, maybe #familiar May 11 12:16:50 okay, will do :) thanks :) May 11 12:38:23 anyone more familar with "find" than I'm? May 11 12:38:31 I would like to delete dirs that are older than 30 days May 11 12:38:34 whats up? May 11 12:42:35 zecke: I think that should be "find -type d -ctime +30" May 11 12:44:10 pH5: also is there something like -depth 1? May 11 12:45:07 zecke: -maxdepth May 11 12:47:39 thanks May 11 12:57:14 RP: any opinion on putting persist data into the homedir of the user? Or at least allowing this by not using CACHE but a more dedicated var? May 11 13:00:23 03koen 07org.oe.dev * r8e0cee5d... 10/ (1 packages/fftw/benchfft_3.1.bb): benchfft: fixup Makefile so compile gets a bit further. Still tries to run generated binaries, though May 11 13:00:28 03mail 07org.oe.dev * r3cca61a3... 10/ (11 files in 4 dirs): Jaaa: add 0.4.2 + deps. Jaaa (JACK and ALSA Audio Analyser, is an audio signal generator and spectrum analyser designed to make accurate measurements. May 11 13:08:54 RP: around? May 11 13:10:35 zecke: I am now May 11 13:10:54 zecke: That sounds like a reasonable idea May 11 13:16:07 i had a look at git if something like a remote git-rev-list is possible... even with the source it is difficult May 11 13:17:04 zecke: :/ May 11 13:17:50 RP: With the http protocol and rsync you might have a chanche to do so... with the git protocol you don't have this information May 11 13:18:33 zecke: I guess its something we could request from them? May 11 13:18:41 anyone know anything about gforge and why it might be bitching about my public key, which worked perfectly fine yesterday? May 11 13:19:36 RP: yes, but then we would have to wait for upgraded servers? May 11 13:26:32 zecke pasted "allow to place the persistent data into a persistent directory (!= tmp)" at http://paste.lisp.org/display/60582 May 11 13:26:52 RP: ^^^ I would like to push this to trunk and 1.8? May 11 13:27:43 zecke: Looks good to me May 11 13:27:56 and yes, waiting for new servers would be a pain :( May 11 13:31:12 RP: having rev numbers is something where hg and bzr are "better" for our purpose as buildsystem (but doesn't matter when we pick one for our use) May 11 13:31:43 zecke: yes, this is a shortfall with git... May 11 13:31:49 and monotone May 11 13:32:37 hm I have one problem with hg now May 11 13:32:52 I cant check out sepearate file from a revision May 11 13:33:02 like svn can May 11 13:45:51 03zecke123 * r1068 10bitbake/ (ChangeLog lib/bb/persist_data.py): May 11 13:45:51 Allow to store the PersistData in a PERSISTENT_DIR. May 11 13:45:51 If PERSISTENT_DIR is used wiping the tmpdir will not wipe the PersistData May 11 13:45:51 which sometines is wanted (e.g. for git SRCREVs). May 11 13:45:51 Acked-By: Richard May 11 13:48:53 03zecke123 07bitbake-1.8 * r1069 10/ (ChangeLog lib/bb/persist_data.py): May 11 13:48:53 Allow to store the PersistData in a PERSISTENT_DIR. May 11 13:48:53 If PERSISTENT_DIR is used wiping the tmpdir will not wipe the PersistData May 11 13:48:53 which sometines is wanted (e.g. for git SRCREVs). May 11 13:48:53 Acked-By: Richard May 11 14:03:21 hi flo May 11 18:32:38 RP: for git and SRCREV, I will add an option to have a sortable_revision implementation. This will download the code and do the git-rev-list locally May 11 18:33:32 zecke: At recipe parse time? May 11 18:33:36 * RP shudders May 11 18:33:44 Maybe if its optional May 11 18:33:47 * RP -> afk May 11 18:37:08 trash: warum will man auf platten >2TB auch n partionsblock haben? da wuerd ich direkt ne LVM-kennung draufschreiben, ohne alles .. May 11 18:37:22 -EWRONGCHAN - sorry May 11 18:50:12 03koen 07org.oe.dev * rb10c1f37... 10/ (5 files in 2 dirs): gcc: add skeleton for the CSL 2008q1 release of gcc, based on gcc 4.2.3 May 11 19:48:04 zecke_: ping. May 11 19:55:23 pong May 11 19:57:17 zecke_: How should I fix packages that have non-unique .lai files? Xora committed your om test in base.bbclass. May 11 20:19:05 like2wise: check evas-native for an alternative oe_libinstall, we use that one in om May 11 20:19:41 zecke: muchos gracias, I couldn't find .lai files in libtool docs when googling May 11 20:21:20 like2wise: which package is breaking for you? May 11 20:21:32 zecke_: gettext May 11 20:21:50 zecke_: uclibc build for avr32 May 11 20:23:44 zecke_: libgettexpo.lai, libgettextscr.lai are in one dir May 11 20:23:47 like2wise: the alternative oe_libinstall will move to base.bbclass sooner or later May 11 20:24:19 zecke_: ok but gettext is pretty crucial, so I need to make a temporary fix or revert your base check May 11 20:25:01 zecke_: but in order to fix something, I have to understand what .lai files are for. May 11 20:26:21 like2wise: good question, I have no idea. afaik they are in the builddir and used for relinking on installation... kergoth would be the one that knows May 11 20:26:56 like2wise: the code just assumed that the filename.lai is unique, which at least for evas wasn't the case. so the wrong libs got copied to the right paths May 11 20:28:52 zecke_: so we now have a check in OE .dev that nobody knows exactly what it solves but it breaks the builds. I'ld like to back it out, or be able to move forward and fix stuff. I would rather do this in the sideline rather than in .dev. May 11 20:29:22 like2wise: checks don't solve things in general. May 11 20:29:48 zecke_: why not? most of your checks were very sane :-) May 11 20:30:01 like2wise: oe_libinstall is broken. if I have more than one module.lai in my build dir (e.g. with efl every plugin has the same name) May 11 20:30:32 like2wise: oe_libinstall encounters the different module.lai, but is copying _one_ of them to all the paths... May 11 20:32:34 like2wise: so I had image/module.so painter/module.so and then I used autotools_stage_all May 11 20:32:44 like2wise the author of gettext/iconv is pervert May 11 20:32:45 sorry May 11 20:32:59 but he hides under tons of .m4 marcos May 11 20:33:06 like2wise: and OE copied image/module.so to image/module.so and image/module.so to painter/module.so May 11 20:33:35 like2wise I am working on getting gettext 0.17 in oe May 11 20:34:09 but the author linked programs with libs they dont need May 11 20:34:56 ok, I'll backout the check locally and see how gettext behaves for me. May 11 20:35:09 RP: there? May 11 20:35:12 but I assume every dev will run into this sooner or later. May 11 20:35:47 I seem to be one of the few who starts builds from scratch daily. May 11 20:36:07 like2wise: gettext is provided by glibc, not for uclibc though May 11 20:36:27 like2wise: which is decreasing the number of people exposed to it May 11 20:36:28 zecke avr32 hangs on uclibc May 11 20:36:36 woglinde: i know May 11 20:36:43 like2wise: is gettext using autotools? May 11 20:36:48 * woglinde hangs on uclibc too May 11 20:36:51 zecke yes May 11 20:36:54 but its ugly May 11 20:36:58 really ugly May 11 20:37:04 tons of m4 macros May 11 20:37:10 making the wildest stuff May 11 20:37:33 and as I said programms linking against libs they dont need May 11 20:38:04 like2wise: http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=classes/autotools.bbclass;h=054bbfe21ba1187e350fb82eb33705914313e50e;hb=e1a49285deced0efc19dc6af937871a76d6faf20 try this autotools.bbclass May 11 20:43:35 zecke_: trying May 11 20:51:34 zecke: yes, gettext got built ok May 11 20:52:01 zecke: is that a local branch on the git trees? May 11 20:53:20 like2wise: no, this is the Openmoko branch May 11 20:54:08 zecke: the diff of autotools class isn't that big. The -t $to is added to cp, and STAGE_TEMP is used. May 11 20:54:23 zecke: how does that explain why this would work? May 11 20:55:10 like2wise: the cp was just recently fixed in OE May 11 20:55:27 like2wise: -C gets added to the oe_libinstall, so it is finding only one file :) May 11 20:55:51 zecke: and STAGE_TEMP is nowhere to be found in the temp/ scripts... ? May 11 20:56:35 like2wise: STAGE_TEMP is inside autotools.bbclass May 11 20:57:13 zecke: duh. I looked at the context diff, not the full diff... May 11 20:57:24 more coffee, yet again May 11 20:57:44 (not that it helps, but good excuse helps) May 11 20:58:11 like2wise: the issue is: RP and me can only guess why autotools_stage_all didn't do the -C... May 11 20:58:39 hmm, putting SRCREV into PV is completely broken :} May 11 21:05:39 zecke: back now May 11 21:05:55 hi rp May 11 21:06:00 RP: cool. I have been looking into SRCREV and git revisions May 11 21:06:44 RP: if I've a SRCREV inside sane-srcrevs and have PV = "1.0+git${SRCREV}" this is resulting in non upgradable packages? May 11 21:07:27 RP: I see that AUTOREV is the only one calling get_srcrev... May 11 21:08:19 zecke: -C was already there in my original autotools.bbclass, but the STAGE_TEMP was not used in oe_libinstall. May 11 21:08:39 like2wise: ah okay May 11 21:09:14 RP: even for normal rev's we would want to run it trough sortable_revision... May 11 21:09:26 RP: can you follow? am I wrong? May 11 21:10:12 zecke: Yes, that is a bug :/ May 11 21:10:56 zecke: When locking down SRCREV I've sometimes overridden PV to deal with that May 11 21:11:25 zecke: See conf/distro/poky.conf, grep for libxcalibrate May 11 21:11:41 RP: well, I think the fix would be easy... May 11 21:11:52 zecke: Patches welcome :) May 11 21:12:19 I got so far with it all and then got a headache. Someday I will revisit it... May 11 21:12:41 RP: I will sleep and dream about it May 11 21:12:54 I think we need something to scrape revs from PV? May 11 21:13:32 Last time I tried that I ended up with a massive headache as well as a solution ;-) May 11 21:14:30 hi woglinde May 11 21:14:41 woglinde: I've also tried to deal with gettext 0.17, its painful May 11 21:14:55 woglinde: There are recipes in poky but they don't work May 11 21:29:06 * * OE Bug 4245 has been created by likewise(AT)gmx.net May 11 21:29:08 * * gettext does not pass unique '.lai' files test in base.bbclass. May 11 21:29:10 * * http://bugs.openembedded.net/show_bug.cgi?id=4245 May 11 21:31:05 * * OE Bug 4245 has been RESOLVED (FIXED) by likewise(AT)gmx.net May 11 21:31:07 * * gettext does not pass unique '.lai' files test in base.bbclass. May 11 21:31:09 * * http://bugs.openembedded.net/show_bug.cgi?id=4245 May 11 21:41:12 rp hm they are not in the officel trunk May 11 21:43:18 03koen 07org.oe.dev * rb0651d74... 10/ (8 files in 3 dirs): gcc csl 2008q1: add some OE sanity patches and fix EXTRA_OECONF May 11 21:49:35 woglinde: Sorry, I didn't commit them, I thought I had :( May 11 21:50:08 woglinde: There wasn't much interesting there other than some aclocal lines making sure all the m4 directories were included May 11 21:51:23 woglinde: http://www.rpsys.net/openzaurus/gettext/ May 11 22:06:35 hi everybody May 11 22:06:47 hi thesing May 11 22:09:04 uh... no... May 11 22:09:56 RP: any reason you didn't use git-archive to create the tar.gz? May 11 22:10:12 zecke: It didn't exist when I wrote the fetcher? May 11 22:10:38 * RP doesn't think it existed in git 1.3 May 11 22:11:23 did tar-tree exist? May 11 22:11:33 I don't remember... May 11 22:12:05 I freely admit that fetcher needs rewriting, it was written to fetch kernel trees for my personal use and wasn't designed for the use it gets now ;-) May 11 22:12:24 git has a lot better commands for some of the insane things it does... May 11 22:12:28 (now) May 11 22:12:40 the 3rd line of the git fetcher method go is fun... May 11 22:13:30 zecke: The skipping checkout one? May 11 22:15:12 yes, this leads to downloading a new 60mb tar.gz instead of git-fetching the other 300kb :) May 11 22:16:04 If a checkout already exists, that code could be more optimal ;-) May 11 22:21:26 zecke: The principle was to load the mirrors, not the main server May 11 22:23:50 zecke pasted "only check the presence, do not load the stuff yet" at http://paste.lisp.org/display/60607 May 11 22:24:37 RP: your code will fetch the mirror afterwards anyway.. or git-clone May 11 22:25:22 zecke: Two different things - one is a checked out tarball, the other is a copy of the git repo May 11 22:25:58 wow, two errors in that one line already :) May 11 22:26:20 ? May 11 22:26:33 RP: in my patch, missing colon and Dl_DIR vs. DL_DIR May 11 22:26:46 RP: sure, the difference is that one is a repo the other is a checkout May 11 22:30:31 Fetching checkedout revisions from the server is a sane thing to do... May 11 22:31:34 RP: not always, specially not if I have a repository already and just miss 3 revs May 11 22:31:45 RP: and when using GPRS... May 11 22:31:57 RP: fetching a new checkout 4 days, fetching 3 revs, 3 minutes May 11 22:32:14 zecke: I agree not always. its just not 100% "wrong" either May 11 22:35:44 RP: it is always wrong when I have a repository already. but this is from the "crappy internet point of view". :) May 11 22:35:47 and I need to sleep now May 11 22:36:14 zecke: another time then ;-) May 11 22:36:17 zecke: 'night! May 12 00:16:38 03likewise 07org.oe.dev * r4b02add2... 10/ (1 classes/autotools.bbclass): autotools.bbclass: from OM. Needed as commit 85a5e185b6a21e42e4243ad17befe40373025e0e alone will break uclibc/gettext builds. May 12 00:16:42 03likewise 07org.oe.dev * r28f2be15... 10/ (1 packages/gnash/gnash-minimal.inc): gnash-minimal: Fix building for uclibc by working around faulty argz.h test for uclibc, using _GNU_SOURCE. **** ENDING LOGGING AT Mon May 12 02:59:57 2008