from:"Alex J Lennon"

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

2019-08-01 Thread 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

2018-11-22 Thread 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

2018-02-08 Thread 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

2017-10-18 Thread 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

2017-10-02 Thread 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)

2017-08-28 Thread 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)

2017-08-26 Thread 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

2017-06-04 Thread 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

2017-06-01 Thread 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

2016-11-30 Thread 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

2016-11-30 Thread 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] [meta-mono][PATCH] mono-4.xx: Remove --disable-static from EXTRA_OECONF

2016-07-26 Thread 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

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

2016-01-08 Thread 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

2015-12-30 Thread 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

2015-12-30 Thread 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

2015-10-27 Thread 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

2015-10-26 Thread 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 <and...@gherzan.ro> wrote:
>>>>
>>>>> On Sat, Oct 24, 2015 at 09:58:42PM +0200, Nicolas Aguirre wrote:
>>>>> 2015-10-24 19:26 GMT+02:00 Andrei Gherzan <and...@gherzan.ro>:
>>>>> 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

2015-10-24 Thread 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 1/2] userland: add .pc files for the OpenGLESv2 and EGL libraries

2015-10-22 Thread 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 <ajlen...@dynamicdevices.co.uk>
---
 .../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 <thomas.petazz...@free-electrons.com>
+Signed-off-by: Alex J Lennon <ajlen...@dynamicdevices.co.uk>
+
+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

2015-10-22 Thread 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

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

2015-10-22 Thread Alex J Lennon

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

Signed-off-by: Alex J Lennon <ajlen...@dynamicdevices.co.uk>
---
 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] README: Add section on audio routing

2015-10-22 Thread Alex J Lennon

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

Signed-off-by: Alex J Lennon <ajlen...@dynamicdevices.co.uk>
---
 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

2015-10-22 Thread 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 <ajlen...@dynamicdevices.co.uk>
---
 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 m

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

2015-10-21 Thread 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
>>>>>> <pet...@technux.se <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
>>>>>> <ajlen...@dynamicdevices.co.uk
>>>>>> <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

2015-10-21 Thread 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
>>>>>> <pet...@technux.se <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
>>>>>> <ajlen...@dynamicdevices.co.uk
>>>>>> <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

2015-10-16 Thread 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

2015-10-08 Thread 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

2015-08-25 Thread 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
 pet...@technux.se 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
 ajlen...@dynamicdevices.co.uk
 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

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

2015-08-17 Thread 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 pet...@technux.se
 mailto:pet...@technux.se wrote:

 2015-08-11 19:04 skrev Alex J Lennon:

 Signed-off-by: Alex J Lennon 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
 

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

2015-08-17 Thread 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 pet...@technux.se
 mailto:pet...@technux.se wrote:

 2015-08-11 19:04 skrev Alex J Lennon:

 Signed-off-by: Alex J Lennon 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
 

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

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

2015-08-12 Thread 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 ajlen...@dynamicdevices.co.uk
 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 defconfig solution provided in poky[0]. To specify 
 an in-tree defconfig file, 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 in meta-raspberrypi will need to:
 
 - start using KBUILD_DEFCONFIG_KMACHINE
 - Remove placeholder defconfig and custom copying logic.
 - Avoid replacing all Yocto project configured settings in 
 do_configure_prepend.
 
 For more background regarding this migration read the bugzilla bug info[1].
 
 [0] - 
 http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
 [1] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474
 

Very comprehensive. Many thanks.

 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
 
 Ok, since there has been some changes (not only the early DT change) in
 poky:master it would be good to do the same tests there. Andrei have to
 correct me if wrong, but since we have a fido branch in meta-raspberrypi

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

2015-08-12 Thread 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] RFC on choice of tool for patch review

2015-08-12 Thread 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

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

2015-08-11 Thread 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 ajlen...@dynamicdevices.co.uk 
 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 following test for both 3.18.x and 4.1.3 kernels (rpi2)

bitbake -f -c cleansstate virtual/kernel
bitbake -f virtual/kernel

I've just re-run that again here and it works for me as-is. I thought
cleansstate was causing me to build from scratch so I'm unclear as to
why I'm not seeing the problem...

NB. I'd also add that for preference I'd like to see the kernel build
Makefile patched with whatever is in 4.1 to create that needed overlays
directory but I've had a look and can't spot it.

Cheers,

Alex

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

2015-08-11 Thread 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 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..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

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

2015-08-11 Thread Alex J Lennon

Signed-off-by: Alex J Lennon ajlen...@dynamicdevices.co.uk
---
 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

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

2015-08-11 Thread 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 pet...@technux.se
 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
 ajlen...@dynamicdevices.co.uk
 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 )
 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

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

