[yocto] Problem overwriting default kernel config values

[Ryan Soussan]

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!

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

[Alex J Lennon]

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.

I'd have to check. I think there were a couple of others but adding in
gmcs made all the problems "disappear" so I didn't investigate further.

If I get a chance I may remove tmp/ and rebuild without the gmcs patch
to see what breaks.

monotools-server is there because I want to be able to remote debug onto
ARM platforms with Visual Studio (or Xamarin IDE if I have to) Some time
ago Xamarin had a neat Visual Studio plugin that supported this but
unfortunately it has disappeared. Xamarin IDE can be  configured to
remote debug against Mono/Arm/Linux and I've had some success with
trivial applications but I really want to find time to get this up and
running for more complex commercial applications.

>> I am probably going to reintroduce the script due to time contraints
>> unless you want to take a look at this?
> Yeah, go for it.
>
> I asked on #monodev whether there was any downside to symlinking gmcs to
> mcs, and at least one person responded in the negative. But IIRC, at the
> same time, nobody expressed any surprise that this isn't done already,
> which is kinda weird. I did do some grepping through the mono codebase
> and was unable to find any behavioral changes that were keyed off
> executing mcs as gmcs, so obviously it's going to emit 4.5-compatible
> stuff which isn't ideal, but it does get stuff building.
>
> I presume that your script solution restricts assembly versions
> appropriately and the like and tries to do The Right Thing.
>
> See also
> https://github.com/mono/mono/commit/6b76c7e984cbe42d6455ffcde2fe227aa5ffd801,
> which was breaking mono-xsp when build with gmcs symlinked to mcs. I
> presume you didn't encounter this with your script because it's properly
> behaving like gmcs, but once these mono-xsp gmcs fixes roll in, this
> will probably start breaking stuff.

I wasn't keen on symlinking, so in the short term I am looking at just
reverting the patch I referenced which removed gmcs.

I can believe that may lead us onto other issues but at least it is a
step in the right direction as the recipes will at least build...

>> I use mono primarily on ARM (i.MX6) - commercially, quite a lot - and
>> haven't seen anything that was problematical with the build for some
>> time, since I addressed some issues with use of out of tree mono
>> installed on the host.
>>
>> So from my experience "all is well" with Mono ARM builds. I'd like to
>> know about any issues you or others have seen on ARM platforms though
>> which we need to address.
>>
>> That said, I can't see any reaso

Re: [yocto] [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Richard Tollerton]

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!)

> 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.

> I am probably going to reintroduce the script due to time contraints
> unless you want to take a look at this?

Yeah, go for it.

I asked on #monodev whether there was any downside to symlinking gmcs to
mcs, and at least one person responded in the negative. But IIRC, at the
same time, nobody expressed any surprise that this isn't done already,
which is kinda weird. I did do some grepping through the mono codebase
and was unable to find any behavioral changes that were keyed off
executing mcs as gmcs, so obviously it's going to emit 4.5-compatible
stuff which isn't ideal, but it does get stuff building.

I presume that your script solution restricts assembly versions
appropriately and the like and tries to do The Right Thing.

See also
https://github.com/mono/mono/commit/6b76c7e984cbe42d6455ffcde2fe227aa5ffd801,
which was breaking mono-xsp when build with gmcs symlinked to mcs. I
presume you didn't encounter this with your script because it's properly
behaving like gmcs, but once these mono-xsp gmcs fixes roll in, this
will probably start breaking stuff.

> I use mono primarily on ARM (i.MX6) - commercially, quite a lot - and
> haven't seen anything that was problematical with the build for some
> time, since I addressed some issues with use of out of tree mono
> installed on the host.
>
> So from my experience "all is well" with Mono ARM builds. I'd like to
> know about any issues you or others have seen on ARM platforms though
> which we need to address.
>
> That said, I can't see any reason not to apply your patch so will merge
> that in.

Thanks. I'll try to dig deeper into this soon, and will work upstream
with the mono devs when I get to the bottom of it.

> Regards,
>
> Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Alex J Lennon]

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

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...

I am probably going to reintroduce the script due to time contraints
unless you want to take a look at this?

> That said, if you *don't* have problems compiling to an ARM sysroot, I'd
> be interested in knowing that too. :F
>
>
> The following changes since commit 041cc6b70c7fb3b55e73b90b1a101844da1726b2:
>
>   README: Update to remove references to mono < 3.12.1 (2015-07-17 12:38:32 
> +0100)
>
> are available in the git repository at:
>
>   git://github.com/rtollert/meta-mono dev/rtollert/v5/mono-cfg
>   https://github.com/rtollert/meta-mono/tree/dev/rtollert/v5/mono-cfg
>
> Richard Tollerton (1):
>   mono.bbclass: set MONO_CFG_DIR
>
>  classes/mono.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
>

I use mono primarily on ARM (i.MX6) - commercially, quite a lot - and
haven't seen anything that was problematical with the build for some
time, since I addressed some issues with use of out of tree mono
installed on the host.

So from my experience "all is well" with Mono ARM builds. I'd like to
know about any issues you or others have seen on ARM platforms though
which we need to address.

That said, I can't see any reason not to apply your patch so will merge
that in.

Regards,

Alex

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mono] [RFC] [PATCH 1/1] mono.bbclass: set MONO_CFG_DIR

[Richard Tollerton]

Several mono package builds were observed to fail while cross-compiling
to arm in ways that, upon stracing, boiled down to not being able to
load the mono config file because mono was looking for it in
${STAGING_DIR_NATIVE}/usr/etc instead of
${STAGING_DIR_NATIVE}/etc (which is where it was being installed).

mono/mono/metadata/assembly.c:set_dirs() appears to be responsible for
guessing /usr/etc, by essentially computing $(dirname $0)/../etc.
There's a separate codepath that instead chooses $sysconfdir (cf
assembly.c:fallback(), mono-config-dirs.c:mono_config_get_cfg_dir(), and
the Makefile). Presumably that's what's usually used for native mono
builds, but for presently unknown reasons, it's not getting used here.

