**** BEGIN LOGGING AT Fri Nov 08 02:59:57 2019 Nov 08 05:44:57 New news from stackoverflow: Writing device driver for embedded boards Nov 08 06:45:05 New news from stackoverflow: Data transfer between microzed and PC via tftp Nov 08 07:14:58 ndec: can you maybe put the announce for tuesday on twitter, or poke someone who can? would be good as andreea probably can't manage to until late monday. Nov 08 07:15:09 New news from stackoverflow: Setting up Yocto on my Ubuntu (Ubuntu 18.04.3 LTS/bionic) with error "ImportError: No module named '_sqlite3'" Nov 08 07:31:01 Hi experts! We can use task[noexec] = "1" do disable one task, but can we disable one _append() task? For example, there are many do_install_append() for building kernel. But I want to disable the one in kernel-devicetree.bbclass. Could anyone give me some hints? Thanks! Nov 08 08:07:27 zhangzhi: one hack'ish way I've seen is to have a custom class with default task implementation which ends with "exit 0". that disables all recipe side appends though it's not nice at all... Nov 08 08:15:24 mcfrisk: Thanks! But I do want other \_append() methods. So it looks no elegant way to achieve that... I plans to undo what the \_append() has done in a postfuncs ... Nov 08 08:19:28 kergoth: no objection Nov 08 08:27:50 zhangzhi: IMO best is to just modify the recipe which does the _append. if it's 3rd party layer, the change can be merged or rebased after updates Nov 08 08:30:04 <__angelo> should yocto build inform of duplicate packages added over image recipes ? Nov 08 08:30:36 __angelo: like, what? Nov 08 08:34:25 <__angelo> hiu letothe2nd . i mean, if i add a packagelist, but some packages was already added in included/inherited stuff, does yocto warns about ? (just asking) Nov 08 08:34:37 nope Nov 08 08:34:41 <__angelo> ok. Nov 08 08:35:06 reasoning: many things can depend on the sam package or rdepend on it. Nov 08 08:35:17 <__angelo> on a big package list ia have to add, i am supposing there is no sense to check package by package if it's already built, i just add the list, correct ? Nov 08 08:35:31 mcfrisk: Thanks! Nov 08 08:35:41 __angelo: what is it that you *ACTUALLY* want to archieve Nov 08 08:38:07 <__angelo> letothe2nd, i have a bsp with inheritances on a base common OS recipe. Adding a layer on it for a specific product, that inherit from same OS. For this product only, i have a quite big list of packages to be added. Now, should i check what package is already in the buildlist ? I would just add in the upper recipe the package list reuired. Nov 08 08:39:19 __angelo: if you have something that requires another thing, just state it explicitly where the require happens. thats the correct way. implicitly relying on something to be already around will lead to breakage in the long term Nov 08 08:39:59 <__angelo> ok. But i mean, does it have sense to check for duplicated packages ? Nov 08 08:41:49 nope. the exact opposite, its confuusing and even dangerous Nov 08 08:43:32 <__angelo> letothe2nd, many thanks Nov 08 09:00:35 <__angelo> getting "nothing PROVIDES python-croniter" but .bb is there Nov 08 09:01:59 did you check if the layer where the bb is is parsed? is the python-croniter recipe in a path that is parsed in the layer? can you share the python-croniter recipe? Nov 08 09:02:31 <__angelo> qschulz, ok, i added the .bb, so it's certainly my fault Nov 08 09:02:41 <__angelo> thanks, checking why it's not parsed Nov 08 09:02:46 where did you add it? Nov 08 09:06:06 <__angelo> in the upper layer, same of my image. But there something strange. I am on thud, and package should be there also in the original place, but seems not Nov 08 09:09:09 __angelo: leaving out parts of the directory hierarchy breaks the recipe matching regexp, so thats not a good idea. keep stuff at the same level. and: did you check that the recipe really provides that package? some recipes have dirty tricks there. Nov 08 09:15:44 __angelo: for the recipe matching regexp look for BBFILES in your conf/layer.conf, it's by default ${LAYERDIR}/recipes-*/*/*.bb but can be set to something else (and bad BSP do it) Nov 08 09:18:12 yeah. and the second '*' is important :) Nov 08 09:21:08 <__angelo> mm in the current layer there the recipes has been added i have BBFILES ?= "" Nov 08 09:24:30 __angelo: for the "recipe really provides that package" look for a PROVIDES line in your recipe. But AFAICT, even if you do a PROVIDES = "foo" the PN of your recipe is still in there. Nov 08 09:24:40 (grain of salt as usual) Nov 08 09:25:05 https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-PROVIDES Nov 08 09:25:59 <__angelo> qschulz, thanks checking Nov 08 09:27:44 __angelo: fix your BBFILES first :) Nov 08 09:28:09 <__angelo> ok so i set to = "${LAYERDIR}/recipes-*/*/*.b" Nov 08 09:28:48 <__angelo> (final bb) Nov 08 09:45:56 <__angelo> actually nothing solves the issue. bitbake finds the image recipe on same layer, but continues to say "ERROR: Nothing RPROVIDES 'python-suds-jurko' " Nov 08 09:46:13 <__angelo> uhm, now is RPROVIDE btw Nov 08 09:50:07 Gaaah... This java problem is driving me insane -_- Nov 08 09:53:47 __angelo: different error indeed :) Nov 08 09:54:38 __angelo: https://layers.openembedded.org/layerindex/recipe/45323/ Nov 08 09:54:48 you're missing that layer/recipe Nov 08 09:55:10 <__angelo> qschulz, btw, can confirm recipe (bb) in current layer are not parsed, just added a "pippo.db" to test this Nov 08 09:55:18 <__angelo> (pippo.bb) Nov 08 09:56:22 <__angelo> i have python-suds-jurko_0.6.bb and get it from http://git.yoctoproject.org/cgit/cgit.cgi/meta-cloud-services/tree/meta-openstack/recipes-devtools/python/python-suds-jurko_0.6.bb?h=thud Nov 08 09:58:55 <__angelo> oooh maybe i found the issue Nov 08 10:00:10 pray tell Nov 08 10:00:27 <__angelo> solved Nov 08 10:00:45 <__angelo> sorry to ask you so basic question, you have a beer paid if you are on fosdem :) Nov 08 10:01:06 <__angelo> issue was on Nov 08 10:01:07 <__angelo> BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ Nov 08 10:01:07 <__angelo> ${LAYERDIR}/recipes-*/*/*.bbappend" Nov 08 10:01:25 <__angelo> but my recipes was in recipes-*/here Nov 08 10:01:53 09:09 < letothe2nd> __angelo: leaving out parts of the directory hierarchy breaks the recipe matching regexp, Nov 08 10:01:59 i told you literally an hour ago Nov 08 10:03:29 * qschulz books a plane ticket for fosdem Nov 08 10:03:49 n.pc Nov 08 10:03:50 <__angelo> yeah. Sorry but i am still quite new to yocto. i was mainly looking BBFILES in the wrong place, bblayers.conf Nov 08 10:04:08 __angelo: gave you the path as well :) Nov 08 10:04:26 It's fine, you have to check a lot at the beginning :) Nov 08 10:04:32 __angelo: well it was your wasted hour, not mine :) Nov 08 10:04:47 <__angelo> well, also some of your minutes, sry. Nov 08 10:05:03 <__angelo> thanks for the support, really Nov 08 10:05:20 :-) Nov 08 10:05:25 __angelo: our pleasure Nov 08 10:05:49 <__angelo> i believe this is really newby error, an expert would not put recipes there Nov 08 10:13:37 letothe2nd: sure! Nov 08 10:14:48 ndec: thanks! Nov 08 10:17:12 Has anyone tried to get meta-java to work with thud? Nov 08 10:18:47 wertigon, yes, thud, but not warrior/zeus/master Nov 08 10:19:25 wertigon, by that I mean openjre8 is broken for me in warrior/zeus/master Nov 08 10:23:17 kroon: I get a wierd compile error if I try to build for the thud branch Nov 08 10:24:32 wertigon, which host are you on ? Nov 08 10:25:27 wertigon, I'm on fedora 30, and I need some changes from master-next for it to build Nov 08 10:27:06 kroon, ubuntu 18.04 Nov 08 10:27:36 Trying to compile yields "make: No Rule to make target 'patch-fsg'. Stop." Nov 08 10:28:31 wertigon, hmm, never seen that error before. sure that is the first error encountered ? Nov 08 10:28:48 openjre-8 is the package I build, it gets stuck on the icedtea7-native Nov 08 10:29:38 thats the problematic one Nov 08 10:31:02 i'd doublecheck check if your configure step is failing earlier Nov 08 10:31:56 DEBUG: Executing shell function do_configure Nov 08 10:32:05 NOTE: Nothing to configure Nov 08 10:35:31 Could I force a reconfigure with bitbake? Nov 08 10:36:19 wertigon, you can try: bitbake -c cleansstate icedtea7-native && bitbake icedtea7-native Nov 08 10:36:37 no dont do that! Nov 08 10:36:44 bitbake -C unpack Nov 08 10:36:47 *much* faster Nov 08 10:37:16 -C is 'ensure this task is rerun and do a build' Nov 08 10:37:24 so it forces unpack to run, so configure has to run Nov 08 10:37:47 you force unpack instead of configure to ensure that you get a clean tree and you're not reconfiguring, because some software is stupid Nov 08 10:40:08 rburton, nice, didn't know that trick Nov 08 10:40:24 cleansstate has to go and delete *all* sstate for the recipe Nov 08 10:40:37 if you've a terrabyte of sstate that can literally take minutes Nov 08 10:42:46 Ok, baking now Nov 08 10:44:19 configure fails with "automake not found", interesting. Nov 08 10:46:21 after apt install automake still same problem. -_ Nov 08 10:49:48 Doing a cleansstate yields that configure fails due to no xorg logs. Seeing as the board has no xorg to speak of, this is correct, but should it not be possible to force no x11 then? Nov 08 10:50:01 Sorry, no xorg headers I mean Nov 08 10:50:04 rburton: but to get a clean build afterwards (no warnings) you anyway need to cleansstate right? (or is there another way?) Nov 08 10:50:09 wertigon, that one I know of Nov 08 10:51:25 wertigon, you need to install the xorg headers on your ubuntu. the target java can be configured without X support, but there is no support in the recipes for building the native one without them IIRC Nov 08 10:52:26 kroon: Ok, I shall attempt this Nov 08 10:53:05 Hoping for this to work now :) Nov 08 11:06:12 qschulz: i think just a usual bitbake will do the trik Nov 08 11:09:16 Hello! not sure if this is the right forum for these types of questions but any help is appreciated :) https://pastebin.com/yRzzB3SC Nov 08 11:10:16 lion_heart: please ask your question directly here :) Nov 08 11:11:31 qschulz: Ok, did not want to spam to much Nov 08 11:12:01 Yesterday I was advised to upgrade my Yocto to the latest version, I have some questions about how to even start such an upgrade. Nov 08 11:12:05 lion_heart: if you can't explain the outline of your problem in two lines or less, chances are that you have not yet understood the problem fully anyways :) Nov 08 11:12:30 letothe2nd: that is correct Nov 08 11:13:51 also, It is more of a general question than a build problem, which requires some background info imo Nov 08 11:14:19 but I can come back with more specific questions later, thanks anyway! Nov 08 11:14:36 well if the question is "how do i upgrade my release" then its rather simple. switch the branches of all layers accordingly, rebuild Nov 08 11:14:55 additionally, revisit the migration guide in the dev-manual Nov 08 11:58:14 is there a way to list all postinst scripts that have to be run on first boot? Nov 08 11:58:24 as opposed to those that can be run during rootfs generation Nov 08 11:59:22 (context: my target is missing /etc/*-postinsts and i'm trying to find out if that's normal; the package manager is opkg; run-postinsts is installed) Nov 08 12:09:04 milloni: i'd say by listing the contents of /etc/*-postinsts Nov 08 12:09:09 if there is nothing in there, nothing to be done Nov 08 12:09:42 ok, thanks Nov 08 12:28:18 I'm building Krogoth eSDK, and I'm stuck with uninative... the build seemed to produce it's own uninative archive, but it tries to look it up on the Yocto project site... and it fails due to sha256sum mismatch... 1) Can't I build it with a standard uninative somehow? 2) Where do I put the archive with the least effort so that the eSDK install doesn't fail? Nov 08 12:28:35 lion_heart: 1) distro is not THAT important to start with, so focus on something else (but keep in mind the DISTRO_FEATURES bit, those may be important (enable wifi, pick systemd over sysv, etc..)) Nov 08 12:32:24 2) yes it's a good thing if you can make it work with more upstream u-boot/kernel (you should also be able to use actual upstream version from openembedded-core or poky for this board). Try with the ones from meta-freescale if you prefer to have something that is more or less a BSP variant Nov 08 12:33:31 if you can build and test manually before using Yocto, it's best. That way if it does not work, you know the issue is in Yocto and you don't need to guess if it comes from the sources or from Yocto. Nov 08 12:34:27 lion_heart: however, I don't see where you find the 4.9.67 kernel? Nov 08 12:35:10 (but honestly, just try to compile with this layer and the correct machine and see if that's a good start for you before fiddling too much) Nov 08 12:37:14 qschulz: Thanks a lot!!. I have been looking att linux-fslc and it looks that 4.1.2x is still the latest commit so i guess I should focus on adding my custom kernel to Yocto insted of upgrading Nov 08 12:38:07 bitbake -c menuconfig virtual/kernel Nov 08 12:38:13 0: linux-fslc-imx-4.9-1.0.x+gitAUTOINC+953c6e30c9-r0 do_menuconfig Nov 08 12:39:35 lion_heart: https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-kernel/linux <-- fsl-imx kernel is 4.14.98 Nov 08 12:39:52 i mean, linux-imx. can't you use that? Nov 08 12:40:26 if you've been given something that is *ancient* i'd do a port by basically starting from scratch with meta-freescale and bring your bits in piece by piee Nov 08 12:42:00 Yea this is what I'm slowly realizing Nov 08 12:52:49 <__angelo> :( now getting a compile error on qdeclarativeplaylist.cpp Nov 08 12:53:18 <__angelo> | arm-fslc-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus) Nov 08 12:54:19 lion_heart: when cloning meta layers, don't forget to checkout the correct branch, I'm still confused where you get those kernel versions :) Nov 08 12:56:25 qschulz: I'm on branch Zeus on poky and meta-freescale Nov 08 12:57:26 with MACHINE ??= "imx6qdlsabresd" Nov 08 13:03:33 <__angelo> this is the error, in case someone wants to look in: https://pastebin.com/pNJFHvBw Nov 08 13:15:56 <__angelo> looks like Qt stuff gives error due to parallel build, but not sure Nov 08 13:17:58 internal compiler error is never a good look but never discount the possibility that its saying your RAM is knackered Nov 08 13:47:29 I use a lot of MACHINEs from various BSP meta layers: How can I customize each of them without spread changes (i.e. _append_MACHINE) across all recipes files (*.bb and *.bbappend)? Do I have to define a new MACHINE con file (e.g. beaglebone vs beaglebone-yocto)? Nov 08 13:49:19 Moreover I wanna make a recipe for a Nginx module. The nginx modules doesn't provide any build system because they are built by the main build system in the nginx sources. How can I proceed? Could I use the PACKAGECONFIG[modulename] directive (even it isn't really config)? It is possibile request the nginx sources by a nginx modue recipe and build Nov 08 13:49:19 both toghether replacing old nginx binary? Nov 08 13:49:50 alessioigor51: so how are you meant to build it Nov 08 13:52:23 rburton: I would integrate the module into the main nginx recipe. Nov 08 13:52:47 i mean, if you were not using yocto Nov 08 13:52:59 you're meant to drop the files directly into the nginx source tree? Nov 08 13:54:42 docs suggest yes, so i'd suggest a bbappend to add the sources and a PACKAGECONFIG that you can toggle Nov 08 13:55:28 rburton: ok thanks Nov 08 13:55:45 thats a bit ugly but if thats how it works, thats how it works Nov 08 13:55:54 you'd think it would expose headers and stuff Nov 08 13:56:45 rburton: Thanks again Nov 08 13:57:20 rburton: Do you have any tips for the other my question, please? Nov 08 13:57:33 ping alessioigor Nov 08 13:58:18 <__angelo> rburton, thanks, well seems real error may derive from tst_qaudiodecoderbackend.cpp:184: undefined reference to `.LC69' Nov 08 13:58:40 <__angelo> i added several qt packages, but seems there may be some version mismatch Nov 08 14:00:09 icedtea7-native seems to be building Nov 08 14:00:31 Can I go home with this feature implemented? :D Nov 08 14:05:49 rburton, kroon; thank you for the support on Java, going strong after 632s :D Nov 08 14:13:50 Yay! Java done! :D Nov 08 14:19:32 __angelo, how much RAM is available for the build? Nov 08 14:22:55 <__angelo> luneff, can check but pc is quite powerful, even if i am on chroot Nov 08 14:23:14 <__angelo> luneff, btw, the issue starts from unresolved externals as Nov 08 14:24:00 it may start with anything, but "internal compiler error: Killed" for my experience is 90%+ RAM issues, too much stuff is compiled at once Nov 08 14:25:25 if that's the case, BB_NUMBER_THREADS=1 could help Nov 08 14:29:13 <__angelo> luneff, thanks. At each retry i get a very long error log, multiple errors, due to parallel builds. First interesting error is an unresolved external on linking, so like a library missing, but maybe is missing due to other fails. Nov 08 14:29:24 <__angelo> luneff, trying your suggestion Nov 08 14:34:50 <__angelo> now i just get again unresolved external on qtmultimedia Nov 08 14:35:04 <__angelo> not internal compiler error anymore Nov 08 14:35:41 <__angelo> ram free seems > 5G so shouldn't be the issue Nov 08 14:36:11 JAVA COMPILES HALELUJAH! *Backflips, cartwheels and runs naked through the woods* Nov 08 15:04:06 nrossi: Are you around? Nov 08 15:17:24 JPEW: I am now Nov 08 15:19:36 nrossi: The toolchain tests appear to have broken the reporting for the reproduible build tests in testresults, and I can't quite figure out why Nov 08 15:20:08 nrossi: that is, it broke the reporting in testresults.json Nov 08 15:21:35 JPEW: these are the tests in oe-selftest correct? Nov 08 15:21:39 Correct Nov 08 15:21:59 The status just shows up as unknown and none of the extraresults are present: https://pastebin.com/JiqwJxGq Nov 08 15:23:11 nrossi: It also show up as UNKNOWN status when running: RESULTS - reproducible.ReproducibleTests.test_reproducible_builds: UNKNOWN (21970.48s) Nov 08 15:24:13 JPEW: have you been running the tests locally without issue (with selftest -j 1 or equiv) and its just the autobuilder that is causes problems? Nov 08 15:25:07 nrossi: This is a local run. I didn't use -j1, but I'm only running that one test using the cmd line filter. Nov 08 15:25:59 `oe-selftest -r reproducible` Nov 08 15:27:18 JPEW: ok i think i see the bug... surprised someone had not seen it before release. Nov 08 15:28:00 JPEW: http://git.openembedded.org/openembedded-core/commit/meta/lib/oeqa/selftest/cases/reproducible.py?id=6a1b0c2003a0b4a1983f9494440e6ea02dc25585 Nov 08 15:28:10 note the "extrasresults" instead of "extraresults" Nov 08 15:29:48 at least i was consistent.... :) Nov 08 15:38:16 huh, that's cool, i didn't know there was a way to render a graphviz graph at a terminal. obvious limitations, but.. https://gist.github.com/kergoth/c219bfe62f84082faae3efd67c99a503 Nov 08 15:46:07 nrossi: I fixed that and it still fails :( Nov 08 15:52:37 I'm currently migrating a build system from 2.4 to the latest 2.7 (Warrior) release and while many of the changes have been straightforward to address, I've hit one that I cannot work out. It's occurring in the do_rootfs steps. I've traced the issue to this bit of code in package_manager.py Nov 08 15:52:56 class OpkgIndexer(Indexer): def write_index(self): arch_vars = ["ALL_MULTILIB_PACKAGE_ARCHS", "SDK_PACKAGE_ARCHS", "MULTILIB_ARCHS"] opkg_index_cmd = bb.utils.which(os.getenv('PATH'), "opkg-make-index") Nov 08 15:53:28 for reasons I cannot workout it appears that the opkg-make-index utility is not being installed correctly in the recipe-sysroot-native directory Nov 08 15:54:01 and as such, the above listed opkg_make_index command is not being populated causing fatal errors during build Nov 08 15:55:37 I've not tracked down anything in the changelogs for poky or opkg-utils or opkg in general that would cause only _some_ of the opkg-utils to be installed Nov 08 15:56:04 a listing of the recipe-sysroot-native path looks as follows: Nov 08 15:56:05 initramfs-standard/1.0-r0/recipe-sysroot-native/usr/bin/opkg initramfs-standard/1.0-r0/recipe-sysroot-native/usr/bin/opkg-build initramfs-standard/1.0-r0/recipe-sysroot-native/usr/bin/opkg-buildpackage initramfs-standard/1.0-r0/recipe-sysroot-native/usr/bin/opkg-check-config initramfs-standard/1.0-r0/recipe-sysroot-native/usr/bin/opkg-diff Nov 08 15:56:06 initramfs-standard/1.0-r0/recipe-sysroot-native/usr/bin/opkg-extract-file Nov 08 15:56:25 there are certainly _some_ utilities being installed but I cannot reason why _all_ of them are not being stalled Nov 08 15:56:55 any suggestions for things to double check would be helpful Nov 08 16:05:13 <__angelo> what does it means " Could not invoke dnf." ERROR at end of the image build ? Nov 08 16:10:21 __angelo: we need a little bit more to help you :) dnf is the package manager responsible of installing the package in the rootfs skeleton (by default) Nov 08 16:22:14 Anyone know how to set a Python breakpoint in an OEQA test? Nov 08 16:29:54 JPEW: i see, does fixing that change the result in anyway? just curious if it is related to the reproducible class using subTest Nov 08 16:30:31 nrossi: It might be related to subTest. Other OEQA tests are also using subTest though Nov 08 16:33:32 nrossi: If I run with -j1, I see a correct FAILURE status and get the extradata in the log along with a strange error: https://pastebin.com/nWmS6c9n Nov 08 16:34:17 The _StringException is weird Nov 08 16:36:50 JPEW: ok, then its very likely to be the subTest handling, that weird error is due to how data is being passed from child processes to the parent runner Nov 08 16:37:32 nrossi: Where is that handled? Nov 08 16:38:01 These tests take so long it subTest really needs to work :) Nov 08 16:41:25 JPEW: core/runner.py is where you will need to look into handling subTest+extraresults, i suspect you will need to add a addSubTest override to OETestResult Nov 08 16:43:24 JPEW: i am going to head off (its late here), let me know if you manage to sort it out, otherwise if i get a chance i will look into it over the weekend Nov 08 16:43:38 nrossi: Ok, thanks Nov 08 18:37:56 I am getting Error " Exception during build_dependencies for AUTOREV" after upgrading to Thud. Is there any change for usage of AUTOREV in thud ? Nov 08 19:32:12 <__angelo> so, i had the above "internal compiler error" issue due to parallel build of Qt packages. Setting to 1 thread, rebuilding, i could complete the image build. Nov 08 19:32:31 <__angelo> so i would ask, is there a way to set 1-thread compilation only for Qt packages ? Nov 08 20:11:37 __angelo: only happens in parallel builds of a large package implies heating or ram problems Nov 08 20:26:41 <__angelo> rburton, mmm, as ram seems 5G are freem, but, from when i have this 9700k, often it reaches over 80 *C on heavy load Nov 08 20:27:08 <__angelo> so heating may be a good candidate Nov 08 20:28:08 right Nov 08 20:28:26 when i say ram problems i mean physical problems, not running out Nov 08 20:28:54 leave memcheck running overnight to verify the ram is fine Nov 08 20:29:00 erm, memtest even Nov 08 20:30:17 <__angelo> rburton, oh, ok. thanks. Some time, on j8 builds, this cpu reached throttling point, 100*, then with a better fan i could stay near 80, but i suspect it may be a faulty chip Nov 08 20:30:30 ouchy Nov 08 20:30:36 yes sounds like you've a cooling problem Nov 08 20:31:19 <__angelo> since this cpu's are someway new, still have to understand what is the proper working temp. Well, will investigate. Nov 08 20:31:37 <__angelo> many thanks for your kind help **** BEGIN LOGGING AT Fri Nov 08 21:47:38 2019 **** ENDING LOGGING AT Sat Nov 09 02:59:57 2019