Re: [yocto] Eclipse CMake Errors

[Zhang, Jessica]

Could you please file a bug for this in yocto project bugzilla?

Thanks,
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Sébastien Taylor
Sent: Friday, May 09, 2014 11:27 AM
To: yocto@yoctoproject.org
Subject: [yocto] Eclipse CMake Errors

When using an Eclipse Yocto CMake project, errors in cmake are simply reported 
as a generic error.  Is there an existing method of having the plugin display 
the detailed cmake stdout/stderr output instead?

Example error, 'Configuring project' has encountered a problem.  Build of 
project failed 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] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Bryan Evenson]

Brian,

> -Original Message-
> From: Brian Karcz [mailto:bri...@russound.com]
> Sent: Friday, May 09, 2014 3:49 PM
> To: Bryan Evenson; Bruce Ashfield; yocto@yoctoproject.org
> Subject: RE: [yocto] [meta-atmel] at91sam9x5ek: "no machine record
> defined" failure for core-image-minimal
> 
> Hi Bryan,
> 
> Thanks for the tip. Any chance you tried assigning the PREFFERED_VERSION
> to 3.6.9 and using the linux4sam meta-atmel layer as is?
> 
> I'll definitely check out your layer. I was hoping the at91sam9x5ek would just
> build so that I could start tweaking it to define a machine works for its 
> little
> brother, the at91sam9g20ek.
> 
> I'm coming from an older 2.6.30 kernel that used a board file instead of the
> device tree and was planning to use the demo build from meta-atmel and
> some small mods to give myself a crash course on device tree development.
> Looks like the learning curve might have steepened a bit.

I would take a look at using at least the 3.10 kernel from Atmel.  It's the 
most stable one they have and it's where they've been backporting additional 
device tree support.  I believe if you use my defconfig, you should be able to 
build a 3.10 kernel with Atmel's latest layer.  And definitely start reading up 
on device tree development.  It takes some getting used to but it is a good 
step forward.

Regards,
Bryan

> 
> Thanks,
> Brian
> 
> -Original Message-
> From: Bryan Evenson [mailto:beven...@melinkcorp.com]
> Sent: Friday, May 09, 2014 3:31 PM
> To: Bruce Ashfield; Brian Karcz; yocto@yoctoproject.org
> Subject: RE: [yocto] [meta-atmel] at91sam9x5ek: "no machine record
> defined" failure for core-image-minimal
> 
> Brian,
> 
> I'm currently using a fork of the meta-atmel layer for my at91sam9g25 board.
> If I remember when they added at91sam9x5 support for meta-atmel, I think
> the layer was on kernel 3.6.9 and now it's on 3.10.  There's been a lot of
> machine and device tree related configuration changes for this chipset
> between 3.6.9 and 3.10, so that configuration might not work for 3.10.
> 
> The configuration I'm currently using is over at
> https://github.com/evensonbryan/meta-atmel/tree/master/recipes-
> kernel/linux/files/at91sam9x5ek/linux-3.10-at91.  It also has some patches I
> added in to pick up some missing peripheral support for my system.  You may
> want to give that a try and see if it helps.
> 
> Regards,
> Bryan

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

Re: [yocto] SATO on Intel DN2800MT

[r10kindsofpeople]

On Thu, May 8, 2014 at 3:43 PM, Chris Tapp  wrote:

> On 8 May 2014, at 18:52, r10kindsofpeople 
> wrote:
>
> > On Thu, May 8, 2014 at 12:39 PM, Chris Tapp 
> wrote:
> > Hi John,
> >
> > On 8 May 2014, at 16:25, r10kindsofpeople 
> wrote:
> >
> > > I'm trying to experiment with the SATO build on a DN2800MT with a VGA
> monitor, but can't seem to get going.  The binaries from Daisy and
> genericX86 get as far as the Yocto progress bar complete, and then go
> black.  Any quick hints?
> >
> > Have a look in the README file for the cedartrail BSP. At the bottom you
> will find:
> >
> > Work Around for VGA and LVDS Display issue in PVR driver
> > 
> >
> > The PVR driver has a issue that for some systems it causes
> > it to incorrectly assume that a LVDS display is connected
> > while infact a VGA display is connected and Vice Versa.
> > If your VGA or LVDS display does not work with
> > "cedartrail" MACHINE, then if you have connected a VGA display,
> > add the following to the kernel command line:
> >
> > video=LVDS-1:d video=VGA-1:e
> >
> > 
> >
> > I suspect it's this. Watch out if you use HDMI as well - the VGA fix
> seems to break HDMI. On my systems the VGA then works, but the HDMI pauses
> a lot running the same image! I think you can use similar magic for HDMI
> (or did I just take it out?).
> >
> > > I note also that genericX86 looks like a complete Yocto tree rather
> than just BSP layers.  Am I right, and are there hints on how to combine
> this with a generic Daisy tree for other processors/projects?
> > >
> > >
> Yocto_11_0_0/genericx86-daisy-11.0.0/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/genericx86/xorg.conf
> is a zero length file.   ?
> > >
> > > John
> > > --
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> >
> > Chris Tapp
> >
> > opensou...@keylevel.com
> > www.keylevel.com
> >
> >
> >
> > Chris,
> >
> > Thanks!  What version Yocto are you using?  I ask because you suggest I
> check the README file for the cedartrail BSP, but I've been unable to FIND
> a cedartrail BSP in anything newer than Denzil, and that only by searching
> the git trees.  genericX86 is said to cover cedartrail, but it does seem,
> well, generic, with nothing particularly specific to cedartrail, and much
> more than what I'm used to in a Yocto BSP.
>
> I'm using 'danny' as that's the latest version which includes video
> hardware acceleration for the DN2800.
>
> >   At any rate, I'll try what you suggest in terms of the kernel command
> line.
>
> The README says this fixes the issue for the PVR drivers, but I don't
> think they're included in later versions.
>
> If you've still got problems, it may be worth posting to the meta-intel
> mailing list as well as that's where Intel BSPs are discussed.
>
> > Thanks again,
> >
> > John
>
> Chris Tapp
>
> opensou...@keylevel.com
> www.keylevel.com
>
>
>
>
For what it's worth, it seems to do the trick with Daisy.

In local.conf
APPEND_genericx86 = "video=LVDS-1:d video=VGA-1:e"

THANKS!

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

Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Brian Karcz]

Hi Bryan,

Thanks for the tip. Any chance you tried assigning the PREFFERED_VERSION to 
3.6.9 and using the linux4sam meta-atmel layer as is?

I'll definitely check out your layer. I was hoping the at91sam9x5ek would just 
build so that I could start tweaking it to define a machine works for its 
little brother, the at91sam9g20ek.

I'm coming from an older 2.6.30 kernel that used a board file instead of the 
device tree and was planning to use the demo build from meta-atmel and some 
small mods to give myself a crash course on device tree development. Looks like 
the learning curve might have steepened a bit.

Thanks,
Brian

-Original Message-
From: Bryan Evenson [mailto:beven...@melinkcorp.com] 
Sent: Friday, May 09, 2014 3:31 PM
To: Bruce Ashfield; Brian Karcz; yocto@yoctoproject.org
Subject: RE: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" 
failure for core-image-minimal

Brian,

I'm currently using a fork of the meta-atmel layer for my at91sam9g25 board.  
If I remember when they added at91sam9x5 support for meta-atmel, I think the 
layer was on kernel 3.6.9 and now it's on 3.10.  There's been a lot of machine 
and device tree related configuration changes for this chipset between 3.6.9 
and 3.10, so that configuration might not work for 3.10.

The configuration I'm currently using is over at 
https://github.com/evensonbryan/meta-atmel/tree/master/recipes-kernel/linux/files/at91sam9x5ek/linux-3.10-at91.
  It also has some patches I added in to pick up some missing peripheral 
support for my system.  You may want to give that a try and see if it helps.

Regards,
Bryan

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

Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Bryan Evenson]

Brian,

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
> Sent: Friday, May 09, 2014 2:42 PM
> To: Brian Karcz; yocto@yoctoproject.org
> Subject: Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record
> defined" failure for core-image-minimal
> 
> On 14-05-09 10:58 AM, Brian Karcz wrote:
> > Hi Bruce,
> >
> > I'm not entirely familiar with the mechanism that gets the defconfig from
> the BSP to the .config in work area, but here is how things currently look. 
> The
> two files aren't a direct match as there appear to be some formatting
> differences, but the variables in the SOC/ARCH section seem to correlate
> partially (ie. it knows its trying to build for an at91sam9x5 SOC).

I'm currently using a fork of the meta-atmel layer for my at91sam9g25 board.  
If I remember when they added at91sam9x5 support for meta-atmel, I think the 
layer was on kernel 3.6.9 and now it's on 3.10.  There's been a lot of machine 
and device tree related configuration changes for this chipset between 3.6.9 
and 3.10, so that configuration might not work for 3.10.

The configuration I'm currently using is over at 
https://github.com/evensonbryan/meta-atmel/tree/master/recipes-kernel/linux/files/at91sam9x5ek/linux-3.10-at91.
  It also has some patches I added in to pick up some missing peripheral 
support for my system.  You may want to give that a try and see if it helps.

Regards,
Bryan

> >
> > defconfig:
> > CONFIG_ARCH_AT91=y
> > CONFIG_SOC_AT91SAM9260=y
> > CONFIG_SOC_AT91SAM9263=y
> > CONFIG_SOC_AT91SAM9G45=y
> > CONFIG_SOC_AT91SAM9X5=y
> > CONFIG_MACH_AT91SAM_DT=y
> >
> > .config:
> > #
> > # Atmel AT91 Processor
> > #
> > # CONFIG_SOC_AT91RM9200 is not set
> > CONFIG_SOC_AT91SAM9260=y
> > # CONFIG_SOC_AT91SAM9261 is not set
> > CONFIG_SOC_AT91SAM9263=y
> > # CONFIG_SOC_AT91SAM9RL is not set
> > CONFIG_SOC_AT91SAM9G45=y
> > CONFIG_SOC_AT91SAM9X5=y
> > # CONFIG_SOC_AT91SAM9N12 is not set
> >
> > #
> > # Atmel Non-DT world
> > #
> > CONFIG_ARCH_AT91_NONE=y
> > # CONFIG_ARCH_AT91RM9200 is not set
> > # CONFIG_ARCH_AT91SAM9260 is not set
> > # CONFIG_ARCH_AT91SAM9261 is not set
> > # CONFIG_ARCH_AT91SAM9263 is not set
> > # CONFIG_ARCH_AT91SAM9RL is not set
> > # CONFIG_ARCH_AT91SAM9G45 is not set
> >
> > #
> > # AT91 Board Options
> > #
> >
> > #
> > # Generic Board Type
> > #
> > # CONFIG_MACH_AT91SAM9_DT is not set
> >
> > Given the fact that the ARCH and DT variables don't appear to match, it
> looks like this might be device tree related.
> 
> The reason I asked is that in the past, the error you are seeing was related 
> to
> the machine not being properly defined in the kernel's .config.
> 
> FWIW, assuming you have a full "defconfig", and not a "save_defconfig"
> variant, the path from it to the final .config is pretty much a copy into the
> kernel and a "make oldconfig", so nothing is thrown away unless there is a
> missing dependency, or the Kconfig doesn't exist in the given kernel.
> 
> It's worth checking via menuconfig to see if anything obvious is missing, and
> trying some quick builds to rule out a bad configuration.
> 
> Bruce
> 
> >
> > I was hoping the code out of the box was going to be able to provide a
> demo image that I could build and poke around in for some guidance. My
> ultimate goal is to port the at91sam9x5ek machine definition to one for the
> at91sam9g20ek demo board and then port THAT over to a custom machine
> based roughly off that reference design.
> >
> >
> > -Original Message-
> > From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> > Sent: Friday, May 09, 2014 9:55 AM
> > To: Brian Karcz; yocto@yoctoproject.org
> > Subject: Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record
> > defined" failure for core-image-minimal
> >
> > On 14-05-09 09:44 AM, Brian Karcz wrote:
> >> Hi,
> >>
> >> Not sure if this is the correct place to email this, but I've seen a
> >> few other meta-atmel references so I figured I'd give it a shot.
> >>
> >> I'm attempting to setup a core-image-minimal build using the
> >> guidelines in the meta-atmel README for the at91sam9x5ek machine
> type.
> >> When the kernel build goes to link, I get a "no machine record
> >> defined" error. Is this something others are seeing in the meta-atmel
> demo builds?
> >>
> >> It's a pretty benign build setup according to the README:
> >>
> >> git clone git://git.yoctoproject.org/poky
> >>
> >> cd poky
> >>
> >> git checkout dora-10.0.1 -b dora-10.0.1
> >>
> >> git clone git://git.openembedded.org/meta-openembedded
> >>
> >> cd meta-openembedded
> >>
> >> git checkout 6572316557e742c2dc93848e4d560242bf0c3995 -b my_branch
> >>
> >> cd ..
> >>
> >> git clone http://github.com/linux4sam/meta-atmel
> >>
> >> source oe-init-build-env /workspace/build-atmel
> >>
> >> modify local.conf:
> 

Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Brian Karcz]

Hi Bruce,

Yeah, that's the avenue I'm going to have to go down. I was hoping to avoid the 
trial by fire approach and learn by making small mods to an existing working 
build, but it looks like that might not be in the cards. I was hoping that one 
of the at91/linux4sam people or someone familiar with meta-atmel might be 
lurking in here and have seen the same issue when following the instructions in 
the layer's README file and have a "oh yeah, just tweak this..." fix.

