[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) === {| clas
[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