2015-08-11 Thread 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 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

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

2015-08-11 Thread Alex J Lennon

Signed-off-by: Alex J Lennon 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 \
+
+
 COMPATIBLE_MACHINE = raspberrypi
 
 PV = ${LINUX_VERSION}+git${SRCREV}
-- 
1.9.1

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

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

2015-08-11 Thread 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 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?

 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: support kernel 4.1.3

2015-08-10 Thread Alex J Lennon

Signed-off-by: Alex J Lennon ajlen...@dynamicdevices.co.uk
---
 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

2015-08-10 Thread 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 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

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

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

2015-07-29 Thread 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

2015-07-20 Thread Alex J Lennon

Hi Richard,

On 20/07/2015 19:11, Richard Tollerton wrote:
 Alex J Lennon ajlen...@dynamicdevices.co.uk 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

2015-07-18 Thread 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 ajlen...@dynamicdevices.co.uk 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] [PATCH 00/11] Refactor common mono build bits into mono.bbclass

2015-07-17 Thread 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

2015-07-17 Thread Alex J Lennon



On 17/07/2015 15:43, Richard Tollerton wrote:
 Alex J Lennon ajlen...@dynamicdevices.co.uk 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

2015-07-17 Thread 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] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

2015-07-17 Thread 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] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

2015-07-17 Thread Alex J Lennon



On 17/07/2015 19:24, Richard Tollerton wrote:
 Alex J Lennon ajlen...@dynamicdevices.co.uk writes:

 Hi Richard,

 On 17/07/2015 17:57, Richard Tollerton wrote:
 Hi Alex,

 When you mentioned having weird build troubles, that reminded me that I
 was seeing weird build problems of my own, that I had been refraining
 from sending patches on until I could better characterize the issue.

 If you've been seeing weird build failures in executables that really
 should never be failing in the first place -- i.e., gacutils failures,
 or invalid resx file, or anything involving not being able to dlopen
 libc or being unable to open /etc/mono/config -- you might be interested
 in this patch.
 I think I have identified the problems I was seeing with the recipes,
 which boil down to the lack of a mono gmcs script and inheriting
 autotools-brokensep instead of autotools.

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

 https://github.com/mono/mono/commit/b304ec5e0e694ef7098e0fc3eba9dbc0162f4568
 Yeah, I saw it too. :F I wound up working around it by adding a gmcs
 symlink in the recipe, but then I also added a gmcs symlink in my host
 OS, which wound up masking the build errors when I tried removing the
 gmcs symlink from the recipe later.

 There were also some autotools-brokensep build problems I was planning
 on submitting later, sounds like you got those fixed first (yay!)

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

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

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

 Now I just need to decide whether to reintroduce the gmcs script or fix
 all the other autotools configurations...
 A-ha! mono-xsp fixed its gmcs references in master, but hasn't cut a
 release since May 2013. I just asked on #monodev for somebody to cut a
 new release, but until then, I suppose a workaround is to create a
 mono-xsp_git.bb?

 Which other packages require gmcs? I see that monotools-server does, but
 I can't find evidence of that being maintained since 2010, and I
 otherwise don't have a use for it AFAIK.

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

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

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

 I am probably going to reintroduce the script due to time contraints
 unless you want to take a look at this?
 Yeah, go for it.

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

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

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

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

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

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

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

 That said, I can't see any reason not to apply your patch so will merge
 that in.
 Thanks. I'll try to dig deeper into this soon

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

2015-07-16 Thread 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 rich.toller...@ni.com
 ---
  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/3] DEPENDS/RDEPENDS fixes

2015-07-16 Thread 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] [meta-mono] [PATCH 0/1] mono: use PARALLEL_MAKEINST= instead of PARALLEL_MAKE=

2015-07-16 Thread 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] [PATCH] mono-4.xx.inc: disable parallel make

2015-07-09 Thread Alex J Lennon



On 08/07/2015 21:07, Chris Morgan wrote:
 On Wed, Jul 8, 2015 at 6:49 AM, Alex J Lennon
 ajlen...@dynamicdevices.co.uk 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

2015-07-08 Thread 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

2015-06-24 Thread 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

2015-05-27 Thread 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.

2015-05-27 Thread 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

2015-05-12 Thread 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

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

2015-04-29 Thread 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] [meta-raspberrypi] meta-ivi meta-raspberrypi

2015-04-29 Thread 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 weston-egl-ext.h :-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

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

2015-04-29 Thread 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 ajlen...@dynamicdevices.co.uk 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 weston-egl-ext.h :-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] yocto master work-shared, kernel .config seems to have gone awol

