**** BEGIN LOGGING AT Fri Nov 13 02:59:57 2009 Nov 13 03:43:12 I use 'bitbake linux-omap3 ' Nov 13 03:43:20 And get some error like this http://dl.dropbox.com/u/599479/playspace/overo-oe/build-fail.txt Nov 13 03:43:28 Can anyone help me to fix it? Nov 13 04:08:06 hello Nov 13 04:19:04 I assume that you guys know stuff about opkg and ipkg? Nov 13 04:23:40 Because I keep getting fork errors in opkg, and I'm not sure what to do about that Nov 13 04:25:03 that's not good Nov 13 04:25:15 what operation are you performing? Nov 13 04:25:43 zmjjmz, there is only one fork() in all of opkg Nov 13 04:25:56 which occurs when you extract a file Nov 13 04:25:59 opkg is a memory pig, and leaks like a seive Nov 13 04:26:10 so you need to add swap space for it, or diable your OOM killer Nov 13 04:26:16 er, disable Nov 13 04:26:41 There are some fixes that have been made, so perhaps a more recent version of opkg will work for you. Nov 13 04:27:00 doing an install Nov 13 04:27:05 I actually didn't turn the swapon Nov 13 04:27:05 or you can take a look at some of the other variations on opkg in the OE recipes; the one for SlugOS works ok on 32MB systems. Nov 13 04:27:16 zmjjmz, can you paste the command and its output into a pastbin? Nov 13 04:27:52 sometimes turning on swap can be hard Nov 13 04:28:10 for instance, if you are using flash based filesystem Nov 13 04:28:33 grg: not really, this distro doesn't have anything to do that with Nov 13 04:28:43 Yep, that's why the SlugOS-specific version of opkg exists. It uses (for one thing) vfork instead of fork. Nov 13 04:28:44 and yeah I'm running off of a microSD card Nov 13 04:29:11 mwester, can you point me at this slugos version? Nov 13 04:29:24 and a way to install it? Nov 13 04:29:30 (I do have wget on here, actually) Nov 13 04:29:57 what's the command to opkg install a package manually, because going through the help file is impossible on sucha small screen Nov 13 04:30:27 opkg install foo.opk Nov 13 04:30:35 ok Nov 13 04:30:36 thanks Nov 13 04:30:49 let me browse these repos manually now :| Nov 13 04:31:08 grg: recipes/opkg-nogpg-nocurl_svn.bb builds it; the patches are in the files dir. Nov 13 04:31:16 it would be nice if you could tell me the full error message you are getting... i could at least attempt to look into it then Nov 13 04:33:04 grg: yeah, ok, here let me try Nov 13 04:33:12 I'll have to manually put it into pastebin Nov 13 04:36:07 great, wifi just cut out Nov 13 04:37:14 alright Nov 13 04:40:31 here's what happens when I try to install nmap: Nov 13 04:40:35 grg: http://pastebin.com/m1fca3523 Nov 13 04:41:15 ffs! who wrote the error handling code in opkg... Nov 13 04:41:32 * grg guesses... no one Nov 13 04:42:22 not I Nov 13 04:42:51 no wonder bugs go unfixed. the errors you get when something fails are useless Nov 13 04:43:30 mwester is probably right, and you've just run out of memory Nov 13 04:45:44 ugh Nov 13 04:45:45 ok Nov 13 04:46:18 tried to dl it with wget, then it said "invalid magic" when I tried to install it Nov 13 04:46:39 but I'll see about getting swapon Nov 13 04:47:54 I don't know about that Nov 13 04:48:10 you see, free says that more than half of my memory is available Nov 13 04:48:16 how much does opkg take up? Nov 13 04:48:25 how long is a piece of string? Nov 13 04:48:35 good point Nov 13 04:48:50 how much ram do you have total? Nov 13 04:49:02 32MB Nov 13 04:49:09 well, 30MB Nov 13 04:49:16 says only 13MB is used at idel Nov 13 04:49:18 *idle Nov 13 04:49:24 that is going to be very tight Nov 13 04:49:30 (I guess I'm running wpa_supplicant under that) Nov 13 04:49:36 yeah Nov 13 04:49:36 many opkg commands will fail in bad ways Nov 13 04:49:37 ok Nov 13 04:49:46 I'll try to setup swap then Nov 13 04:49:48 You can't run the unpatched opkg in 32MB Nov 13 04:49:51 just need to find the swap partition Nov 13 04:49:55 :/ Nov 13 04:49:57 you need the SlugOS patched version. Nov 13 04:49:59 that's annoying Nov 13 04:50:10 Can't even do it with swap - sorry. Nov 13 04:50:15 the OOM killer will get you anyway. Nov 13 04:51:09 :/ Nov 13 04:51:37 so, the slugos patch execlp("gunzip") instead of forking and using libbb's unzip function.... any reason why the fork just wasnt removed? Nov 13 04:52:57 great, I don't even have make on here, not sure how I'll get the SlugOS one Nov 13 04:53:37 zmjjmz: I guess I'm confused now -- didn't you build your image? Just change it to depend on the other opkg. Nov 13 04:53:56 mwester: didn't build it, no Nov 13 04:54:07 it was specifically built for this device though Nov 13 04:54:18 grg: probably because at the time there was still some hope to minimize the amount of tmpdir space required... Nov 13 04:54:36 zmjjmz: you'll have to talk to the maintainers for that distro then. Nov 13 04:54:46 mwester: I agree Nov 13 05:05:32 http://dl.dropbox.com/u/599479/playspace/overo-oe/build-fail.txt Nov 13 05:05:42 mwester, i don't follow - your patch uses an identical amount of /tmp space because the data is extracted from one fd to another Nov 13 05:07:07 perhaps I don't follow you -- IIRC the unzip is piped to the parent process Nov 13 05:08:15 yes Nov 13 05:08:38 so your patch does the same thing, it just uses an external program to do so Nov 13 05:09:02 my patch was only intended to replace the fork() with vfork(). Nov 13 05:09:18 in order to dodge the OOM Killer Nov 13 05:09:27 So why not just remove the fork()ing all together? Nov 13 05:09:52 If you remove the forking altogether then one must uncompress to a temp file, and then read that temp file. Nov 13 05:10:09 im not convinced Nov 13 05:10:16 will look into it Nov 13 05:10:31 there's nothing to be convinced about. That's a fundamental *nix concept :) Nov 13 05:11:10 alright, I'll try debian next time :P Nov 13 05:11:14 night, and thanks Nov 13 05:11:41 i am prepared to change the interface between libbb and libopkg Nov 13 05:12:17 You propose to replace the file read operations with calls to the uncompression code? That would work, but is rather a major change. Nov 13 05:13:16 opkg needs major change Nov 13 05:13:47 morning fols Nov 13 05:13:50 folks, even Nov 13 05:13:57 hello Nov 13 05:13:58 If you're actually willing to make that sort of a major change, that's fabulous! Nov 13 05:14:18 Greetings mickey|ICE672 Nov 13 05:15:46 gz_open takes an input FILE* and returns a FILE*. It forks to call unzip() which takes an input FILE* and an output FILE*. Nov 13 05:18:25 hmm Nov 13 05:20:28 making music kergoth ? Nov 13 05:20:33 heh Nov 13 05:20:50 * kergoth 's trying to remember what he did with the version of do_unpack that used the python modules to extract Nov 13 05:20:59 its in one of these 40+ trees, i swear.. Nov 13 05:22:26 hehe Nov 13 05:22:40 locate | xargs grep, perhaps Nov 13 05:23:02 i really, really want something like locate but which pokes inside of git repositories somehow.. magically. Nov 13 05:23:06 heh Nov 13 05:26:20 one of these days i'm going to resurrect bitbake -i Nov 13 05:26:27 i'm really missing it Nov 13 05:26:44 then again, it might still work Nov 13 05:26:51 didn't try for ages Nov 13 05:26:52 seemed to last time i ran it Nov 13 05:26:58 heh, cool Nov 13 05:27:03 don't really use it much, probably should :) Nov 13 05:27:07 i thought all the changes in master broke it Nov 13 05:45:24 mickey|ICE672: what is it you wanted to talk about? Nov 13 05:47:36 Laibsch: just wanted your blessing for the planned radical bugtracker cleanup Nov 13 05:47:58 In general I'm cool with it Nov 13 05:48:12 I don't know about the details, though Nov 13 05:48:35 FWIW, I have heard that all non-OE should be out/closed Nov 13 05:48:57 the question one will have to answer is "what is a OE bug?", then Nov 13 05:49:05 That's easier said than defined Nov 13 05:49:12 corect Nov 13 05:49:24 this is going to be a process Nov 13 05:49:38 OK Nov 13 05:49:57 I'll try to keep an eye on it and give feedback when I think it's necessary Nov 13 05:49:59 great. we're going to have bug squashing weekends again Nov 13 05:50:05 oki Nov 13 05:50:36 Instead of closing tickets that are valid, but out of scope under the new regime, maybe we should put them in a separate part of the bugtracker? Nov 13 05:51:00 OE, bitbake, zaurus kernels, infrastructure, out-of-scope? Nov 13 05:52:07 can we stop reporting activity and creating new ones on out-of-scope stuff? Nov 13 05:52:32 zaurus kernels are out of scope as well, btw. Nov 13 06:04:20 what do you mean stop reporting activity? Nov 13 06:04:36 stop sending mails when things change for bugs out of scope? Nov 13 06:04:45 I think that should be possible Nov 13 06:05:07 It is definitely possible to disallow reporting new bugs against defined components Nov 13 06:13:29 out-of-scope ones should essentially be... out of scope Nov 13 06:13:32 so i'd rather not have any reports to the bug mailing list Nov 13 06:18:16 ok, now we just need to find a way to mass-move all the bugs against != OE and != infrastructure to this new out-of-scope component Nov 13 06:27:21 mwester, it appears likely that the original reason for fork()ing the unzip was to avoid the unpleasantness of libbb. Nov 13 06:27:33 things don't really behave correctly within libbb Nov 13 06:28:11 i'm seeing some really nasty memory abuse Nov 13 06:37:32 now that glib is a requirement for opkg anyways, it might make sense to remove all traces of libbb usage Nov 13 06:46:58 mickeyl: that should be fairly easy to do component-wise Nov 13 06:47:10 mass-changing bugs in bugzilla is easy to do Nov 13 06:47:27 of course, some manual combing through bugs will also be necessary Nov 13 06:47:54 but I guess it will be a rewarding job, never been so easy to move bugs off the radar ;-) Nov 13 06:59:31 morning Nov 13 07:15:12 can anyone help me to fix the error form bitbake? Nov 13 07:18:06 http://dl.dropbox.com/u/599479/playspace/overo-oe/build-fail.txt Nov 13 07:19:20 RP: awake? Nov 13 07:19:30 I just updated the tree and compiled udev. Nov 13 07:19:54 the following files were installed but not shipped in any package: Nov 13 07:20:26 /usr/lib/libudev.so|/usr/lib/libudev.so /usr/lib/libudev.so|libvolume_id.pc Nov 13 07:20:47 isn't that what you supposedly fixed a few hours ago? Nov 13 07:23:44 err, slightly mispasted, sorry. last 2 files are 2 .pc files Nov 13 07:25:29 also dbus-native still seems to fail here: Nov 13 07:25:30 /home/spaetz/src/shrbuildenv/shr-unstable/tmp/staging/x86_64-linux/usr/bin/install: cannot stat `.libs/dbus-daemon': No such file or directory Nov 13 08:22:24 hi Nov 13 08:27:20 http://dl.dropbox.com/u/599479/playspace/overo-oe/build-fail.txt Can somebody help me? Nov 13 08:43:51 gm xora Nov 13 08:43:59 hey Nov 13 09:07:50 * XorA thinks he has found the xterm install issue Nov 13 09:07:57 and its really really stupid Nov 13 09:08:24 xora hehe whats it? Nov 13 09:08:53 they have xterm installed in their host OS, xterm installer is checking mode on /usr/bin/X11/xterm Nov 13 09:09:05 Im just testing to see if Im correct Nov 13 09:09:57 BINGO!!! Nov 13 09:10:03 lol Nov 13 09:17:31 03Koen Kooi  07org.openembedded.dev * rd0ede79db3 10openembedded.git/recipes/xorg-lib/ (10 files in 2 dirs): pixman git: bump SRCREV to one where almost all patches are upstream Nov 13 09:21:35 morning all Nov 13 09:21:39 hey RP Nov 13 09:21:59 well at least we can ignore all that selinux nonsense on the mailing list Nov 13 09:23:44 spaetz: hmm :/ Nov 13 09:23:55 hi rp Nov 13 09:24:10 hello guys Nov 13 09:24:21 hi longfield Nov 13 09:24:44 is it possible to define many names in the LEAD_SONAME variable in a lib recipe ? Nov 13 09:25:01 longfield nope Nov 13 09:25:03 only one Nov 13 09:25:16 either you live with it or you split the package up Nov 13 09:26:04 hum, that's annoying Nov 13 09:26:07 mossila hm I stumbled over similary I think I checked out the kernel stuff by hand and than it works Nov 13 09:26:13 longfield why? Nov 13 09:26:16 its only note Nov 13 09:26:30 for boost will not split it up more Nov 13 09:27:06 well, we have a software we use everywhere, it build varous .so and even executables Nov 13 09:27:44 Every time new media is mounted, I want to run a script to check its filesystem for the existence of a file. How can I do this? Some udev-patch? Nov 13 09:28:09 when I try to run the executables I have built, it tries to look for the .so that are no the LEAD_SONAME where they where when built Nov 13 09:28:32 I guess I have to split my package up Nov 13 09:28:55 I think I will ignore Robert P. J. Day Nov 13 09:29:54 tasslehoff jupp Nov 13 09:30:03 tasslehoff or usbmount Nov 13 09:31:07 03Graeme Gregory  07org.openembedded.dev * redf2a4ca83 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.org/openembedded into org.openembedded.dev Nov 13 09:31:19 03Graeme Gregory  07org.openembedded.dev * r509fe8bba2 10openembedded.git/recipes/xorg-app/ (xterm_207.bb xterm_243.bb xterm_251.bb): (log message trimmed) Nov 13 09:31:19 xterm_207.bb : fix problem on "SELinux" F11 based builds Nov 13 09:31:19 xterm_251.bb : fix problem on "SELinux" F11 based builds Nov 13 09:31:19 This was not really F11 or SELinux problem, installer was checking for Nov 13 09:31:20 the existance of /usr/bin/X11/xterm and trying to read the permissions Nov 13 09:31:22 for that and replicate them into the OE build. A simple --disable-setuid Nov 13 09:31:24 prevents this script being called and the bogus check on host tools Nov 13 09:32:17 morning Nov 13 09:32:18 args why the heck glib-native searches for libtool under usr/bin rather then bin/ for micro Nov 13 09:32:22 hi hrw Nov 13 09:32:57 RP: I'm in the dbus-native build dir now, want me to look for sth specific? Nov 13 09:33:32 hm libxml2-native seems borken too Nov 13 09:34:04 woglinde: my angstrom build is now at 3K/5K tasks Nov 13 09:34:17 woglinde: I think that commit message should be clear enough Nov 13 09:34:23 RP: I only have ./bus/dbus-daemon and not .libs/dbus-daemon Nov 13 09:34:39 RP: this being dbus-n Nov 13 09:34:40 ative-1.2.1-r16.1 Nov 13 09:34:51 xora jupp Nov 13 09:35:47 hm glib-native seems wrong at this line Nov 13 09:35:48 cp ${STAGING_BINDIR}/${TARGET_SYS}-libtool ${S} Nov 13 09:36:05 but why is STAGING_BINDIR for micro set to usr/bin Nov 13 09:36:57 spaetz: I don't know why your configuration wouldn't build things in a .libs directory :/ Nov 13 09:37:11 woglinde, I'll try an extra "RUN+=" in mount.sh and see what happens :) Nov 13 09:37:39 rp any idea? Nov 13 09:37:51 or should STAGING_BINDIR be avoided? Nov 13 09:38:09 woglinde: no, it should work Nov 13 09:38:21 woglinde: actually, native layout will not change though Nov 13 09:38:22 rp or is micro wrong? Nov 13 09:38:36 woglinde: For -native the layout won't change Nov 13 09:38:39 all stuff is now in /bin /include Nov 13 09:38:43 for micro Nov 13 09:38:48 no /usr Nov 13 09:38:53 for native too Nov 13 09:39:15 RP: any plans to merge 1.8/1.10 changes into master bitbake? Nov 13 09:39:16 okay than it is a error inside micro distribution Nov 13 09:39:40 hrw: They're all already in master bitbake aren't they? Nov 13 09:40:11 ok, maybe I forgot to pull them last time Nov 13 09:40:28 woglinde: I think micro may need to override some of the other new variables Nov 13 09:40:57 woglinde: Try prefix_native = "" Nov 13 09:41:00 * XorA wonders if he is allowed to take the cleaner home with him Nov 13 09:42:37 rp ah cool yes Nov 13 09:42:55 this makes sence Nov 13 09:43:05 03Richard Purdie  07org.openembedded.dev * r8e39848b2a 10openembedded.git/recipes/dbus/ (3 files in 2 dirs): Nov 13 09:43:05 dbus-1.2.1: Update fix-daemon-install patch to use automake magic to avoid the wrapper scripts Nov 13 09:43:05 Signed-off-by: Richard Purdie Nov 13 09:43:10 spaetz: pull and try that please Nov 13 09:43:13 rp I will check it in Nov 13 09:43:19 if it works Nov 13 09:44:16 hm exec_prefix_native = "" too I guess Nov 13 09:44:20 lets see Nov 13 09:44:26 RP trying... Nov 13 09:44:35 woglinde: yes Nov 13 09:47:50 no /usr scratch Nov 13 09:47:55 args Nov 13 09:48:08 I meant will start building from scratch Nov 13 09:54:00 RP build fine Nov 13 09:54:26 patch seems ok besides some minor nitpicking about new mixed spaces/tabs and trailing whitespaces :) Nov 13 09:55:12 where would I check if dbus-daemon was correctly installed? Nov 13 09:55:44 RP: spaetz: I could build it yesterday, without this last commit..how? Nov 13 09:56:22 tmp/staging/x86_64-linux/usr/bin/dbus-daemon exists Nov 13 09:56:47 ant_work: don't ask me... Nov 13 09:57:00 spaetz: it will be a wrapper script though Nov 13 09:57:07 RP, nope Nov 13 09:57:21 spaetz: ah, which version of libtool is on your build system? Nov 13 09:57:38 * RP suspects 1.5.x? Nov 13 09:57:43 file tmp/staging/x86_64-linux/usr/bin/dbus-daemon Nov 13 09:57:44 tmp/staging/x86_64-linux/usr/bin/dbus-daemon: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Nov 13 09:58:16 spaetz: That sounds like it installed correctly Nov 13 09:58:40 local host libtool? 2.2.6a-4 Nov 13 09:58:46 (ubuntu karmic) Nov 13 09:59:33 spaetz: hmm, there goes that theory :) Nov 13 10:00:13 libtool-native: libtool-native 0:2.2.4-r25.0 0:2.2.6a-r25.0 Nov 13 10:00:25 (from b -s) Nov 13 10:00:27 bb -s Nov 13 10:00:48 spaetz: just run "libtool --version" on a bash prompt Nov 13 10:00:59 but I guess that is 2.2.6a-4 Nov 13 10:01:08 ltmain.sh (GNU libtool) 2.2.6 Nov 13 10:01:08 hm 8k packages for beagleboard-demo-image Nov 13 10:01:12 not bad Nov 13 10:01:26 I don't know what governs when it uses a .libs directory or not Nov 13 10:01:32 weird, yes Nov 13 10:01:34 The point it if it uses one it breaks Nov 13 10:02:12 rp depends on Makefile.am Nov 13 10:02:27 if you have _la stuff in it normaly uses .lib Nov 13 10:02:57 woglinde: but this is the same makefile? :) Nov 13 10:04:03 but seems to work now Nov 13 10:04:07 or not? Nov 13 10:04:28 woglinde: It will work now as I've hit dbus with a large stick ;-) Nov 13 10:06:36 btw, I think I see how gentoo avoids tlc dependency for building sqlite3: they overwrite an header Nov 13 10:06:59 ..an autogenerated header (sqlite3.h) Nov 13 10:07:01 needing tlc for sqlite in all cases does seem a bit extreme Nov 13 10:07:20 afaik, libtool will always use a .libs directory when shared libs are in use; the only situation where you can dispense with the wrapper script safely is when all the locally build libs are static. Nov 13 10:07:22 tlc != tcl :-D Nov 13 10:07:29 sob..my nightly build stopped against this... Nov 13 10:07:38 yep Nov 13 10:07:44 spaetz: it's only a build tool, I don't think there is anything too outrageous about requiring it. it's not as if you need tcl installed on the target. Nov 13 10:07:44 tcl Nov 13 10:08:10 this header: http://mirrors.tds.net/gentoo/distfiles/sqlite3.h-3.6.20.bz2 Nov 13 10:08:15 doh Nov 13 10:08:21 * spaetz shuts better up now :) Nov 13 10:08:34 pb_: then we have to update the 'required packages' Nov 13 10:08:46 ant_work: in what way? Nov 13 10:08:51 sqlite3.inc already requires tcl-native in DEPENDS Nov 13 10:09:01 hm... Nov 13 10:09:06 build failed overnight Nov 13 10:09:11 actually, that setting is a bit too conservative since sqlite3.6.16 doesn't actually need tcl, but it doesn't hurt too much to have it in there Nov 13 10:10:05 pb_: ah, yes, a new failure...http://tinderbox.openembedded.net/public/logs/task/3537090.txt Nov 13 10:10:48 ant_work: yes, we had that too Nov 13 10:10:50 ah, that is the thing that GNUtoo mentioned yesterday Nov 13 10:10:56 it creates libtcl8.4.so but not libtcl8.4.so.0 Nov 13 10:11:01 it seems as though oe_libinstall is malfunctioning for some reason Nov 13 10:11:08 and symlinks Nov 13 10:11:16 s/and/no/ Nov 13 10:11:21 but, it works for me so I can't really suggest much. Nov 13 10:11:39 There is a report of that on the mailing list too Nov 13 10:11:39 someone who is experiencing that problem needs to debug it. it should be fairly simple, oe_libinstall is a straightforward shell function Nov 13 10:11:58 well, maybe not all that straightforward, but it is just a shell function Nov 13 10:12:07 pb_: :) Nov 13 10:12:08 RP: yes, bluelightning and me were looking at sqlite3 Nov 13 10:12:16 with enough grep and sed magic to make my head spin :) Nov 13 10:12:25 koen uggested to add the dep from tcl-native iirc Nov 13 10:12:30 but... Nov 13 10:12:42 we are discussing now :D Nov 13 10:13:24 I don't think tcl uses libtool, so you can ignore most of the complexity in oe_libinstall Nov 13 10:13:34 he..I missed the fact he actually added the dep Nov 13 10:13:44 commit 393f6e2d3d5adf59392384b68a032d65abeb1dd3 Nov 13 10:15:40 dbus-native is still missing libsm-native dependency? Nov 13 10:17:12 Jay7: ah, I know this one. Needs http://git.pokylinux.org/cgit.cgi/poky/commit/?h=master-work-in-progress&id=fddfe5ddf3fcc9da1da47a1584b17b4ae9a5b00f Nov 13 10:17:34 hm.. Nov 13 10:17:35 JaMa: ^^^ was meant for you Nov 13 10:17:37 :) Nov 13 10:17:42 Jay7: sorry :) Nov 13 10:17:50 JaMa: and http://git.pokylinux.org/cgit.cgi/poky/commit/?h=master-work-in-progress&id=084766c68f440573249e17a50c457aae98d30832 Nov 13 10:17:57 ant_work: afaik sqlite is using tcl for documentation only Nov 13 10:18:14 Jay7: it uses it to build at least one header too Nov 13 10:18:19 omg.. Nov 13 10:18:20 he .. doc is another useflag Nov 13 10:18:26 crazy sqlite.. Nov 13 10:18:48 RP: will try, thanks Nov 13 10:19:38 we should ask eFfeM ...he brilliantly solved the mysql issues :D Nov 13 10:20:11 this one would be a piece of cake ... Nov 13 10:20:50 RP: after second patch dbus-native PR should be also bumped or INC_PR Nov 13 10:29:21 RP: I still need libsm-native dependency with libaudit disabled, otherwise I'll end with /usr/lib64/libSM.so: undefined reference to `uuid_unparse_lower@UUID_1.0' Nov 13 10:35:57 where does bitbake cache the svn version of a package he has fetched (that makes it keep downloading the same version for the same day) ? can we clear it ? Nov 13 10:36:42 longfield archivedir/svn Nov 13 10:37:26 JaMa: Can you doubt check it was actually disabled? Nov 13 10:38:15 woglinde: thanks Nov 13 10:38:26 JaMa: double check Nov 13 10:38:45 longfield or archive-dir/packag_svn_version_tar Nov 13 10:39:30 trunk_opkg.googlecode.com_.svn_209_.tar.gz Nov 13 10:39:34 for instance Nov 13 10:39:42 woglinde: I have removed both, but it keeps download the same (old !) version Nov 13 10:40:52 if I go to the trunk svn dir in archive-dir, do svn up there, then it updates back to the old version ... X( Nov 13 10:40:58 JaMa: hmm, maybe you're right. can you see which line pulls that in in the config.log Nov 13 10:41:20 RP: checked its in log.do_configure and also in run.do_configure Nov 13 10:41:24 JaMa: DBUS_X_LIBS I guess Nov 13 10:41:31 RP: yes.. Nov 13 10:41:51 RP: but if removed from DBUS_X_LIBS manually after do_configure it compiles fine.. Nov 13 10:42:14 RP: and if libsm-native is installed it compiles fine too Nov 13 10:43:36 JaMa|Lunch: For the -native version we should just be disabling X Nov 13 10:44:55 rp good idea Nov 13 10:50:08 hm okay pam bailsout for uclibc Nov 13 10:50:09 thats okay Nov 13 10:55:55 args where khem patch for this is gone Nov 13 10:57:12 hm Nov 13 10:57:13 okay Nov 13 11:05:18 In mount.sh for udev I tried adding a script like so: RUN+="/etc/udev/scripts/mount.sh" RUN+="/apps/softwareupgrade_checkusbdrive", but it doesn't seem to run the script. Am I doing this wrong? Nov 13 11:05:44 tasslehoff did you test the script by hand? Nov 13 11:06:51 woglinde, now I did, and it works :) Nov 13 11:06:57 okay Nov 13 11:07:03 ah, so, I can reproduce the tcl-native thing now Nov 13 11:07:05 so thats not the problem Nov 13 11:07:17 gogo pb Nov 13 11:07:21 it isn't oe_libinstall's fault, tcl-native itself is naming the lib wrongly in its build dir Nov 13 11:07:33 haha lol Nov 13 11:07:39 -rwxr-xr-x 1 pb pb 3586006 2009-11-13 11:00 tmp/work/x86_64-linux/tcl-native-8.4.19-r2/tcl8.4.19/unix/libtcl8.4.so Nov 13 11:07:46 as distinct from the non-native one, which is correct: Nov 13 11:07:46 tcl-native is wrong for micro too Nov 13 11:07:53 installs into usr/bin Nov 13 11:07:56 and stuff Nov 13 11:08:05 -rwxr-xr-x 1 pb pb 577735 2009-11-12 21:10 tmp/work/armv5te-oe-linux-uclibceabi/tcl-8.4.19-r2/tcl8.4.19/unix/libtcl8.4.so.0 Nov 13 11:08:11 ah, well, that's a separate problem Nov 13 11:08:14 patches welcome :-) Nov 13 11:08:29 jupp Nov 13 11:08:41 le me finish beagle demo board Nov 13 11:08:56 maybee its the prefix_native too Nov 13 11:09:23 hm still this libintl stuff Nov 13 11:09:25 NOTE: Couldn't find shared library provider for libintl.so Nov 13 11:10:24 pb_: So why did this problem only appear now? Nov 13 11:10:49 JaMa|Lunch: http://git.pokylinux.org/cgit.cgi/poky/commit/?id=96ece54fa3268d08bb07bedd8eb31493eed020d3 Nov 13 11:10:50 RP: I'm not sure yet. Possibly it's always been broken and it has only just come to prominence because sqlite started depending on tcl-native. Nov 13 11:11:16 pb_: and why does it work for me or did for you? Nov 13 11:11:20 RP: prior to about three days ago, I suspect that tcl-native was something of a fringe interest and I would not be surprised if it had been broken for ages without anybody noticing. Nov 13 11:11:27 hms policy-kit nex Nov 13 11:11:32 RP: in my case it was because I had finger trouble and was looking at the wrong package :-} Nov 13 11:11:46 woglinde, I added it to local.rules. Nov 13 11:11:49 RP: I was looking at the target copy of libtcl, not the native one. Nov 13 11:12:11 pb_: I guess I could just have a version installed on my system which masks the problem Nov 13 11:12:17 afaict, the problem is in the tcl.m4 file which decides what SHARED_LIB_SUFFIX to use. I'm poking at that now. Nov 13 11:12:31 RP: yeah, if you have libtcl installed in your host environment then you wouldn't see the error Nov 13 11:12:57 pb_: which I do indeed have Nov 13 11:13:11 exactly, but this is not one of required packages in order to build... Nov 13 11:13:12 righto, that would explain it Nov 13 11:15:12 hm Nov 13 11:15:29 ant_work: I do know this ;-) Nov 13 11:15:29 libpam install the headers under include rather than include/security Nov 13 11:15:48 ant_work: part of fixing something properly is explaining why it works for some people and not others though Nov 13 11:15:50 why nobody build policykit and find that out Nov 13 11:16:21 RP: I appreciate very much you and pb spending time on that (minor ?) issue :) Nov 13 11:17:33 every now and then these kind of problems happen: was qemu, then fortran, then install, now tcl on host Nov 13 11:17:44 different buildhost settings Nov 13 11:18:04 hah Nov 13 11:18:19 it only works for the target copy because there is "mv libtcl8.4.so libtcl8.4.so.0" in the do_install() method. Nov 13 11:18:34 lol Nov 13 11:18:42 BBEXTEND native Nov 13 11:18:51 it kind of looks like the tcl-add-soname.patch is just broken by design Nov 13 11:19:05 it is adding a -Wl,--soname thing to the library final link but it is not making any effort to get the thing installed in the right place. Nov 13 11:19:27 good morning Nov 13 11:19:49 have there been problems with rpath and .so libraries reported lately (in the last two weeks let's say) ? Nov 13 11:19:58 so, anyway, I think the right answer is to teach it to set the SHARED_LIB_SUFFIX there as well, like it does for netbsd. Nov 13 11:20:18 Longfield: that's rather a vague question. I think there are always some problems of that nature reported. Nov 13 11:22:05 well, I don't know ... I have some related absolute path in my executables built along my .so Nov 13 11:22:14 anyway, this sqlite3 is yhe kind of commit which should have been tested a bit more... Nov 13 11:22:53 and some strange NOTES like that: NOTE: Couldn't find shared library provider for ../libasebacore.so Nov 13 11:23:30 and when I try to run an executable, I have something like asebaswitch: error while loading shared libraries: ../libasebacore.so: cannot open shared object file: No such file or directory Nov 13 11:23:47 but the libs are present in /usr/lib Nov 13 11:26:39 and it used to work pretty well, it's new since the last time I updated OE (beginning of the week) Nov 13 11:27:36 wtf libpam uses w3m to build the doku Nov 13 11:29:57 pb_: Sounds like a perfect example of why we shouldn't have separate native and non-native :) Nov 13 11:30:11 yeah Nov 13 11:30:28 hm Nov 13 11:30:31 -r-xr-xr-x 1 pb pb 3586006 2009-11-13 11:29 tmp/staging/x86_64-linux/usr/lib/libtcl84.so.0 Nov 13 11:30:35 close, but no cigar yet Nov 13 11:31:28 oh, that's what TCL_TRIM_DOTS means Nov 13 11:31:28 heh Nov 13 11:32:05 one more time for the cameras then Nov 13 11:38:13 ~lart pam Nov 13 11:38:13 * ibot executes killall -KILL pam Nov 13 11:38:28 oh, drat, now tclsh won't build because it doesn't have the .so link yet. Nov 13 11:38:40 if test ${includedir} = '${prefix}/include' Nov 13 11:38:40 then Nov 13 11:38:40 includedir="${prefix}/include/security" Nov 13 11:38:40 honestly, whose idea was this build system? it's just the pits. Nov 13 11:38:41 fi Nov 13 11:39:34 okay lunch now Nov 13 11:39:43 and buying a new flashloght Nov 13 11:39:48 flashlight Nov 13 11:39:50 till later Nov 13 11:49:27 RP: dbus-native without-x compiles fine (after -c clean libsm-native..) I'll merge your patches from OE and add dbus-native-1.2.14 too Nov 13 11:50:44 woglinde, the udev stuff worked out. problem was just that my logging didn't appear where I suspected :) Nov 13 12:01:05 ant_work: is Italian post always slow? Nov 13 12:05:56 JaMa: ok. Please don't make it default though - there are some changes after dbus 1.2.4 which may cause problems for OE Nov 13 12:06:42 RP: ok Nov 13 12:09:56 03Martin Jansa  07org.openembedded.dev * r2f08fd26b2 10openembedded.git/recipes/dbus/ (dbus-native_1.0.3.bb dbus-native_1.2.1.bb dbus.inc): Nov 13 12:09:56 dbus: disable libaudit for all and X for native packages (from POKY) Nov 13 12:09:56 Signed-off-by: Martin Jansa Nov 13 12:12:09 03Phil Blundell  07org.openembedded.dev * r2d32253aad 10openembedded.git/recipes/tcltk/ (3 files in 2 dirs): tcl: try to fix sundry problems with library staging Nov 13 12:12:13 ant_work: does that work for you? Nov 13 12:14:31 pb_: sorry, can't check here, )'ll test at home later Nov 13 12:15:16 righto Nov 13 12:16:18 RP: did you have any view on that base.bbclass patch for checksums in .bb files? Nov 13 12:16:38 pb_: This would be on the OE list? Nov 13 12:16:44 yeah Nov 13 12:16:57 hrw: usually Italian posr is faster gong from North to South...dunno why :) Nov 13 12:17:08 ant_work: gravity? Nov 13 12:17:14 :D Nov 13 12:17:30 ant_work: I am waiting for package from Italy and it got stuck in Milano ;( Nov 13 12:17:43 yet-another-devboard Nov 13 12:17:44 ah..from Bergamo I suppose... Nov 13 12:18:04 well, there are 30 km btw mckoan and Milan Nov 13 12:18:16 5 lanes Nov 13 12:18:30 pb_: looks ok to me although I would like to teach bitbake about this in due course Nov 13 12:19:00 pb_: poky uses the inbuilt python checksum utils too if they're present Nov 13 12:19:15 ant_work: this is not package from Marco Nov 13 12:19:21 ah, k Nov 13 12:19:31 yeah, using the python checksum bits would be a nice improvement. Nov 13 12:19:31 would have been strange... Nov 13 12:19:43 ant_work: if Marco would have something for me then we will exchange that during oedem Nov 13 12:19:46 might help with kergoth's customers and their rooted machines where md5sum gives bogus answers Nov 13 12:19:46 hej, anyone knows if the FILESPATH variable sould also work on linux kernel recipes? just trying to add a linux-omap-rt recipe that should basically use the casual linux-omap recipce but add the real-time patch (and config things) Nov 13 12:20:19 looks like I need to fix pyhton-native today Nov 13 12:20:33 * Crofton|work tries to remember how to create corefiles .... Nov 13 12:20:58 hrw: once my wife sent to her parents in PL something for Xmas...was delivered mid febryary... Nov 13 12:21:28 o fsck! Nov 13 12:21:45 perhaps was too big box..who knows Nov 13 12:22:54 * ant_work is studying the incidence angle btw arm-wrist and desk....how can I do so many typos else...? Nov 13 12:23:33 Crofton|work: Try stracing it? Nov 13 12:23:57 Crofton|work: There is a report on the mailing list about the same problem Nov 13 12:24:57 hrw: the cherry on the story is, IT. Post bought an express courrier years ago....result is mixed...courrier got slower and Post a bit faster Nov 13 12:25:11 I see Nov 13 12:25:25 rpday and I must have almsot the same setup Nov 13 12:25:39 going to try making a core file Nov 13 12:25:44 then I will try strace Nov 13 12:32:29 Crofton|work: dude, I fixed your xterm bug :-D Nov 13 12:32:42 thanks Nov 13 12:32:58 what is the program to make a backtrace from a core file? Nov 13 12:32:59 st? Nov 13 12:32:59 Crofton|work: if you can run it interactively in the debugger then that'd probably be the easiest way to attack that problem. Nov 13 12:33:31 Crofton|work: it was so simple when I ignored the duff debug on mailing list :-D Nov 13 12:33:38 heh Nov 13 12:33:57 my problem is I never had enough to time to poke at Nov 13 12:34:04 * XorA guesses you and rpday are the only two people who dont use rxvt :-D Nov 13 12:34:05 then we starting updating dev ... Nov 13 12:34:11 heh Nov 13 12:38:45 * DJWillis has ones of those 'why did I pull .dev' days. Nov 13 12:39:58 image creation can fail as there are no DEPENDS on update-alternative-native which is needed to create an image Nov 13 12:40:06 we had to manually bake update-alternatives-cworth-native Nov 13 12:40:18 JaMa will send a mail to the OE list Nov 13 12:41:07 ok, more data on python-native crash http://pastebin.ca/1669812 Nov 13 12:46:39 looks like you might have too many libncurseses there. what's that libncursesw? Nov 13 12:47:03 yeah, this is my suspicion Nov 13 12:47:11 dunno what it is though Nov 13 12:47:50 I bet if I removed ncurses-dev from my PC it would work :( Nov 13 12:48:17 ncurses-devel is installed here Nov 13 12:48:44 ah, libncursesw is wide ncurses Nov 13 12:48:56 I suspect that mixing wide and narrow ncurseses in a single binary is probably bad news. Nov 13 12:49:25 where is ncursesw getting pulled in from? Nov 13 12:50:54 re Nov 13 12:50:59 the python-native recips is not that complicated ... Nov 13 12:51:36 python-native works here Nov 13 12:51:41 uclibc/micro Nov 13 12:52:05 prefix = "${STAGING_DIR_NATIVE}/${layout_prefix}" Nov 13 12:52:11 does this look funny? Nov 13 12:52:19 yes Nov 13 12:54:29 buildinghost i686 Nov 13 12:54:41 some python is amd64 related Nov 13 12:54:50 args so Nov 13 12:55:01 XorA, you 84 or 32 bit? Nov 13 12:55:12 84 of course :-D Nov 13 12:55:26 those extra 20 make me faster than gentoo Nov 13 12:55:33 XorA: eleet Nov 13 12:55:37 he..keeping spare for safety...nasty Nov 13 12:55:38 *g* Nov 13 12:55:49 didn't layout_prefix change? Nov 13 12:56:26 yeah, it is now defined in terms of ${prefix} Nov 13 12:56:39 so, what you have there will give you a circular definition. Nov 13 12:56:47 I doubt that will produce any useful effect :-} Nov 13 12:57:04 pb_, that is what is in the recipe Nov 13 12:57:14 changing the = to := might be enough to make it work Nov 13 12:57:27 4960 of 8718 Nov 13 12:57:36 depends what it's really trying to accomplish, it's hard to say without studying the recipe in more detail. Nov 13 12:57:57 * Crofton|work stabs in the dark Nov 13 12:58:25 but whatever it was trying to accomplish no longer is happening? Nov 13 12:59:04 Crofton|work: http://www.youtube.com/watch?v=exsniB-P9Ww Nov 13 13:00:12 recalcati: hi Nov 13 13:01:39 well, that did not help Nov 13 13:01:44 hi hrw . I'm writing to mickeyl@linuxtogo.org Nov 13 13:02:36 ok Nov 13 13:10:30 hi zecke Nov 13 13:11:02 jo zecke Nov 13 13:12:17 ~hail git-svn and git rebase Nov 13 13:12:18 * ibot bows down to git-svn and git rebase and chants, "I'M NOT WORTHY!!" Nov 13 13:12:22 woglinde: hi Nov 13 13:12:43 hrw *g* Nov 13 13:12:54 zecke its all broken again Nov 13 13:12:57 *joke* Nov 13 13:13:20 for some it is still broken Nov 13 13:13:22 good morning Nov 13 13:13:25 Crofton|work: Wasn't that removed from python-native? Nov 13 13:13:32 no Nov 13 13:13:42 hi mckoan Nov 13 13:13:51 RP, you suggest I try that? Nov 13 13:14:23 * Crofton|work grasps at straws ... Nov 13 13:14:34 hi woglinde, any news from Robert? Nov 13 13:14:50 mckoan no Nov 13 13:14:59 I hope I will see him on monday Nov 13 13:15:11 woglinde: no news, good news :-D Nov 13 13:15:19 Crofton|work: I thought there was a commit where that was removed. Yes, I'd try that if it isn't gone already Nov 13 13:15:32 no commit, I am up to dat Nov 13 13:15:40 rp maybee only in poky? Nov 13 13:15:46 rofl Nov 13 13:15:58 nope still fails Nov 13 13:16:06 crofton hm Nov 13 13:16:11 differently Nov 13 13:16:19 hm? Nov 13 13:16:22 | gcc: unrecognized option '-R/usr/lib64' Nov 13 13:16:22 | gcc: unrecognized option '-R/usr/lib64' Nov 13 13:16:23 post error? Nov 13 13:16:29 lol Nov 13 13:16:33 then cores Nov 13 13:17:11 Crofton|work: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=52aea4b0c5d14a3c5f0dfaa8f24ae96286701ca6 ? Nov 13 13:17:38 hm Nov 13 13:17:47 Crofton|work: I'm worried you don't have that :/ Nov 13 13:18:13 qgit is fine for quick searching Nov 13 13:19:21 crap Nov 13 13:19:30 I was browsing in my stable checjkout Nov 13 13:19:38 uh Nov 13 13:19:49 ok Nov 13 13:19:54 so I still have that problem Nov 13 13:20:20 hi mckoan , I see eodem, seems nice. I have to read some articles about it, I hope!!!! Nov 13 13:20:56 ok, the problem is still there, I was just looking at wrong file Nov 13 13:21:03 did you establish which binary actually contains the linkage with that libncursesw? Nov 13 13:22:22 funnily enough my ncurses-native doesn't appear to have staged anything, so python is running with my regular host ncurses. heh. Nov 13 13:22:22 no Nov 13 13:22:37 pb_: hmm, that is possibly what is going wrong Nov 13 13:23:06 Although my ncurses-native looks ok Nov 13 13:23:10 RP: yeah, that certainly doesn't seem right. I don't quite understand where the wide curses thing is coming from in the first place though. Nov 13 13:23:18 I'm gonna rebuild ncurses-native and see what happens. Nov 13 13:23:28 Crofton|work: okay. well, that would probably be a place to start. Nov 13 13:23:42 I don't have an ncursesw dependency at all in there. Nov 13 13:23:48 at least, not obviously. Nov 13 13:23:59 anyone knows why FILESPATH does not work when used in a linux kernel recipe ? Nov 13 13:24:09 mlip: in what way does it "not work"? Nov 13 13:24:12 I have ncurses.h in staging Nov 13 13:24:22 pb_: Id be interested to see if your rebuild works Nov 13 13:24:44 and libncurses Nov 13 13:24:59 pb_: if I understand it right, I can use this variable to adjust the filesdir to be for example the one used for omap. i.e. FILESPATH = "${FILE_DIRNAME}/linux-omap-${PV}" Nov 13 13:25:22 but /lib64 has ncurses and ncursesw in it Nov 13 13:25:51 pb_: using this approach i thought i could fork a kernel recipe using the already existing patches Nov 13 13:26:20 RP: yeah, after a rebuild I now have libncurses.so.5 in staging. dunno what happened previously, I might have damaged the tree through some careless action. Nov 13 13:26:31 I don't have the wide one, though, just the narrow one. Nov 13 13:26:36 pb_: actually when doing -cconfigure the defconfig is not found. could it be that the machine directories are not considered when changing the filespath? Nov 13 13:26:44 which I think is expected, we don't have a recipe for wide curses as far as I know Nov 13 13:27:18 I am wondering if the recent changes allowed Python to pick up the wide version from the build machine Nov 13 13:27:28 hi recalcati Nov 13 13:27:37 yeah, it seems that way. Nov 13 13:28:03 pb_: http://www.linuxfromscratch.org/lfs/view/6.5/chapter06/ncurses.html Nov 13 13:28:03 as I say, the best way to understand what is happening would be to find out what library or binary actually contains the libncursesw linkage and then work back from there. Nov 13 13:28:14 seems --enable-widec Nov 13 13:28:35 ant_work: right, but we don't have any recipe that uses that flag Nov 13 13:28:38 at least, not to my knowledge Nov 13 13:28:48 pls read the NOTE Nov 13 13:29:04 The instructions above don't create non-wide-character Ncurses libraries since no package installed by compiling from sources would link against them at runtime. ?? Nov 13 13:29:23 indeed Nov 13 13:29:33 I don't quite understand the point you're trying to make. Nov 13 13:29:49 is it possible to compile without wide? Nov 13 13:29:57 do the rest link? Nov 13 13:30:00 yes, you just don't use --enable-widec Nov 13 13:30:42 forgive me, I've never scratched under ncursed hood Nov 13 13:34:08 Idle question, has anyone built FLAC recently (independent of DISTRO)? I assume it's failing as a result of the recent rework but I can't see how that would suddenly break the do_compile on my box so wondered if anyone else was getting good builds. Nov 13 13:34:38 hi dj willis Nov 13 13:34:47 DJWillis: trying now for angstrom/armv5te Nov 13 13:35:23 XorA: thanks for taking the time on xterm Nov 13 13:35:37 hrw: thanks, just wondering if it's local to me as it's an odd one. Nov 13 13:35:43 pb_: any hint on the filespath issue ? Nov 13 13:35:55 zecke: it was only 30s before I came to work this morning, suddenly actually reading the script the bug was clear Nov 13 13:36:21 Am I also right in thinking that autotools_stage_all can go with the recent rework (or will be going)? Nov 13 13:36:24 mlip: it's hard to say from the description you gave above. if your FILESPATH was the problem then I would have expected you to get a failure during do_fetch(), not during do_configure. Nov 13 13:36:55 XorA: nothing like a good mailing list thread to get it so far off the mark ;-) Nov 13 13:37:05 hi woglinde Nov 13 13:37:18 DJWillis: we were about to assault the fortress of the NSA for writing SElinux :-D Nov 13 13:37:28 pb_: sorry, do_unpack failed, when i was doing do_configure ;/ Nov 13 13:37:45 DJWillis: NOTE: Running task 487 of 487 (ID: 0, /home/hrw/devel/oe/openembedded/recipes/flac/flac_1.2.1.bb, do_build) Nov 13 13:38:01 Crofton|work: currently doing a BFS Nov 13 13:38:05 XorA: it was heading to 'tar, feathers and pitchforks' ;-) Nov 13 13:38:39 wtf is sucking in ncurses .... Nov 13 13:39:15 haha Nov 13 13:39:17 32bit Nov 13 13:41:11 http://pastebin.com/m7c1e6999 , basically i wanted to fork omap-2.6.31 and additonally applying the real-time patches. because I didn't want to copy the old patches directory, I thought i just could refer to it Nov 13 13:41:44 mlip look at FILESPATH Nov 13 13:41:50 or grep Nov 13 13:41:59 in recipes Nov 13 13:42:48 or better put SRC_URI_MYMAHCINE += " fille:///;patch" into the normal recipe Nov 13 13:43:23 or make a new var which sys USE_REALTIME = "yes" Nov 13 13:44:06 any examples on such USE_... things ? i used FILESPATH, but it didn't work Nov 13 13:44:21 USE_NLS Nov 13 13:44:31 and gettext.bbclass Nov 13 13:46:57 oke, on the FILESPATH thing: it seems that usually bibtake looks in machine specific dir for the defconfig Nov 13 13:47:07 i think this is not the case when manually adjusting FILESPATH Nov 13 13:47:35 better use the USE_REALTIME approach Nov 13 13:48:13 i will try Nov 13 13:48:47 I'm not sure we want to go down that path Nov 13 13:49:18 crofton? Nov 13 13:49:30 ? Nov 13 13:49:33 seeting flags to control what options are in kernels Nov 13 13:50:03 without the patch Nov 13 13:50:07 no options Nov 13 13:50:20 and its locally for him Nov 13 13:50:24 so I see no problem Nov 13 13:51:04 well, i would've also sent it to the mailing list if it works; and since i have seen some recipces go the fork route when adding specific features, I thought i would just fork the kernel recipce Nov 13 13:52:14 maybe if your using USE_REALTIME munge the PN to make it clear it's a new package for a RT kernel? Nov 13 13:54:16 any thoughts on how I can find who is sucking in libncursesw? Nov 13 13:54:20 mlip: forking just for that certainly doesn't seem like a very good plan. Nov 13 13:54:37 Crofton|work: run readelf on each binary in turn until you find the one that has a NEEDED entry for that library Nov 13 13:55:12 mlip: but, looking at your recipe, I think the problem you are having with FILESPATH is that you are clobbering the old value entirely rather than prepending to it. Nov 13 13:55:31 pb_: so I would create an appropriate bbclass file that adds everything to linux-omap_2.6.31 recipce ? Nov 13 13:55:40 you might also consider setting FILESPATHPKG rather than FILESPATH directly. Nov 13 13:56:13 pb_: don't know whats the 'right' approach here then ;) Nov 13 13:56:42 pb_: thought I dont mess with the actual linux-omap reipce Nov 13 13:56:46 mlip: well, I tend to agree with woglinde that some kind of realtime flag in DISTRO_FEATURES would be the nicest way of solving that problem. after all, realtime is a (fairly) generic patchset that can be applied to any machine: it isn't really specific to yours. Nov 13 13:57:03 it'd be a bit sucky if we ended up with a forked realtime copy of every kernel recipe Nov 13 13:57:26 pb_: oke, then I'll try to investigate how to do that Nov 13 13:57:30 the more general case is a flag for every defconfig change people can think off Nov 13 13:58:17 pb_: since DISTRO_FEATURES is not mentioned in the handbook, any starting point ? Nov 13 13:58:41 mlip: I can't think of a good example offhand but I imagine grep will find one for you. Nov 13 13:58:49 k Nov 13 13:58:50 Is there a way to debug things when "module_autoload_*" doesn't work at all? Nov 13 13:59:44 spaetzWork: surely there is. Nov 13 13:59:55 there is always a way to debug things :-} Nov 13 14:00:02 hehe :P Nov 13 14:00:02 what do you mean by "doesn't work at all"? Nov 13 14:00:36 do you mean that the file in /etc/modutils doesn't get created, or that the postinst isn't created/is broken? Nov 13 14:00:49 or that it just doesn't get loaded at runtime despite the above being correct? Nov 13 14:01:04 well, I added "module_autoload_snd_soc_neo1973_gta02_wm8753 = "snd_soc_neo1973_gta02_wm8753"" to om-gta02.conf for example Nov 13 14:01:13 in conf/machine/om-gta-02.conf Nov 13 14:01:31 and it's just not loaded and /etc/modutils doesn't contain any references either Nov 13 14:01:53 JaMa has previously tried the same thing with g_ether and apparently it didn't work for him either Nov 13 14:02:08 do any autoloads work for you? Nov 13 14:02:41 args powertop installs into /usr/bin too Nov 13 14:02:45 next package to fix Nov 13 14:02:49 *sigh* Nov 13 14:02:50 there are no other autoloads in that machine conf. I just discovered that we hackishly add stuff in the image creation. Nov 13 14:02:52 is kernel-module-snd-soc-neo1973-gta02-wm8753 actually getting installed correctly? Nov 13 14:02:55 ugly ugly ugly Nov 13 14:03:10 Crofton: qemu-arm is broken for me :-( Nov 13 14:03:26 how so? Nov 13 14:03:27 so I'll try to add other autoloaded modules and report back. Just wanted to know if there is a quick fix :) Nov 13 14:03:38 mmap perm denied? Nov 13 14:03:42 Crofton|work: bails when doin glocals Nov 13 14:03:49 Crofton|work: no error messages Nov 13 14:04:00 look for mmap perm denied Nov 13 14:04:00 Crofton|work: no selinux messages either Nov 13 14:04:03 selinux enforcing? Nov 13 14:04:07 urg Nov 13 14:04:12 stable is working for me Nov 13 14:04:36 python native is pissing me off, may go work on sane branch for a bit Nov 13 14:05:03 hm seems everyone is pissed Nov 13 14:05:07 Crofton|work: ah might be a newer selinux has undone me Nov 13 14:05:18 Crofton|work: I can see some errors back in the logs Nov 13 14:05:39 setsebool -P allow_unconfined_mmap_low 1 Nov 13 14:05:47 is needed Nov 13 14:06:17 looking at 4 wgets the same time is funny Nov 13 14:07:17 hi cbrake Nov 13 14:09:01 Crofton|work: that should have been set, but must have been lost in selinux upgrade Nov 13 14:09:09 yeah Nov 13 14:09:22 I have a bad feeling I lost some otehr stuff in one Nov 13 14:10:00 but apparently not :) Nov 13 14:11:14 and BFS is off again Nov 13 14:12:08 hm all tasks create empty image dir Nov 13 14:12:13 and packaging complains Nov 13 14:17:48 woglinde: friday 13th Nov 13 14:30:05 morning Nov 13 14:31:43 pb_ present ? Nov 13 14:34:58 If anyone wants to make a short talk on something cool they have done on omap3 watch this: Nov 13 14:35:00 http://www.youtube.com/watch?v=w6PKytPI5Mk Nov 13 14:35:39 morning Nov 13 14:35:51 g'day kergoth Nov 13 14:35:58 hey pb_ Nov 13 14:36:51 morning kergoth, MV still quiet post-buyout? Nov 13 14:47:49 morning kergoth Nov 13 14:50:46 DJWillis: yep, no changes thus far Nov 13 14:50:49 * kergoth yawns Nov 13 14:53:07 zecke: ping Nov 13 14:53:20 kergoth: aloha Nov 13 14:54:24 zecke: thoughts on squashing some of the commits on parser-rework before pulling it into 1.10? like merging the commits that move bits from feeder -> functions, and the ones that move the functions into the ast, and the ones that convert the functions to classes. was thinking we probably don't need to see each step from the development process after pulling it over :) Nov 13 14:56:19 kergoth: it depends, are we confident the conversion is correct? the one by one has helped me a lot with tracking regressions Nov 13 14:56:32 kergoth: if we don't need it, we can squash Nov 13 14:57:29 kergoth: e.g. if you want to drive and merge it into 1.10 then go ahead Nov 13 14:58:45 zecke: are you content with the checksums patch that I posted yesterday? if you have no objection then I will go ahead and commit that to the .dev branch. Nov 13 14:58:52 zecke: Did you generate any performance tests btw? Nov 13 14:59:31 RP: no, but I asked people to benchmark it, Stefan Schmidt posted some benchmarks Nov 13 15:00:08 pb_: posted that within the checksum thread Nov 13 15:00:17 zecke: indeed Nov 13 15:03:50 pb_: looks good Nov 13 15:04:16 ugh, i need more caffeine Nov 13 15:04:45 zecke: the code looks good to me, but perhaps can do pre-post metadata comparisons again just to be safe Nov 13 15:04:55 pb_: two comments though. Nov 13 15:05:11 pb_: First one, did you consider moving the verify code into a common method? Nov 13 15:05:57 pb_: Second one, the error message still refers to checksums.ini, I assume that the new syntax will be the preferred form and the error message should be updated Nov 13 15:06:06 zecke: oh, one quick thing i wanted to run by you. currently, it delays inclusion/inherit until eval() time. i was thinking the inclusion/inherit could happen immediately and give a new StatementGroup to include in the other StatementGroup Nov 13 15:06:20 zecke: thoughts? Nov 13 15:06:22 zecke: hm, which error message is that? Nov 13 15:06:27 * kergoth downs mt dew Nov 13 15:06:38 zecke: merging the verify code sounds like a good idea, I will do that this afternoon Nov 13 15:07:19 pb_: inside the actual fetch method, you have patched two lines there (use the params) and add a new method invocation Nov 13 15:07:39 oh, right, I see Nov 13 15:07:44 the "has no entry in checksums.ini" one Nov 13 15:07:48 yeah, good point, I will fix that too Nov 13 15:07:57 zecke: thanks Nov 13 15:07:57 kergoth: the problem comes with include ${PV}.inc... only at eval I know which file to open Nov 13 15:08:02 * pb_ heads home Nov 13 15:08:09 pb_: great Nov 13 15:08:10 ahh, good point. that's annoying :) Nov 13 15:08:13 okay then Nov 13 15:08:13 bbiab, gotta go deal with a childcare issuette Nov 13 15:08:19 me heads to the gate Nov 13 15:09:30 RP: the question with the speed is more like memory... currently my "cache" of .inc files is a [] and it only grows Nov 13 15:10:48 RP: a finite cache is a good idea as most ".inc" files are either local (while in the recipes/foo dir) or global Nov 13 15:11:55 zecke: hmm, that is an intersting one Nov 13 15:12:26 hmm Nov 13 15:13:05 RP: the memory difference was not that big.. but a LRU cache would be the best Nov 13 15:13:13 anyway, cya :) Nov 13 15:19:02 good mornin Nov 13 15:20:30 morning Nov 13 15:20:34 Good Morning folks. Nov 13 15:20:44 SlugOS image built fine over night :) Nov 13 15:20:49 Packages didn't though. Nov 13 15:20:50 cool Nov 13 15:21:36 Sooo... what's the deal with python-native? and sqlite3? Anyone else having trouble with those (in which case I'll not duplicate effort)? Nov 13 15:25:55 gcc: unrecognized option '-R/usr/lib64' Nov 13 15:27:14 mwester: sqlite3 should be fixed by the tcl-native fix Nov 13 15:27:23 Followed by a segmentation fault :( Nov 13 15:27:46 RP: Ok, then I'll pull again and see what builds :) Nov 13 15:27:57 But python looks messed up. Nov 13 15:28:49 mwester: What was noticed so far as possibly some kind of corruption with finding the host's ncurses Nov 13 15:28:57 mwester: but it works for some of us :/ Nov 13 15:29:35 mwester: I don't have a /usr/lib64 though Nov 13 15:30:14 Well, my fast build machine does. I could try it on the other (32-bit) system, but that would suck. Nov 13 15:30:29 I'd at least have some logs I could compare, though. Nov 13 15:38:10 it isnt a 64 bit problem Nov 13 15:41:21 mwester, yeah busted for me Nov 13 15:41:29 but I am ticked off and working on something else Nov 13 15:42:24 This bodes poorly for me. If you've gotten ticked off by it, there's little chance I'll be able to fix the issue. :( Nov 13 15:42:39 XorA: thanks - I'll waste no time on that red herring then. Nov 13 15:43:52 well Nov 13 15:44:03 part of the problem is getting nothing done all week Nov 13 15:44:16 so I am trying to get some old stuff of mine building in sable Nov 13 15:44:23 which is its own can of works Nov 13 15:44:26 worms Nov 13 15:44:28 hmm; is there a reccommended method to creating bitbake recipes for my own code? Nov 13 15:44:36 looking at updating omniorb atm Nov 13 15:45:42 tzanger: vim? ;) Nov 13 15:46:20 tzanger, look on gumstix.net I think there are some suggestions there Nov 13 15:46:36 kergoth: smartass. :-) Nov 13 15:47:08 Crofton|work: can you tar up your failing python-native workdir and share it somewhere? Nov 13 15:47:59 yep Nov 13 15:49:14 the version of omniorb in oe is seriously ancient .... Nov 13 15:49:37 I thought ORBs were dead, I killed them Nov 13 15:50:48 not yet Nov 13 15:51:03 zombie ORBs? Nov 13 15:51:40 I did my dissertartion on them back in 97 Nov 13 15:52:16 RP, http://balister.dyndns.org:8008/~balister/busted-python-native.tgz Nov 13 15:54:08 Crofton|work: thanks, I'll take a look and see if I can figure this out Nov 13 15:55:03 my BFS has passed python-native on what should be pretty identical machine to Crofton|work :-( Nov 13 15:55:21 I poked about with readelf, but couldn't see any reason to suck in libncursesw Nov 13 15:55:45 well, looks like it hits mwester and rday Nov 13 15:55:59 I need to get ready for soem errands Nov 13 15:56:05 so like xterm could be something extra you 3 installed Nov 13 15:56:15 on the host? Nov 13 15:56:35 or in OE? Nov 13 15:56:42 http://tinderbox.openembedded.org/public/logs/task/3560778.txt Nov 13 15:56:44 the xterm failure was triggered by xterm installed on the host Nov 13 15:56:47 anyone see this b4? Nov 13 15:56:54 (in stable) Nov 13 15:56:58 weird Nov 13 15:57:00 Do people really have hosts without xterm?? Nov 13 15:57:09 bye guys, have a nice weekend Nov 13 15:57:17 (my servers all have X installed, even if they are headless) Nov 13 15:57:23 mwester: no distro installs it be default anymore Nov 13 15:57:31 * mwester is surprised Nov 13 15:57:49 darn, you're right. Nov 13 15:58:00 mwester: its no longer part of Xorg Nov 13 15:58:18 It's not installed on my buildhost... I wonder what the term emulator actually is, then? Nov 13 15:59:14 * mwester digs to see if it's installed but not in the default path Nov 13 16:01:58 Nope, no xterm on my buildhost -- it's a fedora 10 x64 system, BTW. Nov 13 16:02:21 konsole or gnome-terminal, usually Nov 13 16:02:31 * kergoth uses rxvt-unicode, personally Nov 13 16:02:32 :) Nov 13 16:13:30 Crofton|work: That file was huge as it wasn't compressed ;-) Nov 13 16:14:39 urg Nov 13 16:14:46 sorry Nov 13 16:14:52 I did cvf not czf Nov 13 16:15:03 did you see the note on the list Nov 13 16:15:21 I had been poking at that avenue, but culdn't find the libnursesw linkage Nov 13 16:15:48 I'll be out for a couple hours Nov 13 16:16:00 and then I need to work on fpga interface the rest of the day Nov 13 16:16:01 Crofton|work: I have a debug patch I need someone to run Nov 13 16:16:04 but i can run tests Nov 13 16:16:19 post to the list, I will be back in a few hours Nov 13 16:16:35 thanks! Nov 13 16:17:22 Crofton|work: bfn Nov 13 16:21:45 This debug patch shows all kinds of problems Nov 13 16:24:34 re Nov 13 16:29:19 pb__: wherey will you inject the checksums in the recipe? After wich field? Pls update oe-stylize.py consequently Nov 13 16:29:42 ant_work: uh, dunno. After SRC_URI I guess, but I don't have much of a view on it. Nov 13 16:29:51 np Nov 13 16:29:56 just do it once :) Nov 13 16:31:12 ah, à propos..why do you refer to URI and not PN for tarballs? Nov 13 16:32:21 hmm. Nov 13 16:32:30 isn't foo.bar_1.0.tar.gz MD5 blah enough? Why was the URI in checksums.ini? Nov 13 16:32:47 just wondering, Genott hasn,t Nov 13 16:32:51 *Gentoo Nov 13 16:33:09 we fetch more than just tarballs, and not all of the files are guaranteed to be unique across all sites and recipes. iirc, that was the logic behind it, anyway Nov 13 16:33:29 ant_work: I don't quite understand what you're asking. Nov 13 16:33:37 not unique = different checksum Nov 13 16:33:55 pb_: i think he wants to know why we use full urls in the checksums.ini Nov 13 16:34:08 * kergoth yawns Nov 13 16:34:27 ah, right Nov 13 16:34:37 yeah, for the reason kergoth said. Nov 13 16:34:44 ^^^ Nov 13 16:35:53 * mwester has wondered that as well -- why would the same PN have different MD5SUMs when stored at different locations on the net? Nov 13 16:36:03 the logic seems a bit flawed to me... Nov 13 16:36:52 re Nov 13 16:36:57 filename+pn would probably be sufficient, yes, assuming no recipe ever fetches the same filename from multiple locations Nov 13 16:37:12 mickeyl: We should talk about python-native ;-) Nov 13 16:37:14 hm only 11 paackages failed Nov 13 16:37:31 first fixing libpam for micro Nov 13 16:40:31 kergoth: for the same reason I don't understand why Gentoo keeps the size of the file in their Manifests :) Nov 13 16:40:55 ok, double-check Nov 13 16:41:01 still... Nov 13 16:41:21 ant_work: i could see that being *potentially* useful for some sort of resuming, perhaps? *shrug*, its pointless as a "is it complete", since the sum gives you that.. Nov 13 16:44:17 mwester: there are patches on the mailing list you could test now Nov 13 16:44:28 Crofton|work: see the mailing list... Nov 13 16:44:31 I just got to that email :) Nov 13 16:44:45 mwester: There is another one coming with a fix Nov 13 16:45:07 mwester: same address, python-hostfix.patch Nov 13 16:45:45 mwester: a before and after with the debug patch applied first would make me feel happier we're fixing the right thing Nov 13 16:52:37 jo jama Nov 13 16:53:19 jo woglinde Nov 13 17:06:39 RP: patch works. Debug before and after shows no more references to /usr/lib and /usr/lib64 Nov 13 17:10:15 nice w/e Nov 13 17:11:53 mwester: cool, I'll wait for mickey to make the final call on that patch Nov 13 17:23:26 03Phil Blundell  07org.openembedded.dev * rca68e0eeba 10openembedded.git/classes/base.bbclass: base.bbclass: add support for checksums in .bb files Nov 13 17:23:47 oh that was fast Nov 13 17:23:50 hi esben Nov 13 17:24:33 hm why beagleboard mesa is stuck at 7.0.2 Nov 13 17:26:03 seems micro restriction Nov 13 17:26:14 hi, oe_libinstall doesn't work when the build system of the application is broken and has 2 non-symlinks for libtcl8.4.so.0 and libtcl8.4.so Nov 13 17:26:33 gnutoo *g* Nov 13 17:26:42 and oe_runmake install either Nov 13 17:26:45 pb_ fixed it the wohle day Nov 13 17:26:53 ah ok Nov 13 17:27:07 thanks a lot pb_ Nov 13 17:31:34 hm xserver stuff is broken Nov 13 17:31:43 xserver depends on mesa Nov 13 17:31:51 but the newer are mesa-xlib or mesa-dri Nov 13 17:32:29 hm I think mesa should be virtual too Nov 13 17:32:40 or gl-package at least Nov 13 17:33:08 woglinde: it is virtual/libgl Nov 13 17:33:33 woglinde: check martin_jansa/xorg-7.5 :) Nov 13 17:33:41 meh Nov 13 17:33:45 i can't concentrate worth a damn today Nov 13 17:33:51 03Phil Blundell  07org.openembedded.dev * r1f986867b6 10openembedded.git/classes/base.bbclass: fix c&p error in last patch Nov 13 17:34:01 03Phil Blundell  07org.openembedded.dev * r4babfdd621 10openembedded.git/ (conf/checksums.ini recipes/busybox/busybox_1.14.3.bb): busybox_1.14.3: move checksum to bb file Nov 13 17:34:04 kergoth: doh, too much mountain dew? Nov 13 17:34:19 JaMa I am talking about dev Nov 13 17:34:24 if one can is too much, something is wrong :) Nov 13 17:34:30 heh Nov 13 17:34:30 not the branches which will be merged in few months Nov 13 17:34:34 more likely its because its friday.. :) Nov 13 17:34:38 but maybee its only a micro problem Nov 13 17:34:48 * kergoth thinks about bb.fetch Nov 13 17:34:56 woglinde: but virtual/libgl exists in few places already in .dev Nov 13 17:34:57 which should include the right preferred xversion stuff Nov 13 17:35:26 pb is it okay to include preferred-xorg-versions-X11R7.4 or 7.5 into micro? Nov 13 17:35:29 woglinde, I'll test it...I had patches for building the newer Xorg not for openmoko for SHR merge but they were lost with a git reset hard...but anyway there were easy to reproduce... Nov 13 17:35:52 woglinde: sure Nov 13 17:35:56 okay Nov 13 17:35:58 woglinde: 7.5 in .dev isnt 7.5... Nov 13 17:36:07 lost means that I didn't care while doing git pull so I did hard reset....I can recreate them Nov 13 17:36:14 jama yes I will take 7.4 Nov 13 17:36:18 as angstrom Nov 13 17:36:55 hm I will do as minimal Nov 13 17:41:56 gnutoo git reflog Nov 13 17:42:04 so you maybee can find them Nov 13 17:42:26 again Nov 13 17:43:07 woglinde, but they were for the intel breakage Nov 13 17:44:08 woglinde, basically I moved the disable intel to be overriden by SHR Nov 13 17:44:20 and some minor things Nov 13 17:45:32 anyway I'll look where I put the git patches for older version Nov 13 17:45:42 you'll have a better idea Nov 13 17:46:51 I modified: Nov 13 17:47:13 ./recipes/dri/libdrm_git.bb and ./recipes/mesa/mesa-dri_git.bb Nov 13 17:48:18 more or less that: Nov 13 17:48:19 http://pastebin.com/m6215525e Nov 13 17:48:50 only that I replaced htcdream by shr in the more recent patches Nov 13 17:54:40 hm why we have libfribidi and fribidi Nov 13 18:00:08 I'll have to go now Nov 13 18:01:04 bye gnutoo Nov 13 18:12:24 hmm. Nov 13 18:13:25 hm ecors fails Nov 13 18:26:19 pulseaudio blows chunks now: Error: selected processor does not support 'pkhbt r0,r3,r2,LSL#16' Nov 13 18:32:23 * kergoth experiments with using git to track changes to a directory, as a possible way of doing better tracking of what tasks do, and/or being able to pop back to a previous task exactly as it was Nov 13 18:33:46 hmm Nov 13 18:34:33 * mwester thinks about the ClearCase mvfs and derived objects. Nov 13 18:39:16 heh, there's something to be said for storing objects in the scm, at least for the build Nov 13 18:39:20 clearmake and stuff comes to mind Nov 13 18:39:57 i was just thinking if we had better tracking, we could allow a "clean" that doesn't wipe the source tree, just reverts it back to pristine Nov 13 18:42:01 03Mike Westerhof  07org.openembedded.dev * r7596dc3367 10openembedded.git/conf/distro/include/preferred-slugos-versions.inc: Nov 13 18:42:01 SlugOS: preferred-slugos-versions.inc - use older pulseaudio version Nov 13 18:42:01 (latest version fails to compile) Nov 13 18:43:31 I agree with that -- and I also think it would greatly facilitate understanding (and therefore debugging) if someone can get a simple answer to the question "what did recipe xyz change in staging?", or "who staged file xyz" Nov 13 18:44:19 git is a fine way to start, although I'm not sure how well it handles binaries. Nov 13 18:44:59 well, we wouldn't necessarily have to keep everything around indefinitely, particularly if its just a tracking repository. if you clean, i could see that forcing the ref back to the old state, so the rest can be freed up in a gc, unless you really want to be able to move back forward again Nov 13 18:47:52 something as simple as http://kergoth.pastey.net/128583, run after each task could be useful, if we had everything in one place, at least. otherwise we'd have to try to get it to pick up multiple dirs contents in some way.. hmm Nov 13 18:48:32 I'm interested in this stuff for the caching possibilities long term. If the input to a task hasn't changed (including toolchain and metadata), we could know we don't have to re-run the task.. Nov 13 18:49:52 :) clearmake "wink-in" Nov 13 18:50:03 :) Nov 13 18:50:20 course, adding better tracking to the metadata is nontrivial Nov 13 18:50:32 but.. baby steps Nov 13 18:50:41 Imagine if we could do that over the net from selected "blessed" buildhosts... that would empower a lot of users to work with OE. Nov 13 18:50:56 Not to mention the commercial users who would really appreciate that sort of a system. Nov 13 18:51:34 MVL6 does prebuilt binaries, but its pretty limited. the prebuilts are packaged staging packages, and their filenames include an md5 sum of the metadata (minus blacklisted entries known to not affect the build), and of course that's the whole recipe, not task level Nov 13 18:52:02 I'm having a few problems with kernel-modules and module_autoload_, wondering if anyone else is Nov 13 18:52:04 even then its a feature people like. the failure case is just a forced rebuild, but if nothing has changed, at least it doesn't have to Nov 13 18:52:24 I like the idea. Nov 13 18:53:17 (but I confess to bias, having worked with clearcase and clearmake for so many years I may "over-appreciate" the benefits of such close tracking of build artifacts) Nov 13 18:53:48 I'd really like to see better traceability of our builds, better bill of materials emission, .. Nov 13 18:56:05 * mwester starts a fresh build of the package feeds, and heads off to get some chores done Nov 13 18:56:50 hmm. Nov 13 18:57:46 what if you pointed bitbake to a common OE directory from your project area, and had a tool to "add" recipes to the project.. and anything you add to the project automatically got built when you ran bitbake.. and the "add" actually did the unpack/patch or clone operations directly into dirs relative to $PWD in the project Nov 13 19:05:50 RP, did you find someone to test the python change? Nov 13 19:06:25 comments on the list seemed to indicate that it fixed it Nov 13 19:08:18 ok, I think I'll do real work then Nov 13 19:10:22 I've noticed for some reason, modules added to module_autoload in a machine conf don't seem to have /etc/modutils/ added to the kernel package even on a clean virtual/kernel build. Has this been deprecated ? Or is this not the channel to ask ? Nov 13 19:11:25 dfoley: /etc/modutils should be in the module packages, not the kernel package Nov 13 19:12:23 pb__: sorry, that's what I meant. it does not get put in the module package Nov 13 19:12:38 do you get an "installed but not shipped" diagnostic for it? Nov 13 19:14:59 pb__: no, the only thing I get is something about the modules.order file Nov 13 19:16:05 hm. are the module packages getting the right dependencies applied? Nov 13 19:16:16 if not, that might suggest that the frob_metadata hook just isn't running at all. Nov 13 19:16:37 (it's also what sets the Description, which might be easier to spot than the dependencies.) Nov 13 19:17:15 if you are getting descriptions and depends but no modutils directory, that would suggest that the modutils-adding code in that hook is either broken or out of sync with the rest of the packaging system Nov 13 19:20:02 pb__: the tmp linux image/etc/modutils/ directory does get created with the files for each module corresponding to module_autoload_ Nov 13 19:22:12 ah, righ Nov 13 19:22:13 t Nov 13 19:22:48 that would suggest that the packaging system has changed in some way that kernel.bbclass was not expecting Nov 13 19:22:48 I guess the hook is now getting run too late, or something Nov 13 19:22:50 pb__: every thing used to work not too far back Nov 13 19:23:01 can you pinpoint when it broke? Nov 13 19:23:17 afaik, there has not been a deliberate move to obsolete it, I think this is just accidental damage Nov 13 19:23:47 if you can do a binary chop of the contents of the classes/ directory and figure out what commit caused it to stop working, that might be useful information Nov 13 19:24:39 pb__: I don't know when it broke right no, but I could probably go back and forth to figure it out Nov 13 19:25:07 pb__: yes I can probably do that Nov 13 19:25:16 okay Nov 13 19:25:37 I imagine the offending commit is in classes/package.bbclass, or certainly in classes/ somewhere. Nov 13 19:25:53 luckily those files do not change especially often so there should not be a vast number of commits to bisect. Nov 13 19:27:04 pb__: bye the way there is also a problem when adding "kernel-modules" to MACHINE_EXTRA_RRECOMMENDS. Some modules simply don't get added and some do Nov 13 19:27:47 I guess you mean that they don't show up in the rootfs, right? Nov 13 19:27:56 as opposed to don't actually get added to the variable Nov 13 19:27:58 pb__: correct Nov 13 19:28:18 unfortunately that could be caused by any number of things: opkg failure, packaging errors, ... Nov 13 19:28:32 you'd need to check the opkg log output for clues as a first step Nov 13 19:28:52 pb__: if I comment out "for l in module...." loop in the kernel.bbclass (blacklist) I get all my modules added Nov 13 19:30:07 pb__: as far as I can tell these are 2 separate problems, but I really don't know enough about the inner workings of the package, kernel, and friends classes Nov 13 19:30:19 I think they are two separate problems, yes. Nov 13 19:31:47 pb__: I'll do some re-building and bisecting I guess for now. Thanks for your help Nov 13 19:35:20 cute, got a ${WORKDIR}/.monitor-git which has a commit after each task recording what it did in workdir, with tags pointing at the commit by task name Nov 13 19:35:43 clarson@foul ~/o/p/3/t/w/i/s/.monitor-git> pwd Nov 13 19:35:43 ~/oe/projects/35291/tmp/work/i686-linux/shasum-native-1.0-r1/.monitor-git Nov 13 19:35:44 clarson@foul ~/o/p/3/t/w/i/s/.monitor-git> git log | git shortlog Nov 13 19:35:44 Chris Larson (2): Nov 13 19:35:44 Output from do_unpack Nov 13 19:35:45 Output from do_compile Nov 13 19:37:44 course, its not ideal to only capture workdir.. Nov 13 19:38:59 * kergoth ponders Nov 13 19:46:50 kernel.bbclass seems a bit broken now, can someone confirm my behavior Nov 13 19:48:51 def get_dependencies(file, pattern, format): gets file parametr in form like this: /home/projects/OE/tmpdir-dev-shr/work/om-gta02-oe-linux-gnueabi/linux-openmoko-shr-drm-devel-2.6.29-drm-oe14+gitr3+c848d00bd43c47e7f11724330380e0c68ec7ae5e-r2/package/lib/modules/2.6.29-rc3-drm/kernel/net/ipv6/sit.ko Nov 13 19:49:35 but then in "if module_deps.has_key(file):" is checked against same file but without builddir prefix so something like /lib/modules/2.6.29-rc3-drm/kernel/net/ipv6/sit.ko Nov 13 19:50:15 so "if module_deps.has_key(file):" returns nothing an RDEPENDS for needed modules ins't right then Nov 13 19:51:16 RP: do you have a sec? for ^^ Nov 13 19:54:49 http://kergoth.pastey.net/128586 Nov 13 19:54:51 heh Nov 13 19:58:21 course, tasks running simultaneously would be a problem :) Nov 13 20:03:21 mmm hi Nov 13 20:03:28 NOTE: Update svn://svn.o-hand.com/repos/matchbox/trunk;module=matchbox-panel-2;proto=http => svn: Failed to add directory 'applets': an unversioned directory of the same name already exists Nov 13 20:10:18 gnutoo: remove corespoding dir in downloads.. Nov 13 20:12:21 RP: ping Nov 13 20:13:34 pb__: I have an ugly patch for first problem in kernel.bbclass Nov 13 20:13:54 pb__: missing RDEPENDS entries because of changed layout.. Nov 13 20:14:20 RP: I'm getting a webkit-gtk build failure from a clean top-of-tree build. Seems related to the webkit-1.0.pc file in sysroot-destdir. Nov 13 20:14:57 RP: http://pastebin.com/m9e15421 Nov 13 20:15:21 perhaps similar to some of the issues you fixed yesterday? Nov 13 20:18:55 pb__: and regression is created by 29c7d3351f43678c6e93b707b301832009f64b31 Nov 13 20:20:25 JaMa: righto. I see this was one of RP's patches; it might be best to take it up with him. Nov 13 20:21:43 hmm Nov 13 20:22:30 urgs Nov 13 20:22:31 os.system('cp -pPR %s/* %s/' % (dest, dvar)) Nov 13 20:23:03 heh, whats the urgs for? i like using something like shutil.copytree instead, but cp does get the job done :) Nov 13 20:23:54 system calls should be avoided Nov 13 20:24:11 true. we really need to get some wrappers into the bitbake python module Nov 13 20:24:17 ones that use subprocess under the hood Nov 13 20:24:58 hmmm Nov 13 20:25:07 * kergoth wonders how hard itd be to hack in monitoring of which tasks use which variables Nov 13 20:27:04 JaMa, ok that's what I thought Nov 13 20:27:56 might not be that bad.. monkeypatch bb.data to hook getVar() to store it.. the harder part would be hacking expand() to store what variables were referenced in the expansion Nov 13 20:28:00 hmm Nov 13 20:29:43 hm Nov 13 20:29:46 grep -r os.system * | wc -l -> 44 Nov 13 20:30:26 ow Nov 13 20:30:48 rm_work.bbclass: os.system('rm -f '+ dir) Nov 13 20:30:59 is python really so bad? Nov 13 20:31:08 haha Nov 13 20:31:13 thats terrible Nov 13 20:31:16 unlink() is not hard.. Nov 13 20:31:36 shutil even provides rmtree() Nov 13 20:31:49 package_tar.bbclass: ret = os.system('zcat %s | tar -xf -' % pkgfn) Nov 13 20:32:08 seems some python devs would run and screem Nov 13 20:33:04 TarFile & friends are quite easy to use if you know they exist Nov 13 20:33:13 * kergoth has a do_unpack using them *somewhere* Nov 13 20:33:15 opie.bbclass is worst Nov 13 20:33:18 * kergoth can't seem to find it though Nov 13 20:33:27 os.system( "install -d %s%s%s/" % ( D, palmtopdir, bindir ) ) Nov 13 20:33:36 os.system( "install -m 0755 %s/lib%s.so %s%s%s/" % ( S, APPNAME, D, palmtopdir, bindir ) ) Nov 13 20:33:39 7 times Nov 13 20:34:37 ugh.. if you're going to use that much shell, just make a shell function in the metadata and call it from python.. Nov 13 20:34:38 seems we have enough places to improve Nov 13 20:34:59 what sucks is people copy bad practices, thinking whats there must be worthy of copying.. Nov 13 20:35:03 sadly this is nowhere near the case Nov 13 20:35:18 if I had seen this earlier Nov 13 20:35:26 it would have been topic at oedem Nov 13 20:35:37 death to os.syste, Nov 13 20:35:41 args system Nov 13 20:36:29 in mvl6, i switched everything to use a system wrapper that uses subprocess, to avoid the SIGPIPE issue. better to fix things to use python modules though Nov 13 20:39:10 hm I will start with rm_work.bbclass Nov 13 20:39:15 that should be easy to fix Nov 13 20:40:05 *sigh* os.removedirs(path) New in version 1.5.2. Nov 13 20:40:45 yeah, death to os.system() would be a good topic for a future oedem Nov 13 20:41:17 or, perhaps more generically, death to all practices which impose weird constraints on what you can call your working tree Nov 13 20:41:30 need to work on that title a bit to make it more snappy, though Nov 13 20:42:57 I'd just like us to always take advantage of what functionality our current minimum python version provides to us Nov 13 20:43:01 (pipe dream) Nov 13 20:43:57 that would be nice, yeah Nov 13 20:44:31 http://kergoth.pastey.net/128587 - thoughts? of course, the project.conf bit can be separate from the rest, but i kind of like moving the fetch up a layer and moving the sources to a more accessible location for development Nov 13 20:45:51 yes, that's quite a cute idea Nov 13 20:46:18 might as well just have "bitbake-project add-collection /path/to/oe", I guess Nov 13 20:46:20 course, I'm not sure how such a thing would handle prebuilts, really, since you wouldn't necessarily want to see that source tree.. hmm Nov 13 20:46:24 heh, yeah, true Nov 13 20:47:06 I guess you'd want to have prebuilts (and staging in general) tucked away in ~/.bitbake-project somewhere. Nov 13 20:47:11 this is kind of like what I'd want to see long term, but this way it's not horribly invasive, uses the existing metadata, and opens up the door to adding sources directly to the project which contain their own recipes Nov 13 20:47:19 yeah, probably Nov 13 20:47:55 hm never again I will build beagleboard-demo image Nov 13 20:48:41 but yeah, in general, something like that would be quite cool Nov 13 20:48:56 it'd certainly be good to get away from the ghastly "set BBFILES in local.conf" paradigm Nov 13 20:48:56 heh Nov 13 20:49:04 bitbake can automatically build the packages in BBPKGS if the var is set, so could do this without making huge changes to bitbake.. just the pre-parsing of the project.conf which is independent of the project idea.. do that, then write a project wrapper which also adds a class to INHERIT to manipulate the fetch/unpack/patch process Nov 13 20:49:07 woglinde, why not? Nov 13 20:49:08 yeah, indeed Nov 13 20:49:15 it is an excellent test case :) Nov 13 20:49:56 * Crofton must turn the power switch on and hope the magic smoke does not come out Nov 13 20:50:13 I have an fpga attached to the omap3 gpmc bus Nov 13 20:50:23 i also think we should consider moving packaging and image creation out of recipes. make the recipe emit the do_install output, and everything else is a matter of pulling those out and doing things with them.. but i don't have a coherent idea around that yet.. Nov 13 20:50:24 I think no outputs are set to drive outputs ..... Nov 13 20:50:30 Crofton because I see to many ugly things Nov 13 20:50:34 heh Nov 13 20:50:39 what is ugly Nov 13 20:50:41 and have to fix to many stuff Nov 13 20:50:46 ah Nov 13 20:51:00 so you are going through the test nature of the image :) Nov 13 20:51:27 right now I am seeing firefox compiling Nov 13 20:51:30 with so many warnings Nov 13 20:54:14 woglinde, still a good test after recent dev changes Nov 13 20:54:24 ok, time to plug things in Nov 13 20:55:46 crfotn thumbs up Nov 13 21:10:52 anyone else seeing webkit-gtk build failures or is it "just me"? :-) Nov 13 21:12:34 sakoman didnt test Nov 13 21:13:03 woglinde: http://pastebin.com/m9e15421 Nov 13 21:14:00 sakoman whats pkgconfig_sysroot_preprocess really doing? Nov 13 21:14:11 could you paste the relevant code from run Nov 13 21:14:25 sure Nov 13 21:14:37 woglinde, its a cat $f | sed foo >$ Nov 13 21:14:39 hm okay Nov 13 21:14:49 found in the bbclass Nov 13 21:14:51 lets see Nov 13 21:15:33 ah okay Nov 13 21:15:54 woglinde: http://pastebin.com/m6d26eb16 Nov 13 21:16:00 cat $pc > ${SYSROOT_DESTDIR}${PKG_CONFIG_DIR}/$pcname Nov 13 21:16:11 seems $pc == ${SYSROOT_DESTDIR}${PKG_CONFIG_DIR}/$pcname Nov 13 21:16:35 sakoman: rebuilt webkit 2 days ago from dev to support some tweaks I was doing to Midori, worked well. Not seen that error, I can try a clean and build later Nov 13 21:16:40 now we have to find out why Nov 13 21:17:03 i had this error tonight. just removed midori Nov 13 21:17:16 I'm not sure what proper work sysroot-destdir contents are supoosed to look like but mine are quite strange! Nov 13 21:17:33 playya_: ahh, so it's a victim of the .dev rework? Nov 13 21:18:00 i'm on shr/merge, but it might come from .dev Nov 13 21:20:21 DJWillis: I'm at current top of dev tree Nov 13 21:22:10 skoman hm could you put a echo "here comes pc $pc" into pkgconfig.bbclass? Nov 13 21:22:13 and run again Nov 13 21:22:31 would be nice to see whats pc is Nov 13 21:25:00 woglinde: OK, will do Nov 13 21:34:19 woglinde: sorry had a phone call Nov 13 21:34:49 woglinde: http://pastebin.com/m2f81d724 Nov 13 21:36:13 hm yeah Nov 13 21:36:27 ${S} is some how wrong Nov 13 22:25:57 pb__: still there? Nov 13 22:27:26 03Khem Raj  07org.openembedded.dev * r849cddddec 10openembedded.git/recipes/eglibc/ (5 files): Nov 13 22:27:26 eglibc_2.11: Add recipes for new eglibc 2.11 release Nov 13 22:27:26 * Use EGLIBC_BRANCH in missing places where it could be used. Nov 13 22:27:26 * Update svn recipe to latest. Nov 13 22:27:26 * Update svn recipe version to 2.11+ now that 2.12 is tracking trunk. Nov 13 22:27:27 * Make DEFAULT_PREFERENCE = -1 for eglibc 2.11 default stays 2.10. Nov 13 22:27:31 Signed-off-by: Khem Raj Nov 13 22:32:23 ~lart ecore devs Nov 13 22:32:23 * ibot explains, ever so gently, that if ecore devs doesn't give the channel more information, they can't help Nov 13 22:39:23 ant__: hi Nov 13 22:42:01 pb__: the build of sqlite3 now completes. still a minor issue, though http://fr.pastebin.ca/1670559 Nov 13 22:42:20 cp: cannot stat `/oe/build/tmp/work/i686-linux/tcl-native-8.4.19-r3/image/*': No such file or directory Nov 13 22:47:24 re Nov 13 22:47:26 yeah, that is a bit odd Nov 13 22:47:29 hm evdev crashed my X Nov 13 22:47:40 I think it is probably harmless but it would be interesting to know what is causing it Nov 13 22:48:04 ant could you paste it again? Nov 13 22:48:09 see, I'll try with comment on the line #INHERIT += "rm_work" Nov 13 22:48:15 I'm using it Nov 13 22:48:23 I doubt it's caused by rm_work Nov 13 22:49:03 judging from the error, I would guess that some part of the new staging code is not being completely disabled in legacy mode Nov 13 22:49:14 and/or it just isn't set up to cope with native packages properly Nov 13 22:49:37 ah Nov 13 22:49:52 either way that would probably be an issue for rp :-} Nov 13 22:51:07 ^_^ Nov 13 22:52:48 hm sill wonder which package drags in external-toolchain Nov 13 22:53:00 in my beagleboard-demo-image Nov 13 22:53:08 btw I'm feeling adventurous and I'm rebuilding now sqlite having a console image building in another terminal...doh..seems even to work! Nov 13 22:54:03 pb__: absolutely , rm_work makes no difference, sorry for the noise ;) Nov 13 23:08:13 RP, I'll test the python-native path tomorrow Nov 13 23:09:35 RP: have you seen that kernel.bbclass problem? Nov 13 23:32:49 * mwester notes that the python-native fix is not yet committed... Nov 13 23:32:50 :( Nov 13 23:32:55 Sigh. Nov 13 23:33:35 Can't we just commit the fix, and undo it if Mickey objects? Nov 13 23:45:58 woglinde: did you have any thoughts on how to fix the webkitgtk issue? The recipe actually does set S to $WORKDIR Nov 13 23:47:54 sakoman why? Nov 13 23:48:43 sakoman could you just remove the line Nov 13 23:48:46 and test again Nov 13 23:54:11 woglinde: you mean remove the S = "${WORKDIR}/" line? Nov 13 23:55:36 the webkit recipe is strange -- it pulls source from 7 different SNV repo's and uses its own config and makefile Nov 13 23:56:50 sakoman yes Nov 13 23:59:22 mwester: is ACKED already... Nov 13 23:59:35 s/is/it's/ Nov 14 00:57:07 JaMa: still around? Nov 14 00:58:20 hm Nov 14 00:58:27 hum Nov 14 00:58:32 pygtk seems to need some love too Nov 14 01:02:53 03Richard Purdie  07org.openembedded.dev * r2c09164fd4 10openembedded.git/classes/kernel.bbclass: Nov 14 01:02:53 kernel.bbclass: Fix populate_packaged 'D' references Nov 14 01:02:53 Signed-off-by: Richard Purdie Nov 14 01:03:54 ah found it Nov 14 01:03:56 sed -i s:/usr/share:${STAGING_DATADIR}: codegen/pygtk-codegen-2.0 Nov 14 01:03:59 tse tse Nov 14 01:07:44 * mwester thinks that if he ever gets back home again, maybe he should actually test to see if any of the images boot on a real NSLU2. :( Nov 14 01:08:30 mwester: :/ Nov 14 01:09:05 contract work is a tough way to make a living here. Nov 14 01:09:18 sakoman: I've set a build away but I should really sleep :( Nov 14 01:09:49 mwester: I've been there before - advantages and disadvantages... Nov 14 01:10:12 I think the upper-midwest US is going to revert to an agricultural economy... So since I'm not in a position to move right now, I think I'll work on "OE for Cows" :D Nov 14 01:10:37 CowOS Nov 14 01:12:14 It'll be udderly fantastic. Nov 14 01:13:25 * kergoth thinks he should boot his sheevaplug. haven't used it once since he bought it Nov 14 01:14:07 RP do we prefix defined? Nov 14 01:14:10 +have Nov 14 01:14:35 ah yes cool Nov 14 01:17:20 * RP -> Zzzz Nov 14 01:17:24 'night all Nov 14 01:17:31 good night. Nov 14 01:17:36 nite rp Nov 14 01:17:51 hmm, how do people normally manage version in setup.py & __version__ in python projects? Nov 14 01:18:12 dont know Nov 14 01:18:32 let me see what I have in my setuptools Nov 14 01:19:26 hm Nov 14 01:19:34 only have version = "0.1" Nov 14 01:19:46 saw one solution with constant Nov 14 01:19:56 pyro Nov 14 01:20:21 hmm. i saw one that imports the module and uses its __version__ as the setup.py version, but that can interfere with buildout usage and the like, importing the package may pull in other stuff that isn't available yet Nov 14 01:20:23 code=compile(open(os.path.join('Pyro','constants.py')).read(), "constants", "exec") Nov 14 01:20:30 constants={} Nov 14 01:20:37 version=constants["VERSION"] Nov 14 01:20:48 ah, interesting Nov 14 01:21:04 that's a cute idea, seems to resolve the other issue, since its a standalone file Nov 14 01:21:18 # General Pyro Version String #### Nov 14 01:21:19 VERSION = '3.9.1' Nov 14 01:21:30 from constants.py Nov 14 01:23:16 ah it worked Nov 14 01:23:28 another package fixed for micro Nov 14 01:23:31 *sigh* Nov 14 01:29:31 heh, fun fun Nov 14 01:30:00 * kergoth is starting on a bitbake project manager script.. though he still needs to teach bitbake to make use of a project Nov 14 01:30:10 hm e-wm drives me crazy I have uclibc and its passes ifdef __GLIBC__ Nov 14 01:37:43 jo raster Nov 14 01:37:53 raster are you master of e-wm? Nov 14 01:42:32 well not really Nov 14 01:42:39 okay Nov 14 01:42:42 i've... had some input on it Nov 14 01:43:08 wonder why on my uclibc toolchain ifdef __GLIBC__ was true Nov 14 01:44:38 damn, ipython is awesome Nov 14 01:44:47 ipython? Nov 14 01:45:04 better interpreter Nov 14 01:45:18 completion, syntax highlighting, can fall back to shell commands, so you can 'cd' and 'ls' and stuff Nov 14 01:45:23 easy call out to external commands Nov 14 01:45:33 built in support for reloading modules Nov 14 01:45:38 !vim somefile.py Nov 14 01:45:40 reload somefile Nov 14 01:45:43 somefile.foo() Nov 14 01:45:44 heh Nov 14 01:46:56 woglinde: autofoo.... dunno - it's detecting host system headers as opposed to staging only? Nov 14 01:47:36 hm didnt checked this Nov 14 01:47:40 maybee tomorrow Nov 14 01:47:53 raster who maintains ecore? Nov 14 01:49:15 oe or upstream? Nov 14 01:49:21 upstream Nov 14 01:49:31 we do Nov 14 01:50:04 someone did understand how detect iconv/gettext with autotools Nov 14 01:50:34 okay time for bed now Nov 14 01:53:41 did or didnt? Nov 14 01:53:46 oh too late **** ENDING LOGGING AT Sat Nov 14 02:59:56 2009