**** BEGIN LOGGING AT Fri Feb 21 02:59:57 2020 Feb 21 03:51:55 New news from stackoverflow: Why is there an error when executing bitbake commands in the Yokto project? Feb 21 04:01:49 how do i use the kernel image as a DEPENDS in a recipe? i've tried virtual/kernel.. kernel-image.. etc. nothing ive tried adds my zImage to the sysroot. Feb 21 04:49:47 mischief: IMAGE_INSTALL += "kernel-image-bzimage" Feb 21 04:49:54 ah I means kernel-image-zimage Feb 21 07:13:06 what is the shorthand of "this package in the destination image", i mean i want to copy something under ${D}/path/to/this/package Feb 21 07:13:36 must be something simple but i just cant figure it out, i blame the morning Feb 21 07:46:55 Is anybody using multiconfig builds? Feb 21 07:48:08 Why does it quite randomly choose that it needs to rebuild a bunch of packages that have not been changed at all? Feb 21 07:48:28 It basically does not work Feb 21 07:48:40 stuom1: can't confirm that. Feb 21 07:49:11 I have common downloads dir but others are separate Feb 21 07:49:19 we're not exactly power users, but here it does pretty much what it is expected to do. Feb 21 07:50:50 now it decided that I need to recompile chromium, I could use that 4 hours for something else Feb 21 07:52:20 stuom1: if you can share the configuration one can have a look. beyond that, no idea. Feb 21 07:53:26 stuom1: plus, no need to keep seperate sstates. the only things that should be seperate are the TMPDIRs, as i understand it. Feb 21 07:57:32 good morning Feb 21 08:31:32 Hi guys! I wrote a simple recipe that compiles and installs a shared object library. In do_install() I wrote oe_runmake install DESTDIR=${D} PREFIX=/usr Feb 21 08:32:29 The resulting .so are found under /usr/lib/x86_64-linux-gnu/libargon2.so Feb 21 08:34:02 In another recipe I set DEPEND = "argon2", but it fails compilation stating that ld cannot find -largon2 Feb 21 08:34:07 kriive: because your prefix doesn't include ${D}, probably Feb 21 08:35:33 or is the path that you gave inside the image? Feb 21 08:37:54 LetoThe2nd: are you referring to the argon2 recipe or the one that depends on it? Feb 21 08:38:09 kriive: here is the source of your headache: https://github.com/P-H-C/phc-winner-argon2/blob/master/Makefile#L146 Feb 21 08:38:45 kriive: hooray for another project that thinks hand-carving Makefiles is the way to go, and nobody ever needs to cross compile Feb 21 08:39:31 Do I need to set LIBRARY_REL to plain lib? Feb 21 08:39:39 you can try passing in LIBRARY_REL, but generally i'd call that broken. Feb 21 08:40:46 Sorry if I don't get it, but is it the x86_64-linux-gnu that breaks it all? Feb 21 08:41:31 yup Feb 21 08:42:48 YESSSSSSSSSS COMPILES Feb 21 08:43:03 kriive: invoce address please :) Feb 21 08:43:04 LetoThe2nd: Thank you so so much Feb 21 08:43:31 You won a beer for one of the live coding videos Feb 21 08:44:06 hehe Feb 21 08:44:25 really, this is almost a poster example why handwritten Makefiles are stupid and ugly. Feb 21 09:09:57 Hi, I'm working with a poky version from a couple of years ago, and dealing with a (typical enough) situation where the organization has some different install prefixes, or at least libraries and apps end up in different prefixes Feb 21 09:10:39 I've found that they've strongarmed the system to achieve this by adding do_populate_sysroot() functions to their recipes Feb 21 09:11:36 gtristan20: sounds pretty hackish to me. Feb 21 09:11:47 So do_install() installs to the real intended location, and do_populate_sysroot() stages to the normal prefixes, for the purpose of the build (header files and libraries can be found in /usr/lib instead of /opt/foo/lib) Feb 21 09:12:26 Yes, so the result of this is that the sstate files for populate_sysroot tasks are empty, and the sstate cache is not usable (builds break if you try to reuse the cache) Feb 21 09:13:06 I'm trying to fix this by removing the do_populate_sysroot calls, and adding a custom class which informs the dependencies of extra link paths, setting up LDFLAGS Feb 21 09:13:14 And cleanly defining the alternative prefixes Feb 21 09:13:18 But I ran into a snag Feb 21 09:14:08 Basically at least in my version of poky, the staging.bbclass (which implements do_populate_sysroot()), is hard coded in such a way to be picky and selective about which files to choose Feb 21 09:14:47 So I only get the header files (which we leave under /usr/include for builds and SDKs), but /opt/foo stuff gets left out and never staged to the sysroot Feb 21 09:15:27 there appears to be no way to configure this, short of patching staging.bbclass and implementing a tad of flexibility there Feb 21 09:19:04 looking at master: https://github.com/openembedded/openembedded-core/blob/master/meta/classes/staging.bbclass, it appears that I would be able to work around this by appending my paths to SYSROOT_DIRS Feb 21 09:19:16 But not in this version Feb 21 09:19:29 Maybe I should backport that to my version of poky Feb 21 09:20:27 Any thoughts ? I usually don't work with yocto/poky, so maybe there is a better approach ? Feb 21 09:21:26 I've considered overriding prefix/exec_prefix in the recipes which get installed to separate locations, but I fear this will not only affect the installation prefix variables, but also variables used to discover dependencies Feb 21 09:22:08 e.g. ${libdir} would end up being my installation one, but would be passed the the compiler in -L${libdir} instead of the regular libdir (as opposed to in addition to it) Feb 21 09:22:23 same with pkg_config_path etc Feb 21 09:27:33 Aha Feb 21 09:27:39 I found this thread http://lists.openembedded.org/pipermail/openembedded-core/2016-May/239813.html Feb 21 09:27:53 which introduces SYSROOT_DIRS, and shows me patches of "the old way" Feb 21 09:28:07 Which uses these preprocess functions Feb 21 09:30:14 gtristan20: hum. what version are you an? Feb 21 09:36:06 gtristan20: I'd try and use the methods that were there before SYSROOT_DIRS rather than backporting the other changes Feb 21 09:38:22 Hmmm, alright so that works ! Feb 21 09:39:21 SYSROOT_PREPROCESS_FUNCS += "libfoo_sysroot_preprocess" <-- like that Feb 21 09:39:34 and define a function of that name which stages just the alternative prefix Feb 21 09:40:26 But, this is a bit generic, do you think I can define this sysroot preprocess func in a .bbclass and just inherit it in any of the recipes which install to a custom prefix ? Feb 21 09:40:56 * gtristan20 is only unsure of this because it's defining a function, and in upstream poky I'm seeing individually named per-recipe functions being used for this purpose Feb 21 09:42:06 gtristan20: again, what version are you on? there has been a massive change in sysroot/staging, so if you are pre-pyro then you totally should not refer to current master. Feb 21 09:42:26 Maybe I can define the function like: ${PN}_sysroot_preprocess() {...} ? Feb 21 09:43:21 LetoThe2nd, nah I'm referring to the poky I have I mean, I'm about 3 to 6 months behind the massive change which causes recipes to build safely in their own separate sysroots Feb 21 09:43:57 When I mean "upstream poky" I mean the stuff I have here that is not custom, I did check the git sha a while back but couldnt tell you off hand the exact version Feb 21 09:46:33 That said, referring to current master is exactly what lead me to find SYSROOT_DIRS, which in turn pointed me to the ML discussion, and caused me to discover the "old way" of doing it, which works with this version :D Feb 21 10:07:05 khem: no, i need this for a build time dependency as part of an image recipe. i don't wan the kernel binary in my imagine, but i want to do some stuff with the kernel image. does that make sense? Feb 21 10:07:45 ugh terrible english Feb 21 10:17:42 Guys do you have guidance on how to write .pro (qmake project file) suitable for cross-compile? Because I don't see any variable ready to use and I often have seen hardcoded install paths and ugly stuff like that Feb 21 10:18:31 Advice like move to cmake and burn qmake with fire are totally accepted Feb 21 10:19:57 kriive: i hereby suggest the latter. just for the fun of setting something on fire. Feb 21 10:23:09 New news from stackoverflow: CMake project using external SDK toolchain file cross-compile error Feb 21 10:53:15 New news from stackoverflow: Yocto:, error perf-1.0-r9 do_compile: oe_runmake failed from bitbake image Feb 21 10:59:26 hi, I just updated to the latest warrior version (2.7.3), and now builds against meta-boundary or meta-freescale-3rdparty fail because they provide a linux-firmware_git.bbappend, but the linux-firmware_git.bb was renamed in poky with the following commit https://git.yoctoproject.org/cgit.cgi/poky/commit/?h=warrior&id=58ded66418f67c7fc81143bc129d74aabc6cde1a Feb 21 10:59:30 was this intended? Feb 21 11:02:47 blarz: its basically a version bump, so the other layers should bump too. but i agree at the the filename change is unfortunate. Feb 21 11:03:40 Hi Folks. Do you know of any license.manifest parsing utilities. E.g. currently it is a sorted list of packages, but what if I want to get this is the licenses, this is the packages with this license. Feb 21 11:11:07 LetoThe2nd: indeed it is. but yeah, I will need to wait for the other layers then. thanks! Feb 21 11:15:07 LetoThe2nd: do you have millions of followers on twitter yet? Feb 21 11:15:29 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13807 is a bug i just filed, would make an interesting little project for someone who wishes to learn and do something concrete Feb 21 11:15:30 Bug 13807: enhancement, Undecided, ---, unassigned, NEW , Add support for elfutils debuginfod Feb 21 11:15:32 rburton: not yet, unfortunately. Feb 21 11:19:18 rburton: i can put it on if you'd like, but i don't expect any outcome to be honest. Feb 21 11:23:23 New news from stackoverflow: Understanding Yocto Project sstate-cache functioning Feb 21 13:24:43 exit Feb 21 13:47:44 hi, if i try to ubifsmount an ubifs volume which was created with Linux i get BADMSG -74 ECC errors Feb 21 13:47:50 Is it possible that Linux Ubifs is not compatible with Uboot ubifs? Feb 21 14:00:17 What's the best way (security-wise also) to initialize a MariaDB password randomly in Yocto? Feb 21 14:00:41 I don't want every device to have the same root pwd Feb 21 14:30:19 Hi all Feb 21 14:30:55 Are there any tips on how to debug the "sstate mirror object availability"? Feb 21 14:31:49 When it loads for a long time and at the end everything gets fetched and build from the ground Feb 21 14:32:13 I've tried running bitbake with -vvv Feb 21 14:32:22 But that didn't result in a change Feb 21 14:39:24 Found pkg_postinst_ontarget_${PN}, is a valid method to initialize root passwords? Feb 21 14:49:26 kriive: no Feb 21 14:49:40 kriive: google 'yocto set root password' gives you https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_password Feb 21 15:03:32 * RP wonders if we could get the first green master-next in two weeks Feb 21 15:03:44 * RP wills the build onward Feb 21 15:15:18 RP: We used to have a in-house build system written in perl that I had the ignominious glory of hacking on... the ongoing joke was that it only worked because I willed it to continue Feb 21 15:15:37 I was *so* happy when we got rid of it Feb 21 15:16:17 RP: btw, did my master-next build of mingw pass? I don't think I got a link... Feb 21 15:16:46 rburton: Pardon me, I meant root mysql passwords Feb 21 15:17:47 I am well aware of usermod and extrauser methods Feb 21 15:17:57 Sorry for not clarifying Feb 21 15:26:28 hi everybody, so i have a forerunner 225 from garmin and the inicial idea is put steroid os on her Feb 21 15:27:06 i've discovered that i need to write a layer and i found octo Feb 21 15:27:43 Italian? Feb 21 15:27:49 and my new idea is "only" run linux on him Feb 21 15:27:58 brazilian kriive Feb 21 15:28:35 him* yocto* Feb 21 15:28:39 saw giovanni, thought italian nvm :) beautiful country, sorry for the ot Feb 21 15:29:00 that's okay Feb 21 15:33:47 giovannism20: my understanding is that asteroidos is only for watches that run android out of the box Feb 21 15:34:10 yes Feb 21 15:34:24 garmin 225 is a wath but with a propietary software Feb 21 15:34:31 watch* Feb 21 15:36:13 unless you know how to get access to the bootloader and what the hardware specs are, you're a long way from needing a bsp layer Feb 21 15:37:27 you have some tip of how can i find hardware specs ? Feb 21 15:38:08 well garmin won't tell you Feb 21 15:38:26 you'll need to reverse engineer the port on the back and see if you can get a console to the watch Feb 21 15:39:03 look at the install instructions on asteroid, step 1 is always 'turn on android development mode' Feb 21 15:48:03 well, sure Feb 21 15:48:08 i'll try to do that Feb 21 15:48:10 thnks! Feb 21 15:48:33 but if your watch isn't running android then that won't work... Feb 21 15:49:21 and can i install android or put another system Feb 21 15:49:58 cause i trying to change because he not connect at satellites Feb 21 15:50:09 i doubt changing the OS will solve that Feb 21 15:50:21 GPS is slow to sync unless you have assisted-gps Feb 21 15:51:00 you won't be able to 'just install android' on a watch that doesn't run android without a huge amount of effort Feb 21 15:51:52 uhmm sure Feb 21 15:52:02 i'll try to solve this satellites problem Feb 21 15:52:22 and if still not working i'll try another alternatives Feb 21 15:52:43 hi rburton, is there any update regarding the psplash screen? https://bugzilla.yoctoproject.org/show_bug.cgi?id=4339 Feb 21 15:52:43 Bug 4339: normal, Medium, 3.99, matthew.zeng, IN PROGRESS REVIEW , psplash doesn't work with systemd Feb 21 15:52:54 i thought that was integrated already Feb 21 15:54:24 the patch you asked me to test has not yet been merged Feb 21 15:54:32 https://patchwork.openembedded.org/patch/169342/ Feb 21 15:54:43 RP: ^ Feb 21 16:18:53 rburton, I think he is taking some time off Feb 21 16:23:16 RP: I see this kind of msg when runniing core-image-sato-sdk-ptest https://hastebin.com/unowoxesec.sql Feb 21 16:23:41 RP: how are ptest errors reported Feb 21 16:25:55 Are pkg_postinst_ontarget_${PN} () commands used in qemu? Feb 21 16:26:33 Should I expect them to run also on qemu virtualized image? Feb 21 16:28:20 if you mean in a qemu-system then yes, that is the target Feb 21 16:28:58 Yeah, sorry qemu-system Feb 21 16:30:20 only use a ontarget postinst if you can't run a normal one (that executes on the build host during rootfs) Feb 21 16:31:51 Maybe that was an XY question. My need is to initialize random passwords and crypto nonces at boot time. Feb 21 16:32:13 Only the first time after the system has been booted Feb 21 16:33:10 ontarget is what you want then yes Feb 21 16:33:30 For example mysql (mariadb) root password and db password, and also seed an initial db (but I think I can do that at build time) Feb 21 16:33:41 rburton: Oh ok, thanks Feb 21 16:40:12 khem, I think RP is taking time off Feb 21 16:50:46 ok Feb 21 17:15:15 armpit: my connection is struggling :/ Feb 21 17:30:51 wic-tools seems to be breaking for me again on thud Feb 21 17:31:39 For some reason extend_recipe_sysroot() is trying to pull in both libgcc-initial and libgcc Feb 21 17:33:53 It worked on the first build but then fails on subsequent builds in the same tmpdir Feb 21 17:34:46 paulbarker: :(. I have some half memory of debugging that but nothing specific :( Feb 21 17:35:41 RP: It looks to be very intermittent. I know dl9pf hit it when building AGL at FOSDEM Feb 21 17:35:48 I'll look into it further over the weekend Feb 21 17:36:03 The connection to my build machine seems to be playing up Feb 21 17:36:26 paulbarker: I'm seeing a lot of connection turbulence today :/ Feb 21 17:37:03 RP: Mine is likely my error somewhere, wireguard works and I can ping my home machine over the encrypted tunnel but ssh files Feb 21 17:38:33 I'm pretty sure I've narrowed this down to the wic-tools recipe calling extend_recipe_sysroot but I need to see if I can reproduce it on master Feb 21 17:40:08 Ah excellent there's a bunch of commented out bb.note calls in that function. I'll uncomment those and re-run the build later so I can see the whole dep tree Feb 21 17:41:34 paulbarker: Try adding http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=zeus&id=ccff952d9c747d8c7e12836094657ebcd3501a86 Feb 21 17:41:44 paulbarker: that may make it fail consistently Feb 21 17:41:56 Will do Feb 21 18:04:14 matthewzmd: I've queued that, thanks for the pointer, I'd wanted to merge it Feb 21 18:04:56 JPEW: I did get various passes and merged things as a result Feb 21 18:05:12 JPEW: I think your toolchain test did pass, I didn't merge though as I wasn't sure what you wanted Feb 21 18:23:52 RP: ptests started passing when they shouldn't https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/716 Feb 21 18:24:04 possibly related to the parsing fix of yours? Feb 21 18:49:23 <[Sno]> RP: thanks to the config.log I can now reproduce the root cause and it's exploding a bit ... Feb 21 18:49:37 <[Sno]> RP: take a little while Feb 21 19:00:28 RP: the other day you said i can DEPENDS += virtual/kernel, but that doesn't seem to work - i don't get a kernel in my recipe sysroot. any clue how i can do it? Feb 21 19:18:42 I see that the perl5 upstream already has 5.31.9 release https://github.com/Perl/perl5/releases, is there a reason why yocto still keeps it at 5.30.1? Feb 21 19:20:29 i think kanavin_home upgraded it to 5.30.1 on december Feb 21 19:24:59 New news from stackoverflow: Bitbake: "The metadata is not deterministic and this needs to be fixed" Feb 21 19:29:46 I try to upgrade it myself, but dunno how to generate the perl-cross.md5sum and sha256sums Feb 21 20:46:27 matthewzmd: they're the checksum of the perl-cross tarball Feb 21 20:46:42 which hasn't made a new release since 1.3.1 Feb 21 20:46:55 rburton: thank you, i ended up backporting a commit from upstream Feb 21 20:47:07 i figured 5.31.* is not a stable release Feb 21 20:47:09 that does support perl 5.31.6 so feel free to try upgrading to that without touching perl-cross Feb 21 20:47:14 ah fair Feb 21 20:47:20 that odd/even thing is relatively commo Feb 21 20:47:32 right Feb 21 22:08:52 mischief: that will add a dependency on the kernel, you didn't specify what bits of the kernel you wanted. Look at some of our module examples Feb 21 22:09:56 kanavin_home: what makes you say it shouldn't have passed? Feb 21 22:10:48 kanavin_home: I guess https://autobuilder.yocto.io/pub/non-release/20200221-7/testresults/testresult-report.txt confirms its bust Feb 21 22:21:16 RP: I sent a patch :) Feb 21 22:21:34 RP: it's not supposed to pass because I know very well not everything is fixed yet! Feb 21 22:21:50 particularly, mdadm and valgrind Feb 21 22:23:46 kanavin_home: right, was just wondering what to look for but its obvous from the report :( Feb 21 22:24:12 kanavin_home: thanks, what a silly mistake :/ Feb 21 22:24:51 RP: cheers Feb 21 22:35:33 kanavin_home: added to -next and tests restarted Feb 21 22:35:42 khem: I dropped binutils again as the perf issue remains Feb 21 22:35:46 zeddii: ^^^ Feb 21 22:37:16 I only fixed it for 5.4 Feb 21 22:37:33 do you have a link to the failure ? it definitely worked here. Feb 21 22:38:47 zeddii: pick from any failures in https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/734 Feb 21 22:41:01 RP: I have clean world build locally so I think perhaps zeddi's pull did not include https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=0ada120c883d4f1f6aafd01cf0fbb10d8bbba015 ? Feb 21 22:42:06 nope. it certainly does. Feb 21 22:44:21 unless the SRCREVs are wrong, the patch is in the kernel. I can easily check the commit. sec. Feb 21 22:45:27 looks ok on that front. My SRCREV bump includes; https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.4/standard/base&id=f4d7dbafb103e4f782323017c239c548871c1567 Feb 21 22:46:42 something is off on that build Feb 21 22:46:46 it doesn’t seem to have my PV fix Feb 21 22:46:57 its building recipe linux-yocto-5.4.15 Feb 21 22:47:02 but that should be .20 Feb 21 22:47:08 zeddii: have a look at -next and tell me what is missing? Feb 21 22:47:22 pulling. sec Feb 21 22:47:27 ah I am also doing build on master-next and its passing world build too for qemux86 Feb 21 22:48:04 but next maybe stale Feb 21 22:49:15 RP: they all do look to be there, but yet the .15 is wrong. my commit: “linux-yocto: fix PV”, let me see if something is undoing that in -next. Feb 21 22:54:08 zeddii: in my checkout of master-next I am getting 5.4.20 and I can see the commit is in Feb 21 22:54:52 RP: I wonder if this build which failed missed the kernel bump ? Feb 21 22:54:57 but had binutils in Feb 21 22:55:35 likewise, I just refreshed and started again. and see the .20 coming out. Feb 21 22:56:43 RP: Just nor rebuilt perf on master-next + binutils patch and it built fine Feb 21 22:56:59 RP: so I think something went wrong on AB perhaps Feb 21 22:57:16 khem: it was what was in -next + binutils Feb 21 22:57:48 yeah I just updated 2 mins ago so to ensure I am on same master-next Feb 21 22:58:01 but I am on OE-core if that makes difference Feb 21 22:58:27 RP: does poky lock revs differently Feb 21 22:58:34 khem, zeddii: Does poky change kernel versions? Feb 21 22:59:08 meta-yocto-bsp does have its own mind Feb 21 22:59:22 dont know if thats causing it Feb 21 23:00:20 RP: no version setting in poky that I know of, the qemu* is straight from oe-core and has always followed the PV + SRCREVs that I set. Feb 21 23:02:26 RP: i need the kernel image itself, so that i can build a fit. Feb 21 23:02:51 i don't need the headers and makefiles, etc Feb 21 23:03:50 mischief: you probably want a do_xxxx[depends] = "virtual/kernel:do_deploy" and then pull it from the deploy dir then? Feb 21 23:05:08 mischief: add kernel-image-zimage to IMAGE_INSTALL Feb 21 23:05:19 that should put it in /boot in rootfs Feb 21 23:05:29 zeddii: there is a pattern to the failures - all real hardware reference platforms you haven't moved to the new version? Feb 21 23:05:59 right. they are probably on 5.2, which I was leaving for my next series, and yes, it doesn’t have the same commit. Feb 21 23:06:25 zeddii: hence the failures Feb 21 23:06:40 apart from pkgman-non-rpm which is alsa-utils Feb 21 23:06:42 we’d either need to bump their 5.2 srcrevs (I could port the fix), or we need to move their default to 5.4 and update the SRCREVs Feb 21 23:07:25 oh wait Feb 21 23:07:29 it’s already building 5.4 Feb 21 23:07:39 it just needs a SRCREV bump. I can send that. Feb 21 23:10:52 RP: patch to the yocto list for the SRCREV bump. Feb 21 23:11:46 zeddii: thanks. I'll queue and retest Feb 21 23:14:57 * RP stops and starts a new build Feb 21 23:18:30 zeddii: we're going to get a lot of questions about this patch :/ Feb 21 23:21:10 khem: no no. i do not want the kernel in my root file system. i want to use the kernel image as an input to a recipe. Feb 21 23:21:26 RP: i can try that if it is not possible to get it into a recipe sysroot. Feb 21 23:22:54 mischief: Its either that or try the module style approach and see if it gets into STAGING_DIR_KERNEL, I don't remember Feb 21 23:25:51 fwict there is no such variable in poky Feb 21 23:32:03 mischief: sorry, I'm getting flashbacks from older times :( Feb 21 23:32:34 ah, STAGING_KERNEL_DIR Feb 21 23:35:00 mischief: have a read of make-mod-scripts_1.0.bb for ideas Feb 21 23:35:03 * RP -> Zzzz Feb 21 23:41:57 mischief: then do what RP suggested Feb 22 00:22:19 thank you! Feb 22 00:25:58 New news from stackoverflow: Yocto Bitbake Recipes for Nvidia Jetson Nano for Python whl files not on PyPi **** ENDING LOGGING AT Sat Feb 22 02:59:57 2020