**** BEGIN LOGGING AT Wed Oct 04 03:00:02 2017 Oct 04 08:53:50 When I bitbake -c menuconfig virual/kernel , where is my .config saved in the poky directory? Oct 04 08:55:10 learningc: in the unpacked source tree of the kernel, AFAIK. doesn't the kernel-dev manual by the yocto project explicitly state it? Oct 04 08:57:01 hello Oct 04 08:57:26 is there a way to configure bitbake so that it will NOT rename bad checksum files? Oct 04 08:58:59 because: we are several users, and most of us have updated the recipe to the latest version, which contains the right checksum but several have the old broken recipe and everytime they try to build, the file gets renamed Oct 04 08:59:15 so, from time to time, some of us fix the filename again Oct 04 08:59:29 which leads to unpredictable results Oct 04 09:00:00 wsn't bitbake designed with multi-users in mind? Oct 04 09:01:07 cornel: multiple users on a shared sstate, but not multiple users on a single working copy. Oct 04 09:01:39 so the source files must be unique for each user? Oct 04 09:01:51 which source files? Oct 04 09:02:00 these files that get renamed Oct 04 09:02:07 we have some local mirrors Oct 04 09:02:14 cornel: are we talking about the recipes? the application sources?... Oct 04 09:02:21 Hi all, my ##OEROOT## seems not working. From which "branch" of poky does the ##OEROOT## works ? Oct 04 09:02:22 not recipes Oct 04 09:02:32 the recipes take the binaries from a common directory Oct 04 09:02:38 LetoThe2nd, ^ Oct 04 09:02:54 like archives Oct 04 09:03:39 cornel: i admit i don't get what you are sharing, and what not. the point is, multiple users are meant to share a) the download directory b) the sstate-cache. they are *not* meant to share a common build directory. Oct 04 09:04:07 LetoThe2nd, that's fine, it's not about a common build Oct 04 09:04:29 and as a side note, i know is not working for the common download directory Oct 04 09:04:33 at least not always Oct 04 09:04:39 but that's another story Oct 04 09:09:00 anyway, let's go back to the original question: can bitbake be configured to not rename bad checksum files Oct 04 09:09:02 ? Oct 04 09:11:32 no Oct 04 09:11:35 ok Oct 04 09:11:38 :( Oct 04 09:11:42 whats the problem? Oct 04 09:12:04 the problem is that one bad recipe contained a bad checksum Oct 04 09:12:08 and we are many users Oct 04 09:12:17 the recipe was fixed but not all users did this Oct 04 09:12:45 and all those who did not, keep renaming the source files which prevents the build for those that have the right recipe Oct 04 09:13:11 how would changing bitbake configuration help, as you'd have to push that to the users that haven't updated the recipe? :) Oct 04 09:13:14 so we have to keep renaming the file back from time to time Oct 04 09:13:39 if you have a read only source mirror you can stop that sort of thing Oct 04 09:13:42 if the rename does not happen, the problem is only to the users that have not update\ Oct 04 09:13:56 rburton, good point Oct 04 09:14:06 i have to try this :) Oct 04 09:14:19 read only, populated in a cron job Oct 04 09:14:54 the fix is to get the users to update, obviously. no matter what the solution is, you need to get the users to update *something* Oct 04 09:15:23 rburton, thank you, the read-only trick may be good enough Oct 04 09:16:24 rburton, right, but if one is in romania, another in malaysia, another in germanu and another in usa, and there are also some automated builds controled by another team(s), syncing all get a little complicated Oct 04 09:16:53 as said, if the rename is not happening, all users that update are good, and those are not will read the signs :) Oct 04 09:17:43 i wonder if bitbake stops if the bad checksum filename already exists Oct 04 09:17:57 you could touch it, then tell everyone to update if they get the error. Oct 04 09:30:17 I wanted to update my bblayers to the ##OEROOT## version and get problems. "Unable to parse ##OEROOT##/meta/conf/layer.conf": file ##OEROOT##/meta/conf/layer.conf not found in /home/user/Yoctodir/build.... I don't know why he is searching in the build dir. I thought OEROOT is the absolute path to where oe init setup is... Oct 04 09:31:04 to conclude, i'd like to request this enhancement: stope renaming bad checksum files Oct 04 09:31:06 :) Oct 04 09:32:25 or maybe there is a hidden benefit for this that i don't know Oct 04 09:32:39 ChrysD: doesn't ##OEROOT## get transformed if you use it in a bblayers.conf.template, not in bblayers.conf Oct 04 09:33:21 rburton : oh ok, so it's when i charge with TEMPLATECONF that oeroot get transformed, thanks ! Oct 04 09:34:21 rburton : i get the template conf only when i do oe-initsetup... or there is a way which we can do a kind of "bitbake " ? Oct 04 09:34:46 the template is only used when you populate a new build directory, that's right Oct 04 09:38:38 rburton : thanks. Oct 04 09:38:45 rburton : i offer you a coffee. Oct 04 09:43:18 Is their an easy way to clean/invalidate the sstate of a specific recipe from within the recipe itself? To force that the packages is rebuilt from scratch every single time. Oct 04 09:44:12 zerus_: depends on the reason you want for forcing to rebuild Oct 04 09:44:26 zerus_: if its about aplicaiton development, you probably want externalsrc Oct 04 09:45:54 LetoThe2nd: It's a temp solution for picking a application binary built from an external sysroot. That always will be picked from the same location (which of course will fool the sstate). I will lokk into externalsrc Oct 04 09:47:47 zerus_: sounds like it would probably fit Oct 04 09:48:53 zerus_: why not just put the full path in SRC_URI? Oct 04 09:53:51 rburton: hmm yeah, that would probably work. Then the normal mechanism will handle new checksums of the binary pointed out by SRC_URI I guess? I will give it a shoot Oct 04 09:53:57 yes Oct 04 09:54:26 rburton, in our particular setup, even without write and execute rights, if i'm a member of the group, i can still mv file filebad Oct 04 09:54:33 shame Oct 04 09:54:36 maybe it's a problem in our setup Oct 04 09:54:57 you just need access rights on the parent directory Oct 04 09:55:03 so it comes down to how does bitbake do the rename Oct 04 09:55:04 oh Oct 04 09:55:25 mv will do the right thing, but the syscalls bitbake uses may be different Oct 04 09:55:35 i see :( Oct 04 09:56:35 maybe using a git large filesystem would fix this Oct 04 10:09:24 after I bitbake -c compile, where does it put the image? I cannot find it in deploy/images/board Oct 04 10:14:18 learningc: compile does just what it says, it compiles Oct 04 10:15:18 learningc: just bitbake the target recipe without command, so it does the whole process Oct 04 10:15:49 The target recipe or the target kernel? Oct 04 10:16:19 I meant, image recipe or kernel recipe Oct 04 10:16:26 if its the kernel, just do bitbake virtual/kernel Oct 04 10:16:46 Then it will produce the image of the kernel? Oct 04 10:16:52 it should Oct 04 10:27:29 I have removed networking from the kernel, but when I bitbake, I get an error, how can I fix this? Oct 04 10:28:32 learningc: helps if you say what the error is Oct 04 10:29:08 linux-renesas_3.10.bb, do_compile) failed with exit code '1' Oct 04 10:29:35 cannot compile Oct 04 10:29:35 open-nandra how is your upgrade to pyro going? Oct 04 10:29:46 we just managed to build an image :-) Oct 04 10:30:23 it wasn't too painful, a few build time dependencies missing in some of our recipes, remote True from calls to getVar and pretty much that's it Oct 04 10:30:27 arch/arm/mach-shmobile/built-in.o: In function `mmd_write_reg.constprop.1': Oct 04 10:30:28 | :(.text+0x12d4): undefined reference to `mdiobus_write' Oct 04 10:30:35 I get errors like this Oct 04 10:30:37 s/remote/remove Oct 04 10:31:39 arch/arm/mach-shmobile/built-in.o: In function `r8a7790stoutfull_add_standard_devices': Oct 04 10:31:39 | :(.init.text+0x43f8): undefined reference to `phy_register_fixup_for_uid' Oct 04 10:31:48 another error of the like Oct 04 10:34:40 learningc: well thats a problem of your kernel respectively its configuration itself. Oct 04 10:35:12 learningc: in my experience, the best way is to work on the kernel outside of the OE build until it is sufficiently finished, or close enough Oct 04 10:35:38 LetoThe2nd, How can I do that Oct 04 10:35:48 How to do it "outside" ? Oct 04 10:36:05 learningc: 1) get arm toolchain, from linaro for example Oct 04 10:36:14 learningc: 2) get your kernel sources Oct 04 10:36:58 learningc: 3) enter kernel sources, and (basically) do ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make Oct 04 10:37:23 learningc: insert steps for modifying your config and/or sources as needed Oct 04 10:38:07 And that's it? Oct 04 10:38:57 depending on your specific needs and state of kernel source there might be bits and pieces needed here and there. but basically, yes. Oct 04 10:39:23 I see Oct 04 10:41:29 I think bitbake created some object files from previous compile and using them for the new .config file. How can I tell bitbake to rebuild from scratch? Oct 04 10:41:45 learningc: -c clean Oct 04 10:46:50 melonipoika: I plan to do it but in maybe 2 weeks :) Oct 04 10:47:09 meloipoika: great it work for you Oct 04 10:51:11 ok! in two weeks maybe you can jump directly to Rocko :-) Oct 04 10:57:08 I see there is -c cleansstate too, when should I use it? Is it better than -c clean? Oct 04 11:14:06 I did bitbake virtual/kernel -c clean, then bitbake virtual/kernel -c menuconfig, modify then save to .config, then bitbake virtual/kernel. But the images produced does not seem to have the new changes from the .config file. Is there something I am missing? Oct 04 11:14:54 learningc: you should also use savedefconfig task and then update the newly created defconfig in the metadata Oct 04 11:15:17 when the configure task is re-executed your saved changes from menuconfig will be overwritten Oct 04 11:17:01 JaMa, and step by step instruction? savedefconfig task is an option? -c savedefconfig ? Oct 04 11:17:10 and/any Oct 04 12:02:42 sgw: matt did reply; he is testing it. Oct 04 13:08:57 It is possible for a recipe to stage some files to sysroots before do_compile? Oct 04 13:09:07 Is it* Oct 04 13:11:35 why on earth would you want to do that? Oct 04 13:15:25 rburton: hmmm I know that this is not correct. But I am wondering if it was possible Oct 04 13:17:47 rburton: The actual case is that some .so's from a recipe A need some headers files from a recipe B. And recipe B needs the so's from recipe A to be build Oct 04 13:18:03 Tamis: write a separate recipe for those things, and make the one that has do_compile depend on it Oct 04 13:18:57 so B_headers -> A_so -> B_final Oct 04 13:19:08 three recipes Oct 04 13:19:58 That's was also on my mind. I tried not to write 3 recipes and download the repo twice. Oct 04 13:20:10 But I guess I have to do that way Oct 04 13:20:50 yes Oct 04 13:21:23 how can I get access to the source/build dir of a package after it's built? Oct 04 13:21:58 ramcq: what for? Oct 04 13:23:19 rburton: because https://github.com/flatpak/freedesktop-sdk-base/commit/8bf766d71767c7a60d15662feadc7de073785086 suggests https://github.com/flatpak/freedesktop-sdk-base/commit/90c6418f5b489ced814f7941a1adf3c51336b173 didn't do anything Oct 04 13:23:39 rburton: (supported by no change in -dumpspecs output, and nothing particularly inspiring in readelf on the resulting binaries) Oct 04 13:23:54 tmp/work has the build and source trees in Oct 04 13:24:09 assuming that you're not using rm_work, or it didn't restore from sstate instead of building Oct 04 13:24:48 you can force a recipe to build by doing something like bitbake foo -C unpack (where -C says mark this task as needing to be ran, and then do a usual build) Oct 04 13:25:35 I think 'devtool modify foo' is a lot easier in this case Oct 04 13:25:51 also because it's then far easier to tweak the source code Oct 04 13:26:04 and produce commits/patches as needed Oct 04 13:26:20 right - but here I'm not looking to modify it, just to poke around in configure logs and other generated junk to see where those options got to Oct 04 13:28:33 ramcq: you don't have to actually do any modifications, but it makes such poking a lot easier Oct 04 13:28:43 ramcq: especially if you find that you do need to tweak something after all Oct 04 13:29:22 so how do I get it to build according to the recipe? Oct 04 13:29:26 or does it do that? Oct 04 13:29:40 ramcq: first issue 'devtool modify foo', then 'bitbake foo' as usual Oct 04 13:29:50 cool Oct 04 13:30:27 it will tell you where the sources are (build/workspace/sources/foo typically), and the same directory will have symlinks to logs and build dirs Oct 04 13:30:54 we're really not promoting devtool enough Oct 04 13:33:52 is it possible that the gcc recipes are weird enough that they need to all be build with devtool? error about gcc/libgcc1/ missing Oct 04 13:34:10 * ramcq tries devtool modify gcc-runtime and then we'll see what happens... Oct 04 13:34:49 gcc is *very* weird, it uses the gcc-shared recipe to have a single source tree Oct 04 13:34:59 instead of fetching the gcc source N times Oct 04 13:35:53 :'( Oct 04 13:36:00 ramcq: indeed, devtool may not work for really weird cases Oct 04 13:36:18 then you can find stuff in tmp/work/..., but it's awkward :) Oct 04 13:37:26 for the FSL / NXP guys in the channel: anybody having problems fetching firmware-imx? $ git clone git://git.freescale.com/imx/imx-firmware.git \ Cloning into 'imx-firmware'... \ fatal: read error: Connection reset by peer Oct 04 13:39:48 ok, so back to tmp/work - how do I temporarily disable rm_work too then...? :) Oct 04 13:40:13 remove rm_work from USER_CLASSES Oct 04 13:41:45 ramcq: easy check is did you turn it on in local.conf (its not on by default, so "you" turned it on) Oct 04 13:44:41 diego_r: I just tried to clone it here and it succeed. It is dead slow though ... Oct 04 13:46:09 rburton: I asked about lttng yesterday. Should I drop the backported patches and bump to 2.9.4? Oct 04 13:46:26 otavio: thanks. 'dead slow' is definition of fsl regular repositories speed. I'll try to do the same from some other server around the world and see if it succeeds, thanks Oct 04 13:46:28 otavio: for master. for rocko i think the patches we've got are safest. Oct 04 13:47:09 rburton: so I'll wait for the merge and I do the normal general upgrade of it Oct 04 13:47:37 rburton: just bear in mind that 2.9.4 is bugfix only Oct 04 13:47:43 rburton: but your call Oct 04 13:56:18 otavio: thanks for the update on go Oct 04 13:57:00 otavio: does the lttng update have more fixes than what you back ported? Does it address newer kernels (4.14)? Oct 04 13:57:06 sgw: :-) most of work was from matt Oct 04 13:57:38 sgw: https://github.com/lttng/lttng-modules/commits/stable-2.9 Oct 04 13:57:40 sgw: yes Oct 04 13:57:50 sgw: imo it is a must Oct 04 13:59:16 the lttng update is a must for what ? the current release ? Oct 04 13:59:26 * zeddii_home suspects people are getting caught up in the BS of LTS tagging Oct 04 14:08:07 zeddii_home: not for initial but for ongoing maintenance. At NXP BSP we are using 4.13 kernel which fails with current and we are already working for 4.14 which will be LTS so a lot of people will adopt it Oct 04 14:08:31 so it can go into a dot release later. Oct 04 14:08:44 there’s a constant stream of kernels that will follow, ‘future proofing’ is a made up argument. Oct 04 14:09:01 yes; we don't need to delay the release due that Oct 04 14:09:10 cool. that was my only concern. Oct 04 14:09:15 but should get merged soon Oct 04 14:09:43 agreed. I’m obviously going to do 4.14 + a new kernel for the reference linux-yocto’s in the coming months, so I’ll hit it as well. Oct 04 14:10:00 and then delete all my old crappy LTS kernels from master :D yay! Oct 04 14:13:23 Im getting this error when I make a build: image-1.0-r0 do_rootfs: lmsensors not found in the feeds I can do bitbake lmsensors and it builds fine. Oct 04 14:13:52 Any idea why it would build using bitbake directly, but when inlcuded as IMAGE_INSTALL_append = " lmsensors" it fails with that error? Oct 04 14:17:07 hey all Oct 04 14:17:41 is there an easy way to enable/disable a kernel option conditionnaly (based on a machine feature in my case) Oct 04 14:18:04 boucman_work: depends on what kernel recipe you are using. Oct 04 14:18:13 so far the best I can do is conditionnaly include a .cfg fragment withe weird SRC_URI tricks... Oct 04 14:18:32 zeddii_home: yey! Oct 04 14:18:44 yah. or set a KERNEL_FEATURE if you are based on kernel-yocto. Oct 04 14:18:59 zeddii_home: i'm using an ugly BSP provided kernel... let's stay at "if I use the yocto provided one" and i'll deal with all the mud :P Oct 04 14:19:17 ;) I completely understand. Oct 04 14:19:27 zeddii_home: i'll look into KERNEL_FEATURES, I had missed that one... Oct 04 14:19:51 I have an old bug to integrate things a bit more between the techniques, some of which will go into the next release. but it really is the wild west, so hard to do :D Oct 04 14:20:31 ok, I'll just read all the K* variables in the yocto doc, I guess :P Oct 04 14:21:18 boucman_work: feel free to ping me as well. I have plenty of experience on this front. Oct 04 14:21:42 sure, I will.. Oct 04 14:34:53 otavio: it seems firmware-imx works for me too now. Thanks Oct 04 17:48:59 Hello Oct 04 17:50:20 I have a layer which differs a bit regarding the image to build. Im wondering whats the best way of implementing this in a recipe / recipe append. Oct 04 17:51:06 E.g., I have a kernel append to load an additional cfg for image A and another cfg for image B. Oct 04 17:53:01 Is it possible (and best practice) to set a global variable KERNEL_FEATURE_A and check it in the append? Oct 04 20:22:48 Looking for help with Toaster - production server - django not found Oct 04 20:25:13 Oct 04 20:34:16 John_K_ I tried the production instance with mysql a few months ago and gave up as this is absolutely not working for many reasons. Oct 04 20:36:55 @FabKna, Thanks... I've been on this for 3 weeks and did 2 clean CentOS installs... Instructions are not clear about env info... Oct 04 20:37:46 Yeah I agree I think it is really bad that this instructions is only as it is never tested. Oct 04 20:38:00 And I tried it several weeks Oct 04 20:38:22 try yocto-autobuilder Oct 04 20:38:43 it is in my opinion better than toaster Oct 04 20:39:21 https://github.com/RobertBerger/yocto-autobuilder is an example docker image Oct 04 20:42:12 Well, I got it to work directly, without Apache... Oct 04 20:42:20 yep same here Oct 04 20:42:37 I'll take a look at that, but client was pretty specific that he wanted it with apache Oct 04 20:43:03 and installed on bare metal. Oct 04 20:43:29 I worked a few months with it. However, toaster has drawbacks in my opinion, e.g., debugging infos are not enough for me. Oct 04 20:44:40 I will definitely pass this on.... thanks again Oct 04 20:44:46 John_K_: As said I tried it several weeks with apache and mysql and env info is only one thing... you have to fix many more issues to get it working and these issues are not documented anywhere Oct 04 20:45:48 for example, I had to alter the mysql database and so on. In the end I was happy with the built in django server Oct 04 20:46:47 not sure why they built-in won't handle a half dozen developers Oct 05 02:27:56 I'm confused with .config and defconfig. When I bitbake virtual/kernel -c menuconfig, it produce .config or defconfig? Do I need both to bitbake virtual/kernel? Oct 05 02:42:13 learningc: bitbake -c menuconfig will just write to the .config, if you wanted to include that in a recipe properly you would rename it to defconfig, put it next to the recipe and add it to SRC_URI; alternatively you can do bitbake -c diffconfig virtual/kernel and you'll get a config fragment you can use with just the changes in it Oct 05 02:42:41 learningc: you only need to do that when you're actually happy with the final configuration though Oct 05 02:51:30 bluelightning, should I bother with defconfig file at all? If I bitbake virtual/kernel, does it require .config or defconfig? Oct 05 02:52:50 learningc: if you have done bitbake virtual/kernel -c menuconfig you only need to go ahead and build the kernel, no need to worry about the defconfig Oct 05 02:53:29 learningc: but bear in mind that your config changes are temporary at this point, once you are finished making changes you should move it to a defconfig next to the recipe or a config fragment Oct 05 02:54:58 (otherwise if for example you did bitbake -c clean virtual/kernel or deleted your TMPDIR your changes would be gone) Oct 05 02:54:59 bluelightning, I see. Thanks. Getting clearer in my mind Oct 05 02:56:38 bluelightning, Where is the recipe directory that I should put the defconfig located? There are so many directories in tmp/ that I'm getting lost Oct 05 02:57:29 learningc: the defconfig, should you want to preserve it, should go in a subdirectory named "files" or the same name as the recipe right next to the recipe file itself Oct 05 02:58:12 then you need to add "file://defconfig" to SRC_URI within the recipe if it isn't already there **** ENDING LOGGING AT Thu Oct 05 03:00:01 2017