**** BEGIN LOGGING AT Wed May 28 02:59:59 2014 May 28 04:03:54 p May 28 04:05:22 dca: thats debug package May 28 04:06:04 dca: the real package would come from libxmu May 28 07:27:03 good morning May 28 07:42:09 hi mckoan May 28 08:21:32 asd May 28 08:41:33 morning all May 28 08:44:02 morning! May 28 08:45:31 hi pompomJuice May 28 08:46:02 another day fixing random bugs for me May 28 08:52:18 so annoying May 28 08:52:56 I am getting this weird git fetch issue where it is trying to do a git-remote and it fails because of this mesterious ^{} that is concatinated to the last ref May 28 08:53:12 only happens with my u-boot recipies May 28 08:53:16 they are old May 28 08:53:26 cant be upgraded because I don't know how May 28 08:53:34 u-boot is not for noobs May 28 08:53:51 all the other git recipies work though May 28 08:53:54 just bizarre May 28 08:55:14 and inspecting the recipies yield nothing obvious May 28 08:59:01 yea May 28 08:59:13 cmd = "%s ls-remote %s://%s%s%s %sEND" % \ May 28 08:59:20 results in May 28 08:59:33 The command git ls-remote git://arago-project.org/git/projects/u-boot-omap3.git refs/heads/v2010.06_TI81XXPSP_04.04.00.01 refs/tags/v2010.06_TI81XXPSP_04.04.00.01^{}END gave empty output unexpectedly May 28 09:00:26 recipy contains SRCREV = "v2010.06_TI81XXPSP_04.04.00.01" May 28 09:02:12 pompomJuice: arago-project.org isn't know for it's uptime or stable git service May 28 09:02:48 you can try adding ;protocol=http to the SRC_URI May 28 09:02:50 or https May 28 09:04:05 ok il try May 28 09:06:38 seems to require a username password? May 28 09:06:52 trying http May 28 09:08:59 koen May 28 09:09:17 but if I execute the git ls-remote without the ^{} it works...? May 28 09:09:47 same problem May 28 09:10:12 I get a ^{} concatinated to my rev... let me see if I can debug... May 28 09:13:25 I tested ptest-runner.sh yesterday. I saw lots of failures due to getfacl/setfacl not being available. I do have "libacl", but not "acl", which contains the binaries, in the target image. May 28 09:14:13 Is there a reason for why acl.inc doesnt have "acl" in its RDEPENDS_${PN}-ptest ? May 28 09:18:12 search = "refs/heads/%s refs/tags/%s^{}" % (ud.unresolvedrev[name], ud.unresolvedrev[name]) May 28 09:18:32 what is that ^{} doing there? it is somehow selectively jamming my uboot recipies May 28 09:19:57 git.py line 343 May 28 09:28:26 who is Richard Purdie? May 28 09:28:33 God May 28 09:28:39 God makes mistakes May 28 09:28:44 lets get him May 28 09:28:46 lol May 28 09:29:08 pompomjuice: ^{} is used to dereference a tag object to a commit. May 28 09:29:12 ifI google git ls-remote "^{}" May 28 09:29:14 I get nothing May 28 09:29:36 ^{} as regex makes no sense May 28 09:29:47 ok... May 28 09:29:50 let me google that May 28 09:30:29 thanks zibri, I found some docs May 28 09:59:26 ok... so I have learned a few things now May 28 09:59:33 the is anew change in yocto1.6 May 28 10:00:16 and that if you try to ls-remote a tag that is a lightweight tag with a ^{} it returns nothing instead of the ref... May 28 10:00:44 not all tags are annotated, and the ones that are not annotated are not available anymore if you do it this way May 28 10:01:34 which makes sense if you go into a zero tolarence mode for tags May 28 10:01:39 sucks for me though May 28 10:24:28 here is the solution May 28 10:24:29 http://hastebin.com/qituzavosi.diff May 28 10:28:24 RP: ^ May 28 10:33:34 pompomJuice: hmm, this is tricky :/ May 28 10:41:06 pompomJuice: we may have to fall back like you describe, looks like we can't win... May 28 10:50:42 Shouldn't PACKAGECONFIG_GL = "gles2" in qtbase_%.bbappend give me a Qt5 configured with -eglfs? May 28 10:59:28 tasslehoff: yes May 28 11:00:33 Crofton|work: jenkins is busy to test master changes, so I would prefer daisy maintainer to run own builds May 28 11:01:24 Crofton|work: currently running test-dependencies build for last 12 days, 2 more days to go May 28 11:04:25 JaMa: hm. odd. I've changed Yocto-version, board and distro, and lost that option somehow May 28 11:10:04 JaMa, sounds like we need more hardware May 28 11:13:31 Crofton|work: and more people reading logs from it May 28 11:13:38 :) May 28 11:14:35 JaMa: this is my qtbase_%.bbappend: http://pastebin.com/dGxHYrMd. it builds with opengl and opengles2, but not eglfs. May 28 11:21:55 tasslehoff: check the configure log May 28 11:23:24 JaMa: it doesn't list eglfs in Build options, only opengl and opengles2 May 28 11:43:04 RP, I am having issues on a few recipies... not a train smash May 28 12:00:03 Another change that got me is it seems before I could use a branch name as a SRCREV, now I cant. May 28 12:01:08 seems so yeah May 28 12:01:12 use branch= May 28 12:09:53 JaMa: DISTRO_FEATURES_remove = "x11 wayland" in local.conf did the trick May 28 12:10:34 btw, how do I know what I can put in my image.bb, and what needs to be put in local.conf? May 28 12:18:40 bencoh: indeed, I am ficiong all these broken git recipies of ours May 28 12:18:45 fixing* May 28 12:49:40 Just in general, do you guys have strange issues with Lenaro > 4.7? May 28 12:49:54 Ever since I went from 1.4 to 1.5 shit has been going wrong May 28 12:51:47 As far as I can tell, something has gone wrong with the optimizer in lenaro 4.8+ May 28 12:52:21 some of our c++ programs have bizarre issues, then I take away the -O2 and then they work... May 28 12:52:26 lenaro? May 28 12:52:38 is that the chinese knock-off version of linaro? May 28 12:52:45 lol May 28 12:52:54 vervlaks May 28 12:53:06 linaro *cough* May 28 12:53:14 prpl? May 28 12:53:16 so one of the strange issues looks like this: May 28 12:53:23 haven't had troubles with 4.8, but I did have issues with linaro binutils May 28 12:53:34 which should be fixed in the new binutils drop May 28 12:54:08 struct data; memcpy( zmqBuffer, data, sizeof(data) ); <----- GCC 4.8 FAILED May 28 12:54:25 replace memcpy with a for loop all problems dissapear... May 28 12:54:33 or so I thought... May 28 12:54:34 now May 28 12:55:10 struct data contain arrays and oter structs etc... somewhere in the middle of this struct in memory there are 4 doubles.... May 28 12:55:34 they come through as zero May 28 12:56:08 so when I print those values before I memcpy( zmqBugger, data, sizeof(data)) it suddenly works.... <----------- super strange May 28 12:56:18 if I remove -O2 May 28 12:56:24 everything works as expected May 28 12:56:47 so I have heizenbug May 28 12:57:08 anyway... May 28 12:57:18 im upgrading to 1.6... May 28 12:57:28 almost there.. May 28 13:14:50 once I get to yocto1.6 imma go home and down a shampagne... took me 6 months to take it from 1.3 to 1.6... May 28 13:16:13 and it all started when mono demanded gcc 4.7+... a chain reaction.... nuclear chain reaction May 28 13:16:35 talking about gcc and strange stuff .... May 28 13:16:56 I hitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 May 28 13:17:00 landing out of my depth in irc channels May 28 13:17:15 memset? May 28 13:17:25 nope, push_minipool_fix May 28 13:17:55 I missed that one somehow May 28 13:18:16 the code that triggered it isn't in oe repositories May 28 13:18:38 yea May 28 13:18:43 as is all sources of problems May 28 13:18:53 We have a version two of our product May 28 13:18:57 well this really is a gcc bug May 28 13:19:09 yea gcc bugs are not cool May 28 13:19:23 because the boss man does not understand that you have nothing May 28 13:19:28 I ""fixed"" (read: kludged) it with a 2-lines gcc patch inspired from gcc ml, OE might be interested since it doesnt seem to be included May 28 13:19:28 you are in the dark May 28 13:20:03 (and probably wont before 4.9/4.10) May 28 13:20:10 damn May 28 13:20:26 I will make sure I go check what that bug is about May 28 13:20:39 might be causing problems for me too May 28 13:21:31 it fails at compile time, so I doubt it May 28 13:21:43 yea internal error May 28 13:21:53 time to recompile gcc in debug mode and start debugging ;) May 28 13:22:01 over here we are not scared to do such things May 28 13:22:24 12 months ago I did not even know about oe May 28 13:22:36 high level programmer, c#... May 28 13:22:36 honestly I don't really want to :) May 28 13:22:49 not my cup of tea May 28 13:22:50 I donno, oe for me is like...amagad May 28 13:22:52 (gdb on gcc) May 28 13:23:02 hehe May 28 13:23:16 that is what you need to be prepared to do if you work on embedded devices.. May 28 13:23:32 yeah, been working on those for years ;) May 28 13:24:20 See my new stratigy with management is to make them understand that if you have this uber hardware device then you must understand that you are opening yourself up to all kinds of shenanigans... sunspot activity... May 28 13:24:40 random compiler failure May 28 13:24:56 if the moon is aligned skew your build might break... May 28 13:25:05 so now things are going better... May 28 13:25:14 they leave me alone and I can do my work properly May 28 13:25:21 investigate every error May 28 13:26:29 before it was like... "...but sir the compile broke we got nothing.... BOSS: Silence! Pull more levers, push more buttons I want that thing out tomorrow" May 28 17:44:24 hmm, shouldn't xf86-video-ati in meta-oe rrecommends linux-firmware-radeon rather than linux-firmware? we should really give some thought to how to handle linux-firmware better. some machines pull in the toplevel linux-firmware recipe with no real reason for it, or to support expansion hardware whether the distro wants to support that or not May 28 17:44:25 * kergoth ponders May 28 17:51:29 kergoth: linux-firmware-radeon didn't exist when that rrecommends was added May 28 17:51:38 ah, fair enough :) May 28 17:53:11 I added it a day later and forgot to update xf86-video-ati May 28 17:53:42 * koen still doesn't have a 100% working glamoregl May 28 17:55:10 :D May 28 20:17:24 bencoh:are you seeing this with gcc 4.9 or 4.8 ? May 28 20:23:08 khem: 4.8 May 28 21:15:56 is there a way to change the name of the sdk when you use populate_sdk? May 28 21:24:37 Crofton|work: which part of the name? May 28 21:25:03 just something so I know which image the sdk is from May 28 21:26:34 I'm pretty sure in current versions the image name is in the SDK output file name May 28 21:27:13 hmm May 28 21:27:17 I'll check again May 28 21:27:40 actually I might be mistaken... still digging May 28 21:27:58 my impression is the name is always the same May 28 21:29:18 ah, it's in poky.conf of all places May 28 21:29:45 perhaps you can just do the same in your config May 28 21:29:52 it does: SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}" May 28 21:30:12 so you set SDK_NAME May 28 21:30:25 I wonder why that ended up in poky.conf May 28 21:30:52 but basically we set SDK_NAME May 28 21:30:56 yep May 28 21:31:06 it seems like something we ought to consider moving up to defaultsetup.conf or similar May 28 21:31:24 meta/conf/bitbake.conf:SDK_NAME_PREFIX ?= "oecore" May 28 21:31:24 meta/conf/bitbake.conf:SDK_NAME = "${SDK_NAME_PREFIX}-${SDK_ARCH}-${TUNE_PKGARCH}" May 28 21:31:35 yep May 28 22:10:14 bencoh: interesting do you have a reproducer May 28 22:18:09 khem: I'd need to revert my patch but I think I could yeah May 28 22:19:36 radoen-ucode seems a tad newer than what's in linux-firmware May 28 22:20:45 bencoh: it would be interesting if you can create reproducer May 28 22:27:52 sounds doable May 28 23:41:39 I dont understand bitbake -S printdiff ... For "acl" I get messages that tasks couldn't be used from sstate cache, but "bitbake acl" seems to run straight from cache May 28 23:43:13 Or is it information from the latest rebuild I'm seeing ? May 28 23:57:44 thats concerning, afaik it shouldn't be doing that May 28 23:58:20 afaik it's supposed to find the cache entries which most closely match what you have right now, and show the delta. in a case where you can build from sstate, the ones which closely match it should be an exact match with what you're building now, and there should be no delta May 29 00:17:44 mhm.. strange May 29 00:20:06 kroon: might want to open a bug. I'm guessing you have multiple sets of sstate floating around and it incorrectly grabbed one that was close to what you're building instead of the exact match, but it's richard's baby, he'd know better than i May 29 00:55:23 kergoth, could you test if the output looks correct in your setup ? May 29 00:55:41 kergoth, I see this output for basically any recipe I try May 29 00:57:08 kergoth, I do use wipe-sysroot/cleanup-workdir/sstate-cache-management often, and do inc. rebuilds, so maybe its one of them that is confusing my setup May 29 00:58:04 im using master branches btw **** ENDING LOGGING AT Thu May 29 03:00:00 2014