**** BEGIN LOGGING AT Mon Jan 07 02:59:56 2019 Jan 07 06:59:17 New news from stackoverflow: Make img from ext4, dtb and uboot.bin Jan 07 09:48:31 robbawebba: later today i have time to isolate the problem. ;-\ Jan 07 10:18:32 good morning Jan 07 11:35:08 hi, while upgrading from rocko to thud I've been hit by a build failure in the newish make-mod-scripts recipe: Jan 07 11:35:18 ./include/linux/if.h:28:10: fatal error: sys/socket.h: No such file or directory Jan 07 11:37:23 the thing is, that include file is in the recipe-sysroot, but make-mod-scripts passes only KERNEL_CC and HOST_CC, but none of them adds that path to the include dir list Jan 07 13:00:26 New news from stackoverflow: Bitbake copying a prebuilt static library into `/usr/lib` location of output yocto linux image Jan 07 13:32:53 am i blind or isn't there zero documentation on how to run yocto-autobuilder-helper? Jan 07 13:39:57 derRichard: i suspect the autobuilder code in yocto-autobuilder2 is the documentation Jan 07 13:40:03 anyone here use icecc? Jan 07 13:41:05 rburton: ahh!, i cloned yocto-autobuilder and wondered why i found no traces to yocto-autobuilder-helper.... Jan 07 13:42:32 yay, now the thing starts to make sense :P Jan 07 14:11:17 RP: the make-mod-scripts issue I reported disappears if I revert your commit http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb?id=0f85563eacf5138d98b826343cdfc3833d1c5c8e Jan 07 14:11:36 IOW if I disable make prepare Jan 07 14:14:34 BTW in the meanwhile I tried building a clean boneblack configuration, and make-mod-scripts succeeds; I compared the line where make is called, and they look the same (except for different paths and arm/arm64 differences) Jan 07 14:16:06 lucaceresoli: when you say they aren't passed in KERNEL_CC or HOST_CC, is there a --sysroot option in there? Jan 07 14:19:00 RP: no, there seem to be no "--sysroot" in the entire log.do_configure (after bitbake -v make-mod-scripts) Jan 07 14:21:40 RP: with bitbake -e make-mod-scripts I see the only lines mentioning --sysroot are those exporting CC, CCLD, CPP, CXX, FC, LD, plus the TOOLCHAIN_OPTIONS= line Jan 07 14:22:08 but the recipe only passes the HOST and KERNEL_ variants of those Jan 07 14:22:20 lucaceresoli: which machine is this for? It is working everywhere else without the headers so I'm wondering how your setup differs Jan 07 14:23:35 rburton: we should decide about the python and hostname patches in -next. In or out in which form? Jan 07 14:23:55 rburton: I'm leaning to merge the python ones and rework netbase to move the file Jan 07 14:24:44 RP: I have a custom machine conf file, based on the zynqmp machine conf in meta-xilinx Jan 07 14:25:19 lucaceresoli: does the plain zynqmp machine work for thud? Jan 07 14:25:51 lucaceresoli: it may be the kernel version you're using needs some fix? Jan 07 14:25:52 RP: yes, albeit in a different setup (they use multiconfig, I don't) Jan 07 14:26:10 RP: in my files I have only a few extra definitions: Jan 07 14:26:56 RP: the most relevant is PREFERRED_PROVIDER_virtual/kernel and PREFERRED_PROVIDER_virtual/bootloader pont to my linux and u-boot recipes Jan 07 14:27:16 ok, yocto-autobuilder-helper is not the right thing for me Jan 07 14:27:21 RP: may the different virtual/kernel provider cause similar issues? Jan 07 14:27:39 lucaceresoli: well, it means you're using a totally different kernel ;-) Jan 07 14:28:13 derRichard: fair enough, its just a different way of handling setup based on a single config file Jan 07 14:28:39 RP: sounds reasonable Jan 07 14:29:29 RP: for buildbot yocto-autobuilder-helper makes sense. but i need something small/simple/easy-to-use. so i go back to shellscript Jan 07 14:29:35 +reporepo Jan 07 14:29:38 RP: but not different kernel sources. "my" kernel points to the same tag as Xilinx's. Jan 07 14:30:46 RP: and my own kernel recipe is basically 'require recipes-kernel/linux/linux-yocto.inc' plus a few small additions Jan 07 14:32:16 derRichard: if something with -helper like functionality were part of bitbake, would that change? Jan 07 14:32:47 lucaceresoli: some difference has to cause it though! Jan 07 14:33:13 RP: yes. Jan 07 14:33:14 RP: I totally agree :) Jan 07 14:33:32 derRichard: that is a potential future :) Jan 07 14:34:04 RP: to use yocto-autobuilder-helper, you need yocto-autobuilder2, this generates a layersinfo.json. then you need yocto-autobuilder-helper to fetch these repos, next step is having a config.json and run more magic scripts... Jan 07 14:34:15 a single tool plus a single config file would be nice :-) Jan 07 14:34:48 bonus: these scripts take parameters via commandline _and_ shell env Jan 07 14:34:53 derRichard: the idea is there could be a different driver than y-ab2, its just not been written yet Jan 07 14:35:08 RP: I'm trying to restrict the area to investigate, do you think the kernel recipe itself can be the culprit (as opposed to the make-mod-scripts recipe?) Jan 07 14:35:11 RP: yeah, i understand. Jan 07 14:35:13 derRichard: including Jenkins Jan 07 14:35:27 so, no big deal. i'm fine with shellscript+reporepo or +gitsubmodules Jan 07 14:35:37 lucaceresoli: I'd check it really is the same kernel source and if so, diff the kernel configs Jan 07 14:47:07 RP: same kernel SHA-1. Do you mean you'd compare the two kernel diffs? To sort out what looks like an include path issue? Ok, will do it for lack of better ideas... but I don't get the reason Jan 07 14:52:50 lucaceresoli: I'm wondering if linux-yocto is applying patches or something Jan 07 14:53:32 lucaceresoli: same sha may or may not mean what we'd like it to mean depending on where you get it from Jan 07 15:05:13 RP: weird. After a cleansstate of kernel, now make-mod-scripts succeeded Jan 07 15:05:18 I'm puzzled Jan 07 15:08:21 RP: think i fixed the sdk thing, will fire a new quick build now Jan 07 15:14:43 rburton: yay! Jan 07 15:30:58 New news from stackoverflow: Yocto compiled U-Boot for custom Sabresd-based board won't boot Jan 07 16:09:55 rburton_: I brought back nativeperl wrapper, can we do another AB pass? Jan 07 16:10:12 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/perl-sanity Jan 07 16:13:27 RP: ^^^ Jan 07 16:22:49 RP: with the new code the upstream version checks for all recipes are no longer parallel, and thus much slower :( Jan 07 16:31:12 New news from stackoverflow: Bitbake: How to only fetch the sources? Jan 07 16:41:54 rburton: Ah! I always wondered why the SDK might possibly have multiple environment scripts.... its for multilib :) Jan 07 16:44:12 PLease check my answer to the s-o question Jan 07 16:56:18 hello! Jan 07 16:57:13 where does qemu mac address come from? on different hosts it's the same, is there a way to deduct it from host's eth0 somehow ? Jan 07 17:11:02 kanavin: If its a problem we can likely parallelise it Jan 07 17:27:54 kanavin: running Jan 07 17:28:24 JPEW: or potentially multiconfig too Jan 07 17:38:11 kanavin, wtf is Yocto 2.5 :) Jan 07 17:40:28 JPEW: yeah. the nightly-multilib autobuilder run has a three-way MIPS build Jan 07 17:40:53 proper 32-bit, proper 64-bit, and that halfway 32/64 bit combo Jan 07 17:41:10 thats where all the "check the binary matches what we expect" tests came from Jan 07 17:41:26 derRichard: could you pm me please? Jan 07 17:49:52 Crofton: the one after 2.4? Jan 07 17:50:03 lol Jan 07 17:50:12 I added a link to the version decoder ring Jan 07 18:46:29 yates_home: did so Jan 07 19:08:58 * kroon wonders why some files under oe-core/meta/files/common-licenses/* get their "Modify"/"Change" timestamps updated during a build Jan 07 19:11:51 ok Jan 07 19:21:55 derRichard: ok, check now please Jan 07 19:26:05 I have a python task that needs to import a module from a -native recipe that is not in a standard location like /usr/lib. I've used the `sys.path.insert(1, the_native_path)` however I get `No module named 'whatever'` after a few imports (e.g., `from some import native_thing` which then imports `whatever`). The pyc files are there, where it's supposedly searching. It works fine in a devshell and seems to only have a Jan 07 19:26:05 problem when importing modules relative to the top. Jan 07 19:31:49 New news from stackoverflow: How to install dependencies from requirements.txt in a Yocto recipe for a local Python project Jan 07 19:46:09 Anyone have an idea on how to get the recursively referenced modules to import in the python task as well? Jan 07 20:12:15 Ah, I see the problem. The python task isn't running a 2.7 interpreter, which my native module needs. Jan 07 20:12:30 Is there a way to have a python 2.7 task in bitbake? Jan 07 20:17:40 no. tasks run in bitbake itself, and bitbake is python 3 Jan 07 20:17:54 it sounds like what you really want is a separate python 2 script which a bitbake task runs Jan 07 20:18:06 and inherit pythonnaitve so 'python' in the task is the python 2 we built Jan 07 20:18:38 you can easily put the script in a layer, add that layer's scripts path to the PATH in layer.conf, and thereby ensure you can run it from the task easily Jan 07 20:24:41 tgoodwin: https://pythonclock.org Jan 07 20:26:32 heh, indeed Jan 07 20:27:48 just saying ;) Jan 07 20:31:34 kergoth: nice Jan 07 20:32:06 Yeah I need to share that link with a few people. Jan 07 20:38:52 How to use this new bitbake-hashserv, is one supposed to start it manually and then have SSTATE_HASHEQUIV_SERVER set and do a build ? Jan 07 20:41:15 * armpit nothing like loading the gun to shoot yourself in the foot... gosh, I am expert at it Jan 07 20:45:37 i get this warning: package-foo went backwards which would break package feeds from (0:git0+90bd93c1ae-r0 to 0:git0+25e2fb7e3c-r0) Jan 07 20:45:51 why is this kind of check not disabled for autorev/git recipes? Jan 07 20:46:01 comparing the git sha1 is not very wise ;) Jan 07 20:46:37 iirc if you're using SRCPV it should include a leading number based on commit count, not hash alone Jan 07 20:46:49 which is why you shouldnt directly add SRCREV to your PV Jan 07 20:47:57 kroon: Yes, but it's still a work in progress :) Jan 07 20:48:11 kroon: Including documentation Jan 07 20:48:26 kergoth: well, i did: Jan 07 20:48:26 SRCREV = "${AUTOREV}" Jan 07 20:48:26 PV = "git${SRCPV}" Jan 07 20:48:31 is this stupid? :) Jan 07 20:49:01 that's correct, not sure why you're getting git0 for both unless you rebased the branch so the distance didn't change Jan 07 20:49:04 hmm Jan 07 20:50:03 i did not rebase Jan 07 20:50:19 derRichard: did you enable prserv? Jan 07 20:50:36 since i don't know what prserv is, i guess "no" :-) Jan 07 20:51:14 JPEW, figured out I had to set BB_SIGNATURE_HANDLER too Jan 07 20:51:21 prserv is a service which returns incremented LOCALCOUNT number to be used as a prefix for SRCREV in SRCPV Jan 07 20:51:30 kroon: Oh, right that too :) Jan 07 20:52:31 kroon: Also SSTATE_HASHEQUIV_REPORT_TASKDATA = "1" if you want to be nice and make debugging the cache a little easier Jan 07 20:52:37 kergoth: this git repo has no tags. maybe this is the reason for git0 Jan 07 20:52:54 JPEW, just wondering, in the end, shouldn't the server be started/stopped automatically when doing a build with bitbake ? Jan 07 20:53:03 kroon: And probably INHERIT += "reproducible_build" Jan 07 20:53:45 kroon: Ya possibly... running a local one might not be too useful AFAICT. You really need to share one for maximal effectiveness (sort of like the prserv) Jan 07 20:54:48 JPEW, hmm I though this hashserv thing would sort of accelerate doing incremental builds ? Jan 07 20:55:08 kroon: Thats the end goal, but its not there right now Jan 07 20:55:19 JPEW, ok Jan 07 21:19:32 JPEW, I'm trying to figure out if it makes sense to use some of the hash output from OEOuthashBasic() and store that in buildhistory, to detect when files change Jan 07 21:20:22 kroon: Possibly, is this as part of an attempt to make builds more reproducible? Jan 07 21:23:07 JPEW, well, more like detecting when files change, so that fixes can be made to make it reproducible. buildhistory seemed like the place to put this info, at least i'm not aware of any other way to easily detect changes in the output Jan 07 21:24:08 kroon: Yes, I think using the output from OEOuthashBasic would be a good use for that. I've been meaning to find some one working on the reproducible build setup to suggest it Jan 07 21:24:26 kroon: The only thing to be aware of is that OEOuthashBasic ignores timestamps Jan 07 21:26:16 JPEW, ok Jan 07 21:27:06 kroon: In general I think there is a lot of good overlap between the usecases for using the hash equivalence to accelerate builds and reproducible builds Jan 07 21:32:13 New news from stackoverflow: need help in using bitbake INCOMPATIBLE_LICENSE flag Jan 07 21:45:56 Anyone see this on rocko: I'm getting an installed-vs-shipped QA about files that don't exist in the image's directory (which were deleted during the install task after autotools ran). Jan 07 21:52:04 Turns out it's the base do_package duplicating my sources and putting them into the package path. So that suggestion from installed-vs-shipped actually can't be worked around since do_package is causing its own problem. Jan 07 21:52:53 guys, can it be that the go-cross-canadian package is broken? it contains the go compiler but no sources for the standard go packages Jan 07 21:53:09 therefore you cannot build anything with the go compilert in the sdk Jan 07 22:01:00 derRichard: you may need to add something to the target sysroot too? Jan 07 22:01:11 * RP doesn't know much about go Jan 07 22:02:07 RP: well, i hoped that go-cross-canadian-XXX-dev contains these files, but this rpm is empty Jan 07 22:02:27 usually the "go" package on a linux distro contains the compiler plus the standard library Jan 07 22:03:16 derRichard: I'd not expect that package to contain those things Jan 07 22:03:29 derRichard: its the wrong arch (running on the nativesdk system) Jan 07 22:04:07 derRichard: go-runtime-dev in the target sysroot? Jan 07 22:04:31 let me check, this is a good idea Jan 07 22:05:47 RP: sounds like a sane approach, go-runtime-dev was not installed Jan 07 22:05:52 let me rerun the build Jan 07 22:05:58 that go stuff drives me crazy Jan 07 22:10:38 JPEW, sstate.bbclass line 826 looks a little funny .. stat:ing twice is that intentional ? Jan 07 22:11:50 (using master-next) Jan 07 22:12:45 kroon: Yes it is on purpose. It is reporting the file mode (permissions; S_IMODE) and file type (e.g. file, directory, symlink; S_IFMT) seperately to make it easier to see why something changed Jan 07 22:13:13 It doesn't actually call stat() twice Jan 07 22:15:07 hmm are we talking about the same line.. ? this one "if stat.S_ISBLK(s.st_mode) or stat.S_ISBLK(s.st_mode):" Jan 07 22:15:56 ah, hah hah. Jan 07 22:16:35 You are correct, it should be stat.S_ISBLK() or stat.S_ISCHR() Jan 07 22:17:19 yes, that would make more sense :-) Jan 07 22:22:53 Quick guidance question: I have used a custom BSP for many years with a Pentium-M architecture. Now I am migrating to an Intel-Atom (E3845) w/ BayTrail SoC. It appears I must use the meta-intel BSP. I'm currently at Sumo for Pentium-M. How do use the meta-intel BSP (MACHINE ?= intel-corei7-64) and include all my previous BSPs? I am currently using meta-intel as a submodule and symbolic linking to POKY_DIR. Is it best to copy Jan 07 22:24:28 you never have to use meta-intel (or any other semi layer).. you can always do it yourself.. Jan 07 22:24:50 But often it's easier to use a semi's layer -- just keep in mind it often comes with penalties of requring a kernel different from the main YP kernel Jan 07 22:26:07 When you say, do it yourself. Are you referring to copying the meta-intel as a starting point then honing it down to the bare essentials? Jan 07 22:26:41 no, I'm referring to you defining your own machine.conf file for your own boards and using the Yocto Project kernel for sources Jan 07 22:27:10 since the Yocto Project kernel is very close to the upstream Linux kenrel (kernel.org).. If you know it works there, it should work properly with the Linux Yocto as well. Jan 07 22:27:39 if you want to use a semi layer, such as meta-intel, then just download it 'somewhere', and when you create a new build directory, you just add it to your build's conf/bblayers.conf file Jan 07 22:27:54 that will enable the components, after that it's just an issue of using the components and configurign them properly Jan 07 22:28:06 (this is all covered the main documentation) Jan 07 22:29:27 Oh, yes I currently have a "machine.conf" for my pentium-M. It works great, and has many custom kernel options for 3.14.* and many bbappend files. This new hardware will require a new kernel 4.11+ and I am wondering best way to start. I was gonna start with the meta-intel but didn't know if that is correct? Jan 07 22:31:13 if you are not using anything specific from meta-intel, there is no reason to use it.. Jan 07 22:31:13 A semi-layer (BSP) is the meta-intel. I understand terminology now. Hmmm. If you tweak the meta-intel BSP files then what is best way to control? Your own repo? Jan 07 22:31:26 (specific things, optimziation configurations, specific BSP configurations, kernel modules, etc) Jan 07 22:32:32 In general you want to make sure only include layers that have specific items you want/need/use.. otherwise you run a risk of introducing errors or difficult to find problems.. Jan 07 22:33:05 I see. I believe I need the meta-intel for optimization but not certain yet. The meta-intel might not be required if I'm not using the graphics card, etc. It is a headless unit. Jan 07 22:33:22 (I've got nothing against meta-intel or any other semi layer -- just be aware of what you are getting when you use them) often they provide custom kernel sources that may provide specific vendor features (good) or (bad) lock you in to some random kernel that is difficult to support Jan 07 22:34:00 I don't want vendor lock. I have been locked to the 3.14 kernel due to HW drivers. Jan 07 22:34:09 In the past Jan 07 22:34:22 Atom/Baytrail may not have specific system config files.. I believe it supports the core i7 config Jan 07 22:35:12 Yeah, I don't know if the Baytrail SoC requires the meta-intel. I Jan 07 22:35:32 am just getting ramped up for this new effort. Wanted the expert opinions from you guys. Thanks for ideas. Jan 07 22:35:41 intel arch is one of those that mostly just works without anything special.. unless you need specific drivers and/or graphics support.. Jan 07 22:36:15 I tend to stay away from meta-intel, only because I want to use the linux-yocto kernel (stock) to try to avoid semi vendor specific changes.. Jan 07 22:36:25 (since i have to support a bunch of ARM, MIPS and PPC systems as well) Jan 07 22:36:48 it does mean that there is potentially more work on my side to setup the system tuning, and configure the kernel though.. Jan 07 22:36:56 but it's a reasonable tradeoff for my needs.. Jan 07 22:37:51 I'll try to maintain my custom machine.conf, and update kernel first. It might be without major headaches, but it's never quite that easy. ;) Jan 07 22:39:16 Using third party layers can make things easier, (and usually does for userspace).. but when it comes to the kernel.. you need to either trust the semi (and understand that one kernel is usually not compatible with another semi's kernel) or use the stock system and then have access to the shared kernel. Both are entirely valid approaches, just a tradeoff Jan 07 22:39:31 (since semi kernels often have specific board and device optimizations not in the more generic shared kernel. Jan 07 22:40:56 but either way the approaches are similar.. any work you do should be in your own custom layer anyway.. (even if it's adjustments to meta-intel).. makes it easier to manage long term.. and the approach of including layers (meta-intel and/or your own) is pretty standard Jan 07 22:41:24 Fray: Preventing a custom delivery, I will try to keep stock kernel. I see your points. Jan 07 22:42:09 (and if you want to use the raw upstream kernel.org kernel, you can do that as well.. but the Linux yocto kernel has a few common integration changes that are usually needed.. thus I prefer the linux-yocto kernel over kernel.org myself) Jan 07 22:43:07 If I do use the meta-intel BSP, then I will control within my local repo. This is different from my openembedded submodule. I was hoping to use a submodule for meta-intel if needed. Jan 07 22:43:49 I will stick with the yocto-kernel. That is what I use now for my deployments. Jan 07 22:44:03 the way you download the layers (submodules or otherwise) is up to you.. there is no standard approach.. I use 'repo' myself, but I don't know of any two groups that do exactly the same thing Jan 07 22:44:28 (I don't particularly like submodules, as I find them harder to manager then repo... but that is personal preferrence) Jan 07 22:45:44 submodules for openembedded has been easy for me when jumping yocto releases. It just required some experimentation of both. Jan 07 22:46:32 whatever youa re comfortable is fine for managing downloads.. Jan 07 22:47:21 Fray: Thanks again for your activity and responses. I appreciate it. Well done sir. Jan 07 22:48:02 no problem.. Jan 07 22:56:03 JPEW, I'm thinking along the lines of putting a processed depsig.do_package under version control in buildhistory, maybe making the content a little more human-readable Jan 07 22:57:05 depsig isn't human readable? ;) Jan 07 22:58:02 More seriously, it should be human readable, thats most of the point of having it exist. Now is the time to change it if you have suggestions before it starts being used Jan 07 23:00:20 JPEW, fairly human readable to be fair :-) but maybe file mode and type could be spelled out in a way that is easier to grasp Jan 07 23:00:34 JPEW, instead of a hex number Jan 07 23:01:26 kroon: Sure, that would make sense. Can you comment about that (and any other ideas that would make the reproducible stuff easier) on the patch on the mailing list? Jan 07 23:02:08 kroon: I'd rather spend a little longer now that have a OEOuthashBasic2 in a few months :) Jan 07 23:03:36 JPEW, oh is this set in stone once released :-/ Jan 07 23:03:56 JPEW, sure I'll post a mail tomorrow with these comments Jan 07 23:03:56 No, you can choose a new one, it just invalidates all the old hashes Jan 07 23:04:35 kroon: Thanks Jan 07 23:07:46 robbawebba: found why my go application crashes when built with yocto. it is due to dynamic linking Jan 07 23:08:08 if i disable it in meta/classes/goarch.bbclass, the application works fine Jan 08 01:54:28 derRichard: is that related to the GO_LINKSHARED variable that I included in my recipe? **** ENDING LOGGING AT Tue Jan 08 02:59:57 2019