**** BEGIN LOGGING AT Sat Sep 05 02:59:58 2009 Sep 05 04:54:38 no matter how much I tell it to build native-sdk-console-image it keeps producing same 3 mb tar file Sep 05 07:19:05 Hi, I have small bash script for bumping xorg stuff versions in OE, based on latest tarballs in http://xorg.freedesktop.org/releases/individual/, is someone interested? Sep 05 10:32:09 khem: My spitz image build failed on your last change. Spitz image uses PXA270 with glibc, new names are: armv5teb (ipk and deploy), armv5teb-angstrom-linux-gnueabi (work). Can you confirm, that these are correct and I should adopt all spitz configs to new names? Sep 05 10:41:24 hey, i got a fun one Sep 05 10:41:26 http://pastebin.com/d549a175b Sep 05 10:41:50 i got it compiling after i found a patch from gentoo that checks for nis headers Sep 05 10:42:09 this is pam, btw, being linked to uclibc 9.30.1 Sep 05 10:42:31 i recently installed gettext and libiconv to staging Sep 05 10:49:38 libpam_la_LIBADD = @LIBAUDIT@ $(LIBPRELUDE_LIBS) @LIBDL@ @INTLLIBS@ Sep 05 10:49:43 i dunno if thats 100% right Sep 05 10:49:54 would it be LIBINTL Sep 05 10:49:57 eh i can check Sep 05 10:50:26 seems good Sep 05 11:08:01 00001c34 g F .text00000024 libintl_dgettext Sep 05 11:08:06 its totally right there Sep 05 11:08:16 i just cant figure out how to change Makefile.am to get it to link to it Sep 05 11:29:00 m4t: Yes, adding $(INTLLIBS) or @INTLLIBS@ to the Makefile.am is the correct solution. Developers often forget to do it (it's empty with glibc). Sep 05 11:30:06 m4t: Don't forget to send the patch upstream. Sep 05 11:31:33 sbrabec_utx i got the pos to compile Sep 05 11:31:54 there was another problem with the same function from libintl in modules/pam_tally Sep 05 11:32:04 the Makefile.am fix that worked in libpam didnt work there Sep 05 11:32:16 i ended up adding '-lintl' to LIBS= in the Makefile Sep 05 11:32:19 which fixed it Sep 05 11:32:36 i really dont know how all of the variables translate from Makefile.am etc. into the Makefile though Sep 05 11:33:05 * m4t adds a note to his patch Sep 05 11:33:59 sbrabec_utx , thanks for the feedback btw Sep 05 11:34:05 Makefile.am -> Makefile.in: Done once by the autoreconf, equal for all platforms. Makefile.in->Makefile is done by configure in compile time. Sep 05 11:34:30 Adding anything to auto-generated Makefile (or Makefile.in) is a hack. Sep 05 11:35:06 sbrabec_utx i'm aware of that :/ Sep 05 11:35:32 pam_tally_la_LIBADD = -L$(top_builddir)/libpam -lpam $(INTLLIBS) does not work? Sep 05 11:35:41 nope Sep 05 11:35:51 What happens there? Sep 05 11:36:03 same undefined reference Sep 05 11:36:10 it ends up in the Makefile though Sep 05 11:36:17 the $(INTLLIBS) Sep 05 11:36:24 erm hmm Sep 05 11:37:03 maybe INTLLIBS would work, i tried LTINTLLIBS and LIBINTL Sep 05 11:37:05 $(INTLLIBS) can, Makefile contains INTLLIBS = ... (distro dependent). Sep 05 11:38:46 * m4t 's dependencies running in circles, just to get libao.m4 for mpg321 Sep 05 11:39:23 i got libtorrent/rtorrent compiling earlier too. needed cstdio Sep 05 11:39:42 for snprintf Sep 05 12:39:06 cool Sep 05 12:39:14 got fixed point mp3 decoding Sep 05 13:41:55 anyone successfully using libao/uclibc? Sep 05 13:42:01 runtime Sep 05 13:43:16 its either libao or mpg321. mp3blaster 'worked', but playback wasn't adequate because it used floating point Sep 05 13:44:00 ioctl(5, 0x40104132, 0x7f957048) Oops: kernel access of bad area, sig: 11 [#10] Sep 05 13:45:02 wavwriter output works fine Sep 05 13:55:25 hi, i am having problem with ortp Sep 05 13:55:38 does anyone know why ortp can't be bitbake ? Sep 05 14:05:32 egh wtf latest moc segfaults the same way Sep 05 14:16:12 heh there is a stuck process now Sep 05 14:16:21 ps hangs, it cant even list it Sep 05 14:16:36 if i strace -p it, strace hangs Sep 05 14:17:22 Name:mocp Sep 05 14:17:23 State:D (disk sleep) Sep 05 14:20:17 ls -l hangs at /proc/912/exe Sep 05 14:20:22 hung i guess. i had to cycle power Sep 05 14:21:09 here is the gist: http://pastebin.com/d38953c0e Sep 05 14:22:34 definitely libao-alsa. libao-oss doesnt segfault Sep 05 14:22:43 oss compatibility layer, but still Sep 05 14:28:31 after this much fpu-less fun, i think the next machine i buy will be an itanium Sep 05 14:32:49 Hi, does anybody know a good guide about building qt3 apps in openembedded? Sep 05 14:45:00 http://shell2.reverse.net/~matt/radio.mp3 that is a sample of the output of a 128kb/s mp3 Sep 05 15:11:23 hi does anyone know why ortp failes to bitbake? Sep 05 15:13:32 * rkirti runs a build here Sep 05 15:33:13 rkirti: any idea why ortp does not work? Sep 05 15:33:26 i filed an issue in OE's bug system, but no response Sep 05 15:34:16 whitefox: resolving bugs takes time. You just did that yesterday :) Is it the same glib.h issue ? Sep 05 15:34:53 yes Sep 05 15:35:08 rkirti: oh i see. i was just not sure if i followed the right approach. Sep 05 15:35:16 rkirti: it was working before Sep 05 15:35:24 before i git pull Sep 05 15:37:23 whitefox: give me 5 mins, I had tried a build here, but it failed coz fetch issues. I will check again Sep 05 15:37:48 are you using the latest as well? Sep 05 15:38:25 yep Sep 05 15:39:18 ok, thanks alot Sep 05 15:52:00 whitefox: seems to have built here for me Sep 05 15:52:06 I am on .dev branch Sep 05 15:52:20 and I think my last git pull was yesterday Sep 05 16:18:17 morning Sep 05 16:32:24 good morning Sep 05 18:05:20 Hello, can anybody help me? Sep 05 20:34:23 good morning Sep 05 20:37:24 hello ant__ Sep 05 20:41:51 gm Sep 05 20:42:46 evening ant__ Sep 05 20:43:16 pb_: hey Sep 05 20:43:33 possibly your ueber-long tail breaked irclogs ;) Sep 05 20:43:49 heh Sep 05 20:44:00 yeah, my tail has been quite fearsome of late Sep 05 20:44:06 just joking but some bad char slipped in the logfile it seems Sep 05 20:44:20 http://ibot.rikers.org/%23oe/ Sep 05 20:44:30 no logs for 2nd sept Sep 05 20:44:41 and for 5th (today) too :) Sep 05 20:44:48 oh yeah Sep 05 20:44:58 today's logs probably won't be available until tomorrow, I think ibot runs in arrears Sep 05 20:44:59 just wait the log-rotate Sep 05 20:45:08 but yeah, it is weird that the log for the 2nd is missing Sep 05 20:45:15 on hentges.net we get real-time logs Sep 05 20:45:24 and it failed today too Sep 05 20:45:29 already ;) Sep 05 20:45:55 heh Sep 05 20:46:35 just wondering ...I know the php/web issues but never played with ircbots... Sep 05 20:55:22 03Khem Raj  07org.openembedded.dev * recf30fb13c 10openembedded.git/recipes/ortp/ (ortp.inc ortp_0.13.1.bb ortp_0.7.1.bb): Sep 05 20:55:22 ortp: Add glib-2.0 dependency for 0.7.1 Sep 05 20:55:22 * Also use INC_PR Sep 05 20:55:22 * Do not use glib dependency on 0.13.1 Sep 05 20:55:22 Signed-off-by: Khem Raj Sep 05 21:03:50 pb_: I just read something but still...what has changed that now I get armv5teb instead of armv5te as before? Sep 05 21:05:36 ..and /etc/opkg.conf has still armv5te in path... Sep 05 21:05:43 urgh.. Sep 05 21:08:06 ant__: that is rather strange. what's your MACHINE? Sep 05 21:08:14 c7x0 Sep 05 21:08:19 no changes Sep 05 21:08:35 pb_: I was investigating about | Collected errors: Sep 05 21:08:35 | * Cannot find package kexecboot. Sep 05 21:09:01 was fine a week ago... Sep 05 21:09:02 hm, c7x0 definitely ought to be armv5te, not -b Sep 05 21:09:12 I don't know why that would have changed though Sep 05 21:11:03 some commit about build triplet? Sep 05 21:11:24 afaik, that should only have affected TARGET_OS, not the architecture part Sep 05 21:11:53 if you're on angstrom then the changes are fairly minor. Sep 05 21:12:37 what's strange, the change has propagated everywere (cross, staging..) Sep 05 21:12:53 but NOT in i686-linux/etc/opkg.conf Sep 05 21:13:00 still old paths there Sep 05 21:13:15 'old arch' (armv5te) Sep 05 21:13:42 hello stanislav Sep 05 21:13:52 Hallo. Sep 05 21:15:42 pb_: OpenEmbedded: Switch to using linux-uclibceabi and linux-gnu for TARGET_OS Sep 05 21:16:30 right, that's TARGET_OS not TARGET_ARCH Sep 05 21:16:35 mickeyl: good evening Sep 05 21:16:45 good evening pb_ Sep 05 21:17:31 Is the change from armv5te to armv5teb for spitz in work/ and ipk/ intended? Binaries inside seems to be compatible with the old build, but build of image fails - ipk is not able to find packages in new dirs. Sep 05 21:18:13 this touches tune-xscale.inc Sep 05 21:18:21 sbrabec_zaurus: yep Sep 05 21:19:27 So I have to fix my opkg config to search in new directories, isn't it? Sep 05 21:19:27 sbrabec_zaurus: no, that is clearly a bogus change. spitz is not a big endian platform. Sep 05 21:19:40 sbrabec_zaurus: it was unintended I mean ;) Sep 05 21:19:49 seems a bug to me Sep 05 21:20:08 Ah. And where should i fix it? Sep 05 21:20:23 I'm looking at this change but ... Sep 05 21:20:24 http://cgit.openembedded.org/cgit.cgi/openembedded/diff/conf/machine/include/tune-xscale.inc?id=558f6d44365f062523fbba3926ab46e5cd1984b8 Sep 05 21:21:12 the commit is huge and I don't see the whole picture in 5 mins ;) Sep 05 21:21:39 oh, that tune-xscale change can't be right Sep 05 21:24:05 actually, maybe it can, it seems that siteinfo isn't quite so sensitive as I thought it was. Sep 05 21:24:33 do the strings in siteinfo.bbclass look like they are in sync with your current TARGET_OS setting? Sep 05 21:26:38 I didn't set TARGET_OS and let it to use default. Sep 05 21:26:39 I am not an endian expert, how can I detect endian of built binaries? If my new bash runs in the old system, does it have the same endian? Sep 05 21:26:48 hi Sep 05 21:27:37 sbrabec_zaurus: use "file" Sep 05 21:28:09 or readelf Sep 05 21:28:40 sbrabec@ben:/data/OE/buildsystem/OE/build/tmp/work/armv5teb-angstrom-linux-gnueabi/bash-3.2-r8/image/bin> file bash Sep 05 21:28:41 bash: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), stripped Sep 05 21:30:24 readelf -h says little endian Sep 05 21:30:51 So it seems to be just a bad directory name. Sep 05 21:34:20 ha ha.. Sep 05 21:34:29 logs fixed...http://www.hentges.net/irclogs/%23oe/2009/September/20090902_oe.log Sep 05 21:34:36 (thx CoreDump|home ) Sep 05 21:34:45 see khem's mgsg Sep 05 21:43:58 03Henning Heinold  07org.openembedded.dev * rfc84d991bc 10openembedded.git/recipes/gstreamer/gst-plugins-good_0.10.15.bb: Sep 05 21:43:58 gst-plugins-good: add esound to DEPENDS line Sep 05 21:43:58 * fixes compilation error Sep 05 21:43:58 * bump PR Sep 05 21:47:26 pb_: khem wrote machine conf has BASE_PACKAGE_ARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}" Sep 05 21:47:37 it goes into recursion Sep 05 21:47:53 if I set BASE_PACKAGE_ARCH = "armv5teb" in above machine file all is ok Sep 05 21:48:08 kergoth: this is tune-xscale.conf file Sep 05 21:48:15 it tries to set BASE_PACKAGE_ARCH smartly using python voodoo Sep 05 21:48:27 weird when I assign it to local it works Sep 05 21:48:30 * khem will live with it Sep 05 21:48:32 lol Sep 05 21:49:42 doh Sep 05 21:49:57 well, I guess you should take it up with khem Sep 05 21:50:02 :) Sep 05 21:50:29 he simply didn't bother kergoth enough :D Sep 05 21:52:17 sbrabec_utx: I'm retrying setting as above Sep 05 21:52:24 but armv5te Sep 05 21:54:23 ant__: This is my conf: http://www.penguin.cz/~utx/zaurus/feed/tools/conf/local.conf Sep 05 21:56:03 sbrabec_utx: seems vanilla like mine Sep 05 21:56:19 I'm editing tune-xscale.inc Sep 05 21:56:33 waiting for further investigations... Sep 05 22:04:24 btw, anybody get "NOTE: Handling BitBake files: - (0310/7109) [ 4 %]:103: DeprecationWarning: the sets module is deprecated Sep 05 22:04:24 " Sep 05 22:04:28 ? Sep 05 22:04:54 python 2.6 Sep 05 22:05:22 I see, is a known issue then, thx Sep 05 22:05:40 you could use from git Sep 05 22:06:21 yep..I have the latest svn + some patches Sep 05 22:06:35 svn is deprecated Sep 05 22:06:40 use git one Sep 05 23:00:52 woglinde: bitbake is now in GIT? Sep 05 23:03:50 sure Sep 05 23:03:59 didnt you read ml announcement? Sep 05 23:04:24 http://cgit.openembedded.org/cgit.cgi/bitbake/ Sep 05 23:21:22 woglinde:No I missed it (but found it now). I guess the wiki should be updated. Sep 05 23:21:42 hm isnt it already in the wiki? Sep 05 23:24:53 No I just edited a page. Sep 05 23:25:06 Getting Started -> Bitbake (http://wiki.openembedded.net/index.php/BitBake) Sep 05 23:25:22 All the project pages of bitbake themselves still talk about the SVN repo Sep 05 23:25:32 I think a news item is required on the OE main page. Sep 06 02:20:38 03Khem Raj  07org.openembedded.dev * reaabd140ce 10openembedded.git/recipes/perl/perl_5.8.8.bb: Sep 06 02:20:38 perl_5.8.8.bb: Use exec_prefix instead of layout_exec_prefix Sep 06 02:20:38 Signed-off-by: Khem Raj Sep 06 02:20:39 03Khem Raj  07org.openembedded.dev * r1578d2e0a5 10openembedded.git/recipes/perl/perl_5.8.8.bb: Sep 06 02:20:39 perl_5.8.8.bb: Fix compilation when bindir is not /usr/bin Sep 06 02:20:43 * Right now default perl installation happens in /usr prefix Sep 06 02:20:45 This patch tries to depend upong layout_prefix to decide on Sep 06 02:20:47 where to install. This is required for distros like micro Sep 06 02:20:49 who flatten the install tree and do not use /usr prefix Sep 06 02:20:51 Signed-off-by: Khem Raj Sep 06 02:20:53 03Khem Raj  07org.openembedded.dev * r8c2c7d80a8 10openembedded.git/recipes/procps/procps_3.2.7.bb: Sep 06 02:20:56 procps_3.2.7.bb: Fix compilation when usr/bin is same as /bin Sep 06 02:20:58 * On DISTROs like micro where bindir and base_bindir are Sep 06 02:21:00 same, procps does not compile because it wants to install Sep 06 02:21:02 binaries in both places. We have to pass the variable to Sep 06 02:21:04 make file since it does not use autotools. Sep 06 02:21:06 Signed-off-by: Khem Raj Sep 06 02:21:08 03Khem Raj  07org.openembedded.dev * r9300c47599 10openembedded.git/recipes/gcc/ (3 files in 2 dirs): Sep 06 02:21:15 gcc-4.4.1: Fix canadian cross compilation. Sep 06 02:21:17 * Forward port cache amnesia patch Sep 06 02:21:19 * Forward port gcc-flags-for-build patch Sep 06 02:21:21 * do_configure needs to be overridden for 4.4.1 Sep 06 02:21:23 Signed-off-by: Khem Raj Sep 06 02:21:25 03Khem Raj  07org.openembedded.dev * rf4c7ff92f9 10openembedded.git/recipes/pam/ (libpam-1.0.2/pam-disable-nis-on-uclibc.patch libpam_1.0.2.bb): Sep 06 02:21:30 libpam_1.0.2.bb: Fix compilation for uclibc systems. Sep 06 02:21:32 * libpam is not able to figure out that Sep 06 02:21:34 uclibc does not support NIS. This patch Sep 06 02:21:36 helps in making it do so. The patch is only Sep 06 02:21:38 applied for uclibc OVERRIDES. Sep 06 02:21:40 Signed-off-by: Khem Raj **** ENDING LOGGING AT Sun Sep 06 02:59:57 2009