| 00:00.50 | RP__ | Tartarus: pong |
| 00:01.02 | Tartarus | fetch2 funny issue |
| 00:01.31 | Tartarus | One box get_srcrev gives me "git[0" |
| 00:01.48 | Tartarus | Another parses it out correctly from SRCREV=171 (which is a tag) |
| 00:02.15 | Tartarus | Where do I even start digging on that? |
| 00:02.38 | RP__ | Tartarus: same git-native version? |
| 00:02.46 | Tartarus | yeah |
| 00:02.56 | Tartarus | both machines are on the same set of repos |
| 00:03.09 | RP__ | Tartarus: git-native built in both cases? |
| 00:03.19 | Tartarus | these are both on things like udev_171.bb or linux-omap_2.6.39.bb |
| 00:03.43 | Tartarus | and yeah |
| 00:03.52 | RP__ | Tartarus: both with fetch2 being used? |
| 00:03.52 | Tartarus | whole world for systemd-gnome-image is built, sans those two recipes |
| 00:04.18 | Tartarus | # SRCPV=${@bb.fetch2.get_srcrev(d)} |
| 00:04.18 | Tartarus | SRCPV="1+git.kernel.org[0:" |
| 00:04.26 | Tartarus | So I assume yes, all the fetch2 stuff is set right |
| 00:04.57 | RP__ | Tartarus: corrupt cache of some kind? |
| 00:05.29 | Tartarus | nuking 'em all now |
| 00:06.49 | RP__ | needs to sleep I'm afraid |
| 00:06.59 | Tartarus | k |
| 00:07.00 | Tartarus | later |
| 00:07.44 | Tartarus | very crazy |
| 00:08.30 | *** join/#oe cfrabel (~cfrabel@LMontsouris-156-24-37-125.w217-128.abo.wanadoo.fr) |
| 00:25.36 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 00:29.17 | Crofton | the left coast/eu time differential is rough |
| 01:04.04 | *** join/#oe kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 01:25.38 | *** join/#oe dijenerate (~dijenerat@204.212.240.159) |
| 01:57.09 | *** join/#oe rsalveti (~rsalveti@201.82.65.93) |
| 01:57.09 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
| 02:02.39 | *** join/#oe lamawithonel_ (~lucas@72-63-213-31.pools.spcsdns.net) |
| 02:02.46 | *** join/#oe devzero_ (devzero@xdsl-78-35-51-199.netcologne.de) |
| 03:00.43 | *** join/#oe thaytan (~jan@ppp59-167-167-201.static.internode.on.net) |
| 03:02.00 | *** join/#oe hufnus (~hufnus@69-12-177-67.dsl.static.sonic.net) |
| 03:14.59 | *** join/#oe hbeck (~hbeck@69.41.94.155) |
| 03:32.27 | *** part/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 03:35.38 | *** join/#oe methril (~methril@189.27.136.57.dynamic.adsl.gvt.net.br) |
| 03:39.02 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
| 04:34.20 | *** join/#oe vanner (~vanner@195.91.241.19) |
| 04:44.44 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 04:48.58 | *** join/#oe svolpe (~Gerrath@unaffiliated/gerrath) |
| 05:03.47 | *** join/#oe MWelchUK_work__ (~welchma@65.91.2.71) |
| 05:05.58 | *** join/#oe rghunter (~rghunter@box.bu.edu) |
| 05:06.51 | *** join/#oe darkschneider2 (~gab@93.51.118.31) |
| 05:07.37 | *** join/#oe toi (~peter@vrt.nat.ibbt.be) |
| 05:07.59 | rghunter | has anyone attempted to build the ar drone kernel using oe? |
| 05:12.51 | *** join/#oe darkschneider_ (~gab@93-32-51-181.ip32.fastwebnet.it) |
| 05:19.37 | *** join/#oe amarsman (~marsman@52488909.cm-4-1c.dynamic.ziggo.nl) |
| 05:30.36 | *** join/#oe hillct (~hillct@cpe-174-109-201-200.nc.res.rr.com) |
| 05:30.55 | *** join/#oe tasslehoff (~Tasslehof@147.84-49-231.nextgentel.com) |
| 05:53.01 | *** join/#oe Crofton (~balister@108-65-78-2.lightspeed.sntcca.sbcglobal.net) |
| 06:19.06 | *** join/#oe tdebrouw (~tdebrouw@91.182.45.162) |
| 06:19.31 | *** join/#oe amarsman (~marsman@89.184.175.76) |
| 06:29.28 | *** join/#oe vitus (~vitus@145.253.169.210) |
| 06:35.36 | CIA-8 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r22b971e958 10openembedded.git/recipes/kexec-tools/kexec-tools.inc: (log message trimmed) |
| 06:35.36 | CIA-8 | kexec-tools: don't depend on virtual/kernel |
| 06:35.36 | CIA-8 | * Imported from oe-core (ba6da75657d0bf9ed48f0d6c4132f12993648e7a) |
| 06:35.36 | CIA-8 | * There doesn't appear to be any terribly good reason for kexec-tools to |
| 06:35.36 | CIA-8 | * depend on the kernel. (I verified that kexec-tools is buildable in a |
| 06:35.37 | CIA-8 | * clean TMPDIR without having previously built virtual/kernel.) |
| 06:35.38 | CIA-8 | * Having this dependency in place is a nuisance because it makes it |
| 06:37.29 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 06:47.40 | *** join/#oe rschus (~rschus@68.163.71.86.rev.sfr.net) |
| 06:51.45 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 06:52.21 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 06:54.45 | *** join/#oe lamikr (~lamikr@dyn60-31.dsl.spy.dnainternet.fi) |
| 07:00.19 | *** join/#oe GNUtoo (~GNUtoo@host148-3-dynamic.244-95-r.retail.telecomitalia.it) |
| 07:25.03 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 07:25.23 | mangomake | the console-image seems to use DES encryption for passwords by default giving an effective maximum password length of 8 characters, I want to change this to use md5 (i.e. chpasswd -m , mkpasswd -m md5) but cannot find any config file for this, does it have to be done at build time? |
| 07:27.09 | *** join/#oe MMx (mmx@2001:41b8:200::42) |
| 07:31.34 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
| 07:32.12 | *** join/#oe tscheck1 (~weechat@83.151.21.119) |
| 07:32.14 | *** join/#oe bluelightning (~paul@cpc9-lewi14-2-0-cust183.2-4.cable.virginmedia.com) |
| 07:32.14 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 07:56.28 | ant_work | pb_: today's consult would be about debian naming: should I just inherit+="debian" to get klibc -> libklibc? And apart the lib, what happens to the binaries in 'utils'? |
| 08:17.13 | *** join/#oe florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 08:17.13 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:18.05 | *** join/#oe Tartarus (trini@pixelshelf.com) |
| 08:19.21 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 08:31.58 | *** join/#oe drainbamage (7d132775@gateway/web/freenode/ip.125.19.39.117) |
| 08:32.01 | drainbamage | hii |
| 08:38.32 | *** join/#oe kristoffer (~kristoffe@host-90-237-151-38.mobileonline.telia.com) |
| 08:39.15 | *** join/#oe celston (bcdc8df1@gateway/web/freenode/ip.188.220.141.241) |
| 08:39.44 | *** join/#oe thhp (50c14443@gateway/web/freenode/ip.80.193.68.67) |
| 08:42.39 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 08:46.25 | ant_work | interesting commits in oe-core about INHIBIT_DEFAULT_DEPS = "1" for many recipes |
| 08:47.43 | ant_work | oe-classic starts to have too much drift to be put in sync with oe-core. Someone said 'pointless' |
| 08:47.55 | celston | I'm a bit confused about bb recipe variable namespacing, can anyone help me sort out my dimwittedness? |
| 08:50.48 | ant_work | have you read the (a bit outdated) documentation? |
| 08:50.58 | ant_work | in that case, just fire your q |
| 08:52.40 | celston | I've had a look in the bb and oe documentation, probably missed the answer I need :) |
| 08:53.52 | celston | So I have a recipe which would like to use KERNEL_VERSION as set in kernel.bbclass. What would I need to do to make sure that this recipe can access it? |
| 08:55.34 | ant_work | is just easy: |
| 08:56.04 | celston | Or to widen the question (in case there's a better way to solve this). I'm compiling an old kernel without falloc (vendor supplied kernel), I'd like to compile util-linux with --disable-falloc if kernel version < 2.6.25. Is there already a way to do that, before I invent my own? |
| 08:56.19 | ant_work | base_version_less_or_equal |
| 08:57.44 | ant_work | but I have a bad news...this fails with some fancy kernel version strings |
| 08:58.29 | ant_work | we had similar issue and wrote a workaround: see linux/linux-kexecboot.inc |
| 08:58.30 | celston | That saves me reinventing the version comparison, but I still need access to KERNEL_VERSION from util-linux*.bb |
| 09:00.36 | celston | In linux-kexecboot.inc you use PV, which won't work for util-linux :( |
| 09:01.21 | celston | I know I could call get_kernelversion from linux-kernel-base.bbclass, but it seems wasteful to re-parse the header. |
| 09:05.03 | ant_work | let me see the recipe |
| 09:05.45 | celston | Which one? |
| 09:06.38 | ant_work | I'm looking at root/recipes/util-linux/util-linux.inc |
| 09:07.04 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 09:07.04 | celston | That's the one. |
| 09:07.09 | ant_work | I see kernel is not listed in depends so you could actually build withouth it :/ |
| 09:07.39 | ant_work | no way to peek in STAGING_KERNEL_DIR |
| 09:07.52 | celston | I wonder if it's strictly a libc dependency. |
| 09:08.15 | ant_work | in oe-dev util-linux DEPENDS = "zlib ncurses" |
| 09:08.33 | celston | i.e.: util-linux needs falloc, provided by libc, dependent on kernel support. |
| 09:09.12 | ant_work | ok, those are default deps |
| 09:09.41 | ant_work | (libc and toolchain) |
| 09:10.43 | celston | Is libc configured for certain features depending on kernel support? Perhaps I could query the libc package instead of the kernel ver. |
| 09:14.38 | *** join/#oe thhp (50c14443@gateway/web/freenode/ip.80.193.68.67) |
| 09:15.12 | ant_work | *libc (apart klibc) do not compile against kernel headers |
| 09:15.45 | ant_work | but use linux-libc-headers instead |
| 09:17.28 | celston | Let me dig a bit more and get my facts straight on what fallocate in util-linux is really looking for, biab. |
| 09:18.02 | ka6sox-away | ant_work, ping? |
| 09:18.13 | ant_work | hello |
| 09:18.26 | ka6sox-away | hiya, if I find email addy's can you add to ML? |
| 09:18.34 | ka6sox-away | I fixed the wiki already. |
| 09:18.55 | ant_work | I have no supercow powers |
| 09:19.22 | ka6sox-away | okay, I'll ask pb_ then :D |
| 09:19.25 | ant_work | I would have collected a list to send to XorA or Crofton |
| 09:19.38 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 09:19.38 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 09:20.12 | celston | OK, fallocate.c in util-linux includes linux/falloc.h. So should it really depend on the kernel? Or does oe provide the kernel headers from a different package? |
| 09:20.44 | ka6sox-away | ya, both would just forward it on to somebody else.... |
| 09:20.59 | ant_work | :] |
| 09:21.02 | ka6sox-away | okay I fixed wiki though (although its not really alphabetical... |
| 09:21.04 | ka6sox-away | ) |
| 09:21.28 | ka6sox-away | I don't have cow_powers for ML |
| 09:24.02 | bluelightning | hi all |
| 09:24.46 | *** join/#oe drainbamage (7d132775@gateway/web/freenode/ip.125.19.39.117) |
| 09:24.59 | drainbamage | hii i'm trying to compile krb5 |
| 09:25.16 | ka6sox-away | morning bluelightning |
| 09:25.21 | drainbamage | i am getting some error in compiling |
| 09:25.40 | drainbamage | <PROTECTED> |
| 09:26.08 | drainbamage | anyone have idea |
| 09:26.14 | drainbamage | any idea>> |
| 09:26.15 | drainbamage | >> |
| 09:27.48 | XorA | ka6sox-away: ping |
| 09:27.58 | ka6sox-away | XorA, pong |
| 09:28.28 | celston | drainbamage: Can you paste the full configure log to pastebin? |
| 09:28.42 | drainbamage | k |
| 09:30.05 | drainbamage | http://pastebin.com/Rv53vLDw |
| 09:33.28 | celston | Have you tried doing what it says? Open a devshell for the app and run 'make distclean' |
| 09:34.04 | celston | LDFLAGS value has only whitespace diffs I think. |
| 09:35.01 | celston | ant_work: fallocate.c in util-linux includes linux/falloc.h. Does that mean it *should* depend on the kernel pkg? Or does oe provide the kernel headers from a different pkg? |
| 09:38.31 | drainbamage | i've tried a clean make |
| 09:38.37 | drainbamage | but the same error |
| 09:38.44 | drainbamage | i'm getting again |
| 09:38.47 | ant_work | celston: sorry, phone call... |
| 09:38.52 | ant_work | brb |
| 09:38.56 | celston | ant_work, np :) |
| 09:39.11 | celston | drainbamage: define 'clean make' |
| 09:40.15 | drainbamage | k |
| 09:40.17 | drainbamage | let me try |
| 09:40.47 | celston | bitbake -c clean krb5 ? |
| 09:41.11 | drainbamage | yeah i've tried this before |
| 09:41.18 | *** join/#oe chrisw957 (~chris@mail.tacticalelectronics.com) |
| 09:41.31 | ant_work | celston: see kernel.bbclass |
| 09:42.03 | drainbamage | are u able to compile krb5 ?? |
| 09:42.25 | celston | drainbamage: I'm doing board bring-up on a new platform, so no :) |
| 09:42.38 | drainbamage | ohk |
| 09:43.01 | *** join/#oe phdeswer (~philippe@80-186-155-124.elisa-mobile.fi) |
| 09:43.53 | celston | ant_work: yep. Been looking in there all morning. |
| 09:44.15 | ant_work | kernel headers are staged per machine when building a kernel |
| 09:45.10 | *** join/#oe pepermint (~pepermint@host167-85-dynamic.8-87-r.retail.telecomitalia.it) |
| 09:45.55 | celston | util-linux includes linux/falloc.h, so it should depend on the kernel recipe then? |
| 09:48.59 | pb_ | no, it should be getting the sanitized linux/falloc.h from linux-libc-headers |
| 09:49.18 | ant_work | well, I see some patches around |
| 09:49.21 | ant_work | Patchworkβ [oe,v4] linux-libc-headers_2.6.24: Add falloc.h to kernel exported headers |
| 09:49.28 | pb_ | the only things that should be compiling against headers from the kernel itself are kernel modules. |
| 09:49.40 | ant_work | 'morning pb_ |
| 09:50.17 | pb_ | hi ant |
| 09:50.21 | drainbamage | can anyone help me |
| 09:50.33 | pb_ | depends what help you need. |
| 09:50.40 | drainbamage | haha |
| 09:50.41 | pb_ | are you drowning? on fire? |
| 09:50.48 | drainbamage | lol |
| 09:51.05 | drainbamage | plz help me krb5 compilation |
| 09:51.14 | ant_work | pb_: about the debian renaming..I'll try that. Hacking with FILES_ was leading me to bad issues with RDEPENDS |
| 09:51.16 | pb_ | what goes wrong for you? |
| 09:51.29 | drainbamage | http://pastebin.com/Rv53vLDw |
| 09:52.14 | pb_ | oh, that's weird |
| 09:52.25 | pb_ | crazy krb5 seems to be doing some kind of recursive configure thing |
| 09:52.39 | drainbamage | hmm.. |
| 09:52.44 | pb_ | I suspect that if you do a sed 's/ / /' kind of thing on LDFLAGS then that will probably sort it out |
| 09:58.38 | *** join/#oe pespin (~pespin@90.163.82.81) |
| 09:59.56 | *** join/#oe morphis (~morphis@ip-2-206-208-250.web.vodafone.de) |
| 10:03.52 | celston | morning pb_, sorry, been afk. Catching up now. |
| 10:05.51 | celston | pb_: in my case, there *is* no falloc.h, kernel is 2.6.18 (mmmm, vintage vendor kernel). So it's a question of how to pass --disable-fallocate to util-linux configure in this case. |
| 10:07.35 | pb_ | what linux-libc-headers are you using? |
| 10:08.10 | pb_ | and, well, you'd rather hope that util-linux would be able to figure out for itself that falloc.h was missing. This is meant to be one of autoconf's core competencies. |
| 10:08.36 | ant_work | in that regard I could find this: http://comments.gmane.org/gmane.linux.utilities.util-linux-ng/3511 |
| 10:08.42 | celston | Yes, that's my feeling on the matter too :) |
| 10:09.23 | celston | +1 fixed upstream :) |
| 10:10.54 | *** join/#oe CMoH-office (~cipi@89.35.222.158) |
| 10:10.54 | *** join/#oe CMoH-office (~cipi@unaffiliated/c-moh) |
| 10:14.57 | *** join/#oe kristoffer (~kristoffe@host-90-237-172-214.mobileonline.telia.com) |
| 10:15.43 | *** join/#oe sanket (~sanket@114.143.165.67) |
| 10:17.39 | drainbamage | anyone have idea regardin libldapsdk?? |
| 10:17.56 | drainbamage | this lib comes with which package |
| 10:18.30 | pb_ | openldap maybe? |
| 10:18.50 | drainbamage | k |
| 10:18.55 | drainbamage | i'll try |
| 10:29.48 | drainbamage | and libgssapi.so |
| 10:40.06 | *** join/#oe morphis (~morphis@ip-2-206-208-250.web.vodafone.de) |
| 10:47.20 | ajb_oe | What controls which binaries busybox supplies? I'd like to replace the shell with a full featured bash (and a bunch of the other CLI utilities as well) |
| 10:50.38 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 11:02.57 | *** join/#oe errordeveloper (~barby@host109-152-113-105.range109-152.btcentralplus.com) |
| 11:05.03 | mangomake | anybody seen msgs like this before and know what it means? http://pastebin.com/UqZZFuVC |
| 11:05.09 | errordeveloper | hello |
| 11:05.41 | mangomake | I used the same tree to build for zaurus which works fine - built for tx25 and get those after kernel loads |
| 11:05.41 | errordeveloper | I'm trying to intall bitbake on slackware using 'pip install bitbake' |
| 11:05.53 | errordeveloper | and it doesn't work for some strange reason .. |
| 11:06.56 | bluelightning | errordeveloper: which version of bitbake do they provide in slackware? |
| 11:07.45 | bluelightning | ajb_oe: I think you'd just need to get the packages that provide the binaries you want installed |
| 11:08.13 | errordeveloper | well .. there is not slackware package |
| 11:08.18 | bluelightning | ajb_oe: the alternatives system should handle things like bash where busybox otherwise provides a cut-down version of the same package |
| 11:08.25 | errordeveloper | hence i'm trying to use pip |
| 11:08.27 | bluelightning | ajb_oe: erm, s/package/binary |
| 11:08.59 | bluelightning | errordeveloper: hmm, ok, don't know anything about pip I'm afraid |
| 11:09.52 | bluelightning | errordeveloper: if you're lucky you might find someone else who uses it here, but frankly I would suggest grabbing it from git or a release tarball and just extracting it next to your OE tree as most people do |
| 11:13.47 | errordeveloper | perhaps getting bitbake from the git repo is the best option really :) |
| 11:21.41 | ajb_oe | bluelightning: thanks... |
| 11:23.18 | drainbamage | only libldap comes up with openldap package |
| 11:23.23 | drainbamage | no ldapsdk |
| 11:23.31 | drainbamage | libldapsdk |
| 11:40.32 | celston | pb_ ant_work: I have a 'style' question. I've added a recipe for a later version of util-linux (which includes the patch ant_work pointed me at). *most* of the patches which apply to the current version apply to this new version too. Should I clone the util-linux-<ver> dir to util-linux-<ver+1>, or should I move it to util-linux ? |
| 11:41.08 | pb_ | Move it to util-linux. |
| 11:41.50 | celston | Cool, thanks pb_ |
| 11:45.41 | celston | So now I have a recipe for the later version, should I post it to the ML for discussion/application? |
| 11:47.32 | pb_ | Yes, please. |
| 11:48.14 | pb_ | If this is oe classic, send it to the openembedded-devel list. If this is oe-core, send it to the oe-core list. |
| 11:53.27 | celston | oe-core. |
| 12:00.28 | *** join/#oe errordeveloper (~barby@host86-185-146-79.range86-185.btcentralplus.com) |
| 12:06.36 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
| 12:13.47 | *** join/#oe SystemR89 (~SystemR89@host166-28-dynamic.40-79-r.retail.telecomitalia.it) |
| 12:15.41 | *** join/#oe mgundes (~kays@95.0.156.17) |
| 12:15.55 | mgundes | Hi everybody |
| 12:34.17 | *** join/#oe vitus (~vitus@145.253.169.210) |
| 12:35.43 | *** join/#oe rickfoosusa (~chatzilla@adsl-68-91-195-173.dsl.austtx.swbell.net) |
| 12:37.17 | *** join/#oe kgilmer (~kgilmer@ntngsk052174.ngsk.nt.ftth4.ppp.infoweb.ne.jp) |
| 12:38.38 | *** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |
| 12:41.02 | *** join/#oe pespin (~pespin@217.Red-88-26-201.staticIP.rima-tde.net) |
| 12:53.22 | otavio | RP__: the problem I had yestarday with the task was due its name not end with nativesdk. I renamed it and then it worked. |
| 12:53.39 | RP__ | otavio: ah, cool |
| 12:56.26 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 12:56.28 | otavio | RP__: dunno why this is require |
| 12:56.37 | otavio | *required* |
| 12:56.55 | RP__ | otavio: nativesdk.bbclass now only works magic on things it sees marked as nativesdk |
| 12:56.56 | *** join/#oe lamawithonel (~lucas@wsip-174-79-188-247.dc.dc.cox.net) |
| 12:57.13 | otavio | RP__: and this is done based on PN? |
| 12:57.23 | RP__ | otavio: yes |
| 12:57.33 | RP__ | otavio: It makes more sense in the native.bbclass case |
| 12:57.51 | RP__ | otavio: I'm trying to bring native.bbclass and nativesdk.bbclass into line with each other |
| 12:58.07 | *** join/#oe playya_ (~playya@93.216.241.157) |
| 12:58.54 | otavio | RP__: I see |
| 13:09.06 | *** join/#oe kevinsc (~a0214685@nat/ti/x-eyyajljddyvlsgnm) |
| 13:14.40 | *** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) |
| 13:17.52 | *** join/#oe mgundes (~kays@95.0.156.17) |
| 13:26.26 | *** join/#oe kristoffer_ (~kristoffe@host-90-237-176-171.mobileonline.telia.com) |
| 13:30.18 | *** join/#oe udovdh (~udovdh@pindarots.xs4all.nl) |
| 13:42.27 | *** join/#oe kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 13:42.35 | pb_ | morning kergoth |
| 13:43.42 | *** join/#oe kannerke (~pvandenb@83.101.83.77) |
| 13:46.04 | *** part/#oe Tartarus (trini@pixelshelf.com) |
| 13:47.01 | kannerke | I'm having some problems to link my program when cross-compiling for the TI Netra |
| 13:47.23 | kannerke | it is a QT program using OpenGL without X11 |
| 13:48.02 | kannerke | do I need to include -lQtOpenGLE? |
| 13:48.16 | *** join/#oe woglinde (~heinold@g225145194.adsl.alicedsl.de) |
| 13:48.37 | kannerke | http://groups.google.com/group/beagleboard/browse_thread/thread/af08e6df4cf72a64 mentions QtOpenGLE is not used by the examples |
| 13:48.58 | *** join/#oe Tartarus (trini@pixelshelf.com) |
| 13:49.23 | kannerke | whn I include it, I get some undefined reerence errors of libQtOpenGLE.so |
| 13:50.00 | kannerke | e.g.: ../sysroots/armv7a-none-linux-gnueabi/usr/lib/libQtOpenGLE.so: undefined reference to `QEglContext::configAttrib(int, int*) const' |
| 13:50.01 | woglinde | hi tartaturs |
| 13:50.47 | woglinde | kannerke use the precompiled packages |
| 13:51.10 | woglinde | dont know why he take the pain to compile qt himself on the beagle |
| 13:52.34 | kannerke | woglinde: which precompiled packages? |
| 13:58.28 | woglinde | angstroem? |
| 14:00.46 | *** join/#oe kevinsc1 (~a0214685@nat/ti/x-fcbvufxdhwurvzea) |
| 14:00.47 | khem | RP__: around |
| 14:01.50 | khem | RP__: if you add FEED_ARCH = ${BASE_PACKAGE_ARCH}" somewhere in your distro.conf you should be abale to reproduce the parsing error I am seeing |
| 14:02.28 | RP__ | khem: ok, I'll try that |
| 14:02.47 | pb_ | khem: like that, or with matching quotes? |
| 14:03.19 | *** join/#oe devzero_ (devzero@xdsl-89-0-160-68.netcologne.de) |
| 14:04.24 | RP__ | khem: hmm, it didn't work here |
| 14:05.15 | RP__ | If I add it to overrides too though... |
| 14:05.24 | *** join/#oe mgundes (~kays@95.0.156.17) |
| 14:05.40 | RP__ | (and enable rm_work) |
| 14:08.35 | RP__ | Ah, I can understand the problem I think |
| 14:08.54 | RP__ | If you add FEED_ARCH into OVERRIDES and its "all", that causes problem |
| 14:10.01 | RP__ | Specifically, the rm_work_all task conflicts with rm_work |
| 14:11.17 | pb_ | hm, those perl changes seem to have hosed my TMPDIR somehow. |
| 14:12.09 | ant_work | heh..I missed the autofoo fixes btw |
| 14:12.48 | pb_ | oh well, probably about time I did a clean build anyway |
| 14:13.01 | kergoth | heh, we really need a new char for overrides, and/or overrides namespaces |
| 14:13.04 | kergoth | yawns |
| 14:13.11 | pb_ | yeah |
| 14:13.57 | pb_ | still, what's FEED_ARCH doing in OVERRIDES anyway? that sems a bit on the bogus side. |
| 14:14.34 | *** join/#oe rschus (daemon@gate.tarent.de) |
| 14:14.59 | RP__ | pb_: If you did manage to work around that parsing failure, rebuilding autoconf-native/automake-native would probably fix it if I'm guessing correctly |
| 14:15.23 | RP__ | pb_: I've never liked the idea. The reason is so you can do things like have armv7a specific overrides |
| 14:15.44 | RP__ | kergoth: agreed, just a question of how/when we'd do something like that... |
| 14:16.02 | pb_ | yeah, probably. I don't actually have a parsing failure at the moment, it's just that autom4te is looking for perl in the wrong place |
| 14:16.45 | RP__ | pb_: perl got moved into its own special path which means anything assuming it was in the sysroot needs to rebuild |
| 14:17.02 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 14:17.03 | RP__ | hopes this will put some of the perl issues to rest, finally |
| 14:17.06 | pb_ | yeah |
| 14:17.24 | pb_ | I'll just blow the tree away and rebuild. |
| 14:17.41 | pb_ | gotta save my modified kernel tree first, though, be annoying to lose that. heh. |
| 14:18.35 | pb_ | meantime I'll work on webkit for a bit, and then when that gets too nauseating I will have a look at the buildbot thing. |
| 14:18.48 | RP__ | pb_: :) |
| 14:19.00 | pb_ | doesn't look like it should be too hard to set up from the quick glance I had earlier. |
| 14:19.22 | RP__ | would like to know why builds are taking 15 mins longer :/ |
| 14:19.25 | pb_ | compared to when? |
| 14:19.41 | RP__ | pb_: A few days ago |
| 14:20.01 | RP__ | pb_: trouble is I had a sane result, I added a patch, got a bad one, reverted the patch and its still bad |
| 14:20.21 | RP__ | so I'm at a loss to explain the result :/ |
| 14:20.57 | RP__ | You can't even diff build times between recipes as it depends too much on system load |
| 14:21.05 | RP__ | We have a very chaotic system :( |
| 14:22.14 | *** join/#oe CosmicPenguin (~nobody@soa.codeaurora.org) |
| 14:22.25 | RP__ | All the profiling says the patch I added should have improved things so I'm very confused. The baseline must have been bad or something else has crept in :/ |
| 14:27.45 | *** join/#oe aloril (~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) |
| 14:28.06 | woglinde | rp urgs |
| 14:28.27 | Tartarus | RP__: so, heh, the cache got bad somehow |
| 14:28.48 | Tartarus | RP__: I'd be a little concerned here since it was a brand new checkout and all that |
| 14:29.02 | Tartarus | (as in, total blank slate first time I ran bitbake there) |
| 14:29.15 | RP__ | Tartarus: I'm concerned but need more info :/ |
| 14:29.31 | Tartarus | I can give you a git hash |
| 14:29.48 | RP__ | Tartarus: That doesn't tell me much :/ |
| 14:30.01 | Tartarus | What do you need? |
| 14:30.10 | RP__ | Tartarus: A reproducer really :/ |
| 14:30.13 | Tartarus | heh |
| 14:30.22 | Tartarus | So I shouldn't have nuked the cache? :( |
| 14:30.41 | RP__ | Tartarus: it could have had some clues |
| 14:30.49 | Tartarus | Bah, damnit |
| 14:31.09 | RP__ | Tartarus: I still wondering if its something to do with git-native on that machine |
| 14:31.19 | RP__ | Tartarus: Have you tried another build? |
| 14:32.02 | Tartarus | RP__: kicking one now |
| 14:33.31 | pb_ | RP__: yeah, agreed, I have also noticed the build times are a bit variable. It is indeed rather hard to benchmark changes reliably, it'd be nice to figure out a way to fix that. |
| 14:34.54 | *** join/#oe morphis (~morphis@hfw-ext-wlan.rz.hs-bremen.de) |
| 14:35.08 | *** join/#oe morphis_ (~morphis@hfw-ext-wlan.rz.hs-bremen.de) |
| 14:36.01 | pb_ | hm, I'm still getting perl-native built as a dependency of pseudo. I had hoped that was going to go away with the chnages that just got landed. |
| 14:36.19 | *** join/#oe morphis (~morphis@hfw-ext-wlan.rz.hs-bremen.de) |
| 14:36.22 | RP__ | pb_: What version of tar is on your system? |
| 14:36.30 | pb_ | 1.23 |
| 14:36.42 | RP__ | pb_: thats why. Update it to 1.24 and it should stop doing that |
| 14:37.48 | pb_ | ah. why does an outdated tar cause perl-native to be needed? |
| 14:37.59 | pb_ | (and why do we need tar 1.24 specifically?) |
| 14:38.19 | RP__ | pb_: It builds tar-replacement-native and roughly that needs gettext which needs perl |
| 14:38.28 | pb_ | crumbs, it's also building curl-native and openssl-native now. I don't think that used to nappen. |
| 14:38.32 | pb_ | s/nappen/happen/ |
| 14:38.53 | RP__ | and we need tar 1.24 as versions 1.18-1.23 are broken and can't cope with our sstate tarballs containing symlinks |
| 14:38.55 | pb_ | oh, for git-native I suppose. |
| 14:39.01 | pb_ | ah, drat, build failed. |
| 14:39.08 | pb_ | | make[1]: /home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux/bin/perl: Command not found |
| 14:39.12 | pb_ | sux0r |
| 14:39.30 | RP__ | pb_: sstate packages from before? |
| 14:39.44 | pb_ | no, I nuked sstate_cache and tmp* |
| 14:40.14 | RP__ | wonders if the confllict was 100% resolved |
| 14:40.18 | *** join/#oe B_Lizzard (~havoc@athedsl-119394.home.otenet.gr) |
| 14:40.27 | pb_ | that was git-native's compile stage failing, fwiw |
| 14:41.06 | RP__ | wonders if he's screwed up resolving the merge conflict |
| 14:41.22 | pb_ | the perl that I have is in sysroots/x86_64-linux/bin/perl-native/perl |
| 14:41.31 | mgundes | Hi everybody, wow can I tell bitbake my application will be for host? by inheriting native class in bb file? |
| 14:41.52 | pb_ | which I guess is the right place, it seems that git is just looking for it in the wrong path |
| 14:41.54 | RP__ | pb_: what is it thats searching there? |
| 14:42.07 | pb_ | dunno, some crazy git thing |
| 14:42.10 | pb_ | | /home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux/bin/perl Makefile.PL PREFIX='/home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux' INSTALL_BASE='' |
| 14:42.11 | pb_ | | make[1]: /home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux/bin/perl: Command not found |
| 14:42.11 | pb_ | | make[1]: *** [perl.mak] Error 127 |
| 14:42.16 | pb_ | is a bit more of the context |
| 14:42.33 | RP__ | $ cat meta/recipes-devtools/git/git.inc | grep OECONF |
| 14:42.33 | RP__ | EXTRA_OECONF = "--with-perl=${STAGING_BINDIR_NATIVE}/perl-native/perl --without-tcltk" |
| 14:43.07 | RP__ | pb_: Can you confirm you have that? |
| 14:43.23 | *** join/#oe kgilmer (~kgilmer@ntngsk052174.ngsk.nt.ftth4.ppp.infoweb.ne.jp) |
| 14:44.27 | pb_ | ah, right, that's it |
| 14:44.42 | pb_ | I don't have that patch because I reverted to an older git to work around the earlier parse error |
| 14:44.50 | pb_ | and then I forgot to update git again once the perl thing was fixed |
| 14:45.53 | pb_ | let me try again then |
| 14:45.56 | RP__ | mgundes: likely, yes |
| 14:49.07 | *** join/#oe grund (~grund@66.43.64.66) |
| 14:52.26 | mgundes | RP__: thanks |
| 14:53.08 | *** join/#oe DHR (~hugh@CPE00606767ed59-CM000f9fa81660.cpe.net.cable.rogers.com) |
| 14:55.46 | pb_ | hm, do we actually need the perl bits enabled for git-native? |
| 14:56.20 | pb_ | gnu-config-native and automake-native are both using perl-native-runtime now, which seems like an improvement, but perl-native is still needed by git-native (which is getting dragged in by gettext for some obscure reason) |
| 15:01.43 | ant_work | marks the 3 LAKML threads about DTB appended to arm zImage for later reading |
| 15:04.35 | *** join/#oe incandescant (~joshual@c-24-21-159-20.hsd1.or.comcast.net) |
| 15:06.04 | *** join/#oe tasslehoff (~foo@145.79-161-31.customer.lyse.net) |
| 15:07.23 | tasslehoff | How much space does your TMPDIR's occupy? I'm installing dualboot and need to set aside enough space for OE. |
| 15:17.38 | *** join/#oe kevinsc (~a0214685@nat/ti/x-alqlrwcptsdwluib) |
| 15:22.26 | *** join/#oe zenlinux (~sgarman@c-76-115-40-57.hsd1.or.comcast.net) |
| 15:22.43 | pb_ | rather depends what you're building. mine seems to be 38G but that is with several kernel trees. |
| 15:25.10 | ant_work | pb_: yes, it depends on how many machines/ kernels too |
| 15:25.30 | tasslehoff | pb_: thanks. I'm gonna compile Angstrom 2010.x for a Beaglish board |
| 15:33.31 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
| 15:34.55 | *** join/#oe pespin (~pespin@90.163.82.81) |
| 15:36.28 | *** join/#oe rschus (~rschus@68.163.71.86.rev.sfr.net) |
| 15:38.15 | tasslehoff | running on a 64-bit, can I compile an SDK for a 32-bit? |
| 15:39.05 | tasslehoff | s/a //g |
| 15:40.14 | *** join/#oe kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 15:40.50 | *** part/#oe kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 15:42.25 | incandescant | tasslehoff: yes |
| 15:43.47 | incandescant | tasslehoff: SDKMACHINE, at least in oe-core |
| 15:45.16 | *** join/#oe tyco (~tyler@74.95.84.140) |
| 15:50.11 | tasslehoff | ah. cool |
| 15:54.16 | fray | who had editing permissions on the oe WIKI "Category:Policy" page? |
| 15:54.32 | fray | (I need to get an additional policy listed there) |
| 15:54.45 | fray | http://wiki.openembedded.org/index.php/Commit_Patch_Message -- TSC approved commit and patch message guidelines |
| 15:56.57 | pb_ | nobody, it seems |
| 15:57.05 | tyco | where does the base kernel source live in oe? |
| 15:57.22 | pb_ | I think RP has the privs in theory but last I heard he wasn't actually able to edit any pages |
| 15:57.23 | fray | heh.. I'll just have to ping someone later |
| 15:58.38 | khem | RP__: yes with matching quotes |
| 15:58.45 | khem | RP__: hmmm |
| 15:58.48 | tyco | i'm trying to figure out how to use my kernel with oe - it looks like i need to make a series of patches against some base? |
| 15:59.10 | fray | tyco, if you want to use the oe-core kernel(s) and integrate it in.. then yes.. |
| 15:59.13 | khem | tyco: its in workdir |
| 15:59.13 | *** join/#oe jconnolly (~jconnolly@66.43.64.66) |
| 15:59.23 | fray | it's based on configuration data and patches applied to the base.. |
| 15:59.26 | *** part/#oe jconnolly (~jconnolly@66.43.64.66) |
| 15:59.37 | fray | otherwise the shortcut is just to provide your own kernel sources as part of a new recipe |
| 16:00.01 | tyco | that sounds easier |
| 16:00.18 | tyco | thanks |
| 16:00.19 | fray | it's easier.. but if you want to support it longer term, the patch/meta approach is easier |
| 16:00.23 | fray | that only works with oe-core though.. |
| 16:00.38 | tyco | what is oe-core? |
| 16:00.40 | fray | (it's easier because you only manage the patches, not the whole kernel.. in my experience it's MUCH easier to update and keep things in sync) |
| 16:01.03 | fray | http://git.openembedded.org/cgit.cgi/openembedded-core/ |
| 16:01.14 | fray | this is the "future" of open embedded |
| 16:01.16 | tyco | right, if i want to keep with the current kernel version |
| 16:01.21 | fray | it's still work in progress though.. |
| 16:01.43 | khem | RP__: also try to add ${FEED_ARCH} to OVERRIDES |
| 16:01.50 | tyco | okay, i want a very simple system based on a ts7800 |
| 16:01.52 | fray | for kernel documentation on the oe-core kernel items and tooling: |
| 16:01.53 | fray | http://www.yoctoproject.org/documentation |
| 16:01.56 | khem | and see if you can reproduce it |
| 16:02.06 | fray | it's the BSP developers guide and Yocto Project Kernel Architecture and Use Manual |
| 16:02.08 | tyco | to replace the static debian distro that the manufacturer provides |
| 16:02.34 | *** join/#oe alan_o (~alan@c-68-62-240-236.hsd1.fl.comcast.net) |
| 16:02.43 | fray | tyco are you building product, or just hacking? if the later, then either will work for you |
| 16:02.44 | tyco | is oe-core worth using at this point? what kind of issues should i expect iwht it? |
| 16:02.54 | tyco | product |
| 16:03.10 | fray | if the former, the oe-core is what I would suggest -- unless your release date is within the next 6 months.. then you need to consider that it's still "in progress" development.. |
| 16:03.23 | tyco | okay, thanks |
| 16:03.33 | fray | right now we're expecting to stabilize it and do a more formal release in the roughly september/october time frame.. |
| 16:03.35 | *** join/#oe amarsman (~marsman@52488909.cm-4-1c.dynamic.ziggo.nl) |
| 16:03.46 | tyco | i really just want a simple build system to allow me to control the rootfs and strip it down |
| 16:03.47 | fray | (we're in the middle of a transition right now) |
| 16:03.56 | *** join/#oe amarsman (~marsman@52488909.cm-4-1c.dynamic.ziggo.nl) |
| 16:04.05 | tyco | i see, how different will it be to use? |
| 16:04.11 | fray | tyco, if you have the time, I'd suggest starting with the oe-core... just keep in mind it might not be what you need right now |
| 16:04.18 | fray | the bitbake items and such are all the same.. |
| 16:04.42 | fray | oe-core has fewer recipes then oe-dev... (many of these are available in a new meta-openembedded layer -- not not all.. |
| 16:05.04 | khem | tyco: you should use 2011.03 release branch to start off |
| 16:05.13 | tyco | i don't need much, no graphical util. just board support basically |
| 16:05.16 | khem | if you want a stable thing |
| 16:05.22 | tyco | okay, that's what i am on currently |
| 16:05.33 | fray | oe-core is changing things a bit that instead of having one large repository of build instructions/recipes.. it's a much smaller subset.. easier to get started with (IMHO).. then you can add "layers" to it in order to specify distribution specific items, BSPs, etc.. |
| 16:05.35 | khem | depending upon how much crapo'la you can take you might use dev branches |
| 16:05.39 | fray | yes, 2011.03 is the last stable release |
| 16:05.52 | fray | if you need stable, thats where you want to be.. |
| 16:05.59 | tyco | fray, that sounds sensible |
| 16:06.35 | fray | oe-core is expected to the basis of OpenEmbedded, Angstrom, Yocto, and other distributions moving forward... but as I said, we're still transitioning |
| 16:06.39 | khem | TS-7800 is arm9 cpu right ? |
| 16:06.48 | tyco | yes |
| 16:07.12 | fray | the 4.6.0 gcc in oe-core is still having teething issues on ARM.. if you do try oe-core, I'd suggest using the gcc 4.5.1 instead |
| 16:08.10 | tyco | looks like oe-core is moving fast, and there is only one branch. i think i will stick with the release for now |
| 16:08.40 | fray | thats very reasonable if you are working on product |
| 16:08.59 | tyco | sounds like a good direction for it to be moving though |
| 16:09.25 | fray | ya, a lot of the folks think so, which is why we're doing it.. |
| 16:09.25 | khem | tyco: but you might not have feroceon support in oe toolchains |
| 16:09.36 | khem | but soft-float should owrk keep that in mind |
| 16:10.40 | tyco | does it make sense to use the manuf.'s provided toolchain? |
| 16:10.54 | khem | since open protium also used to have orion board which having same core as yours and was supported by OE |
| 16:11.01 | khem | so I guess it should not be a problem |
| 16:11.20 | khem | you can plugin external toolchains |
| 16:11.35 | khem | someone I remember plugged in Marvell's toolchain few months back |
| 16:11.44 | khem | look into ml archive |
| 16:11.52 | tyco | okay |
| 16:12.12 | khem | heads off |
| 16:16.43 | *** join/#oe kevinsc (~a0214685@nat/ti/x-rbeoqnttdjlkqrbf) |
| 16:16.49 | *** join/#oe hollisb (~hollisb@24.20.193.174) |
| 16:21.28 | RP__ | khem: Anything putting "all" in overrides is doomed to cause problems |
| 16:21.57 | RP__ | pb_: git-native needs certain perl modules not installed as part of normal perl on most systems :( |
| 16:22.21 | pb_ | groan |
| 16:23.25 | pb_ | so we can't just configure it --without-perl, I guess? |
| 16:24.04 | fray | git is made up of perl scripts.. ;) so "no" |
| 16:24.20 | fray | (it has more then JUST perl scripts, but a lot of it is perl) |
| 16:24.39 | pb_ | well, right, I guess what I was asking was: do we need the perl bits for what we do with git-native? |
| 16:24.49 | fray | afaik, yes |
| 16:25.01 | pb_ | afaik, if you just want to clone and check out, you only need the core exe (which I think is non perl) |
| 16:25.13 | pb_ | but maybe we need git-native for more than that, I dunno |
| 16:26.06 | fray | the kernel tooling uses branch and some other specialty clone tooling.. |
| 16:26.56 | fray | ...but I'm looking, and the few items I thought were still perl don't seem to be in the latest version |
| 16:27.32 | fray | I just checked, no perl IS used heavily still |
| 16:29.44 | pb_ | which bits are still perl? |
| 16:30.20 | fray | the ones that absolutely are: |
| 16:30.26 | pb_ | I just looked in /usr/lib/git-core on my desktop and it seems that only git-add--interactive, git-difftool and git-relink are perl |
| 16:30.33 | pb_ | maybe there are some others hidden away that I didn't spot |
| 16:30.37 | *** join/#oe tasslehoff (~Tasslehof@145.79-161-31.customer.lyse.net) |
| 16:30.46 | *** part/#oe thhp (50c14443@gateway/web/freenode/ip.80.193.68.67) |
| 16:31.22 | fray | git-add--interactive, git-am, git-archimport, git-cvs*, git-difftool, git-instaweb, git-relink, git-send-email, git-svn, |
| 16:31.26 | tasslehoff | So I should be able to compile an SDK in 64-bit Ubuntu 11.04, that can be used in 32-bit Ubuntu 10.10? |
| 16:31.41 | fray | all of the binaries also show up if I do a grep perl on them -- but I'm not sure fi they use perl or not |
| 16:32.07 | fray | git-relink and git-difftool are both used in various standard tasks.. |
| 16:32.28 | fray | git-am and git-send-email are used in a few tasks as well, but likely could be ignored |
| 16:33.34 | pb_ | which standard tasks are those? I just did "grep -r git-relink oe-core" and didn't find any hits except the FILES in git.inc |
| 16:33.46 | pb_ | same with difftool |
| 16:34.25 | fray | my understanding is that relink is used by the cloning operation when specific options are selected.. these options are used by the kernel tooling in order to save space |
| 16:34.47 | fray | difftool, I believe is used in the merging tools.. (but I may be wrong there) |
| 16:35.36 | *** join/#oe easwar (~inpressi@unaffiliated/inpressi) |
| 16:36.49 | fray | I'm trying it quick to see if any of the items are needed |
| 16:37.01 | pb_ | thanks |
| 16:37.21 | pb_ | rp, can you comment on the kernel tooling thing? |
| 16:38.09 | fray | guy who knows the kernel tooling isn't here.. he's likely at lunch |
| 16:40.25 | fray | perl-native will still be needed though, even if git doesn't need it anymore |
| 16:40.57 | fray | perl-native is needed by other -native tools (gettext?) and it's also needed to be built if you will use perl on the target |
| 16:41.33 | pb_ | gettext doesn't seem to depend on perl-native directly, only via git-native |
| 16:42.09 | pb_ | gnu-config-native and automake-native are now using perl-native-runtime, and I think that should also be true for most of the other native tools |
| 16:43.29 | fray | whats the bitbake command to show me what required perl-native? since it's still being required |
| 16:43.45 | pb_ | I use bitbake -g and look at the .dot files |
| 16:43.56 | pb_ | there might be an incantation to get bitbake to tell you directly, but I don't know what it is |
| 16:44.04 | fray | thats what I was looking for |
| 16:44.11 | fray | there is also an external tool that will show you the stuf as well |
| 16:44.48 | pb_ | hm, rpm-native is still depending on perl-native as well. I thought we put a stop to that. |
| 16:45.08 | pb_ | that and git-native appear to be the only users of perl-native in my build, at least |
| 16:45.32 | otavio | What is the difference between meta-toolchain and meta-toolchain-sdk? |
| 16:46.06 | pb_ | oh, I bet rp's change to native class handling has defeated the DEPENDS thing in rpm.bb |
| 16:46.14 | fray | yes, I suspect it did |
| 16:48.16 | pb_ | so, anyway, if we could stop git-native needing perl (and fix rpm harder) then it looks like we could eliminate perl-native as a dependency for at least some images. no doubt there are still others that will go on needing it, of course. |
| 16:50.09 | incandescant | there was a change to make git use the host perl but on F15 stock perl is missing some bits required by git |
| 16:51.04 | fray | incandescant pb_'s question is.. do any of the perl components in git need to be there.. |
| 16:51.22 | fray | the answer is unclear to me this second.. I suspect some do, but I'm not sure |
| 16:51.45 | *** join/#oe HokieTux (~bhilburn@wireless-5192.wireless.ece.vt.edu) |
| 16:51.53 | Tartarus | It depends on how usable git-native needs to be |
| 16:52.02 | Tartarus | ie folks using sysroot/.../usr/bin/git |
| 16:52.41 | RP__ | It would be interesting to see which bits of git are affected |
| 16:53.10 | pb_ | RP__: fray had a list, see above |
| 16:53.21 | pb_ | possibly not a totally comprehensive list, but at least a place to start |
| 16:53.30 | Tartarus | RP__: I bet things like send-email need some amount of perl |
| 16:53.52 | pb_ | yeah. so the question is, do we care about having git-send-email work with git-native? |
| 16:54.00 | otavio | Tartarus: but those are used from the running system |
| 16:54.04 | RP__ | would say not |
| 16:54.11 | RP__ | I'd just check what the fetcher uses |
| 16:54.14 | pb_ | if there is a desire to have a git that is fully usable for random interactive hacking then I would think it probably belongs in some git-sdk kind of thing |
| 16:54.15 | otavio | Tartarus: or ought to be |
| 16:54.17 | kergoth | wonders if libgit2 has come along well enough yet to make a pygit2 fetcher viable |
| 16:54.21 | Tartarus | The high level question is, do we want people to use git-native when host git is old/incomplete/etc |
| 16:54.28 | fray | RP__ it's the kernel tooling I'm concerned about.. |
| 16:54.30 | Tartarus | Or just tell them to install a newer git |
| 16:54.33 | fray | the fetcher I believe is just clone |
| 16:54.49 | *** join/#oe risca (~risca@h241n2-n-a31.ias.bredband.telia.com) |
| 16:54.52 | *** join/#oe awozniak (~awozniak@76.205.222.174) |
| 16:55.03 | otavio | Tartarus: I'd say to ask to install a newer one |
| 16:55.05 | RP__ | fray: mostly now but not all (ls-remote at least) |
| 16:55.05 | *** join/#oe tharvey (~tharvey@adsl-76-205-222-174.dsl.snlo01.sbcglobal.net) |
| 16:55.14 | RP__ | fray: We probably need input from zedd |
| 16:55.18 | fray | yup |
| 16:55.30 | otavio | Tartarus: especially because OE will work fine with the old one, except the user won't be able to send fix |
| 16:55.41 | bluelightning | kergoth: "libgit2 uses waf as its buildsystem" aaargh run away |
| 16:55.44 | Tartarus | otavio: right, you can clone but contiributing is harder |
| 16:55.53 | otavio | Tartarus: in fact, depending on the format of the repo we might be depending on 1.6 already |
| 16:56.05 | otavio | Tartarus: or 1.4, don't recall |
| 16:56.27 | otavio | Tartarus: but OE works. That's what it matter. |
| 16:56.39 | otavio | Tartarus: as pb_ said, we can provide an git-sdk or whatever |
| 16:56.56 | otavio | Tartarus: or even git-native-sdk |
| 16:57.06 | Tartarus | Sure we can, I'm asking if we want to neuter git-native like that, or not |
| 16:57.14 | Tartarus | And be clear we're doing it |
| 16:57.21 | Tartarus | vs just assuming no one uses it today |
| 16:57.24 | Tartarus | People do |
| 16:57.26 | otavio | Tartarus: but I think if we can reduce the build-deps then better |
| 16:57.32 | otavio | Tartarus: it will be good for most people |
| 16:59.51 | otavio | And I am unsure many people will be using a too old git on the development machine |
| 17:00.21 | otavio | In fact, from the mails I see on mailing list most people use 1.7 or newer |
| 17:02.32 | Tartarus | How many of them are people using git-native? ;) |
| 17:02.41 | otavio | What is the difference between meta-toolchain and meta-toolchain-sdk? |
| 17:02.59 | otavio | Tartarus: I doubt many. I think most people uses distro tools for this |
| 17:03.19 | Crofton | pb_, thanks for fixing up the members list |
| 17:03.42 | pb_ | sure, no problem |
| 17:03.48 | pb_ | go home now |
| 17:03.49 | pb_ | later all |
| 17:06.16 | *** join/#oe mewyn (~mewyn@noise.slashnet.org) |
| 17:16.11 | *** join/#oe DHR (~hugh@CPE00606767ed59-CM000f9fa81660.cpe.net.cable.rogers.com) |
| 17:20.40 | khem | RP__: so thats the issue I think angstrom puts FEED_ARCH into overrides and FEED_ARCH = BASE_PACKAGE_ARCH which is set to "all" |
| 17:21.07 | khem | RP__: can we use allarch instead ? |
| 17:21.12 | fray | FYI,, git-native won't building without code patches -- if perl isn't available |
| 17:24.26 | *** join/#oe rje`cf (~rje@c-67-161-99-149.hsd1.wa.comcast.net) |
| 17:25.26 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 17:28.53 | RP__ | khem: allarch will work |
| 17:34.41 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 17:40.09 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 17:40.11 | bluelightning | otavio: FYI still working on these bbappends; got stuck on qt4-tools-nativesdk failing to build (for several reasons) |
| 17:40.49 | bluelightning | I don't even think nativesdk needs these flags but it does explicitly build src/sql |
| 17:44.16 | otavio | bluelightning: right |
| 17:44.20 | otavio | bluelightning: no problem |
| 17:44.42 | *** join/#oe kristoffer (~kristoffe@host-90-237-176-171.mobileonline.telia.com) |
| 17:52.26 | *** join/#oe stefan_schmidt (~stefan@p4FC76FEB.dip.t-dialin.net) |
| 17:52.44 | otavio | Is perl-native unbuildable for anyone else ? |
| 17:53.21 | kergoth | i think every single one of my builds is hosed right now, each for an entirely different reason |
| 17:53.27 | kergoth | thinks today is Monday again |
| 17:53.34 | khem | RP__: ok I have posted the patch for it here http://patches.openembedded.org/patch/5815/ |
| 17:53.42 | otavio | kergoth: good that I am not alone on that |
| 17:53.45 | khem | plz consider |
| 17:53.48 | mewyn | kergoth: That would be horrible. |
| 17:54.12 | khem | bitbake has gone a bit wonky I observe |
| 17:54.37 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 17:54.47 | otavio | khem: I've been using bitbake master without issues since some days |
| 17:55.02 | otavio | khem: but today's oe-core is unbuildable |
| 17:55.08 | khem | on one of my box I am getting this error I reported to bitbake-devel earlier |
| 17:55.14 | khem | intermittently |
| 17:55.20 | khem | I hate those kind of errors |
| 17:55.35 | khem | otavio: what error do u get |
| 17:55.36 | kergoth | getting an eglibc patch application failure on my oe-core angstrom build atm |
| 17:55.47 | khem | kergoth: hmm |
| 17:56.01 | khem | what changed |
| 17:56.16 | otavio | perl-native build failure |
| 17:56.31 | khem | checks how is his build going on |
| 17:57.17 | khem | hmm progressing steadily no hiccups |
| 17:57.31 | khem | you guys need to throw away your build boxes :) |
| 17:57.32 | kergoth | khem: when i hit that bitbake issue, i updated oe-core and it went away. seems like its metadata caused,s omehow |
| 17:57.34 | kergoth | which is worrisome |
| 17:57.38 | kergoth | dunno |
| 17:57.55 | khem | yeah I recloned bitbake |
| 17:57.59 | khem | and it went away for me |
| 17:58.13 | khem | may be some file permissions |
| 17:58.15 | khem | dunno |
| 17:58.21 | bluelightning | otavio: have you updated oe-core in the last couple of hours? a whole bunch of perl-native related fixes went in |
| 17:58.30 | khem | bitbake is one tool we need to make sure gets well tested |
| 17:58.33 | otavio | bluelightning: yes |
| 17:58.34 | khem | before patch is merged in |
| 17:58.42 | khem | it can create havocs |
| 17:58.46 | otavio | bluelightning: and those "fixes" broke my builds heheh |
| 17:59.06 | bluelightning | yes, if it makes any difference my existing builds were also broken |
| 17:59.19 | khem | bitbake patches should we sent to ml and let folks test them for a week or so before applying them I would say |
| 17:59.26 | otavio | bluelightning: hehe it's nice to share the pain heehhe |
| 17:59.56 | bluelightning | I've deleted tmp and started from scratch |
| 18:00.02 | otavio | bluelightning: I am doing it |
| 18:00.12 | otavio | bluelightning: in fact I have also removed sstate-cache |
| 18:00.23 | bluelightning | which is not great to have to do :/ but I'm in the middle of fixing this qt4 stuff |
| 18:00.53 | otavio | bluelightning: yes; qt4 is a nice thing to boost also because it has lacking behind oe-dev and oe-core |
| 18:01.54 | *** join/#oe timtimred (~meh@79-67-228-176.dynamic.dsl.as9105.com) |
| 18:02.14 | otavio | bluelightning: are you already bringing the qt4-native recipe at this moment ? |
| 18:02.23 | otavio | bluelightning: or left it to another set? |
| 18:02.42 | bluelightning | otavio: I've left that for a separate exercise |
| 18:06.31 | otavio | bluelightning: I am not depends on this yet so for me it is not (yet) urgent |
| 18:06.40 | otavio | bluelightning: rest of qt4 is indeed more important |
| 18:07.05 | otavio | bluelightning: specially because it will reduce the delta a lot (between oe-core and meta-oe) |
| 18:07.19 | bluelightning | otavio: right, the tidier these recipes are the better |
| 18:07.29 | otavio | bluelightning: indeed |
| 18:07.54 | otavio | bluelightning: i am working now at meta-toolchain that uses the qt4 recipes and so I ought to be putting fixes for those soon to |
| 18:08.15 | bluelightning | otavio: ok, great |
| 18:08.49 | bluelightning | otavio: btw I notice we have qt4-tools-sdk in meta-oe as well as qmake2 - do we need these? |
| 18:09.19 | bluelightning | qmake2 is not used AFAICT and qt4-tools-sdk should be obsoleted by qt4-tools-nativesdk (when the latter is building successfully that is) |
| 18:09.45 | otavio | bluelightning: I guess not; qmake2 will be built on qt4-tools |
| 18:09.57 | bluelightning | yes |
| 18:10.01 | otavio | bluelightning: and then it will turn into qt4-native later on |
| 18:10.47 | otavio | bluelightning: and the build time difference doesn't justify to split qmake from the rest. Specially because most packages that use qmake depends on qt4 anyway |
| 18:11.14 | bluelightning | otavio: ok, I will include separate patches to remove these from meta-oe then |
| 18:11.24 | bluelightning | leaves his builds running and heads home |
| 18:12.28 | *** join/#oe veganadian (~andrew@CPE0013f7b6cfd2-CM0013f7b6cfce.cpe.net.cable.rogers.com) |
| 18:22.51 | fray | anyone around yet that has the ability to edit the Policy listing on the OE wiki? |
| 18:23.04 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 18:23.54 | Jay7 | mm.. I have login but not sure about rights |
| 18:24.03 | Jay7 | what changes you need there? |
| 18:24.13 | fray | Need to get the new commit and patch guidelines linked there |
| 18:24.21 | fray | http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines |
| 18:24.37 | fray | but I don't have editing priveleges on Category:Policy |
| 18:24.49 | Jay7 | ah.. |
| 18:24.59 | Jay7 | well, khem or ka6sox-away may help iirc |
| 18:25.26 | fray | page was last edited in 2008 by Laibsch |
| 18:25.35 | fray | (when the contents were locked down) |
| 18:27.09 | otavio | Nos it fails with | /home/otavio/hacking/el/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.6.0/ld: cannot find -lm |
| 18:29.33 | Tartarus | cbrake: ping |
| 18:32.38 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 18:33.07 | otavio | khem: any idea about the gcc build failure? it is gcc-runtime that fails to build (4.6.0-r3) |
| 18:34.26 | *** join/#oe dos11 (~dos@aeby126.neoplus.adsl.tpnet.pl) |
| 18:34.35 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
| 18:34.41 | *** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl) |
| 18:37.03 | otavio | is reverting to previous oe-core checkout to get his work going |
| 18:38.46 | *** join/#oe WielkiTost (~dos@unaffiliated/dos1) |
| 18:39.39 | fray | ok.. the Command and Patch Message Guidelines are posted |
| 18:39.49 | fray | email coming out shortly... |
| 18:43.33 | *** join/#oe pepermint (~pepermint@host167-85-dynamic.8-87-r.retail.telecomitalia.it) |
| 18:43.35 | *** join/#oe holoturoide (~eder@189.85.128.10) |
| 18:43.46 | tzanger | hmm.. anyone here from Milan? I have a question about a local electronics supplier |
| 18:44.58 | tasslehoff | repeats himself |
| 18:45.00 | tasslehoff | So I should be able to compile an SDK in 64-bit Ubuntu 11.04, that can be used in 32-bit Ubuntu 10.10? |
| 18:47.40 | Tartarus | tasslehoff: in theory oe-core supports this, yes |
| 18:47.46 | Tartarus | Probably more than theory even |
| 18:48.46 | tasslehoff | Tartarus: hope so. and I have a feeling I soon need to find out what this oe-core is :) |
| 18:48.54 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 18:49.45 | sakoman | gm |
| 18:50.28 | sakoman | I tried using a fresh checkout of oe-core |
| 18:50.31 | *** join/#oe toi (~peter@94-226-63-5.access.telenet.be) |
| 18:50.39 | tasslehoff | found a post explaining it, but I'm unsure if it means that the stuff from oe-core is found in my org.openembedded.dev. |
| 18:50.42 | sakoman | (using the angstrom script) |
| 18:50.42 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 18:51.22 | sakoman | My first build attempt fails with: Pseudo is not present but is required, building this first before the main build |
| 18:51.29 | sakoman | and a return to the command prompt |
| 18:52.17 | sakoman | hard to believe I screwed up a 5 line process :-) |
| 18:52.27 | sakoman | has anyone else encountered this? |
| 18:53.30 | *** join/#oe rsalveti (~rsalveti@201.82.65.93) |
| 18:53.30 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
| 18:53.41 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 19:01.41 | otavio | For those having problem with oe-core builds, c3d317014f417ca895458b797afdf6c40e5b5a57 seems like a safe bed for now. |
| 19:04.48 | *** join/#oe rsalveti (~rsalveti@201.82.65.93) |
| 19:04.48 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
| 19:05.41 | khem | otavio: I guess you disabled libm in eglibc |
| 19:06.05 | otavio | khem: I didn't touch it |
| 19:06.13 | Tartarus | config knob unfun? |
| 19:06.13 | khem | otavio: What does your DISTRO_FEATURES look like |
| 19:06.19 | otavio | khem: it were building fine before |
| 19:06.20 | khem | Tartarus: yupp |
| 19:06.23 | otavio | khem: let me check |
| 19:06.28 | khem | otavio: yes I know |
| 19:06.45 | khem | otavio: distro's now need to select features |
| 19:06.50 | Tartarus | khem: So we failed to do this in a way that wouldn't horribly break folks or that's expected breakage that distros are going to need to recheck stuff? |
| 19:07.10 | khem | Tartarus: I would have expected to enable all features by default |
| 19:07.17 | khem | as folks have been doing that anyway |
| 19:07.28 | khem | but something might have slipped in |
| 19:07.33 | Tartarus | k |
| 19:07.33 | khem | we will find out |
| 19:08.00 | Tartarus | hands khem the asbestos pants |
| 19:08.01 | khem | sometimes you have DISTRO_FEATURES enabled and something might have been missing |
| 19:08.09 | khem | Tartarus: heh |
| 19:08.14 | khem | I am taking heat today |
| 19:08.41 | khem | out to lunch |
| 19:08.46 | otavio | khem: meta/conf/distro/ossystems-minimal.conf:DISTRO_FEATURES = "ipv4 ipv6 alsa pci largefile" |
| 19:09.09 | khem | you should prolly use += |
| 19:09.30 | otavio | khem: which one enables m? |
| 19:18.43 | *** join/#oe joelagnel (~joel@cpe-76-184-244-226.tx.res.rr.com) |
| 19:20.21 | *** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl) |
| 19:21.30 | pb_ | yeah, I got bitten by that missing libm thing as well |
| 19:21.42 | pb_ | it seems that if you define a custom DISTRO_FEATURES you need to make sure it includes DISTRO_LIBC_FEATURES. |
| 19:21.55 | pb_ | otherwise, you get everything switched off in eglibc, doh |
| 19:23.00 | cbrake | Tartarus: hello |
| 19:23.24 | Tartarus | cbrake: I see testing-next didn't happen last week. Going to this week tho, right? :) |
| 19:23.25 | pb_ | hi cbrake |
| 19:23.46 | cbrake | pb_: Hi Phil |
| 19:24.09 | cbrake | Tartarus: :-) yeah, we need to come up with a testing plan again, or just leave it up to Yocto |
| 19:24.26 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 19:24.28 | Tartarus | Yeah, there's that too |
| 19:24.32 | Tartarus | and what to do about reporting |
| 19:24.45 | Tartarus | I've been doing the same matrix as before and keeping an eye out for new breakage I can fix |
| 19:24.54 | Tartarus | (and I need to find the time to migrate that stuff to handle oe-core too) |
| 19:25.13 | cbrake | Tartarus: do you think oe-core is ready for a matrix of tests? |
| 19:25.33 | cbrake | Tartarus: or should we continue to focus on openembedded? |
| 19:25.38 | Tartarus | 'a'? Sure, same as the old one? no |
| 19:25.47 | Tartarus | I think we need to get to focusing on oe-core |
| 19:25.59 | Tartarus | and distro folks that haven't already need to start their distro layer |
| 19:26.11 | Tartarus | (and that means "distro-less" testing as part of the matrix) |
| 19:26.15 | cbrake | Tartarus: that is my thought (focus on oe-core) |
| 19:26.21 | ka6sox-away | khem and I have already got a test setup for oe-core that builds it in 22hrs |
| 19:26.34 | ka6sox-away | and can regress it constantly |
| 19:26.39 | Tartarus | ka6sox-away: Can you shoot that my way please? |
| 19:26.48 | Tartarus | or wiki it :) |
| 19:26.53 | ka6sox-away | I'll let khem shoot that your way. |
| 19:27.03 | ka6sox-away | he has the scripts he used. |
| 19:27.07 | cbrake | khem: copy me as well |
| 19:27.35 | ka6sox-away | but we use an SSD to make that happen in 22hrs |
| 19:27.54 | Tartarus | Yeah, we'll see what the setup here takes |
| 19:28.06 | Tartarus | shouldn't be an issue |
| 19:28.09 | cbrake | thoughts on if its worth trying to get multiple users involved in a testing effort again? |
| 19:28.51 | cbrake | it seems like we found a fair number of issues with the testing effort in the past (various workstation distros, etc) |
| 19:29.05 | Tartarus | yeah, we need to make it easy for folks to test stuff too |
| 19:29.12 | Tartarus | on whatever set of layers they're using |
| 19:29.36 | cbrake | Tartarus: what are you using for project setup for oe-core + layers? |
| 19:29.45 | ka6sox-away | if we are already testing the 5 arches of oe-core what else would you want to test? meta-oe? |
| 19:30.05 | Tartarus | ka6sox-away: yes, meta-oe + various distros |
| 19:30.06 | cbrake | ka6sox-away: whatever is needed to provide the components that people need |
| 19:30.13 | Tartarus | Or at least someone wants to be :) |
| 19:30.25 | Tartarus | cbrake: We're still playing around |
| 19:30.35 | Jay7 | may setup nightly builds |
| 19:30.47 | Tartarus | I've been using koen's setup-scripts repo, kergoth has something based on that iirc, but a bit different |
| 19:30.49 | cbrake | Tartarus: I'm still using git submodules, but most people don't like that mechanism as well as I do |
| 19:30.54 | Jay7 | but it should complete in 8 hrs |
| 19:31.39 | cbrake | Tartarus: for tested branches, git submodules would be nice as it could pull a known set of modules locked down to specific has versions |
| 19:31.43 | Tartarus | cbrake: I don't think anyone likes using anything 'raw' |
| 19:32.21 | ka6sox-away | I was hoping to make buildbot take unsolicited reports but after creating an event handler that only reports success/failure + log for a package of the build. |
| 19:32.45 | ka6sox-away | so instead of every step..every package of a full build. |
| 19:32.58 | cbrake | ka6sox-away: that sounds ideal |
| 19:36.14 | *** join/#oe rob_w (~bob@ppp-188-174-16-158.dynamic.mnet-online.de) |
| 19:39.25 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 19:42.13 | *** join/#oe bluelightning (~paul@cpc9-lewi14-2-0-cust183.2-4.cable.virginmedia.com) |
| 19:42.13 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:48.38 | *** join/#oe toi (~peter@94-226-63-5.access.telenet.be) |
| 19:52.43 | *** join/#oe tmbinc (abcd@83.141.3.59) |
| 19:59.41 | CIA-8 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r6d7afa5200 10openembedded.git/recipes/x-load/x-load_git.bb: |
| 19:59.41 | CIA-8 | x-load git: 1.5.0 sorts lower than 1.44ss, so bump PE |
| 19:59.41 | CIA-8 | Signed-off-by: Koen Kooi <koen@openembedded.org> |
| 20:05.43 | kergoth | cbrake: i use submodules too, works well enough |
| 20:06.04 | fray | the problem with submodules is the maintenance of the tags.. they are a good way to put together non-changing content.. |
| 20:06.25 | fray | but as things evolve, you have to maintain the submodule ids... and that has proven difficult for people |
| 20:06.35 | kergoth | as long as its convenient to update i don't see an issue. the user can always pull it down and update them |
| 20:06.37 | fray | it's much easier to just pull from a branch from various repos |
| 20:06.39 | *** join/#oe HokieTux (~bhilburn@wireless-5192.wireless.ece.vt.edu) |
| 20:06.56 | kergoth | git submodule foreach git checkout master; git submodule foreach git pull |
| 20:07.02 | fray | if subgits could say "I want this branch" instead of "this commit".. it would be a whole hell of a lot better IMHO |
| 20:07.21 | fray | 'er.. submodules, not subgits |
| 20:07.33 | kergoth | 'repo' used to do just that, and they ended up changing their minds, now it'll be based on submodules |
| 20:07.37 | kergoth | heh |
| 20:11.33 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 20:12.16 | cbrake | kergoth: is repo moving to submodules? |
| 20:12.46 | kergoth | last i read it was going to in the long term, but i don't monitor its development that closely |
| 20:21.18 | *** join/#oe nschle85 (~kvirc@89.204.137.141) |
| 20:22.09 | nschle85 | hello, i have a vala problem, during build of shr image: /home/nschle85/shr-build/shr-unstable/tmp/sysroots/x86_64-linux/usr/bin/valac -C --basedir .. --vapidir ../data --vapidir ../vapi --pkg glib-2.0 --pkg gio-2.0 --pkg libgisi --pkg posix --pkg posix-ext --header gisicomm.h --library gisicomm-0.0 gisicomm.vala |
| 20:22.09 | nschle85 | | posix-ext.vapi:7.5-7.30: error: `Posix' already contains a definition for `INET_ADDRSTRLEN' |
| 20:22.09 | nschle85 | | const int INET_ADDRSTRLEN; |
| 20:22.35 | nschle85 | can anybody help ? |
| 20:22.45 | woglinde | wait for mickeyl |
| 20:23.33 | woglinde | but that can last a while |
| 20:24.13 | nschle85 | woglinde: who else may help ? |
| 20:24.53 | *** join/#oe cpo (~cpo@194.145.151.17) |
| 20:25.32 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 20:31.12 | *** join/#oe pespin_ (~pespin@90.163.82.81) |
| 20:32.01 | *** join/#oe mikey_w (~mike@pool-74-110-218-2.rcmdva.fios.verizon.net) |
| 20:32.49 | tyco | ls |
| 20:32.56 | tyco | whops |
| 20:40.36 | *** join/#oe kristoffer (~kristoffe@host-90-237-134-134.mobileonline.telia.com) |
| 20:41.06 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 20:43.50 | *** join/#oe flo_lap (~fuchs@sign-4d0942f5.pool.mediaWays.net) |
| 20:43.50 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 20:52.07 | *** part/#oe easwar (~inpressi@unaffiliated/inpressi) |
| 20:56.07 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 20:57.12 | khem | cbrake: my setup is using angstrom top of oe-core right now |
| 21:01.07 | cbrake | khem: ok, thanks |
| 21:02.29 | *** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) |
| 21:07.56 | *** join/#oe ant__ (~andrea@host9-105-dynamic.50-82-r.retail.telecomitalia.it) |
| 21:10.10 | *** join/#oe rob_w (~bob@ppp-188-174-16-158.dynamic.mnet-online.de) |
| 21:12.15 | *** join/#oe woglinde_ (~heinold@f052228164.adsl.alicedsl.de) |
| 21:15.41 | *** join/#oe anarsoul (~anarsoul@46.28.99.145) |
| 21:18.35 | *** join/#oe zenlinux_laptop (~sgarman@masterfoo.zenlinux.com) |
| 21:42.21 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 21:42.53 | *** join/#oe rcf (~rcf@42.210-243-81.adsl-dyn.isp.belgacom.be) |
| 21:43.23 | *** join/#oe pb_ (~pb@mail.pbcl.net) |
| 21:55.59 | CIA-8 | 03Stanislav Brabec <utx@penguin.cz> 07master * rf8a2cccaca 10openembedded.git/recipes/navit/navit_svn.bb: |
| 21:55.59 | CIA-8 | navit: Update to SVN version 4530. |
| 21:55.59 | CIA-8 | Signed-off-by: Stanislav Brabec <utx@penguin.cz> |
| 21:57.15 | Jay7 | ~lart citrix for binary client blob |
| 21:57.15 | ibot | plops citrix into a giant vat of herring for binary client blob |
| 21:57.35 | *** join/#oe unsolo (~unsolo@146.80-203-33.nextgentel.com) |
| 21:58.28 | CIA-8 | 03Stanislav Brabec <utx@penguin.cz> 07master * rea92543e4b 10openembedded.git/recipes/epos/ (3 files in 2 dirs): |
| 21:58.28 | CIA-8 | epos: New recipe for new package (text-to-speech). |
| 21:58.28 | CIA-8 | Signed-off-by: Stanislav Brabec <utx@penguin.cz> |
| 22:00.36 | CIA-8 | 03Tom Rini <tom_rini@mentor.com> 07master * r3c2fb5ab3c 10openembedded.git/recipes/lttng/ust_0.8.bb: |
| 22:00.36 | CIA-8 | ust: Drop 0.8 |
| 22:00.36 | CIA-8 | This is unpinned and has problems on certain architectures. |
| 22:00.36 | CIA-8 | Signed-off-by: Tom Rini <tom_rini@mentor.com> |
| 22:00.46 | CIA-8 | 03Tom Rini <tom_rini@mentor.com> 07master * r2a430776fe 10openembedded.git/recipes/lttng/ (ust.inc ust/ustd.init): |
| 22:00.46 | CIA-8 | ust.inc: Fix ustd.init for 0.12 |
| 22:00.46 | CIA-8 | With 0.12, how ust daemon needs to be started changed, update the initscript |
| 22:00.46 | CIA-8 | for it. (While in here, Tom dropped S assignment from ust.inc). |
| 22:00.46 | CIA-8 | Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> |
| 22:00.46 | CIA-8 | Signed-off-by: Tom Rini <tom_rini@mentor.com> |
| 22:04.04 | *** join/#oe lamawithonel (~lucas@pool-173-66-110-102.washdc.fios.verizon.net) |
| 22:05.12 | Jay7 | hm.. seems mentor.com have lot of russian employees ;) |
| 22:08.11 | *** join/#oe lamawithonel (~lucas@pool-173-66-110-102.washdc.fios.verizon.net) |
| 22:35.34 | mickey|daddy | woglinde_: hmm, sound like libgisi should be bumped in OE |
| 22:35.45 | mickey|daddy | i'll take a look tomorrow |
| 22:41.53 | woglinde_ | he mickeyl |
| 22:41.55 | woglinde_ | grats |
| 22:41.56 | woglinde_ | *g* |
| 22:42.01 | woglinde_ | and welcome to the club |
| 22:43.48 | kgilmer | yeah mickey|daddy, congrats! |
| 22:46.40 | *** join/#oe pepermint (~pepermint@host78-12-dynamic.58-82-r.retail.telecomitalia.it) |
| 23:24.09 | CIA-8 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r8a987fbee5 10openembedded.git/recipes/klibc/ (20 files in 2 dirs): |
| 23:24.09 | CIA-8 | klibc: move to 1.5.23 |
| 23:24.09 | CIA-8 | * retain compatibilty patches for older kernels |
| 23:24.09 | CIA-8 | Signed-off-by: Andrea Adami <andrea.adami@gmail.com> |
| 23:28.12 | *** join/#oe ensc_ (~irc-ensc@p5DF2F5F5.dip.t-dialin.net) |
| 23:28.36 | *** join/#oe msm1 (~msm@192.88.168.35) |
| 23:54.43 | *** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net) |
| 23:58.27 | *** join/#oe msm1 (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net) |