**** BEGIN LOGGING AT Tue Mar 26 02:59:56 2019 Mar 26 08:20:55 I have a native package that seems to need -rpath or -rpath-link with Yocto and an old native toolchain, but not with a modern Mar 26 08:37:02 doh, just some missing LDFLAGS... Mar 26 08:44:42 New news from stackoverflow: How to export DBUS_SESSION_BUS_ADDRESS Mar 26 12:15:21 New news from stackoverflow: Building OpenDDS with bitbake Mar 26 13:45:35 New news from stackoverflow: meta-marvell update do_image_ [depends] with MACHINE override Mar 26 15:30:59 if a recipe shall provide the packages PN-dbg, PN-examples and PN-example-dbg, is there any magic at work we have to watch out for? like, FILES_ globbing that might clash or duplicate for the two -dbg packages? Mar 26 15:31:49 ${PN}-dbg is generated automatically nowadays. if you want to explicitly control it, you might have to override that. not sure, though. Mar 26 15:32:31 LetoThe2nd: I think it may have some magic properties due to the name. You'd have to look at the code to see what those were :/ Mar 26 15:33:56 RP: feared that. Mar 26 15:38:14 hmm, having only a single recipe dbg was almost mandatory when -dbg was packaging sources, but now that those are split out, i wonder if we should re-visit the per-package dbg-package possibility Mar 26 15:39:48 kergoth: a given binary is in a given package so there are new possibilities, yes. Could make sense Mar 26 15:40:04 kergoth: could also lead to an explosion in packages Mar 26 15:40:25 hmm, I wonder what watch lists that puts me on... Mar 26 15:40:30 ha Mar 26 15:40:41 true. would need to be able to toggle it, both globally and per-recipe. one of those things that'd need prototyping to see if it's even worthwhile Mar 26 15:41:07 kergoth: its an area I'd really want to support one or the other, not a mess... Mar 26 15:41:19 fair enough Mar 26 15:42:15 $coworker alread found the magic, there seems to be a NO_DEBUG_SPLIT (orwhateveritscalled) variable to give back manual control. Mar 26 15:42:19 so we're fine Mar 26 15:45:52 kergoth: it would escape some of the dep chains madness though... Mar 26 15:50:46 RP: might be less confusing for new users since it’d be more like the desktop distros, but definitely agree it will be a lot more packages and might be fun for package stream users on upgrade Mar 26 16:01:31 I'm working with a atsama5d27 using Yocto sumo. I've got libjpeg-turbo in my IMAGE_INSTALL. Yocto builds and completes successfully and I can find libjpeg-turbo in the debs folder. It does not, however, install it on the root filesystem. Instead it is installing regular libjpeg. Any ideas on what could be overriding or altering what gets installed on the rootfs? Mar 26 16:18:07 output_4: sumo doesn't ship normal libjpeg, so have you considered that its actually libjpeg-turbo? Mar 26 17:09:48 I thought that but when I rename and/or did a symlink the dynamic linker complained that it wasn't. Mar 26 17:11:13 I also did a binary diff to just see if it was the same thing and they are different. It is possible another recipe is pulling it in? I know that is a very vague question. Mar 26 17:11:27 Is* it Mar 26 17:19:05 https://lists.yoctoproject.org/pipermail/yocto/2018-January/039628.html Mar 26 17:19:38 Not sure if this is relevant or not... Mar 26 18:11:47 So it looks like "PREFERRED_PROVIDER_jpeg": "jpeg and "PREFERRED_PROVIDER_jpeg-native": "jpeg-native" are set to standard jpeg and not turbo. Mar 26 18:12:38 does anyone use non-turbo jpeg anymore? Mar 26 18:12:47 Okay so I think I figured it out. Looks like there is a .inc buried in the meta-atmel that is setting the PREFERRED_PROVIDER. Mar 26 18:13:19 And they are setting it to jpeg not turbo. Mar 26 18:13:31 I'm going to change it and rebuilt. I think that is the root cause here. Mar 26 18:13:50 Threw me for a loop since everything else in Yocto references turbo now. Mar 26 18:43:08 output_4: they must also be shipping non-turbo, as oe-core doesn't have it Mar 26 18:43:22 or maybe they actually want non-turbo for whatever reason Mar 26 18:46:49 That is possible. Going to build with turbo and do some testing now. Mar 26 23:19:20 armpit: builds look like a disaster :( Mar 26 23:19:31 * RP suspects a build perf sstate problem Mar 26 23:20:08 RP, turn that frown up side down Mar 26 23:20:37 * armpit looks Mar 26 23:20:46 * RP goes to get food Mar 26 23:44:06 armpit: found a bug in config.json in the helper. Basically we destroy sstate in release builds :/ Mar 26 23:44:57 * armpit RP the destroy Mar 26 23:45:16 * RP pushes a fix and we can try rc2 Mar 26 23:45:16 its a good test ? Mar 26 23:46:09 hmm, who is swat this week? Mar 26 23:46:37 Paul? Mar 26 23:47:07 I can take a look later this evening Mar 26 23:47:29 armpit: thanks. There are just some things we need to get into bugzilla, ensure we don't lose them Mar 26 23:47:56 k Mar 26 23:59:18 * RP thinks Paul is away for a day or two. We need bugs for https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/115 and https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/118 which I'll sort tomorrow unless someone beats me to it Mar 27 00:10:50 bugs its sorted (Paul was around) Mar 27 02:32:18 k **** ENDING LOGGING AT Wed Mar 27 02:59:57 2019