[yocto] [meta-raspberrypi] Back-porting raspberrypi2 or raspberrypi3 support to Yocto 1.7 Dizzy

[Thomas A. F. Thorne MEng AUS MIET]

I would like an idea of how much work it could be to backport support
for a raspberrypi2 or raspberrypi3 to Yocto 1.7.  I am relatively knew
to Raspberry Pis and not that experienced in Yocto either. 

I can see that there is a raspberrypi Machine specification supplied in
the dizzy branch.  The raspberrypi2.conf and raspberrypi3.conf files do
not turn up till later on.  Is copying these two configuration files
back to a dizzy branch all that needs to happen? 

If I can get a bitbake to complete successfully is that really all there
is to it or are there a handful of runtime issues I might encounter
later?  I would not like to create a minefield for myself. 

The reason I am thinking about the feasibility of back-porting support
is that we have an existing product which is based on 1.7.  Either we:
develop everything on the older version of Yocto (which means
backporting Pi 2 or 3 support), develop on two versions of Yocto for
now, or try to port the existing product to something more modern line
Yocto 2.1 Krogoth. 

If nothing else I thought someone here might be able to give an
authoritative answer to how big a job the backport was likely to be so
we could way up our options.  I am happy to muddle a long and do the
work in isolation, this is not a request for anyone else to perform the
backport or publish it to a public branch (though I would obvious love
to be told it is already done ;-)). 

Regards,


-- 
Thomas A. F. Thorne MEng. AUS MIET
*Software Engineer*

*NET2EDGE*

Tel: +44 3450 130 030 
Email: thomas.tho...@net2edge.com 
Web: http://www.Net2Edge.com/ 

Net2Edge Limited is a company registered in England & Wales (Company No.
2438435, VAT No. GB 537553821) Passfield Oak, Liphook, Hampshire, GU30
7RL. This email transmission is confidential and intended solely for the
person or organisation to whom it is addressed. If you are not the
intended recipient, you must not copy, distribute or disseminate the
information, or take any action in reliance of it. Any views expressed
in this message are those of the individual sender, except where the
sender specifically states them to be the views of any organisation or
employer. If you have received this message in error, do not open any
attachment but please notify the sender (above) and delete this message
from your system. Please rely on your own virus check. Although all
outbound mail is checked for viruses, no responsibility is taken by the
sender for any damage rising out of any bug or virus infection.



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

[linux-yocto] Custom kernel from "non-git"repository

[e-consultant]

I am trying to use a custom kernel which is sourced from an SVN 
repository, using proky-Krogoth.


After fetch it it comes with an erro message about the wrong path in 
'S'  When checking the error output is is looking in a directory ending 
with "git" although I have no git in my SRC_URI


( the kernel source in my repository has the .git folder as well, should 
this be removed ? )


Is it possible to use a non git repository for a kernel source ?


Any help will be appreciated.


  Marcel




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

Re: [yocto] error: package X is already installed

[Khem Raj]

On 11/9/16 4:57 AM, Yannick Kiekens wrote:
> Hi all,
> 
> I am porting several projects from Jethro to Morty.
> Some of those projects give several hundreds of "error: package X is already
> installed" during do_populate_sdk stage in Morty. 
> These projects compiled fine in Jethro.
> 
> What can cause these errors?

bitbake and metadata checkers got more stricter with every new release, the
problem you have was always there, it just was not detected. The problem is
that multiple recipes are producing artifacts which conflict in final image
because they are trying to install same file. So the right fix is to choose
one recipe which will provide the package/file in final rootfs and add rm -rf
${D}/path/to/ in do_install of other recipes

> 
> Mvg
> Yannick Kiekens
> 
> 



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

Re: [yocto] Postinsts question

[Vuille, Martin (Martin)]

Thanks Ross, Khem

It looks like we aren’t setting ‘read-only-rootfs’

Our images and init are very customized, so we missed that.
Will look into it.

Regards,
MV

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: November 09, 2016 08:19
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Postinsts question


On 8 November 2016 at 23:23, Vuille, Martin (Martin) 
> wrote:
We are running with our rootfs mounted read-only.
Consequently, any postinsts that get deferred to first boot fail.

Is there a way to fail the build for any postinsts that can’t
be performed during the build and have to be deferred?

I was looking at some other selftests today and a test suggested that this 
already happens, and it's true.

If you add 'read-only-rootfs' to IMAGE_FEATURES then delayed postists are fatal:

ERROR: core-image-sato-base-1.0-r0 do_rootfs: The following packages could not 
be configured offline and rootfs is read-only: ['postinst-test-delayed']
ERROR: core-image-sato-base-1.0-r0 do_rootfs: Function failed: do_rootfs

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

Re: [yocto] How to handle meta-intel/openembedded repos with multiple developers

[Mike Looijmans]

Git submodules work fine for this.

In general, for each project I create a top-level repo that has the OE repos 
as submodule. The project repo also contains the project-specific recipes.



On 07-11-16 20:31, Chris Z. wrote:

Hi,

How you store your project configuration ? How you prepare workspace (download
each layer separately)?
Basic stuff, SW release should be reproducible (in easy way). Store somewhere
used hash of each piece or use tags. Non company assets should be already
somehow tagged or you use HEAD or master/-next ?

Br,
Chris Z

On Thu, Oct 27, 2016 at 8:22 AM, Edward Wingate > wrote:

On Thu, Mar 3, 2016 at 8:27 AM, Mark Hatle > wrote:
>  At some point during product development a lead/architect needs to make 
the
> decision to 'freeze' development and at that point everything is
tagged/branched
> and only backports are used from them on.  (If the number of backports
gets too
> large, you MIGHT decide to selectively rebase.)

I'm currently trying to figure out with how to control external layers
in my Yocto build and found this thread.  I'm a little unclear on how
to track a release to the version used on non-company layers.  Say I'm
using poky, meta-openembedded, meta-xilinx and then my own layer,
meta-me. When I freeze development and do a release, I can tag
meta-me, but because I also treat non-company assets as RO, I
shouldn't tag poky, meta-openembedded nor meta-xilinx (or should I? Is
this where I use git's lightweight tagging as opposed to annotated
tags?) When "everything is tagged/branched", does that somehow include
tagging the non-company assets?  Thanks for any help.

Ed
--



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





___

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] Postinsts question

[Burton, Ross]

On 8 November 2016 at 23:23, Vuille, Martin (Martin) 
wrote:

> We are running with our rootfs mounted read-only.
>
> Consequently, any postinsts that get deferred to first boot fail.
>
>
>
> Is there a way to fail the build for any postinsts that can’t
>
> be performed during the build and have to be deferred?
>
>
I was looking at some other selftests today and a test suggested that this
already happens, and it's true.

If you add 'read-only-rootfs' to IMAGE_FEATURES then delayed postists are
fatal:

ERROR: core-image-sato-base-1.0-r0 do_rootfs: The following packages could
not be configured offline and rootfs is read-only: ['postinst-test-delayed']
ERROR: core-image-sato-base-1.0-r0 do_rootfs: Function failed: do_rootfs

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

[yocto] error: package X is already installed

[Yannick Kiekens]

Hi all,

I am porting several projects from Jethro to Morty.
Some of those projects give several hundreds of "error: package X is
already installed" during do_populate_sdk stage in Morty.
These projects compiled fine in Jethro.

What can cause these errors?

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