**** BEGIN LOGGING AT Wed Feb 01 03:00:02 2017 Feb 01 09:48:58 I just built libav package and copied the *.so related to target but gst-inspect-1.0 | grep libav give me nothing Feb 01 09:49:32 is there any way to include libav packages to gst-inspect-1.0 ? Feb 01 09:51:24 Ramose_: gstreamer-libav1.0 is the recipe you probably want Feb 01 09:51:51 sorry, gstreamer1.0-libav Feb 01 09:52:39 it doesn't use system libav by default so libav itself is not needed Feb 01 10:16:19 jku_: Thanks, it worked :) Feb 01 11:36:36 marquiz: I've merged -next into master, thanks for the numbers! Feb 01 11:50:28 rburton: did you already have a look at (all) oe-core failures in martins report from yesterday or should I? Feb 01 11:51:36 i thought i replied last night Feb 01 11:51:39 did i fail to hit send? Feb 01 11:51:44 wouldn't be surprised Feb 01 11:51:48 rburton: oh you did Feb 01 11:52:03 some were already fixed, some were trivial and i just need to write nice commits, two were the staging code exploding. Feb 01 11:52:24 yeah three weird ones left plus cryptodev-module you didn't mention Feb 01 11:53:39 rburton: I have no idea on the exploding code btw :/ Feb 01 11:54:54 i still feel like death warmed up Feb 01 11:55:03 i'll get those patches out now and then crash again Feb 01 11:57:41 * FILELIST: added "/usr/share/locale/uk/LC_MESSAGES/libc.mo" Feb 01 11:57:41 packages/corei7-64-poky-linux/glibc-locale/glibc-locale-vi: FILELIST: added "/usr/share/locale/vi/LC_MESSAGES/libc.mo" Feb 01 11:57:41 packages/corei7-64-poky-linux/glibc-locale/glibc-locale-vi: PKGSIZE changed from 0 to 165597 (+100%) Feb 01 11:57:45 that happens when i rebuild stuff Feb 01 11:57:52 slightly worrying Feb 01 12:01:52 rburton: yes. Sorry to hear you're still not any better :( Feb 01 12:04:44 RP: did anyone else see master-next exploding in sstate fixup? Feb 01 12:05:32 rburton: no reports Feb 01 12:06:05 ok, will rebuild with current next and see what happens Feb 01 12:06:13 i had to revert the pkgconfig change to make it work Feb 01 12:06:35 rburton: which pkgconfig change? Feb 01 12:06:44 Revert "relocatable: Make native .pc files relocatable" Feb 01 12:06:52 rburton: hmm :( Feb 01 12:07:43 * RP fires the new AB at -next to test that and the other patches queued there for rss performance Feb 01 12:22:23 RP: ok, np Feb 01 12:22:38 i'll configure the machines back to normal cycle Feb 01 12:40:24 marquiz: it was helpful to validate those patches. I guess I do have more in -next which should help performance but I might fast track those into master assuming my test builds are ok Feb 01 12:44:15 ok, just let me know, it is very easy to make the switch Feb 01 12:51:45 hello everybody. I have here a local.conf buildconf which I want to edit: http://git.toradex.com/cgit/meta-toradex-demos.git/tree/buildconf/local.conf#n41 Feb 01 12:51:49 SERIAL_CONSOLES_colibri-vf = "115200;ttyLP0 115200;ttyGS0" Feb 01 12:52:08 So I created in my own meta layer too an folder buildconf and a local.conf with this line. Feb 01 12:52:13 But it doesn't work Feb 01 12:54:46 HyP3r: only one copy of local.conf will be used, usually the one you copy into your build directory and edit Feb 01 12:55:56 But if I do an bitbake -c cleanall systemd-serialgetty and bitbake -c install systemd-serialgetty. The configuration is still wrong Feb 01 12:56:11 But ok Feb 01 12:56:45 I guess its the configuration inside the build/conf/local.conf directory. Feb 01 12:57:58 RP: what of those many local.conf of the different layers and configratuion directorys is used? Feb 01 13:14:31 HyP3r: do you mean local.conf or layer.conf? Each layer has a layer.conf but there is only one local.conf which is used Feb 01 13:30:19 Ran 238 tests in 12741.726s Feb 01 13:30:19 FAILED (failures=116, errors=4) Feb 01 13:30:25 still, it's a start, eh? Feb 01 13:30:40 * kanavin has run oe-selftest with dnf ^^^ Feb 01 13:37:07 alimon: what are the test case numbers for? let's say I want to add a new testcase, how do I give it a number? Feb 01 13:48:42 Hi guys! Feb 01 13:50:05 Could you help me with changing of gcc version to more new. I use https://github.com/meta-debian/meta-debian. There is gcc 4.9. I have to use as minimum 5.0 . What is the simplest way for replacing gcc from this repo to 5.4 ? Feb 01 13:54:42 Guest3927: you can always try to backport (e.g. copy) newer gcc recipes from more recent oe revisions. Feb 01 14:00:44 Guest3927: meta-debian has a jethro branch. oe-core (jethro) has gcc-5.2 Feb 01 14:01:34 or is meta-debian really just debian, not oe-core at all ? Feb 01 14:03:57 jku, meta-debian is an interesting thing Feb 01 14:04:15 It tries to build debian with openmbedded Feb 01 14:04:24 this is likely a gross over simplification Feb 01 14:23:04 RP: I mean the local conf which one is used? Feb 01 15:55:18 HyP3r: the first one found in BBPATH Feb 01 15:56:34 HyP3r: I don't know how you have your build setup but bitbake looks through each entry in BBPATH and looks for conf/local.conf. bitbake -e | grep BBPATH= might help Feb 01 15:56:52 kanavin: the numbers of test cases are assigned by QA team in Testopia Feb 01 15:56:57 kanavin: the numbers correspond with entries in testpopia (part of bugzilla) Feb 01 15:57:31 kanavin: you can search for a free id in certain test plan Feb 01 15:57:44 yeah, but what if I'm writing new test cases? Feb 01 15:58:39 why not just automaticall deduce the the id from the name of the testcase? Feb 01 15:59:33 kanavin: yes we can, but we need to standardize the test case names and create a function to generate unique id's Feb 01 15:59:59 JosePerez1: ^ Feb 01 16:01:30 alimon: sha256 ? :) Feb 01 16:01:42 kanavin: it's too long... Feb 01 16:01:51 alimon: sha265[:10] :) Feb 01 16:01:54 i prefer a small int Feb 01 16:02:18 kanavin: the issue here is difficult to remember a hash instead of numeric value Feb 01 16:02:41 kanavin: but your idea is good to have auto generated ids Feb 01 16:02:44 alimon: but why use numbers at all - just refer to test cases by name Feb 01 16:03:18 kanavin: to be able to reference in Testopia, i suppose Feb 01 16:03:34 alimon: fix testopia to not require numbers Feb 01 16:05:07 recipetool and devtool were introduced in fido correct? Feb 01 16:05:39 kanavin alimon The IDs should be the same from Testopia Feb 01 16:06:22 JosePerez1: how does one add new test cases? Feb 01 16:06:40 JosePerez1: I'm adding test cases for rpm, what am I supposed to do with those ids? Feb 01 16:07:27 kanavin those are part of testimage right ? Feb 01 16:08:50 kanavin you need to add them to test plan 18 https://bugzilla.yoctoproject.org/tr_show_plan.cgi?plan_id=18 Feb 01 16:09:31 JosePerez1: you're missing my point, this shouldn't be necessary Feb 01 16:10:23 I just want to write some test cases, and test that they pass locally Feb 01 16:11:06 kanavin ok so they wont be part of the testimage suite ? Feb 01 16:11:23 JosePerez1: no they will, I will submit a patch Feb 01 16:11:49 JosePerez1: I'm porting smart test cases to dnf, removing some and adding some others Feb 01 16:12:47 JosePerez1: I have no interest in fixing test ids though, those should be maintained somewhere separate, or generated automatically Feb 01 16:13:07 kanavin ok then you need a Testopia ID for them, we use a templates defined for every QA cycle an the IDs of the test cases should be the same an I should also to update the template Feb 01 16:13:44 JosePerez1: you still miss what I am trying to say :) Feb 01 16:14:26 kanavin: you can send your test cases and then JosePerez1 can handle the task to put ids into Testopia, i think Feb 01 16:14:40 alimon: can I submit the patch without test ids? Feb 01 16:14:48 dreyna: http://lists.openembedded.org/mailman/listinfo/bitbake-devel Feb 01 16:14:58 kanavin for the modified test cases the ID can be the same.. for the new ones please send me a list of the name off the test case added and can create the testopia entrance and give back number to you. Feb 01 16:15:06 alimon: it would really be better if the ids were not written in the same file as test cases Feb 01 16:16:27 JosePerez1: you need to fix this process, far too much manual work Feb 01 16:16:29 kanavin: yes i understand the issue we need a manner to don't handle manually the ids Feb 01 16:16:34 kanavin: no, it really wouldn't. Just submit the new tests without IDs, its simple Feb 01 16:17:09 RP: and what would guarantee that the new tests wouldn't be ignored? Feb 01 16:17:20 kanavin send the patch and copy me .. I can create the testopia entries and send other path to add the IDs once are merged Feb 01 16:17:50 kanavin: the IDs are only used for results reporting back into testopia, they will get run the ABs Feb 01 16:18:49 okay, alright Feb 01 17:28:40 <3 the meta-intel change so we can use runqemu without changing to a qemu machine. so handy Feb 01 17:33:52 RP: test_continue (oeqa.selftest.bbtests.BitbakeTests) is SO SLOW :) Feb 01 17:34:12 I understand why you had to make it so, but wonder if it could be somehow optimized Feb 01 17:35:02 like, the thing it's testing is whether bitbake -k is able to continue after a failure Feb 01 17:36:06 the recipe that is subjected to failure is man Feb 01 17:36:22 which means everything that man needs has to be fetched and built, from total scratch Feb 01 17:36:48 couldn't we trigger a failure somewhere much earlier in the build chain? Feb 01 17:42:41 kanavin: probably, I've been saying that various tests need to be improved for a while... Feb 01 17:42:49 actually, no, man is failing before it's fetched, it's xcursor-transparent-theme that is taken to complete build Feb 01 17:42:51 kanavin: its assumed your sstate is hot I guess Feb 01 17:43:09 RP: this particular testcase has its own sstate Feb 01 17:43:23 kanavin: ouch :( Feb 01 17:43:48 RP: I might bundle a bonus fix into my dnf patchset or something :) Feb 01 17:44:13 kanavin: or just send it separately? please ;-) Feb 01 17:44:51 * RP is pondering whether absolute links are ever really a good idea or if we should just remove them all (hence making sstate easier) Feb 01 17:45:19 RP: sure, yes Feb 01 17:53:38 RP: Feb 01 17:53:38 2017-02-01 19:52:53 - test_checkuri (oeqa.selftest.bbtests.BitbakeTests) ... ok Feb 01 17:53:38 2017-02-01 19:53:02 - test_continue (oeqa.selftest.bbtests.BitbakeTests) ... ok Feb 01 17:53:56 previously it was 20 to 50 minutes depending on time of days Feb 01 17:54:50 (because binutils and friends were downloaded etc.) Feb 01 17:55:13 absolute links are nice on target, easier to follow, but anywhere else don't make much sense Feb 01 17:55:14 * kergoth yawns Feb 01 17:59:42 kanavin: sounds like a good improvement :) Feb 01 17:59:47 kergoth: morning! Feb 01 18:00:18 kergoth: I'm torn on fixing these everywhere or just for populate_sysroot use :/ Feb 01 18:00:38 kergoth: not found too many cases so far thankfully (bzip2, openssl, fontconfig) Feb 01 18:01:07 kergoth: I could complicate the sstate code more to handle it but I'm not really seeing the pressing need Feb 01 18:05:02 jku: FWIW you're right about these absolute symlinks, they're a pain Feb 01 18:05:20 jku: I'm very tempted to just mandate removal of them earlier in the process... Feb 01 18:06:24 jku: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=0ec97f58e60b6127f71e47d31ef7a13538601336 is my wip testing (with a typo so the sstate code fails) Feb 01 18:07:35 er, http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=fb8a78b8f279f62de3ab9701288b3c56b420945c has the missing file Feb 01 18:07:54 * RP -> food Feb 01 18:22:07 RP thanks, I'll have a look tomorrow Feb 01 18:24:33 RP: I'm checking the tests that uses cleansstate and if removed from sstatetests that would defeat tests' purposes Feb 01 18:26:28 So we can a separate sstate cache dir and use sstate mirrors here Feb 01 18:40:45 oh, so, i keep getting reminders about that xattrs bug Feb 01 18:40:49 so I fixed it in upstream Feb 01 18:41:03 I don't have time to do a proper submission/review/etc., but the code's at least somewhat tested. Feb 01 18:41:24 trivia point: my comment on the likely fix was exactly right, except that my SQL syntax was completely wrong. Feb 01 18:41:43 As I learned when I used that completely wrong syntax, nothing worked, and it took a while for me to have the thought of checking pseudo.log to find the diagnostics. Feb 01 20:46:48 hmm, there are a decent chunk of changes in pseudo master that it would be good to have in oe-core/yp Feb 01 21:11:52 joshuagl, seebs: yes, would probably be good to upgrade... Feb 01 21:12:15 justanotherboy: which tests are those out of interest? Feb 01 21:12:21 RP: right, I was just looking at that. Probably need to backport all of the patches for the non-git recipe? :-/ Feb 01 21:13:07 I could tag a release. Feb 01 21:13:12 joshuagl: no, we make a release! : Feb 01 21:13:13 :) Feb 01 21:13:18 seebs: snap! Feb 01 21:13:20 RP: All contained in sstatetests module Feb 01 21:13:31 RP: seebs: oh good, let's do that Feb 01 21:14:30 justanotherboy: note how it uses temp_sstate_location already? Feb 01 21:15:01 RP: It does, but it would be better if we actually use the mirror option Feb 01 21:15:11 justanotherboy: why? Feb 01 21:15:50 RP: To avoid rebuilds of already built recipes Feb 01 21:16:10 justanotherboy: it looks like those tests should all be safe to me just to work with an existing sstate mirror? Feb 01 21:17:04 RP: Yeah, I'll do some tests using a mirror Feb 01 21:17:15 Okay, tagged it as 1.8.2. It should be safe to just run "make tarball" anywhere after checking it out and running configure. Feb 01 21:17:33 justanotherboy: You mean testing the code as is, right? Feb 01 21:17:44 RP: right Feb 01 21:17:49 justanotherboy: ok Feb 01 21:18:25 seebs: one or both of us can even publish release tarballs right? Feb 01 21:34:10 Sure. I'm not really working-on-Yocto these days, so I don't have a specific place to stash tarballs anyway. Feb 01 21:50:00 seebs: just let me know if you want me to generate/publish anything Feb 01 21:50:28 seebs: I appreciate you finding some time to help with pseudo! Feb 01 22:15:38 'k. I still have plans for some reliability fixes, turns out that FASTOP breaks things for cases where the server crashes, and I didn't spot that because I was busy thinking about the cases where everything runs correctly. Feb 01 22:32:18 RP: while building nativesdk clang, its looking for x86_64-oesdk-linux-gcc Feb 01 22:32:31 which seems to be confusing Feb 01 22:33:15 khem: nativesdk is built by crosssdk gcc so that might not be unreasonable Feb 01 22:34:58 RP: thats right. Feb 01 22:35:35 RP: but I think in this case clang should be built with clang crossdk hmm Feb 01 22:35:56 khem: ah, right Feb 01 22:35:59 btw. your binutils patch looked fine. One thing I wondered if multilib worked Feb 01 22:36:14 and if baremetal worked as well. Feb 01 22:36:17 khem: tests all suggest its fine Feb 01 22:36:50 those paths are usually only used when you used specially options during linking Feb 01 22:36:50 khem: we never use that tools directory given the way we use our sysroots so I think we should be ok. I only patched binutils-cross at this point too Feb 01 22:37:02 yeah I believe so too Feb 01 22:37:38 khem: if you looked at the size/number of linker scripts, then the number of sysroots that were each getting copies, it was huge Feb 01 22:42:10 yeah it is indeed ridiculous Feb 01 22:42:21 it just grew mathematically Feb 01 22:44:41 RP: I have inherited nativesdk in clang_git.bb now I wonder if I have to add dep on crossdk gcc explicity Feb 01 22:45:07 RP: I thought it will coem automatically with nativesdk inheriting Feb 01 22:53:21 khem: lib/oe/classextend has some "gcc" code which may need generalising Feb 01 22:54:08 khem: When I was changing the gcc recipes, I realised there are some simplifying tweaks we could make to the dependencies to ease some of this Feb 01 22:55:15 ok Feb 01 23:13:26 halstead: are we able to run an M2-rc2 build now? Feb 01 23:13:33 (based on master) Feb 01 23:13:58 RP, I added Fedora 25 and started a master build to test. Feb 01 23:14:52 We can cancel that test and try to build the rc2 with or without Fedora25 in the mix. Feb 01 23:15:18 RP, What do you think? Feb 01 23:15:50 halstead: A tough call. I'm tempted to try rc2 with it enabled and if that fails, I'll trigger a new build in the morning with it paused? Feb 01 23:16:17 halstead: sorry, the timing here is conspiring against us :/ Feb 01 23:16:28 RP, Okay. Let me cancel this and change the worker count back. Feb 01 23:16:46 halstead: thanks! Feb 01 23:17:35 halstead: I'm going to leave this with you if that is ok, I need some sleep, totally worn out... Feb 01 23:18:12 RP, Sounds good. Just build master all the way down the list right? Feb 01 23:18:30 halstead: yes, but send to QA as M2 rc2 **** ENDING LOGGING AT Thu Feb 02 03:00:01 2017