**** BEGIN LOGGING AT Sun Jul 30 03:00:01 2017 Jul 30 12:54:33 Has anyone tried to build/package against fftw? When I try to do_rootfs for an image, I get "could not invoke dnf" because of "conflicting requests" since "nothing provides fftw". It suggests adding "--allowerasing" to replace the conflicting package, but I've not seen this before in Morty or Krogoth (trying to update to Pyro). Jul 30 12:58:29 The problem is coming from the solver, giving me "nothing provides fftw needed by libfftlib0-2.0.0-r1.aarch64 (building for QEMUARM64 as a test). It recommends as a solution not to install a package providing the package group that I need... Jul 30 13:08:26 tgoodwin: is fftw empty Jul 30 13:10:31 khem: I don't follow what you're asking. The recipe is not empty. It provides fftw, fftwl, and fftwf. In the past, we would depend on fftwf, however in Morty and Pyro we get a "nothing RPROVIDES..." for anything other than fftw. Jul 30 13:11:28 khem: I'm trying to pick apart this new recipe now to figure out what changed in the output products when it was consolidated to a single recipe from multiple. Jul 30 13:11:30 check what all rpms are built Jul 30 13:11:42 by fftw recipe Jul 30 13:12:11 RP1: llvm/mesa tree is ready for pull, give it a shot if you have time today Jul 30 13:33:22 Sorry, I had to step away. Jul 30 13:35:29 Is anyone else around that is familiar with using the morty/pyro version of fftw? Per khem's last comment before signing off, there are no fftw IPKs. Instead it's fftwf-wisdom, etc. Jul 30 13:38:06 Changing the runtime dependency for my dependent recipe to fftwf-wisdom seems to have solved the error, but now I et DEPLOY_DIR_IMAGE is NULL when trying to start qemu (runqemu qemuarm64) Jul 30 13:42:54 Never mind... looks like I have to manually specify the path now even though DEPLOY_DIR_IMAGE is set in the environment. Jul 30 14:46:37 khem: ok, will try, thanks Jul 30 15:28:07 khem: build running on yocto.io along with a few other changes in the queue Jul 30 16:04:09 RP1: thx great Jul 30 17:00:09 khem: 1.5 hours so far cloning llvm :( Jul 30 17:00:18 khem: main build hasn't even triggered Jul 30 17:01:17 is it actually larger than gcc source? Jul 30 17:01:37 or just on a slow server? :) Jul 30 17:02:41 paulg: no idea. I'm just going to leave it to it... Jul 30 17:02:54 RP: thats quite unusual Jul 30 17:03:12 its pulling from github so it shouldn't be that slow... Jul 30 17:03:22 RP: its from github, I was hoping it will have good CDN Jul 30 17:04:01 sounds like the kind of thing best started late in the evening just before you unplug for the day.... Jul 30 17:04:18 for me here it takes less than a min to clone Jul 30 17:04:34 yeah murphy's law Jul 30 17:09:44 RP: I am also carry a local patch http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=083f35114041011c2699d5da6848b19d90247de8 Jul 30 17:10:07 I wonder if we can make it default in oe-core to enable llvmpipe Jul 30 22:21:58 khem: we might be able to, that is one for ross/jku Jul 30 22:22:21 khem: 2.5 hours and the build proceeded. Locally took 20mins to fetch fwiw Jul 31 02:21:31 RP: ok. Jul 31 02:21:51 RP: I think once 5.0 releases we might think of using tarballs Jul 31 02:25:08 RP: hopefully it built successfully thereafter **** ENDING LOGGING AT Mon Jul 31 03:00:01 2017