I'll have to take a look through some of the linux-yocto-custom log files to 
see where the .config is getting generated from and whether the defconfig from 
the BSP kernel recipe is playing a roll in it. I'm guessing without an explicit 
board file (which there isn't) and the CONFIG_MACH_AT91SAM9_DT parameter not 
making its way from defconfig to the .config, that would explain why there is 
no machine record macro being declared.

I'll keep digging...

Thanks,
Brian

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Friday, May 09, 2014 2:42 PM
To: Brian Karcz; yocto@yoctoproject.org
Subject: Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" 
failure for core-image-minimal

The reason I asked is that in the past, the error you are seeing was related to 
the machine not being properly defined in the kernel's .config.

FWIW, assuming you have a full "defconfig", and not a "save_defconfig"
variant, the path from it to the final .config is pretty much a copy into the 
kernel and a "make oldconfig", so nothing is thrown away unless there is a 
missing dependency, or the Kconfig doesn't exist in the given kernel.

It's worth checking via menuconfig to see if anything obvious is missing, and 
trying some quick builds to rule out a bad configuration.

Bruce


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

Re: [yocto] [oe] GStreamer 0.10's future

[Burton, Ross]

On 9 May 2014 16:19, Neuer User  wrote:
> Yes, it does, as long as you need QtMultimedia. Same applies to Qt5.
> There was a discussion on the Qt mailing list about moving to
> gstreamer1.0, but this seems to be rather some time in the future was my
> impression.

So Qt 5.3 won't have GStreamer 1.0 support.  The port is being done in
a branch so it's possible that it will land in Qt 5.4, which is due to
be released in the September/October timeframe.

One option would be to move GStreamer 0.10 into another layer, give
Qt4/Qt5 disabled-by-default GStreamer 0.10 options and hope that by
the time Yocto 1.7 is released, Qt5.4 with GStreamer 1.0 is also
released.  Even as someone who's rather keen on removing cruft from
oe-core that's a bit too eager for my liking.

Revised plan unless anyone has a better idea: in 1.7 we'll move
everything possible away from GStreamer 0.10 but keep 0.10 around
until the 1.8 cycle, and then revisit the Qt situation.

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

[yocto] Eclipse CMake Errors

[Sébastien Taylor]

When using an Eclipse Yocto CMake project, errors in cmake are simply reported 
as a generic error.  Is there an existing method of having the plugin display 
the detailed cmake stdout/stderr output instead?

Example error, 'Configuring project' has encountered a problem.  Build of 
project failed 1.


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

Re: [yocto] [oe] GStreamer 0.10's future

[Burton, Ross]

On 9 May 2014 16:19, Neuer User  wrote:
>> So the catch here is that Qt4 currently depends on GStreamer 0.10.
>>
> Yes, it does, as long as you need QtMultimedia. Same applies to Qt5.
> There was a discussion on the Qt mailing list about moving to
> gstreamer1.0, but this seems to be rather some time in the future was my
> impression.

Oh, even Qt5 needs 0.10?  That's disappointing.

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

Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Bruce Ashfield]

On 14-05-09 10:58 AM, Brian Karcz wrote:

Hi Bruce,

I'm not entirely familiar with the mechanism that gets the defconfig from the 
BSP to the .config in work area, but here is how things currently look. The two 
files aren't a direct match as there appear to be some formatting differences, 
but the variables in the SOC/ARCH section seem to correlate partially (ie. it 
knows its trying to build for an at91sam9x5 SOC).

defconfig:
CONFIG_ARCH_AT91=y
CONFIG_SOC_AT91SAM9260=y
CONFIG_SOC_AT91SAM9263=y
CONFIG_SOC_AT91SAM9G45=y
CONFIG_SOC_AT91SAM9X5=y
CONFIG_MACH_AT91SAM_DT=y

.config:
#
# Atmel AT91 Processor
#
# CONFIG_SOC_AT91RM9200 is not set
CONFIG_SOC_AT91SAM9260=y
# CONFIG_SOC_AT91SAM9261 is not set
CONFIG_SOC_AT91SAM9263=y
# CONFIG_SOC_AT91SAM9RL is not set
CONFIG_SOC_AT91SAM9G45=y
CONFIG_SOC_AT91SAM9X5=y
# CONFIG_SOC_AT91SAM9N12 is not set

#
# Atmel Non-DT world
#
CONFIG_ARCH_AT91_NONE=y
# CONFIG_ARCH_AT91RM9200 is not set
# CONFIG_ARCH_AT91SAM9260 is not set
# CONFIG_ARCH_AT91SAM9261 is not set
# CONFIG_ARCH_AT91SAM9263 is not set
# CONFIG_ARCH_AT91SAM9RL is not set
# CONFIG_ARCH_AT91SAM9G45 is not set

#
# AT91 Board Options
#

#
# Generic Board Type
#
# CONFIG_MACH_AT91SAM9_DT is not set

Given the fact that the ARCH and DT variables don't appear to match, it looks 
like this might be device tree related.


The reason I asked is that in the past, the error you are seeing
was related to the machine not being properly defined in the
kernel's .config.

FWIW, assuming you have a full "defconfig", and not a "save_defconfig"
variant, the path from it to the final .config is pretty much a copy
into the kernel and a "make oldconfig", so nothing is thrown away
unless there is a missing dependency, or the Kconfig doesn't exist in
the given kernel.

It's worth checking via menuconfig to see if anything obvious is
missing, and trying some quick builds to rule out a bad configuration.

Bruce



I was hoping the code out of the box was going to be able to provide a demo 
image that I could build and poke around in for some guidance. My ultimate goal 
is to port the at91sam9x5ek machine definition to one for the at91sam9g20ek 
demo board and then port THAT over to a custom machine based roughly off that 
reference design.


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, May 09, 2014 9:55 AM
To: Brian Karcz; yocto@yoctoproject.org
Subject: Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" 
failure for core-image-minimal

On 14-05-09 09:44 AM, Brian Karcz wrote:

Hi,

Not sure if this is the correct place to email this, but I've seen a
few other meta-atmel references so I figured I'd give it a shot.

I'm attempting to setup a core-image-minimal build using the
guidelines in the meta-atmel README for the at91sam9x5ek machine type.
When the kernel build goes to link, I get a "no machine record
defined" error. Is this something others are seeing in the meta-atmel demo 
builds?

It's a pretty benign build setup according to the README:

git clone git://git.yoctoproject.org/poky

cd poky

git checkout dora-10.0.1 -b dora-10.0.1

git clone git://git.openembedded.org/meta-openembedded

cd meta-openembedded

git checkout 6572316557e742c2dc93848e4d560242bf0c3995 -b my_branch

cd ..

git clone http://github.com/linux4sam/meta-atmel

source oe-init-build-env /workspace/build-atmel

modify local.conf:

MACHINE ??= "at91sam9x5ek"

PACKAGE_CLASSES ?= "package_ipk"

modify bblayers.conf:

BBLAYERS ?= " \

/opt/poky/meta-atmel \

/opt/poky/meta \

/opt/poky/meta-yocto \

/opt/poky/meta-yocto-bsp \

/opt/poky/meta-openembedded/meta-oe \

/opt/poky/meta-openembedded/meta-networking \

"

bitbake core-image-minimal

Setting this up, I get the following build configuration and error:

/workspace/build-atmel$ bitbake core-image-minimal

Loading cache: 100%
|#
|#|
ETA:  00:00:00

Loaded 1782 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies

Build Configuration:

BB_VERSION= "1.20.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING   = "Ubuntu-12.04"

TARGET_SYS= "arm-poky-linux-gnueabi"

MACHINE   = "at91sam9x5ek"

DISTRO= "poky"

DISTRO_VERSION= "1.5.1"

TUNE_FEATURES = "armv5 thumb dsp"

TARGET_FPU= "soft"

meta-atmel= "master:269066a8128d1e767deee64854a142e67451a5f2"

meta

meta-yocto

meta-yocto-bsp= "dora-10.0.1:8e410e9e46e3335458a7747cdd32e05f5c19ccbb"

meta-oe

meta-networking   = "my_branch:6572316557e742c2dc93848e4d560242bf0c3995"

NOTE: Preparing runqueue

NOTE: Executing SetScene

Re: [yocto] replace udhcpc

[Burton, Ross]

On 9 May 2014 17:57, Neuer User  wrote:
> Seems, I am not the only one wondering why connman phones home:

The "ask the author" approach works quite well.  The hostname it's
looking up is connman.net.  This is the captive portal detection:
pretty much every major platform does something similar and it's to
detect the situation that you have something that looks like a network
connection, but actually you're not routed anywhere (i.e. you're in a
hotel and need to pay for connectivity).  ConnMan makes a trivial
request to it's home page and if it gets back the response it was
expecting you have internet, captive portals tend to include
machine-readable links in the response that ConnMan will tell the UI
to open.  If you've ever joined an iOS (and probably Android, but I've
not got one) device to a hotel's wifi and seen a login page open
immediately the same you've seen this behaviour in action.

The response also includes some basic geo-ip so your machine knows
roughly where it is, useful for automatic timezone updating.

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

Re: [yocto] RPM to Verify Installed Packages

[Mark Hatle]

On 5/7/14, 7:46 AM, Diego Sueiro wrote:

Folks,


I'm looking at this issue.  I'd suggest you open a bug in the Yocto Project 
bugzilla.  Feel free to assign it to me.  (I'll end up with it anyway...)


--Mark


On Tue, May 6, 2014 at 3:48 PM, Diego Sueiro mailto:diego.sue...@gmail.com>> wrote:

On Tue, May 6, 2014 at 3:39 PM, Khem Raj mailto:raj.k...@gmail.com>> wrote:

On Tue, May 6, 2014 at 11:34 AM, Diego Sueiro mailto:diego.sue...@gmail.com>> wrote:
 >
 > It's hard to say. But when I try to execute it I receive: "cannot 
execute
 > binary file".
 > And the output of "file" command is: "data".
 >
 > My bet is that the system was powered down during the update process.

what happens if you reinstall it ?


It works.
But the problem is that --verify option is not working.
Even if I remove a file from the installed package it did not point for a
missing file.


Any thoughts?



Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br


/*long live rock 'n roll*/




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

Re: [yocto] replace udhcpc

[Neuer User]

Seems, I am not the only one wondering why connman phones home:

https://bbs.archlinux.org/viewtopic.php?id=181038

The address is 87.106.208.187, which is the IP of
"senator.holtmann.net". The author of the connman package seems to be
Marcel Holtmann .

Honestly, without a reasonable explanation why this package adds this
route, I wouldn't use this package on my systems.

Am 09.05.2014 18:51, schrieb Neuer User:
> Hi Andrea
> 
> I'd like the idea of a somewhat smarter network daemon, but connman
> slowly becomes a bit suspicious to me.
> 
> First, it is very bad documented and difficult to understand what it
> does. Second, it needs iptables to work. Why? Third, it adds strange
> static routes to my routing table and deletes them later
> (87.106.208.187). What is it doing there? Sending pings to this server?
> 
> Hmm, anybody knows a reasonable alternative? Maybe I just start a
> dhclient on my LAN interface and see if it stays in the background, when
> disconnected.
> 
> Michael
> 
> Am 09.05.2014 17:27, schrieb Andrea Galbusera:
>> Michael,
>>
>> On Fri, May 9, 2014 at 3:21 PM, Auslands-KV  wrote:
>>> Thanks a lot. I will look through these links and hope I will understand
>>> better then :-)
>>>
>>> I hope it works nicely with a read-only rootfs. It seems to write to its
>>> own config data (which is a strange behaviour).
>>
>> One of the reasons I started looking at connman was the hope to find a
>> solution to the hell that comes with runtime configuration of network
>> connections in embedded systems. What I had to address many and many
>> time in the past was designing the glue logic sitting between the
>> application specific way of saying "I want eth1 to have this address"
>> instead of "add this DNS server" and the backend required to "deploy"
>> such a new configuration. This usually involved poking with some
>> configuration file and restarting/signaling a service to pickup the
>> new configuration.
>>
>> If I understand it correctly, one of the main goals of connman's
>> design is to provide a backend functionality for handling
>> configurations and deploying them all in a standard and well defined
>> way. This is accomplished by implementing appropriate interfaces
>> exposed over d-bus. It turns out to allows client application, either
>> the provided connmanctl client or your application specific
>> configuration frontend, to interact with the low-level configuration
>> engine, connman daemon, which support plugins for different connection
>> technologies specific needs.
>>
>> So, yes, in my understanding, connman manages its own configuration
>> files. You're supposed to interact with it at an higher level, through
>> methods calls over d-bus: this allows, amongst other things, multiple
>> applications to interact with connman in a safe and controlled way. I
>> guess the design got highly inspired by network configuration tools
>> included in modern Linux distros and the way they work, GNOME's
>> networkmanager being probably one of them. Connman brings all this to
>> the embedded by making it a little bit more lightweight and modular.
>> Anyway, quite far from classic "write myriads of format-heterogeneous
>> config files and fire up some hacked script for reconfiguration".
>>
>> Read-only filesystem shouldn't be a problem itself. I guess you can
>> configure connman to have its own configuration files placed on a
>> tmpfs or similar. Of course, if you need to change configurations at
>> runtime and persistency is required, you probably still need some
>> writable filesystem. But this would be so, even without connman!
>>
>>> Do you by chance know, why it depends on the xuser-account package? I
>>> don't want any additional user accounts on my system. If it is not
>>> essential I would remove it.
>>
>> I'd guess depending on xuser-account grants providing the correct
>> d-bus permissions for interacting with connman to processes which run
>> under a GUI session (non-root). IMHO this RDEPEND should be somewhat
>> conditional to X being enabled on your distro/image. I couldn't find
>> any explicit reference to xuser in connman source code... Maybe
>> someone more expert than me on the list can give a better explanation.
>>
>>>
>>> Thanks
>>>
>>> Michael
>>>
>>> Am 09.05.2014 15:06, schrieb Andrea Galbusera:
 Hi,

 On Fri, May 9, 2014 at 12:28 PM, Neuer User  wrote:
> Connman is really a problem without documentation. :-(
>
> I tried it out and first I noticed that it depends on the creation of an
> xuser account. It also needs iptables, so probably can configure these, 
> too.
>
> I also found that it does not correctly configure the dns entries:
>
> cat /etc/resolv.conf:
> # Generated by Connection Manager
> nameserver 127.0.0.1
> nameserver ::1
 This is in fact a working configuration for the DNS proxy feature that
 connman offers built-in. See [1].
 I personally went through your same frustration when trying to
 

Re: [yocto] replace udhcpc

[Neuer User]

Hi Andrea

I'd like the idea of a somewhat smarter network daemon, but connman
slowly becomes a bit suspicious to me.

First, it is very bad documented and difficult to understand what it
does. Second, it needs iptables to work. Why? Third, it adds strange
static routes to my routing table and deletes them later
(87.106.208.187). What is it doing there? Sending pings to this server?

Hmm, anybody knows a reasonable alternative? Maybe I just start a
dhclient on my LAN interface and see if it stays in the background, when
disconnected.

Michael

Am 09.05.2014 17:27, schrieb Andrea Galbusera:
> Michael,
> 
> On Fri, May 9, 2014 at 3:21 PM, Auslands-KV  wrote:
>> Thanks a lot. I will look through these links and hope I will understand
>> better then :-)
>>
>> I hope it works nicely with a read-only rootfs. It seems to write to its
>> own config data (which is a strange behaviour).
> 
> One of the reasons I started looking at connman was the hope to find a
> solution to the hell that comes with runtime configuration of network
> connections in embedded systems. What I had to address many and many
> time in the past was designing the glue logic sitting between the
> application specific way of saying "I want eth1 to have this address"
> instead of "add this DNS server" and the backend required to "deploy"
> such a new configuration. This usually involved poking with some
> configuration file and restarting/signaling a service to pickup the
> new configuration.
> 
> If I understand it correctly, one of the main goals of connman's
> design is to provide a backend functionality for handling
> configurations and deploying them all in a standard and well defined
> way. This is accomplished by implementing appropriate interfaces
> exposed over d-bus. It turns out to allows client application, either
> the provided connmanctl client or your application specific
> configuration frontend, to interact with the low-level configuration
> engine, connman daemon, which support plugins for different connection
> technologies specific needs.
> 
> So, yes, in my understanding, connman manages its own configuration
> files. You're supposed to interact with it at an higher level, through
> methods calls over d-bus: this allows, amongst other things, multiple
> applications to interact with connman in a safe and controlled way. I
> guess the design got highly inspired by network configuration tools
> included in modern Linux distros and the way they work, GNOME's
> networkmanager being probably one of them. Connman brings all this to
> the embedded by making it a little bit more lightweight and modular.
> Anyway, quite far from classic "write myriads of format-heterogeneous
> config files and fire up some hacked script for reconfiguration".
> 
> Read-only filesystem shouldn't be a problem itself. I guess you can
> configure connman to have its own configuration files placed on a
> tmpfs or similar. Of course, if you need to change configurations at
> runtime and persistency is required, you probably still need some
> writable filesystem. But this would be so, even without connman!
> 
>> Do you by chance know, why it depends on the xuser-account package? I
>> don't want any additional user accounts on my system. If it is not
>> essential I would remove it.
> 
> I'd guess depending on xuser-account grants providing the correct
> d-bus permissions for interacting with connman to processes which run
> under a GUI session (non-root). IMHO this RDEPEND should be somewhat
> conditional to X being enabled on your distro/image. I couldn't find
> any explicit reference to xuser in connman source code... Maybe
> someone more expert than me on the list can give a better explanation.
> 
>>
>> Thanks
>>
>> Michael
>>
>> Am 09.05.2014 15:06, schrieb Andrea Galbusera:
>>> Hi,
>>>
>>> On Fri, May 9, 2014 at 12:28 PM, Neuer User  wrote:
 Connman is really a problem without documentation. :-(

 I tried it out and first I noticed that it depends on the creation of an
 xuser account. It also needs iptables, so probably can configure these, 
 too.

 I also found that it does not correctly configure the dns entries:

 cat /etc/resolv.conf:
 # Generated by Connection Manager
 nameserver 127.0.0.1
 nameserver ::1
>>> This is in fact a working configuration for the DNS proxy feature that
>>> connman offers built-in. See [1].
>>> I personally went through your same frustration when trying to
>>> understand how connman is supposed to work in order to evaluate its
>>> maturity. Not yet an expert at all, but [2] and [3] gave me a
>>> reasonable bootstrap into connman's main logic. Beside this, "git
>>> grepping" the source tree is your best friend.
>>> Angstrom distribution, i.e. available on the beaglebone boards is also
>>> a good example of a real connman based system.
>>>
 I really would like to understand what it does with these and how I can
 change or modify it's behaviour.

 It's definitely

Re: [yocto] building qtbase for raspberry pi fails

[Felix01 Fischer]

Hello all,
I managed to get qtbase building with a raspberry pi.
In the end, all you have to do is to add a .bbappend for qtbase with the 
following

QT_CONFIG_FLAGS += " \
-device linux-rasp-pi-g++ \
-device-option 
CROSS_COMPILE=$PATH_TO_SYSROOT_DIR/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-
 
\
-I$PATH_TO_SYSROOT_DIR/raspberrypi/usr/include/interface/vcos/pthreads 
\
"
and then it builds.

Unfortunately any qt application on the rasp will always fail with error 
0b300b :-(






yocto-boun...@yoctoproject.org schrieb am 06.05.2014 13:56:57:

> Von: Felix01 Fischer 
> An: Khem Raj , 
> Kopie: "yocto@yoctoproject.org" 
> Datum: 06.05.2014 15:54
> Betreff: [yocto] Antwort: Re:  building qtbase for raspberry pi fails
> Gesendet von: yocto-boun...@yoctoproject.org
> 
> Khem Raj  schrieb am 30.04.2014 10:14:29:
> 
> > Von: Khem Raj  
> > An: Felix01 Fischer , 
> > Kopie: "yocto@yoctoproject.org"  
> > Datum: 30.04.2014 10:15 
> > Betreff: Re: [yocto] building qtbase for raspberry pi fails 
> > 
> > On Tue, Apr 29, 2014 at 4:37 AM, Felix01 Fischer 
> >  wrote:
> > > But still I haven't figured out how to get this build correctly so 
qtbase
> > > can find and use it.
> > 
> > I am assuming you need to select this user land recipe to provide
> > virtual/libgles2 virtual/egl
> > 
> > PREFERRED_PROVIDER_virtual/egl = "userland"
> > PREFERRED_PROVIDER_virtual/libgres2 = "user land"
> > 
> > in config metadata
> 
> 
> 
> I think you have two typos in the second line. 
> It should be 
> PREFERRED_PROVIDER_virtual/libgles2 ?= "userland" 
> right? 
> 
> If yes, then this is already set in rpi-default-providers.inc
> (see here http://git.yoctoproject.org/cgit/cgit.cgi/meta-
> raspberrypi/plain/conf/machine/include/rpi-default-providers.inc )
> 
> Nevertheless I managed to build qtbase now, I still have to figure 
> out which options exactly are responsible for this :-)
> 
> One thing I now for sure: 
> 
> I have to add the following line to 
> "/media/yocto_build/qt5-raspb/build/tmp/work/armv6-vfp-poky-linux-
> gnueabi/atbase/5.2.1-r0/qtbase-opensource-src-5.2.1/mkspecs/linux-
> oe-g++/qmake.conf" 
> 
> "QMAKE_LIBS_EGL += "/media/yocto_build/qt5-raspb/build/tmp/sysroots/
> raspberrypi/usr/lib/libGLESv2.so"
> 
> 2 Questions: 
> First, why isn't this library found by default? It clearly is in /
> usr/lib so this should be a no brainer I think 
> Second, If I have to add this line manually via a bbappend how do I do 
this? 
> I tried by just adding this line to a qtbase_5.2.1.bbappend, by 
> prefixing it with OE_, by substituting the full path with $
> {STAGING_DIR_TARGET} 
> and by trying all of these steps in meta-qt5/recipes-qt/qt5/
> qtbase.inc but with no success so far
> 
> 
> 
> Unfortunately, I still get the from before when trying to run a Qt 
> programm on the raspberrypi:
> 
> EGLFS: Unable to query physical screen size, defaulting to 100 dpi. 
> EGLFS: To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and 
> QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). 
> libpng warning: iCCP: Not recognizing known sRGB profile that has been 
edited 
> EGL Error : Could not create the egl surface: error = 0x300b
> 
> 
> anny suggestions?
> 
> Felix-- 
> ___
> 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] nativesdk-cmake can't use a separate build dir, currently fails to build

[Jonathan Austin]

Hi all,

I've discovered today that nativesdk-cmake fails to build by default. 
The cmake and cmake-native targets still work.


The difference appears to be the metadata in:

meta/conf/distro/include/seperatebuilddir.inc

...which tells bitbake not to use a separate build dir for the latter 
two targets, but doesn't make the exception for nativesdk-cmake


I got things working again with the following hack:

---8<---
diff --git a/meta/conf/distro/include/seperatebuilddir.inc 
b/meta/conf/distro/include/seperatebuilddir.inc

index 8f2ebfa..2ece812 100644
--- a/meta/conf/distro/include/seperatebuilddir.inc
+++ b/meta/conf/distro/include/seperatebuilddir.inc
@@ -473,7 +473,7 @@ B_pn-nativesdk-bigreqsproto = "${SEPB}"
 B_pn-nativesdk-bison = "${SEPB}"
 B_pn-nativesdk-bzip2 = "${SEPB}"
 B_pn-nativesdk-chrpath = "${SEPB}"
-B_pn-nativesdk-cmake = "${SEPB}"
+#B_pn-nativesdk-cmake = "${SEPB}"
 B_pn-nativesdk-curl = "${SEPB}"
 B_pn-nativesdk-db = "${SEPB}"
 B_pn-nativesdk-dbus = "${SEPB}"
->8---

I'm not really sure what the 'right' way to remove this is - the two 
existing cmake targets are just commented out, but recent patches seem 
to be simply removing targets.


Is this the appropriate fix? Does anyone know if there's a reason for 
two out of three cmake targets to be commented but not the third? Did it 
work once?


Any guidance one what the actual patch should look like is welcome!

Jonny

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

Re: [yocto] replace udhcpc

[Andrea Galbusera]

Michael,

On Fri, May 9, 2014 at 3:21 PM, Auslands-KV  wrote:
> Thanks a lot. I will look through these links and hope I will understand
> better then :-)
>
> I hope it works nicely with a read-only rootfs. It seems to write to its
> own config data (which is a strange behaviour).

One of the reasons I started looking at connman was the hope to find a
solution to the hell that comes with runtime configuration of network
connections in embedded systems. What I had to address many and many
time in the past was designing the glue logic sitting between the
application specific way of saying "I want eth1 to have this address"
instead of "add this DNS server" and the backend required to "deploy"
such a new configuration. This usually involved poking with some
configuration file and restarting/signaling a service to pickup the
new configuration.

If I understand it correctly, one of the main goals of connman's
design is to provide a backend functionality for handling
configurations and deploying them all in a standard and well defined
way. This is accomplished by implementing appropriate interfaces
exposed over d-bus. It turns out to allows client application, either
the provided connmanctl client or your application specific
configuration frontend, to interact with the low-level configuration
engine, connman daemon, which support plugins for different connection
technologies specific needs.

So, yes, in my understanding, connman manages its own configuration
files. You're supposed to interact with it at an higher level, through
methods calls over d-bus: this allows, amongst other things, multiple
applications to interact with connman in a safe and controlled way. I
guess the design got highly inspired by network configuration tools
included in modern Linux distros and the way they work, GNOME's
networkmanager being probably one of them. Connman brings all this to
the embedded by making it a little bit more lightweight and modular.
Anyway, quite far from classic "write myriads of format-heterogeneous
config files and fire up some hacked script for reconfiguration".

Read-only filesystem shouldn't be a problem itself. I guess you can
configure connman to have its own configuration files placed on a
tmpfs or similar. Of course, if you need to change configurations at
runtime and persistency is required, you probably still need some
writable filesystem. But this would be so, even without connman!

> Do you by chance know, why it depends on the xuser-account package? I
> don't want any additional user accounts on my system. If it is not
> essential I would remove it.

I'd guess depending on xuser-account grants providing the correct
d-bus permissions for interacting with connman to processes which run
under a GUI session (non-root). IMHO this RDEPEND should be somewhat
conditional to X being enabled on your distro/image. I couldn't find
any explicit reference to xuser in connman source code... Maybe
someone more expert than me on the list can give a better explanation.

>
> Thanks
>
> Michael
>
> Am 09.05.2014 15:06, schrieb Andrea Galbusera:
>> Hi,
>>
>> On Fri, May 9, 2014 at 12:28 PM, Neuer User  wrote:
>>> Connman is really a problem without documentation. :-(
>>>
>>> I tried it out and first I noticed that it depends on the creation of an
>>> xuser account. It also needs iptables, so probably can configure these, too.
>>>
>>> I also found that it does not correctly configure the dns entries:
>>>
>>> cat /etc/resolv.conf:
>>> # Generated by Connection Manager
>>> nameserver 127.0.0.1
>>> nameserver ::1
>> This is in fact a working configuration for the DNS proxy feature that
>> connman offers built-in. See [1].
>> I personally went through your same frustration when trying to
>> understand how connman is supposed to work in order to evaluate its
>> maturity. Not yet an expert at all, but [2] and [3] gave me a
>> reasonable bootstrap into connman's main logic. Beside this, "git
>> grepping" the source tree is your best friend.
>> Angstrom distribution, i.e. available on the beaglebone boards is also
>> a good example of a real connman based system.
>>
>>> I really would like to understand what it does with these and how I can
>>> change or modify it's behaviour.
>>>
>>> It's definitely not just "when ethernet cable inserted, bring up the
>>> interface using DHCP".
>>>
>>> I even can't find a config file for connman. Is there one?
>> Yes, there usually is one for each service handled by connman. See [4]
>> for details on configuration file format and their default location.
>> As you can see from previously suggested references, you'll usually
>> modify configurations by using the connmanctl client tool instead of
>> editing those files by hand.
>>
>> [1] http://git.kernel.org/cgit/network/connman/connman.git/tree/README
>> [2] 
>> http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
>> [3] http://www.ptrackapp.com/apclassys-notes/embedded-linux-using-connma/
>> [4] 
>> http://git.kernel.org/c

Re: [yocto] replace udhcpc

[Neuer User]

Great, then I will remove it.

My app does not run as root, but all system configuration tasks are only
available for root on my system.

Am 09.05.2014 17:22, schrieb Burton, Ross:
> On 9 May 2014 16:15, Neuer User  wrote:
>> Do you by chance know, why it depends on the xuser-account package? I
>> don't want any additional user accounts on my system. If it is not
>> essential I would remove it.
> 
> If you're applications are running as root then you can remove the
> dependency on that package and the patch that changes the security
> policy.  The reasoning is complicated but basically so that the "user"
> can manipulate the network settings.
> 
> Ross
> 


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

Re: [yocto] replace udhcpc

[Burton, Ross]

On 9 May 2014 16:15, Neuer User  wrote:
> Do you by chance know, why it depends on the xuser-account package? I
> don't want any additional user accounts on my system. If it is not
> essential I would remove it.

If you're applications are running as root then you can remove the
dependency on that package and the patch that changes the security
policy.  The reasoning is complicated but basically so that the "user"
can manipulate the network settings.

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

Re: [yocto] RPM to Verify Installed Packages

[Diego Sueiro]

Folks,

After 1 day of debugging I found what was causing the issue.

Commenting out the to lines (590-591) below on lib/verify.c
(showVerifyPackage function) solved the issue:

/* If not verifying %ghost, skip ghost files. */
/* XXX the broken!!! logic disables %ghost queries always. */
if (!(FF_ISSET(qva->qva_fflags, GHOST) && FF_ISSET(fflags, GHOST)))
continue;


I've tested "rpm -V" on qemuarm and qemux86 and it's reporting errors for
missing files and MD5 error at least.

I really don't know what is the side effect of this change and any help on
trying to understand what's going on with this bug is very welcome.



Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/


On Wed, May 7, 2014 at 9:46 AM, Diego Sueiro  wrote:

> Folks,
>
> On Tue, May 6, 2014 at 3:48 PM, Diego Sueiro wrote:
>
>> On Tue, May 6, 2014 at 3:39 PM, Khem Raj  wrote:
>>
>>> On Tue, May 6, 2014 at 11:34 AM, Diego Sueiro 
>>> wrote:
>>> >
>>> > It's hard to say. But when I try to execute it I receive: "cannot
>>> execute
>>> > binary file".
>>> > And the output of "file" command is: "data".
>>> >
>>> > My bet is that the system was powered down during the update process.
>>>
>>> what happens if you reinstall it ?
>>
>>
>> It works.
>> But the problem is that --verify option is not working.
>> Even if I remove a file from the installed package it did not point for a
>> missing file.
>>
>
> Any thoughts?
>
>
>
> Regards,
>
> --
> *dS
> Diego Sueiro
>
> Administrador do Embarcados
> www.embarcados.com.br
>
> /*long live rock 'n roll*/
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] GStreamer 0.10's future

