[oe] [PATCH 2/2] postgresql: blacklist because tcl in oe-core is broken for last month

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 meta-oe/recipes-support/postgresql/postgresql_9.4.5.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-oe/recipes-support/postgresql/postgresql_9.4.5.bb 
b/meta-oe/recipes-support/postgresql/postgresql_9.4.5.bb
index 54b660e..4a0296d 100644
--- a/meta-oe/recipes-support/postgresql/postgresql_9.4.5.bb
+++ b/meta-oe/recipes-support/postgresql/postgresql_9.4.5.bb
@@ -12,3 +12,5 @@ SRC_URI += "\
 SRC_URI[md5sum] = "8b2e3472a8dc786649b4d02d02e039a0"
 SRC_URI[sha256sum] = 
"b87c50c66b6ea42a9712b5f6284794fabad0616e6ae420cf0f10523be6d94a39"
 
+# 
http://lists.openembedded.org/pipermail/openembedded-core/2016-May/122095.html
+PNBLACKLIST[postgresql] ?= "Depends on broken tcl"
-- 
2.8.4

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [PATCH 1/2] python-pygobject, python-cloudeebus, python-dbusmock: Blacklist because of python-pygobject is broken

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb | 5 -
 meta-oe/recipes-devtools/python/python-pygobject_3.18.2.bb | 2 ++
 meta-python/recipes-devtools/python/python-cloudeebus_0.6.0.bb | 3 +++
 meta-python/recipes-devtools/python/python-dbusmock_0.10.1.bb  | 3 +++
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb 
b/meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb
index d6d16c0..05e3daf 100644
--- a/meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb
+++ b/meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb
@@ -27,7 +27,10 @@ do_install_append() {
 }
 
 RDEPENDS_${PN}-dev = "bluez-hcidump"
-RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"
+RDEPENDS_${PN}-testtools += "python python-dbus"
+
+# 
http://lists.openembedded.org/pipermail/openembedded-devel/2016-June/107798.html
+# RDEPENDS_${PN}-testtools += "python-pygobject"
 
 ALLOW_EMPTY_libasound-module-bluez = "1"
 PACKAGES =+ "libasound-module-bluez ${PN}-testtools"
diff --git a/meta-oe/recipes-devtools/python/python-pygobject_3.18.2.bb 
b/meta-oe/recipes-devtools/python/python-pygobject_3.18.2.bb
index e4eeafb..1c78e26 100644
--- a/meta-oe/recipes-devtools/python/python-pygobject_3.18.2.bb
+++ b/meta-oe/recipes-devtools/python/python-pygobject_3.18.2.bb
@@ -29,3 +29,5 @@ do_install_append() {
 rm ${D}${includedir}/pygobject-3.0/pygobject.h 
${D}${libdir}/pkgconfig/pygobject-3.0.pc
 }
 
+# 
http://lists.openembedded.org/pipermail/openembedded-devel/2016-June/107798.html
+PNBLACKLIST[python-pygobject] ?= "BROKEN: fails to build since it was moved to 
meta-oe"
diff --git a/meta-python/recipes-devtools/python/python-cloudeebus_0.6.0.bb 
b/meta-python/recipes-devtools/python/python-cloudeebus_0.6.0.bb
index 120a8a7..d067358 100644
--- a/meta-python/recipes-devtools/python/python-cloudeebus_0.6.0.bb
+++ b/meta-python/recipes-devtools/python/python-cloudeebus_0.6.0.bb
@@ -14,6 +14,9 @@ inherit distutils
 DEPENDS_${PN} = "python python-distribute"
 RDEPENDS_${PN} = "python python-dbus python-json python-argparse 
python-pygobject python-autobahn python-twisted python-subprocess"
 
+# 
http://lists.openembedded.org/pipermail/openembedded-devel/2016-June/107798.html
+PNBLACKLIST[python-cloudeebus] ?= "Rdepends on broken python-pygobject"
+
 do_install_prepend() {
   install -d ${D}${PYTHON_SITEPACKAGES_DIR}/${PN}
 }
diff --git a/meta-python/recipes-devtools/python/python-dbusmock_0.10.1.bb 
b/meta-python/recipes-devtools/python/python-dbusmock_0.10.1.bb
index 2520bfc..244e59f 100644
--- a/meta-python/recipes-devtools/python/python-dbusmock_0.10.1.bb
+++ b/meta-python/recipes-devtools/python/python-dbusmock_0.10.1.bb
@@ -9,6 +9,9 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=e6a600fd5e1d9cbde2d983680233ad02"
 
 DEPENDS += "python-pygobject python-dbus"
 
+# 
http://lists.openembedded.org/pipermail/openembedded-devel/2016-June/107798.html
+PNBLACKLIST[python-dbusmock] ?= "Depends on broken python-pygobject"
+
 SRC_URI = "https://launchpad.net/${BPN}/trunk/${PV}/+download/${BP}.tar.gz;
 SRC_URI[md5sum] = "7370d325c4a75494dd71885ca65b79e8"
 SRC_URI[sha256sum] = 
"03aadc93bdc26ea18d4d78fcff7b6cb34f4e18623bc5cc41cf9539d663cee11e"
-- 
2.8.4

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH 6/8] python-pygobject: add a recipe

[Alexander Kanavin]

On 06/10/2016 03:33 PM, Martin Jansa wrote:

On Tue, May 24, 2016 at 02:56:59PM +0300, Alexander Kanavin wrote:

oe-core provides only python3-pygobject now, and a few recipes in meta-oe
still need the version built against Python 2.


I've merged this but now it started to fail:

| checking whether python2.7 version >= 2.7... yes
| checking for python2.7 version... 2.7
| checking for python2.7 platform... linux2
| checking for python2.7 script directory... 
${prefix}/lib64/python2.7/site-packages
| checking for python2.7 extension module directory... 
${exec_prefix}/lib64/python2.7/site-packages
| checking for python version... (cached) 2.7
| checking for python platform... (cached) linux2
| checking for python script directory... (cached) 
${prefix}/lib64/python2.7/site-packages
| checking for python extension module directory... (cached) 
${exec_prefix}/lib64/python2.7/site-packages
| checking for headers required to compile python extensions... not found
| configure: error: Python headers not found
| WARNING: python-pygobject/3.18.2-r0/temp/run.do_configure.32140:1 exit 1 from 
'exit 1'
| ERROR: Function failed: do_configure (log file is located at 
python-pygobject/3.18.2-r0/temp/log.do_configure.32140)
NOTE: recipe python-pygobject-3.18.2-r0: task do_configure: Failed


I think the recipe can be dropped with its dependencies:
- python-dbusmock is not used by anything
- python-cloudeebus is not used by anything
- bluez4 testtools have been superseded by test tools from bluez5 and 
can be disabled


Alex

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] the fate of Vala in OE

[Alexander Kanavin]

On 06/09/2016 07:36 PM, Burton, Ross wrote:


We do use Vala for internal gstreamer-related projects so I would
volunteer to support it in oe-core.


Would you volunteer to maintain it in a separate layer if possible?  If
nothing in core uses it and it can be maintained out of core then I
think it should be moved out.  Currently, vala support is in oe-core but
nothing in oe-core uses it... so the autobuilder can't tell if it works.


How about?

1) vala compiler recipe and support for generating library bindings 
stays in oe-core


2) we take care of updating the vala recipe to latest stable upstream 
version


3) we make sure that vala recipe builds correctly and library bindings 
are generated without error for libraries that are in oe-core


4) any other issues, such as compiler not working properly, or issues 
with bindings for things that are not in oe-core are handled by 'the 
community'.




Alex

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] the fate of Vala in OE

[Alexander Kanavin]

On 06/10/2016 01:10 PM, Gary Thomas wrote:



Yes, I realized that :-(

The actual list is smaller, but still important:
"gcr" -> "vala-native" [style=solid]
"gcr" -> "vala" [style=solid]
"libsecret" -> "vala-native" [style=solid]
"libsecret" -> "vala" [style=solid]

Both of those packages are in OE-core (meta/recipes-gnome)


These packages are libraries, and need vala only for generating vala 
bindings for their library APIs. If there are no users of those 
bindings, then vala dependencies could be easily disabled.


The actual things in oe-core and meta-oe that truly need vala are Rygel 
and vala-terminal.



Alex
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] the fate of Vala in OE

[Alexander Kanavin]

On 06/09/2016 05:37 PM, Burton, Ross wrote:


That said, what other layers use vala? If it leaves core, is there a
layer that can host it and support other layers using it without to much
trouble?



That's the key question really - can the support be extracted and added to
eg meta-vala in some way?


The problem with such extraction is that for recipes in oe-core support 
for generating their vala bindings still has to be provided. I don't see 
a way to do that that is not overly complicated (in 'opaque side 
effects' kind of way) and difficult to grasp for humans.



Alex

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] the fate of Vala in OE

[Alexander Kanavin]

On 06/09/2016 05:08 PM, Philip Balister wrote:


It seems that there are use cases beyond just embedded systems for
OpenEmbedded, so this logic is not really valid. See:

http://openxt.org/

And yes, I think it is useful for openembedded-core to have as broad an
audience as possible.


Our resources are limited, so there has to be specific evidence for a 
need for Vala; not the vague 'it could be useful to someone out there' 
kind of thinking.


The reason I was proposing removing Vala is that:
a) you can count the open source software written in Vala on fingers of 
one hand: it's Rygel, Elementary OS apps, and a couple of 
desktop-oriented Gnome apps.
b) until yesterday, we haven't heard of any in-house usage of Vala by OE 
users.


But since people have spoken up, I'll make a different proposal in a moment.


That said, what other layers use vala? If it leaves core, is there a
layer that can host it and support other layers using it without to much
trouble?


As far as oe-core and all of meta-oe layers go, it's Rygel and 
vala-terminal, that's all.


Alex

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH 6/8] python-pygobject: add a recipe

[Martin Jansa]

On Tue, May 24, 2016 at 02:56:59PM +0300, Alexander Kanavin wrote:
> oe-core provides only python3-pygobject now, and a few recipes in meta-oe
> still need the version built against Python 2.

I've merged this but now it started to fail:

| checking whether python2.7 version >= 2.7... yes
| checking for python2.7 version... 2.7
| checking for python2.7 platform... linux2
| checking for python2.7 script directory... 
${prefix}/lib64/python2.7/site-packages
| checking for python2.7 extension module directory... 
${exec_prefix}/lib64/python2.7/site-packages
| checking for python version... (cached) 2.7
| checking for python platform... (cached) linux2
| checking for python script directory... (cached) 
${prefix}/lib64/python2.7/site-packages
| checking for python extension module directory... (cached) 
${exec_prefix}/lib64/python2.7/site-packages
| checking for headers required to compile python extensions... not found
| configure: error: Python headers not found
| WARNING: python-pygobject/3.18.2-r0/temp/run.do_configure.32140:1 exit 1 from 
'exit 1'
| ERROR: Function failed: do_configure (log file is located at 
python-pygobject/3.18.2-r0/temp/log.do_configure.32140)
NOTE: recipe python-pygobject-3.18.2-r0: task do_configure: Failed


> 
> Signed-off-by: Alexander Kanavin 
> ---
>  ...c-add-sysroot-path-to-GI_DATADIR-don-t-se.patch | 41 
> ++
>  .../python/python-pygobject_3.18.2.bb  | 31 
>  2 files changed, 72 insertions(+)
>  create mode 100644 
> meta-oe/recipes-devtools/python/python-pygobject/0001-configure.ac-add-sysroot-path-to-GI_DATADIR-don-t-se.patch
>  create mode 100644 meta-oe/recipes-devtools/python/python-pygobject_3.18.2.bb
> 
> diff --git 
> a/meta-oe/recipes-devtools/python/python-pygobject/0001-configure.ac-add-sysroot-path-to-GI_DATADIR-don-t-se.patch
>  
> b/meta-oe/recipes-devtools/python/python-pygobject/0001-configure.ac-add-sysroot-path-to-GI_DATADIR-don-t-se.patch
> new file mode 100644
> index 000..a391f7e
> --- /dev/null
> +++ 
> b/meta-oe/recipes-devtools/python/python-pygobject/0001-configure.ac-add-sysroot-path-to-GI_DATADIR-don-t-se.patch
> @@ -0,0 +1,41 @@
> +From 5e5350d730f85957a42c6d846d347d080e7dd996 Mon Sep 17 00:00:00 2001
> +From: Alexander Kanavin 
> +Date: Fri, 23 Oct 2015 12:40:34 +0300
> +Subject: [PATCH] configure.ac: add sysroot path to GI_DATADIR; don't set
> + introspection scanner and compiler paths
> +
> +Upstream-Status: Pending [review on oe-core maillist]
> +Signed-off-by: Alexander Kanavin 
> +---
> + configure.ac | 8 +---
> + 1 file changed, 1 insertion(+), 7 deletions(-)
> +
> +diff --git a/configure.ac b/configure.ac
> +index 2c0cfbd..cfcb3bf 100644
> +--- a/configure.ac
>  b/configure.ac
> +@@ -194,7 +194,7 @@ PKG_CHECK_MODULES(GI,
> + gobject-introspection-1.0 >= introspection_required_version
> + )
> + 
> +-GI_DATADIR=$($PKG_CONFIG --variable=gidatadir gobject-introspection-1.0)
> ++GI_DATADIR=$PKG_CONFIG_SYSROOT_DIR$($PKG_CONFIG --variable=gidatadir 
> gobject-introspection-1.0)
> + AC_SUBST(GI_DATADIR)
> + 
> + if test "$enable_cairo" != no; then
> +@@ -219,12 +219,6 @@ AC_ARG_WITH(common,
> + with_common=yes)
> + AM_CONDITIONAL(WITH_COMMON, test "$with_common" = "yes")
> + 
> +-INTROSPECTION_SCANNER=`$PKG_CONFIG --variable=g_ir_scanner 
> gobject-introspection-1.0`
> +-INTROSPECTION_COMPILER=`$PKG_CONFIG --variable=g_ir_compiler 
> gobject-introspection-1.0`
> +-
> +-AC_SUBST(INTROSPECTION_SCANNER)
> +-AC_SUBST(INTROSPECTION_COMPILER)
> +-
> + # compiler warnings, errors, required cflags, and code coverage support
> + GNOME_COMPILE_WARNINGS([maximum])
> + AC_MSG_CHECKING(for Gnome code coverage support)
> +-- 
> +2.1.4
> +
> diff --git a/meta-oe/recipes-devtools/python/python-pygobject_3.18.2.bb 
> b/meta-oe/recipes-devtools/python/python-pygobject_3.18.2.bb
> new file mode 100644
> index 000..e4eeafb
> --- /dev/null
> +++ b/meta-oe/recipes-devtools/python/python-pygobject_3.18.2.bb
> @@ -0,0 +1,31 @@
> +SUMMARY = "Python GObject bindings"
> +SECTION = "devel/python"
> +LICENSE = "LGPLv2.1"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=a916467b91076e631dd8edb7424769c7"
> +
> +inherit autotools pkgconfig gnomebase distutils-base gobject-introspection
> +
> +DEPENDS += "python glib-2.0"
> +
> +SRCNAME="pygobject"
> +SRC_URI = " \
> +
> http://ftp.gnome.org/pub/GNOME/sources/${SRCNAME}/${@gnome_verdir("${PV}")}/${SRCNAME}-${PV}.tar.xz
>  \
> +file://0001-configure.ac-add-sysroot-path-to-GI_DATADIR-don-t-se.patch \
> +"
> +
> +SRC_URI[md5sum] = "0a956f3e785e23b0f136832f2e57a862"
> +SRC_URI[sha256sum] = 
> "2a3cad1517916b74e131e6002c3824361aee0671ffb0d55ded119477fc1c2c5f"
> +
> +S = "${WORKDIR}/${SRCNAME}-${PV}"
> +
> +BBCLASSEXTEND = "native"
> +
> +EXTRA_OECONF = "--disable-cairo --with-python=python2.7"
> +
> +RDEPENDS_${PN} += "python-setuptools python-importlib"
> +
> 

Re: [oe] [OE-core] the fate of Vala in OE

[Gary Thomas]

On 2016-06-10 10:41, Martin Jansa wrote:

You're reading it from wrong side.

This shows what vala-native needs, not what needs vala-native.


Yes, I realized that :-(

The actual list is smaller, but still important:
"gcr" -> "vala-native" [style=solid]
"gcr" -> "vala" [style=solid]
"libsecret" -> "vala-native" [style=solid]
"libsecret" -> "vala" [style=solid]

Both of those packages are in OE-core (meta/recipes-gnome)



On Fri, Jun 10, 2016 at 10:35 AM, Gary Thomas  wrote:


On 2016-06-10 02:04, Petr Nechaev wrote:


I can see that libsecret in oe-core depends on vala though for testing
only.

If moving to meta-oe is community's decision, I will prepare the patch.



It looks like a lot of things need vala (or more precisely vala-native).
I just tried a build which included meta-browser (I know this isn't OE-core
but _is_ very common) and saw this dependency chain:
"vala-native" -> "libxslt-native" [style=solid]
"vala-native" -> "glib-2.0-native" [style=solid]
"vala-native" -> "autoconf-native" [style=solid]
"vala-native" -> "automake-native" [style=solid]
"vala-native" -> "libtool-native" [style=solid]
"vala-native" -> "gnu-config-native" [style=solid]
"vala-native" -> "pkgconfig-native" [style=solid]
"vala-native" -> "flex-native" [style=solid]
"vala-native" -> "bison-native" [style=solid]

In this case, I think vala (vala-native) deserves OE-core status.


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] the fate of Vala in OE

[Martin Jansa]

You're reading it from wrong side.

This shows what vala-native needs, not what needs vala-native.

On Fri, Jun 10, 2016 at 10:35 AM, Gary Thomas  wrote:

> On 2016-06-10 02:04, Petr Nechaev wrote:
>
>> I can see that libsecret in oe-core depends on vala though for testing
>> only.
>>
>> If moving to meta-oe is community's decision, I will prepare the patch.
>>
>>
> It looks like a lot of things need vala (or more precisely vala-native).
> I just tried a build which included meta-browser (I know this isn't OE-core
> but _is_ very common) and saw this dependency chain:
> "vala-native" -> "libxslt-native" [style=solid]
> "vala-native" -> "glib-2.0-native" [style=solid]
> "vala-native" -> "autoconf-native" [style=solid]
> "vala-native" -> "automake-native" [style=solid]
> "vala-native" -> "libtool-native" [style=solid]
> "vala-native" -> "gnu-config-native" [style=solid]
> "vala-native" -> "pkgconfig-native" [style=solid]
> "vala-native" -> "flex-native" [style=solid]
> "vala-native" -> "bison-native" [style=solid]
>
> In this case, I think vala (vala-native) deserves OE-core status.
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
>
> --
> ___
> 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

Re: [oe] [OE-core] the fate of Vala in OE

[Gary Thomas]

On 2016-06-10 02:04, Petr Nechaev wrote:

I can see that libsecret in oe-core depends on vala though for testing only.

If moving to meta-oe is community's decision, I will prepare the patch.



It looks like a lot of things need vala (or more precisely vala-native).
I just tried a build which included meta-browser (I know this isn't OE-core
but _is_ very common) and saw this dependency chain:
"vala-native" -> "libxslt-native" [style=solid]
"vala-native" -> "glib-2.0-native" [style=solid]
"vala-native" -> "autoconf-native" [style=solid]
"vala-native" -> "automake-native" [style=solid]
"vala-native" -> "libtool-native" [style=solid]
"vala-native" -> "gnu-config-native" [style=solid]
"vala-native" -> "pkgconfig-native" [style=solid]
"vala-native" -> "flex-native" [style=solid]
"vala-native" -> "bison-native" [style=solid]

In this case, I think vala (vala-native) deserves OE-core status.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-networking][jethro][backport][PATCH] samba: add volatile file to support readonly rootfs

[Richard Leitner]

This patch adds a volatile file for samba which was removed by the
update from 3.6.25 to 4.1.12. This file is necessary to build a image
that uses the read-only-rootfs feature.

Backported from master 12e31ce

Signed-off-by: Johannes Pointner 
Signed-off-by: Martin Jansa 
Signed-off-by: Joe MacDonald 
Signed-off-by: Richard Leitner 
---
 .../recipes-connectivity/samba/samba-4.1.12/volatiles.03_samba | 3 +++
 meta-networking/recipes-connectivity/samba/samba_4.1.12.bb | 2 ++
 2 files changed, 5 insertions(+)
 create mode 100644 
meta-networking/recipes-connectivity/samba/samba-4.1.12/volatiles.03_samba

diff --git 
a/meta-networking/recipes-connectivity/samba/samba-4.1.12/volatiles.03_samba 
b/meta-networking/recipes-connectivity/samba/samba-4.1.12/volatiles.03_samba
new file mode 100644
index 000..4bdfa7d
--- /dev/null
+++ b/meta-networking/recipes-connectivity/samba/samba-4.1.12/volatiles.03_samba
@@ -0,0 +1,3 @@
+#  
+d root root 0755 /var/log/samba none
+d root root 0755 /var/run/samba none
diff --git a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb 
b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
index 4d2ab66..733821b 100644
--- a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
+++ b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
@@ -34,6 +34,7 @@ SRC_URI = "${SAMBA_MIRROR}/stable/samba-${PV}.tar.gz \
file://19-systemd-daemon-is-contained-by-libsystemd.patch \
file://20-do-not-import-target-module-while-cross-compile.patch \
file://21-add-config-option-without-valgrind.patch \
+   file://volatiles.03_samba \
   "
 
 SRC_URI[md5sum] = "232016d7581a1ba11e991ec2674553c4"
@@ -135,6 +136,7 @@ do_install_append() {
 install -d ${D}${sysconfdir}/samba
 echo "127.0.0.1 localhost" > ${D}${sysconfdir}/samba/lmhosts
 install -m644 packaging/LSB/smb.conf ${D}${sysconfdir}/samba/smb.conf
+install -D -m 644 ${WORKDIR}/volatiles.03_samba 
${D}${sysconfdir}/default/volatiles/03_samba
 
 install -d ${D}${libdir}/tmpfiles.d
 install -m644 packaging/systemd/samba.conf.tmp 
${D}${libdir}/tmpfiles.d/samba.conf
-- 
2.1.4

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH 1/3] gitkpkgv: Ensure files are closed

[Mike Looijmans]

On 07-06-16 15:49, Richard Purdie wrote:

On Tue, 2016-06-07 at 11:02 +0200, Mike Looijmans wrote:

Looks like regression in Python itself?

In both Python 2 and 3, the file is closed properly if the file
object is not
being stored:

  >>> import os
  >>> os.listdir('/proc/self/fd')
['0', '1', '2', '3']
  >>> l=open('/proc/self/stat').readline()
  >>> os.listdir('/proc/self/fd')
['0', '1', '2', '3']
  >>> f=open('/proc/self/stat')
  >>> os.listdir('/proc/self/fd')
['0', '1', '2', '3', '4']
  >>>


(file descriptor "3" is the one being used to read the /proc/self/fd
directory, "4" is the one used for reading the stat file)

The "with" construction should not be needed here. Something else is
causing
this (e.g. nested function definition or exception handler?).


$ python2 -Wdefault -c "open('/bin/bash')"
$ python3 -Wdefault -c "open('/bin/bash')"
-c:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/bin/bash' mode='r' 
encoding='UTF-8'>

Admittedly its not an out the box warning but it is one that seems to
be enabled under bitbake. Details in:

https://bugs.python.org/issue10093

but the gist of the issue is that relying on the garbage collector to
close files is a cpython'ism and other implementations of python may
not do this.

So whilst "with" might not be strictly required, it is recommended.


Oh dear, looks like's there's been a change of sorts in the Python community 
and they're now adopting the Java stupidity of "the garbage collector doesn't 
actually work so you'll have to do all your own resource management".


These are reasons why projects are so reluctant to move from Python 2 to 3. 
Python 3 is just a different language.


Ah well, guess we'll have to live with that. I'm already getting used to 
embedded devices running 30MB of software to enable the flashlight...



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel