**** BEGIN LOGGING AT Mon Sep 18 03:00:01 2017 Sep 18 03:22:24 Hi. I would need to custom build the kernel. How do I configure and compile the kernel in Yocto? Which directory to go? Thanks in advance. **** BEGIN LOGGING AT Mon Sep 18 08:08:04 2017 Sep 18 08:12:22 Anyone else seen that applying patchs fails in a git tree recipe where S has been moved to a sub directory in the git tree? manually applying the patch works with correct path strip levels, but bitbake insists that patching fails. Sep 18 08:22:00 aha! bitbake uses quilt to apply the patch and the parameters to patch are wrong Sep 18 08:31:18 hello, what is the most proper way of storing all of the sources necessary for a build locally so that future clean builds are no longer dependent on downloads from remote servers that might not be available anymore? Sep 18 08:32:29 because images for devices might need to be maintained for many years and links to source repositories are likely to break during that time Sep 18 08:34:25 eduardas_m PREMIRRORS? http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-PREMIRRORS Sep 18 08:35:22 we append it in our distro conf file and add a premirror to our local server Sep 18 08:39:13 melonipoika: did you have to manually clone all of the necessary repositories for this to work? any way to automate this? Sep 18 08:41:00 Hi Everybody. Little question here about "best practice". I would like to add a patch but there is already a new .bbappend. What is the best practice ? Just make the changes in .bbappend or there is another thing to do ? Sep 18 08:41:39 eduardas_m aour B&I team owns that mirror. Not sure how they populate it but definitely not manually Sep 18 08:42:22 eduardas_m: bitbake world -c fetchall, iirc Sep 18 08:42:43 eduardas_m: and turn on BB_GENERATE_MIRROR_TARBALLS or whatever the actual option is. Sep 18 08:43:13 ChrysDaze: your choice, either add more to the bbappend if its one you control, or add another if you want to keep it separate Sep 18 08:43:39 rburton : so there is no problem of having two bbappend in the same recipe folder? Sep 18 08:44:01 rburton : with the same name Sep 18 08:44:21 in the same folder obviously you can't have two files with the same name :) Sep 18 08:44:31 if its your layer then just edit the existing append Sep 18 08:45:01 rburton : yeah true, i forgot about it. Ok thanks. Sep 18 08:45:07 rburton: the tarballs in this case are the same ones that appear in the usual downloads folder? Sep 18 08:45:20 rburton : the commit message should be enough Sep 18 08:45:23 eduardas_m: the tarballs are the ones that don't appear unless you turn it on (tarballs of git archives) Sep 18 08:45:32 but if you want a mirror you want those Sep 18 08:46:48 rburton: one more thing, where are these git archive tarballs going to appear by default? Sep 18 08:46:54 in DL_DIR Sep 18 08:47:25 rburton: thank you, will try it out Sep 18 08:52:03 ioanb7: Is KERNEL_MODULE_AUTOLOAD = "modulename" is what you'r looking for ? Sep 18 09:26:08 Hi, quick question, can you use wildcards in PRIVATE_LIBS_${PN} ? I have a lot of libs, but they have a common prefix so would be good to use "xxx*" if that is possible/allowed Sep 18 10:15:14 How do I know what name to bitbake? Sep 18 10:18:38 How do I purge a packages from the sstate cache completely? I thought -c cleanall or -c cleansstate did, but I still find lots of artefacts by that name in th state cache after running it. Sep 18 10:19:13 rm works :) Sep 18 10:19:32 find . -name sstate:\*somename\* -delete ? Sep 18 10:19:35 yeah Sep 18 10:19:39 thanks Sep 18 10:32:32 hello guys! Sep 18 10:32:55 is there an easy way I can change the filename separator for bitbake packages from ":" to something more like "_", "-" or anything else really? Sep 18 10:53:48 Bretos: portability with windows based file systems? Sep 18 10:55:33 sveinse: nope. Artifactory weird requirements and unability to upload files with ":" in names Sep 18 11:02:18 Well, the separator can't be "_" nor "-" because these symbols are used within package names. E.g. "x86_64" or "cortexa9hf-neon-poky" and so on Sep 18 11:03:14 But I don't really know how hardcoded the ':' is Sep 18 11:04:30 For my dev machine I'm using a USB removable disk running NTFS for sstate cache. It does actually work with ':' in them on ntfs, but opening the sstate cache on windows confuses the explorer :P Sep 18 12:00:28 ntfs is not nice, but it's a lot nicer than Windows makes it look :) Sep 18 12:06:51 ; might be a good choice Sep 18 12:31:15 Oh man I hate debugging basehash mismatch errors. So extremely time consuming Sep 18 12:33:14 I wish bitbake could make the effort of actually storing the sigdata and present the actual diff Sep 18 12:54:41 When I build for an image on pyro, I get "ERROR: When reparsing ...lm-initrd-image.bb.do_image_cpio, the basehash value changed from X to Y" Sep 18 12:54:56 If I rerun bitbake, no error is printed Sep 18 12:55:07 I try to follow https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc) Sep 18 12:55:55 if possible, I'd like a sanity check: git.ti.com seems to be not working for me, so some WiLink related recipes fail to fetch... is it just me or are other people also having this problem today? Sep 18 12:59:44 but I have no .sigdata output for the lm-initrd-image in /tmp/stamps/. How can I get hold of the two sigdatas that bitbake is complaining about when (re)parsing? Sep 18 13:56:24 I get a "No GNU_HASH in the elf binary". Google suggest that that might be ${LDFLAGS} not being used properly. This is a configure based recipe, so perhaps this is not setting things up correctly? Sep 18 13:57:13 it's not obeying the LDFLAGS we set in the environment. autoconf based projects generally do pick it up, unless the configure sript is explicitly overriding LDFLAGS, or it's not automake-based and the makefile.in isn't setting and using LDFLAGS at all Sep 18 14:05:47 Hmm, this Makefile(.in) is a completely manual thing. No $(LDFLAGS) used at all, so I must patch. What other compilevars must be honored from BB? Sep 18 14:06:32 CFLAGS , LDFLAGS, CC, LD, AS, CPP Sep 18 14:06:46 those are the common ones at least Sep 18 14:07:41 None for ar and ranlib? Sep 18 14:08:10 if you program is doing static binaries, then use AR and RANLIB as well Sep 18 14:08:27 static binaries/libraries Sep 18 14:08:49 thanks Sep 18 14:11:47 This program is doing, ln -sf $(PREFIX)/objdictgen/objdictedit.py $(PREFIX_BIN)/bin/objdictedit, which results in a absolute symlink path error. How should this be rearraged to handle proper sysroot paths? Sep 18 14:12:21 you want it to be relative. There are helper programs (forgetting the names right now) that will convert an absolute to relative path Sep 18 14:13:56 fray: OOI, is this always the case? Do you always want to use relative symlink on the target system? Sep 18 14:14:19 it makes a lot of things much easier Sep 18 14:14:53 it also allows you to more easily serve filesystems over NFS and do other manipulations where an absolute link can be problematic Sep 18 14:15:35 yes, but it also locks down the relative distance from the two files. So generically speaking, some distros does not like this approach for this reason. Move the symlink and the reference is gone. Sep 18 14:16:25 you are creating a distribution with the Yocto Project/OE builder... you can design it however you want.. but generally speaking the core distribution pieces should not 'move' over the life of the system. This causes a -lot- of the problems for deployed systems Sep 18 14:17:05 this is also why there are helpers to do the relative links.. the links are generated when you creat ehte packaeg and the system has the full knowledge of the standard paths.. Sep 18 14:17:15 Sure, I'm just elaborating and trying to gauge where yocto is at in this. Sep 18 14:17:23 so if your distro doesn't use '/usr' and another does.. that is fine.. the relative paths are still setup properly Sep 18 14:18:29 here we go.. Sep 18 14:18:31 For the first embedded (ubuntu) system we used in the field, I wrote a tool that modifies all absolute symlinks and linker-script references in a sysroot to relative ones, creating consistency within the sysroot, but allowed absolute references on the target system Sep 18 14:18:50 lnr both can be absolute, result will be relative links on the disk Sep 18 14:18:58 lnr is a utility provided as part of oe.. Sep 18 14:19:14 right, cool, I'll try to patch that in Sep 18 14:19:32 alternatively you can use ln -r -s .... as well, but this requires the host to have coreutils 8.16 or newer Sep 18 15:06:47 oh I love packages which is creative when it comes to CFLAGS and LDFLAGS and have automagic (TM) detection of what options to use. In this piece of code the latter variable is named EXE_CFLAGS :o Nice! Sep 18 15:30:42 RP, i have stagged the kernel updates the bluetooth sec fixes for pyro Sep 18 15:32:00 armpit: thanks, are you handling the meta-yocto-bsp kernel updates also? Morty? Sep 18 15:37:56 sqw looking at those next. once done moving to Morty Sep 18 15:43:36 armpit: let me know if you need any help with the BSP side Sep 18 15:43:51 k Sep 18 15:58:43 armpit: thanks! were they build tested and ready to merge? Sep 18 16:00:59 RP, no AB build testing Sep 18 16:01:26 I was wait for them to hit master Sep 18 16:02:04 armpit: fair enough, we can queue and test then. I've been having some issues with some patch causing image size to spill over :/ Sep 18 16:03:40 RP: can I help with the image size issue? Sep 18 16:07:39 RP, I did run a pyro build this weekend and tagged the commit built with "good-build-1" Sep 18 16:09:20 armpit: so some patches are good to merge? Sep 18 16:09:40 sgw: good question. I have a theory but the patch to test that theory is proving a pain to write :/ Sep 18 16:09:57 RP, sure Sep 18 16:10:28 RP: let me know, I am building clean master and pyro for sanity Sep 18 16:22:13 RP: is this image sieze issue specific to the the sato-sdk-ptest image? Sep 18 16:22:56 aehs29: yes Sep 18 16:28:08 armpit: I had contrib branches with kernel patches for pyro and morty for genericx86*, idk if you already got those though hsalejandro/genx86_pyro_kernel Sep 18 16:28:16 RP: ok, Im reproducing atm Sep 18 16:33:10 aehs29, I will take a look. thanks Sep 18 16:33:18 zeddii, ping Sep 18 16:38:37 armpit: no prob /s/pyro/morty for morty Sep 18 16:39:11 k Sep 18 16:55:55 aehs29, sgw, rburton: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip5&id=0a5acbc273bfa691fa222cf5651976cf62d1795e - that "fixed" my local build so filtering the rpms my build can see does help. Now I can add back bits of mut and see what breaks it Sep 18 17:22:07 RP: still building master and waiting for it to fail, I'll check once that finishes Sep 18 17:24:57 RP: I can see why you said it was a pain to write though Sep 18 18:18:18 Hi all. I made some changes and -c fetch/config/deploy u-boot-fslc. I need those changes to make it into the image. Am I right that "bitbake -f -c deploy core-image-mycustomimage" will remake the rootfs and sdcard files? Sep 18 18:18:57 I only ask because I don't want to give a -f that will result in an entire system re-roll and I end up waiting 4+ hours Sep 18 18:20:05 that chain of events for u-boot-fslc is inaccurate. I fetch and config'd it, made my code changes, then deploy'd Sep 18 18:23:57 ok, well 'deploy' on the image isn't right... Sep 18 18:32:08 just do bitbake Sep 18 18:32:30 khem: Thanks Sep 18 19:13:44 sgw, I believe I updated all yocto bsp to latest pyro can support. all changes in my pyro-next if you want to take a look. I am confirm locally Sep 18 19:20:16 any opinions on ADT bug? https://bugzilla.yoctoproject.org/show_bug.cgi?id=12095 Sep 18 19:20:18 Bug 12095: normal, Undecided, ---, brian.avery, NEW , Toolchain.Host.Mismatch problem Sep 18 19:24:28 fray: rebased patch for libsolv on musl: https://github.com/Conan-Kudo/libsolv/commit/bf7cbff69acd96067511695ca8503fb5477a0671 Sep 18 19:32:59 armpit: sgw looks good to me Sep 18 19:35:15 aehs29, thanks Sep 18 19:43:36 aehs29: thanks for looking at Sep 18 20:29:06 fray, I will be in about 10 minutes. Sep 18 20:31:10 halstead when you can, we need a command run on the layer index.. update.py --branch rocko --layer meta-poky --reload Sep 18 20:31:26 (checking to see if anything else needs a reload) Sep 18 20:31:30 fray, Will do ASAP. Sep 18 20:32:06 yup.. that is the only thing I need.. thanks Sep 18 20:32:14 let me know ehen it's done and I'll verify it worked Sep 18 20:38:10 fray, Run. There were a few warning like WARNING: Duplicate inclusion for /opt/workdir/git___git_openembedded_org_openembedded-core/meta/conf/distro/include/yocto-uninative.inc in /opt/workdir/git___git_yoctoproject_org_meta-yocto/meta-poky/conf/distro/poky.conf Sep 18 20:39:32 yup.. expected those.. sec Sep 18 20:39:41 yup, fixed the issue.. thanks! Sep 18 20:40:16 Of course fray. Happy to help. Sep 18 20:57:38 halstead, ping Sep 18 20:58:39 Good evening, Sep 18 20:58:52 Can somebody help me with following issue: Sep 18 20:58:52 http://lists.openembedded.org/pipermail/openembedded-core/2016-July/123886.html Sep 18 20:59:05 I would like to build extended SDK Sep 18 21:06:58 armpit: I'm may be a little slow to respond. WiFi is broken here. Sep 18 21:07:48 halstead, do the AB systems share sstates locations? Sep 18 21:09:47 if I build on yocto.io will the original one reuse the sstates? Sep 18 21:11:14 armpit they are separated right now. We may combine in the future. Which were you hoping for? Sep 18 21:13:24 original. I saw RP ran an pyro release build but I dont know if my pyro-next would be able to take advantage of his build. I built last on yocto.io but its busy Sep 18 21:13:53 I kick of a build on the original ab as it was idle Sep 18 21:14:57 armpit, so reuse across clusters would be helpful? Sep 18 21:15:35 * ulf` doesn't find steelhead at Costco all that expensive Sep 18 21:15:41 ww Sep 18 21:15:42 I think so if its possible Sep 18 21:16:36 something to talk about with others Sep 18 21:17:18 * armpit ahhh, refkit again Sep 18 21:17:44 armpit, l will make that possible sometime in October. Sep 18 21:17:59 cool Sep 18 21:18:17 Maybe somebody will know - is it possible to remove packages from building extensible SDK? Sep 18 21:18:31 Like for example remove custom kernel recipe? Sep 18 21:18:48 (Is it really needed to build applicatons)? Sep 18 21:25:46 armpit: just ignore refkit :( Sep 18 21:31:21 The problem is with extensible SDK creation Sep 18 21:31:55 the Linux-custom recipe with INITRAMFS creation enable is causing such problems: Sep 18 21:32:30 https://pastebin.com/5XTfivHJ Sep 18 21:43:53 Any yocto system is pretty heavily dependent on sstates integrity. Are there running any (continous?) regression testing regarding its validity, e.g. by comparing non-sstate'd build vs a sstate based build? Sep 18 21:44:49 QA in our company paid us a visit asking these questions about Yocto... Sep 18 21:45:14 sveinse we do internal testing related to that Sep 18 21:45:24 if you are concerned, you can turn off sstate and always build from source Sep 18 21:45:35 fray: how to do execute it? Sep 18 21:45:49 *argh, how do you execute it Sep 18 21:45:57 teting or disabling it? Sep 18 21:46:12 testing it. what is the methodology Sep 18 21:46:29 perform build (from source).. Sep 18 21:46:56 move to a different user, different path (set old build path as not accessable by the other use -- but it should exist) Sep 18 21:47:04 repeat building, using the sstate cache.. Sep 18 21:47:06 and run CI/product test showing equal performance as the sstated one? Sep 18 21:47:10 verify results of the build (deploy dir) Sep 18 21:47:28 performance comparisons use the build history and such Sep 18 21:47:47 yeah, it was the verification part I was wondering about Sep 18 21:48:17 I dont know if the file system footprint is equal enough to directly compare Sep 18 21:48:28 we compare the binaries themselves Sep 18 21:48:36 I suppose elf files will be different from different build times, right? Sep 18 21:48:50 yeah Sep 18 21:48:51 sstate-cache doesn't build.. it extracts and deploys Sep 18 21:48:59 so no actual changes --unless-- it rebuilds.. Sep 18 21:49:07 even if it does rebuild, you do an elf comparison.. Sep 18 21:49:22 the test is build, save, build from sstate, save, compare Sep 18 21:49:24 basically the parts of the text section should be compared, but things that are not loaded do not need to be compared Sep 18 21:49:29 fray: yeah, sure. sstate is being reused Sep 18 21:49:38 recipe-specific sysroots probably improved the situation quite a bit, too. Sep 18 21:49:44 aha, right, so you compare some elf segments? Sep 18 21:50:27 if the item has been built, we check the text section.. binary comparison with some interaction to look for timestamp changes Sep 18 21:50:40 if it was not built (uses sstate-cache) then we do a pure comparison Sep 18 21:50:50 great, cool. Sep 18 21:51:12 (we do this in the scope of our product testing.. if we find any issues, we send patches abck to the community...) Sep 18 21:51:30 should make selftest to something similar Sep 18 21:51:33 armpit: if builds die try again, there is an intermittent problem and I'd just leave refkit set as master (even then it can sometimes fail) Sep 18 21:51:35 I don't know if we're run these tests for 2.3/2.4 yet.. but I don't expect any regressions.. we ran it and it passed for 2.2 Sep 18 21:52:09 fray and rburton, thanks Sep 18 21:52:22 (our products are based on fall release.. so we generally test every other one) Sep 18 21:52:33 1.3, 1.5, 1.7, 2.0, 2.2 and now 2.4 Sep 18 21:52:52 Maybe somebody could help: Sep 18 21:52:53 https://pastebin.com/5XTfivHJ Sep 18 21:52:58 fray, so your product is yocto releases? Sep 18 21:53:18 We have had some customers who require sstate validation (signatures verification and such).. but this is outside the actual usage of it Sep 18 21:53:26 SDK_INHERIT_BLACKLIST_append = " kernel" doesn't help Sep 18 21:53:37 We do HW end-user products where the customer is oblivious to yocto Sep 18 21:54:17 Wind River Linux 5, 6, 7, 8, 9 and the upcoming Fall release are all YP based Sep 18 21:54:28 (WRL 1, 2, 3 and 4 lines were internal) Sep 18 21:54:29 lukma: did you delete sstate Sep 18 21:54:43 khem: Nope Sep 18 21:55:17 khem: Maybe this is better: SDK_LOCAL_CONF_BLACKLIST_append = " INITRAMFS_IMAGE" Sep 18 21:56:06 lukma: are you using default poky distro ? Sep 18 21:56:07 khem: Do you mean to delete the whole /sstate-cache ? Sep 18 21:56:14 yes, this is poky Sep 18 21:56:26 YPRR 2.3.1 Sep 18 21:56:46 yes ineffect you need to narrow it down using bitbake-diffsig tool and see which distro setting is causing it Sep 18 21:57:08 khem: http://lists.openembedded.org/pipermail/openembedded-core/2016-July/123886.html Sep 18 21:57:36 But I do want to build INITRAMFS for my meta-layer Sep 18 21:57:48 It is the part of my build Sep 18 21:58:48 (The question is if I need the linux-custom-kernel.bb in the extensible SDK ? ) Sep 18 21:59:39 linux-ramips:do_bundle_initramfs try it out with diffsigs and see whats causing signature change Sep 18 21:59:45 I think you do Sep 18 22:00:28 I'm stuck with a basehash error while doing parsing for initrd too, but I cannot figure out how to extract the sigdata to make it compareable with diffsigs. It does not generate any .sigdata files to compare. ...but this will have to wait until tomorrow. Sleep required Sep 18 22:01:36 I've learned that running bitbake --parse-only first before diving into actual builds fixes the errors Sep 18 22:02:22 hmmm Sep 18 22:02:42 seems a bit wierd Sep 18 22:02:58 does this mean that parse cache is corrupting Sep 18 22:04:14 yup it's wierd. Would help a lot if bitbake could actually tell me which vars have changed rather than just complaining about the hash being changed. Sep 18 22:05:55 khem: After removing sstate-cache -> 3940 ERROR messages shown Sep 18 22:06:53 aehs29, sgw: confirmed the linux-firmware change in mut pushes the genericx86 image size over 4GB Sep 18 22:07:37 imho, the biggest user flaw of bitbake. It is the single most costly activity for us with yocto. And I say this with the biggest respect, so no ranting, just trying telling that this is a pain point. Sep 18 22:08:15 sveinse: apply the sigbasedata bitbake patch Sep 18 22:08:18 thats your best bet Sep 18 22:08:57 kergoth: where can I find it? Sep 18 22:09:28 and does it apply to pyro? do you know? Sep 18 22:10:13 https://gist.github.com/kergoth/8b0c01b86d8ab4d9330527ba9c2bb8e2 or equivalent Sep 18 22:10:28 might not apply as is, dpeending on your branch, but should be trivial to adapt if needed Sep 18 22:10:31 not much to it Sep 18 22:10:54 yes, that one. We've been here before Sep 18 22:11:20 it remains the only viable method for diagnosing basehash mismatches, afaik Sep 18 22:11:27 RP: wow and bummer we are at 3.4Gish without it, I wonder what else changed in the linux-firmware, I have not fully looked at it. I am looking now Sep 18 22:12:28 kergoth: the last time I tried that one, the build died. On Krogoth. I had to modify it. But now we're attempting Pyro, so perhaps it'll work better. I'll test it once more. thanks Sep 18 22:12:38 khem: bitbake-diffsigs -t linux-yocto-custom do_bundle_initramfs Sep 18 22:12:38 ERROR: Only one matching sigdata file found for the specified task (linux-yocto-custom do_bundle_initramfs) Sep 18 22:12:52 khem: Is this the expected output Sep 18 22:16:12 hmm there should be atleast one more Sep 18 22:16:16 to compare to Sep 18 22:18:41 khem: I did: Sep 18 22:18:41 1. removed /sstate-cache directory Sep 18 22:19:06 2. run bitbake -c do_populate_sdk_ext core-image-XXX Sep 18 22:21:46 3. Summary: There was 1 WARNING message shown. Sep 18 22:21:46 Summary: There were 3940 ERROR messages shown, returning a non-zero exit code. Sep 18 22:22:02 4. bitbake-diffsigs -t linux-yocto-custom do_bundle_initramfs Sep 18 22:22:02 ERROR: Only one matching sigdata file found for the specified task (linux-yocto-custom do_bundle_initramfs) Sep 18 22:22:18 khem: Do I need to remove some other directories? Sep 18 22:22:55 also remove tmp dir Sep 18 23:03:24 yes, deleting just the sstate-cache is bad for building the eSDK Sep 18 23:36:21 RP: huh, apparently you can't include/require a bbappend. to share metadata between appends, a .inc is mandatory. that seems odd. bitbake says the bbappend isn't a bitbake file :) **** ENDING LOGGING AT Tue Sep 19 03:00:01 2017