2015-03-31 Thread Alex J Lennon



On 30/03/2015 21:27, Burton, Ross wrote:

 On 30 March 2015 at 18:36, Alex J Lennon
 ajlen...@dynamicdevices.co.uk 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

2015-03-30 Thread 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

2015-03-24 Thread 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 g...@mlbassoc.com wrote:
On 2015-03-23 16:22, Andreas Müller wrote:
On Mon, Mar 23, 2015 at 10:43 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2015-03-23 14:57, Andreas Müller wrote:
On Mon, Mar 23, 2015 at 4:59 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2015-03-22 14:21, Andreas Müller wrote:

Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
...-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

2015-03-24 Thread Alex J Lennon

On Mon, Mar 23, 2015 at 4:59 PM, Gary Thomas g...@mlbassoc.com wrote:

On 2015-03-22 14:21, Andreas Müller wrote:

recipes-kernel/linux/linux-raspberrypi/0001-start-sound-during-boot-by-compiling-SND_BCM2835-int.patch

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.

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

2015-03-23 Thread 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 schnitzelt...@googlemail.com
---
...-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][PATCH] make sound work out of the box for raspberrypi2

2015-03-23 Thread Alex J Lennon

On 23/03/2015 18:08, Gary Thomas wrote:
On 2015-03-23 10:42, Alex J Lennon wrote:

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.

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] RaspberryPi2 - no audio?

2015-03-22 Thread Alex J Lennon



On 22/03/2015 21:17, Andreas Müller wrote:
 On Sun, Mar 22, 2015 at 1:25 PM, Andrei Gherzan and...@gherzan.ro wrote:
 Hello,

 On Sun, Mar 22, 2015 at 1:19 PM, Gary Thomas g...@mlbassoc.com 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

2015-03-20 Thread Alex J Lennon



On 20/03/2015 11:15, Prasant J wrote:
 On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon
 ajlen...@dynamicdevices.co.uk 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

2015-03-20 Thread 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.

2015-03-19 Thread 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 enric.balle...@collabora.com

Merged. Thanks Enric.

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

2015-03-17 Thread 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] Kernel configuration fragments and defconfig from kernel source tree, not meta layer file

2015-03-17 Thread Alex J Lennon



On 17/03/2015 21:08, Bruce Ashfield wrote:
 On Tue, Mar 17, 2015 at 1:57 PM, Alex J Lennon
 ajlen...@dynamicdevices.co.uk 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

Re: [yocto] Adding new library to yocto project

2015-03-09 Thread 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

2015-03-09 Thread 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

2015-03-04 Thread 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

2015-02-02 Thread 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

2015-02-01 Thread 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

2015-02-01 Thread 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

2015-02-01 Thread 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

2015-02-01 Thread 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

2015-01-31 Thread 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

2015-01-15 Thread 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

2014-10-20 Thread 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

2014-10-08 Thread 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
https://www.freescale.com/webapp/Download?colCode=L3.10.17_1.0.0_LINUX_DOCSappType=licenselocation=nullfasp=1WT_TYPE=Supporting%20InformationWT_VENDOR=FREESCALEWT_FILE_FORMAT=gzWT_ASSET=DocumentationfileExt=.gz
)
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

2014-09-12 Thread 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

2014-08-08 Thread 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

2014-08-07 Thread 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] RFC: Improving the developer workflow

2014-08-07 Thread 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 change/append in order to provide your own 
 version of a particular config file. FYI I entered the following enhancement 
 bug 
 some months ago to add a tool to help with that:

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

Interesting thanks. I don't recall seeing this in recipes. I might have
missed it or are not many
people using this features in their recipes? Of course the next issue is
not knowing what you
want to do with those conf files during an unattended upgrade onto an
embedded box

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

2014-08-04 Thread 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

2014-08-02 Thread 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

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

2014-08-02 Thread 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

2014-08-02 Thread Alex J Lennon


On 02/08/2014 20:52, Khem Raj wrote:
 On Sat, Aug 2, 2014 at 8:35 AM, Alex J Lennon
 ajlen...@dynamicdevices.co.uk 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] Build Tizen with yocto work-flow

2014-08-01 Thread Alex J Lennon


On 31/07/2014 15:55, ronan wrote:
 Hi all,
 presently we are working on a project Tizen on Yocto that provides
 an alternative to gbs tools or OBS.
 - https://wiki.tizen.org/wiki/Tizen_on_yocto

 We are glad to announce the first release 0.1 of our project.

 The main features as the same found in Tizen common:
 - Smack security
 - Pure wayland environment, with tz-launcher
 - Crosswalk
 - Multi-user support
 - ...

 We would like to share this project with Tizen and Yocto communities.

 If you are interested to build Tizen with yocto, just follow this link:
 - https://wiki.tizen.org/wiki/Build_Tizen_with_Yocto

 If you have any question or issue feel free to contact us, on the
 Tizen mailing list (d...@lists.tizen.org) .

 Here a link to the yocto project:
 - https://www.yoctoproject.org/



Hi Ronan,

I'm interested in trying this out. Presumably it should be trivial to
add Mono support by pulling in meta-mono?

Have you looked at this on ARM target platforms at all? e.g. i.MX6 ?

Regards,

Alex

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

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

2014-08-01 Thread Alex J Lennon


On 01/08/2014 11:03, ronan wrote:
 Hi Alex


 I'm interested in trying this out. Presumably it should be trivial to
 add Mono support by pulling in meta-mono?

 Have you looked at this on ARM target platforms at all? e.g. i.MX6 ?

 No, we did not test it for ARM yet, but it's in the pipe.

 If try a ARM build, we would be interested in your feed back.

 Regarding Mono, it shouldn't be an issue. 

Thanks. I'll see if I can take a look here on an RPi or an i.MX6 then
and let you know how it goes.

Cheers,

Alex

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

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

2014-08-01 Thread Alex J Lennon


On 01/08/2014 11:07, Alex J Lennon wrote:
 On 01/08/2014 11:03, ronan wrote:
 Hi Alex

 I'm interested in trying this out. Presumably it should be trivial to
 add Mono support by pulling in meta-mono?

 Have you looked at this on ARM target platforms at all? e.g. i.MX6 ?
 No, we did not test it for ARM yet, but it's in the pipe.

 If try a ARM build, we would be interested in your feed back.

 Regarding Mono, it shouldn't be an issue. 
 Thanks. I'll see if I can take a look here on an RPi or an i.MX6 then
 and let you know how it goes.

 Cheers,

 Alex

 ___
 General mailing list
 gene...@lists.tizen.org
 https://lists.tizen.org/listinfo/general


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'

Layers
=

Build Configuration:
BB_VERSION= 1.23.1
BUILD_SYS = x86_64-linux
NATIVELSBSTRING   = Ubuntu-14.04
TARGET_SYS= i586-poky-linux
MACHINE   = genericx86
DISTRO= poky
DISTRO_VERSION= 1.6+snapshot-20140801
TUNE_FEATURES = m32 core2
TARGET_FPU= 
meta
meta-yocto
meta-yocto-bsp= tizen:faa50171a19a59600f6ac4ec124689bdc0cc1c48
meta-systemd
meta-ruby
meta-multimedia
meta-oe   = master:321c808a57e657c857dfe412d3c09839ebac27f1
meta-tizen= master:0f5ac68414f7c5702cec0fbc2d54cd01c104b4df

Cheers,

Alex

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

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

2014-08-01 Thread Alex J Lennon

Hi Kévin,

On 01/08/2014 15:38, Kévin THIERRY wrote:
 ls -l scripts/find-supplements{,.ksyms}

~/yocto/poky/build/tmp/work/x86_64-linux/rpm-native/git-r0/git$ ls -l
scripts/find-supplements{,.ksyms}
-rw-r--r-- 1 ajlennon ajlennon  418 Aug  1 11:41 scripts/find-supplements
-rw-r--r-- 1 ajlennon ajlennon 2764 Aug  1 11:41
scripts/find-supplements.ksyms

Cheers,

Alex

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

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

2014-08-01 Thread Alex J Lennon


On 01/08/2014 15:38, Kévin THIERRY wrote:
 Hi Alex,

 Can you check if the filesfind-supplements and find-supplements.ksyms
 exist by trying this please:

 bitbake rpm-native -c devshell
 ls -l scripts/find-supplements{,.ksyms}

 And tell us the output.

I think it's the bash vs dash issue rearing its head again

Replacing

 install -m 755 scripts/find-supplements{,.ksyms} ${D}${prefix}/lib/rpm

with

 install -m 755 scripts/find-supplements ${D}${prefix}/lib/rpm
  install -m 755 scripts/find-supplements.ksyms ${D}${prefix}/lib/rpm

in rpm-extraconf.inc got me further, onto an error about a missing pushd

This made me think it was a shall issue and sure enough reconfiguring
back to bash with

dpkg-reconfigure dash

fixed the problem.

I'm not sure of the Yocto policy on dash vs bash but I've been using
dash without problems in general for some time now

Cheers,

Alex

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

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

2014-08-01 Thread Alex J Lennon


 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


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

1 2 3 >

1 - 100 of 267 matches

Mail list logo