**** BEGIN LOGGING AT Tue Nov 19 02:59:58 2019 Nov 19 05:18:29 khem: if I want to include compiler on target image (but it might be gcc or musl)... best practices? Nov 19 05:24:58 moto-timo: EXTRA_IMAGE_FEATURES_append = " tools-sdk packagegroup-core-buildessential" Nov 19 05:25:22 khem: right. thank you. must be tired Nov 19 09:25:42 hi Nov 19 09:27:16 is my understanding correct, that the mesa recipe packages a copy of the *same* file for every driver? Nov 19 09:28:02 i.e. a copy of the megadriver? Nov 19 09:59:00 bluelightning: hi, I'm trying to get qt4-embedded to compile on warrior but that does not work well ATM. I fixed builds for qemux86, qemuarm, qemuarm64 and beaglebone-yocto and one error on qemux86-64 but the latter is still failing (missing lrelease in native-sysroot) Nov 19 10:00:15 bluelightning: the qt4-embedded issue on warrior is because GCC v8 now refuses to compile `asm volatile` lines. As per the documentation, volatile is the default qualifier for asm so we should be good removing it Nov 19 10:00:49 qschulz: ok - if you could send your patch(es) I can apply them Nov 19 10:01:05 however, I saw this error only in some JavascriptCore JStubs file and nowhere else even though asm volatile is present in different files Nov 19 10:01:25 are you fine with a patch that is fixing the issues I saw even though it's not fixing all the `asm volatile` occurences? Nov 19 10:02:28 qschulz: yep that's fine, if others become problematic they can be fixed as and when Nov 19 10:04:44 bluelightning: ok! Expect some mails today and if not, scream at me tomorrow :) Nov 19 10:16:35 T_UNIX: no, it packages hardlinks Nov 19 10:17:20 ok Nov 19 10:18:10 look like in the mesa i have, there are two real libraries and lots of hardlinks Nov 19 10:42:20 yeah. My fault. Got mislead by `scp -r` instead of `rsync -rH` Nov 19 10:53:27 when trying to use tmux on a rather simple image, i get "tmux: need UTF-8 locale (LC_CTYPE) but have ANSI_X3.4-1968" Nov 19 10:53:30 any pointers? Nov 19 10:58:51 might the IAMGE_LINGUAS + GLIBS_GENERATE_LOCALES dance fix this? Nov 19 11:13:16 Hey everyone, How do I download a file with SRC_URI with different name? Nov 19 11:13:53 I am using SRC_URI = "https://fonts.google.com/download?family=Roboto" and it is downloading a the file as download?familly=Roboto Nov 19 11:20:29 hyper_dave: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#http-ftp-fetcher Nov 19 11:21:03 LetoThe2nd: does sound like you need a locale installed Nov 19 11:49:24 RP: yeah something along those lines Nov 19 11:58:57 If recipe A required artifacts from recipe B, but only for building, does recipe B need a "do_install" section for putting everything into like a STAGING_DIR_NATIVE? Nov 19 11:59:07 requires* Nov 19 12:03:25 jofr: thats usually the difference betwenn `DEPENDS` and `RDEPENDS`. Where `R` is short for runtime. Nov 19 12:04:18 do `A.bb` would contain a line like `DEPENDS += "B"` Nov 19 12:04:38 Yeah, I haven't been able to fully wrap my head around that. i.e. the full relation between DEPENDS vs. RDEPENDS and then native-recipes. Nov 19 12:05:11 did you read about `cross-canadian` in the context of compilation? Nov 19 12:05:38 Yes yes. Nov 19 12:06:05 So in my head, native recipes are for doing basically what I want. Provide stuff that should be used at compile-time Nov 19 12:06:27 But what then is the difference between depending and rdepending on a native recipe? Nov 19 12:07:07 usually you need the `-native` version only if you need to execute an architecture binary tool Nov 19 12:07:19 (when I say native, I mean a recipe the classextends and is used with the -native suffix) Nov 19 12:07:28 New news from stackoverflow: About the use of yocto toaster? Nov 19 12:11:07 jofr: look at http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/psplash/psplash_git.bb Nov 19 12:11:55 as you can see it invokes http://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/make-image-header.sh Nov 19 12:12:13 which, in turn, invokes `gdk-pixbuf-csource` Nov 19 12:15:08 so `psplash` eventually requires `gdk-pixbuf-native`, which might `DEPENDS`ed on `libpng-native` to be built and `RDEPENDS` on `libpng-native` to execute. Nov 19 12:16:18 but at the point of executing the recipe for `psplash`, it neglects the `DEPENDS` of `gdk-pixbuf-native` and only stages the files covered by mentioned `RDEPENDS`. Nov 19 12:16:37 which - in this very case - *might* be the same. Nov 19 12:18:34 jofr: if you think about linking architecture specific applications statically, it might make more sense. Nov 19 12:22:19 jofr: B should install its stuff into the sysroot like normal. A will depend on B, and A's sysroot has stuff from B in. Nov 19 12:22:50 rburton: Ok. I'll make up some paths then :) Nov 19 12:22:58 But thanks both of you :) Nov 19 12:23:01 jofr: rdepending on a native recipe makes no sense at all Nov 19 12:23:21 rburton: I just found out.. QA gave me a warning Nov 19 12:23:22 (unless you're a native recipe) Nov 19 12:24:37 jofr: so native recipes are entirely for stuff that *runs* at build time. if you've a recipe that just ships a pile of data that another recipe needs, then its still a target recipe. Nov 19 12:24:59 rburton: then, I assume, `-native` packages are depending on the corresponding `-native` version automagically? or are the handled in some parallel namespace? Nov 19 12:25:19 not sure i understand, got a concrete example? Nov 19 12:25:21 But for such an do_install section.. I think I might be too verbose: {D}${STAGING_DIR_NATIVE}${includedir}? Nov 19 12:25:31 (missing $) Nov 19 12:25:41 not STAGING_DIR_NATIVE Nov 19 12:25:46 Aight. Nov 19 12:25:47 install like normal, ${D}${includedir} Nov 19 12:25:54 Thanks! Nov 19 12:26:39 one day we'll do something awesome and lock down writes during builds so do_install can't write into directories it shouldn't be writing into Nov 19 12:29:34 rburton: And recipe A should DEPENDS on B-native? Nov 19 12:30:11 Or RDEPENDS on B? Nov 19 12:30:21 jofr: `-native` is not necessary if your data is not architecture specific to your build system :) Nov 19 12:30:48 jofr: do you need the data to be there, when you want to execute A on the target? Nov 19 12:31:20 Nope. Recipe generates (among other things) a header-file that recipe A uses when building. Nov 19 12:31:43 Nope. Recipe B generates (among other things) a header-file that recipe A uses when building. Nov 19 12:32:55 It's a bit convoluted, I know. But those artifacts from B are required my more than recipe-A. i.e. there are multiple recipe-A's ;) Nov 19 12:33:13 then B should provide and create some `-dev` package and `A` should `DEPEND` on `B` :) Nov 19 12:35:06 jofr: definitely no native involved Nov 19 12:35:56 jofr: its not convoluteld: you've a recipe that generates a header. put it in $D$includedir. Nov 19 12:36:10 you'll then also get a B-dev package for if you want to rebuild A on target for free Nov 19 12:37:36 New news from stackoverflow: Yocto recipes not found Nov 19 12:38:09 Nice. Thanks! Nov 19 12:38:36 Now. A completely different problem. Nov 19 12:38:48 Which I do have a workaround for, but I think it's ugly has hell. Nov 19 12:42:26 I have a recipe for a custom-package. But I would like to do that build as a part of our CI-system, and that includes building for pull-requests. I'm having some SRC_URI problems, because in that case, the "Git-path" isn't a normal branch (refs/head), but rather a pull-branch (refs/pull). Anyone solved that problem before? Nov 19 12:44:44 The branch-name (and commit-hash as well actually) is passed as an evironment variable (which I have whitelisted and all that is fine), and I have Python snippet that mangles the SRC_URI to conditionally add the "nobranch=1" if that branch-name starts with "refs/pull". Nov 19 12:45:28 Isn't there a better solution? Nov 19 12:47:41 Hi All, I am new to this chat. Learning my way in to Yocto (and IRC) Nov 19 12:49:44 Hi, bigMT1 :) Nov 19 12:49:53 bigMT1: welcome! Nov 19 12:53:33 rburton: One last question. Recipe B installs its stuff to ${D}${includedir}, but what is the full-path on the other-side, from recipe-A's perspective? Nov 19 12:53:56 ${D} isn't the same on both sides, is it? Nov 19 12:54:53 (I wish those variables were populated in the -c devshell) Nov 19 12:55:49 D is Destination Nov 19 12:55:53 jofr: it's going to be in recipe-sysroot (or recipe-sysroot-native if native package) Nov 19 12:55:55 when installing, write to D Nov 19 12:56:05 the include file will just be in the sysroot like every other include file Nov 19 12:57:31 Yes.. But if I have other files where I need to specify their full path? Nov 19 12:57:55 jofr: IRL example? Nov 19 12:58:52 (IIRC, a few tools get a --sysroot argument from yocto before executing any stuff on the source code of recipes) Nov 19 12:59:38 A newbie question i suppose: I have build a default image for a raspberry pi. It boots, but my keyboard does not work. The screen shows messages that identifies the keyboard when I (re-plug) the keyboard in another port. Any suggestions? Nov 19 13:01:35 jofr: STAGING_DATADIR etc will be the absolute path into the sysroot Nov 19 13:01:45 bigMT1: missing driver is the kernel Nov 19 13:01:49 is/in Nov 19 13:02:01 jofr: note that not everything is in the sysroot by default, ie $datadir isn't included unless you tell it Nov 19 13:05:19 Yeah, I think I should just explain the whole thing. So what I'm messing with is the u-boot-environment. I have an environment specified in a file. Then I have a Python parser that parses that file and makes it nice for a header-file which is then #defined as CONFIG_EXTRA_ENV_SETTINGS in u-boot. So what I used to do was generate that header and then copy it into ${S}/include/configs where ${S} has been defined as the WORKDIR/git for the u Nov 19 13:05:19 -boot recipes. This header file is used by u-boot, but also for u-boot-fw-utils. Nov 19 13:05:19 Now I've added another dependency on such an output, that one is actually not using the same parser, because the output-format needs to be slightly different, but it mangles the same u-boot-environment to make it compatible for passing to (U-Boot) fw_setenv --script (this can happed at update-time if required). That part actually doesn't need to go anywhere in the sysroot, I can just "deploy" it to the image-folder (similar to some other Nov 19 13:05:19 final-artifacts). Nov 19 13:06:00 So, In order not to change my u-boot build too much, I would really like to copy this header to ${S}/include/configs in U-boot.. Nov 19 13:07:16 why don't you use bbappends for U-Boot directly? Nov 19 13:09:12 put your logic in an .inc shared by both u-boot and u-boot-fw-utils and add them in bbappends so you don't duplicate code. But I feel like I'm suggesting something you didn't want or that is not fixing your issue, what am I missing? Nov 19 13:56:56 qschulz: That's what I had at first. So I just had a "files" folder and in my bbappend, I copied my files/_defconfig, my files/.h (the one I'm talking about here), etc. into the appropriate places within ${S}. But then me and other people found it so annoying to maintain the .h with the #define CONFIG_EXTRA_ENV_SETTINGS, making sure that the newline-escapes (the "string" \ ) were always ok, etc. S Nov 19 13:56:56 o I created this parser-thing that takes a nicer input, where the environment can be properly indented and so on and turns it into the string required by #define CONFIG_EXTRA_ENV_SETTINGS. Nov 19 13:56:57 Now the update-system has gotten a little more complicated than it used to be. The update didn't update u-boot at all, and actually still doesn't, but it may require changes to the u-boot environment. So at build-time, the environment that gets compiled into the new u-boot as the default-environment, also gets output to a file that's compatible with "fw_setenv --script" so it can be used to update the u-boot-environment on the target. Tha Nov 19 13:56:57 t required another parser, because now instead of doing the "" \ business, it needs to remove newlines from each variable and so on. That environment-file/script then gets released with the update. Nov 19 14:01:30 So what I have now is a recipe called "u-boot-extra-env-settings(.bb)" and everything that it entails. Then u-boot and u-boot-fw-utils depend on this new recipe, and that's how it now gets its .h file. But, then there's the update system. That's a recipe that creates a "package", which is just a zip-file that consists for the artifacts, a JSON-manifest and a update-shellscript. That recipe required this other output from "u- Nov 19 14:01:30 boot-extra-env-settings". Nov 19 14:03:16 s/for the artifacts/of the artifacts/ Nov 19 14:30:34 jofr: find a way for u-boot to take header files from the sysroot, don't copy it from your custom recipe's syrsroot to u-boot icnlude/configs. Nov 19 14:31:36 jofr: also, maybe you can use your u-boot-extra-env-settings binary as a native tool in your u-boot* recipes and create the header file directly in your u-boot* source code Nov 19 14:52:15 Hey everyone, How can I manually trigger the build of a package? Nov 19 14:52:28 starting from do_fetch Nov 19 14:52:59 bitbake -C fetch Nov 19 14:53:39 Okay, thanks Nov 19 15:02:57 just bitbake [recipe] will work unless you want to force a rebuild Nov 19 15:03:05 in which case -C fetch is the trick Nov 19 15:03:35 i prefer -C unpack if you don't need to force a re-download Nov 19 16:29:14 armpit: am I up to date with patch merging for the stable branches? Nov 19 16:30:45 let me check Nov 19 16:31:47 armpit: FWIW I want to get this hashequiv fix I'm working on into zeus Nov 19 16:32:55 RP, you are up to date Nov 19 16:33:02 k Nov 19 16:33:13 armpit: great, thanks Nov 19 16:41:59 adelcast: I was thinking more about the error handling in opkg - I think the "easy" fix may be to leave the collected error code but *also* print it at the time it happens? Nov 19 19:29:10 I am trying to be a good citizen when it comes to shared library sonames. Yocto is forcing me to do so, actually. Nov 19 19:30:27 In my project I am using opkg. Let's say that a project, bar, links to libfoo.1.2.so. Can I upgrade libfoo to libfoo.1.3.so (which are ABI compatible) without updating all of the packages which depend on libfoo? Nov 19 19:30:40 What happens to libfoo.1.2.so when the package is upgraded? Nov 19 19:31:59 and, yes, I mean libfoo.so.1.2 etc. Nov 19 19:34:54 I see for things like libglib executables link to libglib-2.0.so.0 which is a symlink to a specific version. Nov 19 19:35:38 if it's compatible, then the new version needs to provide BOTH 1.3 and 1.2 sonames Nov 19 19:36:01 usual failure is someone releases 1.3, with a 1.2 compatible ABI, but never defines BOTH the 1.3 and 1.2 sonames Nov 19 19:36:28 the YP build system inspects libraries, and if they're not defined right you will get dependency errors Nov 19 19:37:39 I will aim for that Nov 19 19:37:56 not the usual failure case, multiple sonames Nov 19 19:38:38 does that mean multiple -Wl arguments to ld? Nov 19 19:39:30 sorry I don't have an example offhand Nov 19 19:39:53 darn. I'll dig through recipes I guess. Nov 19 19:40:24 usuaully not recipe specific, but buried in the upstream code.. Nov 19 19:40:34 but ya, it's multiple -Wl arguments, just don't remember the format offhand Nov 19 19:41:20 gcc -shared -o libfoo.so.x.y -Wl,-soname,libfoo.so.x some_file.o ... Nov 19 19:41:25 try specifying -soname multiple times Nov 19 19:41:39 recipe processing will automatically see this, and setup everything Nov 19 19:41:44 I have libraries which, for better or worse, are done in a Makefile.. so I'm the buried upstream code at the moment. :-) Nov 19 19:41:51 roger Nov 19 20:08:51 New news from stackoverflow: Yocto generated linux modules do not contain all the drivers selected in config Nov 19 21:39:04 New news from stackoverflow: Unable to add Kernel Module in the final image Nov 19 21:57:30 JPEW: an interesting dilemma. How do we clean things out of the hash equiv database when we realise something is broken? Nov 19 21:58:00 RP: Ya, that is a interesting situation Nov 19 22:00:09 RP: Did you run into a problem with that? Nov 19 22:01:35 JPEW: we have zero size broken packages in the sstate cache :/ Nov 19 22:01:46 I'm just not sure how to clean them out :( Nov 19 22:02:14 I guess if I remove them the hadhequiv entry is less of an issue than the broken sstate Nov 19 22:02:51 RP: I would expect so... only another broken package should (theortically) be detected as equivalent Nov 19 22:03:47 Bump PR on the broken recipes? Nov 19 22:04:06 JPEW: I don't know exactly which broke :( Nov 19 22:04:16 RP: Ah, well, that won't work then Nov 19 22:04:41 Are they completely empty? Nov 19 22:04:51 JPEW: yes, I think so Nov 19 22:05:50 JPEW: well, they're packages with no files so they have control data but no actual files Nov 19 22:06:03 Hi, I am trying to build an image for my Raspberry Pi. Using straightforward the poky warrior, meta-raspberrypi and meta-openembedded. I managed to boot it, it recognizes my keyboard but does not work. It has been suggested to include keyboard drivers to the kernel. How do I do this? Any help appreciated for this newbie. Nov 19 22:06:46 bigMT1: sounds like you need to change the kernel defconfig and add in the pieces you need, then rebuild Nov 19 22:06:47 RP: Ah, I was thinking that they might all have the same outhash in the hashequiv database, but even if they were completely empty, it still wouldn't be the case because the outhash has a few recipes specific vars hashed in Nov 19 22:07:26 RP: Do you have an example or a link at hand? Nov 19 22:07:54 bigMT1: I'm afraid not Nov 19 22:08:04 JPEW: right, its not a simple issue :/ Nov 19 22:08:49 RP: Anyway, I still think that the hashequiv part isn't a huge deal... it would only match in the event you re-created that same output anyway (which seems unlikely). Nov 19 22:09:11 Hi all, does anyone know why attr depends on kernel? Nov 19 22:09:23 The other option is to delete all hashequiv recipes for the broken recipes (assuming you can find which they are, which appears the be the bigger problem) Nov 19 22:12:49 "attr.do_build" -> "linux-yocto.do_deploy" Nov 19 22:12:56 it is not clear from the recipe =\ Nov 19 22:14:22 JPEW: what is worrying me is how this problem persisted over some changes :/ Nov 19 22:14:37 something isn't adding up Nov 19 22:14:52 RP: Was it undetected? Nov 19 22:17:15 JPEW: I added some tests to do_package so empty packages are detected. I'm assuming I fixed the hash equiv runqueue issue that generated them. I guess I should change it again to make it error, that should invalidate all hashes. I guess it means there is still a latent runqueue bug Nov 19 22:17:29 too many different issues at once :( Nov 19 22:20:58 RP: 59b7001767d ("bitbake: runqueue: Fix hash equivalence duplicate tasks running") ? Nov 19 22:21:36 I *think* that change won't cause the taskhashes to change, meaning the hashequivalence server won't know the hashes are equivalent. Nov 19 22:21:47 *aren't equivalent Nov 19 22:24:20 JPEW: That won't but the package.bbclass change in OE-Core will Nov 19 22:30:42 RP: Sorry, I have to go :( You might be able to find the taskhashes before and after than change in the database and validate that they do indeed have distinct outhashes? Nov 19 22:36:39 JPEW: np, thanks. I need to think further about what is going on I guess Nov 20 01:35:25 may be is a known issue but i'm accessing shared states trought NFS mount (SSTATE_MIRRORS = "file://DIR") and there is no progress information available, Currently 4 running tasks (0 of 0) 100% **** ENDING LOGGING AT Wed Nov 20 02:59:58 2019