**** BEGIN LOGGING AT Fri Feb 15 02:59:56 2019 Feb 15 03:22:39 * armpit woo-hoo, sumo-nmut oe-selftest passes.. thanks RP for the hints Feb 15 03:23:31 * armpit down to one failure to debug Feb 15 07:43:34 hi.. I have 4 identical build machines (cloned VMs) and my images fail on one of them. What's the easiest way to clean the whole build environment without screwing too much with bitbake's internal state? Feb 15 07:50:51 armpit: nice :) Feb 15 07:56:35 sven^: in build remove sstate-cache cache tmp Feb 15 07:56:59 sven^: keep conf and downloads Feb 15 09:04:22 I'm wondering if there is any standard way to be aware in Makefile that we are built under OE/Yocto? Feb 15 09:05:32 I can pass crafted EXTRA_OEMAKE="YOCTO_BUILD=1" to oe_runmake and in the Makefile check if this variable is defined Feb 15 09:06:03 but I'm wondering if there is any other way to distinguish in runtime if we run the makefile under Yocto/OE or standalone Feb 15 09:06:13 lukma: nope Feb 15 09:07:08 rburton: There was no need for such a feature, or you assume that makefile shall be written in build agnostic way? Feb 15 09:09:06 latter Feb 15 09:09:10 why should it matter? Feb 15 09:10:17 rburton: Use case - some really bad, hand crafted Makefiles needs to be ported to OE Feb 15 09:10:38 they use CFLAGS += .......... -sysroot -isysroot ,etc Feb 15 09:10:39 some really bad, hand crafted makefiles are broken already Feb 15 09:10:41 fix generally and they'll work everywhere Feb 15 09:11:14 and also some modifications of flags Feb 15 09:11:22 what if someone builds under buildroot? same problems no doubt. Feb 15 09:13:27 rburton: Yes, I'm aware of that Feb 15 09:14:11 rburton: I was just wondering if no default flag is set in envs when built under bitbake (but I've checked env command and the environment is pretty standard, which is good IMHO) Feb 15 09:14:21 honestly if the makefile was both actually simple but outrageously bad, i'd just drop in a meson.build :) Feb 15 09:14:53 i guess you could see if bberror or something is defined. but don't do that. Feb 15 09:18:22 rburton: If there is no standard way - then I will fix makefiles Feb 15 09:18:37 rburton: If I add a hack, it will bite me sooner or latter :) Feb 15 09:38:50 hi, I have a problem with machine configs Feb 15 09:38:58 I have two machine config with the same file name in two different layers: my top layer (highest priority) and a vendor layer Feb 15 09:39:20 the one from the vendor layer is used Feb 15 09:39:34 is it correct? can I blacklist the vendor layer machine conf? Feb 15 09:39:46 this is on thud Feb 15 09:42:55 lucaceresoli, I think it might be easier to rename your own config Feb 15 09:46:07 kanavin: thanks. I was hoping to avoid that, but if it's impossible I'll proceed with the whole renaming Feb 15 09:46:41 you can also talk to the vendor :) Feb 15 09:48:12 kanavin: lol, the duplicated filename is the board name... maybe they can rename the board for me :) Feb 15 09:55:36 lucaceresoli: the machine file itself is a solvable problem, the bigger issue would be a clash of override namespace :( Feb 15 10:01:59 RP: gaah, right. Guess I'll remember to add a prefix or suffix to all my machines from now on Feb 15 10:04:08 lucaceresoli: right, beaglebone and beaglebone-yocto come to mind! Feb 15 10:58:06 hello. has anyone had issues building ruby gems with yocto? I am able to build successfully, but on the target the gems are being ignored because they are not pristine. I have read this is possibly due the gems linking against a different libruby version as what exists on the board. I have found that building with bitbake fails should I allow the LDFLAGS variable to (automatically) point to the sysroot-native libraries, and is successfu Feb 15 11:33:15 ollie: sounds like the generic description of "non-cross-compile-aware build scripts" Feb 15 11:58:06 LetoThe2nd: ya I am sure something needs to be changed in regards to the LDFLAGS/LIBRUBY variables. It is just tricky because yocto builds both the native and target. I was just hoping that someone else had experience with compiling ruby-gems on a development machine to deploy on the target Feb 15 12:23:37 Ruby based Ruby Gems or some more interesting ones with C or other stuff in them? Feb 15 12:23:49 The Ruby only ones Just Worked^TM Feb 15 12:24:33 The hellishnightmare created with network packet mangling inside that needed a bunch of C code compiled were fun to build no native and I never tried to cross-compile them. Feb 15 12:24:46 TLDR; basic Ruby only worked for me about 2 years ago Feb 15 12:27:58 Ruby gems with with C : specifically https://github.com/hercules-team/ruby-augeas Feb 15 12:29:02 I can build native and package for ARM successfully, but .rb files requiring the gems report that they are being ignored because their extensions are not built Feb 15 12:29:52 im worried that this is because the gem is installed (during the yocto build) and linked against the native libruby, which of course doesnt exist on the (ARM) target Feb 15 12:30:19 building and installing the gems on the target itself is not an option Feb 15 12:31:48 ive also implemented this fix: https://lists.yoctoproject.org/pipermail/meta-virtualization/2016-January/001685.html Feb 15 12:32:24 which makes it possible to build at all (without it its a no go). but it seems soemthing is still missing Feb 15 14:01:48 New news from stackoverflow: No mouse cursor in Qt ELGFS on Yocto Feb 15 14:24:18 Hello, anyone with psplash experience here? Feb 15 14:31:53 New news from stackoverflow: No mouse cursor in Qt EGLFS on Yocto Feb 15 14:35:45 Anyway, so I'm trying to add a custom splash screen using this guide http://trac.gateworks.com/wiki/ventana/SplashScreen I can compute all steps and build a simple "core-image-minimal" Feb 15 14:36:31 But my custom splash screen does not get included, even if I log into the system and look in ./usr/bin/psplash the "old" splash screen pops up Feb 15 14:38:05 I'm only using the rootfs from Yocto so my first question is, is my assumption correct that psplash is executed from filesystem and not in U-boot or kernel? Feb 15 14:42:25 Willie: assumption correct Feb 15 14:44:00 Willie: yes. sounds like your image didn't get compiled in for some reason Feb 15 14:44:52 Thanks guys! that means I'm atleast on the right tracks :) Feb 15 14:52:40 kanavin: any idea offhand why postinstall deferrment might error on ipk/deb but pass builds on rpm ? Feb 15 14:53:10 kanavin: that busybox upgrade did just that and makes me worry abiot Feb 15 14:53:10 RP: can I see the error? Feb 15 14:53:35 kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/283 and https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/284 but no other errors Feb 15 14:53:47 kanavin: I'm wondering why rpm didn't break too Feb 15 14:54:32 RP: I don't know :( I guess it has to be reproduced locally Feb 15 14:55:12 kanavin: ok, I'll add it to my "worry about" list... Feb 15 14:55:30 how long is that list? Feb 15 14:55:54 RP: for what it's worth, there is a pretty rigorous oe-selftest for it, in test_failing_postinst Feb 15 14:56:22 Crofton: fairly :( Feb 15 14:56:40 kanavin: right. Something just doesn't add up here Feb 15 15:01:45 kanavin: Is there somewhere I can collect up the 'perfect' AUH patches? Feb 15 15:02:37 RP: autobuilder.yoctoproject.org/home/auh/build/upgrade-helper/ , however, I'd suggest you wait until the run that starts today is finished and take that Feb 15 15:02:52 kanavin: fair enough Feb 15 15:02:54 (and give maintainers a few days I'd say) Feb 15 15:08:58 kanavin: I hadn't realised it was running now, I'll wait a little then Feb 15 15:10:37 RP: I think it will start in a few hours, usually takes a day to work through, possibly more now as we have a lot of non-updated recipes Feb 15 15:10:44 so, by monday :) Feb 15 15:13:40 kanavin: I'll get my two updates out now... Feb 15 15:16:43 RP: https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/223 \0/ Feb 15 15:16:52 in it goes? :) Feb 15 15:17:45 kanavin: in what goes? Feb 15 15:17:53 the virgl patchset :) Feb 15 15:18:06 kanavin: rburton has asked for time to review that Feb 15 15:18:23 oh :( meanwhile I am working on more meson conversions, and qemu split is still on the todo Feb 15 15:18:41 mesa conversion to meson has been shot down, sadly Feb 15 15:18:47 but I'll keep the patch around Feb 15 15:19:12 kanavin: its not shot down, Otavio just wants the upgrade split out and has agreed to do it Feb 15 15:19:37 kanavin: I agree if he gets the patches sorted that is ok Feb 15 15:20:48 RP: someone came out saying they don't want meson in 18.3 series, and it better be postponed to 19.0 Feb 15 15:21:25 kanavin: otavio is the maintainer so lets see what happens (and whether native is easy to fix too) Feb 15 15:22:13 RP: I did fix the native Feb 15 15:24:13 kanavin: ah, cool :) Feb 15 15:24:38 khem: going to stop looking at test results processing and try and sort this busybox thing :( Feb 15 16:26:11 opkg-0.3.0 / opkg install --ofline-root /mnt /package-cache/*.ipk complains about wrong arch, but installing them without -o in the running system is fine (so not a real arch error...). /mnt is empty btw Feb 15 16:26:20 can anyone help here? Feb 15 16:30:21 well, --add-arch :1 did it though, wonder why it doesn't pick up the system's arch by default... picking another arch to install would make sense to opt-in by giving the flag explicitly and use current arch if no such flag is given Feb 15 17:20:00 RP, armpit Please go ahead with builds on the AB. Feb 15 17:20:39 halstead, thanks Feb 15 17:23:13 halstead: thanks Feb 15 17:24:36 RP, any issue if I mark Rocko as "community supported" on wiki ? Feb 15 17:25:06 armpit: no Feb 15 17:35:38 * armpit while ad it, included warrior and Zeus code names Feb 16 00:50:17 Hello. I'm trying to create a Yocto build with Qt5.12 and OPC UA plugin for a Raspberry 3. I've added the qtopcua plugin in qt5_image.bb and the build is running fine. However, as soon as I execute a Qt application on the Raspberry, I get the error message that the OPC plugin can not be found. Can someone help me? **** ENDING LOGGING AT Sat Feb 16 02:59:57 2019