**** BEGIN LOGGING AT Tue Aug 20 03:01:37 2019 Aug 20 07:29:02 Hello guys, I would to build and use a tools during the image generation, i think the class is the better way to do but I don't know how to build the binary for the host and note for the target ... any advice ? cheers Aug 20 07:41:47 PinkSnake, you can add a native only recipe for the host binary you need Aug 20 07:42:06 and use it through DEPENDS in other recipes where needed Aug 20 07:49:48 mihai sounds good ! Thx. But do you know i can 'install custom tool in order to call it from the recipe ? Maybe i'm wrong and it's the better way :S Aug 20 07:52:23 PinkSnake: Yes you can Aug 20 07:53:01 @jofr I'm trying BBCLASSEXTEND += "native", keep in touch ;) Aug 20 07:56:18 PinkSnake: Yes. And then in your other recipe you "DEPENDS" on yourrecipe-native" Aug 20 07:57:33 @jofr it's the same if I use a bbclass instead of a recipe ? Aug 20 07:58:19 i.e. Your devtoolrecipe "BBCLASSEXTEND"s, has a proper do_install section, and then you have yourotherrecipe "DEPENDS" on devtoolrecipe-native Aug 20 08:00:08 No, you are only creating (.bb) recipes. Aug 20 08:01:24 The "native.bbclass" already exists. Your devtoolrecipe is just "using" it. Aug 20 08:22:02 PinkSnake: Something like this? https://gist.github.com/johannfr/4c08bc904665be60e93477b6e4bee666 Hopefully I'm not just confusing you even more :p Aug 20 08:23:36 @jofr exactly what I would like to do, i have to fix my install methode and should be okay, thx ! Aug 20 09:07:23 if oe-pkgdata-util find-path *libfreetype.so.6 reports that 2 recipes provide that library, and one of them is in PRIVATE_LIBS, is there a command that I can see that runtime dependency resolver will include in image the right one? Aug 20 09:08:25 jofr All right ! tha again ;) Aug 20 09:18:45 RP: have you had a chance to look at the second version of toolchain testing RFC? looking to clean it up as a patch series this week Aug 20 09:18:59 PinkSnake: No problem :) Aug 20 09:26:45 RP: so meta-darwin, do you remember how much of the osx sdk is needed? just libc and a few friends, right? Aug 20 09:27:06 RP: wondering how much effort it would be to bootstrap it using https://github.com/darlinghq instead Aug 20 09:27:41 ooh, or even better https://github.com/phracker/MacOSX-SDKs Aug 20 09:32:46 rburton: right, it doesn;t need much Aug 20 09:33:41 nrossi: I did quickly read through it and worried you were starting to overlap with the test result handling elsewhere in oeqa but in general its good Aug 20 09:38:17 RP: hm meta-darwin also builds 32-bit binaries, which are pretty much deprecated on modern macos Aug 20 09:52:21 rburton: its been a while since it was touched! Aug 20 09:52:37 rburton: switching it to 64 bit should be fine Aug 20 09:55:09 2015! Aug 20 09:55:22 rburton: thats more recently than I thought! Aug 20 09:58:28 RP: you mentioned there was some filtering stuff in oeqa, but I was not sure what you were referring to, got an example testcase that makes use of it? Aug 20 09:59:46 is zeus 2.8 or 3.0? Aug 20 10:01:00 nrossi: sorry, I should be clearer. We don't filter the results, we write all of them into the testresults.json files and then the plan is to handle the filtering at a later stage Aug 20 10:02:09 nrossi: Ultimately the idea is that resulttool regression/report would handle this Aug 20 10:02:29 mihai: 2.8 became and is 3.0 Aug 20 10:04:01 RP, ok, thanks Aug 20 10:04:04 RP: I see, so should each testsuite output each test case that failed/etc as part of the testresults.json? Aug 20 10:04:30 nrossi: yes, that would be the best way to handle things I think Aug 20 10:04:53 RP: so it should be similar to how ptest works? Aug 20 10:04:58 nrossi: Given the number of cases, I think its going to end up working like ltp/ltp posix/ptest Aug 20 10:05:02 nrossi: yes Aug 20 10:05:25 nrossi: we might need to generalise that code a bit... Aug 20 10:13:34 RP: ok so just looking at the resulttool part, there does not appear to be any filtering instead its based on regression vs previous executions. Is that right or am I missing something? Aug 20 10:15:08 nrossi: you're right, the plan was to add more filtering but we're not there yet Aug 20 10:15:41 nrossi: what I'm worried about is having this kind of thing in multiple places. It really belongs in resulttool and the test data should always be saved Aug 20 10:17:56 RP: it makes sense, I am just not very familar with it all. At the moment though there is not a large amount of tests that need filtering, so maybe I should stick to having the results fully populated for resulttool and skip filtering in this series? Aug 20 10:18:10 nrossi: sorry, I'm explaining this badly. This is why I hadn't gotten to reply to the email :( Aug 20 10:18:30 nrossi: Probably, yes. Unless there are any tests that hang in which case its find to skip those Aug 20 10:18:33 RP: thats ok, I know you have been very busy Aug 20 10:18:55 nrossi: I do like the info you've got in the series about the expected results Aug 20 10:19:48 hash equiv's last build seems to have gotten a lot worse :( Aug 20 10:22:32 RP: ok, so I think that has sorted out the plan for the patch series. will have to look into the filtering as a separate part. Did you have any opinion on the qemu-user use for gcc tests? given the improved results Aug 20 10:30:20 nrossi: I don't really trust qemu user :/ Aug 20 10:30:49 nrossi: thats purely because I have an idea of what its doing and all the ways it can break having looked at the code... Aug 20 10:31:22 nrossi: so basically I'm torn Aug 20 10:34:38 RP: for gcc it is probably worthwhile using qemu-user due to the runtime speed. And the gcc tests are created with running in a simulator in mind. But it is also probably worth running the tests against qemu system and physical hardware for a release Aug 20 10:35:21 nrossi: having configuration that allows us to do both is certainly great and yes, I agree Aug 20 10:38:50 RP: did a next build last night and it died in all sorts of exciting ways Aug 20 10:38:58 gstreamer and systemd failed to compile Aug 20 10:39:21 rburton: hash equiv enabled or disabled? Aug 20 10:39:26 disabled i think Aug 20 10:39:38 rburton: I thought there might be bad patches in there :/ Aug 20 10:42:04 hm swear i did a build last night and this morning its rebuilding Aug 20 10:42:10 i wonder what i poked since Aug 20 10:43:10 ah Aug 20 10:43:41 is it intentional that changing BB_HASHSERVE or BB_SIGNATURE_HANDLER causes a full rebuild? Aug 20 10:44:58 New news from stackoverflow: Bitbake do_rootfs failure for syslog-ng Aug 20 10:45:20 rburton: that depends. It if no longer has the equiv data it would rebuild stuff Aug 20 10:45:38 i had it set yesterday, disabled this morning and caused a rebuild Aug 20 10:46:00 rburton: it can no longer see things are equivalent so yes, I'd say that is expected Aug 20 10:46:09 yeah fair enough Aug 20 12:12:14 RP, Did an incremental build of my distro, going from bitbake/oe-core master to master-next, with hashequiv enabled, no issues Aug 20 13:24:59 * zeddii searches for the core-image-sato test results Aug 20 13:38:37 can anyone here share experiance with NAND-flash boards? We are thinking of switching from rpi, so that someone won't just copy the SD card and easily reproduce our distribution. Aug 20 13:38:42 I'm guessing it's only a matter of switching the machine layer? Aug 20 13:40:34 kayterina NAND-flash are not really "easy to use", you have to use MTD partition with or without file system support ;) , if you have choice, you should choose emmc Aug 20 13:41:59 but...it is not easy even with yocto? Aug 20 13:43:20 there are some myirtech boards that says "256Mb NAND-flash" Aug 20 13:43:40 and there is MTD support in the linux kernel Aug 20 13:44:19 and JJFS filesystem Aug 20 13:54:17 RP: do you happen to have a link where I can look at the test history ? I can’t find it this morning. I’m not able to get sato graphics on any x86-64 build. So it isn’t my new kernel or headers, since I’ve gone all the way back to 4.19 and can’t get anything to work. qemuarm64 did work, so I know the qemu build, etc, is at least somewhat sane. Aug 20 14:02:52 zeddii: http://git.yoctoproject.org/cgit.cgi/yocto-testresults/ Aug 20 14:04:27 thanks! Aug 20 14:04:32 * zeddii clicks and looks. Aug 20 14:11:40 hmm. X is running, I just can’t connect vncview to it. Aug 20 14:17:38 zeddii: I think it does work but I haven't personally checked recently Aug 20 14:58:23 https://autobuilder.yocto.io/pub/non-release/ is down. Who handles that server? Aug 20 15:02:10 apparently it's just my connection, so nevermind. Aug 20 15:14:36 vmeson, I'm the person to ping about that server. Aug 20 15:15:42 New news from stackoverflow: RTOS on kw41z. Yocto project Aug 20 15:26:14 guys, I have a problem understanding the sysroot thing. In yocto 2.4.4, the webkitgtk recipe fails to compile because of some conflicting typedefs in [...]/recipe-sysroot/usr/include/GL/glext.h Aug 20 15:27:08 From what I've understood from the yocto manual, the sysroot in the workdir of a recipe is for pulling in dependent headers Aug 20 15:27:56 So, when I need to patch one of these headers, I guess I should patch that in the originating recipe rather than in the webkitgtk recipe, right? Aug 20 15:28:03 hello folks Aug 20 15:28:13 is it possible to access the image/ folder of a recipe from another recipe? Aug 20 15:28:53 our installer recipe needs to package the data of our firmware recipe and encrypt it. so it needs access to the image/ (like devtool does it) Aug 20 15:29:19 e.g. package A depends on header B.h from recipe B, I should patch B.h with a B.bbappend recipe... Aug 20 15:30:02 yes Aug 20 15:30:07 nameclash, that's correct Aug 20 15:30:51 However, I have a hard time finding the source of GL/glext.h -- when I grep through the yocto layers for do_populate_sysroot() I get very few matches Aug 20 15:31:20 I'm stuck on finding the source recipe for GL/glext.h Aug 20 15:31:56 nameclash: just use oe-pkgdata-util Aug 20 15:32:06 you can use that to search for the package/recipe that provides it Aug 20 15:32:34 ah ok -- will look into it, thx! Aug 20 15:34:30 but you can only use it if you already have the package built, as far as I know? Aug 20 15:34:52 sometimes, I wanted to know what recipe/package provides a certain file without having built it. I wasn't able to make that work Aug 20 15:45:47 New news from stackoverflow: How to install files in the native sysroot with yocto when doing populate_sdk? Aug 20 15:46:13 Stupid question : I would like to override SSCACHE_DIR variable from the setup-env but the following cmd (export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SSTATE_DIR") doesn't seem to work... any tips ? :) Aug 20 15:59:50 ok, not yet there.. Aug 20 16:00:14 I ran: oe-pkgdata-util find-path /usr/include/GL/glext.h Aug 20 16:00:29 which gave me: Aug 20 16:00:31 libgl-mesa-dev: /usr/include/GL/glext.h Aug 20 16:01:03 then I ran: oe-pkgdata-util lookup-recipe libgl-mesa-dev Aug 20 16:01:22 which gave me 'mesa' as the recipe in question Aug 20 16:02:22 however, to be able to create a patch for glext.h, I need to cd into the sources dir of the mesa recipe (afaik) Aug 20 16:03:56 my problem is, I can't find any sources fetched for mesa Aug 20 16:04:23 nameclash, try 'devtool modify mesa' Aug 20 16:05:21 user@devbuntu:~/os/yocto/build$ find . -name glext.h./tmp/work/cortexa9t2hf-neon-montavista-linux-gnueabi/webkitgtk/2.18.6-r0.5/recipe-sysroot/usr/include/GL/glext.h./tmp/work/cortexa9t2hf-neon-montavista-linux-gnueabi/webkitgtk/2.18.6-r0.5/recipe-sysroot/usr/include/GLES/glext.h./tmp/sysroots-components/cortexa9hf-neon/mesa/usr/include/GL/glext.h. Aug 20 16:05:21 /tmp/sysroots-components/cortexa9hf-neon/mesa/usr/include/GLES/glext.h Aug 20 16:05:36 ok kanavin Aug 20 16:11:49 kergoth, kanavin, thank you guys, saved my evening! Aug 20 16:14:06 if devtool works as charming as advertised in https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe then it's a pretty decent tool to know! Aug 20 16:22:29 nameclash, devtool is by far the most underrated and not widely known tool in yocto. Aug 20 16:23:05 I would probably add a notice about it to the default env init banner Aug 20 16:23:59 RP: back now. yah, it *appears* to be running, so I asssume it works. but vncviewer attachs and detaches immediately with “Unknown message type 190 from VNC server” .. google isn’t useful for what that is yet. Trying to see If I can figure out how to build SDL instead. Aug 20 16:26:35 kanavin: agreed. recipetool too. the two both provide a lot of value. actually every tool we have other than bitbake itself is probably not as well known as it should be. even bitbake-layers Aug 20 16:27:33 Hmm, i bet a lot of folks don't know you can replace arbitrary config files on the target with recipetool appendfile, or in the source with appendsrcfile Aug 20 16:34:07 is yocto warrior broken for rpm package types? i get: Aug 20 16:34:09 ERROR: core-image-minimal-1.0-r0 do_rootfs: Could not invoke dnf. Aug 20 16:34:20 ... Aug 20 16:34:21 ModuleNotFoundError: No module named '_curses' Aug 20 16:34:24 in do_rootfs Aug 20 16:42:36 derRichard, probably not, as it is tested on the autobuilder Aug 20 16:43:00 kanavin, kergoth: I'd take a patch to the oe-build-init-env script... Aug 20 16:44:30 kanavin: maybe a host-system related issue, i'll dig into it Aug 20 16:44:38 i'm on opensuse 15.1 Aug 20 16:44:59 RP: I am just trying to figure out why do we have two copies of conf/conf-notes.txt, in meta and meta-poky Aug 20 16:45:58 New news from stackoverflow: Controlling SAMA5D27-SOM1-EK1 Board LEDS using DEVICE-TREE file in linux kernel Aug 20 16:46:52 RP: as that is where the banner is. maybe best left for tomorrow Aug 20 16:50:41 hm that reminds me, i dont think i ever got the change merged to split cooker construction from bitbake.conf parsing to allow bitbake-layers to avoid parsing errors due to layer addition/removal order Aug 20 16:50:45 oops Aug 20 16:50:55 * kergoth wonders where he put that old branch Aug 20 17:16:03 New news from stackoverflow: List packages which will be included in host Yocto SDK Aug 20 17:32:17 what is the right way to make sanity.bbclass use my custom local.conf.sample instead of pokys? Aug 20 17:38:57 hm, i suppose i need to make a distro layer. Aug 20 18:27:54 RP: I think I've figured out how to improve the hash equiv server performance by a factor of 5 Aug 20 18:31:11 wow Aug 20 18:36:22 The thing I'm not sure about is how to structure the protocol Aug 20 18:45:08 JPEW: have you tried enabling keep-alive? Aug 20 18:45:12 (or do you already) Aug 20 18:45:28 assuming lots of connections come from relatively few clients, that could help a lot Aug 20 18:47:21 Ya, reusing connections is part of the improvement. Unfortunately, python's urllib doesn't let you do that, so we'll have to manually Aug 20 18:47:49 i saw the server can be made to do keep-alive but didn't look at the client Aug 20 18:47:53 embed a copy of requests? Aug 20 18:47:55 Right Aug 20 18:48:21 requests has quite a few dependencies Aug 20 18:48:26 https://bgw.github.io/Century/library/plugins/keepalive.html? Aug 20 18:48:56 some days i wish bitbake was handled the way most python projects are. install with pip, etc. harder due to the tight interdependence with oe-core, though Aug 20 18:49:14 kergoth: i absolutely wish that bitbake had a requirements.txt Aug 20 18:49:19 kergoth: I really like pipenv... I use it all the time for my projects Aug 20 18:49:29 pipenv is handy indeed. poetry is pretty nice too Aug 20 18:49:47 But, it might be academic because the other big improvement is to optimize the protocol to not send full HTTP headers for each hash lookup during signature generation Aug 20 18:51:17 You can to this over HTTP, using the "Upgrade" header a la websockets. We can negotiate a HTTP connection to a simple byte orientated TCP connection (which is exactly what websockets do) Aug 20 18:52:11 So, we could 1) just use websockets, 2) make our own Upgrade procotcol over HTTP 3) ditch HTTP completely and use a JSON over TCP protocol Aug 20 18:52:43 can a package that depends on a virtual provider be generic (arch) or should it be marked as machine-specific? as it records the actual provider and not virtual Aug 20 18:52:52 Each has advantages and disadvanges. Aug 20 18:58:16 rburton: maybe you know? see above Aug 20 18:58:42 if the provider is machine specific you should make the recipe machine specific Aug 20 19:00:19 hello is anybody here with experience with external toolchains used in yocto? Aug 20 19:00:29 I have this issue and not sure how to resolve it: https://lists.yoctoproject.org/pipermail/yocto/2019-August/046391.html Aug 20 19:00:56 rburton: so, let's say there are machine-specific providers for GLES in Aarch64 world. does it mean all the recipes that RDEPEND on virtual/libgles1 have to be machine-specific? e.g. gstreamer-plugins-base, etc. Aug 20 19:05:42 would be nice if the apps would link to the generic soname, as the generated deps should be using the generic names too Aug 20 19:17:12 rburton: even when the app links to a generic libGLES.so, the package (at least opkg) ends up recording dependency to a specific machine package (e.g. TI SGX or RPi VC4), even though those are marked as providers for libgles1/2, etc. Aug 20 19:18:43 afaik it *should* go purely based on the SONAME, so if that doesn't change, it should work.. Aug 20 19:21:10 kergoth: what if there are bunch of SONAMEs in a package, but it sets R/PROVIDES for all of them? Aug 20 19:21:59 doubt it matters unless you override or disable shlibs, as that goes by soname Aug 20 19:22:06 * kergoth shrugs Aug 20 19:22:17 keith: should each lib gets packaged into own package instead of one bundle? Aug 20 19:22:31 kergoth: sorry^^^ Aug 20 19:57:31 kergoth, rburton: and a related question - even when a package depends on SONAME, different providers will have different versions. the package will have Depends: SONAME (>= X.Y.Z) and X.Y.Z will be widely different per machine Aug 20 19:58:34 good point. it sounds like this may be a case where manual is superior to shlibs for rdepends/rprovides handling Aug 20 19:59:48 kergoth, rburton: e.g. gstreamer-plugins-base records it depends on libgles1 (>= 19.0.0) and I have libgles1 for my platform that is lower... Aug 20 20:00:19 kergoth: are there examples of manually driving shlibs rdepends? Aug 20 20:00:58 not a clue. ideally we'd only disable it for these libs, otherwise we'd have to also manually add libc, etc Aug 20 20:01:12 i.e. EXCLUDE_FROM_SHLIBS is likely too large an implement for this case Aug 20 20:01:42 check package.bbclass, thats' where it's handled Aug 20 20:02:46 ok, thanks Aug 21 01:28:28 halstead: hey Michael, can you take a look at why meta-freertos is not being indexed?, thanks! **** ENDING LOGGING AT Wed Aug 21 02:59:58 2019