[Neuer User]

Am 08.05.2014 17:54, schrieb Burton, Ross:
> On 8 May 2014 15:48, Burton, Ross  wrote:
>> For the 1.7 release I want to move GStreamer 0.10 from oe-core into
>> meta-multimedia, and ensure everything in oe-core has ported to
>> GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
>> unmaintained so we don't need to be shipping both versions anymore.
> 
> So the catch here is that Qt4 currently depends on GStreamer 0.10.
> 
Yes, it does, as long as you need QtMultimedia. Same applies to Qt5.
There was a discussion on the Qt mailing list about moving to
gstreamer1.0, but this seems to be rather some time in the future was my
impression.

> Can someone who doesn't come out in a rash when looking at C++ code
> spend two minutes to tell if me Qt4 supports GStreamer 1.0 (unlikely)
> and whether we can make GStreamer 0.10 support a build-time
> configuration and simply disable it in oe-core.
> 
> Ross
> 


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

Re: [yocto] replace udhcpc

[Neuer User]

Thanks a lot. I will look through these links and hope I will understand
better then :-)

I hope it works nicely with a read-only rootfs. It seems to write to its
own config data (which is a strange behaviour).

Do you by chance know, why it depends on the xuser-account package? I
don't want any additional user accounts on my system. If it is not
essential I would remove it.

Thanks

Michael
Am 09.05.2014 15:06, schrieb Andrea Galbusera:
> Hi,
> 
> On Fri, May 9, 2014 at 12:28 PM, Neuer User  wrote:
>> Connman is really a problem without documentation. :-(
>>
>> I tried it out and first I noticed that it depends on the creation of an
>> xuser account. It also needs iptables, so probably can configure these, too.
>>
>> I also found that it does not correctly configure the dns entries:
>>
>> cat /etc/resolv.conf:
>> # Generated by Connection Manager
>> nameserver 127.0.0.1
>> nameserver ::1
> 
> This is in fact a working configuration for the DNS proxy feature that
> connman offers built-in. See [1].
> I personally went through your same frustration when trying to
> understand how connman is supposed to work in order to evaluate its
> maturity. Not yet an expert at all, but [2] and [3] gave me a
> reasonable bootstrap into connman's main logic. Beside this, "git
> grepping" the source tree is your best friend.
> Angstrom distribution, i.e. available on the beaglebone boards is also
> a good example of a real connman based system.
> 
>> I really would like to understand what it does with these and how I can
>> change or modify it's behaviour.
>>
>> It's definitely not just "when ethernet cable inserted, bring up the
>> interface using DHCP".
>>
>> I even can't find a config file for connman. Is there one?
> 
> Yes, there usually is one for each service handled by connman. See [4]
> for details on configuration file format and their default location.
> As you can see from previously suggested references, you'll usually
> modify configurations by using the connmanctl client tool instead of
> editing those files by hand.
> 
> [1] http://git.kernel.org/cgit/network/connman/connman.git/tree/README
> [2] http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
> [3] http://www.ptrackapp.com/apclassys-notes/embedded-linux-using-connma/
> [4] 
> http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt
> 
>>
>> Thanks
>>
>> Michael
>>
>> Am 08.05.2014 12:27, schrieb Burton, Ross:
>>> On 8 May 2014 04:58, Neuer User  wrote:
 I had a brief look at connman half a year ago, but that time I was
 unable to find a good documentation about it. Do you have by chance a
 link to some tutorial or at least man entry for the configuration?
>>>
>>> What do you need to configure?  For "when ethernet cable inserted,
>>> bring up the interface using DHCP" this is default behaviour and won't
>>> need any configuring.  connman is sadly under-documented but the IRC
>>> channel is fairly responsive.
>>>
>>> Ross
>>>
>>
>>
>> --
>> ___
>> 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] replace udhcpc

[Auslands-KV]

Thanks a lot. I will look through these links and hope I will understand
better then :-)

I hope it works nicely with a read-only rootfs. It seems to write to its
own config data (which is a strange behaviour).

Do you by chance know, why it depends on the xuser-account package? I
don't want any additional user accounts on my system. If it is not
essential I would remove it.

Thanks

Michael

Am 09.05.2014 15:06, schrieb Andrea Galbusera:
> Hi,
>
> On Fri, May 9, 2014 at 12:28 PM, Neuer User  wrote:
>> Connman is really a problem without documentation. :-(
>>
>> I tried it out and first I noticed that it depends on the creation of an
>> xuser account. It also needs iptables, so probably can configure these, too.
>>
>> I also found that it does not correctly configure the dns entries:
>>
>> cat /etc/resolv.conf:
>> # Generated by Connection Manager
>> nameserver 127.0.0.1
>> nameserver ::1
> This is in fact a working configuration for the DNS proxy feature that
> connman offers built-in. See [1].
> I personally went through your same frustration when trying to
> understand how connman is supposed to work in order to evaluate its
> maturity. Not yet an expert at all, but [2] and [3] gave me a
> reasonable bootstrap into connman's main logic. Beside this, "git
> grepping" the source tree is your best friend.
> Angstrom distribution, i.e. available on the beaglebone boards is also
> a good example of a real connman based system.
>
>> I really would like to understand what it does with these and how I can
>> change or modify it's behaviour.
>>
>> It's definitely not just "when ethernet cable inserted, bring up the
>> interface using DHCP".
>>
>> I even can't find a config file for connman. Is there one?
> Yes, there usually is one for each service handled by connman. See [4]
> for details on configuration file format and their default location.
> As you can see from previously suggested references, you'll usually
> modify configurations by using the connmanctl client tool instead of
> editing those files by hand.
>
> [1] http://git.kernel.org/cgit/network/connman/connman.git/tree/README
> [2] http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
> [3] http://www.ptrackapp.com/apclassys-notes/embedded-linux-using-connma/
> [4] 
> http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt
>
>> Thanks
>>
>> Michael
>>
>> Am 08.05.2014 12:27, schrieb Burton, Ross:
>>> On 8 May 2014 04:58, Neuer User  wrote:
 I had a brief look at connman half a year ago, but that time I was
 unable to find a good documentation about it. Do you have by chance a
 link to some tutorial or at least man entry for the configuration?
>>> What do you need to configure?  For "when ethernet cable inserted,
>>> bring up the interface using DHCP" this is default behaviour and won't
>>> need any configuring.  connman is sadly under-documented but the IRC
>>> channel is fairly responsive.
>>>
>>> Ross
>>>
>>
>> --
>> ___
>> 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] [yocto-autobuilder][PATCH v1 4/4] GetDeployDir.py/PublishArtifacts.py: get deploy dir from bitbake

[stefan]

From: Stefan Agner 

Since the deploy dir is configureable (also through TMPDIR), we
need to have a more generic variant to get that path. Also the
Ångstrom distribution adds "-eglibc" to the TMPDIR. Hence, the
safest way to get the deployment dir is to parse buildbots
environment.

Signed-off-by: Stefan Agner 
---
 .../autobuilder/buildsteps/GetDeployDir.py | 47 +
 .../autobuilder/buildsteps/PublishArtifacts.py | 48 --
 2 files changed, 73 insertions(+), 22 deletions(-)
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py

diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py
new file mode 100644
index 000..944fcf0
--- /dev/null
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py
@@ -0,0 +1,47 @@
+'''
+Created on Mai 8, 2014
+
+__author__ = "Stefan Agner"
+__copyright__ = "Copyright 2014, Toradex AG"
+__credits__ = ["Stefan Agner"]
+__license__ = "GPL"
+__version__ = "2.0"
+__maintainer__ = "Stefan Agner"
+__email__ = "ste...@agner.ch"
+'''
+from buildbot.steps.shell import ShellCommand
+from buildbot.status import progress
+from buildbot.status.results import SUCCESS, FAILURE, WARNINGS
+from buildbot.process.properties import WithProperties
+from twisted.python import log
+from autobuilder.config import *
+
+class GetDeployDir(ShellCommand):
+haltOnFailure = False
+flunkOnFailure = True
+name = "GetDeployDir"
+def __init__(self, factory, argdict=None, **kwargs):
+for k, v in argdict.iteritems():
+setattr(self, k, v)
+self.description = "Get Deploy Directory"
+self.deploydir = None
+ShellCommand.__init__(self, **kwargs)
+
+def start(self):
+cmd = '. ./oe-init-build-env; bitbake -e | grep "^DEPLOY_DIR="'
+self.command = cmd
+ShellCommand.start(self)
+
+def commandComplete(self, cmd):
+if cmd.didFail():
+return
+result = cmd.logs['stdio'].getText()
+if "=" not in result:
+self.finished(FAILURE)
+param, value = result.split("=")
+deploydir = value.replace('"', '').strip()
+self.setProperty('deploydir', deploydir, "Setting Deploy Directory")
+self.finished(SUCCESS)
+
+def getText(self, cmd, results):
+return ShellCommand.getText(self, cmd, results)
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
index ebc761f..303df36 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
@@ -19,10 +19,10 @@ class PublishArtifacts(ShellCommand):
 
 haltOnFailure = False
 flunkOnFailure = True
-name = "Publishing Artifacts"
+name = "PublishArtifacts"
+description = "Publishing Artifacts"
 def __init__(self, factory, argdict=None, **kwargs):
 self.factory = factory
-self.description = "Publishing Artifacts"
 self.slavedir=os.path.join(os.path.join(YOCTO_ABBASE, "yocto-slave"))
 for k, v in argdict.iteritems():
 if type(v) is bool:
@@ -42,10 +42,14 @@ class PublishArtifacts(ShellCommand):
 self.layerversion_yoctobsp = self.getProperty("layerversion_yoctobsp")
 self.layerversion_yocto = self.getProperty("layerversion_yocto")
 self.layerversion_core = self.getProperty("layerversion_core")
+self.deploydir = self.getProperty("deploydir")
 log.msg(layerversion_yoctobsp)
-self.basedir=os.path.join(os.path.join(
-self.slavedir, buildername),
-"build/build/")
+self.basedir = os.path.join(self.slavedir, buildername, "build/build/")
+
+# Deploydir might not be set in case the step did not run, fallback to 
default
+if self.deploydir is None:
+self.deploydir = os.path.join(self.basedir, "tmp/deploy/")
+
 command=""
 DATESTAMP=datetime.datetime.now().strftime("%Y%m%d")
 if str(os.environ.get('PUBLISH_BUILDS')) == "True":
@@ -70,17 +74,17 @@ class PublishArtifacts(ShellCommand):
 if artifact == "adt-installer":
 command=command+"mkdir -p " + os.path.join(DEST, 
ADT_INST_PUBLISH_DIR) + ";"
 command=command+"cp -R --no-dereference --preserve=links " 
+ \
-os.path.join(self.basedir, 
"tmp/deploy/sdk/") + \
+os.path.join(self.deploydir, "sdk/") + \
 "*adt* " + os.path.join(DEST, 
ADT_INST_PUBLISH_DIR) + ";"
 elif artifact == "adt-installer-QA":
 command=command+"mkdir -p " + os.path.join(DEST, 
ADTQA_INST_PUB

[yocto] [yocto-autobuilder][PATCH v1 3/4] master.py/botmaster.py: use builders list for builders order

[stefan]

From: Stefan Agner 

This patch uses the order of the list builderNames when requesting
builder names. This order is relevant for the Waterfall order.

However, the order of builderNames is not meaningful by default,
hence the change in botmaster.py makes sure the builderNames is
taken form the configuration files list of builder.

Hence we can get rid of the environment work around (which also
did not honor non Autobuilder builders).

Signed-off-by: Stefan Agner 
---
 lib/python2.7/site-packages/autobuilder/Autobuilder.py  | 17 +
 .../buildbot/process/botmaster.py   |  3 ++-
 .../buildbot-0.8.8-py2.7.egg/buildbot/status/master.py  | 12 ++--
 3 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/lib/python2.7/site-packages/autobuilder/Autobuilder.py 
b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
index 4c33489..cf8672f 100644
--- a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
+++ b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
@@ -38,20 +38,21 @@ class Autobuilder:
 self.cfile = "./buildset-config/yoctoAB.conf"
 
 def createBuildsets(self):
-beenHere=[]
+buildersSorted=[]
 sort = True
 if self.config.has_option('BuildSets', 'order'):
 sort = False
 for set in ast.literal_eval(self.config.get('BuildSets', 'order')):
-beenHere.append(set)
+buildersSorted.append(set)
+
 for key in self.configdict:
-if key not in beenHere and key != "BuildSets":
-beenHere.append(key)
+if key not in buildersSorted and key != "BuildSets":
+buildersSorted.append(key)
+
 if sort:
-beenHere.sort()
-# REALLY crappy way to do this, but better than setting globals.
-os.environ["YOCTO_SORTED_BUILDERS"]= str(beenHere)
-for buildset in beenHere:
+util.naturalSort(buildersSorted)
+
+for buildset in buildersSorted:
 self.schedprops = []
 self.checkoutprops={}
 self.set_props = {}
diff --git 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/process/botmaster.py
 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/process/botmaster.py
index d5597f7..f2c3b9f 100644
--- 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/process/botmaster.py
+++ 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/process/botmaster.py
@@ -262,7 +262,8 @@ class BotMaster(config.ReconfigurableServiceMixin, 
service.MultiService):
 builder.master = self.master
 builder.setServiceParent(self)
 
-self.builderNames = self.builders.keys()
+# Use order according to configuration files builders list
+self.builderNames = list([ (bc.name) for bc in new_config.builders ])
 
 metrics.MetricCountEvent.log("num_builders",
 len(self.builders), absolute=True)
diff --git 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/master.py
 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/master.py
index b5fe741..df122b4 100644
--- 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/master.py
+++ 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/master.py
@@ -221,16 +221,8 @@ class Status(config.ReconfigurableServiceMixin, 
service.MultiService):
 
 def getBuilderNames(self, categories=None):
 if categories == None:
-#YOCTO PROJECT ADDITION
-import os
-import ast
-sortbuilders=""
-
sortbuilders=ast.literal_eval(os.environ.get('YOCTO_SORTED_BUILDERS'))
-#I hate the way this is sorted. This is the laziest way to get this
-#in the format I want.
-return sortbuilders
-#YOCTO PROJECT ADDITION
-#return util.naturalSort(self.botmaster.builderNames) # don't let 
them break it
+# assume this is already sorted...
+return self.botmaster.builderNames
 
 l = []
 # respect addition order
-- 
1.9.0

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

[yocto] [yocto-autobuilder][PATCH v1 2/4] README: add high level overview, fix build slave description

[stefan]

From: Stefan Agner 

Replace builders with build slaves, since this are different things
in BuildBot world. Also add a section with some high level view
what Autobuilder actually is.

Signed-off-by: Stefan Agner 
---
 README |  8 
 README-NEW-AUTOBUILDER | 11 +++
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/README b/README
index c7c9acf..3b418fd 100644
--- a/README
+++ b/README
@@ -26,7 +26,7 @@ Setup
connection that I haven't figured out yet. Manually connecting seems to 
set up the session correctly.)
 
