**** BEGIN LOGGING AT Thu Jun 02 02:59:56 2011 **** ENDING LOGGING AT Thu Jun 02 03:41:39 2011 **** BEGIN LOGGING AT Thu Jun 02 03:42:14 2011 Jun 02 06:36:42 JaMa: ping Jun 02 06:56:20 pong Jun 02 08:06:19 RP__: good morning Jun 02 08:06:31 hi sgw Jun 02 08:09:43 RP__: that looks like a good call on 1131, I had not really looked closely at it yet. Working on some other strange stuff Jun 02 08:25:55 morning all Jun 02 08:27:58 hi bluelightning Jun 02 09:16:52 RP__: hi Jun 02 09:18:09 RP__: the git filter-branches will change the git history, in this case, it have difficult to sync with the upstream repo next time Jun 02 09:18:47 yuke: I was thinking we might just be able to extract revised commits to transfer over to the other repo with it though? Jun 02 09:20:59 RP__: do you mean git clone to another temporary git repo, and generate the patch we need, and then delete this repo ? Jun 02 09:23:42 yuke: no, that sounds messy Jun 02 09:24:08 yuke: Perhaps see how git-filter-branch works behind the scenes and see if we can use some of the commands it calls? Jun 02 09:24:47 RP__: Ok, i will look into more detail Jun 02 09:36:21 RP__: ping Jun 02 09:36:34 qhe: pong Jun 02 09:37:30 RP__: morning, well, I found quite some inconsistencies when I tried to add multilib:i386 to every recipe Jun 02 09:38:11 RP__: the problems mainly come from packaging, DEPENDS, PROVIDES, Rxxxx, PACKAGES, etc. Jun 02 09:39:20 qhe: Did you see my patch to native/nativesdk.bbclass the other day? Jun 02 09:39:35 qhe: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/temp3&id=1ed909e8b9bac6ed88ffbbe6a100a42c4289f498 Jun 02 09:39:49 RP__: not yet, will have a look Jun 02 09:39:52 We will need something like this for multilib.bbclass Jun 02 09:41:00 qhe: That should help with some of the problems, I'd be interested to see what issues we have beyond that. It then becomes a question of how best to address any remaining issues Jun 02 09:43:31 RP__: I think there's still a lot Jun 02 09:44:10 RP__: for example, -native doesn't really do packaging, but in multilib, things are different Jun 02 09:44:23 qhe: nativesdk does do packaging though Jun 02 09:44:49 RP__: we have many syntax like RDEPENDS_${PN} = "${PN}-ids", that will fail Jun 02 09:44:50 qhe: I knew there would be some issues and if we have the core code in place I'm happy to help try and resolve them Jun 02 09:45:10 qhe: PN changes so it shouldn't? Jun 02 09:45:40 RP__: pciutils-lib32-ids-lib32? Jun 02 09:46:12 qhe: ah, right. We can teach map_dependencies() to avoid that though Jun 02 09:46:31 RP__: And from what I observe, qt, python and perl's packaging has quite some complications Jun 02 09:46:45 Rather than appending, perhaps that could should do a search and replace based on PN Jun 02 09:46:54 RP__: I'm doing that right now Jun 02 09:46:57 s/could/code/ Jun 02 09:47:00 def extend_name(name): Jun 02 09:47:17 return name.replace("-lib32", "") + "-lib32" Jun 02 09:48:08 qhe: I mean do something like if name.find("PN-lib32") == "-1": name.replace("PN", "PN-lib32") Jun 02 09:48:11 and there is the problem for PREFERRED_PROVIDER Jun 02 09:49:21 RP__: and also many recipes dynamically manipulate PACKAGES, like qt4, python and kernel Jun 02 09:49:25 qhe: It may be we end up enabling this for a subset of recipes to start with. I do think we should be able to extend it globally eventually though Jun 02 09:50:02 RP__: Yeah, I still suppose we are better off to start from a subset Jun 02 09:50:47 but it's not very easy to implement if we don't add BBCLASSEXTEND directly into recipes? Jun 02 09:51:05 qhe: BBCLASSEXTEND_append_pn-xxxx = "multilib" Jun 02 09:51:50 you could even do this with anonymous python and set that with a for loop Jun 02 09:52:30 for r in d.getVar("MULTILIBRECIPES"): Jun 02 09:52:30 d.setVar("BBCLASSEXTEND_append_pn-%s" % r) Jun 02 09:52:49 RP__: can an anonymous python code appear in bitbake.conf or one of includes? Jun 02 09:53:07 qhe: it would probably have to go in a class file Jun 02 09:53:16 qhe: but it could only do that if the variable was set Jun 02 09:54:02 RP__: and PREFERRED_PROVIDER probably need to go to anonymous python as well Jun 02 09:54:20 The PREFERRED_PROVIDER issues are likely bugs Jun 02 09:54:38 where a package is hardcoding PN Jun 02 09:54:44 s/package/recipe/ Jun 02 09:55:18 RP__: why? I think today we have things like PREFERRED_PROVIDER thing Jun 02 09:55:37 like PREFERRED_PROVIDER_virtual/libc ?= "eglibc" Jun 02 09:55:45 qhe: its hard to understand the exact problem without specific examples Jun 02 09:55:57 all these needs to be PREFERRED_PROVIDER_virtual/libc-lib32 ?= "eglibc-lib32" Jun 02 09:56:23 I know if a recipe does something like PROVIDES = "busybox" then BBCLASSEXTEND has problems as every variant then provides busybox Jun 02 09:56:38 if it did PROVIDES = "${PN}" then things work better Jun 02 09:56:45 as one exmaple Jun 02 09:56:50 I actually made it PROVIDES_multilib-lib32 = "busybox-lib32" Jun 02 09:57:38 RP__: this is why I wrote a helper function: Jun 02 09:57:39 def extend_name(name): Jun 02 09:57:39 return name.replace("-lib32", "") + "-lib32" Jun 02 09:58:12 We might just add something like a CLASSEXTENSION variable which would get set to -lib32 or -native etc. Jun 02 09:58:37 So a recipe can do things like PROVIDES = "busybox${CLASSEXTENSION}" Jun 02 09:58:42 need a better name though Jun 02 09:59:15 yes, there are things like the libc providers which would need to get setup Jun 02 10:00:56 RP__: Doesn't that add a lot of maintenance effort to individual recipes? Jun 02 10:02:18 qhe: I'm hoping there are very few places we'd actually have this problem and that using ${PN} would resolve most cases easily Jun 02 10:02:57 Its hard to say what the end result will be until we try it though Jun 02 10:03:08 RP__: One of the other problem is the dynamic nature of python Jun 02 10:03:18 qhe: in what way? Jun 02 10:03:36 RP__: for example, qt4 only creates a lot of PACKAGES and FILES_x right before packaging Jun 02 10:03:46 RP__: in populate_packages_prepend() Jun 02 10:03:58 you can have a look in recipes-qt/qt4/qt4.inc Jun 02 10:04:07 qhe: I know the kind of code Jun 02 10:04:17 the multilib.bbclass has nothing to do with this situation Jun 02 10:04:27 qhe: Hopefully it uses ${PN} rather than hardcoding it Jun 02 10:04:46 so things happen that we will end up with qt4-x11-free and qt4-x11-free-lib32 both providing qt4-x11-free Jun 02 10:05:07 RP__: although qt4 may never be built for a multilib usage Jun 02 10:05:19 qhe: This is why I'm thinking if it used ${PN} in the name we'd have less potential problems Jun 02 10:06:29 RP__: you mean we should have names like qt4-lib32-tools? instead of qt4-tools-lib32 Jun 02 10:06:42 RP__: it looks inconsistent Jun 02 10:06:49 qhe: I'm starting to think that it might be neccessary :/ Jun 02 10:07:29 qhe: There is a flaw in the design of what we're doing since PN is appended to but as you point out that breaks in the ${PN}-xxx case Jun 02 10:07:30 RP__: that is sad Jun 02 10:08:00 RP__: can my approach work? to simply prune all -lib32 and append it at the end of the new package name Jun 02 10:08:37 qhe: possibly, yes Jun 02 10:08:42 RP__: e.g. ${PN}-ids: pciutils-lib32-ids-lib32 -> pciutils-ids-lib32 Jun 02 10:08:48 RP__: so I'll try that first Jun 02 10:09:03 within a subset of packages Jun 02 10:09:24 because qt4 kind of thing seems uncapable of circumvented Jun 02 10:09:47 the multilib anonymous python runs always before the packging task Jun 02 10:10:35 qhe: Its certainly a tricky problem Jun 02 10:10:45 RP__: yeah Jun 02 12:44:19 argh. Jun 02 12:45:17 I must be doing something wrong. I have what I think is an up to date master and am seeing patch failures in gcc 4.6.0 .. which I swear I heard discussed and fixed. Jun 02 12:57:18 * zeddii confirms he is up to date. Jun 02 12:57:39 is everyone else using gcc 4.6 from master ? Jun 02 13:40:10 zeddii: I built core-image-minimal yesterday without any apparent issues Jun 02 13:40:25 or was it the day before, I forget Jun 02 13:40:33 bluelightning. I did as well, for some targets, but now I'm testing some omap changes and it blew up there. call me confused. Jun 02 13:40:55 I was building for beagleboard if that makes a difference Jun 02 13:41:23 strangely, that's the one that doesn't work for me. I'm testing out a largish merge before pushing it out and can't get past gcc. Jun 02 13:41:42 I'll do an update and start a new build from scratch Jun 02 15:07:06 gm all Jun 02 15:07:17 hi zenlinux Jun 02 15:07:45 zeddii: build of core-image-minimal for beagleboard succeeded again FYI Jun 02 15:07:56 * zeddii weeps openly Jun 02 15:08:06 I removed everything and qemuarm just built. Jun 02 15:08:12 I'm switching to beagleboard now. Jun 02 15:08:43 bluelightning, I've only got meta/meta-yocto as layers. is that what you have ? Jun 02 15:09:10 hmm... crap, I had meta-crownbay still enabled :/ Jun 02 15:09:33 not that it should affect anything but it's not the test I thought I was doing Jun 02 15:09:48 agreed. it shouldn't impact anything. I'll see how this build goes. Jun 02 15:10:03 my head is hurting from slamming into my desk, so I hope it works ;) Jun 02 15:10:35 I'm not a doctor but I think that's unlikely to improve your headache ;) Jun 02 15:11:08 good tip. I'll just go for more coffee instead. Jun 02 15:27:15 RP__: did you push the gnutls fixes JaMa did ? Jun 02 15:30:33 otavio: yes it's there Jun 02 15:30:54 otavio: but I didn't bump PR so if it fails for you, you had to -c clean it first Jun 02 15:58:59 Site info could not determine endianess for target Jun 02 15:59:14 I am ending up with this message quite a bit while parsing today Jun 02 16:05:29 khem: allarch it should be fixed by todays patches Jun 02 16:05:42 hmm siteinfo_get_endianess checks for only endian-little and endian-big Jun 02 16:05:47 allarch is third case Jun 02 16:05:52 and should be added Jun 02 16:06:06 e.g. may be endian-free Jun 02 16:06:16 or biendian Jun 02 16:06:42 :) Jun 02 16:08:37 khem: is there still a separate siteinfo.bbclass file in meta-oe? Jun 02 16:09:04 ah, hmm. allarch recipes shouldn't be checking endianess Jun 02 16:10:34 RP__: I think yes Jun 02 16:10:39 but that does not matter Jun 02 16:10:43 http://paste.ubuntu.com/616855/ Jun 02 16:10:46 should fix it Jun 02 16:10:52 khem: I would wonder why it needs its own Jun 02 16:11:08 RP__: I dont know either Jun 02 16:11:16 khem: which recipes are triggering that? Jun 02 16:11:25 RP__: but there were some improvents that Chris did but they are still in oe.dev Jun 02 16:11:39 RP__: allarch recipes Jun 02 16:11:42 I guess Jun 02 16:11:47 let me try the fi Jun 02 16:11:48 x Jun 02 16:11:48 khem: which ones Jun 02 16:12:00 let me see Jun 02 16:12:00 khem: Are they allarch in meta-oe or oe-core? Jun 02 16:12:12 need to parse verbose Jun 02 16:12:55 RP__: above fix in place the errors are gone now let me see which recipes were causing it Jun 02 16:13:10 I am sure they were some allarch inheriting ones Jun 02 16:16:09 khem: was it fatal error or just warning? Jun 02 16:17:10 JaMa: its a bb.error but it still continues to parse Jun 02 16:17:45 * JaMa curious because built few images today without seeing it Jun 02 16:17:46 JaMa: I thought bitbake would stop at some point but it does not Jun 02 16:21:00 RP__: the recipes are from oe-core as well as from meta-oe Jun 02 16:21:07 and they are many Jun 02 16:21:32 RP__: here is my parse output http://paste.ubuntu.com/616867/ Jun 02 16:21:49 one common thing they have is they all inherit allarch Jun 02 16:23:12 RP__: btw is there some step between -c cleanall which removes sstate data and removing sources from downloads dir? looking at base.bbclass doesn't look like there is, would you find it usefull (should I send patch for it?) Jun 02 16:26:51 something like cleansstate would be nice Jun 02 16:26:52 JaMa: nice idea Jun 02 16:26:58 sometimes I dont want to clean sources Jun 02 16:27:15 but I want to rebuild it Jun 02 16:29:43 siteinfo in meta-oe defines both SITEINFO_ENDIANESS and SITEINFO_ENDIANNESS as if we were less confused already Jun 02 16:30:09 and use of both variables is spread across everywhere Jun 02 16:33:36 JaMa: I think one argument against that would be that if sstate is causing problems that necessitate that function it would be better to fix those problems Jun 02 16:33:57 of course that's not necessarily a fun task Jun 02 16:35:35 JaMa: it would be really nice to bump PR of gnutls. It makes it tested on builders and all current users. The fix worked for me but in any case would be nice to have it bumped. Jun 02 16:37:13 JaMa: fixing it myself since I got another fix on it. Jun 02 16:40:31 bluelightning: agreed.. but sometimes I hit ^C just in time to get incomplete _populate-lic.tgz somehow and for recipes with huge sources I really don't want to redownload it just because it was badly repackaged on local Jun 02 16:41:33 JaMa: that's really a bug though Jun 02 16:41:43 so now I have to options rm -f sstate-cache/sstate-sth manually or move downloads before -c cleanall Jun 02 16:41:51 s/to/two Jun 02 16:42:23 I do know that Ctrl+C out (if you press it more than once) does leave a mess behind and it would be nice if we could fix that Jun 02 16:44:24 JaMa: I'd say that cleanall should be change to not drop downloads and we ought to have another target for it Jun 02 16:44:28 bluelightning: sometimes were just want to rebuild a package and not use sstate Jun 02 16:44:32 JaMa: like cleanfiles Jun 02 16:44:41 especially when we rebuilt compler Jun 02 16:45:07 khem: I think cleanall isn't intuitive about it dropping the files Jun 02 16:45:26 khem: it means, for me, as clean all built data (sstate included) Jun 02 16:45:38 khem: but not clean cache Jun 02 16:46:12 otavio: we can keep old cleanall as it was and add cleansstate calling just sstate_clean_cachefiles(d) Jun 02 16:46:13 it might be any interepretation as long as we agree on it Jun 02 16:46:21 khem: that's where I would like to see -c rebuild reinstated IMHO Jun 02 16:46:53 otavio: and clanall would remove all including sstate as it does now Jun 02 16:47:18 bluelightning: I think clean is more intuitive Jun 02 16:47:50 khem: so cleansstate ? Jun 02 16:47:53 khem: if you're only wanting it for rebuild it forces you to go through two invocations of bitbake for one task though, which can be annoying Jun 02 16:48:47 I'm not suggesting clean should go away Jun 02 16:49:08 bluelightning: its ok to do it twice at least user knows something is not sweeping below the nose Jun 02 16:52:06 hmm, I'm not exactly convinced Jun 02 16:56:20 bluelightning: hmm sometimes even -c cleanall doesn't do what I expect.. :/ http://paste.pocoo.org/show/399562/ Jun 02 16:58:48 RP__: so should we keep SITEINFO_ENDIANESS or SITEINFO_ENDIANNESS with NN Jun 02 17:05:03 khem: Double N is the correct spelling Jun 02 17:05:27 khem: Your build looks to be dereferencing variables which mine doesn't. I'd like to understand why :/ Jun 02 17:07:05 slugos Jun 02 17:07:48 khem: hmm. Maybe there is some other variable we need to force for all arch packages then :/ Jun 02 17:08:07 khem: It would be good to work out which variable is actually doing this... Jun 02 17:08:16 hmm Jun 02 17:08:38 khem: The siteinfo fix is just a bandaid on a bigger issue Jun 02 17:08:47 yeah i see Jun 02 17:13:08 RP__: I wonder how can I track it Jun 02 17:13:48 khem: I wonder if the sstate dependencies would tell us? Jun 02 17:17:33 RP__: I use the variable on distro conf file Jun 02 17:17:36 could that be it Jun 02 17:17:47 khem: how did you use it? Jun 02 17:18:39 add le or be to image name Jun 02 17:19:21 IMAGE_BASENAME = slugos${SITEINFO_ENDIANESS} Jun 02 17:19:58 Something like update-modules shouldn't dereference IMAGE_BASENAME though Jun 02 17:20:05 It has to be some other use... Jun 02 17:27:10 RP__: when I change a FILES_ using bb.data.setVar how can I ask for it to be save on the database? Jun 02 17:28:00 otavio: it does "save" it. It depends what context you're in as to which data store its saved in though Jun 02 17:28:35 RP__: the problem is that files split by locale are not marked as included ... Jun 02 17:28:48 RP__: it does the FILES_ mangling on package class Jun 02 17:28:56 otavio: right Jun 02 17:29:04 RP__: so I get warnings for those Jun 02 17:29:19 otavio: I'm missing a whole load of context in this conversation ;-) Jun 02 17:29:58 RP__: package_do_split_locales at package.bbclass ... Jun 02 17:30:19 RP__: it changes FILES to split those right? Jun 02 17:30:46 RP__: but when bb check of not packaged files I get warnings for those Jun 02 17:30:52 RP__: which seems wrong Jun 02 17:31:30 otavio: It sounds like your recipe is installing empty locale directories Jun 02 17:31:39 otavio: don't do that and you won't see the warnings Jun 02 17:32:00 * RP__ had to look at the code to figure out what you were talking about Jun 02 17:32:06 RP__: by empty locale directories you mean what? Jun 02 17:32:29 RP__: the code I have is lightly changed since I am adding support to split qm files on it Jun 02 17:32:35 otavio: The line that says "locales = os.listdir(localedir)" Jun 02 17:32:43 RP__: and it works fine but I get the warning Jun 02 17:32:44 That comes up with a list of locales to package Jun 02 17:32:49 * otavio checks Jun 02 17:32:57 It sounds like you have a set of locales that don't exist Jun 02 17:33:27 * RP__ can't help you debug code I have no knowledge of Jun 02 17:33:38 RP__: not really Jun 02 17:33:44 RP__: wait, will paste it Jun 02 17:34:29 http://paste.debian.net/118690/ Jun 02 17:35:52 otavio: What happens if there is a locale that doesn't have a qt translation counterpart? Jun 02 17:36:09 RP__: counterpart? didn't get it Jun 02 17:37:20 otavio: summary - don't add things to files that don't actually exist Jun 02 17:37:27 otavio: I need to hear AFK now, sorry Jun 02 17:37:33 RP__: they do! Jun 02 17:37:42 RP__: they do exist. Jun 02 18:14:07 RP__: I think I know whats going on Jun 02 18:14:51 RP__: BASE_PACKAGE_ARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}" Jun 02 18:15:00 RP__: thats in tune-xscale.inc Jun 02 18:17:30 RP__: so now question is should these tune files be barred from inclusion into allarch recipes ? might be a tough ask Jun 02 18:23:00 RP__: and meta/conf/machine/include/tune-xscale.inc also has INHERIT += "siteinfo" Jun 02 18:30:39 otavio: Maybe they're ending up in a different package then? Jun 02 18:30:46 They have to be going somewhere... Jun 02 18:31:44 khem: Do you see the problem if you add BASE_PACKAGE_ARCH = "" to allarch.bbclass? Jun 02 18:45:39 RP__: it seems they're going to sysroot-destdir and this ought not be done Jun 02 18:45:56 RP__: the sysroot copies what? by default Jun 02 18:51:25 otavio: ignore the sysroot stuff, that happens separately Jun 02 18:51:45 I meant are they being split into a separate package Jun 02 18:51:51 RP__: right but this is the only thing that might cause it Jun 02 18:51:53 RP__: they're Jun 02 18:52:03 RP__: if I look at packages-split they're all there Jun 02 18:56:26 RP__: yeah or may be set it to "all" Jun 02 18:56:44 RP__: I added BASE_PACKAGE_ARCH = "all" and it fixes the issue Jun 02 18:57:05 khem: cool Jun 02 18:59:01 RP__: I will send a patch with some more breakage fix on uclibc :( Jun 02 18:59:26 khem: breakage newly introduced? Jun 02 19:02:47 (devel)~/hacking/el% ls -l tmp-eglibc-eglibc/work/i586-oe-linux/ostt-ui-0.0+gitr4+11fae639aa68be6b654561673d586545c92aac4c-r2/packages-split/ostt-ui-locale-pt-br/usr/share/cclient/i18n/ Jun 02 19:02:51 total 4 Jun 02 19:02:53 -rwxr--r-- 2 otavio otavio 23 Jun 2 19:01 pt_BR.qm* Jun 02 19:02:54 RP__: it does exist, as I said ... Jun 02 19:03:03 RP__: I am confusing with this warning Jun 02 19:03:56 otavio: I'm totally confused with this. If you'd like help, please take the time to construct a clear email to the mailing list explaing what the problem is, what changes you've made and what is happening that is unexpected Jun 02 19:04:26 otavio: You've never even shown me what the warning is or anything about which files are or aren't there so expecting me to answer these questions isn't really fair Jun 02 19:04:51 RP__: the not package warning ... Jun 02 19:05:09 WARNING: the following files were installed but not shipped in any package: Jun 02 19:05:09 WARNING: /usr/share/cclient/i18n/es_ES.qm Jun 02 19:05:11 this Jun 02 19:05:52 that means a file was installed into the install stage, (in do_install) but was not listed in any of the FILES_... patterns for inclusion into a package split Jun 02 19:06:16 RP__: yes util-linux upgrade Jun 02 19:06:19 and this is different to what I thought you were asking :( Jun 02 19:06:27 fray: I know what it means. The problem is that it has been put into the package Jun 02 19:06:52 RP__: we need to get some siteinfo stuff from oe Jun 02 19:06:55 (devel)~/hacking/el% dpkg -c tmp-eglibc-eglibc/deploy/ipk/i586/ostt-ui-locale-es-es_0.0-87-g11fae63-r2_i586.ipk | grep es_ Jun 02 19:06:58 -rw-r--r-- root/root 23 2011-06-02 19:04 ./usr/share/cclient/i18n/es_ES.qm Jun 02 19:07:44 you shouldn't end up with a warning if a split gets a copy.. I don't know whats going on, offhand at least Jun 02 19:07:54 * RP__ neither Jun 02 19:08:17 otavio: please do as I suggested above and write this up properly. its too complex to deal with adhoc here Jun 02 19:08:50 RP__: I will first debug it a little bit further Jun 02 19:08:54 otavio: I'd also suggest reproducing that on a clean build as it doesn't make sense Jun 02 19:20:01 RP__: the bug is quite simple ... will fix it now Jun 02 19:20:01 heya, anyone else having a problem running bitbake poky-minimal-directdisk ? whenever i try it i get ERROR: Function 'poky-image-minimal-directdisk: LIC_FILES_CHKSUM points to invalid file Jun 02 19:21:43 RP__: it missed the / in /usr so it looked for .usr not ./usr Jun 02 19:35:31 RP__: I sent the patch to oe-core ml; it does work for me now Jun 02 19:35:56 RP__: it was my fault on the package.bbclass change; but now fixed Jun 02 19:46:00 RP__: I posted the patches to ml Jun 02 20:28:01 RP__, in trying to extract the GROUPADD_PARAM_packagename for each package I've come up with this: http://pastebin.com/LqZtnsfX Jun 02 20:28:50 but how can this be used in the shell functions? Jun 02 20:29:17 also, anonymous python seems to be run during recipe parse time, so the context this is running in may not be what I need Jun 02 20:32:38 zenlinux: ${@my_python_fun()} ? Jun 02 20:32:57 zenlinux: git grep $\{@ Jun 02 20:33:06 incandescant, you may have just made my day Jun 02 20:33:10 should show you some examples Jun 02 20:33:10 thanks Jun 02 20:33:12 np Jun 02 21:03:16 khem, ping Jun 02 21:06:10 dvhart: yes Jun 02 21:07:31 khem, so I'm hitting the set-but-not-used build failure in perf bench/sched-pipe.c. I've added -Wno-unused-but-set-variable to work around it - but it seems this shouldn't be happening with the patch you backported to linux-yocto using __used ret; Jun 02 21:07:40 wondering if you have any thoughts on why I might be hitting this Jun 02 21:09:09 hmmm Jun 02 21:09:46 is the offending definition declared with __used ? Jun 02 21:10:45 yes Jun 02 21:11:15 int __used ret, Jun 02 21:11:24 | bench/sched-pipe.c:58:6: error: variable 'ret' set but not used [-Werror=unused-but-set-variable] Jun 02 21:11:54 ok and source ? Jun 02 21:12:16 khem, sorry, for which? Jun 02 21:12:27 bench/sched-pipe.c Jun 02 21:12:52 btw. is it happening on some given arch only ? or always Jun 02 21:13:56 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/tree/tools/perf/bench/sched-pipe.c?h=zedd/yocto/standard/beagleboard&id=982b19ec377a48b9730aaae2b7ac8dd23a3c5957 Jun 02 21:14:08 khem, seems to be arm Jun 02 21:14:25 although zedd and I are seeing different things - seems to build for him Jun 02 21:14:36 despite us both using gcc 4.6.0 Jun 02 21:15:01 hmm Jun 02 21:15:15 i guess something might be fishy Jun 02 21:15:26 either your sources are not patched Jun 02 21:15:38 or he is using gcc 4.5 Jun 02 21:17:44 khem.... hrm... I did a branch contains to show your patch and it appeared Jun 02 21:17:50 I just did it again... and I'm not seeing it Jun 02 21:17:51 sigh Jun 02 21:17:58 :) Jun 02 21:18:17 and indeed the __used is no longer there Jun 02 21:18:18 wtf Jun 02 21:18:29 * dvhart goes to throw someting Jun 02 21:18:34 thanks khem Jun 02 21:18:38 sorry for the false alarm Jun 02 21:18:47 I'll go sort out what's up with the checkout Jun 02 21:23:18 * zenlinux does a happy jig thanks to incandescant 's tip Jun 02 21:23:59 hmmm...contrasting emotions between /me and dvhart ;) Jun 02 21:24:17 ;-) Jun 02 21:24:31 * dvhart throws something at zenlinux , that should balance thing sout Jun 02 21:24:43 zenlinux: now you get to document that for others to find ;-) Jun 02 21:24:52 heh Jun 02 21:25:11 we need to get dvhart a nerf gun Jun 02 21:29:04 zenlinux, that might not be a good idea Jun 02 22:51:25 fray: ping Jun 02 23:01:38 khem: the mailing list might work with attachements now **** ENDING LOGGING AT Fri Jun 03 02:59:57 2011