[oe] State of the world, 2018-06-11
== Failed tasks 2018-06-11 ==
INFO: jenkins-job.sh-1.8.45 Complete log available at
http://logs.nslu2-linux.org/buildlogs/oe/world/thud/log.report.20180611_074339.log
=== common (8) ===
*
sources/meta-openembedded/meta-networking/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_2.0.876.bb:do_compile
*
sources/meta-openembedded/meta-networking/recipes-protocols/tsocks/tsocks_1.8beta5.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-extended/collectd/collectd_5.8.0.bb:do_configure
*
sources/meta-openembedded/meta-oe/recipes-extended/libqb/libqb_1.0.3.bb:do_configure
*
sources/openembedded-core/meta/recipes-graphics/mesa/mesa_18.0.2.bb:do_compile
*
virtual:native:sources/meta-openembedded/meta-networking/recipes-support/wireshark/wireshark_2.6.1.bb:do_compile
*
virtual:native:sources/meta-openembedded/meta-oe/recipes-graphics/fontforge/fontforge_20170731.bb:do_compile
=== common-x86 (1) ===
*
sources/meta-openembedded/meta-webserver/recipes-httpd/hiawatha/hiawatha_10.7.bb:do_package_qa
=== qemuarm (7) ===
*
sources/meta-openembedded/meta-filesystems/recipes-utils/aufs-util/aufs-util_git.bb:do_compile
*
sources/meta-openembedded/meta-gnome/recipes-gnome/gnome-keyring/libgnome-keyring_3.12.0.bb:do_compile
*
sources/meta-openembedded/meta-networking/recipes-support/rdma-core/rdma-core_18.bb:do_install
*
sources/meta-openembedded/meta-oe/recipes-benchmark/libc-bench/libc-bench_20110206.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-extended/redis/redis_4.0.8.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-support/syslog-ng/syslog-ng_3.15.1.bb:do_package
=== qemuarm64 (6) ===
*
sources/meta-openembedded/meta-networking/recipes-connectivity/mbedtls/mbedtls_2.9.0.bb:do_package_qa
*
sources/meta-openembedded/meta-oe/recipes-crypto/libsodium/libsodium_1.0.16.bb:do_fetch
*
sources/meta-openembedded/meta-oe/recipes-devtools/mercurial/mercurial_4.6.1.bb:do_fetch
*
sources/openembedded-core/meta/recipes-devtools/glide/glide_0.13.1.bb:do_package_qa
* sources/openembedded-core/meta/recipes-devtools/go/go_1.9.bb:do_package_qa
*
sources/openembedded-core/meta/recipes-devtools/go/go-dep_0.4.1.bb:do_package_qa
=== qemux86 (17) ===
*
sources/meta-openembedded/meta-networking/recipes-connectivity/rdist/rdist_6.1.5.bb:do_package
*
sources/meta-openembedded/meta-networking/recipes-daemons/opensaf/opensaf_5.18.02.bb:do_compile
*
sources/meta-openembedded/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.3.bb:do_compile
*
sources/meta-openembedded/meta-networking/recipes-netkit/netkit-rsh/netkit-rsh_0.17.bb:do_compile
*
sources/meta-openembedded/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb:do_compile
*
sources/meta-openembedded/meta-networking/recipes-netkit/netkit-telnet/netkit-telnet_0.17.bb:do_configure
*
sources/meta-openembedded/meta-networking/recipes-support/rdma-core/rdma-core_18.bb:do_compile
*
sources/meta-openembedded/meta-networking/recipes-support/spice/spice_git.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-core/dbus/dbus-broker_git.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-extended/upm/upm_git.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-kernel/crash/crash_7.2.0.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-kernel/minicoredumper/minicoredumper_2.0.0.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-multimedia/alsa/alsa-oss_1.0.28.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-support/syslog-ng/syslog-ng_3.15.1.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-test/pm-qa/pm-qa_git.bb:do_compile
*
sources/openembedded-core/meta/recipes-support/libunwind/libunwind_1.2.1.bb:do_compile
=== qemux86_64 (2) ===
*
sources/meta-openembedded/meta-networking/recipes-connectivity/civetweb/civetweb_git.bb:do_compile
*
sources/meta-openembedded/meta-oe/recipes-support/open-vm-tools/open-vm-tools_10.1.5.bb:do_compile
=== Number of failed tasks (78) ===
{| class=wikitable
|-
|| qemuarm || 15 ||
http://logs.nslu2-linux.org/buildlogs/oe/world/thud/log.world.qemuarm.20180611_045942.log/
||
|-
|| qemuarm64 || 18 ||
http://logs.nslu2-linux.org/buildlogs/oe/world/thud/log.world.qemuarm64.20180611_055718.log/
||
|-
|| qemux86 || 28 ||
http://logs.nslu2-linux.org/buildlogs/oe/world/thud/log.world.qemux86.20180611_045951.log/
||
|-
|| qemux86_64 || 17 ||
http://logs.nslu2-linux.org/buildlogs/oe/world/thud/log.world.qemux86-64.20180611_055701.log/
||
|}
=== PNBLACKLISTs (0) ===
=== QA issues (40) ===
{|
[oe] [meta-networking][PATCH] samba: add dynamic packages regexp for auth and pdb modules
Since those modules are dynamically split into sub-packages, they need
a regexp added to PACKAGES_DYNAMIC in order for the samba recipe to
RPROVIDE those packages. Without that, those packages are only known as
RRECOMMENDS for samba-base, which can be an issue when building an image
with NO_RECOMMENDATIONS = "1".
---
meta-networking/recipes-connectivity/samba/samba_4.7.6.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-networking/recipes-connectivity/samba/samba_4.7.6.bb
b/meta-networking/recipes-connectivity/samba/samba_4.7.6.bb
index a8517c5..ee298b3 100644
--- a/meta-networking/recipes-connectivity/samba/samba_4.7.6.bb
+++ b/meta-networking/recipes-connectivity/samba/samba_4.7.6.bb
@@ -218,6 +218,7 @@ python samba_populate_packages() {
}
PACKAGESPLITFUNCS_prepend = "samba_populate_packages "
+PACKAGES_DYNAMIC = "samba-auth-.* samba-pdb-.*"
RDEPENDS_${PN} += "${PN}-base ${PN}-python ${PN}-dsdb-modules"
RDEPENDS_${PN}-python += "pytalloc python-tdb"
--
2.1.4
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-java][PATCHv3] jdepend: Retrieve source from Git rather than tarball
The change below doesn't seem to have been merged. Is there anything else
that I need to do?
Thanks.
Mike.
On Tuesday 08 May 2018 at 10:36:31 +0100, Mike Crowe wrote:
> When Bitbake downloads jdepend-2.9.1.zip itself and I download
> https://github.com/clarkware/jdepend/blob/master/dist/jdepend-2.9.1.zip ,
> the calculated hashes don't match the ones included in the recipe.
>
> The hashes were last changed in commit
> dd5c43fca8289b8795a9214aee616775e1493109 on 1st March, but GitHub claims
> that the file being downloaded was published on 20th January, so I can't
> explain why they are wrong. Ross Burton has provided a plausible reason in
> http://lists.openembedded.org/pipermail/openembedded-devel/2017-September/114916.html
> where he also advocates switching to using Git repositories rather than
> GitHub-generated tarballs.
>
> It seems that we can't really rely on these tarballs to remain unchanged,
> so let's download the Git hash that corresponds to v2.9.1 instead. This
> should always remain valid.
>
> Cc: André Draszik
> Cc: Khem Raj
> Cc: Ross Burton
> Signed-off-by: Mike Crowe
> ---
> recipes-core/jdepend/jdepend_2.9.1.bb | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/recipes-core/jdepend/jdepend_2.9.1.bb
> b/recipes-core/jdepend/jdepend_2.9.1.bb
> index 5f09a8b..dfbf493 100644
> --- a/recipes-core/jdepend/jdepend_2.9.1.bb
> +++ b/recipes-core/jdepend/jdepend_2.9.1.bb
> @@ -6,7 +6,9 @@ LIC_FILES_CHKSUM =
> "file://LICENSE;md5=f5777d32a7709d558c2877d4a6616230"
>
> HOMEPAGE = "https://github.com/clarkware/jdepend;
>
> -SRC_URI =
> "https://github.com/clarkware/jdepend/archive/${PV}.zip;downloadfilename=${BP}.zip;
> +SRC_URI = "git://github.com/clarkware/jdepend"
> +SRCREV = "57980590313a5dbde236a3eb2c8958e9e53e6a10"
> +S = "${WORKDIR}/git"
>
> inherit java-library
>
> @@ -18,7 +20,4 @@ do_compile() {
>fastjar cf ${JARFILENAME} -C build .
> }
>
> -SRC_URI[md5sum] = "9b91efe1d770e023893f89f4dde8434e"
> -SRC_URI[sha256sum] =
> "536b5082d64e4f4514ce30178f36c7a31b34d969275f278f72e522e7f7c9"
> -
> BBCLASSEXTEND = "native"
> --
> 2.11.0
>
>
> --
> ___
> 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
[oe] [meta-oe][PATCH] nano: Upgrade 2.9.7 -> 2.9.8
Upgrade nano to 2.9.8, the latest version as of 2 June 2018:
https://www.nano-editor.org/dist/v2.9/ChangeLog
Signed-off-by: Leon Anavi
---
meta-oe/recipes-support/nano/nano_2.9.7.bb | 8
meta-oe/recipes-support/nano/nano_2.9.8.bb | 4
2 files changed, 4 insertions(+), 8 deletions(-)
delete mode 100644 meta-oe/recipes-support/nano/nano_2.9.7.bb
create mode 100644 meta-oe/recipes-support/nano/nano_2.9.8.bb
diff --git a/meta-oe/recipes-support/nano/nano_2.9.7.bb
b/meta-oe/recipes-support/nano/nano_2.9.7.bb
deleted file mode 100644
index 419e5406b..0
--- a/meta-oe/recipes-support/nano/nano_2.9.7.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-include nano.inc
-
-do_install_append_libc-musl () {
- rm -rf ${D}${libdir}/charset.alias
- rmdir ${D}${libdir}
-}
-SRC_URI[md5sum] = "e0c6d76c93932f6c41c40842952495f7"
-SRC_URI[sha256sum] =
"b64ab017305b1777e97b5b9b07b31db8aeebfc3e8719f61e8da1cf3866d344bd"
diff --git a/meta-oe/recipes-support/nano/nano_2.9.8.bb
b/meta-oe/recipes-support/nano/nano_2.9.8.bb
new file mode 100644
index 0..aa6e9ff16
--- /dev/null
+++ b/meta-oe/recipes-support/nano/nano_2.9.8.bb
@@ -0,0 +1,4 @@
+include nano.inc
+
+SRC_URI[md5sum] = "31714360342f9baa344e2fa574c144db"
+SRC_URI[sha256sum] =
"c2deac31ba4d3fd27a42fafcc47ccf499296cc69a422bbecab63f2933ea85488"
--
2.14.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] nano: Upgrade 2.9.7 -> 2.9.8
Hi Khem,
On 6.06.2018 04:05, Khem Raj wrote:
> On Mon, Jun 4, 2018 at 9:29 AM, Leon Anavi wrote:
>> Upgrade nano to 2.9.8, the latest version as of 2 June 2018:
>> https://www.nano-editor.org/dist/v2.9/ChangeLog
>>
>> Signed-off-by: Leon Anavi
>> ---
>> meta-oe/recipes-support/nano/nano_2.9.7.bb | 8
>> meta-oe/recipes-support/nano/nano_2.9.8.bb | 8
>> 2 files changed, 8 insertions(+), 8 deletions(-)
>> delete mode 100644 meta-oe/recipes-support/nano/nano_2.9.7.bb
>> create mode 100644 meta-oe/recipes-support/nano/nano_2.9.8.bb
>>
>> diff --git a/meta-oe/recipes-support/nano/nano_2.9.7.bb
>> b/meta-oe/recipes-support/nano/nano_2.9.7.bb
>> deleted file mode 100644
>> index 419e5406b..0
>> --- a/meta-oe/recipes-support/nano/nano_2.9.7.bb
>> +++ /dev/null
>> @@ -1,8 +0,0 @@
>> -include nano.inc
>> -
>> -do_install_append_libc-musl () {
>> - rm -rf ${D}${libdir}/charset.alias
>> - rmdir ${D}${libdir}
> This is failing on musl like below
>
> | make[1]: Leaving directory
> '/mnt/a/oe/build/tmp/work/core2-64-bec-linux-musl/nano/2.9.8-r0/build'
> | rmdir: failed to remove
> '/mnt/a/oe/build/tmp/work/core2-64-bec-linux-musl/nano/2.9.8-r0/image/usr/lib':
> No such file or directory
> | WARNING:
> /mnt/a/oe/build/tmp/work/core2-64-bec-linux-musl/nano/2.9.8-r0/temp/run.do_install.40342:1
> exit 1 from 'rmdir
> /mnt/a/oe/build/tmp/work/core2-64-bec-linux-musl/nano/2.9.8-r0/image/usr/lib'
>
>
> I think you might need --ignore-fail-on-non-empty
> option with rmdir
Thank you for the feedback. I reproduced the issue with musl. The
directory that rmdir tries to remove doesn't exist at all so I think the
whole do_install_append_libc-musl is redundant. I did a few tests to
confirm this and I will send a new version of the patch shortly.
Thanks,
Leon
>
>> -}
>> -SRC_URI[md5sum] = "e0c6d76c93932f6c41c40842952495f7"
>> -SRC_URI[sha256sum] =
>> "b64ab017305b1777e97b5b9b07b31db8aeebfc3e8719f61e8da1cf3866d344bd"
>> diff --git a/meta-oe/recipes-support/nano/nano_2.9.8.bb
>> b/meta-oe/recipes-support/nano/nano_2.9.8.bb
>> new file mode 100644
>> index 0..ac5f0622b
>> --- /dev/null
>> +++ b/meta-oe/recipes-support/nano/nano_2.9.8.bb
>> @@ -0,0 +1,8 @@
>> +include nano.inc
>> +
>> +do_install_append_libc-musl () {
>> + rm -rf ${D}${libdir}/charset.alias
>> + rmdir ${D}${libdir}
>> +}
>> +SRC_URI[md5sum] = "31714360342f9baa344e2fa574c144db"
>> +SRC_URI[sha256sum] =
>> "c2deac31ba4d3fd27a42fafcc47ccf499296cc69a422bbecab63f2933ea85488"
>> --
>> 2.14.1
>>
>> --
>> ___
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
Leon Anavi
Software Engineer
konsulko.com
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-java] maintainer status
On Mon, Jun 11, 2018 at 02:30:35PM +0300, Maxin B. John wrote: > Hi Richard, > > Sorry for my long silence here in the list ( was away due to a personal loss). > > > On Thu, Jun 07, 2018 at 04:32:36PM +0200, > prvs=68935beb6=richard.leit...@skidata.com wrote: > > On 06/07/2018 03:56 PM, Otavio Salvador wrote: > > > On Thu, Jun 7, 2018 at 10:53 AM, Richard Leitner > > > wrote: > > > > > >> As I'm using this layer now for quite a few years I'll be glad to help > > >> you with > > >> the maintainership of meta-java. Nonetheless I have to admit that I have > > >> no > > >> experience in maintaining an openembedded layer ;-) > > >> Therefore if you're still interested I'd have some questions regarding > > >> the > > >> "strategic" targets, workflows and stuff like that... > > > > > > Awesome, new energy! > > Great ! > > > > Sure, go ahead and ask :-D > > > > > > > Thanks :-) > > > > So here are some question that currently came to my mind: > > > > * do you use some kind of patch management software (like patchwork)? > > meta-java doesn't use patchwork till now. Yes, but we are using the normal the oe mailinglist, that is why you can find the patches with the meta-java tag in the current patchwork too. Bye Henning -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-java] maintainer status
Hi Richard, Sorry for my long silence here in the list ( was away due to a personal loss). On Thu, Jun 07, 2018 at 04:32:36PM +0200, prvs=68935beb6=richard.leit...@skidata.com wrote: > On 06/07/2018 03:56 PM, Otavio Salvador wrote: > > On Thu, Jun 7, 2018 at 10:53 AM, Richard Leitner > > wrote: > > > >> As I'm using this layer now for quite a few years I'll be glad to help you > >> with > >> the maintainership of meta-java. Nonetheless I have to admit that I have no > >> experience in maintaining an openembedded layer ;-) > >> Therefore if you're still interested I'd have some questions regarding the > >> "strategic" targets, workflows and stuff like that... > > > > Awesome, new energy! Great ! > > Sure, go ahead and ask :-D > > > > Thanks :-) > > So here are some question that currently came to my mind: > > * do you use some kind of patch management software (like patchwork)? meta-java doesn't use patchwork till now. > * are there any "quality gate tests" for patches being applied to master or > stable branches? At the moment, we dont have enough tests in meta-java (It will be good to have more selftests). Moving from manual build/testing to a Jenkins based automated one was briefly tested in a personal setup. > * is there something like a build/test robot for patches and/or branches? Not yet. Tested a travis based setup in github. Testing wasn't successful due to the resource restrictions (mainly storage) there. > * should we use the master-next branch for staging new patches? Preferably - yes. > * is there a reason for not having OpenJDK >8 recipes? Nothing that I can remember :) > * if the above is answered with something like "because nobody submitted > them": Should we try to follow the current OpenJDK release model (a feature > release every six month)? +1, That will be nice. > * based on what scheduling are the stable branches created? Yocto Project > release dates I guess? Yes. > * what kind of patches should be applied/backported to the stable branches? Depends. Mostly security based patches and others, based on urgency/demand. > > I think that's all for now (but presumably some more question will follow > during the next weeks) ;-) > > regards;Richard.L Best Regards, Maxin -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-java][PATCH 2/2] openjdk-8: combine the -dbg package
On 2018年06月08日 18:07, Richard Leitner wrote:
On 06/08/2018 11:02 AM, Wenlin Kang wrote:
On 2018年06月08日 15:39, Richard Leitner wrote:
Hi,
thank you for you patch!
On 06/07/2018 11:24 AM, Wenlin Kang wrote:
One recipe should only have one -dbg package, because OE only picks
up all .debug file into the last one -dbg package listed in variable
PACKAGES.
Why should one recipe, altough it conains multiple packages have only
one dbg package? Shouldn't the openjdk-8-demo-dbg package contain the
debug information for the openjdk-8-demo package?
This may be OE's policy, if one recipe contain multiple -dbg package , other
-dbg packages all will be
a empty pacakge, only have one will contain all .debug file, you can see the source
"meta/classes/package.bbclass"
But obviously the demo-dbg package isn't empty because it has its "FILES"
defined ;-)
Hi Richard
You can check each -dbg directory under packages-split/, will find only
one -dbg package has .debug file.
1129 python populate_packages () {
1130 import glob, re
1156 for pkg in packages.split():
1157 if pkg in package_list:
1158 msg = "%s is listed in PACKAGES multiple times, this leads to
packaging errors." % pkg
1159 package_qa_handle_error("packages-list", msg, d)
1160 # If debug-with-srcpkg mode is enabled then the src package will
have
1161 # priority over dbg package when assigning the files.
1162 # This allows src package to include source files and remove them
from dbg.
1163 elif split_source_package and pkg.endswith("-src"):
1164 package_list.insert(0, pkg)
1165 elif autodebug and pkg.endswith("-dbg") and not split_source_package:
<==
1166 package_list.insert(0, pkg)
1167 else:
1168 package_list.append(pkg)
1169 d.setVar('PACKAGES', ' '.join(package_list))
1170 pkgdest = d.getVar('PKGDEST')
...
1177 debug = []
1178 for root, dirs, files in cpath.walk(dvar):
1179 dir = root[len(dvar):]
1180 if not dir:
1181 dir = os.sep
1182 for f in (files + dirs):
1183 path = "." + os.path.join(dir, f)
1184 if "/.debug/" in path or path.endswith("/.debug"):
<==
1185 debug.append(path)
1186
Nonehteless according to my first quick test the demo-dbg package
contains lots of other debug information too...
So maybe it would be the better way to fix the content of the different
dbg packages rather than removing one?
I also thought this, but after discussing with the other guys, the result is
a recipe can only have
a -dbg package, and this is OE's policy.
Do you have a pointer to this discussion (or if it exists to the according
documentation) for us?
Thanks & regards;Richard.L
--
Thanks,
Wenlin Kang
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-java][PATCH 2/2] openjdk-8: combine the -dbg package
Hi Richard,
On 06/08/2018 06:07 PM, Richard Leitner wrote:
On 06/08/2018 11:02 AM, Wenlin Kang wrote:
On 2018年06月08日 15:39, Richard Leitner wrote:
Hi,
thank you for you patch!
On 06/07/2018 11:24 AM, Wenlin Kang wrote:
One recipe should only have one -dbg package, because OE only picks
up all .debug file into the last one -dbg package listed in variable
PACKAGES.
Why should one recipe, altough it conains multiple packages have only
one dbg package? Shouldn't the openjdk-8-demo-dbg package contain the
debug information for the openjdk-8-demo package?
This may be OE's policy, if one recipe contain multiple -dbg package , other
-dbg packages all will be
a empty pacakge, only have one will contain all .debug file, you can see the source
"meta/classes/package.bbclass"
But obviously the demo-dbg package isn't empty because it has its "FILES"
defined ;-)
1129 python populate_packages () {
1130 import glob, re
1156 for pkg in packages.split():
1157 if pkg in package_list:
1158 msg = "%s is listed in PACKAGES multiple times, this leads to
packaging errors." % pkg
1159 package_qa_handle_error("packages-list", msg, d)
1160 # If debug-with-srcpkg mode is enabled then the src package will
have
1161 # priority over dbg package when assigning the files.
1162 # This allows src package to include source files and remove them
from dbg.
1163 elif split_source_package and pkg.endswith("-src"):
1164 package_list.insert(0, pkg)
1165 elif autodebug and pkg.endswith("-dbg") and not split_source_package:
<==
1166 package_list.insert(0, pkg)
1167 else:
1168 package_list.append(pkg)
1169 d.setVar('PACKAGES', ' '.join(package_list))
1170 pkgdest = d.getVar('PKGDEST')
...
1177 debug = []
1178 for root, dirs, files in cpath.walk(dvar):
1179 dir = root[len(dvar):]
1180 if not dir:
1181 dir = os.sep
1182 for f in (files + dirs):
1183 path = "." + os.path.join(dir, f)
1184 if "/.debug/" in path or path.endswith("/.debug"):
<==
1185 debug.append(path)
1186
Nonehteless according to my first quick test the demo-dbg package
contains lots of other debug information too...
So maybe it would be the better way to fix the content of the different
dbg packages rather than removing one?
I also thought this, but after discussing with the other guys, the result is
a recipe can only have
a -dbg package, and this is OE's policy.
Do you have a pointer to this discussion (or if it exists to the according
documentation) for us?
For oe-core's recipes, each recipe only has one dbg package, split dbg packages
doesn't make any sense since they usually can't be run independently. Please
see oe-core's commit:
commit a3b000643898d7402b9e57c02e8d10e677cc9722
Author: Ross Burton
Date: Tue Dec 15 16:32:43 2015 +
meta: more removals of redunant FILES_${PN}-dbg
In some recipes overly-split -dbg packages were merged into PN-dbg. Unless
there's a very good reason, recipes should have a single -dev and -dbg
package.
// Robert
// Robert
Thanks & regards;Richard.L
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
