**** BEGIN LOGGING AT Wed Nov 27 02:59:57 2019 Nov 27 06:04:48 Good morning everybody! First: Thank you guys for the new warrior release! (y) (y) (y) Nov 27 06:09:52 Probably a simple question to most of you: How to tell a package to NOT go into SDK? I appreciate also hints to the answering chapter in Reference-Manual ;D Nov 27 06:24:43 anyone used package_management with opkg? Nov 27 06:38:59 xtron: sure, its commonly used Nov 27 06:39:13 RP: http://jenkins.nas-admin.org/view/OE/job/oe_world_workspace-compare-signatures/873/console Nov 27 06:39:20 something changed in OE-Core ? Nov 27 06:39:25 its using master-next Nov 27 06:47:11 khem, there is a problem with package_feed configuration, package_management is set, package_feed_uris,path,arch are set but reflecting in opkg configs Nov 27 06:48:01 opkg list-installed is empty and it can't update from repo server Nov 27 06:56:11 bitbake -g is not generating recipe-dependencies Nov 27 07:22:43 xtron: it means package info is missing in image Nov 27 07:27:07 khem, seems like a build issue, as it works good first time with a fresh build afterward it don't have the repo configurations Nov 27 07:35:01 are you deleting the opkg info from image ? Nov 27 07:35:12 many times people do that to reduce size Nov 27 07:35:23 hmm Nov 27 07:36:01 are you using PACKAGE_FEED_URIS Nov 27 07:36:49 New news from stackoverflow: Yocto: create recipe for SciKit-learn Nov 27 07:52:25 good morning Nov 27 08:06:55 New news from stackoverflow: A: Use vivante GPU on IMX6 with 4.14 kernel Nov 27 08:16:02 khem: hmm, good question. Something could have broken that :/ Nov 27 08:26:36 -test- Nov 27 08:31:16 mckoan: -negative/failed- Nov 27 08:31:53 LetoThe2nd: yes it is :-( fighting against irssi config Nov 27 08:48:49 what may be wrong with CMAKE while building SDK? https://pastebin.com/QMkZ9u0M Nov 27 10:42:57 what may be wrong with CMAKE while building SDK? I have nativesdk-libarchive, but cmake can't find it in recipe-sysroot https://pastebin.com/QMkZ9u0M Nov 27 11:07:09 rburton: can you have a glance over -next please? Think its probably good now (assuming I drop the patches+reverts) Nov 27 11:56:14 *Le sigh* I hate Java :P Nov 27 11:56:41 Anyone know how to solve compile issues with meta-java on gcc 8.3? Nov 27 11:56:52 thud branch Nov 27 12:00:55 wertigon: check history of master branch which should contain the fixes for newer gcc explicitly or as updates to newer version Nov 27 12:01:59 You mean like 3832a3a74dc Nov 27 12:12:45 yep, that fixed it for now Nov 27 12:12:57 Hope no other problems arrive :) Nov 27 12:38:16 Ok, after cherry-picking 3832a3a7 and 90984a33 to the thud branch things work just fine Nov 27 13:07:15 RP: rwill do Nov 27 13:10:25 RP: the meta-intel failure was disk space limit in hddimg. the easy fix is to remove hddimg from the default fstypes for x86 Nov 27 13:10:42 just use wic images Nov 27 13:11:05 rburton: I'd love to do that since it would also fix the coreutils ptest issue on master-next Nov 27 13:11:36 i'll post the patch and you can it on it for a few days for review Nov 27 13:13:27 rburton: ok Nov 27 13:19:15 RP: you're going to clean up master-next before merging right? dummyprovides fixup HACK etc Nov 27 13:19:31 rburton: yes! :) Nov 27 13:21:10 RP: i'd be tempted to leave the final py2 removal bits in next a little longer so we can announce to the lists before pushing Nov 27 13:21:33 ok apart from the obvious hackery, next looks fine Nov 27 13:21:39 rburton: right, probably wise :) Nov 27 13:25:39 rburton: done, still 13 patches left in -next but those can waut Nov 27 13:25:44 rburton: thanks Nov 27 13:25:58 rburton: there were some you had in a branch ready as well? Nov 27 13:27:22 right Nov 27 13:27:23 will rebase Nov 27 13:28:14 did the virgl test fail again? Nov 27 13:29:35 rburton: I can't tell due to all the other failures Nov 27 13:29:50 rburton: it might be the thing causing those UNKNOWN issues Nov 27 13:30:10 hence its in holding pattern Nov 27 14:00:46 RP: is the coreutils patch still failing? I noticed the revert patches Nov 27 14:15:47 tgamblin: multiple problems, some not your fault Nov 27 14:16:28 tgamblin: https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/1289 is the size of the ptest image growing too large Nov 27 14:17:13 tgamblin: coreutils-ptest_8.31-r0_amd64.deb is listed in https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/521 too Nov 27 14:17:27 tgamblin: this latter one I'm not sure if that one is your patch or not Nov 27 14:19:39 hmm Nov 27 14:24:10 kergoth: no upstream-status in your libcapng patches Nov 27 14:24:21 erk, oops. thanks Nov 27 14:24:50 i wonder if devtool finish should print a warning/reminder to add them :) Nov 27 15:18:44 in a mc build, we have a recipe that refers to an artifact from another mc. when we use the file fetcher on ${TMPDIR}, we see problems in the sstate being used instead of the probably newly generated file. a hack we found is, prepending a "/" to ${TMPDIR}, therefore making it absolute and the fetcher always pulls it. yet, is that a recommendable way? Nov 27 15:38:57 rburton, I've been updating and fixing ptests in some of the core recipes: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates Nov 27 15:39:15 holding off sending those, as there is a queue of previous work Nov 27 15:39:31 but sed/flex/gettext are now all at latest upstream and 100% ptest pass Nov 27 15:40:12 kanavin_: sorry I'm so lagged on testing/integrating :( Nov 27 15:42:27 RP: it's entirely understandable, I have no problem with queueing and rebasing patches many times over Nov 27 15:42:53 Hi, i have a question about UBOOT configuration. In my board it configure "UBOOT_CONFIG[sd] = "mx6ull_14x14_evk_config"" where do i find this config? Nov 27 15:43:17 Iam working on my own MACHINE configuration Nov 27 15:48:44 and on top i have another question. I would like to put my application into a recipe like : recipe-myapp/src/... Is there a way to do this or do i need to overwrite the specific tasks? Nov 27 16:19:52 GeneralStupid: the docs cover 'how to write a recipe' Nov 27 16:20:38 sounds like they might want to put the source in the layer or something? unclear Nov 27 16:20:52 kergoth: exactly. Nov 27 16:21:49 it will be software which is not intended to use outside of an yocto build Nov 27 16:25:34 just put it in the layer and point at it with SRC_URI Nov 27 16:25:43 SRC_URI can handle a file://directory/ and copy the contents Nov 27 16:34:05 RP: I'll submit a v3 for coreutils eventually. Clearly I've missed a few things in developing it! Nov 27 16:35:15 tgamblin: not really, its just a tricky one Nov 27 16:35:55 tgamblin: for the space issue there are patches in progress to remove "live" images from x86 by default which should help. rburton has sent a patch but it will break things so we're waiting on a second one Nov 27 16:36:17 Well, I'm trying it out on another machine and I'm getting a few new issues, too Nov 27 16:36:23 tgamblin: you could test the reproducibility problem locally though and see if that is an issue or not Nov 27 16:36:32 tgamblin: ah :/ Nov 27 16:36:47 yeah, I'm going to look into reproducibility too Nov 27 16:37:11 for some reason "ptest-runner coreutils" just hangs when I call it Nov 27 16:37:16 occasionally, rather Nov 27 16:37:33 tgamblin: that doesn't sound good :/ Nov 27 16:37:49 * RP really dreams of deterministic failures Nov 27 16:41:54 RP: I'll see about cutting some stuff out of the RDEPENDS for now, and make note of them in the patch for the future. Guess that means that an extra six passes with valgrind added is out of the question, though :) Nov 27 16:42:47 tgamblin: valgrind is definitely too much Nov 27 16:42:58 tgamblin: don't mind having a configuration option for it Nov 27 16:49:21 RP: i noticed a revert of the gcc/configargs.h patch in master-next, was there any issue with it? Nov 27 16:54:34 nrossi: it may or may not have caused a reproducibility regression Nov 27 16:55:00 nrossi: too many changes all causing too many problems. Its on hold until I can either tell whether it did or didn't Nov 27 16:55:16 nrossi: I didn't send email as I simply don't know :( Nov 27 16:57:08 tgamblin: ptests are 'does this work' not 'has upstream introduced a leak' Nov 27 16:57:19 tgamblin: ie primarily integration tests Nov 27 16:58:41 rburton: right, but while poking around after seeing those build failures, I've found a couple of things I didn't catch when I first sent it to the list Nov 27 17:01:20 RP: no problem, just wanted to check if there was something too look into Nov 27 17:21:43 I'm trying to build the v1.4.1 libgpiod package (http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/libgpiod/libgpiod.inc?h=zeus) with python3 bindings. That fails because "QA Issue: non -staticdev package contains static .a library". Is there a way to stop the static package from building? Nov 27 17:22:45 For reference I've added PACKAGECONFIG ?= "tools cxx python3" to the bb file to build the tools, cxx bindings, and python3 bindings Nov 27 17:31:37 d_thomas: it's Yocto packages, so what you would like to modify is PACKAGES no PACKAGECONFIG. Nov 27 17:31:43 but just put the .a in the correct place Nov 27 17:32:04 or modify one of the FILES_${PN}-something to have the correct paths Nov 27 17:32:17 default paths if they are not overriden are in bitbake.conf Nov 27 17:32:19 afk now Nov 27 17:33:03 Interesting, the recipes I started with used PACKAGECONFIG instead of PACKAGES. Let me try that Nov 27 17:40:05 If I use "PACKAGES ?= "tools cxx python3"" with that recipe, it does not actually build and include the tools. I have to use PACKAGECONFIG. Is that an error with the script? Nov 27 17:59:17 Sorry qschulz, but I'm not following what needs to be done to enable the python bindings with that recipe Nov 27 18:00:24 And the way I have done it, causes a problem because there is a static library sitting in the site-packages directory and the QA script doesn't think it should be there Nov 27 18:37:06 * RP hmm, I guess its good I have wo selftest failure problems reproducing on one of the autobuilder workers Nov 27 18:37:26 Ran 1 test in 11029.456s is less good Nov 27 18:37:32 d_thomas: the fix is to extend FILES_${PN}-staticdev with that .a file Nov 27 18:37:36 ouch Nov 27 18:38:17 tgamblin: isolating it is a good first step at least. Now to see if I can make if fail faster :) Nov 27 18:38:37 unless someone else wants to try of course... Nov 27 19:33:00 RP: I can have a peek with some more details Nov 27 19:35:10 may be later this evening before I get to it, though Nov 27 19:45:08 rburton, could you explain a bit more? What does extending FILES_${PN}-staticdev with the file do? Right now it seems like the file is getting added to the deploy dir and it the QA test doesn't think it should be there Nov 27 19:46:00 d_thomas: the qa task is upset it's in the *wrong package*. if you put it in the right package, it won't end up in the wrong one Nov 27 19:47:34 So the file is "gpiod.a". If I set FILES_${PN}-staticdev equal to that value, it will correctly locate the file? Nov 27 19:48:22 no, you have to specify the full path, not just a filename Nov 27 19:48:41 the full path relative to the root of the rootfs, that is. i.e. /usr/foo Nov 27 19:48:47 Right now bitbake -e shows "FILES_libgpiod-staticdev="/usr/lib/*.a /lib/*.a /usr/lib/libgpiod/*.a" Nov 27 19:49:04 where's gpiod.a ending up? Nov 27 19:49:32 usr/lib/python3.5/site-packages/gpiod.a Nov 27 19:50:05 FILES_${PN}-staticdev += "${PYTHON_SITEPACKAGES_DIR}/*.a Nov 27 19:50:08 " Nov 27 19:50:41 like i said, the path to the file. PYTHON_SITEPACKAGES_DIR is ${libdir}/${PYTHON_DIR}/site-packages, aka /usr/lib/python3.5/site-packages Nov 27 19:51:31 Except I'm not sure the file is suppose to be there Nov 27 19:51:49 ERROR: libgpiod-1.4.1-r0 do_package_qa: QA Issue: non -staticdev package contains static .a library: libgpiod-python path '/work/cortexa5hf-neon-poky-linux-gnueabi/libgpiod/1.4.1-r0/packages-split/libgpiod-python/usr/lib/python3.5/site-packages/gpiod.a' [staticdev] Nov 27 19:51:59 if you know enough about its buildsystem to disable it, go for it. i doubt anywhere here is an expert on libgpiod Nov 27 19:52:27 it's true that it's not typical to install static libraries in a python library search path Nov 27 19:52:52 that said, adding it to the FILES entry will at least ensure it's in the right package and will silence the QA issue Nov 27 19:52:53 I don't know enough.... was thinking this was just an oops in the recipe that I could fix Nov 27 19:53:03 worth doing regardless. then pursue avoiding building it at all later Nov 27 19:53:21 alternatively, do_install_append () { rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/*.a } Nov 27 19:53:22 oh, actually I want to build the python bindings Nov 27 19:53:26 which will ensure it doesn't get packaged at all Nov 27 19:53:28 By default they are not built Nov 27 19:53:31 yes, i know Nov 27 19:53:37 pursue avoiding building the .a at all later Nov 27 19:53:48 the .a isn't part of the python bindings, python doesn't load .a files Nov 27 19:53:55 I tried a few attempts at avoiding the static library, but nothing successful Nov 27 19:54:42 right, so either remove it in do_install or add it to -staticdev as rburton suggested Nov 27 19:55:16 I'll try the do_install fix you suggested. That seems like a clean workaround Nov 27 19:56:09 agreed, no point packaging something that won't get used anyway.. Nov 27 19:56:22 we do generally package static libraries since they're useful in development, but i doubt this one is Nov 27 20:00:53 kergoth, Thank you, libgpiod built. I'll build the full image next to verify that all the tools and bindings are there like I expect Nov 27 20:01:37 grats Nov 27 20:04:08 rburton: you know if anyone has done a recursive -w for oe-depends-dot, or a wrapper script to do so? Nov 27 20:04:17 particularly now that recipe-depends is gone.. Nov 27 20:09:26 kergoth: I did write a reversed version of task-depends.dot the other day to try and debug something Nov 27 20:09:52 we do have a problem being able to visualise how things are pulled in :/ Nov 27 20:13:32 i still rather liked the simplicity of bb-whatdepends -r. see the very very bottom of https://github.com/kergoth/bb, last example. just uses indentation with '..' for items we've already traversed Nov 27 20:14:47 ideally it'd be nice to mark up the graph edges with additional info. deptask, DEPENDS, etc. why the edge is there Nov 27 20:21:04 RP: actually mused the VSCode aspect for some time already. I just don't have the slightest clue what such a thing would be supposed to do. Nov 27 20:22:51 RP: so if you actually have an idea for a use case, please shoot. i'm q pretty avid vscode user these days and i totally agree that this would be a massive "new audience" thing Nov 27 20:23:50 kergoth, well libgpiod supposedly built the python bindings but did not deploy them. I'll have to look into that more... Nov 27 20:29:55 LetoThe2nd: I was playing with the remote ssh vscode functionality today. Would be very cool if it could use OE to cross compile and debug on target Nov 27 20:30:08 LetoThe2nd: a bit like the eclipse IDE plugin did Nov 27 20:31:19 certainly vscode would be a better base these days Nov 27 20:31:27 and it's a pretty nice IDE Nov 27 20:34:31 JPEW: looks like bitbake XXX-image -c populate_sdk_ext fails with my hashequiv patch Nov 27 20:34:37 JPEW: not looked into why yet Nov 27 20:35:05 RP: i am doing seomthing quite similar all day long: VSCode via remote into build server, kicking off devtool deploy-target in the integrated terminal Nov 27 20:35:38 LetoThe2nd: right, the question is whether we could put something better around it? Nov 27 20:36:05 LetoThe2nd: or at least document how you can use vscode for this Nov 27 20:36:25 if only we had someone who did videos Nov 27 20:37:24 RP: we certainly can do something better. the question is, what do we want to do bettre Nov 27 20:38:00 LetoThe2nd: maybe make it so someone can use a prebuilt toolchain in there without needing to build from source? Nov 27 20:38:07 * RP thinking out loud Nov 27 20:39:25 so you'd say, target are the app developers, not the distro builders Nov 27 20:39:32 * LetoThe2nd notes Nov 27 20:42:27 its a good reasoning: if you have a horde of application developers who like your tools, its like a total sales guarantee for the OS/distro guys Nov 27 21:00:47 LetoThe2nd: right. the distro people are usually happier with commandline Nov 27 21:04:00 RP: let me think about this a bit. :) Nov 27 21:04:42 RP: "xds" does exactly that integration Nov 27 21:05:00 https://docs.automotivelinux.org/docs/en/master/devguides/reference/xds/part-1/xds-overview.html Nov 27 21:06:11 hmm, why is python3 and bash and crap being pulled into a meta-environment build. Nov 27 21:06:33 * kergoth scratches head Nov 27 21:08:34 kergoth: ptest? Nov 27 21:08:44 dl9pf: interesting, will look it up Nov 27 21:08:48 that has been the answer each time I wondered recently Nov 27 21:09:06 dl9pf: that does look interesting. Can you run xdg-server from a native recipe too? Nov 27 21:09:12 ncurses in TOOLCHAIN_NEED_CONFIGSITE_CASCHE, which pulls in opkg-utils for update-alternatives, which needs python3, etc. Nov 27 21:09:25 even if nothing i'm doing with the sdk has anything to do with the site files. /me overrides it for now Nov 27 21:09:44 maybe i should resurrect those bits to use chkconfig's alternatives implementation.. Nov 27 21:11:06 having to build a target python3 just to get upd-alt is a little much :) Nov 27 21:11:15 * kergoth yawns Nov 27 21:18:53 RP: it is written in 'go' , atm we built it separately Nov 27 21:19:53 dl9pf: of course, it would be :) Nov 27 21:20:11 * zeddii chuckles Nov 27 21:30:35 dl9pf: it does sound interesting/useful and we could benefit as a project by focusing around it as I'd assume its not AGL specific? Nov 27 21:30:42 reproducible.ReproducibleTests.test_reproducible_builds: ERROR (3.16s) Nov 27 21:30:50 * RP prefers that time to failure Nov 27 21:31:25 no. you throw the plain yocto sdk at it and it can compile Nov 27 21:31:58 it is not specific. Nov 27 21:32:26 dl9pf: I couldn't see why it would be but I had to check :) Nov 27 21:44:34 RP, the zeus ReproducibleTests.test_reproducible_builds: FAILED is intermittent.. Nov 27 21:45:07 or maybe host related Nov 27 21:45:53 I will open bugs on that plus the build perf and assign them to anuj Nov 27 21:49:25 armpit: I think its the already known perl issue Nov 27 21:50:03 armpit: we didn't block 3.0.0 for it so we wouldn't block 3.0.1 for it either assuming its the same one Nov 27 21:50:04 needs to be bugged anyways.. Nov 27 21:50:14 armpit: Im sure there already is on Nov 27 21:50:20 one Nov 27 21:50:41 build perf?? Nov 27 21:51:13 I don't think its a blocker but we need to figure out why Nov 27 21:51:15 armpit: no, sorry, the reproducible one Nov 27 21:51:26 build perf needs a bug Nov 27 21:51:36 on it Nov 27 22:05:57 RP, done Nov 27 22:11:15 RP: I am reading the python2 removal patch and it seems we should not delete unadorned 'python' Nov 27 22:11:35 since when distro's drop py2 then python -> python3 Nov 27 22:11:41 should exist Nov 27 22:12:29 on arch python3 is default python for many years Nov 27 22:13:30 and many packages which needs python can work with python2 and python3 so they wont bother to change to use python3 explicitly Nov 27 22:17:56 khem: well, we've mandated python be python3 for years, I'm not sure just swapping it is a good idea Nov 27 22:20:21 but this will make life difficult for OE packagers since upstream package maintainer will still use 'python' and mean python3 Nov 27 22:20:40 why are we crusading Nov 27 22:24:56 khem: anything using "python" will probably be expecting python2 so we don't end up validating all our uses :/ Nov 27 22:25:26 khem: I really don't like just suddenly swapping it over and pretending everything is fine. We don't want python2 creeping in Nov 27 22:28:21 you are assuming unadorned python to be python2 which is not always the case Nov 27 22:31:23 khem: but sometimes can be Nov 27 22:33:59 python-unversioned-command in fc31 is pointing to py3 Nov 27 22:34:36 so whichever distro is switching defaults is providing /usr/bin/python Nov 27 22:37:33 khem: thanks to arch being dumb the use of python is really hard Nov 27 22:37:48 i agree with the PEP: don't use /usr/bin/python Nov 27 22:37:52 because you can't know what it is Nov 27 22:38:08 lets just patch anything that tries to use it to use a versioned hashbang Nov 27 22:39:10 rburton: since other distros are not doing it people will keep using it so we will be patching stuff until py4 comes out Nov 27 22:39:12 transparently swapping python to be python3 would break at least one of the recipes we fixed earlier in the week Nov 27 22:39:16 and restart again Nov 27 22:39:54 khem: i'd suggest that most upstreams are moving to versioned hashbangs because they can't rely on python being anything in particular, and don't want the pain of trying to write py2-and-py3-safe code Nov 27 22:40:38 I would like that however, I am afraid that upstream will ignore such changes Nov 27 22:41:10 if distros dont push it or provide solutions like what fedora is doing and arch is doing Nov 27 22:41:56 if in a years time, python is universally py3 then we can review adding it back, but right now its far too ambigous Nov 27 22:42:55 I have already patches a dozen and its seems never ending Nov 27 22:43:31 lets switch to apple, no scripting langugaes period Nov 27 22:43:39 did you try adding code back to make python->py3 and see how much breaks with the assumption that its py2? Nov 27 22:45:08 https://www.python.org/dev/peps/pep-0563/ Nov 27 22:45:15 they are already talking about py4 Nov 27 22:45:41 another good reason for python to be killed Nov 27 22:45:58 is a bare python py2, py3 or py4 Nov 27 22:48:32 * khem hugs rust Nov 27 22:48:33 https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html Nov 27 22:48:41 :) Nov 27 22:49:12 it promises to never have rust 2.0 Nov 27 22:49:38 just editions which can be mixed and demanded by source files Nov 27 22:51:03 there are cmake functions checking for python which are failing Nov 27 22:51:08 used by many apps Nov 27 22:51:56 py3native should probably set PYTHON_EXECUTABLE Nov 27 23:06:32 and PYTHON Nov 27 23:18:25 * armpit PYRUSTC++ Nov 27 23:43:56 the problem with out autobuilder failure is that its using our buildtools tarball and traceback2 is missing Nov 27 23:44:57 * RP wonders if we can just use traceback Nov 27 23:47:30 answer, yes we can Nov 27 23:48:32 but tomorrow Nov 28 01:44:04 what may be the problem with RPATH? https://pastebin.com/md9MKAQ7 Nov 28 02:44:01 * armpit hmm, zeus 3.0.1... same failures **** ENDING LOGGING AT Thu Nov 28 02:59:57 2019