**** BEGIN LOGGING AT Fri Apr 05 02:59:58 2013 Apr 05 03:01:57 hello Apr 05 03:04:02 ahoy Apr 05 03:05:03 home of tiny OS coding?? Apr 05 03:06:35 openembedded... Apr 05 03:09:10 open source for microcontrollers Apr 05 03:17:45 this channel is for the openembedded project, not for general embedded discussion Apr 05 03:17:53 see #edev or #elinux for that Apr 05 06:21:11 khem ping Apr 05 06:50:10 good morning Apr 05 06:52:34 hi mckoan Apr 05 06:52:59 morning mckoan, woglinde, all Apr 05 06:59:23 hi bluelightning Apr 05 07:43:19 good morning Apr 05 07:44:06 hi apelete Apr 05 07:46:43 hi apelete Apr 05 07:47:09 hi woglinde, bluelightning Apr 05 07:49:24 bluelightning: fixed the kernel issue we were talking about yesterday, you were right about the change in gcc (http://gcc.gnu.org/gcc-4.6/porting_to.html) Apr 05 07:49:46 apelete: aha, interesting Apr 05 07:51:00 apelete when using gcc-4.7 and binutils 2.23 you problaly need more to fix Apr 05 07:51:52 bluelightning: concerning the DEFAULTTUNE in machine conf, I wasn't sure about it, thanks for pointing the ml conversation. Apr 05 07:53:00 bluelightning: I will probably do a pull request v2 to remove the defaulttune tune patch Apr 05 07:54:05 apelete: you don't have to, I can just pull 1/2 out Apr 05 07:54:17 okay, great. Apr 05 07:54:41 apelete: I believe the accepted method is to use DEFAULTTUNE_ben-nanonote = "somevalue" in your distro config Apr 05 07:56:31 hi zecke Apr 05 07:57:20 bluelightning: ok. I forgot to set MACHINE and DISTRO in local.conf when I started working on meta-jlime (embarrassing, I know...) Apr 05 07:57:49 apelete: oh well, not to worry... Apr 05 07:58:00 we all make mistakes :) Apr 05 07:58:04 morning all Apr 05 07:58:11 hi silvio Apr 05 07:58:13 bluelightning: that's why I found out that there's actually a lot more to fix, just as woglinde just said Apr 05 07:58:37 hi woglinde , apelete, bluelightning , all Apr 05 07:58:42 hi silvio__ Apr 05 07:58:46 hi silvio__ Apr 05 07:59:53 aplete did you work an xmlpull? Apr 05 08:00:14 otherwise I can fix it really quick Apr 05 08:02:25 woglinde: didn't have the time to work on it yet, I would appreciate your help :) Apr 05 08:10:18 woglinde: hi Apr 05 08:10:29 bluelightning: about defaulttune, I was wondering what's the difference between 'mipsel-nf' and 'mips32el-nf' ? Apr 05 08:10:57 apelete: not sure, you'd have to compare the flags used in both cases Apr 05 08:12:13 the nanonote cpu is a mips JZ4740, 32bit with endianness-little and soft fpu so mips32el-nf seemed right to me, but wasn't so sure about it actually Apr 05 08:18:48 apelete: I thought MIPS was a bi-endian arch Apr 05 08:21:11 ah, xburst supports LE only... Apr 05 08:21:21 one wonders if this is a special case Apr 05 08:43:06 hi Apr 05 08:43:41 hmm, I wonder if we could use the namespaces feature in linux 3.8 to replace pseudo Apr 05 08:44:38 gm hrw Apr 05 08:44:56 Zagor: we can not Apr 05 08:45:02 Zagor: not everyone runs 3.8 Apr 05 08:45:35 Zagor: you have to wait 2-3 years so people will upgrade to 3.8 Apr 05 08:45:37 hrw: well of course. I meant for those on 3.8+. pseudo is a major bottleneck. Apr 05 08:46:17 ERROR: Multiple .bb files are due to be built which each provide virtual/arm-linux-gnueabihf-libc-for-gcc (/home/hrw/HDD/devel/canonical/aarch64/openembedded/repos/openembedded-core/meta/recipes-core/eglibc/eglibc_2.17.bb /home/hrw/HDD/devel/canonical/aarch64/openembedded/repos/meta-linaro/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb). Apr 05 08:46:23 I hate it Apr 05 08:46:51 gm stefan Apr 05 08:46:56 for some reason bitbake wants eglibc to provide virtual/arm-linux-gnueabihf-libc-for-gcc which is already provided by external-linaro-toolchain Apr 05 08:47:06 morning woglinde Apr 05 08:47:12 morning hrw Apr 05 08:47:15 hrw remove meta-linaro Apr 05 08:47:16 morning all :) Apr 05 08:47:26 from bblayers Apr 05 08:47:48 woglinde: ? Apr 05 08:49:02 *g* Apr 05 08:49:36 I woke up less than 1.5h ago ;D Apr 05 08:50:56 hrw: wow, slow bootup. :) Apr 05 08:51:12 It takes me 45 minutes from my bed to being at my desk at work :) Apr 05 08:51:19 and that is with a train ride :) Apr 05 08:51:47 stefan_schmidt_w: I need minute Apr 05 08:51:51 heh Apr 05 08:52:03 hrw: yeah, I miss working from home Apr 05 08:56:44 stefan_schmidt hm but with collegues it is not so bad working in office Apr 05 09:00:03 GFW#TGJ#$%IUTGY#^(T@$!U$!@##$@$@##$@!!@#@!@ - my feelings on external toolchains Apr 05 09:01:59 hrw I am sure it only needs a little fix Apr 05 09:02:29 what I am checking now is a hack Apr 05 09:04:41 OE parser log looks more funnier when there is no eglbc recipe Apr 05 09:09:42 or I should probably ask in other way... Apr 05 09:10:01 did someone built image with external toolchain? if yes then with which one? Apr 05 09:11:17 hrw actually I only saw failures Apr 05 09:11:33 from other people Apr 05 09:11:46 ok, will bring it to OECore ML then Apr 05 09:20:51 mail sent Apr 05 09:22:31 https://bugzilla.yoctoproject.org/show_bug.cgi?id=3393 is ~same Apr 05 09:41:43 apelete xmlpull recipes is pushed to master Apr 05 09:50:15 woglinde: ah great, thank you very much Apr 05 09:59:04 woglinde: any thoughts about moving llvm from meta-java to meta-oe or oe-core? Apr 05 10:02:48 jama fell free Apr 05 10:02:52 ups feel Apr 05 10:57:23 I'm gonna scream Apr 05 10:57:38 I hate package renaming stuff Apr 05 10:57:51 external toolchains as well Apr 05 10:57:59 :) Apr 05 10:58:36 bitbake -e is my main tool today Apr 05 11:01:33 and bitbake -g -vDDDDD Apr 05 11:03:13 DEBUG: providers for eglibc-thread-db are: ['eglibc', 'external-linaro-toolchain'] Apr 05 11:03:17 NOTE: selecting external-linaro-toolchain to satisfy runtime eglibc-thread-db due to PREFERRED_PROVIDER_eglibc = external-linaro-toolchain Apr 05 11:03:28 looks properly - right? Apr 05 11:07:32 hrw: I would think so, yes Apr 05 11:07:47 DEBUG: sorted providers for eglibc-thread-db are: ['/home/hrw/HDD/devel/canonical/aarch64/openembedded/repos/meta-linaro/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb', '/home/hrw/HDD/devel/canonical/aarch64/openembedded/repos/openembedded-core/meta/recipes-core/eglibc/eglibc_2.17.bb'] Apr 05 11:07:52 DEBUG: adding '/home/hrw/HDD/devel/canonical/aarch64/openembedded/repos/meta-linaro/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb' to satisfy runtime 'eglibc-thread-db' Apr 05 11:07:56 DEBUG: adding '/home/hrw/HDD/devel/canonical/aarch64/openembedded/repos/openembedded-core/meta/recipes-core/eglibc/eglibc_2.17.bb' to satisfy runtime 'eglibc-thread-db' Apr 05 11:08:02 but those are not looking right for me. Apr 05 11:08:08 PREFERRED_PROVIDER_eglibc-thread-db = "external-linaro-toolchain" Apr 05 11:08:13 is in config ;( Apr 05 11:08:52 is eglibc-thread-db in external-linaro-toolchain PROVIDES? Apr 05 11:09:09 RPROVIDES Apr 05 11:11:41 JaMa: it has such package in PACKAGES, it PROVIDES that as well Apr 05 11:12:17 hrw: this is a runtime dependency (hence "runtime" in the debug output) Apr 05 11:12:27 but eglibc-thread-db can not rprovide eglibc-thread-db Apr 05 11:27:30 ok. external-linaro-toolchain.bb produces libthread-db1 which provides glibc-thread-db and at same time (according to config) e-l-t.bb is also PREF_PROV for glibc-thread-db which is needed by tclibc-eglibc.inc in LIBC_DEPENDENCIES (hacked from eglibc to glibc locally). still wrong ;( Apr 05 11:30:18 fun fun Apr 05 11:38:55 indeed Apr 05 11:58:40 ok. looks like I found it in lib/bb Apr 05 11:59:29 hm? Apr 05 12:00:21 wait for my mail Apr 05 12:00:32 okay Apr 05 12:18:11 Hello. Apr 05 12:18:50 Is this possible to do something in bitbake layer to do not allow appending? Apr 05 12:19:48 I have recipe in layer with BBFILE_PRIORITY = 20 Apr 05 12:20:27 And at the end of this recipe I have appended text from layer with BBFILE_PRIORITY = 7. Apr 05 12:21:12 sent Apr 05 12:21:47 I do not want to have my recipe modified – how can I do this? Apr 05 12:21:57 I may not be good at Python but I managed to understand BitBake code again Apr 05 12:23:42 lets see Apr 05 12:26:23 woglinde: ignore patch in email Apr 05 12:29:20 I have problem. Apr 05 12:29:24 and I built an image Apr 05 12:29:26 I can not build my image beucase: Apr 05 12:29:32 git ls-remote git://github.com/E2OpenPlugins/e2openplugin-OpenWebif.git master could not be run: Apr 05 12:29:35 None Apr 05 12:29:45 When I've tried to run this command manually I've received: Apr 05 12:29:48 fatal: remote error: Storage server temporarily offline. See http://status.github.com for GitHub system status. Apr 05 12:30:04 otwieracz: rm recipe Apr 05 12:30:13 hrw but the patch looks not this bad Apr 05 12:30:16 Can I somehow continue build instead some servers are offline? Apr 05 12:30:41 woglinde: I wonder what RP will tell Apr 05 12:31:01 ech. lamp image gave me multiples again ;( Apr 05 12:32:27 NOTE: ['/home/dreambox/oe-core-dev/meta-openpli/recipes-bsp/alsa-state/alsa-state.bbappend', '/home/dreambox/oe-core-dev/meta-vts/recipes-vts/alsa-state/alsa-state.bbappend'] to ['/home/dreambox/oe-core-dev/meta-openpli/recipes-bsp/alsa-state/alsa-state.bbappend'] Apr 05 12:32:31 What does it means? Apr 05 12:33:00 that 3 alsa-state bbappends were parsed Apr 05 12:33:14 3? Apr 05 12:33:17 2 Apr 05 12:33:25 and, what about that? Apr 05 12:33:36 I've never seen that NOTE Apr 05 12:33:58 I see it every time I add new .bbappend and I just ignore it Apr 05 12:34:06 ok. Apr 05 12:35:07 I can not somehow continue build in case that github is down? Apr 05 12:38:33 (and use versions already pulled?) Apr 05 12:38:47 use -k to build other recipes Apr 05 12:39:20 you can use already downloaded sources or PREMIRROR, but if those resipes are using tag= in git:// SRC_URI then you're out of luck Apr 05 12:39:51 It crashes while parsing receipes. Apr 05 12:40:10 otwieracz: rm recipe Apr 05 12:40:39 argh. external toolchains suxx Apr 05 12:40:41 That's not solution, I need this receipe, bitbake have latest copy on hdd. Apr 05 12:40:53 otwieracz: so set fixed SRCREV in it Apr 05 12:41:00 But it crashes while checking what is the latest version. Apr 05 12:41:41 And problem appeared on github. Apr 05 12:43:36 otwieracz: when recipe does not have fixed src revision then bitbake asks upstream repo for it Apr 05 12:43:53 otwieracz: in your case it fails to connect to it bails out due to lack of that info Apr 05 12:45:34 otwieracz: or do you prefer explanation in Polish? Apr 05 12:47:08 :) Apr 05 12:47:36 hrw: Yeah, I've already undestood. Apr 05 12:47:53 To generate package version it need info from remote server. Apr 05 13:34:13 one thing is sure when it comes to external-toolchain Apr 05 13:34:18 they suxx Apr 05 13:34:46 other thing is that OE (as metadata) is not friendly for it as well Apr 05 13:35:23 we need to alter gcc packaging to have it includeable by external toolchains so packaing info is not written twice Apr 05 13:40:27 hrw: when you get your external toolchain working, can you try it with icecc? Apr 05 13:40:50 JaMa: rather not Apr 05 13:44:18 just one machine capable of OE Apr 05 13:46:52 hrw: ok, fwiw I was only interested to know if it finds all tools provided by your external toolchain (not that it works ok as icecc) Apr 05 13:56:51 hi all Apr 05 13:57:21 I'm facing a sanity WARNING: BBPATH references the current directory, either through an empty entry, or a '.'. Apr 05 14:33:57 hrw: heh, mentor uses the sourcery g++ toolchain, but it requires custom tuning arguments to control selection of the multilib in the external toolchain sysroots, so we switched to a separate layer and overrode the tuning files in question Apr 05 14:34:13 hrw: that's why the sourcery stuff in oe-core isn't 100% anymore, I haven't had time to mess with it Apr 05 14:34:31 kergoth: are you able to build full images with it? Apr 05 14:34:36 hrw: if you want to see an example of external toolchain stuff that works for us, see https://github.com/MentorEmbedded/meta-sourcery Apr 05 14:34:50 we build everything at mentor with meta-sourcery and our external toolchains, every day Apr 05 14:34:58 kergoth: thanks, will look Apr 05 14:35:13 it doesn't get those multiple provider messages, so i'm assuming something in there fixed it Apr 05 14:35:21 but i'm honestly not sure what exactly offhand :) Apr 05 14:35:27 check the recipe PROVIDES i'm guessing Apr 05 14:35:31 (and preferences in tcmode) Apr 05 14:35:31 sure Apr 05 14:35:47 we should get the stuff in oe-core in better shape, at hte very least as a functional example / starting point Apr 05 14:35:56 i just haven't had time recently Apr 05 14:37:51 kergoth: I think that Ken Werner based a lot on sourcery stuff when he added Linaro one Apr 05 14:38:11 it also includes the ability to rebuild just eglibc from the external toolchain's sources, though it expects a particular format used by sourcery's stuff Apr 05 14:38:15 * kergoth nods Apr 05 14:38:41 I hope not to have to take over linaro toolchains maintaince D: Apr 05 15:28:30 Does anyone know what kind of problem I'd be looking for if I ran nandtest on my flash and saw all kinds of "ECC corrected at" messages? This is a machine that has been flashed with a JFFS2 rootfs image and used for some time before this. Apr 05 15:29:22 a second run of nandtest yields no ECC messages Apr 05 15:47:42 woglinde: I updated to FreeBSD 8.4 on the buildserver yesterday. you might need to boot your vm Apr 05 15:48:02 okay Apr 05 15:48:13 isnt 9 out? Apr 05 15:48:46 ah yes I already have it up again Apr 05 15:58:51 khem: ping Apr 05 16:27:16 "guile: remove from meta-oe, there is newer version in oe-core" -- why are people checking in changes which aren't bugfixes into danny? I know danny technically isn't a release branch, but it is a *stable* branch, so checking in needless non-bugfix commits seems questionable, no? Apr 05 16:27:40 unless there's a bug in the version that was in meta-oe that's fixed in the version that's in oe-core Apr 05 16:54:29 moin Apr 05 16:55:57 kergoth: that's up to the meta-oe danny maintainer Apr 05 16:59:36 kergoth: stable branch users have been pretty demanding when it comes to backporting fixes :/ Apr 05 16:59:40 Yeah, was hoping they were hanging out in here Apr 05 17:00:05 looks like ebenard isn't online atm Apr 05 17:00:08 bluelightning: just broke our build due to bbappends. minor and easy to fix, but still irritating having numerous non-bugfix commits go in Apr 05 17:00:12 heh Apr 05 17:00:13 k Apr 05 17:00:51 kergoth: it would be appropriate to reply to the original patch/backport request and ask for an explanation explaining the issue it caused you I think Apr 05 17:21:07 kergoth: iirc there was some longer thread about some build issue with danny Apr 05 17:21:26 kergoth: ross wasn't able to reproduce and in the end it was caused by different guile from meta-oe Apr 05 17:21:28 khem: ping Apr 05 17:22:20 kergoth: cannot find that thread (iirc it also had some misleading subject), but that could be the reason why ross submitted it as "bugfix" Apr 05 17:23:09 hm what is this qemu-teslib script for? Apr 05 17:27:19 woglinde: it's part of the qemu image tests Apr 05 17:27:31 woglinde: we run them on the autobuilder; you can run them on your own machine pretty easily too Apr 05 17:29:12 bluelightning hm what exactly it is doing? Apr 05 17:29:19 I used runqemu for now Apr 05 17:29:29 s i can see the image comes up Apr 05 17:29:58 woglinde: it runs a small number of sanity tests within the booted qemu system and reports success or failure of each one Apr 05 17:30:43 woglinde: have a look for IMAGETEST in meta/conf/local.conf.sample for how to enable it Apr 05 17:30:44 hm okay Apr 05 17:31:04 hm I should sent my patch for runqemu Apr 05 17:31:10 location is now diffrent Apr 05 17:31:22 and there is a problem when using -daemonize option Apr 05 17:31:23 woglinde: the tests themselves can be found in scripts/qemuimage-tests/ Apr 05 17:31:44 okay will later look into them Apr 05 17:32:00 only wanted to know if they not run some binaries only Apr 05 17:32:13 till later Apr 05 17:32:30 thanks for explain it Apr 05 17:32:50 np Apr 05 17:33:12 we could really do with adding it to the docs... Apr 05 17:33:17 Apr 05 17:33:35 at least the enabling part is in the example config Apr 05 17:33:47 JaMa: ah, thanks for the background Apr 05 17:39:22 got the following errors at end of a test build: Apr 05 17:39:23 ERROR: Creation of tar /fast/devel/oe-core.git/meta-jlime/build/tmp-eglibc-eglibc/deploy/tar/kernel-vmlinux-2.6.36-r0.tar.gz failed. Apr 05 17:39:23 ERROR: Creation of tar /fast/devel/oe-core.git/meta-jlime/build/tmp-eglibc-eglibc/deploy/tar/kernel-dev-2.6.36-r0.tar.gz failed. Apr 05 17:39:25 http://paste.debian.net/247592/ Apr 05 17:39:49 does someone knows what's that about ? Apr 05 17:40:06 the tar.gz archives seem fine to me... Apr 05 17:58:29 apelete check diskspace Apr 05 18:48:46 woglinde: got plenty of disk space left, strange Apr 05 19:00:09 okay Apr 05 19:14:33 Does anyone have problems with svn info https://openpli.svn.sourceforge.net/svnroot/openpli/trunk/external/tuxterm/ ? Apr 05 20:13:06 can recipe and package names contain a dot? something like foobar1.0_1.0.17 and foobar0.8_0.8.22 ? Apr 05 20:13:36 in case two major versions can coexist in the same rootfs Apr 05 20:39:05 dv_: yep that's allowed Apr 05 20:41:16 Is it possible to .bbappend a machine to the COMPATIBLE_MACHINE list ? Apr 05 20:46:03 jkroon: it's just a regex Apr 05 20:46:26 jkroon: the practice of using brackets to surround the list is actually unnecessary Apr 05 20:46:54 uhm... you mean parenthesis right ? Apr 05 20:47:05 jkroon: technically yes Apr 05 20:47:19 jkroon: I guess I use "brackets" when I mean () a lot, perhaps I shouldn't Apr 05 20:48:12 bluelightning, so, if I create a my_override_for_package_y_1.0.bbappend, and add 'COMPATIBLE_MACHINE = "mymachine"', it should work Apr 05 20:48:53 well, at least get picked up by bitbake, right ? Apr 05 20:50:58 jkroon: it'll have to be packagename_version.bbappend to match the original recipe, but yes... however I think what you ought to do is do COMPATIBLE_MACHINE_append = "|mymachine" Apr 05 20:51:31 aha Apr 05 20:58:05 hmm, it wont bite for some reason.. Apr 05 21:00:18 ah, im stupid Apr 05 21:01:06 hm this rerun of do_packagescene and do_fetch is really annoying Apr 05 21:07:24 woglinde: we have been discussing the solution Apr 05 21:07:36 woglinde: I don't know if JaMa is working on it or not Apr 05 21:07:59 bluelightning: not realy (busy with other stuff) Apr 05 21:08:15 * JaMa still has that rm_work patch as work around Apr 05 21:08:51 JaMa: as have I been unfortunately Apr 05 21:09:06 hrw: there is one more issue with external toolchains, I was just hit in systemd build with our internal external toolchain Apr 05 21:09:28 systemd is using AC_PATH_TOOL(OBJCOPY, objcopy) Apr 05 21:09:34 JaMa: there are lot of issues ;( Apr 05 21:09:50 but host prefix in OE is not the same as in binary toolchain Apr 05 21:10:07 so it looks for configure:14545: checking for arm-foo-linux-gnueabi-objcopy Apr 05 21:10:25 while binary toolchain has only arm-bar-linux-gnueabi-objcopy Apr 05 21:10:33 configure:14588: checking for objcopy Apr 05 21:10:37 configure:14606: found /usr/bin/objcopy Apr 05 21:10:39 and bam Apr 05 21:10:58 a lot later when it tries objcopy from host on some arm lib **** ENDING LOGGING AT Sat Apr 06 02:59:58 2013