**** BEGIN LOGGING AT Mon Aug 14 03:00:02 2017 Aug 14 07:36:16 hi , i tried to upgrade my glib from 2.46 to 2.50.1, i meet such error, ERROR: Required build target 'nativesdk-glib-2.0' has no buildable providers Aug 14 07:36:37 does anyone know how to fix it, this error bothers me Aug 14 07:41:38 rheagar: on which release, and how did you do the version bump? Aug 14 07:43:49 LetoThe2nd: my local yocto is 2.1, i synced a new yocto project , and check out the glib version tag , then i move all glib related file to my local build. Aug 14 07:44:48 LetoThe2nd: i make some changes like downgrade python3 to python2 , remove manpages support , for other changes, i think they don't matter Aug 14 07:46:34 rheagar: i'd suggest to give it a clean approach first. e.g. 1) get a fresh clone of poky on your desired branch 2) add an empty custom layer 3) in that custom layer, do the version bump Aug 14 07:48:16 plus for bumping, i'd say to try and get the last 2.50 state from poky mainline, like http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/glib-2.0?id=60558c15443ed64c8203fada97040e7586b94bed Aug 14 07:48:55 then you can be pretty sure that you did not accidentially do something wrong in the version forwarding Aug 14 08:24:33 LetoThe2nd: thanks for your help , from my new observation , i find in new glib added PACKAGECONFIG[libmount], which will make something like nativesdk-coreutils(libmount), this fails. Aug 14 08:25:40 LetoThe2nd: so seems as glib is nativesdk, all PACKAGECONFIG in it should be nativesdk too. Aug 14 08:38:01 rheagar: at least all that are enabled, yes Aug 14 12:11:21 I'm having problems building morty Aug 14 12:11:33 ERROR: slang-2.3.0-r0 do_configure: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Aug 14 12:11:33 Rerun configure task after fixing this. Aug 14 12:11:36 due to: Aug 14 12:11:51 checking for ncurses5-config... /mnt/ssd/vcs/gnome/freedesktop-sdk-base/build/x86_64/tmp-glibc/sysroots/qemux86-64/usr/bin/crossscripts/ncurses5-config Aug 14 12:11:51 checking for terminfo... ERROR: /usr/bin/ncurses5-config should not be used, use an alternative such as pkg-config Aug 14 12:11:51 no Aug 14 12:11:54 Is this a known issue? Aug 14 13:46:01 ERROR: The hw-test-image recipe is an image, and therefore is not supported by this tool Aug 14 13:46:24 from the command "devtool modify -x hw-test-image src/hw-test-image" Aug 14 13:46:34 yet "bitbake hw-test-image" works fine. Aug 14 13:54:39 any ideas why ? Aug 14 13:55:46 RP: ping. I wanted to confirm some kernel version plans with you. Now that I'm back from vacation and will finish up my features. Aug 14 13:56:45 TafThorne: any ideas? Aug 14 13:57:42 yates: I am not that familiar with the devtool commands. Aug 14 13:58:02 I tend to write and edit lots of things myself in a text editor. Aug 14 13:59:35 no this isnt' a gui. the name sounds like it, but it's not. Aug 14 14:00:11 It may be a ui though Aug 14 14:00:30 one of the things it does is keep the modified tmp/work-space/kernel-source directory available for further tweaking. Aug 14 14:00:54 "devtool helps you easily develop projects whose build output must be part of an image built" http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-devtool-in-your-workflow Aug 14 14:01:10 An image cannot be part of an image. Aug 14 14:01:31 So you get the "recipe is an image, and therefore is not supported by this tool" error message to tell you that. Aug 14 14:02:33 nope Aug 14 14:03:19 from 4.3.1.2, "$ devtool modify recipe" Aug 14 14:03:47 you give it a recipe name. Aug 14 14:04:01 this worked on another recipe anme. must be something it doesn't like about this one.. Aug 14 14:04:16 "The hw-test-image recipe is an image," Aug 14 14:04:27 It will not work on image recipies. Aug 14 14:04:44 ok, it's monday... Aug 14 14:04:51 Well that is how I read its error message and the sections in the manual. Aug 14 14:05:50 Was the other recipie that it did work on for something smaller than a whole image? Aug 14 14:06:04 Like a kernel, application, patch or something? Aug 14 14:07:18 zeddii: hi! Aug 14 14:08:17 hey ... digging out from email backlog, but I'm skipping the usual catch up to get some code out the door. Aug 14 14:09:17 RP: my issue is that looking at the release date, I had targetted 4.13 as the kernel and set the -dev kernel in motion for that, but it is on rc5 right now. which means the full kernel won't be out before the feature freeze. Aug 14 14:09:39 4.14 will be the next LTS, which means once again, I can't target it in the fall as a reference. Aug 14 14:09:59 so either I do a -rc recipe for feature freeze, or fall back to 4.12. Aug 14 14:10:30 zeddii: will we get 4.13 final before the release? Aug 14 14:10:47 zeddii: or cutting it fine? Aug 14 14:11:17 TafThorne: i guess it was a kernel-recipe Aug 14 14:11:19 code freeze is the 18th of september, right ? Aug 14 14:11:46 yeah, the kernel recipe worked with devtool Aug 14 14:12:40 zeddii: For M4, yes Aug 14 14:13:02 yates: a kernel-recipie is not an image recipie. If my reading is correct that would be why it worked. Could you try modifying a component of the hw-test-image instead of the whole image? Aug 14 14:14:25 RP: yah. so the timeline would be Sept 3rd if linus does a -rc8. there wouldn't be any surprises now in the kernel, so if I do a -rc kernel right away, we'd be bumping the REVs and doing one last round of sanity about 2 weeks before M4 cutoff. Aug 14 14:15:12 but honestly, I can go either way on this. 4.12 is just as random a version as anything else, it'll just be a few months more stale, but just as short a maintenance window upstream. Aug 14 14:16:55 zeddii: I'm tempted to say 4.12 and give us all a little bit less pressure Aug 14 14:17:07 zeddii: we don't have any pressing need for 4.13? Aug 14 14:17:15 TafThorne: isn't the kernel recipe a component of the image? that's what i did Aug 14 14:17:49 RP: I'm also leaning that way, since I'm sure there will be other issues in M4 (as usual). I'll troll 4.13's logs and see if anything jumps out. but assume 4.13 unless I find something 'must have' .. and that is unlikely. Aug 14 14:17:58 gah Aug 14 14:18:03 assume 4.12 !!! Aug 14 14:18:08 zeddii: was about to say :) Aug 14 14:18:11 that was an important number to not typo! Aug 14 14:18:15 zeddii: sounds like a plan Aug 14 14:18:37 cool. I'll go get it done now. I'm prepp'd so it shouldn't take long, just builds and sanity booting. Aug 14 14:19:23 zeddii: sounds good. I'm drowning in build failures :( Aug 14 14:19:42 I'm two weeks out of date, will see what I find lurking. Aug 14 14:20:13 zeddii: never did reply to you directly about those long standing bugs but I think we did get movement on some of them at least Aug 14 14:20:52 RP: no worries. and yes, they both finally moved along. the perf one is still outstanding, but I'll check in to see what exactly has happened on it (did you grab it ? I recall something like that as the last update). Aug 14 14:21:20 zeddii: I have a large pile of problem bugs :( Aug 14 14:21:31 zeddii: the bitbake server changes are keeping me busy Aug 14 14:22:18 RP: :( .. assuming I can get the 4.12 + frags stuff done as planned, I'll loop back around and see what I can pick up. Aug 14 14:33:56 Im trying to auto start a gui application on boot using systemd on a waylad/weston system but when i start the service it complains about error: XDG_RUNTIME_DIR not set in the environment. Aug 14 14:46:47 hmwel: Yes you need to set that variable in order to start weston Aug 14 14:49:23 TafThorne: Yes, I think the kernel-recipie is part of the hw-test-image recipe. I was more asking if you needed to use devtool modify -x hw-test-image at all? Aug 14 14:58:12 is this the right place to ask about openembedded layer contents? Aug 14 15:00:18 brrm: You can try asking Aug 14 15:00:44 brrm: One of us can then try answering. Aug 14 15:01:36 I added recipes-support/libbsd/libbsd_0.8.5.bb to my image. I expected it would install queue.h, but it doesn't. Aug 14 15:01:57 do I have to do sth. special to get the header files installed? Aug 14 15:02:55 i have an .deb in SRC_URI, do_unpack fails, feels like yocto cant find xz or something Aug 14 15:03:13 anyone had a similair issue? Aug 14 15:08:00 brrm: does anything require the recipe? I guess you have added it to an append in local.conf or something? Aug 14 15:08:33 zepto88: what is the error message? Aug 14 15:15:04 TafThorne: I wrote my own image recipe, based on an existing image. there is no error message. libbsd.so.0.8.3 is installed, but without the headers Aug 14 15:21:12 ar x data.tar.xz && tar --no-same-owner -xpf data.tar.xz && rm Aug 14 15:21:12 data.tar.xz failed with return value 2 Aug 14 15:21:40 do_unpack cant extract the deb package for some reason Aug 14 15:22:19 found this mailthread with the same error that links to this commit: https://lists.yoctoproject.org/pipermail/yocto/2017-April/035643.html Aug 14 15:22:52 this is the commit http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=283a9b3883083e45bbdaf0488a3c6c76c5b197d7 Aug 14 15:23:01 i have this patch, still doesnt work Aug 14 15:32:28 brrm: there are not many headers here: https://cgit.freedesktop.org/libbsd/tree/src Aug 14 15:35:43 brrm: now wait. I found them in the include directroy https://cgit.freedesktop.org/libbsd/tree/include/bsd Looking at the recipe it does not do anything that exotic with the source .tar file. Does `inherit autotools pkgconfig` sort out the deployment of recipe results automatically? Aug 14 17:06:37 Hey all, trying to get some more control over the packages present in my image. I kinda understand the structure under the image definition, however there is something that I don't understand. core-image.bbclass installs packagegroup-base-extended. It looks like the -extended revision of package-base does... nothing. It includes 3 blank variables. Aug 14 17:07:12 Can someone confirm that I'm right there? Any questions or comments appreciated. Aug 14 17:08:49 *4 blank vbariables Aug 14 17:09:22 majuk: look further down in pg-base.bb -> http://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-base.bb#n117 Aug 14 17:09:25 https://pastebin.com/E5gPAt43 <-relevant snip from packagegroup-base.bb Aug 14 17:13:35 nrossi: Not sure what you're referring to. Those packagegroups are included per MACHINE/COMBINED/DISTRO_FEATURES, _not_ as a result of the ADD_* variables in packagegroup-core-extended. Aug 14 17:13:45 If that's wrong, please correct me. Aug 14 17:15:26 majuk: the ADD_* variables are set to non empty depending on distro/machine features Aug 14 17:16:26 nrossi: Ah! ok, I see what it's doing now. Thanks. Aug 14 17:16:52 majuk: np, can be easy to miss those anonymous functions :) Aug 14 18:07:57 we are hijacking several GPIO pins from enet2. so it seems that, in addition to reconfiguring the pin muxes for those pins, we somehow need to turn enet2 off: https://da.gd/sDXwL -> https://paste.fedoraproject.org/paste/c42-NX~j70CD5trhxoubDg/ Aug 14 18:08:20 is this correct? if so, how would we do this? Aug 14 18:08:49 (see line 176, e.g.) Aug 14 18:08:56 is it via the status ? Aug 14 18:42:18 does yocto leave sources/poky/build/tmp/work-shared//kernel-source/... intact after a successful image build? Aug 14 18:44:50 if so, then if i subsequently change something there, then will "bitbake image-recipe" rebuild the changes there or will they be overwritten? Aug 14 18:44:53 workdirs aren't wiped at all by default, for anything, unless you're inheriting the rm_work class Aug 14 18:44:59 and even then i don't know if it wipes work-shared Aug 14 18:45:15 and no, it doesn't monitor files in already unpacked sources for changes Aug 14 18:45:24 ah. Aug 14 18:45:28 if you want that, use the externalsrc class / `devtool modify -x` Aug 14 18:45:32 that's what devtool is for Aug 14 18:45:33 yes. Aug 14 18:48:06 would patching the fs_enet_probe() function in fs_enet-main.c to return a failure for a specific network device be a reasonable way of disabling that network interface? Aug 14 20:40:21 Trying to understand defconfig/kernel setup. In my machine conf, PREFERRED_PROVIDER_virtual/kernel ?= "linux-wandboard". Found linux-wandboard_VER.bb which includes linux-wandboard.inc. The .inc seems to declare which defconfig is being used, but I don't understand the syntax. Aug 14 20:40:49 This is from meta-fsl-arm-extra layer Aug 14 20:42:02 Can someone shed light on this? I see there is a linux-wandboard_VER/ folder and a defconfig file under that. Is it that simple? It's going to find the recipe folder and use that defconfig? Aug 14 20:45:43 see the bitbake user manual on how fetching works, specially file:// Aug 14 20:46:14 halstead: did something happen to the autobuilder? Aug 14 20:46:21 kergoth: Cool, thanks, I'll check that out. Aug 14 20:46:23 halstead: centos7.yocto.io specificially? Aug 14 20:46:45 RP, I used it to test the proxy settings a little bit ago. Aug 14 20:46:48 Hrmm.. Aug 14 20:47:02 halstead: it seems rather unwell and the current build is struggling Aug 14 20:47:13 RP, Not sure. I'm getting alerts. Let me see if I can get console access. Aug 14 20:47:26 halstead: I can log in and its idle :/ Aug 14 20:47:41 halstead: it shouldn't be: https://autobuilder.yocto.io/builders/nightly-x86-64-lsb/builds/411 Aug 14 20:48:23 RP, I got network unreachable at first. But I'm in now. Hrmm. Aug 14 20:51:32 RP, I see some nfs timeouts but new locks are working fine. And I see the twisted process running but just sitting in epoll_wait. Aug 14 20:53:48 RP, I haven't seen this before. Shall I investigate or just get it back up now? Aug 14 21:02:04 halstead: you can investigate Aug 14 21:02:24 halstead: when done retrigger the build of master-next? Aug 14 21:02:30 Thanks RP. Will do! Aug 14 21:09:17 hello! i'm having issues running `-c testimage` against built images Aug 14 21:10:27 while do_testimage is trying to set up tap interfaces, i get this error: `sudo: no tty present and no askpass program specified` and `Failed to setup tap device. Run runqemu-gen-tapdevs to manually create.` Aug 14 21:13:07 trying 'sudo `which runqemu-gen-tapdevs`' raises questions about which user will own the tap device -- it's unclear to me what any of this is trying to accomplish, or how i'm supposed to resolve it. googling about yocto tap devices didn't yield much insight, so i'm asking here. Aug 14 21:17:08 garbados, I know how to create the tap devices for the autobuilder. Maybe I can help a little? We specify the builduser's uid Aug 14 21:17:59 In our poky/scripts directory we run "./runqemu-gen-tapdevs 6000 100 32 /opt/poky/sysroots/x86_64-pokysdk-linux/" to make 32 of them at boot. Aug 14 21:19:04 ah, ok Aug 14 21:19:37 i got it to run but i'm still not sure what a tap device is or why i'd need 4 or 32 or however many of them Aug 14 21:29:34 garbados: you need one per image you're testing so if you test 3 images in parallel you'd need 3 Aug 14 21:29:44 RP, ah, ty Aug 14 21:30:03 garbados: the tap device is how it connects into the host networking and allows network communication Aug 14 21:30:33 garbados: setting up the device is a privileged op and we don't want the build user with such privs in general Aug 14 21:31:33 RP, i understand wanting to restrict those privileges, but runqemu-gen-tapdevs requires root privileges Aug 14 21:31:45 unless i misunderstand what you've said? Aug 14 21:32:20 garbados: it needs root so the main build doesn't need it Aug 14 21:32:49 ah Aug 14 22:02:16 - package librepo0-1.7.20+git0+e1137cbbda-r0.core2_64 requires libcrypto.so.1.1()(64bit), but none of the providers can be installed Aug 14 22:02:20 oops.. Aug 14 22:38:18 halstead: much progress? Aug 14 22:38:27 halstead: should I run the build on the other AB? Aug 14 22:39:35 RP, processes on the nas and on downloads.yoctoproject.org caused me to need to restart the cluster. Working on getting it back up. Aug 14 22:40:06 halstead: ok, np Aug 14 22:40:10 RP, Waiting on failed disks to timeout so I can get the nas mounted again. Aug 14 22:40:49 RP, I'll queue the build as soon as possible. Aug 14 22:41:00 halstead: ah, so it was disk failures causing nfs to slow? Aug 14 22:41:25 halstead: I could use the other builder if that helps Aug 14 22:42:16 RP, No, that's just slowing down a reboot. It looks like hosting the SSTATE directly from the NAS overloaded nginx somehow. I'll try to find out how once I have it back up. Aug 14 22:43:47 halstead: ok, np Aug 14 22:45:07 RP, https://autobuilder.yocto.io/ ready to queue. Shall I go ahead or would you rather? Aug 14 22:47:38 halstead: go for it :) Aug 14 22:47:43 * halstead nods. Aug 14 22:49:58 halstead: thanks Aug 15 01:44:44 does anyone know the commit has for 2.4-M2? Aug 15 01:46:15 aehs29: it's on the QA status page: https://wiki.yoctoproject.org/wiki/2.4_QA_Status Aug 15 01:49:08 bluelightning: thanks paul **** ENDING LOGGING AT Tue Aug 15 03:00:01 2017