**** BEGIN LOGGING AT Wed Nov 23 02:59:57 2011 Nov 23 06:36:54 Circuitsoft: http://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/ Nov 23 07:28:05 gm Nov 23 07:37:42 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 Nov 23 08:15:54 good morning Nov 23 08:23:31 hi mckoan Nov 23 08:46:14 hey all, my linux-omap_2.6.39.bb recipe is failing to clone the linux-omap2.6.git Nov 23 08:46:24 from git.kernel.org Nov 23 08:47:06 is thr any another repo where i can find linux-omap2.6 git? Nov 23 08:54:13 hi guys. I'm using Angstrom to bitbake virtual/kernel and I'm getting this: Nov 23 08:54:15 NOTE: Error expanding variable toolchain_create_sdk_version############################################ | ETA: 00:01:25 Nov 23 08:54:15 ERROR: Failure expanding variable METADATA_REVISION, expression was ${@base_detect_revision(d)} which triggered exception OSError: [Errno 12] Cannot allocate memory Nov 23 08:54:15 ERROR: Command execution failed: Exited with 1 Nov 23 08:54:55 Fresh 'install' of Angstrom.. followed instructions to the T. Nov 23 08:56:24 I'm running Debian 6. Nov 23 08:56:31 Any help would be greatly appreciated. Nov 23 09:02:08 stomach_contents: looks like wrong /dev/shm or /run/shm permissions Nov 23 09:03:54 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 Nov 23 09:09:30 maybe it's really lack of free memory.. Nov 23 09:11:45 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. Nov 23 09:12:32 arg.. death. Nov 23 09:14:19 how much RAM should bitbake need do you think? Nov 23 09:16:52 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? Nov 23 09:21:02 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) Nov 23 09:24:53 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. Nov 23 09:32:39 JaMa|Off: Dude. you rock. Nov 23 09:33:07 Jama|Off: It was simply that. Insufficient ram for this insane bloatware! Thanks!!! Nov 23 09:33:33 Jama|Off: Guess sometimes I should just take the error message at face value. :) Nov 23 09:34:41 yes with 512MB in VM it's good idea :) Nov 23 09:35:19 Jama|Off: first linux app ever that's run out of memory. Nov 23 09:35:39 Jama|Off: After all, this isn't M$ remember :P Nov 23 09:37:39 Jama|Off: Do you know much about building the Gumstix Overo stuff? Got a nasty error there too, but not RAM related. Nov 23 10:20:55 pb_: heh, your lead_soname crusade ;) Nov 23 10:26:12 heh Nov 23 10:26:23 yeah, I wish that mechanism had never been invented Nov 23 10:26:32 it was such a dumb idea Nov 23 10:29:01 anyone an idea how to get matchbox-stroke compiled ? it's complaining on missing XRenderFillRectangle Nov 23 10:29:48 is it linking with -lXrender? Nov 23 10:31:01 pwgen: there is a patch for this from khem on the oe-core list Nov 23 10:31:01 http://patchwork.openembedded.org/patch/15159/ ? Nov 23 10:31:09 ant_work: fast guy :) Nov 23 10:31:27 heh, I've read it earlier this morning ;) Nov 23 10:35:10 btw it did compile (core-image-sato) without this patch on my host. I even tried to run it but it was seemingly broken Nov 23 10:35:19 this was last week Nov 23 10:53:39 florian: denix Crofton: how about a board meeting this week? Nov 23 10:53:56 mickey|office: hi! How are you? Nov 23 10:54:36 hi mickey|office Nov 23 10:54:44 mickey|office: might be a good idea Nov 23 10:55:00 stefan_schmidt: apart from a bunch of problems with my aging body, i'm feeling excellent. you? Nov 23 10:55:25 mickey|office: feeling got as well. Studies done. :) Nov 23 10:55:37 yay! Nov 23 10:55:55 mickey|office: And due to some more sports in the last months I also having a better fitness again Nov 23 10:56:31 mickey|office: Jan is done as well. Daniel still needs some months but is already on his thesis (last part) Nov 23 11:02:02 hm Nov 23 11:02:35 I was wondering if anyone had tried to use FreeBSD for an embedded system? Nov 23 11:16:17 errordeveloper: like juniper? Nov 23 11:38:42 patrickg: i thought they use/sponsor NetBSD? Nov 23 11:42:09 http://www.freebsdnews.net/2008/07/23/junipers-junos-freebsd-based-router-operating-system/ claims freebsd Nov 23 11:59:56 is juniper using OE? Nov 23 12:00:59 well, I mean I was actually going to ask 'has anyone tried to write a recipe for freebsd kernel' ? Nov 23 12:01:07 would be quite interesting I suppose ... Nov 23 12:01:26 OE shouldn't be limited to linux I think :) Nov 23 12:01:31 guys, stay clear of Alabama :) Nov 23 12:01:40 http://www.economist.com/blogs/democracyinamerica/2011/11/unintended-consequences?fsrc=scn/tw/te/bl/niceonealabama Nov 23 12:02:01 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. Nov 23 12:02:56 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. Nov 23 12:04:38 Porting the bsd libc is probably the easier option, I guess. Nov 23 12:04:58 on the subject of libcs, has anybody written a recipe for MUSL? Nov 23 12:05:34 debian/kfreebsd uses glibc, no? Nov 23 12:06:00 pb_: hm, I rember booting a debian kFreeBSD image just a month ago or so Nov 23 12:06:06 oh yeah, so they do Nov 23 12:06:10 it was recent (iirc) Nov 23 12:06:43 so in that case, yes, it should be straightforward to do in oe too Nov 23 12:06:43 I would imagine that bsd libc is not as fat as glibc Nov 23 12:07:02 right, bsd libc is smaller but does less stuff Nov 23 12:07:08 I thing gentoo should work also .. Nov 23 12:18:06 pb_: At least I remember someone mentioned MUSL some time ago in one of the embedded channels... Nov 23 12:22:32 yeah, it sounds quite cool from what the webpage says Nov 23 12:22:55 less big than glibc, less demented than klibc and uclibc Nov 23 12:27:16 mickey|office, this week is a holiday in .us Nov 23 12:27:40 maybe Friday, or early Monday, since I will be traveling the rest of next week Nov 23 12:47:51 03Richard Purdie  07master * rb7114d8e5d 10bitbake.git/lib/bb/runqueue.py: (log message trimmed) Nov 23 12:47:51 runqueue.py: Ensure setscene tasks don't break dependency order Nov 23 12:47:51 If A depends upon B which depends upon C and the setscene for B Nov 23 12:47:51 succeeds but C is going to get rebuilt, we should wait for C to Nov 23 12:47:51 try and build A but currently we don't. Nov 23 12:47:51 This is due to the timing of when we run the task_skip() as this Nov 23 12:47:52 triggers other tasks to become buildable. This patch moves the timing Nov 23 12:57:52 Crofton|work: sad to see the US sliding further towards a "papers please" society :/ Nov 23 13:00:55 :) Nov 23 13:01:07 bluelightning, you have a moment Nov 23 13:01:15 Crofton|work: sure thing Nov 23 13:02:11 so the FindQt4 macro in cmake runs /qmake2 -query QT_INSTALL_HEADERS Nov 23 13:02:28 which returns paths in the x86 sysroot Nov 23 13:03:04 it seems like we need to tell cmake to use a different spc file I think Nov 23 13:04:43 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? Nov 23 13:06:17 nobody cares about upgrade path from OE-classic to new layers, so this would be only one of _many_ issues you will get Nov 23 13:07:28 JaMa|Off: well, surprisingly it went mostly well Nov 23 13:07:45 I found a sort of bug in opkg that forced me to rewrite some recipes to work around it Nov 23 13:07:57 because you didn't notice PV/PR going backwards :) Nov 23 13:08:19 ehm, no, why should PV go backwards? Nov 23 13:08:34 my classic setup was two years old ;) Nov 23 13:08:49 because oe-core has (at least had) some recipes in older version then what was in OE-classic when it was abandoned Nov 23 13:09:10 well, I did not update classic for two years, so that problem did not hit me Nov 23 13:09:45 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 Nov 23 13:09:59 but luckily only for two packages, so that was managable Nov 23 13:10:40 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 Nov 23 13:10:56 btw even live upgrade from glibc to eglibc worked out well Nov 23 13:15:38 bluelightning, http://www.mail-archive.com/cmake@cmake.org/msg37312.html Nov 23 13:16:29 Crofton|work: hmm... no response to that one I see :/ Nov 23 13:19:02 read the thread Nov 23 13:19:20 apparently we need to tell cmake where the stuff is really hard Nov 23 13:19:43 how exactly does PROVIDES and RPROVIDES work? Nov 23 13:20:04 whats the opkg behaviour when those settings are encountered? Nov 23 13:29:26 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 :( Nov 23 13:30:35 grml :( Nov 23 13:31:02 that does not sound too primising... Nov 23 13:31:18 opkg-devel did not answer anything yet either Nov 23 13:37:23 getVar(SOMEVAR, bool) what does the bool flag stand for? Nov 23 13:41:02 expand-now; e.g. when there is written a='${FOO}', then getVar('a', false) == '${FOO}' and getVar('a', true) == getVar('FOO', true) holds Nov 23 13:42:05 thanks Nov 23 13:45:17 hmm, I remember I have seen this before: http://pastebin.com/Wzi40n80 Nov 23 13:45:55 bitbake complains during rootfs build with file_md5sum_alloc can not open files, but files exist. Nov 23 13:46:04 Anyone has an idea about this? Nov 23 13:46:30 its an oe-core build with ansgtrom setup-scripts and a own layer for the image and some extra recipes Nov 23 13:46:58 I only know what the opkg means by file_md5sum_alloc, have not seen this error during image generation though Nov 23 13:47:29 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 Nov 23 13:47:43 but no clue why you are getting it during rootfs generation and if it is relevant for you at all Nov 23 13:48:03 Jin^eLD: hmm, ok Nov 23 13:48:27 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 Nov 23 13:48:47 Jin^eLD: Maybe I'm hunting the wrong problem again. Will have another look at the whole log file :) Nov 23 13:52:23 Crofton|work: have you got a reasonably simple example so I can play around with this? Nov 23 13:53:06 not really Nov 23 13:53:11 just gnuradio Nov 23 13:53:20 I can send you the recipe Nov 23 13:53:32 I am trying to inspire myself to try some things Nov 23 13:53:39 but it is a holiday week here :) Nov 23 13:53:44 Crofton|work: that would be helpful thanks Nov 23 13:54:10 right, yeah, you probably shouldn't be working I guess :) Nov 23 13:57:09 well, motivation is hard :) Nov 23 13:57:20 and it is early and I should have stayed in bed :) Nov 23 13:58:24 just shows a blank page for me. Can somebody check that please. Nov 23 13:59:00 hrm again? Nov 23 13:59:06 * florian shoots ltg Nov 23 13:59:13 * florian shoots planetplanet Nov 23 14:00:30 florian: So it is not just me. Thank you for confirming this. Nov 23 14:01:04 * florian fixes Nov 23 14:02:00 looks better Nov 23 14:13:30 florian: Thank you. It works for me now. Nov 23 14:20:14 morning Nov 23 14:21:29 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? Nov 23 14:21:42 yep Nov 23 14:22:18 ok, thanks! Nov 23 14:23:52 hi kergoth` Nov 23 14:26:20 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. Nov 23 14:26:31 kergoth`: one is that git status will tell you the status of your tree and submodules Nov 23 14:46:09 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!? Nov 23 14:46:38 s/fails on/fails on downloading/ Nov 23 14:48:21 ah, I just found KERNELORG_MIRROR within meta/classes/mirrors.bbclass Nov 23 14:54:57 try KERNELORG_MIRROR = "http://mirror.nexcess.net/kernel.org/" Nov 23 15:01:22 kergoth: yep, thanks! I just added another mirror and bitbake goes further Nov 23 15:01:30 kergoth`: looks like this is becoming a FAQ, maybe is time to add some new mirror in classes/mirrors.bbclass ;-) Nov 23 15:02:11 yeah, or just change the default one Nov 23 15:02:15 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 Nov 23 15:02:33 maybe at least cut down to just one for each to cover the case where the default server is down Nov 23 15:02:34 honestly, what is it with kernel.org? it must be three months now that their data has been offline. Nov 23 15:02:41 good question, it's crazy Nov 23 15:11:02 * kenws nods Nov 23 15:11:09 pb_: only uclibc syslinux and module-init tools are back Nov 23 15:11:32 I know HPA is still waiting to have klibc back Nov 23 15:12:43 wow.. klibc.git *is* back Nov 23 15:14:30 he, hpa has real cow powers ;) Nov 23 15:17:49 https://github.com/kergoth/homefiles/blob/master/oe/classes/mirrors.bbclass is what I'm using for my personal builds nowadays Nov 23 15:20:11 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 : ) Nov 23 15:20:19 lol Nov 23 15:20:38 I was bit by tzdata2001g last time... Nov 23 15:21:13 that's really *the้ most asked sort of questions here lately Nov 23 15:26:43 What's the issue with tzdata2001g? Nov 23 15:30:13 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 Nov 23 15:32:33 kenws: *2001g is in meta-oe but isn't fetchable Nov 23 15:35:36 ant_work: ah ok, and what's the solution? Nov 23 15:36:08 ideally we use the one, more recent, in oe-core Nov 23 15:36:37 though, the meta-oe maintainer insists the reipes in meta-oe are better Nov 23 15:36:59 there is a thread in the mailing list Nov 23 15:37:49 in the meanwhile I remove the meta-oe recipes ;) Nov 23 15:38:58 Ok, I have't used the oe-meta layer yet. I thought oe-meta provides only additional stuff to oe-core. Nov 23 15:39:12 unfortunately there are still some dupes Nov 23 15:40:21 hm, even a eglibc is within recipes-core - strange Nov 23 15:40:33 oh, that's even worst imho Nov 23 15:40:47 is an old release dropped from oe-core and there for 'compatibility' Nov 23 15:41:18 interesting Nov 23 15:43:21 well, there is hope is that more people will start using meta-oe layer... Nov 23 15:43:45 I've read some recent comments on yocto ML about that Nov 23 15:43:46 * kenws just noticed recipes-devtools/gcc/gcc-4.6/linaro Nov 23 16:01:00 03Richard Purdie  07master * r61017fc5d3 10bitbake.git/lib/bb/runqueue.py: (log message trimmed) Nov 23 16:01:00 runqueue.py: Ensure we fully process the covered list Nov 23 16:01:00 The existing looping code can mask an existing "found = True" Nov 23 16:01:00 by forcing it to False each time. This can lead to dependency Nov 23 16:01:00 lists not being fully searched and results in dependency errors. Nov 23 16:01:01 An exmaple of this was the autobuilder building linux-yocto from Nov 23 16:01:02 sstate but then rebuilding some of the recipe's tasks for no Nov 23 16:35:12 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 Nov 23 16:35:13 any hints? Nov 23 16:35:32 I need to ad RREPLACES_each-localedata-package = "glibc-localedata-*" Nov 23 16:35:43 well you get the idea Nov 23 16:37:23 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 Nov 23 16:38:48 Jin^eLD: cool Nov 23 16:39:03 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 Nov 23 16:40:26 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 :> Nov 23 16:40:46 Jin^eLD: sounds good Nov 23 16:41:46 soo... any clues regarding eglibc? I can't find who or what defines those *localedata* packages Nov 23 16:45:04 Jin^eLD: it's the result of do_split_packages in meta/classes/libc-package.bbclass Nov 23 16:45:17 so it's dynamic based on the output of the build Nov 23 16:45:31 that probably makes it harder for you :( Nov 23 16:46:29 doh... indeed... so I guess I should override the libc-package.bbclass in my layer then Nov 23 16:48:30 Jin^eLD: or just append to the eglibc recipe Nov 23 16:48:50 or, you can even define the RREPLACES etc. at a distro level Nov 23 16:49:00 can I overwrite a function from a bbclass in the recipe? Nov 23 16:51:32 yes Nov 23 16:54:03 ..by just defining my own with the same name, or how does it work? Nov 23 16:54:12 yes, exactly that Nov 23 16:54:16 thanks Nov 23 16:57:34 :> Nov 23 17:49:17 Anyone looked into extending the patch support to handle series files and/or archives? Nov 23 17:51:50 03Matthew McClintock  07master * rf1eb6d3dcc 10bitbake.git/lib/bb/siggen.py: Nov 23 17:51:50 bitbake: print out symmetric difference when comparing sigs Nov 23 17:51:50 This is useful for really longs lists to pinpoint what has Nov 23 17:51:50 actually changed Nov 23 17:51:50 Signed-off-by: Matthew McClintock Nov 23 17:51:51 Signed-off-by: Richard Purdie Nov 23 17:51:52 03Matthew McClintock  07master * r9a2029899c 10bitbake.git/lib/bb/siggen.py: (log message trimmed) Nov 23 17:51:52 siggen.py: sort task hash depedencies with basepath Nov 23 17:51:53 Without this patch the tash hash dependencies can be in a order Nov 23 17:51:53 that is dependent upon directory/filesystem layout. With this Nov 23 17:51:54 change the data is sorted the same regardless. Nov 23 17:51:54 Without this the dependent hashes could be in different orders Nov 23 17:51:55 on different systems and consequently final md5 hash would differ Nov 23 17:55:53 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 Nov 23 17:56:10 yeah Nov 23 17:56:45 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 Nov 23 17:57:11 pb_: I've also been a bit unsettled by such reports Nov 23 17:57:23 Hopefully we're getting to the bottom of those issues Nov 23 17:57:27 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 Nov 23 17:57:34 right Nov 23 17:57:43 think it took me like a week and a half just to get the shell/python dependency scanning sorted Nov 23 17:57:46 heh Nov 23 17:58:06 I think the task_skip() change may make the world of difference Nov 23 17:58:20 since it was totally breaking the dependency ordering Nov 23 17:58:25 I'll try pulling those bits into our local tree on Monday and see if the situation improves. Nov 23 17:58:47 possibly time I tried just generally updating to a newer oe-core, too. I think we are a while behind at the moment. Nov 23 17:58:50 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) Nov 23 18:00:15 btw, on the subject of sstate, should we just make it always be inherited from base.bbclass or something? Nov 23 18:00:30 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. Nov 23 18:00:55 pb_: probably, yes Nov 23 18:01:05 you can't build without it? hmm, that's interesting Nov 23 18:01:18 I don't quite recall what went wrong but it doesn't seem worth spending much effort on fixing. Nov 23 18:01:22 * kergoth nods Nov 23 18:01:34 kergoth: we depend on it to be able to clean things out the sysroot Nov 23 18:01:37 (not least since, empirically, nobody is using a non-sstate configuration at the moment or they would be complaining) Nov 23 18:01:43 ah, right Nov 23 18:02:09 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 Nov 23 18:02:20 yeah Nov 23 18:02:21 kergoth: right, exactly Nov 23 18:02:49 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. Nov 23 18:03:21 er, removal from sysroot, not from sstate Nov 23 18:03:38 I guess I meant to write "from sysroot by sstate", or something. Nov 23 18:04:12 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 Nov 23 18:05:46 sounds like a good plan. I've never actually tried it myself but it does sound interesting. Nov 23 18:06:29 kergoth: I talked to esben at ELC-E about it at length Nov 23 18:06:53 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 Nov 23 18:07:27 yeah, that is a bit of a shame Nov 23 18:07:38 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 Nov 23 18:07:44 yeah.. some of it would have been hard to do without breaking compatibility though, so I can see why he took that approach Nov 23 18:07:52 some of it could probably be brought in gradually though Nov 23 18:07:59 kergoth: right Nov 23 18:08:21 kergoth: the parser corrections and grammar improvements for example Nov 23 18:08:32 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. Nov 23 18:08:35 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 Nov 23 18:09:04 agreed, I would like that (and per-recipe sysroots) very much. Nov 23 18:09:09 yeah, those do look nice, some of them anyway. The ability to express dependencies amongst eventhandlers/hooks is quite nice Nov 23 18:09:40 * RP__ needs to go, back later Nov 23 18:11:13 * pb_ too Nov 23 18:11:14 later all Nov 23 18:11:33 later Nov 23 18:44:06 I really have a feeling that builds take much longer now with pseudo :P Nov 23 18:48:28 top: make 17% CPU, pseudo 22% CPU, pseudo often spikes up to 50% and more Nov 23 18:53:32 ouch Nov 23 18:54:19 I have no idea why but I constantly see this since I switched to OE core Nov 23 18:54:55 and builds feel much slower now than with classic Nov 23 19:45:22 has anyone worked with the at91sam9g20? I'm trying to figure out if there is USB 2.0 support under Linux or not Nov 23 19:47:56 I'm on at91sam9g20ek but I did not check regarding usb 2.0 specifically Nov 23 19:49:51 ok, yeah as far as I can tell it only uses a ohci driver which (I think) is USB 1.0 Nov 23 19:50:54 jimsheldon: looks like 1? http://pastebin.mozilla.org/1387781 Nov 23 19:51:05 if you want me to paste something more specific tell me, I have a system up and running Nov 23 19:51:38 ok thank you, let me see if anything in dmesg would help... Nov 23 19:59:32 re Nov 23 20:27:22 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. Nov 23 20:27:57 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). Nov 23 20:28:27 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 Nov 23 20:28:51 time permitting I'll try to submit a patch Nov 23 20:29:04 and thanks for your help! Nov 23 20:29:49 (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) Nov 23 20:31:42 eFfeM: char signedness issue, probably. some platforms char is unsigned, if it is, -1 will likely give you 255.. Nov 23 20:31:52 always best to be explicit about char signedness, or pass the gcc arg to force the matter Nov 23 20:33:02 kergoth; guess it is, noticed too that (unsigned char)-1 == 255 Nov 23 20:33:25 * kergoth nods Nov 23 20:33:39 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) Nov 23 20:34:34 pretty sure it depends on platform, which is why it's often a problem Nov 23 20:34:37 will work on that later, the nice thing is that uclibc halves the size of my initramfs cpio file Nov 23 20:34:44 people will code with an implicit assumption about it and run into portability issues Nov 23 20:36:29 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) Nov 23 20:38:34 * kergoth nods Nov 23 20:39:00 i'd leave it an int and explicitly cast if need be for the message bits Nov 23 20:39:01 * kergoth shrugs Nov 23 20:39:06 i never code c anymore :) Nov 23 20:41:00 yeah, guess I will do so; Nov 23 20:41:06 I still program quite some C Nov 23 20:41:54 getting rusty, guess I should brush up Nov 23 20:51:13 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 Nov 23 20:51:57 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 Nov 23 20:52:15 add FOO = "1" to libc-package.bbclass and bitbake -e your recipe and check for it Nov 23 20:52:22 that's what i'd do, anyway Nov 23 20:52:27 ok, thanks Nov 23 21:12:35 eFfeM: ok glad you are out of woods Nov 23 21:12:50 default char on ppc is unsigned btw Nov 23 21:12:57 khem, I am Nov 23 21:13:15 khem, ah, ok, that explains my other problem, thanks for the info! Nov 23 21:14:20 on x86 default is signed Nov 23 21:14:29 on ppc/macos default is signed char Nov 23 21:14:36 confused ? Nov 23 21:14:51 :) thats how messy it is Nov 23 21:16:57 best to either explicitly use unsigned char or use the gcc arg to specify the behavior. thanks for clarifying the platform details Nov 23 21:17:14 * kergoth experiments with a new dotfiles setup Nov 23 21:18:31 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 :-) Nov 23 21:18:34 mhm, when I put my overriding class into my layer, it seems it is not being taken... Nov 23 21:19:47 Ideally, a portable program should always use signed char or unsigned char when it depends on the signedness of an object Nov 23 21:20:16 Jin^eLD: verify your priority is set correctly in your layer.conf Nov 23 21:20:32 erm, no, class, in this case verify the order of layers in BBLAYERS Nov 23 21:20:45 kergoth: BBPATH Nov 23 21:20:49 should be higher priority to lower priority Nov 23 21:21:00 yeah, bblayers determines bbpath, since all layers append to it right now Nov 23 21:21:17 btw, the example layer.conf files still suck. unnecessary usage of :=, etc Nov 23 21:21:17 ok let me check... Nov 23 21:21:19 * kergoth rolls eyes Nov 23 21:21:46 Jin^eLD: re: the pseudo thing, ensure you have the latest bitbake and pseudo Nov 23 21:22:06 Jin^eLD: There were some speedups I managed to find which were added fairly recently Nov 23 21:22:27 RP__: I have bitbake 1.14, have to check regarding pseudo Nov 23 21:22:36 RP__: re libtool Nov 23 21:22:51 should we upgrade to 2.4.2 or do u have some outstanding patches Nov 23 21:22:59 I have not gone through all mails yet Nov 23 21:23:20 calling it a day, nite all! Nov 23 21:25:03 kergoth: BBLAYERS list my layer in first position Nov 23 21:27:56 Jin^eLD: use bitbake -e to verify the sanity of your BBPATH. Nov 23 21:28:53 ok that explains it... my environment script put oe core in front Nov 23 21:28:59 thanks :> Nov 23 21:30:22 np Nov 23 21:30:36 you shouldn't put any layers in your default bbpath, the layer.conf for them will add them for you Nov 23 21:30:43 just need your build dir or whatever Nov 23 21:31:04 ok.. will fix that Nov 23 21:39:24 khem: I have http://git.openembedded.org/openembedded-core/commit/?h=master-next&id=c15235e797e2e9623bfd28f3dbe2a6ed43e48434 outstanding Nov 23 21:39:34 khem: I'm just about in a position where I think we can push that though Nov 23 21:39:57 btw, after a -c clean mypackage building again does not always trigger a real rebuild Nov 23 21:40:04 am I doing something wrong? Nov 23 21:40:10 that worked in older bitbakes Nov 23 21:40:26 Jin^eLD: http://git.openembedded.org/bitbake/commit/?id=05c29ab0b2ad3c521414cabb6a92bca15c6e919c is the speedup, its not in 1.14 :( Nov 23 21:41:02 RP__: how stable is git head? should I rather wait for the next release or just update? I'd use it in production Nov 23 21:55:09 Jin^eLD: The current HEAD should be ok, not sure what is coming next as development is ongoing though Nov 23 21:55:29 well I'd probably update and then freeze till the next release Nov 23 21:56:20 hmm, if I do a bb.note in my class, it should get into the logs in the work/package/temp dir, right? Nov 23 22:36:45 did anyone get a chance to look at my RFC patch regarding gcc-cross? Nov 23 23:01:41 Anyone know where I can find the source for psplash? Nov 23 23:02:44 Circuitsoft: the answer is the same for anything in OE, have a look at where SRC_URI is pointing in the recipe Nov 23 23:03:10 as for the current sources, the repository is at http://git.yoctoproject.org/cgit/cgit.cgi/psplash Nov 23 23:03:32 but the recipe you are using may not be pointed there, depending on whether you use OE-classic or OE-core Nov 23 23:04:17 That's new. All the references I've found before were to svn.o-hand.org, which doesn't seem to exist anymore. Nov 23 23:04:55 Thank you very much. I was afraid I was going to have to find a different splash solution for my device. Nov 23 23:46:32 msm: I did Nov 23 23:47:17 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 Nov 23 23:47:35 msm: its worked well for the cross-canadian stuff Nov 24 00:40:49 RP: you mean work-shared? **** ENDING LOGGING AT Thu Nov 24 02:59:58 2011