Re: [meta-virtualization] RFC : [PATCH] xen: remove xen-bootimg.inc

2017-08-24 Thread Bruce Ashfield
On Thu, Aug 24, 2017 at 2:46 PM,  wrote:

> From: Christopher Clark 
>
> This inc file has not been used within meta-virtualization since:
> Date:   Tue Sep 10 21:02:41 2013 -0400
> commit 214c4715f0ed53ba9c499932b0b6ee3f602ff89f
>
> and has needed updating since the changes in:
> Date:   Wed Feb 24 01:23:58 2016 -0800
> git://git.openembedded.org/openembedded-core
> commit e38c94d6bf83ed3ca7f046d9503e81b927487bf2
>
> Signed-off-by: Christopher Clark 
> ---
>
> This inc file either needs updating to change SYSLINUXCFG to SYSLINUX_CFG
> or alternatively it could be removed. Since it is no longer used within
> meta-virtualization, and I cannot find a reference to it elsewhere via
> web search engine, it requires further work to test any change to this
> file.
> This patch just removes it.
>
>
No objections from me.

I'll let this sit for a day or two and see if we get any objections .. ACKs
would be great as well.

Bruce


>
>  recipes-extended/images/xen-bootimg.inc | 35
> -
>  1 file changed, 35 deletions(-)
>  delete mode 100644 recipes-extended/images/xen-bootimg.inc
>
> diff --git a/recipes-extended/images/xen-bootimg.inc
> b/recipes-extended/images/xen-bootimg.inc
> deleted file mode 100644
> index 093aa68..000
> --- a/recipes-extended/images/xen-bootimg.inc
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -SYSLINUX_TIMEOUT = "10"
> -SYSLINUX_LABEL = "boot"
> -SYSLINUX_XEN_APPEND = "dom0_mem=1048576"
> -SYSLINUX_KERNEL_APPEND = "ramdisk_size=32768 root=/dev/ram0 rw
> console=tty0 console=ttyS0,115200n8"
> -#LABELS_append = " ${SYSLINUX_LABEL} "
> -
> -INITRD = "${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.cpio.lzma"
> -
> -do_bootimg[depends] += "${IMAGE_BASENAME}:do_rootfs"
> -
> -inherit bootimg
> -
> -syslinux_populate_append() {
> -   install -m 0444 ${STAGING_LIBDIR}/syslinux/mboot.c32
> ${HDDDIR}${SYSLINUXDIR}/mboot.c32
> -}
> -
> -grubefi_populate_append() {
> -   install -m 0644 ${DEPLOY_DIR_IMAGE}/xen-${MACHINE}.gz
> ${DEST}${EFIDIR}/xen.gz
> -}
> -
> -populate_append() {
> -   install -m 0644 ${DEPLOY_DIR_IMAGE}/xen-${MACHINE}.gz
> ${DEST}/xen.gz
> -}
> -
> -build_syslinux_cfg() {
> -   echo ALLOWOPTIONS 1 > ${SYSLINUXCFG}
> -   echo SERIAL 0 115200 > ${SYSLINUXCFG}
> -   echo DEFAULT ${SYSLINUX_LABEL} >> ${SYSLINUXCFG}
> -   echo TIMEOUT ${SYSLINUX_TIMEOUT} >> ${SYSLINUXCFG}
> -   echo PROMPT 1 >> ${SYSLINUXCFG}
> -   echo LABEL ${SYSLINUX_LABEL} >> ${SYSLINUXCFG}
> -   echo KERNEL mboot.c32 >> ${SYSLINUXCFG}
> -   echo APPEND xen.gz ${SYSLINUX_XEN_APPEND} --- vmlinuz
> ${SYSLINUX_KERNEL_APPEND} --- initrd >> ${SYSLINUXCFG}
> -}
> -
> --
> 2.7.4
>
> --
> ___
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


Re: [meta-virtualization] [PATCH] Added recipe for the Singularity container platform.

2017-08-24 Thread Bruce Ashfield
On Thu, Aug 24, 2017 at 8:33 AM, Alexandru Tiniuc <
tiniuc.alexan...@gmail.com> wrote:

> Singularity is a container platform built on the principle of mobility
> of compute.  It is designed to be used on HPC clusters and, unlike
> Docker, it does not require root access to mount an image. In addition,
> it can use Docker images out-of-the-box and it can pull them from the
> Docker Hub. For more information, see singularity.lbl.gov
>
> This recipe enables building the Singularity container platform.
> Additionally, it creates a symlink from /usr/bin/python3 to
> /usr/bin/python, as well as a symlink to where python3 expects
> CA certificates to be.
>
> I have tested it on a Raspberry Pi 3: I successfully built and run
> arm32v7 images from Docker Hub. Make sure you have the right image for
> your CPU architecture: it defaults to amd64.
>

Looks reasonable to me.

I do have one additional request though.

Even if it is a really simple concept, can you create a README that shows
the
commands to run a simple sanity/smoke test. That way, we'll have a guide in
the
checked out layer on how to use the infrastructure.

Cheers,

Bruce


>
> Signed-off-by: Alexandru Tiniuc 
> ---
>  recipes-containers/singularity/singularity_git.bb | 35
> +++
>  1 file changed, 35 insertions(+)
>  create mode 100644 recipes-containers/singularity/singularity_git.bb
>
> diff --git a/recipes-containers/singularity/singularity_git.bb
> b/recipes-containers/singularity/singularity_git.bb
> new file mode 100644
> index 000..d0fbeb9
> --- /dev/null
> +++ b/recipes-containers/singularity/singularity_git.bb
> @@ -0,0 +1,35 @@
> +# Skip QA check for library symbolic links (core issue is a packaging
> problem within
> +# Singularity build / config: read up on the dev-so test for more info)
> +INSANE_SKIP_${PN} += "dev-so"
> +
> +RDEPENDS_${PN} += "glibc python3 ca-certificates openssl"
> +# Singularity expects to find python3 under the name python, therefore
> both
> +# cannot be installed at the same time.
> +RCONFLICTS_${PN} = "python"
> +
> +LICENSE = "BSD"
> +LIC_FILES_CHKSUM = "file://COPYRIGHT.md;md5=
> be78c34e483dd7d8439358b1e024b294 \
> +file://LICENSE-LBNL.md;md5=
> 45a007b527e1a9507aa7fa869f8d7ede \
> +file://LICENSE.md;md5=df4326b473db6424033f1d98a5645e30
> \
> +file://debian/copyright;md5=
> ed267cf386d9b75ab1f27f407e935b10"
> +
> +SRC_URI = "git://github.com/singularityware/singularity.
> git;protocol=https"
> +PV = "2.3.1+git${SRCPV}"
> +SRCREV = "e214d4ebf0a1274b1c63b095fd55ae61c7e92947"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit pythonnative autotools-brokensep
> +EXTRA_OECONF = "--prefix=/usr/local"
> +
> +pkg_postinst_${PN}() {
> +# Singularity requires "python" to resolve to "python3" within the
> commandline.
> +# This creates a symbolic link from python3 to python. A side-effect
> of this is
> +# that scripts which expect Python 2 may fail to run correctly.
> +ln -sr $D${bindir}/python3 $D${bindir}/python
> +
> +# python3 expects CA certificates to be installed in a different
> place to where
> +# they are actually installed. These lines link the two locations.
> +rm -r $D${libdir}/ssl-1.1/certs
> +ln -sr $D${sysconfdir}/ssl/certs $D${libdir}/ssl-1.1
> +}
> --
> 2.1.4
>
> --
> ___
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


[meta-virtualization] RFC : [PATCH] xen: remove xen-bootimg.inc

2017-08-24 Thread christopher . w . clark
From: Christopher Clark 

This inc file has not been used within meta-virtualization since:
Date:   Tue Sep 10 21:02:41 2013 -0400
commit 214c4715f0ed53ba9c499932b0b6ee3f602ff89f

and has needed updating since the changes in:
Date:   Wed Feb 24 01:23:58 2016 -0800
git://git.openembedded.org/openembedded-core
commit e38c94d6bf83ed3ca7f046d9503e81b927487bf2

Signed-off-by: Christopher Clark 
---

This inc file either needs updating to change SYSLINUXCFG to SYSLINUX_CFG
or alternatively it could be removed. Since it is no longer used within
meta-virtualization, and I cannot find a reference to it elsewhere via
web search engine, it requires further work to test any change to this file.
This patch just removes it.


 recipes-extended/images/xen-bootimg.inc | 35 -
 1 file changed, 35 deletions(-)
 delete mode 100644 recipes-extended/images/xen-bootimg.inc

diff --git a/recipes-extended/images/xen-bootimg.inc 
b/recipes-extended/images/xen-bootimg.inc
deleted file mode 100644
index 093aa68..000
--- a/recipes-extended/images/xen-bootimg.inc
+++ /dev/null
@@ -1,35 +0,0 @@
-SYSLINUX_TIMEOUT = "10"
-SYSLINUX_LABEL = "boot"
-SYSLINUX_XEN_APPEND = "dom0_mem=1048576"
-SYSLINUX_KERNEL_APPEND = "ramdisk_size=32768 root=/dev/ram0 rw console=tty0 
console=ttyS0,115200n8"
-#LABELS_append = " ${SYSLINUX_LABEL} "
-
-INITRD = "${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.cpio.lzma"
-
-do_bootimg[depends] += "${IMAGE_BASENAME}:do_rootfs"
-
-inherit bootimg
-
-syslinux_populate_append() {
-   install -m 0444 ${STAGING_LIBDIR}/syslinux/mboot.c32 
${HDDDIR}${SYSLINUXDIR}/mboot.c32
-}
-
-grubefi_populate_append() {
-   install -m 0644 ${DEPLOY_DIR_IMAGE}/xen-${MACHINE}.gz 
${DEST}${EFIDIR}/xen.gz
-}
-
-populate_append() {
-   install -m 0644 ${DEPLOY_DIR_IMAGE}/xen-${MACHINE}.gz ${DEST}/xen.gz
-}
-
-build_syslinux_cfg() {
-   echo ALLOWOPTIONS 1 > ${SYSLINUXCFG}
-   echo SERIAL 0 115200 > ${SYSLINUXCFG}
-   echo DEFAULT ${SYSLINUX_LABEL} >> ${SYSLINUXCFG}
-   echo TIMEOUT ${SYSLINUX_TIMEOUT} >> ${SYSLINUXCFG}
-   echo PROMPT 1 >> ${SYSLINUXCFG}
-   echo LABEL ${SYSLINUX_LABEL} >> ${SYSLINUXCFG}
-   echo KERNEL mboot.c32 >> ${SYSLINUXCFG}
-   echo APPEND xen.gz ${SYSLINUX_XEN_APPEND} --- vmlinuz 
${SYSLINUX_KERNEL_APPEND} --- initrd >> ${SYSLINUXCFG}
-}
-
-- 
2.7.4

-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


Re: [meta-virtualization] [m-c-s][PATCH] uwsgi: fixups for gcc 7.x

2017-08-24 Thread Bruce Ashfield
merged.

Bruce

On Wed, Aug 23, 2017 at 3:20 PM, Mark Asselstine <
mark.asselst...@windriver.com> wrote:

> Apply several upstream patches to fixup fallthrough switch
> statements. This fixes build failures such as:
>
> | core/hash.c:44:13: error: this statement may fall through
> [-Werror=implicit-fallthrough=]
> |h ^= key[2] << 16;
> |~~^~~
> | core/hash.c:45:7: note: here
> |case 2:
> |^~~~
>
> Signed-off-by: Mark Asselstine 
> ---
>  ...icit-breaks-to-avoid-implicit-passthrough.patch | 50
> ++
>  ...icit-breaks-to-avoid-implicit-passthrough.patch | 50
> ++
>  meta-openstack/recipes-extended/uwsgi/uwsgi_git.bb |  2 +
>  3 files changed, 102 insertions(+)
>  create mode 100644 meta-openstack/recipes-extended/uwsgi/files/Add-
> explicit-breaks-to-avoid-implicit-passthrough.patch
>  create mode 100644 meta-openstack/recipes-extended/uwsgi/files/more-Add-
> explicit-breaks-to-avoid-implicit-passthrough.patch
>
> diff --git a/meta-openstack/recipes-extended/uwsgi/files/Add-
> explicit-breaks-to-avoid-implicit-passthrough.patch
> b/meta-openstack/recipes-extended/uwsgi/files/Add-
> explicit-breaks-to-avoid-implicit-passthrough.patch
> new file mode 100644
> index 000..4b9c015
> --- /dev/null
> +++ b/meta-openstack/recipes-extended/uwsgi/files/Add-
> explicit-breaks-to-avoid-implicit-passthrough.patch
> @@ -0,0 +1,50 @@
> +From 0a14d0f0425f00421a69f0ca8e09a92cfdfc6a36 Mon Sep 17 00:00:00 2001
> +From: Paul Tagliamonte 
> +Date: Mon, 7 Aug 2017 11:18:56 -0400
> +Subject: [PATCH] Add explicit breaks to avoid implicit passthrough.
> +
> +commit 0a14d0f0425f00421a69f0ca8e09a92cfdfc6a36 from upstream
> +git://github.com/unbit/uwsgi.git
> +
> +-Werror=implicit-fallthrough was added in gcc 7.1, which will
> +throw a compile error if a switch has an implicit passthrough.
> +
> +Seeing as how this switch doesn't appear to depend on passthrough to
> +function correctly, I've added explicit breaks to the switch.
> +
> +From https://gcc.gnu.org/gcc-7/changes.html:
> +
> +-Wimplicit-fallthrough warns when a switch case falls through. This
> +warning has five different levels. The compiler is able to parse a wide
> +range of fallthrough comments, depending on the level. It also handles
> +control-flow statements, such as ifs. It's possible to suppress the
> +warning by either adding a fallthrough comment, or by using a null
> +statement: __attribute__ ((fallthrough)); (C, C++), or [[fallthrough]];
> +(C++17), or [[gnu::fallthrough]]; (C++11/C++14). This warning is enabled
> +by -Wextra.
> +---
> + core/hash.c | 3 +++
> + 1 file changed, 3 insertions(+)
> +
> +diff --git a/core/hash.c b/core/hash.c
> +index a1288fa..9ae6bd2 100644
> +--- a/core/hash.c
>  b/core/hash.c
> +@@ -42,11 +42,14 @@ static uint32_t murmur2_hash(char *key, uint64_t
> keylen) {
> +   switch (keylen) {
> +   case 3:
> +   h ^= key[2] << 16;
> ++  break;
> +   case 2:
> +   h ^= key[1] << 8;
> ++  break;
> +   case 1:
> +   h ^= key[0];
> +   h *= 0x5bd1e995;
> ++  break;
> +   }
> +
> +   h ^= h >> 13;
> +--
> +2.7.4
> +
> diff --git a/meta-openstack/recipes-extended/uwsgi/files/more-Add-
> explicit-breaks-to-avoid-implicit-passthrough.patch
> b/meta-openstack/recipes-extended/uwsgi/files/more-Add-
> explicit-breaks-to-avoid-implicit-passthrough.patch
> new file mode 100644
> index 000..5a885ed
> --- /dev/null
> +++ b/meta-openstack/recipes-extended/uwsgi/files/more-Add-
> explicit-breaks-to-avoid-implicit-passthrough.patch
> @@ -0,0 +1,50 @@
> +From 54666237455273e147eadb1904d261ed7624a8b6 Mon Sep 17 00:00:00 2001
> +From: Paul Tagliamonte 
> +Date: Mon, 14 Aug 2017 15:42:15 -0400
> +Subject: [PATCH] Add explicit breaks to avoid implicit passthrough.
> +
> +commit 54666237455273e147eadb1904d261ed7624a8b6 from upstream
> +git://github.com/unbit/uwsgi.git
> +
> +-Werror=implicit-fallthrough was added in gcc 7.1, which will
> +throw a compile error if a switch has an implicit passthrough.
> +
> +Seeing as how this switch doesn't appear to depend on passthrough to
> +function correctly, I've added explicit breaks to the switch.
> +
> +From https://gcc.gnu.org/gcc-7/changes.html:
> +
> +-Wimplicit-fallthrough warns when a switch case falls through. This
> +warning has five different levels. The compiler is able to parse a wide
> +range of fallthrough comments, depending on the level. It also handles
> +control-flow statements, such as ifs. It's possible to suppress the
> +warning by either adding a fallthrough comment, or by using a null
> +statement: __attribute__ ((fallthrough)); (C, C++), or [[fallthrough]];
> +(C++17), or [[gnu::fallthrough]]; (C++11/C++14). This warning is enabled
> +by -Wextra.
> 

Re: [meta-virtualization] [m-c-s][PATCH] spice: fix builds with gcc 7.x

2017-08-24 Thread Bruce Ashfield
merged.

Bruce

On Wed, Aug 23, 2017 at 2:08 PM, Mark Asselstine <
mark.asselst...@windriver.com> wrote:

> There is an upstream fix for this issue but it doesn't apply cleanly
> and is rather simple so rather than backport it and turn it into
> something unrecognizeable I simply created my own version of it. This
> fixes builds which fail with:
>
> | ../../git/server/reds.c: In function 'vdi_port_read_one_msg_from_
> device':
> | ../../git/server/reds.c:797:31: error: this statement may fall through
> [-Werror=implicit-fallthrough=]
> |  state->read_state = VDI_PORT_READ_STATE_GET_BUFF;
> |  ~~^~
> | ../../git/server/reds.c:798:9: note: here
> |  case VDI_PORT_READ_STATE_GET_BUFF: {
> |  ^~~~
>
> Signed-off-by: Mark Asselstine 
> ---
>  .../spice/files/Fix-build-issues-with-gcc-7.patch  | 59
> ++
>  recipes-support/spice/spice_git.bb |  1 +
>  2 files changed, 60 insertions(+)
>  create mode 100644 recipes-support/spice/files/
> Fix-build-issues-with-gcc-7.patch
>
> diff --git a/recipes-support/spice/files/Fix-build-issues-with-gcc-7.patch
> b/recipes-support/spice/files/Fix-build-issues-with-gcc-7.patch
> new file mode 100644
> index 000..7fcafdc
> --- /dev/null
> +++ b/recipes-support/spice/files/Fix-build-issues-with-gcc-7.patch
> @@ -0,0 +1,59 @@
> +From 9f001b6818ac4baa1df010ccf4200ca56bfb11b2 Mon Sep 17 00:00:00 2001
> +From: Mark Asselstine 
> +Date: Wed, 23 Aug 2017 13:47:29 -0400
> +Subject: [PATCH] Fix build issues with gcc 7
> +
> +gcc 7 checks for when a switch statement doesn't break between
> +cases. When a break is not found you will see
> +
> +| ../../git/server/reds.c: In function 'vdi_port_read_one_msg_from_
> device':
> +| ../../git/server/reds.c:797:31: error: this statement may fall through
> [-Werror=implicit-fallthrough=]
> +|  state->read_state = VDI_PORT_READ_STATE_GET_BUFF;
> +|  ~~^~
> +| ../../git/server/reds.c:798:9: note: here
> +|  case VDI_PORT_READ_STATE_GET_BUFF: {
> +|  ^~~~
> +
> +The 'fallthrough' comment will let gcc know this is done on purpose.
> +
> +Signed-off-by: Mark Asselstine 
> +---
> + server/inputs_channel.c | 1 +
> + server/reds.c   | 2 ++
> + 2 files changed, 3 insertions(+)
> +
> +diff --git a/server/inputs_channel.c b/server/inputs_channel.c
> +index 931dac1..534ab66 100644
> +--- a/server/inputs_channel.c
>  b/server/inputs_channel.c
> +@@ -321,6 +321,7 @@ static int inputs_channel_handle_parsed(RedChannelClient
> *rcc, uint32_t size, ui
> + activate_modifiers_watch();
> + }
> + }
> ++/* fallthrough */
> + case SPICE_MSGC_INPUTS_KEY_UP: {
> + SpiceMsgcKeyDown *key_down = (SpiceMsgcKeyDown *)buf;
> + for (i = 0; i < 4; i++) {
> +diff --git a/server/reds.c b/server/reds.c
> +index 30d0652..8c80eb6 100644
> +--- a/server/reds.c
>  b/server/reds.c
> +@@ -795,6 +795,7 @@ static SpiceCharDeviceMsgToClient
> *vdi_port_read_one_msg_from_device(SpiceCharDe
> + }
> + state->message_recive_len = state->vdi_chunk_header.size;
> + state->read_state = VDI_PORT_READ_STATE_GET_BUFF;
> ++/* fallthrough */
> + case VDI_PORT_READ_STATE_GET_BUFF: {
> + if (!(state->current_read_buf = vdi_port_read_buf_get())) {
> + return NULL;
> +@@ -806,6 +807,7 @@ static SpiceCharDeviceMsgToClient
> *vdi_port_read_one_msg_from_device(SpiceCharDe
> + state->message_recive_len -= state->recive_len;
> + state->read_state = VDI_PORT_READ_STATE_READ_DATA;
> + }
> ++/* fallthrough */
> + case VDI_PORT_READ_STATE_READ_DATA:
> + n = sif->read(vdagent, state->recive_pos, state->recive_len);
> + if (!n) {
> +--
> +2.7.4
> +
> diff --git a/recipes-support/spice/spice_git.bb b/recipes-support/spice/
> spice_git.bb
> index cfb75d7..04e7a25 100644
> --- a/recipes-support/spice/spice_git.bb
> +++ b/recipes-support/spice/spice_git.bb
> @@ -37,6 +37,7 @@ SRC_URI += " \
>  file://build-allow-separated-src-and-build-dirs.patch \
>  
> file://0001-red_parse_qxl-Fix-BITMAP_FMT_IS_RGB-defined-but-not-.patch
> \
>  
> file://0001-Use-PRI-macros-in-printf-to-keep-compatibility-betwe.patch
> \
> +file://Fix-build-issues-with-gcc-7.patch \
>  "
>
>  S = "${WORKDIR}/git"
> --
> 2.7.4
>
> --
> ___
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
meta-virtualization mailing list

Re: [meta-virtualization] [PATCH 1/4] vgabios : extract biossums tool and build it separately, native

2017-08-24 Thread Bruce Ashfield
On Wed, Aug 23, 2017 at 5:13 PM, Christopher Clark <
christopher.w.cl...@gmail.com> wrote:

> On Wed, Aug 23, 2017 at 1:18 PM, Christopher Clark
>  wrote:
> > On Wed, Aug 23, 2017 at 5:54 AM, Bruce Ashfield
> >  wrote:
> >>
> >>
> >> On Wed, Aug 23, 2017 at 2:43 AM, Christopher Clark
> >>  wrote:
> >>>
> >>> On Tue, Aug 22, 2017 at 7:42 PM, Bruce Ashfield
> >>>  wrote:
> >>> > On Tue, Aug 22, 2017 at 1:08 AM, 
> wrote:
> >>> >> From: Christopher Clark 
> >>> >>
> >>> >> The biossums tool is used to generate the vgabios build product.
> >>> >>
> >>> >> This patch:
> >>> >> * adds a separate recipe "biossums" for the tool
> >>> >> * makes the vgabios recipe depend upon biossums-native
> >>> >> * makes the vgabios recipe use the native binary rather than a
> locally
> >>> >> built one
> >
> >>> >> +
> >>> >> +do_compile() {
> >>> >> +oe_runmake clean
> >>> >
> >>> >
> >>> > What actually happens if the clean isn't run before each compile ?
>
> I figured it out: a 32-bit biossums binary is distributed inside the
> upstream source tarball, and make decides that it doesn't need to
> rebuild it since the timestamp is newer than the source code file.
>

Aha. Thanks for the information .. gives more confidence in the approach.
We could
also just rm the files, but using the clean mechanism to take care of it
properly makes
sense.

I've now merged the 4 patch series.

Bruce


>
> I think that makes the "clean" seem like a reasonable step to put
> before compile.
>
> Christopher
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


Re: [meta-virtualization] [PATCH V2] docker-distribution: update to 2.6.2

2017-08-24 Thread Bruce Ashfield
v2 is merged.

Bruce

On Thu, Aug 24, 2017 at 2:39 AM, Yi Zhao  wrote:

> CVE-2017-11468 is fixed in this release.
>
> Reference:
> https://nvd.nist.gov/vuln/detail/CVE-2017-11468
>
> Release note:
> https://github.com/docker/distribution/releases/tag/v2.6.2
>
> Signed-off-by: Yi Zhao 
> ---
>  recipes-containers/docker-distribution/docker-distribution_git.bb | 6
> +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-containers/docker-distribution/docker-
> distribution_git.bb b/recipes-containers/docker-distribution/docker-
> distribution_git.bb
> index 08b6d70..e2eac2e 100644
> --- a/recipes-containers/docker-distribution/docker-distribution_git.bb
> +++ b/recipes-containers/docker-distribution/docker-distribution_git.bb
> @@ -3,14 +3,14 @@ SUMMARY = "The Docker toolset to pack, ship, store, and
> deliver content"
>  LICENSE = "Apache-2.0"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=d2794c0df5b907fdace235a619d80314"
>
> -SRCREV_distribution="0810eba2adf048b77621472991211924d9ec31c5"
> -SRC_URI = "git://github.com/docker/distribution.git;branch=
> master;name=distribution;destsuffix=git/src/github.com/docker/distribution
> \
> +SRCREV_distribution="48294d928ced5dd9b378f7fd7c6f5da3ff3f2c89"
> +SRC_URI = "git://github.com/docker/distribution.git;branch=
> release/2.6;name=distribution;destsuffix=git/src/github.com/
> docker/distribution \
> file://docker-registry.service \
>"
>
>  PACKAGES =+ "docker-registry"
>
> -PV = "v2.6.0-rc+git${SRCPV}"
> +PV = "v2.6.2"
>  S = "${WORKDIR}/git/src/github.com/docker/distribution"
>
>  inherit goarch
> --
> 2.7.4
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


Re: [meta-virtualization] [PATCH] kernel: drop 4.1 bbappend

2017-08-24 Thread Bruce Ashfield
I already have this one queued. I was waiting for my patches to merge to
oe-core before pushing it.

Cheers,

Bruce

On Thu, Aug 24, 2017 at 3:03 AM, Chunrong Guo  wrote:

> From: Chunrong Guo 
>
> *4.1 is no longer in oe-core master, so we drop the bbappend
>
> Signed-off-by: Chunrong Guo 
> ---
>  recipes-kernel/linux/linux-yocto_4.1.bbappend | 20 
>  1 file changed, 20 deletions(-)
>  delete mode 100644 recipes-kernel/linux/linux-yocto_4.1.bbappend
>
> diff --git a/recipes-kernel/linux/linux-yocto_4.1.bbappend
> b/recipes-kernel/linux/linux-yocto_4.1.bbappend
> deleted file mode 100644
> index f163fdf..000
> --- a/recipes-kernel/linux/linux-yocto_4.1.bbappend
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> -
> -SRC_URI += "file://xt-checksum.scc \
> -file://ebtables.scc \
> -   file://vswitch.scc \
> -   file://lxc.scc \
> -file://docker.scc \
> -   "
> -KERNEL_FEATURES_append = " features/kvm/qemu-kvm-enable.scc"
> -
> -KERNEL_MODULE_AUTOLOAD += "openvswitch"
> -KERNEL_MODULE_AUTOLOAD += "kvm"
> -KERNEL_MODULE_AUTOLOAD += "kvm-amd"
> -KERNEL_MODULE_AUTOLOAD += "kvm-intel"
> -
> -# aufs kernel support required for xen-image-minimal
> -KERNEL_FEATURES_append += "${@bb.utils.contains('DISTRO_FEATURES',
> 'aufs', ' features/aufs/aufs-enable.scc', '', d)}"
> -
> -# xen kernel support
> -SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'xen', '
> file://xen.scc', '', d)}"
> --
> 1.9.0
>
> --
> ___
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


[meta-virtualization] [PATCH] Added recipe for the Singularity container platform.

2017-08-24 Thread Alexandru Tiniuc
Singularity is a container platform built on the principle of mobility
of compute.  It is designed to be used on HPC clusters and, unlike
Docker, it does not require root access to mount an image. In addition,
it can use Docker images out-of-the-box and it can pull them from the
Docker Hub. For more information, see singularity.lbl.gov

This recipe enables building the Singularity container platform.
Additionally, it creates a symlink from /usr/bin/python3 to
/usr/bin/python, as well as a symlink to where python3 expects
CA certificates to be.

I have tested it on a Raspberry Pi 3: I successfully built and run
arm32v7 images from Docker Hub. Make sure you have the right image for
your CPU architecture: it defaults to amd64.

Signed-off-by: Alexandru Tiniuc 
---
 recipes-containers/singularity/singularity_git.bb | 35 +++
 1 file changed, 35 insertions(+)
 create mode 100644 recipes-containers/singularity/singularity_git.bb

diff --git a/recipes-containers/singularity/singularity_git.bb 
b/recipes-containers/singularity/singularity_git.bb
new file mode 100644
index 000..d0fbeb9
--- /dev/null
+++ b/recipes-containers/singularity/singularity_git.bb
@@ -0,0 +1,35 @@
+# Skip QA check for library symbolic links (core issue is a packaging problem 
within 
+# Singularity build / config: read up on the dev-so test for more info)
+INSANE_SKIP_${PN} += "dev-so"
+
+RDEPENDS_${PN} += "glibc python3 ca-certificates openssl"
+# Singularity expects to find python3 under the name python, therefore both
+# cannot be installed at the same time.
+RCONFLICTS_${PN} = "python"
+
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://COPYRIGHT.md;md5=be78c34e483dd7d8439358b1e024b294 \
+
file://LICENSE-LBNL.md;md5=45a007b527e1a9507aa7fa869f8d7ede \
+file://LICENSE.md;md5=df4326b473db6424033f1d98a5645e30 \
+
file://debian/copyright;md5=ed267cf386d9b75ab1f27f407e935b10"
+
+SRC_URI = "git://github.com/singularityware/singularity.git;protocol=https"
+PV = "2.3.1+git${SRCPV}"
+SRCREV = "e214d4ebf0a1274b1c63b095fd55ae61c7e92947"
+
+S = "${WORKDIR}/git"
+
+inherit pythonnative autotools-brokensep
+EXTRA_OECONF = "--prefix=/usr/local"
+
+pkg_postinst_${PN}() {
+# Singularity requires "python" to resolve to "python3" within the 
commandline.
+# This creates a symbolic link from python3 to python. A side-effect of 
this is
+# that scripts which expect Python 2 may fail to run correctly.
+ln -sr $D${bindir}/python3 $D${bindir}/python 
+
+# python3 expects CA certificates to be installed in a different place to 
where
+# they are actually installed. These lines link the two locations.
+rm -r $D${libdir}/ssl-1.1/certs
+ln -sr $D${sysconfdir}/ssl/certs $D${libdir}/ssl-1.1 
+}
-- 
2.1.4

-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


Re: [meta-virtualization] [question] Sending a pull request

2017-08-24 Thread Tiniuc Alexandru
I have figured out what I was doing wrong with Git. I'm still not quite
sure how to make the create-pull-request script work. In case anyone else
stumbles into this: you need to configure git to use the GMail SMTP server.
I used this guide:
https://coderwall.com/p/dp-gka/setting-up-git-send-email-with-gmail , and I
generated an app password specifically for it, since storing your main
password in plaintext inside a config file is a Bad Thing.

I hope somebody will find this useful
Alexandru Tiniuc



On Thu, Aug 24, 2017 at 10:33 AM, Tiniuc Alexandru <
tiniuc.alexan...@gmail.com> wrote:

> I have been trying to send a pull request for a couple of days, and I have
> had little luck. The create-pull-request script fails and informs me that
> the remote URL seems incorrect (git://git.yoctoproject.org/
> meta-virtualization is the URL I am using.).
>
> Sending the patch directly using git send-email, as advised in the README
> file, doesn't seem to deliver the messages. My logfile mentions that the
> email was sent, but it hasn't appeared in the mailing list, nor in my inbox
> (I am automatically CC'd)
>
> Would you mind telling me what I am doing wrong? This is my first time
> using a terminal email client and I would be more than happy to learn how
> to do it properly.
>
> Many thanks,
> Alexandru Tiniuc
>
-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


[meta-virtualization] [PATCH] kernel: drop 4.1 bbappend

2017-08-24 Thread Chunrong Guo
From: Chunrong Guo 

*4.1 is no longer in oe-core master, so we drop the bbappend

Signed-off-by: Chunrong Guo 
---
 recipes-kernel/linux/linux-yocto_4.1.bbappend | 20 
 1 file changed, 20 deletions(-)
 delete mode 100644 recipes-kernel/linux/linux-yocto_4.1.bbappend

diff --git a/recipes-kernel/linux/linux-yocto_4.1.bbappend 
b/recipes-kernel/linux/linux-yocto_4.1.bbappend
deleted file mode 100644
index f163fdf..000
--- a/recipes-kernel/linux/linux-yocto_4.1.bbappend
+++ /dev/null
@@ -1,20 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRC_URI += "file://xt-checksum.scc \
-file://ebtables.scc \
-   file://vswitch.scc \
-   file://lxc.scc \
-file://docker.scc \
-   "
-KERNEL_FEATURES_append = " features/kvm/qemu-kvm-enable.scc"
-
-KERNEL_MODULE_AUTOLOAD += "openvswitch"
-KERNEL_MODULE_AUTOLOAD += "kvm"
-KERNEL_MODULE_AUTOLOAD += "kvm-amd"
-KERNEL_MODULE_AUTOLOAD += "kvm-intel"
-
-# aufs kernel support required for xen-image-minimal
-KERNEL_FEATURES_append += "${@bb.utils.contains('DISTRO_FEATURES', 'aufs', ' 
features/aufs/aufs-enable.scc', '', d)}"
-
-# xen kernel support
-SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'xen', ' file://xen.scc', 
'', d)}"
-- 
1.9.0

-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


[meta-virtualization] [question] Sending a pull request

2017-08-24 Thread Tiniuc Alexandru
I have been trying to send a pull request for a couple of days, and I have
had little luck. The create-pull-request script fails and informs me that
the remote URL seems incorrect (git://
git.yoctoproject.org/meta-virtualization is the URL I am using.).

Sending the patch directly using git send-email, as advised in the README
file, doesn't seem to deliver the messages. My logfile mentions that the
email was sent, but it hasn't appeared in the mailing list, nor in my inbox
(I am automatically CC'd)

Would you mind telling me what I am doing wrong? This is my first time
using a terminal email client and I would be more than happy to learn how
to do it properly.

Many thanks,
Alexandru Tiniuc
-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization


[meta-virtualization] [PATCH V2] docker-distribution: update to 2.6.2

2017-08-24 Thread Yi Zhao
CVE-2017-11468 is fixed in this release.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2017-11468

Release note:
https://github.com/docker/distribution/releases/tag/v2.6.2

Signed-off-by: Yi Zhao 
---
 recipes-containers/docker-distribution/docker-distribution_git.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-containers/docker-distribution/docker-distribution_git.bb 
b/recipes-containers/docker-distribution/docker-distribution_git.bb
index 08b6d70..e2eac2e 100644
--- a/recipes-containers/docker-distribution/docker-distribution_git.bb
+++ b/recipes-containers/docker-distribution/docker-distribution_git.bb
@@ -3,14 +3,14 @@ SUMMARY = "The Docker toolset to pack, ship, store, and 
deliver content"
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=d2794c0df5b907fdace235a619d80314"
 
-SRCREV_distribution="0810eba2adf048b77621472991211924d9ec31c5"
-SRC_URI = 
"git://github.com/docker/distribution.git;branch=master;name=distribution;destsuffix=git/src/github.com/docker/distribution
 \
+SRCREV_distribution="48294d928ced5dd9b378f7fd7c6f5da3ff3f2c89"
+SRC_URI = 
"git://github.com/docker/distribution.git;branch=release/2.6;name=distribution;destsuffix=git/src/github.com/docker/distribution
 \
file://docker-registry.service \
   "
 
 PACKAGES =+ "docker-registry"
 
-PV = "v2.6.0-rc+git${SRCPV}"
+PV = "v2.6.2"
 S = "${WORKDIR}/git/src/github.com/docker/distribution"
 
 inherit goarch
-- 
2.7.4

-- 
___
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization