**** BEGIN LOGGING AT Mon Oct 13 02:59:57 2008 Oct 13 07:27:12 morning Oct 13 08:12:07 yo Oct 13 08:16:35 good mornin' Oct 13 08:19:40 hrw: ping Oct 13 08:22:43 png Oct 13 08:25:15 hello Oct 13 08:25:47 I'd need some suggestions about defconfigs / ext3 Oct 13 08:26:04 I attached some on oebug 4688 Oct 13 08:26:29 but probably 2 lines are enough: Oct 13 08:26:35 +CONFIG_EXT3_FS=y Oct 13 08:26:36 +CONFIG_JBD=y Oct 13 08:27:19 I suppose CONFIG_EXT3_FS_XATTR would be overkill for small devices... Oct 13 08:27:56 maybe Oct 13 08:29:01 Siide question: a lot of patching is done including linux.inc (localversion, logo...). Should I strip it from my patches? Oct 13 08:29:31 The relations linux-rp, linux-kexecboot and the magic of linux.inc are a bit confusing... Oct 13 08:32:31 brb Oct 13 08:37:54 morning all Oct 13 09:25:54 03  07org.openembedded.dev * r75bbe51964 10org.openembedded.dev.git/contrib/mtn2git/ (mtn2cache.py mtn2git.py): Oct 13 09:25:54 mtn2git: fix bugs in conversion script Oct 13 09:25:54 also add mtn2cache.py which extracts some information from the DB (caution ~40GiB) Oct 13 10:01:26 hi Oct 13 10:03:22 hm.. running into a problem with a self-build .bb package .. ERROR: log data follows (/home/gilligan/projects/oedev/x86_test/tmp/work/i486-angstrom-linux/rsh-redone-1.1-r0/temp/log.staging_helper.20262) Oct 13 10:03:22 | /home/gilligan/projects/oedev/x86_test/tmp/work/i486-angstrom-linux/rsh-redone-1.1-r0/temp/run.staging_helper.20262: line 752: syntax error: unexpected end of file Oct 13 10:04:51 http://pastebin.com/m2a3c5953 <-- that is my .bb file Oct 13 10:05:07 maybe someone could have a glance at it and tell me if there is something obviously wrong? Oct 13 10:08:11 don't understand why it reports an unexpected end of file.. can't see any unterminated quotes or anything like that Oct 13 10:09:16 where it says anything about your bb file? :) Oct 13 10:09:23 it's run.staging_helper.20262: line 752 Oct 13 10:12:53 eh.. THAT much i spotted myself :0 Oct 13 10:12:56 :) Oct 13 10:13:10 750 cd /home/gilligan/projects/oedev/x86_test/tmp/staging Oct 13 10:13:10 751 staging_helper Oct 13 10:13:30 that doesn't look obviously faulty Oct 13 10:14:17 hence i'm a bit clueless as to where to search for the problem Oct 13 10:19:42 yo Oct 13 10:20:11 hi mickeyl Oct 13 10:21:16 * mickeyl back in cold .de Oct 13 10:21:28 mickeyl: welcome back Oct 13 10:21:32 thanks :) Oct 13 10:22:10 so, renewed my "contract" w/ Openmoko and will continue w/ these guys for next year Oct 13 10:22:26 very good :-) Oct 13 10:22:56 yeah Oct 13 10:23:10 got some more freedom negotiated :) Oct 13 10:23:20 mickeyl, could I bug you about a problem i'm having here? :) Oct 13 10:23:30 gilligan_: sure, what's wrong? Oct 13 10:23:30 mickeyl, maybe you have some ingenious suggestions for me hehe Oct 13 10:23:58 mickeyl, http://pastebin.com/m2a3c5953 put together that small package .. Oct 13 10:24:17 simple enough .. Oct 13 10:24:20 however Oct 13 10:24:24 | /home/gilligan/projects/oedev/x86_test/tmp/work/i486-angstrom-linux/rsh-redone-1.1-r0/temp/run.staging_helper.20819: line 753: syntax error: unexpected end of file Oct 13 10:24:24 NOTE: Task failed: /home/gilligan/projects/oedev/x86_test/tmp/work/i486-angstrom-linux/rsh-redone-1.1-r0/temp/log.staging_helper.20819 Oct 13 10:24:24 NOTE: package rsh-redone-1.1-r0: task do_setscene: failed Oct 13 10:24:24 ERROR: TaskFailed event exception, aborting Oct 13 10:24:39 the reported file ends with .. Oct 13 10:24:45 750 cd /home/gilligan/projects/oedev/x86_test/tmp/staging Oct 13 10:24:53 751 staging_helper Oct 13 10:25:01 (numbers of course are line numbers from vim hehe) Oct 13 10:25:14 mickeyl: I also just "returned" to .de. Oct 13 10:25:20 likewise: welcome :) Oct 13 10:25:28 gilligan_: ok, that file looks good Oct 13 10:25:29 mickeyl: congrats on more freedom + more days Oct 13 10:25:29 mickeyl, I can't spot any obvious missing terminating strings or something like that in the file - so now I am somewhat lost Oct 13 10:25:30 let me try here Oct 13 10:25:46 mickeyl: following the Qt dev days stuff in Munich. Oct 13 10:26:55 gilligan_: staging_helper looks more like somthing in OE being broken Oct 13 10:27:15 did you rm -rf after the TMP ABI changes? Oct 13 10:27:34 because otherwise your .bb looks fine to me Oct 13 10:27:45 likewise: ah, interesting. Will be in Munich next week for SYSTEMS Oct 13 10:27:49 ~curse intelfb badly Oct 13 10:27:50 May the fleas of a thousand camels infest your most sensitive regions, intelfb badly ! Oct 13 10:28:12 mickeyl, i built an angstrom image in that environment and everything went smoothly .. just this package fails Oct 13 10:28:25 oh Oct 13 10:28:28 wow, that's strange Oct 13 10:28:40 can you check whether you have invisible invalid characters in there? Oct 13 10:28:51 like, are the " real "? Oct 13 10:29:04 aaah Oct 13 10:29:04 that is massively unlikely since i only ever work under linux/vim Oct 13 10:29:06 found it! Oct 13 10:29:07 hehe Oct 13 10:29:09 you have a typo Oct 13 10:29:12 ${WORKDIR] Oct 13 10:29:12 arrrgh Oct 13 10:29:14 instead of Oct 13 10:29:17 ${WORKDIR} Oct 13 10:29:18 :)) Oct 13 10:29:23 hehe Oct 13 10:29:31 hahaha Oct 13 10:29:36 * gilligan_ slaps his forehead Oct 13 10:29:39 sorry for the insane error Oct 13 10:29:41 :) Oct 13 10:29:47 s/error/message/ Oct 13 10:29:51 ;--] Oct 13 10:30:13 i kept on looking at that file thinking.. huh.. that looks just fine doesn't it hehe Oct 13 10:30:33 mickeyl, oh also another thing I wanted to mention.. Oct 13 10:30:47 ya? Oct 13 10:30:49 ah btw. Oct 13 10:30:53 i have some style comments Oct 13 10:30:56 wanna hear? Oct 13 10:31:22 mickeyl, sure.. shoot.. this package is plain ugly and made in a rush.. but do let me know nonetheless Oct 13 10:31:40 use, $(MAKE), not make. do not use absolute paths in $FILES Oct 13 10:31:51 mickeyl, ah alright Oct 13 10:32:01 rest looks good Oct 13 10:32:05 hey z! Oct 13 10:32:09 welcome in .de Oct 13 10:32:12 moin Oct 13 10:32:29 * zecke sits at the university and is bored... Oct 13 10:32:33 hehe Oct 13 10:32:42 I want to finish that damn thing :( Oct 13 10:33:29 mickeyl, I took a long break from any OE activity at work (other projects) .. I updated my OE repo and it took me pretty long to figure out that my bitbake as was too old. There is indeed a sanity check which at some stage reports that bitbake is too old .. problem is I never even got that far and got a totally cryptic error message instead hehe Oct 13 10:33:31 zecke: how many years/months ? Oct 13 10:33:51 likewise: close to infinite, maybe infinite-1 Oct 13 10:34:11 gilligan_: uh, nasty. do you have a log of that incident? Oct 13 10:34:20 zecke: I spent almost half my life at uni, and I'm 34 now. go figure.... Oct 13 10:34:59 mickeyl, that's what's going through my mind right now.. hmm.. are there irc logs somewhere ? Oct 13 10:35:30 * likewise lunchbreaks Oct 13 10:35:46 gilligan_: ya, let me check Oct 13 10:35:50 ~logs Oct 13 10:35:51 All conversations are logged to http://ibot.rikers.org/channel, where "channel" is replaced by the URL-encoded channel name, such as %23freenode for #freenode. Lines starting with spaces are not logged. Oct 13 10:35:56 here we are Oct 13 10:36:18 ah Oct 13 10:36:43 mickeyl, actually I am pretty sure that I had to comment out "export PATH" at line 336 in conf/bitbake.conf Oct 13 10:36:48 mickeyl, please don't ask me why :) Oct 13 10:36:58 oh yes Oct 13 10:37:05 mickeyl, it was reporting a syntax error otherwise Oct 13 10:37:07 export 'foo' is legal syntax only since 1.8.something Oct 13 10:37:12 previously only Oct 13 10:37:16 export foo=bar was legal Oct 13 10:37:22 ah, okay Oct 13 10:37:35 so we had to use export FOO := ${FOO} Oct 13 10:37:45 which is now better expressed as export FOO Oct 13 10:37:50 mickeyl, so I was stuck at "export PATH" ... syntax error.. somewhat bewildering hehe Oct 13 10:37:56 agreed Oct 13 10:38:09 our problem is we can only access the metadata after a successul parse Oct 13 10:38:09 after that I got through to the sanity check and figured that my bitbake was out of date Oct 13 10:38:14 hm yeah Oct 13 10:38:20 we should improve that though Oct 13 10:38:32 can you open a bug against bitbake for that so we do better in the future? Oct 13 10:38:43 sure, will do Oct 13 10:38:46 thanks Oct 13 10:39:01 Hey Oct 13 10:39:37 maybe the conf file could actually contain some version info that bitbake could check against easily? i don't know about any of the internals, so maybe this idea sucks :) Oct 13 10:40:22 say as header/part of a comments block or so Oct 13 10:41:13 yah, that should be possible Oct 13 10:41:14 Did anyone attempt to upgrade xorg stuff recently? Oct 13 10:41:26 config abi version or smth Oct 13 10:41:27 I could deserve a inputproto 1.4.4 and, GL and glproto Oct 13 10:41:38 by now i'd also like to reconsider whether we should not maintain bitbake in the OE repository Oct 13 10:42:42 not in the same repository Oct 13 10:46:02 gotta go Oct 13 10:46:06 cu gilligan_ Oct 13 10:46:10 mickeyl, thanks again for spotting my silly typo :)) Oct 13 10:46:13 np :) Oct 13 10:46:17 laters Oct 13 10:47:28 ~curse intelfb badly Oct 13 10:47:29 May the fleas of a thousand camels infest your most sensitive regions, intelfb badly ! Oct 13 10:48:24 good morning Oct 13 10:49:30 florian: good morning Oct 13 10:49:39 yo florian Oct 13 10:59:53 zecke: You wanted to talk to me yesteday? Did you read my mail in bitbake-dev? Oct 13 11:00:23 alphaone: did you read my response? Oct 13 11:08:00 anyone wants to test Xglamo based on xorg 1.5? Oct 13 11:20:04 zecke: As a matter of fact no. Oct 13 11:20:10 Where did you send it to? Oct 13 11:20:42 alphaone: somewhere.... you stumble across an issue that is known for ~4 month, and two patches has been sent to the ml for review ;) Oct 13 11:20:58 zecke: Heh, so why isn't it fixed? Oct 13 11:21:14 alphaone: no one in the OE community reviewed it... :) Oct 13 11:21:26 brb Oct 13 11:21:41 I pushed some unreviewed changes yesterday... Oct 13 11:21:46 Wow, this just makes me so happy right now Oct 13 11:21:47 Hmm Oct 13 11:22:01 zecke: I saw, but they don't seem to fix this issue Oct 13 11:23:05 zecke: re known problem sorry, but I assumed that if it had been known it would have already been fixed. Oct 13 11:23:16 Doesn't look too complicated IMHO Oct 13 11:23:39 Maybe I should shut up for a while. The jetlag makes me grumpy Oct 13 11:24:41 alphaone: do you have a clash with PN? Oct 13 11:25:01 alphaone: your patch adds branch to the key, I added PN, this works nicely in OM's metadata Oct 13 11:25:21 alphaone: okay, my battery will be gone soon :) Oct 13 11:26:34 zecke: sounds good to test, Im up for it Oct 13 11:26:57 zecke: Xglamo that is Oct 13 11:27:23 XorA: master-1.5 branch, you need to update updateproto and put --disable-glx into the oeconf Oct 13 11:27:35 zecke: excellent I shall go poke now Oct 13 11:55:48 re Oct 13 11:58:01 mickeyl, thanks for addings the pythin symbol, I also had to add pkgutil Oct 13 12:00:50 zecke: You added the PN thing to sortable_revision, but I encountered the problem in latest_revision Oct 13 12:01:12 So I think you need to add PN there as well? Oct 13 12:01:31 I can't claim I understand the code completely.. Oct 13 12:06:04 Crofton|work: seen it, cool. welcome on co-maintaining python in OE :) Oct 13 12:06:16 grrrr Oct 13 12:06:29 I should have waityed for you to land ... Oct 13 12:06:31 alphaone: let me take a look Oct 13 12:06:36 now everyone will bother me Oct 13 12:06:44 zecke: thankd Oct 13 12:06:59 * Genesis bought Palm Tungsten E that is not longer support by us :) Oct 13 12:07:02 zecke, I assume you want a patch from me so you have a real email address for me? Oct 13 12:07:18 alphaone: I assume as we have not many people capable of doing formating changes in a wiki we might have an overflow of python developers now? Oct 13 12:07:42 Crofton|work: I don't mind too much, crofton@unknown.openembedded.org is okay for me :) Oct 13 12:07:45 about that ... ttp://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi could be cool Oct 13 12:07:58 zecke: ? Oct 13 12:07:58 what is the point of having a real email address? Oct 13 12:08:47 hi Oct 13 12:08:51 yop woglinde Oct 13 12:10:46 hi genesis Oct 13 12:17:01 hey woglinde Oct 13 12:17:40 woglinde, you did the e2fsprog commit? I'm experiencing a build error: http://tinderbox.openembedded.net/public/logs/1464289.txt Could you fix that? Oct 13 12:24:08 XorA: would you please fix the merge? Oct 13 12:24:10 git-grep "^PV" packages/ | grep "svn\\$" | grep SRCREV Oct 13 12:24:12 is not zero :) Oct 13 12:24:34 git-grep "^PV" packages/ | grep "git\\$" | grep SRCREV Oct 13 12:24:52 could you please fix it ASAP? Oct 13 12:25:22 zecke: curses, they keep sneaking in, will do it now Oct 13 12:25:31 I count 3, same for you? Oct 13 12:25:38 4 Oct 13 12:26:16 XorA: I will send a grumpy mail :) Oct 13 12:26:42 XorA: ~7 in total, SRCREV => SRCPV, and please add the 'r' and bump the PE :) Oct 13 12:26:57 XorA: for extra points to the last two things upstream, and the SRCREV => SRCPV in our tree :} Oct 13 12:27:04 zecke: ok, send the grumpy mail and Ill fix Oct 13 12:27:50 forgot to do the SRCREV->SRCPV bit after merge, I normally check for that Oct 13 12:28:02 must remember not to finish merges at 23:30 Oct 13 12:28:30 :) Oct 13 12:28:37 thanks Oct 13 12:28:55 I hope we manage to switch to git on wednesday Oct 13 12:30:16 here we made the switch :) Oct 13 12:33:33 lumddu, Oct 13 12:35:39 woglinde: nice pass Oct 13 12:37:35 woglinde, what about e2fsprogs? If you haven't got time atm, no prob...just like to be informed :) Oct 13 12:43:25 XorA: https://docs.openmoko.org/trac/ticket/2070 is also really interesting... sometimes it forgets that it knows the Qtopia libs... Oct 13 12:43:55 quickdev? Oct 13 12:44:00 e2fsprogs is fixed Oct 13 12:44:25 or did you mean with uclibc-minimal? Oct 13 12:44:43 this I will fix this evening and setting the right compiler autools version Oct 13 12:47:02 woglinde, is this fixed? http://tinderbox.openembedded.net/public/logs/1464323.txt I doubt.. Oct 13 12:47:11 zecke: yes, I saw that one, confuses me Oct 13 12:48:17 XorA: no idea when I have time, but we should check that we run ldconfig as postinst Oct 13 12:48:35 quickdev in oe gettext-0.17 is the default Oct 13 12:48:36 zecke: Ill add that to a postit here Oct 13 12:48:38 XorA: or we might run it before /etc/ld.so.conf.d/* was popoulated Oct 13 12:48:43 and gettext-0.17 has the macro Oct 13 12:48:57 XorA: I pushed a bandaid and put LD_LIBRARY_PATH back Oct 13 12:49:22 bitbake -c clean e2fsprogs && bitbake-clean gettext-native && bitbake e2fsprogs Oct 13 12:50:00 hello everyone Oct 13 12:51:19 alphaone: thanks, I will push another fix your bitbake issue Oct 13 12:51:41 Xora> did you happen by any chance to have time to look at the libxml-perl-native package problem ? Oct 13 12:52:19 zecke: great, thanks Oct 13 12:52:21 Longfield: no Oct 13 12:55:11 03zecke123 07bitbake-1.8 * r1107 10/lib/bb/fetch/__init__.py: Oct 13 12:55:11 [fetch] Always add PN to the _revision_key we get from the fetcher Oct 13 12:55:11 This is extending r1101 to always append something to the Oct 13 12:55:11 _revision_key of the fetcher. alphaone spotted that it was missing Oct 13 12:55:11 for the latest_revision case. Oct 13 12:55:16 alphaone: could you test that? Oct 13 12:56:10 03zecke123 * r1108 10bitbake/lib/bb/fetch/__init__.py: Oct 13 12:56:10 [fetch] Always add PN to the _revision_key we get from the fetcher Oct 13 12:56:10 This is extending r1101 to always append something to the Oct 13 12:56:10 _revision_key of the fetcher. alphaone spotted that it was missing Oct 13 12:56:10 for the latest_revision case. Oct 13 12:57:35 XorA: I will change inputproto to 1.4.4 Oct 13 12:57:40 zecke: Will do that now Oct 13 12:58:48 pyflakes even saved my ass :) Oct 13 12:59:13 zecke: Though there could still be a problem if different versions of a recipe use different branches. Oct 13 12:59:34 Don't know if we want to have that or not Oct 13 13:03:57 woglinde, if i wouldn't have talked to you..how could I know that I have to clean gettext-native? :) Oct 13 13:05:19 woglinde: didn't you bump the PR? Oct 13 13:06:42 zecke on gettext? Oct 13 13:06:50 long ago Oct 13 13:07:19 03  07org.openembedded.dreambox * r520222ad03 10org.openembedded.dev.git/packages/dreambox/dreambox-dvb-modules.bb: dreambox-dvb-modules: add fpupgrade for dm8000 Oct 13 13:07:22 03  07org.openembedded.dreambox * r67e9802ae4 10org.openembedded.dev.git/packages/initscripts/ (2 files in 2 dirs): initscripts-opendreambox: insert bcm7400 module for dm8000 due to changed dependencies Oct 13 13:07:23 03  07org.openembedded.dreambox * rfd0afa321e 10org.openembedded.dev.git/packages/enigma2/enigma2.bb: enigma2: update, add dependencies for subtitle display Oct 13 13:07:32 pb_: got a second? Oct 13 13:07:35 tmbinc: ping Oct 13 13:07:37 woglinde, if you would have upgraded the package revision, the thing would have been cleaned, wouldn't it? Oct 13 13:08:01 quickdev sure do not know what went false in your way Oct 13 13:08:23 I have the same problem Oct 13 13:08:32 tmbinc hm Oct 13 13:08:36 even with clean&rebuild of both gettext-0.17 and e2fsprogs Oct 13 13:08:40 d Oct 13 13:08:44 zecke: cool Oct 13 13:08:52 tmbinc oh I thought you say it is fixed Oct 13 13:08:55 hey zecke Oct 13 13:09:09 tmbinc sorry gettext-native has to be 0.17 Oct 13 13:09:18 wss too late yesterday Oct 13 13:09:26 and I got puzzeld Oct 13 13:09:30 woglinde, no, sorry. I noticed that I didn't cleaned before. Oct 13 13:09:33 tmbinc: you are aware of the git change? Oct 13 13:09:37 but cleaning didn't help Oct 13 13:10:07 zecke: yes. i finally merged again, btw, and I'm preparing this new tree in git already. Oct 13 13:10:17 zecke: when will be the final switch? Oct 13 13:10:22 i.e. the mtn server shutdown? Oct 13 13:10:29 tmbinc: mtn on thursday Oct 13 13:10:48 tmbinc: git on wednesday, you must git-rebase then Oct 13 13:11:25 zecke: at your service Oct 13 13:11:41 pb__: how much do you know about x.org processes? Oct 13 13:11:51 pb__: I would like to merge OM's xserver upstream Oct 13 13:12:16 woglinde, "tmbinc sorry gettext-native has to be 0.17" - so there's a wrong version atm and there will be a fix soon? :) Oct 13 13:12:16 zecke: I don't know a great deal about them I'm afraid. I guess you should ask keithp or one of the other X-Men. Oct 13 13:12:27 #freedesktop would be your resource for that, I suppose Oct 13 13:12:44 pb__: portland time is -9h? Oct 13 13:12:55 for you, yes Oct 13 13:12:56 quickdev no Oct 13 13:13:15 quickdev it can happen that somehow you are using old gettext-0.14.1 stuff in there Oct 13 13:13:19 woglinde: i'm confused, too. What do I have to do to "make this work"? clean-rebuild gettext-native? Oct 13 13:13:28 pb__: okay, I will give him some time to wake up Oct 13 13:13:44 tmbinc hm be sure all gettext-native 0.14.1 stuff is out Oct 13 13:13:55 pb__: actually... Oct 13 13:14:22 and then build gettext-0.17 Oct 13 13:14:49 and clean-rebuild gettext should do this Oct 13 13:15:14 woglinde, thanks for the hint Oct 13 13:16:15 quickdev if this fix it not Oct 13 13:16:26 It seems I have made mistake somewhere Oct 13 13:16:39 we'll see, thanks in advance Oct 13 13:36:18 woglinde: it doesn't seem to help. Oct 13 13:36:32 i rebuilt gettext-native Oct 13 13:41:34 tmbinc, which version of gettext-native? Oct 13 13:50:26 quickdev: -0.17-r2 Oct 13 13:50:46 and gettext? Oct 13 13:52:57 03  07org.openembedded.dev * r3810e0992a 10org.openembedded.dev.git/conf/distro/include/preferred-om-2008-versions.inc: preferred-om-2008-versions.inc: bump gettext Oct 13 13:58:48 tmbinc hm Oct 13 14:00:29 args Oct 13 14:00:43 seems this macro is comming from automake Oct 13 14:01:03 *sigh* Oct 13 14:01:09 sometimes I can not read Oct 13 14:01:23 tmbinc which automake version you are using? Oct 13 14:06:29 from #beagle, new way to break OE: Ahhh found my problem with "as" and the "-Qy" option...: Don't use "." in your path ;-) Oct 13 14:12:04 eeks Oct 13 14:15:10 hi everybody Oct 13 14:15:55 i have a question about our dreambox-image.bb where i added a function to create .nfo file together with the image Oct 13 14:16:08 i added a task after do_rootfs before do_build Oct 13 14:16:11 mickeyl, someone should doble check Oct 13 14:16:25 if proven we could add a check to snity Oct 13 14:16:26 but it doesn't get called when doing bitbake dreambox-image unless the do_nfo stamp was deleted Oct 13 14:16:35 adding . to your path is crazy :) Oct 13 14:25:19 crofton do you have an idea how i could do that? Oct 13 14:48:13 e2fsprogs still doesn't work with gettext 0.17 :( Oct 13 14:48:44 But I'm going to commit a horrible hack, because I really *must* get the SlugOS feeds re-populated before we freeze things for the git transition. Oct 13 14:49:04 (They haven't successfully rebuilt since before the last ABI change) Oct 13 14:49:11 mwester: sounds like we need to disapprove that then Oct 13 14:49:20 * mickeyl runs a testbuild atm. Oct 13 14:49:55 mickeyl: I think the fault is that SlugOS has fallen very far behind in some packages, such as toolchain and autoconf, etc. Oct 13 14:50:23 It's on my list, and now is on the top of it. I need to get the feeds built just once, then freeze them, and move to EABI -- finally! Oct 13 14:50:52 *nod* Oct 13 14:51:01 then again, changes in critical packages should be rather tested on more archs Oct 13 14:51:17 s/critical/everything that is among task-boot or so/ Oct 13 14:52:17 mwester sorry I didnt read carefully the macro is comming from automake Oct 13 14:52:53 woglinde: That's what I guessed last night, and it is SlugOS that is at fault for being so far behind on automake. Oct 13 14:53:17 So I'll just commit the hack, build the feeds, and fix SlugOS instead. :) Oct 13 14:53:28 (and remove the hack, of course) Oct 13 14:54:31 woglinde: 1.9.3-r5 Oct 13 14:56:05 tmbinc could you update to automake-1.10 Oct 13 14:57:56 hm we have to find a policy on autotools Oct 13 14:58:20 it is pain to support the different version Oct 13 14:59:05 woglinde: autotool version selection, just like any other version choice, is basically a DISTRO decision. Oct 13 14:59:23 I don't think it would make any sense to try to make a one-size-fits-all policy for that. Oct 13 15:00:06 pb okay then try to think how we can solve the problem with e2fs-programs Oct 13 15:00:15 what exactly is the problem? Oct 13 15:00:39 MKINSTALLDIR vs. MK_DIR_P macro Oct 13 15:01:17 MKINSTALLDIR is only in < 1.10 Oct 13 15:01:26 MK_DIR_P is in >= 1.10 Oct 13 15:01:54 of automake, you mean? Oct 13 15:02:02 right Oct 13 15:02:57 I guess this sort of thing kind of illustrates what I was saying yesterday about not wanting to just blindly upgrade. it is a bit of a shame that the automake people have this tendency to break backwards compatibility like that. Oct 13 15:03:12 my immediate reaction is that the right fix is to patch newer versions of automake to reinstate the removed macro. Oct 13 15:03:21 hm Oct 13 15:03:26 mom Oct 13 15:04:27 bye Oct 13 15:04:28 okay Oct 13 15:04:33 alternatively, with a bit of fiddling around in staging, you could arrange for multiple versions of automake to be parallel installable. Oct 13 15:04:36 they have no fall back Oct 13 15:04:47 that's basically what debian does; you can invoke "automake1.10" or whatever if you want to use that version. Oct 13 15:04:55 so it's not my fault to find the fallback Oct 13 15:05:18 hm yes Oct 13 15:05:25 in that case, obviously, e2fsprogs could use the newer automake without disturbing other packages. Oct 13 15:05:43 or the older one, whichever it wants Oct 13 15:06:38 but, as long as this sort of incompatible change is being introduced in automake, I think any attempt to enforce a single automake version across everything is basically doomed. you could do it within a DISTRO, if you were sufficiently determined, but across all distros is almost certainly impossible. Oct 13 15:06:44 hm Oct 13 15:06:57 pb yes you are right Oct 13 15:08:57 hms its my fault Oct 13 15:09:07 after readin the macro Oct 13 15:09:11 shame on me Oct 13 15:10:10 * mwester would be satisfied if we could just have a medatdata syntax that would emit a warning or error during parsing -- so that one might be able to mark dependencies: ERROR_REQUIRED_PACKAGE_VERSION_automake = "> 1.10" Oct 13 15:10:57 That would make it very clear when a problem is the distro (as pb__ notes), or when the problem might be otherwise fixed. Oct 13 15:11:58 there is such hack every where in the code ... i hope we'll be able to maintain it after years Oct 13 15:14:46 mwester: yeah, that's not a bad idea. Oct 13 15:15:06 way back when, we did have a theory that you could write 'automake (>= 1.10)' or so in DEPENDS, but I don't think that ever actually worked. Oct 13 15:15:24 iirc, right now you can write that and the parser won't complain, but it doesn't actually do anything with the version information. Oct 13 15:16:17 it would be fairly straightforward to enhance something like sanity.bbclass to check that the versions were actually satisfied at build time; you wouldn't need to touch the bb core for that. Oct 13 15:19:01 That's a good idea. Oct 13 15:19:32 And actually makes a lot of sense to put it into sanity.bbclass. Oct 13 15:20:03 Hmm... one could also use that same mechanism to deal with the libusb* conflicts that I encountered some weeks ago. Oct 13 15:22:04 woglinde: ok, automake-native-1.10 fixes it Oct 13 15:27:09 tmbinc but its my fault Oct 13 15:27:16 older autotools Oct 13 15:27:50 uses mkdir_p Oct 13 15:28:03 and on that they support upgrad path Oct 13 15:28:13 I will fix this evening Oct 13 15:37:52 03  07org.openembedded.dreambox * r9fba7245e1 10org.openembedded.dev.git/packages/images/dreambox-image.bb: dreambox-image: fix .nfo creation Oct 13 16:56:39 RP: ping Oct 13 17:04:48 ah Oct 13 17:04:51 zecke Oct 13 17:05:20 is there a littel c helper function which comapres the last 5 chars of a string Oct 13 17:06:01 memcmp? Oct 13 17:06:09 hm Oct 13 17:06:38 strncmp Oct 13 17:06:56 woglinde: check if the string has at least 5 chars (strlen) Oct 13 17:07:05 hm no strncmp needed the string reverse Oct 13 17:07:13 no Oct 13 17:07:21 I the string can have variable size Oct 13 17:07:42 and I only need the last the 5 chars to compare Oct 13 17:07:57 hm put the string in char array Oct 13 17:08:15 woglinde: nah Oct 13 17:08:25 woglinde: string is just an array... imagine you have 10 chars Oct 13 17:08:31 woglinde: you want to compare the last five Oct 13 17:08:48 right Oct 13 17:08:54 woglinde: strncmp(str+5, "12345", sizeof "12345"); Oct 13 17:09:05 ah right Oct 13 17:09:14 pointer got me again Oct 13 17:12:09 woglinde: now telematik and lak1 overlap... :} Oct 13 17:14:09 hm then strncmp(cliargv[0]+(sizeof(cliargv[0]) - sizeof("moo") -1), "nxagent", sizeof("moo") == 0) should be okay Oct 13 17:22:52 zecke: g_str_has_suffix() is what you need :-) Oct 13 17:24:19 woglinde: ah right, use glib, you might link to it anyway :) Oct 13 17:24:43 hm sorry glib is not an option here Oct 13 17:25:14 woglinde: make sure that cliargv[0] is big enough :) Oct 13 17:25:28 woglinde: or I will tell fefe and then you will be too ashamed to read his blog :) Oct 13 17:25:37 zecke hm Oct 13 17:25:53 your are right Oct 13 17:26:09 a malious user can change the name of the programm Oct 13 17:26:10 also, for what it's worth, you don't need to use strncmp() and worry about the second call to sizeof(). if you are comparing the end of the string then you can use strcmp() and rely on the null terminator. Oct 13 17:26:38 thanks Oct 13 17:27:14 but yes, you can't rely on the name of the program having any particular length. It might even be executed with argv[0] being the empty string. Oct 13 17:27:33 in theory I suppose argv[0] might not even exist if argc==0. Oct 13 17:28:28 hm does c lazy evaluation? Oct 13 17:28:37 no Oct 13 17:28:54 woglinde: it is like haskell, it even has pattern matching Oct 13 17:28:56 hm than I could use ther && op Oct 13 17:29:08 right? Oct 13 17:29:23 er, I'm not quite sure I understand what you mean. Oct 13 17:29:27 where do you want to use &&? Oct 13 17:29:43 pb first test the sizeof arg[0] Oct 13 17:29:47 hms Oct 13 17:30:06 oh, right. Oct 13 17:30:14 (sizeof(arg[0]) >= sizeof (moo)) && bllala Oct 13 17:30:24 yes, && is a short-circuiting operator. if you have a && b, and a is false, b will not be evaluated at all. Oct 13 17:30:34 thanks Oct 13 17:30:37 so, it is safe to write "if (a != NULL && *a ...)" Oct 13 17:33:17 How is arg declared? i.e. if it is **argv, then sizeof cannot work because sizeof is evaluated at compile time. Oct 13 17:33:48 hello Oct 13 17:34:26 can someone give me some help Oct 13 17:34:44 I have been able to bitbake the task-base bbfile Oct 13 17:35:06 but when I try to build console-image it does not work Oct 13 17:35:32 while installing ipk packages it complains about the package glibc (>=2.5) not found Oct 13 17:35:41 the package name is libc6 Oct 13 17:35:42 mwester hm good point Oct 13 17:36:13 any idea of what can I read to create a virtual glibc package that depends in libc6? Oct 13 17:38:02 03  07org.openembedded.dev * rdd448d7c8c 10org.openembedded.dev.git/ (2 files in 2 dirs): Oct 13 17:38:02 SlugOS: Set PREFERRED_VERSION for gettext, e2fsprogs, and add a temporary Oct 13 17:38:02 hack to e2fsprogs_1.38.bb to work around the autotools and gettext version Oct 13 17:38:02 incompatabilities. Oct 13 17:38:03 03  07org.openembedded.dev * rd730ac03c3 10org.openembedded.dev.git/: Oct 13 17:38:06 merge of '32e97ff195b391fe0a9c6e1af5eada1538dbfa52' Oct 13 17:38:08 and '7cb0692da0f14131ab23beef52a20dd492fe8312' Oct 13 17:38:24 ribalda: which package is wanting deps on glibc 2.5 or greater and fix that package Oct 13 17:39:18 khem: the package is sysvinit Oct 13 17:39:44 but if grep glibc * -r Oct 13 17:39:53 on that pacakge dir I get no results Oct 13 17:40:04 so the dependence has been automagically created Oct 13 17:41:22 ribalda: you can generate dep info from bitbake too use bitbake -g and see the logs Oct 13 17:48:59 khem: the dependents.doc do not show who depends on glibc Oct 13 17:49:30 khem: but I think that the real problem is that the glibc .bb produces libc6.pkg but not glibc.pkg Oct 13 18:44:45 re Oct 13 18:44:49 pb still there? Oct 13 18:51:38 yeah Oct 13 18:51:45 well, actually in a different place now, but still Oct 13 18:52:02 hm how do I get the size of a char **? Oct 13 18:52:12 "size" meaning what? Oct 13 18:52:28 size of pointer? Oct 13 18:52:34 count the chars Oct 13 18:52:38 char ** is a pointer to an array of pointers. Oct 13 18:52:41 yes Oct 13 18:52:50 do you want the length of the first string, or the length of all the strings combined, or something else? Oct 13 18:52:53 woglinde: strlen() ? Oct 13 18:53:02 jay7 hm Oct 13 18:53:10 hms Oct 13 18:53:19 if you want the length of the first string, strlen(argv[0]) like jay7 said Oct 13 18:53:46 args I am idiot yes Oct 13 18:53:51 *sigh* Oct 13 18:53:55 assuming that you have already checked argc >= 1 Oct 13 19:16:34 hurray Oct 13 19:16:38 now it works Oct 13 19:16:51 thank Oct 13 19:16:57 bye till later Oct 13 20:49:50 pb_: hello; those my complaints about gettext -- I'm using minimal-uclibc and it looks like there is slight incompatibility between glibc and uclibc... Oct 13 20:50:29 right, that's certainly possible. Oct 13 20:51:11 anyway, where do you have 0.17-r2 from ? I just checked org.oe.dev, and there's just -r1... Oct 13 20:51:16 pulled this morning... Oct 13 20:51:43 hm, that's odd Oct 13 20:51:45 let me look Oct 13 20:52:14 hey pb_ Oct 13 20:52:47 ah, whoops, gettext-native is at r2, but gettext itself is only at r1 Oct 13 20:52:51 I must have been looking at the wrong package Oct 13 20:53:19 hi ant__ Oct 13 20:53:47 I'll be guinea-pig for uclibc later...(angstrom-c7x0) Oct 13 20:55:52 but now I need help... a strange 'moc' thing here Oct 13 20:55:54 http://tinderbox.openembedded.net/packages/175728/ Oct 13 20:58:59 ant__: this is ccache error Oct 13 20:59:13 you have no link with such name in ccache dir Oct 13 20:59:28 imho, easier is to disable ccache Oct 13 20:59:49 Jay7: hm...rebuilt from scratch Oct 13 20:59:57 (hey, btw) Oct 13 21:00:03 hmhm.. Oct 13 21:00:10 hi :) Oct 13 21:00:30 strangely was compiling few days ago... Oct 13 21:00:33 is any other opie program build ok? Oct 13 21:00:50 I was helping bluelightning on c7x0 Oct 13 21:00:59 opie was compiling last week... Oct 13 21:01:39 cough..cough...disabling integrated w100 graphic Oct 13 21:02:10 try to find where is ccache links placed Oct 13 21:02:34 that is an odd failure. fwiw, it is nothing to do with moc, it's an error with either ccache, your compiler build, or your environment. Oct 13 21:02:36 it is directory with symlinks to real compilers Oct 13 21:04:36 well, perhaps I did a rebuild using packaged-staging yesterday night... Oct 13 21:04:47 let see withreal 'scratch' Oct 13 21:05:00 ccache -c Oct 13 21:05:07 oops..wrong window Oct 13 21:05:31 g'day kergoth Oct 13 21:05:36 hey pb_ Oct 13 21:05:38 how's it going? Oct 13 21:07:02 pretty good, I guess. the uk economy seems to be imploding around us, but as far as my own little world is concerned everything is fine :-) Oct 13 21:07:50 right now I'm trying to update my mythtv system which is proving to be a bit more of a challenge than I hoped. Oct 13 21:08:46 heh, i think the economies in most places are exploding to some extent, just a matter of degree Oct 13 21:09:34 yeah, true enough, we certainly don't have it as bad as, say, iceland. Oct 13 21:10:32 our government does seem to be in the process of buying big stakes (up to 60% in some cases) in most of our major banks, though. Oct 13 21:10:45 ah Oct 13 21:11:39 heh Oct 13 21:11:49 everyone is nationalizing their banks Oct 13 21:12:06 heh Oct 13 21:12:10 yeah, it seems Oct 13 21:12:41 the problem being the total debits are much bigger than central banks trasury... Oct 13 21:12:48 well, either that or letting them go bust :-} Oct 13 21:12:53 ever heard about 'moltiplicator' ? Oct 13 21:13:00 * mwester is just keeping his head low, and making sure he has enough cash on hand to deal with a sudden "employment change" Oct 13 21:14:55 * Crofton|work is glad his bank was bought by wells fargo and not citi Oct 13 21:16:52 * mwester too. Oct 13 21:22:10 * Jay7 have read some analytics today.. seems that crysis coming up to 2012-2014.. Oct 13 21:24:00 btw, 2013 is end of current 'era' by Maya's calendar.. Oct 13 21:24:27 seems interconnected :) Oct 13 21:25:01 You know, just by sheer coincidence, at least one of the "end-of-the-world" groups will end up being right. Oct 13 21:28:50 btw, anyone built e2fsprogs-1.38 recently? Oct 13 21:29:30 (using automake-1.10 and libtool-2.2.4) Oct 13 21:30:45 I think woglinde is your expert for that. Oct 13 21:31:13 this is the MKINSTALLDIRS thing, presumably Oct 13 21:32:09 yes, exactly Oct 13 21:32:21 did I already mention it? Oct 13 21:32:32 argh... or even bugreported :) Oct 13 21:33:18 I really don't remember the things which I did and which didn't bugreport :) Oct 13 21:37:44 hmm, going to give a shot to e2fsprogs-1.41.3 Oct 13 21:38:49 but looks like it doesn't work anyway Oct 13 21:39:46 I hope I'll catch woglinde tomorrow then :) Oct 13 22:33:47 hi, is there a j2me/midp implementation for OE? Oct 13 22:34:23 take a look to jalimo Oct 13 22:36:44 i don't see PhoneME in meta/packages :\ Oct 13 23:07:17 echelon: you can build phoneme-advanced-foundation and -personal with OE Oct 13 23:07:49 echelon: phoneme + midpath (= midp2.0 implementation) does not work right now, but that is considered a bug Oct 13 23:15:47 i need both midpath _and_ phoneme for midp implementation? Oct 13 23:27:44 03  07org.openembedded.dev * r3320f41cea 10org.openembedded.dev.git/packages/e2fsprogs/ (e2fsprogs-1.38/mkinstalldirs.patch e2fsprogs_1.38.bb): Oct 13 23:27:44 e2fsprogs: fix automake-1.9 vs automake-1.10 Oct 13 23:27:44 * hm it seems we can use @mkdir_p@ on both version Oct 13 23:27:44 * sorry I did not see this earlier Oct 13 23:27:44 * bump PR Oct 13 23:27:51 03  07org.openembedded.dev * r2c052bfbda 10org.openembedded.dev.git/packages/e2fsprogs-libs/ (2 files in 2 dirs): Oct 13 23:27:53 e2fsprogs-libs: fix mkdir_p problem Oct 13 23:27:55 * do the same fix as to e2fsprogs Oct 13 23:27:57 * bump PR Oct 13 23:39:25 hi ppl Oct 13 23:55:39 i can successfully get openswan compiling & installing but don't know how to have kernel modules... any tips ? **** ENDING LOGGING AT Tue Oct 14 02:59:57 2008