* Re: [PATCH 4/4] sanity.bbclass: fix check_connectivity() for BB_NO_NETWORK = "0"
From: Robert Yang @ 2016-11-14 15:37 UTC (permalink / raw)
To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZANn7+CW65pS-fV8d=0ju9v5YjAY64=b3=qZLnZ8C+uz+hg@mail.gmail.com>
On 11/14/2016 11:03 PM, Christopher Larson wrote:
>
> On Mon, Nov 14, 2016 at 7:34 AM, Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>> wrote:
>
> The old code:
> network_enabled = not d.getVar('BB_NO_NETWORK', True)
>
> It is True only when BB_NO_NETWORK is not set (None),
> but BB_NO_NETWORK = "0" should also be True while "1" means no network,
> "0" means need network in a normal case.
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>>
> ---
> meta/classes/sanity.bbclass | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index 7e383f9..c5e3809 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -363,15 +363,19 @@ def check_connectivity(d):
> test_uris = (d.getVar('CONNECTIVITY_CHECK_URIS', True) or "").split()
> retval = ""
>
> + bbn = d.getVar('BB_NO_NETWORK', True)
> + if bbn not in (None, '0', '1'):
> + return 'BB_NO_NETWORK should be "0" or "1", but it is "%s"' % bbn
>
>
> Does this mirror the same logic used in bitbake? What’s the behavior if it’s
> set, but to the empty string?
bitbake only checks whether it equals "1" or not. Without this patch, an empty
string is the same as not set since it doesn't equal to "1". But if it is
set to "0", bitbake uses it as enable network, sanity.bbclass uses it
as disable netowrk, which are conflicted. We can add checking for empty string,
but do we have to ? Limit it to "0" or "1" makes things clear.
// Robert
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* Re: [PATCH] wic: Fix rootfs_size variable not found error.
From: Burton, Ross @ 2016-11-14 15:24 UTC (permalink / raw)
To: Philip Balister; +Cc: OE-core
In-Reply-To: <1478886733-27782-1-git-send-email-philip@balister.org>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On 11 November 2016 at 17:52, Philip Balister <philip@balister.org> wrote:
> Commit 1ba6101ceaee354816e690d44bc9a5dd8dcf4011 introduced the runtime
> error. Thi scommit should fix it. Tested with an sd card build with
> an ext4 file system.
>
Already sent as "wic: use partition size when creating empty partition
files", should be in master soon.
Ross
[-- Attachment #2: Type: text/html, Size: 872 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] sanity.bbclass: fix check_connectivity() for BB_NO_NETWORK = "0"
From: Christopher Larson @ 2016-11-14 15:03 UTC (permalink / raw)
To: Robert Yang; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <8c8065fec7073acfbe7c9ea308137e7bb8b83321.1479133967.git.liezhi.yang@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]
On Mon, Nov 14, 2016 at 7:34 AM, Robert Yang <liezhi.yang@windriver.com>
wrote:
> The old code:
> network_enabled = not d.getVar('BB_NO_NETWORK', True)
>
> It is True only when BB_NO_NETWORK is not set (None),
> but BB_NO_NETWORK = "0" should also be True while "1" means no network,
> "0" means need network in a normal case.
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
> meta/classes/sanity.bbclass | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index 7e383f9..c5e3809 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -363,15 +363,19 @@ def check_connectivity(d):
> test_uris = (d.getVar('CONNECTIVITY_CHECK_URIS', True) or "").split()
> retval = ""
>
> + bbn = d.getVar('BB_NO_NETWORK', True)
> + if bbn not in (None, '0', '1'):
> + return 'BB_NO_NETWORK should be "0" or "1", but it is "%s"' % bbn
>
Does this mirror the same logic used in bitbake? What’s the behavior if
it’s set, but to the empty string?
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 1965 bytes --]
^ permalink raw reply
* Re: [RFT][PATCH] systemd: Upgrade to 232
From: Dmitry Rozhkov @ 2016-11-14 14:52 UTC (permalink / raw)
To: Khem Raj, openembedded-core
In-Reply-To: <20161110061149.20570-1-raj.khem@gmail.com>
On Wed, 2016-11-09 at 22:11 -0800, Khem Raj wrote:
> * Drop support for rcS.d SysV init scripts.
> These are prone to cause dependency loops, and almost all packages
> with
> rcS scripts now ship a native systemd service.
>
> * Drop mount propagation patch, it only happens with libseccomp, OE
> doesnt
> enable it
>
> * kdbus option has disappeared from configure
>
> * Ignore dev-so for PN now since systemd introduced private .so see
> https://github.com/systemd/systemd/issues/3810
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
I've "smoke"-tested systemd-resolved's new functionality: seems to work
as expected and I haven't noticed regressions so far in the rest of
SystemD.
BR,
Dmitry
^ permalink raw reply
* Re: [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage
From: Marek Vasut @ 2016-11-14 14:48 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0LZVXqvWmRaYHCchxLJ-Bpb86d+EQk-49J3cUZUH07Q5NQ@mail.gmail.com>
On 11/14/2016 03:45 PM, Burton, Ross wrote:
>
> On 12 November 2016 at 18:31, Marek Vasut <marex@denx.de
> <mailto:marex@denx.de>> wrote:
>
> > Also the u-boot series went through a number of revisions, can you
> > verify that the patches in poky-contrib:ross/mut match what you expect
> > to see?
>
> Do you have a link for me ?
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mut-broken&id=4f6dbc99950da645dc4d0e23e0065ff8245a0e74
>
> As the cleanups didn't really make sense standalone, I squashed the lot.
I prefer to keep the history, but OK. It looks like what I'd expect there.
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage
From: Burton, Ross @ 2016-11-14 14:45 UTC (permalink / raw)
To: Marek Vasut; +Cc: OE-core
In-Reply-To: <db0f1a76-ef02-c274-9dfd-1bb8808faebc@denx.de>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
On 12 November 2016 at 18:31, Marek Vasut <marex@denx.de> wrote:
> > Also the u-boot series went through a number of revisions, can you
> > verify that the patches in poky-contrib:ross/mut match what you expect
> > to see?
>
> Do you have a link for me ?
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mut-broken&id=4f6dbc99950da645dc4d0e23e0065ff8245a0e74
As the cleanups didn't really make sense standalone, I squashed the lot.
Ross
[-- Attachment #2: Type: text/html, Size: 1141 bytes --]
^ permalink raw reply
* Re: WRL error: "Can't locate Config_heavy-target.pl in @INC" -- OE versus WRL
From: Robert P. J. Day @ 2016-11-14 14:40 UTC (permalink / raw)
To: Mark Hatle; +Cc: openembedded-core
In-Reply-To: <ca53cb96-5c1e-35f1-55f3-8f61897de18f@windriver.com>
i think i figured out the problem ... all of the perl recipes i was
trying to build (from meta-cpan) had the line:
inherit cpan allarch
rather than just:
inherit cpan
so the native perl built by WRL chokes on that, while the slightly
newer perl that comes with OE has a patch to handle that.
at least, that's what *appears* to be happening. does that make any
sense?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH v2 00/10] wic: bugfixes & --fixed-size support, tests, selftest: minor fixes
From: Maciej Borzęcki @ 2016-11-14 14:37 UTC (permalink / raw)
To: Burton, Ross; +Cc: Paul Eggleton, Maciej Borzecki, OE-core
In-Reply-To: <CAJTo0Lby4RLXxxe8cG_Kr8Uq-srb8nv2tZCTCuQxBYD8hY5YyA@mail.gmail.com>
On Mon, Nov 14, 2016 at 3:07 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 14 November 2016 at 14:03, Maciej Borzęcki <maciej.borzecki@rndity.com>
> wrote:
>>
>> TARGET_ARCH is in fact not exported as you have indicated, there's this
>> piece in meta/conf/bitbake.conf:
>
>
> Ah yes there's a bit of bad interaction between unexport variables, the hack
> that is -e, and the even greater hack that is get_bb_var.
>
> I actually have a patch to change the -e output, I've just noticed that it
> will break selftest as that makes assumptions about -e output, but it does
> solve the problem that you can't reliably use get_bb_var() on unexport.
I suppose that settles it then. I will stick with HOST_ARCH in v3 of the series.
--
Maciej Borzecki
RnDity
^ permalink raw reply
* [PATCH 4/4] sanity.bbclass: fix check_connectivity() for BB_NO_NETWORK = "0"
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1479133967.git.liezhi.yang@windriver.com>
The old code:
network_enabled = not d.getVar('BB_NO_NETWORK', True)
It is True only when BB_NO_NETWORK is not set (None),
but BB_NO_NETWORK = "0" should also be True while "1" means no network,
"0" means need network in a normal case.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/sanity.bbclass | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 7e383f9..c5e3809 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -363,15 +363,19 @@ def check_connectivity(d):
test_uris = (d.getVar('CONNECTIVITY_CHECK_URIS', True) or "").split()
retval = ""
+ bbn = d.getVar('BB_NO_NETWORK', True)
+ if bbn not in (None, '0', '1'):
+ return 'BB_NO_NETWORK should be "0" or "1", but it is "%s"' % bbn
+
# Only check connectivity if network enabled and the
# CONNECTIVITY_CHECK_URIS are set
- network_enabled = not d.getVar('BB_NO_NETWORK', True)
+ network_enabled = not (bbn == '1')
check_enabled = len(test_uris)
- # Take a copy of the data store and unset MIRRORS and PREMIRRORS
- data = bb.data.createCopy(d)
- data.delVar('PREMIRRORS')
- data.delVar('MIRRORS')
if check_enabled and network_enabled:
+ # Take a copy of the data store and unset MIRRORS and PREMIRRORS
+ data = bb.data.createCopy(d)
+ data.delVar('PREMIRRORS')
+ data.delVar('MIRRORS')
try:
fetcher = bb.fetch2.Fetch(test_uris, data)
fetcher.checkstatus()
--
2.10.2
^ permalink raw reply related
* [PATCH 3/4] sanity.bbclass:check_connectivity(): print more error messages
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1479133967.git.liezhi.yang@windriver.com>
This can help fix the problem when the error happens.
Now the error message is:
Fetcher failure for URL: 'https://www.example.com/'. URL https://www.example.com/ doesn't work.
Please ensure your host's network is configured correctly,
or set BB_NO_NETWORK = "1" to disable network access if
all required sources are on local disk.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/sanity.bbclass | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 7682ffb..7e383f9 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -380,7 +380,10 @@ def check_connectivity(d):
# pointed to a support mechanism.
msg = data.getVar('CONNECTIVITY_CHECK_MSG', True) or ""
if len(msg) == 0:
- msg = "%s. Please ensure your network is configured correctly.\n" % err
+ msg = "%s.\n" % err
+ msg += " Please ensure your host's network is configured correctly,\n"
+ msg += " or set BB_NO_NETWORK = \"1\" to disable network access if\n"
+ msg += " all required sources are on local disk.\n"
retval = msg
return retval
--
2.10.2
^ permalink raw reply related
* [PATCH 2/4] testsdk.bbclass: print which file is not found
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1479133967.git.liezhi.yang@windriver.com>
This is helpful when debug.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/testsdk.bbclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/classes/testsdk.bbclass b/meta/classes/testsdk.bbclass
index 43342b1..06b4c50 100644
--- a/meta/classes/testsdk.bbclass
+++ b/meta/classes/testsdk.bbclass
@@ -59,7 +59,7 @@ def testsdk_main(d):
tcname = d.expand("${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh")
if not os.path.exists(tcname):
- bb.fatal("The toolchain is not built. Build it before running the tests: 'bitbake <image> -c populate_sdk' .")
+ bb.fatal("The toolchain %s is not built. Build it before running the tests: 'bitbake <image> -c populate_sdk' ." % tcname)
sdktestdir = d.expand("${WORKDIR}/testimage-sdk/")
bb.utils.remove(sdktestdir, True)
@@ -109,8 +109,8 @@ def testsdkext_main(d):
tcname = d.expand("${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}.sh")
if not os.path.exists(tcname):
- bb.fatal("The toolchain ext is not built. Build it before running the" \
- " tests: 'bitbake <image> -c populate_sdk_ext' .")
+ bb.fatal("The toolchain ext %s is not built. Build it before running the" \
+ " tests: 'bitbake <image> -c populate_sdk_ext' ." % tcname)
testdir = d.expand("${WORKDIR}/testsdkext/")
bb.utils.remove(testdir, True)
--
2.10.2
^ permalink raw reply related
* [PATCH 1/4] populate_sdk_ext.bbclass: use weak assignment for TOOLCHAINEXT_OUTPUTNAME
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1479133967.git.liezhi.yang@windriver.com>
The TOOLCHAINEXT_OUTPUTNAME is different from TOOLCHAIN_OUTPUTNAME, it
is used for eSDK only, so that it doesn't mix with SDK, use "?=" for it
so that other conf file can define it.
If we don't use "?=" here, then we need use forcevariable to redfine it:
TOOLCHAINEXT_OUTPUTNAME_forcevariable = "foo"
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/populate_sdk_ext.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass
index a0856d4..2c9def6 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -77,7 +77,7 @@ COREBASE_FILES ?= " \
SDK_DIR_task-populate-sdk-ext = "${WORKDIR}/sdk-ext"
B_task-populate-sdk-ext = "${SDK_DIR}"
-TOOLCHAINEXT_OUTPUTNAME = "${SDK_NAME}-toolchain-ext-${SDK_VERSION}"
+TOOLCHAINEXT_OUTPUTNAME ?= "${SDK_NAME}-toolchain-ext-${SDK_VERSION}"
TOOLCHAIN_OUTPUTNAME_task-populate-sdk-ext = "${TOOLCHAINEXT_OUTPUTNAME}"
SDK_EXT_TARGET_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}.target.manifest"
--
2.10.2
^ permalink raw reply related
* [PATCH 0/4] Fixes for sanity.bbclass and sdk
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 9303d8055c45a0f6af295d70a6f6a8b9d8d8a7c9:
devtool: add "rename" subcommand (2016-11-07 11:04:17 +0000)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/4fixes
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/4fixes
Robert Yang (4):
populate_sdk_ext.bbclass: use weak assignment for
TOOLCHAINEXT_OUTPUTNAME
testsdk.bbclass: print which file is not found
sanity.bbclass:check_connectivity(): print more error messages
sanity.bbclass: fix check_connectivity() for BB_NO_NETWORK = "0"
meta/classes/populate_sdk_ext.bbclass | 2 +-
meta/classes/sanity.bbclass | 19 +++++++++++++------
meta/classes/testsdk.bbclass | 6 +++---
3 files changed, 17 insertions(+), 10 deletions(-)
--
2.10.2
^ permalink raw reply
* Re: [PATCH v2 00/10] wic: bugfixes & --fixed-size support, tests, selftest: minor fixes
From: Burton, Ross @ 2016-11-14 14:07 UTC (permalink / raw)
To: Maciej Borzęcki; +Cc: Paul Eggleton, Maciej Borzecki, OE-core
In-Reply-To: <CAD4b0_KC108KpwO3kvWqt7LCoqAQZ88_R0b_BXmmuSFAv_xVfQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
On 14 November 2016 at 14:03, Maciej Borzęcki <maciej.borzecki@rndity.com>
wrote:
> TARGET_ARCH is in fact not exported as you have indicated, there's this
> piece in meta/conf/bitbake.conf:
>
Ah yes there's a bit of bad interaction between unexport variables, the
hack that is -e, and the even greater hack that is get_bb_var.
I actually have a patch to change the -e output, I've just noticed that it
will break selftest as that makes assumptions about -e output, but it does
solve the problem that you can't reliably use get_bb_var() on unexport.
Ross
[-- Attachment #2: Type: text/html, Size: 1064 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/10] wic: bugfixes & --fixed-size support, tests, selftest: minor fixes
From: Maciej Borzęcki @ 2016-11-14 14:03 UTC (permalink / raw)
To: Burton, Ross; +Cc: Paul Eggleton, Maciej Borzecki, OE-core
In-Reply-To: <CAJTo0LZ+JpE8G-qvLOQburPb+vFCJ-GB6HnGpKZD80tnLpv86A@mail.gmail.com>
On Mon, Nov 14, 2016 at 2:34 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 14 November 2016 at 10:35, Maciej Borzęcki <maciej.borzecki@rndity.com>
> wrote:
>>
>> Do you think it makes sense to replace TARGET_ARCH check with something
>> like this instead:
>>
>> arch = get_bb_var('HOST_ARCH', 'core-image-minimal')
>>
>> is_x86 = arch in ['i586', 'i686', 'x86-64']
>> if is_x86:
>> self.write_config('IMAGE_FSTYPES += " hddimg"\n'
>> 'MACHINE_FEATURES_append = " efi"\n')
>>
>> Basically, I do not want to build syslinux or set config options that
>> are usable on x86 target when building for other targets.
>
>
> That expression is more likely to work, yeah, though woudn't TARGET_ be more
> suitable than HOST_?
TARGET_ARCH is in fact not exported as you have indicated, there's this
piece in meta/conf/bitbake.conf:
# Make sure TARGET_ARCH isn't exported
# (breaks Makefiles using implicit rules, e.g. quilt, as GNU make has this
# in them, undocumented)
TARGET_ARCH[unexport] = "1"
HOST_ARCH defaults to TARGET_ARCH, I suppose it should be fine to use:
HOST_ARCH = "${TARGET_ARCH}"
Cheers,
--
Maciej Borzecki
RnDity
^ permalink raw reply
* Re: [PATCH] Supply correct argument to .deb pre/postinsts
From: Burton, Ross @ 2016-11-14 14:02 UTC (permalink / raw)
To: Linus Wallgren; +Cc: OE-core
In-Reply-To: <20161114103544.19886-1-linus.wallgren@scypho.com>
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
On 14 November 2016 at 10:35, Linus Wallgren <linus.wallgren@scypho.com>
wrote:
> The debian policy manual and MaintainerScripts wiki page states that the
> postinst script is supposed to be called with the `configure` argument
> at first install, likewise the preinst script is supposed to be called
> with the `install` argument on first install.
>
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
> https://wiki.debian.org/MaintainerScripts
>
Please prefix the commit shortlog with the name of the component being
modified ("lib/oe/package_manager: " seems reasonable to me), and add a
signed-off-by to the commit log.
Ross
[-- Attachment #2: Type: text/html, Size: 1313 bytes --]
^ permalink raw reply
* Re: libdbus-c++
From: thilo.cestonaro @ 2016-11-14 13:33 UTC (permalink / raw)
To: ross.burton@intel.com; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <CAJTo0LZ68DbpCMpHy=5AKuxsHNCjzw2vJMJBd1WC27VTga=fqg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
Am Montag, den 14.11.2016, 10:53 +0000 schrieb Burton, Ross:
>
> On 14 November 2016 at 10:33, thilo.cestonaro@ts.fujitsu.com <thilo.cestonaro@ts.fujitsu.com> wrote:
> > I wanted to build an executable using libdbus-c++ but OE-Core has no recipe providing libdbus-c++, please correct me if I'm wrong here!
> >
> > Is there a reason, other than no one wanted a recipe for libdbus-c++ yet, against the usage of dbus-c++ implementation or why isn't there a recipe for libdbus-c++?
> >
>
> There isn't a recipe in oe-core because nothing in oe-core needs it, and it isn't considered fundamental enough. It seems that every six months someone writes a recipe for dbus-c++ (because they
> have problems and ask for help on the lists) but nobody yet has actually submitted a recipe to meta-oe. You can be that person!
>
Yeah I propably can and will be if I need to write my own. But the funny thing is, that there ones was a meta-oe dbus-c++ recipe and this was removed with the comment, that it didn't work and it's
better to use the one from oe-core :)
http://lists.openembedded.org/pipermail/openembedded-devel/2011-August/079834.html
So I just wanted to make sure, that none exists.
Thanks for that approval!
Cheers,
Thilo
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]
^ permalink raw reply
* Re: libdbus-c++
From: Burton, Ross @ 2016-11-14 13:38 UTC (permalink / raw)
To: thilo.cestonaro@ts.fujitsu.com; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <1479130386.8647.5.camel@ts.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
On 14 November 2016 at 13:33, thilo.cestonaro@ts.fujitsu.com <
thilo.cestonaro@ts.fujitsu.com> wrote:
> Yeah I propably can and will be if I need to write my own. But the funny
> thing is, that there ones was a meta-oe dbus-c++ recipe and this was
> removed with the comment, that it didn't work and it's
> better to use the one from oe-core :)
> http://lists.openembedded.org/pipermail/openembedded-devel/
> 2011-August/079834.html
>
> So I just wanted to make sure, that none exists.
>
That's strange, I can't find any dbus-c++ in oe-core's history. Maybe the
submitter was referring to plain libdbus or something else?
Ross
[-- Attachment #2: Type: text/html, Size: 1274 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/10] wic: bugfixes & --fixed-size support, tests, selftest: minor fixes
From: Burton, Ross @ 2016-11-14 13:34 UTC (permalink / raw)
To: Maciej Borzęcki; +Cc: Paul Eggleton, Maciej Borzecki, OE-core
In-Reply-To: <CAD4b0_LBO_WbaGdaYne7U8KT0QiBb=P5_Th0MjzR24F6px-vXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 716 bytes --]
On 14 November 2016 at 10:35, Maciej Borzęcki <maciej.borzecki@rndity.com>
wrote:
> Do you think it makes sense to replace TARGET_ARCH check with something
> like this instead:
>
> arch = get_bb_var('HOST_ARCH', 'core-image-minimal')
>
> is_x86 = arch in ['i586', 'i686', 'x86-64']
> if is_x86:
> self.write_config('IMAGE_FSTYPES += " hddimg"\n'
> 'MACHINE_FEATURES_append = " efi"\n')
>
> Basically, I do not want to build syslinux or set config options that
> are usable on x86 target when building for other targets.
>
That expression is more likely to work, yeah, though woudn't TARGET_ be
more suitable than HOST_?
Ross
[-- Attachment #2: Type: text/html, Size: 1266 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] go: Add recipes for golang compilers and tools
From: Alexander Kanavin @ 2016-11-14 13:00 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1478887474.23123.233.camel@linuxfoundation.org>
On 11/11/2016 08:04 PM, Richard Purdie wrote:
> This was something that came up at OEDEM. There are several layers with
> several attempts at getting this right, most have some issues.
>
> Whilst we've been pulling things out of core, we also need to consider
> things that perhaps should get added. Having this in core would
> certainly address a number of issues (but is also potentially a
> maintenance burden).
>
> We did agree there that we'd consider this. Obviously input from people
> not there is welcome though and this does need discussion. I'm leaning
> moderately in favour of adding it as things stand.
I guess I would be more open to this if Khem at the same time sent a
patch that explicitly assigns maintainership of all those new recipes.
So please don't merge until that is agreed and done.
Alex
^ permalink raw reply
* [PATCH] binutils: Fix build for c293pcie PPC machine
From: Fabio Berton @ 2016-11-14 12:28 UTC (permalink / raw)
To: openembedded-core
The following patch fix build for c293pcie PPC machine :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=8941017b
This patch is a backport from master branch.
Fix error:
/
|ERROR: binutils-2.27-r0 do_package: runstrip: ''powerpc-fslc-linux-gnuspe-strip'
|--remove-section=.comment --remove-section=.note --strip-unneeded
|'../tmp/work/ppce500v2-fslc-linux-gnuspe/binutils/2.27-r0/package/usr/lib/
|libbfd-2.27.0.20160806.so'' strip command failed with 1
|(b'powerpc-fslc-linux-gnuspe-strip: ../tmp/work/ppce500v2-fslc-linux-gnuspe/
|binutils/2.27-r0/package/usr/lib/stJMAEnm: Not enough room for program headers,
|try linking with -N\npowerpc-fslc-linux-gnuspe-strip:../tmp/work/
|ppce500v2-fslc-linux-gnuspe/binutils/2.27-r0/package/usr/lib/stJMAEnm
|[.note.gnu.build-id]: Bad value\n')
\
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
---
meta/recipes-devtools/binutils/binutils-2.27.inc | 1 +
...01-ppc-apuinfo-for-spe-parsed-incorrectly.patch | 37 ++++++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100644 meta/recipes-devtools/binutils/binutils/0001-ppc-apuinfo-for-spe-parsed-incorrectly.patch
diff --git a/meta/recipes-devtools/binutils/binutils-2.27.inc b/meta/recipes-devtools/binutils/binutils-2.27.inc
index fc81721..75180ea 100644
--- a/meta/recipes-devtools/binutils/binutils-2.27.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.27.inc
@@ -37,6 +37,7 @@ SRC_URI = "\
file://0015-binutils-mips-gas-pic-relax-linkonce.diff \
file://0015-Refine-.cfi_sections-check-to-only-consider-compact-.patch \
file://0016-Fix-seg-fault-in-ARM-linker-when-trying-to-parse-a-b.patch \
+ file://0001-ppc-apuinfo-for-spe-parsed-incorrectly.patch \
"
S = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/0001-ppc-apuinfo-for-spe-parsed-incorrectly.patch b/meta/recipes-devtools/binutils/binutils/0001-ppc-apuinfo-for-spe-parsed-incorrectly.patch
new file mode 100644
index 0000000..d82a0b6
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/0001-ppc-apuinfo-for-spe-parsed-incorrectly.patch
@@ -0,0 +1,37 @@
+From 8941017bc0226b60ce306d5271df15820ce66a53 Mon Sep 17 00:00:00 2001
+From: Alan Modra <amodra@gmail.com>
+Date: Tue, 30 Aug 2016 20:57:32 +0930
+Subject: [PATCH] ppc apuinfo for spe parsed incorrectly
+Organization: O.S. Systems Software LTDA.
+
+apuinfo saying SPE resulted in mach = bfd_mach_ppc_vle due to a
+missing break.
+
+ PR 20531
+ * elf32-ppc.c (_bfd_elf_ppc_set_arch): Add missing "break".
+
+
+Backport from :
+https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=8941017b
+
+Upstream-Status: Backport
+Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
+---
+ bfd/elf32-ppc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/bfd/elf32-ppc.c b/bfd/elf32-ppc.c
+index 95ce1dc..e42ef1c 100644
+--- a/bfd/elf32-ppc.c
++++ b/bfd/elf32-ppc.c
+@@ -2246,6 +2246,7 @@ _bfd_elf_ppc_set_arch (bfd *abfd)
+ case PPC_APUINFO_BRLOCK:
+ if (mach != bfd_mach_ppc_vle)
+ mach = bfd_mach_ppc_e500;
++ break;
+
+ case PPC_APUINFO_VLE:
+ mach = bfd_mach_ppc_vle;
+--
+2.1.4
+
--
2.1.4
^ permalink raw reply related
* Re: libdbus-c++
From: Burton, Ross @ 2016-11-14 10:53 UTC (permalink / raw)
To: thilo.cestonaro@ts.fujitsu.com; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <1479119619.8647.1.camel@ts.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
On 14 November 2016 at 10:33, thilo.cestonaro@ts.fujitsu.com <
thilo.cestonaro@ts.fujitsu.com> wrote:
> I wanted to build an executable using libdbus-c++ but OE-Core has no
> recipe providing libdbus-c++, please correct me if I'm wrong here!
>
> Is there a reason, other than no one wanted a recipe for libdbus-c++ yet,
> against the usage of dbus-c++ implementation or why isn't there a recipe
> for libdbus-c++?
>
There isn't a recipe in oe-core because nothing in oe-core needs it, and it
isn't considered fundamental enough. It seems that every six months
someone writes a recipe for dbus-c++ (because they have problems and ask
for help on the lists) but nobody yet has actually submitted a recipe to
meta-oe. You can be that person!
Ross
[-- Attachment #2: Type: text/html, Size: 1241 bytes --]
^ permalink raw reply
* Re: [PATCH v2 08/10] wic: selftest: do not repeat core-image-minimal
From: Maciej Borzęcki @ 2016-11-14 10:38 UTC (permalink / raw)
To: Ed Bartosh; +Cc: Paul Eggleton, Maciej Borzecki, OE-core
In-Reply-To: <CAD4b0_KMU9ba8-EhtLOLqnp1XGLGryKGLVfYZUQVjaZgeSZsKg@mail.gmail.com>
On Thu, Nov 10, 2016 at 9:33 PM, Maciej Borzęcki
<maciej.borzecki@rndity.com> wrote:
> On Thu, Nov 10, 2016 at 9:15 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 10 November 2016 at 12:18, Maciej Borzecki <maciej.borzecki@rndity.com>
>> wrote:
>>>
>>> def test_qemux86_directdisk(self):
>>> """Test creation of qemux-86-directdisk image"""
>>> image = "qemux86-directdisk"
>>> - self.assertEqual(0, runCmd("wic create %s -e core-image-minimal"
>>> \
>>> - % image).status)
>>> + wic_cmd_vars = {
>>> + 'wks': image,
>>> + 'image': self.OE_IMAGE,
>>> + }
>>> + self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
>>> + % wic_cmd_vars).status)
>>
>>
>> Is it just me who thinks that this is more understandable then?
>>
>> def test_qemux86_directdisk(self):
>> self.assertEqual(0, runCmd("wic create qemux86-directdisk -e
>> core-image-minimal").status)
>> self.assertEqual(1, len(glob(os.path.join(self.resultdir,
>> "core-image-minimal-*direct"))))
>>
>> Not my test case so just an opinion :)
>>
>
> Now that I look at this patch, I probably might have overdone it a little. Let's
> wait and see what Ed thinks about this change. I suppose there might be a need
> for v3 of this series, in which case I'll just drop this patch and rebase the
> remaining patches.
Ed, did you get a chance to review this series?
Cheers,
--
Maciej Borzecki
RnDity
^ permalink raw reply
* [PATCH] Supply correct argument to .deb pre/postinsts
From: Linus Wallgren @ 2016-11-14 10:35 UTC (permalink / raw)
To: openembedded-core; +Cc: Linus Wallgren
The debian policy manual and MaintainerScripts wiki page states that the
postinst script is supposed to be called with the `configure` argument
at first install, likewise the preinst script is supposed to be called
with the `install` argument on first install.
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
https://wiki.debian.org/MaintainerScripts
---
meta/lib/oe/package_manager.py | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 3cee973..ec947c3 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -1993,7 +1993,10 @@ class DpkgPM(OpkgDpkgPM):
"""
def run_pre_post_installs(self, package_name=None):
info_dir = self.target_rootfs + "/var/lib/dpkg/info"
- suffixes = [(".preinst", "Preinstall"), (".postinst", "Postinstall")]
+ ControlScript = collections.namedtuple("ControlScript", ["suffix", "name", "argument"])
+ control_scripts = [
+ ControlScript(".preinst", "Preinstall", "install"),
+ ControlScript(".postinst", "Postinstall", "configure")]
status_file = self.target_rootfs + "/var/lib/dpkg/status"
installed_pkgs = []
@@ -2016,16 +2019,18 @@ class DpkgPM(OpkgDpkgPM):
failed_pkgs = []
for pkg_name in installed_pkgs:
- for suffix in suffixes:
- p_full = os.path.join(info_dir, pkg_name + suffix[0])
+ for control_script in control_scripts:
+ p_full = os.path.join(info_dir, pkg_name + control_script.suffix)
if os.path.exists(p_full):
try:
bb.note("Executing %s for package: %s ..." %
- (suffix[1].lower(), pkg_name))
- subprocess.check_output(p_full, stderr=subprocess.STDOUT)
+ (control_script.name.lower(), pkg_name))
+ subprocess.check_output([p_full, control_script.argument],
+ stderr=subprocess.STDOUT)
except subprocess.CalledProcessError as e:
bb.note("%s for package %s failed with %d:\n%s" %
- (suffix[1], pkg_name, e.returncode, e.output.decode("utf-8")))
+ (control_script.name, pkg_name, e.returncode,
+ e.output.decode("utf-8")))
failed_pkgs.append(pkg_name)
break
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v2 00/10] wic: bugfixes & --fixed-size support, tests, selftest: minor fixes
From: Maciej Borzęcki @ 2016-11-14 10:35 UTC (permalink / raw)
To: Burton, Ross; +Cc: Paul Eggleton, Maciej Borzecki, OE-core
In-Reply-To: <CAJTo0LaLwE+VOJwa3vad2XOc0FmwPpcGOxUvev=7RbnatnOKRg@mail.gmail.com>
On Mon, Nov 14, 2016 at 11:16 AM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 14 November 2016 at 10:02, Maciej Borzęcki <maciej.borzecki@rndity.com>
> wrote:
>>
>> I see that the builds were running with qemux85-64 MACHINE, shouldn't
>> TARGET_ARCH be set to x86-64 then? There's a check that builds
>> syslinux(-native) for x86 archs only since it's not buildable for
>> anything else. Same for HDDIMG.
>
>
> Not quite:
>
> $ MACHINE=qemux86 bitbake core-image-minimal -e | grep ^TARGET_ARCH=
> TARGET_ARCH="i586"
>
> $ MACHINE=qemux86-64 bitbake core-image-minimal -e | grep ^TARGET_ARCH=
> TARGET_ARCH="x86_64"
>
> (had to patch bitbake.conf to export TARGET_ARCH)
Do you think it makes sense to replace TARGET_ARCH check with something
like this instead:
arch = get_bb_var('HOST_ARCH', 'core-image-minimal')
is_x86 = arch in ['i586', 'i686', 'x86-64']
if is_x86:
self.write_config('IMAGE_FSTYPES += " hddimg"\n'
'MACHINE_FEATURES_append = " efi"\n')
Basically, I do not want to build syslinux or set config options that
are usable on x86 target when building for other targets.
>
>>
>> One more question, the assert raised when comparing parted's output is
>> caused by different locale. Do you think it would be ok to just enforce
>> LC_ALL=C when running commands under wic?
>
>
> Yes, enforcing a locale is essential when comparing output of commands.
> Bitbake switches to en_US.UTF8 on startup for the same reason, so feel free
> to use that or C.
I suppose I'll just enforce that in oe-selftest.
--
Maciej Borzecki
RnDity
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox