**** BEGIN LOGGING AT Wed Feb 24 03:00:02 2010 Feb 24 07:35:44 good morning Feb 24 07:35:50 denix|air: thank you Feb 24 07:42:58 good morning Feb 24 08:29:29 03Martin Jansa  07org.openembedded.dev * r987c90ef18 10openembedded.git/recipes/tasks/task-shr-feed.bb: Feb 24 08:29:29 task-shr-feed: fix machine override Feb 24 08:29:29 * Never += to override variable as it appends to empty override variable Feb 24 08:29:29 which is later used instead of that variable without override Feb 24 08:29:29 Signed-off-by: Martin Jansa Feb 24 08:29:30 03Martin Jansa  07org.openembedded.dev * rc1061ca1f1 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Feb 24 08:29:31 preferred-shr-versions: use qt 4.6.2 Feb 24 08:29:31 Signed-off-by: Martin Jansa Feb 24 08:29:32 03Martin Jansa  07org.openembedded.dev * r23681e9601 10openembedded.git/recipes/opensync/libsyncml_0.5.4.bb: Feb 24 08:29:32 libsyncml: bump PR for -O2 from sane-toolchain-eglibc.inc Feb 24 08:29:33 Signed-off-by: Martin Jansa Feb 24 08:29:33 03Martin Jansa  07org.openembedded.dev * r1ae254cccf 10openembedded.git/conf/distro/shr.conf: Feb 24 08:29:34 shr: use eglibc-2.11 Feb 24 08:29:34 Signed-off-by: Martin Jansa Feb 24 08:29:35 03Martin Jansa  07org.openembedded.dev * r4bfd40b10b 10openembedded.git/conf/distro/include/sane-toolchain-eglibc.inc: Feb 24 08:29:35 sane-toolchain-eglibc: use -O2 for qt4-x11-free and libsyncml (needed for gcc-4.4) Feb 24 08:30:21 Signed-off-by: Martin Jansa Feb 24 08:32:29 hi. i am having problems building the ccid recipe. is this the correct place to ask a question about this? Feb 24 08:59:44 morning Feb 24 09:42:53 morning Feb 24 10:24:33 good morning Feb 24 10:25:19 good moaning Feb 24 10:29:58 fsck need --really-force-as-I-am-not-fs-developer option Feb 24 10:30:10 hehe Feb 24 10:30:32 what is a use in requiring user to drop to maintaince shell to run fsck manually if all what user do is keeping enter pressed to confirm all actions? Feb 24 10:30:50 inode 23525 has i_size=234 should be 2356423, fix ? Feb 24 10:31:00 do I look like ext4 developer? Feb 24 10:31:12 hrw: whats wrong with -y ? Feb 24 10:31:21 or yes | fsck :-) Feb 24 10:31:57 XorA: normal user should not be forced to get it this. my wife for example do not even know root pass for her laptop Feb 24 10:32:30 hrw: how did you break it that bad anyway? Feb 24 10:32:40 hrw: since ext3 I havent busted up a fs that bad Feb 24 10:32:58 XorA: random system hang during use + forced reboot Feb 24 10:52:40 found why.. Feb 24 10:52:49 FU.K you intel!!! Feb 24 10:53:31 * Romke wants his board! Feb 24 10:54:11 dammit, bloody chinese, ship it Feb 24 10:54:11 if I start X11 then my laptop hangs Feb 24 10:55:04 Hi all Feb 24 10:55:28 where can i get latest kernel for Angstrom Omap/Beagle Feb 24 10:56:14 siji, this is neither a beagle channel nor an omap channel Feb 24 10:56:22 nor an angstrom channel Feb 24 10:56:22 okay Feb 24 10:57:00 peek into the recipes dir and build your own Feb 24 10:58:34 ok Feb 24 11:17:46 03Koen Kooi  07org.openembedded.dev * r32799b8fb2 10openembedded.git/recipes/powervr-drivers/ (27 files in 3 dirs): Feb 24 11:17:46 libgles-omap3: complete overhaul Feb 24 11:17:46 * convert to new-style staging Feb 24 11:17:46 * (re)build demos with proper toolchain and flags Feb 24 11:17:46 * build trainingcourses Feb 24 11:17:47 * generate .desktop files on the fly Feb 24 11:17:47 * delete old versions Feb 24 11:48:39 03Koen Kooi  07org.openembedded.dev * r5c7b09a3a7 10openembedded.git/recipes/powervr-drivers/ (15 files in 4 dirs): libgles-omap3: complete the previous commit, I suck at using git mergetool Feb 24 11:49:31 03Koen Kooi  07org.openembedded.dev * r0f51be1b08 10openembedded.git/recipes/powervr-drivers/libgles-omap3.inc: libgles-omap3: fix DEPENDS as well Feb 24 12:00:44 huhu Feb 24 13:08:15 is it possible to use different opkg-collateral configuration in do_rootfs and then later on device? Feb 24 13:08:47 * JaMa|Wrk is stupid and didn't test setting tmp_dir option in do_rootfs, where it expects /var/lib/opkg/tmp directory available on buildhost Feb 24 13:11:21 do_rootfs shouldnt be using the one in the image Feb 24 13:11:28 thats new if it has started to Feb 24 13:14:21 hmm than I have to check where it wanted to create that dir from end of http://tinderbox.openembedded.net/public/logs/task/5128628.txt Feb 24 13:16:23 odd Feb 24 13:16:48 have to dissassemble run.do_rootfs I guess Feb 24 13:18:27 JaMa|Wrk: --tmp-dir and force your own tmd_dir? Feb 24 13:18:37 JaMa|Wrk: just in case it is picking out of image Feb 24 13:23:35 hmm running corresponding run.do_rootfs.29365 in terminal finished ok :/ Feb 24 13:29:42 XorA: ah testlab is calling opkg-cl -f /OE/tmpdir-dev-shr/rootfs/shr-lite-image/etc/opkg instead opkg-cl -f /OE/tmpdir-dev-shr/staging/x86_64-linux/etc/opkg.conf Feb 24 13:30:22 JaMa|Wrk: ahah, that would explain it Feb 24 13:31:00 JaMa|Wrk: that was koens baby I think, kick him :-D Feb 24 13:33:22 XorA: yes he is written there as author Feb 24 13:33:48 XorA: trying http://paste.pocoo.org/show/182030/, then I'll poke him :) Feb 24 13:36:35 JaMa|Wrk: XorA: after one night of sleep I see the klibc issue(s) clearly: they still need the full linux headers to build. In latest .git one patch for the install step was applied, using now headers_install script from kernel. This fails on 2.6.26 because of headers mismatch (getline issue). If you're using a modern 2.6.33 kernel the klibc build will fail in do_compile because of asm... Feb 24 13:36:37 ...headers mismatch. I see kernel.bbclass has some patches for this but probably more work is needed. Feb 24 13:37:12 see http://www.gentoo-portage.com/AJAX/Ebuild/95599/View Feb 24 13:38:25 JaMa|Wrk XorA: so I suspect th patch here is still needed: http://www.zytor.com/pipermail/klibc/2009-September/002457.html Feb 24 13:39:41 ant_work: this is what I used 2 days ago.. but then it failed for me with those missing AF_INET (because sys/socket.h instead linux/socket.h) and after chaniging that it failed to link in the end.. Feb 24 13:40:03 GNUtoo: hi, saw your hi yesterday, didn't want to be unfriendly but actually this is my compu @ work Feb 24 13:40:34 ok Feb 24 13:40:47 JaMa|Wrk: then, I'm not sure we can run that unmodified install_headers script.... Feb 24 13:40:57 someone else answered my question Feb 24 13:41:01 hi btw Feb 24 13:41:18 hi all Feb 24 13:41:38 he.. finally.. Feb 24 13:41:41 # This will be able to go away once the klibc author updates his code Feb 24 13:41:43 # to build again the headers provided by the kernel's 'headers_install' target. Feb 24 13:46:42 ant_work: see http://tinderbox.openembedded.net/public/logs/task/5128803.txt Feb 24 13:47:09 author (hpa) agrees : ... it will require some beating on the scripts, though. Feb 24 13:57:45 how does one bitbake gettext_native, now that it uses: BBCLASSEXTEND = "native nativesdk" Feb 24 13:58:39 cbrake: bitbake gettext-native doesn't work? Feb 24 13:58:56 JaMa|Wrk: let me try ... Feb 24 13:59:29 I've seen that -b doesn't work for recipes with BBCLASSEXTEND = "native", but calling with provider name worked for me in all cases sofar Feb 24 14:00:39 JaMa|Wrk: yes, that works -- thanks! Feb 24 14:18:33 after two days with debian on sheeva I want armv7a devices only Feb 24 14:18:45 [ 261.059334] Alignment trap: fsck.ext4 (1003) PC=0x0003f20c Instr=0xe1a01003 Address=0xcccccccd FSR 0x801 Feb 24 14:18:48 [ 261.069173] Alignment trap: not handling instruction e1a01003 at [<0003f20c>] Feb 24 14:18:51 [ 261.076644] Unhandled fault: alignment exception (0x801) at 0xcccccccd Feb 24 14:18:53 Warning... fsck.ext4 for device /dev/sda1 exited with signal 4. Feb 24 14:18:59 thats under angstrom. debian oopsed Feb 24 14:19:05 morning kergoths Feb 24 14:20:22 morning Feb 24 14:22:20 * hrw -> food Feb 24 14:30:08 hi kergoth Feb 24 14:30:20 SPAM: "This might be a bit off-topic but I believe there are a lot of smokers here on http://www.xora.org.uk." WTF??? Feb 24 14:30:39 kergoth: Are you going to implement this ??= ? :) Feb 24 14:30:49 kergoth: or should I look at it? Feb 24 14:31:12 I'll take a look. shouldn't be too painful. Feb 24 14:31:57 kergoth: No, just please create a cache of the keynames that use it - it will keep the parser fast Feb 24 14:32:51 I figured just store the last one for a given variable, then do the actual assignment from it at finalise() time Feb 24 14:33:05 * kergoth gets caffeine Feb 24 14:34:14 kergoth: agreed - you just want a list of variables finalise need to look at rather than using the whole dict keys Feb 24 14:34:27 ah, right, good idea :) Feb 24 14:34:37 kergoth: this is the voice of experience ;-) Feb 24 14:34:39 hehe Feb 24 14:46:01 * XorA goes to watch more vampite diaries Feb 24 15:23:25 * hrw wants armv7a sheevaplug ;( Feb 24 15:23:56 ;) Feb 24 15:27:08 hrw: whats up with your sheeva? Feb 24 15:27:20 hrw: are there armv7a instructions in the debian distro? Feb 24 15:27:26 hrw: or just general instability? Feb 24 15:31:17 cbrake: fsck of 1.5TB ext4 ends in unaligned traps and often in kernel hang. nevermind debian or angstrom Feb 24 15:32:15 hrw: nice storage ;) Feb 24 15:32:52 soltys: 360pln for hdd and 120pln for esata/usb case with extra 2 usb ports Feb 24 15:33:12 i gave up on shevaplug for nas hrw, too slow. Feb 24 15:33:29 kgilmer: 30MB/s is enough Feb 24 15:33:33 hrw: mhm but first you should have that sum of money ;) Feb 24 15:33:41 kgilmer: at max Feb 24 15:33:55 hrw: well, that's just a kernel bogosity. there is no way that 0xe1a01003 can generate an alignment trap. Feb 24 15:34:01 kgilmer: but I use it for storage of media files so speed is not a matter Feb 24 15:34:48 that's what i though too, but it turned out speed did matter for me. i was not getting 30MB/s on mine though, more like 10. Feb 24 15:35:08 pb_: maybe, but connecting disk to desktop just for making fsck is strange Feb 24 15:35:38 sure. it's probably nothing to do with the presence or absence of armv7a though. Feb 24 15:37:33 sure Feb 24 15:38:04 pb_: but running armv5te stuff on BB did not gave me that problem (but it has few other ones) Feb 24 15:39:20 Pass 1: Checking inodes, blocks, and sizes Feb 24 15:39:20 BUG: Bad page state in proc================== | 58.4% Feb 24 15:39:22 argh Feb 24 15:39:26 * hrw -> coffee Feb 24 15:59:38 Hi, when I setup my MACHINE to nhk15, OpenEmbedded downloads automatically kernel source and patches for nhk15, where are the configuration files that tell openembedded to download the specific patches , Feb 24 15:59:39 ? Feb 24 16:00:45 vadmeste: nhk15 config sets provider for virtual/kernel to be "linux". Feb 24 16:01:17 and what about your specific patches ? Feb 24 16:01:21 vadmeste: then recipes/linux/linux_2.6.20.bb has line which sets default preference for nhk15 as "1" so it is used as virtual/kernel Feb 24 16:01:50 vadmeste: then linux_2.6.20.bb recipe has SRC_URI_append_nhk15 which adds patches to sources Feb 24 16:02:03 okey :) Feb 24 16:06:25 In fact, I am trying to compile a kernel manually (that's useful to understand many things).. but after compiling it and installing it to nhk-15 memory at 0x100000, bootm 0x10000 tells me that it found an invalid magic number.. :( Feb 24 16:07:24 maybe we have to create an nhk15 channel :) Feb 24 16:10:21 ah okey, it's uboot format => uImage Feb 24 16:11:10 you need uImage Feb 24 16:11:56 yes i am searching now how you did it Feb 24 16:13:57 I left it for Oe Feb 24 16:17:45 hrw: re busybox, was your ack wearing an Angstrom hat? :) Feb 24 16:21:49 Tartarus: no, OE hat Feb 24 16:22:02 Tartarus: I use angstrom, not develop it Feb 24 16:22:36 * XorA has a supply of Angstrom hats :-) Feb 24 16:23:21 03Koen Kooi  07org.openembedded.dev * rd7c7cda4a2 10openembedded.git/recipes/e17/ (5 files): e17: add some modules: cpu, forecasts, uptime and screenshot (+ emprint dep) Feb 24 16:23:21 03Koen Kooi  07org.openembedded.dev * rdf85cf9268 10openembedded.git/conf/distro/include/sane-srcrevs.inc: efl: bump SRCREV to fix a stuttering issue in the first-run wizard Feb 24 16:25:53 hey guys... I've tried to write a BB recipe for libhid - but both my version as well as the suggested version I've found on http://codingnotez.blogspot.com/2009/04/bitbake-libhid.html are failing with the same error message Feb 24 16:26:08 hrw: ah, k Feb 24 16:26:14 i've spent several hours on this, but I really couldn't figure out the problem Feb 24 16:26:23 * Tartarus hopes koen sees it soon then Feb 24 16:27:29 it fails in the configure step while it's trying to test the python binding link Feb 24 16:27:43 Tartarus: easiest way is to ask him on #beagle Feb 24 16:28:18 hmm, 50h idle Feb 24 16:28:25 i pm'd him yesterday Feb 24 16:30:11 Tartarus: _koen_ is more alive Feb 24 16:30:22 it is corpo version of koen Feb 24 16:31:41 ah, ha Feb 24 16:34:40 * XorA is getting to the point where there is enough security holes in OE that SUIDing busybox woudnt be that bad anyway Feb 24 16:35:30 XorA: "Getting to the point" makes it soudn like this is some sort of goal for you. Feb 24 16:36:12 broonie: I just happened to notice the 9 millions dbus security flaws that debian/redhat just cleared that we still need to :-) Feb 24 16:38:19 hi Feb 24 16:40:25 I got a QA issue when trying to build ipkg-utils. It is saying "No GNU_HASH in elf binary: '.../ipkg-compare-versions'. Feb 24 16:40:52 Can anybody comment? Feb 24 16:46:01 are you all idle or I'm just excluded from the chatroom? Feb 24 16:46:21 you need to fix LDFLAGS in their makefiles Feb 24 16:47:35 is it that what you mean? sshfs 192.168.193.134:/home/marekp/AT91SAMDEV/OE-20100216 /share/at91sam-develop/OE-20100216/ Feb 24 16:47:40 ups.. sorry Feb 24 16:47:52 cut and paste ... Feb 24 16:48:27 i meant: http://www.mail-archive.com/shr-devel@lists.shr-project.org/msg01103.html Feb 24 16:48:30 you mean that? Feb 24 16:49:00 probably Feb 24 16:49:07 thank you a lot Feb 24 16:50:09 i tryied to patch LDFLAGS in gcc-configure-common.inc but did not work Feb 24 17:03:13 kergoth, thanks for the quick fix! Feb 24 17:04:32 listtasks does not list ordered by dependencies of tasks, does it? How can i check the order of tasks of a package? Feb 24 17:07:58 (this must be a FAQ but i failed to find the asnwer i fear) Feb 24 17:08:24 is listtasks a bitbake parameter? Feb 24 17:08:52 answer even. Fingers playing tricks on me. Too many asn typed today ;) Feb 24 17:09:01 marekp, yes. bitbake -c listtasks Feb 24 17:09:01 blindvt`: if you want it for some specific case you can use -n and watch output Feb 24 17:10:05 JaMa|Wrk, i see. But, don't get me wrong, listtasks unsorted is pretty useless overall isn't it Feb 24 17:12:49 I've never used listtasks, maybe because whan I wanted to see what that recipe will do, I used that -n param Feb 24 17:13:10 so I've no idea why listtasks exists and if it's still valid reason Feb 24 17:14:13 * blindvt` nods JaMa|Wrk Feb 24 17:14:28 ok. Thanks for the -n hint Feb 24 17:14:47 yw Feb 24 17:15:22 maybe the .dot files generated by bitbake also give you the infrmation you're looking for Feb 24 17:16:14 but i had problems to display them nicly Feb 24 17:22:49 blindvt`: you could certainly alter listtasks to traverse in order of task dependencies. of course, its not quite so simple as that, because some of those tasks aren't built by default, its a digraph, not a list, but it should be sufficient Feb 24 17:23:22 elo mickeyl Feb 24 17:23:25 blindvt`: np for the fix, thanks for spotting the issue. I'd tested that patch (the one that adds FETCHCMD_git), but apparently not with AUTOREV. Feb 24 17:23:33 heya hrw Feb 24 17:23:57 morning mickeyl Feb 24 17:24:04 good morning pb_ Feb 24 17:24:18 morning mickeyl Feb 24 17:25:22 While it's on my mind, there's a bbclass patch or two from kergoth/I that need acks, if anyone awake feels so empowered :) Feb 24 17:25:29 mickeyl: think http://github.com/kergoth/BitBake/commit/28135ad5df4cec8550cce359343ece9cfd08b167 is worth applying? Feb 24 17:25:51 heh, i think i have a number of patches still pending in patchwork, some from before i left MV.. i should check status Feb 24 17:27:21 mickeyl: there is python ssl patch on oeml - ack it Feb 24 17:27:24 kergoth: good morning. yes, that's definitely worth it Feb 24 17:27:37 not just for performance, but also for clarity Feb 24 17:27:38 k, i'll do some more test builds, then if there's no issues pull over onto master Feb 24 17:27:42 cool Feb 24 17:28:00 thanks Feb 24 17:28:05 kergoth: looks good Feb 24 17:28:29 * kergoth decided to use a github tree for prototype / experimentation, rather than cluttering up the main tree Feb 24 17:28:32 heh Feb 24 17:28:39 hrw: got a link? Feb 24 17:28:46 kergoth: good choice Feb 24 17:28:51 kergoth: We should add a bitbake contrib repo Feb 24 17:29:27 mickeyl: http://patchwork.openembedded.org/patch/1617/ http://patchwork.openembedded.org/patch/1594/ Feb 24 17:30:04 and I would like to get opinion on http://patchwork.openembedded.org/patch/1585/ http://patchwork.openembedded.org/patch/1584/ ones Feb 24 17:30:16 btw, is building Java into angstrom really as simple as creating a new image recipe with classpath added to packages_install ? Feb 24 17:30:19 ok, i will process these in the next couple of hours Feb 24 17:30:24 will make me a patchwork login beforehand Feb 24 17:30:32 I can also push them into tree and look at complains ;D Feb 24 17:30:45 good as well Feb 24 17:30:47 :D Feb 24 17:33:31 hrw: So long as a few distros still build, just do it :) Feb 24 17:35:06 no warranty that they will get upgradable packages ;( Feb 24 17:43:10 is it allowed to use /tmp (on buildhost) in do_rootfs for opkg temporary files? Feb 24 17:44:26 so long as you put them in a uniquified directory, and clean them up afterwards, yes. Feb 24 17:45:02 obviously you need to take precautions against two simultaneous opkg instances colliding with each other, so just sticking the files in a statically-named subdir of /tmp would not be acceptable. Feb 24 17:45:12 I've added tmp_dir option for SHR in opkg.conf, first I expected that wrong config is used when calling opkg-cl, but it's case only in testlab.bbclass Feb 24 17:46:04 have a nice rest of day Feb 24 17:46:04 now I checked that with no tmp_dir option specified in opkg-cl -f staging/etc/opkg.conf it's using option specified in opkg.conf in rootfs specified with -o Feb 24 17:47:06 pb_: sorry, I wasn't clear.. but those are not files I would manually create.. but those opkg-random opkg itself is creating Feb 24 17:47:28 sure, I guessed that. Feb 24 17:47:51 you need to make sure that opkg puts its files in a suitable subdir and that either it or you cleans them up afterwards. Feb 24 17:48:18 and it works ok if I add -t param to opkg-cl call, but I can add -t ${IMAGE_ROOTFS}/tmp or just -t /tmp Feb 24 17:51:44 I would have thought that -t ${WORKDIR}/opkg-tmp was your best option. Feb 24 17:52:05 Putting them in ${IMAGE_ROOTFS}/tmp doesn't seem like that great an idea. You don't want them in the image, do you? Feb 24 17:52:20 Using "-t /tmp" might or might not be acceptable. It depends what exactly opkg does with that argument. Feb 24 17:53:44 pb_: but it's how it worked now I think, and you're right I don't want them in image (opkg removes them if everything goes ok) Feb 24 17:54:20 Hi, anyone seen this compile bug? http://pastebin.com/cG18ePem it fails on package perl-native-5.8.8-r13, using Fedora 11 Feb 24 17:55:17 pb_: I'm trying to add /tmp/opkg-$$ in classes/rootfs_ipk.bbclass, it's easy in that rootfs_ipk_do_rootfs(), but not sure how to prepare unique name already in IPKG_ARGS variable above Feb 24 17:55:33 pb_: and then the same needs to be added to testlab.bbclass Feb 24 17:57:10 pb_: ah sorry maybe now it worked also as with -t /tmp (not ${IMAGE_ROOTFS}/tmp) that explains why i had some opkg-random left-overs in buildhost /tmp Feb 24 17:58:41 JaMa: I think you want to do something along the approximate lines of: Feb 24 17:58:52 git-wtf script is kind of cute Feb 24 17:58:56 IPKG_TMPDIR := "${@Tempfile.mkdtemp()}" Feb 24 17:59:05 IPKG_ARGS += "-t '${IPKG_TMPDIR}'" Feb 24 17:59:20 and then arrange for rootfs_ipk_do_rootfs() to remove ${IPKG_TMPDIR} when it's finished. Feb 24 17:59:52 obviously you'd need to take steps to get tempfile actually imported, but you get the idea. Feb 24 18:00:15 and, er, tempfile not Tempfile, doh Feb 24 18:01:02 That looks suspicously like something easier done by the script and stored in a variable than done in bitbake's variable space Feb 24 18:01:23 unless you want to add a new fork per parsed file Feb 24 18:01:36 well, a mkdir call Feb 24 18:01:48 yeah, that'd work too. Feb 24 18:02:09 I guess you indeed don't want to create the file at parse time, that would be silly. Feb 24 18:04:20 yes now I'm running build with http://paste.pocoo.org/show/182138/ Feb 24 18:06:12 does it look acceptable? (it works for me with option tmp_dir in config) or should I use mkdtemp()? Feb 24 18:06:54 hmm. Feb 24 18:10:04 or maybe I should even use ${TMPDIR} as base for that? and let system /tmp alone? Feb 24 18:10:35 then I can move it even to temp in work dir of actuall image build :) Feb 24 18:10:37 JaMa: or ${IMAGE_ROOTFS}-tmp Feb 24 18:11:58 OK, I will change that and then it's ok for you? I would push it and then send similar patch for testlab for koen's ack Feb 24 18:16:22 re Feb 24 18:16:27 gm Feb 24 18:40:00 hrmph. finalise() isn't ideal for ??=, since a bitbake -e without specifying a recipe won't see those defaults. ideally, itd probably get the default in the getVar or something, but that could be too large a perf hit. will have to test it out and see, but most likely stuck with finalise anyway.. ah well Feb 24 19:13:25 Hi, anyone seen this compile bug? http://pastebin.com/cG18ePem it fails on package perl-native-5.8.8-r13, using Fedora 11 Feb 24 19:14:51 03Martin Jansa  07org.openembedded.dev * r45809c052d 10openembedded.git/recipes/opkg/ (opkg-collateral.bb opkg-collateral/tmp_dir): Feb 24 19:14:51 opkg: add tmp_dir option to opkg.conf for SHR Feb 24 19:14:51 Signed-off-by: Martin Jansa Feb 24 19:14:54 03Martin Jansa  07org.openembedded.dev * rfe7f6581e7 10openembedded.git/recipes/tasks/task-shr-feed.bb: Feb 24 19:14:54 task-shr-feed: remove eve, removed from upstream svn repository in svnr45979 Feb 24 19:14:54 Signed-off-by: Martin Jansa Feb 24 19:14:54 03Martin Jansa  07org.openembedded.dev * rde991f13e6 10openembedded.git/recipes/openmoko-3rdparty/mcnavi_0.2.5.bb: Feb 24 19:14:55 mcnavi: add edje-native dependency, thanks to Dieter Thimm Feb 24 19:14:55 Signed-off-by: Martin Jansa Feb 24 19:14:56 03Martin Jansa  07org.openembedded.dev * rfd0d1b5f87 10openembedded.git/recipes/ (8 files in 2 dirs): Feb 24 19:14:56 shr-theme-neo: bump SRCREVS for illume, elementary, phoneui theme, remove last traces of libframeworkd-phonegui-efl-theme-neo even from RSUGGESTS, add idle_screen.edj.neo Feb 24 19:14:57 Signed-off-by: Martin Jansa Feb 24 19:14:57 03Thomas Zimmermann  07org.openembedded.dev * r42edf9d42d 10openembedded.git/recipes/sofia-sip/ (sofia-sip.inc sofia-sip_1.12.10.bb): Feb 24 19:14:58 sofia-sip: upgrade to latest version (1.12.10) Feb 24 19:15:05 * 1.12.7 doesn't compile with newer autotools Feb 24 19:15:05 Signed-off-by: Martin Jansa Feb 24 19:15:05 03Thomas Zimmermann  07org.openembedded.dev * ra7ff7964bc 10openembedded.git/recipes/evopedia/evopedia_git.bb: Feb 24 19:15:05 evopedia: bump SRCREV and update recipe Feb 24 19:15:06 * depencie on kernel-module-squashfs is no longer needed Feb 24 19:15:06 * python-compression is needed to read bz2 dumps Feb 24 19:15:07 Signed-off-by: Martin Jansa Feb 24 19:15:07 03Martin Jansa  07org.openembedded.dev * r046c7c5f1c 10openembedded.git/classes/rootfs_ipk.bbclass: (log message trimmed) Feb 24 19:15:08 rootfs_ipk.bbclass: always specify tmp_dir in opkg-cl call with -t parameter Feb 24 19:15:08 * When option tmp_dir is used in opkg.conf installed on rootfs then it's Feb 24 19:15:09 used also in do_rootfs call and points to probably non-existent directory Feb 24 19:15:09 on buildhost like /var/lib/opkg/tmp. Feb 24 19:15:13 * The value of tmp_dir from rootfs is used even with another config file Feb 24 19:15:13 specified with -c parameter Feb 24 19:17:22 CIA-2: wtf? Feb 24 19:19:54 eldis: it should link with libpthread Feb 24 19:20:01 adding -lthread to LDFLAGS might help Feb 24 19:23:38 thanks khem, will try that Feb 24 19:52:57 So, hmm Feb 24 19:53:18 As I feared, pstaging and kernel+devicetrees isn't saving device trees Feb 24 19:53:32 It's easy enough to bandaid this too Feb 24 19:53:39 But I suspect that compulab is also broken Feb 24 19:53:53 And also, any other special case stuff I don't see at first Feb 24 20:04:59 whats the best way to fix the "no GNU_HASH in library" error? Feb 24 20:22:07 Jin^eLD: that depends. you need to review the buildsystem in question to figure out how to make it obey our flags variables. Feb 24 20:22:12 read the makefiles Feb 24 20:22:24 doh.. its libjs ;) Feb 24 20:22:34 good luck Feb 24 20:22:37 I hope they release the 0.8 version soon, it will finally use autotools Feb 24 20:23:06 kergoth: but the meaning of this error , summarized shortly? Feb 24 20:23:08 you can hack it by adding LDFLAGS to the target cc arch var, since its likely obeying our CC var at aleast, and that feeds into that.. but its a definite hack Feb 24 20:23:36 it isn't obeying our LDFLAGS, so its not picking up the argument to set the gnu hash. I'm not intimiately familiar with how the gnu hash stuff works though, you'd have to google it Feb 24 20:24:17 indeed, so far I googled for the error.. but your explanation already helps a lot understanding the issue Feb 24 20:24:29 * khem thinks adding it as default for toolchain wud help many Feb 24 20:24:45 its a new way of hashing symbols Feb 24 20:25:01 it would, but better to see this error as a way of spotting buildsystems that dont obey our variables that let that behavior be hidden, imo Feb 24 20:25:07 s/that let/than let/ Feb 24 20:25:09 which is fast and speeds up dynamic linking by 2 folds Feb 24 20:25:36 I know but its a PITA to see atleast 2 devs hitting same error everyday Feb 24 20:26:05 then it's a good item for an FAQ :) Feb 24 20:26:17 and if we do not propose the changes upstream its no use Feb 24 20:27:09 of course its of use. you'd rather the builds just ignore us? Feb 24 20:28:28 well, my build did not fail because of it, so making me see the issue is surely a good thing, but I could not figure out the meaning of the error by myself Feb 24 20:28:51 probably because I was googling for the OE related QA error message and not for the gnu hash thing itself Feb 24 20:33:51 well libc is able to handle both sysv and gnu hash so it wont fail on execution just it will not see the dynamic linking speedup Feb 24 21:06:50 Hmm Feb 24 21:07:09 So anyone with an opinion on pstaging/kernel do_deploy stuff I haven't prodded already? Feb 24 21:07:27 I'm thinking maybe we just have to shellfile stuff as people care about it breaking Feb 24 21:08:50 Tartarus: what exactly did you do ? guess I missed it Feb 24 21:09:00 shellfile is evil... Feb 24 21:09:16 So the problem is all of the special case do_deploys Feb 24 21:09:24 devicetree's are also missing Feb 24 21:10:36 $ grep -l DEPLOY_DIR_IMAGE * | wc -l Feb 24 21:10:36 29 Feb 24 21:10:40 All broken Feb 24 21:10:58 (in that stuff won't be there on a from-pstaging only build) Feb 24 21:11:37 higher since that excludes linux.inc and devicetrees Feb 24 21:28:53 i noticed there were issues but never figured out the cause Feb 24 21:29:30 eFfeM1: those files are outside of staging. if you don't run the stagefile script, it won't go into the pstage package, so won't come back when using the package Feb 24 21:55:15 kergoth: ah ok, understood, so this is a different issue from what I was seeing Feb 24 21:57:13 What issue were you seeing? Feb 24 21:57:38 The "big" one with virtual/kernel was how kernel.bbclass did the default do_deploy Feb 24 21:57:54 I "fixed" that by using shellfile on the file in question, as that was easiest Feb 24 22:01:09 Tartarus: what i saw was that sometimes when restoring from packaged staging still the kernel do_deploy was executed. Feb 24 22:01:27 not sure exactly when it happened, could be the first time after a restore Feb 24 22:01:44 that is: at the first restore from pstage Feb 24 22:02:11 Yeah, do_deploy is redone Feb 24 22:02:40 Which, I don't know if is or isn't the root of the problem Feb 24 22:03:02 I was quite idly thinking that maybe we need a "new style deploy" ala new style staging Feb 24 22:03:15 So we can always make sure that stuff is tucked into pstaging Feb 24 22:03:20 btw wrt packaged staging there is also an issue with BBCLASSEXTEND = "native", those do not restore properly but (if i recall correctly) complain about no architecture, didn't find any info on it eihter, control seemed ok, but I lacked the time to dig into it Feb 24 22:03:47 Tartarus: new style deploy seems a good plan to me :-) Feb 24 22:04:47 Tartarus: might be that your patch do do_deploy resolved my problem, haven't seen it since, but haven't really rebuild from scratch since iirc Feb 24 22:04:47 hi there, quick question Feb 24 22:05:15 i'm working on a recipe for ruby 1.8.6 and i'm running into some issues with library paths after installing the package Feb 24 22:05:43 afk for 10 min or so Feb 24 22:06:06 the problem comes in when i want to use rubygems to compile native portions of a library on the target machine Feb 24 22:06:42 paths from my host machine are percolating to my dev machine Feb 24 22:07:02 specifically the path for my install executable Feb 24 22:07:41 which is being taken from config.status Feb 24 22:07:46 on my host machine Feb 24 22:08:26 anyone seen a similar situation before? Feb 24 22:14:55 have to run, but i will check back later Feb 24 22:31:42 03Tom Rini  07org.openembedded.dev * rb8c742d6c6 10openembedded.git/recipes/linux/linux.inc: linux.inc: Use package_stagefile_shell in do_devicetree_image Feb 24 23:10:58 denix, if you can see how to easily preserve the deinstall status in opkg, could you send a patch? Feb 24 23:12:12 denix, i assume you're referring to the behaviour of pkg_merge() ? Feb 24 23:13:07 grg: pkg_vec_insert_merge() to be exact Feb 24 23:22:38 grg: pkg_merge() just merges all the fields from 2 packages Feb 24 23:23:09 denix, right. But it doesn't touch the status field. Feb 24 23:23:15 and maybe it should Feb 24 23:23:31 grg: while pkg_vec_insert_merge() determines if needs to merge them (they have the same name, version, revision and arch) or insert a new one, if any one of those fields don't match Feb 24 23:24:12 grg: ah, haven't noticed that... maybe you're right - need to experiment Feb 24 23:24:29 denix, what is your test case? Feb 24 23:25:14 have a custom image where I don't need one of the RRECOMMENDS... Feb 24 23:31:08 03Florian Boor  07org.openembedded.dev * r2f3568adab 10openembedded.git/recipes/mc/mc_4.6.2.bb: mc: Fix build of 4.6.2 by not deleting required config.rpath Feb 24 23:47:33 hey khem? Feb 24 23:48:59 Or, hum, RP? Feb 24 23:50:57 Tartarus: yup Feb 24 23:51:13 khem, So, 8c662717cc89055f505c92191b8b455a5544bc1f i think is breaking pstaging pretty horribly Feb 24 23:51:29 I'm having no usr/include/stdio.h for example Feb 24 23:51:37 poking around the poky tree Feb 24 23:53:02 hmm do_stage changes probably Feb 24 23:53:18 Yeah. I'm wondering if there's a good reason RP didn't notice Feb 24 23:53:27 ie there's some tangental change that needed to come in too Feb 24 23:53:28 or what Feb 24 23:53:34 no Feb 24 23:53:47 he doesnt think pstage is worth at present :) Feb 24 23:55:08 but I dont understand why it went missing Feb 24 23:55:12 in pstage Feb 24 23:55:19 Poking around... Feb 24 23:55:59 Or rather, re-kicking a build but w/ a -v in cp to see what's being copied.. Feb 24 23:57:23 ok Feb 24 23:59:51 hummmm Feb 24 23:59:55 maybe that's a red herring Feb 25 00:00:07 stage file has contents Feb 25 00:06:08 denix, this is untested, but maybe does the right thing... http://pastebin.com/1afAZ1DZ Feb 25 00:11:01 denix, oops. Try this one instead. http://pastebin.com/QudB4vsE Feb 25 00:11:34 grg: I was thinking along the same lines. but for version comparison I wanted to preserve the current behavior if version/arch are specified and skip them, if they are not... Feb 25 00:12:49 not sure about line #37 - is that required? Feb 25 00:13:58 i think so. Otherwise control info parsed from feed files or .opk files will get priority over the existing info in the status file Feb 25 00:14:04 opkg is such a mess :) Feb 25 00:14:52 i think i should rename the oldpkg and newpkg variables in pkg_merge(). They clearly are not the old and the new package. Feb 25 00:15:24 but that was not the case if the check in ##23-28 was successful... Feb 25 00:18:46 would anyone share experiences using distcc and ccache together Feb 25 00:25:22 denix, set_status==1 only for when the status file is being read. If the status file is read, then we go to read e.g. the feeds file: set_status==0 and if we match on a "vec->pkgs[i]" (which comes from the status file), then "pkg" will just overwrite the "vec->pkgs[i]" without retaining the state_want, state_flag which should be done in pkg_merge() Feb 25 00:26:53 * grg would like to hit the previous architect(s) of ipkg with a big stick Feb 25 00:31:28 i hope that made sense. It may only make sense in my head :) Feb 25 00:33:10 hum hum hummm Feb 25 00:33:21 at the end of a from cache only virtual/libc, we're good Feb 25 00:33:40 doing an image now w/ a while [ -f ... ] sleep; kill Feb 25 00:38:53 grg: let me try it out... Feb 25 00:52:20 grg: doesn't seem to work so far - it still inserts a second instance of a package... Feb 25 00:56:03 denix, hmmm. I might need a small test case to play with this... Feb 25 00:56:34 I don't understand the OE stuff, so I cant drive it very well Feb 25 00:58:55 I wish someone was working on something like dpkg lite :) Feb 25 00:59:23 grg: let me try something, while I have my test case handy... Feb 25 01:00:17 khem, busybox has a dpkg clone these days Feb 25 01:01:59 khem: it isn't dpkg lite that we really need, its apt-get lite Feb 25 01:02:47 precicely yes Feb 25 01:07:54 grg: ok I fixed it slightly, so it is now merges the package structures instead of inserting a new one. but it still ends up installing it... Feb 25 01:11:40 grg: btw, as I thought, line #37 is not needed, as it is already called with set_status=1 when handling the primed status and merging pkgs Feb 25 01:12:49 Problem with dpkg stuff is a lack of use in a non-system way Feb 25 01:13:29 I'm leery only because I got bit and could never figure out why, some version of dpkg & co would call some host dpkg stuff on 9.04/newer Feb 25 01:13:53 I hate to say it, but if you want a pkg manager that's well tested and works in non-system mode, RPM :) Feb 25 01:14:19 (and then yum( Feb 25 01:15:14 yuck Feb 25 01:15:19 bleh Feb 25 01:15:26 I know yum works but apt is better Feb 25 01:15:42 I stopped using redhat distros because of it Feb 25 01:16:00 Could always write a new frontend to the feed Feb 25 01:16:24 yum left my system in irrecoverable state so many times Feb 25 01:16:37 may be it is better now Feb 25 01:16:51 I am taking about FC4,5,6 etc Feb 25 01:17:08 I have never used anything newer consistently thereafter Feb 25 01:17:25 distro not supporting KDE well are turn off for me :) Feb 25 01:18:13 distros not called slackware are a turn off for me :) Feb 25 01:19:04 s/slackware/gentoo/g Feb 25 01:19:33 * mwester just wants a computer to work; pragmatism vs principle Feb 25 01:20:23 what's so interesting in a working computer? it's not challenging! :) Feb 25 01:20:41 the more work you have to do to get a system the way you like it after installation, the worse it is Feb 25 01:21:38 there is nothing perfect and there are always tradeoffs Feb 25 01:22:43 hehe! I have enough things around my house that need to be constantly fixed and maintained; the fewer things I have to do with my computers the better... someday I hope to have time for my hobby again, but not until the economy here improves, I'm afraid... Feb 25 01:28:12 mwester: heh, I'm kind of in a similar situation - work and family take all my time and not much left for house-work and hobbies... Feb 25 01:29:06 * kergoth used to enjoy working on computers, but now agrees with mwester, they just need to fucking work, so he can get done what he really wants to get done Feb 25 01:37:19 mwester: to a certain extent I agree with you after so many years of using lnx Feb 25 01:48:19 I even dont complain about different SCM's Feb 25 01:49:48 heh Feb 25 01:50:06 I was amazed as hell that my x86 work laptop had a functional hibernate earlier this month Feb 25 01:50:15 it was almost like using a real OS :) Feb 25 01:50:22 gasp Feb 25 01:50:58 ♥ hibernate. always switch the main power button on my desktops to do that Feb 25 01:51:52 I get tempted to try that now and again Feb 25 01:52:13 But then I need to kinda sorta care about WoL so I can use 'em again in the morning Feb 25 02:01:33 Are there any graphic benchmarks existing in OE for the framebuffer. (I'm having some problems with display, which I think is the framebuffer being very slow. I'd like to be able to confirm that.) Feb 25 02:03:09 Tartarus: ubuntu was good at hibernation stuff Feb 25 02:04:13 shrug, failed on my desktop, worked on my laptop, desktop might have been 8.10 at the time tho Feb 25 02:06:00 I have it working on IBM laptops always Feb 25 02:06:04 I dont know desktop Feb 25 02:06:13 my desktops are sleepless Feb 25 02:12:12 * mwester doesn't get to sleep; neither should his computers. :D Feb 25 02:24:50 heh **** ENDING LOGGING AT Thu Feb 25 02:59:58 2010