-2. Adding additional builders
+2. Adding additional build slaves
 
 The production yocto autobuilder uses a cluster of build slaves, all 
sharing
 the same SSTATE_DIR and DL_DIR via an NFS4 mounted NAS. The main nightly 
@@ -36,7 +36,7 @@ Setup
 In theory you could also run your build slaves with NO_NETWORK to enforce 
a 
 single point of populating DL_DIR.
 
-Running multiple builders is fairly simple, but does require some setup.
+Running multiple build slaves is fairly simple, but does require some 
setup.
 
 1. Ensure the autobuilder.conf for each build slave is appropriate. As
certain variables are set within this file that are local to each 
builder
@@ -45,7 +45,7 @@ Setup
 2. Within yocto-master/master.cfg make the following changes substituing 
 for your debug password and  max_builds for the number of builds 
you wish to run on each builder. Your main builder that will run the 
-   nightly trigger buildset should have at least 2 builders running.
+   nightly trigger buildset should have at least 2 build slaves running.
 
 
 c['slaves'] = [BuildSlave("builder1", "", max_builds=3),
@@ -53,7 +53,7 @@ c['slaves'] = [BuildSlave("builder1", "", max_builds=3),
BuildSlave("builder3", "", max_builds=3),
BuildSlave("builder4", "", max_builds=3)]
 
-3. For each buildslave change yocto-slave/buildbot.tac to point to the 
+3. For each build slave change yocto-slave/buildbot.tac to point to the 
correct build master and port. The default setup points to local host.
 
 buildmaster_host = 'builder1.myproject.org'
diff --git a/README-NEW-AUTOBUILDER b/README-NEW-AUTOBUILDER
index 1e46f5b..acb5387 100644
--- a/README-NEW-AUTOBUILDER
+++ b/README-NEW-AUTOBUILDER
@@ -23,6 +23,17 @@ TODO
 - deploy stuff
 - killing triggers. this has been a long standing issue. look into
 
+What is it
+
+Yocto Autobuilder is essentially some extension to the vanilla build bot.
+This extension mainly addresses configuration file handling and Yocto specific
+build steps.
+For better maintainability, the Autobuilder (see Autobuilder.py located at
+lib/python2.7/site-packages/autobuilder/), handles configuration from multiple
+files.
+Additional build steps such as CheckOutLayers.py or CreateBBLayersConf are
+Yocto specific and simplify the bulders configuration.
+
 Setup
 
 Nothing here has changed much. 
-- 
1.9.0

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

[yocto] [yocto-autobuilder][PATCH v1 1/4] GetDistroVersion.py support for Angstrom distro version

[stefan]

From: Stefan Agner 

Ångström distribution has a different location for distro version,
support "angstrom" as distro too.

Signed-off-by: Stefan Agner 
---
 .../site-packages/autobuilder/buildsteps/GetDistroVersion.py   | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/GetDistroVersion.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/GetDistroVersion.py
index 3d4f314..2555e62 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/GetDistroVersion.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/GetDistroVersion.py
@@ -32,10 +32,13 @@ class GetDistroVersion(ShellCommand):
 
 def start(self):
 buildername=self.getProperty("buildername")
+distroconf=self.slaveworkdir + "/" + buildername
 if 'poky' in self.distro:
-distroconf=self.slaveworkdir + "/" + buildername + 
"/build/meta-yocto/conf/distro/poky.conf|grep 'DISTRO_VERSION = \"'"
+distroconf+="/build/meta-yocto/conf/distro/poky.conf|grep 
'DISTRO_VERSION = \"'"
 elif 'oecore' in self.distro:
-distroconf=self.slaveworkdir + "/" + buildername + 
"/build/meta/conf/distro/include/default-distrovars.inc|grep 'DISTRO_VERSION '"
+
distroconf+="/build/meta/conf/distro/include/default-distrovars.inc|grep 
'DISTRO_VERSION '"
+elif 'angstrom' in self.distro:
+distroconf+="/build/meta-angstrom/conf/distro/angstrom-*.conf|grep 
'DISTRO_VERSION = \"'"
 else:
 self.finished(FAILURE)
 cmd = 'cat ' + distroconf
-- 
1.9.0

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

[yocto] [yocto-autobuilder][PATCH v1 0/4] fixes for use with Angstrom

[stefan]

From: Stefan Agner 

Hi folks,

We plan to make use of the Yocto Autobuilder at Toradex. I successfully
deployed an installation, however since we distribute an Anstrom based
BSP I had to adjust some files. With those patches and a custom layer
configuration (not included since quite ugly) I'm able to build our BSP.

Would be good to have those changes upstream. Especially the new way to
preserve the order of builders is more generic, however maybe not yet
perfect. I needed this especially since I build some other stuff using
POBBC (plain old build bot configuration :-)).

Just as a general question: What is planned with the autobuilder in 
general? Is there an integration planned with Toaster? As far as I can
see, since the build directory is recreated each time, this is not
really possible right now. It would need adjustment to the autobuilder
to start the toaster web interface for each builder, and clean/restart
builds in a way that doesn't interfere with Toaster. Any thoughts on
this?

--
Stefan

Stefan Agner (4):
  GetDistroVersion.py support for Angstrom distro version
  README: add high level overview, fix build slave description
  master.py/botmaster.py: use builders list for builders order
  GetDeployDir.py/PublishArtifacts.py: get deploy dir from bitbake

 README |  8 ++--
 README-NEW-AUTOBUILDER | 11 +
 .../site-packages/autobuilder/Autobuilder.py   | 17 
 .../autobuilder/buildsteps/GetDeployDir.py | 47 +
 .../autobuilder/buildsteps/GetDistroVersion.py |  7 +++-
 .../autobuilder/buildsteps/PublishArtifacts.py | 48 --
 .../buildbot/process/botmaster.py  |  3 +-
 .../buildbot/status/master.py  | 12 +-
 8 files changed, 106 insertions(+), 47 deletions(-)
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py

-- 
1.9.0

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

Re: [yocto] [OE-core] GStreamer 0.10's future

[Tim Orling]

> On May 8, 2014, at 8:07 AM, Paul Eggleton  
> wrote:
> 
>> On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
>> Hi all,
>> 
>> Sorry for the cross-post but I want this to have a wide audience.
>> 
>> For the 1.7 release I want to move GStreamer 0.10 from oe-core into
>> meta-multimedia, and ensure everything in oe-core has ported to
>> GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
>> unmaintained so we don't need to be shipping both versions anymore.
>> 
>> Everyone in agreement?  Should I expect any hate mail over this?
> 
> +1
> 
+1 as well
> The next question is does that mean for the "old" libav (which gst-ffmpeg 
> depends upon), do we move that as well or drop it?

If xbmc is ever going to work, it will need to be updated to build ffmpeg 
internally. Unless we can get upstream to improve things.

> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> -- 
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Brian Karcz]

Hi Bruce,

I'm not entirely familiar with the mechanism that gets the defconfig from the 
BSP to the .config in work area, but here is how things currently look. The two 
files aren't a direct match as there appear to be some formatting differences, 
but the variables in the SOC/ARCH section seem to correlate partially (ie. it 
knows its trying to build for an at91sam9x5 SOC).

defconfig:
CONFIG_ARCH_AT91=y
CONFIG_SOC_AT91SAM9260=y
CONFIG_SOC_AT91SAM9263=y
CONFIG_SOC_AT91SAM9G45=y
CONFIG_SOC_AT91SAM9X5=y
CONFIG_MACH_AT91SAM_DT=y

.config:
#
# Atmel AT91 Processor
#
# CONFIG_SOC_AT91RM9200 is not set
CONFIG_SOC_AT91SAM9260=y
# CONFIG_SOC_AT91SAM9261 is not set
CONFIG_SOC_AT91SAM9263=y
# CONFIG_SOC_AT91SAM9RL is not set
CONFIG_SOC_AT91SAM9G45=y
CONFIG_SOC_AT91SAM9X5=y
# CONFIG_SOC_AT91SAM9N12 is not set

#
# Atmel Non-DT world
#
CONFIG_ARCH_AT91_NONE=y
# CONFIG_ARCH_AT91RM9200 is not set
# CONFIG_ARCH_AT91SAM9260 is not set
# CONFIG_ARCH_AT91SAM9261 is not set
# CONFIG_ARCH_AT91SAM9263 is not set
# CONFIG_ARCH_AT91SAM9RL is not set
# CONFIG_ARCH_AT91SAM9G45 is not set

#
# AT91 Board Options
#

#
# Generic Board Type
#
# CONFIG_MACH_AT91SAM9_DT is not set

Given the fact that the ARCH and DT variables don't appear to match, it looks 
like this might be device tree related.

I was hoping the code out of the box was going to be able to provide a demo 
image that I could build and poke around in for some guidance. My ultimate goal 
is to port the at91sam9x5ek machine definition to one for the at91sam9g20ek 
demo board and then port THAT over to a custom machine based roughly off that 
reference design.


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Friday, May 09, 2014 9:55 AM
To: Brian Karcz; yocto@yoctoproject.org
Subject: Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" 
failure for core-image-minimal

On 14-05-09 09:44 AM, Brian Karcz wrote:
> Hi,
>
> Not sure if this is the correct place to email this, but I've seen a 
> few other meta-atmel references so I figured I'd give it a shot.
>
> I'm attempting to setup a core-image-minimal build using the 
> guidelines in the meta-atmel README for the at91sam9x5ek machine type. 
> When the kernel build goes to link, I get a "no machine record 
> defined" error. Is this something others are seeing in the meta-atmel demo 
> builds?
>
> It's a pretty benign build setup according to the README:
>
> git clone git://git.yoctoproject.org/poky
>
> cd poky
>
> git checkout dora-10.0.1 -b dora-10.0.1
>
> git clone git://git.openembedded.org/meta-openembedded
>
> cd meta-openembedded
>
> git checkout 6572316557e742c2dc93848e4d560242bf0c3995 -b my_branch
>
> cd ..
>
> git clone http://github.com/linux4sam/meta-atmel
>
> source oe-init-build-env /workspace/build-atmel
>
> modify local.conf:
>
> MACHINE ??= "at91sam9x5ek"
>
> PACKAGE_CLASSES ?= "package_ipk"
>
> modify bblayers.conf:
>
> BBLAYERS ?= " \
>
>/opt/poky/meta-atmel \
>
>/opt/poky/meta \
>
>/opt/poky/meta-yocto \
>
>/opt/poky/meta-yocto-bsp \
>
>/opt/poky/meta-openembedded/meta-oe \
>
>/opt/poky/meta-openembedded/meta-networking \
>
>"
>
> bitbake core-image-minimal
>
> Setting this up, I get the following build configuration and error:
>
> /workspace/build-atmel$ bitbake core-image-minimal
>
> Loading cache: 100%
> |#
> |#|
> ETA:  00:00:00
>
> Loaded 1782 entries from dependency cache.
>
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
>
> BB_VERSION= "1.20.0"
>
> BUILD_SYS = "x86_64-linux"
>
> NATIVELSBSTRING   = "Ubuntu-12.04"
>
> TARGET_SYS= "arm-poky-linux-gnueabi"
>
> MACHINE   = "at91sam9x5ek"
>
> DISTRO= "poky"
>
> DISTRO_VERSION= "1.5.1"
>
> TUNE_FEATURES = "armv5 thumb dsp"
>
> TARGET_FPU= "soft"
>
> meta-atmel= "master:269066a8128d1e767deee64854a142e67451a5f2"
>
> meta
>
> meta-yocto
>
> meta-yocto-bsp= "dora-10.0.1:8e410e9e46e3335458a7747cdd32e05f5c19ccbb"
>
> meta-oe
>
> meta-networking   = "my_branch:6572316557e742c2dc93848e4d560242bf0c3995"
>
> NOTE: Preparing runqueue
>
> NOTE: Executing SetScene Tasks
>
> NOTE: Executing RunQueue Tasks
>
> ERROR: Function failed: do_compile (log file is located at
> /workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-
> yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291)
>
> ERROR: Logfile of failure stored in:
> /workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-
> yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291
>
> Log data follows:
>
> | DEBUG: Executing

Re: [yocto] Question / issue

[Bruce Ashfield]

On 14-05-09 01:14 AM, Paul McGougan wrote:


Hi all.

We are currently using Poky 1.5.0.

We have created our own custom layer for our powerpc-based board.

We are running u-boot as our bootloader and want to use the new FIT 
(FDT) style kernel/dtb image blob.


To that end, in our custom layer we have a file 
poky/meta-OURS/recipes-kernel/linux/linux-yocto_3.10.bbappend, and in 
that file I have a function do_install_append() in which I call 
u-boot's mkimage passing it the kernel and DTB files that we want 
stored in the FIT image that we will use to boot from u-boot.


My first question is, is there a better place to be making the FIT image?



It depends on if everything you need to construct the FIT image is
in the kernel's build directory, or also available in the sysroot/deploy
directories.

If you need kernel build artifacts, doing it in the bbappend (or a .inc,
.bbclass, etc) of the kernel recipe is the right place.

As a side-question to that, I was surprised that there isn't native 
support already for creating this type of u-boot image considering how 
useful it is, does anyone know if there is a specific reason no one 
has done this yet?




None that I know of (but I haven't checked all the SDK, vendor
and distro layers in the ecosystem).

Either a image_types bbclass or something like the existing linux-dtb.inc
could fill the roll. It just depends on what is needed to build the uImage.

Secondly, (and this is our main issue) I have found that by adding the 
do_install_append function, even if it is completely empty, whenever I 
try to bitbake anything that depends on the kernel, that bitbake 
always re-runs the kernel install stage, even when there have been no 
changes. Literally I can run a bitbake, then run the same bitbake 
command again, and both times the kernel install stage gets run (this 
is a problem because it takes a long time to run). It appears to be 
happening because the stampfile is not found every time (the hash 
appears to be wrong). Is this a bug? Is there a fix or work-around for 
this problem?




In this front, I'm not the best reference. Checking the sstate signature
might help, it should show which variables are being used .. and possibly
invalidating the signature, triggering the steps to run again.

Bruce


Thanks.

Paul.


Confidentiality Notice: This message (including attachments) is a 
private communication solely for use of the intended recipient(s). If 
you are not the intended recipient(s) or believe you received this 
message in error, notify the sender immediately and then delete this 
message. Any other use, retention, dissemination or copying is 
prohibited and may be a violation of law, including the Electronic 
Communication Privacy Act of 1986."   ­­





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

Re: [yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Bruce Ashfield]

On 14-05-09 09:44 AM, Brian Karcz wrote:

Hi,

Not sure if this is the correct place to email this, but I’ve seen a few
other meta-atmel references so I figured I’d give it a shot.

I’m attempting to setup a core-image-minimal build using the guidelines
in the meta-atmel README for the at91sam9x5ek machine type. When the
kernel build goes to link, I get a “no machine record defined” error. Is
this something others are seeing in the meta-atmel demo builds?

It’s a pretty benign build setup according to the README:

git clone git://git.yoctoproject.org/poky

cd poky

git checkout dora-10.0.1 -b dora-10.0.1

git clone git://git.openembedded.org/meta-openembedded

cd meta-openembedded

git checkout 6572316557e742c2dc93848e4d560242bf0c3995 -b my_branch

cd ..

git clone http://github.com/linux4sam/meta-atmel

source oe-init-build-env /workspace/build-atmel

modify local.conf:

MACHINE ??= ”at91sam9x5ek”

PACKAGE_CLASSES ?= “package_ipk”

modify bblayers.conf:

BBLAYERS ?= " \

   /opt/poky/meta-atmel \

   /opt/poky/meta \

   /opt/poky/meta-yocto \

   /opt/poky/meta-yocto-bsp \

   /opt/poky/meta-openembedded/meta-oe \

   /opt/poky/meta-openembedded/meta-networking \

   "

bitbake core-image-minimal

Setting this up, I get the following build configuration and error:

/workspace/build-atmel$ bitbake core-image-minimal

Loading cache: 100%
|##|
ETA:  00:00:00

Loaded 1782 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies

Build Configuration:

BB_VERSION= "1.20.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING   = "Ubuntu-12.04"

TARGET_SYS= "arm-poky-linux-gnueabi"

MACHINE   = "at91sam9x5ek"

DISTRO= "poky"

DISTRO_VERSION= "1.5.1"

TUNE_FEATURES = "armv5 thumb dsp"

TARGET_FPU= "soft"

meta-atmel= "master:269066a8128d1e767deee64854a142e67451a5f2"

meta

meta-yocto

meta-yocto-bsp= "dora-10.0.1:8e410e9e46e3335458a7747cdd32e05f5c19ccbb"

meta-oe

meta-networking   = "my_branch:6572316557e742c2dc93848e4d560242bf0c3995"

NOTE: Preparing runqueue

NOTE: Executing SetScene Tasks

NOTE: Executing RunQueue Tasks

ERROR: Function failed: do_compile (log file is located at
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291)

ERROR: Logfile of failure stored in:
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291

Log data follows:

| DEBUG: Executing shell function do_compile

| NOTE: make -j 2 zImage CC=arm-poky-linux-gnueabi-gcc
-mno-thumb-interwork -marm LD=arm-poky-linux-gnueabi-ld.bfd

|   GEN
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/linux-at91sam9x5ek-standard-build/Makefile

|   CHK include/generated/uapi/linux/version.h

|   CHK include/generated/utsrelease.h

|   Using
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/linux
as source for kernel

| make[3]: `include/generated/mach-types.h' is up to date.

|   CC  scripts/mod/devicetable-offsets.s

|   GEN scripts/mod/devicetable-offsets.h

|   HOSTCC  scripts/mod/file2alias.o

|   CALL
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/linux/scripts/checksyscalls.sh

|   HOSTLD  scripts/mod/modpost

|   CHK include/generated/compile.h

|   LINKvmlinux

|   LD  vmlinux.o

|   MODPOST vmlinux.o

|   GEN .version

|   CHK include/generated/compile.h

|   UPD include/generated/compile.h

|   CC  init/version.o

|   LD  init/built-in.o

| arm-poky-linux-gnueabi-ld.bfd: no machine record defined

| make[2]: *** [vmlinux] Error 1

| make[1]: *** [sub-make] Error 2

| make: *** [all] Error 2

| ERROR: oe_runmake failed

| WARNING: exit code 1 from a shell command.

| ERROR: Function failed: do_compile (log file is located at
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291)

ERROR: Task 208
(/opt/poky/meta-atmel/recipes-kernel/linux/linux-yocto-custom_3.10.bb,
do_compile) failed with exit code '1'

NOTE: Tasks Summary: Attempted 793 tasks of which 785 didn't need to be
rerun and 1 failed.

Waiting for 0 running tasks to finish:

Summary: 1 task failed:

   /opt/poky/meta-atmel/recipes-kernel/linux/linux-yocto-custom_3.10.bb,
do_compile

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Any thoughts on what might be missing from the README or my
implementation of it to get this demo build working?


Can you confirm that the final .config for the board has the machine
definitions that you'd expect for the board ?

Bruce



Thanks,

Brian





--

[yocto] [meta-atmel] at91sam9x5ek: "no machine record defined" failure for core-image-minimal

[Brian Karcz]

Hi,

Not sure if this is the correct place to email this, but I've seen a few other 
meta-atmel references so I figured I'd give it a shot.

I'm attempting to setup a core-image-minimal build using the guidelines in the 
meta-atmel README for the at91sam9x5ek machine type. When the kernel build goes 
to link, I get a "no machine record defined" error. Is this something others 
are seeing in the meta-atmel demo builds?

It's a pretty benign build setup according to the README:

git clone git://git.yoctoproject.org/poky
cd poky
git checkout dora-10.0.1 -b dora-10.0.1
git clone git://git.openembedded.org/meta-openembedded
cd meta-openembedded
git checkout 6572316557e742c2dc93848e4d560242bf0c3995 -b my_branch
cd ..
git clone http://github.com/linux4sam/meta-atmel
source oe-init-build-env /workspace/build-atmel

modify local.conf:

MACHINE ??= "at91sam9x5ek"

PACKAGE_CLASSES ?= "package_ipk"

modify bblayers.conf:

BBLAYERS ?= " \

  /opt/poky/meta-atmel \

  /opt/poky/meta \

  /opt/poky/meta-yocto \

  /opt/poky/meta-yocto-bsp \

  /opt/poky/meta-openembedded/meta-oe \

  /opt/poky/meta-openembedded/meta-networking \

  "
bitbake core-image-minimal

Setting this up, I get the following build configuration and error:

/workspace/build-atmel$ bitbake core-image-minimal
Loading cache: 100% 
|##|
 ETA:  00:00:00
Loaded 1782 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.20.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "at91sam9x5ek"
DISTRO= "poky"
DISTRO_VERSION= "1.5.1"
TUNE_FEATURES = "armv5 thumb dsp"
TARGET_FPU= "soft"
meta-atmel= "master:269066a8128d1e767deee64854a142e67451a5f2"
meta
meta-yocto
meta-yocto-bsp= "dora-10.0.1:8e410e9e46e3335458a7747cdd32e05f5c19ccbb"
meta-oe
meta-networking   = "my_branch:6572316557e742c2dc93848e4d560242bf0c3995"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_compile (log file is located at 
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291)
ERROR: Logfile of failure stored in: 
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 2 zImage CC=arm-poky-linux-gnueabi-gcc  -mno-thumb-interwork 
-marm LD=arm-poky-linux-gnueabi-ld.bfd
|   GEN 
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/linux-at91sam9x5ek-standard-build/Makefile
|   CHK include/generated/uapi/linux/version.h
|   CHK include/generated/utsrelease.h
|   Using 
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/linux
 as source for kernel
| make[3]: `include/generated/mach-types.h' is up to date.
|   CC  scripts/mod/devicetable-offsets.s
|   GEN scripts/mod/devicetable-offsets.h
|   HOSTCC  scripts/mod/file2alias.o
|   CALL
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/linux/scripts/checksyscalls.sh
|   HOSTLD  scripts/mod/modpost
|   CHK include/generated/compile.h
|   LINKvmlinux
|   LD  vmlinux.o
|   MODPOST vmlinux.o
|   GEN .version
|   CHK include/generated/compile.h
|   UPD include/generated/compile.h
|   CC  init/version.o
|   LD  init/built-in.o
| arm-poky-linux-gnueabi-ld.bfd: no machine record defined
| make[2]: *** [vmlinux] Error 1
| make[1]: *** [sub-make] Error 2
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at 
/workspace/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/3.10+AUTOINC+68f2c28207-r5/temp/log.do_compile.2291)
ERROR: Task 208 
(/opt/poky/meta-atmel/recipes-kernel/linux/linux-yocto-custom_3.10.bb, 
do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 793 tasks of which 785 didn't need to be rerun 
and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
  /opt/poky/meta-atmel/recipes-kernel/linux/linux-yocto-custom_3.10.bb, 
do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Any thoughts on what might be missing from the README or my implementation of 
it to get this demo build working?

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

[yocto] Mesa do_compile fail

[Fabio Berton]

Hi!
I'm trying to make a qt4-x11 image and the mesa_9.1.6.bb failed on compile. The 
log is http://pastebin.com/0Zznjsux
I'm using host build Fedora 20 and dora branch from poky. I tried to use the 
mesa version 9.1.3 and the same error occurs.

Fabio Berton.

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

Re: [yocto] [meta-selinux][PATCH] initscripts/checkroot.sh: restore file contexts for /run

[Joe MacDonald]

Merged, thanks Jackie.

-J.

[[yocto] [meta-selinux][PATCH] initscripts/checkroot.sh: restore file contexts 
for /run] On 14.05.09 (Fri 05:50) jackie.hu...@windriver.com wrote:

> From: Jackie Huang 
> 
> The file contexts for /run is incorrect while running checkroot.sh
> in boot time which causes mount fail to create new dir and file
> in /run, so restore the security contexts in it.
> 
> Signed-off-by: Jackie Huang 
> ---
>  recipes-core/initscripts/initscripts_1.0.bbappend |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/recipes-core/initscripts/initscripts_1.0.bbappend 
> b/recipes-core/initscripts/initscripts_1.0.bbappend
> index 7ec66ea..367cd6b 100644
> --- a/recipes-core/initscripts/initscripts_1.0.bbappend
> +++ b/recipes-core/initscripts/initscripts_1.0.bbappend
> @@ -5,4 +5,6 @@ do_install_append () {
>  touch /var/log/lastlog
>  test ! -x /sbin/restorecon || /sbin/restorecon -RF /var/volatile/ /var/lib 
> /run
>  EOF
> + sed -i '/mount -n -o remount,$rootmode/i\test ! -x /sbin/restorecon || 
> /sbin/restorecon -RF /run' \
> + ${D}${sysconfdir}/init.d/checkroot.sh
>  }
> -- 
> 1.7.9.5
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] replace udhcpc

[Andrea Galbusera]

Hi,

On Fri, May 9, 2014 at 12:28 PM, Neuer User  wrote:
> Connman is really a problem without documentation. :-(
>
> I tried it out and first I noticed that it depends on the creation of an
> xuser account. It also needs iptables, so probably can configure these, too.
>
> I also found that it does not correctly configure the dns entries:
>
> cat /etc/resolv.conf:
> # Generated by Connection Manager
> nameserver 127.0.0.1
> nameserver ::1

This is in fact a working configuration for the DNS proxy feature that
connman offers built-in. See [1].
I personally went through your same frustration when trying to
understand how connman is supposed to work in order to evaluate its
maturity. Not yet an expert at all, but [2] and [3] gave me a
reasonable bootstrap into connman's main logic. Beside this, "git
grepping" the source tree is your best friend.
Angstrom distribution, i.e. available on the beaglebone boards is also
a good example of a real connman based system.

> I really would like to understand what it does with these and how I can
> change or modify it's behaviour.
>
> It's definitely not just "when ethernet cable inserted, bring up the
> interface using DHCP".
>
> I even can't find a config file for connman. Is there one?

Yes, there usually is one for each service handled by connman. See [4]
for details on configuration file format and their default location.
As you can see from previously suggested references, you'll usually
modify configurations by using the connmanctl client tool instead of
editing those files by hand.

[1] http://git.kernel.org/cgit/network/connman/connman.git/tree/README
[2] http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
[3] http://www.ptrackapp.com/apclassys-notes/embedded-linux-using-connma/
[4] 
http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt

>
> Thanks
>
> Michael
>
> Am 08.05.2014 12:27, schrieb Burton, Ross:
>> On 8 May 2014 04:58, Neuer User  wrote:
>>> I had a brief look at connman half a year ago, but that time I was
>>> unable to find a good documentation about it. Do you have by chance a
>>> link to some tutorial or at least man entry for the configuration?
>>
>> What do you need to configure?  For "when ethernet cable inserted,
>> bring up the interface using DHCP" this is default behaviour and won't
>> need any configuring.  connman is sadly under-documented but the IRC
>> channel is fairly responsive.
>>
>> Ross
>>
>
>
> --
> ___
> 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] [meta-raspberrypi][PATCH 8/9] rpi-gpio: Update to v0.5.5

[Andrei Gherzan]

Change-Id: I8394426b9ffc3c3b524e9fb536945e25d74b2ddd
Signed-off-by: Andrei Gherzan 
---
 recipes-devtools/python/rpi-gpio_0.5.4.bb | 19 ---
 recipes-devtools/python/rpi-gpio_0.5.5.bb | 19 +++
 2 files changed, 19 insertions(+), 19 deletions(-)
 delete mode 100644 recipes-devtools/python/rpi-gpio_0.5.4.bb
 create mode 100644 recipes-devtools/python/rpi-gpio_0.5.5.bb

diff --git a/recipes-devtools/python/rpi-gpio_0.5.4.bb 
b/recipes-devtools/python/rpi-gpio_0.5.4.bb
deleted file mode 100644
index 7307399..000
--- a/recipes-devtools/python/rpi-gpio_0.5.4.bb
+++ /dev/null
@@ -1,19 +0,0 @@
-DESCRIPTION = "A module to control Raspberry Pi GPIO channels"
-HOMEPAGE = "http://code.google.com/p/raspberry-gpio-python/";
-SECTION = "devel/python"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENCE.txt;md5=35af90ff2a10e8bdc967653b9dfcb22a"
-
-SRCNAME = "RPi.GPIO"
-
-SRC_URI = "\
-  
http://pypi.python.org/packages/source/R/RPi.GPIO/${SRCNAME}-${PV}.tar.gz \
-  "
-S = "${WORKDIR}/${SRCNAME}-${PV}"
-
-inherit distutils
-
-COMPATIBLE_MACHINE = "raspberrypi"
-
-SRC_URI[md5sum] = "add6554ed8331d515fccb5e052c7d1ff"
-SRC_URI[sha256sum] = 
"5fae8e59a9a1cdb68208d40239d7ad788d22aa9d58c54c482fa5d89ccc4c0f37"
diff --git a/recipes-devtools/python/rpi-gpio_0.5.5.bb 
b/recipes-devtools/python/rpi-gpio_0.5.5.bb
new file mode 100644
index 000..1d73331
--- /dev/null
+++ b/recipes-devtools/python/rpi-gpio_0.5.5.bb
@@ -0,0 +1,19 @@
+DESCRIPTION = "A module to control Raspberry Pi GPIO channels"
+HOMEPAGE = "http://code.google.com/p/raspberry-gpio-python/";
+SECTION = "devel/python"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENCE.txt;md5=35af90ff2a10e8bdc967653b9dfcb22a"
+
+SRCNAME = "RPi.GPIO"
+
+SRC_URI = "\
+  
http://pypi.python.org/packages/source/R/RPi.GPIO/${SRCNAME}-${PV}.tar.gz \
+  "
+S = "${WORKDIR}/${SRCNAME}-${PV}"
+
+inherit distutils
+
+COMPATIBLE_MACHINE = "raspberrypi"
+
+SRC_URI[md5sum] = "8cbc1cb0c0f1a4d93bf1efe1a745f1f0"
+SRC_URI[sha256sum] = 
"c8e1f0da6327103a3551a6e86055ef001113b94af683fcb08070db5f5ecea51f"
-- 
1.8.5.3

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

[yocto] [meta-raspberrypi][PATCH 7/9] userland: Update to remote's HEAD

[Andrei Gherzan]

Change-Id: If0e36184c741da5d68c158e1fb582050f5835bf9
Signed-off-by: Andrei Gherzan 
---
 recipes-graphics/userland/userland_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-graphics/userland/userland_git.bb 
b/recipes-graphics/userland/userland_git.bb
index 07c8381..a348090 100644
--- a/recipes-graphics/userland/userland_git.bb
+++ b/recipes-graphics/userland/userland_git.bb
@@ -11,7 +11,7 @@ PROVIDES = "virtual/libgles2 \
 virtual/egl"
 COMPATIBLE_MACHINE = "raspberrypi"
 
-SRCREV = "8181677fc08814cd5fcd1475ab73046f89f8dc80"
+SRCREV = "eccb81050afd177da1923404b366c6226f29bfe0"
 SRC_URI = 
"git://github.com/raspberrypi/userland.git;protocol=git;branch=master \
   "
 S = "${WORKDIR}/git"
-- 
1.8.5.3

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

[yocto] [meta-raspberrypi][PATCH 9/9] omxplayer: Update to remote's HEAD

[Andrei Gherzan]

Rebase a patch for this version and fix "unsafe for cross-compilation"
warnings.

Change-Id: Idcc9f188bc716982ede9dfb5f87870d9f5a2f9a3
Signed-off-by: Andrei Gherzan 
---
 ...nd-headers-from-ffmpeg-are-installed-in-u.patch | 38 +-
 recipes-multimedia/omxplayer/omxplayer_git.bb  |  2 +-
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git 
a/recipes-multimedia/omxplayer/omxplayer/0002-Libraries-and-headers-from-ffmpeg-are-installed-in-u.patch
 
b/recipes-multimedia/omxplayer/omxplayer/0002-Libraries-and-headers-from-ffmpeg-are-installed-in-u.patch
index 7f7927f..9bc137f 100644
--- 
a/recipes-multimedia/omxplayer/omxplayer/0002-Libraries-and-headers-from-ffmpeg-are-installed-in-u.patch
+++ 
b/recipes-multimedia/omxplayer/omxplayer/0002-Libraries-and-headers-from-ffmpeg-are-installed-in-u.patch
@@ -8,37 +8,45 @@ Don't search for libraries and headers in /usr/local.
 Upstream-Status: Inappropriate [embedded specific]
 Signed-off-by: Andrei Gherzan 
 
-Index: git/Makefile
-===
 git.orig/Makefile
-+++ git/Makefile
-@@ -1,9 +1,9 @@
+---
+ Makefile| 6 +++---
+ Makefile.ffmpeg | 2 +-
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 87cb775..abe9923 100644
+--- a/Makefile
 b/Makefile
+@@ -2,9 +2,9 @@ include Makefile.include
  
  CFLAGS+=-std=c++0x -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS 
-DTARGET_POSIX -DTARGET_LINUX -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE 
-D_FILE_OFFSET_BITS=64 -DHAVE_CMAKE_CONFIG -D__VIDEOCORE4__ -U_FORTIFY_SOURCE 
-Wall -DHAVE_OMXLIB -DUSE_EXTERNAL_FFMPEG  -DHAVE_LIBAVCODEC_AVCODEC_H 
-DHAVE_LIBAVUTIL_OPT_H -DHAVE_LIBAVUTIL_MEM_H -DHAVE_LIBAVUTIL_AVUTIL_H 
-DHAVE_LIBAVFORMAT_AVFORMAT_H -DHAVE_LIBAVFILTER_AVFILTER_H 
-DHAVE_LIBSWRESAMPLE_SWRESAMPLE_H -DOMX -DOMX_SKIP64BIT -ftree-vectorize 
-DUSE_EXTERNAL_OMX -DTARGET_RASPBERRY_PI -DUSE_EXTERNAL_LIBBCM_HOST
  
 -LDFLAGS+=-L./ -Lffmpeg_compiled/usr/local/lib/ -lc -lWFC -lGLESv2 -lEGL 
-lbcm_host -lopenmaxil -lfreetype -lz
 +LDFLAGS+=-L./ -Lffmpeg_compiled/usr/lib/ -lc -lWFC -lGLESv2 -lEGL -lbcm_host 
-lopenmaxil -lfreetype -lz
  
--INCLUDES+=-I./ -Ilinux -Iffmpeg_compiled/usr/local/include/
-+INCLUDES+=-I./ -Ilinux -Iffmpeg_compiled/usr/include/
+-INCLUDES+=-I./ -Ilinux -Iffmpeg_compiled/usr/local/include/ -I 
/usr/include/dbus-1.0 -I /usr/lib/arm-linux-gnueabihf/dbus-1.0/include
++INCLUDES+=-I./ -Ilinux -Iffmpeg_compiled/usr/include/ 
-I=/usr/include/dbus-1.0 -I=/usr/lib/arm-linux-gnueabihf/dbus-1.0/include
  
  DIST ?= omxplayer-dist
  
-@@ -70,5 +70,5 @@ dist: omxplayer.bin
+@@ -71,5 +71,5 @@ dist: omxplayer.bin
cp omxplayer omxplayer.bin $(DIST)/usr/bin
-   cp COPYING $(DIST)/usr/share/doc/
-   cp README.md $(DIST)/usr/share/doc/README
+   cp COPYING $(DIST)/usr/share/doc/omxplayer
+   cp README.md $(DIST)/usr/share/doc/omxplayer/README
 -  cp -a ffmpeg_compiled/usr/local/lib/*.so* $(DIST)/usr/lib/omxplayer/
 +  cp -a ffmpeg_compiled/usr/lib/*.so* $(DIST)/usr/lib/omxplayer/
cd $(DIST); tar -czf ../$(DIST).tgz *
-Index: git/Makefile.ffmpeg
-===
 git.orig/Makefile.ffmpeg
-+++ git/Makefile.ffmpeg
-@@ -248,5 +248,5 @@ checkout:
+diff --git a/Makefile.ffmpeg b/Makefile.ffmpeg
+index c21b2fa..5518680 100644
+--- a/Makefile.ffmpeg
 b/Makefile.ffmpeg
+@@ -249,5 +249,5 @@ checkout:
  
  install:
cd ffmpeg; make -j9 DESTDIR="$(WORK)/ffmpeg_compiled" install
 -  $(HOST)-strip ffmpeg_compiled/usr/local/lib/*.so
 +  $(HOST)-strip ffmpeg_compiled/usr/lib/*.so
  
+-- 
+1.8.5.3
+
diff --git a/recipes-multimedia/omxplayer/omxplayer_git.bb 
b/recipes-multimedia/omxplayer/omxplayer_git.bb
index cee68e1..5763d8f 100644
--- a/recipes-multimedia/omxplayer/omxplayer_git.bb
+++ b/recipes-multimedia/omxplayer/omxplayer_git.bb
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 DEPENDS = "libpcre libav virtual/egl boost freetype dbus"
 PR = "r3"
 
-SRCREV = "7af21f596378e5efeceebedff9c4a298e2d06d98"
+SRCREV = "f3221825a92f27c5f49a52200ff933e454977ed2"
 SRC_URI = 
"git://github.com/popcornmix/omxplayer.git;protocol=git;branch=master \
file://0001-Remove-Makefile.include-which-includes-hardcoded.patch \

file://0002-Libraries-and-headers-from-ffmpeg-are-installed-in-u.patch \
-- 
1.8.5.3

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

[yocto] [meta-raspberrypi][PATCH 6/9] firmware: Update to remote's HEAD

[Andrei Gherzan]

Change-Id: I9e28318c5746484ebde636295c66f7b6b64ba2fb
Signed-off-by: Andrei Gherzan 
---
 recipes-bcm/common/firmware.inc | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/recipes-bcm/common/firmware.inc b/recipes-bcm/common/firmware.inc
index 390f6b3..168cd37 100644
--- a/recipes-bcm/common/firmware.inc
+++ b/recipes-bcm/common/firmware.inc
@@ -1,6 +1,5 @@
-# 21/02/2014 firmware; this can be overridden from distro config
-RPIFW_SRCREV ?= "cf20d522e926f30e91fa890d42d010ca98913286"
-RPIFW_DATE ?= "20140221"
+RPIFW_SRCREV ?= "c8881991d9181779aee9637d6f4b215f108021a3"
+RPIFW_DATE ?= "20140508"
 RPIFW_SRC_URI ?= 
"git://github.com/raspberrypi/firmware.git;protocol=git;branch=master"
 RPIFW_S ?= "${WORKDIR}/git"
 
-- 
1.8.5.3

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

[yocto] [meta-raspberrypi][PATCH 5/9] linux-raspberrypi: Replace v3.13.3 by v3.14.2

[Andrei Gherzan]

Change-Id: I2ceb950d30f984ab66de79085b30b541d20e6e25
Signed-off-by: Andrei Gherzan 
---
 recipes-kernel/linux/linux-raspberrypi_3.13.3.bb | 6 --
 recipes-kernel/linux/linux-raspberrypi_3.14.2.bb | 6 ++
 2 files changed, 6 insertions(+), 6 deletions(-)
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi_3.13.3.bb
 create mode 100644 recipes-kernel/linux/linux-raspberrypi_3.14.2.bb

diff --git a/recipes-kernel/linux/linux-raspberrypi_3.13.3.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.13.3.bb
deleted file mode 100644
index 078c031..000
--- a/recipes-kernel/linux/linux-raspberrypi_3.13.3.bb
+++ /dev/null
@@ -1,6 +0,0 @@
-SRCREV = "660b0008f5d318d8a29187b64c8717e75ad14c1c"
-SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.13.y \
-   file://sl030raspberrypii2ckernel.patch \
-  "
-
-require linux-raspberrypi.inc
diff --git a/recipes-kernel/linux/linux-raspberrypi_3.14.2.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.14.2.bb
new file mode 100644
index 000..9cb7c64
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi_3.14.2.bb
@@ -0,0 +1,6 @@
+SRCREV = "b0da29026e2bd5602fed7f650124838696f9dda6"
+SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.14.y \
+   file://sl030raspberrypii2ckernel.patch \
+  "
+
+require linux-raspberrypi.inc
-- 
1.8.5.3

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

[yocto] [meta-raspberrypi][PATCH 1/9] rpi-default-versions: Use 3.12.X as default kernel version

[Andrei Gherzan]

Change-Id: Ief7949be4b9726b5b6ba58e6280f6b6ca3fdfdc4
Signed-off-by: Andrei Gherzan 
---
 conf/machine/include/rpi-default-versions.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/include/rpi-default-versions.inc 
b/conf/machine/include/rpi-default-versions.inc
index 04297ba..1ca9701 100644
--- a/conf/machine/include/rpi-default-versions.inc
+++ b/conf/machine/include/rpi-default-versions.inc
@@ -1,3 +1,3 @@
 # RaspberryPi BSP default versions
 
-PREFERRED_VERSION_linux-raspberrypi ?= "3.10.%"
+PREFERRED_VERSION_linux-raspberrypi ?= "3.12.%"
-- 
1.8.5.3

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

[yocto] [meta-raspberrypi][PATCH 4/9] linux-raspberrypi: Update v3.12.11 to v3.12.18

[Andrei Gherzan]

Change-Id: Ifa763e4352051e4533eac98b4f7c74daf791cf72
Signed-off-by: Andrei Gherzan 
---
 recipes-kernel/linux/linux-raspberrypi_3.12.11.bb | 6 --
 recipes-kernel/linux/linux-raspberrypi_3.12.18.bb | 6 ++
 2 files changed, 6 insertions(+), 6 deletions(-)
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi_3.12.11.bb
 create mode 100644 recipes-kernel/linux/linux-raspberrypi_3.12.18.bb

diff --git a/recipes-kernel/linux/linux-raspberrypi_3.12.11.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.12.11.bb
deleted file mode 100644
index ff8ed2a..000
--- a/recipes-kernel/linux/linux-raspberrypi_3.12.11.bb
+++ /dev/null
@@ -1,6 +0,0 @@
-SRCREV = "e297b214d77ce06a321e5ff98d74ae511ce18696"
-SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \
-   file://sl030raspberrypii2ckernel.patch \
-  "
-
-require linux-raspberrypi.inc
diff --git a/recipes-kernel/linux/linux-raspberrypi_3.12.18.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.12.18.bb
new file mode 100644
index 000..736be5f
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi_3.12.18.bb
@@ -0,0 +1,6 @@
+SRCREV = "b09a27249d61475e4423607f7632a5aa6e7b3a53"
+SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \
+   file://sl030raspberrypii2ckernel.patch \
+  "
+
+require linux-raspberrypi.inc
-- 
1.8.5.3

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

[yocto] [meta-raspberrypi][PATCH 2/9] linux-raspberrypi: Update v3.10.30 to v3.10.38

[Andrei Gherzan]

Change-Id: Ia620e8fd6928f9cd2c625b87599cd6d6a405a344
Signed-off-by: Andrei Gherzan 
---
 recipes-kernel/linux/linux-raspberrypi_3.10.30.bb | 6 --
 recipes-kernel/linux/linux-raspberrypi_3.10.38.bb | 6 ++
 2 files changed, 6 insertions(+), 6 deletions(-)
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi_3.10.30.bb
 create mode 100644 recipes-kernel/linux/linux-raspberrypi_3.10.38.bb

diff --git a/recipes-kernel/linux/linux-raspberrypi_3.10.30.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.10.30.bb
deleted file mode 100644
index e1f2a1a..000
--- a/recipes-kernel/linux/linux-raspberrypi_3.10.30.bb
+++ /dev/null
@@ -1,6 +0,0 @@
-SRCREV = "26d1de2993c81c01f91ebc93a1fad8957c9ece17"
-SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.10.y \
-   file://sl030raspberrypii2ckernel.patch \
-  "
-
-require linux-raspberrypi.inc
diff --git a/recipes-kernel/linux/linux-raspberrypi_3.10.38.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.10.38.bb
new file mode 100644
index 000..a0c5012
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi_3.10.38.bb
@@ -0,0 +1,6 @@
+SRCREV = "1b49b450222df26e4abf7abb6d9302f72b2ed386"
+SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.10.y \
+   file://sl030raspberrypii2ckernel.patch \
+  "
+
+require linux-raspberrypi.inc
-- 
1.8.5.3

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

[yocto] [meta-raspberrypi][PATCH 3/9] linux-raspberrypi: Remove v3.11

[Andrei Gherzan]

Change-Id: I28824a738a081bdeb362da4cf0cb449d11cbe449
Signed-off-by: Andrei Gherzan 
---
 recipes-kernel/linux/linux-raspberrypi_3.11.10.bb | 6 --
 1 file changed, 6 deletions(-)
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi_3.11.10.bb

diff --git a/recipes-kernel/linux/linux-raspberrypi_3.11.10.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.11.10.bb
deleted file mode 100644
index 6df11fe..000
--- a/recipes-kernel/linux/linux-raspberrypi_3.11.10.bb
+++ /dev/null
@@ -1,6 +0,0 @@
-SRCREV = "8f768c5f2a3314e4eacce8d667c787f8dadfda74"
-SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.11.y \
-   file://sl030raspberrypii2ckernel.patch \
-  "
-
-require linux-raspberrypi.inc
-- 
1.8.5.3

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

Re: [yocto] Third Party Components Integration in Yocto

[Alex J Lennon]

On 09/05/2014 06:56, Meenakumari Shedole wrote:
> Thanks for your response Alex.
>
> I gone with all these steps but not helpful.
>

Hi Meena,

I'm sorry to hear that. I think your installation line is still
incorrect, and should probably be ${S}/bb-example or ${WORKDIR}/bb-example

I'm not sure what is in the source archive you are using
'bb-example.tar.bz2' though, but you're specifying make in your recipe
so I imagine you are attempting to build something? Perhaps that's not
working?

If the compile is failing you should see some errors in the log files we
discussed.

If you upload bb-example.tar.bz2 somewhere for me I will take a look at
it for you.

>   install -m 0755 bb-example ${D}${bindir}

That said, I don't want to overcomplicate things for you, but I'm
assuming you're trying to understand how the build system works so it
might be worth us taking a step back here and looking at some simple
examples that do work to understand the process.

I've commited a very simple autotools based project to git hub here,
https://github.com/DynamicDevices/bbexample

This will build an executable called bbexample with a dependency on a
shared library. It'll print out a couple of Hello World messages.

Building on the host for test


You can check this all works on your build PC - independently of the
Yocto environment - with something like the following:
(Note that I've taken the hyphen out of the name of the executable as it
was causing me trouble with autotools configuration)

git clone  git://github.com/DynamicDevices/bbexample.git
cd bbexample
./autogen.sh
./configure
make

At the end of this process you will have an executable 'bbexample' in
your build directory

If you run it with:

./bbexample

You will see

Hello Yocto World...
Hello World (from a shared library!)

So we know this builds and works on your host.

Building and Packaging from a Git Commit
=

Next we can create a recipe that makes use of this project within Yocto
to cross-compile, package the bbexample executable and the shared
library it depends upon.
   
I've created an example layer, using the yocto-layer command, that
contains a recipe to build the bbexample project.

(a) You can git clone and add this layer to your conf/bblayer.conf file

cd sources
git clone  git://github.com/DynamicDevices/meta-example.git

e.g. in conf/local/conf

BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) +
'/../..')}"

BBLAYERS = " \
  ${BSPDIR}/sources/poky/meta \
  ${BSPDIR}/sources/poky/meta-yocto \
  ...
  ${BSPDIR}/sources/meta-example \
  ...
"

(b) Alternatively if you don't want to do that just grab the recipe text
from github and put it somewhere suitable in your source tree.

https://github.com/DynamicDevices/meta-example/blob/master/recipes-example/bbexample/bbexample_1.0.bb

Next run

bitbake bbexample

This will go through fetching the source, unpacking, configuring,
compiling, installing and packaging

Depending on the machine you are targetting the resulting package will
be somewhere in the tmp/deploy tree

e.g. I am building RPMs for Raspberry Pi here so

tmp/deploy/rpm/arm6_vfp/bbexample-1.0-r0.0.armv6_vfp.rpm

You can do something like this to see where it is

cd tmp/deploy
find -name bbexample*

A quick check of the package contents with

rpm -qlp rpm/armv6_vfp/bbexample-1.0-r0.0.armv6_vfp.rpm

shows the executable and the shared library are packaged as we want them

/usr
/usr/bin
/usr/bin/bbexample
/usr/lib
/usr/lib/libbbexample.so.1
/usr/lib/libbbexample.so.1.0.0

You can then add the recipe to your output image by adding something
like this to your conf/local/conf

IMAGE_INSTALL_append = " bbexample"

Building and Packaging from a remote release tarball
===

Now that's still not quite what you are doing, as you are using a source
tarball instead of a git commit from what I can see

So I've created another two recipes, bbexample-rt and bbexample-lt which
show the process for using a remote tarball, and a local tarball

If you run

bitbake bbexample-rt

Bitbake will pull down the archive from

https://github.com/DynamicDevices/bbexample/archive/bbexample-v1.0.tar.gz

It'll unpack the archive, build, install, package and so forth.

As above you'll see the files in the generated archive, something similar to

rpm -qlp tmp/deploy/rpm/armv6_vfp/bbexample-rt-1.0-r0.2.armv6_vfp.rpm

Note that if you look in the recipe you'll see I am redefining the
source directory to be appropriate for the structure of the downloaded
tarball.

This is _critical_ as otherwise bitbake won't find the files...

# Make sure our source directory (for the build) matches the directory
structure in the tarball
# A tagged tarball from github contains a folder which includes the
github tag, so deal with it here
S = "${WORKDIR}/bbexample-bbexample-v${PV}"

https://github.com/DynamicDevices/meta-example/blob/master/recipes-example/bbexample/b

Re: [yocto] Issue with download cache tarball uniqueness?

[Alex J Lennon]

On 09/05/2014 11:38, Alex J Lennon wrote:
> Hi,
>
> I'm putting together a simple example recipe and have run into an issue
> with an incorrect tarball being used from the download cache.
>
> e.g. I have some code committed to github here
>
> https://github.com/DynamicDevices/bbexample/
>
> It's tagged v1.0 so github generates a source tarball for me here
>
> https://github.com/DynamicDevices/bbexample/archive/bbexample-v1.0.tar.gz
>

Correction:

https://github.com/DynamicDevices/bbexample/archive/v1.0.tar.gz

vs

https://github.com/DynamicDevices/mono-helloworld/archive/v1.0.tar.gz
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Issue with download cache tarball uniqueness?

[Alex J Lennon]

Hi,

I'm putting together a simple example recipe and have run into an issue
with an incorrect tarball being used from the download cache.

e.g. I have some code committed to github here

https://github.com/DynamicDevices/bbexample/

It's tagged v1.0 so github generates a source tarball for me here

https://github.com/DynamicDevices/bbexample/archive/bbexample-v1.0.tar.gz

I use a SRC_URI in my recipe something like this

SRC_URI =
"https://github.com/DynamicDevices/bbexample/archive/${PN}-v${PV}.tar.gz";

That should result in the file being downloaded, or pulled from cache,
unpacked and so forth.

When I build this recipe I get the wrong source code unpacked (from a
mono-helloworld project I created a while ago)

The mono-helloworld project is also at github and also tagged v1.0

https://github.com/DynamicDevices/mono-helloworld

https://github.com/DynamicDevices/mono-helloworld/archive/v1.0.tar.gz

If I look in my downloads folder I see there is a v1.0.tar.gz file and a
corresponding .done file.

This contains the mono-helloworld sources.

Thus I believe that bitbake is incorrectly assuming that the
mono-helloworld tarball is the cached bbexample tarball as there's no
URI information there.

I was able to show this by removing the v1.0.tar.gz file containing the
mono-helloworld sources in which case a rebuild of my bbexample recipe
results in the correct sources being pulled down, although of course
then the mono-helloworld recipe is broken

...

It doesn't seem unreasonable to use github or the simple vX.X tagging
mechanism, but if I understand what is happening correctly it seems this
will result in cache collisions with downloaded tarballs because of the
naming convention employed by github and the lack of full URI
information in the download cache?

Alex




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

[yocto] WiPi on meta-raspberrypi

[Joe D]

Would anyone be able to help me set up a recipe for using the WiPi dongle
on the meta-raspberrypi backend?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] replace udhcpc

[Neuer User]

Connman is really a problem without documentation. :-(

I tried it out and first I noticed that it depends on the creation of an
xuser account. It also needs iptables, so probably can configure these, too.

I also found that it does not correctly configure the dns entries:

cat /etc/resolv.conf:
# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1

I really would like to understand what it does with these and how I can
change or modify it's behaviour.

It's definitely not just "when ethernet cable inserted, bring up the
interface using DHCP".

I even can't find a config file for connman. Is there one?

Thanks

Michael

Am 08.05.2014 12:27, schrieb Burton, Ross:
> On 8 May 2014 04:58, Neuer User  wrote:
>> I had a brief look at connman half a year ago, but that time I was
>> unable to find a good documentation about it. Do you have by chance a
>> link to some tutorial or at least man entry for the configuration?
> 
> What do you need to configure?  For "when ethernet cable inserted,
> bring up the interface using DHCP" this is default behaviour and won't
> need any configuring.  connman is sadly under-documented but the IRC
> channel is fairly responsive.
> 
> Ross
> 


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

Re: [yocto] couple simple questions on building for intel galileo

[Robert P. J. Day]

On Thu, 8 May 2014, Rob Woolley wrote:

> Hi Rob,
> Have you seen the Quark BSP Build Guide?
>
> https://communities.intel.com/servlet/JiveServlet/previewBody/21882-102-1-25153/Quark_BSPBuildGuide_329687_001.pdf

  i believe there is a much newer release of that doc here:

https://communities.intel.com/servlet/JiveServlet/previewBody/22476-102-2-26020/Quark_BSP_BuildandSWUserGuide_329687_005.pdf

in my travels around the intertoobz, a few people made it clear they
weren't impressed with the 0.7.5 release, so a newer release is
definitely a good thing.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] [meta-selinux][PATCH] initscripts/checkroot.sh: restore file contexts for /run

[jackie.huang]

From: Jackie Huang 

The file contexts for /run is incorrect while running checkroot.sh
in boot time which causes mount fail to create new dir and file
in /run, so restore the security contexts in it.

Signed-off-by: Jackie Huang 
---
 recipes-core/initscripts/initscripts_1.0.bbappend |2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-core/initscripts/initscripts_1.0.bbappend 
b/recipes-core/initscripts/initscripts_1.0.bbappend
index 7ec66ea..367cd6b 100644
--- a/recipes-core/initscripts/initscripts_1.0.bbappend
+++ b/recipes-core/initscripts/initscripts_1.0.bbappend
@@ -5,4 +5,6 @@ do_install_append () {
 touch /var/log/lastlog
 test ! -x /sbin/restorecon || /sbin/restorecon -RF /var/volatile/ /var/lib /run
 EOF
+   sed -i '/mount -n -o remount,$rootmode/i\test ! -x /sbin/restorecon || 
/sbin/restorecon -RF /run' \
+   ${D}${sysconfdir}/init.d/checkroot.sh
 }
-- 
1.7.9.5

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

Re: [yocto] Third Party Components Integration in Yocto

[Burton, Ross]

On 9 May 2014 06:56, Meenakumari Shedole  wrote:
> install: cannot stat `bb-example': No such file or directory

Your compile task didn't actually work.

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