**** BEGIN LOGGING AT Fri May 22 02:59:57 2009 May 22 03:05:36 I failed while compiling gcc-cross-initial, it reports: checking whether the C compiler works... configure: error: cannot run C compiled programs May 22 03:06:11 I checked config.log, it reports: can't find gmp.h file May 22 03:06:42 anybody knows this issue? May 22 04:34:03 hi guys any reason why a kernel recipe would fail to compile with __LINUX_ARCH_ARM__ is not define errors? May 22 04:34:32 quick google search said I should set ARCH=arm on the make line but this is supposed to be automatic isn't it (ARCH=${TARGET_ARCH} ?) May 22 06:19:40 hi, i wondered if some one could help. I'm trying to build Angstrom under Fedora and it always fails during do_rootfs for the image (log http://pastebin.com/mdaf0690) May 22 06:30:21 good morning May 22 07:18:05 * * OE Bug 5119 has been created by hbo22(AT)student.canterbury.ac.nz May 22 07:18:07 * * do_rootfs fails May 22 07:18:09 * * http://bugs.openembedded.net/show_bug.cgi?id=5119 May 22 08:02:40 | /usr/bin/perl Makefile.PL PREFIX='/data/openembedded/tmp/staging/i686-linux/usr' May 22 08:02:42 | Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: /etc/perl5 /usr/lib/perl5/i386-linux /usr/lib/perl5 /usr/local/lib/perl5/site_perl/5.8.9/i386-linux /usr/local/lib/perl5/site_perl/5.8.9 /usr/local/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/i386-linux /usr/lib/perl5/vendor_perl /usr/lib/perl5/vendor_perl .) at Makefile.PL line 1. May 22 08:03:00 is it perl-native? :) May 22 08:04:54 more info here: http://tinderbox.openembedded.net/public/logs/5387366.txt May 22 09:09:07 perl-native && perl have not fixed that error May 22 09:21:52 florian, zecke: good morning May 22 09:22:05 good morning May 22 10:06:07 03Koen Kooi  07org.openembedded.dev * rf924eacf0f 10openembedded.git/conf/distro/include/angstrom.inc: angstrom: stop disabling binary localegen for >=armv6 per RFC on the ml May 22 10:44:13 gm May 22 10:50:33 03Phil Blundell  07org.openembedded.dev * rba76dd503d 10openembedded.git/ (3 files in 3 dirs): May 22 10:50:33 bluez-libs: add 4.40, set default preference to -1 pending availability May 22 10:50:33 of apps May 22 10:53:04 OSError: [Errno 2] No such file or directory: '/home/booxter/projects/oe//tmp/work/armv7a May 22 10:53:09 -angstrom-linux-gnueabi/util-linux-ng-2.15-r2/install/e2fsprogs-libs-dbg' May 22 10:53:40 why does e2fsprogs-libs package look for files in util-linux-ng dir?.. May 22 10:55:41 sounds like a bug May 22 10:55:59 was it actually e2fsprogs-libs you were building, or util-linux-ng? May 22 10:56:12 e2fsprogs-libs package failed May 22 10:56:21 util-linux-ng is built ok May 22 10:57:58 morning May 22 10:58:17 gm May 22 10:58:59 hrw: morning. look at the bug above. I think you're one of the persons to blame :) At least, that's what git log on util-linux-ng says :) May 22 11:00:24 ow, I removed the latest changes made by Koen for e2fsprogs-libs/e2fsprogs-libs.inc and the stuff seems to be compiled and packaged ok May 22 11:10:00 Strange, I am unable to build latest pull for my gumstix. udev fails: udevd.c:(.text+0x16cc): undefined reference to `ppoll' Any idea anyone? May 22 11:11:22 are you pulling from .dev or from gumstix? May 22 11:15:03 hmm, good question May 22 11:15:27 I am making it based on instructions at gumstix.net, let me check. May 22 11:16:19 $ git clone git://gitorious.org/gumstix-oe/mainline.git org.openembedded.dev May 22 11:16:30 urg May 22 11:16:37 ? May 22 11:16:42 * Crofton|work kicks sakoman May 22 11:16:56 I was in morning speaking with him.. May 22 11:16:57 I'm surprised he let that go out :) May 22 11:17:12 heh his night then May 22 11:17:29 It will be pleasant morning for him ;) May 22 11:17:35 yeah May 22 11:18:08 I also have problem with flac, it wont currenty bitbake. May 22 11:18:16 I'm still getting going here, when I see him, I need to to talk to him about it May 22 11:18:42 would be nice, I gave him msg about this.. May 22 11:23:59 gm May 22 11:28:13 ppafin: we had a long discussion about the ppoll thing here yesterday, you could check the logs. I think the eventual outcome was that this is a kernel problem and needs to be fixed there. May 22 11:32:07 koen founs an issue with oldest kernel May 22 11:32:14 but Iam not certain that helps May 22 11:32:21 well, you can build May 22 11:32:39 but I ahve a boot hang on the beagle, but I do not know if it is related May 22 11:34:02 yes, it's hangs a boot for me also, because udevd does not build May 22 11:38:09 koen's OLDEST_KERNEL checkin will just swap the build time failure for a run time lockup. May 22 11:38:52 I think we talked about that yesterday as well. obviously if he feels that this is an improvement then that's fine, but it isn't going to fix the problem completely. May 22 11:39:42 absent a kernel workaround you might be able to revert to an older udev that's less dependent on ppoll; I'm not sure how deeply ingrained that requirement is in its code. May 22 11:40:12 I think I leave this to sakoman, all I just want is working system... May 22 11:40:31 but, ultimately, it's a kernel bug and that's where the fix needs to be done. I don't quite understand why it's taking those dudes so long, it doesn't seem like it is exactly rocket science. May 22 11:41:00 which dues? May 22 11:41:04 the kernel dudes May 22 11:41:17 ah kernel dudes in general, not OE ones May 22 11:41:40 pb_, yeah I thin kI see that May 22 11:41:49 a lockup May 22 11:42:10 xora: yeah, I was thinking more of the upstream arm h4x0rs. it probably wouldn't be too hard to patch it in oe if a fix is not forthcoming from upstream, but obviously it'd be a bit tedious to do that to all the kernels. May 22 11:42:19 I think we'll need to go back to udev without ppoll until we fix the kernel May 22 11:43:07 yes, if there is an older udev you can use that doesn't need ppoll(), that's probably the best short term workaround. May 22 11:43:26 pb_, agreed May 22 11:43:39 at least we know the problem May 22 11:43:49 and how to set the kernel version var May 22 11:44:12 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729 seems to be the ubuntu version of the bug report May 22 11:44:47 yup, that's the one May 22 11:45:27 I think Remnant's analysis is correct. May 22 11:45:40 http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=d5de99808128ffd1f02e069c790907faa56d0c4d May 22 11:45:47 so udev mioves with hal? May 22 11:48:04 hal does require a minimum level of udev, yeah, so you might have to downgrade hal as well if udev is backed down. May 22 11:48:19 you'd have to check the hal package to find out exactly what its requirements are. May 22 11:48:29 I am testing a build based on reverting that change May 22 11:49:18 I'd look at the kernel change, but googling is not helpful May 22 11:49:33 there is a patch for ppoll link to in that thread which never gets commented on :-( May 22 11:49:40 and I have to do a tutorial in 2 weeks that I am not prepared for :) May 22 11:49:47 hmm May 22 11:49:52 okay, very good May 22 11:50:02 maybe someone can try that also May 22 11:50:18 http://www.spinics.net/lists/arm-kernel/msg38114.html May 22 11:51:07 thanks XorA May 22 11:51:19 yeah, that looks like the right kind of thing May 22 11:52:56 that patch is from 2007 :( May 22 11:53:30 right, that's what I meant by not understanding why it was taking the kernel h4x0rs so long. May 22 11:53:51 likely ppoll is not in wide use May 22 11:53:53 in typical arm fashion it probably doesnt happen on a RiscPC from 1995 May 22 11:54:03 or the udev case is the first to actually hang May 22 11:54:12 yeah, that might be true. May 22 11:54:35 ppoll() is a fairly new thing, it seems to be linux's response to pselect() being mandated by new posix. May 22 11:54:58 obviously linux wouldn't want to actually implement what posix requires, that'd be silly, but ppoll() is basically equivalent. May 22 11:55:58 I suspect there probably isn't all that much code that relies on it heavily yet, and as you say in a lot of cases it could well be that you just don't notice the breakage even when apps are trying to use it. May 22 11:56:12 yeah May 22 11:56:22 life on the edge May 22 11:56:32 If OE hasn't noticed it much I'd be surprised if nobody else did. May 22 11:56:41 yeah May 22 11:56:55 s/nobody/someone/ duh May 22 11:56:55 people should pay us for this crap :) May 22 11:57:04 ubuntu obviously noticed it May 22 11:57:16 what is ubuntu? May 22 11:57:18 :) May 22 11:57:56 I was away, did you came any conclusion regarding this issue? May 22 11:58:13 apropos signals and the kernel, that reminds me, someone should benchmark whether the SA_RESTORER thing is still a win now that the kernel does its funky high page return stuff. May 22 11:58:27 ppafin, we need to test reverting the udev update May 22 11:58:35 and the kernel patch with the new udev May 22 11:58:51 ok, can I be any assistance? May 22 11:59:10 Probably just needs someone to push the patch at lakml a little. May 22 11:59:42 * XorA volunteers broonie + cricket bat :-D May 22 11:59:47 well, best test it first I guess :-} May 22 11:59:58 pb_: Where's your sense of adventure! May 22 12:00:11 heh May 22 12:00:16 since when did linux arm releases get testing :-) May 22 12:01:37 otavio: glibc 2.6.1 is not buildable for geodelx with your patchset. neither TARGET_ARCH=i586 or i486 May 22 12:04:00 03Koen Kooi  07org.openembedded.dev * ree47628688 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 22 12:04:11 03Matthieu Poullet  07org.openembedded.dev * r567e88579c 10openembedded.git/ (4 files in 2 dirs): (log message trimmed) May 22 12:04:11 wget: update to version 1.11.4 May 22 12:04:11 The actual version was released in 2003, so I think it's time to update it. May 22 12:04:11 This patch prepares the transition and allows other to test the latest release. May 22 12:04:13 Regards, May 22 12:04:15 Matthieu. May 22 12:04:17 Signed-off-by: Matthieu Poullet May 22 12:04:19 03Koen Kooi  07org.openembedded.dev * rf2ec20f498 10openembedded.git/recipes/hal/consolekit_0.3.0.bb: consolekit: fixes suggested by RP May 22 12:23:12 hal seems to be hal seems to be unbuildable in .dev May 22 12:27:56 I have setup openembedded build env on fedora 9 and have some issues May 22 12:28:15 while compiling source packages May 22 12:28:59 bitbake -vv -b /home/mvl6/work/OE/openembedded/recipes/bind/bind_9.3.1.bb May 22 12:29:07 it seems that angstrom/2008.1 distro doesn't prefer specific hal version but e2fsprogs-libs and e2fsprogs versions it preferes are too old for newly added hal May 22 12:29:20 /usr/bin/autoreconf: unrecognized option `--exclude=autopoint' May 22 12:29:20 | Try `/usr/bin/autoreconf --help' for more information. May 22 12:29:20 | FATAL: autoreconf execution failed. May 22 12:29:20 NOTE: Task failed: /home/mvl6/tmp/work/armv4t-angstrom-linux-gnueabi/bind-9.3.1-r1/temp/log.do_configure.21137 May 22 12:29:50 I amgetting above errors May 22 12:31:08 Hi booxter, Can you plz answer my qestion May 22 12:31:52 ashukla: why do you specify the full path for recipe? May 22 12:32:22 thanks for reply, otherwise also I am getting problem May 22 12:32:52 [mvl6@localhost ~]$ bitbake squid May 22 12:32:52 NOTE: Psyco JIT Compiler (http://psyco.sf.net) not available. Install it to increase performance. May 22 12:32:52 NOTE: Parsing finished. 0 cached, 0 parsed, 0 skipped, 0 masked. May 22 12:32:52 NOTE: Cache is clean, not saving. May 22 12:32:52 ERROR: Nothing PROVIDES 'squid' May 22 12:33:17 I am newbie to OE May 22 12:33:21 ashukla, what are you trying to do? May 22 12:34:07 I am trying to build bind package for angstrom/2008.1 distro and beagle board May 22 12:35:28 what happens when you do bitbake bind? May 22 12:35:44 same errors as above May 22 12:35:59 ERROR: Nothing PROVIDES 'bind May 22 12:37:58 ashukla, have you built anything with oe? May 22 12:38:46 On ubuntu host I am able to build the userland packeges but for fedora not May 22 12:39:06 Can you plz help me out May 22 12:39:38 what happens if you try bitbake nano? May 22 12:40:37 Crofton|work: why are you kicking me so early in the morning! May 22 12:41:29 If you are unconfortable better take sleep May 22 12:41:33 thanks May 22 12:41:41 heh May 22 12:41:45 and why is udev-141 building and working just fine for me? May 22 12:42:02 depends when you did the pull I thinnk May 22 12:42:10 and if you do a clean build May 22 12:42:33 clean build of udev or complete system? May 22 12:42:41 complete system May 22 12:42:47 ah May 22 12:42:57 also koen pushed a fix for the compile problem May 22 12:43:05 it is pretty confusing May 22 12:43:17 I my beagle is still hangin with old udev May 22 12:43:35 so does koen's fix eliminate the clean build issue? May 22 12:43:44 it does May 22 12:43:51 if so then I will be a happy camper May 22 12:43:53 by making gcc stub ppoll May 22 12:44:06 there is also a kernel patch to implement ppoll May 22 12:44:43 what we are not certain about is if not having a real ppoll is a problem May 22 12:44:51 I thought I was certain May 22 12:45:13 hrw: I built it here; it must be another thing May 22 12:45:27 I am playing with oveo today, but am afraid to update May 22 12:45:39 and my beagle is being a pain for some reason May 22 12:47:12 otavio: probably May 22 12:47:49 Crofton|work: I will try a clean build with koen's fix May 22 12:47:55 yeah May 22 12:47:57 good idea May 22 12:48:13 but udev-141 with an unclean build is working just fine May 22 12:48:15 I need to make gnuradio work with a usrp today May 22 12:48:22 so no testing there for me May 22 12:48:44 that means you have ppoll in glibc May 22 12:49:43 is that typical? May 22 12:50:10 there was another change that took it out May 22 12:50:23 the minimum kernel version or something update May 22 12:50:40 ah, ok. has that been reverted? May 22 12:50:58 no, it was changed to reflect the version that introduced ppoll May 22 12:51:14 during the poking around, we found ppoll is not in the arm kernel May 22 12:51:24 there is a patch around to fix this May 22 12:51:28 hmm . . . has something changed with the git server? I don't see any updates in the last 42 hours May 22 12:51:43 git is at git.openembedded.org May 22 12:51:52 you need to read .dev :) May 22 12:52:16 so many lists I "need" to read :-( May 22 12:52:33 hrw: I'm using this patchset in stable May 22 12:52:50 hrw: and it can influence those things since it doesn't has all changes in dev May 22 12:52:59 hrw: did you try to use gcc 4.3.2? May 22 12:53:09 hrw: I'm using it in our distro May 22 12:53:17 or you just wait until something changes and ask here :) May 22 12:53:41 otavio: I am using .dev with 4.3.3 gcc May 22 12:53:49 otavio: | checking sysdep dirs... configure: error: The geode subspecies of i486 is not supported. May 22 12:54:06 otavio: if I switch TARGET_ARCH to i586 message is similar May 22 12:54:15 hrw: ahh this is glibc configure May 22 12:54:31 hrw: I saw it once, let me remember how I fixed it May 22 12:54:36 otavio: ok May 22 12:55:07 hrw: are you using xorg at this machine? May 22 12:55:24 otavio: no, but can May 22 12:57:48 hrw: I'm having trouble with geode driver May 22 12:57:58 hrw: and would be nice if you could give it a try May 22 12:58:25 * otavio confuses; he is using this patch and this works May 22 12:58:34 * otavio asks himself why it fails to hrw May 22 12:58:56 sakoman, btw ppafin was having the build issue againt gumtix oe May 22 12:59:00 otavio: first I have to pass glibc May 22 12:59:25 Crofton|work: yeah, I know he was doing a clean build so that makes sense May 22 12:59:32 yeah May 22 12:59:40 last clean build for me was a week ago so I haven't seen it May 22 12:59:43 I guess you have not had coffee yet May 22 12:59:52 in hand! May 22 13:01:43 hrw: it is quite strange since I did a clean build two days ago May 22 13:03:50 Crofton|work: just did the merge with new server. I'll try an unclean build first to make sure functionality isn't broken and then a clean build to make sure that works too May 22 13:04:04 hrw: please apply this: http://pastebin.com/f6640d6f7 May 22 13:05:42 great May 22 13:06:16 hrw: but it confuses me May 22 13:06:33 otavio: restarted build May 22 13:06:40 hrw: I remember to saw this error once but not how I fixed it May 22 13:25:11 hi, were the patches for glibc and qemu pushed...because I've FATAL: kernel too old May 22 13:42:57 btw does oe have workable qt toolchain? May 22 13:45:27 what do you mean by 'qt toolchain' exactly? May 22 13:46:15 it does have various versions of qt for the target. I don't think it has Designer and suchlike, if that's what you meant. May 22 13:47:58 03Rolf Leggewie  07org.openembedded.dev * r9dc71d0fb7 10openembedded.git/recipes/bluez/ (2 files in 2 dirs): May 22 13:47:58 bluez: document that hciattach-ti-bts.patch has landed upstream May 22 13:47:58 sometime between 3.35 and 3.36 May 22 13:51:58 guys: how to check fstype of mountpoint? May 22 13:52:24 cat /proc/mounts? May 22 13:53:01 pb_: fstype=rootfs is not good. I need ext3 there.. May 22 13:54:39 pb_: by default OE has "rootfs / rootfs rw 0 0" and I need to know is it ext2/3/4 or jffs2/ubifs etc May 22 13:54:51 as I want to have fsck running on boot May 22 13:55:38 ah, I see. May 22 13:55:48 and you don't have a dependable fstab, presumably? May 22 13:56:04 my fstab also has 'rootfs' like entry May 22 13:56:07 obviously the traditional way of dealing with that is just to inspect the entry for / in /etc/fstab. May 22 13:56:18 so, fixing your fstab would be the first thing to consider. May 22 13:56:20 "rootfs / auto defaults 1 1" May 22 13:56:46 failing that I think you can get the information from statfs() but I don't know if it's exposed to the shell in any convenient form. May 22 13:58:59 "stat -f / -c %T" May 22 13:59:04 or, failing all else, in the specific case of the rootfs you could just mandate that the bootloader needs to pass it to the kernel (most do) and fish it back out of /proc/cmdline. May 22 13:59:05 returns 'ext2/ext3' ;D May 22 13:59:12 ah, very good May 22 14:00:23 but that require coreutils ;( May 22 14:01:07 how can I produce a patch suitable for git-send-email from HEAD? May 22 14:01:08 you could always write a standalone binary to do that job, it's only about four lines of code. May 22 14:01:10 hm. busybox can have it too May 22 14:01:12 I don't want to commit things first May 22 14:01:25 Laibsch: git format-patch -n -1 HEAD May 22 14:01:36 Laibsch: dont be afraid of commiting into git May 22 14:01:50 Laibsch: you can always do 'git reset --hard HEAD~1' May 22 14:02:06 It's not that I'm afraid May 22 14:02:18 But then I have to come up with a commit message May 22 14:02:28 And have undo that commit May 22 14:02:51 For things I want to review, I'd rather keep that in stash until I can actually commit it May 22 14:03:08 strange May 22 14:03:18 I prefer to have work/something branch for such stuff May 22 14:03:23 hrw: I think "git format-patch -n -1 HEAD" also takes the last commit, not the changes in the work dir May 22 14:03:38 Laibsch: git do not care about changes. it wants commits May 22 14:05:59 I guess I can't commit to branch if I don't check it out first, can I? May 22 14:06:06 Laibsch: the kind of workflow you're trying to use isn't really what git is designed for. traditionally with git you'd check all your own stuff in on a branch, then get the contents of the branch reviewed, and then land it on the HEAD either by sending a patch or by having someone else pull from your branch. May 22 14:06:27 * Laibsch is still learning the best git way May 22 14:06:29 ;-) May 22 14:06:45 obviously there's nothing to stop you from using your own workflow if you prefer, but git doesn't give you much support in that case. May 22 14:07:01 Laibsch: http://www.andrewmoore.com/public/index.php/My_git_workflow May 22 14:07:06 Well, here is what I do, please criticize/suggest May 22 14:07:11 you'd basically have to implement your own git-send-email kind of thing based on the output of 'git diff' or something. May 22 14:07:20 Laibsch: read that - its nice howto May 22 14:07:30 yes, thanks May 22 14:07:37 I'll come back if anything is unclear May 22 14:07:43 Laibsch: http://bec-systems.com/web/index.php?option=com_content&task=view&id=77&Itemid=9 was also nice May 22 14:08:55 alright, one quick question before I wade through all that text May 22 14:09:11 Can I work on the branch that I use for compiling stuff? May 22 14:09:22 I don't want to switch too much to and from it, though May 22 14:09:47 The reason is May 22 14:10:36 !oebug 5102 May 22 14:10:37 * * Bug 5102, Status: UNCONFIRMED, Created: 2009-05-19 13:10 May 22 14:10:39 * * : TMPDIR and switching branches May 22 14:10:39 * * http://bugs.openembedded.net/show_bug.cgi?id=5102 May 22 14:11:16 why not May 22 14:16:31 why not switch branches you ask? May 22 14:16:52 you can work on branch which you compile May 22 14:17:09 The reason is given in bug 5102. I am afraid that switching back and forth between .dev and .stable for example will screw my TMPDIR May 22 14:17:29 That is why TMPDIR includes the branch name for me May 22 14:17:43 tmp/$DISTRO/$BRANCH/ May 22 14:19:00 Laibsch: wouldn't it be easier just to keep two TMPDIRs, one for each branch? May 22 14:19:04 I just use different dirs for builds. May 22 14:19:07 But I have found that bitbake will somehow forget about $BRANCH and use tmp/$DISTRO as TMPDIR the next time it runs when I switch branches May 22 14:19:40 build/angstrom/ is for .dev and has own conf/ tmp/ dirs, build/stable/ is for stable/2009 etc May 22 14:19:40 I want this to be generally usable for my apt-getable OE May 22 14:20:22 I need to close bash and open a fresh console and then everything is back working fine May 22 14:21:46 what I do is have a git hook for checkout to produce .git/openembedded/branch.conf with content GIT_BRANCH="org.openembedded.dev" May 22 14:22:07 hmm, who manages cutting stuff over to stable? May 22 14:22:14 that is sourced from my start scripts and $GIT_BRANCH is part of my definition of TMPDIR May 22 14:22:29 if i maintain packages, is that me for my packages? May 22 14:22:36 timtimwork: look at the wiki May 22 14:22:47 there is a page on the stable branch that should describe this May 22 14:22:54 hrw lined out the steps May 22 14:22:55 okies will do :) May 22 14:23:17 ta! May 22 14:23:45 shit.. May 22 14:23:58 rootfs in fstab == /dev/root == no idea what... May 22 14:24:22 as /dev/root do not exists May 22 14:24:38 I guess there is no way to commit to a branch without checking it out, right? May 22 14:25:02 Laibsch: if you are afraid of breaking your working copy then clone to other dir May 22 14:25:25 that is not really what I want, either May 22 14:25:32 of course, I want to test my work May 22 14:25:45 hrw: you can get the device id for / from stat() and use that to create /dev/root if you want. May 22 14:25:49 so it needs to be the directory that bitbake accesses May 22 14:25:56 right May 22 14:33:04 ~curse rootfs May 22 14:33:05 May you be reincarnated as a Windows XP administrator, rootfs ! May 22 14:34:53 morning May 22 14:35:29 pb_: device id is one value. mknod expects two.. and wants them in decimal. May 22 14:36:14 hrw: a stupid question .. May 22 14:37:08 this is the correct #oe chat for development, isn't it? There are only 3 people, maybe is because is friday afternoon. May 22 14:37:24 16:37 -!- Irssi: #oe: Total of 156 nicks [1 ops, 0 halfops, 0 voices, 155 normal] May 22 14:37:33 recalcati_oe: as you see I see more then 3 May 22 14:39:08 you mean "Idlers" May 22 14:39:21 -!- Irssi May 22 14:39:35 16:37 -!- Irssi May 22 14:39:46 16:37 -!- Irssi: #oe May 22 14:40:00 hrw: it's a bitfield, you just need to split it into two parts May 22 14:40:02 How do you write that funny command? May 22 14:43:04 pb_: I gave up. sed -e 's/.*root=\([a-zA-Z0-9/]*\).*/\1/g' /proc/cmdline is working for sane devices May 22 14:43:48 /proc/cmdline is working for sane devices May 22 14:43:51 ops May 22 14:44:22 fair enough. personally I still think you should just fix your fstab, but I guess it's up to you :-} May 22 14:45:08 pb_: I want to keep possibility to use few rootfs with same fstab May 22 14:49:07 recalcati_oe: instead of using mibbit you could use a real irc client May 22 14:54:54 * Laibsch has a kind of deja-vu, it's about that time of day, too May 22 14:55:37 mount is insane... May 22 14:56:00 'mount -n -o remount,ro /' form checkroot == mount: you must specify the filesystem type May 22 14:58:58 mckoan: ehi May 22 14:59:18 you can suggest me a good one? May 22 14:59:25 hrw: that's probably the kernel to blame, not mount. May 22 14:59:27 what does strace say? May 22 15:00:33 recalcati_oe: irssi May 22 15:00:41 pb_: when I do that from commandline it works fine May 22 15:00:47 I was looking, thx, I try it May 22 15:02:46 that is a bit weird. still, same applies, probably need to see strace output to figure out what's wrong. May 22 15:05:11 looks like changing fstab will be needed anyway ;( May 22 15:05:20 goodbye one fstab for all systems May 22 15:05:53 one fstab to rule them in the land of shadows May 22 15:06:16 is having one fstab per device such a big deal? it's not exactly a complicated thing to create. May 22 15:06:39 to be honest, if you're not going to put the correct (i.e. device-specific) information in fstab then you might as well not bother shipping it at all. I don't think a dummy, generic kind of fstab buys you much. May 22 15:08:01 mckoan: not possible, I'n in a protected LAN and irssu use 6667 for irc.freenode.net . May 22 15:08:57 mckoan: I'm looking maybe is possible to login outside via proxy May 22 15:11:19 anyway somehow I end with /dev/root / even with proper fstab May 22 15:12:23 morning May 22 15:12:28 yo kergoth May 22 15:12:31 hi kergoth May 22 15:12:41 gm May 22 15:13:20 * kergoth wonders about using our -dbg files to add traceability back to sources from our binaries May 22 15:13:38 morning all kergoth, hrw, mckoan pb_ May 22 15:13:41 kergoth: explain? May 22 15:13:43 hi gremlin[it] May 22 15:13:51 hi gremlin[it] May 22 15:14:16 kergoth: traceability in what sense? May 22 15:16:29 so you know exactly what flowed into what you're distributing. the filename info in the debug output would enable you to know what inputs fed into what outputs. I'm thinking about embedded alley's new features, they're commonly requested by companies using bitbake, the manifest / bill of materials / tracing of inputs/outputs through the process from beginning to end May 22 15:16:51 so you can then in turn show what versions of what files from their scm went into a build, as an example May 22 15:16:59 hi gremlin[it] ready for relaxing weekend or still busy? May 22 15:17:12 particularly cm folks who've used tools like clearmake in the past like that sort of thing May 22 15:17:14 heh May 22 15:19:44 mckoan, half and half ... wanna play with the AVR32 board (and OE) and have to look at some furniture factory ... May 22 15:20:24 guh, sleepy May 22 15:20:37 * pb_ hands kergoth a flagon of coffee May 22 15:20:43 huzzah May 22 15:20:44 kergoth: apart from the filename (which is already in) you mean things like the OE commit hash etc? May 22 15:21:44 I'm not sure what you mean by "which is already in" May 22 15:22:05 kergoth: -dgb contains a reference to the source file (last time I remotely debugged) May 22 15:22:25 * likewise wonders if he is completely mistaken now - and is checking his notes May 22 15:22:34 i know, thats why i brought this up. i was thinking about making use of that information in reporting facilities so the user knows what fed into the output May 22 15:23:05 well, ideally I'd like to track the input and output of every bitbake task, but that's a pipe dream at this point :) May 22 15:23:10 what is the status of stable openembedded branch? I'd like to pull and customize a console + qt 4.5 system. May 22 15:23:49 recalcati_oe: it is stable as in "if it works for you, it tends to keep working for you". May 22 15:24:23 recalcati_oe: where-as .dev: "if it works today, it probably won't work tomorrow, but it might work again the day after" May 22 15:25:10 likewise: yes,clear, I'm back to look oe, because I was working on other project last weeks May 22 15:25:59 qt 4.5 on frame buffer should be integrated with examples, I hope May 22 15:27:09 likewise, yes ... and isn't a good thing .. specially with the second rule "no patch for stable if not tested on dev" ... May 22 15:27:55 bye, I have to go. May 22 15:28:09 gremlin[it]: no patch for stable if not present in dev May 22 15:28:34 hrw, true ... i write bad ... May 22 15:51:06 zecke: parser work looks great overall, i don't see any obvious problems when reviewing the patches. need to do more test builds with the patchset applied though :) May 22 15:53:22 kergoth: yes, I wondered if I should patch one bitbake and pickle all data dicts May 22 15:53:29 kergoth: then reparse and diff the dicts :) May 22 15:53:37 i thought about that too :) May 22 15:53:40 not a bad idea May 22 16:03:06 kergoth: not sure I really understood your -dbg idea May 22 16:03:09 but two comments May 22 16:03:29 first, doesn't dpkg --info $ipk give you the info you want? May 22 16:03:52 second, not all packages actually create a -dbg package, I think May 22 16:03:54 I'm talking about keeping track of what *sources* fed into what binaries May 22 16:04:01 i dont see how a list of files in the package gives you that information May 22 16:04:04 Last I looked, that was listed May 22 16:04:13 Let me check May 22 16:04:59 no, thats a list of the files in SRC_URI May 22 16:04:59 I'm talking about actual sources May 22 16:06:00 you mean including full URI? May 22 16:06:17 no, i mean exactly what .c and .h files went into a binary. May 22 16:06:18 Or including the source tarball? May 22 16:06:31 Oh, I guess the tarball May 22 16:06:32 guys any reason why my kernel build would fail with __LINUX_ARM_ARCH__ not defined? I checked the log and the kernel make command being run has weird stuff in it (CC=ccache armv7e-gnueabi-blah) which I expected would need quotes, and there is no ARCH=arm variable May 22 16:07:02 kergoth: how about creating a new ipk? May 22 16:07:16 Again, not all packages will create -dbg May 22 16:07:30 and again, I'm just toying around with possible ways of tracking inputs and outputs May 22 16:07:36 Yes, good idea May 22 16:07:40 I'm toying with you May 22 16:07:42 ;-) May 22 16:08:21 One problem I see is that if you want to include the tarball, -dbg will be a monster for things like minimo May 22 16:08:23 i think my sense of humor needs more caffeine May 22 16:08:41 Laibsch: any package that generates compiled binaries ought to be producing a -dbg. May 22 16:08:48 if it isn't, that's a bug, and we should fix it. May 22 16:09:12 OK May 22 16:09:13 and, even if it weren't a bug, it would be easy enough to force -dbg generation on for this specific case. May 22 16:09:19 Sure May 22 16:09:44 bbl May 22 16:09:45 So, last thing to consider would be the possibly considerable increase in size May 22 16:09:49 kergoth's plan seems sound enough to me, although I don't personally have much interest in researching the provenance of my binaries :-} May 22 16:09:57 at least that is the last thing I could think of now May 22 16:10:18 yes, it sounds like an interesting thing to have May 22 16:10:21 aye, I doubt I'd use it much myself, but some cm people are crazy about that sort of thing May 22 16:10:29 if somebody volunteered to implement it ;-) May 22 16:10:38 it's on my list... way, way, way, way down the list.. May 22 16:10:41 well, you could make it optional, though I kind of feel that as soon as you talk about installing -dbg packages you probably don't care much about space anymore. May 22 16:10:55 kergoth: where abouts on that list is bug 518? ;-) May 22 16:11:02 oh, right :P May 22 16:11:02 Number from memory May 22 16:11:18 okay, i think i'll get that taken care of today, i dont have much on my plate at work at the moment May 22 16:11:27 debug data can already be many megabytes so this wouldn't be an order-of-magnitude kind of explosion for those packages. May 22 16:11:28 cool, that would be awesome May 22 16:11:33 finished my current bug yesterday May 22 16:14:47 Laibsch: okay, reviewing the patch finally, and it looks like itll explode with a divide by zero if you upgrade tslib but don't re-run ts_calibrate, or if they use a calibrator other than ts_calibrate. May 22 16:14:52 Laibsch: or am i missing something here? May 22 16:15:31 I can't comment on the quality of the patch, really May 22 16:15:40 I just wanted you to take a serious look May 22 16:15:48 Exactly because I can't ;-) May 22 16:15:55 !oebug 518 May 22 16:15:56 * * Bug 518, Status: ASSIGNED, Created: 2005-12-10 05:39 May 22 16:15:57 * * mardy(AT)users.sourceforge.net: \[PATCH\] tslib: work with different screen resolution May 22 16:15:58 * * http://bugs.openembedded.net/show_bug.cgi?id=518 May 22 16:15:59 this is the sort of bug i expected to find, and is why i avoided looking at it up until now :) May 22 16:16:10 i don't have any actual ts hardware handy to test with May 22 16:16:15 wait, i take that back May 22 16:16:19 my dad mailed me my old zaurii May 22 16:16:24 i should resurrect one May 22 16:16:31 I can test Zauri for you if you want me to May 22 16:16:36 collie and spitz May 22 16:16:48 and I use them and want to continue using them May 22 16:17:12 Laibsch: I'm thinking it should just default to current screen resolution if it fails to get it from the calibration file. May 22 16:17:16 Laibsch: does that seem sane to you? May 22 16:17:35 kergoth: I don't think it'll explode, it checks for lin->cal_res_x != 0 before dividing by it May 22 16:17:50 afaict, it'll just behave in the old way if you don't have a resolution specified, which probably isn't such a bad plan May 22 16:18:04 oh, right, I'm blind :) May 22 16:18:08 nevermind then, looks fine May 22 16:18:11 cool May 22 16:18:42 Is that patch in OE already? Can we expect a new release of tslib that includes this? May 22 16:18:54 IOW, how should we deal in OE with this? May 22 16:18:55 i'll commit to tslib shortly May 22 16:19:04 cool May 22 16:19:39 will we see tslib 1.1? May 22 16:20:00 heh. ten months to the day since kergoth reported that he felt his motivation returning :-} May 22 16:20:19 hehe May 22 16:20:43 well, i tried to come back to OpenEmbedded stuff like 4 times before doing it for mv May 22 16:20:44 well, it's coming back in a big, crushing wave now May 22 16:20:48 (and failed) May 22 16:20:56 heh, indeed May 22 16:21:01 well, good to see you active again May 22 16:21:05 that's all I say May 22 16:21:47 yeah, all we need is to get mickey back as well and it'll be just like old times. May 22 16:21:49 and recently I've already seen a fair bit of code from your side that I thought was plain cool May 22 16:22:02 OE is bigger now May 22 16:23:00 Laibsch: don't worry, kergoth can handle it May 22 16:24:20 he's got the shaved head and the mean attitude now. May 22 16:24:40 actually, I guess he always had the mean attitude. oh well. May 22 16:25:27 hahah May 22 16:28:30 kergoth: what's the word on mv picking up oe? May 22 16:28:54 you missed the announcements? May 22 16:29:22 likewise: http://www.linuxdevices.com/news/NS8766209836.html May 22 16:29:33 likewise: the mvl6 integration platform is based on bitbake/oe May 22 16:30:29 it is not mentioned there, is it? May 22 16:31:14 http://tinderbox.openembedded.net/public/logs/5391607.txt May 22 16:31:33 can anybody suggest some solution? :) May 22 16:32:30 bye May 22 16:33:06 likewise: May 22 16:33:07 kergoth: we looked at mv linux versus qnx versus oe linux 5 years ago, and decided for the latter approach in our company. May 22 16:33:07 "MontaVista Integration Platform -- This new bitbake build engine provides standard recipe file formats to customize kernel, device drivers, libraries, and applications, says MontaVista. Built on standard open source technology and incorporating a command-line interface, the Integration Platform enables developers to fetch and integrate code from other team members, outside vendors, or the open source community, says the company. Developers can build all targe May 22 16:33:13 likewise: copied & pasted from that link May 22 16:33:32 kergoth: ah bitbake is mentioned indeed May 22 16:33:50 there's an interview with joe green that covers a bit more info i think May 22 16:33:50 lets see May 22 16:33:57 there's also a webcast showing video of its use May 22 16:34:07 http://bec-systems.com/site/425/montavista-linux-6-is-based-on-openembedded-technologies May 22 16:34:17 http://mvista.com/download/playvideo.php?v=MVL6_Demonstration May 22 16:36:25 ooh, thats neat, i didn't realize, though i should have, that the git stash is just a ref, and git stash list just does a git reflog of the ref May 22 16:38:25 * likewise watching May 22 16:38:47 oh mvl is oe based now May 22 16:38:57 are they publishing their changes somewhere? May 22 16:39:14 I've already pushed lots of stuff I've done for mv with OpenEmbedded May 22 16:39:19 and will continue to do so May 22 16:39:22 but there's no public git repo or anything May 22 16:39:28 so no then :) May 22 16:40:23 * kergoth thinks the installers, content delivery tools / content server, and mvl-project makes getting up and running really easy May 22 16:40:27 and fast May 22 16:42:16 OE is MIT right? May 22 16:42:19 Laibsch: 518 is committed. is there anything else on my plate that I've forgotten about, that you know of? :) May 22 16:42:27 so corps can just rip it and not give anything back? May 22 16:42:29 timtimwork: yep. bitbake is gpl, but OpenEmbedded is MIT May 22 16:42:37 kergoth: OH NO It's Klaas explaining the installation May 22 16:42:38 yes, we always wanted it that way to encourage adoption May 22 16:42:43 likewise: :) May 22 16:42:45 indeed it is May 22 16:42:54 Dutch Coalmine English May 22 16:43:02 haha May 22 16:43:09 kergoth: cool, thanks. May 22 16:43:14 that doesnt encourage cutting changes back over at all though, from a community perspective its not great :) May 22 16:43:19 if people were curious about why klaas's latest OpenEmbedded presentation talked about its flaws, that most were well known, now you know why May 22 16:43:23 kergoth: Klaas stil llives in .ca May 22 16:43:27 kergoth: The script we talked about yesterday, has that landed in OE? May 22 16:43:35 questionmark May 22 16:43:49 timtimwork: well, it's working well for the project thus far, and has kept our marketshare and adoption high May 22 16:44:00 likewise, if klaas can explain it,everyone can :-) May 22 16:44:02 and many have been contributing back even when they aren't required to May 22 16:44:04 people making money off our work with any obligations, basically May 22 16:44:14 thats how i see it :) May 22 16:44:20 you're welcome to your opinion May 22 16:44:25 * eFfeM thought the dutch coalmines were closed long ago :-) May 22 16:44:40 linux is GPL, that doesnt stop these same corps using it :) May 22 16:44:52 that works May 22 16:44:54 anyway :) May 22 16:44:55 this is just metadata, it's not like it's substantial value May 22 16:44:58 ooh, they fixed a src_uri May 22 16:45:00 who gives a fuck May 22 16:45:18 regardless, we'll have to agree to disagree on this, I'm thinking May 22 16:45:26 what? OE is not of substantial value? :) May 22 16:45:34 yeah sure :) May 22 16:45:37 as a collective it is May 22 16:45:43 the movie stopped downloading during the demo showed downloading the recipes :-) May 22 16:47:25 if they do not bring in changes perhaps we can bash them at a major conference, like GKH did with ubuntu :p May 22 16:47:34 hehe May 22 16:47:35 good plan May 22 16:47:58 but really, OpenEmbedded is as guilty of that as anyone else. very, very few of our patches have gone to *any* upstream May 22 16:48:03 sadly May 22 16:49:33 basically i am quite confused with the whole process and how the stream actually goes and who decides etc May 22 16:49:45 eFfeM: decides what? May 22 16:50:14 http://wiki.openembedded.net/index.php/Push_patches_upstream May 22 16:50:19 what is accepted and what not, some things are just not taken because the format is deemed to be improper or because it comes over the wrong channel May 22 16:50:39 Laibsch: was unaware of that page May 22 16:50:51 you're talking about pushing patches *into* OE, right? May 22 16:51:17 out of OE to other projects... May 22 16:51:28 ie, recipies May 22 16:51:45 timtimwork: kergoth was talking about that, yes May 22 16:51:46 cute, hadnt seen that wiki page, i like that May 22 16:52:02 no, what i had a few times is that I had a problem, found the cause, made a fix, had no good way to get it to the author (if a package) or to a specific subsystem dev (if it is a kernel issue) May 22 16:52:04 we've already had a few push'em weekends May 22 16:52:07 two or three May 22 16:52:25 could use a sanity check on http://kergoth.pastey.net/114719 if someone has a moment May 22 16:52:29 fair success, but not overwhelming May 22 16:52:38 may be useful as default behavior, doesn't hurt anything May 22 16:53:23 example: had a patch to extend timing in mmc driver for beagle and kingston, sent it to the mmc maintainer, got rejected as some devices do not have a register that supports a longer timout May 22 16:53:24 it took me half a year (and 10 releases) to push a trivial patch back into lighttpd May 22 16:53:52 packages are sometimes worse sometimes a heaven, depends greatly on the developer May 22 16:53:54 pushing upstream seems even harder then pushing to OE :-) May 22 16:54:03 hi again, were the patches for glibc and qemu pushed...because I've FATAL: kernel too old May 22 16:54:24 likewise: by far, since OpenEmbedded accepts patches that are hacks, really.. as long as it works, we tend to let it go May 22 16:54:25 for coherence e.g. getting patches in the next release is very easy, but for other packages it is a nightmare May 22 16:54:52 kergoth: agreed May 22 16:56:29 hacky patches are part of the embedded fun. May 22 16:56:31 :) May 22 16:56:38 hehe May 22 16:56:46 true that, its all about getting shit out the door.. May 22 16:56:51 it's like drilling a hole to a BGA ball and then soldering a wire May 22 16:57:00 to workaround a hardware design error May 22 16:57:04 likewise: cool May 22 16:57:16 some of our patches would have trouble going upstream just because upstreams tend to not care about their buildsystems May 22 16:57:18 FAIL last week :-) May 22 16:57:24 no build/cm folk, and devs just want to leave it alone if it works May 22 16:57:51 * likewise is tracing a racy heisenbug May 22 16:58:30 no ideas on the kernel command line thing then? :/ May 22 16:58:47 is there any way I can append something to the make arguments for the kernel build without replacing do_compile ? May 22 16:59:10 Neko: Using += should work on the variable May 22 16:59:14 kergoth: you asked about your plate. Can you close bug 518? What should we do in OE about it, push a patch, wait for a release? May 22 16:59:18 EXTRA_OEMAKE += .. May 22 16:59:36 aha :) May 22 16:59:40 Neko: do you want to append to the kernel command line? May 22 16:59:42 Laibsch: ah, will do. I'm used to only resolving, and letting the submitter verify, and then close :) May 22 16:59:47 Neko: or to the make of the kernel? May 22 16:59:52 no, I want to append to the make arguments May 22 16:59:55 not sure whats best in OpenEmbedded May 22 16:59:56 k May 22 17:00:00 * kergoth looks at the tslib recipe May 22 17:00:01 kergoth: Furthermore, I see bug 3156 and 4452 May 22 17:00:09 okay, thanks for the pointers :) May 22 17:00:11 it's not setting ARCH=arm for some odd reason and right now.. I need this kernell to build May 22 17:00:38 Neko: look in work dir temp/run.do_compile to see what it DOES use May 22 17:00:43 kergoth: np, I always like a high "bugs closed last week" count May 22 17:00:50 thanks for your help this week May 22 17:00:51 ;-) May 22 17:00:52 * kergoth nods May 22 17:01:07 Laibsch: haha, the weekly report is nice to have indeed May 22 17:01:23 * kergoth isn't a big fan of bts's, just because most seem to do such a crappy job of obeying your workflow and limited workflow automation May 22 17:01:26 kergoth: resolve is all OE really does. Anybody hardly ever verifies May 22 17:01:39 that's too bad, really :\ May 22 17:01:46 nature of open source though, i guess May 22 17:01:58 kergoth: If you have concrete examples and suggestions for improvements, I'm the man to talk to May 22 17:02:13 yeah, that's how almost all oss projects tend to use bugzilla. it's fine, you just need to get used to the idea that RESOLVED is a terminal state. May 22 17:02:14 I'm all ears and very eager to hear why people don't seem to like the bugtracker we have May 22 17:02:34 the only places I've seen VERIFIED used are commercial shops with a formal QA process May 22 17:02:44 and, to be honest, I have never found a use for CLOSED even there. May 22 17:04:12 likewise, I don't see ARCH set in anything there May 22 17:04:29 kergoth: I try to verify both if I'm the reporter and the triager. But I still don't really use anything but the resolved state May 22 17:04:31 also the log for do_compile failure NOTE:s the command used to run it, and ARCH isn't set May 22 17:04:49 Laibsch: i'll give it some thought, but for example in this case, if we aren't leveraging verified here, perhaps it should go away, or perhaps there should be an automatic transition from resolved/fixed to closed or something. this is a fairly good example actually. often real world workflows don't fit what's there, or, May 22 17:04:54 there is a lot of old stuff in the tracker, also bugs do not seem to get assigned, so it is up to whoever wanders around and fixes things. May 22 17:04:56 for example, I've had processes where things had to be handed off to build / release folks when the bug was fixed and committed, yet the bug stayed assigned to me, the state stayed resolved, and nowhere was it recorded what state it was in after the fix May 22 17:05:07 with EXTRA_OEMAKE it does NOTE: make -j2 ARCH=arm include/linux/version.h CC=ccache arm-angstrom-linux-gnueabi-gcc LD=arm-angstrom-linux-gnueabi-ld May 22 17:05:21 i dont think bugzilla has the kind of workflow automation stuff I'd like to see, like automatically reassigning to the next step in the process when it hits resolved, you know May 22 17:05:21 shouldn't CC= be in quotes? May 22 17:05:32 or is the logger stripping them? May 22 17:05:36 dunno May 22 17:05:39 kergoth: it doesn't, but it's fairly easy to build that stuff around bugzilla. May 22 17:05:56 Neko: it probably is, but i think that's just an echo, and the shell is stripping em May 22 17:06:07 ok May 22 17:06:07 pb__: ah, is it? cool, i stand corrected :) May 22 17:06:08 actually and this also relates to the broken recipes dir that was proposed: I feel we need to distinguish between packages with maintainers (and bugs should be assigned to the maintainer) and unsupported packages (which could still be in the tracker) May 22 17:06:09 eFfeM: Bugs only get assigned in very rared circumstances (like I did in bug 518) because most devs heavily objected. There are no clear areas of responsibility, so who do you assign to? May 22 17:06:14 rare May 22 17:06:31 Laibsch: that is exactly the problem May 22 17:06:36 ugh, again an example of the lack of responsibility in the project May 22 17:06:40 * kergoth stops before he starts ranting again May 22 17:06:46 gah now it says no rule to make target include/linux/version.h May 22 17:06:48 * Neko cries May 22 17:06:49 eFfeM: propose a fix, and I'll likely support you May 22 17:06:58 eFfeM: it's not the tool to blame here, though ;-) May 22 17:07:03 indeed May 22 17:07:04 It just represents reality May 22 17:07:05 true! May 22 17:07:09 it's not extracting the kernel tarball or patching anymore May 22 17:07:12 so random :( May 22 17:07:20 * eFfeM thinks reality is an illusion caused by a lack of alcohol :p May 22 17:07:41 kergoth: for example, our qa engineers have a big button on their bugzilla consoles that shows them all the bugs that are either (a) assigned to R&D and marked RESOLVED (i.e. need verification), or (b) assigned to qa themselves and marked OPEN. together, that's pretty much a definitive list of things that they need to work on. May 22 17:07:50 Laibsch: will try to write a msg to #oe but i have a lot of things at hand atm May 22 17:07:57 neat May 22 17:08:27 kergoth: so, their mission is to take all the RESOLVED bugs from R&D, verify whether they're actually fixed, and either punt them back to R&D (by setting them back to OPEN, at which point they show up on the R&D radar again) or accept the fix by setting them to VERIFIED. May 22 17:09:21 eFfeM: I like your main and universe distinction (to use Ubuntu terminology) ;-) It would have my support if RFC'd May 22 17:09:22 likewise, all the R&D guys have a similar button that shows them all the OPEN bugs that are assigned to R&D, plus all the RESOLVED bugs that were originally opened by them. May 22 17:09:31 one of my pet peeves is workflow / process problems, so whenever i see the tools failing to represent the process, or unnecessary overhead in the process slowing everybody down, I'm about ready to snap, or go batshit insane, or both :) May 22 17:09:47 heh. yeah, agreed. May 22 17:09:55 sigh May 22 17:10:08 most of these tools do suck in some way or other, in their out-of-the-box configuration, but luckily they are not all that hard to customise. May 22 17:10:17 ugh, and then half the time they dont want to spend the money to fix it, even though itd *easily* pay for itself in less wasted developer time.. May 22 17:10:19 * kergoth twitches May 22 17:10:44 kergoth: I'm all with you, the tools should help make life easier, that is what these stupid machines are for ;-) May 22 17:11:52 pb, eFfeM, kergoth: If we got some kind of agreement in OE on workflow, I could try to represent that better in bugzilla. Right now people seem to like "mail to ml" and patchwork. If that works for most, I'm happy with that, too. May 22 17:12:07 workflow and area of responsibility May 22 17:12:24 the latter being more of a problem, I think May 22 17:13:09 anyone know how to use xclip here May 22 17:13:27 * Laibsch is off to see if VERIFIED shouldn't be dropped May 22 17:13:44 I recently added NEEDSINFO because that fits my triage workflow May 22 17:14:10 And bugs can only be reported as UNCONFIRMED now, so devs can opt for looking at CONFIRMED bugs only May 22 17:14:52 plus, I became Maintainer in Debian proper for bugz (command line interface to bugzilla, thanks for the pointer kergoth) May 22 17:15:17 who confirms bugs? May 22 17:15:24 Laibsch: ah, nice :) May 22 17:15:46 i need to use that tool more May 22 17:16:05 eFfeM: people with canconfirm rights May 22 17:16:12 i've no problems fixing bugs, but i hate to wade through tons of stuff that are either outdated, or way out of my scope May 22 17:16:33 eFfeM: tell me what you want to look at, I'll suggest a search for you May 22 17:16:42 you can then save that as a custom search May 22 17:16:54 Laibsch: do we think we can get someone to confirm May 22 17:16:55 kergoth: Are you using a Debian based distro? May 22 17:17:00 always May 22 17:17:11 eFfeM: I have picked up going through the bugs again May 22 17:17:39 kergoth: "aptitude install bugz" ;-) May 22 17:17:41 do it now! May 22 17:17:56 I think it's not in testing, yet, though May 22 17:17:57 Laibsch: typically I am only interested in packages, not on issues with e.g. the build system, and only for hw that I have (otherwise I cannot test), so for now this is beagle and openplug (and a semi-retired nslu2) May 22 17:18:06 Very fresh off the press May 22 17:18:18 Only took like a few month in the queue May 22 17:20:03 eFfeM: You only want build problems, right? Generic OE problems? Your first search is then "Product: Openembedded" I recently cleaned up incorrectly assigned issues, here May 22 17:20:12 Laibsch: and my expertise is C, so I am also not too intrestesed in perl or python problems May 22 17:20:48 build problems are typically easy to reproduce and often not too difficult to fix. May 22 17:21:02 functional problems are often more interesting but require more indepth knowledge May 22 17:35:09 kergoth: There are already 86 bugs in the database with either VERIFIED or CLOSED status. I guess even though they usually aren't used (I don't use them) they should stay. I don't think they really hurt that much May 22 17:35:33 And even in the workflow you're used to, you would have set 518 to RESOLVED, right? May 22 17:36:07 eFfeM: machine-specific problems are a bit more problematic May 22 17:36:10 yep. i dont think I've ever used a bts that didn't expect you to resolve when you commit the fix May 22 17:36:15 just what happens after that seems to vary May 22 17:36:16 bugzilla is usually not for cross-compiling May 22 17:36:40 so, the support they have does not distinguish between HOST vs TARGET May 22 17:36:50 which results in that field usually not being used at all May 22 17:37:10 the field does not support multiple selections, either May 22 17:37:24 What we usually do is to create meta bugs per package May 22 17:38:11 !oebug 2156 May 22 17:38:12 * * Bug 2156, Status: CONFIRMED, Created: 2007-04-29 02:48 May 22 17:38:13 * * : \[META\] SL-C3xxx machines, mainly in Angstrom and derivatives May 22 17:38:14 * * http://bugs.openembedded.net/show_bug.cgi?id=2156 May 22 17:38:16 is an example May 22 17:39:10 you'd have to create something like that for the beagle and the openplug May 22 17:39:19 Laibsch: why can't there be a field mentioning the mahcine on which the problem was detected or the machine for which the build failed. May 22 17:39:26 bug I'm not sure there are that many bugs about that in the tracker May 22 17:39:52 the reason it's not there is two-fold May 22 17:40:21 a) it's not in stock bugzilla and I rather don't patch it but stay with the Debian package if possible May 22 17:40:40 OE used too many customized software that always blew up in our face after about 6 months May 22 17:40:50 but if really necessary, it could be added May 22 17:40:52 currently bugzilla allows me to specify whether it is mips or arm or pc, but not the board May 22 17:41:06 but there is b) those fields don't support multiple selections May 22 17:41:21 You cannot correctly mark something as affecting spitz AND collie May 22 17:41:34 I've resorted to meta bugs and keywords May 22 17:41:52 If you want, I can add openplug and beagle keywords May 22 17:42:15 btw oine of the things that could also be done to make things more stable is to better examine the tinderbox log and report or fix those issues May 22 17:42:20 eFfeM: the question is, if you say MIPS, do you talk about MIPS target or MIPS host? May 22 17:43:14 if I now look at the report page, I can search for e.g. status, resolution, severity, priority, hardware and OS May 22 17:43:30 eFfeM: I've made a few request to integrate the two more tightly over the last few days. Jeremy usually had immediate turn-around May 22 17:43:35 os seems host, so not that important I think May 22 17:43:47 I agree that build failures in general should be tracked in tinderbox May 22 17:44:10 I usually completely ignore HW and OS May 22 17:44:11 any opinion of http://kergoth.pastey.net/114719 ? May 22 17:44:25 guess i should mail the list with some of this stuff, i keep forgetting May 22 17:45:24 yes, this is better for the list May 22 17:45:32 :) May 22 17:45:34 But we all want immediate feedback, don't we;-) May 22 17:45:48 How is amend.inc different from $PN.inc? May 22 17:46:02 it's automatic, and separate from the usual recipe/inclusion May 22 17:46:12 so an overlay can have its changes without copying the recipe into the overlay May 22 17:46:27 if you were to set filespath appropriately, anyway May 22 17:47:15 lets you keep a set of local changes to a recipe and avoid unnecessary conflicts with upstream for them. most changes aren't of that sort, but it could be useful on occasion May 22 17:48:04 Since git has such nice branching features, I don't use an overlay anymore May 22 17:50:55 kergoth: I'll keep the VERIFIED and CLOSED state but change the workflow definition so that you can't set bugs to them anymore in the future May 22 17:51:02 cool May 22 17:51:09 that should eventually keep that out of sight in the drop-down field May 22 17:51:19 You'll only continue to see them in searches May 22 17:53:49 * Laibsch wonders if I can deactivate the HW and OS fields, too, somehow May 22 17:53:51 grah now it's trying to copy some defconfig from somewhere random May 22 17:53:59 :( May 22 17:54:34 what's the official way to supply a defconfig for a kernel, because the adding a new machine docs suck May 22 17:54:50 and every kernel recipe I looked at either puts it in a different place or has a weird hack for it May 22 17:55:09 03Koen Kooi  07org.openembedded.dev * rfc9e12bd19 10openembedded.git/ (conf/checksums.ini recipes/xorg-lib/pixman_0.15.6.bb): pixman: add 0.15.6, it has some internal reorg, more NEON patches and since it's 0.odd.x extra unstableness May 22 17:55:10 03Koen Kooi  07org.openembedded.dev * r9143c0988f 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 22 17:55:11 03Dmitry Artamonow  07org.openembedded.dev * r0f1bfa08ce 10openembedded.git/recipes/linux/ (2 files in 2 dirs): (log message trimmed) May 22 17:55:12 linux-handhelds-2.6: fix compilation with gcc-4.3 May 22 17:55:14 Backport time.h patch from 2.6.25 kernel May 22 17:55:16 (commit 38332cb98772f5ea757e6486bed7ed0381cb5f98) May 22 17:55:18 It fixes following error during compilation: May 22 17:55:20 LD .tmp_vmlinux1 May 22 17:55:22 kernel/built-in.o: In function `getnstimeofday': May 22 17:58:07 HW and OS can't be deactivated May 22 17:58:25 But I guess I can trim down the allowed values ;-) May 22 18:00:09 anyone? May 22 18:06:55 I just dropped it in linux-mx51/defconfig like I expected and it just doesn't grab it or tries to copy it from some scary location May 22 18:08:46 hrw|gone: got it? May 22 18:09:36 "selected processor does not support `cpsid i`" WTF? May 22 18:27:02 NOTE: base_set_filespath usage is deprecated, e2fsprogs-libs-native-1.41.2 should be fixed May 22 18:27:13 JFYI May 22 18:27:24 there are lots, please don't report every one here :) May 22 18:27:30 they're easy to fix though, if you're bored May 22 18:27:30 ok :) May 22 18:32:29 kergoth: how? May 22 18:32:38 what to replace it with? May 22 18:33:11 most -native/-cross ones are just setting it to ensure they get the filespath of the main package, which is completely unnecessary now that BPN/BP exist and are in the filespath by default, just remove it May 22 18:33:29 then there are cases of variants usually May 22 18:33:44 foo-bar wants the "foo" dirs in its filespath, so it gets the patches for foo.bb May 22 18:33:52 in which case you can just add an entry to FILESPATHPKG May 22 18:34:20 the default FILESPATHPKG is ${PF}:${P}:${PN}:${BP}:${BPN}:files:. May 22 18:34:38 those are the dirs relative to filespathbase dirs that are checked. default filespathbase is just one dir, the location of the recipe May 22 18:34:47 then overrides dirs are checked under those May 22 18:38:30 otavio: built - will check next week May 22 18:39:05 hrw|gone: ok May 22 18:39:28 Laibsch: do a git grep FILESPATHPKG, you'll see some recipes thatve been made to use it May 22 18:39:56 ok May 22 18:39:56 thanks May 22 18:40:13 if you look at bitbake.conf, how FILESPATH is constructed is pretty straightforward May 22 20:00:29 hi florian May 22 20:01:18 hi all May 22 20:01:28 re May 22 20:27:09 server May 22 20:27:37 Oops, wrong tab May 22 20:33:29 03Jan Lübbe  07fso/milestone5.5 * re95b79125e 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs: bump mdbus, mickeyterm May 22 20:39:27 cbrake, ping May 22 20:40:25 uhh-oh May 22 20:40:40 heh May 22 20:40:45 you already know May 22 20:40:47 ? May 22 20:41:18 Crofton|work: Koen just informed me May 22 20:41:22 yeah May 22 20:41:29 I told him it was friday night May 22 20:41:36 well May 22 20:41:40 for him :) May 22 20:41:52 did you change anything May 22 20:42:37 Crofton|work: there was some cleanup happening May 22 20:42:44 heh May 22 20:42:55 never trust anyone who says they are "cleaning up" May 22 20:47:31 what happened? May 22 20:47:44 bluelightning: git+ssh is broken May 22 20:48:08 whew, from what you guys were saying I thought something valuable had been erased ... :) May 22 20:48:33 bluelightning: well, that might have happened too :-) May 22 20:48:55 mmm...I've the same issue than the one described in qemu+glibc one: FATAL: kernel too old I'll recompile qemu May 22 20:49:16 to have the same kernel May 22 20:49:21 version May 22 20:50:36 03Koen Kooi  07org.openembedded.dev * r3ef2a43b4e 10openembedded.git/recipes/bluez/bluez4_4.39.bb: May 22 20:50:36 bluez4 4.39: actually run initscript May 22 20:50:36 * now *that's* an embarassing bug! May 22 20:51:00 ok, git+ssh is now happy again May 22 20:53:23 thanks! May 22 20:54:55 mmm....has "(e)glibc-package: fix kernel version passed to qemu" been reverted ? applied? May 22 20:55:13 when I updated it made me recompile glibc and I had this issue May 22 21:01:27 so do the *-dbg packages have debug symbols, or are they just not stripped? May 22 21:02:25 cbrake: -dbg packages *are* debug symbols. they aren't unstripped versions of the original binaries, they're *only* the debug bits from the original binaries May 22 21:02:53 kergoth: does gdb automatically check .debug directories for these? May 22 21:03:01 good question :) May 22 21:03:14 * cbrake runs a few more tests May 22 21:03:37 mmm...OLDEST_KERNEL is set to 2.4.0 May 22 21:04:33 cbrake, gdb (can) uses theses dirs May 22 21:04:36 I'll check May 22 21:05:01 mmm...my notes where about gdb-remote May 22 21:05:05 I have to try to see May 22 21:06:19 it looks like gdb finds the debug symbols automatically as I no longer get (no debugging symbols found) messages May 22 21:06:37 so what does DEBUG=1 do in local.conf? May 22 21:08:02 ahh, found DEBUG_BUILD in bitbake.conf May 22 21:09:13 just changes optimization May 22 21:14:12 heh, DEBUG_BUILD is from before the -dbg stuff existed :) May 22 21:15:26 kergoth: ahh May 22 21:15:35 kergoth: still handy to change optimization I gues May 22 21:15:53 aye, could be May 22 21:15:58 kergoth: is there any reason not to have -g in the FULL_OPTIMIZATION? May 22 21:16:40 i can't think of one. you'd think itd get split out anyway.. but i dunno, I'm sure there's someone who knows the dbg bits better than i do :) May 22 21:17:11 kergoth: maybe I'll the ml once I try a few experiements with a fussy midori May 22 21:17:19 *ask the ml May 22 21:17:56 cbrake: Maybe you want to ask RP about implementing some kind of apache redirect/rewrite from .net to .org until .net DNS has been updated? May 22 21:18:06 just for cgit website May 22 21:18:40 I'd take a stab at it myself, but I'm not very familiar with those rewrites May 22 21:19:03 Laibsch: go for it. I doubt RP has the time ... May 22 21:21:26 any ideas why linux/linux-handhelds-2.6_2.6.21-hh20.bb builds with a PR of "r0" despite the explicit setting of "r25"? May 22 21:21:41 should the require... be further towards the top maybe? May 22 21:21:53 hmm I just set up a collection and my linux kernel recipe says it can't find the required file linux.inc May 22 21:22:16 cbrake: that was reasonably easy May 22 21:22:16 BBPATH is fine, collection pattern etc. is fine (I took it from the OE manual).. why can't it see it in the upstream tree? May 22 21:22:24 bluelightning, sounds like a need to update to MACHINE_PR May 22 21:22:31 cgit.oe.net is now working as before May 22 21:22:37 bluelightning, see kernel.bbclass May 22 21:22:43 only that it redirects all tasks to .org May 22 21:22:59 and thus you actually get to see the latest results on the latest cgit May 22 21:23:14 Laibsch: nice May 22 21:23:28 "Redirect / http://cgit.openembedded.org/" in /etc/apache2/sites-available/cgit and an apache restart May 22 21:23:35 heh, that is slick May 22 21:23:49 yes, it even works for deep urls May 22 21:24:00 like http://cgit.openembedded.net/cgit.cgi?url=openembedded/tree/recipes/busybox/busybox-1.9.2/adduser-longops.patch May 22 21:24:13 I thought it might redirect to the top page May 22 21:24:25 But it's actually showing you the file May 22 21:25:59 can't we get cgit.oe.net CNAME'd to .org? May 22 21:26:05 yes May 22 21:26:07 we will May 22 21:26:08 I ahven't seen mickey|FSOSHRUDC around May 22 21:26:11 ok May 22 21:26:13 But mickey is out of town May 22 21:26:20 for another week or so May 22 21:26:23 we do need to stamp out the use of .net though :) May 22 21:26:25 it will be done then May 22 21:26:56 * Laibsch remembers a time when .net was the saviour and favoured because .org routinely died in January May 22 21:26:57 ;-) May 22 21:27:00 Tartarus: not sure I fully understand the purpose of this... is it documented? May 22 21:27:12 Laibsch, we solved that issue :) May 22 21:27:21 I know May 22 21:27:25 Very good May 22 21:27:27 bluelightning, only on the ML May 22 21:27:44 bluelightning, the issue is that on some machines (ie Beagleboard) we need to keep the kernel and some external packages in sync May 22 21:27:50 change kernel, must rebuild other packages May 22 21:28:00 So we have the PR live in the machine.conf file for the kernel May 22 21:28:26 This is the 2nd or 3rd time someone has hit this bug, so I'm gonna get the full'ish list and post to the ML :) May 22 21:28:31 Tartarus: ok, so forgive me my ignorance, but why wasn't this done in a way that doesn't require everyone else to fix up their recipes? May 22 21:28:52 bluelightning, that is a good question May 22 21:29:43 I see a patch from hrw in patchwork to default MACHINE_KERNEL_PR to PR, but it's marked as rejected May 22 21:32:22 bluelightning: Are you still doing opie work? May 22 21:32:31 Laibsch: definitely May 22 21:32:38 kudos May 22 21:32:47 in fact I am working on the stupid cursor rotation bug atm May 22 21:32:51 I may retry an image myself May 22 21:32:52 hope to nail it finally :) May 22 21:33:01 That would be awesome May 22 21:33:35 What's the other option. Qt4 is around, is that not as suitable for small devices? May 22 21:33:51 or are you concerned about the legacy apps? May 22 21:34:17 I'd like to understand if and how those can be "upgraded" without too much fuss May 22 21:34:27 Laibsch: basically yeah... Qtopia4 exists, but has limited apps and is designed for phones May 22 21:34:44 kde4 :) May 22 21:34:57 "upgrading" existing QtE2 apps to Qt4 would basically be a rewrite May 22 21:35:03 Hey all. May 22 21:35:09 some guys have running it on Nokia N8xx :) May 22 21:35:16 OE is damn cool, but man, it hurts my head. May 22 21:35:22 Jay7: yes I saw that a while ago, haven't seen any recent news May 22 21:35:39 haha May 22 21:35:42 SDuensin: how so? May 22 21:36:07 Laibsch: feel free to drop by #opie, it's a bit quiet these days :) May 22 21:36:08 SDuensin, welcome to our lives :) May 22 21:36:12 kergoth - Well, I keep toying with running Angstrom. I can build it, but then I run into things that I can't find answers for... May 22 21:36:33 Like how to install packages, how to modify the kernel, why the hell won't Java build, etc. :-) May 22 21:37:02 OE is a single and easy answer :) May 22 21:37:24 'Just build it' :) May 22 21:37:26 Jay7 - That's more of a "what". I'm after "how". :-) May 22 21:38:03 look into :) May 22 21:38:49 I've been reading the wiki and forums. There's just so much here that's not made it into the docs. Still, damn cool stuff. May 22 21:39:38 SDuensin: most coders hate writing docs... those who don't (like myself) perhaps still lack the time May 22 21:39:41 SDuensin, what MACHINE? May 22 21:39:55 it's a common problem in the free software world May 22 21:40:22 Yea. Time is a mofo. It's my constant enemy as well. May 22 21:40:41 Crofton - Host is x86 Ubuntu, target is SheevaPlug ARM. May 22 21:40:55 ah cool May 22 21:42:34 Has anyone built a JVM for ARM? May 22 21:44:37 SDuensin: there is apage in OE Wiki iirc May 22 21:44:45 you need custom local.conf May 22 21:44:53 still trying to fix a madwifi-ng recipe - when I allow LDFLAGS to be set by OE the build fails with: armeb-commonos-linux-uclibcgnueabi-ld: unrecognized option '-Wl,-rpath-link,/home/tharvey/oe/commonOS-sync/build/tmp/staging/armv5teb-commonos-linux-uclibcgnueabi/usr/lib' May 22 21:45:13 armeb-commonos-linux-uclibcgnueabi-ld: use the --help option for usage information May 22 21:45:45 SDuensin: http://wiki.openembedded.net/index.php/Java#State_of_support May 22 21:45:48 ant__ - Thanks. Been staring at that for two days. :-) May 22 21:46:09 then try to catch TheBohemian May 22 21:46:23 ko May 22 21:47:06 I am currently running Ubuntu on the ARM, but the Cacao JVM has a bug and blows up on me. I was going to try and build a different one and see what happens. May 22 21:47:29 sorry I just fAILED A BUILD AND DISCUSSED May 22 21:47:33 oops May 22 21:47:43 with him on the ML May 22 21:48:00 was x11-gpe-java-image May 22 21:48:10 I rather avoid java May 22 21:48:18 sorry..it's me ;) May 22 21:48:25 It's a lot of people. :-D May 22 21:48:42 is like .NEt...ignored May 22 21:48:51 My project started in C, but ended up in Java. Go figure. May 22 21:49:09 SDuensin: may as well try C# + mono too :-) May 22 21:49:26 then finish to msaccess/vbasic May 22 21:49:48 if I unset LDFLAGS in do_compile/do_install madwifi-ng builds fine but then I have the QA Issues with GNU_HASH, which is why I was trying to figure out yesterday what to specify in LDFLAGS to set gnu-hash - so why would ld be complaining about the -Wl,-rpath-link,... which are params clearly mean for ld? May 22 21:50:00 I moved from C# to Java, actually. I really liked C#. Only problem is that every single add on library for it is $249 instead of GPLed. May 22 21:50:36 tharvey: it seems you can just skip the QA for this recipe (INSANE_SKIP) May 22 21:50:51 ant__, ya... just saw that on the maillist May 22 21:50:58 didn't know about that var - thx May 22 21:51:01 is ackward, yes May 22 21:51:28 I think thats the right fix for the convoluted madwifi build though... May 22 21:51:37 I see mwester points ...patch against moving source May 22 21:51:44 lot of May 22 21:52:22 ya May 22 21:52:37 sad he got it 'personal' May 22 21:52:51 I'm sure it was unintentinal May 22 21:54:27 Well, hopefully I manage to figure this project out. It's neat stuff. May 22 21:58:08 happy you manage to beat the beast ;) May 22 22:20:31 Does anybody understand why I get so frequent "fatal: The remote end hung up unexpectedly"? Others have reported the same and I had hoped this would go away with the new server. May 22 22:21:15 seems to be a common/known issue - I get it the first time I git pull, try again and it completes fine May 22 22:30:10 Laibsch: iirc it happens when you clonethis way $ git clone git://git.openembedded.org/openembedded May 22 22:30:10 and trry to push May 22 22:31:11 I get the remote hanging up on me mostly on pull, push is usually fine May 22 22:31:19 But I push to ssh and pull normally May 22 22:31:41 I work in local, can't say more, sorry May 22 23:26:45 for now, console-image depends on bluez that depends on gstreamer that depends on some x11 stuff. Why does console-image depends on x11 stuff?.. May 22 23:40:18 booxter, because gstreamer depends on X stuff even if it doesn't use it. There are a lot of apps around that require the X bitmap lib for example for.. not very good reasons.. mainly so they can load little icons and so on May 22 23:40:57 it only is a couple libs and some protocols though, nothing huge.... a matter of kilobytes May 22 23:41:15 you'd waste more space with the billions of udev rules etc. May 22 23:41:22 Neko: I understand the thing. I just don't get it -> how can console-image depend on x11 stuff? That's just silly. May 22 23:41:43 maybe you could patch gstreamer not to require it and everything would be fine? :) May 22 23:42:21 I was looking at it for a Qt system and the build requires X even though I use the directfb driver.. and gstreamer under phonon.. May 22 23:42:36 Neko: that's not a problem to give configure --disable-x11. But that's not what we have in default recipe May 22 23:42:56 well the recipe has to work with x11 configs too :] May 22 23:43:05 make a new one for gstreamer-nox11 or something May 22 23:43:15 Neko: btw qt4-embedded packages don't compile libqdirectfbscreen.so, don't they? May 22 23:43:36 umm no but I'm doing a non-oe build for that for various reasons May 22 23:44:21 Neko: I think one of the reasons is the inability to get workable qt4 toolchain from OE, am I right? May 22 23:45:28 I need a bunch of patches for tslib and other stuff and have another build environment (ltib) for it May 22 23:45:44 I am just too lazy to put it into OE right now as I am still beating my head on the desk trying to automate kernel build May 22 23:46:46 qt 4.5.1 should be fine with qdirectfbscreen and it's a simple mod to enable it May 22 23:47:06 just porting from crap stuff I hate to OE stuff that is making me cry right now May 22 23:47:26 hopefully once I work through the issues OE can be my sole build environment :D May 22 23:49:41 Neko: I'm going to enable directfb for qt4-embedded by default May 22 23:49:48 Neko: file a blocker bug against May 22 23:49:52 !oebug 5109 May 22 23:49:53 * * Bug 5109, Status: CONFIRMED, Created: 2009-05-20 22:25 May 22 23:49:54 * * : \[META\] unexpected build-time dependencies May 22 23:49:55 * * http://bugs.openembedded.net/show_bug.cgi?id=5109 May 22 23:50:13 oh. but x11 isn't unexpected... :D May 22 23:50:19 Maybe things can be slimmed down by splitting up recipes or something like that May 22 23:50:44 as a compile-time dependency for a console-image? May 22 23:50:50 I think that would be unexpected May 22 23:50:58 I mean it's not like "glibc REQUIRES BASH!!!!" ulrich drepper style stuff but, x11 dependency on most gui toolkits and stuff like imagemagick is well known May 22 23:51:02 It can be explained why currently it's the way it is May 22 23:51:27 I'm more concerned right now why OE built me a cross toolchain that can't generate instructions for my processor May 22 23:51:51 Oh, sorry, I think booxter is the one who like me found that to be kind of unexpected May 22 23:51:58 so he should file the bug May 22 23:52:18 probably :] May 22 23:52:19 and risk having it closed as invalid after receiving an explanation why things as they are perfectly fine May 22 23:52:20 ;-) May 22 23:52:50 Happened to me with one of the "unexpected build-time dependency" bugs May 22 23:52:58 so, that is perfectly OK May 22 23:53:07 "selected processor does not support `cpsid i`" is what I am struggling with now May 22 23:53:37 Laibsch: just wrote a comment there. May 22 23:53:48 oe is really bloated by dependencies... May 22 23:53:55 booxter: Please open a new bug May 22 23:54:02 a meta bug is not for comments May 22 23:54:07 one issue - one bug May 22 23:54:33 the problem is that there is no generic way of disabling/enabling some optional stuff except editing recipes. If only OE had USE flags like Gentoo... May 22 23:54:57 Laibsch: ok, I'll create a new one :) May 22 23:56:22 USE flags are evil May 22 23:56:26 just create a new recipe :D May 22 23:58:04 Hello, I was wondering if anyone knew of a channel that was devoted to ARM linux development? May 22 23:58:07 * * OE Bug 5120 has been created by ihar.hrachyshka(AT)gmail.com May 22 23:58:09 * * Console image is not really pure console one May 22 23:58:11 * * http://bugs.openembedded.net/show_bug.cgi?id=5120 May 22 23:59:40 Or if there were any hardcore ARM guys here that wouldn't mind discussing something with me? May 23 00:00:03 richratt: maybe #elinux will help you May 23 00:00:39 booxter: thank you very much May 23 00:12:25 03Rolf Leggewie  07org.openembedded.dev * r8a81095baa 10openembedded.git/recipes/ (4 files in 3 dirs): May 23 00:12:25 psplash: fix runtime dependencies. (Partly Closes: #2412) May 23 00:12:25 * virtual/psplash should be virtual-psplash to not confuse dpkg May 23 00:12:25 * make corresponding changes in initramfs-module-psplash_1.0.bb May 23 00:12:25 and exquisite_svn.bb as well May 23 00:49:58 03Rolf Leggewie  07org.openembedded.dev * r3b32ee46ce 10openembedded.git/recipes/xorg-lib/libx11_git.bb: May 23 00:49:58 libx11: replace virtual/libx11 with virtual-libx11 for runtime #2412 May 23 00:49:58 * it doesn't look like this is actually used anywhere May 23 01:10:54 03Rolf Leggewie  07org.openembedded.dev * r9ae9613655 10openembedded.git/recipes/ (12 files in 8 dirs): May 23 01:10:54 {qpf|ttf}-fonts: fix runtime dependencies. (Closes: #2412) May 23 01:10:54 * replace virtual/japanese-font with virtual-japanese-font May 23 01:10:54 in RPROVIDES May 23 01:10:54 * adjust RDEPENDS and RRECOMMENDS accordingly in zten, uim, May 23 01:10:56 qpobox, nunome, jards and anki May 23 01:11:00 03Rolf Leggewie  07org.openembedded.dev * r656ce4421f 10openembedded.git/recipes/ttf-fonts/ttf-arphic-uming_20080216.bb: May 23 01:11:03 ttf-fonts: fix runtime dependencies. (Partly Closes: #2412) May 23 01:11:05 * replace virtual/chinese-font with virtual-chinese-font May 23 01:11:07 in RPROVIDES May 23 01:11:09 * doesn't seem to be actually used anywhere May 23 01:13:05 * * OE Bug 2412 has been RESOLVED (FIXED) by May 23 01:13:07 * * dpkg-deb failing when package name contains character '/' May 23 01:13:09 * * http://bugs.openembedded.net/show_bug.cgi?id=2412 May 23 01:42:06 * * OE Bug 4572 has been marked as DUPLICATE of bug 4472 by May 23 01:42:08 * * xfce-mcs-manager.pc problem which leads to a QA error May 23 01:42:10 * * http://bugs.openembedded.net/show_bug.cgi?id=4572 May 23 01:45:06 * * OE Bug 4573 has been marked as DUPLICATE of bug 2302 by May 23 01:45:08 * * Exo package compilation fails May 23 01:45:10 * * http://bugs.openembedded.net/show_bug.cgi?id=4573 **** ENDING LOGGING AT Sat May 23 02:59:57 2009