**** BEGIN LOGGING AT Wed Jul 24 02:59:57 2019 Jul 24 04:53:52 zeddii: do you have plans to bump linux-libc-headers to newer than 5.0 soon'ish Jul 24 04:59:54 that is 5.2+, there is this change https://github.com/torvalds/linux/commit/35341ca0614ab13e1ef34ad4f29a39e15ef31fa8 that will fix bunch of packages on aarch64/musl which use ptrace stuff Jul 24 05:02:41 zeddii:see https://git.openembedded.org/openembedded-core-contrib/commit/?h=yoe/mut&id=16b5032528164fd4063c86e52ced95a4266b4a63 Jul 24 05:24:26 Hi, I have some problems to build a package "grpcSandbox", which depends on gRPC and protobuf. There already exists recipes for gRPC and protobuf which builds well. Jul 24 05:25:40 However, I do not really understand how to link from my grpcSandbox package, to the shared libs from gRPC and how to execute the meta-compiler "protoc" which is provided by protobuf. Jul 24 05:28:27 This is the recipe for grpcSandbox: https://pastebin.com/anzQVYiF Jul 24 05:31:31 When I start the devshell for package grpcSandbox, I expected that the executable "protoc" from protobuf would be known, since I listed it as dependency. Its not available. What is the problem here? Jul 24 06:07:05 New news from stackoverflow: How to access protoc compiler in own Yocto package and reference to gRPC libs Jul 24 06:08:35 ThomasD13: it should probably be a couple of things. protoc is to be executed on the host, so you need to depend on the -native version of it Jul 24 06:09:49 ThomasD13: stupid idea, have you outright grepped meta-openembedded or such for protobuf to find any already existing users that could be used as inspiration? Jul 24 06:15:17 Hi LetoThe2nd. Okay, so the native thing is first which I will try. No I didn't grepped for protobuf recipes already. Thats a good idea, I will try to find any references Jul 24 06:18:53 But is my asumption correct, that in the sysroot directory of package grpcSandbox should be the stuff available, which I declared as DEPENDS within its recipe? Jul 24 06:20:02 ThomasD13: yes and no Jul 24 06:20:28 ThomasD13: in the target arch sysroot those things that you declared DEPENDS should be available. Jul 24 06:20:48 ThomasD13: so the library to link against should be there. Jul 24 06:21:32 ThomasD13: whereas any compiler, preprocessor, tools, etc. that are to be executed at build time are not supposed to be there. in your case, protoc. Jul 24 07:53:40 LetoThe2nd, okay that is good to know. However, is it possible to make protoc at build time (on my native sysroot) available? Exists even are generic solution for this kind of task? Jul 24 07:55:15 Thats what DEPENDing on a -native recipe is meant for :) Jul 24 07:55:33 ThomasD13: the -native in a package name has basically exactly that meaning. Jul 24 07:56:39 Okay, so when my recipe looks like this: DEPENDS_${PN} += " protobuf protobuf-native grpc" Jul 24 07:56:49 it should theoretically work Jul 24 07:57:36 But what can I do when it does not?? I don't know where to even start to look at... Jul 24 07:58:57 the next step would be to look and see if the protobuf packages are actually what you want, or if the protoc tool is not put into a distinct package Jul 24 07:59:09 and, DEPENDS is usually without _${PN} Jul 24 07:59:21 alright, thank you ;) Jul 24 08:07:24 New news from stackoverflow: Find Codeaurora oe installation manifest [on hold] Jul 24 08:16:40 what is the best way to change systemd journal config to use volatile storage? Jul 24 08:19:09 ricardocrudo: AFAIK this should be the default Jul 24 08:34:12 LetoThe2nd the file installed by bitbake has Storage=auto Jul 24 08:36:06 ricardocrudo: are you sure that this comes from generic poky and not from some bsp/layer? Jul 24 08:46:02 LetoThe2nd: yes, I just tested Jul 24 08:46:22 ricardocrudo: hm Jul 24 09:01:26 ricardocrudo: well the read-only-rootfs IMAGE_FEATURE triggers it, AFAIK. maybe find some inspiration in meta/recipes-core/volatile-binds/volatile-binds.bb Jul 24 09:07:35 New news from stackoverflow: How to create a custom recipe for MQTT in yocto? Jul 24 09:37:39 New news from stackoverflow: Yocto - using extensible SDK with multilib Jul 24 10:37:47 New news from stackoverflow: Replace mosquitto.conf file with bbappend? Jul 24 10:50:08 Mmmm people? If a patch I sent one the mailing list for backporting and isn't part of thud or thud-next branch nor in the latest review request (30 or so patches a few days ago), it's most likely not going to make it for 2.6.3 is it? Jul 24 10:56:17 qschulz: its looking tricky. Which patch? Jul 24 10:56:30 for opkg Jul 24 10:56:36 let me get the link in the archive Jul 24 10:57:09 https://lists.yoctoproject.org/pipermail/poky/2019-June/011777.html Jul 24 10:58:27 qschulz: right, I remember the discussion. We should fix that. Not sure what armin's plans are here though. Those patches do have higher risk Jul 24 11:27:48 RP: yes, I do understand. I just wanted to make sure they are not forgotten, so that they're merged one day or at least discussed a little bit more to find something that suits poky more Jul 24 11:29:57 qschulz: well, they are merged in master, its just a question of the stable series Jul 24 11:32:33 RP: yes sorry, merged in thud/any release affected by the same bug is what I meant Jul 24 11:35:46 qschulz: I think I'd remind Armin about them. Only trouble is I know he's now travelling Jul 24 11:40:02 RP: "I" in the sense "If I was in your boots" or "I" in "I, RP, would"? Jul 24 11:45:32 the boots one Jul 24 11:50:56 LetoThe2nd You are a hero ;) Thank you very much, my package compiles now (install still fails but I think I'm able to fix that too) Jul 24 11:53:27 ThomasD13: :) Jul 24 11:54:48 Main problem was DEPENDS_${PN}. Changing that to DEPENDS resulted in available protoc and libs/headers Jul 24 11:55:28 I don't really understand this, but I'm happy to be a step furhter Jul 24 11:56:46 ThomasD13: the usual applies: reding the dev-manual, as well as looking at already existing recipes. Jul 24 11:57:01 yet i am sure RP or such can explain it in a sentence or two Jul 24 12:19:28 hello! Jul 24 12:19:57 how to depend on source (files) of another recipe in a recipe Jul 24 12:20:52 akrpic77: by rethinking your concept. Jul 24 12:39:42 akrpic77: add them to the second recipe's SRC_URI too ;-) Jul 24 12:39:56 It's going to be one of those days .. Jul 24 12:40:06 I should probably just stand up and leave my keyboard Jul 24 12:40:11 * zeddii does just that Jul 24 12:50:54 zeddii: yeah i should do that too. Jul 24 12:54:29 * RP likes the idea Jul 24 12:54:58 at least i'm only like 2.5hrs away from going to the nearest se. Jul 24 12:55:03 lake. Jul 24 12:56:48 LetoThe2nd: there is a beach out my window covered in people enjoying the sun... Jul 24 12:57:50 RP: how surprising! Jul 24 13:38:17 New news from stackoverflow: Yocto compilation Jul 24 14:09:45 there's a following construct in of the recipes i'm dealing with: Jul 24 14:10:33 SRC_URI_append_kernelpatchok += Jul 24 14:10:54 i know what the _append bit does, but what's with the kernelpatchok part? Jul 24 14:11:11 i looked in the .bbclass files of the classes the recipe inherits but didn't find anything Jul 24 14:12:20 milloni: looks like some kind of override (see OVERRIDES) Jul 24 14:12:36 sorry - OVERRIDES where? Jul 24 14:16:32 milloni: have a look in the bitbake manual for overrides. kernelpatchok is likely an override Jul 24 14:16:41 right, thanks Jul 24 14:28:04 RP: yes! thank you Jul 24 14:38:26 New news from stackoverflow: Supply a .deb kernel in yocto [on hold] Jul 24 15:08:30 JPEW: tracked down the performance issue, its sqlite: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=0101966e8fe640258fb163d58d44b862bb2b2a3c Jul 24 15:10:25 Hmm, ya. I think you would want to do something different for a shared (non-local) server (enable WAL, or what have you). Jul 24 15:10:53 Did you happen to try with WAL? Jul 24 15:17:17 Anyone available that could advise on kernel metadata handling? Jul 24 15:19:23 RP: I think the following would give the best performance/safety tradeoff: "PRAGMA synchronous = NORMAL; PRAGMA journal_mode = WAL" Jul 24 15:41:56 JPEW: basically as soon as you get any kind of fsync() in there it will die during a build :( Jul 24 15:46:03 RP: FWIW, with that mode it will only fsync twice when the WAL gets full (once to flush the WAL itself, and once to commit the changes to the database once the WAL has been replayed). I know that can still be really slow though Jul 24 15:46:39 JPEW: fsync() can take minutes in a decent build :( Jul 24 15:46:55 JPEW: realistically we can't afford it Jul 24 15:47:01 RP: Ya.... However, if you make that the default, it really can't be used as a generic hashserver.... it *will* get corrupted at some point. Perhaps it needs an option? Jul 24 15:47:19 JPEW: yes, I'd accept it as an option Jul 24 15:48:36 hmm. systemd doesn't build with the 5.2 headers Jul 24 15:48:38 * zeddii googles Jul 24 16:02:19 JPEW: btw, can we just delete the libsdl bbappend in mingw? Jul 24 16:04:51 I don't know.... are we no longer building nativesdk-libsdl? Jul 24 16:05:19 JPEW: I'm hoping its just libsdl2 Jul 24 16:13:46 RP: Seems reasonable then Jul 24 16:19:12 JPEW: we're deleting it in oe-core fwiw (in -next) Jul 24 16:19:42 Ah, Ok. That makes sense. I'll push a patch to meta-mingw master-next to remove it Jul 24 16:22:28 JPEW: I think you may be able just to go to master, I doubt anything uses it now Jul 24 18:07:58 Is anyone familiar with the autobuilder2 setup and README? The section "on the controller" makes it sound like the yocto-autobuilder-helper should be installed inside the worker's directory, but the "Deployment" section says it should be in the build user's home directory. Jul 24 18:13:35 RP: libsdl is no longer in meta-mingw Jul 24 22:28:07 JPEW: cool, thanks Jul 24 22:30:35 tgoodwin: its in the homedir, alongside yocto-controller **** ENDING LOGGING AT Thu Jul 25 02:59:57 2019