00:01.10 | khem | fray: you should have a new email with temp passwd |
00:01.46 | Jay7 | like to see CPU load graph of oe-core |
00:02.18 | fray | thanks.. :P this time I'll click on the RIGHT one! |
00:02.20 | Jay7 | almost always all cores are loaded > 90% |
00:02.30 | khem | fray: rpmbuild --nodeps --short-circuit --target armv5te-poky-linux-gnu |
00:02.34 | fray | Jay7 -- there is a bootchart like module in there so you can see.. |
00:02.44 | khem | should that be gnueabi ? |
00:02.44 | fray | khem is that what is failing? |
00:03.00 | Jay7 | but overall speed seems a bit slower that OE's one |
00:03.01 | fray | khem, it should be.. but practically speaking RPM doesn't care.. |
00:03.04 | khem | fray: thats what I am seeing on meta/recipes-core/util-linux/util-linux_2.17.2.bb |
00:03.07 | fray | (yes I'll fix it once I get working) |
00:03.09 | Jay7 | ERROR: Function 'do_configure' failed (see /storage/oe/oe-core/oe-core/build/tmp/work/x86_64-linux/qemu-native-0.13.0-r1/temp/log.do_configure.10294 for further information) |
00:03.10 | khem | ok |
00:03.13 | Jay7 | hehe |
00:03.25 | Jay7 | | + echo 'You need libGL.so and libGLU.so to exist in your library path and the development headers for SDL installed to build qemu-native. |
00:03.59 | khem | fray: ERROR: Function 'BUILDSPEC' failed (see /scratch/oe-core/work/armv5te-poky-linux-gnueabi/util-linux-2.17.2-r5/temp/log.do_package_write_rpm.16668 for further information) |
00:04.02 | khem | NOTE: package util-linux-2.17.2-r5: task do_package_write_rpm: Failed |
00:04.04 | khem | thats what I am seeing |
00:04.11 | khem | so its something rpm related |
00:04.54 | fray | there we go, I'm confirmed now |
00:05.20 | khem | <PROTECTED> |
00:05.26 | fray | ouch |
00:05.41 | khem | so it seems rpmbuild is going for a ride |
00:05.48 | fray | is that from log.do_package_write_rpm.16668 ? |
00:05.53 | khem | yes |
00:06.09 | fray | what host are you running? (I'm having other problems, but not that) |
00:06.25 | khem | http://paste.ubuntu.com/574731/ |
00:06.29 | khem | full log |
00:06.44 | khem | I am on ubuntu 11.04/64bit |
00:06.54 | khem | well its an alpha of 11.04 |
00:07.08 | khem | but fairly good |
00:07.23 | fray | that really makes me wonder if it's pseudo |
00:07.25 | Jay7 | fray: do oe-core's qemu-native really require SDL? |
00:07.34 | fray | Jay7, ya.. :| |
00:07.38 | khem | Jay7: its meant to run into GUI |
00:07.39 | Jay7 | omg... |
00:07.42 | fray | I have a local patch that I use to avoid that |
00:07.48 | fray | let me point you at it |
00:07.57 | khem | Jay7: it has to if you need to boot into some sort of GUI |
00:07.58 | Jay7 | qemu have vnc :) |
00:08.07 | khem | and it does have sdl too |
00:08.10 | Jay7 | and I have host's qemu :) |
00:08.26 | khem | ok then you can add it to assume-provided |
00:08.43 | fray | there are optimization in here to speed up GL processing.. thats why the SDL is used |
00:08.45 | khem | but dont bugger the ml or channel if you have problem with host qemu :0 |
00:08.48 | khem | :) |
00:08.48 | Jay7 | problem is that I'm building inside container |
00:09.01 | fray | http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/qemu&id=c061e59911328046e845c4f1b040735832d92d15 |
00:09.02 | *** join/#oe GNUtoo|oeee (~GNUtoo@host157-58-dynamic.116-80-r.retail.telecomitalia.it) |
00:09.18 | fray | take a look at that.. I have to hack it because my host systems libGL is busted.. (welcome to nvidia proprietary drivers!) |
00:09.42 | khem | arm mali will kick their ass soon |
00:09.53 | GNUtoo|oeee | ah? |
00:10.15 | GNUtoo|oeee | do we have some free drivers apart the s3c6xxx reverse engineered ones? |
00:10.26 | khem | GNUtoo|oeee: for mali ? |
00:10.32 | GNUtoo|oeee | for whatever |
00:10.43 | khem | not yet but ARM guys says they have no issues |
00:10.46 | fray | http://wiki.openembedded.org/index.php/Category:Dev how do I add an OpenEmbedded-Core to the "dev" category items? |
00:10.48 | GNUtoo|oeee | wow |
00:10.50 | GNUtoo|oeee | ok |
00:10.54 | khem | they just want to sell their hardware I guess |
00:11.08 | GNUtoo|oeee | so maly will be able to go upstream? |
00:11.14 | GNUtoo|oeee | *mali |
00:11.18 | khem | maybe I dont know |
00:11.31 | fray | the biggest problem I see these days with drivers is Imagination Technology.. they are very much anti-open source due to IP licensing of their PowerVR cores.. |
00:11.55 | GNUtoo|oeee | because non-free drivers aren't able to have the kernel part upstreamed even if that part is free |
00:12.03 | GNUtoo|oeee | indeed |
00:12.06 | fray | other then that, most of the other drivers I see these days are just nasty in their coding, but little is stopping them from being released |
00:12.11 | khem | yeah powerVR is what most socs have |
00:12.22 | GNUtoo|oeee | basically I eared that it was because of patents |
00:12.36 | GNUtoo|oeee | for powervr |
00:12.55 | fray | the problem with "patents" (in any graphics driver) is there are so many people are worried that releasing the source will show a competitor a patent is being used and trigger a lawsuit |
00:13.23 | fray | (thats what was explained to me by someone) I'm not sure that holds much water.. if a competitor thought there was a patent issue, I don't think source availability would matter.. |
00:13.32 | GNUtoo|oeee | I wonder what costs more between no mainline and patents |
00:13.35 | khem | tries ulimit -c unlimited |
00:13.47 | fray | costs my and my customers more due to the no mainline! |
00:14.01 | khem | *** glibc detected *** /scratch/oe-core/sysroots/x86_64-linux/usr/bin/rpmbuild.real: corrupted double-linked list: 0x0000000000d62050 *** |
00:14.05 | fray | khem, if you can tell me where it blew up, that might give me a clue as to what to suggest.. |
00:14.43 | GNUtoo|oeee | didn't migrate to oe-core yet |
00:14.54 | khem | fray: http://pastey.net/146708 |
00:15.03 | fray | khem, we're currently chasing a problem with zypper -- but we're nto aware (in yocto) of any issues with RPM itself.. |
00:16.01 | fray | if the call to mireClean is what I think it might be.. it looks like something went wrong with teh system configuration.. |
00:16.12 | fray | can you look in the rpm-native directory and see if it detected pcre? |
00:16.30 | khem | could be since I hand linked one binary |
00:16.34 | khem | which was failing for me |
00:16.51 | khem | but all I did was added two libraries to link line which libtool was not detecting |
00:16.55 | fray | there is a mismatch between the system regex.h and the one from pcre.. if the wrong regex is used you get a crash similar to this.. (we think -- based on zypper usage) |
00:17.54 | fray | khem, I'd really like to know how the libtool failed on your machine.. I'm trying to reproduce it here.. but so far not having a lot of success.. |
00:18.15 | fray | (and apparently the speed of my network just went to crap too which isn't helping) |
00:18.36 | khem | fray: here is config.log of rpm-native http://paste.ubuntu.com/574736/ |
00:18.43 | khem | it seems to find pcre ok |
00:19.34 | fray | ya pcre looks fine |
00:20.39 | fray | I see no obvious issues with beecrypt configuration either |
00:20.54 | khem | yeah may be it just needs a reboot |
00:21.01 | khem | should go back to slackware |
00:21.19 | khem | freaking ubuntu |
00:21.22 | khem | its for humans |
00:21.25 | fray | sorry, I really don't know.. I don't appear to have any way to debug it right now |
00:22.22 | fray | the biggest problem is parts of rpm are still needed even if you disable rpm package generation.. (it's used for dependency scanning as well) |
00:24.52 | khem | hmmm do any yocto people use any other host besides fedora or redhat |
00:25.07 | fray | lots of folks use ubuntu |
00:25.14 | khem | k |
00:25.51 | Jay7 | looks like I'm only using debian :) |
00:26.12 | khem | which is ok if someone has it working on ubuntu you should be ok |
00:26.29 | fray | I'm not sure if anyone is using debian other then you.. (I have coworkers that do, but they're not using poky/yocto stuff) |
00:27.56 | khem | ../beecrypt/.libs/libbeecrypt.la ../syck/lib/.libs/libsyck.la |
00:28.25 | khem | these were two I had to add when linking mtree while building rpm-native |
00:29.02 | fray | that seems really strange to me.. it should have picked up ../beecrypt/libbeecrypt.la and ../syck/lib/libsyck.la |
00:29.09 | khem | yep |
00:29.11 | fray | something odd seems to be happening in the libtool |
00:29.14 | khem | and its reproducable |
00:29.21 | fray | what version of libtool is it using? |
00:29.29 | fray | (a built version or the host system version?) |
00:29.49 | khem | oh libtool is from what we build |
00:29.57 | khem | from libtool-native |
00:30.05 | khem | it does not use host libtool at all |
00:30.08 | fray | well, thats what I had expected.. libtool-native -- I wodner if somethign went wrong there |
00:30.29 | fray | (or if there is something there that is not compatible with that version of ubuntu) |
00:31.13 | khem | I will see if I find some time should be findable |
00:31.38 | fray | is just annoyed he can't even get enough to build to get far enough to reproduce it or fail.. |
00:32.00 | fray | the linux-libc-headers keeps failing on me with no real error messages other then exit code 1 |
00:32.59 | *** join/#oe kevinsc (~a0214685@nat/ti/x-rbxtpwdwvqeldlpe) |
00:36.41 | khem | fray: use latest bitbake from today |
00:37.22 | fray | khem, says I'm up to date |
00:37.29 | fray | commit 36fe59ce314c295d239b76de34c8714def2c32d5 |
00:37.29 | fray | Author: Khem Raj <raj.khem@gmail.com> |
00:37.29 | fray | Date: Wed Mar 2 08:33:49 2011 +0000 |
00:37.31 | fray | thats my top commit |
00:38.26 | khem | hmmm ok |
00:38.47 | khem | there was one utils.py patch that was relevant but it should be in there |
00:39.59 | khem | nukes the tmpdir and restarts reboot did not help |
00:44.46 | Jay7 | sleep |
00:45.18 | ka6sox | nn Jay7 |
00:52.42 | *** join/#oe Philippe_ (~Philippe@a83-245-252-47.elisa-laajakaista.fi) |
01:19.07 | *** join/#oe bluelightning (~paul@cpc9-lewi14-2-0-cust183.2-4.cable.virginmedia.com) |
01:19.07 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
01:43.23 | *** join/#oe Gaston|Home (Gaston@ua-83-227-239-139.cust.bredbandsbolaget.se) |
01:43.23 | *** join/#oe anarsoul (~anarsoul@80.249.93.12) |
01:43.23 | *** join/#oe mrc3_ (~mrc3@nat/ti/x-dfahkidezirrzlbx) |
01:43.23 | *** join/#oe pingswept_ (~pingswept@209-6-42-115.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) |
01:43.23 | *** join/#oe mckoan|away (~marco@unaffiliated/mckoan) |
01:44.50 | *** join/#oe blindvt (~brf@85-127-87-224.dynamic.xdsl-line.inode.at) |
01:51.09 | *** join/#oe Gaston|Home (Gaston@ua-83-227-239-139.cust.bredbandsbolaget.se) |
01:51.09 | *** join/#oe anarsoul (~anarsoul@80.249.93.12) |
01:51.09 | *** join/#oe mrc3_ (~mrc3@nat/ti/x-dfahkidezirrzlbx) |
01:51.09 | *** join/#oe pingswept_ (~pingswept@209-6-42-115.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) |
01:51.09 | *** join/#oe mckoan|away (~marco@unaffiliated/mckoan) |
03:04.24 | *** join/#oe fraxinath (~quassel@pD95360BE.dip.t-dialin.net) |
03:04.40 | *** join/#oe ChrisD1 (~ChrisD@dsl-217-155-59-204.zen.co.uk) |
03:10.52 | *** join/#oe mrj10 (~mrj10@63.252.64.254) |
03:23.48 | *** join/#oe _julian (~quassel@hmbg-4d069de6.pool.mediaWays.net) |
03:39.17 | *** join/#oe shoragan_____ (~shoragan@sicherheitsschwankung.de) |
03:42.22 | *** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |
03:44.38 | *** join/#oe shoragan_____ (~shoragan@sicherheitsschwankung.de) |
03:46.14 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
03:47.44 | *** join/#oe lamawithonel (~lucas@173-101-176-25.pools.spcsdns.net) |
03:50.09 | *** join/#oe shoragan_____ (~shoragan@sicherheitsschwankung.de) |
04:01.08 | *** join/#oe mrc3 (~ddiaz@189.157.107.208) |
04:16.25 | *** join/#oe kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
04:21.22 | *** join/#oe nitink (~nitink@192.55.55.37) |
04:30.42 | *** join/#oe nitink (~nitink@192.55.55.39) |
04:32.21 | *** part/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
04:43.17 | *** join/#oe rsalveti (~rsalveti@201.82.69.7) |
04:53.24 | *** join/#oe mario-go` (~user@67.205.85.241) |
05:05.16 | *** join/#oe tmbinc (abcd@83.141.3.59) |
05:11.02 | *** join/#oe cdbot2_ (~cdbot2@hentges.net) |
05:16.53 | *** join/#oe Gin-geR (~hacker@g230197205.adsl.alicedsl.de) |
05:22.32 | *** join/#oe dth_ntb (~dth@a89-183-199-187.net-htp.de) |
05:30.17 | *** join/#oe woglinde (~woglinde@89.204.153.177) |
05:41.11 | *** join/#oe henning_ (henning@familie-heinold.de) |
05:44.32 | *** join/#oe woglinde (henning@familie-heinold.de) |
06:00.57 | *** join/#oe jedahan (~jedahan@cpe-24-193-90-69.nyc.res.rr.com) |
06:00.57 | *** join/#oe jedahan (~jedahan@subtle/user/jedahan) |
06:13.49 | *** join/#oe vanous (~vanous@194.228.223.3) |
06:59.20 | *** join/#oe rob_w (~bob@ppp-93-104-186-72.dynamic.mnet-online.de) |
06:59.23 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
07:05.52 | *** join/#oe anr78 (~Mich@145.79-161-31.customer.lyse.net) |
07:10.35 | *** join/#oe amarsman_nl (~marsman@89.184.175.76) |
07:14.50 | *** join/#oe khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net) |
07:23.54 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r6536f01865 10openembedded.git/conf/ (5 files in 2 dirs): |
07:23.54 | CIA-47 | sane-toolchain-*: define DEBUG_FLAGS and add it to FULL_OPTIMIZATION to make -dbg packages more usefull |
07:23.54 | CIA-47 | Acked-by: Tom Rini <tom_rini@mentor.com> |
07:23.54 | CIA-47 | Acked-by: Khem Raj <raj.khem@gmail.com> |
07:23.54 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
07:24.56 | *** join/#oe NightMonkey (debian-tor@pdpc/supporter/professional/nightmonkey) |
07:30.25 | *** join/#oe vitus (~vitus@145.253.169.210) |
07:49.47 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
07:53.21 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
08:01.47 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
08:19.44 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
08:21.01 | *** join/#oe dth_ntb (~dth@a89-182-5-66.net-htp.de) |
08:21.05 | *** part/#oe dth_ntb (~dth@a89-182-5-66.net-htp.de) |
08:22.13 | *** join/#oe Matt0 (~matt@11.184-95-109.netnet.net) |
08:24.14 | *** join/#oe Jefro (~josiermi@134.134.137.71) |
08:24.19 | *** join/#oe B_Lizzard (~havoc@athedsl-119969.home.otenet.gr) |
08:27.28 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
08:37.39 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
08:53.30 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
08:56.56 | *** join/#oe pespin (~pespin@cisne-cn07.upc.es) |
09:01.31 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
09:06.11 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
09:19.06 | *** join/#oe bluelightning (~paul@83.217.123.106) |
09:19.06 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
09:20.35 | bluelightning | morning all |
09:21.19 | *** part/#oe mrj10 (~mrj10@63.252.64.254) |
09:21.47 | bluelightning | am writing a comprehensive response to the top comment on http://lwn.net/Articles/430614/ |
09:24.35 | Jay7 | seems man tried OE and was very frustrated because this is not what he wants.. |
09:25.59 | Jay7 | heh.. nice collection of wrong opinions |
09:54.53 | *** join/#oe ibot (~ibot@rikers.org) |
09:54.53 | *** 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 |
09:57.15 | *** join/#oe vitus (~vitus@145.253.169.210) |
10:10.28 | *** join/#oe obi (~obi@unaffiliated/obi) |
10:16.04 | ericben | good morning |
10:16.20 | mckoan | ericben: hi |
10:16.50 | ericben | hi mckoan |
10:17.19 | ericben | lwn comments are funny. I saw the same kind of coments last week on a new on a french site annoucing buidlroot |
10:18.39 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
10:18.49 | pb_ | mickey|office: good morning |
10:19.22 | ericben | what makes the difference is the "hmi" with make menuconfig which make people believe they have control over what they are doing :-) |
10:20.08 | *** join/#oe mr_nice|work (~mr_nice|w@83-64-51-210.static.xdsl-line.inode.at) |
10:20.37 | ericben | khem: patchwork still doesn't take my patches. http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-March/030613.html is not present in patchwork |
10:21.27 | mckoan | ericben: the problem is that nobody tries to understand the feelings of a people trying OE for the first time |
10:22.01 | mckoan | ericben: I still remember it: frustration (more than with other tools) |
10:22.49 | pb_ | I don't think it's true that nobody tries to understand their feelings. It is true that nobody is doing much to improve their experience but this is at least partly because it is quite a hard problem to solve. |
10:22.50 | mckoan | ericben: and I know a lot of people who dropper OE after a few time because of these 'usual' problems |
10:24.05 | mckoan | pb_: IMHO nobody cares about that because all of us already know OE enough to use it proficiently (almost all of us) |
10:24.45 | mickey|office | good morning pb_ |
10:26.21 | pb_ | mckoan: well, I guess it depends what you mean by "cares". I am a fairly proficient OE user and I still find it deeply annoying that you have to jump through so many hoops to get it to work on a new machine from scratch. But I haven't been able to think of any straightforward way of improving that. |
10:26.22 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
10:27.45 | mckoan | pb_: this sentence raises the actual problem, we all easily see the 'internal' point of view, but not who newbies see it from 'external' |
10:28.07 | mckoan | a (HUGE) black box |
10:29.39 | mckoan | I have always preached to provide a reduced set of configurations (BSP) stable and always working. |
10:30.03 | mckoan | For those approaches for the first time OE is frustrating to fail all the early build. |
10:30.19 | mckoan | ~hail translate.google.it |
10:30.19 | ibot | ACTION bows down to translate.google.it and chants, "I'M NOT WORTHY!!" |
10:31.36 | *** join/#oe Charlie (d4d10305@gateway/web/freenode/ip.212.209.3.5) |
10:32.10 | Charlie | How do I get all "-dbg" packages installd into the rootfs image |
10:32.32 | *** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |
10:33.17 | *** join/#oe Heinervdm (~thomas@pD9E15B5A.dip.t-dialin.net) |
10:33.58 | mckoan | goes to the soldering desk ;-) |
10:35.24 | hrw | fights with cross gcj under ubuntu |
10:36.00 | ericben | mckoan: sorry my line was cut "short circuit" on the phone line ;-) I'm now reading the archives |
10:38.54 | CIA-47 | 03Eric Bénard <eric@eukrea.com> 07org.openembedded.dev * r64503bd9bc 10openembedded.git/recipes/busybox/busybox_1.18.3.bb: |
10:38.54 | CIA-47 | busybox-1.18.3: add last fix |
10:38.54 | CIA-47 | Signed-off-by: Eric Bénard <eric@eukrea.com> |
10:38.54 | CIA-47 | Acked-by: Khem Raj <raj.khem@gmail.com> |
10:44.02 | JaMa|Off | any idea what could be causing this in oe-core? ERROR: Error parsing /OE/shr-core/meta-shr/recipes-efl/efl/eeze_svn.bb: cannot concatenate 'str' and 'dict' objects |
10:44.25 | JaMa|Off | SRC_URI = "${E_SVN}/trunk;module=${SRCNAME};proto=http;scmdata=keep" |
10:44.32 | JaMa|Off | and E_SVN is added to shr.conf |
10:44.32 | ericben | mckoan: adding a machine to other build systems is not always an easy task. check for doc for ltib, ptxdist or even buildroot ... at least when there is some doc detailing this. |
10:45.26 | hrw | adding machine into OE can be done in 1 hour (+ build time) if you have working kernel tree |
10:45.35 | ericben | hrw : true |
10:46.45 | ericben | and people using buldroot and giving critic on OE should think twice as the goal of buildroot for future release is to provide feature already existing in oe : package generation, external toolchain support, sdk creation ... |
10:47.02 | mckoan | ericben: adding a machine is an andvanced feature |
10:47.26 | hrw | ericben: buildroot supports external toolchains |
10:47.43 | hrw | ericben: crosstool-ng support is integrated too |
10:47.46 | mckoan | hrw: +1 |
10:47.59 | ericben | instead of opposing buildsystems, it would be great that build system work together, especially for cross compiling patches ... there was an attemps by ptx |
10:48.25 | CIA-47 | 03Pau Espin Pedrol <pespin.shar@gmail.com> 07master * r569c6db89e 10openembedded.git/recipes/openmoko-3rdparty/emtooth2_svn.bb: |
10:48.25 | CIA-47 | emtooth2: bump SRCREV |
10:48.25 | CIA-47 | Signed-off-by: Pau Espin Pedrol <pespin.shar@gmail.com> |
10:48.25 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
10:48.31 | ericben | hrw: yes but the feature seems to be stabilizing seeing the work being done on it |
10:48.39 | hrw | ericben: and for last two years crossdev ML is nearly empty |
10:48.52 | ericben | I should have say "stabilizing and impriving external toolchain support" |
10:49.25 | ericben | hrw: in fact I was talking about this tentative : http://www.send-patches.org/ |
10:50.04 | hrw | ericben: which is same |
10:50.09 | mckoan | ericben: LOL that website has always been the motto of my old friend Schwebel |
10:50.13 | ericben | hrw: OK ;-) |
10:51.25 | ericben | the idea is good |
10:51.41 | mckoan | IMHO we are all too technical, we need a political vision too |
10:52.25 | ericben | well ... then find political people to get the political vision and break everything :-D |
10:53.37 | mckoan | ericben: no, I didn't mean that, but a mis of technically-good and generally-useful could help |
10:53.44 | mckoan | s/mis/mix |
10:54.02 | ericben | the root problem is that more and more people expect to build en embedded system without any knowledge only because they aregoing to use linux |
10:54.27 | mckoan | ericben: for 5/5 configuratons would be a must |
10:54.36 | mckoan | 4/5 conf |
10:54.54 | mckoan | a sort of 'quick-start' |
10:55.35 | mckoan | if you see thinkg working you are eager to continue |
10:56.53 | mckoan | this is my personal way of evaluating a project that uses open-source time for the rhyme: First let's see if something works |
10:57.22 | mckoan | s/rhyme/first time |
10:57.43 | ericben | mckoan: that exists : http://openembedded.org/index.php/Getting_started & http://www.angstrom-distribution.org/simplified-development-setup are good starting points |
10:59.11 | mckoan | ericben: ok, but usually you are evaluating it at home during your overtime, and you are using your laptop |
10:59.42 | mckoan | ericben: which would require at least all the night for the first build |
10:59.59 | mckoan | ericben: so the external toolchain is a must |
11:01.11 | mckoan | moreover that getting started is focused on beagleboard (favourite TI people board) |
11:01.35 | mckoan | I meant 4/5 generic configurations |
11:01.37 | ericben | mckoan: maybe but that adds complexity. I think the added value of OE is building something from scratch without lot of dependencies. |
11:02.10 | ericben | and a getting started focused on beagleboard is not a bad thing considering the popularity of this board and its small price. |
11:02.13 | hrw | sstate support + external repo with sstate packages may help |
11:02.14 | mckoan | ericben: yes of course I love it and always wanted it (since I used PTXdist), but is not good for starting |
11:02.48 | ericben | and also the amount of work done by Ti & Koen to have a good board support for this board |
11:03.18 | ericben | mckoan: for starting narcissus + already build sdk is a good thing |
11:03.35 | ericben | this allows people to concentrate on there application instead of loosing time building a base system |
11:04.07 | mckoan | is moving to oscilloscope desk for bug hunting |
11:04.42 | ericben | ok lunch time it's not every day that a semiconductor vendor invite us to restaurant ;-) |
11:05.45 | ynezz | no wonder, I've always thought, that you french only eat, drink wine and strike all the time... |
11:05.53 | ynezz | :) |
11:06.23 | *** join/#oe timtimred (~meh@85.210.134.118) |
11:06.42 | Jay7 | ynezz: btw, I'm going to add testbuilder.cond.d directory support :) |
11:06.57 | Jay7 | I have about 5 build configs already.. starting hard to manage in one file |
11:06.57 | ynezz | hm, what's that? |
11:07.10 | Jay7 | . testbuilder.conf.d/*.conf :) |
11:07.13 | ynezz | ah |
11:07.24 | *** join/#oe lamawithonel (~lucas@173-101-176-25.pools.spcsdns.net) |
11:07.52 | *** join/#oe rsv (7aa60de8@gateway/web/freenode/ip.122.166.13.232) |
11:08.45 | rsv | earlier, there was a checksum.ini file which consisted all the checksums of all packages, no the file is empty. |
11:09.13 | ynezz | yes, because the checksums moved to the corresponding recipes |
11:09.14 | hrw | rsv: we moved it to recipes |
11:10.23 | rsv | okay, so if i need a old package, i just need to change the checksum |
11:10.28 | rsv | in the reciepe |
11:10.38 | ynezz | yep |
11:10.45 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
11:11.29 | rsv | okay, i have not worked on oe for a long time. looks like i need to brush up |
11:12.44 | rsv | hrw: then why is the checksum.ini exists |
11:12.56 | rsv | i mean empty checksum.ini |
11:13.08 | hrw | no one dropped it? |
11:14.23 | hrw | someone remember who Junqian Gordon Xu is? |
11:17.28 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
11:19.22 | bluelightning | hrw: xjqian ? |
11:20.12 | bluelightning | haven't seen him around much lately |
11:21.19 | rsv | can i send a patch to the OE mailing list to remove it? |
11:21.30 | hrw | bluelightning: thx |
11:21.35 | hrw | rsv: yes |
11:22.28 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
11:31.26 | *** join/#oe methril_work (~Rafael@189.114.111.135) |
11:42.16 | *** join/#oe GNUtoo|laptop (~gnutoo@host157-58-dynamic.116-80-r.retail.telecomitalia.it) |
11:45.15 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
11:46.20 | *** join/#oe guyvdb_ (~guy@41.124.237.205) |
11:46.24 | otavio | I'd like to get some advice how to solve an issue we're needing to deal with. We're using git submodule to "control" our layer and OE submodules and this way allowing us to have a reproducable environment without using a single. |
11:46.59 | otavio | The problem is that we need to have an way to get the git tag of supermodule. |
12:37.48 | *** join/#oe ibot (~ibot@rikers.org) |
12:37.48 | *** 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 |
12:48.31 | *** join/#oe Jin^eLD (~jin@belief.htu.tuwien.ac.at) |
12:48.32 | Jin^eLD | huhu |
13:11.11 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
13:14.34 | *** join/#oe pespin (~pespin@cisne-cn08.upc.es) |
13:19.39 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
13:35.16 | *** join/#oe brolin (~brolin@nat59.udea.edu.co) |
13:38.45 | *** join/#oe dos1 (~dos@d45-212.icpnet.pl) |
13:38.48 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
13:42.33 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r270f5d7144 10openembedded.git/recipes/ (7 files in 5 dirs): |
13:42.33 | CIA-47 | recipes: don't use weak assignment for LICENSE |
13:42.33 | CIA-47 | * while trying openembedded-core I've noticed that such LICENSE field is ignored anyways |
13:42.33 | CIA-47 | * it doesn't make much sense |
13:42.33 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
13:42.40 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r414823a3c0 10openembedded.git/recipes/ (5 files in 3 dirs): |
13:42.40 | CIA-47 | recipes: drop unused SHR_RELEASE field |
13:42.40 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
13:42.43 | CIA-47 | 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r4dd61042a7 10openembedded.git/recipes/ (11 files in 4 dirs): |
13:42.43 | CIA-47 | recipes: s/LICENCE/LICENSE/g |
13:42.43 | CIA-47 | * while trying openembedded-core I've noticed that some recipes have LICENCE instead LICENSE which is checked in oe-core, just rename |
13:42.43 | CIA-47 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
13:43.56 | *** join/#oe mrc3 (~ddiaz@189.157.121.89) |
13:46.28 | *** join/#oe darkschneider (~gab@93-32-38-90.ip31.fastwebnet.it) |
13:48.58 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
13:49.41 | *** join/#oe kristoffer (~kristoffe@c-ccdfe555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
13:50.01 | ericben | hi otavio : what do you mean by "git tag of supermodule" ? |
13:50.57 | ericben | ynezz: the most difficult here in Bordeaux is to find time to work between meals & wine tastery ;-) |
13:51.45 | *** join/#oe darkschneider (~gab@93-32-38-90.ip31.fastwebnet.it) |
13:53.12 | *** join/#oe gandhijee (akp@ip67-152-15-148.z15-152-67.customer.algx.net) |
13:53.25 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
13:54.19 | Crofton|work | rofl |
13:58.31 | *** join/#oe GNUtoo|laptop (~gnutoo@host157-58-dynamic.116-80-r.retail.telecomitalia.it) |
14:01.32 | *** join/#oe mrc3 (~ddiaz@189.157.112.203) |
14:09.26 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
14:11.25 | *** join/#oe kristoffer (~kristoffe@c-ccdfe555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
14:12.49 | *** join/#oe hrw (~hrw@linaro/hrw) |
14:19.27 | *** join/#oe mrc3 (~ddiaz@189.157.111.123) |
14:19.49 | *** join/#oe mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) |
14:25.26 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * r0d732b3b54 10bitbake.git/lib/bb/server/process.py: (log message trimmed) |
14:25.26 | CIA-47 | server: use local fixed _bootstrap when appropriate |
14:25.26 | CIA-47 | When running on python versions 2.6.0 through 2.6.2, we use a local copy |
14:25.26 | CIA-47 | of the python 2.6.6 _bootstrap method of Process, to ensure that we have |
14:25.26 | CIA-47 | the fix for http://bugs.python.org/issue5313. This avoids the "hang" of |
14:25.26 | CIA-47 | the bitbake process at 0% progress during the parsing on older distros |
14:25.27 | CIA-47 | like Fedora 12. |
14:25.34 | CIA-47 | 03Chris Larson <chris_larson@mentor.com> 07master * r898f557cbd 10bitbake.git/bin/bitbake-layers: |
14:25.34 | CIA-47 | bitbake-layers: drop 2.6 from #!, per Joshua Lock |
14:25.34 | CIA-47 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
14:25.55 | Jay7 | ah, kergoth |
14:26.05 | Jay7 | catch you :) |
14:26.22 | kergoth_ | heh :) |
14:26.45 | Jay7 | I wish to say that trying to bitbake something with wrong MACHINE produces unreadable trace for user :) |
14:26.49 | kergoth_ | if anyone can test that hang fix on fedora 12 or another distro with the affected python version, I'd appreciate it. it worked for me, but.. |
14:27.07 | Jay7 | something about INVALID machine |
14:27.25 | kergoth_ | Jay7: ah, yeah, i've seen that.. its due to our use of "${MACHINE}" in a python snippet in OVERRIDES, i think, if you're referring to the one with the python error about trying to find a matching ' or somesuch |
14:27.30 | kergoth_ | i think.. |
14:27.33 | kergoth_ | tests |
14:27.41 | *** join/#oe dth_ntb (~dth@a89-183-199-187.net-htp.de) |
14:27.45 | *** join/#oe hrww (~hrw@linaro/hrw) |
14:27.52 | kergoth_ | right, yeah, EOL while scanning string literal, ugly indeed |
14:28.08 | Jay7 | I've just made mistype in my MACHINE and got it :) |
14:28.21 | *** part/#oe dth_ntb (~dth@a89-183-199-187.net-htp.de) |
14:28.29 | kergoth_ | we could avoid it by having a fallback |
14:28.41 | kergoth_ | MACHINE = "INVALID" in bitbake.conf or unknown or somesuch |
14:28.48 | kergoth_ | or we could change how we add machine to overrides / filespath |
14:28.52 | kergoth_ | hmmm |
14:30.31 | kergoth_ | hmm, bitbake-layers shows more deprecation warnings than bitbake, i forgot the warnings stuff i do there isn't in a common place |
14:30.35 | kergoth_ | wonders what to doa bout that |
14:37.04 | kergoth_ | hmm |
14:37.34 | kergoth_ | Jay7: if you set, e.g. DISTRO = "unknown" MACHINE = "unknown" in bitbake.conf, it gets past this issue, and then appears to hang when it hits the unknown endianness |
14:37.36 | kergoth_ | rolls eyes |
14:38.00 | pb_ | bletch |
14:38.03 | Jay7 | an yes, I have seem that about unknown endianiess :) |
14:38.06 | pb_ | that stuff is so full of suck |
14:38.41 | kergoth_ | indeed |
14:39.17 | *** join/#oe mrc3 (~ddiaz@189.157.112.194) |
14:39.21 | *** join/#oe hrww (~hrw@linaro/hrw) |
14:42.01 | *** join/#oe valhalla (~valhalla@81-174-23-185.dynamic.ngi.it) |
14:42.46 | *** join/#oe hillct_ (~hillct@cpe-174-109-201-200.nc.res.rr.com) |
14:44.46 | kergoth_ | of course, really, target arch being INVALID should be caught at ConfigParsed time, before the recipes are parsed.. |
14:44.46 | kergoth_ | hmm, sanity.bbclass operates at BuildStarted time, not ConfigParsed |
14:44.46 | kergoth_ | i could see needing to wait till then, but most of it could likely be done at config parsed |
14:44.46 | kergoth_ | s/needing/some things needing/ |
14:45.52 | *** join/#oe kergoth__ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
14:59.47 | CIA-47 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rc8bbbb90cc 10openembedded.git/recipes/sdr/soft66_git.bb: |
14:59.47 | CIA-47 | soft66: add git version |
14:59.47 | CIA-47 | "Library and tools for Soft66ADD and related SDR radio receivers" |
15:01.54 | *** join/#oe mrj10 (~mrj10@63.252.64.254) |
15:03.08 | *** part/#oe mrj10 (~mrj10@63.252.64.254) |
15:06.30 | *** join/#oe lamawithonel (~lucas@173-101-176-25.pools.spcsdns.net) |
15:07.20 | *** join/#oe hrww (~hrw@linaro/hrw) |
15:07.34 | *** join/#oe lamawithonel (~lucas@173-101-176-25.pools.spcsdns.net) |
15:08.51 | *** join/#oe hrw (~hrw@linaro/hrw) |
15:11.53 | *** join/#oe mgrundy (~grund@66.43.64.66) |
15:19.32 | *** join/#oe pespin (~pespin@90.163.57.54) |
15:20.13 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
15:26.00 | broonie | Hrm. OE keeps grinding to a halt during boot just after starting portmap. |
15:30.42 | Crofton | OE does? |
15:30.51 | Crofton | or an image created with OE :) |
15:40.55 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
15:42.16 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
15:46.21 | *** join/#oe anr78 (~Mich@145.79-161-31.customer.lyse.net) |
15:48.10 | *** join/#oe Soopaman (~soopaman@dsl-69-172-82-49.acanac.net) |
15:48.42 | *** join/#oe hrw-backup (~hrw@89-73-120-20.dynamic.chello.pl) |
15:49.53 | *** join/#oe hrw (~hrw@linaro/hrw) |
15:50.50 | Soopaman | morning all |
15:52.18 | Soopaman | are there any tutorials for setting up a new oe platform? want to add a stream for my old Transmeta Crusoe based internet appliance |
15:58.30 | GNUtoo|laptop | Soopaman, I think so |
15:58.44 | GNUtoo|laptop | look in the manual and in the wiki |
15:58.49 | GNUtoo|laptop | for adding a new "machine" |
15:58.53 | *** join/#oe brolin (~brolin@nat57.udea.edu.co) |
15:58.54 | GNUtoo|laptop | look for the machine keyword |
16:03.51 | Soopaman | k |
16:09.52 | *** join/#oe dth_ntb (~dth@a89-183-199-187.net-htp.de) |
16:10.17 | *** join/#oe Guest75525 (~solaris@pool-71-108-9-206.lsanca.dsl-w.verizon.net) |
16:10.19 | *** part/#oe dth_ntb (~dth@a89-183-199-187.net-htp.de) |
16:20.36 | GNUtoo|laptop | Soopaman, did you find what you were looking for? |
16:23.17 | *** join/#oe thaytan (~jan@ppp59-167-167-201.static.internode.on.net) |
16:24.45 | Soopaman | kind of but not really |
16:24.59 | *** join/#oe nitink (~nitink@192.55.54.42) |
16:25.32 | Soopaman | hoping to reduce the amount of guess-build iterations |
16:27.08 | Tartarus | Well, you're just treating it as another x86 right? |
16:27.11 | GNUtoo|laptop | basically you need to add : |
16:27.17 | Tartarus | Look at qemux86 as an example machine.conf |
16:27.22 | GNUtoo|laptop | *a machine config in conf/machine/ |
16:27.25 | GNUtoo|laptop | *a kernel |
16:27.28 | Tartarus | Then find openembedded/recipes -name qemux86 -type d |
16:27.28 | GNUtoo|laptop | that's the minimum |
16:27.48 | GNUtoo|laptop | then add other configs like xorg.conf or /etc/network/interfaces etc... |
16:27.50 | Tartarus | (Along with a git grep _qemux86 recipes/*/*.{inc,bb}) |
16:31.37 | hrw | Soopaman: which device exactly you have? |
16:32.19 | hrw | Soopaman: progear may fit your device as it was for my webpad based on Crusoe |
16:32.55 | Soopaman | hrw, I have the Gateway Connected Touchpad |
16:33.06 | Soopaman | lemme see if I can dig up a link |
16:33.47 | Soopaman | Tartarus: I was thinking about that approach, but wasn't exactly sure if it matters that the final build will have to be written to a cf card |
16:33.53 | hrw | I see |
16:34.34 | hrw | Soopaman: try progear - should give you something working |
16:34.50 | Soopaman | http://www.zdnet.com/news/gateway-connected-touch-pad/299005 |
16:34.57 | Soopaman | k |
16:36.25 | hrw | 96MB of ram... |
16:36.38 | hrw | progear has 128 |
16:37.10 | hrw | Soopaman: you will probably have to adapt X11 config a bit but should work |
16:37.14 | *** join/#oe jedahan (~jedahan@subtle/user/jedahan) |
16:37.30 | hrw | Soopaman: I will be interested in informations does backlight control works |
16:38.43 | Soopaman | I have my old x11 configs |
16:39.21 | Soopaman | and the backlight scripts, so hopefully i'll be able to work it back in if it works |
16:39.31 | anr78 | I get the following errors when compiling qt4-embedded with latest org.openembedded.dev: http://pastebin.com/9H2nYtb5. |
16:39.44 | *** join/#oe nitink (~nitink@192.55.54.40) |
16:40.54 | *** join/#oe Jefro (~josiermi@nat/intel/x-phqtyvdzyddvmfwh) |
16:43.15 | *** join/#oe jedahan_ (~jedahan@66.43.64.66) |
16:45.34 | mckoan | anr78: qt4e with armv7a ? good luck :-D |
16:45.54 | *** join/#oe JaMa (~martin@161-24.13.24.78.awnet.cz) |
16:50.43 | ericben | mckoan: works fine here why should that create trouble ? |
16:51.53 | anr78 | works fine for me as well (when it builds) |
16:52.11 | anr78 | so I also wonder why :) |
16:52.23 | *** join/#oe bluelightning_ (~paul@83.217.123.106) |
16:52.23 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
16:52.26 | mckoan | ericben: anr78: good to know, thx |
16:54.16 | mckoan | have a nice rest of the day |
16:57.46 | *** join/#oe NvrBst (~nb@66.183.110.123) |
16:58.45 | *** join/#oe duffolonious (~bryan@75-168-99-215.mpls.qwest.net) |
16:59.08 | anr78 | ericben: do you use 4.7.1? |
16:59.40 | ericben | anr78: yes |
17:00.37 | ericben | anr78: with angstrom 2010 |
17:00.37 | *** join/#oe phdeswer (~Philippe@a83-245-252-47.elisa-laajakaista.fi) |
17:01.14 | anr78 | ericben: hm. I still use angstrom 2008, but have been looking for reasons to switch :) |
17:01.25 | *** join/#oe BlindMan_ (~othmar@h081217021188.dyn.cm.kabsi.at) |
17:01.49 | *** join/#oe mhentges (~mhentges@hentges.net) |
17:02.31 | anr78 | still, 4.7.1 has compiled for me on angstrom 2008 until todays fetch |
17:05.13 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
17:05.49 | *** join/#oe Jay7x (jay@78-106-50-245.broadband.corbina.ru) |
17:06.23 | *** join/#oe toi (~peter@d54C2AA76.access.telenet.be) |
17:06.44 | *** join/#oe hrw (~hrw@linaro/hrw) |
17:08.19 | ericben | anr78: I'll launch a build from scratch |
17:08.27 | Tartarus | denix, any typos in the gdbserver patch from Ben, before I git am it? :) |
17:10.38 | *** join/#oe sakoman (~sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) |
17:16.37 | *** join/#oe guyvdb_ (~guy@41.124.237.205) |
17:18.15 | guyvdb_ | What is the support for CMake and scons like in OE. Is it on par with autotools? Which build system would you choose for a project that will eventually be built in OE? |
17:19.55 | fray | cmake in general is horrible.. |
17:20.19 | fray | I don't know how well it's supported in oe, but if I was doing a new project -- it would be "regular" make based.. if it's at all complicated -- autoconf based |
17:20.19 | guyvdb_ | and scons? |
17:20.31 | guyvdb_ | ok |
17:20.38 | fray | I don't know anything about scons |
17:21.03 | ka6sox | fray, can you edit the wiki now? |
17:21.12 | fray | autotools has one advantage, a heck of a lot of people know how to work with it.. cmake, not a lot of people (in comparison) know how to -- or refuse to.. |
17:21.25 | fray | ka6sox ya I do, but I had a question -- how do I add a new topic to the dev section list?\ |
17:21.26 | guyvdb_ | I guess a majority of projects are still autotools based.. but I have seen a few now moving to cmake... Apache QPid |
17:21.33 | Jin^eLD | guyvdb_: I personally hate cmake very much, it's number one on my build systems shitlist :) I did have to create some recipes for scons based projects and it did work |
17:21.41 | ka6sox | fray, which topic oe-core? |
17:21.44 | fray | I really think it's rate.. cmake is really a terrible make system.. |
17:21.58 | fray | ya.. I havn't created it yet.. but thats what I want "OpenEmbedded-Core" |
17:22.11 | fray | 'er.. it's rare (cmake that is)... |
17:22.19 | *** join/#oe Jay7 (jay@78-106-52-116.broadband.corbina.ru) |
17:22.27 | Jin^eLD | aem, cmake I mean, not scons, although I remember we had a scons based project too long time ago |
17:22.49 | guyvdb_ | So with being able to be cross compiled with OE a priority... i should stick to autotools |
17:22.51 | CIA-47 | 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07org.openembedded.dev * re238a7a949 10openembedded.git/recipes/meego-cellular/libcmtspeechdata_git.bb: libcmtspeechdata: new recipe; library for cellular speech data path on n900 |
17:23.03 | CIA-47 | 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07org.openembedded.dev * r8f4d4e7b5a 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into org.openembedded.dev |
17:23.11 | fray | or no helper environment |
17:23.11 | ka6sox | fray, does it need to be on the front page? or can it be under Developers:More? |
17:23.31 | fray | developers:more |
17:23.38 | Jin^eLD | guyvdb_: as I said, "inherit cmake" did work for me, but I'd go with autotools |
17:23.59 | ka6sox | fray, okay will do in a bit..meeting |
17:24.01 | Jin^eLD | in the latter case I would at least know what to do if anything does not work out, with cmake I'd be lost |
17:24.14 | fray | thanks.. let me know.. I have an errand in a few minutes, but I should be back in an hour or so |
17:24.31 | fray | Jin^eLD ya, I echo that as well |
17:24.32 | guyvdb_ | I have a recipe that looks like it is working for me for zeromq.. not much too it... but if there is interest how would i contribute it? |
17:26.14 | *** join/#oe vanous (~vanous@194.228.223.3) |
17:30.23 | *** join/#oe neilm (~neil@s64-180-61-141.bc.hsia.telus.net) |
17:37.13 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
17:37.48 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
17:39.38 | *** join/#oe _chase_ (~chase@nat/ti/x-zvxfpecoegfqaeab) |
17:39.40 | *** join/#oe shoragan______ (~shoragan@sicherheitsschwankung.de) |
17:40.04 | *** join/#oe neilm1 (~neil@s64-180-61-141.bc.hsia.telus.net) |
17:47.26 | anr78 | ericben: great |
17:47.59 | *** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl) |
17:49.20 | eFfeM | gm |
17:51.08 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
17:51.08 | *** join/#oe B_Lizzard (~havoc@athedsl-119969.home.otenet.gr) |
17:51.08 | *** join/#oe muep (~muep@2a00:1a58:f501:235:5867:a7ff:fe44:6724) |
17:51.08 | *** join/#oe tomimo (~kurre@xdsl-83-150-88-111.nebulazone.fi) |
17:53.51 | *** join/#oe Philippe_ (~Philippe@a83-245-252-47.elisa-laajakaista.fi) |
17:53.53 | *** join/#oe vanous1 (~vanous@194.228.223.3) |
17:56.50 | *** join/#oe Gaston|Home (Gaston@ua-83-227-239-139.cust.bredbandsbolaget.se) |
18:00.48 | *** join/#oe B_Lizzard (~havoc@athedsl-119969.home.otenet.gr) |
18:01.16 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
18:06.48 | *** join/#oe sakoman_ (~sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) |
18:07.25 | *** join/#oe nitink (~nitink@192.55.55.41) |
18:17.41 | *** join/#oe tomimo (~kurre@xdsl-83-150-88-111.nebulazone.fi) |
18:20.38 | *** join/#oe anarsoul (~anarsoul@80.249.93.12) |
18:22.59 | *** join/#oe muep (~muep@2a00:1a58:f501:235:5867:a7ff:fe44:6724) |
18:23.08 | *** join/#oe rsalveti (~rsalveti@201.82.69.7) |
18:23.12 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
18:23.45 | *** join/#oe filip (~filip@ns.tefnet.pl) |
18:23.46 | anr78 | ericben: is your build done yet? gotta run in 5, and I'll check back tomorrow if it's not |
18:24.46 | *** join/#oe dm8tbr (dm8tbr@gw.bfst.de) |
18:25.06 | *** join/#oe neilm (~neil@s64-180-61-141.bc.hsia.telus.net) |
18:26.26 | *** join/#oe polyonymous_ (~hacker@g230197205.adsl.alicedsl.de) |
18:26.58 | *** join/#oe Jefro1 (~josiermi@nat/intel/x-kesastpxnolypxro) |
18:27.09 | *** join/#oe eFfeM1 (~frans@j200125.upc-j.chello.nl) |
18:27.13 | *** join/#oe vanous (~vanous@194.228.223.3) |
18:27.34 | *** join/#oe nitink1 (~nitink@134.134.139.76) |
18:29.23 | *** join/#oe Guest75525 (~solaris@pool-71-108-9-206.lsanca.dsl-w.verizon.net) |
18:29.26 | *** join/#oe anarsoul (~anarsoul@80.249.93.12) |
18:30.28 | *** join/#oe obi (~obi@unaffiliated/obi) |
18:32.07 | CIA-47 | 03Denys Dmytriyenko <denys@ti.com> 07master * ra47c14c83c 10openembedded.git/recipes/meta/external-toolchain-csl.bb: (log message trimmed) |
18:32.07 | CIA-47 | external-toolchain-csl: handle packaging of gdbserver based on PREFERRED_PROVIDER |
18:32.07 | CIA-47 | Allow packaging independent copy of specific version of gdbserver with |
18:32.07 | CIA-47 | external-toolchain-csl by setting PREFERRED_PROVIDER. E.g. for GPLv2 |
18:32.07 | CIA-47 | gdbserver, add these lines to your distro/local.conf: |
18:32.08 | CIA-47 | PREFERRED_PROVIDER_gdbserver = "gdbserver" |
18:32.09 | CIA-47 | PREFERRED_VERSION_gdbserver = "6.6" |
18:32.34 | *** join/#oe eFfeM_work1 (~frans@D4B26BC1.static.ziggozakelijk.nl) |
18:33.03 | *** join/#oe denix0 (~denix@pool-71-251-48-61.washdc.east.verizon.net) |
18:33.13 | *** join/#oe tzanger (~tzanger@gromit.mixdown.ca) |
18:34.39 | *** join/#oe orjanf (~onfg@hd5b91d02.k46641.sta.perspektivbredband.net) |
18:38.28 | *** join/#oe MMx (mmx@tesla.bfst.de) |
18:39.11 | CIA-47 | 03Denys Dmytriyenko <denys@ti.com> 07master * rdf59f77a2e 10openembedded.git/conf/distro/include/toolchain-external.inc: |
18:39.11 | CIA-47 | toolchain-external.conf: set the default provider for gdbserver |
18:39.11 | CIA-47 | Signed-off-by: Denys Dmytriyenko <denys@ti.com> |
18:40.20 | *** join/#oe XorA (~XorA@www.xora.org.uk) |
18:41.19 | *** join/#oe JDuke128 (~kadir@46.2.15.143) |
18:41.38 | JDuke128 | hi , does someone know openmika jvm ? |
18:43.03 | *** join/#oe rob_w (~bob@ppp-93-104-186-72.dynamic.mnet-online.de) |
18:49.40 | *** join/#oe mrj10 (~mrj10@63.252.64.254) |
18:49.40 | *** join/#oe rob_w_ (~bob@ppp-93-104-186-72.dynamic.mnet-online.de) |
18:49.45 | *** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
18:50.04 | *** join/#oe muep (~muep@2a00:1a58:f501:235:5867:a7ff:fe44:6724) |
18:50.04 | *** join/#oe mickey|bbl (~mickey@80.81.242.146) |
18:50.04 | *** part/#oe neilm (~neil@s64-180-61-141.bc.hsia.telus.net) |
18:50.07 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
18:50.07 | *** join/#oe mrmoku (~mrmoku@ppp-188-174-64-167.dynamic.mnet-online.de) |
18:50.42 | *** join/#oe sakoman_ (~sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) |
18:52.37 | Soopaman | hrw: around? |
18:52.59 | Soopaman | a little confused what to send the DISTRO value of my local.conf |
18:53.15 | *** join/#oe jmpdelos_ (~polk@outgoing.delos.com) |
18:54.18 | Soopaman | trying to make sure I understand what you, Tartarus, GNUtoo|laptop and the website suggest for creating a new machine |
18:54.48 | GNUtoo|laptop | Soopaman, hi again |
18:55.18 | GNUtoo|laptop | try to look at similar machine than yours |
18:55.22 | GNUtoo|laptop | in conf/machine |
18:55.27 | GNUtoo|laptop | and try to make a kernel recipe |
18:55.49 | GNUtoo|laptop | basically create conf/machine/foo.conf |
18:56.01 | GNUtoo|laptop | in the org.openembedded.dev git |
18:56.08 | GNUtoo|laptop | that you checked out |
18:56.27 | GNUtoo|laptop | then try to create a kernel recipe for your machine |
18:56.41 | GNUtoo|laptop | and well...that's the minimum required |
19:01.03 | kergoth_ | Soopaman: what does DISTRO have to do with anything? it's completely orthagonal vs MACHINE, they're two entirely different things |
19:02.05 | *** join/#oe rcf (~rcf@10.83-243-81.adsl-dyn.isp.belgacom.be) |
19:05.35 | Soopaman | GNUtoo|laptop: that's where I'm at, just trying to make sure where the DISTRO suggestion from http://openembedded.org/index.php/Getting_started fits in |
19:05.42 | Soopaman | hey kergoth, long time |
19:06.31 | GNUtoo|laptop | Soopaman, what's your machine already? |
19:06.55 | Soopaman | i made a gctp.conf from hrw's suggestion of progear.conf |
19:08.59 | kergoth_ | getting started is for setting up your first build, it's the basics, you might want to try doing that from beginning to end before you get anywhere near creating a machine .conf of your own.. |
19:09.22 | fray | :) |
19:12.17 | GNUtoo|laptop | it's a transmetta |
19:12.20 | GNUtoo|laptop | but what is it? |
19:12.22 | GNUtoo|laptop | a laptop? |
19:12.25 | GNUtoo|laptop | a pda? |
19:12.54 | GNUtoo|laptop | ha sorry I didn't realize that he didn't have his build setup |
19:13.29 | kergoth_ | Soopaman: make sure you can build for an existing distro and machine before you go any further. i'd suggest qemux86 or qemuarm for the machine |
19:13.52 | *** join/#oe aloisiojr (~aloisio@187.113.104.207) |
19:15.49 | Soopaman | GNUtoo|laptop: it's an "internet appliance" (webpad w/o battery), using the transmeta crusoe tm5500 chip (if my memory serves me) |
19:15.59 | GNUtoo|laptop | ok |
19:18.00 | khem | fray: around ? |
19:18.12 | khem | fray: I can reproduce the rpmbuild coredump |
19:18.47 | fray | khem.. there is a patch in poky-contrib qhe/zypper can you apply that and rebuild RPM -- and retry? (the patch is actually to libpcre) |
19:19.03 | khem | fray: ok pointer ? |
19:19.19 | kergoth_ | git://git.pokylinux.org/poky-contrib |
19:19.36 | fray | :) beat me to it |
19:19.41 | fray | (it's the top patch in that tree) |
19:20.08 | khem | I thought the url was yoctolinux |
19:20.24 | fray | pokylinux.org and yoctoproject.org are the same.. |
19:20.28 | fray | there is no yoctolinux.org |
19:20.44 | fray | (well there is, but it's to a holding site -- no content and not part of the yoctoproject) |
19:21.40 | khem | http://git.yoctoproject.org/cgit/cgit.cgi/poky/ |
19:21.45 | khem | is what I am at |
19:21.57 | fray | poky-contrib, not poky |
19:22.15 | khem | http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=qhe/zypper&id=e16bcffe0a3ce527cdd91aa01c21fc7305a2ab99 |
19:22.19 | khem | is one ? |
19:22.36 | fray | ya, thats it.. |
19:22.53 | fray | when yuo apply it.. be sure to rebuild libpcre before rpm.. (native and target) |
19:22.57 | hrw | GNUtoo|laptop: Soopaman's machine generally is sort of 'try does it works, recycle if not after 2 days of hacking' |
19:23.13 | khem | why would target be needed ? |
19:23.22 | khem | its dying in rpmbuild on host |
19:23.40 | fray | once you get it working, assuming you want to be able to use rpm on the target.. :P |
19:23.45 | khem | thats patch has patch=1 btw which is deprecated |
19:23.51 | GNUtoo|laptop | ? |
19:24.05 | fray | then we should fix that as well |
19:25.08 | khem | and patch needs origin information |
19:25.20 | khem | basically something similar to what I did for the rpm patch I have sent |
19:25.23 | fray | thats fine -- this is a test thing |
19:25.24 | khem | did you look at the patch ? |
19:25.28 | khem | is it ok? |
19:25.40 | fray | which patch? |
19:26.05 | fray | (BTW I am in the process of writing up the commit [and patch msg] guidelines) |
19:26.12 | fray | I hope to have them done today adn to the oe-tsc list |
19:26.38 | khem | fray: there is one for rpm I posted to oe-core |
19:27.03 | khem | fixes the build problems I was seeing on ubuntu |
19:27.05 | fray | found it, I'd overlooked it.. it's fine |
19:27.11 | khem | ack it then |
19:27.38 | fray | just did |
19:27.42 | khem | thx |
19:29.25 | fray | I've forwarded it on to rpm-devel@rpm5.org |
19:29.42 | khem | cool |
19:30.02 | khem | ok so libpcre-native is rebuilding lets see |
19:30.16 | fray | ya, based on your symptoms this is likely the issue |
19:30.27 | fray | conflict between pcre and libc regex functions.. |
19:30.41 | khem | hmm likely the issue |
19:31.10 | fray | the back trace you sent me was very similar to the one we'd been tracking on the target side.. the fix resolves the target side issue we had |
19:31.34 | khem | I am using eglibc libc-2.13 on build host |
19:33.03 | khem | ah forgot to clean rpm-native |
19:33.22 | fray | real fix will likely bump the PR which will trigger rpm-native to rebuild... |
19:35.28 | khem | one day bitbake will be able to figure out reverse deps :) |
19:36.25 | *** join/#oe morphis (~morphis@p5489F5DF.dip.t-dialin.net) |
19:37.28 | fray | well, theoretically the checksumming enhancements take into account versiong and other attributes of depends -- this should trigger rebuilds.. but no PR update (of libpcre) means no rebuild (of RPM).. |
19:37.59 | khem | well PR for libpcre got incremented |
19:38.20 | fray | hmm, that should have triggered rpm to rebuild then.. :( |
19:38.35 | fray | we'll have to bring it up to RP and see if it's implemented the way I thougth it was |
19:38.55 | kergoth_ | and are you both using the same bitbake? i'm sure tehre are still some siggen commits that haven't been pulled to master yet |
19:38.56 | khem | ok sounds like it will fix the problem |
19:39.08 | khem | I am always on master |
19:39.13 | fray | ahh that could be it.. |
19:39.17 | khem | I dont use others |
19:39.35 | kergoth_ | i think there's a few siggen/stamp commits in particular, which is likely this behavior |
19:39.40 | kergoth_ | along with the server changes |
19:39.44 | kergoth_ | and thats hould be it for differences |
19:39.52 | kergoth_ | maybe a few fetch2 fixes left, not sure |
19:40.45 | khem | fray: seems that patch was what I needed please propose it for oe-core |
19:41.04 | fray | I'm waiting for the final version, then I'll make sure it gets sent to oe-core |
19:41.15 | khem | sure thing |
19:41.17 | *** part/#oe mrj10 (~mrj10@63.252.64.254) |
19:41.35 | khem | so it seems finally I will have a qemu image that I can boot (hopefully) |
19:43.55 | mario-goulart | Hi. I'm making a class and I want to call do_fetch and do_unpack from base.bbclass when SRC_URI is defined on the recipes, instead of the ones defined on the class I'm making. How can I do that? Explicitly calling base_do_fetch and base_do_unpack doesn't work. |
19:49.08 | fray | I'm looking at a diff of Poky's bitbake and the upstream bitbake now.. |
19:49.08 | *** join/#oe Soopaman1 (~soopaman@dsl-69-172-82-49.acanac.net) |
19:49.29 | fray | one thing we added was Summary's to each recipe... it doesn't look like that made it upstream |
19:51.14 | khem | fray: one more thing for oe-core patch from yocto which have bugid mentioned should say yocto bugid blah |
19:51.24 | khem | or may be have a link to bugzilla |
19:51.46 | khem | I reckon that might become invalid in future if bugzilla changes |
19:51.52 | khem | its location |
19:54.07 | *** join/#oe methril (~methril@189.27.128.57.dynamic.adsl.gvt.net.br) |
19:57.36 | khem | fray: here is another error its running into http://pastey.net/146728 |
19:59.28 | fray | error: LOOP: well isn't.. there is no error msg there |
19:59.43 | fray | (it's actually a warning of circular dependencies) |
20:00.01 | fray | if rootfs creation failed look above that |
20:01.32 | fray | used to have a patch that removed those messages -- but I'll probably generate a new one that changes them into visible warnings |
20:01.56 | fray | at some point we should likely try to figure out a way to resolve the circular dependencies |
20:01.58 | woglinde | re |
20:02.06 | khem | fray: http://paste.ubuntu.com/575142/ is log_do_rootfs |
20:02.14 | mario-goulart | I also thought about not exporting my classe's functions when SRC_URI is not empty, so base.bbclass' ones would be used, but I could not make such a condition in the class toplevel environment (like `if (not empty SRC_URI) EXPORT_FUNCTIONS do_fetch do_unpack ...') |
20:03.15 | woglinde | boag |
20:03.15 | jedahan_ | the documents are slightly confusing, and i cant see any decent examples of BSPs |
20:03.17 | khem | mario-goulart: I think you have to override the defaults |
20:03.17 | fray | between lines 336 and 337 there should be actual error messages.. |
20:03.25 | jedahan_ | I am not sure what to put in layout.conf and what in machine/bug20.conf ... |
20:03.32 | woglinde | free beer |
20:03.46 | mario-goulart | khem: but how to do that conditionally? |
20:03.50 | fray | since we don't have any, my suggestion is to enable debugging on that line.. |
20:04.29 | woglinde | damn fair parties |
20:04.45 | khem | woglinde: too drunk ? |
20:04.51 | jedahan_ | layer.conf seems to just let poky find the layer, why does it have bbfiles defined? |
20:05.04 | woglinde | but now I know where my taxes go |
20:05.07 | fray | khem on line 308 of classes/package_rpm.bbclass |
20:05.13 | fray | add "-vv" before the --root ... |
20:05.15 | jedahan_ | because shouldnt machine/bsp.conf have all the bb file stuff in |
20:05.26 | fray | re run your build.. that should give us a lot more clue as to the failure |
20:05.26 | woglinde | khem I stopped right |
20:07.12 | khem | fray: that verbose thing should be make available as knob may be ? |
20:09.20 | fray | it really slows things down -- and really shouldn't be needed.. |
20:09.50 | fray | ...but at the top is a RPM="rpm"... it was done this way so we could change it to RPM="rpm -vv" easily.... |
20:10.22 | fray | khem, I'm working with the RPM maintainer -- he doesn't think thats the right fix.. |
20:10.31 | fray | but we're not sure what the correct one is.. |
20:10.33 | khem | fray: http://paste.ubuntu.com/575148/ |
20:11.35 | khem | fray: ok whatever is the right fix is fine since rpmio depended on these missing libs and mtree was using rpmio I thought it was right thing to do |
20:11.49 | fray | the beecrypt/syck should bec oming in via the linkage of librpmmisc |
20:11.53 | fray | thats as much as we know right now |
20:12.04 | fray | all of the librpm* should be including librpmmisc already |
20:12.10 | fray | I suspect this is an "as-needed" issue |
20:12.29 | khem | but if librpmio needs them then it should bring them along I would think would be the right way |
20:12.44 | fray | it does -- when you are not on Ubuntu 11.04-alpha |
20:12.46 | khem | yeah as-needed could be |
20:13.31 | khem | fray: that last paste is the link with verbose enabled |
20:13.45 | fray | ya.. there is no obvious error.. it just "stopped" |
20:14.02 | fray | let me try a build locally and see what I can get.. which target did you try to build? |
20:14.03 | khem | rpm has been PITA for me :) |
20:14.05 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
20:14.11 | khem | qemuarm |
20:14.30 | fray | I think it knows you are on ubuntu and doesn't want to behave properly.. ;) |
20:15.22 | fray | ARG! I still can't build because it says linux-libc-headers do_install fials |
20:15.30 | fray | is anyone else seeing that behavior with oe-core? |
20:15.41 | khem | fray: whats the error |
20:15.51 | fray | ERROR: Function 'do_install' failed (see /home/mhatle/git/oe-core/build-oe-core/tmp/work/i586-poky-linux/linux-libc-headers-2.6.37.2-r0/temp/log.do_install.20306 for further information) |
20:15.55 | fray | thats the whole error message |
20:16.01 | khem | hmmm |
20:16.01 | fray | another of these mystery failures |
20:16.13 | khem | and is there anything in /home/mhatle/git/oe-core/build-oe-core/tmp/work/i586-poky-linux/linux-libc-headers-2.6.37.2-r0/temp/log.do_install.20306 |
20:16.36 | fray | that -is- the only line in that file |
20:16.47 | khem | hmm |
20:17.00 | fray | but this doesn't fail on my poky system.. so something screwy is going on |
20:17.13 | fray | trys switching out bitbake |
20:17.21 | khem | which bitbake are you using ? |
20:17.25 | fray | thats with master |
20:17.33 | khem | I have master too |
20:17.57 | khem | but I see that you are trying qemux86 prolly |
20:18.05 | fray | yes.. it's what I had |
20:18.28 | khem | try bitbake -DDDD |
20:18.35 | khem | it might give some hints |
20:18.50 | fray | I'll try that next.. it looks like it might be working with teh poky bitbake |
20:18.58 | fray | (but I'm not yet sure) |
20:26.04 | fray | yes it worked for me with Poky's bitbake.. |
20:26.15 | fray | so there is something in the Poky bitbake patches that is causing failures for me.. |
20:26.20 | fray | anyway, back to trying to reproduce the issue |
20:26.36 | fray | (might turn out it's fakeroot/pseudo related.. if so the poky bitbake might be worth trying) |
20:27.08 | kergoth_ | if you're using bitbake master, make sure you're still using the oe-core/scripts/bitbake wrapper.. |
20:27.43 | fray | yes, I was/am |
20:27.58 | kergoth_ | i was referring more to khem, but good :) |
20:28.05 | fray | I assume Khem is as well, otherwise I'm not sure he would have gotten that far into the build |
20:28.06 | kergoth_ | forgot about it at first :) |
20:28.31 | khem | no I am not using wrapper |
20:28.38 | khem | well I did |
20:28.46 | kergoth_ | the wrapper makes sure the whole build runs under pseudo |
20:28.55 | fray | --ahh-- that would explain it! |
20:29.15 | fray | when RPM tries to chroot into the new filesystem it's failing and I suspect asserting -- without displaying an error message.. |
20:29.17 | khem | I was doing it and then I was running into all sort of issues |
20:29.20 | fray | looks at the RPm code |
20:29.20 | khem | lets retry using it |
20:29.26 | otavio | khem: but if mario-goulart provides a do_fetch on his class, the base's one won't be used. The problem is that it needs to be done conditionally. |
20:29.42 | JDuke128 | hi , does someone know openmika jvm ? |
20:29.48 | otavio | khem: in case we have VAR=1 it uses the class do_fetch, otherwise the base's one |
20:30.06 | khem | otavio: then reimplement base ones to have two versions and use other if first one is not there |
20:30.08 | JDuke128 | hi , does someone know openmika jvm ? |
20:30.09 | JDuke128 | hi , does someone know openmika jvm ? |
20:30.17 | khem | hmm |
20:30.22 | *** mode/#oe [+o kergoth_] by ChanServ |
20:30.24 | otavio | khem: duplicate the code? |
20:30.29 | otavio | gosh! |
20:30.31 | kergoth_ | JDuke128: don't do that again |
20:30.47 | kergoth_ | otavio: is there some reason you can't just call the base one from yours? what are you trying to do? |
20:31.03 | otavio | kergoth_: mario-goulart tried and it didn't work. |
20:31.04 | fray | <PROTECTED> |
20:31.04 | fray | <PROTECTED> |
20:31.04 | fray | <PROTECTED> |
20:31.04 | fray | <PROTECTED> |
20:31.13 | otavio | kergoth_: base_do_fetch failed. mario-goulart am I wrong? |
20:31.18 | fray | it's possible the error message never makes it out.. but I'm not sure why that would be |
20:31.30 | kergoth_ | otavio: so make it work. what's the failure? |
20:31.39 | *** join/#oe CMoH (~cipi@95.76.68.223) |
20:31.39 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
20:31.58 | woglinde | args |
20:32.02 | otavio | mario-goulart: can you paste.bin the error? |
20:32.04 | woglinde | jduek here too |
20:32.09 | mario-goulart | kergoth_, otavio: it failed. If that's supposed to work, maybe I made some syntax mistake |
20:32.19 | *** join/#oe pretec (~Matthias@port-92-195-13-101.dynamic.qsc.de) |
20:32.32 | kergoth_ | mario-goulart: oe was *designed* to facilitate overriding tasks and calling the base ones from them |
20:32.40 | kergoth_ | so yes, if that doesn't work, something is wrong. |
20:33.20 | fray | (BTW we're trying to figure out a way to determine if pseudo is running or not in a sanity check -- but we need to make sure to only do this on the stage2 build, not stage1.. so far I don't think we've added the check because of that -- in yocto) |
20:34.52 | khem | hmmm that script can only be run if I use poky-init-env |
20:34.57 | khem | since it needs BUILDDIR |
20:35.09 | kergoth_ | set BUILDDIR. |
20:35.11 | kergoth_ | :P |
20:35.11 | fray | yes, the environment needs to be setup |
20:35.27 | fray | you can choose not to use the poky-init-env -- but you still need the environment configured |
20:35.50 | mario-goulart | kergoth_: I see. I'm getting a traceback now. |
20:36.02 | *** mode/#oe [-o kergoth_] by kergoth_ |
20:36.14 | fray | (and for anyone who really doesn't want to use a POSIX shell, I have patches that enache (t)csh support in poky-init-env... but they're pretty nasty) |
20:36.24 | kergoth_ | shudders |
20:36.26 | fray | ...and no I don't use (t)csh, but I have some customers who do) |
20:36.38 | kergoth_ | sticks to zsh (bash if not available) |
20:36.53 | mario-goulart | kergoth_: http://paste.lisp.org/display/120180 |
20:37.07 | khem | so we are going to promote pople to use this env |
20:37.10 | fray | poky-init-env works on zsh, bash, ash (dash), and pdksh |
20:37.19 | kergoth_ | wow, what the hell. i just used a python ast visitor and hit a recursionerror |
20:37.22 | khem | since I see pseudo needing few env settings |
20:37.31 | fray | the values are needed -- it's up to the end distribution to use an initscript or not.. |
20:37.32 | mario-goulart | What I did was making my own_do_fetch() simply call base_do_fetch |
20:37.38 | kergoth_ | mario-goulart: base_do_fetch is python, not shell. |
20:37.43 | kergoth_ | you can't run python from shell |
20:37.59 | mario-goulart | Hmmm! |
20:38.09 | fray | PSEUDO needs to be setup in the ld_preload and ld-Library-path.. the problem is that you can't do that from within bitbake because there is no way to say "I don't have pseudo -- so don't do this.. ok now I have pseudo .. set this and re-exec ourselves" |
20:38.13 | *** part/#oe RP__ (~richard@93-97-173-237.zone5.bethere.co.uk) |
20:38.18 | fray | thus the wrapper script |
20:38.26 | kergoth_ | so to do what you want, you'd have to define a python do_fetch (though you could have it exec_func a shell funciton to do some of what you want to do, for convenience) |
20:38.30 | mario-goulart | kergoth_: so I should make my class' do_fetch in python? |
20:38.43 | kergoth_ | if you want to run base_do_fetch, your do_fetch will have to be python, yes |
20:38.48 | *** join/#oe RP__ (~richard@93-97-173-237.zone5.bethere.co.uk) |
20:38.53 | *** join/#oe lamawithonel (~lucas@173-101-176-25.pools.spcsdns.net) |
20:38.59 | mario-goulart | kergoth_: ah, ok. Thanks a lot. |
20:39.09 | kergoth_ | np |
20:39.14 | fray | (pseudo is loaded in memory at all times, so there is 'fakeroot' like ability for python and shell tasks.. without forcing the python tasks for fork/exec (which would have been required with libfakeroot.. the overhead of the fork/exec vs just fork is very measurable in build performance) |
20:39.16 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
20:39.35 | fray | we resisted the wrapper as well -- until we found it cut 20+ minutes off a build.. :P |
20:39.53 | khem | fray: I guess we need to document the environment settings |
20:39.54 | Crofton|work | fray, how long was the build :) |
20:40.18 | Crofton|work | although it would take an excessively long build for me not to notice 20 minutes ... |
20:40.40 | fray | I think a poky-image-sato build was up around 200 minutes on a 4 core 2.9GHz |
20:40.48 | fray | so 20 minutes was roughly 10% |
20:40.58 | Crofton|work | oouch |
20:41.23 | fray | we're currently at around 110 minutes for the same build, on the same machine due to other performance improvements |
20:42.36 | fray | this is to fix a bug that AFAIK exists in existing oe.. if you run tasks with python -- there is currently no way to do the fakeroot behaviors.. which can cause incorrect permissions in the resulting target packages |
20:42.53 | fray | our first fix to that was simply allow python functions (non-shell) for fork/exec.. |
20:42.53 | *** join/#oe philippe (~philippe@a83-245-252-47.elisa-laajakaista.fi) |
20:43.02 | fray | that added a lot of unexpected time to the build.. |
20:43.27 | fray | add pseudo -- and suddenly things took longer because it handles the build interception in a more complete (IMHO) fashion that fakeroot does.. |
20:44.26 | fray | (currently with the wrapper there is a variable PSEUDO_DISABLED=1 that is set in the wrapper.. pseudo just stays in memory, watches for fork/exec calls -- when it sees one, quickly checks the environment.. if that goes away or is set to 0, it then activates... otherwise stays dormant) |
20:46.02 | khem | fray: if I need to use BUILDDIR outside the control of these scripts then I do source ./poky-init-build-env BUIDLDIR=/mydir |
20:46.18 | fray | source ./poky-init-build-env <build dir> |
20:48.02 | khem | and MACHINE and DISTRO |
20:48.16 | fray | machine and distro are set in the conf/local.conf |
20:52.05 | khem | hmm it copies conf into builddir |
20:52.21 | fray | yes.. there is a sample conf, which gets copied as conf/local.conf |
20:52.27 | khem | I usally am used to have it along with sources |
20:52.28 | fray | then you can add/remove or edit the entries in there |
20:52.43 | fray | thats how you would disable package_rpm and defualt onto to ipk for instance |
20:52.45 | khem | so I can delete the builddit |
20:52.48 | khem | builddir |
20:53.12 | fray | (note rpm is still needed for dependency scanning, even in deb and ipk processing -- but it just doesnt' build RPM packages) |
20:53.26 | woglinde | what? |
20:53.32 | khem | yeah rpm is must it seems |
20:53.57 | woglinde | I didnt see rpm building |
20:54.18 | khem | fray: is there some reason to use only rpm |
20:54.28 | fray | there were a number of (run-time) dependencies that didn't appear in the original work.. I added code that used "rpmdeps" program to go in and capture provide and requires information per-file.. |
20:54.29 | *** join/#oe pespin_ (~pespin@90.163.57.54) |
20:54.35 | fray | this solved some nagging dep issues for us.. |
20:54.36 | khem | I think if someone does not want to use rpm he/she could see it potential let off |
20:54.56 | fray | rpm for the dep scanning was simply the easiest way to do it -- and most reliable I found.. |
20:55.02 | fray | but rpm for the packaging is strictly optional.. |
20:55.15 | fray | I doubt a lot of people doing OE work reallyw ant RPM as the default packaging format |
20:55.23 | *** join/#oe timtimred (~meh@85.210.134.118) |
20:55.35 | fray | (company I work for and our customers do need rpm as the default packaging format for one reason or another) |
20:56.04 | fray | (specifically larger systems seem to want rpm or similar, while smaller systems seem to want something like opkg or no packaging method) |
20:56.21 | khem | fray: thats fine however what I was thinking is if its possible to use say opkg instead to do dep scanning and make it pluggable and if user has no choice then use rpm |
20:56.46 | fray | opkg doesn't do dep scanning.. it relys on the information from OE |
20:56.48 | *** join/#oe Jefro (~josiermi@134.134.139.72) |
20:57.26 | fray | for details, look in "package.bbclass" search for "rpmdeps" |
20:58.26 | fray | trying to remember the missing details.. I believe it was versioned symbols, specific soname requirements, and something else.. there were three things that were missing.. |
20:58.33 | fray | (Sorry I'm blanking now on exactly what they were..) |
20:58.55 | fray | rpmdeps just uses the same code RPM does to generate dependencies, without using the rest of the rpm packaging system to either package or install.. |
20:59.27 | fray | (the other side effect is we now have -per-file- dependency information available.. I hope to use this in the future to allow for post package generation "repackaging" behavior through an external tool) |
20:59.52 | khem | I think its a good thing no doubt |
21:00.23 | khem | needs food |
21:00.26 | fray | specifically if say package "foo" generates with three binaries "/bin/A" "/bin/B" and "/bin/C".. the user can look at it and understand what each A, B, C have for runtime dependencies and then repackage it and say remove 'B' without having to re-write the recipe and such |
21:00.45 | fray | in otherwords, the customization a lot of people do already |
21:01.43 | fray | gotta run.. sounds like my car is done at the body shop.. bbiab |
21:04.31 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
21:11.56 | *** join/#oe Gaston|Home (Gaston@ua-83-227-239-139.cust.bredbandsbolaget.se) |
21:23.10 | *** join/#oe kgilmer (~kgilmer@ntngsk052174.ngsk.nt.ftth4.ppp.infoweb.ne.jp) |
21:33.45 | *** join/#oe Guest75525 (~solaris@pool-71-108-9-206.lsanca.dsl-w.verizon.net) |
21:36.48 | *** join/#oe CMoH (~cipi@95.76.68.223) |
21:36.49 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
21:40.48 | *** join/#oe nschle85 (~kvirc@77.47.83.31.dynamic.cablesurf.de) |
21:50.20 | khem | kergoth: I am trying to setup a local git repo which should track an upstream projects |
21:50.36 | khem | kergoth: have you done that before |
21:50.42 | khem | and any experiences to share ? |
21:55.09 | robtaylor | khem: git clone ; git pull; |
21:56.01 | *** join/#oe ant__ (~andrea@host208-105-dynamic.50-82-r.retail.telecomitalia.it) |
21:56.03 | khem | robtaylor: I am looking for shareing this repo and make it writable to local folks |
21:56.10 | khem | at the same time |
21:56.42 | robtaylor | khem: ah, righty, then git clone --bare, somewhere accessible by http |
21:57.51 | robtaylor | khem: do you want yur local toeam to be abel to push to it? |
21:58.01 | khem | yes |
21:58.17 | khem | atleast they should clone/pull it |
21:58.21 | khem | easily |
21:58.36 | khem | and I should be able to take their changes and at the same time changes from upstream |
22:00.05 | robtaylor | khem: are there any port restrictions between the mirror machine and your developers? |
22:00.11 | khem | nope |
22:01.47 | robtaylor | khem: ok so :http://book.git-scm.com/4_setting_up_a_public_repository.html |
22:02.27 | robtaylor | khem: thoughm you probably want to use git clone --mirror , which will mirror all the branches in the public repo |
22:04.11 | robtaylor | khem: then you'll want a cron job running GIT_DIR=/path/to/git/repo git pull --all |
22:04.53 | robtaylor | khem: your team would them be able to create their own branches there for sharing their work, and you can upstream your work in the ususal way |
22:05.23 | robtaylor | khem: though I have one other suggestion that might be worthwhile - just use github? |
22:05.34 | robtaylor | depends how secret the work is, i guess :) |
22:06.27 | khem | robtaylor: well its internal so no github for now |
22:06.59 | khem | robtaylor: git clone --bare --mirror is what i need |
22:07.02 | robtaylor | khem: you can have private github repos |
22:07.15 | robtaylor | khem: no need for --bare, --mirror implies bare :) |
22:07.24 | khem | k |
22:07.35 | khem | and for getting changes from upstream |
22:07.45 | khem | I can just track upstream as remote repo right ? |
22:07.48 | robtaylor | khem: it is possiblyt to set up an internal gitorius - which is quite nice for code review, |
22:07.54 | robtaylor | khem: spot on |
22:08.06 | khem | gerrit |
22:08.17 | robtaylor | khem: ah, that's better :) |
22:08.55 | robtaylor | khem: the main issue with gitis there's so many differnt options on setting up the workflow |
22:09.12 | khem | yes |
22:09.35 | khem | robtaylor: so that page does not explain the part how to setup git access on server |
22:09.48 | robtaylor | khem: tbh, one main q here - is the mirror just for local access speed? |
22:10.06 | khem | robtaylor: speed + local patch history |
22:10.50 | robtaylor | khem: tbh, i'd probably use two repos, just to save mess |
22:11.08 | robtaylor | khem: one as the mirror - for your team to use as their remote/upstream |
22:11.18 | khem | robtaylor: what needs to be done on git server to enable git:// |
22:11.20 | robtaylor | khem: read only, of course |
22:11.29 | robtaylor | khem: and one for dev |
22:11.40 | khem | robtaylor: it will mostly be pull model |
22:11.46 | Soopaman1 | is there an easy way to test if bitbake has been installed correctly? |
22:11.54 | khem | so devs will clone in and send patches wont push directly |
22:11.57 | robtaylor | khem: well, i'd need more info to talk you through that. what distro? |
22:12.04 | khem | ubuntu |
22:12.21 | khem | do I need git-daemon |
22:12.35 | robtaylor | khem: yep |
22:12.54 | robtaylor | khem: there's a bit of trickyness with permissions etc |
22:13.04 | khem | I have apache running |
22:13.19 | khem | so probably I can hook in cgit too |
22:13.40 | robtaylor | khem: the easiest thing is to make a single git user, and have all your devs put their public keys in /home/git/.ssh/authorized_keys |
22:13.44 | *** join/#oe neilm (~neil@s64-180-61-141.bc.hsia.telus.net) |
22:14.05 | robtaylor | khem: the issue is,I can't really point to a simple how to-guide |
22:14.13 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
22:14.39 | robtaylor | khem: a bit of googling will give you some useful inputs though. |
22:15.04 | robtaylor | khem: might be gitosis is a good option |
22:15.05 | khem | robtaylor: yeah probably I need gitolite or somesuch |
22:16.04 | robtaylor | khem: sounds like you've got a good handle on it now ;) good luck! |
22:16.15 | khem | thx |
22:17.49 | neilm | where does the r100 in uImage-2.6.36-r100-overo.bin come from? |
22:17.59 | Soopaman1 | is there any way I can track down the cause of an "error: printing the evironment of the function" error? googling and searching the wiki haven't given much help |
22:18.04 | khem | nelim: Its PR |
22:18.13 | khem | probably look in conf/ |
22:18.18 | khem | for omap machines |
22:18.33 | khem | Soopaman1: some python error prolly |
22:19.26 | neilm | all I can find is MACHINE_KERNEL_PR = "" |
22:20.33 | khem | look in machine/include/omap3.inc |
22:21.13 | Tartarus | hey khem |
22:21.16 | neilm | MACHINE_KERNEL_PR = "r97" |
22:21.27 | khem | Tartarus: howdy |
22:21.33 | Tartarus | If I said I wanted to put --hash=both for -cross/-native stuff, would you kill me? :) |
22:21.46 | Tartarus | RHEL5 defaults to --hash=gnu which doesn't run on RHEL4 |
22:22.01 | khem | EOL it |
22:22.09 | Tartarus | 2012 |
22:22.12 | khem | hmm |
22:22.13 | Tartarus | is EOL for RHEL4 |
22:22.24 | khem | hmmm |
22:22.26 | Tartarus | So gcc-cross-sdk for example won't work on RHEL4 w/o that kind of change |
22:22.28 | Soopaman1 | khem: using python 2.6.6 on ubuntu 10.10 which seems to be kosher in the req page |
22:22.31 | khem | its getting to be like cygwin |
22:22.37 | Tartarus | I'll let you think for a little, heh |
22:22.45 | Tartarus | If we need to carry it forward locally that's fine too |
22:22.51 | khem | Tartarus: there is some penalty |
22:23.13 | khem | and since we already suffer with long build times I would ask you to measure build times |
22:23.32 | khem | with both as well as gnu |
22:23.57 | B_Lizzard | Does bitbake default to fetching the "master" branch if the branch name given in the recipe doesn't exist? |
22:24.13 | khem | B_Lizzard: I would think so |
22:24.36 | khem | Tartarus: in theory it should not be that bad but measuring is probably right thing |
22:24.39 | B_Lizzard | Does git or bitbake emit a log? |
22:24.41 | B_Lizzard | :/ |
22:24.58 | khem | B_Lizzard: there should be log.do_<task> |
22:25.02 | khem | in your build tree |
22:25.07 | B_Lizzard | OK |
22:25.09 | Tartarus | khem, you mean =both vs system default? |
22:25.10 | khem | if you have enabled QA_LOG |
22:25.12 | B_Lizzard | Thanks. |
22:25.23 | khem | Tartarus: =both and =gnu |
22:25.47 | B_Lizzard | I think it's some issue in the git repo because it stopped working after a rebase or something like that |
22:25.49 | B_Lizzard | Sucky |
22:25.49 | nschle85 | hello, I heard abaout that OE repository will be split in different repositories. Where can I read about It and what will happen with openembedded repo ? |
22:26.17 | khem | nschle85: there is some email from RP in detail about it |
22:26.20 | khem | on oe ml |
22:26.36 | khem | nschle85: and more details on openembedded-core ml |
22:26.39 | robtaylor | oh, that's good news |
22:30.53 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * rc4328e5c5e 10bitbake.git/lib/bb/cooker.py: (log message trimmed) |
22:30.54 | CIA-47 | bitbake/cooker: add generateTargetsTree method |
22:30.54 | CIA-47 | The generateTargetsTree() command needs to return a model which includes more |
22:30.54 | CIA-47 | metadata than the one generated by generateDepTree(). |
22:30.54 | CIA-47 | This patch adds a new method generateTargetsTreeData() to the cooker, based |
22:30.54 | CIA-47 | on generateDepData(), and switches generateTargetsTree() to use it. |
22:30.55 | CIA-47 | (From Poky rev: dcfc5ae7b1f5925587b0675e1cba6c60f098267c) |
22:30.57 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * red9178cc40 10bitbake.git/lib/bb/ (command.py cooker.py event.py): (log message trimmed) |
22:30.58 | CIA-47 | implement command to get all possible targets and their dependencies |
22:30.58 | CIA-47 | Add a new command generateTargetsTree() which returns a dependency tree of |
22:30.58 | CIA-47 | possible targets (tasks and recipes) as well as their dependency information. |
22:30.58 | CIA-47 | Optional parameter 'klass' also ensures any recipes which inherit the |
22:30.58 | CIA-47 | specified class path (i.e. 'classes/image.bbclass') are included in the model |
22:30.58 | CIA-47 | (From Poky rev: 1b3eb0c35f504e8f652303a4b238034ecc5c5d02) |
22:30.59 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * rb8cfc85ddc 10bitbake.git/lib/bb/cooker.py: (log message trimmed) |
22:31.00 | CIA-47 | bitbake/cooker: reduce code duplication |
22:31.11 | CIA-47 | introduce crumbs.TaskListModel a gtk.ListStore subclass |
22:31.11 | CIA-47 | Provide a gtk.ListStore subclass which includes a function, |
22:31.18 | CIA-47 | populate(), which takes as input the data emitted by |
22:31.18 | CIA-47 | bb.event.TargetsTreeGenerated and fills the ListStore model |
22:31.18 | CIA-47 | appropriately. |
22:31.18 | CIA-47 | Furthermore convenience functions are provided by which the caller can |
22:31.18 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * r4a2fb1b550 10bitbake.git/lib/bb/event.py: |
22:31.18 | CIA-47 | bitbake/event: fix some whitespace issues |
22:31.18 | CIA-47 | (From Poky rev: b14cda62d075d1213fc4769aa6b3622a491b57d5) |
22:31.19 | CIA-47 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
22:31.20 | CIA-47 | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
22:31.29 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * r97c405f0d7 10bitbake.git/lib/bb/ui/crumbs/progress.py: (log message trimmed) |
22:31.29 | CIA-47 | bitbake/progress: add method to pulse the progress bar |
22:31.29 | CIA-47 | When we're running a long operation with indeterminate duration it's useful |
22:31.29 | CIA-47 | to use the gtk.ProgressBar's pulse method to show that something is happening |
22:31.30 | CIA-47 | but we don't know how long it will take. |
22:31.30 | CIA-47 | (From Poky rev: fb62c54e13e875dd81e0b5220c54a7753b4d5fa2) |
22:31.31 | CIA-47 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
22:31.42 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * ref1ba91719 10bitbake.git/lib/bb/cache.py: |
22:31.42 | CIA-47 | bitbake/cache: store a list of inherited files in the cache |
22:31.42 | CIA-47 | (From Poky rev: 920c402342bd490cd94b365c3e151de735dec0d6) |
22:31.42 | CIA-47 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
22:31.42 | CIA-47 | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
22:31.54 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * rf491f1fd60 10bitbake.git/lib/bb/cooker.py: (log message trimmed) |
22:31.54 | CIA-47 | bitbake/cooker: don't drop possible_world ref count |
22:31.54 | CIA-47 | We need this if we want to run the buildWorldTargetList function more than |
22:31.54 | CIA-47 | once, for example in a UI where we can change the MACHINE and DISTRO as much |
22:31.54 | CIA-47 | as we like before triggering a build. |
22:31.54 | CIA-47 | (From Poky rev: c2814caa5d80d3a1097c83b82b7a3f8eeb8da548) |
22:31.55 | CIA-47 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
22:31.57 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * rc2ee2b71ec 10bitbake.git/lib/bb/ui/ (crumbs/hobeventhandler.py hob.py): |
22:31.57 | CIA-47 | Add new UI hob, a prototype Gtk+ GUI for creating images |
22:31.57 | CIA-47 | Hob is a first stab at implementing an interactive GUI for BitBake. |
22:31.57 | CIA-47 | (From Poky rev: 6dbceb0be9a1b8d7d5124b4fbd74f18609bc6146) |
22:31.57 | CIA-47 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
22:31.58 | CIA-47 | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
22:31.59 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * rc72ad4fdeb 10bitbake.git/lib/bb/ui/crumbs/__init__.py: |
22:32.00 | CIA-47 | bitbake/crumbs: update documentation header |
22:32.00 | CIA-47 | (From Poky rev: 7f8aa691c52547ee5f1272a7931ca9cccd1a120a) |
22:32.17 | CIA-47 | 03Joshua Lock <josh@linux.intel.com> 07master * r42cfa8e261 10bitbake.git/lib/bb/ui/crumbs/progress.py: |
22:32.18 | CIA-47 | bitbake/progress: make progress dialog modal for parent window |
22:32.18 | CIA-47 | (From Poky rev: f258cedfe8432d61eebd21a239381e9510be7109) |
22:32.18 | CIA-47 | Signed-off-by: Joshua Lock <josh@linux.intel.com> |
22:32.18 | CIA-47 | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
22:50.59 | *** join/#oe lamawithonel (~lucas@pool-96-240-135-33.washdc.fios.verizon.net) |
23:00.17 | fray | they keep pushing out the ELF for RHEL4.. I wouldn't be surprised if someone pays RH enought to push out the EOL past 2012 |
23:05.03 | Tartarus | heh |
23:05.06 | Tartarus | So I'm not crazy |
23:05.12 | Tartarus | I thought it was already gone, but had to check today |
23:05.26 | fray | original EOL was end of 2010 |
23:05.44 | fray | rumor (I heard) was that some big company paid them a lot of money in a 2 year extension.. |
23:06.04 | Tartarus | I know that's always been possible, but I assumed it would be kept private |
23:06.41 | fray | the rumor was it was a large enough support deal that a stipulation was that they continue public support as well.. (for this companies customers).. and no I have no idea who that company is |
23:09.45 | ReaperOfSouls | wonders how much that extra two years cost. |
23:09.57 | fray | I'm guessing someone's soul (at RH) |
23:11.24 | ReaperOfSouls | Well it prolly crushed someone's soul, not sure about cost them. |
23:11.57 | Soopaman1 | heh |
23:13.08 | Soopaman1 | goodness, now i'm starting to remember how frustrating bitbake is |
23:13.35 | Soopaman1 | if not bitbake, just getting it to "work" |
23:26.48 | CIA-47 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * rf54d43fc6d 10openembedded.git/recipes/kexecboot/ (kexecboot-klibc_git.bb kexecboot_git.bb): |
23:26.48 | CIA-47 | kexecboot: bump to SRCREV 1464e897e416f7458e93fb30148e87e60509a667 |
23:26.48 | CIA-47 | * adds new icons and fonts, logs, text-ui, multiple kernels per partition |
23:26.48 | CIA-47 | * bump PR |
23:26.48 | CIA-47 | Signed-off-by: Andrea Adami <andrea.adami@gmail.com> |
23:26.59 | CIA-47 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * re8a78acb1e 10openembedded.git/recipes/kexecboot/kexecboot-cfg_0.1.bb: |
23:26.59 | CIA-47 | kexecboot_cfg: update boot.cfg example to sync with kexecboot. |
23:26.59 | CIA-47 | * clean some cmdline cruft |
23:26.59 | CIA-47 | * bump PR |
23:27.00 | CIA-47 | Signed-off-by: Andrea Adami <andrea.adami@gmail.com> |
23:27.01 | CIA-47 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r60ede7b913 10openembedded.git/recipes/kexecboot/kexecboot.inc: |
23:27.01 | CIA-47 | kexecboot.inc: update configure options. |
23:27.01 | CIA-47 | * --enable-evdev-rate default is disabled so readd it to Zaurus machines |
23:27.02 | CIA-47 | Signed-off-by: Andrea Adami <andrea.adami@gmail.com> |
23:30.23 | CIA-47 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r5da6fe894b 10openembedded.git/recipes/kexecboot/kexecboot.inc: |
23:30.23 | CIA-47 | kexecboot.inc: fix typo. |
23:30.23 | CIA-47 | Signed-off-by: Andrea Adami <andrea.adami@gmail.com> |
23:37.44 | CIA-47 | 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r688d359b9c 10openembedded.git/recipes/linux/linux-kexecboot.inc: |
23:37.44 | CIA-47 | linux-kexecboot.inc: bump PR to follow kexecboot changes. |
23:37.44 | CIA-47 | Signed-off-by: Andrea Adami <andrea.adami@gmail.com> |
23:46.43 | *** join/#oe Jefro (~josiermi@nat/intel/x-ryluuktdorqwbcya) |