| 00:11.22 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 00:18.05 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 00:51.24 | *** join/#oe dijenerate (~dijenerat@65.48.221.118) |
| 00:54.42 | *** join/#oe lamawithonel_ (~lucas@pool-71-191-8-96.washdc.east.verizon.net) |
| 00:55.59 | *** join/#oe dijenerate (~dijenerat@65.48.221.118) |
| 01:17.42 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 01:51.33 | *** join/#oe dijenerate (~dijenerat@65.48.221.118) |
| 01:54.23 | *** join/#oe dijenerate (~dijenerat@65.48.221.118) |
| 01:59.06 | *** join/#oe dijenerate (~dijenerat@65.48.221.118) |
| 03:01.03 | *** join/#oe signal11 (~esteban@gnv.quaddro.net) |
| 03:05.53 | *** join/#oe devzero_ (devzero@xdsl-89-0-174-147.netcologne.de) |
| 03:47.05 | *** join/#oe toobluesc (~nitro@cpe-76-183-62-99.tx.res.rr.com) |
| 04:15.40 | *** join/#oe rsalveti` (~rsalveti@186.214.57.130) |
| 04:23.27 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
| 04:42.14 | *** join/#oe playya__ (~playya@p4FF8A4BA.dip.t-dialin.net) |
| 04:42.14 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
| 04:58.03 | *** join/#oe snkt (~snkt@114.143.160.125) |
| 05:00.12 | *** join/#oe GNUtoo (~gnutoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
| 05:21.20 | *** join/#oe erwt (~rahul@114.143.160.125) |
| 05:30.17 | *** join/#oe nitink (~nitink@nat/intel/x-wxrvvaphtvliooro) |
| 06:35.36 | *** join/#oe tasslehoff (~Tasslehof@147.84-49-231.nextgentel.com) |
| 06:56.21 | *** join/#oe vitus (~vitus@145.253.169.210) |
| 06:57.21 | *** join/#oe phdeswer (~philippe@80-186-176-55.elisa-mobile.fi) |
| 07:15.48 | *** join/#oe lamikr (lamikr@nat/nokia/x-zcgdzensjqmybksf) |
| 07:20.16 | *** join/#oe stefan_schmidt (~stefan@2001:638:602:1183:f2de:f1ff:fe62:28f7) |
| 07:21.46 | *** join/#oe errordeveloper (~Dmitriche@host109-145-40-140.range109-145.btcentralplus.com) |
| 07:44.23 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 07:53.17 | stefan_schmidt | Hmm, Paul Eggleton is bluelighting, right? |
| 08:10.20 | *** join/#oe phdeswer (~philippe@80-186-176-55.elisa-mobile.fi) |
| 08:11.05 | mckoan | good morning |
| 08:30.56 | Jin^eLD | mornin |
| 08:36.11 | mckoan | Jin^eLD: gm |
| 08:44.35 | *** join/#oe zecke (~ich@91-65-246-230-dynip.superkabel.de) |
| 09:03.27 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 09:04.53 | *** join/#oe SidH_ (~SidH@203.101.61.7) |
| 09:05.15 | *** join/#oe davidlt (808d885b@gateway/web/freenode/ip.128.141.136.91) |
| 09:08.36 | davidlt | I just did a full build (rm -rf tmp), but Bitbake did not include kernel-module-libertas driver! |
| 09:09.20 | davidlt | I still have my linux-omap recipe, but other configuration was restored. |
| 09:09.52 | davidlt | My recipe (david-linux-omap) was not build and kernels were not mixed, this time. |
| 09:10.28 | davidlt | ./lib/modules/2.6.34/kernel/drivers/net/wireless/libertas/libertas_sdio.ko ./lib/modules/2.6.34/kernel/drivers/net/wireless/libertas/usb8xxx.ko |
| 09:10.35 | davidlt | Missing libertas.ko |
| 09:10.38 | davidlt | sakoman: ping |
| 09:11.37 | davidlt | Hmm... I have changes to module-init-tools-cross |
| 09:13.16 | davidlt | Probably that's it! |
| 09:23.11 | *** join/#oe erwt (~rahul@114.143.160.125) |
| 09:25.32 | *** join/#oe florian (~fuchs@port-217-146-132-69.static.qsc.de) |
| 09:25.35 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 09:36.55 | *** join/#oe lamikr (lamikr@nat/nokia/x-cxnxexxjfzdmnphl) |
| 09:48.44 | *** join/#oe soltys (soltys@83.168.118.74) |
| 09:50.55 | *** join/#oe Z3r0l3g (~Oleg@ip-195-88-138-71.dss-group.net) |
| 09:59.26 | *** join/#oe pespin (~pespin@cisne-cn07.upc.es) |
| 10:04.46 | *** join/#oe SidH_ (~SidH@203.101.61.10) |
| 10:11.30 | *** join/#oe risca (~risca@c-78fae253.022-6-6e6b702.cust.bredbandsbolaget.se) |
| 10:38.26 | pb_ | hi all |
| 10:40.19 | *** join/#oe GNUtoo (~gnutoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
| 10:44.51 | *** join/#oe lamikr (lamikr@nat/nokia/x-rtmjqgbepkxozvhr) |
| 10:45.39 | Jin^eLD | hi pb_ |
| 10:53.35 | otavio | ericben: around? |
| 10:54.07 | otavio | ericben: i just got your mail about the Qt issue ... |
| 11:00.45 | ericben | otavio: hi. I trie to understand that for the last few hours but I need to be able to reproduce it (and from memory I fail to remember exactly the error message) |
| 11:01.01 | otavio | ericben: sure ... |
| 11:01.42 | otavio | ericben: the generated pkgconfig files has -L/usr/lib in Libs.private and this causes the user of host libraries as fallback |
| 11:02.56 | otavio | RP__: how do you think it is better to address this issue? using SYSROOT env var from pkgconfig and dropping the expanded sysroot paths from it? |
| 11:03.32 | ericben | otavio: do you have a simple example on how to trigger the problem so that I can reproduce it ? |
| 11:04.12 | otavio | ericben: just build Qt and grep the generated pc files for '\-L/usr/lib' |
| 11:04.20 | ericben | otavio: OK |
| 11:04.39 | ericben | otavio: I think this may come from one sed in qt4.inc |
| 11:04.51 | *** join/#oe rschus (~rschus@fb-n15-11.unbelievable-machine.net) |
| 11:04.57 | otavio | ericben: my problem was it ended up linking against a host lib and it took two days for me to get why it was segfaulting heh |
| 11:05.15 | *** part/#oe rschus (~rschus@fb-n15-11.unbelievable-machine.net) |
| 11:05.20 | ericben | otavio: ok, this is with a cmake project ? |
| 11:05.30 | otavio | ericben: no |
| 11:05.38 | otavio | ericben: it failed with a qmake one |
| 11:06.11 | otavio | ericben: it uses a static lib and then it got the libs.private options onto gcc command line, and then it made it link against host and fail |
| 11:06.16 | ericben | otavio: ah ok so I should be able to reproduce it |
| 11:07.18 | otavio | ericben: but you don't really need to reproduce it... as far as pc files are sane, we're fine |
| 11:07.39 | otavio | ericben: and I can build a toolchain with a proposed fix and test here if need |
| 11:07.57 | *** join/#oe pepermint (~pepermint@host107-84-dynamic.4-87-r.retail.telecomitalia.it) |
| 11:08.43 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 11:08.56 | ericben | otavio: ok I launch a rebuild hope that won't break something else, will keep you updated |
| 11:09.10 | RP__ | otavio: in summary, yes |
| 11:09.10 | otavio | ericben: awesome |
| 11:09.17 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
| 11:09.37 | otavio | RP__: mind to explain to ericben what you want? he is looking at this now |
| 11:11.58 | RP__ | otavio: "what I want"? |
| 11:12.34 | RP__ | otavio: I just tried to explain to you how this should work (i.e. like the rest of the system), its not a personal thing |
| 11:13.50 | otavio | RP__: ok; What I meant was is if you could tell ericben about this so we can fix it properly and avoid to have to work on that again in future |
| 11:14.17 | RP__ | ericben: The basic summary is that when we call pkg-config, we have 'export PKG_CONFIG_SYSROOT_DIR = "${STAGING_DIR_HOST}"' from bitbake.conf and this should ensure any paths returned from pkg-config have the appropriate suffix prepended |
| 11:14.37 | RP__ | ericben: in the target case we should only see paths like "/usr/lib" in the .pc files |
| 11:15.06 | RP__ | ericben: in the cross/native cases we see "/xxx/tmp/sysroot/xxx" paths since STAGING_DIR_HOST is / |
| 11:15.16 | RP__ | ericben: but we should never see them mixed together |
| 11:16.24 | RP__ | ericben: I never did establish was wasn't working in otavio's specific problem case but the .pc file he showed me was clearly broken as it had a mixture of these paths (and was for the target iirc so the non /usr/lib/ entries were incorrect) |
| 11:17.48 | ericben | RP__: otavio : here is the .pc I get here : http://pastebin.com/ByGUKXv7 |
| 11:18.02 | ericben | otavio: does yours looks like this ? |
| 11:18.32 | otavio | ericben: yes; look at line 20 |
| 11:18.34 | ericben | the problems is in Libs.private |
| 11:18.35 | otavio | ericben: it is mixed |
| 11:18.40 | ericben | otavio: yes |
| 11:19.08 | ericben | that seems specific to qt .pc files |
| 11:27.05 | ericben | otavio: I think I foudn the problem, build launched while going to the pool ;) |
| 11:27.27 | otavio | ericben: I envy you now :P |
| 11:27.29 | otavio | lol |
| 11:29.04 | pb_ | stabs gcc |
| 11:29.28 | pb_ | seems that the library search paths are all busted if you have two MACHINEs sharing a TARGET_ARCH in a single build tree. |
| 11:30.24 | RP__ | pb_: That sounds worrying |
| 11:30.34 | pb_ | yeah, it is a bit suboptimal |
| 11:31.00 | pb_ | what seems to happen is that you end up with search paths to the MACHINE-specific sysroot encoded in the gcc driver binary (and/or its specs, I'm not quite sure which) |
| 11:31.19 | *** join/#oe woglinde (~heinold@f052225026.adsl.alicedsl.de) |
| 11:31.32 | pb_ | but, since gcc itself is only namespaced by TARGET_ARCH, you end up with a random choice of MACHINE depending on what it happened to be set to when gcc was compiled. |
| 11:32.28 | pb_ | I think it generally doesn't matter since oe itself sets the appropriate paths on the compiler commandline, but it causes unexpected lossage if that fails to happen for some reason. |
| 11:36.43 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 11:37.14 | pb_ | ah yes, gcc.c embeds a default sysroot setting, see "target_system_root". |
| 11:38.55 | pb_ | on a different topic, does anybody have experience of persuading uclibc binaries to run on a glibc system? |
| 11:39.10 | woglinde | pb never tried |
| 11:39.11 | pb_ | I have a bunch of binary-only bits here which were, unfortunately, built against uclibc and that is not what we are using. |
| 11:39.55 | woglinde | but I have openjdk running again under uclibc |
| 11:39.58 | woglinde | and oe-core |
| 11:41.18 | pb_ | very good |
| 11:42.12 | *** join/#oe lamikr (lamikr@nat/nokia/x-ienalqxruvqnsbpt) |
| 11:46.32 | woglinde | lucnh |
| 11:46.48 | RP__ | pb_: Perhaps we should set the inbuilt sysroot path for gcc to somewhere different |
| 11:47.08 | RP__ | pb_: We certainly assume that software is passing our flags in :/ |
| 11:51.42 | pb_ | yeah. it seems a little bit toxic to have the builtin sysroot path be somewhere that is sometimes right and sometimes wrong. |
| 11:52.15 | pb_ | I think we should either configure gcc with a builtin sysroot that is never right (so that it's obvious when you fail to pass --sysroot) or build it per MACHINE and get it to compile in the correct path (which would mean we could remove it from CFLAGS). |
| 11:59.59 | GNUtoo | woglinde, wow so java will come to oe-core, nice |
| 12:00.17 | tasslehoff | must one have some symlinks package to get the SDK to work? calling arm-angstrom-linux-gnueabi-gcc just gives me 'No such file or directory'. |
| 12:02.04 | woglinde | https://github.com/woglinde/meta-java |
| 12:08.51 | *** join/#oe erwt (~rahul@114.143.160.125) |
| 12:08.54 | *** join/#oe snkt (~snkt@114.143.160.125) |
| 12:12.53 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 12:12.53 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 12:25.04 | *** join/#oe lamikr (lamikr@nat/nokia/x-dqrccxnppjhyvfvb) |
| 12:26.43 | *** join/#oe fcooper (c05b42ba@gateway/web/freenode/ip.192.91.66.186) |
| 12:37.38 | *** join/#oe Z3r0l3g (~Oleg@ip-195-88-138-71.dss-group.net) |
| 12:40.03 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
| 12:49.27 | *** join/#oe _chase_ (~a0271661@nat/ti/x-dmgbcghkmkvqgcgb) |
| 12:52.22 | *** join/#oe fcooper1 (~a0273011@pool-173-65-58-67.tampfl.fios.verizon.net) |
| 12:54.40 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 12:59.45 | ericben | tasslehoff: did you source /usr/local/angstrom-eglibc-x86_64-armv6-vfp/environment-setup-armv6-vfp-angstrom-linux-gnueabi (or the equivalent in your sdk) ? |
| 13:01.14 | GNUtoo | woglinde, ok thanks a lot |
| 13:01.23 | *** join/#oe fcooper2 (~a0273011@nat/ti/x-omfiqtyofgkydcsj) |
| 13:05.35 | *** join/#oe rschus (~rschus@fb-n15-11.unbelievable-machine.net) |
| 13:18.18 | *** join/#oe cminyard (~cminyard@pool-173-71-58-7.dllstx.fios.verizon.net) |
| 13:23.14 | *** join/#oe rob_w (~bob@clnet-p01-141.ikbnet.co.at) |
| 13:26.04 | tasslehoff | ericben: I made an attempt at extracting the sdk to another folder in disk, since I consider adding it to version control. |
| 13:26.27 | tasslehoff | ericben: after putting it in /usr/local and sourcing, it executes |
| 13:26.43 | tasslehoff | why doesn't it when just invoked from the folder I have extracted to? |
| 13:27.19 | GNUtoo | maybe because of toolchain relocation issues? |
| 13:27.46 | GNUtoo | or maybe the script expects the toolchain to be at that place |
| 13:32.01 | *** join/#oe tdebrouw` (~tdebrouw@91.182.250.224) |
| 13:35.04 | tasslehoff | GNUtoo: must be something that expects it. twasn't that way in classic. |
| 13:35.26 | tasslehoff | but, I'm considering installing to /usr/local instead |
| 13:36.02 | *** join/#oe tmbinc__ (abcd@83.141.3.59) |
| 13:39.39 | ericben | tasslehoff: that was the same behaviour under oe-classic, at least for angstrom sdk |
| 13:42.01 | fcooper2 | ericben: I spoke to Koen the other day about an issue I was having with getting Qt Creator to work with the qt embedded and he suggested I speak to since you already got it working. |
| 13:42.26 | fcooper2 | erickben: I am trying to cross compile my qt application in QT Creator on my host system to run it on my target system. However pointing Qt Creator to qmake located in linux-devkit/bin/qmake issues this message "Qt version is not properly installed, please run make install". It seems the way qt4-tools-sdk_4.7.2.bb is installing Qt files in a way that Qt Creator isn't happy with. Any tips on how you got this working? |
| 13:42.49 | ericben | fcooper2: are you using qt |
| 13:42.53 | ericben | 4.7.2 ? |
| 13:43.25 | fcooper2 | ericben: Yes. And sourcing enviroment-setup and running qmake via command line works without a problem. |
| 13:43.37 | ericben | fcooper2: so you are using oe-classic |
| 13:44.40 | fcooper2 | ericben: I believe so. This is being used within TI Arago SDK which I believe is using oe-classic recipes for qt. |
| 13:45.09 | davidlt | Are there a package for htpdate ? |
| 13:45.17 | davidlt | HTP (HTTP Time Protocol) |
| 13:46.28 | ericben | fcooper2: this was fixed in oe commit 3b175b3421122c55d3acb1922d80b2caf15c9ccb so check if arago has this |
| 13:49.25 | ericben | fcooper2: last time I tried (with oe-classic & qt 4.7.3 it was working fine) |
| 13:49.58 | fcooper2 | ericben: That commit is indeed included in arago's qt4-tools-sdk.inc file. In the file I see # make a symbolic link to mkspecs for compatibility with Nokia's SDK |
| 13:49.58 | fcooper2 | # and QTCreator which is what confused me in the first place. I assumed that this fix was addressing the issue but it didn't work for me. |
| 13:50.26 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 13:51.10 | *** join/#oe kristoffer (~kristoffe@c-b9dde555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 13:52.11 | anarsoul | bluelightning: hi |
| 13:52.17 | bluelightning | hi anarsoul |
| 13:52.31 | fcooper2 | ericben: Are you using Qt Creator on the target system or on your host system? |
| 13:52.33 | anarsoul | bluelightning: here're some h1940 patches and updated config: http://devio.us/~anarsoul/h1940.28nov/ |
| 13:52.47 | ericben | fcooper2: on the host system |
| 13:53.00 | ericben | which version of qtcreator are you using ? |
| 13:53.25 | anarsoul | bluelightning: these patches fix DMA issue with s3cmci (so DMA can be used with it), and with s3c24xx-i2s |
| 13:53.34 | bluelightning | anarsoul: ok thanks... presumably this improves SD card access speed? |
| 13:53.48 | anarsoul | nope, but it reduces CPU usage |
| 13:53.56 | bluelightning | ok, cool |
| 13:54.09 | fcooper2 | I downloaded the latest version from Nokia 2.3.1 |
| 13:56.13 | anarsoul | there's still isue with s3c24xx-i2s, it does not handle DMA errors properly |
| 13:57.04 | bluelightning | anarsoul: what happens when a DMA error does occur? |
| 13:57.09 | bluelightning | at the moment |
| 13:57.10 | anarsoul | so mpg123 does not work for me (looks like it's not fast enough to provide sound data to alsa), but mplayer works |
| 13:57.15 | anarsoul | bluelightning: nothing :) |
| 13:57.18 | bluelightning | ok |
| 13:57.22 | anarsoul | no sound |
| 13:57.41 | anarsoul | no crashes, etc |
| 13:58.23 | *** join/#oe pespin (~pespin@cisne-cn09.upc.es) |
| 14:00.33 | stefan_schmidt | woglinde: cool, you pushed meta-java. Only the preferred version in local.conf and disabling angstrom-java.inc or did you keep it? |
| 14:00.40 | stefan_schmidt | bah, to late :) |
| 14:01.20 | tasslehoff | ericben: in classic I extracted the angstrom sdk to a folder on disk, and set CC to a gcc symlink that pointed to arm-angstrom.... and could compile without sourcing the environment setup |
| 14:01.47 | ericben | tasslehoff: ok maybe I always used the environment script |
| 14:01.52 | tasslehoff | ericben: still, I should likely install like everyone else do :) |
| 14:02.12 | tasslehoff | ericben: the thought behind having it in VCS is to make it easier to reproduce release builds |
| 14:14.39 | kenws | Hi, Is there an easy way to a use binary cross compiler rather than have OE build one to compile oe-core for a given target? |
| 14:15.02 | kenws | (the binary gnueabi ARM toolchain that code sourcery provides for example) |
| 14:21.15 | ant_work | yes, you can use external tooclhains but the question is why? |
| 14:22.46 | kenws | reads http://lists.linuxtogo.org/pipermail/openembedded-devel/2008-November/006946.html |
| 14:23.02 | kenws | ant_work: To test the toolchain for example : ) |
| 14:26.23 | Crofton|work | testing toolchains? novel idea :) |
| 14:29.30 | kenws | interesting - it looks likes one could set: TOOLCHAIN_PATH, TOOLCHAIN_TYPE, TOOLCHAIN_VENDOR, TOOLCHAIN_BRAND |
| 14:33.01 | *** join/#oe kevinsc (~a0214685@nat/ti/x-jltlwdwxzwrmgfrp) |
| 14:34.58 | *** join/#oe woglinde (~heinold@g225007037.adsl.alicedsl.de) |
| 14:37.33 | *** join/#oe dijenerate (~dijenerat@65.48.163.146) |
| 14:41.44 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 14:48.13 | GNUtoo | woglinde, will you add meta-java to http://www.openembedded.org/wiki/LayerIndex at some point? |
| 14:48.32 | GNUtoo | hi stefan_schmidt |
| 14:48.48 | stefan_schmidt | hi GNUtoo |
| 14:49.27 | stefan_schmidt | GNUtoo: meta-bug is already up and I'm working on meta-buglabs now. Testing meta-java as well. |
| 14:49.34 | stefan_schmidt | woglinde: cool, you pushed meta-java. Only the preferred version in local.conf and disabling angstrom-java.inc or did you keep it? |
| 14:50.07 | GNUtoo | stefan_schmidt, yes I run an xfce image on it |
| 14:50.15 | GNUtoo | built with openembedded-core |
| 14:50.24 | stefan_schmidt | GNUtoo: on bug20? |
| 14:50.25 | GNUtoo | but mplayer fails to compile somehow |
| 14:50.27 | GNUtoo | yes |
| 14:50.31 | stefan_schmidt | GNUtoo: nice |
| 14:50.39 | GNUtoo | I had to hand-fix dbus tough |
| 14:50.50 | GNUtoo | and it doesn't shut down well yet |
| 14:50.57 | stefan_schmidt | GNUtoo: hmm, there have been issues with mplayer for armv7a IIRC. Don't build it here normally |
| 14:50.57 | GNUtoo | (systemd...) |
| 14:51.12 | stefan_schmidt | yeah, systemd shutdown is broken here as well |
| 14:51.28 | GNUtoo | ok it's rather a library problem |
| 14:51.34 | stefan_schmidt | No idea how to fix this yet. Will look into it again when I have the other layers in place |
| 14:51.35 | GNUtoo | it doesn't find some XV symbols |
| 14:57.41 | *** join/#oe joelagnel (~joel@nat/ti/x-jqclrupixrktrsbr) |
| 15:03.18 | *** join/#oe shoragan (~shoragan@debian/developer/shoragan) |
| 15:04.27 | *** join/#oe devzero_ (devzero@xdsl-89-0-103-76.netcologne.de) |
| 15:06.10 | *** join/#oe galak (~galak@192.88.168.35) |
| 15:07.41 | *** join/#oe joelagnel (~joel@nat/ti/x-ikjnlorazygjihva) |
| 15:12.07 | *** join/#oe pespin (~pespin@cisne-cn07.upc.es) |
| 15:13.50 | stefan_schmidt | GNUtoo, woglinde: NOTE: package openjdk-6-jre-6b18-1.8.11-r11.0: task do_rm_work_all: Succeeded |
| 15:13.53 | stefan_schmidt | woglinde: nice job |
| 15:14.13 | GNUtoo | nice |
| 15:15.43 | shoragan | stefan_schmidt, nice :) |
| 15:17.53 | kenws | Maybe this is a stupid question but how do I a clean up former builds? |
| 15:18.45 | stefan_schmidt | kenws: bitbake -ccleansstate TARGET |
| 15:18.47 | kenws | I've tried `bitbake -c clean world` but a `bitbake core-image-minimal` doesn't seem to rebuild everything from scratch |
| 15:19.05 | kenws | stefan_schmidt: thanks! |
| 15:19.23 | stefan_schmidt | kenws: np |
| 15:19.28 | bluelightning | kenws: if you really want to clean out everything just rm -rf your tmpdir |
| 15:19.51 | bluelightning | (or rather TMPDIR) |
| 15:20.34 | kenws | bluelightning: yep, that's what I did earlier, but I thought there's probably some bitbake rule that does the trick |
| 15:20.53 | bluelightning | kenws: not if you truly want to clean out everything |
| 15:21.07 | bluelightning | it all depends on what you're trying to achieve |
| 15:21.14 | kenws | ok : ) |
| 15:21.59 | kenws | bluelightning: I'm trying to (ex)change the toolchain and therefore want to rebuild the minimal image from scratch using the external toolchain |
| 15:22.26 | bluelightning | kenws: right, I think that probably qualifies as something where you'd just want to delete everything |
| 15:24.00 | bluelightning | you'd probably want to delete the sstate-cache, although you should be able to speed up the next build with no ill effect by just deleting the non-native cache files |
| 15:24.55 | kenws | bluelightning: so, you're suggesting `rm -r sstate-cache tmp-eglibc` prior the rebuild? |
| 15:25.29 | bluelightning | you want tmp as well, but yes |
| 15:27.33 | kenws | hm, there is no tmp dir - strange. thedefault should be ${TOPDIR}/tmp |
| 15:27.43 | kenws | I definitely want to keep the downloads dir : ) |
| 15:28.38 | *** join/#oe xumbi (~jim@static-64-223-142-66.man.east.myfairpoint.net) |
| 15:29.43 | xumbi | has anyone used a USB 2.0 device on an atmel board with the at91_ohci driver? as far as I can tell ohci only supports USB 1.0 |
| 15:29.44 | kenws | It looks like my "tmp" dir is the "tmp-eglibc" directory. |
| 15:33.14 | *** join/#oe zecke (~ich@91-65-246-230-dynip.superkabel.de) |
| 15:38.31 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 15:39.11 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 15:45.18 | stefan_schmidt | woglinde: I had two small problems with the classpath recipe. First the LICENSE had no LIC_CHECKSUM and second QA erroring out because of so links |
| 15:45.40 | stefan_schmidt | woglinde: Skipping this error works here as a workaround: INSANE_SKIP_${PN} = "dev-so" |
| 15:46.16 | JaMa|Off | but better to fix packaging if .so is not really needed |
| 15:46.53 | stefan_schmidt | JaMa|Off: sure, needs real fixing. Just as a workaround right now. |
| 15:58.19 | *** join/#oe hillct (~hillct@cpe-174-109-206-062.nc.res.rr.com) |
| 16:09.33 | *** join/#oe pxx42 (~qwerty@203.115.73.127) |
| 16:20.03 | *** join/#oe zenlinux (~sgarman@c-98-246-160-155.hsd1.or.comcast.net) |
| 16:23.15 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 16:25.58 | *** join/#oe gchiii (~gchiii@adsl-76-255-12-150.dsl.mrdnct.sbcglobal.net) |
| 16:26.38 | *** join/#oe randori (~randori@50-76-134-129-static.hfc.comcastbusiness.net) |
| 16:29.34 | *** join/#oe Tartarus (trini@pixelshelf.com) |
| 16:29.40 | *** join/#oe racoon00 (~qwerty@203.115.73.127) |
| 16:35.33 | *** join/#oe awozniak (~awozniak@76.205.222.174) |
| 16:45.28 | *** join/#oe randori (~randori@50-76-134-129-static.hfc.comcastbusiness.net) |
| 17:03.23 | *** join/#oe CosmicPenguin (~nobody@soa.codeaurora.org) |
| 17:05.34 | *** join/#oe pespin (~pespin@cisne-cn07.upc.es) |
| 17:07.19 | awozniak | Anyone know the fix for this (error during bitbake -c devshell) : (gnome-terminal:32371): GLib-GIO-CRITICAL **: Settings schema 'org.gnome.system.proxy' is not installed |
| 17:07.40 | awozniak | I know I can set TERMCMD and use xterm, but I'd really like to use gnome-terminal |
| 17:08.21 | *** join/#oe florian (~fuchs@sign-4db60946.pool.mediaWays.net) |
| 17:08.22 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 17:08.43 | awozniak | this may be the actual error: ERROR:terminal-app.c:1450:terminal_app_init: assertion failed: (app->system_font_desc != NULL) |
| 17:14.55 | *** join/#oe notespace (~notespace@dsl081-118-011.dfw1.dsl.speakeasy.net) |
| 17:15.29 | *** join/#oe mrmoku (~mrmoku@ppp-188-174-26-243.dynamic.mnet-online.de) |
| 17:19.25 | khem | awozniak: is that error happening on target ? |
| 17:19.36 | khem | ah devshell |
| 17:21.59 | khem | <PROTECTED> |
| 17:22.24 | awozniak | this may be a more ubuntu problem; sudo apt-get --reinstall install libgdk-pixbuf2.0-0 fails with an error: E: Internal Error, No file name for libgdk-pixbuf2.0-0 |
| 17:22.35 | khem | I think either install the schema on your host |
| 17:22.41 | khem | yes its 100% host problem |
| 17:40.04 | *** join/#oe errordeveloper (~Dmitriche@host109-152-120-158.range109-152.btcentralplus.com) |
| 17:46.44 | ericben | otavio: I just sent you a patch, please try it and tell me if that fix the problem |
| 17:47.05 | bluelightning | ka6sox: hi, is it possible for us to remove edit restrictions from the oe wiki? http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-November/036497.html |
| 17:47.29 | otavio | ericben: awesome |
| 17:54.05 | *** join/#oe woglinde_ (~heinold@g225073125.adsl.alicedsl.de) |
| 17:54.42 | otavio | ericben: i am finishing a build and will give it a try |
| 17:57.33 | *** join/#oe housel (~user@mccarthy.opendylan.org) |
| 17:58.52 | khem | bluelightning: spamming is still a problem |
| 17:59.12 | bluelightning | khem: we have a captcha now, we did not have that before the restrictions were enacted |
| 17:59.20 | khem | bluelightning: although I dont know if we ever opened it up widely after introducin captcha |
| 17:59.31 | khem | right |
| 18:02.19 | khem | bluelightning: I think only registration must be regulated now. Edits should be as usual arent they |
| 18:02.55 | bluelightning | khem: berhard can't edit his own user page, so I would assume not... |
| 18:03.23 | khem | hmmm thats something should not happen |
| 18:03.24 | *** join/#oe housel (~user@mccarthy.opendylan.org) |
| 18:03.37 | khem | I thought it was restricted only for registration now |
| 18:04.00 | khem | ka6sox was travelling hope to catch him later today |
| 18:04.04 | khem | I will let him know |
| 18:04.31 | bluelightning | probably hasn't helped documentation contributions... |
| 18:08.26 | khem | actually there are registration span that hits quite a bit |
| 18:08.35 | khem | I see that problem for patchwork too |
| 18:09.14 | *** join/#oe zecke (~ich@91-65-246-230-dynip.superkabel.de) |
| 18:24.04 | *** join/#oe pxx42 (~qwerty@203.115.73.127) |
| 18:43.23 | *** join/#oe anarsoul (~anarsoul@212.98.184.121) |
| 18:45.10 | nitink | khem: I am merging youand & mine libtool commits, why are you replacing PR = r4 with PR = ${INC_PR}.0 ? |
| 18:48.16 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 18:50.07 | *** join/#oe rob_w (~bob@ppp-188-174-31-129.dynamic.mnet-online.de) |
| 18:52.02 | *** join/#oe galak (~galak@192.88.168.34) |
| 18:53.51 | *** join/#oe Heinervdm (~thomas@pD9E155DA.dip.t-dialin.net) |
| 18:59.25 | khem | nitink: since we have multiple recipes using common header |
| 18:59.57 | khem | nitink: btw. I have those patches rebased on top of what RP__ committed to libtool |
| 19:00.08 | khem | I can push those to the same branch if that will be useful for you |
| 19:00.19 | nitink | khem: cool yes that would be useful |
| 19:05.14 | *** join/#oe msm (~msm@192.88.168.34) |
| 19:05.49 | kergoth__ | What are you guys working on wrt libtool, out of curiosity? |
| 19:06.28 | khem | kergoth: update to 2.4.2 |
| 19:06.33 | kergoth | ah, cool |
| 19:06.47 | khem | kergoth: upstream has take couple of my fixes :) |
| 19:06.52 | kergoth | nice. |
| 19:06.57 | khem | kergoth: btw. regarding chair |
| 19:07.01 | kergoth | that's always great to see. we need to do a better job at that |
| 19:07.03 | khem | my office chair is same |
| 19:07.13 | khem | as we were talking about other day |
| 19:07.57 | kergoth | which one was that again? I was researching a pile of them :) I ended up picking up an Embody at the store yesterday, wanted to take advantage of the 15% off sale on herman miller right now |
| 19:09.11 | *** join/#oe pepermint (~pepermint@host107-84-dynamic.4-87-r.retail.telecomitalia.it) |
| 19:10.54 | khem | stupid computer logged me off |
| 19:11.02 | kergoth | hehe |
| 19:11.03 | khem | kergoth: yes herman miller |
| 19:11.06 | khem | go for it |
| 19:11.10 | khem | its really nice one |
| 19:11.21 | kergoth | i went to a store and sat in a few of them. I don't see why so many people love the aeron |
| 19:11.32 | kergoth | i mean, it was fairly comfortable really, but there are too damn many adjustments to make |
| 19:11.43 | kergoth | and its awfully stiff, doesn't flex or move at all with you the way the mirra and embody do |
| 19:11.53 | kergoth | anyway :) |
| 19:12.11 | khem | herman miller I have has haudralics in it :) |
| 19:12.33 | khem | hydraulics |
| 19:13.09 | khem | kergoth: mine is Aeron |
| 19:13.26 | kergoth | ah, cool |
| 19:13.37 | kergoth | as long as you get it adjusted right :) |
| 19:14.44 | khem | kergoth: correct. I like the stiffness |
| 19:15.09 | khem | kergoth: but embody looks nice too. Havent sat on one so dont know the difference |
| 19:15.15 | kergoth | all the expensive chairs are so much better than the cheap ones that the differences between them are probably minor by comparison :) |
| 19:16.32 | khem | could be. |
| 19:16.40 | kergoth | pokes at a panda build from meta-ti |
| 19:17.00 | khem | but I guess they do have some notable things amongst aeron and embody |
| 19:17.11 | kergoth | linux-omap4 apparently requires lzop, but it doesn't actually depend on it, afaict |
| 19:17.35 | kergoth | khem: apparently they designed the embody expecting it to replace the aeron, but it didn't work, too many people prefer the aeron for a variety of reasons, so now they're both around |
| 19:17.36 | khem | kergoth: isnt lzo optional in kernel |
| 19:17.56 | kergoth | hmm, good point, might have to make it obey the defconfig |
| 19:18.14 | *** part/#oe xumbi (~jim@static-64-223-142-66.man.east.myfairpoint.net) |
| 19:33.36 | *** join/#oe LetoThe2nd (~jd@unaffiliated/letothe2nd) |
| 19:33.46 | *** part/#oe LetoThe2nd (~jd@unaffiliated/letothe2nd) |
| 19:55.05 | *** join/#oe morphis (~morphis@dslb-092-076-172-207.pools.arcor-ip.net) |
| 20:03.38 | *** join/#oe darknighte (~shudson@unaffiliated/darknighte) |
| 20:06.21 | *** join/#oe darknighte (~darknight@hsvwanfw1-nat.mentorg.com) |
| 20:06.21 | *** join/#oe darknighte (~darknight@unaffiliated/darknighte) |
| 20:11.26 | kergoth | wonder if koen would accept a patch to dep on lzop-native if CONFIG_KERNEL_LZO is defined in file://defconfig |
| 20:11.32 | kergoth | would think so |
| 20:11.54 | kergoth | cleans it up |
| 20:18.54 | khem | yes that a sane change imp |
| 20:18.56 | khem | imo |
| 20:19.04 | *** join/#oe JaMa (~martin@94.230.152.246) |
| 20:19.25 | kergoth | k, thanks |
| 20:21.59 | msm | does anyone know why this message might be occuring: |
| 20:21.59 | msm | bootlogd: cannot allocate pseudo tty: No such file or directory |
| 20:22.03 | msm | just in general... |
| 20:22.18 | kergoth | <PROTECTED> |
| 20:24.55 | GNUtoo | msm, I think I had the same message |
| 20:25.04 | GNUtoo | I'll look in my serial console if it still appear |
| 20:25.12 | GNUtoo | re-doing rootfs currently |
| 20:26.15 | *** join/#oe kurre2 (~tomimo@xdsl-83-150-88-111.nebulazone.fi) |
| 20:26.34 | darknighte | msm: variation on kergoth's question: did you create a mount point for /dev/pts? |
| 20:26.49 | msm | no |
| 20:26.51 | msm | well |
| 20:26.59 | msm | let's just say im running fine on real hardware |
| 20:27.08 | msm | there are people running on something "else" |
| 20:27.21 | msm | and get that message |
| 20:27.30 | msm | so maybe - udev is not mounting /dev/pts? |
| 20:27.33 | GNUtoo | msm, something else than what? |
| 20:27.37 | msm | something along those lines? |
| 20:28.00 | GNUtoo | yes we use devtmpfs |
| 20:28.01 | msm | GNUtoo: hardware emulator for instance - who knows what crap is interfering with normal operation |
| 20:28.25 | khem | msm: udev is hardware specific sometimes something else could be the problem |
| 20:28.29 | GNUtoo | you mean qemu,or hardware emulator for creating SOCs? |
| 20:28.34 | msm | basically |
| 20:29.44 | GNUtoo | I guess qemu, because other kinds of emulator are unlikely |
| 20:32.03 | khem | GNUtoo: no semiconductor companies have emulators too |
| 20:32.20 | GNUtoo | I know but they costs are outrageous |
| 20:32.25 | khem | and they are much rich featured in terms of emulation |
| 20:32.34 | khem | well not if you work for the semi |
| 20:32.48 | GNUtoo | I saw the video of the talk of porting Linux on unreleased SOC btw |
| 20:33.59 | msm | GNUtoo: well… no comment =) |
| 20:34.04 | khem | msm: is this emulator using some known machine conf or different that the hardware you said its working ok on |
| 20:34.15 | msm | khem: slightly different |
| 20:34.46 | khem | msm: I would suggest to look at the differences since it works on one hardware it could be just a kernel config or some such |
| 20:37.07 | msm | same kernel and rfs work though |
| 20:37.14 | msm | some minor changes in u-boot |
| 20:37.34 | *** join/#oe rcf (~rcf@21.40-243-81.adsl-dyn.isp.belgacom.be) |
| 20:38.17 | khem | hmmm so .viminfo file was not writable now I see why my vim was crazy on this box |
| 20:38.21 | *** join/#oe fcooper (~a0273011@nat/ti/x-olkjdaoavudkvpvw) |
| 20:38.48 | *** join/#oe rcf (~rcf@21.40-243-81.adsl-dyn.isp.belgacom.be) |
| 20:42.29 | *** join/#oe tomimo (~kurre@xdsl-83-150-88-111.nebulazone.fi) |
| 20:43.14 | *** join/#oe rcf (~rcf@21.40-243-81.adsl-dyn.isp.belgacom.be) |
| 20:43.57 | *** join/#oe rcf (~rcf@21.40-243-81.adsl-dyn.isp.belgacom.be) |
| 20:44.32 | fcooper | Has anyone came across OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG variable left unset error when running MACHINE=am37x-evm bitbake -b eglibc_2.12.bb? Copy of the log is located at http://pastebin.com/LUtqA6Vn I see several posts on the OE forums with no response to the posts. |
| 20:50.57 | *** join/#oe rcf (~rcf@21.40-243-81.adsl-dyn.isp.belgacom.be) |
| 20:53.11 | khem | fcooper: this is because OPTION_EGLIBC_NSSWITCH is not set |
| 20:53.19 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 20:53.36 | khem | in this case it wants that config options OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG and OPTION_EGLIBC_NSSWITCH_FIXED_FUNCTIONS are explicitly set |
| 20:53.48 | *** join/#oe nitink (~nitink@192.55.54.40) |
| 20:54.17 | *** join/#oe rcf (~rcf@21.40-243-81.adsl-dyn.isp.belgacom.be) |
| 20:56.23 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 20:56.38 | *** join/#oe nitin (~nitin@c-98-234-115-200.hsd1.ca.comcast.net) |
| 21:01.03 | ka6sox | khem, ping? |
| 21:01.46 | *** join/#oe fcooper (~a0273011@nat/ti/x-wpjpbajkkwyvebbt) |
| 21:01.47 | khem | ka6sox: hey |
| 21:02.08 | ka6sox | hiya, remove restrictions? no way... |
| 21:02.14 | khem | ka6sox: is there any reason to keep the noose tight on wiki |
| 21:02.15 | ka6sox | remove them for a user? sure! |
| 21:02.33 | khem | ok. I think we can keep the restrictions on new users |
| 21:02.38 | khem | registering |
| 21:02.38 | ka6sox | yes, wikispam...I have NO time to keep up with it. |
| 21:02.58 | khem | but I think for registered users it should be made business as usual |
| 21:03.01 | ka6sox | they register 100's per day |
| 21:03.10 | ka6sox | shiela45 |
| 21:03.13 | ka6sox | bob87 |
| 21:03.24 | khem | isnt there a captcha for registering ? |
| 21:03.59 | ka6sox | the spammers create usernames with real people and then spam with the robot after they get "approved" |
| 21:04.07 | ka6sox | NO automated system will catch that. |
| 21:04.36 | ka6sox | so unless you want your wiki to be overrun with spam then its not doable. |
| 21:04.58 | ka6sox | I have given enough people admin rights to promote users that they *know* are not spammers :D |
| 21:05.27 | khem | hmm for registering there should be a captcha too isnt it |
| 21:05.31 | khem | how do they overcome that |
| 21:05.48 | ka6sox | because I don't allow "autopromotion" |
| 21:06.14 | ka6sox | just because you can register properly does NOT give you access to edit/create/remove |
| 21:06.39 | ka6sox | register properly, talk to one of our admins about promotion... |
| 21:06.41 | fcooper | khem: I guess I don't understand what the solution is. I tried adding GLIBC_EXTRA_OECONF += "OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG OPTION_EGLIBC_NSSWITCH_FIXED_FUNCTIONS" to the recipe but I still got the same error. Was I suppose to be adding this somewhere else? |
| 21:06.49 | ka6sox | then get promoted. |
| 21:07.31 | ka6sox | no automagic....(now the board can override me on this and I'll be glad to back out of trying to keep your wiki free as much as possible of spam. |
| 21:07.34 | khem | ka6sox: ok |
| 21:07.34 | ka6sox | ) |
| 21:07.46 | khem | ka6sox: but we should make it possible for registered users to edit as it used to be |
| 21:07.51 | ka6sox | no |
| 21:08.00 | ka6sox | not unless promoted by a live ADMIN. |
| 21:08.09 | ka6sox | no automagic promotion |
| 21:08.43 | khem | ok. so a new user registers second step is someone promotes him to edit the wiki |
| 21:08.54 | khem | is it then normal for him/her to edit after promotion |
| 21:08.58 | ka6sox | yes |
| 21:09.06 | khem | fcooper: is it with oe-core ? |
| 21:09.43 | khem | fcooper: it seems to be happening with aarago which I guess is based on oe classic |
| 21:09.51 | ka6sox | khem, if I have a username and someone who we know can say "they pass the turing test and are someone who can contribute to this" then we can promote them. |
| 21:10.22 | ka6sox | anything automagic will lead to NOTHING but an overrun wiki with Viagra Spam and other things. |
| 21:10.31 | fcooper | khem: Yes it is with oe-core. |
| 21:10.42 | khem | ka6sox: it would be nice if there was a way for us to promote the users who have contributed in past |
| 21:10.53 | khem | barring if there are spam pages still |
| 21:11.22 | ka6sox | we could do that...I just need more time to be able to find those users. |
| 21:11.49 | ka6sox | so if I knew what user bernhard is on the wiki I could promote him right away... |
| 21:12.01 | ka6sox | but wholesale? recipe for disaster. |
| 21:13.02 | khem | agreed |
| 21:13.10 | khem | fcooper: hmmm |
| 21:13.27 | khem | fcooper: what changes did you make to eglibc config and/or DISTRO_FEATURES |
| 21:14.00 | khem | ka6sox: I think its worth documenting the process for getting wiki access on wiki |
| 21:14.10 | khem | so people can be directed to it |
| 21:14.17 | khem | right now there is some confusion |
| 21:14.29 | khem | and expectation is that now with captcha everything should be hunky dory |
| 21:14.39 | khem | which seems not to be the case as you put it |
| 21:14.45 | ka6sox | its not |
| 21:14.47 | ka6sox | sorry... |
| 21:14.56 | ka6sox | captcha fails everytime with the way the spammers work. |
| 21:14.59 | khem | thats fine, we just then need to document it in wiki |
| 21:15.25 | khem | SIGFOOD |
| 21:17.58 | fcooper | khem: eglibc config? Is that something within the eglibc_2.12.bb recipe? If so the only changes I have made was adding GLIBC_EXTRA_OECONF += "OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG OPTION_EGLIBC_NSSWITCH_FIXED_FUNCTIONS" and changing the SRCREV to SRCREV="13230". I don't know anything about DISTRO_FEATURES so OI doubt that I changed it. |
| 21:25.37 | khem | fcooper: ok bitbake -e eglibc >& prep.txt and paste prep.txt somewhere please |
| 21:33.28 | *** join/#oe kurre2 (~tomimo@xdsl-83-150-88-111.nebulazone.fi) |
| 21:33.48 | *** join/#oe tomimo (~kurre@xdsl-83-150-88-111.nebulazone.fi) |
| 21:34.13 | *** join/#oe pespin (~pespin@123.pool85-50-24.dynamic.orange.es) |
| 21:37.58 | *** join/#oe risca (~risca@h106n1-n-a31.ias.bredband.telia.com) |
| 21:39.03 | fcooper | khem: http://pastebin.com/JcbgY2mq contains the text from prep.txt |
| 21:39.09 | *** join/#oe errordeveloper (~Dmitriche@host109-155-1-13.range109-155.btcentralplus.com) |
| 21:40.43 | *** join/#oe RP__ (~richard@dan.rpsys.net) |
| 21:49.33 | *** join/#oe e-ffi (~cybercom@HSI-KBW-109-192-122-205.hsi6.kabel-badenwuerttemberg.de) |
| 21:53.39 | khem | fcooper: ok so your build is NOT based on oe-core btw. |
| 21:53.49 | khem | fcooper: can you try this fix instead http://pastebin.com/YSZ96LbF |
| 21:53.58 | khem | fcooper: and rebuild eglibc |
| 22:05.32 | *** join/#oe ant____ (~andrea@host6-250-dynamic.0-87-r.retail.telecomitalia.it) |
| 22:07.28 | fcooper | khem: The compiling still failed: http://pastebin.com/HiKdrv6M I however did MACHINE=am37x-evm bitbake -b eglibc_2.12.bb -c clean and then MACHINE=am37x-evm bitbake -b eglibc_2.12.bb. I am trying now using just MACHINE=am37x-evm bitbake eglibc -c clean and MACHINE=am37x-evm bitbake eglibc to see if it makes a difference. I doubt it will but figured I just try it out. |
| 22:10.49 | *** join/#oe notespace1 (~notespace@barracuda.ventureresearch.com) |
| 22:17.28 | msm | what recipe handles: tmp/sysroots/${MACHINE}-tcbootstrap/ |
| 22:18.54 | khem | msm: eglibc-initial |
| 22:19.12 | khem | fcooper: hmmm show me bitbake -e output after patching please |
| 22:19.31 | khem | msm: and also uclibc-initial if you care |
| 22:20.00 | msm | khem: i found a problem |
| 22:20.17 | msm | khem: my kernel headers are pointing to a broken symlink |
| 22:20.28 | msm | khem: when reusing cache |
| 22:20.46 | msm | anyone know an example recipe that needs to fix symlinks for things like this? |
| 22:21.34 | ka6sox | khem, should I contact bluelightning about getting bernhard access? |
| 22:22.12 | msm | e.g.: /home/mattsm/git/poky/build_p4080ds_release/tmp/sysroots/p4080ds-tcbootstrap/usr/include/linux: broken symbolic link to `../../../..//sysroots/p3060qds/usr/include/linux' |
| 22:23.00 | khem | ka6sox: no, just elevate him now that we know he is genuine |
| 22:23.02 | khem | user |
| 22:23.37 | khem | msm: what needs fixing there |
| 22:23.58 | khem | msm: level ? |
| 22:24.09 | ka6sox | what is his username? |
| 22:24.28 | msm | do_install step in eglibc |
| 22:24.40 | msm | it's making symlinks to linux,asm,asm-generic |
| 22:25.00 | msm | works fine when fully building |
| 22:25.03 | msm | but it breaks sstate-cache |
| 22:25.10 | ka6sox | khem, promoted |
| 22:25.11 | msm | i'd like to repair these symlinks |
| 22:25.20 | khem | ka6sox: and let him know |
| 22:25.21 | ka6sox | btw..you have the power to do this as well. |
| 22:25.33 | khem | msm: in my case they are absolute |
| 22:25.42 | khem | msm: so I wonder how do u get them relative |
| 22:25.56 | khem | ok |
| 22:26.15 | msm | khem: abolsute would still not work... |
| 22:27.48 | khem | msm: ok you can fix it in recipes-core/eglibc/eglibc-initial.inc |
| 22:27.54 | khem | do_install step |
| 22:28.07 | khem | but when you are at it please fix uclibc-initial too |
| 22:28.31 | khem | <PROTECTED> |
| 22:28.34 | khem | <PROTECTED> |
| 22:28.37 | khem | <PROTECTED> |
| 22:28.40 | khem | <PROTECTED> |
| 22:28.43 | khem | this is the piece you need to fix |
| 22:28.47 | khem | do u want to make them relative ? |
| 22:29.15 | msm | yes |
| 22:29.20 | msm | mine is relative? |
| 22:29.26 | khem | seems so |
| 22:29.36 | khem | as you pasted |
| 22:29.42 | khem | /home/mattsm/git/poky/build_p4080ds_release/tmp/sysroots/p4080ds-tcbootstrap/usr/include/linux: broken symbolic link to `../../../..//sysroots/p3060qds/usr/include/linux' |
| 22:29.45 | msm | right |
| 22:30.01 | msm | these symlinks point to non-existant directories in the cache case |
| 22:30.25 | khem | hmm |
| 22:30.49 | ka6sox | Tartarus, bernhard has access to work on the wiki now. |
| 22:31.09 | khem | ka6sox: reply to the email thread |
| 22:31.18 | msm | khem: easier fix seems to be just to copy the kernel header |
| 22:31.25 | khem | msm: hmm that indirection level seems skewed |
| 22:33.24 | fcooper | khem: http://pastebin.com/ADQcgzVZ This is for MACHINE=am37x-evm bitbake -e -b eglibc_2.12.bb >& patch.txt |
| 22:34.41 | khem | fcooper: how did u add the patch I gave you |
| 22:34.48 | khem | fcooper: I dont see it in SRC_URI |
| 22:35.08 | ka6sox | khem, sent |
| 22:35.09 | fcooper | khem: http://pastebin.com/Fj8K6sWr This is when I used MACHINE=am37x-evm bitbake -e eglibc >& patch2.txt It is pretty weird that I get two completely different errors. |
| 22:36.31 | fcooper | I didn't even think about using the SRC_URI. I copied the patch into a txt file and ran "git apply eglibc.patch" |
| 22:37.28 | khem | fcooper: never mind I see the patch is applied |
| 22:37.35 | *** join/#oe awozniak (~awozniak@76.205.222.174) |
| 22:37.59 | msm | khem: the cache works if I'm using the p3060qds $machine that is referenced in the symlink… so it seems the actual issue is the broken symlinking |
| 22:38.19 | msm | khem: err, wait... |
| 22:38.22 | khem | fcooper: as I see PR value did not get properly expanded in your case |
| 22:38.31 | msm | khem: pre-typed that… it's almost done testing |
| 22:39.28 | khem | fcooper: /home/franklin/git_projects/bitbake/arago-tmp/work/armv7a-arago-linux-gnueabi/eglibc-1.0-r0/eglibc-1.0/nss/ does this path exist |
| 22:39.53 | fcooper | No |
| 22:40.11 | khem | msm: yes although I am vary that this cross sysroot referencing through symlinks might be not ok |
| 22:40.26 | khem | copying might be better |
| 22:40.39 | khem | fcooper: thats the next problem |
| 22:41.12 | khem | fcooper: can you do bitbake -cclean -b eglibc_2.12.bb and then bitbake eglibc |
| 22:41.26 | khem | fcooper: I want to make sure that reparse happenss |
| 22:41.35 | msm | khem: i'll make a patch to copy and see what feedback we get |
| 22:41.56 | khem | msm: how big is linux/ dir |
| 22:44.42 | msm | 3.4mb |
| 22:45.08 | msm | 3.7M actually |
| 22:45.17 | msm | its much better than having cache not working for me at least |
| 22:45.38 | fcooper | khem: I get the same error as before http://pastebin.com/Fj8K6sWr |
| 22:45.45 | msm | khem: should I add |
| 22:46.01 | msm | do_install[vardeps] += "virtual/kernel:do_sysroot_populate" |
| 22:46.13 | khem | fcooper: ok what does bitbake -e eglibc | grep "^S=" give you |
| 22:46.14 | msm | since this step not locks eglibc to a specific kernel version? |
| 22:46.18 | msm | this seems like overkill... |
| 22:46.44 | Tartarus | fcooper: without scrolling up too far, you did warn folks this is arago right? :) |
| 22:46.59 | khem | Tartarus: yes I figured its aarago |
| 22:47.13 | khem | Tartarus: but problem was in eglibc anyway which I have fixed |
| 22:47.28 | Tartarus | k, thanks khem |
| 22:47.29 | khem | Tartarus: I will post that patch to ml for 2011.03-maintenance branch |
| 22:47.43 | Tartarus | sounds good |
| 22:47.59 | khem | Tartarus: problem is that now I am trying to verify and there might be arago'ness now biting |
| 22:51.05 | khem | fcooper: S seems to be populated ok |
| 22:51.07 | khem | # S=${WORKDIR}/${EGLIBC_BRANCH}/libc |
| 22:51.08 | khem | S="/home/franklin/git_projects/bitbake/arago-tmp/work/armv7a-arago-linux-gnueabi/eglibc-2.12-r21.12+svnr13230/eglibc-2_12/libc" |
| 22:51.18 | fcooper | khem: I am not sure if this makes a difference but initially when I first was running bitbake eglibc_2.12.bb I was getting an entirely different error. I looked at the OE git and saw that the recipe was slightly different. It had the SRCREV set to 13230 which I made the change in my local recipe now. Could this be the underlining issue? |
| 22:51.44 | fcooper | *underlying |
| 22:52.24 | khem | dont think so |
| 22:52.46 | khem | issue is that when evaluating S in the patch I gave you it flunks PR and PV |
| 22:53.02 | khem | OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG = /home/franklin/git_projects/bitbake/arago-tmp/work/armv7a-arago-linux-gnueabi/eglibc-1.0-r0/eglibc-1.0/nss/nsswitch.conf |
| 22:53.51 | *** join/#oe hillct_ (~hillct@cpe-174-109-206-062.nc.res.rr.com) |
| 23:00.03 | *** join/#oe kergoth` (~kergoth@ip24-251-167-38.ph.ph.cox.net) |
| 23:13.09 | fcooper | khem: There is a nsswitch.conf located at /home/franklin/git_projects/bitbake/arago-tmp/work/armv7a-arago-linux-gnueabi/eglibc-2.12-r21.12+svnr13230/eglibc-2_12/libc/nss/ |
| 23:13.14 | khem | fcooper: |
| 23:13.33 | khem | yes thats what I expected it to get when I used S |
| 23:13.46 | khem | Tartarus: whats recommended bitbake version for 2011.03 branch |
| 23:14.10 | denix | khem: 1.10.x |
| 23:14.32 | khem | been muddling with 1.12 :) thx denix |
| 23:15.04 | denix | fcooper: is that regular un-modified eglibc? it worked for me |
| 23:16.07 | denix | fcooper: btw, any specific reason to re-build eglibc at all? as we normally use pre-built binary toolchain in our products... |
| 23:16.35 | fcooper | denix: this is a modified eglibc file. I changed the SRCREV to SRCREV="13230". I also applied the patch that khem sent me: http://pastebin.com/YSZ96LbF |
| 23:17.20 | denix | fcooper: I see. what's the specific feature you are looking from 13230 rev? |
| 23:17.59 | khem | denix: I get ${@oe.utils.ifelse(bool(d.getVar('MACHINE', True)), '${MACHINE}', 'BASE_PACKAGE_ARCH')} |
| 23:18.02 | khem | ERROR: EOL while scanning string literal (MACHINE_ARCH, line 1) while parsing /home/kraj/work/oe/openembedded/recipes/webkit/arora_0.10.2.bb |
| 23:18.06 | khem | flood of those |
| 23:18.26 | kergoth | khem: those mean something referenced a var in a python snippet using {} which was undefined |
| 23:18.29 | fcooper | denix: I am trying trying to run MACHINE=am37x-evm bitbake nano -v -D. Based on your tutorial from Arago Projects and modifying local.conf to have the TOOLCHAIN set to arago. I came across several errors trying to build nano and eglibc is the latest recipe that bitbake nano has failed on. |
| 23:20.08 | denix | fcooper: well, something is bad in the configs, as it shouldn't even go building eglibc with the standard arago setup, as we use pre-built binary toolchain by default. unless you specifically requested internal toolchain built from sources... |
| 23:21.08 | denix | khem: is that oe-classic maintenance and it fails in arora recipe? |
| 23:21.51 | fcooper | denix: My PATH is set to /home/franklin/git_projects/bitbake/arago-bitbake/bin/:/home/franklin/git_projects/bitbake/arago-utils/:/home/franklin/ti-sdk-am37x-evm-05.03.01.00/linux-devkit/bin/:/home/franklin/ccs/ccsv5/eclipse/jre/bin:/home/franklin/ccs/ccsv5/eclipse/jre/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games. I am using the toolchain from with the am37x evm. |
| 23:23.46 | fcooper | denix: *am37x evm 5.03.01 SDK. |
| 23:25.21 | *** join/#oe joelagnel (~joel@cpe-76-184-244-226.tx.res.rr.com) |
| 23:27.26 | denix | fcooper: I see. |
| 23:30.46 | denix | fcooper: I also see couple of your messages from yesterday to the arago list held for moderation... I'll check those and see what the original issue is - you don't need to patch or even re-build eglibc in your setup... |
| 23:31.39 | denix | khem: so, for the newer srcrev of eglibc, we need your patch in the maintenance branch, correct? |
| 23:32.02 | fcooper | denix: Alright denix that would be great. Please let me know. |
| 23:33.26 | khem | denix: yes, but that patch does not work yet |
| 23:33.52 | khem | bitbake does not know PR and PV when the S is asked for |
| 23:33.58 | khem | so it evaluated that wrongly |
| 23:34.12 | khem | that works ok with oe-core but not oe classic |
| 23:34.39 | fcooper | khem and denix: Thanks for you help. My laptop is about to die but I will be back on tomorrow. |
| 23:37.26 | denix | khem: I see, thanks. I was building srcrev=12323 and it works fine for us for now - I'll work with fcooper to rootcause his issue. |
| 23:37.44 | *** join/#oe darknighte_webch (4ac14c5f@gateway/web/freenode/ip.74.193.76.95) |
| 23:45.00 | khem | fcooper: ok I think I have the fixed version |
| 23:45.05 | khem | fcooper: try it please |
| 23:45.47 | khem | fcooper: http://pastebin.com/YPwSXwyF |
| 23:46.20 | khem | I have sent the patch to ml too |
| 23:56.09 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |