**** BEGIN LOGGING AT Wed Jul 26 03:00:03 2017 Jul 26 06:49:28 hello guys Jul 26 06:50:15 does anibody know how to get the [FAILED] process details that comes out at boot once logged in ? Jul 26 06:50:41 I've tried both syslogd and dmesg but still can't find them Jul 26 07:02:23 hello Jul 26 07:04:03 i am using bitbake to build some code... when i build the first time, everything seems fine. if i break my code on purpose, it will try to compile and fail, saying that do_compile failed. i want to ONLY compile to see if my code works. i tried to bitbake -c compile, but that will always succeed, so apparently that does something other than the compilation that bitbake does Jul 26 07:04:36 unfortunately building the whole thing (without -c compile) takes 1h, so i want to only try to compile Jul 26 07:09:27 i also tried to -c cleansstate and then -c compile Jul 26 07:44:46 bitbake works if i rm build/tmp between each build, but then i have to build _everything_, which takes 1 hour Jul 26 08:19:10 hi. Yesterday I (rmmr) posted a query on a build issue on poky krogoth for renesas rcar m3. Just in case it is useful to someone else, he issue was caused by git color configuration. Jul 26 08:20:09 rmr: hmm, what specifically had you changed? Jul 26 08:22:30 bluelightning: I removed the [color] configuration from my .gitconfig. Jul 26 08:23:01 rmr: ok... I'm just wondering what I'd need to do to reproduce it as I have colours enabled here and haven't observed any negative effects Jul 26 08:23:42 blueligtning: the issue only affected building with meta-renesas, not core-image-minimal, but I didn't dive further to find out why. I can move on now with my build. Jul 26 08:26:07 hmm ok Jul 26 09:23:49 hello guys ! Jul 26 09:24:13 anybody knows how to add a perl module to a yocto image ? Jul 26 09:24:22 I0m struggling with this one: Jul 26 09:24:34 https://github.com/makamaka/JSON/tree/2.94 Jul 26 09:25:03 I've created the recipe but the makefile generated with Jul 26 09:25:22 do_compile () { Jul 26 09:25:22 perl Makefile.PL Jul 26 09:25:47 set the host compiler instead of the target Jul 26 10:02:06 The recipe x-fpga is trying to install files into a shared area when those files already exist. Those files and their manifest location are: ... i get this every time i try to devtool build Jul 26 10:02:11 any idea if this can be fixed somehow? Jul 26 10:05:10 i can delete my build/tmp, but then i have to build everything each time Jul 26 10:05:19 which takes nearly 2h Jul 26 10:21:54 talin; have you tried using EXTERNALSRC develop on specifc package Jul 26 10:22:08 catch22_: no, i haven't heard about that before Jul 26 10:23:16 talin: I find it easier than devtool, you can point the package source to 'in-work' folder outside of yocto Jul 26 10:23:54 catch22_: oh. so you specify a repo you want to build and then you use bitbake to build it ? Jul 26 10:25:22 talin: not really, you setup the source folder for a package to somewhere on your system. Then edit that source, and then use bitbakc to build the package Jul 26 10:26:13 catch22_ : you can then also build the '-native' variant Jul 26 10:26:32 http://www.yoctoproject.org/docs/2.0/dev-manual/dev-manual.html#building-software-from-an-external-source Jul 26 10:27:33 we use it for normal software development and don't bother creating and sdk. Jul 26 10:28:28 thank you. i will give this a try. i have tried everything else so far Jul 26 10:28:53 Unlike 'normal' package which are at fixed revisions, the external source packages rebuild when you type "bitbake " Jul 26 10:29:31 I'm not sure why you blowing away your entire build folder to re-build on package Jul 26 10:29:52 have your tried "bitback -c cleanall " Jul 26 10:37:42 catch22_: yes, i did try that Jul 26 10:37:49 and bitbake -c cleansstate Jul 26 11:10:53 ed2: I see you pointed me at a wic example, anything else I should read up on for adding stuff to oe-selftest? Thanks! Jul 26 11:12:13 Tartarus: you can read this wiki page: https://wiki.yoctoproject.org/wiki/Oe-selftest Jul 26 11:12:27 Tartarus: and ask questions here too Jul 26 11:14:43 Tartarus: oe-selftest is based on Python unittest framework. It's pretty easy to understand from existing test cases in the same directory as wic test case. Jul 26 11:17:56 ok, thanks Jul 26 11:22:33 catch22_: you can use devtool to point to an existing external source tree, it doesn't have to be where it puts it by default Jul 26 11:23:54 talin: which directory are the files mentioned in the error in? Jul 26 11:30:59 bluelightning: they are in various subdirs of build/tmp/sysroots/qemux86-64/ Jul 26 11:31:31 talin: are you copying anything into those directories in your recipe directly? Jul 26 11:32:48 bluelightning: doesn't seem like it, no. i am trying to use this externalsrc stuff now Jul 26 11:33:05 talin: externalsrc won't make any difference to this Jul 26 11:33:19 in any event, devtool modify uses externalsrc, FWIW Jul 26 11:35:37 oh, okay Jul 26 11:36:01 hmm, i just found some other task i can work with, so i'm thinking about abandoning this until people come back from vacation Jul 26 11:36:16 Hi, I am new to yocto, and am wondering if anyone can help me with finding yocto recipes to build a shared libraries. Jul 26 11:36:20 some others in my team just gave up on it also. maybe the person who made the recipes did something weird Jul 26 11:37:07 I am trying to change the lua 5.3.4 recipe so it can produce a .so file Jul 26 11:37:32 bluelightning: thanks a lot for all the advice :) Jul 26 11:38:05 talin: there are a few circumstances under which you can get that error - (1) two recipes are genuinely trying to install the same file into the sysroot, which is not permitted; (2) a recipe has been renamed or removed from the system without cleaning up its files (with previous versions only - this is no longer an issue); (3) a recipe is writing to those files in the sysroot directly which is a very bad idea Jul 26 11:39:44 lucas_: I would assume you need to modify the recipe so that it passes the appropriate options at configure time (or sets the appropriate CFLAGS) - this is determined by lua itself, so I would recommend checking its documentation Jul 26 11:40:19 yeah, looking at http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/lua/lua_5.3.4.bb?h=master suggests that the lua recipe just uses its own make install stage Jul 26 11:40:47 so probably it should be something along the lines of --enable-shared being passed to ./configure Jul 26 11:41:16 bluelightning: hmm, i see. Jul 26 11:41:21 Tartarus: the good thing about oe-selftest is that it's one of the acceptance criterias for changes. It's run on AB and if something fells tests the guilty change is not merged into master. Jul 26 11:41:36 EXTRA_OEMAKE = "'CC=${CC} -fPIC' 'MYCFLAGS=${CFLAGS} -DLUA_USE_LINUX -fPIC' -shared' MYLDFLAGS='${LDFLAGS}'" Jul 26 11:42:05 this is what I have added into the bbappend file Jul 26 11:42:20 Tartarus: another good thing is that it's easy to run locally to ensure your code doesn't break anything. Full run takes a lot of time thought. However, -r allows to run only subset of it. Jul 26 11:47:59 any suggestions? Jul 26 11:48:28 ed2: Blah, I can't run the qemu tests on my usual build box Jul 26 11:49:16 I can run in my local just fine, and produce a .so locally but not in bitbake Jul 26 11:50:02 lucas_: well then check if the append gets correctly applied. bitbake -e is your firent Jul 26 11:50:07 friend, even Jul 26 11:50:14 Tartarus: why? Jul 26 11:50:20 I am using mutilib to build only 32 bit packages applications. i have chaned the packagegroup recipe which contains the packages as lib32-packagegroup in image recipe. Still image is trying to build 64 bit. Jul 26 11:50:32 ed2: It's a funky and semi locked down box Jul 26 11:51:18 Tartarus: qemu is used in small amount of test cases. Jul 26 11:51:32 https://www.irccloud.com/pastebin/qniwMP62/ Jul 26 11:51:39 Tartarus: want me to come over with my universal *key*? :-) Jul 26 11:51:43 ed2: Yeah, and the qemu ones didn't go Jul 26 11:52:43 Tartarus: if you implement test case that checks building of vmdk images it would be much better than what we have now. Jul 26 11:53:11 ed2: Yeah, one thing at a time tho :) So, oe-selftest -r wic Jul 26 11:53:20 I get 3 errors, around the qemu ones that can't run on this box Jul 26 11:53:21 and Jul 26 11:53:28 Tartarus: you can run just one test case, btw. oe-selftest -r wic.Wic. Jul 26 11:53:52 2017-07-26 07:28:14,937 - oe-selftest - INFO - RESULTS - wic.Wic.test_exclude_path - Testcase 1661: FAILED Jul 26 11:57:52 ed2: So, newbie question time :) Would 'wic create ... --compress-with=vmdk pass things back to OE and make use of CONVERSION_CMD or no, wic has its own logic and thus it would fail? Jul 26 11:58:02 and pretend I put an end-' in an appropriate place :) Jul 26 11:58:34 Tartarus: no it would not. you should run bitbake for that. Jul 26 12:00:06 Tartarus: you can look at test_wic_image_type test case. it does something similar. Jul 26 12:02:49 Tartarus: you can also look at ../meta/lib/oeqa/selftest/cases/imagefeatures.py Jul 26 12:03:07 Tartarus: probably it's more appropriate place for your test case. Jul 26 12:04:41 Tartarus: ideally it can test all conversion commands similarly to what test_image_fstypes does for image types. Jul 26 12:07:14 ok, thanks Jul 26 12:07:19 more questions soon :) Jul 26 12:09:48 hi all, I'm in the process of upgrading from Morty to Pyro, and one of my recipes fails due to a "command not found" error Jul 26 12:09:53 in the release notes for Pyro I see the following change: "PATH is now filtered within build tasks, using symlinks to only allow calling whitelisted tools from the build host in order to reduce the possibility of host contamination" Jul 26 12:10:00 how would I go about changing the recipe to whitelist certain commands/symlink commands on the host machine to be run during bitbake? Jul 26 12:12:05 ed2: Can I hijack the bmap test to confirm that ext4.bmap.gz is created and a valid gzip archive? Jul 26 12:13:45 Hi, I want to make a recipe that executes an existing recipe but first applies some patches to the recipes called from my existing recipe, how can I do this? Jul 26 12:14:25 Tartarus: yes, you can, but it would be non-ideal solution :) Jul 26 12:14:41 ed2: Well, I need to add a test for 2+ conversions Jul 26 12:14:54 Since that's one of the things that got broken Jul 26 12:15:54 Tartarus: true. What about to test more combinations of conversions? Jul 26 12:16:50 ed2: Well, that's more complex and I'm not sure how to go about that cleanly either Jul 26 12:17:12 Tartarus: you can just add all/subset of possible combinations to IMAGE_FSTYPES, run bitbake and test if those are generated. Jul 26 12:17:14 As is, testing gzip or bz2 seems OK as python has support for those formats by default so I can just confirm that a decompress works Jul 26 12:17:28 ed2: Ah, hm Jul 26 12:19:21 Tartarus: trying to decompress is a good idea too, btw. Jul 26 12:19:49 Tartarus: you can do that in separate test case Jul 26 12:19:51 ed2: So how about 2 tests? One test confirms that ext4.bmap.gz is a valid object, on the bmap test Jul 26 12:20:10 Tartarus: yep, that would be great Jul 26 12:20:21 Other test is that .ext4..u-boot.sha256sum comes out Jul 26 12:30:54 what does bitbake -e do? Jul 26 12:31:36 lucas_: shows you the complete environment that a build process sees. preferably to be piped through some pages, e.g. bitbake -e $YOURINTERESTINGRECIPE | less Jul 26 12:33:05 LetoThe2nd: Thank you :) Jul 26 12:40:34 ed2: OK, testing ext4.bmap.gz test now Jul 26 12:55:31 ed2: OK, ext4.bmap.gz test added, and confirms that we have a valid gzip Jul 26 12:55:41 Now to add a bunch of compression and sha256sum Jul 26 12:56:24 what does this mean: ERROR: Only one copy of bitbake should be run against a build directory Jul 26 12:57:52 lucas_: exactly what it says. do not run more than one instance of bitbake against a specific build directory at any given time. Jul 26 12:58:39 lucas_: check how many running instances with ps aux | grep bitbake Jul 26 13:07:11 Tartarus: just wondering how bitbake would perform with all possible permutations of conversion commands :) Jul 26 13:07:37 ed2: Yeah, no :) Jul 26 13:07:46 I'm adding a separate test to chain together a ton of things Jul 26 13:08:03 And then I'm going to look at json and python Jul 26 13:08:10 since qemu-img info can, I beleive, spit out json info Jul 26 13:08:26 Tartarus: sounds great Jul 26 13:27:37 OK, I think I've got a reasonable long conversion test Jul 26 13:27:44 running all of the image tests now Jul 26 13:27:56 Then to do the harder one of adding wic.vmdk and parsing it Jul 26 13:28:17 Should I do all 3 of them, or just vmdk and assume that means qemu-img is also sane, and that's enough? Jul 26 13:28:50 Tartarus: up to you. I'd say one is enough if adding more will add a lot of code to the test case. Jul 26 13:29:18 s/is enough/it is enough/ Jul 26 13:31:17 ed2: OK, I'll keep it in mind then Jul 26 13:32:01 ed2: Oh, so, the WIC failure I mentioned? Jul 26 13:32:28 You think that's due to my changes? Or can you grab my patches and give them a quick oe-selftest? Jul 26 13:33:40 Tartarus: which failure? I missed it I think. Jul 26 13:34:35 2017-07-26 07:28:14,937 - oe-selftest - INFO - RESULTS - wic.Wic.test_exclude_path - Testcase 1661: FAILED Jul 26 13:35:03 Otherwise it's 3 qemu issues, since I can't run qemu here (but it should well work, I booted the resulting images on virtualbox, so the embedded contents are sane) Jul 26 13:35:39 Tartarus: can you show the failure? oe-selftest reports it before the summary report. Jul 26 13:36:16 Tartarus: it should be some traceback or similar. Jul 26 13:36:29 ed2: Yeah, it's just lost to scrollback Jul 26 13:36:36 moment, sorry Jul 26 13:39:10 ed2: Here's the log https://www.irccloud.com/pastebin/b2zGaxwi/ Jul 26 13:46:46 Tartarus: i don't think it's caused by your test cases. Jul 26 13:47:04 ed2: That's what I was hoping for Jul 26 13:47:07 Tartarus: which MACHINE do you use? Which distro? Jul 26 13:47:21 Can you please run oe-selftest -r wic on your setup with my patches? Jul 26 13:47:35 ed2: qemux86-64, and this is a debain8 chroot on an oddly locked down box Jul 26 13:47:54 Tartarus: I didn't see it before and ab didn't complain about it. Jul 26 13:48:05 ed2: ok Jul 26 13:48:14 Tartarus: do you have your changes in some branch I can pull? Jul 26 13:48:23 ed2: Do not, sorry Jul 26 13:48:38 lets see Jul 26 13:48:49 moment Jul 26 13:51:33 ed2: OK, https://github.com/trini/openembedded-core.git extend-wic-for-vmdk-v1 Jul 26 13:52:04 Has what I posted + my 2 new tests too Jul 26 13:54:00 and, I see I need to fix author in my new test, heh, oops Jul 26 13:54:03 ignore that ;) Jul 26 15:02:32 Hi! I'm trying to add Qt Creator to the SDK by adding "TOOLCHAIN_HOST_TASK += "qt5-creator"" to my local.conf, but getting the following error: Jul 26 15:02:34 do_populate_sdk: qt5-creator not found in the feeds (x86_64-nativesdk noarch any all) in... Jul 26 15:05:50 Tartarus: running oe-selftest on poky master + your patches. So far so good. I have to run now. will let you know about results later today or tomorrow. Jul 26 15:06:37 ed2: ok, thanks! Jul 26 15:53:37 Tartarus: test_mkfs_extraopts fails in my setup, but that doesn't seem to be caused by your changes. the rests of tests are passed. Jul 26 15:54:05 ed2: OK, thanks! Can you follow up to yourself then please and note they're passing? thanks! :) Jul 26 15:54:27 And my vmdk test wasy easy enough to convert to cover all 3 tests Jul 26 15:54:36 We'll see if anyone screams at my probably poor python soon Jul 26 15:54:42 cool Jul 26 15:55:25 I can scream at your python if you show your changes. If I don't scream nobody else would probably do :) Jul 26 15:56:46 extend-wic-for-vmdk-v1-a has 'em all now Jul 26 16:10:23 otavio: Morning Jul 26 16:11:17 otavio: I understand you started looking at the tmux process exit issue also, did you pull a patch together already based on the gnome phonehome script? Jul 26 16:13:41 Tartarus: your patches look good to me. Thank you for developing tests. Now this functionality is more safe. Jul 26 16:13:56 ed2: thanks for the reviews Jul 26 16:52:37 sgw_: i did Jul 26 16:54:08 otavio: will you be send that patch? We have an open Yocto Bug #11146 Jul 26 16:54:09 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=11146 normal, Medium, 2.4 M3, leonardo.sandoval.gonzalez, ACCEPTED , menuconfig changes do not result in kernel or image rebuilds Jul 26 17:01:20 sgw_: yes; I can make it. In fact I was doing it in another use-case but same solution should work for it ... Jul 26 17:01:41 otavio: great thanks, one less think on my list ;-) Jul 26 17:04:45 sgw_: Leo seems to be looking at it and in he did point me the patch so I am afraid I may be stepping in his toes here Jul 26 17:05:14 If you have something already it should be fine, he is out today and tomorrow Jul 26 17:10:02 sgw_: I did https://github.com/UpdateHub/meta-updatehub/commit/6f1f265691ea847e1e03748196e0c5428f093a33 Jul 26 17:10:35 sgw_: but as I mentioned on the bug, it seems it should be a more generic thing as gnome-terminal and tmux will share same code Jul 26 17:11:30 sgw_: so if I pick the bug, I'd first rework the gnome-terminal solution to be generic and then enable it for tmux Jul 26 17:12:28 otavio: yes, I think that;s the right approach since its needed for more than just gnome Jul 26 17:13:25 sgw_: I asked for Leonardo's feedback in the bug and added myself on cc so you can consider it being handled by one of us Jul 26 18:38:51 is anyone else having troubvle accessing git.yp web interface? Jul 26 18:46:37 aehs29: works for me Jul 26 19:28:40 Is there a way to make BBLAYERS use the paths of the current machine? Right now the layers have hard-coded paths which break whenever a developer clones the repository on their their own machine Jul 26 19:28:58 I tried something like `BASE = "${@os.path.realpath('../..')}"` Jul 26 19:29:22 And then `BBLAYERS += "${BASE}/sources/meta-ossystems-base"` Jul 26 19:29:29 But setup-environment doesn't like it Jul 26 20:31:32 ythl: what are you using? Jul 26 20:33:15 ythl: the conf is usually intended to be kept as local configuration so usually I just regenerate it when moving from one machine to another Jul 26 20:33:56 If I regenerate it, won't I have to paste in all the custom layers Jul 26 20:34:01 ythl: however I try to minimize the amount of things done in local.conf and such it is cheap to regenerate them as we use customer-specific layers Jul 26 20:34:15 (into bblayers) Jul 26 20:34:31 ythl: if you are using O.S. Systems tools you can use the setup-environment.d scripts to do it for you Jul 26 20:35:00 ythl: http://doc.ossystems.com.br/managing-platforms.html Jul 26 20:36:12 Ah, so I could write a custom setup-environment hook that adds in the layers Jul 26 20:36:36 ythl: as an example, https://github.com/UpdateHub/meta-updatehub/blob/master/conf/setup-environment.d/updatehub.py Jul 26 20:36:47 ythl: yes Jul 26 20:36:54 I think this is just what I'm looking for Jul 26 20:36:56 ythl: that's why our tools are so nice Jul 26 20:36:56 thanks, otavio Jul 26 20:37:19 ythl: but make sure you are using our setup-environments scripts Jul 26 20:37:23 ythl: or it won't work Jul 26 20:37:48 I'll try it out Jul 26 20:37:49 ythl: yw Jul 26 21:51:50 hmm, wic doesn't remove an existing fstab entry for a particular mount. should probably fix that Jul 26 21:51:57 or at the least error out **** ENDING LOGGING AT Thu Jul 27 03:00:01 2017