Re: [yocto] [meta-mono][PATCH] mono-5.xx: fix an issue with too long paths in doltlibtool

[Alex J Lennon]

On 18/06/2019 11:58, Alexander Kanavin wrote:
> Ping #2!
>
> Alex


Apologies for the long delay! The patch is in finally...


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

Re: [yocto] meta-mono: QA Error building mono-5.12.0.226

[Alex J Lennon]

On 22/11/2018 15:46, Martin Townsend wrote:

Hi,

This one is probably for the meta-mono maintainer

I was getting quite a few file-rdeps QA errors.
I managed to get rid of them all except 1 using
RDEPENDS_${PN}-libs-2.0 += "mono"
RDEPENDS_${PN}-libs-3.5 += "mono"
RDEPENDS_${PN}-libs-4.0 += "mono"
RDEPENDS_${PN}-libs-4.5 += "mono"
RDEPENDS_${PN}-gac += "mono"
RDEPENDS_${PN}-configuration-crypto += "mono"
RDEPENDS_${PN}-xbuild += "mono"
RDEPENDS_${PN}-api-4.5.1 += "mono"
RDEPENDS_${PN}-api-4.5.2 += "mono"
RDEPENDS_${PN}-api-4.6 += "mono"
RDEPENDS_${PN}-api-4.6.1 += "mono"
RDEPENDS_${PN}-api-4.6.2 += "mono"
RDEPENDS_${PN}-api-4.7 += "mono"

The one remaining is

ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/4.5/Microsoft.CodeAnalysis.Scripting.dll contained in
package mono-libs-4.5 requires mono(System.Runtime.Loader), but no
providers found in RDEPENDS_mono-libs-4.5? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA run found fatal errors.
Please consider fixing them.
ERROR: mono-5.12.0.226-r0 do_package_qa: Function failed: do_package_qa
ERROR: Logfile of failure stored in:
/ws/rufilla/oina/tools-oina-build-local/build_oxinst/tmp/work/armv7ahf-neon-poky-linux-gnueabi/mono/5.12.0.226-r0/temp/log.do_package_qa.15001
ERROR: Task 
(/ws/rufilla/oina/tools-oina-build-local/build_oxinst/../meta-mono/recipes-mono/mono/mono_5.12.0.226.bb:do_package_qa)
failed with exit code '1'

It looks like the 4.5 lib package requires the System.Runtime.Loader
library but I'm not sure how to get it to build this or I see there is
an external directory which looks like it contains all the 4.5 libs so
maybe it hasn't been included in here?

Any Help appreciated,
Martin.


Hi Martin,

I've been doing some recent work here which might help

https://github.com/dynamicdevices/meta-mono/tree/master

Cheers,

Alex


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

Re: [yocto] mono build issue

[Alex J Lennon]

> On 7 Feb 2018, at 22:43, Máté Tüske  wrote:
> 
> Hi,
> 
> I try to build custom image with mono. Previously I did it successfully, but 
> now I ran into some issue and I cannot solve it.
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/3.5-api/Microsoft.Build.Engine.dll contained in package 
> mono-libs-3.5 requires mono(System.Xml), but no providers found in 
> RDEPENDS_mono-libs-3.5? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/3.5-api/Microsoft.Build.Utilities.v3.5.dll contained in package 
> mono-libs-3.5 requires mono(System), but no providers found in 
> RDEPENDS_mono-libs-3.5? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/3.5-api/Microsoft.Build.Engine.dll contained in package 
> mono-libs-3.5 requires mono(mscorlib), but no providers found in 
> RDEPENDS_mono-libs-3.5? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/mono-configuration-crypto/4.5/Mono.Configuration.Crypto.dll 
> contained in package mono-configuration-crypto requires mono(mscorlib), but 
> no providers found in RDEPENDS_mono-configuration-crypto? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/mono-configuration-crypto/4.5/Mono.Configuration.Crypto.dll 
> contained in package mono-configuration-crypto requires mono(System.Xml), but 
> no providers found in RDEPENDS_mono-configuration-crypto? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/mono-configuration-crypto/4.5/Mono.Configuration.Crypto.dll 
> contained in package mono-configuration-crypto requires mono(System), but no 
> providers found in RDEPENDS_mono-configuration-crypto? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/mono-configuration-crypto/4.5/Mono.Configuration.Crypto.dll 
> contained in package mono-configuration-crypto requires 
> mono(System.Configuration), but no providers found in 
> RDEPENDS_mono-configuration-crypto? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/mono-configuration-crypto/4.5/Mono.Configuration.Crypto.dll 
> contained in package mono-configuration-crypto requires mono(Mono.Security), 
> but no providers found in RDEPENDS_mono-configuration-crypto? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/4.6-api/Mono.Debugger.Soft.dll contained in package 
> mono-api-4.6 requires mono(Mono.Cecil), but no providers found in 
> RDEPENDS_mono-api-4.6? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/4.6.2-api/Mono.Debugger.Soft.dll contained in package 
> mono-api-4.6.2 requires mono(Mono.Cecil), but no providers found in 
> RDEPENDS_mono-api-4.6.2? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/4.7-api/Mono.Debugger.Soft.dll contained in package 
> mono-api-4.7 requires mono(Mono.Cecil), but no providers found in 
> RDEPENDS_mono-api-4.7? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/xbuild/Microsoft/NuGet/Microsoft.NuGet.Build.Tasks.dll 
> contained in package mono-xbuild requires mono(mscorlib), but no providers 
> found in RDEPENDS_mono-xbuild? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/4.6.1-api/Mono.Debugger.Soft.dll contained in package 
> mono-api-4.6.1 requires mono(Mono.Cecil), but no providers found in 
> RDEPENDS_mono-api-4.6.1? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/gac/Mono.Messaging.RabbitMQ/4.0.0.0__0738eb9f132ed756/Mono.Messaging.RabbitMQ.dll
>  contained in package mono-gac requires mono(mscorlib), but no providers 
> found in RDEPENDS_mono-gac? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA Issue: 
> /usr/lib/mono/4.5/Microsoft.CodeAnalysis.Scripting.dll contained in package 
> mono-libs-4.5 requires mono(System.Runtime.Loader), but no providers found in 
> RDEPENDS_mono-libs-4.5? [file-rdeps]
> ERROR: mono-5.4.1.6-r0 do_package_qa: QA run found fatal errors. Please 
> consider fixing them.
> ERROR: mono-5.4.1.6-r0 do_package_qa: Function failed: do_package_qa
> Can you help me with this?
> 
> regards,
> Matthew
Hi,

I’m in the middle of the Red Sea at the moment but if you can provide your 
build configuration I’ll take a look next week (assuming this hasn’t been 
resolved in the meantime)

Cheers,

Alex


> -- 
> ___
> 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-mono 5.2.x recipe and pdb files

[Alex J Lennon]

> On 18 Oct 2017, at 07:22, Craig McQueen  wrote:
> 
> I wrote:
>> 
>> I'm trying to upgrade from mono 4.6.x to 5.2.x. I see resulting image size
>> increases by about 10 MB in my usage. It appears that a significant
>> contributing factor is the presence of *.pdb files in 5.2.x which weren't in
>> 4.6.x.
>> 
>> * Are the *.pdb files necessary?
>> * What can  be done to exclude them?
> 
> Seeing how the recipe handles *.mdb files, I made a bbappend file containing:
> 
> FILES_${PN}-dbg+= "${libdir}/mono/*/*.pdb ${libdir}/mono/*/*/*.pdb 
> ${libdir}/mono/gac/*/*/*.pdb"
> 
> That seems to do it. This should probably be added to the mono recipe files 
> for mono >= 5.0.x.
> 


Sounds good. I’ll take a look at this in the next couple of days.

Cheers,

Alex

> -- 
> Craig McQueen
> 

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

Re: [yocto] mono 5.0.1.1 TypeLoadException

[Alex J Lennon]

Hi Robin,

If you supply a test case I’ll take a look.

Regards,

Alex

> On 2 Oct 2017, at 15:02, MUGRIDGE Robin  wrote:
> 
> Hi,
>  
> I am using mono with Krogoth.  The current version of mono we are building 
> with is 4.2.2.30.
>  
> I am trying to move mono forward to 5.0.1.1 to avoid an issue in the 
> HttpListener class, but now get a TypeLoadException which I assume is a 
> missing assembly or a build configuration error, but I’m struggling to work 
> out what’s wrong…
>  
> System.TypeLoadException: Could not load type of field 
> 'System.Net.HttpListener:tlsSettings' (9) due to: Could not resolve type with 
> token 0134 (from typeref, class/assembly 
> Mono.Security.Inteace.MonoTlsSettings, Mono.Security, Version=4.0.0.0, 
> Culture=neutral, PublicKeyToken=0738eb9f132ed756) assembly:Mono.Security, 
> Version=4.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 
> typMono.Security.Interface.MonoTlsSettings member:
>  
> Has anyone else come across this and know what the root cause is?
>  
> Thanks,
>  
> Robin
>  
>  
>  
> 
> 
> ___
> This e-mail is confidential and is for the addressee only.   Please refer to 
> www.oxinst.com/email-statement for regulatory information.
> -- 
> ___
> 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] Problems running image in qemu (x86)

[Alex J Lennon]

On 28/08/2017 10:32, Paul Eggleton wrote:
> Hi Alex,
>
> On Sunday, 27 August 2017 1:09:49 AM NZST Alex J Lennon wrote:
>> I'm bringing the Mono build up to date in the meta-mono layer and ran
>> into a problem with my testing.
>>
>> I generally target QEMU, e.g. qemux86, build a core-image-sato based
>> Mono test image and run up with 'runqemu qemux86'
>>
>> It's a remote build system so I am SSH'd in with VNC port forwarding and
>> I view the QEMU box running with a TightVNC client.
>>
>> This has worked well for a long time, and still works fine with the
>> current krogoth branch.
>>
>> I have just built against master though and am seeing screen corruption.
>>
>> e.g. https://postimg.org/image/xjcdybdul
> Yuck :( Would you please file a bug for this? I'm aware we've upgraded qemu 
> recently (I assume this was with the 2.10-rc2 version currently in master?), 
> maybe that has something to do with it.
>

Will do Paul. (I don't suppose you're back over for ELC-E 2017 or FOSDEM
2018 by any chance?)

Cheers,

Alex

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

[yocto] Problems running image in qemu (x86)

[Alex J Lennon]

Hi,

I'm bringing the Mono build up to date in the meta-mono layer and ran
into a problem with my testing.

I generally target QEMU, e.g. qemux86, build a core-image-sato based
Mono test image and run up with 'runqemu qemux86'

It's a remote build system so I am SSH'd in with VNC port forwarding and
I view the QEMU box running with a TightVNC client.

This has worked well for a long time, and still works fine with the
current krogoth branch.

I have just built against master though and am seeing screen corruption.

e.g. https://postimg.org/image/xjcdybdul

Can anybody tell me what's changed?

Thanks,

Alex

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

Re: [yocto] Transaction check error building core-image-mono with pyro

[Alex J Lennon]

On 01/06/2017 15:57, Alex J Lennon wrote:
> Hi,
>
> I'm updating the meta-mono layer with support to build the test
> core-image-mono image under pyro (fine with morty).
>
> It's getting to the point where it starts to create the root
> file-system image then fails with a transaction check error:
>
> ...
>
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> Error: Transaction check error:
>   file /usr/lib/mono conflicts between attempted installs of
> gtk-sharp-2.12.21-r0.i586 and mono-libs-4.5-5.0.1.1-r0.i586
>   file /usr/lib/mono/gac conflicts between attempted installs of
> gtk-sharp-2.12.21-r0.i586 and mono-gac-5.0.1.1-r0.i586
>
> Error Summary
> -
> ...
>
>
> This seems to be suggesting that /usr/lib/mono and /usr/lib/mono/gac
> are files, although they are directories.
>
> I had a look in the logs and the RPMs for gtk-sharp-...
> mono-libs-4.5-... and mono-gac-... but I can't see any obvious file
> conflicts.
>
> Can anybody enlighten me as to what I'm missing?

I made a certain amount of progress with this. I reached out to Zoltan
Boszormenyi who found a workaround. I'm posting snippets of our email
thread here as use of DIRFILES wasn't obvious to me and it perhaps may
help others encountering this type of thing.

...

 "Haven't Pyro replaced the RPM 5.x version with the more Fedora /  Red
Hat / SuSE compatible 4.1x?

I vaguely remember that ownership of identical directories are not 
allowed in two different RPM packages, it would be a problem on  Fedora,
too.

RPM specfiles in Fedora can list empty directories with the %{dir} 
directive (this is what different *filesystem* packages are for in 
Fedora and RHEL/CentOS) but as far as I can see the Bitbake FILES_* 
directives don't make a difference between file patterns and directories.

In Yocto, I only have experience with packaging IPKs. They list all  the
parent directories of a file, too. E.g. for something like this:

FILES_${PN} += "${libdir}/package/somefile.bin"

the resulting IPK will contains these:

./usr
./usr/lib
./usr/lib/package
./usr/lib/package/somefile.bin

When you specify file patterns in an RPM specfile, the resulting RPM
will  only contain the last one, i.e. the file with the full path. Only
this  file will be owned by the RPM. Installing relies on the fact that
the  whole path will be created anyway.

The installation conflict may come from RPM being stricter about
directory  ownership and two packages can only list the same directories
if both  the permissions and the creation date are the same. The latter
would be  identical for two sub-packages of the same recipe but
different for  different packages.

The problem seems to be inherent to how Bitbake creates the list of
packaged files. "

...

"The question is: how can we convince Bitbake to avoid adding
parent directories explicitly into the packages?

I think this is what you need to be aware of (it took me about an hour
to find it):

https://github.com/openembedded/openembedded-core/commit/0e33d232916125ba5305ced7200cc00f8b5f7b22


Presumably, setting DIRFILES="" for gtk-sharp would fix the conflict. "

...

Setting DIRFILES does fix the core-image-mono build for me but I suspect
there's a deeper underlying problem as otherwise many recipes would
surely require this (e.g. just to make use of /etc)

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

[yocto] Transaction check error building core-image-mono with pyro

[Alex J Lennon]

Hi,

I'm updating the meta-mono layer with support to build the test 
core-image-mono image under pyro (fine with morty).


It's getting to the point where it starts to create the root file-system 
image then fails with a transaction check error:


...

Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
  file /usr/lib/mono conflicts between attempted installs of 
gtk-sharp-2.12.21-r0.i586 and mono-libs-4.5-5.0.1.1-r0.i586
  file /usr/lib/mono/gac conflicts between attempted installs of 
gtk-sharp-2.12.21-r0.i586 and mono-gac-5.0.1.1-r0.i586


Error Summary
-
...


This seems to be suggesting that /usr/lib/mono and /usr/lib/mono/gac are 
files, although they are directories.


I had a look in the logs and the RPMs for gtk-sharp-... 
mono-libs-4.5-... and mono-gac-... but I can't see any obvious file 
conflicts.


Can anybody enlighten me as to what I'm missing?

Thanks,

Alex


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

Re: [yocto] [meta-mono][PATCH 0/7] Updates to meta-mono layer

[Alex J Lennon]

On 06/11/2016 04:22, Barry Grussling wrote:
> I have a need to run Mono 4.6.1 on an ARM system.  The last commit to
> the yocto meta-mono tree is over six months old so I figured I would take
> a crack at it myself.  Hopefully these patches help somebody else.

Merged and tested on qemux86. Many thanks Barry
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mono][PATCH] mono-4.xx: Remove --disable-static from EXTRA_OECONF

[Alex J Lennon]

On 27/06/2016 19:41, Fabio Berton wrote:
> Any update on this?
>

Applied, thanks Fabio
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Package mono-libs-4.5 size increase in Mono version 4.4.x

[Alex J Lennon]

On 18/08/2016 03:19, Craig McQueen wrote:
> I wrote:
>> I've just had to upgrade from Mono 4.2.x to Mono 4.4.x, to get a fix for SMTP
>> SSL/TLS.
>>
>> I'm using the mono-libs-4.5 package. I see that the size of it has increased
>> quite a lot (several MB) due to the upgrade. It looks as though it's now
>> putting a bunch of files in /usr/lib/mono/4.5-api in addition to the old
>> /usr/lib/mono/4.5.
>>
>> I can see this mentioned in the Mono 4.4.0 release notes:
>> http://www.mono-project.com/docs/about-mono/releases/4.4.0/
>>
>> But the rationale is not entirely clear to me. Is it possible to cut down the
>> Yocto image size by removing one of /usr/lib/mono/4.5-api and
>> /usr/lib/mono/4.5, or some other refactoring?
> It looks as though, in my image for the device, I only need /usr/lib/mono/4.5.
>
> In my custom layer, I've made a mono_4.4.%.bbappend file which contains:
>
> # Split /usr/lib/mono/4.5-api off into a separate package.
> PACKAGES += "${PN}-libs-4.5-api"
> 
> FILES_${PN}-libs-4.5-api= "${libdir}/mono/4.5-api/*"
> FILES_${PN}-libs-4.5= "${libdir}/mono/4.5/*"
>
> My image includes the package mono-libs-4.5 (as it did before when I was 
> using Mono 4.2.x). Now the image size is back to near what it was for Mono 
> 4.2.x, and everything on the target device seems to be running fine.
>

Thanks Craig. I'll take a look at adding this in

Cheers, Alex

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

Re: [yocto] [meta-mono][PATCH] mono-4.xx: Remove --disable-static from EXTRA_OECONF

[Alex J Lennon]

On 27/06/2016 20:41, Fabio Berton wrote:
> Any update on this?
>
> Without this patch I can't build mono-4.4.0.148.

Hi Fabio - I've been otherwise occupied and only just seen this. I will
take a look at the patch.

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

Re: [yocto] is meta-mono layer actively supported?

[Alex J Lennon]

On 07/07/2016 09:50, Robert P. J. Day wrote:
>   out of nowhere, a client of mine wants to port from WEC7 to linux
> using YP; they already have a working app written in C# .NET and want
> to drag it with them, obviously using mono.
>
>   i see the YP wiki page on running .NET apps here:
>
> https://wiki.yoctoproject.org/wiki/Building_and_running_embedded_Linux_.NET_applications_from_first_principles
>
> which looks like it has the info they need, given that i know
> absolutely *zero* about C#/.NET/mono, but i might as well learn
> something about it.
>
>   the history of that page suggests it's actively supported, can
> anyone confirm that it really does walk one through how to incorporate
> a .NET app in a YP image? given some time this weekend, i'll try to
> follow how to add and run a simple example. thanks.

Hi Robert,

Apologies for the latency. I've been otherwise occupied and have only
just seen this.

Yes, I wrote this piece and the intention is that it does what it says
on the tin - on the basis I have been expecting for some time that
business would be wishing to leverage Mono/Linux for their existing
WinCE codebases.

If you have any issues let me know and I'll be pleased to try to support
you.

Cheers,

Alex

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

Re: [yocto] [meta-mono][PATCH] recipies-mono: fix LIC_FILES_CHKSUM URI

[Alex J Lennon]

On 01/03/2016 10:01, Ioan-Adrian Ratiu wrote:
> Build fails with the following error (caused by a typo s/files/file/):
>
> "Failure expanding variable do_fetch[file-checksums], expression was
> ${@bb.fetch.get_checksum_file_list(d)}  ${@get_lic_checksum_file_list(d)}
> which triggered exception IndexError: string index out of range"
>
> Signed-off-by: Ioan-Adrian Ratiu 
> ---

Applied, thanks Adrian.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mono] Re: ***UNCHECKED*** meta-mono patch

[Alex J Lennon]

On 06/01/2016 20:44, Adam Lussier wrote:
> Alex,
>
> I looked but couldn't find where I might submit a patch for meta-mono.
> Without this patch, mono fails the host-user-contaminated test on
> jethro.  Please let me know if I should send it somewhere else.
>
> Thanks,
> Adam
>

Applied, thanks Adam.

Cheers, Alex


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

Re: [yocto] [meta-mono PATCH] mono-4.xx.inc: Inherit gettext class

[Alex J Lennon]

On 16/12/2015 16:18, Otavio Salvador wrote:
> The mono uses gettext for build, by default, so we ought to ensure it
> is available during the build.
>

Applied. Thanks Otavio.

Cheers, Alex

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

Re: [yocto] [meta-mono][PATCH] README.md: fix mailto links

[Alex J Lennon]

On 23/11/2015 08:25, Roger Meier wrote:
> Signed-off-by: Roger Meier 
> ---
>  README.md | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, Thanks Roger.

Cheers, Alex

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

Re: [yocto] OE/Yocto developer survey

[Alex J Lennon]

On 26/10/2015 19:18, Cliff Brake wrote:
> Hi,
>
> I'd like to get some feedback on the following questions -- feel free
> to respond to list, or directly to me, and I'll withhold your
> name/company from any results.
>
> I would like to collect feedback until 2015-11-02, and will summarize
> the results after that.
>
> My goal with this survey is to get a sense for best practices and what
> is most commonly used among Yocto/OE developers so I can better advise
> clients using Yocto/OE.  Hopefully this will also generate some
> interesting discussions.
>
> How long have you been using OE?  _
>
> How do you use OE/Yocto?
> [X ] product development
> [X ] hobby/research/education/yocto core developer, etc
>
> What distro do you use?
> [X ] Poky
> [  ] Angstrom
> [  ] nodistro or custom
>
> How do you organize multiple git repos?
> [  ] Git submodules
> [  ] Repo
> [X ] Other
>
> What packaging system?
> [  ] OPKG
> [X ] RPM
> [X ] Other
>
> What GUI toolkits?
> [  ] Qt
> [  ] Gtk
> [  ] EFL
> [X ] HTML5/JS
> [X ] Other
>
> What init system?
> [  ] systemd
> [X ] sysvinit
> [  ] busybox init
> [  ] Other
>
> What libc?
> [X ] glibc
> [  ] uclibc
> [  ] musl
> [  ] Other
>
> How do you develop custom applications?
> [  ] application-SDK
> [X ] devshell
> [X ] develop on PC, test on target
> [X ] Other
>
> What language do you primarily use for custom applications?
> [X ] C
> [  ] C++
> [  ] Python
> [  ] Javascript
> [  ] Lua
> [X ] Other
>

Visual Studio C# .NET + Mono

> What do you use for Continuous Integration?
> [  ] Buildbot
> [  ] Jenkins
> [X ] Other
>
> Do you use any any of the tooling projects
> (https://www.yoctoproject.org/tools-resources/projects) such as ADT,
> Hob, Toaster, etc?

No

> ___
>
> Reasons or explanations are appreciated, and please feel free to
> include additional choices/information you think are relevant.
>
> Thanks,
> Cliff

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

Re: [yocto] [meta-chip] Yocto on the 9$ computer

[Alex J Lennon]

On 24/10/2015 22:06, Andrei Gherzan wrote:
> On Sat, Oct 24, 2015 at 09:46:41PM +0100, Alex J Lennon wrote:
>>
>>
>>
>> Sent from my iPhone
>>>> On 24 Oct 2015, at 21:13, Andrei Gherzan  wrote:
>>>>
>>>>> On Sat, Oct 24, 2015 at 09:58:42PM +0200, Nicolas Aguirre wrote:
>>>>> 2015-10-24 19:26 GMT+02:00 Andrei Gherzan :
>>>>> Hi all,
>>>> Hi Andrei,
>>>>
>>>>> Have a C.H.I.P. 9$ computer? It works with Yocto now.
>>>>>
>>>>> http://layers.openembedded.org/layerindex/branch/master/layer/meta-chip/
>>>> Good job.
>>>> IMO it make sense to add C.H.I.P support in meta-sunxi, don't you think ?
>>>>
>>>> https://github.com/linux-sunxi/meta-sunxi
>>> Well. Temporary it is a separate layer. And this is mainly because of the
>>> overhead you need for flashing the board. So I do see a benefit in keeping 
>>> it
>>> separately. We will see in time.
>>>
>>> Thanks for feedback.
>> Great work Andrei. I have a couple of CHiPs here and was trying to decide 
>> whether meta-sunxi would provide what was needed or whether we needed a 
>> custom layer.
>>
>> I've been hugely impressed with what Docker+Resin gives me for application 
>> deployment management so I'd like to look at how easy it is to take your 
>> Linux/u-boot CHiP support and deploy via Resin.
>>
>> Are you at the point you have a base OS image for CHiP with Resin support? 
>> If not I would be interested in having a look at this with you.
>>
> We definitely thought about that already. The problem is that we currently 
> rely
> on a BTRFS partition for the docker runtime environment. This obviously won't
> work on a flash raw device. So if you want to dig into this I can give you 
> some
> hints, otherwise we will just tackle it when we will get to it.
>
>

Are you making use of any BTRFS specific features or should be it fairly
straightforward to use JFFS2 or similar?

Presumably BTRFS will sit happily on other devices with eMMC?

Best, Alex

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

Re: [yocto] [meta-chip] Yocto on the 9$ computer

[Alex J Lennon]

Sent from my iPhone
>> On 24 Oct 2015, at 21:13, Andrei Gherzan  wrote:
>> 
>>> On Sat, Oct 24, 2015 at 09:58:42PM +0200, Nicolas Aguirre wrote:
>>> 2015-10-24 19:26 GMT+02:00 Andrei Gherzan :
>>> Hi all,
>> 
>> Hi Andrei,
>> 
>>> Have a C.H.I.P. 9$ computer? It works with Yocto now.
>>> 
>>> http://layers.openembedded.org/layerindex/branch/master/layer/meta-chip/
>> Good job.
>> IMO it make sense to add C.H.I.P support in meta-sunxi, don't you think ?
>> 
>> https://github.com/linux-sunxi/meta-sunxi
> 
> Well. Temporary it is a separate layer. And this is mainly because of the
> overhead you need for flashing the board. So I do see a benefit in keeping it
> separately. We will see in time.
> 
> Thanks for feedback.

Great work Andrei. I have a couple of CHiPs here and was trying to decide 
whether meta-sunxi would provide what was needed or whether we needed a custom 
layer.

I've been hugely impressed with what Docker+Resin gives me for application 
deployment management so I'd like to look at how easy it is to take your 
Linux/u-boot CHiP support and deploy via Resin. 

Are you at the point you have a base OS image for CHiP with Resin support? If 
not I would be interested in having a look at this with you.

Cheers,

Alex

> --
> Andrei Gherzan
> -- 
> ___
> 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] README: Add section on audio routing

[Alex J Lennon]

See http://redmine.gherzan.com/issues/55

Signed-off-by: Alex J Lennon 
---
 README | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/README b/README
index e32de3a..e16dee9 100644
--- a/README
+++ b/README
@@ -199,8 +199,34 @@ able to compile omxplayer you will need to whiteflag the 
commercial license
 adding to you local.conf:
 LICENSE_FLAGS_WHITELIST = "commercial"
 
+4. Board Configuration
+==
 
-4. Source code and mirrors
+4.A. Audio Routing
+==
+To load audio driver
+
+modprobe snd-bcm2835
+
+To test audio playback
+
+e.g. aplay test.wav
+
+Note that without HDMI connected this emits audio from the 3.5in jack connector
+as expected. However With an HDMI display connected there is no audio output 
from
+the jack connector.
+
+To force the audio routing via the 3.5in jack connector use
+
+amixer cset numid=3 1
+
+Options to amixer cset are:
+
+0=auto
+1=headphones
+2=hdmi
+
+5. Source code and mirrors
 ==
 
 Main repo:
@@ -214,10 +240,10 @@ Bitbucket mirror:
 https://bitbucket.org/agherzan/meta-raspberrypi
 
 
-5. Contributing
+6. Contributing
 ===
 
-5.A. Mailing list
+6.A. Mailing list
 =
 The main communication tool we use is a mailing list:
 yocto@yoctoproject.org
@@ -241,7 +267,7 @@ When sending patches to mailing list, please use something 
like:
 
 git send-email --to yocto@yoctoproject.org 
 
-5.B. Redmine
+6.B. Redmine
 
 In order to manage and trace the meta-raspberrypi issues, we use redmine:
 http://redmine.gherzan.ro/projects/meta-raspberrypi
