Re: [yocto] Problem overwriting default kernel config values
On 2015-07-18 11:53 PM, Bruce Ashfield wrote: On 2015-07-17 9:35 PM, Ryan Soussan wrote: Hello, We're having a problem overwriting the default linux kernel config values. We tried adding our own .cfg file to our layer and appending it to the source url of the linux-yocto bitbake file. The variable in our case is not getting overwritten though (changing CONFIG_ATH5K=m to =y). Here's some relevant output from mismatch.txt: Value requested for CONFIG_ATH5K not in final .config Requested value: CONFIG_ATH5K=y Actual value: CONFIG_ATH5K=m And basically the same error message in missing_required.cfg. So it looks like yocto is seeing our request but ignoring it. The source code for these messages is located here: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/tree/tools/kconf_check We were following the instructions for editing the config file located in the linux directory of the meta-skeleton layer in poky. Any help would be appreciated! What release/branch are you using ? This is a test case that I run ever release (and use every day), so the overrides do work. The kernel configuration system doesn't have the opportunity to ignore settings. They are consolidated and then passed to the kernel's config subsystem and then the results audited. I'll run a similar test here, since if something else later in the configuration is selecting that driver as a module, or another constraint is kicking in .. you will end up with a module, no matter what you set in your fragment. And yes, it was a contraint in the end. I needed this in my fragment to flip ATH5K to =y CONFIG_ATH5K=y CONFIG_ATH_CARDS=y CONFIG_ATH_COMMON=y CONFIG_CFG80211=y CONFIG_R8723AU=y CONFIG_MAC80211=y I'm working on some diagnostics and symbol lookups that will help with this in the future .. but it is much more challenging than you'd expect! Cheers, Bruce Bruce Thanks, Ryan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem overwriting default kernel config values
On 2015-07-17 9:35 PM, Ryan Soussan wrote: Hello, We're having a problem overwriting the default linux kernel config values. We tried adding our own .cfg file to our layer and appending it to the source url of the linux-yocto bitbake file. The variable in our case is not getting overwritten though (changing CONFIG_ATH5K=m to =y). Here's some relevant output from mismatch.txt: Value requested for CONFIG_ATH5K not in final .config Requested value: CONFIG_ATH5K=y Actual value: CONFIG_ATH5K=m And basically the same error message in missing_required.cfg. So it looks like yocto is seeing our request but ignoring it. The source code for these messages is located here: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/tree/tools/kconf_check We were following the instructions for editing the config file located in the linux directory of the meta-skeleton layer in poky. Any help would be appreciated! What release/branch are you using ? This is a test case that I run ever release (and use every day), so the overrides do work. The kernel configuration system doesn't have the opportunity to ignore settings. They are consolidated and then passed to the kernel's config subsystem and then the results audited. I'll run a similar test here, since if something else later in the configuration is selecting that driver as a module, or another constraint is kicking in .. you will end up with a module, no matter what you set in your fragment. Bruce Thanks, Ryan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR
Hi Richard, On 17/07/2015 19:44, Alex J Lennon wrote: > > On 17/07/2015 19:24, Richard Tollerton wrote: >> Alex J Lennon writes: >> >>> Hi Richard, >>> >>> On 17/07/2015 17:57, Richard Tollerton wrote: Hi Alex, When you mentioned having weird build troubles, that reminded me that I was seeing weird build problems of my own, that I had been refraining from sending patches on until I could better characterize the issue. If you've been seeing weird build failures in executables that really should never be failing in the first place -- i.e., gacutils failures, or "invalid resx file", or anything involving not being able to dlopen libc or being unable to open /etc/mono/config -- you might be interested in this patch. >>> I think I have identified the problems I was seeing with the recipes, >>> which boil down to the lack of a mono gmcs script and inheriting >>> autotools-brokensep instead of autotools. >>> >>> I can't quite understand why you were not seeing the problem at your >>> end, but I can see that gmcs was removed at end 2014 - >>> >>> https://github.com/mono/mono/commit/b304ec5e0e694ef7098e0fc3eba9dbc0162f4568 >> Yeah, I saw it too. :F I wound up working around it by adding a gmcs >> symlink in the recipe, but then I also added a gmcs symlink in my host >> OS, which wound up masking the build errors when I tried removing the >> gmcs symlink from the recipe later. >> >> There were also some autotools-brokensep build problems I was planning >> on submitting later, sounds like you got those fixed first (yay!) > Good - that explains it then. Yes autotools-brokensep is in there now. > The gmcs workaround will arrive shortly > >>> The commits I made today address the autotools-brokensep issue and get >>> me to a point where I can build image-full-mono with a hand-added gmcs >>> script in sysroot >>> >>> (There was a patch needed for monotools-server to support the more >>> recent mono-xsp and mono-upnp needed autotools-brokensep). >>> >>> Now I just need to decide whether to reintroduce the gmcs script or fix >>> all the other autotools configurations... >> A-ha! mono-xsp fixed its gmcs references in master, but hasn't cut a >> release since May 2013. I just asked on #monodev for somebody to cut a >> new release, but until then, I suppose a workaround is to create a >> mono-xsp_git.bb? >> >> Which other packages require gmcs? I see that monotools-server does, but >> I can't find evidence of that being maintained since 2010, and I >> otherwise don't have a use for it AFAIK. Out of image-full-mono these have problems without gmcs present, Looks like we need a solution for these three to use mcs instead of gmcs, mono-xsp_3.0.11.bb checking for gmcs... no configure: WARNING: unrecognized options: --disable-dependency-tracking, --with-libtool-sysroot configure: WARNING: using cross tools not prefixed with host triplet configure: error: You need to install 'gmcs' Error: Could not run ./configure, which is required to configure xsp dbus-sharp_0.8.0.bb checking for MONO... yes checking for gmcs... no configure: error: You need to install gmcs Configure failed. The contents of all config.log files follows to aid debugging mono-addins_1.1.bb checking for pkg-config... /data_drive/imx6/rootfs_builder/qemux86.dizzy/tmp/sysroots/x86_64-linux/usr/bin/pkg-config checking for gmcs... no configure: error: mcs Not found Configure failed. The contents of all config.log files follows to aid debugging ... mono-upnp (requires mono-addins) dbus-sharp-glib (requires dbus-sharp) monotools-server (requires mono-xsp) Cheers, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto