**** BEGIN LOGGING AT Tue Jan 21 02:59:59 2014 Jan 21 09:36:09 morning all Jan 21 09:41:42 hey bluelightning Jan 21 09:41:49 hi koen Jan 21 09:48:51 my head hurts after reading package.bbclass Jan 21 09:49:17 and $*@($#@ git blame hitting indentation changes multiple times Jan 21 09:53:04 since my coffee machine broke down this morning I'm a bit slow Jan 21 09:53:10 yes, that class does an awful lot and has been around for quite a long time Jan 21 09:53:13 so please have a look at http://lists.openembedded.org/pipermail/openembedded-core/2014-January/088597.html Jan 21 09:54:42 koen: at a glance the patch looks OK to me Jan 21 09:55:49 right Jan 21 09:55:56 but package.bbclass gives me the creeps Jan 21 09:56:04 "it can't be this simple to fix" Jan 21 09:56:17 I'm doing a build now to see the fallout Jan 21 10:00:41 test build has the expected result: stripped files, no debegedit failure Jan 21 10:02:42 also looks ok to me Jan 21 10:05:25 * koen waits for fray to wake up Jan 21 10:06:27 hmmm Jan 21 10:06:37 why does every BSP layer have a mesa bbappend? Jan 21 10:07:04 virtually all of them seem to do the same thing with slightly different python code Jan 21 10:07:56 koen: about that last patch, in klibc long ago was added INHIBIT_PACKAGE_DEBUG_SPLIT Jan 21 10:08:19 could you pls check we still need that? Jan 21 10:09:06 * koen bitbake klibc Jan 21 10:09:41 thx ;) Jan 21 10:10:00 hmmm, my aarch64 patch isn't in yet Jan 21 10:10:23 koen: wasn't that obviated by the upgrade...? Jan 21 10:12:30 only one of the patches Jan 21 10:12:41 I sent a patch for the .inc and for the .bb Jan 21 10:12:49 the 2.0.3 upgrade fixed the bb Jan 21 10:13:25 I did merge one of the patches at ant_work's request, he said don't merge the other one... Jan 21 10:13:25 wait Jan 21 10:13:29 that went in Jan 21 10:13:34 * koen wonders what is going on Jan 21 10:13:34 hm, the klibc ML is dead since dec 27 and I thought they've added all Jan 21 10:14:04 bluelightning: ask hpa ;) Jan 21 10:14:37 meta-initramfs is not in the default layer setup :/ Jan 21 10:14:49 so it's not COMPATILE_HOST, but PEBKAC Jan 21 10:15:18 * koen retrieves backup coffee machine Jan 21 10:16:52 btw, there is still a fix to do (and sanitize, I know) Jan 21 10:16:55 THIS_LIBKLIBC = "libklibc (= ${PV}-${PR})" Jan 21 10:17:01 PR has gone... Jan 21 10:17:23 I'm starting to regret pulling in the mesa updates into angstrom-dora Jan 21 10:17:58 mesa can do no wrong, it's perfect Jan 21 10:18:27 rburton: it's the gazillion bbappends in BSP layers doing masking magic for gles Jan 21 10:18:42 koen: isn't that just a PACKAGECONFIG now? Jan 21 10:18:52 i mean using mesa-gl, even Jan 21 10:19:05 it's easily fixed with an mv mesa_9.1.6.bbappend mesa_%.bbappend Jan 21 10:19:24 but I'd need to get those patches accepted into all the BSPs :( Jan 21 10:19:30 rburton: dora branch Jan 21 10:19:36 rburton: master is a bit better Jan 21 10:19:51 oh, wasn't aware of any major mesa fixes in master vs dora. Jan 21 10:21:34 I imported the 9.1.6 -> 9.2.2 locally Jan 21 10:21:36 rburton: http://dominion.thruhere.net/koen/angstrom/0001-glamor-add-0.5.1-git.patch Jan 21 10:21:55 aah, glamor Jan 21 10:22:00 does that actually, like, work now? :) Jan 21 10:22:14 it does on radeon hw Jan 21 10:22:28 it's *strongly* recommended to use it there Jan 21 10:22:44 since radeon devs only work 3d stuff Jan 21 10:22:52 neat Jan 21 10:22:59 last time i looked it was "in progress" Jan 21 10:23:15 it still is Jan 21 10:24:05 did you see Eric Anholts LCA talk? Jan 21 10:24:54 he expects it to beat SNA "soon" Jan 21 10:26:38 any meta-intel people around? Jan 21 10:26:50 what's the status of merging gummiboot into oe-core? Jan 21 10:27:15 ant_work: WARNING: QA Issue: File '/usr/lib/klibc-a7VswZo87UiUwSlwvpKvPHaEE3Q.so' from klibc was already stripped, this will prevent future debugging! Jan 21 10:27:39 looks like the klibc buildsys already strips bits Jan 21 10:27:55 no idea why the libname is weird Jan 21 10:28:37 it's RND Jan 21 10:28:54 shared libs do link only with that specific version Jan 21 10:29:22 that's the reason about THIS_KLIBC Jan 21 10:29:47 good, so it's not just me :) Jan 21 10:29:50 s/shared libs/shared utils/ Jan 21 10:30:54 it's so random that we can remove PR ;) Jan 21 10:31:54 ant_work: looks like you can remove the INHIBIT_PACKAGE_DEBUG_SPLIT Jan 21 10:31:59 koen: you should ping dvhart on gummiboot probably Jan 21 10:32:03 but if you do, you need to fix up FILES_${PN}-dbg Jan 21 10:32:12 bluelightning: thanks, will do! Jan 21 10:35:14 koen: I see, thx Jan 21 10:35:56 the debug files are pointless... Jan 21 10:36:29 right Jan 21 10:37:04 for bare-metal type of things stripping makes sense, debug split not so much Jan 21 10:37:06 usually you'd debug a binary linked against klibc not the lib itself... Jan 21 10:37:15 I guess klibc is an edge case Jan 21 10:37:25 (so did I with kexecboot vs armv4/eabi) Jan 21 10:38:10 * koen waits for the delivery person to drop of the mainboard, cpu and radeon card Jan 21 10:46:21 koen: btw kexec-tools: efi runtime support on kexec kernel Jan 21 10:48:06 nice Jan 21 10:48:09 that reminds me Jan 21 10:48:14 I have a v2 for dracut Jan 21 10:48:19 I screwed up PV Jan 21 10:49:15 ant_work: I also discovered a feature of the kernel Jan 21 10:49:44 use 'initrd=0xaddress' and root=/dev/mmcblk0p2 and it will tried the initrd as initramfs Jan 21 10:50:03 only when root=/dev/ram0 triggers initrd mode Jan 21 10:53:45 yes, this is only for initrd Jan 21 10:53:54 all: if you're coming to FOSDEM, please put your name down in the appropriate section here (or ask me to if you have trouble editing): http://openembedded.org/wiki/FOSDEM_2014 Jan 21 10:54:11 koen: have you tried to stack more than one initramfs? Jan 21 10:57:29 no Jan 21 10:59:43 heh, I don't have a wiki account anymore Jan 21 10:59:48 * koen celebrates Jan 21 11:01:11 koen: you want me to put your name down? Jan 21 11:02:03 yes, general attendance Jan 21 11:02:15 I haven't decided yet if I'll bring demos Jan 21 11:02:32 no gangnam-robot this time? Jan 21 11:02:48 no Jan 21 11:02:52 koen: done Jan 21 11:02:57 bluelightning: thanks! Jan 21 11:03:21 * tbr will show up too and troll the OE stand, same procedure as every year Jan 21 11:04:01 I will bring some VLC chocolate Jan 21 11:04:22 damn it and I'm on a diet now too... Jan 21 11:04:52 dark chocolate is good for you :) Jan 21 11:05:09 although the vlc chocolate has a huge amount of sugar in it Jan 21 11:05:18 I thought FOSDEM is a diet-exception event? ;) Jan 21 11:05:50 tbr: I guess with all the beer and frites it might have to be :) Jan 21 11:31:46 hi Jan 21 11:32:04 guys: did someone of you got offer from Packt to review their books? Jan 21 11:34:23 added myself to wiki Jan 21 11:34:42 tbr: do not forget jolla phone - I would like to take a look Jan 21 11:36:30 hrw: there will be quite a few around. :) Jan 21 11:36:37 I'll bring two Jan 21 11:37:01 omg. I am still OE wiki admin Jan 21 11:45:12 hrw: yes, I've gotten a few offers from Packt Jan 21 11:45:22 I don't have time for that, sadly Jan 21 11:45:54 koen: I just wrote them with request of not contacting. never got reply to my reply Jan 21 12:23:36 ant_work: meta-initramfs is now added by default in our linaro config :) Jan 21 12:25:48 bluelightning: I don't have a wiki account but I'm attending FOSDEM; so if you could add me that would be good Jan 21 12:26:31 jackmitchell: done Jan 21 12:27:12 hii Jan 21 12:27:24 can we add extra cleaning steps for bitbake? Jan 21 12:27:33 like do_clean_append() ? Jan 21 12:29:04 Failure expanding variable do_clean: SyntaxError: invalid syntax (, line 2) Jan 21 12:29:19 when i tried to write do_clean_append() or do_clean_prepend() Jan 21 12:29:21 :-( Jan 21 12:29:25 any body help mee Jan 21 12:54:10 jackmitchell, get a wiki account Jan 21 12:54:59 it's a trap! Jan 21 12:55:20 * Crofton|work beats koen Jan 21 12:55:22 * jackmitchell agrees with koen, "Your biography must be at least 10 words long." Jan 21 12:55:28 I hope I am over this cold by FOSDEM Jan 21 12:55:30 NSA! Jan 21 12:56:27 Crofton|work: it will be warmer in brussels than at home? Jan 21 12:56:40 never can tell Jan 21 12:56:40 here, we finally got snow during night Jan 21 12:57:07 it's 42 american weather in brussels Jan 21 12:57:22 temperatures dropped in England yesterday too, will be expecting the first snow here soon Jan 21 12:57:26 snowing here right now Jan 21 12:58:17 the big snow storm, was that last year or 2 years ago? Jan 21 12:58:29 I forget Jan 21 12:58:35 me too :) Jan 21 12:58:41 US is big, one person big snow is another persons dud Jan 21 12:58:51 we are right on the edge for this one Jan 21 12:58:59 can we add extra cleaning steps for bitbake? Jan 21 12:59:05 like do_clean_append() ? Jan 21 12:59:07 there was been a big depression near island this winter Jan 21 12:59:13 when i tried to write do_clean_append() or do_clean_prepend() Jan 21 12:59:17 so .nl gets warm winds from the south Jan 21 12:59:21 Failure expanding variable do_clean: SyntaxError: invalid syntax (, line 2) Jan 21 12:59:47 I think I've only seen the car windshield iced over twice this winter Jan 21 13:00:09 SJ__: maybe first tell why you need it? Jan 21 13:00:12 SJ__: check if it's python or shell you're appending to Jan 21 13:00:22 SJ__: but I suspect you might be better off using addtask Jan 21 13:00:32 koen: lucky you Jan 21 13:03:08 I like snow Jan 21 13:03:11 oh ok but when we use this command bitbake -C clean Jan 21 13:03:20 and I work from home, so I only need electricity :) Jan 21 13:03:26 i need my function to be executed along with general operation of clean Jan 21 13:07:26 koen: electricity and internet Jan 21 13:07:41 SJ__: because? Jan 21 13:07:53 SJ__: addtest sjclean after do_clean? Jan 21 14:05:54 RP_: the DEBUG_SPLIT looks manageble, only a handful of recipes use it Jan 21 14:06:09 grub in oe-core ( after my patch gets in) Jan 21 14:06:30 klibc in meta-initramfs (which needs to whitelist the QA issues) Jan 21 14:06:38 an libhugetlbfs Jan 21 14:06:48 I'm fairly sure libhugetlbfs shouldn't use that flag Jan 21 14:06:55 and emgd in meta-intel Jan 21 14:07:08 which will likely have to whitelist the QA issue Jan 21 15:07:53 koen: agreed, just wanted to give a heads up of the issue Jan 21 15:18:10 RP: just quick question: that fsync patch for sstate, should fix slow bitbake -S or did you find it independently from it? Jan 21 15:19:20 JaMa: independently Jan 21 15:19:32 ok, I'll keep it running :) Jan 21 15:19:37 JaMa: I have another idea for -S, I think I'm going to teach it to take a parameter Jan 21 15:20:00 JaMa: so no option gives the current behaviour and adding other options makes it do different things Jan 21 15:20:11 s/current/previous/ Jan 21 15:20:29 thanks, I like that Jan 21 15:20:42 JaMa: that fsync is worth about 2s per task or two minutes on our benchmark build time Jan 21 15:21:13 I'm looking for something worth 12days so far :) Jan 21 15:21:14 JaMa: will try and get it in as soon as I can, having troubles with the todo list atm Jan 21 15:22:24 but there has to be some combinations of factors on that jenkins jobs, because in my local builds it was just 50% or so slower as reported in that e-mail Jan 21 15:22:44 once it's finished on jenkins I'll retest it on smaller sample to see what's different there Jan 21 15:26:44 JaMa: maybe size of sstate related? Jan 21 15:30:49 local - 1680 sigdata, 17143 sstate tgz Jan 21 15:30:55 jenkins - 27387 sigdata, 92403 sstate tgz Jan 21 15:31:04 there is some difference indeed :) Jan 21 15:36:52 30141 jenkins 20 0 1811M 1501M 3032 R 100. 2.3 155h | | | `- python /home/jenkins/oe/shr-core-branches/shr-core/bitbake/bin/bitba Jan 21 15:37:03 busy thread, strace shows a lot of stat() calls Jan 21 15:40:25 koen: any plans on qt5/aarch64? Jan 21 15:40:29 short 4MB sample http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/log.world.20140109_144047.log/log.strace Jan 21 15:40:57 koen: I just filled 3 bugs for Fedora for it so patches are ready and waiting ;D Jan 21 16:24:30 I've tried "bitbake virtual/kernel" with "-c clean", "-c cleanall", and also with "--no-setscene" after "-c clean". Only cleanall successfully worked after enabling INITRAMFS_IMAGE_BUNDLE=1. no-setscene doesn't do what I thought it did since it re-builds everything and cleanall requires me to re-fetch the entire kernel repo. Is there a better path? Jan 21 16:25:09 what are you trying to accomplish? Jan 21 16:25:19 cleanall is clean + remove of downloaded sources, thats what it does, by definition Jan 21 16:25:34 if you're wanting to force a rebuild of the kernel from scratch, rather than from sstate, you can use the cleansstate task Jan 21 16:25:48 (i realize said cleanall definition isn't implicit in the task name, unfortunately) Jan 21 16:26:38 sr105: cleansstate is just in the middle between "clean" and "remove of downloaded sources" Jan 21 16:26:50 ah, thanks. Jan 21 16:27:43 For some reason, switching on INITRAMFS_IMAGE_BUNDLE after having completely built without it, would always fail during the bundle step. Jan 21 16:28:07 If I performed a cleanall, it would work. Jan 21 16:29:09 which branch? Jan 21 16:29:26 there were some changes like last month IIRC related to this Jan 21 16:31:27 JaMa: I'm not exactly sure how to read this manifest file used by repo, but it says "dora" at the top and "master" for all of the individual repos. It's from the wandboard site. Jan 21 16:32:15 there are at least 2 changes in this area pending for dora, maybe you should test them Jan 21 16:32:35 http://lists.openembedded.org/pipermail/openembedded-core/2014-January/088074.html Jan 21 16:33:12 but I don't know if that's all what's needed from master in order to fix it, search the ML archives for whole story Jan 21 16:33:19 Will do. I need to figure out how to branch with repo first, since I need to keep my current working config around. Jan 21 16:33:21 Ok Jan 21 16:34:05 Perhaps it might be easier to checkout a new sources tree and keep the same build folder for both. Jan 21 16:35:06 I'll look at those e-mails and see if it's the same problem. It would complain that the uImage target for the kernel no longer existed. Jan 21 16:56:10 Does --no-setscene just trash the cache or something? After having run that and interrupted it. It wants to rebuild *everything* and it's constantly warning me about installing files over files it has previously installed. Do I have to remove my tmp folder to get it to do the faster setscene restore process now? Is there a way to fix this without removing tmp? Jan 21 16:57:25 I don't really see why people are so averse to wiping tmp Jan 21 16:57:32 re-extracting things from sstate really doesn't take very long Jan 21 16:57:53 * kergoth doens't know the answer re: —no-setscene behavior, however, never used the argument Jan 21 16:58:02 So, this is the second time this has happened to me. I just removed tmp and now it is rebuilding everything from scratch Jan 21 16:58:20 did you 'just' remove tmp? Jan 21 16:58:41 and you definitely didn't change anything else in the mean time, e.g. doing a "git pull"? Jan 21 16:58:51 I can see the shared state files are still there and new files with different hashes are appearing next to them Jan 21 16:58:54 bitbake doesn't fail to use an sstate archive unless said archive is removed, or the metadata checksums have changed meaning the sstate archives aren't valid for that case Jan 21 16:59:08 all of the git hashes are still the same in the config output of bitbake Jan 21 16:59:30 I don't know how this happened before either. Jan 21 17:00:01 well, something changed the hashes Jan 21 17:00:14 bitbake-diffsigs is intended to help track down why hashes have changed Jan 21 17:00:35 that only works on files in tmp Jan 21 17:00:45 it looks in the sstate cache as well Jan 21 17:00:53 or, it can if directed to Jan 21 17:01:03 Although, wait. I didn't delete tmp, I just moved it. Let me check. Jan 21 17:01:33 I couldn't get diffsigs to work on the siginfo files in the sstate cache. Jan 21 17:01:55 sr105: when you say you couldn't get it to work, what do you mean exactly? Jan 21 17:02:26 It complains that the siginfo files don't contain a list or something Jan 21 17:02:31 I can try it again. Jan 21 17:02:51 It's 99% likely that I wasn't running the tool properly Jan 21 17:03:51 bitbake-diffsigs sstate-cache/..../package-HASH1.siginfo sstate-cache/..../package-HASH2.siginfo Jan 21 17:06:42 if your siginfo files are corrupted, it sounds like you've got bigger problems on your hands than just this :) Jan 21 17:07:33 ugh, now diffsigs is working. I am noticing something I hadn't before, though. For m4-native, I see filenames with '-'s and some with ':'s Jan 21 17:08:16 like populate-sysroot and populate_sysroot and sstate:m4-native:x86_64-linux:1.4.17:r0:x86_64:3: vs sstate-m4-native-x86_64-linux-1.4.17-r0-x86_64-3- Jan 21 17:08:45 but they were fine until I ran --no-setscene Jan 21 17:08:57 I just did a complete set scene rebuild of tmp yesterday morning Jan 21 17:09:16 sounds like you've also updated your metadata recently Jan 21 17:10:29 hmm... diffsigs says things like this "Dependency on variable FC was added Jan 21 17:10:29 Dependency on Variable PR was removed" Jan 21 17:11:02 I'm suspecting more that it has something to do with the "repo" tool Jan 21 17:11:55 Is the : version - naming thing something to concern myself with? Jan 21 17:12:03 : versus - Jan 21 17:12:58 what do you mean? i use 'repo' too. Jan 21 17:14:43 Well, Before I had mistakenly done a "repo sync". It brought me to an unstable set of repos. So I manually reset the git repos to the old revs which I grabbed from scrolling back my terminal. After that, bitbake insisted on a complete rebuild. Jan 21 17:15:42 bitbake won't use the 'version' of the trees in which you have the recipes. it will parse the recipes, and get its checksum from content. Jan 21 17:16:01 And during our discussion here, I created a branch using "repo start working". Now, I did do that AFTER I had run --no-setscene and had tried another build without no-scene where it had also tried to rebuild everything. Jan 21 17:16:09 are you sure you 'restored' all git trees to their 'previous' commits? including bitbake? Jan 21 17:16:28 hmm... maybe I missed bitbake Jan 21 17:17:00 I went to the top of each of the trees listed in manifest and did a "git checkout hash" using the old hashed Jan 21 17:17:02 hashes Jan 21 17:17:08 if you ever get back to the same state as before, then the checksum will be the same as before, and it will start using the sstate files. Jan 21 17:17:28 I don't have a bitbake repo, just poky Jan 21 17:17:42 ok... Jan 21 17:17:50 Does poky have subrepos? Jan 21 17:18:12 my bitbake doesn't have .git Jan 21 17:18:14 i don't know, i use oe-core directly. Jan 21 17:18:31 this is a repo manifest wrapped around yocto Jan 21 17:19:01 ndec: I've just been trying to figure out what I changed to get back to the old state Jan 21 17:19:49 That's why I asked about the - vs : naming thinking I had been using a different bitbake Jan 21 17:19:54 can you check tmp/log/cooker log files? you will get all the commit ids used. Jan 21 17:20:02 sure Jan 21 17:23:33 gm all Jan 21 17:24:04 hi khem ! Jan 21 17:24:16 hi khem Jan 21 17:24:23 ah, I have it now. At least for this time, "repo start working" moved me back forward to the non-working hashes (while we've been talking) and I didn't notice. But I'm sure it wasn't working after the --no-setscene option as well before messing with repo. Oh well. I can now check the cooker logs using the timestamps to see what happened. Jan 21 17:24:27 khem: btw, ping on the buildhistory utf8 issue Jan 21 17:24:29 Thanks all for the help. Jan 21 17:24:35 bluelightning: how does it go Jan 21 17:24:53 bluelightning: yes Jan 21 17:25:12 khem: good thanks and you? Jan 21 17:25:18 bluelightning: I dont see problem with it on on my ubuntu 12.04 or debian system Jan 21 17:25:39 I am severely behind on stuff has been away for long Jan 21 17:25:46 khem: sure, np Jan 21 17:25:57 khem: it just breaks in the manner I described here unfortunately... Jan 21 17:26:31 hi khem Jan 21 17:29:02 hi woglinde Jan 21 17:29:12 bluelightning: I am trying out an example right now Jan 21 17:31:08 khem: thanks Jan 21 17:32:28 Thanks again for the help, using the cooker logs helped. It's back the way it was now. Jan 21 17:33:35 cool! Jan 21 17:33:37 \o/ Jan 21 17:34:10 bl did you see my mail about the sdk? Jan 21 17:34:41 bluelightning: can you add # -*- coding: utf-8 -*- to meta/classes/buildhistory.bbclass Jan 21 17:34:47 and see if that works Jan 21 17:35:08 woglinde: I did... it looks odd; but I don't have an answer as to why you'd see that Jan 21 17:35:24 what is the problem with SDK Jan 21 17:35:36 I'd ping laurentiu but he's not around Jan 21 17:35:46 probably gone home for the day Jan 21 17:36:13 okay Jan 21 17:36:28 khem see ml some x86 files in the arm sysroot Jan 21 18:26:45 khem: nope, no effect Jan 21 18:28:36 khem: I still see postinst files with \n in them Jan 21 18:29:53 khem: is that second parameter to decode() actually valid? the docs say it should state what's supposed to happen when an error occurs, rather than be another encoding scheme to decode Jan 21 18:32:18 hmm Jan 21 19:06:52 How does one remove old sstate files that don't match the current metadata configuration? Jan 21 19:07:15 see the scripts dir in poky/oe-core, there are sstate cache management scripts Jan 21 19:07:21 thank you Jan 21 19:07:44 personally I just put mine on a fs with atime, and periodically wipe any that i haven't used in a week or more, since i build so many configurations, it wouldn't make sense to remove what i'm not currently using :) Jan 21 19:15:14 kergoth: sounds like a better solution. Jan 21 19:42:29 not perfect, but as long as you have enough buffer space vs the rate of builds, it gets the job done :) Jan 21 20:41:01 Hi bluelightning Jan 21 21:07:15 hi apelete Jan 21 21:09:34 bluelightning: just saw this message on oe-devel: http://lists.openembedded.org/pipermail/openembedded-devel/2014-January/093838.html Jan 21 21:10:18 bluelightning: is every oe contributor concerned by this ? Jan 21 21:11:08 bluelightning: what does the message mean by the way ? :) Jan 21 21:12:04 hehe Jan 21 21:17:24 bluelightning JaMa: is that a call for membership application ? Jan 21 21:27:34 Hmm, it'd be nice to have some variable naming conventions. e.g. does context come before or after. PACKAGE_AUTO_DEPS, AUTO_PACKAGE_DEPS, DEPS_AUTO, ... if one looks at things like RDEPENDS, one would think that context comes last, but not always, sometimes context is first, to make the set of variables all seem to belong to that context.. Jan 21 21:27:40 * kergoth scratches head Jan 21 21:29:43 kergoth: true, there is auto AUTOPR, PRAUTO.. Jan 21 21:30:25 indeed Jan 21 21:30:35 would be nice to try to get some more consistency Jan 21 21:32:43 apelete: yes, that's it. Jan 21 21:36:21 ndec: nice, thanks for the answer Jan 21 21:40:18 bluelightning JaMa: do you think I could apply ? (don't know on what criteria members are chosen, better ask before engaging into the process) Jan 21 21:49:47 apelete: yes I think you should apply Jan 21 21:51:57 JaMa: heh, there's also use of _ separator or no. INC_PR, PRINC Jan 21 21:52:03 * kergoth should makea list of variable consistency problems :) Jan 21 21:54:00 JaMa: that's nice, will wrote a bio when I get some time and apply then, thanks Jan 21 21:55:07 kergoth: heh, nice example, but I would scream a bit if we rename one of these 2 :) Jan 21 21:55:38 haha, agreed Jan 21 21:55:44 better to wait for PRINC to die one day Jan 21 21:55:50 more for my list of would-be-nice-but-we-can't-ever-change-it, perhaps Jan 21 21:57:25 apelete: sorry was AFK - yes I would encourage anyone who is interested in the long term future of OE to join Jan 21 22:01:47 I have to take care of my membership. Jan 21 22:02:15 apelete, all we ask is show genuine interest in the project Jan 21 22:02:15 skipped last GA means on next GA I have to be as person or in proxy. Jan 21 22:02:20 yeah Jan 21 22:02:38 or write a voting proposal to make a cahnge to the statutes :) Jan 21 22:02:39 bluelightning: great, got involved in linux kernel hacking these past months to help maintain the ben nanonote bsp in OE, so would really love to apply as a member Jan 21 22:02:40 soon 10 years in project Jan 21 22:02:44 I joined at one point, but never once attended a ga or appointed a proxy, should re-join at some point Jan 21 22:02:51 kergoth: ;)) Jan 21 22:03:38 kergoth: there should be status position for Project Founders Jan 21 22:06:18 Crofton|work: sure, if that means attending the online meetings and voting when asked to (beside code contributions), it seems a fair consequence of being part of a community to me Jan 21 22:06:43 basically, you get to vote, if we have something theat needs voting on Jan 21 22:06:50 which isn't very often Jan 21 22:07:02 It makes you part of the official face of the project Jan 21 22:07:21 I see Jan 21 22:20:41 is it important to add defconfig to my kernel bbappend recipe? It's already in the list and by prepending my files path, mine gets used instead. I just want to make sure there isn't some other reason why it's necessary. Jan 21 22:23:18 sr105: adding it to SRC_URI will just end up duplicating it pointlessly. its the FILESEXTRAPATHS that tells it to use yours, not SRC_URI. it doesn't know "where" a given SRC_URI entry came from, its just a list of urls Jan 21 22:23:45 so short answer, no :) Jan 21 22:25:44 Thanks. I guess I was confused by linux-yocto-custom.bb which says to include it in SRC_URI, but I guess it's only important if the recipe you're appending doesn't already have it. Also, I noticed that a lot of bbappend kernel recipes did it. Jan 21 22:26:26 I think bitbake syntax can be confusing enough without adding unnecessary lines. :) Jan 21 22:27:01 indeed Jan 21 23:37:42 hmm time to break binary feeds L/ Jan 21 23:37:44 :/ Jan 21 23:38:17 you should do that now, while koen sleeps ;-) Jan 21 23:40:45 I'll send 2 patches, one fixing something for binary feeds and the other breaking something in order for bigger fix :) Jan 21 23:41:07 so I guess koen will understand :) Jan 21 23:41:30 but my users wont be so happy about it, because they don't care about "greater good" :) Jan 22 02:09:26 evening all Jan 22 02:12:22 hi pb_ Jan 22 02:13:12 are in PST timezone ? Jan 22 02:13:15 now Jan 22 02:52:34 for me, always... Jan 22 02:52:58 and good evening Jan 22 02:59:56 http://www.total-knowledge.com/~ilya/mips/ugt.html **** ENDING LOGGING AT Wed Jan 22 02:59:59 2014