Re: [yocto] [layerindex-web][PATCH 1/1] import_layer.py: add -t option for layer_type

[Paul Eggleton]

Hi Robert,

On Monday, 23 July 2018 12:30:01 PM CEST Robert Yang wrote:
> Now the logic is:
> Use options.layer_type if specified, guess if not, default to 'M'.
> 
> Note choices=['A', 'B', 'S', 'D', 'M', ''], the '' is for default='', we can't
> use default='M' here, otherwise we don't know whether the 'M' is specified by
> user or not, we don't guess if it is specified by user, otherwise, guess.
> 
> Signed-off-by: Robert Yang 
> ---
>  layerindex/tools/import_layer.py | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/layerindex/tools/import_layer.py 
> b/layerindex/tools/import_layer.py
> index 2413cff..0d501f6 100755
> --- a/layerindex/tools/import_layer.py
> +++ b/layerindex/tools/import_layer.py
> @@ -189,6 +189,10 @@ def main():
>  parser.add_option("-s", "--subdir",
>  help = "Specify subdirectory",
>  action="store", dest="subdir")
> +parser.add_option("-t", "--type",
> +help = "Specify layer type. A: Base, B: Machine(BSP), S: 
> Software, D: Distribution, M: Miscellaneous",
> +choices=['A', 'B', 'S', 'D', 'M', ''],
> +action="store", dest="layer_type", default='')

If it's practical to do, could you make this part of the code use 
LayerItem.LAYER_TYPE_CHOICES from models.py so that this will work
if that is extended in future? Of course that will mean initialising Django
earlier, I'm not sure if that will have any side-effects that we wouldn't want.
If you could give that a try though that would be great.

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] custom linux kernel recipe fails

[ChenQi]

On 07/27/2018 12:56 AM, Steve Pavao wrote:

Hello -

I’m trying to build using a custom 64-bit kernel at head of sumo, but I get an 
error.  It seems that SRCPV cannot be resolved.Please send any ideas you 
may have about how I may adapt my recipe to get it to work.

Normally, I use the default meta-raspberrypi kernel, but for this build, I am using 
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom” in my local.conf

My simple kernel recipe is in linux-yocto-custom.bb.  (It is based on the 
example recipe).

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

PV = "${LINUX_VERSION}+git${SRCPV}"
PR = "r0"

LINUX_VERSION ?= "4.14.4"
LINUX_VERSION_EXTENSION_append = "-xenomai-ipipe-arm64"

SRC_URI = 
"http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1";
SRCREV = "133bbf97672ff6e72fc21784b8ae44b194b76626"


Try:

SRC_URI 
="http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1;name=machine";
SRCREV_machine = "133bbf97672ff6e72fc21784b8ae44b194b76626"

Best Regards,
Chen Qi


SRC_URI[md5sum] = "a5cb3babd85a94fda2905cc3db5e7825"

COMPATIBLE_MACHINE = "raspberrypi3-64"

the error:

WARNING: 
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
 Exception during build_dependencies for PKG_kernel-base
WARNING: 
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
 Error during finalise of 
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
ERROR: ExpansionError during parsing 
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable PKG_kernel-base, 
expression was 
kernel-${@legitimize_package_name('${@get_kernelversion_headers('/data/development/lfs/yocto/build/spark/raspberrypi3-64/tmp/work/raspberrypi3_64-poky-linux/linux-yocto-custom/4.14.4+git${SRCPV}-r0/linux-raspberrypi3_64-standard-build')}')}
 which triggered exception SyntaxError: invalid syntax (PKG_kernel-base, line 1)



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

Re: [yocto] net-snmp_5.7.3.bbappend

[Simon Chamlian]

Hi,

I created a bbappend in the same directory where *net-snmp_5.7.3.bb
* resides:


/sources/meta-openembedded/meta-networking/recipes-protocols/net-snmp$ *cat
net-snmp_5.7.3.bbappend*



EXTRA_OECONF += " --enable-mini-agent --with-default-snmp-version=3
--disable-debugging \
  --with-logfile='/var/log/snmp' --with-transports='UDP
TCP' --enable-blumenthal-aes  "






did