The workaround implemented here is to force setting MONO_CFG_DIR for all
builds to the correct location of /etc in the native sysroot.
(I had earlier worked around this by changing the mono-native build to
install to /usr/etc instead of /etc, but that's more complicated to
manage in the recipes, and violates the configuration symmetry between
architectures.)

Signed-off-by: Richard Tollerton 
---
 classes/mono.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/classes/mono.bbclass b/classes/mono.bbclass
index 315ee82..1cb4b17 100644
--- a/classes/mono.bbclass
+++ b/classes/mono.bbclass
@@ -30,3 +30,5 @@ FILES_${PN}-dev += "\
 FILES_${PN}-doc += "\
   ${libdir}/monodoc/* \
 "
+
+export MONO_CFG_DIR="${STAGING_ETCDIR_NATIVE}"
-- 
2.4.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Richard Tollerton]

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.

That said, if you *don't* have problems compiling to an ARM sysroot, I'd
be interested in knowing that too. :F


The following changes since commit 041cc6b70c7fb3b55e73b90b1a101844da1726b2:

  README: Update to remove references to mono < 3.12.1 (2015-07-17 12:38:32 
+0100)

are available in the git repository at:

  git://github.com/rtollert/meta-mono dev/rtollert/v5/mono-cfg
  https://github.com/rtollert/meta-mono/tree/dev/rtollert/v5/mono-cfg

Richard Tollerton (1):
  mono.bbclass: set MONO_CFG_DIR

 classes/mono.bbclass | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.4.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel header missing for specific Target

[Bruce Ashfield]

On 15-07-17 09:55 AM, Gorny Krystian wrote:

I'm using the fido branch. My iointerrupt.bb file looks as follow:


DESCRIPTION = "Simple IO-interrupt driver"
SECTION = "iointerrupt"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PR = "r0"

SRC_URI = "file://drv_iointerrupt.c"
S = "${WORKDIR}"
do_compile() {
  ${CC} drv_iointerrupt.c -o iointerrupt
}


And so I'm clear .. this is a standard .ko ? Or a userspace kernel driver ?

If you are looking for the internal kernel sources to be on the include
path, you need to reference STAGING_KERNEL_DIR (and something has to
depend on the kernel do_shared_workdir task to get the right bits
in place).

 recipes-kernel/lttng/lttng-modules_2.6.1.bb

Is an example of both.

Bruce


do_install() {
  install -d ${D}${bindir}
  install -m 0755 iointerrupt ${D}${bindir}
}

Thanks,
Krystian

_

Krystian Gorny
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com


_

Weigh Cells | Weighing systems

See our solutions. Visit us at our events
http://www.wipotec.com/de/aktuelles/veranstaltungen/

_

Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. D?ppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, July 17, 2015 3:32 PM
To: Gorny Krystian; yocto@yoctoproject.org
Subject: Re: [yocto] Kernel header missing for specific Target

On 15-07-17 08:47 AM, Gorny Krystian wrote:

Hi

I try add to my core-image-rt image on a x86 arch my own IO driver. I
have already my own recipe, for normal user space programs everything
is working fine.

For the kernel space driver Yocto is missing at do_comile task the
asm/atomic.h header file. I have searched for the atomic.h file and
found a lot of them in the ./build/tmp/work folder. Yocto should use
one of them for the right hardware architecture right? Or is the a
something else I have forget to do?


What Yocto branch are you using ?

atomic.h is placed in the right location by the kernel build, assuming that 
your driver recipe has the proper dependencies.  Without seeing that recipe, it 
is hard to say more.

Cheers,

Bruce



Many thanks

Krystian


_

*Krystian Gorny*
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com





Legal information:
Wipotec Wiege- und Positioniersysteme GmbH HRB 2317 Kaiserslautern,
Management: T. Düppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error)
please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.







--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Kernel header files missing

[Louis Ryan]

Hi,

I am trying to do loadable kernel module development using the yocto produced 
sdk.

I can create the sdk and it works fine for application development.

There appears to be some header files missing for kernel module development.

These are the steps I went through ( I am using Beaglebone Black )

mkdir bb-yocto
cd bb-yocto
git clone -b daisy git://git.yoctoproject.org/poky.git
cd poky
source oe-init-build-env build

vi conf/local.conf
MACHINE ?= "beaglebone"

bitbake core-image-minimal

bitbake core-image-minimal -c populate_sdk

cd tmp/deploy/sdk

./poky-eglibc-x86_64-core-image-minimal-cortexa8hf-vfp-neon-toolchain-1.6.3.sh

some header files I want to use fro kernel module development like kernel.h, 
kdev_t.h appear in 

/opt/poky/bb-linux/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/linux

but some are missing like, module.h, device.h, cdev.h,uaccess.h.


Is there something else I need to do to get the missing files?

Thanks
Louis
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW29

[Jolley, Stephen K]

Current Dev Position: 1.9 Milestone 2 (M2)
Next Deadline: M2 cut off of July 27th at noon GMT

SWAT team rotation: Ross -> Cristian
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Key Status/Updates:

  *   RC2 is out of QA.  The full test report can be accessed 
here.
  *   Autobuilder intermittent failure issues are being tracked via a number of 
bugs, all tracked by bug 
7983.

Key YP 1.9 Dates:
1.9 Feature Freeze Date/M3 Cut off: Aug. 24, 2015 noon GMT
YP Final/M4 Cut off: Sept. 28, 2015 noon GMT
1.9 M1 Release Target: Before July 10, 2015  (Will miss deadline.)
1.9 M2 Release Target: Before Aug. 14, 2015
1.9 M3 Release Target: Before Sept. 11 2015
1.9 final Release Target: Before Oct. 30, 2015

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status
https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features

Tracking Metrics:
WDD 1685 (last week 1684 )
(https://wiki.yoctoproject.org/charts/combo.html)

[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mono] [PATCH 00/11] Refactor common mono build bits into mono.bbclass

[Alex J Lennon]

On 17/07/2015 15:43, Richard Tollerton wrote:
> Alex J Lennon  writes:
>
>> Richard,
>>
>> I'm having some trouble with builds here since that latest patch.
>>
>> Can you tell me, what version of Mono did you test against, and also did
>> you have Mono installed out of tree on the host system?
>> (I've had trouble in the past with the host mono being picked up
>> incorrectly)
> Sorry for the inconvenience :(
>
> I've been building mono 4.0.2.4 with these changes. I tested the build
> both on archlinux, with mono installed on the host, and inside an ubuntu
> 12.04 chroot, with mono not installed.
>
>

Thanks for coming back to me so quickly. No worries. Perhaps it's finger
trouble on my part somehow as I took the opportunity to clean up the
4.xx build a little today too.

I'm using 4.0.2.4 here too, and have been testing also with 4.0.2.5
support I added in. No mono on the host. Simple tests of the
helloworld/helloworldform apps work fine under qemux86 but I'm seeing
trouble building those updated recipes for some reason.

I'll spend a bit of time investigating.

Cheers, Alex


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mono] [PATCH 00/11] Refactor common mono build bits into mono.bbclass

[Richard Tollerton]

Alex J Lennon  writes:

> Richard,
>
> I'm having some trouble with builds here since that latest patch.
>
> Can you tell me, what version of Mono did you test against, and also did
> you have Mono installed out of tree on the host system?
> (I've had trouble in the past with the host mono being picked up
> incorrectly)

Sorry for the inconvenience :(

I've been building mono 4.0.2.4 with these changes. I tested the build
both on archlinux, with mono installed on the host, and inside an ubuntu
12.04 chroot, with mono not installed.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mono] [PATCH 00/11] Refactor common mono build bits into mono.bbclass

[Alex J Lennon]

On 17/07/2015 10:19, Alex J Lennon wrote:
>
> On 17/07/2015 00:16, Richard Tollerton wrote:
>> Building CLI packages involves lots of boilerplate recipe settings, 
>> particularly
>> involving FILES and DEPENDS. This is a first attempt at refactoring these
>> settings into a single bbclass that can be inherited by all CLI packages 
>> that do
>> not require unusual build settings.
>>
>> I attempted to refactor every recipe in the layer with these exceptions:
>>
>> - cefglue, because it doesn't actually install anything (!)
>> - monotools-server, because I haven't been able to build it successfully
>> - mono-upnp and taglib-sharp because I don't use them
>>
>>
>> The following changes since commit 136ed556de19bd497279d6c3ae8704551fb1ec4d:
>>
>>   mono-xsp-3.x.inc: use autogen.sh (2015-07-16 18:56:23 +0100)
>>
>> are available in the git repository at:
>>
>>   git://github.com/rtollert/meta-mono dev/rtollert/v4/bbclass
>>   https://github.com/rtollert/meta-mono/tree/dev/rtollert/v4/bbclass
>>
>> Richard Tollerton (11):
>>   mono.bbclass: add
>>   dbus-sharp-glib: use mono.bbclass
>>   dbus-sharp: use mono.bbclass
>>   fsharp.inc: use mono.bbclass
>>   mono-addins: use mono.bbclass
>>   mono-helloworld: use mono.bbclass
>>   mono-xsp: use mono.bbclass
>>   mono-basic-4.xx.inc: use mono.bbclass
>>   gtk-sharp.inc: use mono.bbclass and make some FILES fixes
>>   gtk-sharp-native: remove mono-native dependency
>>   gtk-sharp: remove mono-native dependency
>>
>>  classes/mono.bbclass   | 32 
>> ++
>>  recipes-mono/dbus-sharp-glib/dbus-sharp-glib.inc   | 13 ++---
>>  recipes-mono/dbus-sharp/dbus-sharp.inc | 13 +
>>  recipes-mono/fsharp/fsharp.inc | 19 +
>>  recipes-mono/gtk-sharp/gtk-sharp-native_2.12.21.bb |  2 +-
>>  recipes-mono/gtk-sharp/gtk-sharp.inc   | 23 +++-
>>  recipes-mono/gtk-sharp/gtk-sharp_2.12.21.bb|  2 +-
>>  recipes-mono/mono-addins/mono-addins.inc   | 14 ++
>>  recipes-mono/mono-basic/mono-basic-4.xx.inc| 13 +
>>  recipes-mono/mono-helloworld/mono-helloworld.inc   |  4 +--
>>  recipes-mono/mono-xsp/mono-xsp-3.x.inc |  3 +-
>>  11 files changed, 47 insertions(+), 91 deletions(-)
>>  create mode 100644 classes/mono.bbclass
>>
> Great idea - applied thanks Richard
>

Richard,

I'm having some trouble with builds here since that latest patch.

Can you tell me, what version of Mono did you test against, and also did
you have Mono installed out of tree on the host system?
(I've had trouble in the past with the host mono being picked up
incorrectly)

Thanks,

Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel header missing for specific Target

[Gorny Krystian]

I'm using the fido branch. My iointerrupt.bb file looks as follow:


DESCRIPTION = "Simple IO-interrupt driver"
SECTION = "iointerrupt"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PR = "r0"

SRC_URI = "file://drv_iointerrupt.c"
S = "${WORKDIR}"
do_compile() {
 ${CC} drv_iointerrupt.c -o iointerrupt
}
do_install() {
 install -d ${D}${bindir}
 install -m 0755 iointerrupt ${D}${bindir}
}

Thanks,
Krystian

_

Krystian Gorny
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com


_

Weigh Cells | Weighing systems

See our solutions. Visit us at our events
http://www.wipotec.com/de/aktuelles/veranstaltungen/

_

Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. D?ppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, July 17, 2015 3:32 PM
To: Gorny Krystian; yocto@yoctoproject.org
Subject: Re: [yocto] Kernel header missing for specific Target

On 15-07-17 08:47 AM, Gorny Krystian wrote:
> Hi
>
> I try add to my core-image-rt image on a x86 arch my own IO driver. I
> have already my own recipe, for normal user space programs everything
> is working fine.
>
> For the kernel space driver Yocto is missing at do_comile task the
> asm/atomic.h header file. I have searched for the atomic.h file and
> found a lot of them in the ./build/tmp/work folder. Yocto should use
> one of them for the right hardware architecture right? Or is the a
> something else I have forget to do?

What Yocto branch are you using ?

atomic.h is placed in the right location by the kernel build, assuming that 
your driver recipe has the proper dependencies.  Without seeing that recipe, it 
is hard to say more.

Cheers,

Bruce

>
> Many thanks
>
> Krystian
>
>
> _
>
> *Krystian Gorny*
> Research & Development
>
> Wipotec GmbH
> Adam-Hoffmann-Str. 26
> 67657 Kaiserslautern
>
> T +49.631.34146-0
> F +49.631.34146-8640
> http://www.wipotec.com
>
>
>
> 
>
> Legal information:
> Wipotec Wiege- und Positioniersysteme GmbH HRB 2317 Kaiserslautern,
> Management: T. Düppre, U. Wagner
>
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail in
> error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in
> this e-mail is strictly forbidden.
>
>


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel header missing for specific Target

[Bruce Ashfield]

On 15-07-17 08:47 AM, Gorny Krystian wrote:

Hi

I try add to my core-image-rt image on a x86 arch my own IO driver. I
have already my own recipe, for normal user space programs everything is
working fine.

For the kernel space driver Yocto is missing at do_comile task the
asm/atomic.h header file. I have searched for the atomic.h file and
found a lot of them in the ./build/tmp/work folder. Yocto should use one
of them for the right hardware architecture right? Or is the a something
else I have forget to do?


What Yocto branch are you using ?

atomic.h is placed in the right location by the kernel build, assuming
that your driver recipe has the proper dependencies.  Without seeing
that recipe, it is hard to say more.

Cheers,

Bruce



Many thanks

Krystian


_

*Krystian Gorny*
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com





Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. Düppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error)
please notify the sender immediately and delete this e-mail. Any
unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly
forbidden.




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Read-only file system with persistent storage

[Nikolay Dimitrov]

Hi Gary,

On 07/16/2015 02:36 PM, Gary Thomas wrote:

I'd like to set up a system with a read-only root file system
along with some persistent read-write storage.  What are the
[best] options in Poky/Yocto for this?  Is there any support
for some type of overlay file system?

Thanks for any ideas/pointers


I remember that back in my automotive days, one of my teams had to use
Genivi's persistence component:

http://projects.genivi.org/persistence-management/

There are also git repositories over there. I can't comment on the code
quality and stability, but this component is part of the Genivi
reference platform (which technically doesn't mean anything), and
there's at least 1 vehicle from a major OEM which uses this component
on the roads. As usual, keep your eyes open for possible issues.

Kind regards,
Nikolay
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] Fix LSB core sysvinit issue.

[Paul Eggleton]

Alex,

Can you please ensure patches for meta-cgl sent to this list are marked with 
[meta-cgl] in the subject?

FYI in case you didn't know, you can ensure this by adding something like the 
following to .git/config under your local clone of the repo:

[format]
subjectprefix = meta-something][PATCH
[sendemail]
to = mailing.l...@example.com

Thanks,
Paul

On Friday 17 July 2015 10:24:58 Alexandru Vaduva wrote:
> Hello Ross,
> 
> It is for meta-cgl. For CGL compliance the STD.1.0 Linux Standard Base
> Compliance requirement requires certain LSB modules compliance.
 The patch
> solves /tset/LSB.fhs/root/sbin/sbin-tc.
> 
> 
> Thanks for the input,
> Alex V.
> 
> 
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, July 17, 2015 1:16 PM
> To: Alexandru Vaduva
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] [PATCH] Fix LSB core sysvinit issue.
> 
> You don't say what layer this is for... but it looks a lot like this fix
> should go into oe-core (with an explanation of why it is needed).
 
> Ross
> 
> On 17 July 2015 at 11:05, Alexandru.Vaduva
> mailto:alexandru.vad...@enea.com>> wrote:
 From:
> Alexandra Safta mailto:alexandra.sa...@enea.com>>
> 
> [LXCR-3306]
> Signed-off-by: Alexandra Safta
> mailto:alexandra.sa...@enea.com>>
 Signed-off-by:
> Tudor Florea mailto:tudor.flo...@enea.com>>
> Signed-off-by: Alexandra Safta
> mailto:alexandra.sa...@enea.com>> ---
>  recipes-core/sysvinit/sysvinit_2.88dsf.bbappend | 3 +++
>  1 file changed, 3 insertions(+)
>  create mode 100644 recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
> 
> diff --git a/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
> b/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
 new file mode 100644
> index 000..4fd3c00
> --- /dev/null
> +++ b/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
> @@ -0,0 +1,3 @@
> +do_install_append(){
> +chmod o+x ${D}${base_sbindir}/shutdown
> +}
> --
> 1.9.1
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Kernel header missing for specific Target

[Gorny Krystian]

Hi

I try add to my core-image-rt image on a x86 arch my own IO driver. I have 
already my own recipe, for normal user space programs everything is working 
fine.
For the kernel space driver Yocto is missing at do_comile task the asm/atomic.h 
header file. I have searched for the atomic.h file and found a lot of them in 
the ./build/tmp/work folder. Yocto should use one of them for the right 
hardware architecture right? Or is the a something else I have forget to do?

Many thanks
Krystian

_

Krystian Gorny
Research & Development

Wipotec GmbH
Adam-Hoffmann-Str. 26
67657 Kaiserslautern

T +49.631.34146-0
F +49.631.34146-8640
http://www.wipotec.com


[http://www.wipotec.com/fileadmin/user_upload/Signatur/W_Standard.jpg]

Legal information:
Wipotec Wiege- und Positioniersysteme GmbH
HRB 2317 Kaiserslautern, Management: T. D?ppre, U. Wagner

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] Fix LSB core sysvinit issue.

[Alexandru Vaduva]

Hello Ross,

It is for meta-cgl. For CGL compliance the STD.1.0 Linux Standard Base 
Compliance requirement requires certain LSB modules compliance.
The patch solves /tset/LSB.fhs/root/sbin/sbin-tc.


Thanks for the input,
Alex V.


From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, July 17, 2015 1:16 PM
To: Alexandru Vaduva
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [PATCH] Fix LSB core sysvinit issue.

You don't say what layer this is for... but it looks a lot like this fix should 
go into oe-core (with an explanation of why it is needed).

Ross

On 17 July 2015 at 11:05, Alexandru.Vaduva 
mailto:alexandru.vad...@enea.com>> wrote:
From: Alexandra Safta 
mailto:alexandra.sa...@enea.com>>

[LXCR-3306]
Signed-off-by: Alexandra Safta 
mailto:alexandra.sa...@enea.com>>
Signed-off-by: Tudor Florea 
mailto:tudor.flo...@enea.com>>
Signed-off-by: Alexandra Safta 
mailto:alexandra.sa...@enea.com>>
---
 recipes-core/sysvinit/sysvinit_2.88dsf.bbappend | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 recipes-core/sysvinit/sysvinit_2.88dsf.bbappend

diff --git a/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend 
b/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
new file mode 100644
index 000..4fd3c00
--- /dev/null
+++ b/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
@@ -0,0 +1,3 @@
+do_install_append(){
+chmod o+x ${D}${base_sbindir}/shutdown
+}
--
1.9.1

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] clone multiple git source repository from single recipe file

[Burton, Ross]

On 17 July 2015 at 10:32, Anooj Gopi  wrote:

> But now I would like to clone two git repository, which of course have
> different hash value to be checked-out. Is it possible to do that in yocto?
>

Almost the same syntax.  I'm not sure why you're using pn-${BPN} notation
in a recipe, but this is from gstreamer1.0-omx:

SRC_URI = " \
git://
anongit.freedesktop.org/gstreamer/gst-omx;branch=master;name=gst-omx \
git://
anongit.freedesktop.org/gstreamer/common;destsuffix=git/common;branch=master;name=common
"

SRCREV_gst-omx = "a2db76b048db278ef0aa798e106b7594264e06c0"
SRCREV_common = "5edcd857b2107cd8b78c16232dd10877513ec157"

Basically, give each URI a name, and then use the names in SRCREV overrides.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] Fix LSB core sysvinit issue.

[Burton, Ross]

You don't say what layer this is for... but it looks a lot like this fix
should go into oe-core (with an explanation of why it is needed).

Ross

On 17 July 2015 at 11:05, Alexandru.Vaduva 
wrote:

> From: Alexandra Safta 
>
> [LXCR-3306]
> Signed-off-by: Alexandra Safta 
> Signed-off-by: Tudor Florea 
> Signed-off-by: Alexandra Safta 
> ---
>  recipes-core/sysvinit/sysvinit_2.88dsf.bbappend | 3 +++
>  1 file changed, 3 insertions(+)
>  create mode 100644 recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
>
> diff --git a/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
> b/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
> new file mode 100644
> index 000..4fd3c00
> --- /dev/null
> +++ b/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
> @@ -0,0 +1,3 @@
> +do_install_append(){
> +chmod o+x ${D}${base_sbindir}/shutdown
> +}
> --
> 1.9.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] Fix LSB core sysvinit issue.

[Alexandru . Vaduva]

From: Alexandra Safta 

[LXCR-3306]
Signed-off-by: Alexandra Safta 
Signed-off-by: Tudor Florea 
Signed-off-by: Alexandra Safta 
---
 recipes-core/sysvinit/sysvinit_2.88dsf.bbappend | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 recipes-core/sysvinit/sysvinit_2.88dsf.bbappend

diff --git a/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend 
b/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
new file mode 100644
index 000..4fd3c00
--- /dev/null
+++ b/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
@@ -0,0 +1,3 @@
+do_install_append(){
+chmod o+x ${D}${base_sbindir}/shutdown
+}
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] VLC compile problem

[Andrej Šimko]

Hello,

i have problem to compile vlc, in attachment is a detailed output, I
dont know what to do next. Can somebody help me?

I have also another question, i cannot find recipes for packages:
usbview ssmtp xtables-addons freenx xf86-video-dummy ftdi-eeprom, if I
tried create-recipe not always I get result, is there something better
than the actual script?

Thanks for any info.

Regards,
Andrej
DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
DEBUG: Executing shell function autotools_preconfigure
DEBUG: Shell function autotools_preconfigure finished
DEBUG: Executing python function autotools_copy_aclocals
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
DEBUG: Python function autotools_copy_aclocals finished
DEBUG: Executing shell function do_configure
automake (GNU automake) 1.15
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey 
   and Alexandre Duret-Lutz .
AUTOV is 1
NOTE: Executing ACLOCAL="aclocal 
--system-acdir=/mnt/sdb/poky/build/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/vlc/2.1.4-r0/build/aclocal-copy/"
 autoreconf --verbose --install --force --exclude=autopoint -I 
/mnt/sdb/poky/build/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/vlc/2.1.4-r0/vlc-2.1.4/m4/
autoreconf: Entering directory `.'
autoreconf: running: aclocal 
--system-acdir=/mnt/sdb/poky/build/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/vlc/2.1.4-r0/build/aclocal-copy/
 -I 
/mnt/sdb/poky/build/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/vlc/2.1.4-r0/vlc-2.1.4/m4/
 -I 
/mnt/sdb/poky/build/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/vlc/2.1.4-r0/vlc-2.1.4/m4/
 --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'autotools'.
libtoolize: copying file 'autotools/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running: 
/mnt/sdb/poky/build/tmp/sysroots/i686-linux/usr/bin/autoconf 
--include=/mnt/sdb/poky/build/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/vlc/2.1.4-r0/vlc-2.1.4/m4/
 --force
autoreconf: running: 
/mnt/sdb/poky/build/tmp/sysroots/i686-linux/usr/bin/autoheader 
--include=/mnt/sdb/poky/build/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/vlc/2.1.4-r0/vlc-2.1.4/m4/
 --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:55: installing 'autotools/compile'
configure.ac:27: installing 'autotools/missing'
bin/Makefile.am: installing 'autotools/depcomp'
autoreconf: running: gnu-configize
autoreconf: Leaving directory `.'
NOTE: Running 
/mnt/sdb/poky/build/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/vlc/2.1.4-r0/vlc-2.1.4/configure
  --build=i686-linux  --host=arm-poky-linux-gnueabi 
  --target=arm-poky-linux-gnueabi --prefix=/usr 
  --exec_prefix=/usr  --bindir=/usr/bin   
--sbindir=/usr/sbin --libexecdir=/usr/lib/vlc   
--datadir=/usr/share--sysconfdir=/etc   
--sharedstatedir=/com   --localstatedir=/var
--libdir=/usr/lib   --includedir=/usr/include   
--oldincludedir=/usr/include--infodir=/usr/share/info   
--mandir=/usr/share/man --disable-silent-rules  
--disable-dependency-tracking   
--with-libtool-sysroot=/mnt/sdb/poky/build/tmp/sysroots/olinuxino-a20 
--enable-dvdread --with-contrib --enable-run-as-root 
--enable-xvideo --disable-screen --disable-caca --enable-httpd 
--enable-vlm --enable-freetype --enable-sdl --enable-png 
--enable-tremor --enable-v4l2 --disable-aa --disable-faad --enable-dbus 
--without-contrib --without-kde-solid --disable-glx 
--enable-realrtsp --disable-libtar 
ac_cv_path_MOC=/mnt/sdb/poky/build/tmp/sysroots/i686-linux/usr/bin/moc4 
ac_cv_path_RCC=/mnt/sdb/poky/build/tmp/sysroots/i686-linux/usr/bin/rcc4 
ac_cv_path_UIC=/mnt/sdb/poky/build/tmp/sysroots/i686-linux/usr/bin/uic4   
--enable-libxml2=no --enable-nls --disable-a52 --disable-jack --disable-libass 
--disable-libva --disable-avcodec --enable-live555 

[yocto] clone multiple git source repository from single recipe file

[Anooj Gopi]

Hello All,

How can we checkout two git repo into work directory?

In SVN we do something like below:

SRC_URI = "svn://
example.com/trunk/OneDirectory;module=SubDirectory1;protocol=http;user=theuser;pswd=thepassword
\
svn://
example.com/trunk/OneDirectory;module=SubDirectory2;protocol=http;user=theuser;pswd=thepassword
"

SRCREV_default_pn-${BPN} = "svn-rev-no"

But now I would like to clone two git repository, which of course have
different hash value to be checked-out. Is it possible to do that in yocto?

Best Regards,
Anooj Gopi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mono] [PATCH 00/11] Refactor common mono build bits into mono.bbclass

[Alex J Lennon]

On 17/07/2015 00:16, Richard Tollerton wrote:
> Building CLI packages involves lots of boilerplate recipe settings, 
> particularly
> involving FILES and DEPENDS. This is a first attempt at refactoring these
> settings into a single bbclass that can be inherited by all CLI packages that 
> do
> not require unusual build settings.
>
> I attempted to refactor every recipe in the layer with these exceptions:
>
> - cefglue, because it doesn't actually install anything (!)
> - monotools-server, because I haven't been able to build it successfully
> - mono-upnp and taglib-sharp because I don't use them
>
>
> The following changes since commit 136ed556de19bd497279d6c3ae8704551fb1ec4d:
>
>   mono-xsp-3.x.inc: use autogen.sh (2015-07-16 18:56:23 +0100)
>
> are available in the git repository at:
>
>   git://github.com/rtollert/meta-mono dev/rtollert/v4/bbclass
>   https://github.com/rtollert/meta-mono/tree/dev/rtollert/v4/bbclass
>
> Richard Tollerton (11):
>   mono.bbclass: add
>   dbus-sharp-glib: use mono.bbclass
>   dbus-sharp: use mono.bbclass
>   fsharp.inc: use mono.bbclass
>   mono-addins: use mono.bbclass
>   mono-helloworld: use mono.bbclass
>   mono-xsp: use mono.bbclass
>   mono-basic-4.xx.inc: use mono.bbclass
>   gtk-sharp.inc: use mono.bbclass and make some FILES fixes
>   gtk-sharp-native: remove mono-native dependency
>   gtk-sharp: remove mono-native dependency
>
>  classes/mono.bbclass   | 32 
> ++
>  recipes-mono/dbus-sharp-glib/dbus-sharp-glib.inc   | 13 ++---
>  recipes-mono/dbus-sharp/dbus-sharp.inc | 13 +
>  recipes-mono/fsharp/fsharp.inc | 19 +
>  recipes-mono/gtk-sharp/gtk-sharp-native_2.12.21.bb |  2 +-
>  recipes-mono/gtk-sharp/gtk-sharp.inc   | 23 +++-
>  recipes-mono/gtk-sharp/gtk-sharp_2.12.21.bb|  2 +-
>  recipes-mono/mono-addins/mono-addins.inc   | 14 ++
>  recipes-mono/mono-basic/mono-basic-4.xx.inc| 13 +
>  recipes-mono/mono-helloworld/mono-helloworld.inc   |  4 +--
>  recipes-mono/mono-xsp/mono-xsp-3.x.inc |  3 +-
>  11 files changed, 47 insertions(+), 91 deletions(-)
>  create mode 100644 classes/mono.bbclass
>

Great idea - applied thanks Richard

Cheers, Alex

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] virtual/kernel: add support for IPMI.

[Alexandru . Vaduva]

Signed-off-by: Alexandru.Vaduva 
---
 meta-cgl-common/recipes-kernel/linux/cgl-common.inc  | 1 +
 meta-cgl-common/recipes-kernel/linux/files/cfg/00025-ipmi.cfg| 9 +
 .../recipes-kernel/linux/linux-qoriq-prt_3.12.bbappend   | 1 +
 3 files changed, 11 insertions(+)
 create mode 100644 
meta-cgl-common/recipes-kernel/linux/files/cfg/00025-ipmi.cfg

diff --git a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc 
b/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
index ffd0b74..2ed1920 100644
--- a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
+++ b/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
@@ -21,5 +21,6 @@ SRC_URI += "file://cfg/1-systemtap.cfg \
 file://cfg/00022-coredump.cfg \
 file://cfg/00023-open-scsi.cfg \
 file://cfg/00024-ftrace.cfg \
+file://cfg/00025-ipmi.cfg \
"
 
diff --git a/meta-cgl-common/recipes-kernel/linux/files/cfg/00025-ipmi.cfg 
b/meta-cgl-common/recipes-kernel/linux/files/cfg/00025-ipmi.cfg
new file mode 100644
index 000..90e9f6e
--- /dev/null
+++ b/meta-cgl-common/recipes-kernel/linux/files/cfg/00025-ipmi.cfg
@@ -0,0 +1,9 @@
+CONFIG_IPMI_HANDLER=y
+CONFIG_IPMI_PANIC_EVENT=y
+CONFIG_IPMI_PANIC_STRING=y
+CONFIG_IPMI_DEVICE_INTERFACE=y
+CONFIG_IPMI_SI=y
+CONFIG_IPMI_WATCHDOG=y
+CONFIG_IPMI_POWEROFF=y
+# CONFIG_SENSORS_IBMAEM is not set
+# CONFIG_SENSORS_IBMPEX is not set
diff --git 
a/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq-prt_3.12.bbappend 
b/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq-prt_3.12.bbappend
index 2376daa..e33d72d 100644
--- a/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq-prt_3.12.bbappend
+++ b/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq-prt_3.12.bbappend
@@ -23,4 +23,5 @@ DELTA_KERNEL_DEFCONFIG += "cfg/1-systemtap.cfg \
 cfg/00022-coredump.cfg \
 cfg/00023-open-scsi.cfg \
 cfg/00024-ftrace.cfg \
+cfg/00025-ipmi.cfg \
 "
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] Update SELinux configuration.

[Alexandru . Vaduva]

From: Siva Borra 

Update SELinux with all dependant confuguation
options enabled/disabled.

[LXCR-5167]

Signed-off-by: Siva Borra 
Signed-off-by: Alexandru.Vaduva 
---
 .../linux/files/cfg/00014-selinux.cfg  | 29 ++
 1 file changed, 29 insertions(+)

diff --git a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg 
b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
index 377ec83..ce7d61d 100644
--- a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
+++ b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
@@ -1 +1,30 @@
+CONFIG_DEFAULT_SECURITY_SELINUX=y
+CONFIG_SECURITY=y
+CONFIG_SYSFS=y
+CONFIG_SECURITY_NETWORK=y
+CONFIG_AUDIT=y
+CONFIG_NET=y
+CONFIG_INET=y
 CONFIG_SECURITY_SELINUX=y
+CONFIG_SECURITY_NETWORK_XFRM=y
+CONFIG_NETWORK_SECMARK=y
+CONFIG_EXT2_FS_XATTR=y
+CONFIG_EXT3_FS_XATTR=y
+CONFIG_EXT4_FS_XATTR=y
+CONFIG_REISERFS_FS_XATTR=y
+CONFIG_JFFS2_FS_XATTR=y
+CONFIG_EXT2_FS_SECURITY=y
+CONFIG_EXT3_FS_SECURITY=y
+CONFIG_EXT4_FS_SECURITY=y
+CONFIG_JFS_SECURITY=y
+CONFIG_REISERFS_FS_SECURITY=y
+CONFIG_JFFS2_FS_SECURITY=y
+CONFIG_SECURITYFS=y
+CONFIG_SECURITY_SELINUX_BOOTPARAM=y
+CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
+CONFIG_SECURITY_SELINUX_DISABLE=y
+CONFIG_SECURITY_SELINUX_DEVELOP=y
+CONFIG_SECURITY_SELINUX_AVC_STATS=y
+CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
+CONFIG_AUDIT_ARCH=n
+CONFIG_AUDIT_GENERIC=y
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] Remove dbg packages for LSB bin-tc core test

[Alexandru . Vaduva]

From: Alexandra Safta 

Signed-off-by: Alexandra Safta 
---
 meta-cgl-common/images/core-image-cgl.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/images/core-image-cgl.bb 
b/meta-cgl-common/images/core-image-cgl.bb
index 395f9dc..d12391b 100644
--- a/meta-cgl-common/images/core-image-cgl.bb
+++ b/meta-cgl-common/images/core-image-cgl.bb
@@ -25,4 +25,4 @@ IMAGE_INSTALL += "\
 KEXECTOOLS_mips ?= ""
 KEXECTOOLS_mipsel ?= ""
 
-IMAGE_FEATURES += "eclipse-debug tools-debug tools-profile dbg-pkgs"
+IMAGE_FEATURES += "tools-debug tools-profile"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] Update config to bring dm-multipath

[Alexandru . Vaduva]

From: Siva Borra 

Update the configuration to bring dm-multipath
and scsi_dh.

[LXCR-5152]

Signed-off-by: Siva Borra 
Signed-off-by: Alexandru.Vaduva 
---
 .../linux/files/cfg/7-device-mapper-multipath.cfg  | 7 +++
 1 file changed, 7 insertions(+)

diff --git 
a/meta-cgl-common/recipes-kernel/linux/files/cfg/7-device-mapper-multipath.cfg
 
b/meta-cgl-common/recipes-kernel/linux/files/cfg/7-device-mapper-multipath.cfg
index 39cf942..89825db 100644
--- 
a/meta-cgl-common/recipes-kernel/linux/files/cfg/7-device-mapper-multipath.cfg
+++ 
b/meta-cgl-common/recipes-kernel/linux/files/cfg/7-device-mapper-multipath.cfg
@@ -1,3 +1,10 @@
+CONFIG_MD=y
+CONFIG_BLK_DEV_MD=y
+CONFIG_BLK_DEV_DM=y
+CONFIG_MD_MULTIPATH=y
+CONFIG_DM_RAID=y
 CONFIG_DM_MULTIPATH=y
 CONFIG_DM_MULTIPATH_QL=y
 CONFIG_DM_MULTIPATH_ST=y
+CONFIG_SCSI=y
+CONFIG_SCSI_DH=y
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] add recipe append for linux-qoriq-prt kernel

[Alexandru . Vaduva]

From: Matei Valeanu 

PREEMPT_RT is not enabled, but use this recipe in case we need PREEMPT_RT 
enabled

Signed-off-by: Matei Valeanu 
---
 .../linux/linux-qoriq-prt_3.12.bbappend| 26 ++
 .../recipes-kernel/linux/linux-qoriq_3.12.bbappend | 26 --
 2 files changed, 26 insertions(+), 26 deletions(-)
 create mode 100644 
meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq-prt_3.12.bbappend
 delete mode 100644 
meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq_3.12.bbappend

diff --git 
a/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq-prt_3.12.bbappend 
b/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq-prt_3.12.bbappend
new file mode 100644
index 000..2376daa
--- /dev/null
+++ b/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq-prt_3.12.bbappend
@@ -0,0 +1,26 @@
+require recipes-kernel/linux/cgl-common.inc
+
+SRC_URI += ""
+
+DELTA_KERNEL_DEFCONFIG += "cfg/1-systemtap.cfg \
+cfg/2-oprofile.cfg \
+cfg/3-lttng.cfg \
+cfg/4-kgdb.cfg \
+cfg/5-quota.cfg \
+cfg/7-device-mapper-multipath.cfg \
+cfg/8-libcgroup.cfg \
+cfg/9-filesystem-acl.cfg \
+cfg/00010-ext4.cfg \
+cfg/00011-raid-1.cfg \
+cfg/00012-hyper-threading.cfg \
+cfg/00013-dot1q-vlans.cfg \
+cfg/00014-selinux.cfg \
+cfg/00015-managing-transient-data.cfg \
+cfg/00016-dynamic-probe-insertion-kprobe.cfg \
+cfg/00018-ipsec.cfg \
+cfg/00019-raid-0.cfg \
+cfg/00021-sctp.cfg \
+cfg/00022-coredump.cfg \
+cfg/00023-open-scsi.cfg \
+cfg/00024-ftrace.cfg \
+"
diff --git a/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq_3.12.bbappend 
b/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq_3.12.bbappend
deleted file mode 100644
index 2376daa..000
--- a/meta-cgl-fsl-ppc/recipes-kernel/linux/linux-qoriq_3.12.bbappend
+++ /dev/null
@@ -1,26 +0,0 @@
-require recipes-kernel/linux/cgl-common.inc
-
-SRC_URI += ""
-
-DELTA_KERNEL_DEFCONFIG += "cfg/1-systemtap.cfg \
-cfg/2-oprofile.cfg \
-cfg/3-lttng.cfg \
-cfg/4-kgdb.cfg \
-cfg/5-quota.cfg \
-cfg/7-device-mapper-multipath.cfg \
-cfg/8-libcgroup.cfg \
-cfg/9-filesystem-acl.cfg \
-cfg/00010-ext4.cfg \
-cfg/00011-raid-1.cfg \
-cfg/00012-hyper-threading.cfg \
-cfg/00013-dot1q-vlans.cfg \
-cfg/00014-selinux.cfg \
-cfg/00015-managing-transient-data.cfg \
-cfg/00016-dynamic-probe-insertion-kprobe.cfg \
-cfg/00018-ipsec.cfg \
-cfg/00019-raid-0.cfg \
-cfg/00021-sctp.cfg \
-cfg/00022-coredump.cfg \
-cfg/00023-open-scsi.cfg \
-cfg/00024-ftrace.cfg \
-"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] Fix for profile.d-tc LSB core test

[Alexandru . Vaduva]

From: Alexandra Safta 

Signed-off-by: Alexandra Safta 
---
 meta-cgl-common/recipes-core/base-files/base-files_3.0.14.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 
meta-cgl-common/recipes-core/base-files/base-files_3.0.14.bbappend

diff --git a/meta-cgl-common/recipes-core/base-files/base-files_3.0.14.bbappend 
b/meta-cgl-common/recipes-core/base-files/base-files_3.0.14.bbappend
new file mode 100644
index 000..e13da3d
--- /dev/null
+++ b/meta-cgl-common/recipes-core/base-files/base-files_3.0.14.bbappend
@@ -0,0 +1 @@
+dirs755-lsb += "/etc/profile.d/"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto