Re: [oe] Reports for CVE triage
Hi, On Thu, 2024-07-04 at 11:02 +0200, Jacoba Brandner via lists.openembedded.org wrote: > This email contains a review of the remaining CVEs from the status > list: https://autobuilder.yocto.io/pub/non-release/patchmetrics-meta- > oe/cve-status-master.txt > This work is done as part of "Milestones 3, 4, 5 and 6. Triage CVEs" > as stated in the Scope of Work with Sovereign Tech Fund (STF) > (https://www.sovereigntechfund.de/). > > The reports are saved as HTML files here: > - Milestone 3: https://clients.neighbourhood.ie/yocto/81-120.html > - Milestone 4: https://clients.neighbourhood.ie/yocto/121-160.html > - Milestone 5: https://clients.neighbourhood.ie/yocto/161-200.html > - Milestone 6: https://clients.neighbourhood.ie/yocto/201-221.html > > The reports contains a review of the CVEs including the following: > - Package versions affected > - Current package version on 'meta-openembedded' > - Notes on how the CVE can be addressed > > Please note that for the CVEs marked as 'invalid', separate patch > status updates have been sent to this mailing- > list: openembedded-devel@lists.openembedded.org. > > The collection of all emails we've sent to NIST are saved > here https://clients.neighbourhood.ie/yocto/NIST.html > > We can also provide this in any other format that might be convenient > for you. Please let us know. I had a look into this. Firstly, I wanted to say a huge thanks for working through this, you're doing a great job! Getting the status of CVEs sorted out, particularly the older ones makes a huge difference to the clarity of the security situation of our codebase. We can see the status of our codebase here: https://autobuilder.yocto.io/pub/non-release/patchmetrics-meta-oe/ You can see we've gone from around 271 CVEs at the start to having 136 currently listed. When I looked at the list of open CVEs, a few did catch my eye, particularly the 24 still open against imagemagick. I can see many were already excluded in the recipe, based upon the CPE needing an update and I appreciate you've sent emails to get the NVD entry tweaked: https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/imagemagick/imagemagick_7.1.1.bb In your report for milestone 4, I see CVE-2014-9822 has a CPE sent for it: https://clients.neighbourhood.ie/yocto/121-160.html but it is listed as being an open issue in the metadata. Was there a reason we don't have the CVE_STATUS[CVE-2014-9822] set in the recipe? There are a few others that are probably in a similar state to this. I suspect there are a few details we need to tweak just to fully ensure the reports reflect all the good work you've done? Thanks again for the work though, there is some really great data here, I just want to ensure our metrics fully reflect it. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#111298): https://lists.openembedded.org/g/openembedded-devel/message/111298 Mute This Topic: https://lists.openembedded.org/mt/107034729/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-*][PATCH] reproducibility: move repro excludes from AB config.json to meta-oe
On Wed, 2024-04-24 at 13:41 +0200, Yoann Congal wrote:
> For now, the known non-reproducible packages list is stored inside
> the
> autobuilder config.json file. This is not ideal. Let's move this list
> into each layers of meta-openembedded.
>
> These lists can be used with, in local.conf:
> include conf/include/non-repro-meta-oe.inc
> OEQA_REPRODUCIBLE_EXCLUDED_PACKAGES = "${KNOWN_NON_REPRO_META_OE}"
>
> Signed-off-by: Yoann Congal
> ---
> Cc: Richard Purdie
> Cc: Khem Raj
> Richard, Khem: The next step will be to move the current AB config to
> use these
> files. And then, continue to cleanup reproducibility errors.
Acked-by: Richard Purdie
Thanks for doing this, this should make issues more visible to people
and easier to update the lists as things change!
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#110123):
https://lists.openembedded.org/g/openembedded-devel/message/110123
Mute This Topic: https://lists.openembedded.org/mt/105708099/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-openembedded] [PATCH 2/2] buildtools-imagemagick: Add new recipe
This is useful on the Yocto Project autobuilder to allow automated
screenshot testing/processing during QA.
Signed-off-by: Richard Purdie
---
meta-oe/recipes-core/meta/buildtools-imagemagick.bb | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 meta-oe/recipes-core/meta/buildtools-imagemagick.bb
diff --git a/meta-oe/recipes-core/meta/buildtools-imagemagick.bb
b/meta-oe/recipes-core/meta/buildtools-imagemagick.bb
new file mode 100644
index 00..d59f7a7a52
--- /dev/null
+++ b/meta-oe/recipes-core/meta/buildtools-imagemagick.bb
@@ -0,0 +1,10 @@
+require recipes-core/meta/buildtools-tarball.bb
+
+SUMMARY = "Standalone tarball of imagemagick binaries"
+LICENSE = "MIT"
+
+# Add nativesdk equivalent of build-essentials
+TOOLCHAIN_HOST_TASK = "nativesdk-imagemagick nativesdk-sdk-provides-dummy"
+TOOLCHAIN_OUTPUTNAME =
"${SDK_ARCH}-buildtools-imagemagick-nativesdk-standalone-${DISTRO_VERSION}"
+
+SDK_TITLE = "Imagemagick tools"
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#109339):
https://lists.openembedded.org/g/openembedded-devel/message/109339
Mute This Topic: https://lists.openembedded.org/mt/104952248/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-openembedded] [PATCH 1/2] imagemagick/lcms/fftw: Allow nativesdk versions to exist
These allow the use of imagemagick in SDKs where it is useful to perform
image analysis such as on the autobuilder for screenshot processing
during QA testing.
Signed-off-by: Richard Purdie
---
meta-oe/recipes-support/fftw/fftw_3.3.10.bb | 2 +-
meta-oe/recipes-support/imagemagick/imagemagick_7.1.1.bb | 2 +-
meta-oe/recipes-support/lcms/lcms_2.16.bb| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta-oe/recipes-support/fftw/fftw_3.3.10.bb
b/meta-oe/recipes-support/fftw/fftw_3.3.10.bb
index 33e8279880..af7117da7b 100644
--- a/meta-oe/recipes-support/fftw/fftw_3.3.10.bb
+++ b/meta-oe/recipes-support/fftw/fftw_3.3.10.bb
@@ -100,4 +100,4 @@ RDEPENDS:${PN}-dev = "libfftw libfftwl libfftwf"
RDEPENDS:${PN}-ptest += "perl"
RDEPENDS:${PN}-ptest:remove = "fftw"
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-oe/recipes-support/imagemagick/imagemagick_7.1.1.bb
b/meta-oe/recipes-support/imagemagick/imagemagick_7.1.1.bb
index dcc951bce8..6ab8a61b9b 100644
--- a/meta-oe/recipes-support/imagemagick/imagemagick_7.1.1.bb
+++ b/meta-oe/recipes-support/imagemagick/imagemagick_7.1.1.bb
@@ -52,7 +52,7 @@ FILES:${PN}-dev +=
"${libdir}/ImageMagick-${BASE_PV}/modules-Q16/*/*.a"
FILES:${PN}-dbg += "${libdir}/ImageMagick-${BASE_PV}/modules-Q16/*/.debug/*"
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
ALTERNATIVE_PRIORITY = "100"
diff --git a/meta-oe/recipes-support/lcms/lcms_2.16.bb
b/meta-oe/recipes-support/lcms/lcms_2.16.bb
index 10c1994a7e..8135f83a05 100644
--- a/meta-oe/recipes-support/lcms/lcms_2.16.bb
+++ b/meta-oe/recipes-support/lcms/lcms_2.16.bb
@@ -8,7 +8,7 @@ SRC_URI[sha256sum] =
"d873d34ad8b9b4cea010631f1a6228d2087475e4dc5e763eb81acc23d9
DEPENDS = "tiff"
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
S = "${WORKDIR}/lcms2-${PV}"
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#109338):
https://lists.openembedded.org/g/openembedded-devel/message/109338
Mute This Topic: https://lists.openembedded.org/mt/104952247/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [yocto] [yocto-autobuilder2][PATCH] schedulers: drop meta-oe-mirror and reproducible-meta-oe from SWAT monitoring
Hi All,
I just wanted to make sure people using meta-openembedded see this.
The implication here is that we're not seeing improvements to the point
where Yocto Project can keep up with the failures being generated from
meta-openembedded so were having to take it out some of our processes.
We can add it back if things improve.
Cheers,
Richard
--- Begin Message ---
From: Alexandre Belloni
Signed-off-by: Alexandre Belloni
---
schedulers.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/schedulers.py b/schedulers.py
index 9ffa88f5f384..5ddcc7a68ce9 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -283,6 +283,8 @@ def repos_for_builder(buildername):
def parent_default_props(buildername, branchname=None):
props = {}
props["swat_monitor"] = True
+if buildername in ['reproducible-meta-oe', 'meta-oe-mirror']:
+props["swat_monitor"] = False
repos = config.buildertorepos.get(buildername)
if not repos:
repos = config.buildertorepos["default"]
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62302): https://lists.yoctoproject.org/g/yocto/message/62302
Mute This Topic: https://lists.yoctoproject.org/mt/103978367/1686473
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[richard.pur...@linuxfoundation.org]
-=-=-=-=-=-=-=-=-=-=-=-
--- End Message ---
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#108462):
https://lists.openembedded.org/g/openembedded-devel/message/108462
Mute This Topic: https://lists.openembedded.org/mt/103978453/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [RFC] Support for alternative init systems
On Tue, 2023-11-07 at 09:30 +, ANQUETIN Mathieu wrote:
> Hello all,
>
> I would like to discuss an architecture solution to ease support for
> alternative init systems.
>
> As of now, OpenEmbedded supports sysvinit and systemd as first-class
> citizens but does so by including required files in the main package
> based on the value of the VIRTUAL-RUNTIME_init-manager variable. This
> forces layers, like meta-openrc for example, to remove files
> generated by other layers before providing their own. This increases
> the maintenance burden for layer maintainers of these alternative
> init systems while making them always feel like second-class
> citizens.
>
> My solution would be to generate specific packages for each init
> system (${PN}-sysvinit, ${PN}-systemd, ...) and RDEPENDS on them
> given the value of the VIRTUAL-RUNTIME_init-manager variable. This
> would simplify recipes because filtering files would no longer be
> required since all packages would be generated and other layers would
> simply provide their ${PN}-altinit package through bbappends.
> I have made a PoC on the 'kirkstone' branch but this kind of
> modification requires all recipes to adapt to the new architecture
> and therefore I would like to know if you would accept such
> modifications.
I'd note that both systemd and sysvinit end up with code which does
manipulate the generated packages depending on which is enabled.
Packages can be generated for systemd only which would result in the
packages not containing sysvinit scripts.
As such, ${PN}-sysvinit and ${PN}-systemd would never exist together
since you have to choose an init system and the ability to swap between
them is limited.
I'd note that you can have init scripts for multiple packages within a
given recipe. I'd also note that packages sometimes aren't actually
useful without their init script.
Also, the packages wouldn't be that useful since if you change
VIRTUAL-RUNTIME_init-manager, all the packages are going to end up
being rebuilt anyway.
As such, I think the proposed solution would need a lot more careful
thought and detail before we'd be able to say whether it would make
sense.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#106452):
https://lists.openembedded.org/g/openembedded-devel/message/106452
Mute This Topic: https://lists.openembedded.org/mt/102439770/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] meta-openembedded CVEs, patch stats and AUH
Patch Metrics and CVEs -- I'm now pleased to say we have CVE and patch metrics being generated (Thanks Yoann and Ross): https://autobuilder.yocto.io/pub/non-release/patchmetrics-meta-oe/ which for example generates this: https://autobuilder.yocto.io/pub/non-release/patchmetrics-meta-oe/cve-status-master.txt (268 CVEs) This doesn't work for the LTS branches since the layer override being used to generate it on master won't work for kirkstone/dunfell. Those reports are generated live onto the site daily but aren't emailed anywhere at this time. Mirroring - I covered mirroring for meta-oe layers here: https://lists.openembedded.org/g/openembedded-devel/message/105754 Basically it works but we need to decide whether we can fix the warnings to keep this enabled for dunfell/kirkstone. Reproducibility --- We can now test reproducibility for meta-oe on the autobuilder: https://autobuilder.yoctoproject.org/typhoon/#/builders/155 In order to make this useful we really need a list of known issues so that we can then exclude them and start showing regressions. AUH --- This is now working and generating updates. It takes a while to run and generates a lot of emails. https://autobuilder.yoctoproject.org/typhoon/#/builders/159/builds/8 (18 hours so far) meta-oe summary: https://lists.yoctoproject.org/g/test-list/message/425 TOTAL: attempted=206 succeeded=42(20.39%) failed=164(79.61%) meta-python summary: https://lists.yoctoproject.org/g/test-list/message/426 TOTAL: attempted=92 succeeded=50(54.35%) failed=42(45.65%) meta-perl summary: https://lists.yoctoproject.org/g/test-list/message/434 TOTAL: attempted=7 succeeded=5(71.43%) failed=2(28.57%) meta-networking summary: https://lists.yoctoproject.org/g/test-list/message/767 TOTAL: attempted=43 succeeded=8(18.60%) failed=35(81.40%) so around ~350 emails of which ~105 were successful upgrades. I'm not sure whether we want to enable that to send to openembedded-devel? There are lot of failures and there are a lot of recipes where the upstream status couldn't be checked. Is anyone interested in working on improving things in either of those areas? There are also various backend improvements we'd love to make to the AUH code now we've seen how it works in practise in this role. Summary --- All things considered, this shows what our tooling is capable of and we've a good baseline. Whether/how we enable/use this going forward depends a lot on whether people are willing to step up and help maintain/process the results. It can't/won't be Khem/I trying to make and keep it all working so this is where we need help from the wider community. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#105837): https://lists.openembedded.org/g/openembedded-devel/message/105837 Mute This Topic: https://lists.openembedded.org/mt/102342283/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] meta-oe source mirroring
On Fri, 2023-10-27 at 12:30 -0400, Tom Rini wrote:
> On Thu, Oct 26, 2023 at 03:22:26PM +0100, Richard Purdie wrote:
>
> > I'm happy to say that meta-openembedded source mirroring is now working
> > via the Yocto Project's infrastructure and available through the
> > project's source mirrors.
> >
> > An example successful run with master is here:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/19
> >
> > Nanbield should also work.
> >
> > kirkstone is here and is now error free but does show a lot of
> > warnings:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/27
> >
> > dunfell is also error free but also shows warnings:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/31
> >
> > I did have to disable two recipes as one uses mercurial (the other has
> > it as a dependency) and the mercurial checkout format changed between
> > versions. The mirrors from later releases don't work with the version
> > of mercurial-native from dunfell meta-oe. Disabling it was the
> > easiest/safest path forward.
> >
> > Currently these are all scheduled to run automatically. If we can fix
> > the warnings, that can stay. If there isn't a desire to fix the
> > warnings in stable branches, we'd probably disable the scheduler for
> > them since we have a policy of no warnings on the autobuilder.
>
> Maybe it's because I'm missing a different step, but I've always had to
> setup source mirrors for SCM archives to be in a subdirectory, not just
> for mercurial style problems but for hash changes. For example I have:
> $ ls -d ~/work/OE/downloads/*/git2_sourceware.org.git.glibc.git.tar.gz
> /home/trini/work/OE/downloads/dunfell/git2_sourceware.org.git.glibc.git.tar.gz
> /home/trini/work/OE/downloads/honister/git2_sourceware.org.git.glibc.git.tar.gz
> ...
>
> And then have in my PREMIRRORS:
> git://.*/.* ${SOURCE_MIRROR_URL}/${LAYERSERIES_COMPAT:core} \n \
> gitsm://.*/.* ${SOURCE_MIRROR_URL}/${LAYERSERIES_COMPAT:core} \n \
>
> So that I get the right thing. Might this be closer to the path forward
> to solve the above issue? Or is mine because I'm not generating the
> archives correctly to start with (and so the mercurial issue really is
> special) ?
The idea is that information is not removed from the archives so that a
newer archive should always have everything the older one had plus
more. In that sense, DL_DIR should be shareable between newer and older
releases and the mirror tarballs should to. They don't have to be
identical, newer ones may contain new revisions, as long as the older
ones are still there.
For YP, we only have one source mirror for all releases.
With mercurial, they changed the on disk format newer tooling creates
so it doesn't work with the mercurial-native from dunfell. If you
ASSUME_PROVIDED it, or update the recipe it would work. Since it is a
single recipe on an fairly old release (now) I'm not worrying too much
about it. The mirrors do have the data and people would make it work if
they needed to.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105780):
https://lists.openembedded.org/g/openembedded-devel/message/105780
Mute This Topic: https://lists.openembedded.org/mt/102200675/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH 2/2] mosquitto: Support building for native again
On Fri, 2023-10-27 at 04:51 +, Peter Kjellerstedt wrote: > > -Original Message- > > From: Richard Purdie > > Sent: den 26 oktober 2023 22:13 > > To: Peter Kjellerstedt ; openembedded- > > de...@lists.openembedded.org > > Subject: Re: [oe] [meta-networking][PATCH 2/2] mosquitto: Support > > building > > for native again > > > > On Thu, 2023-10-26 at 15:22 +0200, Peter Kjellerstedt wrote: > > > Support for building from native was removed in commit e1b332f2e > > > (meta-networking: Drop broken BBCLASSEXTEND variants), most > > > likely due > > > to no support for building libwebsockets-native. That support has > > > now > > > been added, so it is now possible to build mosquitto-native > > > again. > > > > > > Signed-off-by: Peter Kjellerstedt > > > --- > > > .../recipes-connectivity/mosquitto/mosquitto_2.0.18.bb > > > | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > I'm a little curious how this was being used given that > > libwebsockets- > > native was missing? Local changes? > > We do not have the "websockets" PACKAGECONFIG enabled. That explains things, thanks. In some ways a better fix might have been to change the native PACKAGECONFIG and reduce dependencies and build time? That assumes you don't need the native config to enable the target one which I have no idea about though. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#105770): https://lists.openembedded.org/g/openembedded-devel/message/105770 Mute This Topic: https://lists.openembedded.org/mt/102199464/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH 2/2] mosquitto: Support building for native again
On Thu, 2023-10-26 at 15:22 +0200, Peter Kjellerstedt wrote: > Support for building from native was removed in commit e1b332f2e > (meta-networking: Drop broken BBCLASSEXTEND variants), most likely due > to no support for building libwebsockets-native. That support has now > been added, so it is now possible to build mosquitto-native again. > > Signed-off-by: Peter Kjellerstedt > --- > .../recipes-connectivity/mosquitto/mosquitto_2.0.18.bb | 2 ++ > 1 file changed, 2 insertions(+) I'm a little curious how this was being used given that libwebsockets- native was missing? Local changes? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#105765): https://lists.openembedded.org/g/openembedded-devel/message/105765 Mute This Topic: https://lists.openembedded.org/mt/102199464/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-openembedded] [PATCH] python-blivet: Adapt to upstream branch name changes
On Thu, 2023-10-26 at 09:28 -0700, Khem Raj wrote: > +Armin Kuster > This is for dunfell I guess. My local master branch in that repo was out of date, sorry! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#105764): https://lists.openembedded.org/g/openembedded-devel/message/105764 Mute This Topic: https://lists.openembedded.org/mt/102199171/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] meta-oe source mirroring
I'm happy to say that meta-openembedded source mirroring is now working via the Yocto Project's infrastructure and available through the project's source mirrors. An example successful run with master is here: https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/19 Nanbield should also work. kirkstone is here and is now error free but does show a lot of warnings: https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/27 dunfell is also error free but also shows warnings: https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/31 I did have to disable two recipes as one uses mercurial (the other has it as a dependency) and the mercurial checkout format changed between versions. The mirrors from later releases don't work with the version of mercurial-native from dunfell meta-oe. Disabling it was the easiest/safest path forward. Currently these are all scheduled to run automatically. If we can fix the warnings, that can stay. If there isn't a desire to fix the warnings in stable branches, we'd probably disable the scheduler for them since we have a policy of no warnings on the autobuilder. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#105754): https://lists.openembedded.org/g/openembedded-devel/message/105754 Mute This Topic: https://lists.openembedded.org/mt/102200675/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-openembedded] [dunfell] [PATCH 1/2] ibus: Swith to use main branch instead of master
From: Khem Raj Upstream has switched to using main for tip of trunk, therefore follow it here in SRC_URI as well. Signed-off-by: Khem Raj Suggested-by: Fabio Estevam Reported-by: Markus Volk --- meta-gnome/recipes-support/ibus/ibus.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-gnome/recipes-support/ibus/ibus.inc b/meta-gnome/recipes-support/ibus/ibus.inc index c0c0b3b31..2e03f7c6a 100644 --- a/meta-gnome/recipes-support/ibus/ibus.inc +++ b/meta-gnome/recipes-support/ibus/ibus.inc @@ -10,7 +10,7 @@ PV = "1.5.22" DEPENDS = "unicode-ucd" SRC_URI = " \ -git://github.com/ibus/ibus.git;branch=master;protocol=https \ +git://github.com/ibus/ibus.git;branch=main;protocol=https \ file://0001-Do-not-try-to-start-dbus-we-do-not-have-dbus-lauch.patch \ " SRCREV = "e3262f08b9e3efc57808700823b0622ec03a1b5f" -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#105746): https://lists.openembedded.org/g/openembedded-devel/message/105746 Mute This Topic: https://lists.openembedded.org/mt/102199240/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-openembedded] [dunfell] [PATCH 2/2] grubby: Update branchname to match upstream
meta-oe master already made this change along with others. Update the branchname
to match upstream repository changes to allow fetching to continue to work.
Signed-off-by: Richard Purdie
---
meta-initramfs/recipes-devtools/grubby/grubby_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-initramfs/recipes-devtools/grubby/grubby_git.bb
b/meta-initramfs/recipes-devtools/grubby/grubby_git.bb
index c0797ac5c..9d3d7b55c 100644
--- a/meta-initramfs/recipes-devtools/grubby/grubby_git.bb
+++ b/meta-initramfs/recipes-devtools/grubby/grubby_git.bb
@@ -14,7 +14,7 @@ DEPENDS_append_libc-musl = " libexecinfo"
S = "${WORKDIR}/git"
SRCREV = "a1d2ae93408c3408e672d7eba4550fdf27fb0201"
-SRC_URI = "git://github.com/rhboot/grubby.git;protocol=https;branch=master \
+SRC_URI = "git://github.com/rhboot/grubby.git;protocol=https;branch=main \
file://grubby-rename-grub2-editenv-to-grub-editenv.patch \
file://run-ptest \
file://0001-Add-another-variable-LIBS-to-provides-libraries-from.patch \
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105747):
https://lists.openembedded.org/g/openembedded-devel/message/105747
Mute This Topic: https://lists.openembedded.org/mt/102199241/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-openembedded] [kirkstone] [PATCH 3/3] suiteparse: Adapt to upstream branch name changes
meta-oe master branch already made this change. Signed-off-by: Richard Purdie --- meta-oe/recipes-devtools/suitesparse/suitesparse_5.10.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-oe/recipes-devtools/suitesparse/suitesparse_5.10.1.bb b/meta-oe/recipes-devtools/suitesparse/suitesparse_5.10.1.bb index 38e34b93c..56cbfce20 100644 --- a/meta-oe/recipes-devtools/suitesparse/suitesparse_5.10.1.bb +++ b/meta-oe/recipes-devtools/suitesparse/suitesparse_5.10.1.bb @@ -1,6 +1,6 @@ LICENSE = "GPL-2.0-only & GPL-3.0-only & BSD-3-Clause & LGPL-2.0-only & Apache-2.0" LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=5fa987762101f748a6cdd951b64ffc6b" -SRC_URI = "git://github.com/DrTimothyAldenDavis/SuiteSparse;protocol=https;branch=master \ +SRC_URI = "git://github.com/DrTimothyAldenDavis/SuiteSparse;protocol=https;branch=stable \ file://0001-Preserve-CXXFLAGS-from-environment-in-Mongoose.patch \ file://0002-Preserve-links-when-installing-libmetis.patch \ file://0003-Add-version-information-to-libmetis.patch \ -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#105745): https://lists.openembedded.org/g/openembedded-devel/message/105745 Mute This Topic: https://lists.openembedded.org/mt/102199220/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-openembedded] [kirkstone] [PATCH 2/3] python-blivet: Adapt to upstream branch name changes
Signed-off-by: Richard Purdie
---
.../recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta-python/recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb
b/meta-python/recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb
index 29e7a267d..36ab065b5 100644
--- a/meta-python/recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb
+++ b/meta-python/recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb
@@ -9,7 +9,7 @@ S = "${WORKDIR}/git"
B = "${S}"
SRCREV = "42512ee48494cee71febf04078d9774f0146a085"
-SRC_URI =
"git://github.com/storaged-project/blivet-gui.git;branch=master;protocol=https \
+SRC_URI =
"git://github.com/storaged-project/blivet-gui.git;branch=main;protocol=https \
file://0001-Use-setuptools-instead-of-distutils-in-setup.py.patch \
file://0002-Use-symbolic-list-add-and-edit-icons.patch \
"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105744):
https://lists.openembedded.org/g/openembedded-devel/message/105744
Mute This Topic: https://lists.openembedded.org/mt/102199218/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-openembedded] [kirkstone] [PATCH 1/3] grubby: Update branchname to match upstream
meta-oe master already made this change along with others. Update the branchname
to match upstream repository changes to allow fetching to continue to work.
Drop unneeded duplicate semicolon too.
Signed-off-by: Richard Purdie
---
meta-initramfs/recipes-devtools/grubby/grubby_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-initramfs/recipes-devtools/grubby/grubby_git.bb
b/meta-initramfs/recipes-devtools/grubby/grubby_git.bb
index a276bf423..7c40c52cf 100644
--- a/meta-initramfs/recipes-devtools/grubby/grubby_git.bb
+++ b/meta-initramfs/recipes-devtools/grubby/grubby_git.bb
@@ -14,7 +14,7 @@ DEPENDS:append:libc-musl = " libexecinfo"
S = "${WORKDIR}/git"
SRCREV = "a1d2ae93408c3408e672d7eba4550fdf27fb0201"
-SRC_URI = "git://github.com/rhboot/grubby.git;protocol=https;;branch=master \
+SRC_URI = "git://github.com/rhboot/grubby.git;protocol=https;branch=main \
file://grubby-rename-grub2-editenv-to-grub-editenv.patch \
file://run-ptest \
file://0001-Add-another-variable-LIBS-to-provides-libraries-from.patch \
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105743):
https://lists.openembedded.org/g/openembedded-devel/message/105743
Mute This Topic: https://lists.openembedded.org/mt/102199217/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-openembedded] [PATCH] python-blivet: Adapt to upstream branch name changes
Upstream now use main as their development branch.
Signed-off-by: Richard Purdie
---
.../recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta-python/recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb
b/meta-python/recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb
index aba127897..42bcf4651 100644
--- a/meta-python/recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb
+++ b/meta-python/recipes-extended/python-blivet/python3-blivetgui_2.3.0.bb
@@ -9,7 +9,7 @@ S = "${WORKDIR}/git"
B = "${S}"
SRCREV = "42512ee48494cee71febf04078d9774f0146a085"
-SRC_URI =
"git://github.com/storaged-project/blivet-gui.git;branch=master;protocol=https \
+SRC_URI =
"git://github.com/storaged-project/blivet-gui.git;branch=main;protocol=https \
file://0001-Use-setuptools-instead-of-distutils-in-setup.py.patch \
file://0002-Use-symbolic-list-add-and-edit-icons.patch \
"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105742):
https://lists.openembedded.org/g/openembedded-devel/message/105742
Mute This Topic: https://lists.openembedded.org/mt/102199171/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-perl][PATCH] meta-perl: Drop broken BBCLASSEXTEND variants
The command "bitbake universe -c fetch" currently throws a ton of warnings
as there are many 'impossible' dependencies.
In some cases these variants may never have worked and were just added by copy
and paste of recipes. In some cases they once clearly did work but became
broken somewhere along the way. Users may also be carrying local bbappend files
which add further BBCLASSEXTEND.
Having universe fetch work without warnings is desireable so clean up the broken
variants. Anyone actually needing something dropped here can propose adding it
and the correct functional dependencies back quite easily. This also then
ensures we're not carrying or fixing things nobody uses.
Signed-off-by: Richard Purdie
---
.../recipes-perl/libconfig/libconfig-autoconf-perl_0.319.bb | 2 +-
meta-perl/recipes-perl/libio/libio-socket-ssl-perl_2.083.bb | 2 --
meta-perl/recipes-perl/libnet/libnet-dns-perl_1.40.bb | 1 -
meta-perl/recipes-perl/libnet/libnet-ldap-perl_0.68.bb | 2 --
meta-perl/recipes-perl/libstatgrab/libunix-statgrab_0.112.bb| 1 -
5 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/meta-perl/recipes-perl/libconfig/libconfig-autoconf-perl_0.319.bb
b/meta-perl/recipes-perl/libconfig/libconfig-autoconf-perl_0.319.bb
index 5db0bb4269..5c3701f16b 100644
--- a/meta-perl/recipes-perl/libconfig/libconfig-autoconf-perl_0.319.bb
+++ b/meta-perl/recipes-perl/libconfig/libconfig-autoconf-perl_0.319.bb
@@ -38,4 +38,4 @@ S = "${WORKDIR}/Config-AutoConf-${PV}"
inherit cpan ptest-perl
-BBCLASSEXTEND = "native nativesdk"
+BBCLASSEXTEND = "native"
diff --git a/meta-perl/recipes-perl/libio/libio-socket-ssl-perl_2.083.bb
b/meta-perl/recipes-perl/libio/libio-socket-ssl-perl_2.083.bb
index 4d793a4e32..028d9e9163 100644
--- a/meta-perl/recipes-perl/libio/libio-socket-ssl-perl_2.083.bb
+++ b/meta-perl/recipes-perl/libio/libio-socket-ssl-perl_2.083.bb
@@ -52,5 +52,3 @@ RDEPENDS:${PN}-ptest += "\
do_install_ptest:append () {
cp -r ${B}/t/certs ${D}${PTEST_PATH}
}
-
-BBCLASSEXTEND = "native"
diff --git a/meta-perl/recipes-perl/libnet/libnet-dns-perl_1.40.bb
b/meta-perl/recipes-perl/libnet/libnet-dns-perl_1.40.bb
index 65616136c3..e30125ab7b 100644
--- a/meta-perl/recipes-perl/libnet/libnet-dns-perl_1.40.bb
+++ b/meta-perl/recipes-perl/libnet/libnet-dns-perl_1.40.bb
@@ -62,4 +62,3 @@ python __anonymous () {
d.getVar('TCLIBC'))
}
-BBCLASSEXTEND = "native"
diff --git a/meta-perl/recipes-perl/libnet/libnet-ldap-perl_0.68.bb
b/meta-perl/recipes-perl/libnet/libnet-ldap-perl_0.68.bb
index dcc5ea88b1..a77381dce8 100644
--- a/meta-perl/recipes-perl/libnet/libnet-ldap-perl_0.68.bb
+++ b/meta-perl/recipes-perl/libnet/libnet-ldap-perl_0.68.bb
@@ -41,5 +41,3 @@ RDEPENDS:${PN}-ptest += " \
perl-module-perlio \
perl-module-test-more \
"
-
-BBCLASSEXTEND = "native"
diff --git a/meta-perl/recipes-perl/libstatgrab/libunix-statgrab_0.112.bb
b/meta-perl/recipes-perl/libstatgrab/libunix-statgrab_0.112.bb
index c568ade997..cf290d9908 100644
--- a/meta-perl/recipes-perl/libstatgrab/libunix-statgrab_0.112.bb
+++ b/meta-perl/recipes-perl/libstatgrab/libunix-statgrab_0.112.bb
@@ -37,4 +37,3 @@ export LD = "${CCLD}"
inherit cpan pkgconfig ptest-perl
-BBCLASSEXTEND = "native"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105719):
https://lists.openembedded.org/g/openembedded-devel/message/105719
Mute This Topic: https://lists.openembedded.org/mt/102155601/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH] meta-networking: Drop broken BBCLASSEXTEND variants
The command "bitbake universe -c fetch" currently throws a ton of warnings
as there are many 'impossible' dependencies.
In some cases these variants may never have worked and were just added by copy
and paste of recipes. In some cases they once clearly did work but became
broken somewhere along the way. Users may also be carrying local bbappend files
which add further BBCLASSEXTEND.
Having universe fetch work without warnings is desireable so clean up the broken
variants. Anyone actually needing something dropped here can propose adding it
and the correct functional dependencies back quite easily. This also then
ensures we're not carrying or fixing things nobody uses.
Signed-off-by: Richard Purdie
---
.../recipes-connectivity/mosquitto/mosquitto_2.0.18.bb | 2 --
.../recipes-support/netsniff-ng/netsniff-ng_0.6.8.bb| 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta-networking/recipes-connectivity/mosquitto/mosquitto_2.0.18.bb
b/meta-networking/recipes-connectivity/mosquitto/mosquitto_2.0.18.bb
index 0c9ccc810d..7685cc9287 100644
--- a/meta-networking/recipes-connectivity/mosquitto/mosquitto_2.0.18.bb
+++ b/meta-networking/recipes-connectivity/mosquitto/mosquitto_2.0.18.bb
@@ -88,5 +88,3 @@ INITSCRIPT_PARAMS = "defaults 30"
USERADD_PACKAGES = "${PN}"
USERADD_PARAM:${PN} = "--system --no-create-home --shell /bin/false \
--user-group mosquitto"
-
-BBCLASSEXTEND += "native nativesdk"
diff --git a/meta-networking/recipes-support/netsniff-ng/netsniff-ng_0.6.8.bb
b/meta-networking/recipes-support/netsniff-ng/netsniff-ng_0.6.8.bb
index 004330e1b4..341eab015c 100644
--- a/meta-networking/recipes-support/netsniff-ng/netsniff-ng_0.6.8.bb
+++ b/meta-networking/recipes-support/netsniff-ng/netsniff-ng_0.6.8.bb
@@ -33,4 +33,4 @@ do_install() {
oe_runmake DESTDIR=${D} netsniff-ng_install
}
-BBCLASSEXTEND = "native nativesdk"
+BBCLASSEXTEND = "native"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105718):
https://lists.openembedded.org/g/openembedded-devel/message/105718
Mute This Topic: https://lists.openembedded.org/mt/102155591/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-oe][PATCH] meta-oe: Drop broken BBCLASSEXTEND variants
The command "bitbake universe -c fetch" currently throws a ton of warnings
as there are many 'impossible' dependencies.
In some cases these variants may never have worked and were just added by copy
and paste of recipes. In some cases they once clearly did work but became
broken somewhere along the way. Users may also be carrying local bbappend files
which add further BBCLASSEXTEND.
Having universe fetch work without warnings is desireable so clean up the broken
variants. Anyone actually needing something dropped here can propose adding it
and the correct functional dependencies back quite easily. This also then
ensures we're not carrying or fixing things nobody uses.
Signed-off-by: Richard Purdie
---
meta-oe/recipes-connectivity/ser2net/ser2net_4.3.13.bb| 2 --
meta-oe/recipes-connectivity/zeromq/czmq_4.2.1.bb | 2 --
meta-oe/recipes-devtools/dnf-plugin-tui/dnf-plugin-tui_git.bb | 2 --
meta-oe/recipes-devtools/heaptrack/heaptrack_1.2.0.bb | 2 +-
meta-oe/recipes-graphics/openjpeg/openjpeg_2.5.0.bb | 2 +-
meta-oe/recipes-graphics/xorg-app/xkbutils_1.0.5.bb | 2 --
meta-oe/recipes-graphics/xorg-app/xsetroot_1.1.2.bb | 1 -
meta-oe/recipes-multimedia/jack/jack_1.19.22.bb | 1 -
meta-oe/recipes-printing/cups/cups-filters_1.28.17.bb | 2 --
9 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/meta-oe/recipes-connectivity/ser2net/ser2net_4.3.13.bb
b/meta-oe/recipes-connectivity/ser2net/ser2net_4.3.13.bb
index a4c244d447..47f2c26ce4 100644
--- a/meta-oe/recipes-connectivity/ser2net/ser2net_4.3.13.bb
+++ b/meta-oe/recipes-connectivity/ser2net/ser2net_4.3.13.bb
@@ -14,5 +14,3 @@ SRC_URI[sha256sum] =
"ed8b98448d535111d9a593b067601a8b53e2874814d706b2421a9490a6
UPSTREAM_CHECK_URI = "http://sourceforge.net/projects/ser2net/files/ser2net";
inherit autotools pkgconfig
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-oe/recipes-connectivity/zeromq/czmq_4.2.1.bb
b/meta-oe/recipes-connectivity/zeromq/czmq_4.2.1.bb
index 86fde7ccfb..ce9d758d9f 100644
--- a/meta-oe/recipes-connectivity/zeromq/czmq_4.2.1.bb
+++ b/meta-oe/recipes-connectivity/zeromq/czmq_4.2.1.bb
@@ -30,8 +30,6 @@ PACKAGECONFIG[nss] =
"-DCZMQ_WITH_NSS=ON,-DCZMQ_WITH_NSS=OFF,nss"
PACKAGECONFIG[systemd] =
"-DCZMQ_WITH_SYSTEMD=ON,-DCZMQ_WITH_SYSTEMD=OFF,systemd"
PACKAGECONFIG[uuid] = "-DCZMQ_WITH_UUID=ON,-DCZMQ_WITH_UUID=OFF,util-linux"
-BBCLASSEXTEND = "nativesdk"
-
do_install:append() {
mkdir -p ${D}/${includedir}/${BPN}
mv ${D}/${includedir}/sha1.h ${D}/${includedir}/${BPN}/.
diff --git a/meta-oe/recipes-devtools/dnf-plugin-tui/dnf-plugin-tui_git.bb
b/meta-oe/recipes-devtools/dnf-plugin-tui/dnf-plugin-tui_git.bb
index 0709019056..a5d614961a 100644
--- a/meta-oe/recipes-devtools/dnf-plugin-tui/dnf-plugin-tui_git.bb
+++ b/meta-oe/recipes-devtools/dnf-plugin-tui/dnf-plugin-tui_git.bb
@@ -42,6 +42,4 @@ RDEPENDS:${PN} += " \
dnf \
libnewt-python \
"
-DEPENDS:append:class-nativesdk = " file-replacement-nativesdk"
-BBCLASSEXTEND = "nativesdk"
SKIP_RECIPE[dnf-plugin-tui] ?= "${@bb.utils.contains('PACKAGE_CLASSES',
'package_rpm', '', 'does not build correctly without package_rpm in
PACKAGE_CLASSES', d)}"
diff --git a/meta-oe/recipes-devtools/heaptrack/heaptrack_1.2.0.bb
b/meta-oe/recipes-devtools/heaptrack/heaptrack_1.2.0.bb
index 29937e26d0..be2c0f5394 100644
--- a/meta-oe/recipes-devtools/heaptrack/heaptrack_1.2.0.bb
+++ b/meta-oe/recipes-devtools/heaptrack/heaptrack_1.2.0.bb
@@ -29,4 +29,4 @@ EXTRA_OECMAKE += "-DHEAPTRACK_BUILD_GUI=OFF"
COMPATIBLE_HOST:riscv32 = "null"
COMPATIBLE_HOST:riscv64 = "null"
-BBCLASSEXTEND = "native nativesdk"
+BBCLASSEXTEND = "native"
diff --git a/meta-oe/recipes-graphics/openjpeg/openjpeg_2.5.0.bb
b/meta-oe/recipes-graphics/openjpeg/openjpeg_2.5.0.bb
index c71e535649..f2d74078e8 100644
--- a/meta-oe/recipes-graphics/openjpeg/openjpeg_2.5.0.bb
+++ b/meta-oe/recipes-graphics/openjpeg/openjpeg_2.5.0.bb
@@ -18,4 +18,4 @@ EXTRA_OECMAKE +=
"-DOPENJPEG_INSTALL_LIB_DIR=${@d.getVar('baselib').replace('/',
FILES:${PN} += "${libdir}/openjpeg*"
-BBCLASSEXTEND = "native nativesdk"
+BBCLASSEXTEND = "native"
diff --git a/meta-oe/recipes-graphics/xorg-app/xkbutils_1.0.5.bb
b/meta-oe/recipes-graphics/xorg-app/xkbutils_1.0.5.bb
index a672ba5e5e..f078ad60eb 100644
--- a/meta-oe/recipes-graphics/xorg-app/xkbutils_1.0.5.bb
+++ b/meta-oe/recipes-graphics/xorg-app/xkbutils_1.0.5.bb
@@ -13,7 +13,5 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=64322fab5239f5c8d97cf6e0e14f1c62"
DEPENDS += "libxaw libxkbfile"
-BBCLASSEXTEND = "native"
-
SRC_URI_EXT = "xz"
SRC_URI[sha256sum] =
"
[oe] [meta-python][PATCH] meta-python: Drop broken BBCLASSEXTEND variants
The command "bitbake universe -c fetch" currently throws a ton of warnings
as there are many 'impossible' dependencies.
In some cases these variants may never have worked and were just added by copy
and paste of recipes. In some cases they once clearly did work but became
broken somewhere along the way. Users may also be carrying local bbappend files
which add further BBCLASSEXTEND.
Having universe fetch work without warnings is desireable so clean up the broken
variants. Anyone actually needing something dropped here can propose adding it
and the correct functional dependencies back quite easily. This also then
ensures we're not carrying or fixing things nobody uses.
Signed-off-by: Richard Purdie
---
.../recipes-connectivity/python-thrift/python3-thrift_0.16.0.bb | 2 +-
.../recipes-devtools/python/python3-aiohttp-jinja2_1.5.1.bb | 2 --
meta-python/recipes-devtools/python/python3-autobahn_23.6.2.bb | 2 --
meta-python/recipes-devtools/python/python3-bandit_1.7.5.bb | 2 --
meta-python/recipes-devtools/python/python3-can_4.2.2.bb| 2 --
.../recipes-devtools/python/python3-covdefaults_2.3.0.bb| 2 --
meta-python/recipes-devtools/python/python3-ninja_1.11.1.bb | 1 -
meta-python/recipes-devtools/python/python3-pyudev_0.24.1.bb| 2 --
.../python/python3-robotframework-seriallibrary_0.4.3.bb| 2 --
meta-python/recipes-devtools/python/python3-snappy_0.6.1.bb | 2 --
meta-python/recipes-devtools/python/python3-txaio_23.1.1.bb | 2 --
meta-python/recipes-extended/pywbem/python3-pywbem_1.6.2.bb | 2 --
12 files changed, 1 insertion(+), 22 deletions(-)
diff --git
a/meta-python/recipes-connectivity/python-thrift/python3-thrift_0.16.0.bb
b/meta-python/recipes-connectivity/python-thrift/python3-thrift_0.16.0.bb
index 9bb3053885..63065e00ba 100644
--- a/meta-python/recipes-connectivity/python-thrift/python3-thrift_0.16.0.bb
+++ b/meta-python/recipes-connectivity/python-thrift/python3-thrift_0.16.0.bb
@@ -17,4 +17,4 @@ RDEPENDS:${PN} += "\
python3-threading \
"
-BBCLASSEXTEND = "native nativesdk"
+BBCLASSEXTEND = "native"
diff --git
a/meta-python/recipes-devtools/python/python3-aiohttp-jinja2_1.5.1.bb
b/meta-python/recipes-devtools/python/python3-aiohttp-jinja2_1.5.1.bb
index 68cbb265f4..4c4ed3ffd9 100644
--- a/meta-python/recipes-devtools/python/python3-aiohttp-jinja2_1.5.1.bb
+++ b/meta-python/recipes-devtools/python/python3-aiohttp-jinja2_1.5.1.bb
@@ -11,5 +11,3 @@ RDEPENDS:${PN} += " \
${PYTHON_PN}-jinja2 \
${PYTHON_PN}-aiohttp \
"
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-autobahn_23.6.2.bb
b/meta-python/recipes-devtools/python/python3-autobahn_23.6.2.bb
index 54c8f23fc3..42a8e0e7b5 100644
--- a/meta-python/recipes-devtools/python/python3-autobahn_23.6.2.bb
+++ b/meta-python/recipes-devtools/python/python3-autobahn_23.6.2.bb
@@ -19,5 +19,3 @@ RDEPENDS:${PN} += " \
${PYTHON_PN}-txaio \
${PYTHON_PN}-six \
"
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-bandit_1.7.5.bb
b/meta-python/recipes-devtools/python/python3-bandit_1.7.5.bb
index bccdf284e5..ede7f92e8d 100644
--- a/meta-python/recipes-devtools/python/python3-bandit_1.7.5.bb
+++ b/meta-python/recipes-devtools/python/python3-bandit_1.7.5.bb
@@ -17,5 +17,3 @@ RDEPENDS:${PN} += "\
python3-six \
python3-stevedore \
"
-
-BBCLASSEXTEND = "native"
diff --git a/meta-python/recipes-devtools/python/python3-can_4.2.2.bb
b/meta-python/recipes-devtools/python/python3-can_4.2.2.bb
index f3cfd17244..9ca926d66c 100644
--- a/meta-python/recipes-devtools/python/python3-can_4.2.2.bb
+++ b/meta-python/recipes-devtools/python/python3-can_4.2.2.bb
@@ -27,5 +27,3 @@ RDEPENDS:${PN} += " \
python3-typing-extensions \
python3-wrapt \
"
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-covdefaults_2.3.0.bb
b/meta-python/recipes-devtools/python/python3-covdefaults_2.3.0.bb
index b7709aa1ca..a0ef2af828 100644
--- a/meta-python/recipes-devtools/python/python3-covdefaults_2.3.0.bb
+++ b/meta-python/recipes-devtools/python/python3-covdefaults_2.3.0.bb
@@ -27,5 +27,3 @@ do_install_ptest() {
install -d ${D}${PTEST_PATH}
cp -rf ${S}/tests ${D}${PTEST_PATH}
}
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-ninja_1.11.1.bb
b/meta-python/recipes-devtools/python/python3-ninja_1.11.1.bb
index 3b9077f326..dd07968f03 100644
--- a/meta-python/recipes-devtools/python/python3-ninja_1.11.1.bb
+++ b/meta-python/recipes-devtools/python/python3-ninja_1.11.1.bb
@@ -22,4 +22,3 @@ RDEPENDS:${PN} = " \
python3-ninja-syntax \
"
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-d
Re: [oe] [oe-core][kirkstone][PATCH 1/1] webkitgtk: fix CVE-2022-42867
On Tue, 2023-06-06 at 13:47 +, Sanjaykumar kantibhai Chitroda -X (schitrod - E-INFO CHIPS INC at Cisco) wrote: > > Do we accept the CVE fixes which are not reported in our CVE metrics? > https://autobuilder.yocto.io/pub/non-release/patchmetrics/cve-status-kirkstone.txt > > On which image we run cve_check task to generate CVE metrics? Any > image which run for all the packages available in SDK? Yes, we do accept such CVE fixes. I would like to understand why the tool isn't showing them too though if possible and maybe fix that. We don't run the checker against images, we run it against all recipes in OE-Core so it should have shown up. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#103146): https://lists.openembedded.org/g/openembedded-devel/message/103146 Mute This Topic: https://lists.openembedded.org/mt/99357784/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [PATCH] kbd: DEPEND on bison-native and don't build tests
On Tue, 2022-11-22 at 17:00 +0100, Ola x Nilsson wrote:
> bison-native is required if any .y-file is changed.
>
> Add --disable-tests to EXTRA_OECONF as the tests are not usable in
> ptest - they can only run in-situ - and fails when building with
> -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
>
> Signed-off-by: Ola x Nilsson
> ---
> meta/recipes-core/kbd/kbd_2.5.1.bb | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/kbd/kbd_2.5.1.bb
> b/meta/recipes-core/kbd/kbd_2.5.1.bb
> index aa3ab6e121..75b3c2765a 100644
> --- a/meta/recipes-core/kbd/kbd_2.5.1.bb
> +++ b/meta/recipes-core/kbd/kbd_2.5.1.bb
> @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>
> inherit autotools gettext pkgconfig
>
> -DEPENDS += "flex-native"
> +DEPENDS += "bison-native flex-native"
>
> RREPLACES:${PN} = "console-tools"
> RPROVIDES:${PN} = "console-tools"
> @@ -18,6 +18,7 @@ SRC_URI =
> "${KERNELORG_MIRROR}/linux/utils/${BPN}/${BP}.tar.xz \
>
> SRC_URI[sha256sum] =
> "ccdf452387a6380973d2927363e9cbb939fa2068915a6f937ff9d24522024683"
>
> +EXTRA_OECONF = "--disable-tests"
> PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)} \
>"
This needs to go to the other list. I'd also want to understand why we
don't normally run into any problems despite the missing dependency?
That needs to be explained in the commit message.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#99705):
https://lists.openembedded.org/g/openembedded-devel/message/99705
Mute This Topic: https://lists.openembedded.org/mt/95199342/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-openembedded] [PATCH] lmdb: Don't inherit base
base is always inherited so remove this code which will soon cause an error.
Signed-off-by: Richard Purdie
---
meta-oe/recipes-dbs/lmdb/lmdb_0.9.29.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-dbs/lmdb/lmdb_0.9.29.bb
b/meta-oe/recipes-dbs/lmdb/lmdb_0.9.29.bb
index b58a36c44..0590ce008 100644
--- a/meta-oe/recipes-dbs/lmdb/lmdb_0.9.29.bb
+++ b/meta-oe/recipes-dbs/lmdb/lmdb_0.9.29.bb
@@ -15,7 +15,7 @@ SRC_URI =
"git://github.com/LMDB/lmdb.git;nobranch=1;protocol=https \
SRCREV = "8ad7be2510414b9506ec9f9e24f24d04d9b04a1a"
-inherit base ptest
+inherit ptest
S = "${WORKDIR}/git/libraries/liblmdb"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#98191):
https://lists.openembedded.org/g/openembedded-devel/message/98191
Mute This Topic: https://lists.openembedded.org/mt/92954707/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] buildpaths warnings in meta-openembedded
On Mon, 2022-07-18 at 08:02 -0700, akuster808 wrote: > Richard, > > On 7/17/22 23:52, Richard Purdie wrote: > > OE-Core recently enabled buildpaths in WARN_QA. This is so any > > reproducibility issues are highlighted by the build much earlier and > > for a wider cross section of the userbase. We're now at a point where > > having issues show up earlier to users is feasible and very valuable. > > > > We've managed to sort out OE-Core but meta-oe still has a number of > > issues. I've listed the ones from the last autobuilder run below. Note > > that where multiple files in a package trigger a warning, this will > > only list the first occurrence. To reproduce locally, after the first > > warning shows, the object will install from sstate and now warning will > > show a second time so you need to use "-C package_qa" to test under > > some cases. > Any indication this new QA check will be backported to the stable branches? I wasn't planning to, it has needed a lot of fixes in different places. Where there are good fixes for existing code, we might backport those. Also, just for reference, this QA test already exists even in dunfell. It just isn't enabled and has bugs. We might backport the bug fixes, those would be safe enough (they're in the test itself so isolated). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#97879): https://lists.openembedded.org/g/openembedded-devel/message/97879 Mute This Topic: https://lists.openembedded.org/mt/92453784/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] buildpaths warnings in meta-openembedded
OE-Core recently enabled buildpaths in WARN_QA. This is so any reproducibility issues are highlighted by the build much earlier and for a wider cross section of the userbase. We're now at a point where having issues show up earlier to users is feasible and very valuable. We've managed to sort out OE-Core but meta-oe still has a number of issues. I've listed the ones from the last autobuilder run below. Note that where multiple files in a package trigger a warning, this will only list the first occurrence. To reproduce locally, after the first warning shows, the object will install from sstate and now warning will show a second time so you need to use "-C package_qa" to test under some cases. stdio: WARNING: ndisc6-1.0.5-r0 do_package_qa: QA Issue: File /usr/sbin/rdnssd in package ndisc6-rdnssd contains reference to TMPDIR [buildpaths] stdio: WARNING: ndisc6-1.0.5-r0 do_package_qa: QA Issue: File /usr/bin/rltraceroute6 in package ndisc6-rltraceroute6 contains reference to TMPDIR [buildpaths] stdio: WARNING: ndisc6-1.0.5-r0 do_package_qa: QA Issue: File /usr/bin/rdisc6 in package ndisc6-rdisc6 contains reference to TMPDIR [buildpaths] stdio: WARNING: ndisc6-1.0.5-r0 do_package_qa: QA Issue: File /usr/bin/ndisc6 in package ndisc6-ndisc6 contains reference to TMPDIR [buildpaths] stdio: WARNING: ndisc6-1.0.5-r0 do_package_qa: QA Issue: File /usr/bin/name2addr in package ndisc6-misc contains reference to TMPDIR stdio: WARNING: unbound-1.16.0-r0 do_package_qa: QA Issue: File /usr/src/debug/unbound/1.16.0-r0/build/config.h in package unbound-src contains reference to TMPDIR [buildpaths] stdio: WARNING: unbound-1.16.0-r0 do_package_qa: QA Issue: File /usr/sbin/unbound in package unbound contains reference to TMPDIR [buildpaths] stdio: WARNING: minifi-cpp-0.7.0-r0 do_package_qa: QA Issue: File /usr/bin/minifi in package minifi-cpp contains reference to TMPDIR stdio: WARNING: minifi-cpp-0.7.0-r0 do_package_qa: QA Issue: File /usr/bin/.debug/minifi in package minifi-cpp-dbg contains reference to TMPDIR stdio: WARNING: boinc-client-7.18.1-r0 do_package_qa: QA Issue: File /usr/include/boinc/svn_version.h in package boinc-client-dev contains reference to TMPDIR [buildpaths] stdio: WARNING: ntpsec-1.2.1-r0 do_package_qa: QA Issue: File /usr/src/debug/ntpsec/1.2.1-r0/build/host/ntpd/ntp_parser.tab.h in package ntpsec-src contains reference to TMPDIR [buildpaths] stdio: WARNING: yasm-1.3.0+gitAUTOINC+ba463d3c26-r0 do_package_qa: QA Issue: File /usr/include/libyasm-stdint.h in package yasm-dev contains reference to TMPDIR [buildpaths] stdio: WARNING: php-8.1.7-r0 do_package_qa: QA Issue: File /usr/bin/phpdbg in package php-phpdbg contains reference to TMPDIR [buildpaths] stdio: WARNING: php-8.1.7-r0 do_package_qa: QA Issue: File /usr/sbin/php-fpm in package php-fpm contains reference to TMPDIR [buildpaths] stdio: WARNING: php-8.1.7-r0 do_package_qa: QA Issue: File /usr/include/php/main/build-defs.h in package php-dev contains reference to TMPDIR stdio: WARNING: php-8.1.7-r0 do_package_qa: QA Issue: File /usr/bin/.debug/php-cgi in package php-dbg contains reference to TMPDIR stdio: WARNING: php-8.1.7-r0 do_package_qa: QA Issue: File /usr/bin/php in package php-cli contains reference to TMPDIR [buildpaths] stdio: WARNING: php-8.1.7-r0 do_package_qa: QA Issue: File /usr/bin/php-cgi in package php-cgi contains reference to TMPDIR [buildpaths] stdio: WARNING: nspr-4.29-r0 do_package_qa: QA Issue: File /usr/bin/nspr-config in package nspr-dev contains reference to TMPDIR [buildpaths] stdio: WARNING: lprng-3.8.C-r0 do_package_qa: QA Issue: File /etc/lpd/lpd.conf in package lprng contains reference to TMPDIR stdio: WARNING: log4cpp-1.1.3-r0 do_package_qa: QA Issue: File /usr/bin/log4cpp-config in package log4cpp contains reference to TMPDIR [buildpaths] stdio: WARNING: libwmf-0.2.8.4-r3 do_package_qa: QA Issue: File /usr/bin/libwmf-config in package libwmf contains reference to TMPDIR [buildpaths] stdio: WARNING: jsonrpc-1.3.0-r0 do_package_qa: QA Issue: File /usr/lib/libjson-rpc-cpp/cmake/libjson-rpc-cppTargets.cmake in package jsonrpc-dev contains reference to TMPDIR [buildpaths] stdio: WARNING: gutenprint-git-r0 do_package_qa: QA Issue: File /usr/lib/gutenprint/5.3/config.summary in package gutenprint contains reference to TMPDIR [buildpaths] stdio: WARNING: znc-1.8.2-r0 do_package_qa: QA Issue: File /usr/bin/znc-buildmod in package znc contains reference to TMPDIR [buildpaths] stdio: WARNING: imagemagick-7.0.10-62-r0 do_package_qa: QA Issue: File /etc/ImageMagick-7/delegates.xml in package imagemagick contains reference to TMPDIR stdio: WARNING: ncftp-3.2.6-r0 do_package_qa: QA Issue: File /usr/bin/ncftpget in package ncftp contains reference to TMPDIR stdio: WARNING: hdf5-1.8.21-r0 do_package_qa: QA Issue: File /usr/lib/libhdf5.settings in package hdf5 contains reference to TMPDIR [buildpaths] stdio: WARNING: dovecot-2.3.14-r0 do_package_qa: QA Issue: File /usr/lib/dovecot/dovecot-conf
Re: [oe] [Openembedded-architecture] Proposal: INCOMPATIBLE_LICENSE_EXCEPTION
On Fri, 2022-02-18 at 11:41 -0800, Saul Wold wrote: > As a follow-on to yesterday's email and replies, I would like to make > the following proposal for dealing with the changes to > INCOMPATIBLE_LICENSE and associated variables. > > Current Usage: > > INCOMPATIBLE_LICENSE is a list of licenses that are considered > incompatible with a distro's requirements. This is used to compare > against packages built by a given recipe. > > A set of exception variables based on the license name (currently > WHITELIST_) that contains a list of recipes that will be > checked against the current recipe (PN) being evaluated. If it's in > that list then all packages in that recipe will be built and included > and the rest of the evaluation will be skipped. > > Otherwise, the packages (PKGS) from the recipe will be evaluated to see > if any have a package specific license (LICENSE:). If a package > has a license other than the INCOMPATIBLE_LICENSE the recipe will be > built and any packages with the INCOMPATIBLE_LICENSE will be excluded > from being packaged in package.bbclass via LICENSE_EXCLUSION- > internal variable. > > The exception is predominately used for GPLv3 related packages, based on > the emails replies overnight. > > > Proposal: > > Keep the existing INCOMPATIBLE_LICENSE variable with the same behavior. > The values in INCOMPATIBLE_LICENSE should be SDPX normalized license > strings. > > As Richard has already suggested an alternative variable that is more > meaningful: INCOMPATIBLE_LICENSE_EXCEPTION with an a : > value. Rename the LICENSE_EXCLUSION- variable to make it clear that > it is an internal variable. The usage of the _EXCEPTION variable should > contain pkg names not recipe name. ** This would be an important change ** > > Clean up code as appropriate to ensure the exceptions are handled once > and identified during parsing. > > I will start working on the implementation, Monday is a holiday in the > US, so this should give sometime for this to be reviewed for Tuesday. Thanks Saul, from my perspective I think this is a good balance between cleaning up the syntax and other issues whilst being practical to implement and test in the time frames available. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#95393): https://lists.openembedded.org/g/openembedded-devel/message/95393 Mute This Topic: https://lists.openembedded.org/mt/89274042/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
On Fri, 2022-02-18 at 23:34 +, Peter Kjellerstedt wrote: > Warning: wall of text ahead. Sorry about that, but I believe it is > important that we get this right if we are redesigning it. > > TL;DR: see the end for the new suggested licensing variables. > > > -Original Message- > > From: openembedded-devel@lists.openembedded.org > de...@lists.openembedded.org> On Behalf Of Richard Purdie > > Sent: den 18 februari 2022 15:14 > > To: Saul Wold ; openembedded- > > architect...@lists.openembedded.org; OE-core > c...@lists.openembedded.org>; OpenEmbedded Devel List > de...@lists.openembedded.org> > > Subject: Re: [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage > > > > On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote: > > > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > > > and processed to possibly include a COMPATIBLE_LICENSES variable as > > > well, see PeterK's email [0] > > > > > > I am trying to determine the usage of WHITELIST_ which would be > > > used to override a license that might be listed in INCOMPATIBLE_LICENSES > > > variable. > > > > > > Randy and I have done a quick and dirty survey of a 100 or so layers > > > (thanks Randy) and could not find any real usage other than what's > > > currently in OE-Core for WHITELIST_GPL-3.0. > > > > > > If you are using WHITELIST_, please let me reply with your > > > usage. > > > > > > > > > [0] https://lists.openembedded.org/g/openembedded-devel/message/95166 > > > > We need to be mindful that we need to resolve this to unblock the other > > language changes and feature creep here is potentially problematic. I do > > think it is worth trying to improve things rather than blindly allowing > > the horrible syntax in this variable to continue though. > > > > The test case we have for this currently is: > > > > WHITELIST_GPL-3.0:pn-core-image-minimal = "bash" > > > > so I'd wondered about an alternative of: > > > > INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash:GPL-3.0" > > You do not really need the license here (more than possibly as > information to anyone reading the code). Specifying that a package is > allowed in an image regardless of its licenses can just as well be > done by allowing the variable to take a list of packages: > > INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash readline" I'm not sure I agree with that. I get the feeling some people want to allow these packages as long as they're with license X. Licenses can change over time and this allows a safety net that if it changes, the exception has to be updated too. > An alternative (and in my opinion better) variable name would be: > > IMAGE_ALLOW_PACKAGES:pn-core-image-minimal = "bash readline" > > focusing on that this is a list of _packages_ allowed for a given > _image_. This does not explicitly mention licenses, but I do not > believe that is needed. If you assume this isn't being done on license reasons, sure. Except see above, I think this does need to account for licenses, at least the way many use it. > After all there could be multiple reasons a package is not allowed in > an image and this variable would allow to > ignore them all because that is typically what you want to do: > specify that you really want that package in that image. I guess > this is in some sense the opposite of PACKAGE_EXCLUDE. And I guess > like :append vs :remove, if someone for some reason specifies a > package in both IMAGE_ALLOW_PACKAGES and PACKAGE_EXCLUDE, then the > later should win (to err on the side of caution). How would IMAGE_ALLOW_PACKAGES work and be different to IMAGE_INSTALL? This interface would likely confuse more users than it would help. > For the case where you want to allow a recipe to be built despite > it using licenses that are otherwise not allowed you can simply use > > INCOMPATIBLE_LICENSE:pn-foo = "" > > and don't really need a separate variable for it. That is a good point and perhaps should influence how an INCOMPATIBLE_LICENSE_EXCEPTIONS should be package based rather than recipe. I doubt the pn- override existed when that variable was originally added. > > I'm still of the opinion the AVAILABLE_LICENSES variable is something we > > should be aiming to remove ultimately too, it has horrible issues with > > layers changing hashes for all recipes. > > Since I was the one to introduce it, I will answer to that. It was > introduced so that it is possible to specify c
Re: [OE-core] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
On Fri, 2022-02-18 at 14:13 +, Richard Purdie via lists.openembedded.org wrote: > On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote: > > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > > and processed to possibly include a COMPATIBLE_LICENSES variable as > > well, see PeterK's email [0] > > > > I am trying to determine the usage of WHITELIST_ which would be > > used to override a license that might be listed in INCOMPATIBLE_LICENSES > > variable. > > > > Randy and I have done a quick and dirty survey of a 100 or so layers > > (thanks Randy) and could not find any real usage other than what's > > currently in OE-Core for WHITELIST_GPL-3.0. > > > > If you are using WHITELIST_, please let me reply with your usage. > > > > > > [0] https://lists.openembedded.org/g/openembedded-devel/message/95166 > > We need to be mindful that we need to resolve this to unblock the other > language > changes and feature creep here is potentially problematic. I do think it is > worth trying to improve things rather than blindly allowing the horrible > syntax > in this variable to continue though. > > The test case we have for this currently is: > > WHITELIST_GPL-3.0:pn-core-image-minimal = "bash" > > so I'd wondered about an alternative of: > > INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash:GPL-3.0" > > which matches the current functionality, removes the issue that the name of > the > variable is unknown without iterating every possible license name and makes it > clear where it is applying to. > > I don't really like INCOMPATIBLE_LICENSE_ALLOWED_RECIPES since: > > a) it is long > b) it refers to recipes when it works against packages Just as a warning, the code is actually confused. The base.bbclass code assumes it is a recipe name, the license_image code assumes it is a package name. All the more reason to come up with a standard and resolve this. My proposal stands but we need to decide if it is a recipe or package name that is listed (or both?). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#95376): https://lists.openembedded.org/g/openembedded-devel/message/95376 Mute This Topic: https://lists.openembedded.org/mt/89233279/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
On Thu, 2022-02-17 at 15:01 -0800, Saul Wold wrote: > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > and processed to possibly include a COMPATIBLE_LICENSES variable as > well, see PeterK's email [0] > > I am trying to determine the usage of WHITELIST_ which would be > used to override a license that might be listed in INCOMPATIBLE_LICENSES > variable. > > Randy and I have done a quick and dirty survey of a 100 or so layers > (thanks Randy) and could not find any real usage other than what's > currently in OE-Core for WHITELIST_GPL-3.0. > > If you are using WHITELIST_, please let me reply with your usage. > > > [0] https://lists.openembedded.org/g/openembedded-devel/message/95166 We need to be mindful that we need to resolve this to unblock the other language changes and feature creep here is potentially problematic. I do think it is worth trying to improve things rather than blindly allowing the horrible syntax in this variable to continue though. The test case we have for this currently is: WHITELIST_GPL-3.0:pn-core-image-minimal = "bash" so I'd wondered about an alternative of: INCOMPATIBLE_LICENSE_EXCEPTIONS:pn-core-image-minimal = "bash:GPL-3.0" which matches the current functionality, removes the issue that the name of the variable is unknown without iterating every possible license name and makes it clear where it is applying to. I don't really like INCOMPATIBLE_LICENSE_ALLOWED_RECIPES since: a) it is long b) it refers to recipes when it works against packages (INCOMPATIBLE_LICENSE_PACKAGE_EXCEPTIONS is more correct but still long) I do like it mentioning INCOMPATIBLE_LICENSE in full since it works in conjunction with that variable and that is definitely not clear from the current WHITELIST_XXX until you look at the code. I'm still of the opinion the AVAILABLE_LICENSES variable is something we should be aiming to remove ultimately too, it has horrible issues with layers changing hashes for all recipes. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#95375): https://lists.openembedded.org/g/openembedded-devel/message/95375 Mute This Topic: https://lists.openembedded.org/mt/89221730/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
On Tue, 2022-01-25 at 07:50 -0800, Chuck Wolber wrote: > On Mon, Jan 24, 2022 at 8:18 AM Jon Mason wrote: > > %< SNIP %< > > > Branch Names > > The “master” branches on the relevant OpenEmbedded and Yocto Project > > git trees will be changed to an alternative name at some point in the > > future. The current preferred name is “devel”. > > > > > Why devel instead of main [1]? > > [1] > https://lore.kernel.org/git/pull.656.v4.git.1593009996.gitgitgad...@gmail.com/ The idea is we're trying to use the language which makes sense and "devel" says what the branch is/does. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#95073): https://lists.openembedded.org/g/openembedded-devel/message/95073 Mute This Topic: https://lists.openembedded.org/mt/88674414/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-XXX] [PATCH] gattlib: Place pkgconfig file in correct package
Fixes in OE-Core added some pkgconfig dependencies back and this flagged
that the .pc file was in ${PN}, not ${PN}-dev. Fix that.
Signed-off-by: Richard Purdie
---
meta-oe/recipes-connectivity/gattlib/gattlib_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-connectivity/gattlib/gattlib_git.bb
b/meta-oe/recipes-connectivity/gattlib/gattlib_git.bb
index 234f840f9..8485013ba 100644
--- a/meta-oe/recipes-connectivity/gattlib/gattlib_git.bb
+++ b/meta-oe/recipes-connectivity/gattlib/gattlib_git.bb
@@ -29,4 +29,4 @@ EXTRA_OECMAKE += "-DGATTLIB_BUILD_DOCS=OFF"
inherit pkgconfig cmake
FILES:${PN} = "${libdir}/*"
-FILES:${PN}-dev = "${includedir}/*"
+FILES:${PN}-dev = "${includedir}/* ${libdir}/pkgconfig"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#93189):
https://lists.openembedded.org/g/openembedded-devel/message/93189
Mute This Topic: https://lists.openembedded.org/mt/86020028/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [OE-core] [master][PATCH 0/4] Reproducible LTO builds
On Thu, 2021-08-05 at 17:54 -0400, Tony Battersby wrote: > On 8/5/21 6:21 AM, Richard Purdie wrote: > > On Wed, 2021-08-04 at 20:13 -0400, Randy MacLeod wrote: > > > On 2021-07-27 9:34 a.m., Tony Battersby wrote: > > > > Currently, enabling Link Time Optimization via: > > > > > > > > require conf/distro/include/lto.inc > > > > DISTRO_FEATURES_append = " lto" > > > > > > > > makes the build non-reproducible (as in > > > > https://reproducible-builds.org/). This patch set fixes some of the > > > > problems, but is not yet a complete solution. > > > > > > > > This patch set addresses the following bugs: > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481 > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14490 > > > > > > > > openembedded-core patches > > > > 1/4: lto.inc: disable LTO for grub > > > > 2/4: gcc: Backport patch to make LTO builds more reproducible > > > > 3/4: bitbake.conf: add DEBUG_PREFIX_MAP to TARGET_LDFLAGS > > > > > > > > openembedded-devel patches > > > > 4/4: net-snmp: fix QA Issue after LDFLAGS change > > > > > > > > Patch 3 adds DEBUG_PREFIX_MAP to TARGET_LDFLAGS (it was already in > > > > TARGET_CFLAGS). This could possibly be done differently, such as by > > > > removing it from TARGET_CFLAGS and adding it to TOOLCHAIN_OPTIONS, > > > > TARGET_CC_ARCH, or TUNE_CCARGS, but I haven't tested those. Let me know > > > > if there is a better/preferred way to do it. > > > > > > > > The TARGET_LDFLAGS change broke net-snmp from meta-networking, so I have > > > > included a patch to fix that. Other packages might have been broken as > > > > well, although I haven't found any others. > > > > > > > > With all these patches, there are still many shared libraries in /lib > > > > and /usr/lib that are still not reproducible with LTO enabled because > > > > x86_64-poky-linux-libtool filters out the -f*-prefix-map flags added by > > > > patch 3 when linking shared libraries. /usr/lib/libbz2.so.1.0.6 from > > > > the libbz2 package from the bzip2 recipe is a good example. I do not > > > > have a patch for that problem. I will leave that to someone else. > > > > > > > > So this is what we need to achieve reproducible LTO builds: > > > > *) This patch set > > > > *) A fix for libtool > > > > *) Add LTO to reproducible builds testing if appropriate (e.g. > > > > meta/lib/oeqa/selftest/cases/reproducible.py, CI on Autobuilder) > > > > *) Fixes for individual packages, if needed > > > > *) Once everything works, update the documentation again (I previously > > > > requested a documentation change for this bug, which will eventually > > > > show up at > > > > http://docs.yoctoproject.org/test-manual/reproducible-builds.html). > > > This is certainly a few steps in the right direction with a good outline > > > of what's next. > > > > > > I suspect that Richard has been busy with other things like overrides > > > and the update to glibc-2.34. > > > > > > Do you have any suggestions or questions about what we should do > > > with this patch series Richard? > > Thanks for the reminder, I've been meaning to queue/test this which I will > > do. The gcc version has been bumped but I ported the patch forward to it > > and the patches are in master-next for testing. It is great to see this > > support moving forward. > > > > Much as it pains me to admit having any libtool knowledge, I may be able to > > help with that bit. There is an untested patch below which may address that > > issue, or at least give a good hint on how to do it if it doesn't work. I > > don't have an environment to test easily right now. > > > > Cheers, > > > > Richard > > I tested your libtool patch in master-next with the bzip2 recipe. It > works as intended; libbz2.so.1.0.6 and all the other output files are > now reproducible with LTO enabled. I also verified that libtool is > passing the -f*-prefix-map flags to the link command in log.do_compile > as intended. > > I also verified that core-image-minimal builds successfully with the > libtool patch. Thanks for testing that, sounds like it helps that issue. I'll queue that patch. Unfortunately even with the ruby fix I queued, we still see repr
Re: [oe] [OE-core] [master][PATCH 0/4] Reproducible LTO builds
On Wed, 2021-08-04 at 20:13 -0400, Randy MacLeod wrote:
> On 2021-07-27 9:34 a.m., Tony Battersby wrote:
> > Currently, enabling Link Time Optimization via:
> >
> > require conf/distro/include/lto.inc
> > DISTRO_FEATURES_append = " lto"
> >
> > makes the build non-reproducible (as in
> > https://reproducible-builds.org/). This patch set fixes some of the
> > problems, but is not yet a complete solution.
> >
> > This patch set addresses the following bugs:
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14490
> >
> > openembedded-core patches
> > 1/4: lto.inc: disable LTO for grub
> > 2/4: gcc: Backport patch to make LTO builds more reproducible
> > 3/4: bitbake.conf: add DEBUG_PREFIX_MAP to TARGET_LDFLAGS
> >
> > openembedded-devel patches
> > 4/4: net-snmp: fix QA Issue after LDFLAGS change
> >
> > Patch 3 adds DEBUG_PREFIX_MAP to TARGET_LDFLAGS (it was already in
> > TARGET_CFLAGS). This could possibly be done differently, such as by
> > removing it from TARGET_CFLAGS and adding it to TOOLCHAIN_OPTIONS,
> > TARGET_CC_ARCH, or TUNE_CCARGS, but I haven't tested those. Let me know
> > if there is a better/preferred way to do it.
> >
> > The TARGET_LDFLAGS change broke net-snmp from meta-networking, so I have
> > included a patch to fix that. Other packages might have been broken as
> > well, although I haven't found any others.
> >
> > With all these patches, there are still many shared libraries in /lib
> > and /usr/lib that are still not reproducible with LTO enabled because
> > x86_64-poky-linux-libtool filters out the -f*-prefix-map flags added by
> > patch 3 when linking shared libraries. /usr/lib/libbz2.so.1.0.6 from
> > the libbz2 package from the bzip2 recipe is a good example. I do not
> > have a patch for that problem. I will leave that to someone else.
> >
> > So this is what we need to achieve reproducible LTO builds:
> > *) This patch set
> > *) A fix for libtool
> > *) Add LTO to reproducible builds testing if appropriate (e.g.
> > meta/lib/oeqa/selftest/cases/reproducible.py, CI on Autobuilder)
> > *) Fixes for individual packages, if needed
> > *) Once everything works, update the documentation again (I previously
> > requested a documentation change for this bug, which will eventually
> > show up at
> > http://docs.yoctoproject.org/test-manual/reproducible-builds.html).
>
> This is certainly a few steps in the right direction with a good outline
> of what's next.
>
> I suspect that Richard has been busy with other things like overrides
> and the update to glibc-2.34.
>
> Do you have any suggestions or questions about what we should do
> with this patch series Richard?
Thanks for the reminder, I've been meaning to queue/test this which I will
do. The gcc version has been bumped but I ported the patch forward to it
and the patches are in master-next for testing. It is great to see this
support moving forward.
Much as it pains me to admit having any libtool knowledge, I may be able to
help with that bit. There is an untested patch below which may address that
issue, or at least give a good hint on how to do it if it doesn't work. I
don't have an environment to test easily right now.
Cheers,
Richard
>From 7681b0a1461f22034e1f70328a060db34474c60f Mon Sep 17 00:00:00 2001
From: Richard Purdie
Date: Thu, 5 Aug 2021 11:18:20 +0100
Subject: libtool: Fix lto option passing?
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/libtool/libtool-2.4.6.inc| 1 +
meta/recipes-devtools/libtool/libtool/lto-prefix.patch | 16
2 files changed, 17 insertions(+)
create mode 100644 meta/recipes-devtools/libtool/libtool/lto-prefix.patch
diff --git a/meta/recipes-devtools/libtool/libtool-2.4.6.inc
b/meta/recipes-devtools/libtool/libtool-2.4.6.inc
index c1cbceb51f..6748d7468e 100644
--- a/meta/recipes-devtools/libtool/libtool-2.4.6.inc
+++ b/meta/recipes-devtools/libtool/libtool-2.4.6.inc
@@ -23,6 +23,7 @@ SRC_URI = "${GNU_MIRROR}/libtool/libtool-${PV}.tar.gz \
file://0001-libtool-Check-for-static-libs-for-internal-compiler-.patch \
file://0001-Makefile.am-make-sure-autoheader-run-before-autoconf.patch \
file://0001-Makefile.am-make-sure-autoheader-run-before-automake.patch \
+ file://lto-prefix.patch \
"
SRC_URI[md5sum] = "addf44b646ddb4e3919805aa88fa7c5e"
diff --git a/meta/recipes-devtools/libtool/libtool/lto-prefix.patch
b/meta/recipes-
devtools/libtool/libtool/lto-prefix.patch
new file mode 100644
index 00..f788b3fc27
--- /dev/null
+++ b/met
Re: [oe] [yocto] [meta-java] icedtea7 fetching error
On Mon, 2021-06-14 at 21:31 +, Richard Leitner - SKIDATA wrote: > On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote: > > On Mon, 2021-06-14 at 20:20 +, Richard Leitner - SKIDATA wrote: > > > On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote: > > > > I have the tarball. I think we should toss it somewhere safe and update > > > > the > > > > recipe, as it is unlikely the old mercurial repo is coming back. > > > > > > > > Suggestions? > > > > > > Sorry for the late reply, I was on vacation 😉. > > > > > > Nothing that comes to my mind directly. Do you know of any hosting > > > possibilites from YP or OE-Core? > > > > > > @Richard: Sorry for putting you in that conversation without warning... > > > But maybe you may guide us in a direction where to host/mirror some > > > "legacy" > > > meta-java source tarballs? > > > > If someone points me at the tarballs I can probably sort something out with > > our source mirrors. > > Thank you very much Richard! > The openjdk8 tarballs are now hosted at > https://downloads.yoctoproject.org/mirror/sources/ > with their local download names. > > Unfortunately I currently don't have the time and resources to provide a > patch for fixing the URLs and adding the mirror. > So help is greatly appreciated! In theory if these are the names the metadata was using and you have the standard OE/Yocto source mirrors, this should "just work"... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#91896): https://lists.openembedded.org/g/openembedded-devel/message/91896 Mute This Topic: https://lists.openembedded.org/mt/83542203/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [PATCH] [meta-python] python3-m2crypto: Improve multilib header workaround
The multilib header issues continue to cause problems for this recipe. Simplfy
the workaround to something which resolves all the current issues and
is much simpler to understand/maintain.
Signed-off-by: Richard Purdie
---
.../python/python3-m2crypto_0.37.1.bb | 25 ---
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/meta-python/recipes-devtools/python/python3-m2crypto_0.37.1.bb
b/meta-python/recipes-devtools/python/python3-m2crypto_0.37.1.bb
index 896d9d2cc..45abaac33 100644
--- a/meta-python/recipes-devtools/python/python3-m2crypto_0.37.1.bb
+++ b/meta-python/recipes-devtools/python/python3-m2crypto_0.37.1.bb
@@ -36,27 +36,12 @@ SWIG_FEATURES_x32 = "-D__ILP32__"
SWIG_FEATURES ?= "-D__${HOST_ARCH}__"
export SWIG_FEATURES
-# Get around a problem with swig, but only if the
-# multilib header file exists.
-#
do_configure_prepend() {
-${CPP} -dM - < /dev/null | grep -v
'__\(STDC\|REGISTER_PREFIX\|GNUC\|STDC_HOSTED\)__' \
-| sed 's/^\(#define \([^ ]*\) .*\)$/#undef \2\n\1/' >
${S}/SWIG/gcc_macros.h
-
-if [ "${SITEINFO_BITS}" = "64" ];then
-bit="64"
-else
-bit="32"
-fi
-
-if [ -e ${STAGING_INCDIR}/openssl/opensslconf-${bit}.h ] ;then
-for i in SWIG/_ec.i SWIG/_evp.i; do
-sed -i -e "s/opensslconf.*\./opensslconf-${bit}\./" "${S}/$i"
-done
-elif [ -e ${STAGING_INCDIR}/openssl/opensslconf-n${bit}.h ] ;then
-for i in SWIG/_ec.i SWIG/_evp.i; do
-sed -i -e "s/opensslconf.*\./opensslconf-n${bit}\./" "${S}/$i"
-done
+# swig can't handle any multilib header redirection so just remove it for
this build
+if [ -e ${STAGING_INCDIR}/openssl/opensslconf-64.h ] ;then
+cp ${STAGING_INCDIR}/openssl/opensslconf-64.h
${STAGING_INCDIR}/openssl/opensslconf.h
+elif [ -e ${STAGING_INCDIR}/openssl/opensslconf-32.h ] ;then
+cp ${STAGING_INCDIR}/openssl/opensslconf-32.h
${STAGING_INCDIR}/openssl/opensslconf.h
fi
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#91189):
https://lists.openembedded.org/g/openembedded-devel/message/91189
Mute This Topic: https://lists.openembedded.org/mt/82678734/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [yocto] [OE-core] Let me tell you how I really feel. Zero filter. If you need meta-python2, you need to become a maintainer. Immediately. Period.
On Mon, 2021-02-01 at 15:40 +0100, Martin Jansa wrote: > can I get the write access to meta-python2 as mentioned above? > > I have 2 fixes to make it parse able with latest oe-core: > https://lists.openembedded.org/g/openembedded-devel/message/89201 > https://lists.openembedded.org/g/openembedded-devel/message/89200 > > to fix issues discussed in: > https://github.com/openembedded/openembedded-core/commit/fd6a007efa7cb45101a66f294af81d9d33bb3fab#commitcomment-46565284 > https://lists.openembedded.org/g/openembedded-core/message/147477 > https://lists.openembedded.org/g/openembedded-core/message/147514 This sounds like a good idea to me and I have admin right so I've given you access :) Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#89231): https://lists.openembedded.org/g/openembedded-devel/message/89231 Mute This Topic: https://lists.openembedded.org/mt/80286760/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [PATCH] minifi-cpp: Adapt to potential psuedo changes
If we do adopt path filtering for pseudo, we may filter out ${B} as not
needing to be tracked for "root" permissions. We do need to track
the data installed by do_install though, so move the temp directory this
recipe uses out of ${B} and place it in WORKDIR.
Signed-off-by: Richard Purdie
---
meta-oe/recipes-extended/minifi-cpp/minifi-cpp_0.7.0.bb | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta-oe/recipes-extended/minifi-cpp/minifi-cpp_0.7.0.bb
b/meta-oe/recipes-extended/minifi-cpp/minifi-cpp_0.7.0.bb
index 37036ebbb..d75cb9f4e 100644
--- a/meta-oe/recipes-extended/minifi-cpp/minifi-cpp_0.7.0.bb
+++ b/meta-oe/recipes-extended/minifi-cpp/minifi-cpp_0.7.0.bb
@@ -52,9 +52,10 @@ TARGET_CXXFLAGS_append_riscv32 += "-fpic"
TARGET_CFLAGS_append_riscv64 += "-fpic"
TARGET_CXXFLAGS_append_riscv64 += "-fpic"
+do_install[cleandirs] += "${WORKDIR}/minifi-install"
do_install() {
-DESTDIR='${B}/minifi-install' cmake_runcmake_build --target
${OECMAKE_TARGET_INSTALL}
+DESTDIR='${WORKDIR}/minifi-install' cmake_runcmake_build --target
${OECMAKE_TARGET_INSTALL}
MINIFI_BIN=${base_prefix}${bindir}
MINIFI_HOME=${base_prefix}${sysconfdir}/minifi
@@ -63,8 +64,8 @@ do_install() {
install -d ${D}${MINIFI_BIN}
install -d ${D}${MINIFI_HOME}/conf
-cp -a ${B}/minifi-install/usr/bin/* ${D}${MINIFI_BIN}/
-cp -a ${B}/minifi-install/usr/conf/* ${D}${MINIFI_HOME}/conf/
+cp -a ${WORKDIR}/minifi-install/usr/bin/* ${D}${MINIFI_BIN}/
+cp -a ${WORKDIR}/minifi-install/usr/conf/* ${D}${MINIFI_HOME}/conf/
sed -i
's|#appender.rolling.directory=.*|appender.rolling.directory='${MINIFI_LOG}'|g'
\
${D}${MINIFI_HOME}/conf/minifi-log.properties
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#87293):
https://lists.openembedded.org/g/openembedded-devel/message/87293
Mute This Topic: https://lists.openembedded.org/mt/77172511/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] meta-openembedded dunfell maintainer
On Tue, 2020-05-12 at 14:18 +0100, Richard Purdie wrote: > The OE TSC would like to ask if there is anyone interested in stepping > up to look after the dunfell branch of meta-openembedded? > > dunfell is an LTS release for Yocto Project and it would be good to > have some kind of plan for meta-openembedded as well. > > We believe the 'policy' for the branch would be broadly similar to the > one being used for openembedded-core, > https://wiki.yoctoproject.org/wiki/LTS. > > If anyone is interested, please reply here or talk to Khem in the first > instance as the layer maintainer. He can no doubt answer questions if > anyone does want to discuss what the role would involve. Its usually > for the layer maintainer to choose the maintainer but the OE TSC would > be the final decision maker if needed. There was a little bad timing and after the TSC was asked to do this, Armin stepped forward to maintain dunfell but the TSC didn't realise. Thanks Armin! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#84333): https://lists.openembedded.org/g/openembedded-devel/message/84333 Mute This Topic: https://lists.openembedded.org/mt/74157965/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-python] [PATCH] python3-parse-type: Modify ptest output format
On Tue, 2020-05-12 at 22:23 +0800, zangrc wrote:
> Signed-off-by: Zang Ruochen
> ---
> .../recipes-devtools/python/python3-parse-type/run-ptest| 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-python/recipes-devtools/python/python3-parse-type/run-ptest
> b/meta-python/recipes-devtools/python/python3-parse-type/run-ptest
> index 5cec71169..b63c4de0d 100644
> --- a/meta-python/recipes-devtools/python/python3-parse-type/run-ptest
> +++ b/meta-python/recipes-devtools/python/python3-parse-type/run-ptest
> @@ -1,3 +1,3 @@
> #!/bin/sh
>
> -pytest
> +pytest -o log_cli=true -o log_cli_level=INFO | sed -e 's/\[...%\]//g'| sed
> -e 's/PASSED/PASS/g'| sed -e 's/FAILED/FAIL/g'|sed -e 's/SKIPPED/SKIP/g'| awk
> '{if ($NF=="PASS" || $NF=="FAIL" || $NF=="SKIP" || $NF=="XFAIL" ||
> $NF=="XPASS"){printf "%s: %s\n", $NF, $0}else{print}}'| awk '{if ($NF=="PASS"
> || $NF=="FAIL" || $NF=="SKIP" || $NF=="XFAIL" || $NF=="XPASS") {$NF="";print
> $0}else{print}}'
Rather than doing this for every python module, it may be an idea to
consider:
a) teaching ptest runner how to handle the alternate output format
(triggered by run-ptest-XXX instead of run-ptest)
or
b) adding a common python script which could avoid all this sed/awk
magic and the extra dependencies
or
c) patch in a parameter to pytest which outputs the data in the format
we need.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#84332):
https://lists.openembedded.org/g/openembedded-devel/message/84332
Mute This Topic: https://lists.openembedded.org/mt/74153024/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] meta-openembedded dunfell maintainer
The OE TSC would like to ask if there is anyone interested in stepping up to look after the dunfell branch of meta-openembedded? dunfell is an LTS release for Yocto Project and it would be good to have some kind of plan for meta-openembedded as well. We believe the 'policy' for the branch would be broadly similar to the one being used for openembedded-core, https://wiki.yoctoproject.org/wiki/LTS. If anyone is interested, please reply here or talk to Khem in the first instance as the layer maintainer. He can no doubt answer questions if anyone does want to discuss what the role would involve. Its usually for the layer maintainer to choose the maintainer but the OE TSC would be the final decision maker if needed. Cheers, Richard (on behalf of Khem and the OE TSC) -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#84313): https://lists.openembedded.org/g/openembedded-devel/message/84313 Mute This Topic: https://lists.openembedded.org/mt/74157965/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [RFC PATCH] python: remove Python 2 and all supporting classes
On Fri, 2020-01-17 at 14:16 +, Ross Burton wrote: > Python 2 ceased being maintained on the 1st January 2020. We've > already > removed all users of it from oe-core so the final step is to move the > recipe and supporting classes to meta-python2. > > The following are removed in this commit: > - python and python-native 2.7.17 > - python-setuptools > - The classes pythonnative, pythondir, distutils, setuptools > > Signed-off-by: Ross Burton Thanks Ross. I tested this on the autobuilder, only 'surprise' is meta- gplv2 fails: https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1458 (python dependency of mc). Just delete mc from that layer? Some of the other failures there are from other bits of -next. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] [openembedded-core] 28/29: sstatesig: Improve debug output if getpwuid() fails
On Tue, 2020-01-14 at 22:55 +0100, Martin Jansa wrote: > Would it makes sense to print the exception in the same bb.warn, so > that the missing UID is written in the same line as the path - not in > the exception stack trace printed after? But maybe it's not important > as with raise there will always be just one exception like this and > it will be printed immediately after (while in my debug before I was > listing all the files with this issue without leaving the build to > fail). I'm torn on that, I don't really want to interfere with the error handling path, equally as it stands today the traceback isn't so useful without knowing where it failed. Not straight forward :/. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Build info in the spec file
On Wed, 2019-10-23 at 14:00 -0700, Muminul Russell wrote: > Hello Developers, > > Yocto can generate spec file for rpm packaging. But that spec file > does not have %build and %install macro. Is there any work done > already to include those 2 macros? Or could you give me hints how can > I do that? OE uses its own cross building process. You can't encode that cross building process into those macros. rpmbuild assumes native compiling. People have tried and concluded its really not practical. Think about the fact that even if you did have something there, the original process used to run the build would be different. That means two different code paths, one of which will probably end up with different results and hence be broken. So yes, I understand the desire but it really doesn't make sense. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/2] python3-astor: Upgrade 0.7.1->0.8.0
Signed-off-by: Richard Purdie
---
.../python/{python3-astor_0.7.1.bb => python3-astor_0.8.0.bb} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename meta-python/recipes-devtools/python/{python3-astor_0.7.1.bb =>
python3-astor_0.8.0.bb} (100%)
diff --git a/meta-python/recipes-devtools/python/python3-astor_0.7.1.bb
b/meta-python/recipes-devtools/python/python3-astor_0.8.0.bb
similarity index 100%
rename from meta-python/recipes-devtools/python/python3-astor_0.7.1.bb
rename to meta-python/recipes-devtools/python/python3-astor_0.8.0.bb
--
2.20.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/2] python3-astor: Fix issue with new version of setuptools
Signed-off-by: Richard Purdie --- .../python3-astor/fix-new-setuptools.patch | 18 ++ .../python/python3-astor_0.8.0.bb | 3 ++- 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 meta-python/recipes-devtools/python/python3-astor/fix-new-setuptools.patch diff --git a/meta-python/recipes-devtools/python/python3-astor/fix-new-setuptools.patch b/meta-python/recipes-devtools/python/python3-astor/fix-new-setuptools.patch new file mode 100644 index 0..90defe25c --- /dev/null +++ b/meta-python/recipes-devtools/python/python3-astor/fix-new-setuptools.patch @@ -0,0 +1,18 @@ +New versions of setuptools can't parse this expression. We know our python versions +match so just remove it until upstream fixes it. + +Signed-off-by: Richard Purdie +Upstream-Status: Pending + +Index: git/setup.cfg +=== +--- git.orig/setup.cfg git/setup.cfg +@@ -34,7 +34,6 @@ classifiers = + zip_safe = True + include_package_data = True + packages = find: +-python_requires = >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.* + + [options.packages.find] + exclude = tests diff --git a/meta-python/recipes-devtools/python/python3-astor_0.8.0.bb b/meta-python/recipes-devtools/python/python3-astor_0.8.0.bb index c2dc9245c..97dbdbbea 100644 --- a/meta-python/recipes-devtools/python/python3-astor_0.8.0.bb +++ b/meta-python/recipes-devtools/python/python3-astor_0.8.0.bb @@ -4,7 +4,8 @@ SECTION = "devel/python" LICENSE = "BSD-3-Clause" LIC_FILES_CHKSUM = "file://LICENSE;md5=561205fdabc3ec52cae2d30815b8ade7" -SRC_URI = "git://github.com/berkerpeksag/astor.git" +SRC_URI = "git://github.com/berkerpeksag/astor.git \ + file://fix-new-setuptools.patch" SRCREV ?= "4ca3a26e52f08678854c2841cd0fdf223461e47d" inherit setuptools3 -- 2.20.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] libiio: Disable python support for determism
Recent cmake changes in OE-Core mean python is now detected from
PATH. For determism, disable the python bindings to match
previous behaviour.
Signed-off-by: Richard Purdie
---
meta-oe/recipes-support/libiio/libiio_git.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-oe/recipes-support/libiio/libiio_git.bb
b/meta-oe/recipes-support/libiio/libiio_git.bb
index 4e57d5b77..63248b4e3 100644
--- a/meta-oe/recipes-support/libiio/libiio_git.bb
+++ b/meta-oe/recipes-support/libiio/libiio_git.bb
@@ -22,6 +22,7 @@ DEPENDS = " \
EXTRA_OECMAKE = " \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DUDEV_RULES_INSTALL_DIR=${nonarch_base_libdir}/udev/rules.d \
+-DPYTHON_BINDINGS=OFF \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '-DWITH_SYSTEMD=ON
-DSYSTEMD_UNIT_INSTALL_DIR=${systemd_system_unitdir}', '', d)} \
"
--
2.20.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Perl5 build issues (meta-cpan only?)
On Thu, 2019-07-25 at 14:52 +0200, Jens Rehsack wrote: > Maybe one or the other has already seen the following message in > connection with modules::Build-based Perl modules: > ERROR: hash-fieldhash-perl-0.15-r0 do_package_qa: QA Issue: No > GNU_HASH in the ELF binary /home/sno/gpw-community-bsp/gpw-yocto- > platform/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/hash-fieldhash- > perl/0.15-r0/packages-split/hash-fieldhash- > perl/usr/lib/perl5/vendor_perl/5.30.0/arm- > linux/auto/Hash/FieldHash/FieldHash.so, didn't pass LDFLAGS? > [ldflags] > ERROR: hash-fieldhash-perl-0.15-r0 do_package_qa: QA run found fatal > errors. Please consider fixing them. > ERROR: hash-fieldhash-perl-0.15-r0 do_package_qa: > ERROR: hash-fieldhash-perl-0.15-r0 do_package_qa: Function failed: > do_package_qa > ERROR: Logfile of failure stored in: /home/sno/gpw-community-bsp/gpw- > yocto-platform/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/hash- > fieldhash-perl/0.15-r0/temp/log.do_package_qa.12168 > ERROR: Task (/home/sno/gpw-community-bsp/sources/meta-cpan/recipes- > devel/hash-fieldhash-perl/hash-fieldhash-perl_0.15.bb:do_package_qa) > failed with exit code '1' > > I think the reason is in > https://metacpan.org/source/AMBS/ExtUtils-CBuilder-0.280231/lib/ExtUtils/CBuilder/Base.pm#L319 > where the arguments from ldflags are thrown away. That seems very likely, yes. > When those issues came up somewhere else than in meta-cpan, please > let me know (only open-source ^^). We should develop a fix like > https://github.com/meta-cpan/meta-cpan/commit/52ded0759daa3bff909bf5fac6d31c6bc52d713e > then ... > > For now - I think Alberto should receive a patch to use ldflags, too. > > I cannot decide how critic and important that is to make it into > perl-5.30.1 ... > When ExtUtils::CBuilder is properly fixed, no changed are required to > cpan_build.bbclass, aren't they? I'm not sure I understand exactly what you're asking. I think that if the question is whether we should fix this in the perl recipe itself with a patch, so we don't have to add workarounds all over the metadata, I think the answer is yes, we should. It would obviously be ideal if such a change were a backported on which was accepted upstream so we don't have to carry the patch forever! :) Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Git commit process question.
On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote: > Hello, > > I have noticed a large number of git commits with no header > information being accepted. Can you be more specific about what "no header information" means? You mean a shortlog and no full log message? Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe] [PATCH] rapidjson: fix cmake artifacts installation for non-default BASELIB case
On Thu, 2019-02-07 at 09:59 -0800, Khem Raj wrote: > On Thu, Feb 7, 2019 at 9:31 AM Ruslan Bilovol > wrote: > > I see you picked up this patch to master-next, but the patch's > > author > > is incorrect: > > https://git.openembedded.org/meta-openembedded/commit/?h=master-next&id=cf54629463841242ce1faa90f6ad4a2383df3b2c > > > > Could you please fix it? > > > > sure > > > > This is the same issue we faced with oe-core mailing list, I > > remember > > Richard Purdie had some scripts to fix it automatically > > > > I wonder why is this happening? May be Michael can help us > understand, > why patchwork would feed a worng author or is it > some email client error somewhere? Its an email client problem. Roughly speaking the email was sent from an IP address which according to DMARC shouldn't be sending email. The list servers therefore rewrite it to a valid address to stop it being stopped as spam. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [meta-oe][PATCH] directfb: fix tslib version check in configure.in
On Tue, 2018-08-21 at 08:36 +, Jonas Mark (BT-FIR/ENG1) wrote: > Hi Richard, > > This is my third attempt getting my reply onto the mailing list. I > suspect the first two attempts were filtered due to the link to the > v2 > patch I added. I removed the link this time. > > I already sent an updated version of the patch to the > openembedded-devel@lists.openembedded.org mailing list because an > automatic system informed me that I hit the wrong mailing list. I > propose to switch to openembedded-devel for further discussions. > > [meta-oe,v2] directfb: fix tslib version check in configure.in > > Sadly, there hasn't been any reaction yet. FWIW your messages do appear to be making it to the mailing list(s) and you can see them in the archives, e.g.: http://lists.openembedded.org/pipermail/openembedded-devel/2018-August/120115.html I look after OE-Core, not meta-oe where this patch needs to go so I can't help with that but the patch is on the right list for them to see it. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-xfce][PATCH] xfce4-panel: fix QA issue 'installed-vs-shipped'
On Mon, 2018-06-18 at 19:25 -0400, Mark Asselstine wrote: > On Mon, Jun 18, 2018 at 6:27 PM, Andreas Müller com> wrote: > > On Mon, Jun 18, 2018 at 11:42 PM, Richard Purdie > > wrote: > > Off-Topic / FYI for me gmail considered your email spam > > > > > > Removing the libtool files became the project default a while ago > > > (Jan > > > 2017): > > > > > > meta/conf/distro/defaultsetup.conf:INHERIT_DISTRO ?= "debian > > > devshell sstate license remove-libtool" > > > > > > so I suspect you're in the minority not using that now. > > > > Maybe true. But breaking builds consumes resources on many sides - > > this thread is a good example > > > > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/distro > > > /defaultsetup.conf?id=3e2a47fdfceccd5f8832235b7a2df83076e84a98 > > > > > > > The more I think about this: > > > > * Why is remove-libtool something a distro can override? If causing > > trouble it can be deactivated recipe-wise. > > > That was my feeling as well as we were having this discussion, > without digging into the history it felt as if this should have been > made core functionality and not optional, especially given the > opportunity for recipes to opt out. At any rate I am about to send a > commit to get things buildable for when the 'remove-libtool' distro > feature is absent and as long as it remains optional I suppose all > recipes should function with and without the feature. There are many different features which "distro maintainers" can turn on/off which can break the builds. I was always reluctant to add the libtool change but we reached the point where it simply no longer made sense to keep those files around, they caused more problems than it was worth effort for. Its not a setting I'd recommend anyone use now because as you're finding, the .la handling metadata is bitrotting. As with many things in the project, its "at your own risk and maintenance burden". Its not a combination I have any plans to add tests for. The better solution would be to drop all the .la file FILES directives and handle .la files in a similar way to the way we handle debug files into -dbg packages. If anyone cares at this point. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-xfce][PATCH] xfce4-panel: fix QA issue 'installed-vs-shipped'
On Mon, 2018-06-18 at 13:07 -0400, Mark Asselstine wrote: > On Monday, June 18, 2018 12:51:47 PM EDT Andreas Müller wrote: > > On Mon, Jun 18, 2018 at 4:45 PM, Mark Asselstine > > My builds have remove-libtool enabled so I did not see this QA > > warning/error. > > > > Isn't remove-libtool enabled by default since pyro/2.3 - so that > > this > > patch is obsolete (and all the other same kind coming later)? > > The documentation still indicates: > --- > > The remove-libtool class is not > enabled by > default. > > --- > > So as far as I know this still needs to be handled recipe to recipe > by inheriting the remove-libtool class in the affected recipes. I > have done builds without manipulating the generated local.conf which > seem to confirm this but I could be wrong. Add RP who might have > some guidance. Removing the libtool files became the project default a while ago (Jan 2017): meta/conf/distro/defaultsetup.conf:INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool" so I suspect you're in the minority not using that now. http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/distro/defaultsetup.conf?id=3e2a47fdfceccd5f8832235b7a2df83076e84a98 Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] meta-openembedded maintainer ship change.
On Tue, 2018-05-22 at 08:40 -0700, akuster808 wrote: > After much thought, I have decided to step away from being the > meta-openembedded maintainer, patch wrangler and builder. Khem Raj > has kindly stepped up to continue these activities. Maintaining this > was consuming too much of my free time and I need to focus on other > things in the community. > > Thanks for the opportunity to have served you. I appreciate the work involved in this, thanks Armin and thanks Khem! There are probably some discussions we should have about various aspects of this but now isn't the time, lets see how Khem gets on first. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] 2.6 planning proposals and meeting
[Widely cross posted but please reply to openembedded-core only for want of picking somewhere to discuss this] The next big question facing us is what would we like to do in 2.6? What can we do with the resources we have? I'm proposing to hijack the next monthly Yocto Project technical call[1] and dedicate it to 2.6 planning. I'm going to detail some high level 'big' ideas blow in this email from a feature development perspective. Anyone is welcome to join the call (or reply) and I'm happy to answer questions about the ideas below and hear suggestions of others. [1] https://www.yoctoproject.org/monthly-technical-call/ Ultimately, ideas will be turned into bugzilla enhancement entries. It will then be a case of seeing who is willing to step up and help work on any given feature. We're using the "2.99" target milestone as our holding area for potential ideas, only moving to 2.6 when we have a solid commitment for someone to do something. If nobody steps up for something, chances are it will just get pushed out as a "Future" idea. In the past, Intel in particular has stepped up and done a lot of feature work but for various reasons, this is not likely to happen going forward as they focus more in Intel specific work. At the end of the day, we'll process the changes that make it onto the mailing list by the freeze deadlines for the milestones. If its not there, it won't be in the release and 2.6 will be what people put into it. List of high level 'big' ideas: - Reference binary package feed (in particular to test upgrade paths) - Secure/trusted boot support in OE-Core - Improved security tools (e.g. CVE database scanning) - Provide sstate feed out the box for reference - Improve binary output testing (esp. reproducibility, upgrade paths) - Widen the scope of our automated testing infrastructure (include more layers) - Roll processes and tooling into the wider ecosystem (e.g. meta- openembedded) - Ability to make builds more efficient by output comparison and sstate prebuilt reuse in many more cases. Maybe sstate equivalence server - Completion of migration to new autobuilder codebase and infrastructure - Out of box experience/layer setup tooling - Improved binary reproducibility Features aren't all we need to plan for. There are other areas that need work/help: Many other smaller features There are too many for me to list/call out individually but search bugzilla for 2.99 Medium+ items. A good example is adding support for inter-multiconfig dependencies which is a small remaining multiconfig item which would make a big difference to certain workflows. Another harder example is parallelisation of oe-selftest. Its currently the thing which ends up taking the longest in most of our builds, improving its performance would reduce overall testing times. OE-Core Recipe maintenance: 840 recipes in OE-Core - General recipe updates - Security fixes - Recipe specific bugs/regressions - Adapt to new technologies/upstream changes General patch review ~5000 commits/year which need review, testing, identifying regressions, merging General regressions Regressions tests we have are good but don't catch every race condition or intermittent problem. We end up having to track down several, particularly runtime testing instability Bug fixing user issues Users find new use cases and workflows and identify bugs which then need to be addressed For example we can't default to mem-res bitbake as there are known issues. Maintain the tools We directly maintain tools like bitbake, pseudo, devtool, recipetool opkg, yocto-autobuilder, patchwork+patchtest, wic Stable release maintenance People all want stable releases and security fixes but someone has to make these happen. Help in any and all of these areas is much appreciated. Also keep in mind the things above are just to get people thinking. If there are changes you'd like to see, now is your chance to proposal and work on them to make them a reality. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] [openembedded-core] 02/02: nativesdk-glibc: Split glibc and libcrypt to use libxcrypt instead
On Sun, 2018-04-08 at 19:00 +0200, Martin Jansa wrote: > On Ubuntu 14.04 this fails with: > > ../git/gen-des-tables.c: In function ‘write_table_u8’: > ../git/gen-des-tables.c:307:3: error: ‘for’ loop initial declarations > are only allowed in C99 mode > for (size_t i = 0; i < m; i++) > ^ > > I'll try to add explicit -std=gnu99 to support building on such older > host distributions with older gcc. Thanks, looks like centos6 has the same issue: https://autobuilder.yocto.io/builders/buildtools/builds/906/steps/BuildImages/logs/stdio Didn't show up in the first round of testing :( Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Splitting meta-oe?
On Tue, 2018-02-20 at 23:27 +0100, Martin Jansa wrote: > Richard, I agree with all you said. > > But I still don't see how replacing meta-oe git repository with 10 > different git repositories helps with anything. > > It won't give you more time, it would only cause more work to already > exhausted and (re)tired meta-oe maintainers. I'm actually very worried about these (re)tired maintainers. If the layers were more independent it would allow some of the patch handling responsibilities and testing responsibilities to move to other people, reducing the load on those maintainers. Obviously this can't happen with everything all at once but I think some pieces of the current repo may not be far away or that difficult to separate out. Therefore raising the question doesn't seem unreasonable. The separate layers and maintainership is the way we designed the new layered approach to OE to scale. > It won't make the layers independent. It won't, but it would give people more of a reason to fix it. > It won't improve existing tooling. > > It won't improve automated upgrades or testing. > > Yes meta-oe needs to improve and it would be great to have layers as > those fancy colorful boxes from Yocto documentation, which you can > willy-nilly add to your BBLAYERS without any dependencies. But that's > not how it is now and splitting the repository alone won't help with > that. If there are people willing to make it work better, then they > can improve it in existing git repository and when it works well and > there are really independent layers, then we can re-evaluate > splitting the independent ones to separate repositories for easier > consumption. It alone will not change things but it *might* just trigger more people to get involved, help and take some of the workload from those maintainers who are overloaded right now. Its a chicken and egg problem, our difference is we disagree on which step might help. We've tried the monolithic repo for quite a while, it might be time to try a different approach maybe with one piece of meta-oe? Cheers, Richard [away tomorrow so further replies may be delayed] -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Splitting meta-oe?
On Tue, 2018-02-20 at 11:15 -0800, Khem Raj wrote: > On 2/20/18 10:52 AM, Richard Purdie wrote: > > > > On Tue, 2018-02-20 at 10:40 -0800, Khem Raj wrote: > > > > > > On 2/20/18 10:00 AM, Tim Orling wrote: > > > > > > > > I am open to discussion about what direction we go. Individual > > > > layers that > > > > are curated and built together by YP auto builders sounds like > > > > an > > > > intriguing path. If this was coupled with increased ptest or > > > > testimage > > > > usage, our confidence in layer quality would go up > > > > dramatically. > > > > > > > I would like to understand whats stopping YP autobuilders to > > > build > > > layers under meta-openembedded repo and contribute changes as > > > needed. > > > All changes with test improvements etc. above are a good change > > > and > > > should be adopted across layers. However splitting layers is > > > least of > > > the problem as of now. > > The Yocto Project cannot commit to building everything in the meta- > > oe > > repository. There are some specific layers we would consider > > building > > but right now I think there are inter-dependencies that cause > > problems. > > > 1 is better than zero so go for it :) As you see fit, send patches to > subsume the dependencies into other layers and make it meta-oe layer > free, this seems a good step forward Sure, should I do that before or after I fix the autobuilder, sort the stable releases and write the layer tool? ;-) Seriously, I'd love to but I'm probably not going to get there any time soon personally, much as I wish it were otherwise. > > Sure, we can look into those and try and fix them in some way and > > that > > would be one less hurdle. I do appreciate we have autobuilder > > issues > > right now which also causes us problems, I've already committed to > > working through those. > > > > Even once we do that, we (as in YP) can't send out a clear message > > about what we're testing and users will clone meta-oe and expect > > everything to work. So right now I do have problems trying to get > > to a > > point where YP can use meta-oe effectively. > poky is a different git repo and it has its own way of subsuming > subset of oe layers ( oe-core bitbake meta-poky ..), meta-oe is just > another one to deal with fhere. it seems more like a distro problem > here to me. Think about this a different way. The message meta-oe is sending to users is that monolithic repositories of many different layers, lumping all recipes together in ways which mean they can't be separated out is "the right way" to do things. In that sense its little progress over oe-classic! If our tooling is so bad we can't work with layers, perhaps we should abandon that idea? Or perhaps we need to fix the tooling and allow things to be split up? I agree we have some challenges with testing, with automated upgrades, with tooling and so on, but I think meta-oe does need to evolve (as do other parts of the system including things like poky). Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Splitting meta-oe?
On Tue, 2018-02-20 at 10:40 -0800, Khem Raj wrote: > On 2/20/18 10:00 AM, Tim Orling wrote: > > I am open to discussion about what direction we go. Individual > > layers that > > are curated and built together by YP auto builders sounds like an > > intriguing path. If this was coupled with increased ptest or > > testimage > > usage, our confidence in layer quality would go up dramatically. > > > I would like to understand whats stopping YP autobuilders to build > layers under meta-openembedded repo and contribute changes as needed. > All changes with test improvements etc. above are a good change and > should be adopted across layers. However splitting layers is least of > the problem as of now. The Yocto Project cannot commit to building everything in the meta-oe repository. There are some specific layers we would consider building but right now I think there are inter-dependencies that cause problems. Sure, we can look into those and try and fix them in some way and that would be one less hurdle. I do appreciate we have autobuilder issues right now which also causes us problems, I've already committed to working through those. Even once we do that, we (as in YP) can't send out a clear message about what we're testing and users will clone meta-oe and expect everything to work. So right now I do have problems trying to get to a point where YP can use meta-oe effectively. I could combo-layer pieces of meta-oe into poky but I'd imagine that would create more problems than it would solve too and given the general dislike of combo-layer, I think ultimately better layer tooling would be a better answer and more acceptable to everyone. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Splitting meta-oe?
Repositories have reputations. OE-Core is fairly heavily curated and tested and has certain "guarantees" about what people can expect to work. The meta-oe repo is a little trickier as the different pieces do have different 'SLA's (service level agreements). Some pieces like meta-networking/meta-python likely build well, other pieces like some of the bitrotting pieces of the meta-oe layer probably don't build in as many different configurations/architectures and on balance may be more likely to hit issues. I think the world may need to change a bit. We should probably change: * The way people get started with the Yocto Project and Poky to move away from the combo repo and into specific layers. * to have YP testing more layers as part of its builds and testing * to make it easier for people to establish an SLA type reputation for a layer. Part of this is a need for a more universal "using OE" later setup tooling. I've wanted to work on that for a while and I will get there but if I spend time on it, I want to get it right. I've not had enough time to get it right (as yet). Part of this means redefining poky, the YP autobuilders and so on. Pieces of the autobuilder work are in process and will lead to wider layer testing. I have strong influence over the above so I can likely make those happen, time constraints aside. One piece I need the help of others with is meta-oe (the repo). Even just splitting meta-oe out from meta-oe might be enough to establish the SLA differences, I don't know. There is a question about what problem would this solve. The move from OE-Classic was partly about defining maintainership and processes for recipes which we do with layers. The pieces in the separate layers have now become the things we set out to create but the catchall of meta-oe (the layer) remains. I do think we should still be aiming to filter meta-oe into distinct layers with distinct maintainership. There will always be some "leftovers" in a catchall but I think it does have a different personality to the other well separated components and we need to show to users that they do have different expectations from them. I hope I'm managing to convey this concept ok, I'm really trying to take a step back here and think what will help OE users and the project and where we need to go with things. I'm not saying we should/shouldn't do this for 100% certain, I do want people to think about the alternatives though and what options may be possible. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] [openembedded-core] branch morty updated: image: Expand PV to avoid AUTOREV parsing failures
On Sun, 2018-01-21 at 09:51 +0100, Martin Jansa wrote: > Thanks, but was it really pushed? > > http://git.openembedded.org/openembedded-core/log/?h=morty > > still ends with: > * image: Expand PV to avoid AUTOREV parsing failuresmorty > Richard Purdie10 hours1 -0/+2 > * libunwind: Disable documentation explicitlymorty-next > Richard Purdie8 days 1 -0/+1 Sorry, the push failed and I didn't notice. It should really be there now. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] [openembedded-core] branch morty updated: image: Expand PV to avoid AUTOREV parsing failures
On Sun, 2018-01-21 at 00:51 +0100, Martin Jansa wrote: > This causes: > > Exception: TypeError: getVar() missing 1 required positional > argument: 'expand' Sorry, fix pushed. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] MS Windows machine?
On Fri, 2018-01-05 at 12:29 +0100, Steffen Sledz wrote: > On 04.01.2018 15:39, Richard Purdie wrote: > > > > In basic terms, you need a machine which: > > > > * Sets TARGET_ARCH to the right thing (i686 or x86_64) > > * Sets TARGET_OS to mingw32 > > > > and then some distro config which sets up the toolchain when mingw > > is > > the target os to the values like meta-mingw/conf/machine-sdk/i686- > > mingw32.conf sets. > Do you have a sample distro config which we can use as a template? No, sorry. As I said, I've not tried this before. Its not a trivial thing to do, equally it shouldn't be too bad given what we already have... Sadly I don't have the time available to play with something like that either, much as I do quite enjoy it... Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] MS Windows machine?
On Thu, 2018-01-04 at 07:31 +0100, Steffen Sledz wrote: > On 21.12.2017 14:00, Steffen Sledz wrote: > > > > On 21.12.2017 12:39, Burton, Ross wrote: > > > > > > If you want to build for a Windows target then that should be > > > possible but > > > nobody as far as I'm aware has made the work public. meta-mingw > > > will > > > contain most of the changes needed as that does build Windows > > > binaries. > > That's exactly what we like to to. > > > > So has anyone tried this before? > > > > What else would be needed to build e.g. for MACHINE=i686-mingw32? > Is someone able to create a machine definition for this? I'm not > really familiar with this job. In basic terms, you need a machine which: * Sets TARGET_ARCH to the right thing (i686 or x86_64) * Sets TARGET_OS to mingw32 and then some distro config which sets up the toolchain when mingw is the target os to the values like meta-mingw/conf/machine-sdk/i686- mingw32.conf sets. You'd need need to look through the bbappends which are in meta-mingw and add them to the appropriate pieces you need for target binaries rather than sdk binaries. I did once do this for darwin so it is possible, I've never tried it for windows though. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] uninative: Allow a local own-mirror to work with uninative
The games we play with path manipulation of DL_DIR in uninative mean standard
PREMIRRORS don't work and we can't easily put 'chksum' into the url path from
a url parameter with the current fetcher url handling to make a generic
remapping. We therefore add to PREMIRRORS when we know the chksum to
create a premirror mapping which can work.
[YOCTO #9888]
Signed-off-by: Richard Purdie
---
meta/classes/uninative.bbclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 8f34483..a410647 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -49,6 +49,12 @@ python uninative_event_fetchloader() {
localdata = bb.data.createCopy(d)
localdata.setVar('FILESPATH', "")
localdata.setVar('DL_DIR', tarballdir)
+# Our games with path manipulation of DL_DIR mean standard
PREMIRRORS don't work
+# and we can't easily put 'chksum' into the url path from a url
parameter with
+# the current fetcher url handling
+ownmirror = d.getVar('SOURCE_MIRROR_URL')
+if ownmirror:
+localdata.appendVar("PREMIRRORS", "
${UNINATIVE_URL}${UNINATIVE_TARBALL}
${SOURCE_MIRROR_URL}/uninative/%s/${UNINATIVE_TARBALL}" % chksum)
srcuri =
d.expand("${UNINATIVE_URL}${UNINATIVE_TARBALL};sha256sum=%s" % chksum)
bb.note("Fetching uninative binary shim from %s" % srcuri)
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 3/5] image: Drop before do_build from do_rootfs and do_image
do_image_complete has the do_build dependency, these other two tasks
don't need it. If this is present, it complicates the dependency tree
and convinces rm_work that the tasks need to rerun even if they
already did since the stamps are removed.
Drop the unneeded dependency to help resolve this issue.
Signed-off-by: Richard Purdie
---
meta/classes/image.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 40bd614..0885fdb 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -261,7 +261,7 @@ fakeroot python do_rootfs () {
do_rootfs[dirs] = "${TOPDIR}"
do_rootfs[cleandirs] += "${S} ${IMGDEPLOYDIR}"
do_rootfs[umask] = "022"
-addtask rootfs before do_build after do_prepare_recipe_sysroot
+addtask rootfs after do_prepare_recipe_sysroot
fakeroot python do_image () {
from oe.utils import execute_pre_post_process
@@ -272,7 +272,7 @@ fakeroot python do_image () {
}
do_image[dirs] = "${TOPDIR}"
do_image[umask] = "022"
-addtask do_image after do_rootfs before do_build
+addtask do_image after do_rootfs
fakeroot python do_image_complete () {
from oe.utils import execute_pre_post_process
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/5] rm_work: Improve handling for addto_recipe_sysroot
Rather than requiring each user to handle this individually, handle
addto_recipe_sysroot in the core class. As well as preserving the
sysroot directory, this also ensures the stamp is preserved rather
than rerunning the task every time as currently happens.
Signed-off-by: Richard Purdie
---
meta/classes/rm_work.bbclass | 32 ++
.../qemu/qemu-helper-native_1.0.bb | 1 -
.../systemtap/systemtap-native_git.bb | 1 -
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index badeaeb..2a4e808 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -35,22 +35,12 @@ do_rm_work () {
fi
done
-cd ${WORKDIR}
-for dir in *
-do
-# Retain only logs and other files in temp, safely ignore
-# failures of removing pseudo folers on NFS2/3 server.
-if [ $dir = 'pseudo' ]; then
-rm -rf $dir 2> /dev/null || true
-elif ! echo '${RM_WORK_EXCLUDE_ITEMS}' | grep -q -w "$dir"; then
-rm -rf $dir
-fi
-done
-
# Need to add pseudo back or subsqeuent work in this workdir
# might fail since setscene may not rerun to recreate it
mkdir -p ${WORKDIR}/pseudo/
+excludes='${RM_WORK_EXCLUDE_ITEMS}'
+
# Change normal stamps into setscene stamps as they better reflect the
# fact WORKDIR is now empty
# Also leave noexec stamps since setscene stamps don't cover them
@@ -79,6 +69,12 @@ do_rm_work () {
i=dummy
break
;;
+*do_addto_recipe_sysroot*)
+# Preserve recipe-sysroot-native if do_addto_recipe_sysroot
has been used
+excludes="$excludes recipe-sysroot-native"
+i=dummy
+break
+;;
# We remove do_package entirely, including any
# sstate version since otherwise we'd need to leave 'plaindirs'
around
# such as 'packages' and 'packages-split' and these can be large.
No end
@@ -101,6 +97,18 @@ do_rm_work () {
done
rm -f $i
done
+
+cd ${WORKDIR}
+for dir in *
+do
+# Retain only logs and other files in temp, safely ignore
+# failures of removing pseudo folers on NFS2/3 server.
+if [ $dir = 'pseudo' ]; then
+rm -rf $dir 2> /dev/null || true
+elif ! echo "$excludes" | grep -q -w "$dir"; then
+rm -rf $dir
+fi
+done
}
do_rm_work_all () {
:
diff --git a/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb
b/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb
index 27d5315..d86b155 100644
--- a/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb
+++ b/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb
@@ -20,6 +20,5 @@ do_install() {
install tunctl ${D}${bindir}/
}
-RM_WORK_EXCLUDE_ITEMS += "recipe-sysroot-native"
DEPENDS += "qemu-native"
addtask addto_recipe_sysroot after do_populate_sysroot before do_build
diff --git a/meta/recipes-kernel/systemtap/systemtap-native_git.bb
b/meta/recipes-kernel/systemtap/systemtap-native_git.bb
index c3da77c..19cc1cf 100644
--- a/meta/recipes-kernel/systemtap/systemtap-native_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap-native_git.bb
@@ -3,5 +3,4 @@ require systemtap_git.bb
inherit native
-RM_WORK_EXCLUDE_ITEMS += "recipe-sysroot-native"
addtask addto_recipe_sysroot after do_populate_sysroot before do_build
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 5/5] image: Make do_image_qa a dummy sstate task to match do_image_complete
Similar to do_image_complete, make do_image_qa a dummy sstate task
so that rm_work doesn't cause image generation to repeat on every
new build command.
Signed-off-by: Richard Purdie
---
meta/classes/image.bbclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 696aacd..2c1dc81 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -324,6 +324,15 @@ fakeroot python do_image_qa () {
}
addtask do_image_qa after do_image_complete before do_build
+SSTATETASKS += "do_image_qa"
+SSTATE_SKIP_CREATION_task-image-qa = '1'
+do_image_qa[sstate-inputdirs] = ""
+do_image_qa[sstate-outputdirs] = ""
+python do_image_qa_setscene () {
+sstate_setscene(d)
+}
+addtask do_image_qa_setscene
+
def setup_debugfs_variables(d):
d.appendVar('IMAGE_ROOTFS', '-dbg')
d.appendVar('IMAGE_LINK_NAME', '-dbg')
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 4/5] image/rm_work: Promote do_image_complete to be more sstate like
We relied on the missing do_image_complete_setscene task to ensure the dummy
sstate tarball that was created would never be used. This lead to its own
issues and a better fix for SSTATE_SKIP_CREATION has now been merged.
We can therefore make do_image_complete look like a more standard sstate
task which means image generation doesn't keep rerunning when using rm_work.
We do need to turn do_image_complete's stamp into an sstate version to
handle this (it otherwise matches the do_image_* glob).
Signed-off-by: Richard Purdie
---
meta/classes/image.bbclass | 4
meta/classes/rm_work.bbclass | 5 +
2 files changed, 9 insertions(+)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 0885fdb..696aacd 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -289,6 +289,10 @@ do_image_complete[sstate-inputdirs] = "${IMGDEPLOYDIR}"
do_image_complete[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
do_image_complete[stamp-extra-info] = "${MACHINE}"
addtask do_image_complete after do_image before do_build
+python do_image_complete_setscene () {
+sstate_setscene(d)
+}
+addtask do_image_complete_setscene
# Add image-level QA/sanity checks to IMAGE_QA_COMMANDS
#
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index 2a4e808..71c21a0 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -61,6 +61,11 @@ do_rm_work () {
i=dummy
break
;;
+*do_image_complete*)
+mv $i `echo $i | sed -e "s#${j}#${j}_setscene#"`
+i=dummy
+break
+;;
*do_rootfs*|*do_image*|*do_bootimg*|*do_bootdirectdisk*|*do_vmimg*|*do_write_qemuboot_conf*)
i=dummy
break
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/5] sstate: Improve SSTATE_SKIP_CREATION
Currently, dummy archives are created for skipped sstate tasks. We relied
on these never being installed (the setscene task is missing) however this
leads to odd behaviour as for example the setscene stamps are never looked
at.
Rather than trying to continue with the two separate behaviours, really
skip package creation. We do need the file manipulation steps to install files
under sstate control from a manifest perspective so we only skip at the final
creation step.
Signed-off-by: Richard Purdie
---
meta/classes/sstate.bbclass | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index f446c3d..6af0d38 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -346,8 +346,6 @@ def sstate_installpkgdir(ss, d):
oe.path.remove(dir)
for state in ss['dirs']:
-if d.getVar('SSTATE_SKIP_CREATION') == '1':
-continue
prepdir(state[1])
os.rename(sstateinst + state[0], state[1])
sstate_install(ss, d)
@@ -596,8 +594,6 @@ def sstate_package(ss, d):
for state in ss['dirs']:
if not os.path.exists(state[1]):
continue
-if d.getVar('SSTATE_SKIP_CREATION') == '1':
-continue
srcbase = state[0].rstrip("/").rsplit('/', 1)[0]
# Find and error for absolute symlinks. We could attempt to relocate
but its not
# clear where the symlink is relative to in this context. We could add
that markup
@@ -625,6 +621,10 @@ def sstate_package(ss, d):
d.setVar('SSTATE_BUILDDIR', sstatebuild)
d.setVar('SSTATE_PKG', sstatepkg)
+d.setVar('SSTATE_INSTDIR', sstatebuild)
+
+if d.getVar('SSTATE_SKIP_CREATION') == '1':
+return
for f in (d.getVar('SSTATECREATEFUNCS') or '').split() + \
['sstate_create_package', 'sstate_sign_package'] + \
@@ -634,8 +634,6 @@ def sstate_package(ss, d):
bb.siggen.dump_this_task(sstatepkg + ".siginfo", d)
-d.setVar('SSTATE_INSTDIR', sstatebuild)
-
return
def pstaging_fetch(sstatefetch, sstatepkg, d):
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [Openembedded-architecture] OpenEmbedded 2017 General Meeting
On Mon, 2017-05-01 at 13:59 +0200, Martin Jansa wrote: > I had to change the password on the login, but then it worked for me. I think someone promoted you to an admin which is why its working for you... Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] OpenEmbedded 2017 General Meeting
On Mon, 2017-05-01 at 13:07 +0200, Nicolas Dechesne wrote: > well, it's the same for me. In the 'view source' page, i can see > this: > > == > You do not have permission to edit this page, for the following > reason: > The action you have requested is limited to users in the group: > Administrators. Right, it is totally broken. Someone has messed up the group access permissions, likely related to spam protection. Right now it appears only the admins can change anything. I could try and fix it but I should probably understand who did what and why to cause this first. Who has changed the group permissions recently? Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] OpenEmbedded 2017 General Meeting
On Mon, 2017-05-01 at 12:27 +0200, Andrea Galbusera wrote: > > > On Mon, May 1, 2017 at 12:02 PM, Andrei Gherzan > wrote: > > On Wed, Apr 19, 2017 at 9:48 PM, Sean Hudson > m> wrote: > > > The board would like to hold a general meeting with all members. > > Under > > > the new by-laws of the OpenEmbedded organization, we can meet > > > electronically. This will also fulfill the requirement for an > > annual, > > > general meeting. > > > > > > Planned Date/Time: > > > Wednesday, May 3rd, at 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00) > > > > > > Wiki page with full details, including teleconference information > > here: > > > http://www.openembedded.org/wiki/2017_General_Meeting > > > > It seems like there is not Edit button for me to add my username to > > the attendee list. > Same for me... FWIW once I'd logged in I could add my name to the list... Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] u-boot: Update to 2017.03 release
On Wed, 2017-03-29 at 17:56 -0400, Denys Dmytriyenko wrote: > On Mon, Mar 27, 2017 at 04:31:16PM +0200, Marek Vasut wrote: > > > > On 03/27/2017 04:25 PM, Richard Purdie wrote: > > > > > > On Mon, 2017-03-27 at 16:22 +0200, Marek Vasut wrote: > > > > > > > > Upgrade U-Boot to the latest version. > > > Wrong list and how does this compare to Ovatio's patch? > > I was not CCed on Otavio's patch :( > Yeah, me neither, unfortunately - people just ignore maintainers file > now. > > Good thing Ross copied me on the other discussion! This raises a very valid point which is what any maintainers file is and what it is not. The one that exists in meta-yocto today has a very specific meaning. I know there is discussion about moving it to OE-Core however if we do so I want to by *really* *really* clear about what being listed there means and does not mean. As things stand right now, there is no requirement or advice in any of our guides to cc "maintainers". People struggle to send patches as it is and giving them more hoops to jump through doesn't seem like a brilliant idea to me. I know we can create a file with all kinds of path matching for files people care/don't care about but I worry this will descend into complicated scripts and people still getting upset when they were cc'd needlessly or weren't cc'd etc. I also quite strongly dislike the "I own X, so only I can change it" type view, to be the maintainers are people who help look after specific areas in the absence of anyone else and help review patches that come in. They certainly get significant influence on things but the price for that is they also have to help fix issues and figure out ways of helping others with issues in that area. So please think very carefully about what you want this "maintainers" file to be/not be as I worry its a huge can of worms we once tried in OE before... Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] u-boot: Update to 2017.03 release
On Mon, 2017-03-27 at 16:22 +0200, Marek Vasut wrote: > Upgrade U-Boot to the latest version. Wrong list and how does this compare to Ovatio's patch? Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] devshell not working after pulling latest oe-core changes
On Mon, 2017-03-13 at 00:09 -0700, akuster808 wrote: > tmux split-window "do_terminal" > tmux new-window -n "OpenEmbedded Developer Shell" "do_terminal" > terminology -T="OpenEmbedded Developer Shell" -e do_terminal > gnome-terminal -t "OpenEmbedded Developer Shell" -x do_terminal > mate-terminal -t "OpenEmbedded Developer Shell" -x do_terminal > konsole --separate --workdir . -p tabtitle="OpenEmbedded > Developer > Shell" -e do_terminal > xfce4-terminal -T "OpenEmbedded Developer Shell" -e > "do_terminal" > xterm -T "OpenEmbedded Developer Shell" -e do_terminal > rxvt -T "OpenEmbedded Developer Shell" -e do_terminal > tmux new -d -s devshell -n devshell "do_terminal" > screen -D -m I suspect we need a: HOSTTOOLS_NONFATAL += "xterm rxvt tmux screen xfce4-terminal mate- terminal konsole terminology gnome-terminal" into terminal.bbclass. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Splitting meta-oe?
On Fri, 2017-02-17 at 14:45 -0500, Philip Balister wrote: > And I'm with these gyus. Splitting the git repository doesn't solve > any underlying problems. The real problem from my point of view is > very few of use are actually paid to maintain the layers we maintain. > > Employers want to pay things they profit from, and that is not paying > someone to maintain "core infrastructure". > > Layer maintainers interests change over time, and you burn out > supporting people who get to do all the cool stuff with the layers > you maintain. In the end, you get all the crap and non of the glory. > Within this list, most people appreciate your work. Outside the > community, people completely underestimate the amount of work > required to keep the ecosystem running. > > Yeah, add my name to the list of cranky people. I do think this is a valid question that Ross asks and that whilst the first quick reaction is "no", its worth thinking about the pros/cons. The pros to me would be about better test time on patches and in theory more specialist knowledge. This isn't to say Martin/Joe don't do a bad job but the size of meta-oe does mean there are limits. The cons are more around finding suitable layer maintainers, which as we all know are hard to find. I'd probably suggest that: a) We need to encourage/empower more people to maintain layers b) Having better infrastructure, tools and processes that help a) would therefore be desirable. c) We need to be willing to separate out pieces for people to maintain in such layers. It might not always work out but we should be willing to try. As for the comments about core changes, I really do try hard not to make them in many ways. The ones we do make, I'd hope are for the right reasons. No easy answers but don't shoot Ross for asking what I think is a reasonable question. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] subversion: Fix issues in LDFLAGS sed manipulation
The existing sed expression can match expressions like
--sysroot=/some/path/xxx-linux/ which clearly isn't intended and
injects incorrect paths into LDFLAGS.
Fix this in the same way we address the problem in CFLAGS. This fixes corrupt
build paths and incorrect paths in .la files amongst other issues.
Signed-off-by: Richard Purdie
---
.../subversion/subversion/serfmacro.patch | 22 ++
.../subversion/subversion_1.9.4.bb | 1 +
2 files changed, 23 insertions(+)
create mode 100644 meta/recipes-devtools/subversion/subversion/serfmacro.patch
diff --git a/meta/recipes-devtools/subversion/subversion/serfmacro.patch
b/meta/recipes-devtools/subversion/subversion/serfmacro.patch
new file mode 100644
index 000..9a45cb9
--- /dev/null
+++ b/meta/recipes-devtools/subversion/subversion/serfmacro.patch
@@ -0,0 +1,22 @@
+The existing sed expression can match expressions like
+--sysroot=/some/path/xxx-linux/ which clearly isn't intended and
+injects incorrect paths into LDFLAGS.
+
+Fix this in the same way we address the problem in CFLAGS.
+
+RP 2016/12/7
+Upstream-Status: Pending
+
+Index: subversion-1.9.4/build/ac-macros/serf.m4
+===
+--- subversion-1.9.4.orig/build/ac-macros/serf.m4
subversion-1.9.4/build/ac-macros/serf.m4
+@@ -171,7 +171,7 @@ AC_DEFUN(SVN_SERF_PKG_CONFIG,
+ SVN_SERF_INCLUDES=[`$PKG_CONFIG $serf_pc_arg --cflags | $SED -e 's/
-D[^ ]*//g' -e 's/^-D[^ ]*//g'`]
+ SVN_SERF_LIBS=`$PKG_CONFIG $serf_pc_arg --libs-only-l`
+ dnl don't use --libs-only-L because then we might miss some options
+- LDFLAGS=["$LDFLAGS `$PKG_CONFIG $serf_pc_arg --libs | $SED -e
's/-l[^ ]*//g'`"]
++ LDFLAGS=["$LDFLAGS `$PKG_CONFIG $serf_pc_arg --libs | $SED -e 's/
-l[^ ]*//g' -e 's/^-l[^ ]*//g'`"]
+ break
+ else
+ AC_MSG_RESULT([no])
diff --git a/meta/recipes-devtools/subversion/subversion_1.9.4.bb
b/meta/recipes-devtools/subversion/subversion_1.9.4.bb
index fa6a7f2..3e35940 100644
--- a/meta/recipes-devtools/subversion/subversion_1.9.4.bb
+++ b/meta/recipes-devtools/subversion/subversion_1.9.4.bb
@@ -15,6 +15,7 @@ SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://serf.m4-Regex-modified-to-allow-D-in-paths.patch \
file://0001-Fix-libtool-name-in-configure.ac.patch \
file://0001-fix-svnadmin-create-fail-on-x86.patch \
+ file://serfmacro.patch \
"
SRC_URI[md5sum] = "29121a038f87641055a8183f49e9739f"
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] staging: Drop unused SYSROOT_LOCK
This hasn't been used in years and isn't referenced anywhere, drop
the definition.
Signed-off-by: Richard Purdie
---
meta/classes/staging.bbclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index a0b09a0..bfabd06 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -171,7 +171,6 @@ addtask populate_sysroot after do_install
SYSROOT_PREPROCESS_FUNCS ?= ""
SYSROOT_DESTDIR = "${WORKDIR}/sysroot-destdir"
-SYSROOT_LOCK = "${STAGING_DIR}/staging.lock"
# We clean out any existing sstate from the sysroot if we rerun configure
python sysroot_cleansstate () {
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] attr: Convert SSTATEPOSTINSTFUNCS to a do_install_append
A SSTATEPOSTINSTFUNCS function here is overkill, just do this in a
do_install_append_class-native and create relative symlinks rather
than absolute ones which would then have to be relocated.
Signed-off-by: Richard Purdie
---
meta/recipes-support/attr/ea-acl.inc | 47 +---
1 file changed, 22 insertions(+), 25 deletions(-)
diff --git a/meta/recipes-support/attr/ea-acl.inc
b/meta/recipes-support/attr/ea-acl.inc
index 370e16f..583ca1f 100644
--- a/meta/recipes-support/attr/ea-acl.inc
+++ b/meta/recipes-support/attr/ea-acl.inc
@@ -17,36 +17,33 @@ do_install () {
oe_runmake install install-lib install-dev DIST_ROOT="${D}"
}
-PACKAGES =+ "lib${BPN}"
-
-FILES_lib${BPN} = "${base_libdir}/lib*${SOLIBS}"
-
-BBCLASSEXTEND = "native"
-# Only append ldflags for target recipe and if USE_NLS is enabled
-LDFLAGS_append_libc-uclibc_class-target = "${@['', ' -lintl
'][(d.getVar('USE_NLS', True) == 'yes')]}"
-EXTRA_OECONF_append_libc-uclibc_class-target = "${@['', ' --disable-gettext
'][(d.getVar('USE_NLS', True) == 'no')]}"
-
-fix_symlink () {
- if [ "${BB_CURRENTTASK}" != "populate_sysroot" -a "${BB_CURRENTTASK}"
!= "populate_sysroot_setscene" ]
- then
- return
- fi
-
+do_install_append_class-native () {
if test "${libdir}" = "${base_libdir}" ; then
return
fi
+ librelpath=${@os.path.relpath(d.getVar('libdir',True),
d.getVar('base_libdir', True))}
+ baselibrelpath=${@os.path.relpath(d.getVar('base_libdir',True),
d.getVar('libdir', True))}
+
# Remove bad symlinks & create the correct symlinks
- if test -L ${libdir}/lib${BPN}.so ; then
- rm -rf ${libdir}/lib${BPN}.so
- ln -sf ${base_libdir}/lib${BPN}.so ${libdir}/lib${BPN}.so
+ if test -L ${D}${libdir}/lib${BPN}.so ; then
+ rm -rf ${D}${libdir}/lib${BPN}.so
+ ln -sf $baselibrelpath/lib${BPN}.so ${D}${libdir}/lib${BPN}.so
fi
- if test -L ${base_libdir}/lib${BPN}.a ; then
- rm -rf ${base_libdir}/lib${BPN}.a
- ln -sf ${libdir}/lib${BPN}.a ${base_libdir}/lib${BPN}.a
+ if test -L ${D}${base_libdir}/lib${BPN}.a ; then
+ rm -rf ${D}${base_libdir}/lib${BPN}.a
+ ln -sf $librelpath/lib${BPN}.a ${D}${base_libdir}/lib${BPN}.a
fi
- if test -L ${base_libdir}/lib${BPN}.la ; then
- rm -rf ${base_libdir}/lib${BPN}.la
- ln -sf ${libdir}/lib${BPN}.la ${base_libdir}/lib${BPN}.la
+ if test -L ${D}${base_libdir}/lib${BPN}.la ; then
+ rm -rf ${D}${base_libdir}/lib${BPN}.la
+ ln -sf $librelpath/lib${BPN}.la ${D}${base_libdir}/lib${BPN}.la
fi
}
-SSTATEPOSTINSTFUNCS_class-native += "fix_symlink"
+
+PACKAGES =+ "lib${BPN}"
+
+FILES_lib${BPN} = "${base_libdir}/lib*${SOLIBS}"
+
+BBCLASSEXTEND = "native"
+# Only append ldflags for target recipe and if USE_NLS is enabled
+LDFLAGS_append_libc-uclibc_class-target = "${@['', ' -lintl
'][(d.getVar('USE_NLS', True) == 'yes')]}"
+EXTRA_OECONF_append_libc-uclibc_class-target = "${@['', ' --disable-gettext
'][(d.getVar('USE_NLS', True) == 'no')]}"
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] nis/opencv: Update getVar/setVar syntax
The deprecated APIs are removed from bitbake, update two old style references
in meta-oe/meta-networking.
Signed-off-by: Richard Purdie
---
meta-networking/recipes-support/nis/nis.inc | 2 +-
meta-oe/recipes-support/opencv/opencv_3.1.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-networking/recipes-support/nis/nis.inc
b/meta-networking/recipes-support/nis/nis.inc
index c4aa10e..e027a1c 100644
--- a/meta-networking/recipes-support/nis/nis.inc
+++ b/meta-networking/recipes-support/nis/nis.inc
@@ -25,7 +25,7 @@ do_install() {
# so force the package to be skipped here (this will cause a
# 'nothing provides' error)
python () {
-os = bb.data.getVar("TARGET_OS", d, 1)
+os = d.getVar("TARGET_OS", True)
if os == "linux-uclibc":
raise bb.parse.SkipPackage("NIS functionality requires rpcsvc/yp.h,
uClibC does not provide this")
}
diff --git a/meta-oe/recipes-support/opencv/opencv_3.1.bb
b/meta-oe/recipes-support/opencv/opencv_3.1.bb
index 2136b07..670c94b 100644
--- a/meta-oe/recipes-support/opencv/opencv_3.1.bb
+++ b/meta-oe/recipes-support/opencv/opencv_3.1.bb
@@ -108,7 +108,7 @@ python populate_packages_prepend () {
for pkg in packages[1:]:
if not pkg in blacklist and not pkg in metapkg_rdepends and not
pkg.endswith('-dev') and not pkg.endswith('-dbg') and not pkg.endswith('-doc')
and not pkg.endswith('-locale'):
metapkg_rdepends.append(pkg)
-bb.data.setVar('RDEPENDS_' + metapkg, ' '.join(metapkg_rdepends), d)
+d.setVar('RDEPENDS_' + metapkg, ' '.join(metapkg_rdepends))
}
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFT] gcc 6.2 RC1 update
On Tue, 2016-08-16 at 11:55 -0700, Khem Raj wrote: > Hi All > > I have put together recipe upgrade for upcoming gcc 6.2 release now > that it entered RC phase. With gcc 6.2 the recipes are using tarballs > instead of git fetcher as promised :) > Please help testing it out in your setups and report any issues you > see. > > The commit you need to cherry-pick for OE-core is this one > > https://github.com/kraj/openembedded-core/commit/0319b603761a16e65d70 > 4336112c3709a8bf771c > > Thank you for your help I put this through the autobuilder and it passed so I've merged it. I did this quickly as we're putting a "pre M3" build through a QA cycle and I wanted to get some of the more invasive changes into that build so we don't have a stampeding herd of patches breaking everything coming up to the final feature freeze for 2.2. In other news, we are now also testing musl world builds on the autobuilder as part of regular testing. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFT] binutils 2.27
On Tue, 2016-08-09 at 07:42 -0700, Khem Raj wrote: > I could also see it on ppc. backtrace, shows the segfault is in exit > path and happens in libc > at this point, I think the problem is how libc is compiled with > binutils 2.27, connman itself > is ok. Its the issue here: https://sourceware.org/ml/glibc-bugs/2015-01/msg00274.html https://sourceware.org/bugzilla/show_bug.cgi?id=17908 Basically, if you remove the global _IO_stdin_used symbol, it triggers compatibility code which crashes. I've confirmed that if I add that symbol to the version-script in connman, things work again. Any idea how we raise the priority of this issue. There are no comments on the bug despite it having been posted a while ago :(. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFT] binutils 2.27
On Mon, 2016-08-08 at 08:21 -0700, Khem Raj wrote: > They are different issues. for OE ppc also shows same errors with lib > unwind. FWIW, I think the connmand segfault on mips and powerpc is hinted at with this bug: https://bugs.launchpad.net/ubuntu/+source/lua5.3/+bug/1570055 connmand is a binary linked with a linker version-script. If I build connmand without that option, it doesn't segfault, at least on mips. The binutils manuals say you shouldn't build binaries with version scripts: http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html Its suspected connman might do this to limit the function exposure to its plugins. Now sure exactly what needs to happen here without more research but it certainly hits at where the problem is. I suspect its the same issue on ppc. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFT] binutils 2.27
On Mon, 2016-08-08 at 09:14 +0100, Richard Purdie wrote: > On Mon, 2016-08-08 at 00:24 -0700, Khem Raj wrote: > > > On Aug 7, 2016, at 11:28 PM, Richard Purdie < > > > richard.pur...@linuxfoundation.org> wrote: > > > > > > On Sun, 2016-08-07 at 01:39 -0700, Khem Raj wrote: > > > > I have put together upgrade for binutils 2.27 here ( > > > > kraj/master > > > > branch ) > > > > > > > > https://github.com/kraj/openembedded-core/commit/b98f5761d2285f > > > > fd > > > > 773e > > > > c6ecb901b799302ebd6b > > > > > > > > I have started bunch of test builds. but I would appreciate any > > > > help > > > > in testing it out in your > > > > environments and report any issues you see. > > > > > > I ran this through the autobuilder: > > > > > > bitbake world shows issues in libunwind (from gold?): > > > > > > > yes, however, use of gold for libunwind in OE was an escape route > > where we were relying upon gold’s inability to detect this issue > > while BFD linker > > was detecting it earlier. Now in 2.27 gold has caught up as well. > > > > see > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6eeb0170 > > bb > > b43ffb73e8f01b8b481adde8194c21 > > > > so now we have to get to nub of this issue to resolve it. > > Ok. I think we also have: > > https://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds > /8 > 96 > https://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds > /8 > 96 > > in that "connmand --help" is segfaulting on ppc. I've not 100% > confirmed its the binutils patch but its seeming likely at this > point. Its also sefgaulting on all mips builds: https://autobuilder.yoctoproject.org/main/builders/nightly-mips/builds/883 https://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/863 https://autobuilder.yoctoproject.org/main/builders/nightly-mips64/builds/528 :( Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFT] binutils 2.27
On Mon, 2016-08-08 at 00:24 -0700, Khem Raj wrote: > > On Aug 7, 2016, at 11:28 PM, Richard Purdie < > > richard.pur...@linuxfoundation.org> wrote: > > > > On Sun, 2016-08-07 at 01:39 -0700, Khem Raj wrote: > > > I have put together upgrade for binutils 2.27 here ( kraj/master > > > branch ) > > > > > > https://github.com/kraj/openembedded-core/commit/b98f5761d2285ffd > > > 773e > > > c6ecb901b799302ebd6b > > > > > > I have started bunch of test builds. but I would appreciate any > > > help > > > in testing it out in your > > > environments and report any issues you see. > > > > I ran this through the autobuilder: > > > > bitbake world shows issues in libunwind (from gold?): > > > > yes, however, use of gold for libunwind in OE was an escape route > where we were relying upon gold’s inability to detect this issue > while BFD linker > was detecting it earlier. Now in 2.27 gold has caught up as well. > > see > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6eeb0170bb > b43ffb73e8f01b8b481adde8194c21 > > so now we have to get to nub of this issue to resolve it. Ok. I think we also have: https://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds/8 96 https://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds/8 96 in that "connmand --help" is segfaulting on ppc. I've not 100% confirmed its the binutils patch but its seeming likely at this point. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFT] binutils 2.27
On Sun, 2016-08-07 at 01:39 -0700, Khem Raj wrote: > I have put together upgrade for binutils 2.27 here ( kraj/master > branch ) > > https://github.com/kraj/openembedded-core/commit/b98f5761d2285ffd773e > c6ecb901b799302ebd6b > > I have started bunch of test builds. but I would appreciate any help > in testing it out in your > environments and report any issues you see. I ran this through the autobuilder: bitbake world shows issues in libunwind (from gold?): https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds /889/steps/BuildImages/logs/stdio bitbake world with no x11 also shows it: https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/build s/231/steps/BuildImages/logs/stdio Other than that, things don't seem too bad though. Cheers, Richard -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/3] gitkpkgv: Ensure files are closed
On Tue, 2016-06-07 at 11:02 +0200, Mike Looijmans wrote:
> Looks like regression in Python itself?
>
> In both Python 2 and 3, the file is closed properly if the file
> object is not
> being stored:
>
> >>> import os
> >>> os.listdir('/proc/self/fd')
> ['0', '1', '2', '3']
> >>> l=open('/proc/self/stat').readline()
> >>> os.listdir('/proc/self/fd')
> ['0', '1', '2', '3']
> >>> f=open('/proc/self/stat')
> >>> os.listdir('/proc/self/fd')
> ['0', '1', '2', '3', '4']
> >>>
>
>
> (file descriptor "3" is the one being used to read the /proc/self/fd
> directory, "4" is the one used for reading the stat file)
>
> The "with" construction should not be needed here. Something else is
> causing
> this (e.g. nested function definition or exception handler?).
$ python2 -Wdefault -c "open('/bin/bash')"
$ python3 -Wdefault -c "open('/bin/bash')"
-c:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/bin/bash'
mode='r' encoding='UTF-8'>
Admittedly its not an out the box warning but it is one that seems to
be enabled under bitbake. Details in:
https://bugs.python.org/issue10093
but the gist of the issue is that relying on the garbage collector to
close files is a cpython'ism and other implementations of python may
not do this.
So whilst "with" might not be strictly required, it is recommended.
Cheers,
Richard
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/3] gitkpkgv: Ensure files are closed
This avoids warnings with python 3.
Signed-off-by: Richard Purdie
---
meta-oe/classes/gitpkgv.bbclass | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta-oe/classes/gitpkgv.bbclass b/meta-oe/classes/gitpkgv.bbclass
index 1cba00c..4866fac 100644
--- a/meta-oe/classes/gitpkgv.bbclass
+++ b/meta-oe/classes/gitpkgv.bbclass
@@ -87,11 +87,13 @@ def get_git_pkgv(d, use_tags):
if commits != "":
oe.path.remove(rev_file, recurse=False)
-open(rev_file, "w").write("%d\n" % int(commits))
+with open(rev_file, "w") as f:
+f.write("%d\n" % int(commits))
else:
commits = "0"
else:
-commits = open(rev_file, "r").readline(128).strip()
+with open(rev_file, "r") as f:
+commits = f.readline(128).strip()
if use_tags:
try:
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 3/3] abiword/gnone-vfs: Use print as a function
In python 3, print is a function. Disable some pointless debug output
whilst here.
Signed-off-by: Richard Purdie
---
meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb | 2 +-
meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb
b/meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb
index 962a56c..e0888c1 100644
--- a/meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb
+++ b/meta-gnome/recipes-gnome/abiword/abiword_3.0.1.bb
@@ -113,7 +113,7 @@ python populate_packages_prepend () {
packages = d.getVar('PACKAGES', 1).split()
for pkg in packages[1:]:
if not pkg in blacklist and not pkg in metapkg_rdepends and not
pkg.count("-dev") and not pkg.count("-dbg") and not pkg.count("static") and not
pkg.count("locale") and not pkg.count("abiword-doc"):
-print "Modifying ", pkg
+print("Modifying %s" % pkg)
metapkg_rdepends.append(pkg)
d.setVar('RDEPENDS_' + metapkg, ' '.join(metapkg_rdepends))
d.setVar('DESCRIPTION_' + metapkg, 'abiword-plugin meta package')
diff --git a/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb
b/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb
index f9b02b1..d311338 100644
--- a/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb
+++ b/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb
@@ -53,7 +53,7 @@ FILES_${PN}-doc += "${datadir}/gtk-doc"
PACKAGES_DYNAMIC += "^gnome-vfs-plugin-.*"
python populate_packages_prepend () {
-print d.getVar('FILES_gnome-vfs', 1)
+#print(d.getVar('FILES_gnome-vfs', True))
plugindir = d.expand('${libdir}/gnome-vfs-2.0/modules/')
do_split_packages(d, plugindir, '^lib(.*)\.so$', 'gnome-vfs-plugin-%s',
'GNOME VFS plugin for %s')
--
2.7.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/3] netmap-modules: Avoid type warning with python v3
Python 3 is stricter about type comparisions, this avoids warnings.
Signed-off-by: Richard Purdie
---
meta-networking/recipes-kernel/netmap/netmap-modules_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-networking/recipes-kernel/netmap/netmap-modules_git.bb
b/meta-networking/recipes-kernel/netmap/netmap-modules_git.bb
index 406a4f3..6544bb5 100644
--- a/meta-networking/recipes-kernel/netmap/netmap-modules_git.bb
+++ b/meta-networking/recipes-kernel/netmap/netmap-modules_git.bb
@@ -70,7 +70,7 @@ do_configure_append () {
#define NETMAP_LINUX_HAVE_E1000E_DOWN2
EOF
-if ${@ 'false' if (bb.utils.vercmp_string(d.getVar('KERNEL_VERSION', True),
'3.17') < 0) else 'true' } ; then
+if ${@ 'false' if (bb.utils.vercmp_string(d.getVar('KERNEL_VERSION', True) or
"0", '3.17') < 0) else 'true' } ; then
echo OK
cat >> ${S}/LINUX/netmap_linux_config.h <http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] cyrus-sasl: Drop unneeded group addition
The mail group is provided by base-passwd so would always be present. Therefore
drop the uneeded group addition from this recipe.
This works around the recent user cleanup code improvements which meant
this started causing failures for people.
Signed-off-by: Richard Purdie
---
meta-networking/recipes-daemons/cyrus-sasl/cyrus-sasl_2.1.26.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta-networking/recipes-daemons/cyrus-sasl/cyrus-sasl_2.1.26.bb
b/meta-networking/recipes-daemons/cyrus-sasl/cyrus-sasl_2.1.26.bb
index 33468a1..5da3d96 100644
--- a/meta-networking/recipes-daemons/cyrus-sasl/cyrus-sasl_2.1.26.bb
+++ b/meta-networking/recipes-daemons/cyrus-sasl/cyrus-sasl_2.1.26.bb
@@ -72,7 +72,6 @@ do_install_append() {
}
USERADD_PACKAGES = "${PN}-bin"
-GROUPADD_PARAM_${PN}-bin = "--system mail"
USERADD_PARAM_${PN}-bin = "--system --home=/var/spool/mail -g mail cyrus"
SYSTEMD_PACKAGES = "${PN}"
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][meta-networking 5/5] dovecot: Blacklist
On Mon, 2016-02-22 at 14:10 +0100, Martin Jansa wrote:
> Signed-off-by: Martin Jansa
> ---
> meta-networking/recipes-support/dovecot/dovecot_2.2.21.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta-networking/recipes
> -support/dovecot/dovecot_2.2.21.bb b/meta-networking/recipes
> -support/dovecot/dovecot_2.2.21.bb
> index 7fb8b44..f297dff 100644
> --- a/meta-networking/recipes-support/dovecot/dovecot_2.2.21.bb
> +++ b/meta-networking/recipes-support/dovecot/dovecot_2.2.21.bb
> @@ -63,3 +63,5 @@ FILES_${PN}-staticdev += "${libdir}/dovecot/*/*.a"
> FILES_${PN}-dev += "${libdir}/dovecot/*.so"
> FILES_${PN}-dbg += "${libdir}/dovecot/*/.debug"
>
> +# http://errors.yoctoproject.org/Errors/Details/35133/
> +PNBLACKLIST[dovecot] ?= "BROKEN: QA Issue: -dev package contains non
> -symlink .so""
Typo "" above causes a parsing failure with master-next.
Cheers,
Richard
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 12/12] nginx: Fix build when static libs disabled
Signed-off-by: Richard Purdie
---
meta-webserver/recipes-httpd/nginx/nginx_1.9.10.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-webserver/recipes-httpd/nginx/nginx_1.9.10.bb
b/meta-webserver/recipes-httpd/nginx/nginx_1.9.10.bb
index 5d63d41..6fa82ff 100644
--- a/meta-webserver/recipes-httpd/nginx/nginx_1.9.10.bb
+++ b/meta-webserver/recipes-httpd/nginx/nginx_1.9.10.bb
@@ -31,6 +31,7 @@ NGINX_WWWDIR ?= "${localstatedir}/www/localhost"
NGINX_USER ?= "www"
EXTRA_OECONF = ""
+DISABLE_STATIC = ""
do_configure () {
if [ "${SITEINFO_BITS}" = "64" ]; then
--
2.5.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 10/12] libtevent: Fix build when static libs disabled
Signed-off-by: Richard Purdie
---
meta-networking/recipes-support/libtevent/libtevent_0.9.25.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-networking/recipes-support/libtevent/libtevent_0.9.25.bb
b/meta-networking/recipes-support/libtevent/libtevent_0.9.25.bb
index 2ec79e9..aa61ea6 100644
--- a/meta-networking/recipes-support/libtevent/libtevent_0.9.25.bb
+++ b/meta-networking/recipes-support/libtevent/libtevent_0.9.25.bb
@@ -26,6 +26,7 @@ EXTRA_OECONF += "--disable-rpath \
--with-libiconv=${STAGING_DIR_HOST}${prefix}\
--without-gettext \
"
+DISABLE_STATIC = ""
PACKAGES += "python-tevent python-tevent-dbg"
--
2.5.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 06/12] xmlstarlet: Disable PARALLEL_MAKE
Signed-off-by: Richard Purdie
---
meta-oe/recipes-support/xmlstarlet/xmlstarlet_1.5.0.bb | 7 +++
1 file changed, 7 insertions(+)
diff --git a/meta-oe/recipes-support/xmlstarlet/xmlstarlet_1.5.0.bb
b/meta-oe/recipes-support/xmlstarlet/xmlstarlet_1.5.0.bb
index d9a03c6..2b8603e 100644
--- a/meta-oe/recipes-support/xmlstarlet/xmlstarlet_1.5.0.bb
+++ b/meta-oe/recipes-support/xmlstarlet/xmlstarlet_1.5.0.bb
@@ -24,3 +24,10 @@ inherit autotools
EXTRA_OECONF="--disable-build-docs \
--with-libxml-prefix=${STAGING_LIBDIR}/.. \
--with-libxslt-prefix=${STAGING_LIBDIR}/.."
+
+#Makefile:2116: recipe for target 'src/elem-usage.c' failed
+#make[1]: *** [src/elem-usage.c] Error 1
+#/bin/bash: src/escape-usage.c: No such file or directory
+#Makefile:2116: recipe for target 'src/escape-usage.c' failed
+#make[1]: *** [src/escape-usage.c] Error 1
+PARALLEL_MAKE = ""
\ No newline at end of file
--
2.5.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 07/12] inetutils: Fix build when static libs disabled
Signed-off-by: Richard Purdie
---
meta-networking/recipes-connectivity/inetutils/inetutils_1.9.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-networking/recipes-connectivity/inetutils/inetutils_1.9.4.bb
b/meta-networking/recipes-connectivity/inetutils/inetutils_1.9.4.bb
index 50aedd3..68487ea 100644
--- a/meta-networking/recipes-connectivity/inetutils/inetutils_1.9.4.bb
+++ b/meta-networking/recipes-connectivity/inetutils/inetutils_1.9.4.bb
@@ -79,7 +79,7 @@ do_install_append () {
rm -rf ${D}${libexecdir}/
# remove usr/lib if empty
-rmdir ${D}${libdir}
+rmdir ${D}${libdir} || true
}
PACKAGES =+ "${PN}-ping ${PN}-ping6 ${PN}-hostname ${PN}-ifconfig \
--
2.5.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 11/12] soci: Fix build when static libs disabled
Signed-off-by: Richard Purdie
---
meta-oe/recipes-support/soci/soci_3.2.2.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-oe/recipes-support/soci/soci_3.2.2.bb
b/meta-oe/recipes-support/soci/soci_3.2.2.bb
index d1964eb..1f5a485 100644
--- a/meta-oe/recipes-support/soci/soci_3.2.2.bb
+++ b/meta-oe/recipes-support/soci/soci_3.2.2.bb
@@ -36,6 +36,7 @@ PACKAGECONFIG ??= "empty"
# Take the flags added by PACKAGECONFIG and pass them to cmake.
EXTRA_OECMAKE = "${EXTRA_OECONF} -DSOCI_LIBDIR=${libdir}"
+DISABLE_STATIC = ""
inherit cmake
--
2.5.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 04/12] poppler-data: Fix to work with changed makeflags
Without this, the data is installed into /usr/local and fails QA checks.
Signed-off-by: Richard Purdie
---
meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
index 27c4110..e530a48 100644
--- a/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
+++ b/meta-oe/recipes-support/poppler/poppler-data_0.4.7.bb
@@ -28,7 +28,7 @@ do_compile() {
}
do_install() {
-oe_runmake install DESTDIR=${D}
+oe_runmake install DESTDIR=${D} prefix=${prefix} datadir=${datadir}
install -d ${D}${datadir}/poppler/cMap
install -m644 ${WORKDIR}/Identity-* ${D}${datadir}/poppler/cMap/
}
--
2.5.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