@@ -255,7 +281,7 @@ for a bug:
 [Bug #13]
 
 
-6. Maintainers
+7. Maintainers
 ==
 
 Andrei Gherzan 
-- 
1.9.1

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

[yocto] [meta-raspberrypi][PATCH v2] linux-raspberrypi: support configuration fragments / in-tree defconfig

[Alex J Lennon]

Synopsis


Start using Yocto kernel configuration fragments[0] and the "in-tree
defconfig" solution provided in poky[1].

To specify an "in-tree" defconfig file, you may edit the recipe that
builds your kernel so that it has the following command form:

 KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file

You need to append the variable with KMACHINE and then supply the
path to your "in-tree" defconfig file.

In order to achieve this meta-raspberrypi needs to:

- start using KBUILD_DEFCONFIG_KMACHINE
- remove placeholder defconfig and custom copying logic.
- avoid replacing all Yocto project configured settings in
  do_configure_prepend.

In many cases it should not be necessary to change the defconfig
file used.

Instead Yocto supports use of kernel configuration fragment files
to override the in-tree defconfig defaults[0].

For more background regarding this migration read the bugzilla bug
info[2].

[0] - 
http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#changing-the-configuration
[1] - 
http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
[2] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474

Testing
===

Poky master (#6d8ace03) core-image-sato with MACHINE=raspberrypi2

Kernels 3.18.16 / 4.1.10

(1) with no fragment files defined, using in-tree defconfig, kernels/images
build and boot without error.

- build host kernel .config file contains CONFIG_SND_BCM2835=m.
- post boot, target aplay -l reports no sound devices until module is
  loaded.
- post modprobe, target aplay -l reports sound device.

(2) adding a test configuration fragment to build sound driver
into the kernel.

- build host kernel .config file contains CONFIG_SND_BCM2835=y.
- post boot, target aplay -l reports sound device with no modprobe
  step.

Note: It may be necessary to clean sstate for the kernel after adding
  a new configuration fragment to the SRC_URI, e.g.

  bitbake -c cleansstate virtual/kernel

Sample Fragment Implementation
==

linux-raspberrypi.inc:

+SRC_URI += " \
+file://build-in-audio.cfg \
+"

linux-raspberrypi/build-in-audio.cfg:

+CONFIG_SND=y
+CONFIG_SND_BCM2835=y

Signed-off-by: Alex J Lennon 
---
 recipes-kernel/linux/linux-raspberrypi.inc   | 12 
 recipes-kernel/linux/linux-raspberrypi/defconfig |  1 -
 recipes-kernel/linux/linux.inc   |  7 +++
 3 files changed, 7 insertions(+), 13 deletions(-)
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi/defconfig

diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
b/recipes-kernel/linux/linux-raspberrypi.inc
index 70e8bfe..d3766c4 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -6,10 +6,6 @@ SECTION = "kernel"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
 
-SRC_URI += " \
-file://defconfig \
-"
-
 COMPATIBLE_MACHINE = "raspberrypi"
 
 PE = "1"
@@ -18,6 +14,10 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 # NOTE: For now we pull in the default config from the RPi kernel GIT tree.
 KERNEL_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
 KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
+KMACHINE ?= "${MACHINE}"
+KCONFIG_MODE = "--alldefconfig"
+KBUILD_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
+KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
 
 # CMDLINE for raspberrypi
 CMDLINE = "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 root=/dev/mmcblk0p2 
rootfstype=ext4 rootwait"
@@ -42,10 +42,6 @@ python __anonymous () {
 d.setVar("DEPENDS", depends)
 }
 
-do_kernel_configme_prepend() {
-install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} 
${WORKDIR}/defconfig || die "No default configuration for ${MACHINE} / 
${KERNEL_DEFCONFIG} available."
-}
-
 do_install_prepend() {
 install -d ${D}/lib/firmware
 }
diff --git a/recipes-kernel/linux/linux-raspberrypi/defconfig 
b/recipes-kernel/linux/linux-raspberrypi/defconfig
deleted file mode 100644
index ecbf32c..000
--- a/recipes-kernel/linux/linux-raspberrypi/defconfig
+++ /dev/null
@@ -1 +0,0 @@
-# Dummy file to get through do_kernel_configme.
diff --git a/recipes-kernel/linux/linux.inc b/recipes-kernel/linux/linux.inc
index fae78b7..7ed80af 100644
--- a/recipes-kernel/linux/linux.inc
+++ b/recipes-kernel/linux/linux.inc
@@ -33,8 +33,7 @@ kernel_configure_variable() {
 }
 
 do_configure_prepend() {
-# Clean .config
-echo "" > ${B}/.config
+mv -f ${B}/.config ${B}/.config.patched
 CONF_SED_SCRIPT=""
 
 # oabi / eabi support
@@ -109,8 +108,8 @@ do_configure_prepend() {
 
 # Keep this the last line
 # Remove all modified configs and add the rest to .conf

[yocto] [meta-raspberrypi][PATCH 2/2] libepoxy: add needed include paths for RPi

[Alex J Lennon]

ref: https://github.com/raspberrypi/firmware/issues/34

Signed-off-by: Alex J Lennon 
---
 recipes-graphics/libepoxy/libepoxy_git.bbappend | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 recipes-graphics/libepoxy/libepoxy_git.bbappend

diff --git a/recipes-graphics/libepoxy/libepoxy_git.bbappend 
b/recipes-graphics/libepoxy/libepoxy_git.bbappend
new file mode 100644
index 000..e6a428c
--- /dev/null
+++ b/recipes-graphics/libepoxy/libepoxy_git.bbappend
@@ -0,0 +1,2 @@
+EXTRA_OECONF_append_raspberrypi = " 
CPPFLAGS='-I${STAGING_DIR_TARGET}/usr/include/interface/vcos/pthreads'"
+EXTRA_OECONF_append_raspberrypi2 = " 
CPPFLAGS='-I${STAGING_DIR_TARGET}/usr/include/interface/vcos/pthreads'"
-- 
1.9.1

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

[yocto] [meta-raspberrypi][PATCH 1/2] userland: add .pc files for the OpenGLESv2 and EGL libraries

[Alex J Lennon]

These pkg-config files make it easier for libepoxy to find
those libraries and the appropriate link flags.

Modified from Thomas Petazzoni's patch here: http://goo.gl/jdz7lO

Signed-off-by: Alex J Lennon 
---
 .../0004-rpi-userland-add-pkgconfig-files.patch| 53 ++
 recipes-graphics/userland/userland_git.bb  |  6 ++-
 2 files changed, 57 insertions(+), 2 deletions(-)
 create mode 100644 
recipes-graphics/userland/userland/0004-rpi-userland-add-pkgconfig-files.patch

diff --git 
a/recipes-graphics/userland/userland/0004-rpi-userland-add-pkgconfig-files.patch
 
b/recipes-graphics/userland/userland/0004-rpi-userland-add-pkgconfig-files.patch
new file mode 100644
index 000..2d454a4
--- /dev/null
+++ 
b/recipes-graphics/userland/userland/0004-rpi-userland-add-pkgconfig-files.patch
@@ -0,0 +1,53 @@
+Add .pc files for the OpenGLESv2 and EGL libraries
+
+Those pkg-config files make it easier for Qt5 to find those libraries
+and the appropriate link flags.
+
+(Modified to apply to userland by Alex J Lennon)
+
+Signed-off-by: Thomas Petazzoni 
+Signed-off-by: Alex J Lennon 
+
+diff -urN git.org/interface/khronos/CMakeLists.txt 
git/interface/khronos/CMakeLists.txt
+--- git.org/interface/khronos/CMakeLists.txt   2015-10-22 11:51:22.616445270 
+0100
 git/interface/khronos/CMakeLists.txt   2015-10-22 11:55:32.024448754 
+0100
+@@ -74,3 +74,11 @@
+ 
+ install(TARGETS EGL GLESv2 OpenVG WFC khrn_client DESTINATION lib)
+ install(TARGETS EGL_static GLESv2_static khrn_static DESTINATION lib)
++configure_file("${CMAKE_CURRENT_SOURCE_DIR}/egl/egl.pc.in"
++  "${CMAKE_CURRENT_BINARY_DIR}/egl/egl.pc" @ONLY)
++install(FILES "${CMAKE_CURRENT_BINARY_DIR}/egl/egl.pc"
++  DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/pkgconfig")
++configure_file("${CMAKE_CURRENT_SOURCE_DIR}/glxx/glesv2.pc.in"
++  "${CMAKE_CURRENT_BINARY_DIR}/glxx/glesv2.pc" @ONLY)
++install(FILES "${CMAKE_CURRENT_BINARY_DIR}/glxx/glesv2.pc"
++  DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/pkgconfig")
+diff -urN git.org/interface/khronos/egl/egl.pc.in 
git/interface/khronos/egl/egl.pc.in
+--- git.org/interface/khronos/egl/egl.pc.in1970-01-01 01:00:00.0 
+0100
 git/interface/khronos/egl/egl.pc.in2015-10-22 11:54:25.724447827 
+0100
+@@ -0,0 +1,10 @@
++prefix=@CMAKE_INSTALL_PREFIX@
++exec_prefix=${prefix}
++libdir=${exec_prefix}/lib
++includedir=${prefix}/include
++
++Name: egl
++Description: RasberryPi implementation of EGL
++Version: 1.0
++Libs: -L${libdir} -lEGL -lGLESv2
++Cflags: -I${includedir}/ -I${includedir}/interface/vcos/pthreads/
+diff -urN git.org/interface/khronos/glxx/glesv2.pc.in 
git/interface/khronos/glxx/glesv2.pc.in
+--- git.org/interface/khronos/glxx/glesv2.pc.in1970-01-01 
01:00:00.0 +0100
 git/interface/khronos/glxx/glesv2.pc.in2015-10-22 11:54:50.248448170 
+0100
+@@ -0,0 +1,10 @@
++prefix=@CMAKE_INSTALL_PREFIX@
++exec_prefix=${prefix}
++libdir=${exec_prefix}/lib
++includedir=${prefix}/include
++
++Name: glesv2
++Description: RasberryPi implementation of OpenGL ESv2
++Version: 2.0
++Libs: -L${libdir} -lGLESv2
++Cflags: -I${includedir}/
diff --git a/recipes-graphics/userland/userland_git.bb 
b/recipes-graphics/userland/userland_git.bb
index 896229e..46ae2c2 100644
--- a/recipes-graphics/userland/userland_git.bb
+++ b/recipes-graphics/userland/userland_git.bb
@@ -21,11 +21,12 @@ SRC_URI = "\
 file://0001-fix-gcc-5.x-inlines.patch \
 file://0002-fix-musl-build.patch \
 file://0003-fix-alloc-size-uninitialized.patch \
+file://0004-rpi-userland-add-pkgconfig-files.patch \
 "
 
 S = "${WORKDIR}/git"
 
-inherit cmake
+inherit cmake pkgconfig
 
 EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release 
-DCMAKE_EXE_LINKER_FLAGS='-Wl,--no-as-needed'"
 CFLAGS_append = " -fPIC"
@@ -43,7 +44,8 @@ FILES_${PN} += " \
 ${libdir}/*${SOLIBS} \
 ${libdir}/plugins"
 FILES_${PN}-dev = "${includedir} \
-   ${prefix}/src"
+   ${prefix}/src \
+   ${libdir}/pkgconfig/*.pc"
 FILES_${PN}-doc += "${datadir}/install"
 FILES_${PN}-dbg += "${libdir}/plugins/.debug"
 
-- 
1.9.1

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

[yocto] [meta-raspberrypi][PATCH 0/2] Fix core-image-sato build failure

[Alex J Lennon]

Builds of core-image-sato (userland) against poky master fail as
libepoxy fails to build. This patch-set adds needed userland .pc files 
for libepoxy and adds needed paths for include files to the libepoxy recipe

Alex J Lennon (2):
  userland: add .pc files for the OpenGLESv2 and EGL libraries
  libepoxy: add needed include paths for RPi

 recipes-graphics/libepoxy/libepoxy_git.bbappend|  2 +
 .../0004-rpi-userland-add-pkgconfig-files.patch| 53 ++
 recipes-graphics/userland/userland_git.bb  |  6 ++-
 3 files changed, 59 insertions(+), 2 deletions(-)
 create mode 100644 recipes-graphics/libepoxy/libepoxy_git.bbappend
 create mode 100644 
recipes-graphics/userland/userland/0004-rpi-userland-add-pkgconfig-files.patch

-- 
1.9.1

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

Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

[Alex J Lennon]

On 21/10/2015 13:12, Andrei Gherzan wrote:
> On Tue, Aug 25, 2015 at 09:00:06AM +0100, Alex J Lennon wrote:
>> On 25/08/2015 07:57, Petter Mabäcker wrote:
>>>
>>>
>>> 2015-08-17 11:23 skrev Alex J Lennon:
>>>
>>>> On 17/08/2015 09:11, Petter Mabäcker wrote:
>>>>> 2015-08-17 09:57 skrev Andrei Gherzan:
>>>>>> Hello, On Tuesday, August 11, 2015, Petter Mabäcker
>>>>>> mailto:pet...@technux.se>
>>>>>> <mailto:pet...@technux.se <mailto:pet...@technux.se>>> wrote:
>>>>>> 2015-08-11 19:04 skrev Alex J Lennon: Signed-off-by: Alex J Lennon
>>>>>> >>>>> <mailto:ajlen...@dynamicdevices.co.uk>> ---
>>>>>> recipes-kernel/linux/linux-raspberrypi.inc | 4  1 file changed,
>>>>>> 4 insertions(+) diff --git
>>>>>> a/recipes-kernel/linux/linux-raspberrypi.inc
>>>>>> b/recipes-kernel/linux/linux-raspberrypi.inc index e38d905..8024412
>>>>>> 100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
>>>>>> b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,6 +6,10 @@
>>>>>> SECTION = "kernel" LICENSE = "GPLv2" LIC_FILES_CHKSUM =
>>>>>> "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" +SRC_URI += "
>>>>>> \ + file://build-in-audio.cfg \ + " This one didn't make it. --
>>>>>> Andrei Gherzan -- -- Andrei Gherzan
>>>>> Think you got the wrong receiver =) I notified Alex about this some
>>>>> days ago, Alex can you send up a v2 for this?
>>>> The build-in-audio.cfg patch was just for testing of fragment support.
>>>> It's understood that we're not going to have this build into the kernel
>>>> by default, although I do still need to find some words to add to the
>>>> README on audio routing setup and so forth.
>>>>
>>>> I started testing a build with master over the weekend and it built OK.
>>>> Just need to find some time to run up a couple of kernels and will
>>>> resubmit the v2 patch with Petter's enhanced commit message.
>>>>
>>>> I don't have an RPiv1 around at the moment but I will probably double
>>>> check the kernel does still actually build for RPiv1 machine
>>>>
>>>> Cheers,
>>>>
>>>> Alex
>>>>> BR, Petter
>>>
>>> Hi Alex, Any news for the v2 changeset? Would be awesome to get the 4.x
>>> integrated soon.
>>>
>>
>> Hi, yeah I got a little sidetracked I'm afraid. Turns out
>> core-image-sato isn't building in master any more due to a new
>> dependency on libexpoxy which in turn requires EGL.
>>
>> Anyway, so I did successfully build 4.x and 3.x kernels for RPiv2 in an
>> rpi-xxx-image. I just didn't get around to running them up although I
>> see no reason to think they won't.
>>
>> I'll try to take a look at this, as I like you would like this signed off :)
>>
>> Cheers, Alex
>>
> 
> Any chances this is still coming soon?
> 
> --
> Andrei Gherzan
> 

Yes I'd like to wrap this up too. Can we take a step back first and
revisit the earlier patch-set to update to 3.8.16 and add support for
4.1.3 kernels first? If so I'll try to test with what seems to be the
latest long term kernels on kernel.org, 3.8.22 and 4.1.10.

With that in place I can then add the kernel fragment support on top.
(And then start looking into Dockerification which looks intriguing... ;)

How does that sound?

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

Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

[Alex J Lennon]

On 21/10/2015 13:12, Andrei Gherzan wrote:
> On Tue, Aug 25, 2015 at 09:00:06AM +0100, Alex J Lennon wrote:
>> On 25/08/2015 07:57, Petter Mabäcker wrote:
>>>
>>>
>>> 2015-08-17 11:23 skrev Alex J Lennon:
>>>
>>>> On 17/08/2015 09:11, Petter Mabäcker wrote:
>>>>> 2015-08-17 09:57 skrev Andrei Gherzan:
>>>>>> Hello, On Tuesday, August 11, 2015, Petter Mabäcker
>>>>>> mailto:pet...@technux.se>
>>>>>> <mailto:pet...@technux.se <mailto:pet...@technux.se>>> wrote:
>>>>>> 2015-08-11 19:04 skrev Alex J Lennon: Signed-off-by: Alex J Lennon
>>>>>> >>>>> <mailto:ajlen...@dynamicdevices.co.uk>> ---
>>>>>> recipes-kernel/linux/linux-raspberrypi.inc | 4  1 file changed,
>>>>>> 4 insertions(+) diff --git
>>>>>> a/recipes-kernel/linux/linux-raspberrypi.inc
>>>>>> b/recipes-kernel/linux/linux-raspberrypi.inc index e38d905..8024412
>>>>>> 100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
>>>>>> b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,6 +6,10 @@
>>>>>> SECTION = "kernel" LICENSE = "GPLv2" LIC_FILES_CHKSUM =
>>>>>> "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" +SRC_URI += "
>>>>>> \ + file://build-in-audio.cfg \ + " This one didn't make it. --
>>>>>> Andrei Gherzan -- -- Andrei Gherzan
>>>>> Think you got the wrong receiver =) I notified Alex about this some
>>>>> days ago, Alex can you send up a v2 for this?
>>>> The build-in-audio.cfg patch was just for testing of fragment support.
>>>> It's understood that we're not going to have this build into the kernel
>>>> by default, although I do still need to find some words to add to the
>>>> README on audio routing setup and so forth.
>>>>
>>>> I started testing a build with master over the weekend and it built OK.
>>>> Just need to find some time to run up a couple of kernels and will
>>>> resubmit the v2 patch with Petter's enhanced commit message.
>>>>
>>>> I don't have an RPiv1 around at the moment but I will probably double
>>>> check the kernel does still actually build for RPiv1 machine
>>>>
>>>> Cheers,
>>>>
>>>> Alex
>>>>> BR, Petter
>>>
>>> Hi Alex, Any news for the v2 changeset? Would be awesome to get the 4.x
>>> integrated soon.
>>>
>>
>> Hi, yeah I got a little sidetracked I'm afraid. Turns out
>> core-image-sato isn't building in master any more due to a new
>> dependency on libexpoxy which in turn requires EGL.
>>
>> Anyway, so I did successfully build 4.x and 3.x kernels for RPiv2 in an
>> rpi-xxx-image. I just didn't get around to running them up although I
>> see no reason to think they won't.
>>
>> I'll try to take a look at this, as I like you would like this signed off :)
>>
>> Cheers, Alex
>>
> 
> Any chances this is still coming soon?
> 
> --
> Andrei Gherzan
> 

Yes I'd like to wrap this up too. Can we take a step back first and
revisit the earlier patch-set to update to 3.8.16 and add support for
4.1.3 kernels first? If so I'll try to test with what seems to be the
latest long term kernels on kernel.org, 3.8.22 and 4.1.10.

With that in place I can then add the kernel fragment support on top.
(And then start looking into Dockerification which looks intriguing... ;)

How does that sound?

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

Re: [yocto] meta-raspberrypi no soud output

[Alex J Lennon]

On 15/10/2015 16:57, Edward Vidal wrote:
> Hello All,
> Does any have snd working on Raspberry Pi 2B?
>
> I have tried aplay speech_dft.wav
> PLAYING WAVE: 'speech_dft.wav' :  Signed 16 bit Little Endian, rate
> 22050 Hz Mono
> with ear plugs or speaker no snd.
> Any and all help appreciated.
>

Some notes here on routing Edward,

http://redmine.gherzan.ro/issues/55

Best, Alex

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

Re: [yocto] can any one please tell the difference between DEPENDS and RDEPENDS

[Alex J Lennon]

On 07/10/2015 07:10, Vivek Per wrote:
> Hi,
>  Can any one please tell the what is the exact difference between
> DEPENDS and RDEPENDS . I am not able to get it . How these variables
> are exactly parsed.
>
>

Vivek - does this help ?

https://lists.yoctoproject.org/pipermail/yocto/2013-August/015783.html

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

Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

[Alex J Lennon]

On 25/08/2015 07:57, Petter Mabäcker wrote:
>  
> 
> 2015-08-17 11:23 skrev Alex J Lennon:
> 
>> On 17/08/2015 09:11, Petter Mabäcker wrote:
>>> 2015-08-17 09:57 skrev Andrei Gherzan:
>>>> Hello, On Tuesday, August 11, 2015, Petter Mabäcker
>>>> mailto:pet...@technux.se>
>>>> <mailto:pet...@technux.se <mailto:pet...@technux.se>>> wrote:
>>>> 2015-08-11 19:04 skrev Alex J Lennon: Signed-off-by: Alex J Lennon
>>>> >>> <mailto:ajlen...@dynamicdevices.co.uk>> ---
>>>> recipes-kernel/linux/linux-raspberrypi.inc | 4  1 file changed,
>>>> 4 insertions(+) diff --git
>>>> a/recipes-kernel/linux/linux-raspberrypi.inc
>>>> b/recipes-kernel/linux/linux-raspberrypi.inc index e38d905..8024412
>>>> 100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
>>>> b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,6 +6,10 @@
>>>> SECTION = "kernel" LICENSE = "GPLv2" LIC_FILES_CHKSUM =
>>>> "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" +SRC_URI += "
>>>> \ + file://build-in-audio.cfg \ + " This one didn't make it. --
>>>> Andrei Gherzan -- -- Andrei Gherzan
>>> Think you got the wrong receiver =) I notified Alex about this some
>>> days ago, Alex can you send up a v2 for this?
>> The build-in-audio.cfg patch was just for testing of fragment support.
>> It's understood that we're not going to have this build into the kernel
>> by default, although I do still need to find some words to add to the
>> README on audio routing setup and so forth.
>>
>> I started testing a build with master over the weekend and it built OK.
>> Just need to find some time to run up a couple of kernels and will
>> resubmit the v2 patch with Petter's enhanced commit message.
>>
>> I don't have an RPiv1 around at the moment but I will probably double
>> check the kernel does still actually build for RPiv1 machine
>>
>> Cheers,
>>
>> Alex
>>> BR, Petter
> 
> Hi Alex, Any news for the v2 changeset? Would be awesome to get the 4.x
> integrated soon.
>

Hi, yeah I got a little sidetracked I'm afraid. Turns out
core-image-sato isn't building in master any more due to a new
dependency on libexpoxy which in turn requires EGL.

Anyway, so I did successfully build 4.x and 3.x kernels for RPiv2 in an
rpi-xxx-image. I just didn't get around to running them up although I
see no reason to think they won't.

I'll try to take a look at this, as I like you would like this signed off :)

Cheers, Alex

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

[yocto] Issue with init scripts start-stop-daemon and use of set -e ?

[Alex J Lennon]

Hi,

I've been trying to track down an issue I was seeing with ofono not
restarting on a fido image and have encountered what seems to be an
issue related to the sys v init script.

Sometimes when we make a call as follows the ofono daemon isn't started
correctly

/etc/init.d/ofono restart

It seems there's a "set -e" in there to cause the script to exit if a
command returns a non-zero.

When the do_stop() function is called from restart if the daemon isn't
already running busybox will return non-zero which causes the script to
drop out and the do_start() method is never called.

(I have yet to determine why the ofono daemon might not be running
already when we make the call but that's a separate problem...)

Given the expected behaviour of calling restart on a service is to start
it even if it was not running then perhaps the "set -e" needs to be
removed or || true added ?

This seems relevant to ofono in master, and some quick grepping of
init.d shows other scripts are similar.

Can anybody comment?

Thanks,

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

Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

[Alex J Lennon]

On 17/08/2015 09:11, Petter Mabäcker wrote:
> 2015-08-17 09:57 skrev Andrei Gherzan:
> 
>> Hello,
>>
>> On Tuesday, August 11, 2015, Petter Mabäcker > <mailto:pet...@technux.se>> wrote:
>>
>> 2015-08-11 19:04 skrev Alex J Lennon:
>>
>> Signed-off-by: Alex J Lennon 
>> ---
>>  recipes-kernel/linux/linux-raspberrypi.inc | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
>> b/recipes-kernel/linux/linux-raspberrypi.inc
>> index e38d905..8024412 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>> @@ -6,6 +6,10 @@ SECTION = "kernel"
>>  LICENSE = "GPLv2"
>>  LIC_FILES_CHKSUM = 
>> "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>>  
>> +SRC_URI += " \
>> +file://build-in-audio.cfg \
>> +"
>>
>>  
>> This one didn't make it.
>>  
>>  
>>  
>>  
>> --
>> Andrei Gherzan
>>
>>
>> -- 
>> --
>> Andrei Gherzan
> 
> Think you got the wrong receiver =) I notified Alex about this some days
> ago, Alex can you send up a v2 for this?
> 
>

The build-in-audio.cfg patch was just for testing of fragment support.
It's understood that we're not going to have this build into the kernel
by default, although I do still need to find some words to add to the
README on audio routing setup and so forth.

I started testing a build with master over the weekend and it built OK.
Just need to find some time to run up a couple of kernels and will
resubmit the v2 patch with Petter's enhanced commit message.

I don't have an RPiv1 around at the moment but I will probably double
check the kernel does still actually build for RPiv1 machine

Cheers,

Alex


> 
> BR, Petter
> 

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

Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

[Alex J Lennon]

On 17/08/2015 09:11, Petter Mabäcker wrote:
> 2015-08-17 09:57 skrev Andrei Gherzan:
> 
>> Hello,
>>
>> On Tuesday, August 11, 2015, Petter Mabäcker > <mailto:pet...@technux.se>> wrote:
>>
>> 2015-08-11 19:04 skrev Alex J Lennon:
>>
>> Signed-off-by: Alex J Lennon 
>> ---
>>  recipes-kernel/linux/linux-raspberrypi.inc | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
>> b/recipes-kernel/linux/linux-raspberrypi.inc
>> index e38d905..8024412 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>> @@ -6,6 +6,10 @@ SECTION = "kernel"
>>  LICENSE = "GPLv2"
>>  LIC_FILES_CHKSUM = 
>> "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>>  
>> +SRC_URI += " \
>> +file://build-in-audio.cfg \
>> +"
>>
>>  
>> This one didn't make it.
>>  
>>  
>>  
>>  
>> --
>> Andrei Gherzan
>>
>>
>> -- 
>> --
>> Andrei Gherzan
> 
> Think you got the wrong receiver =) I notified Alex about this some days
> ago, Alex can you send up a v2 for this?
> 
>

The build-in-audio.cfg patch was just for testing of fragment support.
It's understood that we're not going to have this build into the kernel
by default, although I do still need to find some words to add to the
README on audio routing setup and so forth.

I started testing a build with master over the weekend and it built OK.
Just need to find some time to run up a couple of kernels and will
resubmit the v2 patch with Petter's enhanced commit message.

I don't have an RPiv1 around at the moment but I will probably double
check the kernel does still actually build for RPiv1 machine

Cheers,

Alex


> 
> BR, Petter
> 

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

Re: [yocto] [meta-raspberrypi] RFC on choice of tool for patch review

[Alex J Lennon]

On 12/08/2015 10:45, Joshua Lock wrote:
> On Wed, 2015-08-12 at 10:25 +0100, Joshua Lock wrote:
>> On Wed, 2015-08-12 at 10:17 +0100, Alex J Lennon wrote:
>>> We've been having a discussion on a way forward to manage patches 
>>> and
>>> code review and would like to open this up for discussion to agree 
>>> a 
>>> way
>>> forward.
>> There's http://patchwork.openembedded.org/. I'm not sure who 
>> maintains
>> it, nor if anyone uses it, but patches sent to the mailing list end 
>> up
>> there.
>>
>> OOI who are "we" in this context? What benefits would a change bring?
> I managed to miss both the [yocto] and [meta-raspberrypi] tags on this
> mail, apologies for that. I guess that "we" are the meta-raspberrypi
> maintainers.

Yes :)

Andrei (maintainer) was using Gerrit but that went away for reasons
outlined in the preceding email.

Some visibility and control of the review process has been lost as a
result and so it was suggested we kick off a conversation on what
tooling to use to restore that.

> Still, the patchwork instance may be an option? The meta-freescale
> layers appear to be using it.

Many thanks!

Cheers,

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

[yocto] [meta-raspberrypi] RFC on choice of tool for patch review

[Alex J Lennon]

We've been having a discussion on a way forward to manage patches and
code review and would like to open this up for discussion to agree a way
forward.

Options appear to be github, gerrit, or bitbucket although there may be
others. This is in addition to continuing to send patches to the mailing
list.

Quote from Andrei,

"We dropped gerrit because at that time google dropped the support for
loging in with their accounts and gerrit didn't support OAUTH. The only
options left were involving me maintaining users / groups / permissions
etc - which obviously didn't have the time for. So, at that time, we
decided to use mailing list as the only way of patches review.

Now, I work with github, bitbucket and gerrit and I definitely, as Alex
said, feel the need of reviewing patches using a tool like these. But I
want to state the fact that, even if we decide using them, we will still
need to send patches to mailing list too - so we can keep the awareness
of this project. In terms of preference, I don't really have one. The
easiest would be github/bitbucket but I can invest some time in
installing gerrit back (as they now have the required support for google
accounts logins). So, I consider this is a community decision and, if a
have to vote, I would go for github."

Quote from Petter,

"About using github and similar, I'm a huge fan of gerrit [...] Gerrit
is really nice for reviewing and working closely together with similar
changesets that are ongoing.."

...

For my five euro-cents, I have used Gerrit a little and GitHub more. I
found Gerrit hard to get to grips with, but have been impressed with
GitHub.

So my own preference would be to use github as the UI and
fork/pull-req/commenting support all seems very accessible and intuitive.

Can others comment?

Thanks,

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

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: support configuration fragments

[Alex J Lennon]

On 12/08/2015 09:08, Petter Mabäcker wrote:
> 2015-08-11 21:20 skrev Alex J Lennon:
> 
>> On 11/08/2015 19:54, Petter Mabäcker wrote:
>>> 2015-08-11 19:04 skrev Alex J Lennon:
>>>> - remove placeholder defconfig and custom copying logic - use
>>>> KBUILD_DEFCONFIG for default in-tree configurations instead - do not
>>>> replace all Yocto configured settings in do_configure_prepen see:
>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474
>>>> Signed-off-by: Alex J Lennon >>> <mailto:ajlen...@dynamicdevices.co.uk>
>>>> <mailto:ajlen...@dynamicdevices.co.uk
>>>> <mailto:ajlen...@dynamicdevices.co.uk>>> ---
>>>> recipes-kernel/linux/linux-raspberrypi.inc | 15 ---
>>>> recipes-kernel/linux/linux-raspberrypi/defconfig | 1 -
>>>> recipes-kernel/linux/linux.inc | 6 +++--- 3 files changed, 7
>>>> insertions(+), 15 deletions(-) delete mode 100644
>>>> recipes-kernel/linux/linux-raspberrypi/defconfig diff --git
>>>> a/recipes-kernel/linux/linux-raspberrypi.inc
>>>> b/recipes-kernel/linux/linux-raspberrypi.inc index 7e36408..e38d905
>>>> 100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
>>>> b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,17 +6,14 @@
>>>> SECTION = "kernel" LICENSE = "GPLv2" LIC_FILES_CHKSUM =
>>>> "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" -SRC_URI += "
>>>> \ - file://defconfig \ - " - COMPATIBLE_MACHINE = "raspberrypi" PV =
>>>> "${LINUX_VERSION}+git${SRCREV}" -# NOTE: For now we pull in the
>>>> default config from the RPi kernel GIT tree.
>>>> -KERNEL_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
>>>> -KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig" +KMACHINE ?=
>>>> "${MACHINE}" +KCONFIG_MODE = "--alldefconfig"
>>>> +KBUILD_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
>>>> +KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig" # CMDLINE for
>>>> raspberrypi CMDLINE = "dwc_otg.lpm_enable=0 console=ttyAMA0,115200
>>>> kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
>>>> @@ -38,10 +35,6 @@ python __anonymous () { d.setVar("DEPENDS",
>>>> depends) } -do_kernel_configme_prepend() { - install -m 0644
>>>> ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig
>>>> || die "No default configuration for ${MACHINE} /
>>>> ${KERNEL_DEFCONFIG} available." -} - do_install_prepend() { install
>>>> -d ${D}/lib/firmware } diff --git
>>>> a/recipes-kernel/linux/linux-raspberrypi/defconfig
>>>> b/recipes-kernel/linux/linux-raspberrypi/defconfig deleted file mode
>>>> 100644 index ecbf32c..000 ---
>>>> a/recipes-kernel/linux/linux-raspberrypi/defconfig +++ /dev/null @@
>>>> -1 +0,0 @@ -# Dummy file to get through do_kernel_configme. diff
>>>> --git a/recipes-kernel/linux/linux.inc
>>>> b/recipes-kernel/linux/linux.inc index fae78b7..103512b 100644 ---
>>>> a/recipes-kernel/linux/linux.inc +++
>>>> b/recipes-kernel/linux/linux.inc @@ -33,8 +33,7 @@
>>>> kernel_configure_variable() { } do_configure_prepend() { - # Clean
>>>> .config - echo "" > ${B}/.config + mv -f ${B}/.config
>>>> ${B}/.config.patched CONF_SED_SCRIPT="" # oabi / eabi support @@
>>>> -109,7 +108,8 @@ do_configure_prepend() { # Keep this the last line
>>>> # Remove all modified configs and add the rest to .config - sed -e
>>>> "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config' +
>>>> sed -e "${CONF_SED_SCRIPT}" < '${B}/.config.patched' >>
>>>> '${B}/.config' + rm -f ${B}/.config.patched yes '' | oe_runmake
>>>> oldconfig } -- 1.9.1
>>> Nice, some small comments only. Please write a short summary of the
>>> feature (kernel-yocto: allow in-tree defconfig) but keep the bugzilla
>>> as a reference for further info. Always good to have some background
>>> found
>> This is seems a significant core change so I wanted to make sure these
>> individual changes were as easily searchable as possible in case any
>> problems arise in future. Can you provide an example of what you are
>> suggesting for the commit msg?
> Perhaps something like:
> 
> Start using the "in-tree defco

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: support configuration fragments

[Alex J Lennon]

On 11/08/2015 19:54, Petter Mabäcker wrote:
> 2015-08-11 19:04 skrev Alex J Lennon:
> 
>> - remove placeholder defconfig and custom copying logic
>> - use KBUILD_DEFCONFIG for default in-tree configurations instead
>> - do not replace all Yocto configured settings in do_configure_prepen
>>
>> see: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474
>>
>> Signed-off-by: Alex J Lennon > <mailto:ajlen...@dynamicdevices.co.uk>>
>> ---
>>  recipes-kernel/linux/linux-raspberrypi.inc   | 15 ---
>>  recipes-kernel/linux/linux-raspberrypi/defconfig |  1 -
>>  recipes-kernel/linux/linux.inc   |  6 +++---
>>  3 files changed, 7 insertions(+), 15 deletions(-)
>>  delete mode 100644 recipes-kernel/linux/linux-raspberrypi/defconfig
>>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
>> b/recipes-kernel/linux/linux-raspberrypi.inc
>> index 7e36408..e38d905 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>> @@ -6,17 +6,14 @@ SECTION = "kernel"
>>  LICENSE = "GPLv2"
>>  LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>>  
>> -SRC_URI += " \
>> -file://defconfig \
>> -"
>> -
>>  COMPATIBLE_MACHINE = "raspberrypi"
>>  
>>  PV = "${LINUX_VERSION}+git${SRCREV}"
>>  
>> -# NOTE: For now we pull in the default config from the RPi kernel GIT tree.
>> -KERNEL_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
>> -KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
>> +KMACHINE ?= "${MACHINE}"
>> +KCONFIG_MODE = "--alldefconfig"
>> +KBUILD_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
>> +KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
>>  
>>  # CMDLINE for raspberrypi
>>  CMDLINE = "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 
>> kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
>> @@ -38,10 +35,6 @@ python __anonymous () {
>>  d.setVar("DEPENDS", depends)
>>  }
>>  
>> -do_kernel_configme_prepend() {
>> -install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} 
>> ${WORKDIR}/defconfig || die "No default configuration for ${MACHINE} / 
>> ${KERNEL_DEFCONFIG} available."
>> -}
>> -
>>  do_install_prepend() {
>>  install -d ${D}/lib/firmware
>>  }
>> diff --git a/recipes-kernel/linux/linux-raspberrypi/defconfig 
>> b/recipes-kernel/linux/linux-raspberrypi/defconfig
>> deleted file mode 100644
>> index ecbf32c..000
>> --- a/recipes-kernel/linux/linux-raspberrypi/defconfig
>> +++ /dev/null
>> @@ -1 +0,0 @@
>> -# Dummy file to get through do_kernel_configme.
>> diff --git a/recipes-kernel/linux/linux.inc b/recipes-kernel/linux/linux.inc
>> index fae78b7..103512b 100644
>> --- a/recipes-kernel/linux/linux.inc
>> +++ b/recipes-kernel/linux/linux.inc
>> @@ -33,8 +33,7 @@ kernel_configure_variable() {
>>  }
>>  
>>  do_configure_prepend() {
>> -# Clean .config
>> -echo "" > ${B}/.config
>> +mv -f ${B}/.config ${B}/.config.patched
>>  CONF_SED_SCRIPT=""
>>  
>>  # oabi / eabi support
>> @@ -109,7 +108,8 @@ do_configure_prepend() {
>>  
>>  # Keep this the last line
>>  # Remove all modified configs and add the rest to .config
>> -sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'
>> +sed -e "${CONF_SED_SCRIPT}" < '${B}/.config.patched' >> '${B}/.config'
>> +rm -f ${B}/.config.patched
>>  
>>  yes '' | oe_runmake oldconfig
>>  }
>> -- 1.9.1
> 
> Nice, some small comments only. Please write a short summary of the
> feature (kernel-yocto: allow in-tree defconfig) but keep the bugzilla as
> a reference for further info. Always good to have some background found

This is seems a significant core change so I wanted to make sure these
individual changes were as easily searchable as possible in case any
problems arise in future. Can you provide an example of what you are
suggesting for the commit msg?

> directly in the commit msg itself. Have you tested it using both
> poky:master and poky:fido?

Rpi2 fido 3.18.16 with/without sound patch, 4.1.3 with/without sound patch.

BR,

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

[yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

[Alex J Lennon]

Signed-off-by: Alex J Lennon 
---
 recipes-kernel/linux/linux-raspberrypi.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
b/recipes-kernel/linux/linux-raspberrypi.inc
index e38d905..8024412 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -6,6 +6,10 @@ SECTION = "kernel"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
 
+SRC_URI += " \
+file://build-in-audio.cfg \
+"
+
 COMPATIBLE_MACHINE = "raspberrypi"
 
 PV = "${LINUX_VERSION}+git${SRCREV}"
-- 
1.9.1

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

[yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: support configuration fragments

[Alex J Lennon]

- remove placeholder defconfig and custom copying logic
- use KBUILD_DEFCONFIG for default in-tree configurations instead
- do not replace all Yocto configured settings in do_configure_prepend

see: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474

Signed-off-by: Alex J Lennon 
---
 recipes-kernel/linux/linux-raspberrypi.inc   | 15 ---
 recipes-kernel/linux/linux-raspberrypi/defconfig |  1 -
 recipes-kernel/linux/linux.inc   |  6 +++---
 3 files changed, 7 insertions(+), 15 deletions(-)
 delete mode 100644 recipes-kernel/linux/linux-raspberrypi/defconfig

diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
b/recipes-kernel/linux/linux-raspberrypi.inc
index 7e36408..e38d905 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -6,17 +6,14 @@ SECTION = "kernel"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
 
-SRC_URI += " \
-file://defconfig \
-"
-
 COMPATIBLE_MACHINE = "raspberrypi"
 
 PV = "${LINUX_VERSION}+git${SRCREV}"
 
-# NOTE: For now we pull in the default config from the RPi kernel GIT tree.
-KERNEL_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
-KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
+KMACHINE ?= "${MACHINE}"
+KCONFIG_MODE = "--alldefconfig"
+KBUILD_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
+KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
 
 # CMDLINE for raspberrypi
 CMDLINE = "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 
root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
@@ -38,10 +35,6 @@ python __anonymous () {
 d.setVar("DEPENDS", depends)
 }
 
-do_kernel_configme_prepend() {
-install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} 
${WORKDIR}/defconfig || die "No default configuration for ${MACHINE} / 
${KERNEL_DEFCONFIG} available."
-}
-
 do_install_prepend() {
 install -d ${D}/lib/firmware
 }
diff --git a/recipes-kernel/linux/linux-raspberrypi/defconfig 
b/recipes-kernel/linux/linux-raspberrypi/defconfig
deleted file mode 100644
index ecbf32c..000
--- a/recipes-kernel/linux/linux-raspberrypi/defconfig
+++ /dev/null
@@ -1 +0,0 @@
-# Dummy file to get through do_kernel_configme.
diff --git a/recipes-kernel/linux/linux.inc b/recipes-kernel/linux/linux.inc
index fae78b7..103512b 100644
--- a/recipes-kernel/linux/linux.inc
+++ b/recipes-kernel/linux/linux.inc
@@ -33,8 +33,7 @@ kernel_configure_variable() {
 }
 
 do_configure_prepend() {
-# Clean .config
-echo "" > ${B}/.config
+mv -f ${B}/.config ${B}/.config.patched
 CONF_SED_SCRIPT=""
 
 # oabi / eabi support
@@ -109,7 +108,8 @@ do_configure_prepend() {
 
 # Keep this the last line
 # Remove all modified configs and add the rest to .config
-sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'
+sed -e "${CONF_SED_SCRIPT}" < '${B}/.config.patched' >> '${B}/.config'
+rm -f ${B}/.config.patched
 
 yes '' | oe_runmake oldconfig
 }
-- 
1.9.1

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

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: Update kernel to 3.18.16

[Alex J Lennon]

On 11/08/2015 11:34, Petter Mabäcker wrote:
>
> 2015-08-11 11:03 skrev Alex Lennon:
>
>>
>>
>> On Tuesday, August 11, 2015, Petter Mabäcker > <mailto:pet...@technux.se>> wrote:
>>
>> 2015-08-11 10:31 skrev Alex J Lennon:
>>
>> On 11/08/2015 08:58, Petter Mabäcker wrote:
>>
>> 2015-08-10 13:08 skrev Alex J Lennon:
>>
>> This requires some changes to KERNEL_DEVICETREE as
>> the dtb layout has changed to support overlays. This
>>     change also makes us ready to support kernel 4.x
>> series Signed-off-by: Alex J Lennon
>> > <mailto:ajlen...@dynamicdevices.co.uk>> ---
>> conf/machine/include/rpi-base.inc | 22
>> ++
>> recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb> | 9 +++-- 2
>> files changed, 17 insertions(+), 14 deletions(-) diff
>> --git a/conf/machine/include/rpi-base.inc
>> b/conf/machine/include/rpi-base.inc index
>> 1dda207..8caa5ba 100644 ---
>> a/conf/machine/include/rpi-base.inc +++
>> b/conf/machine/include/rpi-base.inc @@ -23,18 +23,16
>> @@ KERNEL_DEVICETREE ?= " \ bcm2708-rpi-b-plus.dtb \
>> bcm2709-rpi-2-b.dtb \ \ - ds1307-rtc-overlay.dtb \ -
>> hifiberry-amp-overlay.dtb \ -
>> hifiberry-dac-overlay.dtb \ -
>> hifiberry-dacplus-overlay.dtb \ -
>> hifiberry-digi-overlay.dtb \ -
>> iqaudio-dac-overlay.dtb \ -
>> iqaudio-dacplus-overlay.dtb \ - lirc-rpi-overlay.dtb
>> \ - pcf8523-rtc-overlay.dtb \ - pps-gpio-overlay.dtb
>> \ - w1-gpio-overlay.dtb \ -
>> w1-gpio-pullup-overlay.dtb \ +
>> overlays/hifiberry-amp-overlay.dtb \ +
>> overlays/hifiberry-dac-overlay.dtb \ +
>> overlays/hifiberry-dacplus-overlay.dtb \ +
>> overlays/hifiberry-digi-overlay.dtb \ +
>> overlays/iqaudio-dac-overlay.dtb \ +
>> overlays/iqaudio-dacplus-overlay.dtb \ +
>> overlays/lirc-rpi-overlay.dtb \ +
>> overlays/pps-gpio-overlay.dtb \ +
>> overlays/w1-gpio-overlay.dtb \ +
>> overlays/w1-gpio-pullup-overlay.dtb \ "
>> KERNEL_IMAGETYPE ?= "Image" diff --git
>> a/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb>
>> b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb> index
>> 6d8b155..18c2020 100644 ---
>> a/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb> +++
>> b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb> @@ -1,6 +1,11 @@
>> -LINUX_VERSION ?= "3.18.11" +LINUX_VERSION ?=
>> "3.18.16" -SRCREV =
>> "d64fa8121fca9883d6fb14ca06d2abf66496195e" +SRCREV =
>> "1bb18c8f721ef674a447f3622273f2e2de7a205c" SRC_URI =
>> 
>> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y
>> 
>> <http://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y>"
>> require linux-raspberrypi.inc + +# Create missing out
>> of tree 'overlays' directory prior to install step
>> +do_compile_append() { + mkdir -p
>> ${B}/arch/arm/boot/dts/overlays +} -- 1.9.1
>>
>> Hi Alex, At least I get problems during compile step with
>> above change (I'm building for rpi2). So are your sure
>> '${B}/arch/arm/boot/dts/overlays' isn't needed during
>> compile? I tried with changing above from append to 
>>

>> prepand instead and then it worked fine for me (when
>> building 3.18 kernel). (from log.do_compile, complete log
>> can be found at:
>> http://www.technux.se/logs/log.do_compile.4398.fail )
>>

[yocto] [meta-raspberrypi][PATCH v2 2/2] linux-raspberrypi: support kernel 4.1.3

[Alex J Lennon]

Signed-off-by: Alex J Lennon 
---
 recipes-kernel/linux/linux-raspberrypi_4.1.bb | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 recipes-kernel/linux/linux-raspberrypi_4.1.bb

diff --git a/recipes-kernel/linux/linux-raspberrypi_4.1.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.1.bb
new file mode 100644
index 000..637c5b2
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi_4.1.bb
@@ -0,0 +1,6 @@
+LINUX_VERSION ?= "4.1.3"
+
+SRCREV = "2a2dc4e5e4946e75b98c71eacc3660e913dbd302"
+SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.1.y"
+
+require linux-raspberrypi.inc
-- 
1.9.1

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

[yocto] [meta-raspberrypi][PATCH v2 1/2] linux-raspberrypi: Update kernel to 3.18.16

[Alex J Lennon]

This requires some changes to KERNEL_DEVICETREE as the dtb
layout has changed to support overlays. This change also
makes us ready to support kernel 4.x series

Signed-off-by: Alex J Lennon 
---
 conf/machine/include/rpi-base.inc  | 22 ++
 recipes-kernel/linux/linux-raspberrypi_3.18.bb |  9 +++--
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/conf/machine/include/rpi-base.inc 
b/conf/machine/include/rpi-base.inc
index 1dda207..8caa5ba 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -23,18 +23,16 @@ KERNEL_DEVICETREE ?= " \
 bcm2708-rpi-b-plus.dtb \
 bcm2709-rpi-2-b.dtb \
 \
-ds1307-rtc-overlay.dtb \
-hifiberry-amp-overlay.dtb \
-hifiberry-dac-overlay.dtb \
-hifiberry-dacplus-overlay.dtb \
-hifiberry-digi-overlay.dtb \
-iqaudio-dac-overlay.dtb \
-iqaudio-dacplus-overlay.dtb \
-lirc-rpi-overlay.dtb \
-pcf8523-rtc-overlay.dtb \
-pps-gpio-overlay.dtb \
-w1-gpio-overlay.dtb \
-w1-gpio-pullup-overlay.dtb \
+overlays/hifiberry-amp-overlay.dtb \
+overlays/hifiberry-dac-overlay.dtb \
+overlays/hifiberry-dacplus-overlay.dtb \
+overlays/hifiberry-digi-overlay.dtb \
+overlays/iqaudio-dac-overlay.dtb \
+overlays/iqaudio-dacplus-overlay.dtb \
+overlays/lirc-rpi-overlay.dtb \
+overlays/pps-gpio-overlay.dtb \
+overlays/w1-gpio-overlay.dtb \
+overlays/w1-gpio-pullup-overlay.dtb \
 "
 KERNEL_IMAGETYPE ?= "Image"
 
diff --git a/recipes-kernel/linux/linux-raspberrypi_3.18.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
index 6d8b155..a1fe6b4 100644
--- a/recipes-kernel/linux/linux-raspberrypi_3.18.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
@@ -1,6 +1,11 @@
-LINUX_VERSION ?= "3.18.11"
+LINUX_VERSION ?= "3.18.16"
 
-SRCREV = "d64fa8121fca9883d6fb14ca06d2abf66496195e"
+SRCREV = "1bb18c8f721ef674a447f3622273f2e2de7a205c"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y"
 
 require linux-raspberrypi.inc
+
+# Create missing out of tree 'overlays' directory prior to install step
+do_compile_prepend() {
+  mkdir -p ${B}/arch/arm/boot/dts/overlays
+}
-- 
1.9.1

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

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: Update kernel to 3.18.16

[Alex J Lennon]

On 11/08/2015 11:34, Petter Mabäcker wrote:
>
> 2015-08-11 11:03 skrev Alex Lennon:
>
>>
>>
>> On Tuesday, August 11, 2015, Petter Mabäcker > <mailto:pet...@technux.se>> wrote:
>>
>> 2015-08-11 10:31 skrev Alex J Lennon:
>>
>> On 11/08/2015 08:58, Petter Mabäcker wrote:
>>
>> 2015-08-10 13:08 skrev Alex J Lennon:
>>
>> This requires some changes to KERNEL_DEVICETREE as
>> the dtb layout has changed to support overlays. This
>>     change also makes us ready to support kernel 4.x
>> series Signed-off-by: Alex J Lennon
>> > <mailto:ajlen...@dynamicdevices.co.uk>> ---
>> conf/machine/include/rpi-base.inc | 22
>> ++
>> recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb> | 9 +++-- 2
>> files changed, 17 insertions(+), 14 deletions(-) diff
>> --git a/conf/machine/include/rpi-base.inc
>> b/conf/machine/include/rpi-base.inc index
>> 1dda207..8caa5ba 100644 ---
>> a/conf/machine/include/rpi-base.inc +++
>> b/conf/machine/include/rpi-base.inc @@ -23,18 +23,16
>> @@ KERNEL_DEVICETREE ?= " \ bcm2708-rpi-b-plus.dtb \
>> bcm2709-rpi-2-b.dtb \ \ - ds1307-rtc-overlay.dtb \ -
>> hifiberry-amp-overlay.dtb \ -
>> hifiberry-dac-overlay.dtb \ -
>> hifiberry-dacplus-overlay.dtb \ -
>> hifiberry-digi-overlay.dtb \ -
>> iqaudio-dac-overlay.dtb \ -
>> iqaudio-dacplus-overlay.dtb \ - lirc-rpi-overlay.dtb
>> \ - pcf8523-rtc-overlay.dtb \ - pps-gpio-overlay.dtb
>> \ - w1-gpio-overlay.dtb \ -
>> w1-gpio-pullup-overlay.dtb \ +
>> overlays/hifiberry-amp-overlay.dtb \ +
>> overlays/hifiberry-dac-overlay.dtb \ +
>> overlays/hifiberry-dacplus-overlay.dtb \ +
>> overlays/hifiberry-digi-overlay.dtb \ +
>> overlays/iqaudio-dac-overlay.dtb \ +
>> overlays/iqaudio-dacplus-overlay.dtb \ +
>> overlays/lirc-rpi-overlay.dtb \ +
>> overlays/pps-gpio-overlay.dtb \ +
>> overlays/w1-gpio-overlay.dtb \ +
>> overlays/w1-gpio-pullup-overlay.dtb \ "
>> KERNEL_IMAGETYPE ?= "Image" diff --git
>> a/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb>
>> b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb> index
>> 6d8b155..18c2020 100644 ---
>> a/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb> +++
>> b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> <http://linux-raspberrypi_3.18.bb> @@ -1,6 +1,11 @@
>> -LINUX_VERSION ?= "3.18.11" +LINUX_VERSION ?=
>> "3.18.16" -SRCREV =
>> "d64fa8121fca9883d6fb14ca06d2abf66496195e" +SRCREV =
>> "1bb18c8f721ef674a447f3622273f2e2de7a205c" SRC_URI =
>> 
>> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y
>> 
>> <http://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y>"
>> require linux-raspberrypi.inc + +# Create missing out
>> of tree 'overlays' directory prior to install step
>> +do_compile_append() { + mkdir -p
>> ${B}/arch/arm/boot/dts/overlays +} -- 1.9.1
>>
>> Hi Alex, At least I get problems during compile step with
>> above change (I'm building for rpi2). So are your sure
>> '${B}/arch/arm/boot/dts/overlays' isn't needed during
>> compile? I tried with changing above from append to
>> prepand instead and then it worked fine for me (when
>> building 3.18 kernel). (from log.do_compile, complete log
>> can be found at:
>> http://www.technux.se/logs/log.do_compile.4398.fail )
>>  

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: Update kernel to 3.18.16

[Alex J Lennon]

On 11/08/2015 08:58, Petter Mabäcker wrote:
> 2015-08-10 13:08 skrev Alex J Lennon:
> 
>> This requires some changes to KERNEL_DEVICETREE as the dtb
>> layout has changed to support overlays. This change also
>> makes us ready to support kernel 4.x series
>>
>> Signed-off-by: Alex J Lennon > <mailto:ajlen...@dynamicdevices.co.uk>>
>> ---
>>  conf/machine/include/rpi-base.inc  | 22 ++
>>  recipes-kernel/linux/linux-raspberrypi_3.18.bb |  9 +++--
>>  2 files changed, 17 insertions(+), 14 deletions(-)
>>
>> diff --git a/conf/machine/include/rpi-base.inc 
>> b/conf/machine/include/rpi-base.inc
>> index 1dda207..8caa5ba 100644
>> --- a/conf/machine/include/rpi-base.inc
>> +++ b/conf/machine/include/rpi-base.inc
>> @@ -23,18 +23,16 @@ KERNEL_DEVICETREE ?= " \
>>  bcm2708-rpi-b-plus.dtb \
>>  bcm2709-rpi-2-b.dtb \
>>  \
>> -ds1307-rtc-overlay.dtb \
>> -hifiberry-amp-overlay.dtb \
>> -hifiberry-dac-overlay.dtb \
>> -hifiberry-dacplus-overlay.dtb \
>> -hifiberry-digi-overlay.dtb \
>> -iqaudio-dac-overlay.dtb \
>> -iqaudio-dacplus-overlay.dtb \
>> -lirc-rpi-overlay.dtb \
>> -pcf8523-rtc-overlay.dtb \
>> -pps-gpio-overlay.dtb \
>> -w1-gpio-overlay.dtb \
>> -w1-gpio-pullup-overlay.dtb \
>> +overlays/hifiberry-amp-overlay.dtb \
>> +overlays/hifiberry-dac-overlay.dtb \
>> +overlays/hifiberry-dacplus-overlay.dtb \
>> +overlays/hifiberry-digi-overlay.dtb \
>> +overlays/iqaudio-dac-overlay.dtb \
>> +overlays/iqaudio-dacplus-overlay.dtb \
>> +overlays/lirc-rpi-overlay.dtb \
>> +overlays/pps-gpio-overlay.dtb \
>> +overlays/w1-gpio-overlay.dtb \
>> +overlays/w1-gpio-pullup-overlay.dtb \
>>  "
>>  KERNEL_IMAGETYPE ?= "Image"
>>  
>> diff --git a/recipes-kernel/linux/linux-raspberrypi_3.18.bb 
>> b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> index 6d8b155..18c2020 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> +++ b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
>> @@ -1,6 +1,11 @@
>> -LINUX_VERSION ?= "3.18.11"
>> +LINUX_VERSION ?= "3.18.16"
>>  
>> -SRCREV = "d64fa8121fca9883d6fb14ca06d2abf66496195e"
>> +SRCREV = "1bb18c8f721ef674a447f3622273f2e2de7a205c"
>>  SRC_URI = 
>> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y"
>>  
>>  require linux-raspberrypi.inc
>> +
>> +# Create missing out of tree 'overlays' directory prior to install step
>> +do_compile_append() {
>> +  mkdir -p ${B}/arch/arm/boot/dts/overlays
>> +}
>> -- 1.9.1
>>
> Hi Alex,
> 
> At least I get problems during compile step with above change (I'm
> building for rpi2). So are your sure '${B}/arch/arm/boot/dts/overlays'
> isn't needed during compile? I tried with changing above from append to
> prepand instead and then it worked fine for me (when building 3.18 kernel).
> 
> (from log.do_compile, complete log can be found at:
> http://www.technux.se/logs/log.do_compile.4398.fail )
> 
>   KSYM.tmp_kallsyms1.o
>   KSYM.tmp_kallsyms2.o
>   LD  vmlinux
>   SORTEX  vmlinux
>   SYSMAP  System.map
>   OBJCOPY arch/arm/boot/Image
>   Kernel: arch/arm/boot/Image is ready
> NOTE: make -j 4 bcm2708-rpi-b.dtb
>   DTC arch/arm/boot/dts/bcm2708-rpi-b.dtb
> NOTE: make -j 4 bcm2708-rpi-b-plus.dtb
>   DTC arch/arm/boot/dts/bcm2708-rpi-b-plus.dtb
> NOTE: make -j 4 bcm2709-rpi-2-b.dtb
>   DTC arch/arm/boot/dts/bcm2709-rpi-2-b.dtb
> NOTE: make -j 4 overlays/hifiberry-amp-overlay.dtb
>   DTC arch/arm/boot/dts/overlays/hifiberry-amp-overlay.dtb
> cc1: fatal error: opening output file 
> arch/arm/boot/dts/overlays/.hifiberry-amp-overlay.dtb.dts.tmp: No such file 
> or directory
> compilation terminated.
> make[3]: *** [arch/arm/boot/dts/overlays/hifiberry-amp-overlay.dtb] Error 1
> make[2]: *** [overlays/hifiberry-amp-overlay.dtb] Error 2
> make[1]: *** [sub-make] Error 2
> make: *** [__sub-make] Error 2
> ERROR: oe_runmake failed
> ERROR: Function failed: do_compile (log file is located at 
> /home/epetmab/programming/yocto/alex_test_sstate/tmp/work/raspberrypi2-poky-linux-gnueabi/linux-raspberrypi/3.18.16+git1bb18c8f721ef674a447f3622273f2e2de7a205c-r0/temp/log.do_compile.4398)
> 
> 
> BR, Petter
> 
> 
> 

Hi Petter,

Thanks for testing that out. That is indeed exactly what I was seeing
before I added the directory creation.

I did do the 

[yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: support kernel 4.1.3

[Alex J Lennon]

Signed-off-by: Alex J Lennon 
---
 recipes-kernel/linux/linux-raspberrypi_4.1.bb | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 recipes-kernel/linux/linux-raspberrypi_4.1.bb

diff --git a/recipes-kernel/linux/linux-raspberrypi_4.1.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.1.bb
new file mode 100644
index 000..637c5b2
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi_4.1.bb
@@ -0,0 +1,6 @@
+LINUX_VERSION ?= "4.1.3"
+
+SRCREV = "2a2dc4e5e4946e75b98c71eacc3660e913dbd302"
+SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.1.y"
+
+require linux-raspberrypi.inc
-- 
1.9.1

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

[yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: Update kernel to 3.18.16

[Alex J Lennon]

This requires some changes to KERNEL_DEVICETREE as the dtb
layout has changed to support overlays. This change also
makes us ready to support kernel 4.x series

Signed-off-by: Alex J Lennon 
---
 conf/machine/include/rpi-base.inc  | 22 ++
 recipes-kernel/linux/linux-raspberrypi_3.18.bb |  9 +++--
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/conf/machine/include/rpi-base.inc 
b/conf/machine/include/rpi-base.inc
index 1dda207..8caa5ba 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -23,18 +23,16 @@ KERNEL_DEVICETREE ?= " \
 bcm2708-rpi-b-plus.dtb \
 bcm2709-rpi-2-b.dtb \
 \
-ds1307-rtc-overlay.dtb \
-hifiberry-amp-overlay.dtb \
-hifiberry-dac-overlay.dtb \
-hifiberry-dacplus-overlay.dtb \
-hifiberry-digi-overlay.dtb \
-iqaudio-dac-overlay.dtb \
-iqaudio-dacplus-overlay.dtb \
-lirc-rpi-overlay.dtb \
-pcf8523-rtc-overlay.dtb \
-pps-gpio-overlay.dtb \
-w1-gpio-overlay.dtb \
-w1-gpio-pullup-overlay.dtb \
+overlays/hifiberry-amp-overlay.dtb \
+overlays/hifiberry-dac-overlay.dtb \
+overlays/hifiberry-dacplus-overlay.dtb \
+overlays/hifiberry-digi-overlay.dtb \
+overlays/iqaudio-dac-overlay.dtb \
+overlays/iqaudio-dacplus-overlay.dtb \
+overlays/lirc-rpi-overlay.dtb \
+overlays/pps-gpio-overlay.dtb \
+overlays/w1-gpio-overlay.dtb \
+overlays/w1-gpio-pullup-overlay.dtb \
 "
 KERNEL_IMAGETYPE ?= "Image"
 
diff --git a/recipes-kernel/linux/linux-raspberrypi_3.18.bb 
b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
index 6d8b155..18c2020 100644
--- a/recipes-kernel/linux/linux-raspberrypi_3.18.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
@@ -1,6 +1,11 @@
-LINUX_VERSION ?= "3.18.11"
+LINUX_VERSION ?= "3.18.16"
 
-SRCREV = "d64fa8121fca9883d6fb14ca06d2abf66496195e"
+SRCREV = "1bb18c8f721ef674a447f3622273f2e2de7a205c"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y"
 
 require linux-raspberrypi.inc
+
+# Create missing out of tree 'overlays' directory prior to install step
+do_compile_append() {
+  mkdir -p ${B}/arch/arm/boot/dts/overlays
+}
-- 
1.9.1

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

Re: [yocto] Which repo for meta-altera ?

[Alex J Lennon]

On 28/07/2015 10:10, Spriggs, Jim wrote:
> Hi Guys; confused noob here...
>
> There appear to be (at least) two "official" repos for meta-altera:
>
> github.com/kraj/meta-altera
>
> and
>
> git.rocketboards.org/meta-altera.git
>
>
> So how should I choose between them?
>
> Thanks!
> --
> Jim
>
> Sorry about the company sig.: I can't switch it off.
>

fwiw I would usually start with the official index

http://layers.openembedded.org/layerindex/branch/master/layers/

This seems to point to github

Cheers, Alex

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

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

[Alex J Lennon]

Hi Richard,

On 20/07/2015 19:11, Richard Tollerton wrote:
> Alex J Lennon  writes:
>
>> Out of image-full-mono these have problems without gmcs present,
>>
>> Looks like we need a solution for these three to use mcs instead of gmcs,
>>
>> mono-xsp_3.0.11.bb
> I guess I'm the least concerned about this because of the fixes applied
> in git. They still haven't cut a release yet so I'd guess we should just
> create a mono-xsp_git.bb.
>
>> dbus-sharp_0.8.0.bb
> We might be able to work around this by setting $GMCS, judging from
> configure.ac.
>
>> mono-addins_1.1.bb
> We might be able to work around this by setting $MCS, judging from
> configure.ac.
>
> Beyond that, I suppose the most OE-y way of solving this would be to
> promote your script to a full-blown package that PROVIDES gmcs, such
> that mono3 PROVIDES gmcs and mcs, but mono4 only PROVIDES mcs. Or
> something like that.
>
>> Cheers,
>>
>> Alex

I did a set of work today to bring the recipes up to use mcs instead of
gmcs.

Maybe you can take a look? Thanks,

Alex

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

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

[Alex J Lennon]

Hi Richard,

On 17/07/2015 19:44, Alex J Lennon wrote:
>
> On 17/07/2015 19:24, Richard Tollerton wrote:
>> Alex J Lennon  writes:
>>
>>> Hi Richard,
>>>
>>> On 17/07/2015 17:57, Richard Tollerton wrote:
>>>> Hi Alex,
>>>>
>>>> When you mentioned having weird build troubles, that reminded me that I
>>>> was seeing weird build problems of my own, that I had been refraining
>>>> from sending patches on until I could better characterize the issue.
>>>>
>>>> If you've been seeing weird build failures in executables that really
>>>> should never be failing in the first place -- i.e., gacutils failures,
>>>> or "invalid resx file", or anything involving not being able to dlopen
>>>> libc or being unable to open /etc/mono/config -- you might be interested
>>>> in this patch.
>>> I think I have identified the problems I was seeing with the recipes,
>>> which boil down to the lack of a mono gmcs script and inheriting
>>> autotools-brokensep instead of autotools.
>>>
>>> I can't quite understand why you were not seeing the problem at your
>>> end, but I can see that gmcs was removed at end 2014 -
>>>
>>> https://github.com/mono/mono/commit/b304ec5e0e694ef7098e0fc3eba9dbc0162f4568
>> Yeah, I saw it too. :F I wound up working around it by adding a gmcs
>> symlink in the recipe, but then I also added a gmcs symlink in my host
>> OS, which wound up masking the build errors when I tried removing the
>> gmcs symlink from the recipe later.
>>
>> There were also some autotools-brokensep build problems I was planning
>> on submitting later, sounds like you got those fixed first (yay!)
> Good - that explains it then. Yes autotools-brokensep is in there now.
> The gmcs workaround will arrive shortly
>
>>> The commits I made today address the autotools-brokensep issue and get
>>> me to a point where I can build image-full-mono with a hand-added gmcs
>>> script in sysroot
>>>
>>> (There was a patch needed for monotools-server to support the more
>>> recent mono-xsp and mono-upnp needed autotools-brokensep).
>>>
>>> Now I just need to decide whether to reintroduce the gmcs script or fix
>>> all the other autotools configurations...
>> A-ha! mono-xsp fixed its gmcs references in master, but hasn't cut a
>> release since May 2013. I just asked on #monodev for somebody to cut a
>> new release, but until then, I suppose a workaround is to create a
>> mono-xsp_git.bb?
>>
>> Which other packages require gmcs? I see that monotools-server does, but
>> I can't find evidence of that being maintained since 2010, and I
>> otherwise don't have a use for it AFAIK.

Out of image-full-mono these have problems without gmcs present,

Looks like we need a solution for these three to use mcs instead of gmcs,

mono-xsp_3.0.11.bb

checking for gmcs... no
configure: WARNING: unrecognized options: --disable-dependency-tracking,
--with-libtool-sysroot
configure: WARNING: using cross tools not prefixed with host triplet
configure: error: You need to install 'gmcs'
Error: Could not run ./configure, which is required to configure xsp

dbus-sharp_0.8.0.bb

checking for MONO... yes
checking for gmcs... no
configure: error: You need to install gmcs
Configure failed. The contents of all config.log files follows to aid
debugging

mono-addins_1.1.bb

checking for pkg-config...
/data_drive/imx6/rootfs_builder/qemux86.dizzy/tmp/sysroots/x86_64-linux/usr/bin/pkg-config
checking for gmcs... no
configure: error: mcs Not found
Configure failed. The contents of all config.log files follows to aid
debugging

...

mono-upnp (requires mono-addins)
dbus-sharp-glib (requires dbus-sharp)
monotools-server (requires mono-xsp)

Cheers,

Alex

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

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

[Alex J Lennon]

On 17/07/2015 19:24, Richard Tollerton wrote:
> Alex J Lennon  writes:
>
>> Hi Richard,
>>
>> On 17/07/2015 17:57, Richard Tollerton wrote:
>>> Hi Alex,
>>>
>>> When you mentioned having weird build troubles, that reminded me that I
>>> was seeing weird build problems of my own, that I had been refraining
>>> from sending patches on until I could better characterize the issue.
>>>
>>> If you've been seeing weird build failures in executables that really
>>> should never be failing in the first place -- i.e., gacutils failures,
>>> or "invalid resx file", or anything involving not being able to dlopen
>>> libc or being unable to open /etc/mono/config -- you might be interested
>>> in this patch.
>> I think I have identified the problems I was seeing with the recipes,
>> which boil down to the lack of a mono gmcs script and inheriting
>> autotools-brokensep instead of autotools.
>>
>> I can't quite understand why you were not seeing the problem at your
>> end, but I can see that gmcs was removed at end 2014 -
>>
>> https://github.com/mono/mono/commit/b304ec5e0e694ef7098e0fc3eba9dbc0162f4568
> Yeah, I saw it too. :F I wound up working around it by adding a gmcs
> symlink in the recipe, but then I also added a gmcs symlink in my host
> OS, which wound up masking the build errors when I tried removing the
> gmcs symlink from the recipe later.
>
> There were also some autotools-brokensep build problems I was planning
> on submitting later, sounds like you got those fixed first (yay!)

Good - that explains it then. Yes autotools-brokensep is in there now.
The gmcs workaround will arrive shortly

>> The commits I made today address the autotools-brokensep issue and get
>> me to a point where I can build image-full-mono with a hand-added gmcs
>> script in sysroot
>>
>> (There was a patch needed for monotools-server to support the more
>> recent mono-xsp and mono-upnp needed autotools-brokensep).
>>
>> Now I just need to decide whether to reintroduce the gmcs script or fix
>> all the other autotools configurations...
> A-ha! mono-xsp fixed its gmcs references in master, but hasn't cut a
> release since May 2013. I just asked on #monodev for somebody to cut a
> new release, but until then, I suppose a workaround is to create a
> mono-xsp_git.bb?
>
> Which other packages require gmcs? I see that monotools-server does, but
> I can't find evidence of that being maintained since 2010, and I
> otherwise don't have a use for it AFAIK.

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

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

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

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

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

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

>> I use mono 

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

[Alex J Lennon]

Hi Richard,

On 17/07/2015 17:57, Richard Tollerton wrote:
> Hi Alex,
>
> When you mentioned having weird build troubles, that reminded me that I
> was seeing weird build problems of my own, that I had been refraining
> from sending patches on until I could better characterize the issue.
>
> If you've been seeing weird build failures in executables that really
> should never be failing in the first place -- i.e., gacutils failures,
> or "invalid resx file", or anything involving not being able to dlopen
> libc or being unable to open /etc/mono/config -- you might be interested
> in this patch.

I think I have identified the problems I was seeing with the recipes,
which boil down to the lack of a mono gmcs script and inheriting
autotools-brokensep instead of autotools.

I can't quite understand why you were not seeing the problem at your
end, but I can see that gmcs was removed at end 2014 -

https://github.com/mono/mono/commit/b304ec5e0e694ef7098e0fc3eba9dbc0162f4568

The commits I made today address the autotools-brokensep issue and get
me to a point where I can build image-full-mono with a hand-added gmcs
script in sysroot

(There was a patch needed for monotools-server to support the more
recent mono-xsp and mono-upnp needed autotools-brokensep).

Now I just need to decide whether to reintroduce the gmcs script or fix
all the other autotools configurations...

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

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

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

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

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

Regards,

Alex

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

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

[Alex J Lennon]

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

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

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

I'll spend a bit of time investigating.

Cheers, Alex


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

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

[Alex J Lennon]

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

Richard,

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

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

Thanks,

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

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

[Alex J Lennon]

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

Great idea - applied thanks Richard

Cheers, Alex

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

Re: [yocto] [meta-mono] [PATCH 4/4] mono-xsp-3.x.inc: use autogen.sh

[Alex J Lennon]

On 16/07/2015 18:22, Richard Tollerton wrote:
> The following build failure was observed:
>
> | Makefile.am:7: error: BUILD_DOCS does not appear in AM_CONDITIONAL
>
> This occurs because aclocal must be called with "-I build/m4/shamrock -I
> build/m4/shave", as is done in autogen.sh.
>
> I tried adding those includes to EXTRA_AUTORECONF or acpaths. That seems
> to only partially solve the problem, as MONO_MODULE remains undefined
> and unsubstituted in configure, leading to:
>
> | xsp-3.0.11/configure: line 2651: syntax error near unexpected token 
> `MONO_MODULE,'
>
> This might have something to do with the `automake --gnu` option in
> autogen.sh. I don't know for certain
>
> In any case, merely calling autogen.sh does work. This patch implements
> that, using autotools.bbclass:oe_runconf() as a template.
>
> Signed-off-by: Richard Tollerton 
> ---
>  recipes-mono/mono-xsp/mono-xsp-3.x.inc | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/recipes-mono/mono-xsp/mono-xsp-3.x.inc 
> b/recipes-mono/mono-xsp/mono-xsp-3.x.inc
> index ffe0a28..77af516 100644
> --- a/recipes-mono/mono-xsp/mono-xsp-3.x.inc
> +++ b/recipes-mono/mono-xsp/mono-xsp-3.x.inc
> @@ -9,6 +9,17 @@ inherit autotools-brokensep
>  
>  SRC_URI = "https://github.com/mono/xsp/archive/${PV}.tar.gz";
>  
> +do_configure () {
> +set +e
> +${CACHED_CONFIGUREVARS} ${S}/autogen.sh --verbose ${CONFIGUREOPTS} 
> ${EXTRA_OECONF}
> +if [ "$?" != "0" ]; then
> + echo "Configure failed. The contents of all config.log files follows to 
> aid debugging"
> + find ${S} -name config.log -print -exec cat {} \;
> + bbfatal "oe_runconf failed"
> +fi
> +set -e
> +}
> +
>  S = "${WORKDIR}/xsp-${PV}"
>  
>  PACKAGES += "${PN}-test \

Many thanks for the updates, fixes, and cleanups Richard. Your
patch-sets for mono-xsp, fsharp, mono-basic are applied.

In future can you remove any trailing newlines from your patches please?

Thanks, Alex

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

Re: [yocto] [meta-mono] [PATCH 0/1] mono: use PARALLEL_MAKEINST="" instead of PARALLEL_MAKE=""

[Alex J Lennon]

On 16/07/2015 02:25, Richard Tollerton wrote:
> Hi, last week I sent out a patch to disable parallel builds in mono; in
> hindsight I should have used PARALLEL_MAKEINST instead of PARALLEL_MAKE. Patch
> follows.
>
> This is one of several topic branches I've hacked together over the last 
> couple
> of weeks; you can see the rest at https://github.com/rtollert/meta-mono. I'll
> be meting them out over the next several days.
>
>
> The following changes since commit 9f63cbaaa859f9ae55288de06c1c0eb0e6992f53:
>
>   mono-4.xx.inc: disable parallel make (2015-07-08 11:46:11 +0100)
>
> are available in the git repository at:
>
>   git://github.com/rtollert/meta-mono dev/rtollert/v2/parallel
>   https://github.com/rtollert/meta-mono/tree/dev/rtollert/v2/parallel
>
> Richard Tollerton (1):
>   mono-4.xx.inc: use PARALLEL_MAKEINST="" instead of PARALLEL_MAKE=""
>
>  recipes-mono/mono/mono-4.xx.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Merged, thanks Richard
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mono] [PATCH 0/3] DEPENDS/RDEPENDS fixes

[Alex J Lennon]

On 16/07/2015 02:29, Richard Tollerton wrote:
> These are fixes for build/runtime issues due to insufficient dependency
> specifications. The libgdiplus patches fix observed build failures; the
> gtk-sharp-dev patch is untested but pretty obvious.
>
>
> The following changes since commit 9f63cbaaa859f9ae55288de06c1c0eb0e6992f53:
>
>   mono-4.xx.inc: disable parallel make (2015-07-08 11:46:11 +0100)
>
> are available in the git repository at:
>
>   git://github.com/rtollert/meta-mono dev/rtollert/v2/depends
>   https://github.com/rtollert/meta-mono/tree/dev/rtollert/v2/depends
>
> Richard Tollerton (3):
>   libgdiplus-native: depend explicitly on giflib-native
>   gtk-sharp-dev: add perl dependency
>   libgdiplus: add jpeg, tiff, giflib, libexif dependencies
>
>  recipes-mono/gtk-sharp/gtk-sharp.inc| 1 +
>  recipes-mono/libgdiplus/libgdiplus-native_2.10.8.bb | 2 +-
>  recipes-mono/libgdiplus/libgdiplus_2.10.8.bb| 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
>

Merged, thanks Richard
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] mono-4.xx.inc: disable parallel make

[Alex J Lennon]

On 08/07/2015 21:07, Chris Morgan wrote:
> On Wed, Jul 8, 2015 at 6:49 AM, Alex J Lennon
>  wrote:
>>
>> On 07/07/2015 21:17, Richard Tollerton wrote:
>>> A race was observed during `make install` of mono-native under
>>> PARALLEL_MAKE=-j6:
>> Thanks Richard - patch applied
>>
>> Chris - I wasn't able to replicate the failure you see under Fedora F22
>> with PARALLEL_MAKE="-j 6". The build works for me here.
>> Can you confirm Richard's patch fixes the issue you see on your system?
>>
>> Thanks,
>>
>> Alex
>>
> Hi Alex.
>
> I can confirm that it fixes the build for me here under F22 on an 8
> core machine, although it takes a long time to fail.
>
> Seems like something that should be reported upstream to mono. I
> copied them on Richard's email but haven't seen any response yet.
>

Hi Chris,

Thanks for coming back to me, at least we have an interim workaround then.

You might consider putting a bug report up on Xamarin's bugzilla?

http://www.mono-project.com/community/bugs/

Cheers, Alex

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

Re: [yocto] [PATCH] mono-4.xx.inc: disable parallel make

[Alex J Lennon]

On 07/07/2015 21:17, Richard Tollerton wrote:
> A race was observed during `make install` of mono-native under
> PARALLEL_MAKE=-j6:

Thanks Richard - patch applied

Chris - I wasn't able to replicate the failure you see under Fedora F22
with PARALLEL_MAKE="-j 6". The build works for me here.
Can you confirm Richard's patch fixes the issue you see on your system?

Thanks,

Alex

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

Re: [yocto] meta-mono: Issue building 4.0.2.4

[Alex J Lennon]

On 24/06/2015 01:01, Chris Morgan wrote:
> The double nested output folder looks odd to me but leaving that, it
> looks like a file is being installed twice. Anyone else seeing this?
>
> meta
> meta-skeleton =
> "(HEADdetachedat16caaab):16caaabfcc678b03a0cd88aaeac15f9b8d1c3dad"
> meta-yocto
> meta-yocto-bsp=
> "(HEADdetachedat16caaab):16caaabfcc678b03a0cd88aaeac15f9b8d1c3dad"
> meta-mono = "master:35e8ede514dd35eb3d645d5de22282d0e8204f86"
> meta-oe
> meta-webserver=
> "(HEADdetachedatdf6c7b1):df6c7b1279790d27ebfd58fbdfbac89bde5782ec"
> meta-ti   =
> "(HEADdetachedatb81014d):b81014dbb5cc39fdfa66af87d18b72eb9eb3c701"
> meta-nodejs   =
> "(HEADdetachedate724e27):e724e270bc23a14f12d4a0d73869199457a1b925"
> bitbake-npm   =
> "(HEADdetachedatd88833b):d88833bcf52da7d00e775ca8c2e63ca44cf6ace1"
> meta-ros  =
> "(HEADdetachedatbdc603b):bdc603b821eae5e1d966ec25e63f6832f6386dc8"
> meta-rust =
> "(HEADdetachedat61708ed):61708ed85e76beafdb08b6caf340abeae13bf4b2"
> meta-qt5  =
> "(HEADdetachedat378dfc2):378dfc20ad0e024412da7f3be22efe04c3421c6d"
> meta-ruby
> meta-python
> meta-networking   =
> "(HEADdetachedatdf6c7b1):df6c7b1279790d27ebfd58fbdfbac89bde5782ec"
>
>
> (output snipped)
> | /usr/bin/install -c -c -m 644 frameworks/net_4.5.xml
> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml
> | /usr/bin/install -c -c -m 644
> targets/Microsoft.WebApplication.targets
> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v9.0/WebApplications
> | mkdir -p -- 
> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/14.0/bin/MSBuild
> | /usr/bin/install -c -c -m 644
> targets/Microsoft.Portable.Common.targets
> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/Portable/v4.0/Microsoft.Portable.Common.targets
> | /usr/bin/install -c -c -m 644
> targets/Microsoft.WebApplication.targets
> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v9.0/WebApplications
> | /usr/bin/install: cannot create regular file
> '/home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml':
> File exists
> | Makefile:42: recipe for target 'install-frameworks' failed
> | make[6]: *** [install-frameworks] Error 1
> | make[6]: *** Waiting for unfinished jobs

Hi Chris,

Yes the double nesting does look odd.

I did a test build of 4.0.2.4 here which worked for me. I've also been
supporting another chap who wanted to build 4.0.2.4 rather than the
default 3.12.1 build and he also let me know he had it building
successfully

Clearly there's some kind of issue though. I'm relocating between
countries at the moment without access to a build system and so it'll be
1-2 weeks before I can investigate further myself I'm afraid.

In the meantime do 4.0.1.34  and earlier versions build for you? Does -c
cleansstate help?

Regards,

Alex


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

Re: [yocto] Start openvpn with my own config at startup

[Alex J Lennon]

Hi Matthew,

On 27/05/2015 20:07, Matthew Karas wrote:
> I have an ovpn file I'd like my system to start up with.  I was able
> to install the openvpn file into /etc/openvpn using a bbappends file -
> but the system doesn't start openvpn like the openvpn docs describes.
>
> How do I set up openvpn to launch with my config file at start up?
>
> Thanks

We're using OpenVPN here too. I put a .bbappend together along these
lines which does the job for me. I think you may be needing the
update-rc.d incantations which are documented here

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-update-rc.d

e.g.

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

SRC_URI += "file://openvpn.conf \
   "

do_install_append() {
  install -d ${D}${sysconfdir}/openvpn
  install -m 644 ${WORKDIR}/openvpn.conf
${D}${sysconfdir}/openvpn/openvpn.conf
}

inherit update-rc.d

INITSCRIPT_NAME = "${PN}"
INITSCRIPT_PACKAGES = "${PN}"
INITSCRIPT_PARAMS = "start 90 5 2 . stop 30 0 1 6 ."

...

fwiw we've found that across multiple channels (wired, wireless 802.11,
cellular) we need something more than this and so have started looking
at connman + ofono to provide connection management. NB connman supports
OpenVPN.

Hope that helps,

Alex


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

Re: [yocto] Help getting started developing.

[Alex J Lennon]

Hi Rafael,

On 26/05/2015 22:13, Rafael E. Herrera wrote:
> Hello, 
> I have purchased a TI UEVM5432 board. I have also successfully setup the 
> development environment as described on the online documentation from the TI 
> web site 
> (http://processors.wiki.ti.com/index.php/OMAP5_GLSDK_Software_Developers_Guide).
>  My developement environment is the recommended Ubuntu distribution.
>
> I have also successfully build the Yocto filesystem (as per the instructions 
> in the link above) and successfully booted the generated image in the 
> evaluation board.
>
> Where I need help is on how to port an application to the Yocto filesystem.  
> In particular, I need to build an X Window client.
>
> The instructions in the link above don't explain well how to 
> prepare/configure my environment so I can compile my application. 
>
> If it were a typical development environment, I would configure my Makefiles 
> and just compile. The method used with this development environment (bitbake) 
> is not that clear to me.

If you prepare your application build environment using autotools then
it should "just work" (tm)

This walkthrough might help -

https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles

Also here -

http://www.codeproject.com/Articles/774826/Adding-rd-party-components-to-Yocto-OpenEmbedded-L

Regards,

Alex

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

[yocto] Strange behaviour with stripped connman + openvpn

[Alex J Lennon]

Hi,

I've been looking at some strange behaviour with connman in dizzy (1.25)

With OpenVPN configured and a connman configuration file defining a VPN,
for some reason the service doesn't appear, e.g. connmanctl services

In trying to track down why this is I found that if I use a connmand
daemon binary which is not stripped then all works as it should.

So for those who see this issue, an interim workaround is to inhibit
package stripping in a connman_%.bbappend

e.g. INHIBIT_PACKAGE_STRIP = "1"

Regards,

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

Re: [yocto] [meta-raspberrypi] meta-ivi & meta-raspberrypi

[Alex J Lennon]

On 29/04/2015 16:34, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Apr 2015 16:05:58 +0200
> Alex J Lennon  escreveu:
>
>> On 29/04/2015 15:30, Oliver wrote:
>>> Hello
>>>
>>> I have been working building together the meta-raspberrypi & the meta-ivi 
>>> layers.
>>> I have been stuck with configuration/compilation of weston(from mata-ivi 
>>> layer):
>>>
>>> 1)
>>>
>>> You can check the intial thread 
>>> http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html
>>>
>>>
>>> egl provided by userlad is not detected as the *.pc files are not deployed
>>> Someone has faced similar problems:
>>>
>>>
>>> http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624
>>>
>>> 2)
>>> With this I am able to reach the do_compile stage but there are errors 
>>> related to the undefined type
>>>
>>> PFNEGLQUERYWAYLANDBUFFERWL
>>> Hacked this one forcing the inclusion of  :-S
>>>
>>>
>>> 3)
>>> At linking time the next trouble is:
>>>
>>> /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
>>>  cannot find -lwayland-egl
>>>
>>> IIRC this lib is provided by mesa-gl, but in my build, mesa is 
>>> configured(--disable-egl (is this ok being provided by userlad?)) which 
>>> might be the reason why libwayland-egl is not getting deployed in the image?
>>>
>>> Any correction to my statements or hint to go further would be appreciated
>>>
>>> Best Regards & thanks for your time
>>>
>>> Oliver
>> Hi Oliver,
>>
>> I was looking at wayland/weston last year.  I can't remember exactly
>> where I was at with it I am afraid, but I think I had it building and
>> have pushed some of the code I was playing with to GitHub
>>
>> I think this was related to the .pc issue
>>
>> https://github.com/DynamicDevices/meta-raspberrypi/commit/491dd14585efdb52378a57fa6ddacb1f15065257
>>
>> And this was what I was doing with weston. Looks like I was disabling EGL.
>>
>> https://github.com/DynamicDevices/meta-raspberrypi/commit/c657f69deb57035fc43319dd7d41745c17d7d6e1
>>
>> Sorry I can't be more help but perhaps there's something in there that
>> might be of use.
> I was able to build weston/wayland with meta-raspberrypi, for
> the Tizen distro:
>   http://blogs.s-osg.org/bringing-tizen-to-a-raspberry-pi-2-near-you/
>
> I had to apply a few patches to make it work on both Tizen and
> meta-raspberrypi. The forks are at:
>   http://git.s-osg.org/
>
> The current version there is actually disabling EGL. Enabling
> it seems to be possible, but we're still trying to make it work
> (it compiles fine, though, so I think we're close).
>
> Once done, my plan is to work on porting the patches back to
> meta-raspberrypi (and tizen-distro).
>
>

Great news Mauro. If you need anybody to test out your patches, when
ready, please give me a shout.

Cheers, Alex

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

Re: [yocto] [meta-raspberrypi] meta-ivi & meta-raspberrypi

[Alex J Lennon]

On 29/04/2015 15:30, Oliver wrote:
> Hello
>
> I have been working building together the meta-raspberrypi & the meta-ivi 
> layers.
> I have been stuck with configuration/compilation of weston(from mata-ivi 
> layer):
>
> 1)
>
> You can check the intial thread 
> http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html
>
>
> egl provided by userlad is not detected as the *.pc files are not deployed
> Someone has faced similar problems:
>
>
> http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624
>
> 2)
> With this I am able to reach the do_compile stage but there are errors 
> related to the undefined type
>
> PFNEGLQUERYWAYLANDBUFFERWL
> Hacked this one forcing the inclusion of  :-S
>
>
> 3)
> At linking time the next trouble is:
>
> /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
>  cannot find -lwayland-egl
>
> IIRC this lib is provided by mesa-gl, but in my build, mesa is 
> configured(--disable-egl (is this ok being provided by userlad?)) which might 
> be the reason why libwayland-egl is not getting deployed in the image?
>
> Any correction to my statements or hint to go further would be appreciated
>
> Best Regards & thanks for your time
>
> Oliver

Hi Oliver,

I was looking at wayland/weston last year.  I can't remember exactly
where I was at with it I am afraid, but I think I had it building and
have pushed some of the code I was playing with to GitHub

I think this was related to the .pc issue

https://github.com/DynamicDevices/meta-raspberrypi/commit/491dd14585efdb52378a57fa6ddacb1f15065257

And this was what I was doing with weston. Looks like I was disabling EGL.

https://github.com/DynamicDevices/meta-raspberrypi/commit/c657f69deb57035fc43319dd7d41745c17d7d6e1

Sorry I can't be more help but perhaps there's something in there that
might be of use.

Regards,

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

[yocto] Definition of native toolchain, support for -m32?

[Alex J Lennon]

Hi,

I'm having some trouble building chromium which I think is due to a
definition in chromium.inc which uses the host compiler rather than the
Yocto native compile toolchain

CC_host="${BUILD_CC}" export CC_host
CXX_host="${BUILD_CXX}" export CXX_host

This seems to map to the gcc/g++ on my host system which is surely
incorrect?

Am I right in thinking that the correct way to define the Yocto native
toolchain is using something more like this from native.bbclass?

CC_host="${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}" export CC_host
CXX_host="${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}" export CXX_host

If I do this to eliminate the external dependency I run into a problem
that -m32 is not accepted by the Yocto compiler toolchain (which is
built/running on an x64 Ubuntu 14.04).

Could anybody advise on what steps I might take to have the Yocto native
compile toolchain accepting -m32?

Thanks,

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

Re: [yocto] yocto master work-shared, kernel .config seems to have gone awol

[Alex J Lennon]

On 30/03/2015 21:27, Burton, Ross wrote:
>
> On 30 March 2015 at 18:36, Alex J Lennon
> mailto:ajlen...@dynamicdevices.co.uk>>
> wrote:
>
> I'm updating to Yocto master and have been seeing that when I
> bitbake -c
> devshell virtual/kernel I go into a work-shared tree now.
>
>
> The devshell drops you into whatever ${S} is for that recipe, which
> for the kernel is ${STAGING_KERNEL_DIR} since the kernel
> optimisations.  For the kernel yes, this is sub-optimal.  Maybe the
> kernel should override this using the variable I added (as Bruce
> mentioned).
>

Thanks Ross, Bruce for the feedback and pointers. I shall work through.

One thought - it might perhaps be helpful to have two command variants
to easily drop into either place from the command line without having to
worry about environment variables?

e.g. bitbake -c devshell-shared and bitbake -c devshell or some such?

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

[yocto] yocto master work-shared, kernel .config seems to have gone awol

[Alex J Lennon]

Hi,

I'm updating to Yocto master and have been seeing that when I bitbake -c
devshell virtual/kernel I go into a work-shared tree now.

(This is all with meta-fsl-arm)

I'd normally change the kernel configuration with bitbake -c menuconfig
virtual/kernel then pull out the .config and make my changes to
defconfig as needed.

But I can't seem to find it any more, either in work-shared or if I
traverse to the work tree.

No doubt my own stupidity here but where is it supposed to be nowadays?

Could anybody point me to a discussion on how things are going to be
broken out into work-shared and (presumably) work so I can get up to speed?

Not finding the configuration I thought I'd try generating a kernel
fragment with bitbake  -c diffconfig virtual/kernel from the Yocto docs
but I can't see a fragment.cfg anywhere in the tree

I guess this could all be just that meta-fsl-arm isn't quick in sync
with current the current master? (assuming it's not the more likely
explanation that I just have this plain wrong)

Thanks,

Alex

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

Re: [yocto] [meta-raspberrypi][PATCH] make sound work out of the box for raspberrypi2

[Alex J Lennon]

On 24/03/2015 12:21, Gary Thomas wrote:
> On 2015-03-24 02:40, Alex J Lennon wrote:
>>
>>
>> On 24/03/2015 09:21, Alex J Lennon wrote:
>>>
>>> On 24/03/2015 08:21, Andreas Müller wrote:
>>>> On Tue, Mar 24, 2015 at 12:14 AM, Gary Thomas 
>>>> wrote:
>>>>> On 2015-03-23 16:22, Andreas Müller wrote:
>>>>>> On Mon, Mar 23, 2015 at 10:43 PM, Gary Thomas 
>>>>>> wrote:
>>>>>>> On 2015-03-23 14:57, Andreas Müller wrote:
>>>>>>>> On Mon, Mar 23, 2015 at 4:59 PM, Gary
>>>>>>>> Thomas  wrote:
>>>>>>>>> On 2015-03-22 14:21, Andreas Müller wrote:
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Andreas Müller
>>>>>>>>>> ---
>>>>>>>>>>  ...-during-boot-by-compiling-SND_BCM2835-int.patch | 38
>>>>>>>>>> ++
>>>>>>>>>>  recipes-kernel/linux/linux-raspberrypi_3.18.bb |  8
>>>>>>>>>> +++--
>>>>>>>>>>  2 files changed, 43 insertions(+), 3 deletions(-)
>>>>>>>>>>  create mode 100644
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> recipes-kernel/linux/linux-raspberrypi/0001-start-sound-during-boot-by-compiling-SND_BCM2835-int.patch
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I tried this patch (which downloaded very strangely using
>>>>>>>>> Thunderbird)
>>>>>>>>> and
>>>>>>>>> the
>>>>>>>>> kernel rebuilt fine.  I now have the audio detected, but still
>>>>>>>>> no sound
>>>>>>>>> :-(
>>>>>>>>> Again I've tried the internal (phono) speakers as well as HDMI
>>>>>>>>> audio.
>>>>>>>>>
>>>>>>>>> Just to prove a point on the [brand new] hardware, I installed
>>>>>>>>> OpenELEC
>>>>>>>>> (XBMC)
>>>>>>>>> and it works fine using the HDMI audio.  Sadly when I tried
>>>>>>>>> Raspbian
>>>>>>>>> and
>>>>>>>>> Ubuntu
>>>>>>>>> there was no sound either...
>>>>>>>>>
>>>>>>>>> Were you (Andreas) able to get any sound with this patch?
>>>>>>>>>
>>>>>>>> Yes but I have used 3.5mm sound output - Should have mentioned
>>>>>>>> that in
>>>>>>>> commit. I guess there is to enable something else in kernel
>>>>>>>> config for
>>>>>>>> HDMI. Will look into that
>>>>>>>
>>>>>>> I've tried the 3.5mm jack as well but nothing seems to come out.
>>>>>>> I even tried booting with the HDMI missing (powered off) in case
>>>>>>> that was causing some confusion.
>>>>>>>
>>>>>>> Did you make any changes to config.txt to get this going?
>>>>>> No
>>>>>> Have my standard xfce-image with xfce4-mixer and as mentioned out of
>>>>>> the box: I can hear sound / change volume...
>>>>> Would it be possible to share your [bootable] image?
>>>>>
>>>>>> What does happen if you start alsamixer - if it is installed on your
>>>>>> image?
>>>>> alsamixer looks correct.
>>>>>
>>>>> BTW, I've tried this on my RaspberryPi Model B and I don't get any
>>>>> sound
>>>>> from it either :-(  Again, booting with test_mode=1 shows that the
>>>>> hardware
>>>>> is working, just not in Linux. I'm sure I've tried this in the
>>>>> past with
>>>>> success so I'm becoming more and more confused...
>>>>>
>>>> For sharing I need to create a smaller image - the current one
>>>> contains all stuff from meta-games, all browsers and more. Hope to get
>>>> that done tomorrow evening. What is the preferred way of sharing huge
>>>> files?
>>>>
>>> Circling around this a little, hello_audio built out of vc_graphics
>>> works too over the audio jack
>>>
>>> Alex
>>>
>>
>> OK I got some life from GStreamer and my RPIv2
>>
>> Install amixer
>>
>> modprobe snd_bcm2835 (or presumably use an image with audio built-in)
>>
>> amixer cset numid=3 1 (to set output to audio jack)
>>
>> gst-launch-1.0 audiotestsrc ! alsasink
>>
>> I get a tone out of the audio jack. So some kind of audio routing
>> defaults issue.
>
> Indeed, this does work - tested on RaspberryPi and RaspberryPi2.
>
> Now, to figure out how to make audio over HDMI work.
>

I don't have HDMI audio kit with me here but there are some bits and
bobs here which might help

http://raspberrypi.stackexchange.com/questions/22708/is-there-some-trick-to-getting-aplay-audio-output-working

I'd be wont to try

|amixer cset numid=3 2|


For starters to try to force HDMI output

Some other bits and pieces on ALSA in there I see, which might be relevant

Cheers, Alex




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

Re: [yocto] [meta-raspberrypi][PATCH] make sound work out of the box for raspberrypi2

[Alex J Lennon]

On 24/03/2015 09:21, Alex J Lennon wrote:
>
> On 24/03/2015 08:21, Andreas Müller wrote:
>> On Tue, Mar 24, 2015 at 12:14 AM, Gary Thomas  wrote:
>>> On 2015-03-23 16:22, Andreas Müller wrote:
>>>> On Mon, Mar 23, 2015 at 10:43 PM, Gary Thomas  wrote:
>>>>> On 2015-03-23 14:57, Andreas Müller wrote:
>>>>>> On Mon, Mar 23, 2015 at 4:59 PM, Gary Thomas  wrote:
>>>>>>> On 2015-03-22 14:21, Andreas Müller wrote:
>>>>>>>>
>>>>>>>> Signed-off-by: Andreas Müller 
>>>>>>>> ---
>>>>>>>> ...-during-boot-by-compiling-SND_BCM2835-int.patch | 38
>>>>>>>> ++
>>>>>>>> recipes-kernel/linux/linux-raspberrypi_3.18.bb |  8 +++--
>>>>>>>> 2 files changed, 43 insertions(+), 3 deletions(-)
>>>>>>>> create mode 100644
>>>>>>>>
>>>>>>>>
>>>>>>>> recipes-kernel/linux/linux-raspberrypi/0001-start-sound-during-boot-by-compiling-SND_BCM2835-int.patch
>>>>>>>
>>>>>>>
>>>>>>> I tried this patch (which downloaded very strangely using Thunderbird)
>>>>>>> and
>>>>>>> the
>>>>>>> kernel rebuilt fine.  I now have the audio detected, but still no sound
>>>>>>> :-(
>>>>>>> Again I've tried the internal (phono) speakers as well as HDMI audio.
>>>>>>>
>>>>>>> Just to prove a point on the [brand new] hardware, I installed OpenELEC
>>>>>>> (XBMC)
>>>>>>> and it works fine using the HDMI audio.  Sadly when I tried Raspbian
>>>>>>> and
>>>>>>> Ubuntu
>>>>>>> there was no sound either...
>>>>>>>
>>>>>>> Were you (Andreas) able to get any sound with this patch?
>>>>>>>
>>>>>> Yes but I have used 3.5mm sound output - Should have mentioned that in
>>>>>> commit. I guess there is to enable something else in kernel config for
>>>>>> HDMI. Will look into that
>>>>>
>>>>> I've tried the 3.5mm jack as well but nothing seems to come out.
>>>>> I even tried booting with the HDMI missing (powered off) in case
>>>>> that was causing some confusion.
>>>>>
>>>>> Did you make any changes to config.txt to get this going?
>>>> No
>>>> Have my standard xfce-image with xfce4-mixer and as mentioned out of
>>>> the box: I can hear sound / change volume...
>>> Would it be possible to share your [bootable] image?
>>>
>>>> What does happen if you start alsamixer - if it is installed on your
>>>> image?
>>> alsamixer looks correct.
>>>
>>> BTW, I've tried this on my RaspberryPi Model B and I don't get any sound
>>> from it either :-(  Again, booting with test_mode=1 shows that the hardware
>>> is working, just not in Linux. I'm sure I've tried this in the past with
>>> success so I'm becoming more and more confused...
>>>
>> For sharing I need to create a smaller image - the current one
>> contains all stuff from meta-games, all browsers and more. Hope to get
>> that done tomorrow evening. What is the preferred way of sharing huge
>> files?
>>
> Circling around this a little, hello_audio built out of vc_graphics
> works too over the audio jack
>
> Alex
>

OK I got some life from GStreamer and my RPIv2

Install amixer

modprobe snd_bcm2835 (or presumably use an image with audio built-in)

amixer cset numid=3 1 (to set output to audio jack)

gst-launch-1.0 audiotestsrc ! alsasink

I get a tone out of the audio jack. So some kind of audio routing
defaults issue.

Alex

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

Re: [yocto] [meta-raspberrypi][PATCH] make sound work out of the box for raspberrypi2

[Alex J Lennon]

On 24/03/2015 08:21, Andreas Müller wrote:
> On Tue, Mar 24, 2015 at 12:14 AM, Gary Thomas  wrote:
>> On 2015-03-23 16:22, Andreas Müller wrote:
>>> On Mon, Mar 23, 2015 at 10:43 PM, Gary Thomas  wrote:
 On 2015-03-23 14:57, Andreas Müller wrote:
>
> On Mon, Mar 23, 2015 at 4:59 PM, Gary Thomas  wrote:
>>
>> On 2015-03-22 14:21, Andreas Müller wrote:
>>>
>>>
>>> Signed-off-by: Andreas Müller 
>>> ---
>>> ...-during-boot-by-compiling-SND_BCM2835-int.patch | 38
>>> ++
>>> recipes-kernel/linux/linux-raspberrypi_3.18.bb |  8 +++--
>>> 2 files changed, 43 insertions(+), 3 deletions(-)
>>> create mode 100644
>>>
>>>
>>> recipes-kernel/linux/linux-raspberrypi/0001-start-sound-during-boot-by-compiling-SND_BCM2835-int.patch
>>
>>
>>
>> I tried this patch (which downloaded very strangely using Thunderbird)
>> and
>> the
>> kernel rebuilt fine.  I now have the audio detected, but still no sound
>> :-(
>> Again I've tried the internal (phono) speakers as well as HDMI audio.
>>
>> Just to prove a point on the [brand new] hardware, I installed OpenELEC
>> (XBMC)
>> and it works fine using the HDMI audio.  Sadly when I tried Raspbian
>> and
>> Ubuntu
>> there was no sound either...
>>
>> Were you (Andreas) able to get any sound with this patch?
>>
> Yes but I have used 3.5mm sound output - Should have mentioned that in
> commit. I guess there is to enable something else in kernel config for
> HDMI. Will look into that


 I've tried the 3.5mm jack as well but nothing seems to come out.
 I even tried booting with the HDMI missing (powered off) in case
 that was causing some confusion.

 Did you make any changes to config.txt to get this going?
>>> No

>>> Have my standard xfce-image with xfce4-mixer and as mentioned out of
>>> the box: I can hear sound / change volume...
>>
>> Would it be possible to share your [bootable] image?
>>
>>> What does happen if you start alsamixer - if it is installed on your
>>> image?
>>
>> alsamixer looks correct.
>>
>> BTW, I've tried this on my RaspberryPi Model B and I don't get any sound
>> from it either :-(  Again, booting with test_mode=1 shows that the hardware
>> is working, just not in Linux. I'm sure I've tried this in the past with
>> success so I'm becoming more and more confused...
>>
> For sharing I need to create a smaller image - the current one
> contains all stuff from meta-games, all browsers and more. Hope to get
> that done tomorrow evening. What is the preferred way of sharing huge
> files?
>

Circling around this a little, hello_audio built out of vc_graphics
works too over the audio jack

Alex

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

Re: [yocto] [meta-raspberrypi][PATCH] make sound work out of the box for raspberrypi2

[Alex J Lennon]

On 23/03/2015 18:08, Gary Thomas wrote:
> On 2015-03-23 10:42, Alex J Lennon wrote:
>>
>>
>> On 23/03/2015 16:59, Gary Thomas wrote:
>>> On 2015-03-22 14:21, Andreas Müller wrote:
>>>> Signed-off-by: Andreas Müller 
>>>> ---
>>>>...-during-boot-by-compiling-SND_BCM2835-int.patch | 38
>>>> ++
>>>>recipes-kernel/linux/linux-raspberrypi_3.18.bb |  8 +++--
>>>>2 files changed, 43 insertions(+), 3 deletions(-)
>>>>create mode 100644
>>>> recipes-kernel/linux/linux-raspberrypi/0001-start-sound-during-boot-by-compiling-SND_BCM2835-int.patch
>>>>
>>>
>>> I tried this patch (which downloaded very strangely using Thunderbird)
>>> and the
>>> kernel rebuilt fine.  I now have the audio detected, but still no
>>> sound :-(
>>> Again I've tried the internal (phono) speakers as well as HDMI audio.
>>>
>>> Just to prove a point on the [brand new] hardware, I installed
>>> OpenELEC (XBMC)
>>> and it works fine using the HDMI audio.  Sadly when I tried Raspbian
>>> and Ubuntu
>>> there was no sound either...
>>>
>>> Were you (Andreas) able to get any sound with this patch?
>>
>> Sorry to jump in on your conversation Gary but I am also doing some bits
>> and pieces with meta-raspberrypi myself to test out my new-ish RPiv2.
>>
>> I'll have a look at changing the kernel configuration here later, but I
>> did also try changing TEST_MODE in the config.txt which is billed as
>> giving analogue audio and video out at startup. Sure enough I hear the
>> startup beeps.
>>
>> Perhaps this would enable you to verify the hardware is working too?
>
> Verified - this works.  Still no sound when I boot Poky/Yocto.
>
> Have you tried audio output from Linux?

OK that's something then. I'm in the middle of some i.MX6 builds at the
minute but will look at this with the meta-raspberrypi kernel later and
come back to you. I suspect I will see the same as you.

I don't have anything capable of HDMI audio about here so will output a
wav file or something to the analogue jack. What's your simplest test case?

I might also have a look and see if I can get anything out of the
GStreamer1.0 audio/video playback as I'm looking at that too at the minute.

Regards, Alex

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

Re: [yocto] [meta-raspberrypi][PATCH] make sound work out of the box for raspberrypi2

[Alex J Lennon]

On 23/03/2015 16:59, Gary Thomas wrote:
> On 2015-03-22 14:21, Andreas Müller wrote:
>> Signed-off-by: Andreas Müller 
>> ---
>>   ...-during-boot-by-compiling-SND_BCM2835-int.patch | 38
>> ++
>>   recipes-kernel/linux/linux-raspberrypi_3.18.bb |  8 +++--
>>   2 files changed, 43 insertions(+), 3 deletions(-)
>>   create mode 100644
>> recipes-kernel/linux/linux-raspberrypi/0001-start-sound-during-boot-by-compiling-SND_BCM2835-int.patch
>
> I tried this patch (which downloaded very strangely using Thunderbird)
> and the
> kernel rebuilt fine.  I now have the audio detected, but still no
> sound :-(
> Again I've tried the internal (phono) speakers as well as HDMI audio.
>
> Just to prove a point on the [brand new] hardware, I installed
> OpenELEC (XBMC)
> and it works fine using the HDMI audio.  Sadly when I tried Raspbian
> and Ubuntu
> there was no sound either...
>
> Were you (Andreas) able to get any sound with this patch? 

Sorry to jump in on your conversation Gary but I am also doing some bits
and pieces with meta-raspberrypi myself to test out my new-ish RPiv2.

I'll have a look at changing the kernel configuration here later, but I
did also try changing TEST_MODE in the config.txt which is billed as
giving analogue audio and video out at startup. Sure enough I hear the
startup beeps.

Perhaps this would enable you to verify the hardware is working too?

The docs would seem to indicate that it should output a/v for the
configured number of seconds whereas I see this continuously until I
power cycle, but maybe that is a typo.

http://www.raspberrypi.org/documentation/configuration/config-txt.md

Regards, Alex

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

Re: [yocto] [meta-raspberrypi] RaspberryPi2 - no audio?

[Alex J Lennon]

On 22/03/2015 21:17, Andreas Müller wrote:
> On Sun, Mar 22, 2015 at 1:25 PM, Andrei Gherzan  wrote:
>> Hello,
>>
>> On Sun, Mar 22, 2015 at 1:19 PM, Gary Thomas  wrote:
>>> I just built Poky/Yocto for the RaspberryPi2, straight out
>>> of the box using this configuration:
>>>
>>> Build Configuration:
>>> BB_VERSION= "1.25.0"
>>> BUILD_SYS = "i686-linux"
>>> NATIVELSBSTRING   = "Fedora-13"
>>> TARGET_SYS= "arm-amltd-linux-gnueabi"
>>> MACHINE   = "raspberrypi2"
>>> DISTRO= "amltd"
>>> DISTRO_VERSION= "1.7+snapshot-20150321"
>>> TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard vfpv4
>>> cortexa7"
>>> TARGET_FPU= "vfp-vfpv4-neon"
>>> meta  = "master:12b6cf0f2212519b14333519746174a5b941f7bf"
>>> meta-amltd=
>>> "cutting-edge:d9350ea229c04d64111f38e638f372a1bac87be0"
>>> meta-raspberrypi  = "master:b896a7da70dd7a16ba7ffd664f7747cb37e1d142"
>>>
>>> All seemed to go OK, but when I try to play audio, there are
>>> no sound cards found.  Is there some configuration I need?
>>> Once I get it going, how can I select between the internal
>>> (phono) audio and HDMI?
>>>
>>> Note: I had this working just fine on my RaspberryPi (model B)
>>>
>> We didn't test audio on Raspberrypi 2. So, probably the best thing to do it
>> to shoot a redmine bug and maybe help with some patches? Otherwise we will
>> try to pick it as soon as possible.
>>
>> Thanks a lot.
>>
>> --
>> Andrei Gherzan
>>
> Had same - had no time to send yet [1]...
>
> Andreas
>
> [1] 
> https://github.com/schnitzeltony/meta-raspberrypi/commit/d353859131ead0d45cab322d5e93b3f8391dd2ba

CONFIG_SND=y would be a nice little config fragment

Alex

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

Re: [yocto] Embedded Linux Package Management

[Alex J Lennon]

On 20/03/2015 11:15, Prasant J wrote:
> On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon
>  wrote:
>>
>> On 20/03/2015 09:34, Prasant J wrote:
>>
>> Hi,
>>
>> I'm looking for package management for my embedded linux systems
>> (yocto on armv7 iMX6Q)
>>
>>
>> I'm looking for the following features:
>>
>> (a) Install & remove a package
>> (b) Install packages and its dependencies
>> (c) Install a package with conflicts, such that the conflicting
>> package is force removed
>> (d) A local location with packages should serve as a package source
>> (e) Remote server package (http file server based)
>> (f) List of my packages installed
>> (g) List of my packages not installed but available on the http file server
>> (h) List of my packages that have updates (new version)
>> (i) To be able to manage packages for multiple architectures (eg. rpm
>> can produce packages for multiple architectures using one spec file)
>>
>>
>> The above features will be invoked by the application GUI.
>> Any suggestions: which package management solution would answer all
>> the above use cases?
>>
>>
>>
>> (e) I use smart + RPM. I have a remote package server setup via this in
>> local.conf
>>
>> FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar";
>>
>> Then I'm rsyncing the files up to the server after a bitbake package-index.
>>
>> Then smart update / search / install
>>
>> That seems to work well in my testing.
>>
>
> Hi Alex,
>
> Thanks for inputs!
>
> Is smart development stopped?
>
> When I look at their mailing list it, the last posts were in Nov 2014.
> It looks like no more development for smart package manager. I would
> then tend to say that it will not be a right way for me.
>

I don't know. To me the question would be does it do want I need it to
do as well as I need it to do it,
rather than asking whether there is a lot of activity. One might take
the view that if it is doing its job,
a lack of activity is a sign that it's a mature piece of software that
needs little further development.

You'll have to make that decision yourself.

My understanding is that smart is the recommended way to do things (at
least it was what was
recommended to me) - https://wiki.yoctoproject.org/wiki/Smart

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

Re: [yocto] Embedded Linux Package Management

[Alex J Lennon]

On 20/03/2015 09:34, Prasant J wrote:
> Hi,
>
> I'm looking for package management for my embedded linux systems
> (yocto on armv7 iMX6Q)
>
>
> I'm looking for the following features:
>
> (a) Install & remove a package
> (b) Install packages and its dependencies
> (c) Install a package with conflicts, such that the conflicting
> package is force removed
> (d) A local location with packages should serve as a package source
> (e) Remote server package (http file server based)
> (f) List of my packages installed
> (g) List of my packages not installed but available on the http file server
> (h) List of my packages that have updates (new version)
> (i) To be able to manage packages for multiple architectures (eg. rpm
> can produce packages for multiple architectures using one spec file)
>
>
> The above features will be invoked by the application GUI.
> Any suggestions: which package management solution would answer all
> the above use cases?
>
>

(e) I use smart + RPM. I have a remote package server setup via this in
local.conf

FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar";

Then I'm rsyncing the files up to the server after a bitbake package-index.

Then smart update / search / install

That seems to work well in my testing.

Regards,

Alex

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

Re: [yocto] [meta-mono][PATCH] mono: Support to build mono without X support.

[Alex J Lennon]

On 18/03/2015 15:23, Enric Balletbo i Serra wrote:
> Use PACKAGECONFIG to build a version of mono with or without X support in
> function of x11 DISTRO_FEATURES.
>
> Tested on qemux86 (mono using X) and imx6 board (mono without X)
>
> Signed-off-by: Enric Balletbo i Serra 

Merged. Thanks Enric.

Alex

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

Re: [yocto] Kernel configuration fragments and defconfig from kernel source tree, not meta layer file

[Alex J Lennon]

On 17/03/2015 21:08, Bruce Ashfield wrote:
> On Tue, Mar 17, 2015 at 1:57 PM, Alex J Lennon
>  wrote:
>> Hi,
>>
>> I've been looking into a request to have Yocto kernel configuration
>> fragment support in meta-raspberrypi with a defconfig which is pulled
>> from the kernel source tree for the configured machine.
>>
>> My understanding is that Yocto expects the defconfig file to be supplied
>> in the meta-layer and then configured with SRC_URI += "file://defconfig"
>>
>> We'd prefer not to maintain copies of defconfigs, instead using the true
>> default configuration from the kernel tree and allowing users to add
>> their own .cfg fragments to the SRC_URI via, say, .bbappends.
> Anyone who knows me, knows that I'd say I hate to see defconfigs
> at all ;)

I'm interested to understand the background if it's not too boring a
revisit for you.

Perhaps we can take that offline. What's the problem from your perspective?

> But back on topic, this is something I can change, it is simply that
> when I first put together the linux-yocto kernel configuration steps,
> that most defconfigs were actually out of tree, and not within the kernel
> tree itself.
>
>> It's easy enough to _prepend() a function to copy the appropriate
>> defconfig from the kernel source to the working directory, but I am
>> having a problem as do_patch() in kernel-yocto.bbclass seems to require
>> a defconfig file from the layer itself via use of SRC_URI in find_sccs().
>>
>> Any thoughts? Thanks,
> Pop an enhancement request into the yocto bugzilla and assign it to
> me. I can take care of it from there.
>
> But just to be clear, this will have to stay out of oe-core for a bit, since
> it is past feature freeze for 1.8 and even bug fixes are cut off shortly.

Great. Will do thanks Bruce,

Regards,

Alex

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

[yocto] Kernel configuration fragments and defconfig from kernel source tree, not meta layer file

[Alex J Lennon]

Hi,

I've been looking into a request to have Yocto kernel configuration
fragment support in meta-raspberrypi with a defconfig which is pulled
from the kernel source tree for the configured machine.

My understanding is that Yocto expects the defconfig file to be supplied
in the meta-layer and then configured with SRC_URI += "file://defconfig"

We'd prefer not to maintain copies of defconfigs, instead using the true
default configuration from the kernel tree and allowing users to add
their own .cfg fragments to the SRC_URI via, say, .bbappends.

It's easy enough to _prepend() a function to copy the appropriate
defconfig from the kernel source to the working directory, but I am
having a problem as do_patch() in kernel-yocto.bbclass seems to require
a defconfig file from the layer itself via use of SRC_URI in find_sccs().

Any thoughts? Thanks,

Alex

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

Re: [yocto] Adding new library to yocto project

[Alex J Lennon]

On 09/03/2015 17:50, Kfrell wrote:
> I am using Yocto and I just would like to integrate a new library 
> in my project.
>
> I create a new recipe named "libxerces" which contains a file
> "libxerces-3.1.1.bb". The bb file is quite simple and it is based 
> on autotools : 
>
> DESCRIPTION = "Xerces-c is a validating xml parser written in C++"
> HOMEPAGE = "http://xerces.apache.org/xerces-c/";
> PRIORITY = "optional"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
>
> PR = "r1"
>
> SRC_URI =
> "http://mirror.serversupportforum.de/apache/xerces/c/3/sources/xerces-c-${PV}.tar.gz";
>
> SRC_URI[md5sum] = "6a8ec45d83c8cfb1584c5a5345cb51ae"
> SRC_URI[sha256sum] =
> "a42785f71e0b91d5fd273831c87410ce60a73ccfdd207de1b805d26d44968736"
>
> s="${WORKDIR}/xerces-c-${PV}"
>
> inherit autotools pkgconfig
>
> BBCLASSEXTEND += "native"
>
> I added "libxerces" to my bb image by using IMAGE_INSTALL += " libxerces".
> Then, I try to build my image thru bitbake my-image-test and eveything is
> done correctly but libxerces returns some errors :
>
> I just would like to create the .ipk package named libxerces in 
> which .so files should be available.
>

This might possibly help. The example I created shows how to build a
package including an autotools generated library

https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles

Regards, Alex

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

[yocto] [meta-mono] Update to 3.12.1 to address SKIP TLS / FREAK vulnerabilities

[Alex J Lennon]

Hi,

meta-mono master has been updated to build the latest Mono 3.12.1
release which addresses SKIP TLS / FREAK vulnerabilities in all prior
Mono versions >= 3.4.0.

For further details see:

http://www.mono-project.com/news/2015/03/07/mono-tls-vulnerability/

Basic testing has been performed on an i.MX6 platform running helloworld
(console) and helloworldworld (matchbox ui)

Regards,

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

[yocto] Resizing root flash partition/filesystem on first boot

[Alex J Lennon]

Hi,

I'd like to be able to build an SD card image, deploy to a system and
have it automatically resize on first boot. I haven't seen functionality
that would do this in Yocto. If there is a setting for this could
anybody let me know where that is?

Alternatively if this isn't supported out of the box I was thinking of
adding something, say as a recipe with a post installation task that ran
fdisk, then resizee2fs then either remounted the root f/s if possible or
alternatively rebooted.

I have had a look at this and in a manual hand-rolled way it seems to
work fine.

That said,

e2fsprogs doesn't seem to package resize2fs but I have a small patch to
enable that.

The next problem is that I can automate fdisk with a pipe but when I
delete a partition and create it the default is to start at 1,
overlapping the existing DOS partition that I have on my i.MX6 SD card
images. Odd as I am sure this is different behaviour from what I'd
expect from fdisk on a desktop. I'd have to do some parsing of the
existing partition sizes I guess which I would rather avoid for
simplicity if possible.

If anybody could let me know if this has been done so is a waste of my
time, or if there's a better way to achieve this I'd be grateful.

Thanks,

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

Re: [yocto] meta-qt5 problem in yocto 1.7

[Alex J Lennon]

On 02/02/2015 04:27, peterengcomau...@adam.com.au wrote:
>
>  
> Alex, I have completely separated daisy and dizzy. all of my daisy
> stuff goes into ~/poky-1.6 and I clone only daisy branches there such
> as poky, meta-openembedded, meta-qt5, etc. All of my dizzy stuff goes
> in ~/poky-1.7 so there is never a mix between them. 
>
>
> For dizzy i originally cloned the dizzy meta-qt5 branch and got a lot
> of do_fetch failures for v5.3.2. I then cloned the master branch of
> meta-qt5 from an idea from Simon, but still get the same do_fetch
> failuers but now for v5.4.0.  The files are there because I can
> manually download them, but I cant get the do_fetch to work inside
> bitbake.

So I've successfully built up the latest now, which builds 5.4.0. This
all seems to work OK, excepting that I need to modify the qtbase recipe
as I mentioned to copy examples across to the image tree if I want
qtbase-examples.

Not sure why your do_fetch() step is failing with this...

Regards,

Alex

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

Re: [yocto] meta-qt5 problem in yocto 1.7

[Alex J Lennon]

On 01/02/2015 20:38, peterengcomau...@adam.com.au wrote:
> Hi Alex,
> I have no problem with qt5 with daisy and have been using it fine for
> over 6 months. During that time I have cleaned my tmp file multiple
> times which would force a new reload of the sources.
> Also I dont have a problem with Dizzy when building
> core-image-mininal, core-image-full-cmdline and core-image-sato.
>
> If i bitbake my recipe using the -k option, I only get 3 failed recipes
> 0: qtbase-native-5.4.0-r0 do_fetch (pid 13279)
> 1: qtbase-5.4.0-r0 do_fetch (pid 13280)
> 2: qtdeclarative-5.4.0-r0 do_fetch (pid 13283)
>
> and these relate two 2 failed fetchs:
> ERROR: Function failed: Fetcher failure for URL:
> 'http://download.qt-project.org/official_releases/qt/5.4/5.4.0/submodules/qtdeclarative-opensource-src-5.4.0.tar.xz'.
> Unable to fetch URL from any source.
> ERROR: Function failed: Fetcher failure for URL:
> 'http://download.qt-project.org/official_releases/qt/5.4/5.4.0/submodules/qtbase-opensource-src-5.4.0.tar.xz'.
> Unable to fetch URL from any source.

OK, well I'm not sure but I am going to make some guesses here...

You're building Yocto daisy release/branch which you got from somewhere
then you cloned the meta-qt5 repository or otherwise obtained meta-qt5
meta-data?

You then added that into your bblayers.conf ?

Now the latest meta-qt5 (i.e. master branch) has recipes to build QT
5.4.0 I see

I'm not sure what best practice is here but I tend to try to use the
same branches across the meta-data.

So for example when I am building with Yocto daisy/dizzy I am using the
appropriate branch of meta-qt5 as you saw in my earlier email

For Yocto dizzy, meta-qt5.dizzy =
"dizzy:8b0ffbd849203d07164ccfad2535bdb107eecd08"

If you want to build the meta-qt5 daisy branch then you would go into
the meta-qt5 folder you cloned from the git repo something like this

cd sources/meta-qt5
git branch (to check, probably shows master)
git checkout daisy

Then rebuild. That should be building QT 5.2.1 which is what I am seeing
here

Cheers,

Alex

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

Re: [yocto] meta-qt5 problem in yocto 1.7

[Alex J Lennon]

On 01/02/2015 18:55, Simon Bolek wrote:
> Thanks!
> As for the examples. I cannot help directly, but i would read
> log.do_configure etc. files for details. You might find the reason
> there. Although I have to say, that my knowledge in yocto is at the
> beginners stadium at the moment ;-)
>
> cheers
> simon :-)

I think I've worked out what is happening here. The examples are being
built but not installed to the image folder in the do_install step and
thus there's nothing to package and the qtbase-examples package is ignored

I've committed a change to do_install_append() in a dizzy branch on a DD
fork of meta-qt5 which I think copies the files across correctly

@see:
https://github.com/DynamicDevices/meta-qt5/commit/21b9aef8c3246e9e0b7ec3026bd58d4c595fd5a9

 @@ -216,8 +216,13 @@ do_install_append() {
 # ERROR: objcopy failed with exit code 1 (cmd was
'arm-oe-linux-gnueabi-objcopy' --only-keep-debug
'/OE/oe-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/qtbase/5.0.1-r0.0/package/usr/bin/qmake'
'/OE/oe-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/qtbase/5.0.1-r0.0/package/usr/bin/.debug/qmake')
 rm -f ${D}/${bindir}/${QT_DIR_NAME}/qmake
 # install fonts manually if they are missing
-if [ ! -d ${D}/${OE_QMAKE_PATH_LIBS}/fonts ]; then
-cp -a ${S}/lib/fonts ${D}/${OE_QMAKE_PATH_LIBS}
+if [ ! -d ${D}${OE_QMAKE_PATH_LIBS}/fonts ]; then
+cp -a ${S}/lib/fonts ${D}${OE_QMAKE_PATH_LIBS}
+fi
+# install examples manually if they are missing
+if [ ! -d ${D}${OE_QMAKE_PATH_EXAMPLES} ]; then
+mkdir -p ${D}${OE_QMAKE_PATH_EXAMPLES}
+cp -a ${S}/examples/* ${D}${OE_QMAKE_PATH_EXAMPLES}
 fi
 
 # Remove example.pro file as it is useless

Cheers,

Alex

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

Re: [yocto] meta-qt5 problem in yocto 1.7

[Alex J Lennon]

On 31/01/2015 19:10, peterengcomau...@adam.com.au wrote:
>
> Hi Alex,
>
> Thanks for confirming the problem exists.
> I set QT_MODULE_BRANCH ?= "dev" in
> meta-qt5/recipes-qt/qt5/qt5-git.inc, but still get the same problem. 
> Do I have the correct file ?

Lachlan,

So I have been building for qemux86 with dizzy,

Build Configuration:
BB_VERSION= "1.24.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS= "i586-poky-linux"
MACHINE   = "qemux86"
DISTRO= "poky"
DISTRO_VERSION= "1.7.1"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta
meta-yocto= "dizzy:9fc095a439c36014c73b3a8f240afba09fe0e4d7"
meta-oe
meta-efl
meta-webserver
meta-networking   = "dizzy:200f6cafc878d4c26871fc56d21ecc8eaa9aa61b"
meta-mono = "master:b73fc7c525cc0068b2ed84fc26b5d2d4d87c6c12"
meta-gnome
meta-efl  = "dizzy:200f6cafc878d4c26871fc56d21ecc8eaa9aa61b"
meta-browser.master = "master:14e4829d716db416f62403ddd0941ab97491d707"
meta-ruby
meta-python   = "dizzy:200f6cafc878d4c26871fc56d21ecc8eaa9aa61b"
meta-qt5.dizzy= "dizzy:8b0ffbd849203d07164ccfad2535bdb107eecd08"

local.conf is here http://pastebin.com/0t2GFWhu
bblayers.conf is here http://pastebin.com/CK6dF9f5

Build command is

bitbake -k core-image-minimal

So this fails a few times building, which seems to be related to gcc
issues, and I've seen on and off for some time.

Afer a few restarts I get to the point where most of it is built and I have

ERROR: Function failed: do_configure (log file is located at
/data_drive/imx6/rootfs_builder/qemux86.dizzy/tmp/work/i586-poky-linux/qtwebkit-examples/5.3.2-r0/temp/log.do_configure.26328)
ERROR: Logfile of failure stored in:
/data_drive/imx6/rootfs_builder/qemux86.dizzy/tmp/work/i586-poky-linux/qtwebkit-examples/5.3.2-r0/temp/log.do_configure.26328

ERROR: Task 842
(/data_drive/imx6/rootfs_builder/sources/meta-qt5.dizzy/recipes-qt/qt5/qtwebkit-examples_5.3.2.bb,
do_configure) failed with exit code '1'
WARNING: Failed to fetch URL
git://qt.gitorious.org/qt/qtsystems.git;branch=5.3, attempting MIRRORS
if available
ERROR: Fetcher failure: Unable to find revision
aa651c73bf7bc57c1b6b1bfcfa9afe901884a102 in branch 5.3 even from upstream
ERROR: Function failed: Fetcher failure for URL:
'git://qt.gitorious.org/qt/qtsystems.git;branch=5.3'. Unable to fetch
URL from any source.
ERROR: Logfile of failure stored in:
/data_drive/imx6/rootfs_builder/qemux86.dizzy/tmp/work/i586-poky-linux/qtsystems/5.3.99+5.4.0-beta1+gitAUTOINC+aa651c73bf-r0/temp/log.do_fetch.26325
ERROR: Task 756
(/data_drive/imx6/rootfs_builder/sources/meta-qt5.dizzy/recipes-qt/qt5/qtsystems_git.bb,
do_fetch) failed with exit code '1'

...

Note from the above that qtbase has built ok without modifications to
meta-qt5

To double check the qtbase and also to get qtwebkit building I

bitbake -f -c cleansstate qtbase
bitbake qtbase

This builds OK

...

Then

bitbake -k core-image-minimal

Gives

ERROR: Task 843
(/data_drive/imx6/rootfs_builder/sources/meta-qt5.dizzy/recipes-qt/qt5/qtwebkit-examples_5.3.2.bb,
do_compile) failed with exit code '1'
WARNING: Failed to fetch URL
git://qt.gitorious.org/qt/qtsystems.git;branch=5.3, attempting MIRRORS
if available
ERROR: Fetcher failure: Unable to find revision
aa651c73bf7bc57c1b6b1bfcfa9afe901884a102 in branch 5.3 even from upstream
ERROR: Function failed: Fetcher failure for URL:
'git://qt.gitorious.org/qt/qtsystems.git;branch=5.3'. Unable to fetch
URL from any source.
ERROR: Logfile of failure stored in:
/data_drive/imx6/rootfs_builder/qemux86.dizzy/tmp/work/i586-poky-linux/qtsystems/5.3.99+5.4.0-beta1+gitAUTOINC+aa651c73bf-r0/temp/log.do_fetch.21451
ERROR: Task 756
(/data_drive/imx6/rootfs_builder/sources/meta-qt5.dizzy/recipes-qt/qt5/qtsystems_git.bb,
do_fetch) failed with exit code '1'

...

Changing the branch in qtsystems_git gets qtsystems building

#QT_MODULE_BRANCH = "5.3"
QT_MODULE_BRANCH = "dev"

...

I then removed the qtwebkit examples from local.conf as there's some
strange linker problem there

#qtwebkit-examples-examples \

I then had to remove the qt examples packages as for some reason they
aren't getting built at all

# qtbase-examples \

...

That gets me to the point I get a dizzy root filesystem built. Next I
need to understand why I am not getting the examples packages built.

Hope that helps somewhat.

Cheers,

Alex

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

Re: [yocto] meta-qt5 problem in yocto 1.7

[Alex J Lennon]

On 31/01/2015 19:10, peterengcomau...@adam.com.au wrote:
>
> Hi Alex,
>
> Thanks for confirming the problem exists.
> I set QT_MODULE_BRANCH ?= "dev" in
> meta-qt5/recipes-qt/qt5/qt5-git.inc, but still get the same problem. 
> Do I have the correct file ?

Hi Lachlan,

I'm sorry, I should been more explicit. I was building with "daisy"
branch and that did get things going.

I'll have a quick look at building with "dizzy" here to check...

Cheers,

Alex

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

Re: [yocto] meta-qt5 problem in yocto 1.7

[Alex J Lennon]

On 31/01/2015 13:30, peterengcomau...@adam.com.au wrote:
>
> Hello Martin,
> Thanks for your reply.
> I managed to fix the problem of referring to 5.4 instead of 5.3.2 by
> checking out the master branch instead of the dizzy branch of meta-qt5.
>
> However my problem is with the do_fetch. Most of the do_fetch work
> fine but  I get the folliowing two errors:
> ERROR: Function failed: Fetcher failure for URL:
> 'http://download.qt-project.org/official_releases/qt/5.4/5.4.0/submodules/qtdeclarative-opensource-src-5.4.0.tar.xz'.
> Unable to fetch URL from any source
> ERROR: Function failed: Fetcher failure for URL:
> 'http://download.qt-project.org/official_releases/qt/5.4/5.4.0/submodules/qtbase-opensource-src-5.4.0.tar.xz'.
> Unable to fetch URL from any source.
>

Hi Lachlan, Martin,

I had the same problem on Friday. Investigating the issue it seems to be
that the master branch has disappeared from the g...@gitorious.org:qt and
thus the specified commits are
not found. I had a similar problem with qt3d and qtsystem

Changing QT_MODULE_BRANCH = "dev" seems to get the recipes building.

However I still can't seem to get the examples packages building
whatever I do - any advice on that would be appreciated!

Regards,

Alex


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

[yocto] [meta-mono] Mono updated to 3.12.0

[Alex J Lennon]

I've updated support for Mono build in meta-mono master to 3.12.0 (the
current release).

I've performed basic build testing on an qemux86 build of
core-image-mono, based on core-image-sato, running a "Hello World"
console application and a "Hello World" Windows Forms application.

There has been feedback that issues with armhf support are addressed in
3.10.0/3.12.0 but I have not yet had time to investigate.

ref: https://bugzilla.xamarin.com/show_bug.cgi?id=20239

All feedback on testing and/or issues appreciated.

Regards,

Alex


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

[yocto] [meta-mono] Mono updated to 3.10.0

[Alex J Lennon]

I've updated support for Mono build in meta-mono master to 3.10.0 (the
current release).

I've performed basic build testing on an qemux86 build of
core-image-mono, based on core-image-sato, running a "Hello World"
console application and a "Hello World" Windows Forms application.

There has been feedback that issues with armhf support are addressed in
3.10.0 but I have not yet had time to investigate.

ref: https://bugzilla.xamarin.com/show_bug.cgi?id=20239

All feedback on testing and/or issues appreciated.

Regards,

Alex

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

Re: [yocto] CAN Support

[Alex J Lennon]

Hi Daniel,

On 07/10/2014 15:05, Daniel C. A (NESTIT) wrote:
>
> Hi,
>
> Presently im working on i.mx6 EVK for Automotive
> application. I have used 'fsl-image-gui' which was Bitbaked using
> Yocto-dora release. Since I'm worked on CAN interfaces, I got the
> following queries.
>
> 1.   How to make CAN interfaces up on EVK?
>
> 2.   Is there anything that I have to consider when I Bitbake
> fsl-image-gui?
>
> 3.   Has fsl-image-gui got support for basic drivers like
> CAN,I2c,gpio driver., etc?
>
> 4.   My intention is to test CAN Tx/rx using CAN Analyzer and EVK,
> what all are the steps for the same?Is there any document that I can
> follow?
>
>  
>
> Regards,
>
>Daniel C A
>
>  
>
>

Have you asked over at the meta-freescale list? As you know, driver
support is likely to be closely linked to the Linux kernel
provided for the i.MX6, and they are in the best position over on that
list to answer your question.

Whilst I don't have a definitive answer for you if you look at the
Freescale Embedded Linux bundle for the i.MX6 processor
(e.g. L3.10.17_1.0.0_LINUX_DOCS

 )
you will see sections on GPIO, I2C, and FlexCAN. There are also details
in those sections on
the specific kernel configuration options that need to be turned on if
they are not already turned on by default in the
meta-freescale kernel configuration.

If the drivers you need are not built into the standard kernel by
default then you will need to make some configuration changes.

To do so you might wish to start by looking at the Yocto kernel
development manual here

http://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html

Incidentally. I haven't yet had a chance to pick up a copy of Otavio
Salvador's book "Embedded Linux Development with Yocto Project"
but he's active with all of this over on the meta-freescale list so you
could probably do worse than take a look at his book.

e.g.
http://www.amazon.co.uk/Embedded-Linux-Development-Yocto-Project/dp/1783282339

Regards,

Alex


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

[yocto] [meta-mono] Mono updated to 3.8.0

[Alex J Lennon]

I've updated support for Mono build in meta-mono master from 3.4.0 to
3.8.0 (the current release).

I've performed basic build testing on an x64 host targetting an i.MX6
platform and succesfully run up a commercial application which makes use
of console / X.

If anybody has the time and inclination to perform build and smoke
testing all feedback would be appreciated and incorporated into the README.

Note that there is a still an outstanding issue with Mono not working
correctly with ARM hardfp targets.

ref: https://bugzilla.xamarin.com/show_bug.cgi?id=20239

I have been unable to determine why this is to date. If anybody is
interested in working with me to track down the issue please contact me
directly.

Cheers,

Alex


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

Re: [yocto] RFC: Improving the developer workflow

[Alex J Lennon]

Hi Paul,
> Personally with how fragile package management can end up being, I'm 
> convinced 
> that full-image updates are the way to go for a lot of cases, but ideally 
> with 
> some intelligence so that you only ship the changes (at a filesystem level 
> rather than a package or file level). This ensures that an upgraded image on 
> one device ends up exactly identical to any other device including a newly 
> deployed one. Of course it does assume that you have a read-only rootfs and 
> keep your configuration data / logs / other writeable data on a separate 
> partition or storage medium. However, beyond improvements to support for 
> having a read-only rootfs we haven't really achieved anything in terms of out-
> of-the-box support for this, mainly due to lack of resources.
>
> However, whilst I haven't had a chance to look at it closely, there has been 
> some work on this within the community:
>
> http://sbabic.github.io/swupdate/swupdate.html
> https://github.com/sbabic/swupdate
> https://github.com/sbabic/meta-swupdate/
>  
>

I had a quick look at this. It's interesting. If I am reading this
correctly it's based on the old

-> Bootloader runs Partition A
-> Update Partition B, set Bootloader to run Partition B
->   On failure stay on partition A and retry update.
-> Bootloader runs Partition B
-> Update Partition A, set Bootloader to run Partition A
->  etc.

We've done this type of thing before and it works well. Of course the
drawback is the amount
of flash you need to achieve it but it is a good robust system.

I'd be interested to see how this could work with filesystem deltas say.
I don't _think_ that is
documented here?

...

Thinking a little further what would also really interest me would be to
consider using the
transactionality of the underlying file-system or block-management layer
for the update process.

Given nowadays journalling and log-structure file-systems are already
designed to fail-back when
file/meta-data modifications are interrupted surely we should be able to
start a macro-transaction
point at the start of the  partition update,  and if that update doesn't
complete with a macro-commit
then the f/s layer should be able to automatically roll itself back?
Perhaps the same could be done at
a block management layer?

Cheers,

Alex

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

Re: [yocto] RFC: Improving the developer workflow

[Alex J Lennon]

On 07/08/2014 14:05, Paul Eggleton wrote:
> Hi Alex,
>
> On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote:
>> On 07/08/2014 10:10, Paul Eggleton wrote:
>> fwiw Upgrade solutions are something that is still a read need imho,  as
>> I think we discussed at one of the FOSDEMs.
>>
>> (The other real need being an on-board test framework, again imho, and
>> which I believe is ongoing)
> Indeed; I think we've made some pretty good progress here in that the Yocto 
> Project QA team is now using the automated runtime testing to do QA tests on 
> real hardware. Reporting and monitoring of ptest results is also being looked 
> at as well as integration with LAVA.
>  

Great news. I really want to look into this but as ever time is the
constraining factor.

>> Historically I, and I suspect others, have done full image updates of
>> the storage medium,  onboard flash or whatever but these images are
>> getting so big now that I am trying to  move away from that and into
>> using package feeds for updates to embedded targets.
> Personally with how fragile package management can end up being, I'm 
> convinced 
> that full-image updates are the way to go for a lot of cases, but ideally 
> with 
> some intelligence so that you only ship the changes (at a filesystem level 
> rather than a package or file level). This ensures that an upgraded image on 
> one device ends up exactly identical to any other device including a newly 
> deployed one. Of course it does assume that you have a read-only rootfs and 
> keep your configuration data / logs / other writeable data on a separate 
> partition or storage medium. However, beyond improvements to support for 
> having a read-only rootfs we haven't really achieved anything in terms of out-
> of-the-box support for this, mainly due to lack of resources.

Deltas. Yes I've seen binary deltas attempted over the years, with
varying degrees of success.

I can see how what you say could work at a file-system level if we could
separate out the
writeable data, yes. Not sure I've seen any tooling around this though?

Back in the day when I first started out with Arcom Embedded Linux in
the late '90's I had us
do something similar with a read only JFFS2 system partition and then a
separate app/data
partition. That seemed to work OK. Maybe I need to revisit that.

> However, whilst I haven't had a chance to look at it closely, there has been 
> some work on this within the community:
>
> http://sbabic.github.io/swupdate/swupdate.html
> https://github.com/sbabic/swupdate
> https://github.com/sbabic/meta-swupdate/

I'll take a look. Thanks.

>  
>> My initial experience has been that
>>
>> - as you mention it would be really helpful to have something "more"
>> around management  of package feed releases / targets.
>>
>> - some automation around deployment of package feeds to production
>> servers would help,   or at least some documentation on best practice.
> So the scope of my proposal is a little bit narrower, i.e. for the SDK; and 
> I'm suggesting that we mostly bypass the packaging system since it doesn't 
> really add much benefit and sometimes gets in the way when you're an 
> application developer in the middle of development and the level of churn is 
> high (as opposed to making incremental changes after the product's release).

Mmm. Yes I can understand that. Same here.

>> The other big issue I am seeing, which is mostly my own fault thus far,
>> is that I have sometimes  taken  the easy option of modifying the root
>> filesystem image in various ways within the image recipe (for example
>> changing  a Webmin configuration perhaps)
>>
>> However when I then come to upgrade a package in-situ, such as Webmin,
>> the changes  are  then overwritten.
>>
>> I think this is probably also an issue when upgrading packages that have
>> had local modifications made, and I wonder whether there's a solution to
>> this that I'm not aware of?
> We do have CONFFILES to point to configuration files that may be modified 
> (and 
> thus should not just be overwritten on upgrade). There's not much logic in 
> the 
> actual build system to deal with this, we just pass it to the package 
> manager; 
> but it does work, and recipes that deploy configuration files (and bbappends, 
> if 
> the configuration file is being added rather than changed from there) should 
> set 
> CONFFILES so that the right thing happens on upgrade if you are using a 
> package manager on the target.
>
> A related issue is that for anything other than temporary changes it's often 
> not clear which recipe you need to

Re: [yocto] RFC: Improving the developer workflow

[Alex J Lennon]

On 07/08/2014 10:10, Paul Eggleton wrote:
> Hi folks,
>
> As most of you know within the Yocto Project and OpenEmbedded we've been 
> trying to figure out how to improve the OE developer workflow. This 
> potentially 
> covers a lot of different areas, but one in particular I where think we can 
> have some impact is helping application developers - people who are working 
> on 
> some application or component of the system, rather than the OS as a whole.
>
> Currently, what we provide is an installable SDK containing the toolchain, 
> libraries and headers; we also have the ADT which additionally provides some 
> Eclipse integration (which I'll leave aside for the moment) and has some 
> ability to be extended / updated using opkg only.
>
> The pros:
>
> * Self contained, no extra dependencies
> * Relocatable, can be installed anywhere
> * Runs on lots of different systems
> * Mostly pre-configured for the desired target machine
>
> The cons:
>
> * No ability to migrate into the build environment
> * No helper scripts/tools beyond the basic environment setup
> * No real upgrade workflow (package feed upgrade possible in theory, but no 
> tools to help manage the feeds and difficult to scale with multiple releases 
> and 
> targets)
>

Very interesting Paul.

fwiw Upgrade solutions are something that is still a read need imho,  as
I think we discussed at one of the FOSDEMs.

(The other real need being an on-board test framework, again imho, and
which I believe is ongoing)

Historically I, and I suspect others, have done full image updates of
the storage medium,  onboard flash or whatever but these images are
getting so big now that I am trying to  move away from that and into
using package feeds for updates to embedded targets.

My initial experience has been that

- as you mention it would be really helpful to have something "more"
around management  of package feed releases / targets.

- some automation around deployment of package feeds to production
servers would help,   or at least some documentation on best practice.
 
The other big issue I am seeing, which is mostly my own fault thus far,
is that I have sometimes  taken  the easy option of modifying the root
filesystem image in various ways within the image recipe (for example
changing  a Webmin configuration perhaps)

However when I then come to upgrade a package in-situ, such as Webmin,
the changes  are  then overwritten.

I think this is probably also an issue when upgrading packages that have
had local modifications made, and I wonder whether there's a solution to
this that I'm not aware of?

I am aware of course that mainstream package management tools allow
diffing, upgrading,  ignoring and such but I am unsure as to how that is
supported under Yocto at present?

As a minimum I will have to make sure my OEM recipe changes are all in
the correct .bbappends I believe think (more best practice notes there)
and I definitely need to understand better how configuration file
changes are handled when upgrading packages.

Cheers,

Alex



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

Re: [yocto] [Tizen General] Build Tizen with yocto work-flow

[Alex J Lennon]

On 04/08/2014 08:52, Kévin THIERRY wrote:
>
> On 02/08/2014 17:35, Alex J Lennon wrote:
>> On 01/08/2014 17:36, Alex J Lennon wrote:
>>> On 01/08/2014 16:38, Alex J Lennon wrote:
>>>>> I don't know either but I think it's best to be compliant with both
>>>>> bash and dash, I will try to correct those issues in order to be
>>>>> dash-compliant. Thanks a lot for the feedback ;)
>>>> No problem Kévin. I'm glad you feel it is of some use. I'm getting
>>>> other
>>>> recipes failing now with bash. What I'll probably do is let it run to
>>>> completion with bitbake -k and collate the failures.
>>>>
>>>> Hopefully that'll be some useful feedback in terms of a build on
>>>> Ubuntu
>>>>
>>>> Cheers,
>>>>
>>>> Alex
>>>>
>> Kévin,
>>
>> I made some progress with a USB installation of Yocto Tizen and a
>> VirtualBox disk.
> That's good news ! Did you have to make some changes in meta-tizen ?
> If so, could you send us your patches so we can integrate them ? Thanks !
>>
>> Both a Samsung laptop running from USB and a VirtualBox machine boot,
>> but after mounting the root filesystem they go extremely slowly.
>>
>> They get to "failed to get machine ID" and then it's taking a minute
>> or two before new output appears. Then screen goes black and I don't
>> appear to get any further.
>>
>> e.g.
>> https://www.dropbox.com/sc/ckc84doykfnyvwp/7s_wocGh1PNUJ3tfIMBLa?n=17361870
>>
>>
> We already encountered this issue in the past unfortunately we don't
> know what causes that. We didn't get this issue recently so we are
> unable to reproduce it. I'm wondering if it could be linked too the
> use of a USB (we are not using USB anymore to test the images since
> it's not very convenient). I will put an image on a USB stick and see
> how it goes.
>
> If you have more ideas about what could cause this issue we would be
> glad to know them.
>
> Kevin 

I don't think it's specifically due to USB as I was using USB for the
laptop test, but I built up a VDI disk image in a VirtualBox for the VM
test, so no USB there...

I'm not sure why it might be I'm afraid Kevin. I started trying to
follow the manual procedure to build but ran into some build errors
there and ran out of time.

Cheers,

Alex

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

Re: [yocto] [Tizen General] Build Tizen with yocto work-flow

[Alex J Lennon]

On 02/08/2014 20:52, Khem Raj wrote:
> On Sat, Aug 2, 2014 at 8:35 AM, Alex J Lennon
>  wrote:
>> I made some progress with a USB installation of Yocto Tizen and a VirtualBox 
>> disk.
>>
>> Both a Samsung laptop running from USB and a VirtualBox machine boot, but 
>> after mounting the root filesystem they go extremely slowly.
> its a 'sony' laptop per picture :)

Hah. Well spotted! I am glad to see somebody is paying attention Khem ! :-D

>
>> They get to "failed to get machine ID" and then it's taking a minute or two 
>> before new output appears. Then screen goes black and I don't appear to get 
>> any further.
>
> do you have /etc/machine-id file in rootfs ?
>
>

No there's no /etc/machine-id on the USB stick...

(NB. I did try generating a video to show the behaviour but VirtualBox
video capture isn't playing ball. It doesn't stop completely at the
machine-id error message. It seems to continue further and I get more
messages. Just very very slowly)

Regards,

Alex

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

Re: [yocto] [Tizen General] Build Tizen with yocto work-flow

[Alex J Lennon]

On 01/08/2014 17:36, Alex J Lennon wrote:
> On 01/08/2014 16:38, Alex J Lennon wrote:
>>> I don't know either but I think it's best to be compliant with both
>>> bash and dash, I will try to correct those issues in order to be
>>> dash-compliant. Thanks a lot for the feedback ;)
>> No problem Kévin. I'm glad you feel it is of some use. I'm getting other
>> recipes failing now with bash. What I'll probably do is let it run to
>> completion with bitbake -k and collate the failures.
>>
>> Hopefully that'll be some useful feedback in terms of a build on Ubuntu
>>
>> Cheers,
>>
>> Alex
>>
Kévin,

I made some progress with a USB installation of Yocto Tizen and a VirtualBox 
disk. 

Both a Samsung laptop running from USB and a VirtualBox machine boot, but after 
mounting the root filesystem they go extremely slowly.

They get to "failed to get machine ID" and then it's taking a minute or two 
before new output appears. Then screen goes black and I don't appear to get any 
further.

e.g. 
https://www.dropbox.com/sc/ckc84doykfnyvwp/7s_wocGh1PNUJ3tfIMBLa?n=17361870

Cheers,

Alex

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

Re: [yocto] [Tizen General] Build Tizen with yocto work-flow

[Alex J Lennon]

On 01/08/2014 22:55, Richard Purdie wrote:
> On Fri, 2014-08-01 at 15:13 +0100, Alex J Lennon wrote:
>> Getting some errors here having followed the "Using Scripts" section.
>>
>> I am guessing it might be as I'm using Ubuntu 14.04 LTS x64
>>
>> This is for MACHINE=genericx86
>>
>> e.g.
>>
>> | make[3]: Leaving directory
>> '/home/ajlennon/yocto/poky/build/tmp/work/x86_64-linux/rpm-native/git-r0/git/plugins'
>> | make[2]: Leaving directory
>> '/home/ajlennon/yocto/poky/build/tmp/work/x86_64-linux/rpm-native/git-r0/git/plugins'
>> | make[1]: Leaving directory
>> '/home/ajlennon/yocto/poky/build/tmp/work/x86_64-linux/rpm-native/git-r0/git'
>> | install: cannot stat 'scripts/find-supplements{,.ksyms}': No such file
>> or directory
>> | WARNING: exit code 1 from a shell command.
>> | ERROR: Function failed: do_install (log file is located at
>> /home/ajlennon/yocto/poky/build/tmp/work/x86_64-linux/rpm-native/git-r0/temp/log.do_install.2441)
>> ERROR: Task 99
>> (virtual:native:/home/ajlennon/yocto/meta-tizen/recipes-tizen/rpm/rpm_git.bb,
>> do_install) failed with exit code '1'
> Its because there are bashisms in that metadata and you have dash
> as /bin/sh.
>
> I've already mentioned this at least once but have been ignored :(
>

Yes, thanks Richard, I'd cracked onto that. I wonder if it would be
useful/possible to add a class of warning to bitbake "Bashism detected"
or some such?

Next problem is that grub on my x64 system doesn't seem to like being
used to install x86 files ... :)

Cheers,

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