[oe] [PATCH] fmt: remove unnecessary "inherit ptest" directive
Given that the recipe does not provide the standard ptest
infrastructure, remove the superfluous inherit of ptest.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta-oe/recipes-support/fmt/fmt_10.2.1.bb
b/meta-oe/recipes-support/fmt/fmt_10.2.1.bb
index c2f19c43a..1437eb480 100644
--- a/meta-oe/recipes-support/fmt/fmt_10.2.1.bb
+++ b/meta-oe/recipes-support/fmt/fmt_10.2.1.bb
@@ -9,7 +9,7 @@ SRCREV = "e69e5f977d458f2650bb346dadf2ad30c5320281"
S = "${WORKDIR}/git"
-inherit cmake ptest
+inherit cmake
EXTRA_OECMAKE += "-DBUILD_SHARED_LIBS=ON"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#109250):
https://lists.openembedded.org/g/openembedded-devel/message/109250
Mute This Topic: https://lists.openembedded.org/mt/104841328/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] short list of strange ptest recipes from meta-oe/recipes-support
in my travels, i ran across the following odd allegedly ptest enabled recipes: https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/fmt/fmt_10.2.1.bb https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/function2/function2_4.2.4.bb https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/libmanette/libmanette_0.2.7.bb - inherits ptest while not providing the requisite ptest harness and one more equally odd: https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/websocketpp/websocketpp_0.8.2.bb - tests DISTRO_FEATURES for ptest without even inheriting ptest rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#109244): https://lists.openembedded.org/g/openembedded-devel/message/109244 Mute This Topic: https://lists.openembedded.org/mt/104827290/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] "fmt" recipe inherits ptest while having no ptest content
just noticed here: https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/recipes-support/fmt/fmt_10.2.1.bb that that recipe inherits "ptest" while not even supplying a run-ptest utility, or anything else normally required by ptest. yes, that recipe does provide a test suite, but without wrapping it in a ptest harness, it's not clear what this means. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#109243): https://lists.openembedded.org/g/openembedded-devel/message/109243 Mute This Topic: https://lists.openembedded.org/mt/104825821/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] should "ntp-dev" package have header files in it, or not?
On Wed, 27 Oct 2021, Alex Kiernan wrote: > On Wed, Oct 27, 2021 at 4:55 PM Robert P. J. Day > wrote: > > > > On Tue, 26 Oct 2021, Alex Kiernan wrote: > > > > > On Mon, Oct 25, 2021 at 4:11 PM Robert P. J. Day > > > wrote: > > > > > > > > On Mon, 25 Oct 2021, Alex Kiernan wrote: > > > > > > > > > On Mon, Oct 25, 2021 at 11:51 AM Robert P. J. Day > > > > > wrote: > > > > > > > > > > > > On Sun, 24 Oct 2021, Khem Raj wrote: > > > > > > > > > > > > > On Sun, Oct 24, 2021 at 5:51 AM Robert P. J. Day > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > colleague recently asked me how to get access to one or more > > > > > > > > header > > > > > > > > files associated with "ntp", so he could: > > > > > > > > > > > > > > > > #include > > > > > > > > > > > > > > > > from some other code. casually, i suggested the standard way > > > > > > > > was to > > > > > > > > add ntp to his recipe's DEPENDS, but that didn't do it, so i > > > > > > > > built ntp > > > > > > > > in my own aarch64 project, then took a look under > > > > > > > > packages-split to > > > > > > > > see what got packaged in ntp-dev, and was puzzled to see it was > > > > > > > > absolutely empty. > > > > > > > > > > > > > > > > is this deliberate? are other recipes not entitled to ntp's > > > > > > > > header > > > > > > > > files? am i overlooking something? > > > > > > > > > > > > > > While the header seems to be meant for public consumption, the > > > > > > > build > > > > > > > explicitly does not export it, so perhaps thats not expected to be > > > > > > > used this way anymore. > > > > > > > > > > > > just to tie this back to a question i once asked on (i believe) > > > > > > the > > > > > > YP mailing list, this wind river build is using ntpsec instead of > > > > > > regular ntp, but it would appear this would still have the same > > > > > > problem -- while the ntpsec source contains an "include" directory > > > > > > with lots of ntp-related header files, if one comes up with an > > > > > > ntpsec > > > > > > recipe, nothing would be solved if it also does not install those > > > > > > headers into ntpsec-dev. > > > > > > > > > > > > so, simple question: does anyone have a bitbake recipe for current > > > > > > ntpsec? > > > > > > > > > > I do, it's unfinished as I realised part way through that the python > > > > > dependency meant it wasn't going to fit for my use case, but the > > > > > basics of the build are there. > > > > > > > > so is there a link for this? > > > > > > > > > > Have a look at this: > > > > > > https://github.com/akiernan/meta-openembedded/commit/b1464c4b8dcab4a9dfaebbb7116b1c8462a198c4 > > > > > > Seems like it works for me. Will send a patch if it looks good. > > > > well, it builds for my poky/aarch64/core-image-base build, so all > > that's let is to decide how to populate ntpsec-dev with those header > > files (simple), and why they're not part of nptsec-dev in the first > > place. > > > > I'm just scanning through the code and I don't obviously see > anything which is a public interface (other than the python one)? > There's clearly bits you could pick out, but having that in a > default package feels wrong to me - there's no -dev package in > Ubuntu that I can spot either. i know, and i just had clarified for me why they're trying to do it this way -- they don't want to support the python interface, so they have to do this hack. i'm not sure i want to go along with that idea. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#93634): https://lists.openembedded.org/g/openembedded-devel/message/93634 Mute This Topic: https://lists.openembedded.org/mt/86553439/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] should "ntp-dev" package have header files in it, or not?
On Tue, 26 Oct 2021, Alex Kiernan wrote: > On Mon, Oct 25, 2021 at 4:11 PM Robert P. J. Day > wrote: > > > > On Mon, 25 Oct 2021, Alex Kiernan wrote: > > > > > On Mon, Oct 25, 2021 at 11:51 AM Robert P. J. Day > > > wrote: > > > > > > > > On Sun, 24 Oct 2021, Khem Raj wrote: > > > > > > > > > On Sun, Oct 24, 2021 at 5:51 AM Robert P. J. Day > > > > > wrote: > > > > > > > > > > > > > > > > > > colleague recently asked me how to get access to one or more > > > > > > header > > > > > > files associated with "ntp", so he could: > > > > > > > > > > > > #include > > > > > > > > > > > > from some other code. casually, i suggested the standard way was to > > > > > > add ntp to his recipe's DEPENDS, but that didn't do it, so i built > > > > > > ntp > > > > > > in my own aarch64 project, then took a look under packages-split to > > > > > > see what got packaged in ntp-dev, and was puzzled to see it was > > > > > > absolutely empty. > > > > > > > > > > > > is this deliberate? are other recipes not entitled to ntp's header > > > > > > files? am i overlooking something? > > > > > > > > > > While the header seems to be meant for public consumption, the build > > > > > explicitly does not export it, so perhaps thats not expected to be > > > > > used this way anymore. > > > > > > > > just to tie this back to a question i once asked on (i believe) the > > > > YP mailing list, this wind river build is using ntpsec instead of > > > > regular ntp, but it would appear this would still have the same > > > > problem -- while the ntpsec source contains an "include" directory > > > > with lots of ntp-related header files, if one comes up with an ntpsec > > > > recipe, nothing would be solved if it also does not install those > > > > headers into ntpsec-dev. > > > > > > > > so, simple question: does anyone have a bitbake recipe for current > > > > ntpsec? > > > > > > I do, it's unfinished as I realised part way through that the python > > > dependency meant it wasn't going to fit for my use case, but the > > > basics of the build are there. > > > > so is there a link for this? > > > > Have a look at this: > > https://github.com/akiernan/meta-openembedded/commit/b1464c4b8dcab4a9dfaebbb7116b1c8462a198c4 > > Seems like it works for me. Will send a patch if it looks good. well, it builds for my poky/aarch64/core-image-base build, so all that's let is to decide how to populate ntpsec-dev with those header files (simple), and why they're not part of nptsec-dev in the first place. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#93632): https://lists.openembedded.org/g/openembedded-devel/message/93632 Mute This Topic: https://lists.openembedded.org/mt/86553439/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] should "ntp-dev" package have header files in it, or not?
On Tue, 26 Oct 2021, Alex Kiernan wrote: > On Mon, Oct 25, 2021 at 4:11 PM Robert P. J. Day > wrote: > > > > On Mon, 25 Oct 2021, Alex Kiernan wrote: > > > > > On Mon, Oct 25, 2021 at 11:51 AM Robert P. J. Day > > > wrote: > > > > > > > > On Sun, 24 Oct 2021, Khem Raj wrote: > > > > > > > > > On Sun, Oct 24, 2021 at 5:51 AM Robert P. J. Day > > > > > wrote: > > > > > > > > > > > > > > > > > > colleague recently asked me how to get access to one or more > > > > > > header > > > > > > files associated with "ntp", so he could: > > > > > > > > > > > > #include > > > > > > > > > > > > from some other code. casually, i suggested the standard way was to > > > > > > add ntp to his recipe's DEPENDS, but that didn't do it, so i built > > > > > > ntp > > > > > > in my own aarch64 project, then took a look under packages-split to > > > > > > see what got packaged in ntp-dev, and was puzzled to see it was > > > > > > absolutely empty. > > > > > > > > > > > > is this deliberate? are other recipes not entitled to ntp's header > > > > > > files? am i overlooking something? > > > > > > > > > > While the header seems to be meant for public consumption, the build > > > > > explicitly does not export it, so perhaps thats not expected to be > > > > > used this way anymore. > > > > > > > > just to tie this back to a question i once asked on (i believe) the > > > > YP mailing list, this wind river build is using ntpsec instead of > > > > regular ntp, but it would appear this would still have the same > > > > problem -- while the ntpsec source contains an "include" directory > > > > with lots of ntp-related header files, if one comes up with an ntpsec > > > > recipe, nothing would be solved if it also does not install those > > > > headers into ntpsec-dev. > > > > > > > > so, simple question: does anyone have a bitbake recipe for current > > > > ntpsec? > > > > > > I do, it's unfinished as I realised part way through that the python > > > dependency meant it wasn't going to fit for my use case, but the > > > basics of the build are there. > > > > so is there a link for this? > > > > Have a look at this: > > https://github.com/akiernan/meta-openembedded/commit/b1464c4b8dcab4a9dfaebbb7116b1c8462a198c4 > > Seems like it works for me. Will send a patch if it looks good. setting up to test build right now: poky/aarch64/core-image-base. will let you know. thank you kindly. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#93624): https://lists.openembedded.org/g/openembedded-devel/message/93624 Mute This Topic: https://lists.openembedded.org/mt/86553439/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] should "ntp-dev" package have header files in it, or not?
On Mon, 25 Oct 2021, Alex Kiernan wrote: > On Mon, Oct 25, 2021 at 11:51 AM Robert P. J. Day > wrote: > > > > On Sun, 24 Oct 2021, Khem Raj wrote: > > > > > On Sun, Oct 24, 2021 at 5:51 AM Robert P. J. Day > > > wrote: > > > > > > > > > > > > colleague recently asked me how to get access to one or more header > > > > files associated with "ntp", so he could: > > > > > > > > #include > > > > > > > > from some other code. casually, i suggested the standard way was to > > > > add ntp to his recipe's DEPENDS, but that didn't do it, so i built ntp > > > > in my own aarch64 project, then took a look under packages-split to > > > > see what got packaged in ntp-dev, and was puzzled to see it was > > > > absolutely empty. > > > > > > > > is this deliberate? are other recipes not entitled to ntp's header > > > > files? am i overlooking something? > > > > > > While the header seems to be meant for public consumption, the build > > > explicitly does not export it, so perhaps thats not expected to be > > > used this way anymore. > > > > just to tie this back to a question i once asked on (i believe) the > > YP mailing list, this wind river build is using ntpsec instead of > > regular ntp, but it would appear this would still have the same > > problem -- while the ntpsec source contains an "include" directory > > with lots of ntp-related header files, if one comes up with an ntpsec > > recipe, nothing would be solved if it also does not install those > > headers into ntpsec-dev. > > > > so, simple question: does anyone have a bitbake recipe for current > > ntpsec? > > I do, it's unfinished as I realised part way through that the python > dependency meant it wasn't going to fit for my use case, but the > basics of the build are there. so is there a link for this? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#93565): https://lists.openembedded.org/g/openembedded-devel/message/93565 Mute This Topic: https://lists.openembedded.org/mt/86553439/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] should "ntp-dev" package have header files in it, or not?
On Sun, 24 Oct 2021, Khem Raj wrote: > On Sun, Oct 24, 2021 at 5:51 AM Robert P. J. Day > wrote: > > > > > > colleague recently asked me how to get access to one or more header > > files associated with "ntp", so he could: > > > > #include > > > > from some other code. casually, i suggested the standard way was to > > add ntp to his recipe's DEPENDS, but that didn't do it, so i built ntp > > in my own aarch64 project, then took a look under packages-split to > > see what got packaged in ntp-dev, and was puzzled to see it was > > absolutely empty. > > > > is this deliberate? are other recipes not entitled to ntp's header > > files? am i overlooking something? > > While the header seems to be meant for public consumption, the build > explicitly does not export it, so perhaps thats not expected to be > used this way anymore. just to tie this back to a question i once asked on (i believe) the YP mailing list, this wind river build is using ntpsec instead of regular ntp, but it would appear this would still have the same problem -- while the ntpsec source contains an "include" directory with lots of ntp-related header files, if one comes up with an ntpsec recipe, nothing would be solved if it also does not install those headers into ntpsec-dev. so, simple question: does anyone have a bitbake recipe for current ntpsec? it's "waf" based, so it might be a bit trickier, but if there is such a recipe, unless it installs its header files into ntpsec-dev, then it doesn't really solve the problem, does it? thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#93560): https://lists.openembedded.org/g/openembedded-devel/message/93560 Mute This Topic: https://lists.openembedded.org/mt/86553439/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] should "ntp-dev" package have header files in it, or not?
Quoting Khem Raj : On Sun, Oct 24, 2021 at 5:51 AM Robert P. J. Day wrote: colleague recently asked me how to get access to one or more header files associated with "ntp", so he could: #include from some other code. casually, i suggested the standard way was to add ntp to his recipe's DEPENDS, but that didn't do it, so i built ntp in my own aarch64 project, then took a look under packages-split to see what got packaged in ntp-dev, and was puzzled to see it was absolutely empty. is this deliberate? are other recipes not entitled to ntp's header files? am i overlooking something? While the header seems to be meant for public consumption, the build explicitly does not export it, so perhaps thats not expected to be used this way anymore. i popped over to https://github.com/ntp-project/ntp to see if the README would clarify anything, and the docs say of the include/ directory: "Directory containing include header files used by most programs in the distribution." "in the distribution." so does that mean that nothing external is expected to use them? still unsure as to what to tell other developers as to whether they are entitled to include any of those headers, no matter how they do it. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#93557): https://lists.openembedded.org/g/openembedded-devel/message/93557 Mute This Topic: https://lists.openembedded.org/mt/86553439/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] should "ntp-dev" package have header files in it, or not?
Quoting Khem Raj : On Sun, Oct 24, 2021 at 5:51 AM Robert P. J. Day wrote: colleague recently asked me how to get access to one or more header files associated with "ntp", so he could: #include from some other code. casually, i suggested the standard way was to add ntp to his recipe's DEPENDS, but that didn't do it, so i built ntp in my own aarch64 project, then took a look under packages-split to see what got packaged in ntp-dev, and was puzzled to see it was absolutely empty. is this deliberate? are other recipes not entitled to ntp's header files? am i overlooking something? While the header seems to be meant for public consumption, the build explicitly does not export it, so perhaps thats not expected to be used this way anymore. That's what I first suspected, but that seems sort of odd. Does that mean no one is expected to now develop against ntp? Or what *does* it mean? I guess checking the Git log is the next step. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#93556): https://lists.openembedded.org/g/openembedded-devel/message/93556 Mute This Topic: https://lists.openembedded.org/mt/86553439/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] should "ntp-dev" package have header files in it, or not?
colleague recently asked me how to get access to one or more header files associated with "ntp", so he could: #include from some other code. casually, i suggested the standard way was to add ntp to his recipe's DEPENDS, but that didn't do it, so i built ntp in my own aarch64 project, then took a look under packages-split to see what got packaged in ntp-dev, and was puzzled to see it was absolutely empty. is this deliberate? are other recipes not entitled to ntp's header files? am i overlooking something? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#93553): https://lists.openembedded.org/g/openembedded-devel/message/93553 Mute This Topic: https://lists.openembedded.org/mt/86553439/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [harkknott 01/23] python3-cerberus: Upgrade 1.3.3 -> 1.3.4
all those patches refer to "harkknott". rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#91548): https://lists.openembedded.org/g/openembedded-devel/message/91548 Mute This Topic: https://lists.openembedded.org/mt/83098487/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [PATCH] packagegroups: delete superfluous "PROVIDES" lines
There is no need for PROVIDES lines in packagegroups, so delete them
as has already been done in oe-core.
Signed-off-by: Robert P. J. Day
---
diff --git
a/meta-filesystems/recipes-filesystems/packageconfigs/packagegroup-meta-filesystems.bb
b/meta-filesystems/recipes-filesystems/packageconfigs/packagegroup-meta-filesystems.bb
index 8a8a8dbe2..c899e83bb 100644
---
a/meta-filesystems/recipes-filesystems/packageconfigs/packagegroup-meta-filesystems.bb
+++
b/meta-filesystems/recipes-filesystems/packageconfigs/packagegroup-meta-filesystems.bb
@@ -2,7 +2,6 @@ SUMMARY = "Meta-filesystem packagegroups"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = ' \
packagegroup-meta-filesystems \
packagegroup-meta-filesystems-support \
diff --git
a/meta-initramfs/recipes-core/packagegroups/packagegroup-meta-initramfs.bb
b/meta-initramfs/recipes-core/packagegroups/packagegroup-meta-initramfs.bb
index 2955baea2..97a60930a 100644
--- a/meta-initramfs/recipes-core/packagegroups/packagegroup-meta-initramfs.bb
+++ b/meta-initramfs/recipes-core/packagegroups/packagegroup-meta-initramfs.bb
@@ -2,7 +2,6 @@ SUMMARY = "Meta-initramfs packagegroups"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = ' \
packagegroup-meta-initramfs \
packagegroup-meta-initramfs-devtools \
diff --git
a/meta-multimedia/recipes-multimedia/packagegroups/packagegroup-meta-multimedia.bb
b/meta-multimedia/recipes-multimedia/packagegroups/packagegroup-meta-multimedia.bb
index c4be1b5ce..e2ef18262 100644
---
a/meta-multimedia/recipes-multimedia/packagegroups/packagegroup-meta-multimedia.bb
+++
b/meta-multimedia/recipes-multimedia/packagegroups/packagegroup-meta-multimedia.bb
@@ -2,7 +2,6 @@ SUMMARY = "Meta-multimedia packagegroups"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = ' \
packagegroup-meta-multimedia \
packagegroup-meta-multimedia-connectivity \
diff --git
a/meta-networking/recipes-core/packagegroups/packagegroup-meta-networking.bb
b/meta-networking/recipes-core/packagegroups/packagegroup-meta-networking.bb
index 231d8d4da..48a7bc056 100644
--- a/meta-networking/recipes-core/packagegroups/packagegroup-meta-networking.bb
+++ b/meta-networking/recipes-core/packagegroups/packagegroup-meta-networking.bb
@@ -2,7 +2,6 @@ SUMMARY = "Meta-networking packagegroups"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = ' \
packagegroup-meta-networking \
packagegroup-meta-networking-connectivity \
diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
index c717d45e5..c9ab261dd 100644
--- a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
+++ b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
@@ -3,7 +3,6 @@ SUMMARY = "Meta-oe ptest packagegroups"
PACKAGE_ARCH = "${MACHINE_ARCH}"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = "\
packagegroup-meta-oe \
packagegroup-meta-oe-benchmarks \
diff --git a/meta-perl/recipes-perl/packagegroups/packagegroup-meta-perl.bb
b/meta-perl/recipes-perl/packagegroups/packagegroup-meta-perl.bb
index 3fa56d439..e390e8bbd 100644
--- a/meta-perl/recipes-perl/packagegroups/packagegroup-meta-perl.bb
+++ b/meta-perl/recipes-perl/packagegroups/packagegroup-meta-perl.bb
@@ -2,7 +2,6 @@ SUMMARY = "Meta-perl packagegroup"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = "\
packagegroup-meta-perl \
packagegroup-meta-perl-extended \
diff --git a/meta-python/recipes-core/packagegroups/packagegroup-meta-python.bb
b/meta-python/recipes-core/packagegroups/packagegroup-meta-python.bb
index e84bf225e..adaffd1a7 100644
--- a/meta-python/recipes-core/packagegroups/packagegroup-meta-python.bb
+++ b/meta-python/recipes-core/packagegroups/packagegroup-meta-python.bb
@@ -2,7 +2,6 @@ SUMMARY = "Meta-python ptest packagegroups"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = ' \
packagegroup-meta-python3 \
'
diff --git
a/meta-webserver/recipes-core/packagesgroups/packagegroup-meta-webserver.bb
b/meta-webserver/recipes-core/packagesgroups/packagegroup-meta-webserver.bb
index 2fa5bc4a9..d4e8aae54 100644
--- a/meta-webserver/recipes-core/packagesgroups/packagegroup-meta-webserver.bb
+++ b/meta-webserver/recipes-core/packagesgroups/packagegroup-meta-webserver.bb
@@ -2,7 +2,6 @@ SUMMARY = "Meta-webserver packagegroups"
inherit packagegroup
-PROVIDES = "${PACKAGES}"
PACKAGES = ' \
packagegroup-meta-webserver \
packagegroup-meta-webserver-http \
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
LinkedIn: http://ca.linkedin.c
[oe] [meta-networking][PATCH] correct "RRCOMMENDS" typo in ipset recipe
Signed-off-by: Robert P. J. Day
---
diff --git a/meta-networking/recipes-filter/ipset/ipset_7.9.bb
b/meta-networking/recipes-filter/ipset/ipset_7.9.bb
index 95e48f013..1ec890b2c 100644
--- a/meta-networking/recipes-filter/ipset/ipset_7.9.bb
+++ b/meta-networking/recipes-filter/ipset/ipset_7.9.bb
@@ -16,6 +16,6 @@ inherit autotools pkgconfig module-base
EXTRA_OECONF += "-with-kbuild=${KBUILD_OUTPUT}
--with-ksource=${STAGING_KERNEL_DIR}"
-RRCOMMENDS_${PN} = "\
+RRECOMMENDS_${PN} = "\
kernel-module-ip-set \
"
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
LinkedIn: http://ca.linkedin.com/in/rpjday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#89291):
https://lists.openembedded.org/g/openembedded-devel/message/89291
Mute This Topic: https://lists.openembedded.org/mt/80392650/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] standardizing HOMEPAGE values in python3 recipes
On Tue, 16 Jun 2020, Adrian Bunk wrote: > On Tue, Jun 16, 2020 at 06:36:50AM -0400, Robert P. J. Day wrote: > > > > given the current flurry of python recipe cleanup, just want to > > verify a couple things that could/should be standardized. > > > > first, HOMEPAGE values of the form: > > > > https://pypi.python.org/pypi/astroid > > > > can be adjusted to reflect the result of the redirection, as in: > > > > https://pypi.org/project/astroid > > > > also, as i read it, recipe HOMEPAGE values should *not* refer to the > > pypi page, as that is already set automatically by pypi.bbclass. > > rather, the HOMEPAGE should refer to the actual source home page, > > which in the case of the astroid package would be: > > > > https://github.com/PyCQA/astroid > > > > does this make sense? > > When the source is on github this is supposed to be linked from > PyPi. > > My personal impression is that meta data like the HOMEPAGE field is > usually poorly maintained, keeping an automatically set "good > enough" value (the PyPi link) would IMHO be the best default option. i'm inclined to agree, but i will at least lay down some standards for a few people as to how to craft recipes from now on. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#85144): https://lists.openembedded.org/g/openembedded-devel/message/85144 Mute This Topic: https://lists.openembedded.org/mt/74913373/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] standardizing HOMEPAGE values in python3 recipes
given the current flurry of python recipe cleanup, just want to verify a couple things that could/should be standardized. first, HOMEPAGE values of the form: https://pypi.python.org/pypi/astroid can be adjusted to reflect the result of the redirection, as in: https://pypi.org/project/astroid also, as i read it, recipe HOMEPAGE values should *not* refer to the pypi page, as that is already set automatically by pypi.bbclass. rather, the HOMEPAGE should refer to the actual source home page, which in the case of the astroid package would be: https://github.com/PyCQA/astroid does this make sense? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#85140): https://lists.openembedded.org/g/openembedded-devel/message/85140 Mute This Topic: https://lists.openembedded.org/mt/74913373/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] use weak assignments for PNBLACKLIST in recipe files
On Wed, 27 May 2020, Khem Raj wrote: > > > On Wed, May 27, 2020 at 3:14 AM Robert P. J. Day > wrote: > On Tue, 26 May 2020, Khem Raj wrote: > > > On Mon, May 25, 2020 at 12:21 PM Robert P. J. Day > > wrote: > > > > > > Make sure PNBLACKLIST assignments in recipe files use weak > > > assignment, so they can be overridden in, for example, local.conf > > > files. > > > > > > > I would like contributions here when someone fixes one of the > > blacklisted recipes. This patch will let downstream users host it in > > bbappends or other places what is the intended use of this patch? > > i'm not sure what you're asking for here ... there is no claim that > any of these recipes have been fixed in any way, only that weak > assignment seems to be the default for blacklisting to at least allow > for the possibility of overriding. > > > Ok I think that’s fine I wanted to understand the reason since weak > assignment do have some unintended results but if it is to make it > uniform I Think that’s fair discussion on YP list that inspired this: https://lists.yoctoproject.org/g/yocto/topic/74460612#49479 rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#84622): https://lists.openembedded.org/g/openembedded-devel/message/84622 Mute This Topic: https://lists.openembedded.org/mt/74464211/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] use weak assignments for PNBLACKLIST in recipe files
On Tue, 26 May 2020, Khem Raj wrote:
> On Mon, May 25, 2020 at 12:21 PM Robert P. J. Day
> wrote:
> >
> > Make sure PNBLACKLIST assignments in recipe files use weak
> > assignment, so they can be overridden in, for example, local.conf
> > files.
> >
>
> I would like contributions here when someone fixes one of the
> blacklisted recipes. This patch will let downstream users host it in
> bbappends or other places what is the intended use of this patch?
i'm not sure what you're asking for here ... there is no claim that
any of these recipes have been fixed in any way, only that weak
assignment seems to be the default for blacklisting to at least allow
for the possibility of overriding.
> >
> > diff --git
> > a/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb
> > b/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb
> > index c39faef8d..eee96d865 100644
> > --- a/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb
> > +++ b/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb
> > @@ -69,4 +69,4 @@ RDEPENDS_${PN}-server += "tcp-wrappers xinetd rpcbind"
> >
> > # http://errors.yoctoproject.org/Errors/Details/186962/
> > COMPATIBLE_HOST_libc-musl = 'null'
> > -PNBLACKLIST[netkit-rusers] = "Fails to build rup.c:51:10: fatal error:
> > rstat.h: No such file or directory"
> > +PNBLACKLIST[netkit-rusers] ?= "Fails to build rup.c:51:10: fatal error:
> > rstat.h: No such file or directory"
> > diff --git a/meta-networking/recipes-support/drbd/drbd_9.0.19-1.bb
> > b/meta-networking/recipes-support/drbd/drbd_9.0.19-1.bb
> > index 23fe2021b..c296c3bc1 100644
> > --- a/meta-networking/recipes-support/drbd/drbd_9.0.19-1.bb
> > +++ b/meta-networking/recipes-support/drbd/drbd_9.0.19-1.bb
> > @@ -22,4 +22,4 @@ do_install () {
> > oe_runmake install DESTDIR="${D}"
> > }
> >
> > -PNBLACKLIST[drbd] = "Kernel module Needs forward porting to kernel 5.2+"
> > +PNBLACKLIST[drbd] ?= "Kernel module Needs forward porting to kernel 5.2+"
> > diff --git
> > a/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
> > b/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
> > index 5917cfb3e..4a1bbe620 100644
> > --- a/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
> > +++ b/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
> > @@ -36,4 +36,4 @@ FILES_${PN}-dbg += "${libexecdir}/lowpan-tools/.debug/"
> > PACKAGES =+ "${PN}-python"
> > FILES_${PN}-python = "${libdir}/python*"
> >
> > -PNBLACKLIST[lowpan-tools] = "WARNING these tools are deprecated! Use
> > wpan-tools instead"
> > +PNBLACKLIST[lowpan-tools] ?= "WARNING these tools are deprecated! Use
> > wpan-tools instead"
> > diff --git a/meta-oe/recipes-devtools/nanopb/nanopb_0.4.0.bb
> > b/meta-oe/recipes-devtools/nanopb/nanopb_0.4.0.bb
> > index 21d110aee..2e3da7d4d 100644
> > --- a/meta-oe/recipes-devtools/nanopb/nanopb_0.4.0.bb
> > +++ b/meta-oe/recipes-devtools/nanopb/nanopb_0.4.0.bb
> > @@ -27,4 +27,4 @@ RDEPENDS_${PN} += "\
> >
> > BBCLASSEXTEND = "native nativesdk"
> >
> > -PNBLACKLIST[nanopb] = "Needs forward porting to use python3"
> > +PNBLACKLIST[nanopb] ?= "Needs forward porting to use python3"
> > diff --git a/meta-oe/recipes-extended/socketcan/can-isotp_git.bb
> > b/meta-oe/recipes-extended/socketcan/can-isotp_git.bb
> > index e40e1cd26..eca8dfc7b 100644
> > --- a/meta-oe/recipes-extended/socketcan/can-isotp_git.bb
> > +++ b/meta-oe/recipes-extended/socketcan/can-isotp_git.bb
> > @@ -11,4 +11,4 @@ inherit module
> >
> > EXTRA_OEMAKE += "KERNELDIR=${STAGING_KERNEL_DIR}"
> >
> > -PNBLACKLIST[can-isotp] = "Kernel module Needs forward porting to kernel
> > 5.2+"
> > +PNBLACKLIST[can-isotp] ?= "Kernel module Needs forward porting to kernel
> > 5.2+"
> > diff --git a/meta-oe/recipes-kernel/bpftool/bpftool.bb
> > b/meta-oe/recipes-kernel/bpftool/bpftool.bb
> > index 6683eccf2..1758430bc 100644
> > --- a/meta-oe/recipes-kernel/bpftool/bpftool.bb
> > +++ b/meta-oe/recipes-kernel/bpftool/bpftool.bb
> > @@ -32,4 +32,4 @@ python do_package_prepend() {
> > }
> >
> > B = "${WORKDIR}/${BPN}-${PV}"
> > -PNBLACKLIST[bpftool] = "Needs forward porting to kernel 5.2+"
> > +PNBLACKLIST[bpftool] ?= "Needs forward porting to kernel 5.2+"
> >
[oe] [PATCH] use weak assignments for PNBLACKLIST in recipe files
Make sure PNBLACKLIST assignments in recipe files use weak assignment,
so they can be overridden in, for example, local.conf files.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb
b/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb
index c39faef8d..eee96d865 100644
--- a/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb
+++ b/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb
@@ -69,4 +69,4 @@ RDEPENDS_${PN}-server += "tcp-wrappers xinetd rpcbind"
# http://errors.yoctoproject.org/Errors/Details/186962/
COMPATIBLE_HOST_libc-musl = 'null'
-PNBLACKLIST[netkit-rusers] = "Fails to build rup.c:51:10: fatal error:
rstat.h: No such file or directory"
+PNBLACKLIST[netkit-rusers] ?= "Fails to build rup.c:51:10: fatal error:
rstat.h: No such file or directory"
diff --git a/meta-networking/recipes-support/drbd/drbd_9.0.19-1.bb
b/meta-networking/recipes-support/drbd/drbd_9.0.19-1.bb
index 23fe2021b..c296c3bc1 100644
--- a/meta-networking/recipes-support/drbd/drbd_9.0.19-1.bb
+++ b/meta-networking/recipes-support/drbd/drbd_9.0.19-1.bb
@@ -22,4 +22,4 @@ do_install () {
oe_runmake install DESTDIR="${D}"
}
-PNBLACKLIST[drbd] = "Kernel module Needs forward porting to kernel 5.2+"
+PNBLACKLIST[drbd] ?= "Kernel module Needs forward porting to kernel 5.2+"
diff --git a/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
b/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
index 5917cfb3e..4a1bbe620 100644
--- a/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
+++ b/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
@@ -36,4 +36,4 @@ FILES_${PN}-dbg += "${libexecdir}/lowpan-tools/.debug/"
PACKAGES =+ "${PN}-python"
FILES_${PN}-python = "${libdir}/python*"
-PNBLACKLIST[lowpan-tools] = "WARNING these tools are deprecated! Use
wpan-tools instead"
+PNBLACKLIST[lowpan-tools] ?= "WARNING these tools are deprecated! Use
wpan-tools instead"
diff --git a/meta-oe/recipes-devtools/nanopb/nanopb_0.4.0.bb
b/meta-oe/recipes-devtools/nanopb/nanopb_0.4.0.bb
index 21d110aee..2e3da7d4d 100644
--- a/meta-oe/recipes-devtools/nanopb/nanopb_0.4.0.bb
+++ b/meta-oe/recipes-devtools/nanopb/nanopb_0.4.0.bb
@@ -27,4 +27,4 @@ RDEPENDS_${PN} += "\
BBCLASSEXTEND = "native nativesdk"
-PNBLACKLIST[nanopb] = "Needs forward porting to use python3"
+PNBLACKLIST[nanopb] ?= "Needs forward porting to use python3"
diff --git a/meta-oe/recipes-extended/socketcan/can-isotp_git.bb
b/meta-oe/recipes-extended/socketcan/can-isotp_git.bb
index e40e1cd26..eca8dfc7b 100644
--- a/meta-oe/recipes-extended/socketcan/can-isotp_git.bb
+++ b/meta-oe/recipes-extended/socketcan/can-isotp_git.bb
@@ -11,4 +11,4 @@ inherit module
EXTRA_OEMAKE += "KERNELDIR=${STAGING_KERNEL_DIR}"
-PNBLACKLIST[can-isotp] = "Kernel module Needs forward porting to kernel 5.2+"
+PNBLACKLIST[can-isotp] ?= "Kernel module Needs forward porting to kernel 5.2+"
diff --git a/meta-oe/recipes-kernel/bpftool/bpftool.bb
b/meta-oe/recipes-kernel/bpftool/bpftool.bb
index 6683eccf2..1758430bc 100644
--- a/meta-oe/recipes-kernel/bpftool/bpftool.bb
+++ b/meta-oe/recipes-kernel/bpftool/bpftool.bb
@@ -32,4 +32,4 @@ python do_package_prepend() {
}
B = "${WORKDIR}/${BPN}-${PV}"
-PNBLACKLIST[bpftool] = "Needs forward porting to kernel 5.2+"
+PNBLACKLIST[bpftool] ?= "Needs forward porting to kernel 5.2+"
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#84589):
https://lists.openembedded.org/g/openembedded-devel/message/84589
Mute This Topic: https://lists.openembedded.org/mt/74464211/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: delete superfluous python-mako.inc
The actual python-mako recipe is in OE, and apparently this .inc file
is historical cruft left over after py2 recipes were moved into their
own layer.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta-python/recipes-devtools/python/python-mako.inc
b/meta-python/recipes-devtools/python/python-mako.inc
deleted file mode 100644
index abcbb8841..0
--- a/meta-python/recipes-devtools/python/python-mako.inc
+++ /dev/null
@@ -1,21 +0,0 @@
-SUMMARY = "A super-fast templating language that borrows the best ideas from
the existing templating languages"
-HOMEPAGE = "http://www.makotemplates.org/;
-SECTION = "devel/python"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=df7e6c7c82990acf0228a55e00d29bc9"
-
-PYPI_PACKAGE = "Mako"
-
-inherit pypi
-
-SRC_URI[md5sum] = "6c3f2da0b74af529a4c4a537d0848bf2"
-SRC_URI[sha256sum] =
"a36919599a9b7dc5d86a7a8988f23a9a3a3d083070023bab23d64f7f1d1e0a4b"
-
-RDEPENDS_${PN} = " \
-${PYTHON_PN}-html \
-${PYTHON_PN}-netclient \
-${PYTHON_PN}-shell \
-${PYTHON_PN}-threading \
-"
-
-BBCLASSEXTEND = "native nativesdk"
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#84399):
https://lists.openembedded.org/g/openembedded-devel/message/84399
Mute This Topic: https://lists.openembedded.org/mt/74253691/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] why is python-mako recipe in OE, while python-mako.inc is in meta-oe?
On Sat, 16 May 2020, Khem Raj wrote: > On Sat, May 16, 2020 at 7:56 AM Robert P. J. Day > wrote: > > > > > > was just perusing some python recipes, trying to learn all the > > details of how python recipes work, and i noticed the following: > > > > ./openembedded-core/meta/recipes-devtools/python/python3-mako_1.1.1.bb > > ./meta-openembedded/meta-python/recipes-devtools/python/python-mako.inc > > > > as in, the recipe for mako is in oe-core, but the include file is in > > meta-oe, the recipe does not include the .inc file, and the git log > > just looks confusing. is there something clever going on here that i > > just don't get? > > > > its cruft left after py2 recipes moved out into its own layer. Send > a patch to remove this inc file for meta-python. roger that. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#84398): https://lists.openembedded.org/g/openembedded-devel/message/84398 Mute This Topic: https://lists.openembedded.org/mt/74250266/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] why is python-mako recipe in OE, while python-mako.inc is in meta-oe?
was just perusing some python recipes, trying to learn all the details of how python recipes work, and i noticed the following: ./openembedded-core/meta/recipes-devtools/python/python3-mako_1.1.1.bb ./meta-openembedded/meta-python/recipes-devtools/python/python-mako.inc as in, the recipe for mako is in oe-core, but the include file is in meta-oe, the recipe does not include the .inc file, and the git log just looks confusing. is there something clever going on here that i just don't get? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#84393): https://lists.openembedded.org/g/openembedded-devel/message/84393 Mute This Topic: https://lists.openembedded.org/mt/74250266/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] proper way to report(?) conflicting files being installed?
On Thu, 19 Mar 2020, Ross Burton wrote: > On 19/03/2020 17:32, Adrian Bunk wrote: > >>this does seem backwards ... if both gnome-common and > >> autoconf-archive currently try to install those two m4-related files, > >> doing the above pretty much *assures* an installation conflict, > >> ... > > > > No, --with-autoconf-archive makes gnome-common not install the > > conflicting files. > > I should point out that gnome-common is dead upstream and mostly > unused now, so if you find a recipe using it do check that it is > actually needed. in fact, just earlier this aft, i sent the short note, "um ... what are you doing that needs that gnome-common thing?" i await the reply. rday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] proper way to report(?) conflicting files being installed?
On Thu, 19 Mar 2020, Adrian Bunk wrote:
> On Thu, Mar 19, 2020 at 01:09:13PM -0400, Robert P. J. Day wrote:
> > On Thu, 19 Mar 2020, Adrian Bunk wrote:
> >
> > > On Thu, Mar 19, 2020 at 09:22:54AM -0400, Robert P. J. Day wrote:
> > > >...
> > > > +# ax_code_coverage.m4 and ax_check_enable_debug.m4 are in gnome-common
> > > > only
> > > > +# because older versions of autoconf-archive didn't have them yet. Now
> > > > they
> > > > +# are in autoconf-archive from OE-core. We depend on that below to
> > > > ensure
> > > > +# that recipes which only depend on gnome-common still get them.
> > > > +do_install_append () {
> > > > +rm -f ${D}${datadir}/aclocal/ax_code_coverage.m4
> > > > +rm -f ${D}${datadir}/aclocal/ax_check_enable_debug.m4
> > > > +}
> > > > +RDEPENDS_${PN} += "autoconf-archive"
> > > > +DEPENDS_append_class-native = " autoconf-archive-native"
> > > > +
> > > >
> > > > it *appears* that solved the problem, which raises the question --
> > > > should this patch be applied to the current gnome-common recipe? that
> > > > patchwork entry dates back to 2017 ... should it have been applied at
> > > > some point?
> > >
> > > The currently implemented solution is:
> > > # Default to enable autoconf-archive to avoid conflicts
> > > PACKAGECONFIG ??= "autoconf-archive"
> > > PACKAGECONFIG[autoconf-archive] = "--with-autoconf-archive,
> > > --without-autoconf-archive, autoconf-archive"
> > >
> > > It is not clear to me why this gives the user to disable it
> > > instead of unconditionally enabling it.
> >
> > this does seem backwards ... if both gnome-common and
> > autoconf-archive currently try to install those two m4-related files,
> > doing the above pretty much *assures* an installation conflict,
> >...
>
> No, --with-autoconf-archive makes gnome-common not install the
> conflicting files.
ah, right, i was just reading (and thinking) backwards.
rday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] proper way to report(?) conflicting files being installed?
On Thu, 19 Mar 2020, Adrian Bunk wrote:
> On Thu, Mar 19, 2020 at 09:22:54AM -0400, Robert P. J. Day wrote:
> >...
> > +# ax_code_coverage.m4 and ax_check_enable_debug.m4 are in gnome-common only
> > +# because older versions of autoconf-archive didn't have them yet. Now they
> > +# are in autoconf-archive from OE-core. We depend on that below to ensure
> > +# that recipes which only depend on gnome-common still get them.
> > +do_install_append () {
> > +rm -f ${D}${datadir}/aclocal/ax_code_coverage.m4
> > +rm -f ${D}${datadir}/aclocal/ax_check_enable_debug.m4
> > +}
> > +RDEPENDS_${PN} += "autoconf-archive"
> > +DEPENDS_append_class-native = " autoconf-archive-native"
> > +
> >
> > it *appears* that solved the problem, which raises the question --
> > should this patch be applied to the current gnome-common recipe? that
> > patchwork entry dates back to 2017 ... should it have been applied at
> > some point?
>
> The currently implemented solution is:
> # Default to enable autoconf-archive to avoid conflicts
> PACKAGECONFIG ??= "autoconf-archive"
> PACKAGECONFIG[autoconf-archive] = "--with-autoconf-archive,
> --without-autoconf-archive, autoconf-archive"
>
> It is not clear to me why this gives the user to disable it
> instead of unconditionally enabling it.
this does seem backwards ... if both gnome-common and
autoconf-archive currently try to install those two m4-related files,
doing the above pretty much *assures* an installation conflict, unless
you apply the patch i linked to earlier at:
https://patchwork.openembedded.org/patch/142467/
where (as i read it) the gnome-common patch uninstalls them, but then
drags in autoconf-archive just to make sure they're installed. so what
*should* this look like?
rday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] proper way to report(?) conflicting files being installed?
On Thu, 19 Mar 2020, Adrian Bunk wrote:
> On Thu, Mar 19, 2020 at 09:22:54AM -0400, Robert P. J. Day wrote:
> >...
> > +# ax_code_coverage.m4 and ax_check_enable_debug.m4 are in gnome-common only
> > +# because older versions of autoconf-archive didn't have them yet. Now they
> > +# are in autoconf-archive from OE-core. We depend on that below to ensure
> > +# that recipes which only depend on gnome-common still get them.
> > +do_install_append () {
> > +rm -f ${D}${datadir}/aclocal/ax_code_coverage.m4
> > +rm -f ${D}${datadir}/aclocal/ax_check_enable_debug.m4
> > +}
> > +RDEPENDS_${PN} += "autoconf-archive"
> > +DEPENDS_append_class-native = " autoconf-archive-native"
> > +
> >
> > it *appears* that solved the problem, which raises the question --
> > should this patch be applied to the current gnome-common recipe? that
> > patchwork entry dates back to 2017 ... should it have been applied at
> > some point?
>
> The currently implemented solution is:
> # Default to enable autoconf-archive to avoid conflicts
> PACKAGECONFIG ??= "autoconf-archive"
> PACKAGECONFIG[autoconf-archive] = "--with-autoconf-archive,
> --without-autoconf-archive, autoconf-archive"
>
> It is not clear to me why this gives the user to disable it
> instead of unconditionally enabling it.
i was a bit confused by that as well, but i figured i just didn't
read it carefully enough.
rday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] proper way to report(?) conflicting files being installed?
long story short, colleague was adding packages to a build and ran
into error wherein both of:
* autoconf-archive
* gnome-common
were trying to install a couple identical m4-related files. some
quick googling produced this:
https://patchwork.openembedded.org/patch/142467/
with the self-evident solution being applied to gnome-common to
"uninstall" the two conflicting files:
--- a/meta-oe/recipes-gnome/gnome-common/gnome-common_3.18.0.bb
+++ b/meta-oe/recipes-gnome/gnome-common/gnome-common_3.18.0.bb
@@ -17,4 +17,15 @@ DEPENDS = ""
FILES_${PN} += "${datadir}/aclocal"
FILES_${PN}-dev = ""
+# ax_code_coverage.m4 and ax_check_enable_debug.m4 are in gnome-common only
+# because older versions of autoconf-archive didn't have them yet. Now they
+# are in autoconf-archive from OE-core. We depend on that below to ensure
+# that recipes which only depend on gnome-common still get them.
+do_install_append () {
+rm -f ${D}${datadir}/aclocal/ax_code_coverage.m4
+rm -f ${D}${datadir}/aclocal/ax_check_enable_debug.m4
+}
+RDEPENDS_${PN} += "autoconf-archive"
+DEPENDS_append_class-native = " autoconf-archive-native"
+
it *appears* that solved the problem, which raises the question --
should this patch be applied to the current gnome-common recipe? that
patchwork entry dates back to 2017 ... should it have been applied at
some point?
rday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] indent: delete meaningless line referring to "/usr/doc"
Remove what appears to be historical line referencing HTML docs under
/usr/doc -- building indent generates no such file.
Signed-off-by: Robert P. J. Day
---
diff --git a/meta-oe/recipes-extended/indent/indent_2.2.12.bb
b/meta-oe/recipes-extended/indent/indent_2.2.12.bb
index 0f4f4c220..90ba8a2e6 100644
--- a/meta-oe/recipes-extended/indent/indent_2.2.12.bb
+++ b/meta-oe/recipes-extended/indent/indent_2.2.12.bb
@@ -24,6 +24,4 @@ inherit autotools gettext texinfo
CFLAGS_append_class-native = " -Wno-error=unused-value"
-FILES_${PN}-doc += "/usr/doc/indent/indent.html"
-
BBCLASSEXTEND = "native"
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] should indent recipe use "${prefix}" instead of "/usr"?
On Wed, 18 Mar 2020, Ross Burton wrote:
> On 18/03/2020 11:00, Robert P. J. Day wrote:
> >never scared to look silly, but i just did a sample build (randomly
> > chose qemuarm64 MACHINE), added:
> >
> >IMAGE_FEATURES += "doc-pkgs"
> >RM_WORK_EXCLUDE = "indent"
> >
> > to local.conf, then ran:
> >
> >$ bitbake indent
> >
> > to look at everything that was generated as part of the "indent" build
> > and how it was packaged, to understand what that:
>
> Much easier way:
>
> $ oe-pkgdata-util list-pkg-files -p indent
>
> >FILES_${PN}-doc += "/usr/doc/indent/indent.html"
> >
> > line is doing in indent_2.2.12.bb, and maybe i'm misreading what was
> > produced, but the only documentation content produced and bundled
> > into the indent-doc rpm package was:
> >
> >$ rpm -qpl indent-doc-2.2.12-r0.aarch64.rpm
> >/usr
> >/usr/share
> >/usr/share/man
> >/usr/share/man/man1
> >/usr/share/man/man1/indent.1
> >$
> >
> > so i'm confused as to that line's purpose ... thoughts?
>
> Historical, maybe. If that line doesn't serve any purpose, delete
> it.
will do ... just nervous when something *looks* too obvious. thanks
for the guidance.
rday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] should indent recipe use "${prefix}" instead of "/usr"?
On Tue, 17 Mar 2020, Ross Burton wrote:
> > just to be clear, this depends on where the indent software
> > actually installs the documentation, yes? i'll have to check when
> > i get home as to were that stuff is actually placed. for all i
> > know, it *could* be under /usr/doc.
>
> Yes.
>
> That FILES suggests that the makefile is installing to /usr/doc/ and
> needs to be told somehow to use $docdir.
never scared to look silly, but i just did a sample build (randomly
chose qemuarm64 MACHINE), added:
IMAGE_FEATURES += "doc-pkgs"
RM_WORK_EXCLUDE = "indent"
to local.conf, then ran:
$ bitbake indent
to look at everything that was generated as part of the "indent" build
and how it was packaged, to understand what that:
FILES_${PN}-doc += "/usr/doc/indent/indent.html"
line is doing in indent_2.2.12.bb, and maybe i'm misreading what was
produced, but the only documentation content produced and bundled
into the indent-doc rpm package was:
$ rpm -qpl indent-doc-2.2.12-r0.aarch64.rpm
/usr
/usr/share
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/indent.1
$
so i'm confused as to that line's purpose ... thoughts?
rday
p.s. it's not like i'm obsessed with the indent package ... i'm more
interested in knowing whether i'm examining this the right way in case
it ever happens again.
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] should indent recipe use "${prefix}" instead of "/usr"?
On Tue, 17 Mar 2020, Ross Burton wrote:
> On 17/03/2020 17:22, Robert P. J. Day wrote:
> >just noticed that ./meta-oe/recipes-extended/indent/indent_2.2.12.bb
> > on master branch contains the line:
> >
> >FILES_${PN}-doc += "/usr/doc/indent/indent.html"
> >
> > should that not properly read:
> >
> >FILES_${PN}-doc += "${prefix}/doc/indent/indent.html"
> >
> > or am i misreading something?
>
> Recipes should never use /usr directly unless they're relocating something
> from e.g. ${D}/usr/lib to ${D}${libdir}.
>
> The recipe should be telling the Makefiles to install into ${docdir}
> (typically, /usr/share/doc).
just to be clear, this depends on where the indent software actually
installs the documentation, yes? i'll have to check when i get home as
to were that stuff is actually placed. for all i know, it *could* be
under /usr/doc.
rday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] should indent recipe use "${prefix}" instead of "/usr"?
On Tue, 17 Mar 2020, Ross Burton wrote:
> On 17/03/2020 17:22, Robert P. J. Day wrote:
> >just noticed that ./meta-oe/recipes-extended/indent/indent_2.2.12.bb
> > on master branch contains the line:
> >
> >FILES_${PN}-doc += "/usr/doc/indent/indent.html"
> >
> > should that not properly read:
> >
> >FILES_${PN}-doc += "${prefix}/doc/indent/indent.html"
> >
> > or am i misreading something?
>
> Recipes should never use /usr directly unless they're relocating
> something from e.g. ${D}/usr/lib to ${D}${libdir}.
>
> The recipe should be telling the Makefiles to install into ${docdir}
> (typically, /usr/share/doc).
ah, of course ... i can submit a patch for that shortly.
rday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] should indent recipe use "${prefix}" instead of "/usr"?
just noticed that ./meta-oe/recipes-extended/indent/indent_2.2.12.bb
on master branch contains the line:
FILES_${PN}-doc += "/usr/doc/indent/indent.html"
should that not properly read:
FILES_${PN}-doc += "${prefix}/doc/indent/indent.html"
or am i misreading something?
rday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] is there a reason meta-openembedded/meta contains a lonely libgpiod.bb recipe?
On Thu, 25 May 2017, Belisko Marek wrote: > On Thu, May 25, 2017 at 9:10 PM, Robert P. J. Day <rpj...@crashcourse.ca> > wrote: > > > > is there some rationale for libgpiod.bb to be the lone recipe > > under meta-openembedded/meta? would that recipe not fit into some > > other layer? > I posted few days ago recipe for libgpiod. Please look at: > http://lists.openembedded.org/pipermail/openembedded-devel/2017-May/112810.html but that doesn't really answer the question as to why that recipe went into meta-openembedded/meta and not meta-openembedded/meta-oe. even the subject refers to "meta-oe", so why was that recipe placed in a directory named "meta"? was that perhaps a typo? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] is there a reason meta-openembedded/meta contains a lonely libgpiod.bb recipe?
is there some rationale for libgpiod.bb to be the lone recipe under meta-openembedded/meta? would that recipe not fit into some other layer? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH][meta-oe] polkit-group-rule.inc: Fix comment typo "polkid" -> "polkitd"
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca> --- diff --git a/meta-oe/recipes-extended/polkit/polkit-group-rule.inc b/meta-oe/recipes-extended/polkit/polkit-group-rule.inc index b727d00..40e4005 100644 --- a/meta-oe/recipes-extended/polkit/polkit-group-rule.inc +++ b/meta-oe/recipes-extended/polkit/polkit-group-rule.inc @@ -1,4 +1,4 @@ -# polkit must prepare polkid group +# polkit must prepare polkitd group DEPENDS += "polkit" inherit useradd rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Yes, good enough for me to include the PNBLACKLIST removal in next bitbake > world run. thanks > > On Mon, Mar 20, 2017 at 4:27 PM, Robert P. J. Day <rpj...@crashcourse.ca> > wrote: > On Mon, 20 Mar 2017, Martin Jansa wrote: > > > Without "_pn-binutils". > > so i rebuilt a core-image-minimal (for mpc8315e-rdb, don't ask) > after setting: > > DISTRO_FEATURES_append = " ld-is-gold" > > then rebuilt accel-ppp and it succeeded. is that considered an > adequate test? i'll let you throw in that patch since you probably have a better idea of what you want the commit msg to say. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Without "_pn-binutils". so i rebuilt a core-image-minimal (for mpc8315e-rdb, don't ask) after setting: DISTRO_FEATURES_append = " ld-is-gold" then rebuilt accel-ppp and it succeeded. is that considered an adequate test? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Without "_pn-binutils". > > On Mon, Mar 20, 2017 at 3:05 PM, Robert P. J. Day <rpj...@crashcourse.ca> > wrote: > On Mon, 20 Mar 2017, Martin Jansa wrote: > > > Yes, sending a patch is OK, but you might want to test it with gold > > enabled, most linking errors are usually reproducible only when gold > > is enabled. > > just to be clear, need i add just this line to my local.conf? > > DISTRO_FEATURES_append_pn-binutils = " ld-is-gold" ah, right, i forgot that it also affects a number of other recipes. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Yes, sending a patch is OK, but you might want to test it with gold > enabled, most linking errors are usually reproducible only when gold > is enabled. just to be clear, need i add just this line to my local.conf? DISTRO_FEATURES_append_pn-binutils = " ld-is-gold" rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
On Mon, 20 Mar 2017, Martin Jansa wrote: > Yes, sending a patch is OK, but you might want to test it with gold > enabled, most linking errors are usually reproducible only when gold > is enabled. okeley dokeley. rday -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] blacklisted accel-ppp (under binutils-2.27) seems to compile under binutils-2.28
current meta-openembedded recipe for accel-ppp reads: PNBLACKLIST[accel-ppp] ?= "BROKEN: fails to build with new binutils-2.27" with error logged here: http://errors.yoctoproject.org/Errors/Details/81003/ just tried under latest poky pull containing binutils-2.28 and it seems to compile just fine. should it be unblacklisted? rday -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] does specifying "--with-mpm=prefork" for apache2 require ugly manual hacking?
just ran across the following situation in that an OE build
(actually, wind river linux, but that should make no difference) has a
bbappend file, "apache2_2.4.16.bbappend", that appears to be going to
a great deal of trouble to simply specify "--with-mpm=prefork":
EXTRA_OECONF += " --with-mpm=prefork "
do_install_append() {
# Make a backup of the original httpd.conf file
cp ${D}/${sysconfdir}/${BPN}/httpd.conf
${D}/${sysconfdir}/${BPN}/httpd.conf.orig
# Remove the two offending lines (to be replaced with the correct ones), as
well as uncommenting the mpm include directive.
sed -r 's_^IncludeOptional\s+/etc/apache2/conf.d/\*.conf__' <
${D}/${sysconfdir}/${BPN}/httpd.conf.orig | sed -r
's_^IncludeOptional\s+/etc/apache2/modules.d/\*.conf__' | sed -r
's_^#Include\s+etc/apache2/extra/httpd-mpm.conf_Include
etc/apache2/extra/httpd-mpm.conf_' | sed -r 's_^Listen 80$_Listen
80\n#Temporary use by minion\nListen 8081_' >
${D}/${sysconfdir}/${BPN}/httpd.conf
# Replacing the two lines removed previously with the correct ones. Loading
the modules first, then configure them.
printf "\nIncludeOptional ${sysconfdir}/${BPN}/modules.d/*.load" >>
${D}/${sysconfdir}/${BPN}/httpd.conf
printf "\nIncludeOptional ${sysconfdir}/${BPN}/conf.d/*.conf" >>
${D}/${sysconfdir}/${BPN}/httpd.conf
}
i'm unclear on what is happening above, but it seems that asking for
a simple configuration like that should be available with something as
basic as adding an option, or selecting PACKAGECONFIG.
am i missing something? is all of the above really necessary to do
something that looks fairly straightforward?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] PYPI_PACKAGE for (blacklisted) python[3]-ndg-httpsclient is incorrect
On Thu, 2 Mar 2017, Derek Straka wrote: > The URL https://pypi.python.org/pypi/ndg_httpsclient/0.4.2 gets a 301 and > redirects to https://pypi.python.org/pypi/ndg-httpsclient/0.4.2. FWIW, the > recipe hasn't been blacklisted in master for a while. ah, i never bothered going down that extra directory level to notice the redirection. > On Thu, Mar 2, 2017 at 8:26 AM, Robert P. J. Day <rpj...@crashcourse.ca> > wrote: > > > > > in my wanderings, i noticed the following line in the include file > > recipes-devtools/python/python-ndg-httpsclient.inc: > > > > PYPI_PACKAGE = "ndg_httpsclient" > > > > however, that appears to be incorrect -- the correct name over at > > pypi.python.org is, in fact, "ndg-httpsclient" (making the assignment > > to PYPI_PACKAGE superfluous, yes?) > > > > https://pypi.python.org/pypi/ndg-httpsclient/0.4.2 > > > > one would think that would cause problems; however, the python3 > > version of the recipe is blacklisted for the following reason: > > > > http://errors.yoctoproject.org/Errors/Details/130615/ > > > > so one would never get the opportunity to see the build error. still, > > wouldn't that cause the python2 version of the recipe to fail? that > > one isn't blacklisted. > > > > thoughts? > > > > rday > > > > -- > > > > > > Robert P. J. Day Ottawa, Ontario, CANADA > > http://crashcourse.ca > > > > Twitter: http://twitter.com/rpjday > > LinkedIn: http://ca.linkedin.com/in/rpjday > > > > > > -- > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > > > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] PYPI_PACKAGE for (blacklisted) python[3]-ndg-httpsclient is incorrect
in my wanderings, i noticed the following line in the include file recipes-devtools/python/python-ndg-httpsclient.inc: PYPI_PACKAGE = "ndg_httpsclient" however, that appears to be incorrect -- the correct name over at pypi.python.org is, in fact, "ndg-httpsclient" (making the assignment to PYPI_PACKAGE superfluous, yes?) https://pypi.python.org/pypi/ndg-httpsclient/0.4.2 one would think that would cause problems; however, the python3 version of the recipe is blacklisted for the following reason: http://errors.yoctoproject.org/Errors/Details/130615/ so one would never get the opportunity to see the build error. still, wouldn't that cause the python2 version of the recipe to fail? that one isn't blacklisted. thoughts? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] meta-python: Remove superfluous "PYPI_PACKAGE" assignments
Given calculation of PYPI_PACKAGE value from recipe file name, a
number of Python recipe files unnecessarily set this value, so delete
these superfluous lines.
In addition, the act of editing added a missing EOL at the end of one
of the files.
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
i dislike extraneous content, so a quick cleaning of some
meta-python recipes where PYPI_PACKAGE will already have the correct
value as calculated by pypi.bbclass.
diff --git
a/meta-python/recipes-connectivity/python-pyconnman/python-pyconnman_0.1.0.bb
b/meta-python/recipes-connectivity/python-pyconnman/python-pyconnman_0.1.0.bb
index 6eeab7e..5cef7d9 100644
---
a/meta-python/recipes-connectivity/python-pyconnman/python-pyconnman_0.1.0.bb
+++
b/meta-python/recipes-connectivity/python-pyconnman/python-pyconnman_0.1.0.bb
@@ -7,8 +7,6 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
SRC_URI[md5sum] = "b7fa82034b1c0e1fb1b518ffe3bb4fc0"
SRC_URI[sha256sum] =
"46c64c0692063fd0c9fb0216d49f7884bec9fa9760d8473db4b1e2f8162fab4a"
-PYPI_PACKAGE = "pyconnman"
-
inherit pypi setuptools
-RDEPENDS_${PN} = "python-dbus python-pprint"
\ No newline at end of file
+RDEPENDS_${PN} = "python-dbus python-pprint"
diff --git a/meta-python/recipes-devtools/python/python-pycrypto.inc
b/meta-python/recipes-devtools/python/python-pycrypto.inc
index 42e31a9..fb2c17d 100644
--- a/meta-python/recipes-devtools/python/python-pycrypto.inc
+++ b/meta-python/recipes-devtools/python/python-pycrypto.inc
@@ -6,7 +6,6 @@ LIC_FILES_CHKSUM =
"file://COPYRIGHT;md5=35f354d199e8cb7667b059a23578e63d"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
DEPENDS += " gmp"
-PYPI_PACKAGE = "pycrypto"
inherit pypi autotools-brokensep
diff --git a/meta-python/recipes-devtools/python/python-pyinotify.inc
b/meta-python/recipes-devtools/python/python-pyinotify.inc
index a9edb2c..0168f1a 100644
--- a/meta-python/recipes-devtools/python/python-pyinotify.inc
+++ b/meta-python/recipes-devtools/python/python-pyinotify.inc
@@ -7,5 +7,4 @@ RDEPENDS_${PN} += "python-threading python-io python-subprocess
python-misc pyth
SRC_URI[md5sum] = "8e580fa1ff3971f94a6f81672b76c406"
SRC_URI[sha256sum] =
"9c998a5d7606ca835065cdabc013ae6c66eb9ea76a00a1e3bc6e0cfe2b4f71f4"
-PYPI_PACKAGE = "pyinotify"
inherit pypi
diff --git
a/meta-python/recipes-devtools/python/python-singledispatch_3.4.0.3.bb
b/meta-python/recipes-devtools/python/python-singledispatch_3.4.0.3.bb
index 87f46e5..44c9505 100644
--- a/meta-python/recipes-devtools/python/python-singledispatch_3.4.0.3.bb
+++ b/meta-python/recipes-devtools/python/python-singledispatch_3.4.0.3.bb
@@ -9,5 +9,4 @@ LIC_FILES_CHKSUM =
"file://README.rst;md5=ee3cd67264adc7eb07981f3644dc17dc"
SRC_URI[md5sum] = "af2fc6a3d6cc5a02d0bf54d909785fcb"
SRC_URI[sha256sum] =
"5b06af87df13818d14f08a028e42f566640aef80805c3b50c5056b086e3c2b9c"
-PYPI_PACKAGE = "singledispatch"
inherit pypi setuptools
diff --git a/meta-python/recipes-devtools/python/python-ujson_1.35.bb
b/meta-python/recipes-devtools/python/python-ujson_1.35.bb
index 4ef3d18..238dc92 100644
--- a/meta-python/recipes-devtools/python/python-ujson_1.35.bb
+++ b/meta-python/recipes-devtools/python/python-ujson_1.35.bb
@@ -7,7 +7,6 @@ LIC_FILES_CHKSUM =
"file://PKG-INFO;startline=8;endline=9;md5=4f369b3c3c290b4aed
SRC_URI[md5sum] = "42f77b0cce686dfa4da2e68480b1dd24"
SRC_URI[sha256sum] =
"f66073e5506e91d204ab0c614a148d5aa938bdbf104751be66f8ad7a222f5f86"
-PYPI_PACKAGE = "ujson"
inherit pypi setuptools
RDEPENDS_${PN} += "\
diff --git a/meta-python/recipes-devtools/python/python-yappi_0.98.bb
b/meta-python/recipes-devtools/python/python-yappi_0.98.bb
index 02ec7d0..51308c8 100644
--- a/meta-python/recipes-devtools/python/python-yappi_0.98.bb
+++ b/meta-python/recipes-devtools/python/python-yappi_0.98.bb
@@ -7,7 +7,6 @@ LIC_FILES_CHKSUM =
"file://PKG-INFO;md5=6b131c3041637f6a5175a43112dde05c"
SRC_URI[md5sum] = "dc56240575c99938a924eaeb7c0d8beb"
SRC_URI[sha256sum] =
"5f657129e1b9b952379ffbc009357d0dcdb58c50f3bfe88ffbb992e4b27b263c"
-PYPI_PACKAGE = "yappi"
inherit pypi setuptools
RDEPENDS_${PN} += "\
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] "Can't install krb5-dev-1.13.6-r0@ppc7400: no package provides krb5 = 1.13.6-r0"
On Mon, 20 Feb 2017, Martin Jansa wrote: > On Mon, Feb 20, 2017 at 07:10:56AM -0500, Robert P. J. Day wrote: > > a simple solution was to add the line: > > > > ALLOW_EMPTY_krb5 = "1" > > > > to my local.conf. is that really the proper fix? > > Removing the runtime dependency on krb5 from krb5-dev is usually > preferred, search ML it was discussed few times. ok, wouldn't be doing my job if i didn't ask ... why isn't this change just added to the recipe file? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] "Can't install krb5-dev-1.13.6-r0@ppc7400: no package provides krb5 = 1.13.6-r0"
On Mon, 20 Feb 2017, Robert P. J. Day wrote: > ok, i hope this issue is not trivially simple. i'm building > core-image-minimal for qemuppc, and tossing in a bunch of other > recipes, everything builds until: > > / start / > ERROR: core-image-minimal-1.0-r0 do_rootfs: Unable to install > packages. Command > '/home/rpjday/oe/builds/qemuppc_oe_small/tmp/work/qemuppc-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/smart > --log-level=info > --data-dir=/home/rpjday/oe/builds/qemuppc_oe_small/tmp/work/qemuppc-poky-linux/core-image-minimal/1.0-r0/rootfs/var/lib/smart > install -y packagegroup-core-boot@qemuppc rpm@ppc7400 > packagegroup-wrl-regular-recipes@all smartpm@ppc7400 > run-postinsts@all' returned 1: > Loading cache... > Updating cache... > [100%] > > Computing transaction...error: Can't install > krb5-dev-1.13.6-r0@ppc7400: no package provides krb5 = 1.13.6-r0 > > > ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs > ERROR: Logfile of failure stored in: > /home/rpjday/oe/builds/qemuppc_oe_small/tmp/work/qemuppc-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.22573 > ERROR: Task > (/home/rpjday/oe/dist/layers/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) > failed with exit code '1' > / end / a simple solution was to add the line: ALLOW_EMPTY_krb5 = "1" to my local.conf. is that really the proper fix? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] "Can't install krb5-dev-1.13.6-r0@ppc7400: no package provides krb5 = 1.13.6-r0"
ok, i hope this issue is not trivially simple. i'm building
core-image-minimal for qemuppc, and tossing in a bunch of other
recipes, everything builds until:
/ start /
ERROR: core-image-minimal-1.0-r0 do_rootfs: Unable to install
packages. Command
'/home/rpjday/oe/builds/qemuppc_oe_small/tmp/work/qemuppc-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/smart
--log-level=info
--data-dir=/home/rpjday/oe/builds/qemuppc_oe_small/tmp/work/qemuppc-poky-linux/core-image-minimal/1.0-r0/rootfs/var/lib/smart
install -y packagegroup-core-boot@qemuppc rpm@ppc7400
packagegroup-wrl-regular-recipes@all smartpm@ppc7400
run-postinsts@all' returned 1:
Loading cache...
Updating cache...
[100%]
Computing transaction...error: Can't install
krb5-dev-1.13.6-r0@ppc7400: no package provides krb5 = 1.13.6-r0
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/rpjday/oe/builds/qemuppc_oe_small/tmp/work/qemuppc-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.22573
ERROR: Task
(/home/rpjday/oe/dist/layers/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
failed with exit code '1'
/ end /
a quick check shows the following rpms:
$ find tmp/deploy/rpm/ -name "*krb*"
tmp/deploy/rpm/qemuppc/kernel-module-rpcsec-gss-krb5-4.8.18-yocto-standard-4.8.18+git0+ea8a679c95_d2c3ea488f-r0.qemuppc.rpm
tmp/deploy/rpm/ppc7400/libgssapi-krb5-2-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-kdc-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-doc-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-dev-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-admin-server-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/libkrb5samba-samba4-4.4.5-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-gss-samples-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/libkrb5-3-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-locale-en-us-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-otp-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/libndr-krb5pac0-4.4.5-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-user-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/libauthkrb5-samba4-4.4.5-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-dbg-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-kpropd-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/libkrb5support0-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-pkinit-1.13.6-r0.ppc7400.rpm
tmp/deploy/rpm/ppc7400/krb5-k5tls-1.13.6-r0.ppc7400.rpm
$
and, sure enough, there's no krb5 rpm. why not? if i check the recipe,
i see:
PACKAGES =+ "${PN}-admin-server \
${PN}-gss-samples \
${PN}-k5tls \
${PN}-kdc \
${PN}-kdc-ldap \
${PN}-kpropd \
${PN}-otp \
${PN}-pkinit \
${PN}-user \
libgssapi-krb5 \
libgssrpc \
libk5crypto \
libkadm5clnt-mit \
libkadm5srv-mit \
libkdb5 \
libkrad \
libkrb5 \
libkrb5support \
libverto"
FILES_${PN} = ""
so ... while the recipe introduces a pile of new output packages, it
empties the base "krb5" package. does that mean it needs to be
identified as allowing empty just to exist?
i've built a lot of qemu/core-image-minimal images, and this is the
first time i've seen this krb5-related issue.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] are you allowed to have an underscore in a recipes directory?
i just noticed this in meta-oe/recipes-support: $ ls ... lm_sensors ... is there any issue with that directory name containing an underscore? i know that has special meaning in a recipe file name, but i've never noticed an underscore being used as above. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] SUMMARY/DESCRIPTION for "libmodule-build-perl_0.31.bb" refers to "tiny" version
just noticed that in meta-openembedded/meta-perl layer, there are two recipes for perl module building: * libmodule-build-perl_0.31.bb * libmodule-build-tiny-perl_0.036.bb but the SUMMARY and DESCRIPTION for the first (non-tiny) version clearly was copied and pasted from the second (tiny) version: SUMMARY = "Module::Build::Tiny - A tiny replacement for Module::Build" DESCRIPTION = "Many Perl distributions use a Build.PL file instead of a \ Makefile.PL file to drive distribution configuration, build, test and \ installation. Traditionally, Build.PL uses Module::Build as the underlying \ build system. This module provides a simple, lightweight, drop-in replacement. \ Whereas Module::Build has over 6,700 lines of code; this module has less than \ 120, yet supports the features needed by most distributions." i'm going to let someone higher up the food chain deal with that. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] DEPENDS += "module-build-perl-native" versus "libmodule-build-perl-native"?
i'm sure i asked about this before, but i currently have a hacky workaround in a build because of the mixture of DEPENDS mentioned in the subject line. first, i've pulled down the meta-cpan layer, where you can see the consistency of recipes that depend on a native build of the perl build module: $ grep -rh "DEPENDS.*module-build-perl-native" * DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" DEPENDS += "module-build-perl-native" $ and, predictably, the meta-cpan layer provides that very recipe: module-build-perl_0.4216.bb OTOH, the meta-openembedded/meta-perl layer takes a slightly different approach: $ grep -r "DEPENDS.*module-build-perl-native" * recipes-perl/libhtml/libhtml-tree-perl_5.03.bb:DEPENDS += "libmodule-build-perl-native \ $ and provides the equivalent(?) recipe: libmodule-build-perl_0.31.bb the last time i checked, trying to mix those two layers verbatim generated a build error, since i include recipes which combine the two dependencies, and try to install the identical content at the same location. clearly(?), i should restrict the build-time dependencies to one or the other of those recipes for the native perl build module. is this even considered an issue that should be resolved? it seems that if layers are catalogued at the https://layers.openembedded.org/, they should be compatible and play nicely together. in this case, it's just a naming convention incompatibility -- as i recall, the OE naming convention for perl modules is "lib-perl", while the meta-cpan does something different; hence, the problem. thoughts? should some names be cleaned up to prevent this? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] building netdata: "No package 'zlib' found"
i was going to start a new thread for this, then remembered this post i was going to respond to: On Tue, 14 Feb 2017, Jack Mitchell wrote: > On 13/02/17 17:01, Robert P. J. Day wrote: > > > > i'm building a totally stock core-image-minimal for qemuppc with > > latest poky checkout, and when i try to add the existing "netdata" > > recipe to the mix, i get: > > > > | configure: error: Package requirements (zlib) were not met: > > | > > | No package 'zlib' found > > | > > | Consider adjusting the PKG_CONFIG_PATH environment variable if you > > | installed software in a non-standard prefix. > > | > > | Alternatively, you may set the environment variables ZLIB_CFLAGS > > | and ZLIB_LIBS to avoid the need to call pkg-config. > > | See the pkg-config man page for more details. > > > > apart from fixing this, how could this recipe ever have built > > before? i realize the current recipe for netdata is almost a year > > old, but should it still not build? > > Recipe specific sysroots. Zlib is so common that it was probably > already available in the shared sysroot to be compiled against, now > there is no access to the shared sysroot it can't be found and > fails. So this was always a dependency bug but one that was probably > never triggered. a couple questions. a couple days ago, all i did was add the line: DEPENDS = "zlib" to the netdata_git.bb recipe file, and that trivially solved the problem. i just updated my poky checkout, built again, and the build failed since, as i notice from monday, a bunch of recipes (including netdata) have been blacklisted because of (unsurprisingly) failure to build: $ git show b7f480c so what should one do here? for that recipe, i can submit a patch which adds the DEPENDS line and removes the blacklisting. or is there a more wide-sweeping plan to fix recipes that are now missing build-time dependencies based on recipe-specific sysroots? also, if there's no objection, i can submit a patch that adds a recipe for the far more recent netdata-1.5.0. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] building netdata: "No package 'zlib' found"
i'm building a totally stock core-image-minimal for qemuppc with latest poky checkout, and when i try to add the existing "netdata" recipe to the mix, i get: | configure: error: Package requirements (zlib) were not met: | | No package 'zlib' found | | Consider adjusting the PKG_CONFIG_PATH environment variable if you | installed software in a non-standard prefix. | | Alternatively, you may set the environment variables ZLIB_CFLAGS | and ZLIB_LIBS to avoid the need to call pkg-config. | See the pkg-config man page for more details. apart from fixing this, how could this recipe ever have built before? i realize the current recipe for netdata is almost a year old, but should it still not build? rday -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] why is the current version of netdata "1.0.1+git${SRCPV}"?
just noticed recipe file "netdata_git.bb", with the above setting for PV ... apparently, there was a very recent tagging with "v1.5.0", is there any value in upgrading(?) to that newer version? or at least adding a fixed version of the recipe to go with the git version? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] does recipe naming convention allow 'libcgi-perl_4.28.bb:RPROVIDES_${PN} += "perl-module-cgi"'?
(apparently, i am doomed to poke around in OE perl recipes for the
next little while. le *sigh* ...)
curious about the following under meta-openembedded/meta-perl:
$ grep -r RPROVIDES *
recipes-perl/libtest/libtest-harness-perl_3.36.bb:RPROVIDES_${PN} +=
"libapp-prove-perl \
recipes-perl/libio/libio-stringy-perl_2.111.bb:RPROVIDES_${PN} += "
libio-atomicfile-perl \
recipes-perl/libmoo/libmoo-perl_2.02.bb:RPROVIDES_${PN} = "
libmethod-inliner-perl \
recipes-perl/libextutils/libextutils-parsexs-perl_3.24.bb:RPROVIDES_${PN} += "
libextutils-parsexs-constants-perl \
recipes-perl/libencode/libencode-perl_2.83.bb:RPROVIDES_${PN} +=
"libencode-alias-perl \
recipes-perl/libhtml/libhtml-tree-perl_5.03.bb:RPROVIDES_${PN} = "
libhtml-element-perl \
recipes-perl/librole/librole-tiny-perl_2.01.bb:RPROVIDES_${PN} = "
librole-tiny-perl \
recipes-perl/libcgi/libcgi-perl_4.28.bb:RPROVIDES_${PN} += "perl-module-cgi"
$
it's that last line that's odd ... i thought the naming convention
was that the "perl-module-" prefix was reserved for modules generated
by the base build of perl itself, while independent recipes used names
with prefixes of "libxxx--perl" and, therefore, provided, well,
exactly that.
so what's the rationale for the RPROVIDES in that last example?
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] mozjs/unhandled signal 11/64k page patch/__powerpc64__ ???
On Wed, 23 Nov 2016, Khem Raj wrote:
>
> > On Nov 23, 2016, at 2:26 PM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> >
> > On Wed, 23 Nov 2016, Khem Raj wrote:
> >
> >>
> >>> On Nov 23, 2016, at 1:26 PM, Robert P. J. Day <rpj...@crashcourse.ca>
> >>> wrote:
> >>>
> >>> On Wed, 23 Nov 2016, Khem Raj wrote:
> >>>
> >>>> can you reproduce it on version 24 as well ?
> >>>
> >>> not sure what you mean ... this is running on a qemuppc image. i
> >>> haven't tried running this on fedora 24 itself. what exactly do you
> >>> want me to try?
> >>>
> >>
> >> I meant version of mozjs
> >
> > this is version 17.
>
> OK, I think 24 has such issues taken care of. I am not near code
> right now. but it will be good to check if something is already
> fixed there for this
is it just me, or is the SRC_URI in mozjs_17.0.0.bb a bit weird?
SRC_URI = " \
http://ftp.mozilla.org/pub/mozilla.org/js/${BPN}${PV}.tar.gz \
^^^ ???
there's no such directory structure.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] mozjs/unhandled signal 11/64k page patch/__powerpc64__ ???
On Wed, 23 Nov 2016, Khem Raj wrote: > > > On Nov 23, 2016, at 2:26 PM, Robert P. J. Day <rpj...@crashcourse.ca> wrote: > > > > On Wed, 23 Nov 2016, Khem Raj wrote: > > > >> > >>> On Nov 23, 2016, at 1:26 PM, Robert P. J. Day <rpj...@crashcourse.ca> > >>> wrote: > >>> > >>> On Wed, 23 Nov 2016, Khem Raj wrote: > >>> > >>>> can you reproduce it on version 24 as well ? > >>> > >>> not sure what you mean ... this is running on a qemuppc image. i > >>> haven't tried running this on fedora 24 itself. what exactly do you > >>> want me to try? > >>> > >> > >> I meant version of mozjs > > > > this is version 17. > > OK, I think 24 has such issues taken care of. I am not near code > right now. but it will be good to check if something is already > fixed there for this ok, i'll take a look, and if it *is* fixed in 24, is there a reason meta-openembedded/meta-oe still contains only mozjs_17.0.0.bb? would it not make sense to bump that up? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] mozjs/unhandled signal 11/64k page patch/__powerpc64__ ???
On Wed, 23 Nov 2016, Khem Raj wrote: > > > On Nov 23, 2016, at 1:26 PM, Robert P. J. Day <rpj...@crashcourse.ca> wrote: > > > > On Wed, 23 Nov 2016, Khem Raj wrote: > > > >> can you reproduce it on version 24 as well ? > > > > not sure what you mean ... this is running on a qemuppc image. i > > haven't tried running this on fedora 24 itself. what exactly do you > > want me to try? > > > > I meant version of mozjs this is version 17. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] mozjs/unhandled signal 11/64k page patch/__powerpc64__ ???
On Wed, 23 Nov 2016, Khem Raj wrote: > can you reproduce it on version 24 as well ? not sure what you mean ... this is running on a qemuppc image. i haven't tried running this on fedora 24 itself. what exactly do you want me to try? > > On Nov 23, 2016, at 10:34 AM, Robert P. J. Day <rpj...@crashcourse.ca> wrote: > > > > > > i know nothing about this issue, i'm asking on behalf of a colleague > > who has allegedly tracked down a bug in wind river linux, and > > comparing sources, it *appears* the very same thing would happen in > > OE. > > > > the symptom running "poweroff" in a qemuppc session; > > > > ... snip ... > > polkitd[680]: unhandled signal 11 at nip 0fa69198 lr 0fa69174code > > 30001 > > ... snip ... > > > > further investigation shows the very same thing happening with: > > > > # systemctl start httpd > > polkitd[680]: unhandled signal 11 at nip 0fa69198 lr 0fa69174code > > 30001 > > Error getting authority: Error initializing authority: Error calling > > StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached > > (g-io-error-quark, 24) > > Failed to start httpd.service: Connection timed out > > # > > > > to make a long story short, said colleague followed bug reports and > > ended up here: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1289432 > > > > eventually, he got the problem to go away by tweaking the patch > > "0005-aarch64-64k-page.patch" for mozjs with the following adjustment: > > > > @@ -113,7 +113,7 @@ struct Cell > > #if defined(SOLARIS) && (defined(__sparc) || defined(__sparcv9)) > > const size_t PageShift = 13; > > const size_t ArenaShift = PageShift; > > -#elif defined(__powerpc__) > > +#elif defined(__powerpc__) || defined(__aarch64__) > > ^^^ change that to __powerpc64__ > > const size_t PageShift = 16; > > const size_t ArenaShift = 12; > > #else > > > > as my colleague reads it, the original patch above is necessary for > > PPC64, but *breaks* PPC32. i haven't followed the logic, but does any > > of this make sense? by making that change, the error went away and > > things work fine. > > > > thoughts? -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] mozjs/unhandled signal 11/64k page patch/__powerpc64__ ???
i know nothing about this issue, i'm asking on behalf of a colleague who has allegedly tracked down a bug in wind river linux, and comparing sources, it *appears* the very same thing would happen in OE. the symptom running "poweroff" in a qemuppc session; ... snip ... polkitd[680]: unhandled signal 11 at nip 0fa69198 lr 0fa69174code 30001 ... snip ... further investigation shows the very same thing happening with: # systemctl start httpd polkitd[680]: unhandled signal 11 at nip 0fa69198 lr 0fa69174code 30001 Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24) Failed to start httpd.service: Connection timed out # to make a long story short, said colleague followed bug reports and ended up here: https://bugzilla.redhat.com/show_bug.cgi?id=1289432 eventually, he got the problem to go away by tweaking the patch "0005-aarch64-64k-page.patch" for mozjs with the following adjustment: @@ -113,7 +113,7 @@ struct Cell #if defined(SOLARIS) && (defined(__sparc) || defined(__sparcv9)) const size_t PageShift = 13; const size_t ArenaShift = PageShift; -#elif defined(__powerpc__) +#elif defined(__powerpc__) || defined(__aarch64__) ^^^ change that to __powerpc64__ const size_t PageShift = 16; const size_t ArenaShift = 12; #else as my colleague reads it, the original patch above is necessary for PPC64, but *breaks* PPC32. i haven't followed the logic, but does any of this make sense? by making that change, the error went away and things work fine. thoughts? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH][meta-oe][meta-perl] Correct typo, "libtap-parsser-result-bailout-perl"
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
diff --git a/meta-perl/recipes-perl/libtest/libtest-harness-perl_3.36.bb
b/meta-perl/recipes-perl/libtest/libtest-harness-perl_3.36.bb
index 1aed5e0..9899bd6 100644
--- a/meta-perl/recipes-perl/libtest/libtest-harness-perl_3.36.bb
+++ b/meta-perl/recipes-perl/libtest/libtest-harness-perl_3.36.bb
@@ -54,7 +54,7 @@ RPROVIDES_${PN} += "libapp-prove-perl \
libtap-parser-iteratorfactory-perl \
libtap-parser-multiplexer-perl \
libtap-parser-result-perl \
-libtap-parsser-result-bailout-perl \
+libtap-parser-result-bailout-perl \
libtap-parser-result-comment-perl \
libtap-parser-result-plan-perl \
libtap-parser-result-pragma-perl \
--
========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] "libtest-harness-perl_3.36.bb" ... "libtap-parsser-result-bailout-perl:
in meta-perl/recipes-perl/libtest/libtest-harness-perl_3.36.bb, can i assume this line is a typo? ... libtap-parsser-result-bailout-perl \ ^^^ ? if so, will submit patch. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] curious about "superfluous" meta-cpan recipes
On Tue, 15 Nov 2016, Jens Rehsack wrote: > Hi Robert, > > > Am 14.11.2016 um 22:45 schrieb Robert P. J. Day <rpj...@crashcourse.ca>: > > > > > > to follow up on a point i made earlier, it seems that a number of > > recipes in meta-cpan are, these days, unnecessary as they are > > available in the standard OE or meta-oe layers. i took a quick > > look and found the following examples: > > > > meta-cpan OE/meta-oe equivalent type > > > > > > uri-perlliburi-perl oe-core > > encode-locale-perl libencode-locale-perl meta-perl > > io-socket-ssl-perl libio-socket-ssl-perl meta-perl ... snip ... > > so you can see that a number of meta-cpan recipes appear to be > > effectively available in basic OE. does that make them > > unnecessary? is there any reason to have meta-cpan recipes that > > basically reproduce what is already available? (other than version > > numbers, of course.) > > you're slightly too fast... that's what *she* said. :-) but seriously ... > There is a clear reason for that what you identified as superfluous: > reliability. > > Experienced users expected, one can easily add an > liburi-perl_%.bbappend or an uri-perl_%.bbappend containing a > PROVIDES+="...". But noone is enforced to remove such a PROVIDES... > > What drives me to package cpan distributions which are already in > meta-oe? The way they're packaged. meta-cpan containes recipes in a > way as they're meant by CPAN authors, not by Debian or > oe-contributors. is there anywhere a guide for writing perl recipes? i've already noticed the subtle differences in packaging, and someone earlier mentioned to avoid the meta-debian recipes as they have their own standard, and so on. is there a HOWTO for this? thanks muchly. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] WARNING: QA Issue: openjdk-8 rdepends on openjre-8, but it isn't a build dependency? [build-deps]
On Thu, 25 Aug 2016, Maxin B. John wrote: > Hi, > > On Thu, Aug 25, 2016 at 07:58:30AM -0400, Robert P. J. Day wrote: > > > > while i'm getting the following QA warning with wind river linux 8, > > i'm assuming the same would be happening with the standard meta-java > > layer; if not, i apologize for posting to the wrong list. > > > > is this something i should file at YP bugzilla? elsewhere? > > Is this still happening with the latest meta-java master branch ? i'm getting this with the latest RCPL of wind river linux; if you give me a while, i can test with a generic configuration of OE -- it's entirely possible that's not an issue using OE. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] WARNING: QA Issue: openjdk-8 rdepends on openjre-8, but it isn't a build dependency? [build-deps]
while i'm getting the following QA warning with wind river linux 8, i'm assuming the same would be happening with the standard meta-java layer; if not, i apologize for posting to the wrong list. is this something i should file at YP bugzilla? elsewhere? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] is there an ETA for a recipe for mariadb 10.x?
client wants to take advantage of features of mariadb 10.x in an OE build, but i see no official layer for it -- is it coming? or should one just hack up a recipe for it? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] meta-oe: php, given "_append", remove superfluous "+="
On Thu, 18 Aug 2016, Martin Jansa wrote: > Don't resend, it's already in master-next (all 4 squashed into one) and I > would keep the space before \ because we always use space before \ even > when it's not really necessary. that's what i thought, which is why i left it there. good to know, thanks. time to start writing a style guide, methinks. rday -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] meta-oe: php, given "_append", remove superfluous "+="
On Thu, 18 Aug 2016, Khem Raj wrote:
>
> > On Aug 18, 2016, at 2:37 AM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> >
> >
> > Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
> >
> > ---
> >
> > again, not compile-tested since it seems obvious
> >
> > diff --git a/meta-oe/recipes-devtools/php/php.inc
> > b/meta-oe/recipes-devtools/php/php.inc
> > index ee7a143..23de2b1 100644
> > --- a/meta-oe/recipes-devtools/php/php.inc
> > +++ b/meta-oe/recipes-devtools/php/php.inc
> > @@ -15,7 +15,7 @@ SRC_URI = "http://php.net/distributions/php-${PV}.tar.bz2
> > \
> >file://0001-acinclude-use-pkgconfig-for-libxml2-config.patch \
> > "
> >
> > -SRC_URI_append_class-target += " \
> > +SRC_URI_append_class-target = “ \
>
> nitpick: You do not need a space here since its already added after newline
>
> > file://iconv.patch \
> > file://imap-fix-autofoo.patch \
> > file://pear-makefile.patch \
> >
ah, quite so.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] meta-oe: php, given "_append", remove superfluous "+="
On Thu, 18 Aug 2016, Khem Raj wrote:
>
> > On Aug 18, 2016, at 2:37 AM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> >
> >
> > Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
> >
> > ---
> >
> > again, not compile-tested since it seems obvious
> >
> > diff --git a/meta-oe/recipes-devtools/php/php.inc
> > b/meta-oe/recipes-devtools/php/php.inc
> > index ee7a143..23de2b1 100644
> > --- a/meta-oe/recipes-devtools/php/php.inc
> > +++ b/meta-oe/recipes-devtools/php/php.inc
> > @@ -15,7 +15,7 @@ SRC_URI = "http://php.net/distributions/php-${PV}.tar.bz2
> > \
> >file://0001-acinclude-use-pkgconfig-for-libxml2-config.patch \
> > "
> >
> > -SRC_URI_append_class-target += " \
> > +SRC_URI_append_class-target = “ \
>
> nitpick: You do not need a space here since its already added after newline
since i did that more than once, i'll resubmit those patches. if i'm
going to be annoyingly nitpicky, i might as well do it correctly.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] meta-oe: toscoterm, given "_append", convert "+=" to "=", add space
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
and that should do it for all of meta-openembedded.
diff --git a/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
b/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
index 6b31fd6..aa031fe 100644
--- a/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
+++ b/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
@@ -24,4 +24,4 @@ do_install() {
oe_runmake PREFIX="${prefix}" DESTDIR="${D}" install
}
-RDEPENDS_${PN}_append_libc-glibc += "glibc-gconv-ibm437"
+RDEPENDS_${PN}_append_libc-glibc = " glibc-gconv-ibm437"
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] meta-oe: mozjs, given "_append", convert superfluous "+=" to "="
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca> --- diff --git a/meta-oe/recipes-extended/mozjs/mozjs_17.0.0.bb b/meta-oe/recipes-extended/mozjs/mozjs_17.0.0.bb index f147714..524f2a5 100644 --- a/meta-oe/recipes-extended/mozjs/mozjs_17.0.0.bb +++ b/meta-oe/recipes-extended/mozjs/mozjs_17.0.0.bb @@ -37,7 +37,7 @@ EXTRA_OECONF = " \ --enable-threadsafe \ --disable-static \ " -EXTRA_OECONF_append_armv4 += " \ +EXTRA_OECONF_append_armv4 = " \ --disable-methodjit \ " -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] meta-oe: php, given "_append", remove superfluous "+="
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
again, not compile-tested since it seems obvious
diff --git a/meta-oe/recipes-devtools/php/php.inc
b/meta-oe/recipes-devtools/php/php.inc
index ee7a143..23de2b1 100644
--- a/meta-oe/recipes-devtools/php/php.inc
+++ b/meta-oe/recipes-devtools/php/php.inc
@@ -15,7 +15,7 @@ SRC_URI = "http://php.net/distributions/php-${PV}.tar.bz2 \
file://0001-acinclude-use-pkgconfig-for-libxml2-config.patch \
"
-SRC_URI_append_class-target += " \
+SRC_URI_append_class-target = " \
file://iconv.patch \
file://imap-fix-autofoo.patch \
file://pear-makefile.patch \
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] meta-oe: Standardize use of "_append" versus use of "+="
Remove superfluous "+=", then manually add necessary leading space.
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
not build-tested, but looks pretty straightforward.
diff --git a/meta-oe/recipes-connectivity/krb5/krb5_1.13.2.bb
b/meta-oe/recipes-connectivity/krb5/krb5_1.13.2.bb
index 500e194..3a3886b 100644
--- a/meta-oe/recipes-connectivity/krb5/krb5_1.13.2.bb
+++ b/meta-oe/recipes-connectivity/krb5/krb5_1.13.2.bb
@@ -57,8 +57,8 @@ CACHED_CONFIGUREVARS +=
"krb5_cv_attr_constructor_destructor=yes ac_cv_func_regc
ac_cv_printf_positional=yes ac_cv_file__etc_environment=yes \
ac_cv_file__etc_TIMEZONE=no"
-CFLAGS_append += "-DDESTRUCTOR_ATTR_WORKS=1 -I${STAGING_INCDIR}/et"
-LDFLAGS_append += "-lpthread"
+CFLAGS_append = " -DDESTRUCTOR_ATTR_WORKS=1 -I${STAGING_INCDIR}/et"
+LDFLAGS_append = " -lpthread"
FILES_${PN} += "${datadir}/gnats"
FILES_${PN}-doc += "${datadir}/examples"
diff --git a/meta-oe/recipes-connectivity/zabbix/zabbix_2.4.7.bb
b/meta-oe/recipes-connectivity/zabbix/zabbix_2.4.7.bb
index c2c4eae..03bad31 100644
--- a/meta-oe/recipes-connectivity/zabbix/zabbix_2.4.7.bb
+++ b/meta-oe/recipes-connectivity/zabbix/zabbix_2.4.7.bb
@@ -53,7 +53,7 @@ EXTRA_OECONF = '--enable-dependency-tracking \
--with-ssh2 \
--with-sqlite3 \
'
-CFLAGS_append += "-lldap -llber"
+CFLAGS_append = " -lldap -llber"
do_configure_prepend() {
export KERNEL_VERSION="${KERNEL_VERSION}"
diff --git a/meta-oe/recipes-connectivity/zeromq/zeromq_4.1.5.bb
b/meta-oe/recipes-connectivity/zeromq/zeromq_4.1.5.bb
index 3fa5724..34749d0 100644
--- a/meta-oe/recipes-connectivity/zeromq/zeromq_4.1.5.bb
+++ b/meta-oe/recipes-connectivity/zeromq/zeromq_4.1.5.bb
@@ -16,8 +16,8 @@ S = "${WORKDIR}/zeromq-${PV}"
#Uncomment to choose polling system manually. valid values are kqueue, epoll,
devpoll, poll or select
#EXTRA_OECONF += "--with-poller=kqueue"
-#CFLAGS_append += "-O0"
-#CXXFLAGS_append += "-O0"
+#CFLAGS_append = " -O0"
+#CXXFLAGS_append = " -O0"
inherit autotools ptest pkgconfig
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] toscoterm: In presence of "_append", convert "+=" to "="
On Tue, 16 Aug 2016, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
>
> ---
>
> diff --git a/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
> b/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
> index 6b31fd6..7593a65 100644
> --- a/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
> +++ b/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
> @@ -24,4 +24,4 @@ do_install() {
> oe_runmake PREFIX="${prefix}" DESTDIR="${D}" install
> }
>
> -RDEPENDS_${PN}_append_libc-glibc += "glibc-gconv-ibm437"
> +RDEPENDS_${PN}_append_libc-glibc = "glibc-gconv-ibm437"
obviously, toss this patch since it has that same weirdness i just
described -- possibly a weird interaction between _append and += when
there is no leading space.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] toscoterm: In presence of "_append", convert "+=" to "="
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
diff --git a/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
b/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
index 6b31fd6..7593a65 100644
--- a/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
+++ b/meta-oe/recipes-support/toscoterm/toscoterm_git.bb
@@ -24,4 +24,4 @@ do_install() {
oe_runmake PREFIX="${prefix}" DESTDIR="${D}" install
}
-RDEPENDS_${PN}_append_libc-glibc += "glibc-gconv-ibm437"
+RDEPENDS_${PN}_append_libc-glibc = "glibc-gconv-ibm437"
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [yocto] [RFT] gcc 5.0 recipes available for testing
On Fri, 20 Feb 2015, Khem Raj wrote: On Feb 20, 2015, at 3:04 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: On Fri, 20 Feb 2015, Khem Raj wrote: Hi All Encouraged by help received on testing out glibc 2.21, now I have put together OE recipes for gcc-5 GCC 5.0 is in prerelease stage 4 ( open for regression and doc fixes only) https://gcc.gnu.org/ml/gcc/2015-01/msg00156.html The recipes are available here http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-5.0 you just need the topmost commit and then set GCCVERSION = 5.0 SDKGCCVERSION = 5.0 in local.conf i assume this new layer should be used *in place* of the current OE layer for testing purposes? Not really, you can do following to grab just the patch on top of your working branch ( of course OE-Core master snapshot don’t try on older releases) git remote add contrib git://git.openembedded.org/openembedded-core-contrib git fetch contrib git cherry-pick 85cf9c0e77378ca8f93868e9f91001214c8d8f3e ah, gotcha. rday p.s. i fixed the OE core mailing list address for you. :-) -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] missing trailing spaces in some _prepend expressions in oe-core
On Mon, 5 Jan 2015, Martin Jansa wrote:
On Mon, Jan 05, 2015 at 09:58:01AM -0500, Robert P. J. Day wrote:
after running across a variable _prepend assignment that had no
trailing space, i did a quick grep through oe-core and ran across the
following, which would all seem to need that trailing space:
$ grep -rn DEPENDS_prepend.*[^ ]\$ *
meta/classes/qt4e.bbclass:2:DEPENDS_prepend = ${QT4EDEPENDS}
meta/classes/cpan_build.bbclass:27:DEPENDS_prepend =
${@cpan_build_dep_prepend(d)}
meta/classes/autotools.bbclass:24:DEPENDS_prepend =
${@autotools_dep_prepend(d)}
meta/classes/qt4x11.bbclass:2:DEPENDS_prepend = ${QT4DEPENDS}
$
e.g. QT4EDEPENDS QT4DEPENDS both end with space, so it's not causing
any problem, but having the trailing space together with prepend is
good.
Only exception I can think of is when you really don't want to
introduce extra space when the variable used in prepend/append is
set to empty, but that's not an issue for DEPENDS (but important
e.x. for tune .inc files)
and
$ grep -rn SRC_URI_prepend.*[^ ]\$ *
meta/recipes-devtools/qemu/qemu_git.bb:10:SRC_URI_prepend =
git://git.qemu.org/qemu.git
meta/recipes-devtools/qemu/qemu_2.2.0.bb:10:SRC_URI_prepend =
http://wiki.qemu-project.org/download/${BP}.tar.bz2;
$
there may be more, i just left it at that, not sure if there's
something magic about those examples or whether they really should
have the space added, so i'll leave it with someone else to tweak.
not sure if i replied to this already, but if someone wants to tweak
those, i'll leave it up to them. obviously, as martin suggests,
they're not actually causing problems, but i'm just a style guide kind
of guy.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] missing trailing spaces in some _prepend expressions in oe-core
after running across a variable _prepend assignment that had no
trailing space, i did a quick grep through oe-core and ran across the
following, which would all seem to need that trailing space:
$ grep -rn DEPENDS_prepend.*[^ ]\$ *
meta/classes/qt4e.bbclass:2:DEPENDS_prepend = ${QT4EDEPENDS}
meta/classes/cpan_build.bbclass:27:DEPENDS_prepend =
${@cpan_build_dep_prepend(d)}
meta/classes/autotools.bbclass:24:DEPENDS_prepend =
${@autotools_dep_prepend(d)}
meta/classes/qt4x11.bbclass:2:DEPENDS_prepend = ${QT4DEPENDS}
$
and
$ grep -rn SRC_URI_prepend.*[^ ]\$ *
meta/recipes-devtools/qemu/qemu_git.bb:10:SRC_URI_prepend =
git://git.qemu.org/qemu.git
meta/recipes-devtools/qemu/qemu_2.2.0.bb:10:SRC_URI_prepend =
http://wiki.qemu-project.org/download/${BP}.tar.bz2;
$
there may be more, i just left it at that, not sure if there's
something magic about those examples or whether they really should
have the space added, so i'll leave it with someone else to tweak.
rday
p.s. is there any difference between appending or prepending to the
list of build-time dependencies in DEPENDS? most extensions to
DEPENDS i've seen use _append, but occasionally, i see _prepend.
does it matter?
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] i'm assuming some do_task[dirs] = directives are redundant, yes?
On Sat, 26 Jul 2014, Christopher Larson wrote:
On Sat, Jul 26, 2014 at 5:43 AM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
On Mon, 21 Jul 2014, Christopher Larson wrote:
On Mon, Jul 21, 2014 at 2:59 AM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
pedantic observation -- i notice in base.bbclass:
do_unpack[dirs] = ${WORKDIR}
and over in patch.bbclass:
addtask patch after do_unpack
do_patch[dirs] = ${WORKDIR}
so given that patching has been added as a task after unpacking,
wouldn't ${WORKDIR} already be guaranteed to exist? doesn't hurt, of
course, and no, i have no intention of trying to clean any of that up
:-), i just wanted to clarify the actual mechanics.
'dirs' isn't just a list of dirs to create, it also sets the current
working directory for the task. The last directory listed is where
the path is set.
is that documented anywhere? the variable flags section of the
bitbake user manual says nothing about that last obviously significant
property.
Good question, I have no idea :) Clearly it should be somewhere.
ok, i'll shoehorn it in there somewhere.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] i'm assuming some do_task[dirs] = directives are redundant, yes?
On Sat, 26 Jul 2014, Christopher Larson wrote:
On Sat, Jul 26, 2014 at 5:43 AM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
On Mon, 21 Jul 2014, Christopher Larson wrote:
On Mon, Jul 21, 2014 at 2:59 AM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
pedantic observation -- i notice in base.bbclass:
do_unpack[dirs] = ${WORKDIR}
and over in patch.bbclass:
addtask patch after do_unpack
do_patch[dirs] = ${WORKDIR}
so given that patching has been added as a task after unpacking,
wouldn't ${WORKDIR} already be guaranteed to exist? doesn't hurt, of
course, and no, i have no intention of trying to clean any of that up
:-), i just wanted to clarify the actual mechanics.
'dirs' isn't just a list of dirs to create, it also sets the current
working directory for the task. The last directory listed is where
the path is set.
is that documented anywhere? the variable flags section of the
bitbake user manual says nothing about that last obviously significant
property.
Good question, I have no idea :) Clearly it should be somewhere.
actually, while i'm there:
http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#variable-flags
anything else i should add just to make it a single patch? (yes, i
realize this should have gone to the bitbake list at this point but
let's just finish it off here and be done with it.)
it occurs that one could mention variable flags like [doc] in that
section since, technically, that section is entitled Variable Flags,
not just Task Flags, even though it is clearly discussing only task
flags, which seems a touch incomplete.
and just so i'm clear on this, one does not need to pre-declare
variable flags anywhere, right? one can just start using them, yes?
that's probably worth mentioning as well as, on a regular basis, my
students ask, where do i declare that thing that looks like a
subscript?
anyway, any suggestions as to what else can go in there while i
ponder what to add/change?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] i'm assuming some do_task[dirs] = directives are redundant, yes?
On Mon, 21 Jul 2014, Christopher Larson wrote:
On Mon, Jul 21, 2014 at 2:59 AM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
pedantic observation -- i notice in base.bbclass:
do_unpack[dirs] = ${WORKDIR}
and over in patch.bbclass:
addtask patch after do_unpack
do_patch[dirs] = ${WORKDIR}
so given that patching has been added as a task after unpacking,
wouldn't ${WORKDIR} already be guaranteed to exist? doesn't hurt, of
course, and no, i have no intention of trying to clean any of that up
:-), i just wanted to clarify the actual mechanics.
'dirs' isn't just a list of dirs to create, it also sets the current
working directory for the task. The last directory listed is where
the path is set.
is that documented anywhere? the variable flags section of the
bitbake user manual says nothing about that last obviously significant
property.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] Correct spelling of BBFILES_PRIORITY in comments
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/meta-multimedia/conf/layer.conf b/meta-multimedia/conf/layer.conf index 64a0a44..bfecb8c 100644 --- a/meta-multimedia/conf/layer.conf +++ b/meta-multimedia/conf/layer.conf @@ -4,7 +4,7 @@ # search the directories from first to last as specified in BBPATH # Therefore if you want a given layer to be considered high priority # for the .inc and .conf etc. then consider it adding at the beginning -# of BBPATH. For bblayers bitbake will use BBFILES_PRIORITY to resolve +# of BBPATH. For bblayers bitbake will use BBFILE_PRIORITY to resolve # the recipe contention so the order of directories in BBFILES does # not matter. diff --git a/meta-oe/conf/layer.conf b/meta-oe/conf/layer.conf index 2a5a428..9d7a60a 100644 --- a/meta-oe/conf/layer.conf +++ b/meta-oe/conf/layer.conf @@ -4,7 +4,7 @@ # search the directories from first to last as specified in BBPATH # Therefore if you want a given layer to be considered high priority # for the .inc and .conf etc. then consider it adding at the beginning -# of BBPATH. For bblayers bitbake will use BBFILES_PRIORITY to resolve +# of BBPATH. For bblayers bitbake will use BBFILE_PRIORITY to resolve # the recipe contention so the order of directories in BBFILES does # not matter. diff --git a/meta-systemd/conf/layer.conf b/meta-systemd/conf/layer.conf index f3fc45d..d8faf21 100644 --- a/meta-systemd/conf/layer.conf +++ b/meta-systemd/conf/layer.conf @@ -4,7 +4,7 @@ # search the directories from first to last as specified in BBPATH # Therefore if you want a given layer to be considered high priority # for the .inc and .conf etc. then consider it adding at the beginning -# of BBPATH. For bblayers bitbake will use BBFILES_PRIORITY to resolve +# of BBPATH. For bblayers bitbake will use BBFILE_PRIORITY to resolve # the recipe contention so the order of directories in BBFILES does # not matter. diff --git a/toolchain-layer/conf/layer.conf b/toolchain-layer/conf/layer.conf index ca81eb1..9289a8f 100644 --- a/toolchain-layer/conf/layer.conf +++ b/toolchain-layer/conf/layer.conf @@ -4,7 +4,7 @@ # search the directories from first to last as specified in BBPATH # Therefore if you want a given layer to be considered high priority # for the .inc and .conf etc. then consider it adding at the beginning -# of BBPATH. For bblayers bitbake will use BBFILES_PRIORITY to resolve +# of BBPATH. For bblayers bitbake will use BBFILE_PRIORITY to resolve # the recipe contention so the order of directories in BBFILES does # not matter. -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] what uses the variable[doc] content in documentation.conf?
is there something that uses all of that [doc] content in documentation.conf? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] i'm assuming some do_task[dirs] = directives are redundant, yes?
pedantic observation -- i notice in base.bbclass:
do_unpack[dirs] = ${WORKDIR}
and over in patch.bbclass:
addtask patch after do_unpack
do_patch[dirs] = ${WORKDIR}
so given that patching has been added as a task after unpacking,
wouldn't ${WORKDIR} already be guaranteed to exist? doesn't hurt, of
course, and no, i have no intention of trying to clean any of that up
:-), i just wanted to clarify the actual mechanics.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass
On Mon, 14 Jul 2014, Rudolf Streif wrote:
then i noticed that the splash feature is defined, not in
core-image.bbclass, but in the more basic image.bbclass, as is
package-management:
FEATURE_PACKAGES_package-management = ${ROOTFS_PKGMANAGE}
SPLASH ?= psplash
FEATURE_PACKAGES_splash = ${SPLASH}
And then there is debug-tweaks for which the hooks are defined in
image.bbclass including the function zap_empty_root_password but the
post-processing is added to the variable by core-image.bbclass:
core-image.bbclass: ROOTFS_POSTPROCESS_COMMAND +=
'${@bb.utils.contains(IMAGE_FEATURES, debug-tweaks, ,
zap_empty_root_password ; ,d)}'
Since image.bbclass also adds the debug-tweaks to the valid image feature
list
image.bbclass:IMAGE_FEATURES[validitems] += debug-tweaks read-only-rootfs
... snip ...
there's something i'll throw in here now that i'm thinking about it.
i've wondered about that very line above -- what is its purpose?
as i read it, the primary purpose for the variable IMAGE_FEATURES is
to define packagegroups through the use of FEATURE_PACKAGES_* that you
see in core-image.bbclass. (so this is again a bit of weirdness where
code in image.bbclass refers up the inheritance tree to stuff found
in core-image.bbclass.)
however, there are of course some IMAGE_FEATURES that don't
correspond directly to package groups; eg, package-management,
debug-tweaks, read-only-rootfs. so why is package-management not
listed in the line:
image.bbclass:IMAGE_FEATURES[validitems] += debug-tweaks read-only-rootfs
is that variable flag supposed to list all valid, non-packagegroup
IMAGE_FEATURES?
i can see that debug-tweaks is processed explicitly in
image.bbclass:
ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains(IMAGE_FEATURES,
debug-tweaks, ssh_allow_empty_password; , ,d)}'
ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains(IMAGE_FEATURES,
debug-tweaks, postinst_enable_logging; , ,d)}'
but, then again, so is package-management:
ROOTFS_BOOTSTRAP_INSTALL = ${@bb.utils.contains(IMAGE_FEATURES,
package-management, , ${ROOTFS_PKGMANAGE_BOOTSTRAP},d)}
so why is debug-tweaks assigned to IMAGE_FEATURES[validitems] but
not package-management? oh, wait, i just noticed that image.bbclass
explicitly does this:
FEATURE_PACKAGES_package-management = ${ROOTFS_PKGMANAGE}
so that package-management *will* be recognized as a valid image
feature here in image.bbclass:
def check_image_features(d):
valid_features = (d.getVarFlag('IMAGE_FEATURES', 'validitems', True) or
).split()
valid_features += d.getVarFlags('COMPLEMENTARY_GLOB').keys()
for var in d:
if var.startswith(PACKAGE_GROUP_):
bb.warn(PACKAGE_GROUP is deprecated, please use FEATURE_PACKAGES
instead)
valid_features.append(var[14:])
elif var.startswith(FEATURE_PACKAGES_):
valid_features.append(var[17:])
valid_features.sort()
gah! i need more coffee ...
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] is it addtask do_X ... or addtask X ... or does it matter?
On Sat, 12 Jul 2014, Christopher Larson wrote: On Sat, Jul 12, 2014 at 4:22 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: want to clarify the two different ways to use addtask. for example: classes/kernel.bbclass:addtask savedefconfig after do_configure classes/kernel.bbclass:addtask do_strip before do_sizecheck after do_kernel_link_vmlinux classes/kernel.bbclass:addtask sizecheck before do_install after do_strip so what is the preferred form? are they equivalent? addtask do_strip will add a task named 'do_do_strip', afaik. so is there a final opinion on the validity of doing addtask do_X ... rather than addtask X ... if what chris writes is accurate, there are some broken class and recipe files in oe-core: classes/kernel.bbclass:addtask do_strip before do_sizecheck after do_kernel_link_vmlinux classes/staging.bbclass:addtask do_populate_sysroot_setscene classes/insane.bbclass:addtask do_package_qa after do_packagedata do_package before do_build classes/insane.bbclass:addtask do_package_qa_setscene classes/package_rpm.bbclass:addtask do_package_write_rpm_setscene classes/license.bbclass:addtask do_populate_lic_setscene classes/archiver.bbclass:addtask do_ar_original after do_unpack classes/archiver.bbclass:addtask do_unpack_and_patch after do_patch classes/archiver.bbclass:addtask do_ar_patched after do_unpack_and_patch classes/archiver.bbclass:addtask do_ar_configured after do_unpack_and_patch classes/archiver.bbclass:addtask do_dumpdata classes/archiver.bbclass:addtask do_ar_recipe classes/archiver.bbclass:addtask do_deploy_archives before do_build classes/deploy.bbclass:addtask do_deploy_setscene classes/package_deb.bbclass:addtask do_package_write_deb_setscene classes/package.bbclass:addtask do_package_setscene classes/package.bbclass:addtask do_packagedata_setscene classes/package_ipk.bbclass:addtask do_package_write_ipk_setscene recipes-core/eglibc/eglibc-package.inc:addtask do_install_locale after do_install before do_populate_sysroot do_package recipes-core/base-passwd/base-passwd_3.5.29.bb:addtask do_package after do_populate_sysroot recipes-core/meta/package-index.bb:addtask do_package_index before do_build recipes-devtools/gcc/gcc-configure-common.inc:addtask do_preconfigure after do_patch before do_configure recipes-support/boost/boost.inc:addtask do_boostconfig after do_patch before do_configure surely all of the above can't be broken, can they? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Mon, 14 Jul 2014, Paul Eggleton wrote: On Friday 11 July 2014 20:39:04 Otavio Salvador wrote: On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: a number of the current packagegroup recipe files still have backward compatibility support for the old task-core names, seems like that's been there for well over a year, would it be safe to finally just toss that? seems like everyone's had enough time to make the move to the new names, and it would be clearer to not confuse the proper use of the word task these days. I agree; however this question should also be send to oe-core mailing list (added in Cc) I agree as well; these should go. I know there are some who want to keep these indefinitely for upgrade purposes, but I think there's a limit to how long they should stay around in OE-Core. They can always be preserved in bbappends for those that do want to keep them. i can submit a patch for that later today if no one objects. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] overriding tasks with EXPORT_FUNCTIONS
On Mon, 14 Jul 2014, Paul Eggleton wrote: Hi Robert, On Sunday 13 July 2014 10:19:08 Robert P. J. Day wrote: followup to last post -- all of the methods for overriding task definitions in the last post can be used without predeclaring that you're about to do that; you just go ahead and do it in either a class file or a recipe file. on the other hand, EXPORT_FUNCTIONS allows you to retain the base definition of a task (or non-task function, as i read it), then define a more general enhanced version. (side note: i don't see a single mention of EXPORT_FUNCTIONS in any of the numerous yocto docs -- i think this feature needs some explanation *somewhere*. :-) Did you try the new BitBake manual? http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#flexible-inheritance-for-class-functions Let me know if that doesn't answer your questions. actually, i worded the above *really* badly. i see it in the bitbake user manual, i was referring to the yocto-docs layer, which contains all of the yocto docs but not the bitbake manual, which might mislead some people into not knowing that the bitbake user manual is even there. i know bitbake is outside the scope of what belongs in the yocto-docs layer, but perhaps there should be at least a pointer to it in the yocto-docs README file? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Mon, 14 Jul 2014, Paul Eggleton wrote:
On Friday 11 July 2014 20:39:04 Otavio Salvador wrote:
On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day
rpj...@crashcourse.ca wrote:
a number of the current packagegroup recipe files still have
backward compatibility support for the old task-core names, seems
like that's been there for well over a year, would it be safe to
finally just toss that? seems like everyone's had enough time to make
the move to the new names, and it would be clearer to not confuse the
proper use of the word task these days.
I agree; however this question should also be send to oe-core mailing
list (added in Cc)
I agree as well; these should go. I know there are some who want to
keep these indefinitely for upgrade purposes, but I think there's a
limit to how long they should stay around in OE-Core. They can
always be preserved in bbappends for those that do want to keep
them.
getting rid of all that task-core stuff in packagegroups looks
pretty easy, except for this snippet in
packagegroup-core-full-cmdline.bb:
packages = d.getVar(PACKAGES, True).split()
for pkg in packages:
if pkg.endswith('-dev'):
mapped = namemap.get(pkg[:-4], None)
if mapped:
mapped += '-dev'
elif pkg.endswith('-dbg'):
mapped = namemap.get(pkg[:-4], None)
if mapped:
mapped += '-dbg'
else:
mapped = namemap.get(pkg, None)
if mapped:
oldtaskname = mapped.replace(packagegroup-core, task-core)
mapstr = %s %s % (mapped, oldtaskname)
d.appendVar(RPROVIDES_%s % pkg, mapstr)
d.appendVar(RREPLACES_%s % pkg, mapstr)
d.appendVar(RCONFLICTS_%s % pkg, mapstr)
}
would one simply delete that last if mapped: conditional in its
entirety? or what?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Mon, 14 Jul 2014, Paul Eggleton wrote: On Friday 11 July 2014 20:39:04 Otavio Salvador wrote: On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: a number of the current packagegroup recipe files still have backward compatibility support for the old task-core names, seems like that's been there for well over a year, would it be safe to finally just toss that? seems like everyone's had enough time to make the move to the new names, and it would be clearer to not confuse the proper use of the word task these days. I agree; however this question should also be send to oe-core mailing list (added in Cc) I agree as well; these should go. I know there are some who want to keep these indefinitely for upgrade purposes, but I think there's a limit to how long they should stay around in OE-Core. They can always be preserved in bbappends for those that do want to keep them. one more (general) question about this ... there's a fair bit of this task/packagegroup backward compatibility stuff under the meta-oe layer as well. i assume that patches to the meta-oe layer should still be posted to this list, but have a subject line of: [meta-oe][PATCH] ... correct? as in, two separate patches. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] Remove long-deprecated task-core backward compat for packagegroups.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
a few notes:
* seems valid as i'm rebuilding a core-image-minimal for qemux86 so
the recipes seem to parse properly
* almost all of this is simple variable assignment deletion but for
that first patch, which is just the python code which does the same
thing
* there is also removal of some assignments that relate to similar
stuff over in meta-oe. is it reasonable to just delete that content
here, and delete the related meta-oe stuff as another patch?
diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb
b/meta/recipes-core/packagegroups/packagegroup-base.bb
index 16f3a51..13a4fe4 100644
--- a/meta/recipes-core/packagegroups/packagegroup-base.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
@@ -124,13 +124,6 @@ python __anonymous () {
if nfc in distro_features and not nfc in machine_features and
(usbhost in machine_features):
d.setVar(ADD_NFC, packagegroup-base-nfc)
-
-# For backwards compatibility after rename
-packages = d.getVar(PACKAGES, True).split()
-for pkg in packages:
-d.appendVar(RPROVIDES_%s % pkg, pkg.replace(packagegroup-,
task-))
-d.appendVar(RREPLACES_%s % pkg, pkg.replace(packagegroup-,
task-))
-d.appendVar(RCONFLICTS_%s % pkg, pkg.replace(packagegroup-,
task-))
}
#
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
index c8bc362..bdc4a1d 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
@@ -17,11 +17,6 @@ PACKAGE_ARCH = ${MACHINE_ARCH}
MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?=
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?=
-# For backwards compatibility after rename
-RPROVIDES_${PN} = task-core-boot
-RREPLACES_${PN} = task-core-boot
-RCONFLICTS_${PN} = task-core-boot
-
# Distro can override the following VIRTUAL-RUNTIME providers:
VIRTUAL-RUNTIME_dev_manager ?= udev
VIRTUAL-RUNTIME_login_manager ?= busybox
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
index 24c98c4..247a30e 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
@@ -10,11 +10,6 @@ inherit packagegroup
PACKAGES = ${PN}-server
-# For backwards compatibility after rename
-RPROVIDES_${PN}-server = task-core-nfs-server
-RREPLACES_${PN}-server = task-core-nfs-server
-RCONFLICTS_${PN}-server = task-core-nfs-server
-
SUMMARY_${PN}-server = NFS server
RDEPENDS_${PN}-server = \
nfs-utils \
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
index 1723989..a544bbd 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
@@ -10,11 +10,6 @@ inherit packagegroup
#PACKAGEFUNCS =+ 'generate_sdk_pkgs'
-# For backwards compatibility after rename
-RPROVIDES_packagegroup-core-sdk = task-core-sdk
-RREPLACES_packagegroup-core-sdk = task-core-sdk
-RCONFLICTS_packagegroup-core-sdk = task-core-sdk
-
RDEPENDS_packagegroup-core-sdk = \
packagegroup-core-buildessential \
coreutils \
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
b/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
index 458d8fa..e99946f 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-ssh-dropbear.bb
@@ -4,9 +4,4 @@ PR = r1
inherit packagegroup
-# For backwards compatibility after rename
-RPROVIDES_${PN} = task-core-ssh-dropbear
-RREPLACES_${PN} = task-core-ssh-dropbear
-RCONFLICTS_${PN} = task-core-ssh-dropbear
-
RDEPENDS_${PN} = dropbear
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb
b/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb
index df70962..32d20e6 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb
@@ -4,9 +4,4 @@ PR = r1
inherit packagegroup
-# For backwards compatibility after rename
-RPROVIDES_${PN} = task-core-ssh-openssh
-RREPLACES_${PN} = task-core-ssh-openssh
-RCONFLICTS_${PN} = task-core-ssh-openssh
-
RDEPENDS_${PN} = openssh
diff --git
a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
index 3325ef6..5d1ce97 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
@@ -4,14 +4,6 @@ LICENSE = MIT
inherit packagegroup
-# For backwards compatibility after rename
-RPROVIDES_${PN} = task-core-standalone-sdk-target
-RREPLACES_${PN
Re: [oe] [OE-core] any value in keeping the backward compat task-core stuff?
On Mon, 14 Jul 2014, Paul Eggleton wrote: On Monday 14 July 2014 07:39:23 Robert P. J. Day wrote: On Mon, 14 Jul 2014, Paul Eggleton wrote: On Friday 11 July 2014 20:39:04 Otavio Salvador wrote: On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: a number of the current packagegroup recipe files still have backward compatibility support for the old task-core names, seems like that's been there for well over a year, would it be safe to finally just toss that? seems like everyone's had enough time to make the move to the new names, and it would be clearer to not confuse the proper use of the word task these days. I agree; however this question should also be send to oe-core mailing list (added in Cc) I agree as well; these should go. I know there are some who want to keep these indefinitely for upgrade purposes, but I think there's a limit to how long they should stay around in OE-Core. They can always be preserved in bbappends for those that do want to keep them. one more (general) question about this ... there's a fair bit of this task/packagegroup backward compatibility stuff under the meta-oe layer as well. i assume that patches to the meta-oe layer should still be posted to this list, but have a subject line of: [meta-oe][PATCH] ... correct? as in, two separate patches. To be clear (since we're cross-posted to two lists in this thread) OE-Core patches go to the openembedded-core list, meta-oe patches to the openembedded- devel list. ah, gotcha, will fix. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] Remove deprecated task backward compatibility from packagegroups
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
all of this looked relatively straightforward.
diff --git a/meta-efl/recipes-efl/packagegroups/packagegroup-efl-sdk.bb
b/meta-efl/recipes-efl/packagegroups/packagegroup-efl-sdk.bb
index 4e5ce78..5ead412 100644
--- a/meta-efl/recipes-efl/packagegroups/packagegroup-efl-sdk.bb
+++ b/meta-efl/recipes-efl/packagegroups/packagegroup-efl-sdk.bb
@@ -11,9 +11,6 @@ require packagegroup-efl-sdk.inc
PACKAGES = ${PN}
-RPROVIDES_${PN} += task-efl-sdk
-RREPLACES_${PN} += task-efl-sdk
-RCONFLICTS_${PN} += task-efl-sdk
RDEPENDS_${PN} = \
packagegroup-core-sdk \
${SDK-EFL} \
diff --git
a/meta-efl/recipes-efl/packagegroups/packagegroup-efl-standalone-sdk-target.bb
b/meta-efl/recipes-efl/packagegroups/packagegroup-efl-standalone-sdk-target.bb
index 1bcac45..6a3f33d 100644
---
a/meta-efl/recipes-efl/packagegroups/packagegroup-efl-standalone-sdk-target.bb
+++
b/meta-efl/recipes-efl/packagegroups/packagegroup-efl-standalone-sdk-target.bb
@@ -11,9 +11,6 @@ require packagegroup-efl-sdk.inc
PACKAGES = ${PN} ${PN}-dbg
-RPROVIDES_${PN} += task-efl-standalone-sdk-target
-RREPLACES_${PN} += task-efl-standalone-sdk-target
-RCONFLICTS_${PN} += task-efl-standalone-sdk-target
RDEPENDS_${PN} = \
packagegroup-core-standalone-sdk-target \
${SDK-EFL} \
diff --git a/meta-efl/recipes-efl/packagegroups/packagegroup-x11-illume.bb
b/meta-efl/recipes-efl/packagegroups/packagegroup-x11-illume.bb
index 47f758a..63ef0f6 100644
--- a/meta-efl/recipes-efl/packagegroups/packagegroup-x11-illume.bb
+++ b/meta-efl/recipes-efl/packagegroups/packagegroup-x11-illume.bb
@@ -11,9 +11,6 @@ inherit packagegroup allarch
ETHEME ?= e-wm-theme-default
ECONFIG ?= e-wm-config-mobile
-RPROVIDES_${PN} += task-x11-illume
-RREPLACES_${PN} += task-x11-illume
-RCONFLICTS_${PN} += task-x11-illume
RDEPENDS_${PN} = \
packagegroup-core-x11-xserver \
packagegroup-core-x11-utils \
diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
b/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
index 08db943..ad1cd83 100644
--- a/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
+++ b/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
@@ -23,9 +23,6 @@ MACHINE_EXTRA_RRECOMMENDS ?=
#
TASK_BASIC_SSHDAEMON ?= dropbear openssh-sftp openssh-sftp-server
-RPROVIDES_${PN} += task-basic
-RREPLACES_${PN} += task-basic
-RCONFLICTS_${PN} += task-basic
#
# The section below is designed to match with packagegroup-boot, but doesn't
depend on it to allow for more freedom
# when writing image recipes.
diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb
b/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb
index 3b634f3..61a519d 100644
--- a/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb
+++ b/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb
@@ -19,10 +19,6 @@ MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?=
# Make sure we build the kernel
DEPENDS = virtual/kernel
-RPROVIDES_${PN} += task-boot
-RREPLACES_${PN} += task-boot
-RCONFLICTS_${PN} += task-boot
-
#
# minimal set of packages - needed to boot
#
diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb
b/meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb
index fbba23c..2a4b067 100644
--- a/meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb
+++ b/meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb
@@ -10,13 +10,6 @@ inherit packagegroup allarch
PACKAGES += ${PN}-debug
-RPROVIDES_${PN} += task-cli-tools
-RPROVIDES_${PN}-debug += task-cli-tools-debug
-RREPLACES_${PN} += task-cli-tools
-RREPLACES_${PN}-debug += task-cli-tools-debug
-RCONFLICTS_${PN} += task-cli-tools
-RCONFLICTS_${PN}-debug += task-cli-tools-debug
-
RDEPENDS_${PN} = \
dbus-daemon-proxy \
dosfstools \
diff --git a/meta-oe/recipes-devtools/packagegroups/packagegroup-sdk-target.bb
b/meta-oe/recipes-devtools/packagegroups/packagegroup-sdk-target.bb
index 9b8cc9a..aafe63a 100644
--- a/meta-oe/recipes-devtools/packagegroups/packagegroup-sdk-target.bb
+++ b/meta-oe/recipes-devtools/packagegroups/packagegroup-sdk-target.bb
@@ -6,9 +6,9 @@ PR = r1
inherit packagegroup allarch
-RPROVIDES_${PN} += packagegroup-native-sdk task-sdk-target task-native-sdk
-RREPLACES_${PN} += packagegroup-native-sdk task-sdk-target task-native-sdk
-RCONFLICTS_${PN} += packagegroup-native-sdk task-sdk-target task-native-sdk
+RPROVIDES_${PN} += packagegroup-native-sdk
+RREPLACES_${PN} += packagegroup-native-sdk
+RCONFLICTS_${PN} += packagegroup-native-sdk
RDEPENDS_${PN} = gcc-symlinks g++-symlinks cpp cpp-symlinks \
binutils-symlinks \
perl-modules \
diff --git
a/meta-oe/recipes-graphics/packagegroups/packagegroup-fonts-truetype.bb
b/meta-oe/recipes-graphics/packagegroups/packagegroup-fonts-truetype.bb
index 931564f..632e7d4 100644
--- a/meta-oe/recipes-graphics/packagegroups/packagegroup-fonts-truetype.bb
+++ b/meta-oe/recipes
Re: [oe] overriding tasks with EXPORT_FUNCTIONS
On Mon, 14 Jul 2014, Burton, Ross wrote:
On 14 July 2014 13:20, Robert P. J. Day rpj...@crashcourse.ca wrote:
but, as far as i can tell, that is the only class that requires a
package name hook, and it simply defines its own implementation -- it
does nothing with package.bbclass and makes no reference to the
exported function package_package_name_hook(). so am i just
misunderstanding something? what was the point of defining and
exporting that function in package.bbclass if no other class takes
advantage of it?
So there needs to be an empty implementation and EXPORT_FUNCTION for
package_package_name_hook so that you don't get cannot find
function package_name_hook when you don't have the debian.bbclass
enabled.
In cleaning that up I proposed removing the EXPORT_FUNCTION entirely
for the hook, but Richard recalled there being something out there
that did use the ability to chain up into debian.bbclass's
implementation, so I kept it.
uh oh ... now i'm a bit confused again so let me back up a bit
because i really want to understand this. my apologies for the tedium.
as i read it, the only purpose of EXPORT_FUNCTIONS is to support the
idea of being able to qualify a function with its class name so that
you can (effectively) have access to more than one function with the
same name at the same time. first, let's see where this is *not*
necessary.
as an example, base.bbclass defines the routine:
oe_runmake() {
oe_runmake_call $@ || die oe_runmake failed
}
now, since every class automatically inherits base.bbclass, all of
those classes can call oe_runmake(), right? that routine is in their
namespace, there is no need to export it, and they will all get that
function as it's defined in base.bbclass.
in addition, even if a class inherits base.bbclass, it has the right
to totally override that routine by redefining a new oe_runmake(),
yes? (or possibly _appending or _prepending to it.) in any event, at
any time, there is only one definition of a function called
oe_runmake() in scope. so far, so good?
what EXPORT_FUNCTIONS appears to do is simply allow you access to
more than one function with the same name, so let's look at
base.bbclass and, say, the do_fetch() routine:
python base_do_fetch() {
... snip code ...
}
...
EXPORT_FUNCTIONS do_fetch
what does the above do? it now allows you to define, say,
derived.bbclass, and define a new do_fetch() in terms of the base
do_fetch(), as in:
do_fetch() {
...
base_do_fetch()
...
}
however, if i created a new class that had no interest in redefining
do_fetch() and i was happy with the base definition, i could simply
continue to use the name do_fetch(), correct? the fact that that
function was exported in base.bbclass is not relevant to me if i am
not trying to redefine the name. (i suspect i could also refer to it
by the name base_do_fetch() if i wanted, but that's unnecessary.)
that's why i was confused by ross' earlier paragraph about
package_name_hook being defined in package.bbclass -- unless some
other class is going to try to access two functions called
package_naem_hook at the same time, i currently see no need to
export it in package.bbclass. however, if there was something else
going on somewhere that needed this as richard purdie suggested, then
i'd be interested in knowing what that is just to understand the whole
picture.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass
On Mon, 14 Jul 2014, Rudolf Streif wrote:
then i noticed that the splash feature is defined, not in
core-image.bbclass, but in the more basic image.bbclass, as is
package-management:
FEATURE_PACKAGES_package-management = ${ROOTFS_PKGMANAGE}
SPLASH ?= psplash
FEATURE_PACKAGES_splash = ${SPLASH}
And then there is debug-tweaks for which the hooks are defined in
image.bbclass including the function zap_empty_root_password but the
post-processing is added to the variable by core-image.bbclass:
core-image.bbclass: ROOTFS_POSTPROCESS_COMMAND +=
'${@bb.utils.contains(IMAGE_FEATURES, debug-tweaks, ,
zap_empty_root_password ; ,d)}'
Since image.bbclass also adds the debug-tweaks to the valid image
feature list
image.bbclass:IMAGE_FEATURES[validitems] += debug-tweaks read-only-rootfs
my inclination would be to move the addition to ROOTFS_POSTPROCESS_COMMAND
from core-image.bbclass to image.bbclass.
The image feature readonly-rootfs is also added to the valid list by
image.bbclass.
i didn't notice the rest of these as i stopped looking after the
splash example and thought i'd ask about it.
Consequently this makes the image features splash, debug-tweaks,
package-management, splash and readonly-rootfs available to image
recipes that inherit image.bbclass while h/w codecs and others are
added by core-image.bbclass and are only available when an image
recipe inherits core-image.
is there something special about hwcodecs that suggests it should
stay in core-image rather than moving to image as well? i'm just
trying to understand the rationale.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] avoiding hard-coded filenames in package file lists
occasionally, i still trip across stuff like this (this is from
oe-core):
meta/recipes-graphics/ttf-fonts/ttf-bitstream-vera_1.10.bb:FILES_${PN} = /etc
${datadir}/fonts
i'm assuming that one should avoid hard-coding names like /etc in
this case, and instead use (in this case) ${sysconfdir}, yes?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass
On Mon, 14 Jul 2014, Rudolf Streif wrote: is there something special about hwcodecs that suggests it should stay in core-image rather than moving to image as well? i'm just trying to understand the rationale. Not necessarily. But I would consider them extended features and they belong into core-image in my opinion. Not all embedded systems need them. Many don't have video or audio support. I would even suggest to move splash to core-image. If a device does not have video there is not reason for a splash screen. I consider debug-tweaks, package-management, and readonly-rootfs the basic image features to be in image. and i have no problem with that rationale. :-) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] is it addtask do_X ... or addtask X ... or does it matter?
On Mon, 14 Jul 2014, Christopher Larson wrote: On Mon, Jul 14, 2014 at 3:11 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: if what chris writes is accurate, there are some broken class and recipe files in oe-core: classes/kernel.bbclass:addtask do_strip before do_sizecheck after do_kernel_link_vmlinux classes/staging.bbclass:addtask do_populate_sysroot_setscene classes/insane.bbclass:addtask do_package_qa after do_packagedata do_package before do_build classes/insane.bbclass:addtask do_package_qa_setscene classes/package_rpm.bbclass:addtask do_package_write_rpm_setscene classes/license.bbclass:addtask do_populate_lic_setscene classes/archiver.bbclass:addtask do_ar_original after do_unpack classes/archiver.bbclass:addtask do_unpack_and_patch after do_patch classes/archiver.bbclass:addtask do_ar_patched after do_unpack_and_patch classes/archiver.bbclass:addtask do_ar_configured after do_unpack_and_patch classes/archiver.bbclass:addtask do_dumpdata classes/archiver.bbclass:addtask do_ar_recipe classes/archiver.bbclass:addtask do_deploy_archives before do_build classes/deploy.bbclass:addtask do_deploy_setscene classes/package_deb.bbclass:addtask do_package_write_deb_setscene classes/package.bbclass:addtask do_package_setscene classes/package.bbclass:addtask do_packagedata_setscene classes/package_ipk.bbclass:addtask do_package_write_ipk_setscene recipes-core/eglibc/eglibc-package.inc:addtask do_install_locale after do_install before do_populate_sysroot do_package recipes-core/base-passwd/base-passwd_3.5.29.bb:addtask do_package after do_populate_sysroot recipes-core/meta/package-index.bb:addtask do_package_index before do_build recipes-devtools/gcc/gcc-configure-common.inc:addtask do_preconfigure after do_patch before do_configure recipes-support/boost/boost.inc:addtask do_boostconfig after do_patch before do_configure surely all of the above can't be broken, can they? I stand corrected, looks like code in bb.build.addtask automatically adds do_ if it isn't present. We probably should pick one and fix the metadata to be consistent, however :) ah, yes, there it is: def addtask(task, before, after, d): if task[:3] != do_: task = do_ + task that just invites abuse, doesn't it? :-) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] some questions about overriding tasks
i think i understand most of this but just want to make sure -- this
doesn't seem comprehensively documented in any of the OE or yocto
docs, and i'll use examples from the oe-core codebase, after which
i'm going to write all this up and wiki it.
to begin with, we have a small number of fundamental tasks defined
in base.bbclass:
* do_fetch
* do_unpack
* do_configure
* do_compile
* do_install
* do_package
first, it's possible to simply override the entire task definition,
both in subsequent class files and recipe files, correct? for
instance, here's something from cross.bbclass:
do_install () {
oe_runmake 'DESTDIR=${D}' install
}
although it seems extremely uncommon to override those tasks from
another bbclass file. it's far more common to do that from recipe
files, like this from zlib_1.2.8.bb:
do_configure (){
./configure --prefix=${prefix} --shared --libdir=${libdir}
}
do_compile (){
oe_runmake
}
so, in both cases, one can simply override *totally* a base task
definition in both a class file and a recipe file, even though this is
done almost exclusively from within recipe files. so far, so good?
the next option is to use _append or _prepend to enhance an
underlying task definition but, again, while this can be done in class
files, there's not a lot of that in the oe-core class files (here's
hoping i got my grep command correct):
$ grep -E ^do_.*(ap|pre)pend *
binconfig-disabled.bbclass:do_install_append () {
gnomebase.bbclass:do_install_append() {
gtk-doc.bbclass:do_configure_prepend () {
icecc.bbclass:do_configure_prepend() {
icecc.bbclass:do_compile_prepend() {
icecc.bbclass:do_compile_kernelmodules_prepend() {
icecc.bbclass:do_install_prepend() {
kernel-module-split.bbclass:do_install_append() {
libc-package.bbclass:do_configure_prepend() {
$
there is, unsurprisingly, way more in recipe files but,
again, the point is that the above can be done in both class and
recipe files, yes?
the final kind of overriding i've seen is to simply deactivate a
task, and i've seen that done three different ways. first, you can
redefine it as the null task, as in xuser-account_0.1.bb:
do_configure() {
:
}
do_compile() {
:
}
do_install() {
:
}
the next option appears to be to use the [noexec] variable flag,
which can occur in both class and recipe files, like this in
packagegroup.bbclass:
packagegroup.bbclass:do_fetch[noexec] = 1
packagegroup.bbclass:do_unpack[noexec] = 1
packagegroup.bbclass:do_patch[noexec] = 1
packagegroup.bbclass:do_configure[noexec] = 1
packagegroup.bbclass:do_compile[noexec] = 1
packagegroup.bbclass:do_install[noexec] = 1
packagegroup.bbclass:do_populate_sysroot[noexec] = 1
and the *third* way to deactivate a task appears to be with
deltask, as in the class files:
$ grep deltask *
cross.bbclass:deltask package
cross.bbclass:deltask packagedata
cross.bbclass:deltask package_write_ipk
cross.bbclass:deltask package_write_deb
cross.bbclass:deltask package_write_rpm
cross.bbclass:deltask package_write
externalsrc.bbclass:bb.build.deltask(task, d)
externalsrc.bbclass:bb.build.deltask(task, d)
native.bbclass:deltask package
native.bbclass:deltask packagedata
native.bbclass:deltask package_write_ipk
native.bbclass:deltask package_write_deb
native.bbclass:deltask package_write_rpm
native.bbclass:deltask package_write
ptest.bbclass:bb.build.deltask(i, d)
$
deltask seems to be used almost exclusively in .bbclass files, but i
found a single example searching through the numerous layers i have on
my system, in meta-oe/meta-initramfs/recipes/devtools/klibc:
klcc-cross_2.0.3.bb:deltask do_package
klcc-cross_2.0.3.bb:deltask do_packagedata
klcc-cross_2.0.3.bb:deltask do_package_write_ipk
klcc-cross_2.0.3.bb:deltask do_package_write_rpm
klcc-cross_2.0.3.bb:deltask do_package_write_deb
klcc-cross_2.0.3.bb:deltask do_package_write_tar
so it appears that deltask is valid for both class and recipe files,
but the above is the only example i found across several layers of its
use in a recipe file.
and about the three ways to deactivate a task:
1)
do_configure() {
:
}
2)
do_configure[noexec] = 1
3)
deltask do_package
is there a style guide, since it would appear that the above might
have very different effects. the first still defines a task which
runs, but simply does nothing.
the second leaves the task defined, but it does *not* run.
the third appears to delete the definition of the task entirely.
are there dependency issues related to which version you use? what
happens if you delete a task which is the dependency of some other
existing task? is this written up somewhere?
i think i'll stop here, a post on EXPORT_FUNCTIONS coming up
shortly ...
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