$ *bitbake -c compile net-snmp*
$ *MACHINE=imx7d-phyboard-zeta-**001 bitbake  fsl-image-pk-imx-15*


Does not seem to make any difference. The manifest files for the rootfs are
identical with the previous build without the bbappend.


Any hints?

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

Re: [yocto] How to force build of a blacklisted recipe?

[MOHAMMAD RASIM]

Thanks, that worked


On 07/26/2018 01:43 PM, Paul Eggleton wrote:

On Thursday, 26 July 2018 11:16:02 AM CEST MOHAMMAD RASIM wrote:

I'm trying to build dvb-apps recipe which is blacklisted and was removed
from the newer openembedded releases, but it exist in the release I work
with

Now when I try to build the recipe I get this error:

  >ERROR:
/home/oealliancebuilder/openpli-oe-core/meta-openembedded/meta-multimedia/
recipes-dvb/dvb-apps/dvb-apps_1.1.1.bb
was skipped: Recipe is blacklisted: Fails to build with RSS
http://errors.yoctoproject.org/Errors/Details/130603/ - the recipe will
be removed on 2017-09-01 unless the issue is fixed

But I want to tell openembedded to override the blacklisting and build
the recipe anyway so I can investigate and hopefully fix the recipe. How
can I do that ?

You should be able to just set PNBLACKLIST[dvb-apps] = "" in a
dvb-apps_%.bbappend for the recipe in your own layer, and then the
blacklisting will be disabled for that recipe.

Cheers,
Paul



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

Re: [yocto] How to force build of a blacklisted recipe?

[Max Krummenacher]

Hi

> I'm trying to build dvb-apps recipe which is blacklisted and was removed 
> from the newer openembedded releases, but it exist in the release I work 
> with
> 
> Now when I try to build the recipe I get this error:
> 
>  >ERROR: 
> /home/oealliancebuilder/openpli-oe-core/meta-openembedded/meta-multimedia/recipes-dvb/dvb-
> apps/dvb-apps_1.1.1.bb 
> was skipped: Recipe is blacklisted: Fails to build with RSS 
> http://errors.yoctoproject.org/Errors/Details/130603/ - the recipe will 
> be removed on 2017-09-01 unless the issue is fixed
> 
> But I want to tell openembedded to override the blacklisting and build 
> the recipe anyway so I can investigate and hopefully fix the recipe. How 
> can I do that ?

You could overwrite the assignment to PNBLACKLIST in conf/local.conf:

PNBLACKLIST[dvb-apps] = ""

However, if you anyway want to work on the recipe you could simply delete
the PNBLACKLIST line in the dvb-apps recipe.

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

Re: [yocto] Intel machine with 64 Bit kernel and 32 Bit user space

[Martin Jansa]

It's not as simple as that in some cases, there are some components which
are pulled in 64bit version even when building lib32-foo-image.

Some are easy to override from the config e.g.:
ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
SPLASH = "${LIB32_PREFIX}psplash"

but to prevent building e.g. syslinux in 64bit version is a bit more tricky.

syslinux.bbclass was fixed long time ago:
commit c8dc421ea18bb7a810501ab6d07efa9c8f6d6eb9
Author: Ming Liu 
Date:   Thu Jun 19 16:42:58 2014 +0800

syslinux.bbclass: Ensure MLPREFIX is applied to depends flag

Add MLPREFIX to depends flag to ensure the correct syslinux is
dependended upon.

-do_bootimg[depends] += "syslinux:do_populate_sysroot \
+do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \

but wic still depends on syslinux without MLPREFIX:

meta/conf/machine/qemux86-64.conf:do_image_wic[depends] +=
"syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
mtools-native:do_populate_sysroot dosfstools-nat...
meta/conf/machine/qemux86.conf:do_image_wic[depends] +=
"syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
mtools-native:do_populate_sysroot dosfstools-native...

similarly opkg-utils and some other components are pulled in the
not-prefixed version even when building image with a prefix. I've
eventually got it working with morty (that it was really building only
couple 64bit recipes, mostly kernel and recipes providing external modules
and e.g. depmodwrapper-cross), but it's kind of shaky and error prone, I'll
send fixes for some of these issues, but as we're using morty it's more
complicated to find out what is still needed and what was resolved in newer
OE already.

And there are the issues with allarch recipes mentioned in the other
multilib thread.

Regards,


On Thu, Jul 26, 2018 at 5:59 PM Mark Hatle  wrote:

> On 7/26/18 10:19 AM, Alexander Kanavin wrote:
> > 2018-07-26 14:56 GMT+02:00 Ayoub Zaki :
> >> Is it possible to define a MACHINE configuration with a 64 Bit kernel
> and 32
> >> Bit user space ?
> >>
> >> The user space should not be using a  x32 ABI.
> >
> > I think (but I am not sure), that you can do it with multilib. Define
> > a configuration like this:
> >
> https://github.com/openembedded/openembedded-core/blob/master/meta-skeleton/conf/multilib-example.conf
> >
> > Then build lib32-core-image-minimal. That image should include only 32
> > bit user space, but the kernel will be 64 bit.
>
> Yes this is the typical approach.  Enable multilibs, and then build the
> image
> you you want with the approach multilib prefix.
>
> This works in any multilib configurations, 64-bit, 32-bit, x32, etc..
>
> --Mark
>
> > 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

[yocto] custom linux kernel recipe fails

[Steve Pavao]

Hello -

I’m trying to build using a custom 64-bit kernel at head of sumo, but I get an 
error.  It seems that SRCPV cannot be resolved.Please send any ideas you 
may have about how I may adapt my recipe to get it to work.

Normally, I use the default meta-raspberrypi kernel, but for this build, I am 
using PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom” in my local.conf

My simple kernel recipe is in linux-yocto-custom.bb.  (It is based on the 
example recipe).

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

PV = "${LINUX_VERSION}+git${SRCPV}"
PR = "r0"

LINUX_VERSION ?= "4.14.4"
LINUX_VERSION_EXTENSION_append = "-xenomai-ipipe-arm64"

SRC_URI = 
"http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1";
SRCREV = "133bbf97672ff6e72fc21784b8ae44b194b76626"
SRC_URI[md5sum] = "a5cb3babd85a94fda2905cc3db5e7825"

COMPATIBLE_MACHINE = "raspberrypi3-64"

the error:

WARNING: 
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
 Exception during build_dependencies for PKG_kernel-base
WARNING: 
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
 Error during finalise of 
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
ERROR: ExpansionError during parsing 
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable PKG_kernel-base, 
expression was 
kernel-${@legitimize_package_name('${@get_kernelversion_headers('/data/development/lfs/yocto/build/spark/raspberrypi3-64/tmp/work/raspberrypi3_64-poky-linux/linux-yocto-custom/4.14.4+git${SRCPV}-r0/linux-raspberrypi3_64-standard-build')}')}
 which triggered exception SyntaxError: invalid syntax (PKG_kernel-base, line 1)

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

Re: [yocto] Intel machine with 64 Bit kernel and 32 Bit user space

[Mark Hatle]

On 7/26/18 10:19 AM, Alexander Kanavin wrote:
> 2018-07-26 14:56 GMT+02:00 Ayoub Zaki :
>> Is it possible to define a MACHINE configuration with a 64 Bit kernel and 32
>> Bit user space ?
>>
>> The user space should not be using a  x32 ABI.
> 
> I think (but I am not sure), that you can do it with multilib. Define
> a configuration like this:
> https://github.com/openembedded/openembedded-core/blob/master/meta-skeleton/conf/multilib-example.conf
> 
> Then build lib32-core-image-minimal. That image should include only 32
> bit user space, but the kernel will be 64 bit.

Yes this is the typical approach.  Enable multilibs, and then build the image
you you want with the approach multilib prefix.

This works in any multilib configurations, 64-bit, 32-bit, x32, etc..

--Mark

> Alex
> 

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

Re: [yocto] Ordering of anonymous Python functions and task signature calculations

[richard . purdie]

On Thu, 2018-07-26 at 09:22 -0500, Matt Hoosier wrote:
> On Wed, Jul 25, 2018 at 4:58 PM Richard Purdie
>  wrote:
> Your advice about BB_DONT_CACHE does cause reparsing to get
> triggered. I can see that in logs.
>  
> > and that the
> > task dependency exists. You have the dependency above and that is
> > the
> > easier piece to fix.
> 
> But this part I'm not seeing. The variable's value is always
> recalculated (sometimes more than once during a Bitbake run, but
> that's okay because it's idempotent), but the task only re-executes
> if the payload of the .bb file itself has changed. The blurb I wrote
> above:
> 
>   do_install[vardepsalwaysdirty] = " EXTERNALLY_INFLUENCED_VARIABLE "
> 
> is just some nonsense syntax I wrote there to illustrate my point. I
> don't think there's any var flag called "vardepsalwaysdirty". Did you
> have this line in mind when you were saying that I'd already gotten
> the task made dependent on the variable? Or were you just noting that
> the syntactic use of the variable inside of the task should engage
> the normal hash-based task-dependency calculation logic?
>  
> > If the recipe is reparsed, the anon python reruns and the task hash
> > recalculated.
> 
> Is there anything extra I need to do to cause the reparsed variable's
> hash to cascade to the task?

I think I understand what you're asking now. The key thing is:

conf/bitbake.conf:AUTOREV[vardepvalue] = "${SRCPV}"
conf/bitbake.conf:SRCPV[vardepvalue] = "${SRCPV}"

which makes SRCREV/AUTOREV work.

For your specific example you'd want:

EXTERNALLY_INFLUENCED_VARIABLE[vardepvalue] = 
"${EXTERNALLY_INFLUENCED_VARIABLE}"

which will add the value of the variable to the task hash.

Cheers,

Richard

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

Re: [yocto] Intel machine with 64 Bit kernel and 32 Bit user space

[Alexander Kanavin]

2018-07-26 14:56 GMT+02:00 Ayoub Zaki :
> Is it possible to define a MACHINE configuration with a 64 Bit kernel and 32
> Bit user space ?
>
> The user space should not be using a  x32 ABI.

I think (but I am not sure), that you can do it with multilib. Define
a configuration like this:
https://github.com/openembedded/openembedded-core/blob/master/meta-skeleton/conf/multilib-example.conf

Then build lib32-core-image-minimal. That image should include only 32
bit user space, but the kernel will be 64 bit.

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

[yocto] Minutes: Yocto Project Weekly Triage Meeting

[Jolley, Stephen K]

Attendees: Joshua W., Stephen, Richard, Randy, Anuj, Amanda,

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

AR: Stephen – Have a discussion about 2.2.5 and 2.3.5 in next week’s triage.

Thanks,

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


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

Re: [yocto] Ordering of anonymous Python functions and task signature calculations

[Matt Hoosier]

Thanks for the reply.

On Wed, Jul 25, 2018 at 4:58 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Wed, 2018-07-25 at 08:47 -0500, Matt Hoosier wrote:
> > Quite a while ago I wrote the following message:
> > On Tue, Jan 24, 2017 at 11:55 AM Matt Hoosier  > > wrote:
> > > In order to support a use-case that embeds information about the
> > > Git revision of Yocto itself that was used to make a build, I would
> > > like to run some arbitrary Python code and dump the results (Git
> > > SHA1's, tag names, etc) into a Bitbake variable.
> > >
> > > The idea is that the variable would get consumed in a do_install()
> > > task to populate some cookie-crumb file in the package payload.
> > >
> > > Something like:
> > >
> > >   DEPENDS = "git-native"
> > >
> > >   python () {
> > > # This pseudocode isn't strictly functional for invoking Git,
> > > but you get the idea
> > > d.setVar('GIT_INFO', subprocess.Popen(['git', 'rev-list',
> > > ...]).communicate().stdout)
> > >   }
> > >
> > >   do_install () {
> > > install -d ${D}/etc
> > > echo "${GIT_INFO}" > ${D}/etc/git-info.txt
> > >   }
> > >
> > > This all works on a fresh run, but Bitbake appears not to be
> > > evaluating the anonymous Python function on each execution. This
> > > leads it to have out-of-date information about the Git working copy
> > > when global state changes but happens not to impact the particular
> > > recipe holding this logic.
> > >
> > >
> >
> > The replies given at the time were very helpful in letting me
> > accomplish my immediate goals, but I never really did get to the
> > bottom of the real question:
> >
> > > Is there any trick available to cause the Python function to
> > > execute (and hence update the value of ${GIT_INFO} each Bitbake
> > > execution so that the up-to-the-moment contents of it filter into
> > > the calculation of the signature for do_install()? Or am I just
> > > trying a wrong-headed approach and doing something illegitimate?
> > >
> >
> > Some build systems I know of [1] that are based on hashes rather than
> > timestamps have a way that you can inform the task execution engine
> > to always poison the inputs to a certain task's up-to-dateness check.
> > Is there anything in Bitbake that would allow a declaration to force
> > such-and-such variable in a recipe always to be re-evaluated:
> >
> >   EXTERNALLY_INFLUENCED_VARIABLE = "${@int(random.random() * 10)}"
> >   do_install[vardepsalwaysdirty] = " EXTERNALLY_INFLUENCED_VARIABLE "
> >
> >   do_install() {
> > echo '${ EXTERNALLY_INFLUENCED_VARIABLE }' > ${D}/etc/stuff.txt
> >   }
> >
> > Don't read too much into the example calling random() here. That's
> > not really what I want to do; the point is just that the variable's
> > value (though deterministic) isn't computed strictly from Bitbake
> > metadata. So I'm searching for a way to get the value of
> > EXTERNALLY_INFLUENCED_VARIABLE to be re-computed each time Bitbake
> > starts. If the computed value ends up matching what was seen on the
> > last execution, then any dependent tasks wouldn't need re-run.
> >
> > Any ideas?
> >
> > [1] I'm thinking particularly of Waf's hash-based task graph, which
> > supports annotations that can be used to always cause a task to be
> > re-run even if all the inputs feeding into it appear up-to-date.
>
> From a bitbake perspective there are two things you need to ensure
> here, that the recipe gets reparsed at every execution


Your advice about BB_DONT_CACHE does cause reparsing to get triggered. I
can see that in logs.


> and that the
> task dependency exists. You have the dependency above and that is the
> easier piece to fix.
>

But this part I'm not seeing. The variable's value is always recalculated
(sometimes more than once during a Bitbake run, but that's okay because
it's idempotent), but the task only re-executes if the payload of the .bb
file itself has changed. The blurb I wrote above:

  do_install[vardepsalwaysdirty] = " EXTERNALLY_INFLUENCED_VARIABLE "

is just some nonsense syntax I wrote there to illustrate my point. I don't
think there's any var flag called "vardepsalwaysdirty". Did you have this
line in mind when you were saying that I'd already gotten the task made
dependent on the variable? Or were you just noting that the syntactic use
of the variable inside of the task should engage the normal hash-based
task-dependency calculation logic?


>
> If the recipe is reparsed, the anon python reruns and the task hash
> recalculated.
>

Is there anything extra I need to do to cause the reparsed variable's hash
to cascade to the task?


>
> If a recipe sets BB_DONT_CACHE, it will be reparsed upon each run and
> the hashes will dynamically change as you want. BB_SRCREV_POLICY !=
> "cache" uses that behind the scenes so that it can dynamically update
> srcrevs.
>
> Hope that helps...
>
> Cheers,
>
> Richard
>
>

Thanks! -Matt
-- 
___
yocto mailing list
yocto@yoctoprojec

Re: [yocto] can bitbake build offline ?

[MOHAMMAD RASIM]

Wow that's a cool trick and it worked for me so ,thank you.

Also after some digging I found a solution that does exactly what I 
described in my previous message(I think), and I'm gonna leave it here 
in case someone face the same issue and find this message:


You can use set BB_SRCREV_POLICY = "cache" the local.conf which will 
prevent the AUTOREV recipes from failing by using the local cache for 
revisions


https://www.yoctoproject.org/docs/2.1/bitbake-user-manual/bitbake-user-manual.html#var-BB_SRCREV_POLICY

But If there is a new commits on the remote repo you probably need to 
disable this and rebuild to let bitbake fetch the latest revision and 
you can re enable it afterwards.



Regards


On 07/26/2018 01:40 PM, Paul Eggleton wrote:

On Thursday, 26 July 2018 12:09:46 PM CEST MOHAMMAD RASIM wrote:

Well, actually I used the find command in that wiki page to find the
recipe that uses tag name to chose github revision and it found only one
recipe

  >meta-openembedded/meta-initramfs/recipes-devtools/mtd/ubi-utils-
  >klibc_1.5.1.bb

Hmm, right, it seems like you're using a previous branch - this got fixed
in a later update of that recipe.


I masked this recipe in the local.conf file and bitbake failed at
parsing other recipes, looking at those recipes I saw that they don't
use tag names but they use

  >SRCREV = "${AUTOREV}"

which is logical since bitbake has to issue ls-remote to know what is
the latest revision on the remote git repo (maybe the wiki page needs
update to point this ?)

Now I can't remove this AUTOREV in these recipes since I need bitbake to
fetch the latest updates ( I push updates regularly on that repo and I
don't want to update the recipe file each time to add the latest revision)

So, here comes the hard part, Is it possible to tell bitbake to issue
ls-remote if there is network and to use the latest fetched revision in
the sources directory if the network is disabled ? that way I can use
${AUTOREV} in my recipes and bitbake will build from the local repo in
the sources directory unless there is network to update the local repo,
probably there is no such thing :) .

So there isn't a mechanism to do exactly that, no, however you can sort of
achieve the same thing if you set up a .inc file that sets the SRCREV values
for each recipe and sets BB_NO_NETWORK at the same time (though the
latter could still be separate). e.g. let's call it no_network.inc:

BB_NO_NETWORK = "1"
SRCREV_pn-abc = "b4c2bd84ee6f699e348d602a82d2d0963384cdea"
SRCREV_pn-xyz = "e3b30def2cd1c9ede7630489c3949a45b6eba6ee"
..

Then to build offline you would just add the following to your config:

require no_network.inc

FYI you can enable buildhistory and use the buildhistory-collect-srcrevs
script to generate all those SRCREV lines so you don't have to do that
by hand:

https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#maintaining-build-output-quality

Cheers,
Paul



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

[yocto] Intel machine with 64 Bit kernel and 32 Bit user space

[Ayoub Zaki]

Hi list,

Is it possible to define a MACHINE configuration with a 64 Bit kernel and
32 Bit user space ?

The user space should not be using a  x32 ABI.


Thank you!

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

Re: [yocto] How to force build of a blacklisted recipe?

[Paul Eggleton]

On Thursday, 26 July 2018 11:16:02 AM CEST MOHAMMAD RASIM wrote:
> I'm trying to build dvb-apps recipe which is blacklisted and was removed 
> from the newer openembedded releases, but it exist in the release I work 
> with
> 
> Now when I try to build the recipe I get this error:
> 
>  >ERROR: 
> /home/oealliancebuilder/openpli-oe-core/meta-openembedded/meta-multimedia/
> recipes-dvb/dvb-apps/dvb-apps_1.1.1.bb 
> was skipped: Recipe is blacklisted: Fails to build with RSS 
> http://errors.yoctoproject.org/Errors/Details/130603/ - the recipe will 
> be removed on 2017-09-01 unless the issue is fixed
> 
> But I want to tell openembedded to override the blacklisting and build 
> the recipe anyway so I can investigate and hopefully fix the recipe. How 
> can I do that ?

You should be able to just set PNBLACKLIST[dvb-apps] = "" in a 
dvb-apps_%.bbappend for the recipe in your own layer, and then the 
blacklisting will be disabled for that recipe.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] can bitbake build offline ?

[Paul Eggleton]

On Thursday, 26 July 2018 12:09:46 PM CEST MOHAMMAD RASIM wrote:
> Well, actually I used the find command in that wiki page to find the 
> recipe that uses tag name to chose github revision and it found only one 
> recipe
> 
>  >meta-openembedded/meta-initramfs/recipes-devtools/mtd/ubi-utils-
>  >klibc_1.5.1.bb

Hmm, right, it seems like you're using a previous branch - this got fixed
in a later update of that recipe.

> I masked this recipe in the local.conf file and bitbake failed at 
> parsing other recipes, looking at those recipes I saw that they don't 
> use tag names but they use
> 
>  >SRCREV = "${AUTOREV}"
> 
> which is logical since bitbake has to issue ls-remote to know what is 
> the latest revision on the remote git repo (maybe the wiki page needs 
> update to point this ?)
> 
> Now I can't remove this AUTOREV in these recipes since I need bitbake to 
> fetch the latest updates ( I push updates regularly on that repo and I 
> don't want to update the recipe file each time to add the latest revision)
> 
> So, here comes the hard part, Is it possible to tell bitbake to issue 
> ls-remote if there is network and to use the latest fetched revision in 
> the sources directory if the network is disabled ? that way I can use 
> ${AUTOREV} in my recipes and bitbake will build from the local repo in 
> the sources directory unless there is network to update the local repo, 
> probably there is no such thing :) .

So there isn't a mechanism to do exactly that, no, however you can sort of
achieve the same thing if you set up a .inc file that sets the SRCREV values
for each recipe and sets BB_NO_NETWORK at the same time (though the
latter could still be separate). e.g. let's call it no_network.inc:

BB_NO_NETWORK = "1"
SRCREV_pn-abc = "b4c2bd84ee6f699e348d602a82d2d0963384cdea"
SRCREV_pn-xyz = "e3b30def2cd1c9ede7630489c3949a45b6eba6ee"
..

Then to build offline you would just add the following to your config:

require no_network.inc

FYI you can enable buildhistory and use the buildhistory-collect-srcrevs 
script to generate all those SRCREV lines so you don't have to do that
by hand:

https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#maintaining-build-output-quality

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] can bitbake build offline ?

[MOHAMMAD RASIM]

Well, actually I used the find command in that wiki page to find the 
recipe that uses tag name to chose github revision and it found only one 
recipe


>meta-openembedded/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.1.bb

I masked this recipe in the local.conf file and bitbake failed at 
parsing other recipes, looking at those recipes I saw that they don't 
use tag names but they use


>SRCREV = "${AUTOREV}"

which is logical since bitbake has to issue ls-remote to know what is 
the latest revision on the remote git repo (maybe the wiki page needs 
update to point this ?)


Now I can't remove this AUTOREV in these recipes since I need bitbake to 
fetch the latest updates ( I push updates regularly on that repo and I 
don't want to update the recipe file each time to add the latest revision)


So, here comes the hard part, Is it possible to tell bitbake to issue 
ls-remote if there is network and to use the latest fetched revision in 
the sources directory if the network is disabled ? that way I can use 
${AUTOREV} in my recipes and bitbake will build from the local repo in 
the sources directory unless there is network to update the local repo, 
probably there is no such thing :) .


Thanks


On 07/26/2018 09:26 AM, Paul Eggleton wrote:

Hi Mohammad,

If it's failing during parsing that means you still have a recipe that does
not have a proper SRCREV set, which you need to fix as described by the page
that Alex linked. The error will be reporting which recipe that is.

Cheers,
Paul

On Thursday, 26 July 2018 5:44:26 AM CEST MOHAMMAD RASIM wrote:

I tried that and bitbake still fails when disabling the network


On 07/21/2018 11:42 AM, Alexander Kanavin wrote:

This page has a tip on what might be causing 'git ls-remote':

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

How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F

Alex

2018-07-21 10:32 GMT+02:00 MOHAMMAD RASIM :

Hi, is there a way I can run a bitbake build offline? I have all the
required sources of the target in the sources directory, and I have built
the target multiple times with internet connection, but when I build

offline

it fails because it needs internet access during parsing recipes.
Can I tell bitbake to skip running `git ls-remote` during parsing recipes

so

I can build offline?

Thanks
--
___
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] How to force build of a blacklisted recipe?

[MOHAMMAD RASIM]

Hi,

I'm trying to build dvb-apps recipe which is blacklisted and was removed 
from the newer openembedded releases, but it exist in the release I work 
with


Now when I try to build the recipe I get this error:

>ERROR: 
/home/oealliancebuilder/openpli-oe-core/meta-openembedded/meta-multimedia/recipes-dvb/dvb-apps/dvb-apps_1.1.1.bb 
was skipped: Recipe is blacklisted: Fails to build with RSS 
http://errors.yoctoproject.org/Errors/Details/130603/ - the recipe will 
be removed on 2017-09-01 unless the issue is fixed


But I want to tell openembedded to override the blacklisting and build 
the recipe anyway so I can investigate and hopefully fix the recipe. How 
can I do that ?


Thanks

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