**** BEGIN LOGGING AT Mon Nov 11 02:59:57 2019 Nov 11 05:24:58 New news from stackoverflow: Pillow installation error on Yocto core-base-image Nov 11 07:31:03 good morning Nov 11 08:25:26 New news from stackoverflow: Integrating GPU drivers to yocto generated Linux kernel || How can I verify sstate-mirror usage? Nov 11 09:45:52 Which is the best way of copying a (HUGE) bunch of precompiled files (some of them already exist in the current rootfs), scripts and configuration files (from a 3rd party new chip support sdk) into the rootfs? Nov 11 09:46:30 I've alredy tried the recipe way, however, Yocto fails trying to establish the dependencies and provides relations (I don't want Yocto to do this, I just want all the files to be copied into the rootfs no matter if their dependencies already exists there or not). Nov 11 09:48:43 I've also tried to add a tar with all the provided files and folders to the rootfs, and finally, unpack and isntall thorugh a ROOTFS_POSTPROCESS_COMMAND function. Nevertheless, this also fails due to rootfs write permissions... Nov 11 09:49:03 the dev manual contains an example that does exactly this: just take stuff and add it to the rootfs. Nov 11 09:49:33 https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#packaging-externally-produced-binaries Nov 11 09:53:52 letothe2nd: Ty. Indeed, I did inherit from bin_package but I got lots of QA errors. Will check the dev manual again anyway! Nov 11 09:54:52 BThere're lots of libs among those files. Nov 11 09:54:56 BTW* Nov 11 09:55:09 malanecora: if QA triggers, then chances are extremely high that you are doing something wrong, and just working around the checks by doing ugly postprocessing hacks will not solve those. Nov 11 10:01:46 letothe2nd: I'm sure I do...haha. I know that all the necessary components are allready properly installed, BTW. But the chip-manufacturer has provided the "sdk" (huh...) as a huge batch of files and directories as if they'd have copied and pasted some (not so) carefully picked folders of their own rootfs. Nov 11 10:02:47 That's why I was wondering if that could be easily done in Yocto, in a "copy and paste" way. Nov 11 10:03:31 you can of course just disable the checks Nov 11 10:06:26 Yep, I have disabled almost all the checks haha. It still keeps throwing "PROVIDES" errors due to the libs. Nov 11 10:07:01 I'll give it another shot Nov 11 10:25:35 malanecora: you will only get into more trouble that way... I would (and sadly need to) install every single pre-compiled binary in their own recipes and make all QA checks pass, including deciding which providers are correct for various libraries when poky open source conflicts with BSP binary blobs. Nov 11 10:27:10 mcfrisk: 1) every request that contains "all i need is to...", "i only want to..." or "i just have to make it work now..." is an outright lie 2) i tend to brain-ignore problems that are caused by such approaches :) Nov 11 10:29:46 mcfrisk: Ty, I'm afraid thats the way to go. Nov 11 10:33:16 I think the best way to work with BSP layers, is to first disable everything in them, and then enable needed recipes and bbappends one by one after review. Nov 11 10:38:00 mcfrisk: add beer + heavy metal. Nov 11 11:44:46 Hello all - anyone have any experience building custom kernels for Yocto? I'm trying to build one and cannot get some modules installed when building with Bitbake - they simply don't appear (no errors) Nov 11 11:45:40 I'm currently working with Rocko (sadly I cannot move away from this) - I've written a patch to enable the items I want, I know this patch is applying because _some_ of the modules I require are built, just not others Nov 11 11:52:39 Foxdie, have you double-checked the resulting kernel .config to make sure that the modules are enabled ? Are the module packages not created ? Nov 11 12:01:21 Foxdie: add .config as defconfig to SRC_URI in your custom recipe, or use KBUILD_DEFCONFIG when you have an in-tree configuration. Good luck! Nov 11 12:02:37 Sorry - got dragged away to a quick meeting Nov 11 12:03:06 @Foxdie: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb?h=rocko Nov 11 12:03:13 I wrote a patch that patches the defconfig that's inherited for my device (arch/arm/configs/apalis_imx6_defconfig) Nov 11 12:03:31 This applies some things and enables most of the stuff I need, just missing a couple of crypto ciphers Nov 11 12:04:24 I did check the build folder for the kernel, there's a defconfig in there that is missing my options, despite them being available if you look in the source tree Nov 11 12:05:03 Foxdie, you should check the generated .config in the kernel build tree Nov 11 12:06:19 i'd just check if the modules are 1) being packaged 2) being installed. Nov 11 12:06:31 those being the most common problems Nov 11 12:29:26 Foxdie: bitbake -c menuconfig virtual/kernel Nov 11 12:29:58 you do not modify anything in there, it's just to look if your configs are selected. Until you get what you want in there, you fiddle with the recipe Nov 11 12:30:32 then you can continue with letothe2nd's suggestion of checking whether the modules are built, and then packaged and then installed Nov 11 12:33:47 rburton, RP per my suggestion the critical path utility was rewritten in Python https://github.com/oesse/python-criticalpath Nov 11 12:34:21 with the intention of eventually submitting for inclusion into buildstats directly Nov 11 12:35:52 Thanks, checking now (again, 'walkovers' distracting me, does anyone else get that?) Nov 11 12:36:11 "Can you quickly just.." yeah there's never anything quick about it :D Nov 11 12:36:23 kanavin_: nice Nov 11 12:38:00 Foxdie: If I understand correctly what you mean by wlakovers, yes, everybody's receiving them. It's the role of your IRC client to ignore them Nov 11 12:39:26 Hehe Nov 11 12:39:38 Okay I have a good ol' menuconfig, checking now Nov 11 12:43:06 Okay running menuconfig against a _completely built_ image / directory tree, I can see my options are not present in there, including those I've patched in.. Nov 11 12:43:38 (and have confirmed working like /dev/crypto support, that's unticked, but it's working on my build) Nov 11 12:43:45 I am confused :) Nov 11 12:44:39 kanavin_: very cool :) Nov 11 12:45:00 Foxdie, maybe they depend on features not enabled, so they get disabled ? Nov 11 12:46:31 I suspect that's the case but I don't know how to enable them "properly", I scoured http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.6/plain/crypto/Kconfig and enabled all the dependencies of dependencies etc in my patch file but still doesn't work Nov 11 12:48:24 kanavin_: I'm confused :) What's the difference with pybootchartgui.py we already have? Nov 11 12:48:48 Foxdie: wait.. how did you create the defconfig? Nov 11 12:50:22 Foxdie: to create defconfigs, NEVER do it manually. You open menuconfnig or xconfig or whatever, you select manually the options you want Nov 11 12:50:45 then you save when exiting the tool. Then you run make savedefconfig Nov 11 12:51:24 you take the defconfig which is at the root of your Linux kernel repo and do something with it. If you want a patch for your defconfig, cp that defconfig over the one you're using, take the diff, make a patch and put it in your recipe Nov 11 12:53:38 How did I make it? The dirty way Nov 11 12:54:10 Checked out the specific commit of the Kernel source (Toradex Repo), modified it to suit, created a git diff patch and then included it with a bitbake recipe Nov 11 12:54:24 It works 99%, just won't do this one cipher Nov 11 12:54:56 Foxdie: don't modify defconfigs or .config manually. Never Nov 11 12:55:02 Foxdie, check the Kconfig and see what the cipher depends on ? Nov 11 12:55:17 use the tools made for creating such files Nov 11 12:57:08 Kroon: I did that yes, I walked the stack through each one and enabled them Nov 11 12:57:18 Foxdie, oh right Nov 11 12:57:20 Dependencies of dependencies etc Nov 11 12:58:04 qschulz: Yeah I hear you, it's an ugly way, I'm not sure _how_ to do it the proper way though when it appears the one that comes with this Bitbake build is already pre-done from the vendor Nov 11 12:58:25 If there's a less painful way to achieve this I'm all ears Nov 11 13:00:36 Foxdie: I explained, see above. TL;DR: make ; make menuconfig (save when exiting); make savedefconfig; Nov 11 13:03:14 qschulz: automatic critical path analysis vs a pretty chart i believe Nov 11 13:04:42 qschulz, I believe the boot chart will not show you the critical path, which is a list of items that contribute directly to overall build time (e.g. everything else has to wait until they get built) Nov 11 13:05:08 did gettext:configure appear in the critical path Nov 11 13:06:09 kanavin_: you can read it from the chart but it definitely doesn't give it to you directly :) Nov 11 13:07:15 Okay thanks qschulz / kroon / Chrusel - I'll battle on with what you've given me Nov 11 13:47:41 Foxdie: and if you're using bitbake directly, then bitbake -c menuconfig virtual/kernel; bitbake -c savedefconfig virtual/kernel; then look in the WORKDIR of your recipe for the defconfig and make a diff between that one and the vendor one. Or use make commands I gave earlier directly within the vendor kernel repo Nov 11 13:47:46 good luck Nov 11 13:48:36 Thanks bud :) I'm just looking now - I may have to patch in support for other things admittedly, but I will use menuconfig in future to make a defconfig Nov 11 13:51:10 Foxdie: one thing at a time :) Nov 11 14:16:25 Spandau Ballet Nov 11 14:16:32 Erk, wrong window >.< Nov 11 14:19:42 It is possible to test a recipe for used `inherit`'s? I want to test if a package has got a `inherit` of a class in my collection. I know I can just test of existing of a variable which is uniform to this class. But maybe it exists a altermative way or a solution. Nov 11 14:20:49 Having a peculiar issue, probably not Yocto specific, when I `make menuconfig` I can search for my patched-in cipher (CRYPTO_USER_API_SKCIPHER) in menuconfig and see it's location, but it's not actually visible - can also see it enabled in .config Nov 11 14:21:24 Foxdie: then some prerequisite is not met Nov 11 14:21:45 Foxdie: have a good look at the depends on section of the menuconfig search Nov 11 14:21:53 I thought that but it's "=y" in my generated .config output file Nov 11 14:22:25 Bah, forgot this is IRC, can't paste in a screenshot, derp Nov 11 14:22:55 Foxdie: not the item itself, but what it depends on. Nov 11 14:23:05 Foxdie: it's okay, some Kconfig actually can "select" other Kconfig Nov 11 14:23:10 in which case the defconfig omits them Nov 11 14:23:14 Ah! Nov 11 14:23:17 That would make sense yes Nov 11 14:23:22 More hunting required Nov 11 14:23:23 because enabling one Kconfig option means the other is enabled Nov 11 14:23:31 Not if it's inherited via defconfig I guess Nov 11 14:23:33 save the defconfig to the right place Nov 11 14:23:41 and check with menuconfig if your option is still there Nov 11 14:23:45 I'm gonna owe you a beer at this rate Nov 11 14:24:19 .config is giving all non default values of Kconfig parameters Nov 11 14:24:49 defconfig is giving you the minimal file which can reconstruct the .config. So anything that is "select"'ed by another Kconfig is omitted Nov 11 14:25:00 that is why defconfig is so much smaller in size than a .config Nov 11 14:25:55 I don't know *exactly* how the defconfig is created but I don't think I'm too far from the actual thing Nov 11 14:26:03 this all sounds very much like a poster example for why one should use menuconfig instead of randomly patching the .config. its just waaaaay to easy to get the dependencies wrong and all. Nov 11 14:26:31 New news from stackoverflow: unable to build valgrind for armv7 in yocto Nov 11 14:27:22 You could be right :) Nov 11 14:28:53 letothe2nd: same for defconfig, sometimes there are depends on "!FOO" and another one on depends on "FOO" and you select both Kconfig options. Nov 11 14:29:26 that's also why I don't like config fragments as well even though I can see the benefits, it introduces uncertainty in the resulting config Nov 11 14:29:29 i always nail my defconfigs down, by menuconfig. and without savedefconfig :) Nov 11 14:30:06 Or Nov 11 14:30:50 I could be an idiot and realise it's there buried in the text under an unassuming, generic line item :) Nov 11 14:35:10 letothe2nd: I don't understand why people find it so fun to put uncertainty in things which take litterally one command and not even a second to do correctly but I might be too rigid. What do you find so appealing in doing this by hand? Nov 11 14:36:06 Some people live for the thrill or challenge of doing it differently and hopefully getting it right? Nov 11 14:36:48 qschulz: it depends (TM) Nov 11 14:37:13 qschulz: i can certainly see some of the use cases, but they're not the ones that I have Nov 11 14:39:52 letothe2nd: I don't know any, please shed some light on those so that I can understand :) Nov 11 14:40:07 rburton_, rpm upstream is working on sqlite support Nov 11 14:40:36 I guess the berkeley db situation caught up to them Nov 11 14:40:53 qschulz: think kernel testing :) Nov 11 14:43:00 letothe2nd: I worked on upstream kernel for 3 years with a team of 10 people doing the same. None where modifying defconfigs by hand :) Nov 11 14:43:10 were* Nov 11 14:43:18 was? Nov 11 14:43:22 English is hard man Nov 11 14:44:40 qschulz: nah i'm not talking by hand. iirc the kernel-dev-manual has quite some information on how to properly prepare the config fragments etc. Nov 11 14:45:05 "were" is perfectly fine :) Nov 11 14:45:34 qschulz: and, think the topic of a bsp. it could enable audio drivers only if the corresponding distro feature is set, for example Nov 11 14:46:39 qschulz: so you'd have the core config, and the other stuff only gets added if needed. save on compilation time and space. Nov 11 14:46:52 letothe2nd: ah the fragments you meant. I definitely see the usecases. I was talking about editing by hand :) Nov 11 14:47:18 (I even think I could migrate us to fragments) Nov 11 14:47:20 qschulz: ah ok, then i misunderstood. no. i also don't know of a usecase for doing it by hand. Nov 11 14:48:06 I'd need to check if conflicting fragments are actually applied blindly or if it fails or if it prints a warning Nov 11 14:49:01 but if YP silently applies the conflicting fragments then it's not great IMHO (but I repeat, I understand how useful that can be :) ) Nov 11 14:49:04 to be tested :) Nov 11 15:06:56 kanavin_: they were looking at a different db implementation previously, glad to hear they're settling on something though Nov 11 15:07:30 silviof: bb.data.inherits_class Nov 11 15:18:29 kanavin_: tried the tool. said that gstreamer-vaapi was on the critical path, which i'm not convinced about Nov 11 15:18:41 mesa, python3, etc, yes Nov 11 15:24:23 nrossi: I have subTest mostly reporting working now. If you have a chance to look it over: http://lists.openembedded.org/pipermail/openembedded-core/2019-November/288964.html Nov 11 15:24:40 nrossi: It still doesn't work with "-j1", but I'm not sure why Nov 11 15:29:34 Thanks rburton_ This works. ❤️ Nov 11 15:32:46 is it time to change the default x86 image away from hddimg? Nov 11 15:37:50 rburton_, 5 1/4 floppy then ? Nov 11 15:38:20 * zeddii nearly replies on a thread about CVE backports and LTS .. and then decides that a kill file would be more useful. Nov 11 15:43:52 at some point I will just post 80 CVE patches for sumo... Nov 11 15:44:02 please do :) Nov 11 15:44:32 if everyone submits the patches they have then there'll be less duplication of effort and more fixes integrated Nov 11 15:45:01 that wasn't my kill file implication, but sure. Nov 11 15:45:55 rburton_, why gstreamer-vaapi makes you suspicious? Nov 11 15:46:22 kanavin_: because the only thing that depends on it is the image Nov 11 15:46:57 right, but it's mostlike built just prior to the image, and so is on the critical path Nov 11 15:47:09 along with a load of other things Nov 11 15:47:38 rburton_, it depends on things like mesa, plugins-bad, etc., so it comes last Nov 11 15:48:01 those other things complete quicker Nov 11 15:56:08 kanavin_: can i file a bug report for that tool? build hangs for minute waiting for omvf to build with literally nothing else happening, isn't in the critical path Nov 11 15:56:55 rburton_, sure, absolutely. I can ping the developer if needed. Nov 11 16:00:37 mcfrisk, +1 on the patches.. looks like I need to rebase my community branch with what is in -next Nov 11 16:01:05 * armpit wonders what the purpose of -next really is??? Nov 11 16:23:10 Four weeks ago was was handed a dev kit and asked to remember years old Yocto knowledge. Today I flashed the board with a custom, Yocto-built image and it's working great. Thanks to everyone here who took the time to answer my questions! Nov 11 16:35:53 Of course, I have another question. Is there anything I can add to the rootfs that would tie it to the image that produced it? For example, my image is timestamped with 20191111153110. I would be helpful to have that number somewhere in the rootfs so I can connect the two. Nov 11 16:38:13 JPEW: I saw the patch I think it looks fine, the major difference between non-"-j" and "-j" is that all results are passed through some base test results classes in subunit and testtools, looking at them now it looks like they themselves do not have subTest support Nov 11 16:38:14 you can get a complete build manifest written into the image if you want Nov 11 16:38:30 d_thomas: see image-buildinfo.bbclass Nov 11 16:39:02 d_thomas: If you want more ancilliary data, you can add extra variables to IMAGE_BUILDINFO_VARS in your distro.conf Nov 11 16:39:45 rburton_, JPEW, thank you, I'll check both of those out. Thanks for the starting point Nov 11 16:43:42 huh, https://github.com/apenwarr/git-subtrac is very interesting Nov 11 16:43:59 another approach to the whole submodules vs subtree vs repo etc Nov 11 16:45:59 uses submodules, but the submodules end up pointing at the parent repo, and the parent repo is adjusted to ensure the submodule commits are available. it makes a submodule-based super-project self-contained. You can cd into a submodule, make a change, commit it, cd to the parent, git subtrac update; check in the submodule change, and push master and master.trac, your submodule commit is available even though you never pushed the submodule anywhere, so Nov 11 16:45:59 you could stage changes to submodules locally in the superproject Nov 11 16:47:03 much like subtree, it's self contained, but unlike subtree it's easier to get changes to the submodules back out for upstream submission again, since they exist as independent submodule commits Nov 11 16:47:07 Ah, from the author of git-subtree too Nov 11 16:47:09 yeah Nov 11 16:47:13 pretty interesting approach Nov 11 16:47:49 the readme is *not* as clear as it could be, and there's not squad for workflow examples of how to make local changes, how to update the submodules from upstream later, etc Nov 11 16:47:55 but once you play with it it becomes pretty clear Nov 11 16:48:03 squat, not squad Nov 11 16:48:54 I ahve reasonable success with submodules Nov 11 16:48:55 then you still have to ensure that you push the corresponding .trac branch for each regular branch to the superproject remote, but i imagine there'd be ways to script around that issue Nov 11 16:49:17 Worth a look. I was thinking about writing up a pros/cons of subtrees/submodules/combo-layer/repo on the Wiki Nov 11 16:50:07 i'm sure a lot of folks would appreciate that. some days i wish we adopted something official for oe even if a lot of companies would have to use something else due to differing requirements Nov 11 16:50:36 oe-lite used to have an 'oe clone ' that'd pull down the parent and the individual layers and everything in one go, official for that project Nov 11 16:50:51 sometimes i love our flexibility, sometimes i hate it, sometimes both :) Nov 11 16:50:58 Ya. I have direct experience with subtrees & submodules, not so much the other 2 Nov 11 16:51:32 https://www.openembedded.org/wiki/MultipleRepositoryMethods Nov 11 16:52:19 Please please help with th ewiki Nov 11 16:52:35 We aren't stuck with the current fronts page look, just need people to help out Nov 11 17:09:21 JPEW: unfortunately it looks like both subunit and testtools do not support subTest. A solution that may work for now is maybe https://gist.github.com/nathanrossi/2b7d54ed5c149019e26eb0badc0375db Nov 11 17:09:24 Added a section on subtrees. Not complete, but a start Nov 11 17:10:54 nrossi: Ah, ok. I'll try that. Thanks Nov 11 17:11:00 I suspect also need submodule update Nov 11 17:11:03 I amy look at that Nov 11 17:11:15 and we need better linkage on site so people can find thing Nov 11 17:11:33 JPEW: wondering if it is worth reworking the selftest codebase to use a single process and manage the bitbake instances as objects instead of assuming the current process is configured, maybe RP has some input on this? Nov 11 17:12:31 nrossi: TBH, I didn't spend too long trying to figure out how it works, so I'm not sure :) Nov 11 17:27:05 New news from stackoverflow: U-boot environment is not the same as Linux "fw_printenv" Nov 11 17:30:08 JPEW: just testing more, that change i linked doesn't quite work... i am not sure there is a way to solve this easily :|. I will have a look more into it tomorrow and let you know if I come up with a solution Nov 11 18:09:23 nrossi: Thanks Nov 11 21:17:47 I'd like to move my modifications to local.conf (adding image-buildinfo and buildhistory) to a *.conf in my layer. Is there a best practice for doing that? Do I extend the distro or something else? Nov 11 21:19:11 you can create a standalone .conf that you require the user include from local.conf when the layer is included, to enable it. you could make the configuration based on a distro feature or similar and have local.conf set that, or you can create your own distro layer Nov 11 21:19:40 in this particular case you probably want your own distro, either copied from the existing or including the existing Nov 11 21:19:56 (don't forget to add to DISTROOVERRIDES if you do the latter to ensure both the original distro overrides and your own get applied) Nov 11 21:25:04 I'm trying to append the distro's conf in a sense. Could I include it from the layer.conf file or does the user have to include it from local.conf? Nov 11 21:43:39 nrossi: wouldn't that slow it down hugely? Nov 11 22:56:35 JPEW: did you see https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/476 ? Nov 11 23:02:38 RP: a regression see https://bugzilla.yoctoproject.org/show_bug.cgi?id=13252#c1 Nov 11 23:02:39 Bug 13252: enhancement, Medium+, 3.1 M1, changqing.li, IN PROGRESS REVIEW , Error report Web: enhance to support get all configuration in the local.conf Nov 11 23:06:30 khem: hmm, right. Need to escape the supplied data? Nov 11 23:07:13 escapes dont help Nov 11 23:07:27 this is json parser getting confused with < and > Nov 11 23:07:52 I tried BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj raj.khem@gmail.com" Nov 11 23:07:55 and that works Nov 11 23:08:01 but BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj \" Nov 11 23:08:10 throws different errors Nov 11 23:36:21 khem: there should be some way of escaping the json, not the actual data in the variables Nov 11 23:47:24 RP:I am sure there is some clever way Nov 11 23:47:32 RP: btw. intresting thread https://lists.llvm.org/pipermail/llvm-dev/2019-November/136579.html Nov 11 23:47:42 llvm community is moving to github Nov 11 23:49:19 khem: multiple review methods sounds like a potential disaster to me unless you work on a dictator model :/ Nov 11 23:50:09 RP: llvm community has multiple committers so it will be interesting, I am observing it closely, as I have to deal with it anyway Nov 11 23:51:06 and its a big contributor community (100s), so if its successful it will be a good success story for other projects Nov 11 23:52:00 khem: it will be interesting... Nov 11 23:52:05 * RP -> Zzzz Nov 11 23:52:10 gn **** ENDING LOGGING AT Tue Nov 12 02:59:57 2019