| 00:01.41 | *** join/#oe risca (~risca@m77-219-169-156.cust.tele2.se) |
| 00:32.21 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 00:34.26 | *** join/#oe Jefro (~josiermi@134.134.137.75) |
| 00:43.27 | *** join/#oe notespace (~notespace@barracuda.ventureresearch.com) |
| 01:14.52 | *** join/#oe rje`cf (~rje@c-67-161-99-149.hsd1.wa.comcast.net) |
| 01:39.57 | *** join/#oe hufnus (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 02:18.15 | *** join/#oe julianpid (~julianpid@62.200.22.2) |
| 02:19.43 | *** join/#oe joelagnel (~joel@nat/ti/x-jxcvgdvenvedhxao) |
| 02:35.37 | *** join/#oe Circuitsoft (40f4c0e2@gateway/web/freenode/ip.64.244.192.226) |
| 02:35.52 | Circuitsoft | Anyone know where I can get the source for psplash? |
| 02:38.17 | kergoth_ | cbrake: how are you liking submodules, out of curiosity? |
| 02:49.54 | Circuitsoft | It looks like it has disappeared since Intel took over. |
| 02:56.23 | *** join/#oe kergoth` (~kergoth@ip24-251-167-38.ph.ph.cox.net) |
| 03:04.10 | *** join/#oe kergoth` (~kergoth@ip24-251-167-38.ph.ph.cox.net) |
| 03:04.40 | *** join/#oe devzero_ (devzero@xdsl-89-0-129-235.netcologne.de) |
| 03:05.13 | *** join/#oe galak (~galak@192.88.168.34) |
| 03:50.13 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 04:04.55 | *** join/#oe eephillip (~eephillip@pdpc/supporter/student/eephillip) |
| 04:05.04 | *** join/#oe kergoth` (~kergoth@ip24-251-167-38.ph.ph.cox.net) |
| 04:47.32 | *** join/#oe joelagnel (~joel@nat/ti/x-peribwtwpwimokyb) |
| 04:48.12 | *** join/#oe msm (~msm@c-98-195-77-8.hsd1.tx.comcast.net) |
| 04:58.37 | *** join/#oe snkt (~snkt@114.143.160.125) |
| 05:04.46 | *** join/#oe snkt (~snkt@114.143.160.125) |
| 05:29.30 | *** join/#oe erwt (~rahul@114.143.160.125) |
| 05:36.22 | *** join/#oe reisei (~reisei@n41-as54-1-ppp206.nordnet.ru) |
| 06:25.40 | *** join/#oe anarsoul (~anarsoul@193.151.42.171) |
| 06:28.48 | *** join/#oe tasslehoff (~Tasslehof@147.84-49-231.nextgentel.com) |
| 06:34.35 | Jay7 | Circuitsoft: http://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/ |
| 06:43.30 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
| 07:19.46 | *** join/#oe risca (~risca@m83-189-153-165.cust.tele2.se) |
| 07:25.47 | eFfeM_work | gm |
| 07:35.23 | eFfeM_work | khem, snippet of info on my uclibc issue: I made sure to remove all -Os when compiling, now the static linked hello world exe builds and prints hello world but does not exit. Next step is to rebuild all with the 2011.03 maintenance branch |
| 07:51.58 | *** join/#oe rob_w (~bob@host-188-174-172-122.customer.m-online.net) |
| 08:02.41 | *** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust439.2-4.cable.virginmedia.com) |
| 08:02.41 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:13.35 | mckoan | good morning |
| 08:18.59 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 08:21.12 | eFfeM_work | hi mckoan |
| 08:25.01 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 08:31.15 | *** join/#oe zecke (~ich@91-65-246-230-dynip.superkabel.de) |
| 08:36.01 | *** join/#oe SterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220) |
| 08:37.05 | *** join/#oe stomach_contents (~xris@89.244.106.162) |
| 08:37.46 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
| 08:42.56 | *** join/#oe artib (~artib@122.166.11.13) |
| 08:43.55 | artib | hey all, my linux-omap_2.6.39.bb recipe is failing to clone the linux-omap2.6.git |
| 08:44.05 | artib | from git.kernel.org |
| 08:44.47 | artib | is thr any another repo where i can find linux-omap2.6 git? |
| 08:51.06 | *** join/#oe rschus (~rschus@fb-n15-11.unbelievable-machine.net) |
| 08:51.53 | stomach_contents | hi guys. I'm using Angstrom to bitbake virtual/kernel and I'm getting this: |
| 08:51.55 | stomach_contents | NOTE: Error expanding variable toolchain_create_sdk_version############################################ | ETA: 00:01:25 |
| 08:51.55 | stomach_contents | ERROR: Failure expanding variable METADATA_REVISION, expression was ${@base_detect_revision(d)} which triggered exception OSError: [Errno 12] Cannot allocate memory |
| 08:51.55 | stomach_contents | ERROR: Command execution failed: Exited with 1 |
| 08:52.36 | stomach_contents | Fresh 'install' of Angstrom.. followed instructions to the T. |
| 08:54.05 | stomach_contents | I'm running Debian 6. |
| 08:54.11 | stomach_contents | Any help would be greatly appreciated. |
| 08:58.20 | *** join/#oe stefan_schmidt (~stefan@2001:638:602:1183:f2de:f1ff:fe62:28f7) |
| 08:59.49 | JaMa|Off | stomach_contents: looks like wrong /dev/shm or /run/shm permissions |
| 09:01.19 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 09:01.34 | stomach_contents | JaMa|Off: erm. ok. will check.. Doesn't seem to happen immediately. There's a delay then it fails. Almost like a stack overflow or summin.. but will check shm |
| 09:07.11 | JaMa|Off | maybe it's really lack of free memory.. |
| 09:09.26 | stomach_contents | i recon its a bug in some script. looking at it now. 3 bitbakes get spawned while it's 'parsing recipes' by the looks of things. 1 is chowing 90% CPU and my RAM is indeed about to run out. |
| 09:10.13 | stomach_contents | arg.. death. |
| 09:12.00 | stomach_contents | how much RAM should bitbake need do you think? |
| 09:12.04 | *** join/#oe lamikr (lamikr@nat/nokia/x-fuqfpplaogztgzjo) |
| 09:14.33 | stomach_contents | Looks like a memory leak. I'm at 44% through parsing recipes and it hasn't freed up any RAM. Would bitbake load everything into RAM while parsing recipes? |
| 09:18.43 | JaMa|Off | stomach_contents: something like 3GB is quite common, but removing tmp/cache/bb_codeparser* files helps a lot (especially when you're building for multiple machines) |
| 09:22.34 | stomach_contents | i'll try that. my VM had 512mb or ram. Wonder if this is a bug or if bitbake really needs to keep the recipes in ram. |
| 09:30.19 | stomach_contents | JaMa|Off: Dude. you rock. |
| 09:30.47 | stomach_contents | Jama|Off: It was simply that. Insufficient ram for this insane bloatware! Thanks!!! |
| 09:31.14 | stomach_contents | Jama|Off: Guess sometimes I should just take the error message at face value. :) |
| 09:32.22 | JaMa|Off | yes with 512MB in VM it's good idea :) |
| 09:32.59 | stomach_contents | Jama|Off: first linux app ever that's run out of memory. |
| 09:33.20 | stomach_contents | Jama|Off: After all, this isn't M$ remember :P |
| 09:35.19 | stomach_contents | Jama|Off: Do you know much about building the Gumstix Overo stuff? Got a nasty error there too, but not RAM related. |
| 09:57.00 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 10:05.03 | *** join/#oe florian (~fuchs@port-217-146-132-69.static.qsc.de) |
| 10:05.04 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 10:07.27 | *** join/#oe rschus (~rschus@fb-n15-11.unbelievable-machine.net) |
| 10:11.06 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 10:18.36 | ant_work | pb_: heh, your lead_soname crusade ;) |
| 10:22.43 | *** join/#oe pespin (~pespin@90.163.81.250) |
| 10:23.52 | pb_ | heh |
| 10:24.03 | pb_ | yeah, I wish that mechanism had never been invented |
| 10:24.07 | *** join/#oe GarthPS (~quassel@qrc29-1-82-245-206-103.fbx.proxad.net) |
| 10:24.12 | pb_ | it was such a dumb idea |
| 10:26.16 | *** join/#oe ChrisD1 (~ChrisD@dsl-217-155-59-204.zen.co.uk) |
| 10:26.41 | pwgen | anyone an idea how to get matchbox-stroke compiled ? it's complaining on missing XRenderFillRectangle |
| 10:27.28 | pb_ | is it linking with -lXrender? |
| 10:28.41 | stefan_schmidt | pwgen: there is a patch for this from khem on the oe-core list |
| 10:28.42 | ant_work | http://patchwork.openembedded.org/patch/15159/ ? |
| 10:28.49 | stefan_schmidt | ant_work: fast guy :) |
| 10:29.08 | ant_work | heh, I've read it earlier this morning ;) |
| 10:32.50 | ant_work | btw it did compile (core-image-sato) without this patch on my host. I even tried to run it but it was seemingly broken |
| 10:32.59 | ant_work | this was last week |
| 10:48.45 | *** join/#oe pepermint (~pepermint@host247-82-dynamic.2-87-r.retail.telecomitalia.it) |
| 10:49.16 | *** join/#oe zecke (~ich@91-65-246-230-dynip.superkabel.de) |
| 10:50.58 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 10:51.19 | mickey|office | florian: denix Crofton: how about a board meeting this week? |
| 10:51.36 | stefan_schmidt | mickey|office: hi! How are you? |
| 10:52.16 | florian | hi mickey|office |
| 10:52.23 | florian | mickey|office: might be a good idea |
| 10:52.40 | mickey|office | stefan_schmidt: apart from a bunch of problems with my aging body, i'm feeling excellent. you? |
| 10:53.05 | stefan_schmidt | mickey|office: feeling got as well. Studies done. :) |
| 10:53.17 | mickey|office | yay! |
| 10:53.35 | stefan_schmidt | mickey|office: And due to some more sports in the last months I also having a better fitness again |
| 10:54.10 | stefan_schmidt | mickey|office: Jan is done as well. Daniel still needs some months but is already on his thesis (last part) |
| 10:57.49 | *** join/#oe shoragan (~shoragan@debian/developer/shoragan) |
| 10:59.19 | *** join/#oe rschus (~rschus@fb-n15-11.unbelievable-machine.net) |
| 10:59.35 | *** join/#oe errordeveloper (~Dmitriche@host86-166-62-242.range86-166.btcentralplus.com) |
| 10:59.42 | errordeveloper | hm |
| 11:00.16 | errordeveloper | I was wondering if anyone had tried to use FreeBSD for an embedded system? |
| 11:00.37 | *** part/#oe stomach_contents (~xris@89.244.106.162) |
| 11:03.14 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 11:03.15 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 11:07.42 | *** join/#oe artib (~artib@122.166.11.13) |
| 11:13.57 | patrickg | errordeveloper: like juniper? |
| 11:15.41 | *** join/#oe artib (~artib@122.166.11.13) |
| 11:36.22 | zecke | patrickg: i thought they use/sponsor NetBSD? |
| 11:39.49 | patrickg | http://www.freebsdnews.net/2008/07/23/junipers-junos-freebsd-based-router-operating-system/ claims freebsd |
| 11:52.28 | *** join/#oe vivijim (~vivijim@unaffiliated/vivijim) |
| 11:57.36 | errordeveloper | is juniper using OE? |
| 11:58.39 | errordeveloper | well, I mean I was actually going to ask 'has anyone tried to write a recipe for freebsd kernel' ? |
| 11:58.47 | errordeveloper | would be quite interesting I suppose ... |
| 11:59.06 | errordeveloper | OE shouldn't be limited to linux I think :) |
| 11:59.11 | Crofton|work | guys, stay clear of Alabama :) |
| 11:59.20 | Crofton|work | http://www.economist.com/blogs/democracyinamerica/2011/11/unintended-consequences?fsrc=scn/tw/te/bl/niceonealabama |
| 11:59.40 | pb_ | I don't think anybody has written a *BSD kernel recipe for oe but I agree that it would be an interesting thing to try. |
| 12:00.35 | pb_ | You'd need to make a decision about whether to try to run BSD libc (etc) on top of it, or port eglibc to the BSD kernel. Glibc did use to have some level of bsd support but I think it is bit-rotten and maybe deleted nowadays. |
| 12:02.18 | pb_ | Porting the bsd libc is probably the easier option, I guess. |
| 12:02.38 | pb_ | on the subject of libcs, has anybody written a recipe for MUSL? |
| 12:03.14 | patrickg | debian/kfreebsd uses glibc, no? |
| 12:03.40 | errordeveloper | pb_: hm, I rember booting a debian kFreeBSD image just a month ago or so |
| 12:03.46 | pb_ | oh yeah, so they do |
| 12:03.50 | errordeveloper | it was recent (iirc) |
| 12:04.22 | pb_ | so in that case, yes, it should be straightforward to do in oe too |
| 12:04.23 | errordeveloper | I would imagine that bsd libc is not as fat as glibc |
| 12:04.42 | pb_ | right, bsd libc is smaller but does less stuff |
| 12:04.48 | errordeveloper | I thing gentoo should work also .. |
| 12:08.28 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 12:15.46 | florian | pb_: At least I remember someone mentioned MUSL some time ago in one of the embedded channels... |
| 12:15.56 | *** join/#oe Z3r0l3g (~Oleg@ip-195-88-138-71.dss-group.net) |
| 12:18.48 | *** join/#oe zecke (~ich@91-65-246-230-dynip.superkabel.de) |
| 12:20.12 | pb_ | yeah, it sounds quite cool from what the webpage says |
| 12:20.34 | pb_ | less big than glibc, less demented than klibc and uclibc |
| 12:21.13 | *** join/#oe rob_w (~bob@93.104.205.194) |
| 12:24.55 | Crofton|work | mickey|office, this week is a holiday in .us |
| 12:25.20 | Crofton|work | maybe Friday, or early Monday, since I will be traveling the rest of next week |
| 12:45.30 | CIA-15 | 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * rb7114d8e5d 10bitbake.git/lib/bb/runqueue.py: (log message trimmed) |
| 12:45.31 | CIA-15 | runqueue.py: Ensure setscene tasks don't break dependency order |
| 12:45.31 | CIA-15 | If A depends upon B which depends upon C and the setscene for B |
| 12:45.31 | CIA-15 | succeeds but C is going to get rebuilt, we should wait for C to |
| 12:45.31 | CIA-15 | try and build A but currently we don't. |
| 12:45.31 | CIA-15 | This is due to the timing of when we run the task_skip() as this |
| 12:45.32 | CIA-15 | triggers other tasks to become buildable. This patch moves the timing |
| 12:52.12 | *** join/#oe snkt (~snkt@114.143.160.125) |
| 12:55.32 | bluelightning | Crofton|work: sad to see the US sliding further towards a "papers please" society :/ |
| 12:58.35 | Crofton|work | :) |
| 12:58.46 | Crofton|work | bluelightning, you have a moment |
| 12:58.54 | bluelightning | Crofton|work: sure thing |
| 12:59.50 | Crofton|work | so the FindQt4 macro in cmake runs /qmake2 -query QT_INSTALL_HEADERS |
| 13:00.07 | Crofton|work | which returns paths in the x86 sysroot |
| 13:00.43 | Crofton|work | it seems like we need to tell cmake to use a different spc file I think |
| 13:02.23 | Jin^eLD | hmm, in newer OE util-linux-ng was renamed to util-linux, what's the best way to do a live upate fro old to new? RREPLACES/RCONFLICTS magic or something with PROVIDES? the recipe spits out tons of packages, would I need to define a RREPLACES for each of them? |
| 13:03.57 | JaMa|Off | nobody cares about upgrade path from OE-classic to new layers, so this would be only one of _many_ issues you will get |
| 13:05.08 | Jin^eLD | JaMa|Off: well, surprisingly it went mostly well |
| 13:05.24 | Jin^eLD | I found a sort of bug in opkg that forced me to rewrite some recipes to work around it |
| 13:05.36 | JaMa|Off | because you didn't notice PV/PR going backwards :) |
| 13:05.58 | Jin^eLD | ehm, no, why should PV go backwards? |
| 13:06.13 | Jin^eLD | my classic setup was two years old ;) |
| 13:06.29 | JaMa|Off | because oe-core has (at least had) some recipes in older version then what was in OE-classic when it was abandoned |
| 13:06.49 | Jin^eLD | well, I did not update classic for two years, so that problem did not hit me |
| 13:07.24 | Jin^eLD | a problem with opkg is where a package was "one" and in core got split into several; and because of the wrong order in which opkg tries to update such packages I got clashes |
| 13:07.38 | Jin^eLD | but luckily only for two packages, so that was managable |
| 13:08.19 | Jin^eLD | and now I also got a few that need to be completely replaced, I just wonder if there is some nicer way than specifying a gazillion of RREPLACES in the util-linux recipe |
| 13:08.35 | Jin^eLD | btw even live upgrade from glibc to eglibc worked out well |
| 13:13.17 | Crofton|work | bluelightning, http://www.mail-archive.com/cmake@cmake.org/msg37312.html |
| 13:14.08 | bluelightning | Crofton|work: hmm... no response to that one I see :/ |
| 13:14.41 | *** join/#oe tasslehoff (~Tasslehof@147.84-49-231.nextgentel.com) |
| 13:16.42 | Crofton|work | read the thread |
| 13:17.00 | Crofton|work | apparently we need to tell cmake where the stuff is really hard |
| 13:17.22 | Jin^eLD | how exactly does PROVIDES and RPROVIDES work? |
| 13:17.43 | Jin^eLD | whats the opkg behaviour when those settings are encountered? |
| 13:27.05 | ensc|w | using the opkg depsolver is complicated and not very well supported by the oe packaging style. opkg takes directory ownership into account, but because OE packages own every (parent) directory (e.g. '/' or '/usr') of shipped files, the package order is shuffled in an unpredicable way :( |
| 13:28.14 | Jin^eLD | grml :( |
| 13:28.41 | Jin^eLD | that does not sound too primising... |
| 13:28.57 | Jin^eLD | opkg-devel did not answer anything yet either |
| 13:29.30 | *** join/#oe risca (~risca@norr-133-190.eduroam.liu.se) |
| 13:35.02 | Jin^eLD | getVar(SOMEVAR, bool) what does the bool flag stand for? |
| 13:38.41 | ensc|w | expand-now; e.g. when there is written a='${FOO}', then getVar('a', false) == '${FOO}' and getVar('a', true) == getVar('FOO', true) holds |
| 13:39.44 | Jin^eLD | thanks |
| 13:42.56 | stefan_schmidt | hmm, I remember I have seen this before: http://pastebin.com/Wzi40n80 |
| 13:43.34 | stefan_schmidt | bitbake complains during rootfs build with file_md5sum_alloc can not open files, but files exist. |
| 13:43.43 | stefan_schmidt | Anyone has an idea about this? |
| 13:44.09 | stefan_schmidt | its an oe-core build with ansgtrom setup-scripts and a own layer for the image and some extra recipes |
| 13:44.37 | Jin^eLD | I only know what the opkg means by file_md5sum_alloc, have not seen this error during image generation though |
| 13:45.08 | Jin^eLD | it's not a fatal opkg error anyway; if a file that was defined as CONFFILE in the old package is no longer a CONFFILE or no longer there in the new package opkg will give this message |
| 13:45.22 | Jin^eLD | but no clue why you are getting it during rootfs generation and if it is relevant for you at all |
| 13:45.42 | stefan_schmidt | Jin^eLD: hmm, ok |
| 13:46.05 | stefan_schmidt | Jin^eLD: I have the feeling I have seen this before and it turned out not to be the problem for the failing of the rootfs |
| 13:46.26 | stefan_schmidt | Jin^eLD: Maybe I'm hunting the wrong problem again. Will have another look at the whole log file :) |
| 13:50.02 | bluelightning | Crofton|work: have you got a reasonably simple example so I can play around with this? |
| 13:50.46 | Crofton|work | not really |
| 13:50.51 | Crofton|work | just gnuradio |
| 13:50.59 | Crofton|work | I can send you the recipe |
| 13:51.11 | Crofton|work | I am trying to inspire myself to try some things |
| 13:51.19 | Crofton|work | but it is a holiday week here :) |
| 13:51.23 | bluelightning | Crofton|work: that would be helpful thanks |
| 13:51.49 | bluelightning | right, yeah, you probably shouldn't be working I guess :) |
| 13:54.48 | Crofton|work | well, motivation is hard :) |
| 13:55.00 | Crofton|work | and it is early and I should have stayed in bed :) |
| 13:56.03 | PaulePanter | <http://planet.linuxtogo.org/> just shows a blank page for me. Can somebody check that please. |
| 13:56.39 | florian | hrm again? |
| 13:56.45 | florian | shoots ltg |
| 13:56.52 | florian | shoots planetplanet |
| 13:57.29 | *** join/#oe kergoth` (~kergoth@ip24-251-167-38.ph.ph.cox.net) |
| 13:58.09 | PaulePanter | florian: So it is not just me. Thank you for confirming this. |
| 13:58.43 | florian | fixes |
| 13:58.58 | *** join/#oe galak (~galak@192.88.168.34) |
| 13:59.39 | florian | looks better |
| 14:11.09 | PaulePanter | florian: Thank you. It works for me now. |
| 14:17.31 | *** join/#oe pespin (~pespin@cisne-cn10.upc.es) |
| 14:17.53 | kergoth` | morning |
| 14:19.08 | kenws | Hi there, My OE-Core build is failing because it could not fetch guilt-0.33.tar.gz from kernel.org. Can I just copy the tarball into the downloads directory and the build process will recognize it? |
| 14:19.21 | kergoth` | yep |
| 14:19.57 | kenws | ok, thanks! |
| 14:21.31 | florian | hi kergoth` |
| 14:23.59 | cbrake | kergoth`: re submodules -- they seem to be a good fit for product build systems were it is very important to control what sources are being used, and the fact that it is built into git has several advantages. |
| 14:24.10 | cbrake | kergoth`: one is that git status will tell you the status of your tree and submodules |
| 14:30.51 | *** join/#oe jmpdelos (~polk@delos.delos.com) |
| 14:43.48 | kenws | It looks like oe fails on many of the kernel.org tarballs (module-init-tools, utils-linux, ...). How do you handle that? One way would be to just dowload the files manually but maybe it's easier to add another mirror or something like this!? |
| 14:44.16 | kenws | s/fails on/fails on downloading/ |
| 14:46.00 | kenws | ah, I just found KERNELORG_MIRROR within meta/classes/mirrors.bbclass |
| 14:48.15 | *** join/#oe mhnoyes (~mhnoyes@74-38-53-240.dr01.myck.or.frontiernet.net) |
| 14:48.16 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 14:52.36 | kergoth` | try KERNELORG_MIRROR = "http://mirror.nexcess.net/kernel.org/" |
| 14:57.38 | *** join/#oe kergoth` (~kergoth@ip24-251-167-38.ph.ph.cox.net) |
| 14:59.00 | kenws | kergoth: yep, thanks! I just added another mirror and bitbake goes further |
| 14:59.09 | mckoan | kergoth`: looks like this is becoming a FAQ, maybe is time to add some new mirror in classes/mirrors.bbclass ;-) |
| 14:59.49 | pb_ | yeah, or just change the default one |
| 14:59.54 | kergoth` | also, having so many redundant mirrors in mirrors.bbclass is stupid. there are two conceptual types of mirrors, one is archival, one is location based for performance. we have a ton of the latter in the variable intended for the former |
| 15:00.12 | *** join/#oe rob_w (~bob@host-188-174-172-122.customer.m-online.net) |
| 15:00.12 | kergoth` | maybe at least cut down to just one for each to cover the case where the default server is down |
| 15:00.12 | pb_ | honestly, what is it with kernel.org? it must be three months now that their data has been offline. |
| 15:00.20 | kergoth` | good question, it's crazy |
| 15:04.11 | *** join/#oe DJWillis (~djwillis@cpc1-bath5-2-0-cust122.aztw.cable.virginmedia.com) |
| 15:05.11 | *** join/#oe devzero_ (devzero@xdsl-89-0-156-208.netcologne.de) |
| 15:06.10 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 15:08.41 | kenws | nods |
| 15:08.48 | ant_work | pb_: only uclibc syslinux and module-init tools are back |
| 15:09.11 | ant_work | I know HPA is still waiting to have klibc back |
| 15:10.22 | ant_work | wow.. klibc.git *is* back |
| 15:12.09 | ant_work | he, hpa has real cow powers ;) |
| 15:13.18 | *** join/#oe pxx42 (~qwerty@203.115.73.79) |
| 15:15.28 | kergoth | https://github.com/kergoth/homefiles/blob/master/oe/classes/mirrors.bbclass is what I'm using for my personal builds nowadays |
| 15:17.49 | kenws | ant_work: the module-init-tools dir is there on kernel.org but it's lacking the module-init-tools-3.16.tar.bz2 - so my oe-core build failed on this one too : ) |
| 15:17.58 | ant_work | lol |
| 15:18.17 | ant_work | I was bit by tzdata2001g last time... |
| 15:18.52 | ant_work | that's really *theƩ most asked sort of questions here lately |
| 15:24.21 | kenws | What's the issue with tzdata2001g? |
| 15:26.00 | *** join/#oe joelagnel (~joel@nat/ti/x-jcugcncnuzbofuwh) |
| 15:26.43 | *** join/#oe joelagnel (~joel@nat/ti/x-ppgixxxeratgbpfd) |
| 15:27.51 | recalcati | Hi all, I'm compiling MACHINE=beagleboard ./oebb.sh bitbake systemd-gnome-image, I get fetch pb on connman-gnome_0.5.bb: http://pastebin.com/psmz5hDT |
| 15:30.12 | ant_work | kenws: *2001g is in meta-oe but isn't fetchable |
| 15:33.15 | kenws | ant_work: ah ok, and what's the solution? |
| 15:33.47 | ant_work | ideally we use the one, more recent, in oe-core |
| 15:34.16 | ant_work | though, the meta-oe maintainer insists the reipes in meta-oe are better |
| 15:34.38 | ant_work | there is a thread in the mailing list |
| 15:34.56 | *** join/#oe kergoth` (~kergoth@ip24-251-167-38.ph.ph.cox.net) |
| 15:35.28 | ant_work | in the meanwhile I remove the meta-oe recipes ;) |
| 15:35.48 | *** join/#oe kergoth` (~kergoth@ip24-251-167-38.ph.ph.cox.net) |
| 15:36.36 | kenws | Ok, I have't used the oe-meta layer yet. I thought oe-meta provides only additional stuff to oe-core. |
| 15:36.51 | ant_work | unfortunately there are still some dupes |
| 15:37.59 | kenws | hm, even a eglibc is within recipes-core - strange |
| 15:38.12 | ant_work | oh, that's even worst imho |
| 15:38.26 | ant_work | is an old release dropped from oe-core and there for 'compatibility' |
| 15:38.56 | kenws | interesting |
| 15:41.00 | ant_work | well, there is hope is that more people will start using meta-oe layer... |
| 15:41.24 | ant_work | I've read some recent comments on yocto ML about that |
| 15:41.24 | kenws | just noticed recipes-devtools/gcc/gcc-4.6/linaro |
| 15:43.16 | *** join/#oe mwester (~mwester@209-242-7-157.rev.dls.net) |
| 15:43.16 | *** join/#oe mwester (~mwester@nslu2-linux/mwester) |
| 15:48.01 | *** join/#oe nitink (~nitink@nat/intel/x-fbsvgbgqsfyxbdyz) |
| 15:51.47 | *** join/#oe pespin (~pespin@cisne-cn08.upc.es) |
| 15:58.39 | CIA-15 | 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r61017fc5d3 10bitbake.git/lib/bb/runqueue.py: (log message trimmed) |
| 15:58.39 | CIA-15 | runqueue.py: Ensure we fully process the covered list |
| 15:58.39 | CIA-15 | The existing looping code can mask an existing "found = True" |
| 15:58.39 | CIA-15 | by forcing it to False each time. This can lead to dependency |
| 15:58.39 | CIA-15 | lists not being fully searched and results in dependency errors. |
| 15:58.40 | CIA-15 | An exmaple of this was the autobuilder building linux-yocto from |
| 15:58.41 | CIA-15 | sstate but then rebuilding some of the recipe's tasks for no |
| 16:12.23 | *** join/#oe gchiii (~gchiii@76.255.12.150) |
| 16:19.11 | *** join/#oe azariah4 (azariah@Tricholoma.Update.UU.SE) |
| 16:32.50 | Jin^eLD | I am trying to read -e output of bitbake eglibc in order to figoure out who or how the *-localedata-* packages are generated, but can't see how that happens |
| 16:32.51 | Jin^eLD | any hints? |
| 16:33.11 | Jin^eLD | I need to ad RREPLACES_each-localedata-package = "glibc-localedata-*" |
| 16:33.21 | Jin^eLD | well you get the idea |
| 16:35.02 | Jin^eLD | I solved my util-linux vs utli-linux-ng problem like this http://pastebin.mozilla.org/1387731 and now trying something similar for eglibc vs glibc |
| 16:36.27 | bluelightning | Jin^eLD: cool |
| 16:36.41 | bluelightning | it would be great if we could put everything needed into an oe-classic-pkg-compat.inc or similar so everyone can take advantage of this |
| 16:38.04 | Jin^eLD | bluelightning: once I finish the migration, which I hope I will this week, I'll get back to you then with some questions on how to make it all suitable for upstream OE :> |
| 16:38.12 | *** join/#oe HokieTux (~HokieTux@157.22.28.13) |
| 16:38.24 | bluelightning | Jin^eLD: sounds good |
| 16:39.24 | Jin^eLD | soo... any clues regarding eglibc? I can't find who or what defines those *localedata* packages |
| 16:42.42 | bluelightning | Jin^eLD: it's the result of do_split_packages in meta/classes/libc-package.bbclass |
| 16:42.55 | bluelightning | so it's dynamic based on the output of the build |
| 16:43.09 | bluelightning | that probably makes it harder for you :( |
| 16:44.07 | Jin^eLD | doh... indeed... so I guess I should override the libc-package.bbclass in my layer then |
| 16:46.08 | bluelightning | Jin^eLD: or just append to the eglibc recipe |
| 16:46.28 | bluelightning | or, you can even define the RREPLACES etc. at a distro level |
| 16:46.38 | Jin^eLD | can I overwrite a function from a bbclass in the recipe? |
| 16:49.10 | pb_ | yes |
| 16:51.41 | Jin^eLD | ..by just defining my own with the same name, or how does it work? |
| 16:51.50 | pb_ | yes, exactly that |
| 16:51.54 | Jin^eLD | thanks |
| 16:55.12 | Jin^eLD | :> |
| 17:11.49 | *** join/#oe joelagnel (~joel@cpe-76-184-244-226.tx.res.rr.com) |
| 17:13.25 | *** join/#oe zenlinux_ (~sgarman@c-67-170-181-205.hsd1.or.comcast.net) |
| 17:31.09 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 17:33.46 | *** join/#oe joelagnel (~joel@cpe-76-184-244-226.tx.res.rr.com) |
| 17:34.31 | *** join/#oe risca (~risca@norr-133-195.eduroam.liu.se) |
| 17:44.24 | *** join/#oe rcf (~rcf@211.94-243-81.adsl-dyn.isp.belgacom.be) |
| 17:46.55 | kergoth | Anyone looked into extending the patch support to handle series files and/or archives? |
| 17:49.28 | CIA-15 | 03Matthew McClintock <msm@freescale.com> 07master * rf1eb6d3dcc 10bitbake.git/lib/bb/siggen.py: |
| 17:49.28 | CIA-15 | bitbake: print out symmetric difference when comparing sigs |
| 17:49.28 | CIA-15 | This is useful for really longs lists to pinpoint what has |
| 17:49.28 | CIA-15 | actually changed |
| 17:49.28 | CIA-15 | Signed-off-by: Matthew McClintock <msm@freescale.com> |
| 17:49.29 | CIA-15 | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
| 17:49.30 | CIA-15 | 03Matthew McClintock <msm@freescale.com> 07master * r9a2029899c 10bitbake.git/lib/bb/siggen.py: (log message trimmed) |
| 17:49.31 | CIA-15 | siggen.py: sort task hash depedencies with basepath |
| 17:49.31 | CIA-15 | Without this patch the tash hash dependencies can be in a order |
| 17:49.31 | CIA-15 | that is dependent upon directory/filesystem layout. With this |
| 17:49.32 | CIA-15 | change the data is sorted the same regardless. |
| 17:49.32 | CIA-15 | Without this the dependent hashes could be in different orders |
| 17:49.33 | CIA-15 | on different systems and consequently final md5 hash would differ |
| 17:53.31 | kergoth | heh, RP__ and msm are doing a good job of getting all the bugs worked out of sstate, I can't believe how many issues there were |
| 17:53.48 | pb_ | yeah |
| 17:54.22 | pb_ | I've had a vague feeling of sstate-related unease for a while, due to the background level of complaints I get from my colleagues about bugs that "just go away after -c cleansstate", but never been able to pin down exactly what was wrong |
| 17:54.49 | RP__ | pb_: I've also been a bit unsettled by such reports |
| 17:55.01 | RP__ | Hopefully we're getting to the bottom of those issues |
| 17:55.05 | kergoth | of course, admittedly it's just a complex thing to be implementing, given how bitbake works. there were bound to be issues to work out |
| 17:55.11 | pb_ | right |
| 17:55.21 | kergoth | think it took me like a week and a half just to get the shell/python dependency scanning sorted |
| 17:55.24 | kergoth | heh |
| 17:55.44 | RP__ | I think the task_skip() change may make the world of difference |
| 17:55.58 | RP__ | since it was totally breaking the dependency ordering |
| 17:56.03 | pb_ | I'll try pulling those bits into our local tree on Monday and see if the situation improves. |
| 17:56.25 | pb_ | possibly time I tried just generally updating to a newer oe-core, too. I think we are a while behind at the moment. |
| 17:56.28 | kergoth | I'll be doing a lot of testing of this on mentor's end of things too. having working binary caching is absolutely critical for us (as it is for freescale and others) |
| 17:57.53 | pb_ | btw, on the subject of sstate, should we just make it always be inherited from base.bbclass or something? |
| 17:58.08 | pb_ | last time I tried, you couldn't actually get a successful build anymore if you didn't have it, so it seems a bit silly for it to be a distro opt-in. |
| 17:58.33 | RP__ | pb_: probably, yes |
| 17:58.43 | kergoth | you can't build without it? hmm, that's interesting |
| 17:58.56 | pb_ | I don't quite recall what went wrong but it doesn't seem worth spending much effort on fixing. |
| 17:59.00 | kergoth | nods |
| 17:59.12 | RP__ | kergoth: we depend on it to be able to clean things out the sysroot |
| 17:59.15 | pb_ | (not least since, empirically, nobody is using a non-sstate configuration at the moment or they would be complaining) |
| 17:59.21 | kergoth | ah, right |
| 17:59.47 | kergoth | not using it really doesn't buy you anything anyway, if you don't trust it, you can always just keep SSTATE_DIR in TMPDIR or wipe it manually |
| 17:59.57 | pb_ | yeah |
| 17:59.59 | RP__ | kergoth: right, exactly |
| 18:00.26 | pb_ | mind you, the removal of stuff from sstate is generating a certain amount of annoyance among my colleagues, need to spend a bit of time figuring out what is going on there. |
| 18:00.59 | pb_ | er, removal from sysroot, not from sstate |
| 18:01.16 | pb_ | I guess I meant to write "from sysroot by sstate", or something. |
| 18:01.50 | kergoth | I really need to find the time to look closer at esben's stuff. It's really intreguing(sp?) but I've only tried building oe-lite once or twice and it failed both times, haven't had the time to dig any more closely |
| 18:03.23 | pb_ | sounds like a good plan. I've never actually tried it myself but it does sound interesting. |
| 18:04.07 | RP__ | kergoth: I talked to esben at ELC-E about it at length |
| 18:04.13 | *** join/#oe pepermint (~pepermint@host247-82-dynamic.2-87-r.retail.telecomitalia.it) |
| 18:04.31 | RP__ | kergoth: There is a lot of good intersting stuff in there, I just wish he didn't feel the need to do it on his own |
| 18:05.04 | pb_ | yeah, that is a bit of a shame |
| 18:05.16 | RP__ | kergoth: He thought we'd not be interested in some things there as they break certain compatibility but I think they might be worth looking at |
| 18:05.22 | kergoth | yeah.. some of it would have been hard to do without breaking compatibility though, so I can see why he took that approach |
| 18:05.30 | kergoth | some of it could probably be brought in gradually though |
| 18:05.37 | RP__ | kergoth: right |
| 18:05.58 | RP__ | kergoth: the parser corrections and grammar improvements for example |
| 18:06.09 | pb_ | yeah. last time I talked to him, though (which was a while ago admittedly) he didn't seem interested in just doing pieces, he felt that it ought to be the whole lot at once or nothing. |
| 18:06.13 | kergoth | The whole use of the binary packages for everything, thereby avoiding the need for separate sstate archives and consolidating the two forms of dependencies is quite nice |
| 18:06.42 | pb_ | agreed, I would like that (and per-recipe sysroots) very much. |
| 18:06.47 | kergoth | yeah, those do look nice, some of them anyway. The ability to express dependencies amongst eventhandlers/hooks is quite nice |
| 18:07.18 | RP__ | needs to go, back later |
| 18:08.50 | pb_ | too |
| 18:08.51 | pb_ | later all |
| 18:09.11 | kergoth | later |
| 18:09.32 | *** join/#oe risca (~risca@f-static-78-70-87-29.business.telia.com) |
| 18:17.24 | *** join/#oe phdeswer (~philippe@a83-245-252-47.elisa-laajakaista.fi) |
| 18:26.14 | *** join/#oe msm (~msm@c-98-195-77-8.hsd1.tx.comcast.net) |
| 18:30.57 | *** join/#oe GNUtoo (~GNUtoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
| 18:32.21 | *** join/#oe rob_w (~bob@host-188-174-172-122.customer.m-online.net) |
| 18:41.43 | Jin^eLD | I really have a feeling that builds take much longer now with pseudo :P |
| 18:46.05 | Jin^eLD | top: make 17% CPU, pseudo 22% CPU, pseudo often spikes up to 50% and more |
| 18:51.09 | kergoth | ouch |
| 18:51.56 | Jin^eLD | I have no idea why but I constantly see this since I switched to OE core |
| 18:52.32 | Jin^eLD | and builds feel much slower now than with classic |
| 18:56.54 | *** join/#oe galak (~galak@192.88.168.35) |
| 19:13.41 | *** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust439.2-4.cable.virginmedia.com) |
| 19:13.42 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:35.28 | *** join/#oe florian (~fuchs@sign-4db6a880.pool.mediaWays.net) |
| 19:35.33 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:42.17 | *** join/#oe jimsheldon (~jim@static-64-223-142-66.man.east.myfairpoint.net) |
| 19:43.00 | jimsheldon | has anyone worked with the at91sam9g20? I'm trying to figure out if there is USB 2.0 support under Linux or not |
| 19:45.33 | Jin^eLD | I'm on at91sam9g20ek but I did not check regarding usb 2.0 specifically |
| 19:47.29 | jimsheldon | ok, yeah as far as I can tell it only uses a ohci driver which (I think) is USB 1.0 |
| 19:47.41 | *** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust439.2-4.cable.virginmedia.com) |
| 19:47.42 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:48.32 | Jin^eLD | jimsheldon: looks like 1? http://pastebin.mozilla.org/1387781 |
| 19:48.42 | Jin^eLD | if you want me to paste something more specific tell me, I have a system up and running |
| 19:49.15 | jimsheldon | ok thank you, let me see if anything in dmesg would help... |
| 19:57.10 | florian | re |
| 19:57.57 | *** join/#oe Zoxc (Zoxc@ti0128a380-dhcp0301.bb.online.no) |
| 20:03.52 | *** join/#oe eFfeM (~frans@a2038.upc-a.chello.nl) |
| 20:06.30 | *** join/#oe rob_w_ (~bob@host-188-174-172-122.customer.m-online.net) |
| 20:07.41 | *** join/#oe pwgen (~ew@pp29-254.phys.au.dk) |
| 20:09.34 | *** join/#oe tasslehoff (~tasslehof@145.79-161-31.customer.lyse.net) |
| 20:16.08 | *** join/#oe risca (~risca@f-static-78-70-87-29.business.telia.com) |
| 20:24.59 | eFfeM | khem, noticed that my uclibc problem was only due to -Os. When I replaced it with -O2 it worked, after that also moved to the maintenance branch, there the problem was cured as gcc had your -Os fix. |
| 20:25.35 | eFfeM | however going to the maintenance branch with minimal resulted in quite some non-fetching recipes (mostly due to stuff that used to be in kernel.org). |
| 20:26.05 | eFfeM | also had to update the netsnmp recipe as it did not work with uclibc, this issue was already fixed in a newer version of netsnmp |
| 20:26.28 | eFfeM | time permitting I'll try to submit a patch |
| 20:26.42 | eFfeM | and thanks for your help! |
| 20:26.57 | *** join/#oe Zoxc (Zoxc@ti0128a380-dhcp0301.bb.online.no) |
| 20:27.26 | eFfeM | (still have one issue left but that is probably in my code, I have a char x = -1; and if at a later point I do printf("%d\n", x); it prints 255 not -1) |
| 20:29.20 | kergoth | eFfeM: char signedness issue, probably. some platforms char is unsigned, if it is, -1 will likely give you 255.. |
| 20:29.30 | kergoth | always best to be explicit about char signedness, or pass the gcc arg to force the matter |
| 20:30.39 | eFfeM | kergoth; guess it is, noticed too that (unsigned char)-1 == 255 |
| 20:31.03 | kergoth | nods |
| 20:31.16 | eFfeM | vaguely seemed to recall that C chars are by default signed, but not 100% sure about it (and I thought in gcc they were by default unless you do some -f option) |
| 20:32.11 | kergoth | pretty sure it depends on platform, which is why it's often a problem |
| 20:32.15 | eFfeM | will work on that later, the nice thing is that uclibc halves the size of my initramfs cpio file |
| 20:32.22 | kergoth | people will code with an implicit assumption about it and run into portability issues |
| 20:34.07 | eFfeM | actually I started with an int, but then I was running the code through splint or flexelint and it complained that in a network message I did put it into a byte, so changed the int into char; will revisit that tomorrow (after changing int to char, gcc complains that I index an array with a char, so it remains so-so) |
| 20:36.11 | kergoth | nods |
| 20:36.37 | kergoth | i'd leave it an int and explicitly cast if need be for the message bits |
| 20:36.38 | kergoth | shrugs |
| 20:36.43 | kergoth | i never code c anymore :) |
| 20:38.37 | eFfeM | yeah, guess I will do so; |
| 20:38.43 | eFfeM | I still program quite some C |
| 20:39.32 | kergoth | getting rusty, guess I should brush up |
| 20:48.49 | Jin^eLD | I don't get it... eglibc-locale.inc does inherit libc-package but when bitbaking -DDD eglibc-locale I do not see that this class is being loaded or used at all |
| 20:49.34 | kergoth | honestly I wouldn't trust the -DDD output nowadays, not with regard to file parsing. I'm pretty sure there are cases in the parsing code where it doesn't emit such a message |
| 20:49.52 | kergoth | add FOO = "1" to libc-package.bbclass and bitbake -e your recipe and check for it |
| 20:49.59 | kergoth | that's what i'd do, anyway |
| 20:50.04 | Jin^eLD | ok, thanks |
| 21:01.27 | *** join/#oe ant____ (~andrea@host59-250-dynamic.0-87-r.retail.telecomitalia.it) |
| 21:09.59 | *** join/#oe Zoxc (Zoxc@ti0128a380-dhcp0301.bb.online.no) |
| 21:10.12 | khem | eFfeM: ok glad you are out of woods |
| 21:10.27 | khem | default char on ppc is unsigned btw |
| 21:10.34 | eFfeM | khem, I am |
| 21:10.52 | eFfeM | khem, ah, ok, that explains my other problem, thanks for the info! |
| 21:11.57 | khem | on x86 default is signed |
| 21:12.06 | khem | on ppc/macos default is signed char |
| 21:12.13 | khem | confused ? |
| 21:12.28 | khem | :) thats how messy it is |
| 21:14.34 | kergoth | best to either explicitly use unsigned char or use the gcc arg to specify the behavior. thanks for clarifying the platform details |
| 21:14.51 | kergoth | experiments with a new dotfiles setup |
| 21:16.08 | eFfeM | khem, I knew it was not too clear, anyway fortunately things like ones complement machines and machines with e.g. 20 bit words seem to become rare :-) |
| 21:16.11 | Jin^eLD | mhm, when I put my overriding class into my layer, it seems it is not being taken... |
| 21:17.24 | khem | Ideally, a portable program should always use signed char or unsigned char when it depends on the signedness of an object |
| 21:17.53 | kergoth | Jin^eLD: verify your priority is set correctly in your layer.conf |
| 21:18.09 | kergoth | erm, no, class, in this case verify the order of layers in BBLAYERS |
| 21:18.22 | khem | kergoth: BBPATH |
| 21:18.26 | kergoth | should be higher priority to lower priority |
| 21:18.37 | kergoth | yeah, bblayers determines bbpath, since all layers append to it right now |
| 21:18.50 | *** join/#oe anarsoul (~anarsoul@193.151.42.171) |
| 21:18.54 | Jin^eLD | ok let me check... |
| 21:18.54 | kergoth | btw, the example layer.conf files still suck. unnecessary usage of :=, etc |
| 21:18.56 | kergoth | rolls eyes |
| 21:19.23 | RP__ | Jin^eLD: re: the pseudo thing, ensure you have the latest bitbake and pseudo |
| 21:19.42 | RP__ | Jin^eLD: There were some speedups I managed to find which were added fairly recently |
| 21:20.04 | Jin^eLD | RP__: I have bitbake 1.14, have to check regarding pseudo |
| 21:20.13 | khem | RP__: re libtool |
| 21:20.28 | khem | should we upgrade to 2.4.2 or do u have some outstanding patches |
| 21:20.36 | khem | I have not gone through all mails yet |
| 21:20.57 | eFfeM | calling it a day, nite all! |
| 21:22.33 | *** join/#oe e-ffi (~cybercom@HSI-KBW-109-192-122-205.hsi6.kabel-badenwuerttemberg.de) |
| 21:22.40 | Jin^eLD | kergoth: BBLAYERS list my layer in first position |
| 21:25.33 | kergoth | Jin^eLD: use bitbake -e to verify the sanity of your BBPATH. |
| 21:26.29 | Jin^eLD | ok that explains it... my environment script put oe core in front |
| 21:26.35 | Jin^eLD | thanks :> |
| 21:27.59 | kergoth | np |
| 21:28.13 | kergoth | you shouldn't put any layers in your default bbpath, the layer.conf for them will add them for you |
| 21:28.20 | kergoth | just need your build dir or whatever |
| 21:28.41 | Jin^eLD | ok.. will fix that |
| 21:32.57 | *** join/#oe Matth_FA (~Matth_FA@mtl93-14-78-241-192-235.fbx.proxad.net) |
| 21:37.00 | RP__ | khem: I have http://git.openembedded.org/openembedded-core/commit/?h=master-next&id=c15235e797e2e9623bfd28f3dbe2a6ed43e48434 outstanding |
| 21:37.10 | RP__ | khem: I'm just about in a position where I think we can push that though |
| 21:37.34 | Jin^eLD | btw, after a -c clean mypackage building again does not always trigger a real rebuild |
| 21:37.40 | Jin^eLD | am I doing something wrong? |
| 21:37.46 | Jin^eLD | that worked in older bitbakes |
| 21:38.02 | RP__ | Jin^eLD: http://git.openembedded.org/bitbake/commit/?id=05c29ab0b2ad3c521414cabb6a92bca15c6e919c is the speedup, its not in 1.14 :( |
| 21:38.38 | Jin^eLD | RP__: how stable is git head? should I rather wait for the next release or just update? I'd use it in production |
| 21:39.24 | *** part/#oe jimsheldon (~jim@static-64-223-142-66.man.east.myfairpoint.net) |
| 21:50.15 | *** join/#oe kergoth_ (~kergoth@ip24-251-167-38.ph.ph.cox.net) |
| 21:52.45 | RP__ | Jin^eLD: The current HEAD should be ok, not sure what is coming next as development is ongoing though |
| 21:53.06 | Jin^eLD | well I'd probably update and then freeze till the next release |
| 21:53.56 | Jin^eLD | hmm, if I do a bb.note in my class, it should get into the logs in the work/package/temp dir, right? |
| 22:03.02 | *** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust439.2-4.cable.virginmedia.com) |
| 22:03.02 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 22:20.17 | *** join/#oe Zoxc- (Zoxc@ti0128a380-dhcp0275.bb.online.no) |
| 22:34.22 | msm | did anyone get a chance to look at my RFC patch regarding gcc-cross? |
| 22:59.06 | *** join/#oe Circuitsoft (40f4c0e2@gateway/web/freenode/ip.64.244.192.226) |
| 22:59.17 | Circuitsoft | Anyone know where I can find the source for psplash? |
| 23:00.20 | bluelightning | Circuitsoft: the answer is the same for anything in OE, have a look at where SRC_URI is pointing in the recipe |
| 23:00.46 | bluelightning | as for the current sources, the repository is at http://git.yoctoproject.org/cgit/cgit.cgi/psplash |
| 23:01.08 | bluelightning | but the recipe you are using may not be pointed there, depending on whether you use OE-classic or OE-core |
| 23:01.53 | Circuitsoft | That's new. All the references I've found before were to svn.o-hand.org, which doesn't seem to exist anymore. |
| 23:02.46 | Circuitsoft | Thank you very much. I was afraid I was going to have to find a different splash solution for my device. |
| 23:03.04 | *** join/#oe pespin (~pespin@123.pool85-50-24.dynamic.orange.es) |
| 23:07.48 | *** join/#oe eephillip (~eephillip@pdpc/supporter/student/eephillip) |
| 23:22.30 | *** join/#oe reactor16 (~rrrr@88.198.211.198) |
| 23:22.37 | *** part/#oe reactor16 (~rrrr@88.198.211.198) |
| 23:24.13 | *** join/#oe risca (~risca@h106n1-n-a31.ias.bredband.telia.com) |
| 23:38.13 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 23:44.08 | RP__ | msm: I did |
| 23:44.39 | *** join/#oe Jefro (~josiermi@134.134.139.76) |
| 23:44.53 | RP__ | msm: been meaning to reply that we really need to get our act together and add a suffix to PN for the cross recipes, then take them out the target workdir |
| 23:45.11 | RP__ | msm: its worked well for the cross-canadian stuff |
| 23:55.35 | *** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |