Tracked down the problem to the fact that conflict checking in RPM 5.4.16 in
Morty is broken.
Backported some changes from upstream and it is working for me now (i.e.,
detecting and
reporting the conflict.)
MV
From: Vuille, Martin (Martin)
Sent: March 09, 2018 20:50
To: yocto@yoctoproject.org
Ran into an issue where we have two packages installing different
content for the same file in rootfs. Whichever gets installed last "wins".
I thought there was a check to prevent this. I'm sure I've seen a
warning/error like that in the past.
Is this condition detected? Should it be?
We're
Transitioning from Fido to Morty
Noticed that there now QA warnings for packages with incorrect names.
But it seems these warnings only show up in tmp/qa.txt, they are not displayed
in the build output.
Is that a bug or intentional? Is there a way to make them appear in the
build output?
MV
--
In the process of transitioning from Fido to Morty.
In the past, when sanity detected a version mismatch with some of
the configuration files (e.g., local.conf, bblayers.conf,) an error message
was displayed.
Now, we see the below, which I do not find very informative or helpful.
Is that a bug
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
>
> On 28 November 2016 at 15:02, Vuille, Martin (Martin)
> <vmar...@avaya.com> wrote:
> Or am I completely off-track?
>
> It will track the md5 of files mentioned in SRC_URI,
I have a custom recipe for building some peculiarly-structured code:
the Makefile is compiling source from ${S}/.. (i.e., parent directory of
the ${S} directory).
It seems (not 100% sure of this, sstate is still "magic" to me) that the sstate
hash only includes the files in ${S} (which is
Currently using Yocto 1.8, planning upgrade to 2.2
Per the Reference Manual, "The uninative class is now enabled by default in
Poky. [...]
With this class enabled, a tarball containing a pre-built C library is
downloaded at the start of the build."
We have to build with BB_NO_NETWORK = "1"
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
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?
MV
--
___
yocto
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: November 07, 2016 12:37
>
> On 11/7/16 9:27 AM, Vuille, Martin (Martin) wrote:
> > I see that “sysvinit” and “systemd” style init is supported.
> >
> >
> >
> > Is there support for
I see that "sysvinit" and "systemd" style init is supported.
Is there support for BSD-style init, or some other minimal init?
Does anyone know of such support in a separate layer?
MV
--
___
yocto mailing list
yocto@yoctoproject.org
Has there ever been any discussion of making select releases
"Long Term Support" releases, i.e., committing to support them
for a number of years?
Presumably that would entail having the resources to commit
a maintainer to that release for the LTS interval.
Out of curiosity, how much effort is
Thank you for the quick answer
MV
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: November 01, 2016 11:28
To: Vuille, Martin (Martin); Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto 2.2 Morty supported Linux Distros
On 1 November 2016 at 15:19, Vuille, Martin
Noticed that Ubuntu 16.04 LTS is not on the list of supported
distributions for Morty.
Is that correct/intentional, or a documentation oversight?
Ubuntu 16.04 is mentioned elsewhere in the docs.
We are planning to upgrade from Ubuntu 12.04 LTS and it would
make more sense to go to the latest LTS
I should clarify that these build machines are not for Yocto builds,
but for building an application that uses the Yocto SDK.
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Vuille, Martin (Martin)
Sent: October 31, 2016 10:38
To: yocto@yoctoproject.org
We are looking at upgrading from Yocto 1.8 to 2.2.
Yocto 2.2 has a minimum kernel requirement of 3.2.0.
This isn't an issue for our target (ARMv5, Linux 4.4) but may be
an issue for our automated build machines (x86, Linux 2.6.32-CentOS 6.)
However, there is a note that says
"For x86 and
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: January 19, 2016 1:58 PM
>
> its a distro policy based upon licensing if weak assignment is used then the
> licensing won’t be able to enforce the decision
> if someone overrides it.
Thanks, that makes sense.
MV
--
Yocto Fido
I am trying to use PREFERRED_VERSION to select an earlier version
of the "db" package. The build includes both db and db-native variants
of the package.
I set PREFERRED_VERSION_db variable and this successfully changes
the version of the db package but not the db-native package.
I
in a "wrapper" header and make your
customizations in the wrapper instead?
Regards,
MV
> -Original Message-
> From: Longchamp, Valentin [mailto:valentin.longch...@keymile.com]
> Sent: December 10, 2015 4:47 AM
> To: Vuille, Martin (Martin); yocto@yoctoproject.or
Hi Valentin,
Not sure whether this the “canonical” Yocto way, but here’s how we solved
the same issue.
First, let me say that we use a BSP from our technology partner, and have
our own meta-XXX layer for customization.
- Created a .bbappend in our layer for the kernel recipe
-
What is the best way to refer to (require) a .inc recipe
in one layer from another layer?
MV
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
In my custom .bbclass, I have a python function
python whatever () {
...
}
and I would like to call it from a shell function
do_something () {
...
whatever
...
}
but bitbake gives me an error "whatever: not found" when building
recipes based on this class
Is what I am trying
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: October 14, 2015 1:25 PM
>
>
> > On Oct 14, 2015, at 9:25 AM, Vuille, Martin (Martin) <vmar...@avaya.com>
> > wrote:
> >
> > Hi,
> >
> > I am having a bit of trouble understanding so
Hi,
I am having a bit of trouble understanding something about
packaging.
I have a custom recipe to build a package that contains both
a daemon executable and a shared object interface library
for the daemon.
But the .so is only packaged in ${PN}-dev, not ${PN}, so
it doesn't end up on the
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: June 03, 2015 3:42 AM
On Tuesday 02 June 2015 19:58:50 Vuille, Martin wrote:
Yocto 1.6.1
I have added a module to my kernel.
The module is getting built, I see a kernel-module-blah-blah RPM
I see that depmod/depmodwrapper is being run in a postinst
script in kernel.bbclass.
I need to adjust the contents of modules.alias after it has been
generated.
Can someone suggest what would be the right way to do this?
MV
--
___
yocto mailing list
module by changing modules.alias line
from alias net-pf-10 ipv6 to alias net-pf-10 off
Any suggestions how to do this?
MV
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Vuille, Martin (Martin)
Sent: May 08, 2015 4:04 PM
To: yocto@yoctoproject.org
Subject
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: March 25, 2015 9:09 AM
On Tue, 2015-03-24 at 22:22 +, Vuille, Martin (Martin) wrote:
Is there a better way to suppress populate_sysroot without breaking
setscene?
Define an empty sysroot_stage_dirs function
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: March 25, 2015 9:51 AM
Just define the empty sysroot_stage_dirs, not populate_sysroot. The
stage_dirs function handles copying files so if its empty, no files will be
copied in.
Thanks, Richard, works fine!
MV
--
Poky Daisy 1.6.1
I have a custom package of font files and a custom recipe to install then
into ${libdir}/fonts.
I don't want these files in the sysroot, as they are not necessary there,
they are only required on the target, and they make the SDK larger.
In my recipe, I defined an empty
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: March 09, 2015 4:47 PM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Daisy 1.6.1 on CentOS 6.5
On Mar 9, 2015, at 1:36 PM, Vuille, Martin (Martin)
vmar...@avaya.commailto:vmar...@avaya.com wrote:
The Yocto
The Yocto 1.6.1 Project Reference Manual states that it is supported and tested
against CentOS release 6.5, but later states that Python 2.7.3 is required,
CentOS 6.5
seems to have an older version of Python (2.6.6).
The build does not, in fact, work and complains that the version of Python is
Poky Daisy 1.6.1
We have to fetch a git repo using https protocol. We are looking to
see whether we can change this to ssh instead, but that is not
possible at the moment.
Access requires a userid and password. We do not want to hard-code
the credentials into the recipe or into some other file
Poky Daisy 1.6.1
I have a recipe that must fetch from a git repo using https. I have specified
;protocol=https in the SRC_URI.
The fetch task for this recipe is failing with:
ERROR: Fetcher failure: Fetch command failed with exit code
128, output:
Cloning into
I have read the information at
https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance
I would like to know how long stable branches are maintained.
If we are using daisy (1.6), how long can we count on point releases with
security patches before we should plan to upgrade to a newer
We build Qt4-embedded and export the headers and libraries
into the SDK for the application to build against.
We also include nativesdk-qt4-tools in the SDK.
The application team is saying that they also need the mkspecs,
and those are not included in the SDK.
Are the mkspecs supposed to be
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 06, 2014 5:16 AM
This is a slightly different symptom of the same underlying problem, yes.
I have filed a bug report in Yocto Bugzilla
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of Vuille, Martin (Martin)
Sent: November 04, 2014 5:02 PM
It's as though bitbake is not seeing my changes.
I deliberately introduced syntax errors into the packagegroup .bb
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 05, 2014 5:56 AM
I deliberately introduced syntax errors into the packagegroup .bb file
What kind of syntax error? Inside a function or outside?
This is my packagegroup .bb file as it
-Original Message-
From: Vuille, Martin (Martin)
Sent: November 05, 2014 5:53 AM
I deliberately introduced syntax errors into the packagegroup .bb file
bitbake image does not report any error bitbake packagegroup does
not report any error
Indeed it appears
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of Vuille, Martin (Martin)
Sent: November 05, 2014 7:35 AM
Indeed it appears that the packagegroup.bb file is not being read.
But bitbake packagegroup -e does re-parse
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 05, 2014 10:10 AM
So it does appear to be cache related, but I just tried creating a similar
packagegroup here and even set SDKMACHINE and could not reproduce the
problem, adding the same
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 05, 2014 10:23 AM
OK, so perhaps this wasn't the best idea after all - I think what's happened
there is that part of the cache is there and the other part now isn't. Instead
of moving that
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 05, 2014 10:29 AM
No, you really don't need to do a complete rebuild. This is a cache problem,
if
you have properly removed the cache the issue (at least the latest errors)
will go away.
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 05, 2014 10:36 AM
Rather than removing or renaming
/home/platform/Workspace/somename/poky/build/tmp/cache/default-
eglibc/sonic/i686, you should remove/rename the cache directory above it
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Same result
If by same result you mean you are still getting these errors, something
very strange is going on.
Yes, that's what I mean. Yes, very strange.
I know I kind of asked this before, but
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 05, 2014 11:04 AM
I don't recall you asking this before, and I certainly never checked.
Yeah, I should really have asked the above, instead I asked about what script
you started the
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 05, 2014 11:04 AM
OK, so this kind of explains it. To be perfectly honest the bitbake memory
resident functionality (which Toaster uses behind the scenes) does have
some holes in picking up
I reported a similar issue a few days ago, but at the time I did not
know how to collect the relevant information to help diagnose the
issue. Hopefully I did better this time.
I have an image that lists several packagegroups in IMAGE_INSTALL.
I updated one of the packagegroups by adding a new
Poky 1.6.1 / daisy
I have a variable REV_TOOLS defined in distro/conf/somename.conf in a
custom distro layer from a git repo.
This variable is assigned to SRCREV in a number of recipes (SRCREV =
${REV_TOOLS})
for packages included in my images and SDKs.
Pulled an update to the distro layer
Hi Paul,
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Hi Martin,
On Saturday 01 November 2014 15:57:34 Vuille, Martin wrote:
Yocto 1.6.1 / daisy
I'm making the transition from denzil/1.2 to daisy.
I have converted tasks from 1.2 to
Hi Paul,
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 03, 2014 9:13 AM
On Monday 03 November 2014 12:53:23 Vuille, Martin wrote:
Poky 1.6.1 / daisy
I have a variable REV_TOOLS defined in distro/conf/somename.conf in
a custom
Hi Belén,
-Original Message-
From: Barros Pena, Belen [mailto:belen.barros.p...@intel.com]
Sent: November 03, 2014 9:12 AM
Hi Martin,
You probably found this already, but just in case. The instructions to set up
Toaster:
https://wiki.yoctoproject.org/wiki/Toaster
When you
I have a package named foo-Bar built by a recipe foo-Bar_1.0.0.bb.
Just noticed in Toaster that for that package it is reporting the package
name as foo- instead of foo-Bar.
Is that a bug in Toaster or a restriction on package names?
MV
--
___
yocto
-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
Sent: November 03, 2014 9:13 AM
I honestly don't know how to explain this behaviour either, because it
should not happen this way. BitBake automatically extracts variable
references within variable values
Hi Richard,
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: November 03, 2014 10:06 AM
On Mon, 2014-11-03 at 12:53 +, Vuille, Martin (Martin) wrote:
I have a variable “REV_TOOLS” defined in distro/conf/somename.conf in
a custom
Hi Martin,
-Original Message-
From: Martin Jansa [mailto:martin.ja...@gmail.com]
Sent: November 03, 2014 11:05 AM
On Mon, Nov 03, 2014 at 03:09:43PM +, Vuille, Martin (Martin) wrote:
Hi Richard,
-Original Message-
From: Richard Purdie [mailto:richard.pur
I am using Poky daisy / Yocto 1.6.1
Occasionally, when building a custom image or SDK after changing
a package recipe or package content, I find that the do_rootfs task is not
executed for the image or the do_populate_sdk task is not executed
for the sdk.
There are custom classes, packages,
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of Bob Cochran
Sent: November 01, 2014 9:08 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] How to debug dependency/setscene/sstate issues
Won't Toaster give you the
Yocto 1.6.1 / daisy
I'm making the transition from denzil/1.2 to daisy.
I have converted tasks from 1.2 to packagegroups.
Something is not working properly, and perhaps I am doing
something wrong, or perhaps my expectations are incorrect.
My image recipes refer to my package groups in
I have custom classes that override a task thus (in foo.bbclass)
foo_do_something () {
...
}
EXPORT_FUNCTIONS do_something
but if I change the name to foo-bar.bbclass and change the class thus
foo-bar_do_something () {
...
From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Christopher
Larson
- isn't a valid character in a shell function, so while potentially
irritating, it's not surprising :)
Hmm, good point! Thanks
MV
--
___
yocto mailing list
Trying to make the transition from denzil (1.2) to daisy (1.6.1) and have
run into a problem that's got me stumped.
There seems to have been a change in the way things are packaged that
is breaking a number of my custom recipes.
Let's say I have a package X that consists of source for an .so and
Trying to make the transition from denzil (1.2) to daisy (1.6.1) and have
run into a problem that's got me stumped.
There seems to have been a change in the way things are packaged that
is breaking a number of my custom recipes.
Let's say I have a package X that consists of source for an
After successfully building an image, the second and subsequent
attempts at building the image were failing with a python OSError:
File exists exception in do_rootfs.
Even bitbake image -c clean did not fix the problem.
Eventually tracked it down to IMAGE_LINK_NAME having been
configured as
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: October 24, 2014 4:32 AM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] autotools-brokensep.bbclass not working
so seperatebuilddir.inc is overriding the use
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: October 24, 2014 4:35 AM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] QA Issue for recipe inheriting from native.bbclass
On Thu, 2014-10-23 at 16:58 +
I have a recipe that inherits from meta/classes/native.bbclass
I am getting an ERROR: QA Issue: for this recipe:
Variable RPROVIDES is set as not being package specific, please fix this.
which, as far as I can tell, is due to the RPROVIDES assignment in
native.bbclass
Is this a bug? Is the
(Using daisy/1.6.1)
I need to build an older version of dhcp because of some
custom functionality that was patched into the client.
That version of dhcp does not support ${B} != ${S}. So I
changed the recipe to inherit autotools-brokensep instead
of inheriting autotools.
But this has no
We're planning an update to Dizzy, and to keep up-to-date after that.
Thanks for your help
MV
-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: September 26, 2014 5:55 PM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Forcing
address
my issue of having to manually force a fetch/unpack every
time the source changes.
Perhaps due to my old versions: Poky 1.2 and bitbake 1.15.1?
MV
-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: September 22, 2014 7:34 AM
To: Vuille, Martin (Martin
I was afraid of that...
Another good reason to upgrade.
Will try the work-around.
Thanks again!
MV
-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: September 23, 2014 9:33 AM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto
-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: September 23, 2014 9:33 AM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Forcing fetch task when source changes
On 23 September 2014 13:46, Vuille, Martin (Martin) vmar
I have defined a class with a customized fetch task (that
copies files from a local read-only directory to the ${S}
directory).
I am looking for a way to cause the fetch task to run
again whenever the contents of the local directory
change w.r.t. what was last fetched/copied to ${S}.
Is there a
, 2014 7:34 AM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Forcing fetch task when source changes
On 22 September 2014 12:25, Vuille, Martin (Martin) vmar...@avaya.com
wrote:
I have defined a class with a customized fetch task (that
copies files from a local
I have defined a class with a customized fetch task (that
copies files from a local directory to the ${S} directory).
I am looking for a way to cause the fetch task to run
whenever the contents of the local directory change
w.r.t. what was last fetched/copied to ${S}.
Seems to me that I could do
Migrating from LDAT to Yocto, and wondering whether
there is an equivalent to LDAT's fs_final.sh script?
The objective is to do some post-processing on the
rootfs tree before it is packaged into the UBIFS image.
MV
--
___
yocto mailing list
Exactly what I am looking for.
Thanks!
MV
-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: May 05, 2014 12:34 PM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Migrating LDAT fs_final.sh to Yocto
On Mon, May 5, 2014 at 6:34 AM
I have a custom layer to add patches to my vendor's BSP layer
(based on Linux 3.4, if it matters) and a .bbappend to list the
patches.
One of the patches adds a header, and this header needs to
be exported to the sysroot.
I added the following to my .bbappend, based on a discussion
I found:
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: April 24, 2014 1:32 PM
On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote:
I have a custom layer to add patches to my vendor's BSP layer
(based on Linux 3.4, if it matters) and a .bbappend to list the
patches.
One
From: Bruce Ashfield
Sent: April 24, 2014 2:01 PM
To: Vuille, Martin (Martin); yocto@yoctoproject.org
Subject: Re: [yocto] Exporting kernel header from patch
On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote:
From: Bruce Ashfield
Sent: April 24, 2014 1:32 PM
On 14-04-24 11:57 AM
From: Bruce Ashfield
Sent: April 24, 2014 4:06 PM
To: Vuille, Martin (Martin); yocto@yoctoproject.org
Subject: Re: [yocto] Exporting kernel header from patch
On 14-04-24 03:54 PM, Vuille, Martin (Martin) wrote:
From: Bruce Ashfield
Sent: April 24, 2014 2:01 PM
To: Vuille, Martin
82 matches
Mail list logo
