| 00:04.58 | *** join/#oe jevin (~jevin@ec2-174-129-222-35.compute-1.amazonaws.com) |
| 00:12.06 | *** join/#oe zecke (~ich@222.68.248.88) |
| 01:36.55 | *** join/#oe hufnus (~hufnus@69-12-177-67.dsl.static.sonic.net) |
| 01:47.44 | *** join/#oe brolin (~brolin@190.250.89.105) |
| 02:01.45 | *** join/#oe fraxinas (~quassel@pD953792C.dip.t-dialin.net) |
| 02:05.45 | *** join/#oe devzero_ (devzero@xdsl-89-0-186-108.netcologne.de) |
| 02:42.13 | *** part/#oe cminyard (~cminyard@pool-173-57-155-71.dllstx.fios.verizon.net) |
| 02:57.47 | *** join/#oe lamawithonel_ (~lucas@pool-173-66-110-102.washdc.fios.verizon.net) |
| 03:10.05 | dorileo | hi guys, I'm getting an error on recipes/base-files/base-files_3.0.14.bb but it just tells me it failed, I've used -D argument to bitbake. how do I see where exactly it's failing? |
| 03:16.47 | *** join/#oe zenlinux (~sgarman@c-98-246-165-28.hsd1.or.comcast.net) |
| 03:36.45 | *** join/#oe methril_ (~methril@189.27.131.59.dynamic.adsl.gvt.net.br) |
| 03:40.19 | *** join/#oe gkwhc (~me@unaffiliated/gkwhc) |
| 03:40.41 | *** join/#oe nslu2-log (~nslu2-log@limax.nslu2-linux.org) |
| 03:48.48 | gkwhc | anyone use SHR? i cant receive SMS and im wondering how to diagnose this. |
| 03:53.17 | *** join/#oe slobo (~slobo@207.81.223.222) |
| 03:53.59 | slobo | is there a way to run rm_work on all packages recursively? I forgot to add it to site.conf and am painfully out of space now |
| 03:54.33 | slobo | (the above of course referring to bitbake) |
| 04:28.43 | *** join/#oe morphis (~morphis@dslb-088-070-159-157.pools.arcor-ip.net) |
| 05:16.42 | *** join/#oe tdebrouw (~tdebrouw@91.182.177.74) |
| 05:31.52 | khem | dorileo: paste complete build log somewhere |
| 05:32.20 | khem | slobo: add it to local.conf and restart the build |
| 05:33.30 | khem | slobo: and may be also add BB_SCHEDULER = "completion" |
| 05:33.38 | khem | to local.conf |
| 05:34.11 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 05:34.18 | khem | gn all |
| 05:34.49 | slobo | thanks khem |
| 05:34.57 | slobo | i'll give it a go |
| 06:25.28 | slobo | INHERIT += "rm_work" and BB_SCHEDULER = "completion" in local.conf and restarting the build did it. thanks |
| 06:31.42 | *** join/#oe rsalveti (~rsalveti@201.82.65.93) |
| 06:31.42 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
| 06:52.47 | *** join/#oe mrAlmond (~gbergamo@82.193.2.131) |
| 06:52.57 | mrAlmond | Hi everyone |
| 06:53.30 | mrAlmond | Which is the recipe name that I must use to build the kernel ? |
| 06:54.22 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 06:56.12 | fraxinas | uhm, usually linux-machinename |
| 06:56.39 | mrAlmond | I've just found "virtual/kernel"... |
| 06:56.53 | mrAlmond | is it the same? |
| 07:03.05 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 07:23.44 | mrAlmond | In my machine conf I'm using PREFERRED_VERSION_linux = "2.6.32.27" Why does it still compile 2.6.37 ? |
| 07:24.03 | *** join/#oe Noor (8bb5d022@gateway/web/freenode/ip.139.181.208.34) |
| 07:24.11 | Noor | hi everybody |
| 07:24.20 | Noor | hi eFfeM_work |
| 07:24.49 | Noor | I have obe question |
| 07:26.10 | Noor | If I have commited one change in my local git repo which is I have moved one task to another bbclass |
| 07:26.52 | *** join/#oe JimHank (~JimHank@212.174.109.54) |
| 07:27.28 | Noor | so not I want to add a task from where I moved the previous task ..... should I sent my patch from my modified file or I have to get unmodified file from main branch and send patch based on that file? |
| 07:28.08 | Noor | *so now |
| 07:29.40 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
| 07:31.06 | *** join/#oe Noor (8bb5d022@gateway/web/freenode/ip.139.181.208.34) |
| 07:35.11 | *** join/#oe rsalveti (~rsalveti@201.82.65.93) |
| 07:35.11 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
| 07:40.03 | mrAlmond | Is there someone who could help me with kernel compilation? |
| 07:44.38 | *** join/#oe likewise (~likewise@095-097-098-131.static.chello.nl) |
| 07:45.16 | *** join/#oe celston (~chris@188-220-141-241.zone11.bethere.co.uk) |
| 07:47.01 | *** join/#oe amarsman (~marsman@90-145-17-249.wxdsl.nl) |
| 07:55.42 | *** join/#oe rsalveti (~rsalveti@201.82.65.93) |
| 07:56.41 | *** join/#oe anarsoul (~anarsoul@46.28.99.150) |
| 07:57.46 | *** join/#oe tscheck1 (~t@83.151.21.119) |
| 08:00.12 | *** join/#oe rsalveti (~rsalveti@201.82.65.93) |
| 08:00.12 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
| 08:15.06 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 08:50.38 | *** join/#oe ChrisD1 (~ChrisD@dsl-217-155-59-204.zen.co.uk) |
| 08:53.39 | *** join/#oe mikestir (~kvirc@213.218.221.154) |
| 08:54.36 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 08:54.42 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 09:06.18 | *** join/#oe sanket (~sanket@114.143.163.33) |
| 09:07.15 | sanket | hello |
| 09:08.08 | sanket | I had a builded a filesystem for mini2440 using oe... I want ffmpeg package .... but bitbake fail.... can anyone help me.... |
| 09:09.31 | sanket | recipes/liba52/liba52_0.7.4.bb do_configure failed |
| 09:10.13 | bluelightning | morning all |
| 09:10.30 | bluelightning | sanket: pastebin the whole error please |
| 09:12.02 | sanket | bluelightning, http://pastebin.mozilla.org/1287102 |
| 09:12.43 | bluelightning | "configure: error: C compiler cannot create executables" |
| 09:12.49 | bluelightning | something quite badly wrong there |
| 09:12.55 | bluelightning | what command did you use? |
| 09:13.13 | sanket | bluelightning, i had use bitbake ffmpeg |
| 09:13.22 | bluelightning | hmm ok |
| 09:13.43 | bluelightning | not sure what could be causing this but there's something fundamentally wrong with your build |
| 09:18.35 | fraxinas | i get a really strange python error here: http://pastebin.com/CuNikEW1 |
| 09:18.43 | fraxinas | does anybody have an idea how to fix that? |
| 09:19.02 | fraxinas | i have Python 2.7.2 and kernel 3.0.0 |
| 09:19.46 | fraxinas | how can that be a syntax err? |
| 09:27.59 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 09:31.36 | hrw | mickeyl: alive? |
| 09:32.45 | bluelightning | fraxinas: doesn't make much sense to me either. can you pastebin the contents of opkg-make-index in your build? |
| 09:32.49 | *** join/#oe pepermint (~pepermint@host100-11-dynamic.58-82-r.retail.telecomitalia.it) |
| 09:33.02 | fraxinas | ayeaye |
| 09:33.41 | fraxinas | http://pastebin.com/EzTrb6Sk |
| 09:34.09 | fraxinas | nothing that looks unusual to me in that script |
| 09:40.23 | mickey|office | hrw: somewhat ;) |
| 09:40.49 | bluelightning | fraxinas: seems OK to me also... |
| 09:43.18 | fraxinas | i already c clean'ed the package and rebaked it without success |
| 09:48.52 | hrw | mickey|office: baby (forgot name) does not allow to sleep? |
| 09:49.32 | ant_work | fraxinas: + ipkgarchs='all any noarch mipsel dm8000' |
| 09:49.42 | ant_work | ^^ looks suspicious |
| 09:49.52 | fraxinas | in which way? |
| 09:50.17 | ant_work | the spacing |
| 09:50.27 | ant_work | I had a related issue maybe |
| 09:50.29 | ant_work | moment |
| 09:51.31 | ant_work | http://paste.debian.net/124848/ |
| 09:51.35 | fraxinas | where does that line come from? run.do_package_update_index_ipk.5614 ? |
| 09:52.16 | fraxinas | soo you're saying the extra space could be the problem |
| 09:52.35 | ant_work | once I fixed it disappeared |
| 09:53.04 | fraxinas | i'll just edit the run.do_package_update_index_ipk.5614 line by hand real quick |
| 09:53.07 | fraxinas | to see if that solves it |
| 09:53.26 | ant_work | maybe is totally unrelated... |
| 09:53.29 | fraxinas | it's even two extra spaces |
| 09:54.05 | ant_work | fraxinas: in my case a whole token was disappering |
| 09:55.19 | fraxinas | ah no that doesn't work, it generates a new run script every time |
| 09:55.29 | fraxinas | so i'll try to fix it in the machine conf |
| 09:55.38 | ant_work | see http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/conf/machine/include/tune-mips32.inc |
| 09:57.42 | fraxinas | hmm my machine.conf doesn't have any PACKAGE_EXTRA_ARCHS concatenation in there |
| 09:57.54 | fraxinas | maybe one of the required incs |
| 10:00.07 | *** join/#oe kobe_ (203a22e3@gateway/web/freenode/ip.32.58.34.227) |
| 10:00.35 | *** join/#oe tasslehoff (~tasslehof@145.79-161-31.customer.lyse.net) |
| 10:00.39 | fraxinas | yeah that would probably be it ant_work |
| 10:00.46 | ant_work | you'll have to check the recent tune overhaul... |
| 10:00.52 | fraxinas | in tune-mips.inc |
| 11:54.17 | *** join/#oe ibot (~ibot@rikers.org) |
| 11:54.17 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Bugtracker: http://bugs.openembedded.org and http://tinderbox.openembedded.org for compile issues | Repository: git.openembedded.org/openembedded and repo.or.cz/r/openembedded.git as ro mirror | This is not a distro or machine support channel |
| 11:55.35 | ensc|w | real problem is that .ipkg own all base directories (e.g. /bin is owned by nearly every package) |
| 11:56.05 | ensc|w | opkg calculates installation order based on directory ownership so the final order is very random |
| 11:57.25 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 12:06.55 | pb_ | ah, yes, I see |
| 12:07.46 | pb_ | I'm not sure there is any good solution to that unfortunately. |
| 12:08.56 | ensc|w | I added the filesystem package as the first RDEPENDS of the top level task package |
| 12:09.20 | ensc|w | that's not nice but it seems to work |
| 12:19.20 | pb_ | yeah |
| 12:19.49 | pb_ | or you could just install the packages in multiple phases, i.e. have a first opkg run which just installs the filesystem package, and then everything else afterwards in a second run. |
| 12:20.30 | pb_ | obviously this particular issue is only going to arise during image construction, though the same general problem could happen in theory with on-device installs too. |
| 12:22.02 | *** join/#oe _abhishek (~abhishek@115.108.3.237) |
| 12:22.11 | *** part/#oe _abhishek (~abhishek@115.108.3.237) |
| 12:24.26 | ensc|w | afair, there was a post on the maillist which allowed to package only the files, not the directories |
| 12:27.36 | ensc|w | http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg03049.html |
| 12:52.54 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 12:53.29 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
| 12:59.44 | *** join/#oe rsalveti_ (~rsalveti@109.234.204.184) |
| 12:59.45 | *** join/#oe rsalveti_ (~rsalveti@linaro/rsalveti) |
| 13:16.00 | *** join/#oe kevinsc (~a0214685@nat/ti/x-mnslyxhbadblkxvy) |
| 13:48.35 | *** join/#oe maelcum (~ahartmetz@188.111.54.34) |
| 13:48.46 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * r7b977ff222 10bitbake.git/lib/bb/ui/hob.py: |
| 13:48.46 | CIA-15 | hob: unset busy cursor on exit |
| 13:48.46 | CIA-15 | Prevent the busy cursor being shown after hob exits if quit is called |
| 13:48.46 | CIA-15 | whilst the busy cursor is set. |
| 13:48.46 | CIA-15 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
| 13:48.47 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * r1009ca570a 10bitbake.git/lib/bb/ui/ (crumbs/hobeventhandler.py hob.py): |
| 13:48.48 | CIA-15 | hob: remove temporary directory on program shutdown |
| 13:48.48 | CIA-15 | Move temp directory handling into the HobEventHandler and clean up the |
| 13:48.49 | CIA-15 | temporary files on program close. |
| 13:48.49 | CIA-15 | Fixes [YOCTO #1307] |
| 13:48.50 | CIA-15 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
| 13:48.50 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * r15cc4fe505 10bitbake.git/lib/bb/ui/crumbs/hobeventhandler.py: |
| 13:48.51 | CIA-15 | ui/crumbs/hobeventhandler: emit a signal when a command fails |
| 13:48.51 | CIA-15 | If a CommandFailed event is seen emit a signal with the error message. |
| 13:48.52 | CIA-15 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
| 13:48.52 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * r2f7eadfdd7 10bitbake.git/lib/bb/ui/crumbs/layereditor.py: |
| 13:49.56 | CIA-15 | ui/crumbs/hobeventhandler: remove unused code |
| 13:49.57 | CIA-15 | Remove some unused variables and methods. |
| 13:49.57 | CIA-15 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
| 13:49.57 | CIA-15 | 03Joshua Lock <josh@linux.intel.com> 07master * rb6f6edd509 10bitbake.git/lib/bb/ui/crumbs/hobeventhandler.py: |
| 13:49.57 | CIA-15 | ui/crumbs/hobeventhandler: emit a signal when there's a fatal-error |
| 13:49.58 | CIA-15 | If the cooker encounters an error we're unable to proceed so emit a signal |
| 13:49.58 | CIA-15 | so that UI's can notify the user and exit. |
| 13:49.59 | CIA-15 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
| 13:51.27 | maelcum | hi. i'm trying to build with configuration angstrom-2001.3 for the pandaboard, using the 2011.03-maintenance branch. |
| 13:51.32 | *** join/#oe brolin (~brolin@nat223.udea.edu.co) |
| 13:52.24 | maelcum | first, i wonder if "pandaboard" is a supported MACHINE at all. "omap4430-panda" fails later :) |
| 13:54.03 | maelcum | and then there is something that looks like a bug: http://pastebin.com/e7LEQwxv |
| 13:54.16 | maelcum | when trying to bitbake x11-image |
| 13:54.48 | maelcum | i'd like to know if i have forgotten something, or if it's a problem in openembedded, bitbake or somewhere else. |
| 13:55.56 | maelcum | (this is with MACHINE=omap4430-panda) |
| 13:59.25 | *** join/#oe rob_w (~bob@ppp-93-104-0-108.dynamic.mnet-online.de) |
| 14:00.23 | *** join/#oe sakoman (~sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) |
| 14:06.15 | *** join/#oe devzero_ (devzero@xdsl-89-0-168-74.netcologne.de) |
| 14:09.57 | *** join/#oe kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 14:18.00 | maelcum | another one: openembedded/recipes/images/gpephone-image.bb: Could not inherit file classes/rootfs_${IMAGE_PKGTYPE}.bbclass |
| 14:18.22 | kergoth | sounds like you didn't set a DISTRO |
| 14:18.57 | maelcum | i did, DISTRO = "angstrom-2011.3" |
| 14:19.37 | kergoth | well, the distro sets IAMGE_PKGTYPE, so apparently you didn't pick a valid one, or you have something else wrong in your setup (e.g. wrong BBPATH) |
| 14:19.48 | kergoth | look in conf/distro/ |
| 14:20.07 | maelcum | setting IMAGE_PKGTYPE manually leads to another error later... |
| 14:20.18 | maelcum | is angstrom-2011.3 not valid? |
| 14:20.29 | kergoth | probably something else that would have been set by your distro. hacking around it isn't going to fix the underlying problem |
| 14:20.38 | maelcum | ok |
| 14:20.50 | kergoth | again, look in conf/distro/ |
| 14:20.55 | kergoth | if it's not there, it isn't going to work |
| 14:22.30 | maelcum | the funny thing is that neither in master nor in the 2011.03-maintenance branch is there any .conf containing "2011". |
| 14:22.56 | maelcum | however the narcissus tool has 2011.3 listed as a valid distro |
| 14:24.24 | maelcum | oh i see, 2011.3 is probably only in the release-2011.03 tag |
| 14:24.27 | kergoth | what that likely means is use of the 2011.03-maintenance branch of OE, based on the 2011.3 oe release |
| 14:24.32 | kergoth | yes |
| 14:24.46 | maelcum | and 2010.x is in fact whatever is current |
| 14:26.52 | maelcum | i've tried 2010.x earlier, but that didn't work apparently due to a bug or incompatibility with bitbake 1.13. |
| 14:32.38 | *** join/#oe pespin (~pespin@90.163.77.194) |
| 14:33.39 | maelcum | that looks good now, bitbake is doing its thing after installing a few missing dependencies on the host machine. |
| 14:33.43 | maelcum | thanks kergoth. |
| 14:34.17 | kergoth | great, np |
| 14:42.45 | kobe_ | how can I make a symbolic link between two folders in the rootfilesystem? (I need to link lib64 to lib) |
| 14:44.22 | kergoth | create a recipe that makes a package tha tincludes it, add it to an existing recipe/package, or use ROOTFS_POSTPROCESS_COMMAND |
| 14:52.55 | *** join/#oe B_Lizzard (~havoc@athedsl-418087.home.otenet.gr) |
| 14:55.04 | kobe_ | ok thanks. I'll try the ROOTFS_POSTPROCESS_COMMAND method |
| 15:07.13 | *** join/#oe CosmicPenguin (~nobody@soa.codeaurora.org) |
| 15:10.05 | *** join/#oe incandescant (~joshual@c-24-21-159-20.hsd1.or.comcast.net) |
| 15:10.56 | *** join/#oe galak (~galak@192.88.168.35) |
| 15:21.09 | *** join/#oe GNUtoo|laptop (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 15:21.33 | pb_ | morning kergoth |
| 15:21.39 | galak | RP__: around? |
| 15:32.45 | *** join/#oe jayabharath (~jayabhara@nat/ti/x-vjzsvayucpwhssmq) |
| 15:33.15 | *** join/#oe nschle85 (~kvirc@82.177.191.90.dyn.estpak.ee) |
| 15:33.27 | *** join/#oe kevinsc (~a0214685@nat/ti/x-dgjajjxlatusojlc) |
| 15:45.45 | *** join/#oe jayabharath (~jayabhara@nat/ti/x-vdyiwwbqvrxjaivu) |
| 15:51.15 | *** join/#oe msm (~msm@192.88.168.35) |
| 15:58.29 | nschle85 | hello openembedded-core/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb does not compile: ./freedesktop.org.xml:754: parser error : Unescaped '<' not allowed in attributes values |
| 15:58.29 | nschle85 | | <mime-type type="application/vnd.oDokument ODA</comment> |
| 15:59.06 | nschle85 | who can fix it ? |
| 16:00.30 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 16:01.20 | *** join/#oe GNUtoo|laptop (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 16:08.21 | *** join/#oe rob_w (~bob@ppp-93-104-0-108.dynamic.mnet-online.de) |
| 16:17.05 | *** part/#oe slobo (~slobo@207.81.223.222) |
| 16:18.28 | *** join/#oe jevin (~jevin@ec2-174-129-222-35.compute-1.amazonaws.com) |
| 16:21.56 | *** join/#oe tom_say (~william@cpe-68-203-248-184.stx.res.rr.com) |
| 16:29.28 | *** join/#oe hollisb (~hollisb@nat-wv.mentorg.com) |
| 16:34.16 | Circuitsoft | alex@msp-vln-app03 ~/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi $ find -iname glib-2.0.pc |
| 16:34.23 | Circuitsoft | ./usr/lib/pkgconfig/glib-2.0.pc |
| 16:34.34 | Circuitsoft | "| configure: No package 'glib-2.0' found" |
| 16:35.53 | Circuitsoft | Any idea why pkgconfig can't find glib-2.0 in my sysroot? |
| 16:41.08 | *** join/#oe nitink (~nitink@134.134.139.70) |
| 16:42.15 | GNUtoo|laptop | hi |
| 16:42.33 | GNUtoo|laptop | add glib-2.0 to the dependency of the thing it's building |
| 16:54.27 | *** join/#oe jevin (~jevin@ec2-174-129-222-35.compute-1.amazonaws.com) |
| 17:05.19 | *** join/#oe woglinde (~woglinde@g225146255.adsl.alicedsl.de) |
| 17:18.21 | *** join/#oe phdeswer (~philippe@a83-245-252-47.elisa-laajakaista.fi) |
| 17:22.03 | *** join/#oe woglinde (~woglinde@g225146255.adsl.alicedsl.de) |
| 17:35.19 | *** join/#oe GNUtoo|laptop (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 17:54.47 | *** join/#oe pepermint (~pepermint@host100-11-dynamic.58-82-r.retail.telecomitalia.it) |
| 18:00.39 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 18:13.36 | *** join/#oe jconnolly (~jconnolly@66.43.64.66) |
| 18:14.52 | Circuitsoft | GNUtoo|laptop - It is. I'm trying to build gstreamer. glib-2.0 has been built. |
| 18:15.07 | Circuitsoft | glib-2.0.pc is where it needs to be in the sysroot, but the gstreamer configure process still fails. |
| 18:19.39 | *** join/#oe morphis (~morphis@dslb-088-070-159-157.pools.arcor-ip.net) |
| 18:23.17 | *** join/#oe galak (~galak@192.88.168.35) |
| 18:30.54 | CIA-15 | 03Philip Balister <philip@balister.org> 07master * r3195e1a544 10openembedded.git/recipes/tasks/task-sdk-gnuradio-native.bb: |
| 18:30.55 | CIA-15 | task-sdk-gnuradio-native : Remove distcc. |
| 18:30.55 | CIA-15 | I shouldn't have added this to the sdk. Deal with this at the image level. |
| 18:30.55 | CIA-15 | Signed-off-by: Philip Balister <philip@balister.org> |
| 18:32.43 | khem | galak: SYSTEMLIBS_DIR hmmm |
| 18:32.50 | khem | galak: thats advanced hackery to beat oe to use same sourcedir for building gcc in different flavours |
| 18:33.09 | khem | nterpreter paths are hardcoded into gcc itself |
| 18:33.17 | khem | so we need to have different interpreter paths for cross sdk |
| 18:33.30 | khem | and earlier when we had every gcc recipe have its own srctree then we could keep such hackery limited to those recipes e.g. gcc-cross-sdk etc. |
| 18:33.31 | galak | khem: hmm, can you give an explicit example |
| 18:33.50 | khem | so at configure time we would emit a .h file which contains the prefix for ld.so |
| 18:33.56 | khem | and then we would concetenate that to name of ld.so to form the final path |
| 18:34.06 | khem | at gcc build time using defines |
| 18:34.11 | khem | this is GLIBC_DYNAMIC_LINKER |
| 18:34.19 | galak | right, I'm familiar with that side |
| 18:34.35 | khem | so that hunk there is to return empty string |
| 18:34.37 | galak | what I'm not clear is what 'values/paths' we want to set GLIBC_DYNAMIC_LINKER to |
| 18:34.58 | khem | galak: thats upto the arch how its setup |
| 18:35.30 | khem | galak: usually it should be inline with the root file system patchs |
| 18:35.57 | galak | so normally I'd expect /lib/.. or /lib64/.. |
| 18:36.01 | khem | yes |
| 18:36.10 | khem | its mucked when generating cross SDK |
| 18:36.24 | galak | that the bit that I'm not clear on it |
| 18:36.44 | galak | is the 'cross SDK' unique or different some how? |
| 18:36.54 | khem | #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2" |
| 18:37.05 | khem | since / is already there |
| 18:37.40 | galak | right so it seems bad/wrong to have SYSTEMLIBS_DIR = "' |
| 18:37.49 | galak | SYSTEMLIBS_DIR = "" |
| 18:38.28 | galak | that would end up with #define GLIBC_DYNAMIC_LINKER64 "/ld-linux-x86-64.so.2" |
| 18:38.36 | khem | correct |
| 18:39.42 | galak | thus my confusion on what these two lines are trying to accomplish: |
| 18:39.43 | galak | <PROTECTED> |
| 18:39.43 | galak | <PROTECTED> |
| 18:39.50 | *** join/#oe slobo (~slobo@d64-180-27-31.bchsia.telus.net) |
| 18:41.00 | khem | galak: that seems redundant to me |
| 18:42.14 | Circuitsoft | khem: It's necessary should someone attempt to use oe under cygwin. |
| 18:42.15 | khem | galak: a case when target_base_libdir is / this could end up with // |
| 18:42.37 | khem | Circuitsoft: if you want your wife to runaway yes :) |
| 18:42.51 | Circuitsoft | khem: Under cygwin, //a/b/c is folder c under share b on SMB server a. |
| 18:43.13 | khem | yes |
| 18:43.22 | Circuitsoft | That has cought me on a few attempts to port things on Windows. |
| 18:43.47 | Circuitsoft | I've since, for the most part, given up, but it is occasionally necessary. |
| 18:44.47 | khem | galak: but that line should not trigger if you have /lib or /lib64 |
| 18:44.48 | galak | khem: how is it redundant, I'm still not clear on when its the right thing for GLIBC_DYNAMIC_LINKER64 to be just "/ld-linux-x86-64.so.2" |
| 18:45.25 | galak | khem: it does, dirname "/lib" returns "/" |
| 18:45.43 | khem | galak: hmmm |
| 18:45.45 | khem | right |
| 18:50.26 | khem | galak: actually its this #define GLIBC_DYNAMIC_LINKER32 SYSTEMLIBS_DIR "/lib/ld-linux.so.2" |
| 18:50.37 | khem | so SYSTEMLIBS_DIR gets concatenated |
| 18:50.44 | khem | prepended actually |
| 18:50.53 | khem | to original GLIBC_DYNAMIC_LINKER |
| 18:51.03 | galak | yeah, the sed line is broken in that respect |
| 18:51.11 | khem | thats why it works |
| 18:51.32 | galak | it works by a fluke right now ;) |
| 18:51.39 | khem | I think that was the intent |
| 18:51.53 | khem | since for SDKs SYSTEMLIBS_DIR will be somewhere else |
| 18:51.59 | khem | since it will be sysrooted |
| 18:52.02 | galak | not according to the commit message |
| 18:52.20 | khem | hmmm |
| 18:52.25 | khem | reads the commit message |
| 18:55.31 | khem | galak: yes the commit message is misleading |
| 18:55.45 | khem | galak: what it does it ok I guess |
| 18:56.03 | khem | hmmm was it a fluke that it was correct |
| 18:56.06 | galak | by it you mean the commit message or the code? |
| 18:56.09 | khem | or if patch changed |
| 18:56.18 | khem | and commit message was not adjusted |
| 18:56.20 | khem | I dont know |
| 18:56.41 | khem | yeah I am looking at the git log of that patch |
| 18:57.13 | khem | this patch had some iterations and may be author forgot to update the commit message is my guess |
| 18:57.48 | khem | you can look back in the ml archives |
| 18:57.54 | khem | and see if thats the case |
| 18:58.09 | galak | hmm, didn't think to look at ml archives, going to look now |
| 18:58.09 | *** join/#oe gnutoo (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 18:58.43 | *** join/#oe nitink (~nitink@192.55.54.36) |
| 18:59.06 | galak | I still think its broken (the patch) as we have issues with 64-bit (non-multilib) setups |
| 18:59.22 | galak | today we seem to default to /lib regardless of 32-bit or 64-bit and thus: |
| 18:59.23 | galak | #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "/lib64/ld-linux.so.2" |
| 18:59.26 | galak | wouldn't be right |
| 19:00.30 | khem | galak: yes see my reply I send few minutes ago |
| 19:01.06 | *** part/#oe gnutoo (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 19:01.07 | khem | galak: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-August/007439.html |
| 19:01.42 | khem | galak: so since ppc64 is kind of new I would say do the right thing |
| 19:01.47 | khem | use the defaults that gcc has |
| 19:02.30 | khem | for ppc64 biarch lib64=64bit and lib=32bit |
| 19:02.45 | galak | khem: where do I need to change /lib to /lib64 for ppc64 |
| 19:02.47 | khem | for ppc64 single arch lib64=64bit |
| 19:03.04 | khem | thats another problem |
| 19:03.08 | Tartarus | ppc64 isn't all that new |
| 19:03.23 | khem | Tartarus: yes in OE-core its new though |
| 19:03.25 | Tartarus | But 32bit /lib and 64bit /lib64 on 64bit is 'normal' for it |
| 19:04.06 | khem | galak: that should not need any change in gcc but in oe you have to account for lib64 |
| 19:04.27 | galak | khem: yeah, its the OE bit I was asking about |
| 19:04.28 | khem | since I think it did not grok anything other than 'lib' in the past for libdir |
| 19:04.42 | khem | its the libdir and base_libdir |
| 19:04.45 | khem | variables |
| 19:04.55 | galak | I'm in agreement, since it matches historic for ppc64 for other distros |
| 19:05.04 | khem | they should be using /lib64 and /usr/lib64 respectively |
| 19:05.38 | khem | right now we will have problems with x86/x86_64 since both exist in oe-core |
| 19:05.45 | khem | and they both use 'lib' |
| 19:05.52 | khem | so when they mulitlib one has to break |
| 19:06.11 | khem | basically its messed up |
| 19:06.25 | khem | but for ppc and mips we cann do the *right thing* |
| 19:07.59 | galak | khem: ok so we have the following in meta/conf/bitbake.conf: |
| 19:08.03 | galak | baselib = "lib" |
| 19:08.14 | khem | galak: meta/conf/bitbake.conf:baselib = "lib" |
| 19:08.20 | khem | make it lib64 |
| 19:08.24 | khem | and then fix the fallouts |
| 19:09.07 | khem | <PROTECTED> |
| 19:09.46 | galak | khem: right, I'm learning how variables work here, so not sure what the best way to 'override' this is for ppc64 |
| 19:09.49 | khem | so if you have BASE_LIB_tune-ppc64 or somesuch set to lib64 |
| 19:09.50 | *** join/#oe chase (~chase@nat/ti/x-ijyyjqkqodikhznc) |
| 19:10.06 | galak | we have that: |
| 19:10.06 | galak | meta/conf/machine/include/powerpc/arch-powerpc64.inc:BASE_LIB_tune-powerpc64 = "lib64" |
| 19:10.39 | khem | meta/conf/machine/include/powerpc/arch-powerpc64.inc |
| 19:10.41 | khem | already has it |
| 19:10.56 | khem | so it should do the right thing |
| 19:10.58 | galak | but that requires multilib.conf usage, trying to make a pure 64-bit build work first |
| 19:11.07 | khem | if you have multilib.conf included |
| 19:11.12 | khem | thats the missing link I believe |
| 19:11.23 | khem | oh |
| 19:12.13 | khem | I guess for that to work yeah you need to override baselib in meta/conf/machine/include/powerpc/arch-powerpc64.inc |
| 19:12.22 | khem | unconditionally |
| 19:13.00 | khem | but there might be more needed since as I said oe metadata only groked 'lib' for libdir |
| 19:13.12 | khem | so fixing those would be needed as you go |
| 19:13.34 | khem | other option is to hack gcc like it was done for x86_64 |
| 19:13.51 | khem | the very same hunk that RP__ removed is needed for ppc64 as well |
| 19:14.00 | khem | but I would not advise doing that |
| 19:14.06 | galak | I have the hack right now locally, but I'd like to avoid it |
| 19:14.31 | khem | yeah I think fixing metadata to let defaults use lib64 would be right |
| 19:20.32 | Circuitsoft | Is there an easy way to run pkgconfig in my sysroot to debug a configure script? |
| 19:20.53 | *** join/#oe chase (~chase@nat/ti/x-narcajooferodrxg) |
| 19:26.23 | galak | khem: trying a build now for ppc64 w/lib64. I'm thinking the multilib changes should have cleaned most of this up |
| 19:28.11 | *** join/#oe morphis_ (~morphis@dslb-088-070-159-157.pools.arcor-ip.net) |
| 19:28.18 | *** join/#oe _chase_ (~chase@nat/ti/x-vqlwcbudheheidct) |
| 19:28.30 | *** join/#oe morphis (~morphis@dslb-088-070-159-157.pools.arcor-ip.net) |
| 19:40.25 | *** join/#oe likewise (~likewise@095-097-098-131.static.chello.nl) |
| 19:40.32 | Circuitsoft | How can I completely restart a recipe? I tried deleting the work/my_sysroot/packagename-vers directory, but bitbake is still trying to restart with do_install. |
| 19:41.23 | *** join/#oe msm1 (~msm@192.88.168.34) |
| 19:45.36 | khem | Circuitsoft: bitbake -ccleanall <recipe> |
| 19:45.44 | khem | Circuitsoft: btw. that with oe-core |
| 19:46.10 | khem | Circuitsoft: with oe.dev use bitbake -cclean <recipe> that should help |
| 19:47.27 | *** join/#oe florian (~fuchs@sign-4db6aaa0.pool.mediaWays.net) |
| 19:47.27 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:47.42 | Circuitsoft | What's the difference between clean and cleanall? |
| 19:48.13 | *** join/#oe woglinde (~heinold@g225146255.adsl.alicedsl.de) |
| 19:54.20 | *** join/#oe likewise (~likewise@095-097-098-131.static.chello.nl) |
| 19:57.48 | *** join/#oe gregT (c05e5c0b@gateway/web/freenode/ip.192.94.92.11) |
| 19:58.17 | *** join/#oe anarsoul (~anarsoul@80.249.91.47) |
| 20:00.36 | *** join/#oe chase (~chase@nat/ti/x-qilebytgmbpudsni) |
| 20:01.28 | *** join/#oe slobo (~slobo@d64-180-27-31.bchsia.telus.net) |
| 20:03.07 | *** join/#oe galak (~galak@192.88.168.34) |
| 20:16.34 | *** join/#oe developer0 (c05e5c0e@gateway/web/freenode/ip.192.94.92.14) |
| 20:20.53 | developer0 | My new recipe tries to fetch from a mirror instead of git, how does one disable mirrors in OE? |
| 20:21.39 | woglinde | look for a STASH variable in local.conf or bitbake.conf |
| 20:22.48 | developer0 | woglinde: couldn't find a STASH variable |
| 20:23.09 | woglinde | developer0 are you oe-core? |
| 20:23.19 | developer0 | woglinde: no oe-classic |
| 20:23.36 | woglinde | than its CVS_STASH |
| 20:23.40 | woglinde | look in local.conf |
| 20:24.04 | woglinde | # Specifies a location to search for pre-generated tarballs when fetching |
| 20:24.04 | woglinde | # a cvs:// URI. Outcomment this, if you always want to pull directly from CVS. |
| 20:24.05 | woglinde | CVS_TARBALL_STASH = "" |
| 20:24.46 | developer0 | woglinde: ok thanks, let me try setting it to nothing |
| 20:31.29 | developer0 | woglinde: it still tries to fetch from the mirror instead of git |
| 20:31.48 | woglinde | hm |
| 20:32.06 | woglinde | than try to kill the wget |
| 20:32.08 | khem | angstrom ? |
| 20:32.15 | developer0 | yes |
| 20:32.33 | khem | well angstrom redirects all kind of dnld to mirror |
| 20:32.41 | khem | including git cvs and what not |
| 20:33.22 | RP__ | galak: We need to fix the sed in gcc configure to do the right thing |
| 20:33.29 | RP__ | galak: That is the proper fix for this |
| 20:33.33 | developer0 | true |
| 20:33.53 | khem | so you only way to disable INHERITing "angstrom-mirrors" |
| 20:34.06 | khem | or modify the class to not care for cvs:// etc. |
| 20:34.26 | khem | RP__: the current sed is ok isnt it ? |
| 20:34.30 | galak | RP__: ok, have another question about the idea of ppc64 (non-multilib) using /lib64, concerns, comments? |
| 20:34.54 | RP__ | galak: there are recipes that don't respect $libdir |
| 20:35.12 | RP__ | galak: We need to get to the point where it works everywhere, some work may remain with that |
| 20:35.26 | RP__ | believes minimal and sato images are clean now, lsb/sdk may not be |
| 20:36.16 | galak | I'm willing to look at it as long as the general direction of utilizing /lib64 for ppc64 is acceptable |
| 20:36.58 | galak | khem: any thoughts on: |
| 20:36.59 | galak | /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference |
| 20:37.38 | developer0 | woglinde, khem: thank you very much |
| 20:37.50 | *** join/#oe chase (~chase@nat/ti/x-okprqmahcsrtluub) |
| 20:39.16 | khem | galak: is that runtime ? |
| 20:39.21 | galak | yes |
| 20:39.25 | galak | on boot |
| 20:40.04 | khem | it seems the libc on target is not same that it was linked to |
| 20:42.45 | RP__ | galak: you mean by default or for multilibs? |
| 20:42.55 | RP__ | galak: regardless, we need to make it work :) |
| 20:43.23 | galak | RP__: by default |
| 20:43.25 | khem | RP__: by default even for non mulitlib case |
| 20:43.44 | khem | right now we always force lib for non multlib case |
| 20:43.50 | RP__ | khem: I realise that |
| 20:43.52 | khem | ppc64 being kind of new to the mix |
| 20:44.15 | khem | RP__: how do we solve the x86/x86_64 case |
| 20:44.24 | khem | since both of them use lib |
| 20:44.25 | RP__ | khem: solve in what way? |
| 20:44.33 | khem | with multilib |
| 20:44.59 | RP__ | khem: well, with multilib enabled one of the libs can use lib64 or lib32 |
| 20:45.09 | RP__ | and we are likely to change the default for x86_64 too |
| 20:45.20 | khem | on x86_64 multilib case 64bit resides in lib64 and 32bit in lib |
| 20:45.42 | RP__ | khem: You should be able to pick your location and have the system respect libdir IMO |
| 20:45.54 | khem | RP__: so I think we should make non mulitlib case for x86_64 also use lib64 may be ? |
| 20:46.01 | RP__ | khem: likely yes |
| 20:46.19 | khem | that will break compatibility with what we have though |
| 20:46.24 | khem | for x86_64 |
| 20:46.30 | RP__ | khem: sad, but true |
| 20:46.31 | khem | I hope thats not a issue |
| 20:46.34 | khem | ok |
| 20:46.47 | RP__ | I don't think its an issue for yocto |
| 20:46.59 | khem | so the gcc change you committed other day needs root file systems to be fixed |
| 20:47.04 | khem | for x86_64 |
| 20:47.16 | RP__ | khem: well, I think the sed expression is wrong |
| 20:47.19 | khem | atleast for non multilib case |
| 20:47.26 | RP__ | it should honour libdir |
| 20:47.27 | khem | hmmm |
| 20:49.15 | khem | RP__: actually for multilib case GLIBC_DYNAMIC_LINKER32 and GLIBC_DYNAMIC_LINKER64 will have different libdirs |
| 20:49.35 | khem | so that needs to be considered as well |
| 20:49.38 | RP__ | khem: It doesn't matter, it just needs to match the one that is currently buiilding |
| 20:50.09 | khem | thats true though since we dont use same gcc |
| 20:50.15 | khem | for 32 and 64 bit |
| 20:50.43 | RP__ | right, we currently don't rely on any compiler/libc support for the multilib pieces |
| 20:51.05 | khem | so ( *"/lib.*\) part should substitute libdir I suppose |
| 20:51.28 | RP__ | yes |
| 20:51.47 | khem | so commit message is correct for that patch |
| 20:52.04 | khem | earlier I was confused with what patch did and what the commit message said |
| 20:52.10 | khem | patch kind of was doing ok |
| 20:52.16 | khem | :) |
| 20:58.00 | galak | here's my version of what the sed line should be to match the commit msg: |
| 20:58.02 | galak | 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\) \( *"/lib.*\)/\(.*\)#\1 SYSTEMLIBS_DIR"/\3#' |
| 21:06.56 | *** join/#oe msm (~msm@192.88.168.34) |
| 21:07.15 | khem | galak: yes thats about right |
| 21:07.29 | khem | galak: and then you will need to get rid of that dirname |
| 21:07.44 | galak | yep |
| 21:07.50 | khem | SYSTEMLIBS_DIR = ${SYSTEMLIBS} |
| 21:08.03 | khem | well we can get rid of SYSTEMLIBS_DIR completely |
| 21:08.29 | khem | galak: would you cook up a patch and send ? |
| 21:09.41 | khem | we still have to make sure that there is no trailing / in SYSTEMLIBS_DIR |
| 21:09.47 | khem | as define |
| 21:10.08 | khem | e.g. SYSTEMLIBS_DIR = /lib/ |
| 21:10.14 | *** join/#oe cminyard (~cminyard@pool-173-57-155-71.dllstx.fios.verizon.net) |
| 21:10.25 | khem | would yield /lib//ld-linux.so.2 |
| 21:16.17 | galak | patch sent, take a look and comment |
| 21:18.42 | khem | galak: actually sed -e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\) \( *"/lib.*\)/\(.*\)#\1 SYSTEMLIBS_DIR" \3#' |
| 21:18.45 | khem | would be better |
| 21:18.51 | khem | since you dont append / |
| 21:18.58 | khem | and expect it from SYSTEMLIBS_DIR |
| 21:19.01 | khem | which we already do |
| 21:19.24 | khem | #define GLIBC_DYNAMIC_LINKER32 SYSTEMLIBS_DIR" ld-linux.so.2" |
| 21:19.29 | khem | thats what it will look like |
| 21:19.53 | khem | sed -e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\) \( *"/lib.*\)/\(.*\)#\1 SYSTEMLIBS_DIR "\3#' |
| 21:19.56 | khem | actually |
| 21:20.02 | khem | #define GLIBC_DYNAMIC_LINKER32 SYSTEMLIBS_DIR "ld-linux.so.2" |
| 21:24.29 | galak | khem: looks, good will send a new version |
| 21:28.06 | khem | galak: ok I will take that new version and give it a whirl with x86_64 |
| 21:28.15 | khem | since thats broken for me and this should fix it |
| 21:30.46 | galak | khem: do you want to get rid of the #define SYSTEMLIBS_DIR completely? |
| 21:32.23 | khem | galak: if it does not have any advantage then I would prefer that we reuse SYSTEMLIBS |
| 21:32.31 | khem | but no preference |
| 21:32.49 | khem | since SYSTEMLIBS_DIR seems more explanatory |
| 21:33.16 | galak | oh, I see |
| 21:35.14 | galak | wait, I'm confused |
| 21:36.46 | khem | galak: SYSTEMLIBS_DIR gets transferred into a default.h header file which is used during compilation |
| 21:37.28 | khem | so you have to remove it from sed expr as well as in other places |
| 21:38.14 | galak | no, we still want the result of the sed expr to look like: |
| 21:38.15 | galak | #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "ld-linux-x86-64.so.2" |
| 21:42.20 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 21:44.50 | Circuitsoft | https://gist.github.com/a1dceb578a6e73fc7153 - Any idea why gstreamer is refusing to build? |