Re: [OE-core] [PATCH 3/3] pulseaudio: fix to manage user services corretly

[Tanu Kaskinen]

On Fri, 2016-09-09 at 20:10 +0200, Pau Espin Pedrol wrote:
> Hi,
> 
> I think I didn't express myself correctly. Please note I did the
> longer investigations quite a while ago and I'm mainly talking from
> memory, so I may be wrong in some of the assumptions.
> 
> From systemd.bbclass, you can see this:
> if service.find('.socket') != -1:
> # for *.socket add *.service and *@.service
> service_base = service.replace('.socket', '')
> systemd_add_files_and_parse(pkg_systemd, path,
> service_base + '.service', keys)
> systemd_add_files_and_parse(pkg_systemd, path,
> service_base + '@.service', keys)
> 
> 
> So, for installation purposes, no .service is required in
> SYSTEMD_USER_SERVICE. Setting it .socket should also install (but not
> enable) the .service file together with the .socket one into the
> image, as actually the .socket one usually depends on the .service
> file at runtime.
> 
> That being said, of course it's not the same behavior if you add only
> one of them, the other or both:
> 1- Adding only .service -> It will install + enable the .service
> 2- Adding only the .socket -> It will install both. It will enable .socket
> 3- Adding .service + .socket -> It will install both. It will enable both.
> 
> Usually, you want either only the .service to be enabled (1, which
> will start it automatically at startup of user session), or only the
> .socket enabled (2, which will start only the socket at startup of
> user session, and only start pulseaudio process when required by some
> pulseaudio client). The third case, that is, installing + enabling
> both is usually not a good idea, at least it makes no sense to me.
> 
> So, we should consider only "1" or "2". I would personally go for 2nd
> option, and probably disable pulseaudio own autospawn system as
> explained by Tanu. This way we don't start pulseaudio unless when it's
> actually needed.
> 
> That is:
> +SYSTEMD_PACKAGES = "${PN}-server"
> +SYSTEMD_USER_SERVICE_${PN}-server = "pulseaudio.socket"
> 
> And by the way, you  should be able to remove
> "${systemd_user_unitdir}/*" from FILES_${PN}-server as it should be
> handled automatically by systemd.bbclass. If that's not the case, then
> probably there's some error in systemd.bbclass you should look into.
> 
> Hope I explained myself better now. Regards!

Thanks for the explanation. Part of my confusion was that I incorrectly
assumed that systemd.bbclass couldn't guess that the pulseaudio-server
package contains systemd units (due to the -server suffix), and
therefore it seemed to me that SYSTEMD_USER_SERVICE is expected to
contain all units, but that problem is fixed by the SYSTEMD_PACKAGES
variable.

Still, I think SYSTEMD_USER_SERVICE is a misleading variable name, if
the actual purpose of that variable is only to control which units to
enable during installation. Something like SYSTEMD_USER_ENABLE_UNITS
would be better. However, this problem is older than these patches (due
to SYSTEMD_SERVICE for system units), so I don't suggest that the
patches should be changed because of this. It indeed seems like the
best course of action would be to only add the pulseaudio.socket unit
to SYSTEMD_USER_SERVICE. Patching client.conf to disable autospawning
in case systemd is enabled would be a good addition, although not
strictly necessary.

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

Re: [OE-core] [PATCH 3/3] pulseaudio: fix to manage user services corretly

[Pau Espin Pedrol]

Hi,

I think I didn't express myself correctly. Please note I did the
longer investigations quite a while ago and I'm mainly talking from
memory, so I may be wrong in some of the assumptions.

>From systemd.bbclass, you can see this:
if service.find('.socket') != -1:
# for *.socket add *.service and *@.service
service_base = service.replace('.socket', '')
systemd_add_files_and_parse(pkg_systemd, path,
service_base + '.service', keys)
systemd_add_files_and_parse(pkg_systemd, path,
service_base + '@.service', keys)


So, for installation purposes, no .service is required in
SYSTEMD_USER_SERVICE. Setting it .socket should also install (but not
enable) the .service file together with the .socket one into the
image, as actually the .socket one usually depends on the .service
file at runtime.

That being said, of course it's not the same behavior if you add only
one of them, the other or both:
1- Adding only .service -> It will install + enable the .service
2- Adding only the .socket -> It will install both. It will enable .socket
3- Adding .service + .socket -> It will install both. It will enable both.

Usually, you want either only the .service to be enabled (1, which
will start it automatically at startup of user session), or only the
.socket enabled (2, which will start only the socket at startup of
user session, and only start pulseaudio process when required by some
pulseaudio client). The third case, that is, installing + enabling
both is usually not a good idea, at least it makes no sense to me.

So, we should consider only "1" or "2". I would personally go for 2nd
option, and probably disable pulseaudio own autospawn system as
explained by Tanu. This way we don't start pulseaudio unless when it's
actually needed.

That is:
+SYSTEMD_PACKAGES = "${PN}-server"
+SYSTEMD_USER_SERVICE_${PN}-server = "pulseaudio.socket"

And by the way, you  should be able to remove
"${systemd_user_unitdir}/*" from FILES_${PN}-server as it should be
handled automatically by systemd.bbclass. If that's not the case, then
probably there's some error in systemd.bbclass you should look into.

Hope I explained myself better now. Regards!


2016-09-08 13:22 GMT+02:00 Tanu Kaskinen :
> On Thu, 2016-09-08 at 14:34 +0800, ChenQi wrote:
>> On 09/07/2016 06:29 PM, Pau Espin Pedrol wrote:
>> >
>> >
>> >
>> > Pau Espin Pedrol
>> >
>> > 2016-09-07 11:22 GMT+02:00 Chen Qi > > >:
>> >
>> > Make use of the new SYSTEMD_USER_SERVICE variable added in
>> > systemd.bbclass
>> > to manage user services in pulseaudio-server package.
>> >
>> > Signed-off-by: Chen Qi > > >
>> > ---
>> >  meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
>> > b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
>> > index 6ed79ef..f3754d7 100644
>> > --- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
>> > +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
>> > @@ -124,8 +124,8 @@ FILES_${PN}-conf = "${sysconfdir}"
>> >  FILES_${PN}-bin +=
>> > "${sysconfdir}/default/volatiles/volatiles.04_pulse"
>> >  FILES_${PN}-server = "${bindir}/pulseaudio ${bindir}/start-*
>> > ${sysconfdir} ${bindir}/pactl */udev/rules.d/*.rules
>> > */*/udev/rules.d/*.rules ${systemd_user_unitdir}/*"
>> >
>> > -#SYSTEMD_PACKAGES = "${PN}-server"
>> > -SYSTEMD_SERVICE_${PN}-server = "pulseaudio.service"
>> > +SYSTEMD_PACKAGES = "${PN}-server"
>> > +SYSTEMD_USER_SERVICE_${PN}-server = "pulseaudio.service
>> > pulseaudio.socket"
>> >
>> > I think specifying "pulseaudio.socket" for
>> > SYSTEMD_USER_SERVICE_${PN}-server should be enough, systemd.bbclass is
>> > going to add the .service file afair.
>>
>> Add both:
>> chenqi@pek-hostel-deb01:~/poky/build-systemd [1] $ ls
>> tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/systemd/user
>> default.target.wants  sockets.target.wants
>>
>> Add pulseaudio.socket:
>> chenqi@pek-hostel-deb01:~/poky/build-systemd [1] $ ls
>> tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/systemd/user
>> sockets.target.wants
>>
>> They have different results.
>> I don't know a lot about pulseaudio. Can you confirm that
>> pulseaudio.socket is enough?
>
> If I understood correctly, Pau's argument was that there would be no
> difference, which doesn't seem to be the case. However, if
> pulseaudio.service isn't included in default.target.wants, that
> shouldn't be a big problem, because socket activation will anyway start
> the service when needed. On the other hand, I don't
> think SYSTEMD_USER_SERVICE is intended to be used for controlling which
> units to enable - it looks more like a variable that should 

Re: [OE-core] [PATCH v2] python-3.5-manifest.inc: the core module RDEPENDS on misc

[Fabio Berton]

Hi Ricardo,

Take a look at commit:
http://cgit.openembedded.org/openembedded-core/commit/?h=krogoth=8bbfe9bd229e3f795577eb5df1cd5104651e2ba2

this commit fix your issue.

Regards

On Tue, Aug 30, 2016 at 10:37 AM, Ricardo Ribalda Delgado <
ricardo.riba...@gmail.com> wrote:

> Hi Fabio
>
> Thanks for your the reply. Yes I was using krogoth. There is no need
> for my patch in master.
>
> Thanks for your help!
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/3] systemd.bbclass: add support to manage user services

[Pau Espin Pedrol]

Hi,

Pau Espin Pedrol

2016-09-08 4:33 GMT+02:00 ChenQi :

> On 09/07/2016 08:14 PM, Pau Espin Pedrol wrote:
>
>
> 2016-09-07 11:22 GMT+02:00 Chen Qi :
>
>> Add new variable SYSTEMD_USER_SERVICE and SYSTEM_USER_AUTO_ENABLE
>> to manage user services. Their usage is like SYSTEMD_SERVICE and
>> SYSTEMD_AUTO_ENABLE.
>>
>> [YOCTO #7800]
>>
>> Signed-off-by: Chen Qi 
>> ---
>>  meta/classes/systemd.bbclass | 17 +
>>  1 file changed, 13 insertions(+), 4 deletions(-)
>>
>> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
>> index db7873f..78cec97 100644
>> --- a/meta/classes/systemd.bbclass
>> +++ b/meta/classes/systemd.bbclass
>> @@ -7,6 +7,7 @@ SYSTEMD_PACKAGES_class-nativesdk ?= ""
>>
>>  # Whether to enable or disable the services on installation.
>>  SYSTEMD_AUTO_ENABLE ??= "enable"
>> +SYSTEMD_USER_AUTO_ENABLE ??= "enable"
>>
>>  # This class will be included in any recipe that supports systemd init
>> scripts,
>>  # even if systemd is not in DISTRO_FEATURES.  As such don't make any
>> changes
>> @@ -30,10 +31,14 @@ fi
>>
>>  if type systemctl >/dev/null 2>/dev/null; then
>> systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
>> +   systemctl $OPTS --global ${SYSTEMD_USER_AUTO_ENABLE}
>> ${SYSTEMD_USER_SERVICE}
>>
>
> I'm not sure having these 2 systemctl being executed together everytime is
> a good idea. What if a recipe has a user service and no system service?
>
>
> Hi Pau Espin Pedrol,
>
> Thanks for your review.
>
> The postinstall script runs successfully with expected result at rootfs
> time. But your question reminds me of the situation of the on-target
> install/remove situation. I think I'll need to make a new patch to make
> sure things work in both situations.
>
> The key point here is that 'systemctl' at rootfs time is a shell script
> written by ourselves and 'systemctl' on target is that provided by systemd.
>

Yes, I was unaware of the existance of that OE script when I worked on
this. Why are we using that script at build time instead of using systemd's
systemctl? Any good reason for that? git log only shows it was imported
from another repo a while ago.


>
> We are calling the first one with an empty system service? Or we are may
> be enabling a systemd system service which should not be enabled according
> to the recipe? I have the feeling this kind of cases are not being catch in
> here and other pkg scripts in this commit.
>
> It is far from perfect, but in case you didn't, you may want to have a
> look at my initial/previous commit to try to fix the issue:
> https://www.mail-archive.com/openembedded-devel@lists.
> openembedded.org/msg42187.html
>
>
>>
>> if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
>> systemctl restart ${SYSTEMD_SERVICE}
>> fi
>> +   if [ -z "$D" -a "${SYSTEMD_USER_AUTO_ENABLE}" = "enable" ]; then
>> +   systemctl --global restart ${SYSTEMD_USER_SERVICE}
>> +   fi
>>  fi
>>  }
>>
>> @@ -47,9 +52,11 @@ fi
>>  if type systemctl >/dev/null 2>/dev/null; then
>> if [ -z "$D" ]; then
>> systemctl stop ${SYSTEMD_SERVICE}
>> +   systemctl --global stop ${SYSTEMD_USER_SERVICE}
>>
>
> I think this is not gonna work, you cannot call --global with stop afair.
> I'm not sure which is the good solution for this though, but you should
> ideally go through all systemd user sessions and call "systemctl --user
> stop". No idea if that's actually easily feasible.
>
>
> The service is enabled and started with '--global' option, and stopping it
> with '--global' option seems reasonable to me. If there's some special
> case, let's look into it then.
>
>

Did you try running it in a running image? As in taking the ipkg, and
reinstalling it live in the image with systemd's systemctl. I bet you will
get an error from systemctl for both "--gobal restart" and "--global stop".
At least it used to be like that afair.



> Best Regards,
> Chen Qi
>
>
>
>
>> fi
>>
>> systemctl $OPTS disable ${SYSTEMD_SERVICE}
>> +   systemctl $OPTS --global disable ${SYSTEMD_USER_SERVICE}
>>  fi
>>  }
>>
>> @@ -139,12 +146,14 @@ python systemd_populate_packages() {
>>  def systemd_check_services():
>>  searchpaths = [oe.path.join(d.getVar("sysconfdir", True),
>> "systemd", "system"),]
>>  searchpaths.append(d.getVar("systemd_system_unitdir", True))
>> +searchpaths.append(oe.path.join(d.getVar("sysconfdir", True),
>> "systemd", "user"))
>> +searchpaths.append(d.getVar("systemd_user_unitdir", True))
>>  systemd_packages = d.getVar('SYSTEMD_PACKAGES', True)
>>
>>  keys = 'Also'
>>  # scan for all in SYSTEMD_SERVICE[]
>>  for pkg_systemd in systemd_packages.split():
>> -for service in get_package_var(d, 'SYSTEMD_SERVICE',
>> pkg_systemd).split():
>> +for service in 

[OE-core] [PATCH 0/1] qemurunner:log testimage qemu launch command

[bavery]

This logs the command that "bitbake  -c testimage" used to launch qemu.
This is helpful if a test failed and you would like to manually start qemu in 
the
same way to debug the failed test.  With this addition you can just cut and 
paste
the runqemu command from the log.do_testimage file.

-b

The following changes since commit 2679a347c576f5411fbe802d2f6201c94036ecb2:

  maintainers.inc: rename gtk-doc-stub to gtk-doc, reassign to me (2016-09-09 
12:12:59 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib bavery/log-runqemu
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=bavery/log-runqemu

bavery (1):
  qemurunner: print out the runqemu command

 meta/lib/oeqa/utils/qemurunner.py | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

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

[OE-core] [PATCH 1/1] qemurunner: print out the runqemu command

[bavery]

This logs the launch command that was used for runqemu while running -c
testimage.  This way, if I'd like to easily launch qemu manually in
order to debug a failed test, I know what commmand was run to create
the qemu instance.

Signed-off-by: bavery 
---
 meta/lib/oeqa/utils/qemurunner.py | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 9783ff8..1f98682 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -141,6 +141,8 @@ class QemuRunner:
 else:
 logger.info('Not using kvm for runqemu')
 launch_cmd += 'tcpserial=%s %s %s %s' % (self.serverport, 
self.machine, self.rootfs, self.qemuparams)
+logger.info('launchcmd=%s'%(launch_cmd))
+
 # FIXME: We pass in stdin=subprocess.PIPE here to work around stty
 # blocking at the end of the runqemu script when using this within
 # oe-selftest (this makes stty error out immediately). There ought
@@ -149,12 +151,12 @@ class QemuRunner:
 output = self.runqemu.stdout
 
 #
-# We need the preexec_fn above so that all runqemu processes can 
easily be killed 
+# We need the preexec_fn above so that all runqemu processes can 
easily be killed
 # (by killing their process group). This presents a problem if this 
controlling
-# process itself is killed however since those processes don't notice 
the death 
+# process itself is killed however since those processes don't notice 
the death
 # of the parent and merrily continue on.
 #
-# Rather than hack runqemu to deal with this, we add something here 
instead. 
+# Rather than hack runqemu to deal with this, we add something here 
instead.
 # Basically we fork off another process which holds an open pipe to 
the parent
 # and also is setpgrp. If/when the pipe sees EOF from the parent 
dieing, it kills
 # the process group. This is like pctrl's PDEATHSIG but for a process 
group
-- 
1.9.1

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

[OE-core] [PATCH 1/1] testimage: add createrepo-native to testimage depends

[bavery]

The smart tests need createrepo to be in the native sysroot. It needs
to be one of the depends for testimage.

Signed-off-by: bavery 
---
 meta/classes/testimage.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index e42c5ac..263d539 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -67,6 +67,7 @@ TESTIMAGEDEPENDS = ""
 TESTIMAGEDEPENDS_qemuall = "qemu-native:do_populate_sysroot 
qemu-helper-native:do_populate_sysroot"
 TESTIMAGEDEPENDS += "${@bb.utils.contains('IMAGE_PKGTYPE', 'rpm', 
'cpio-native:do_populate_sysroot', '', d)}"
 TESTIMAGEDEPENDS_qemuall += "${@bb.utils.contains('IMAGE_PKGTYPE', 'rpm', 
'cpio-native:do_populate_sysroot', '', d)}"
+TESTIMAGEDEPENDS_qemuall += "${@bb.utils.contains('IMAGE_PKGTYPE', 'rpm', 
'createrepo-native:do_populate_sysroot', '', d)}"
 
 TESTIMAGELOCK = "${TMPDIR}/testimage.lock"
 TESTIMAGELOCK_qemuall = ""
-- 
1.9.1

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

[OE-core] [PATCH 0/1] testimage:add createrepo-native to depends

[bavery]

This adds the createrepo-native to the depends for testimage.  Without this,
if you just make the dependencies you need for testimage (for instance if you
already have the image to test) you would be missing the createrepo-native 
needed
by testimage.

-b

The following changes since commit 2679a347c576f5411fbe802d2f6201c94036ecb2:

  maintainers.inc: rename gtk-doc-stub to gtk-doc, reassign to me (2016-09-09 
12:12:59 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib bavery/fix-createrepo-native-missing
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=bavery/fix-createrepo-native-missing

bavery (1):
  testimage: add createrepo-native to testimage depends

 meta/classes/testimage.bbclass | 1 +
 1 file changed, 1 insertion(+)

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

[OE-core] [PATCH] mesa: update to 12.0.2

[Andreas Müller]

* removed patch was applied mainline
* tested on RaspberryPi2 weston / lxqt / kde

Signed-off-by: Andreas Müller 
---
 .../mesa/files/clang-compile-PR89599.patch | 116 -
 .../mesa/{mesa-gl_12.0.1.bb => mesa-gl_12.0.2.bb}  |   0
 .../mesa/{mesa_12.0.1.bb => mesa_12.0.2.bb}|   5 +-
 3 files changed, 2 insertions(+), 119 deletions(-)
 delete mode 100644 meta/recipes-graphics/mesa/files/clang-compile-PR89599.patch
 rename meta/recipes-graphics/mesa/{mesa-gl_12.0.1.bb => mesa-gl_12.0.2.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_12.0.1.bb => mesa_12.0.2.bb} (77%)

diff --git a/meta/recipes-graphics/mesa/files/clang-compile-PR89599.patch 
b/meta/recipes-graphics/mesa/files/clang-compile-PR89599.patch
deleted file mode 100644
index 48bd325..000
--- a/meta/recipes-graphics/mesa/files/clang-compile-PR89599.patch
+++ /dev/null
@@ -1,116 +0,0 @@
-From 5ec140c17b54c25920091501b665b9aa809cc5e8 Mon Sep 17 00:00:00 2001
-From: Matt Turner 
-Date: Mon, 11 Jul 2016 10:44:25 -0700
-Subject: mapi: Massage code to allow clang to compile.
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-According to https://llvm.org/bugs/show_bug.cgi?id=19778#c3 this code
-was violating the spec, resulting in it failing to compile.
-
-Cc: mesa-sta...@lists.freedesktop.org
-Co-authored-by: Tomasz Paweł Gajc 
-Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89599
-Reviewed-by: Emil Velikov 
-
-Upstream-Status: Backport
-Signed-off-by: Khem Raj 
-
-diff --git a/configure.ac b/configure.ac
-index 3799d8d..1ca8359 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -226,6 +226,7 @@ AX_GCC_FUNC_ATTRIBUTE([packed])
- AX_GCC_FUNC_ATTRIBUTE([pure])
- AX_GCC_FUNC_ATTRIBUTE([returns_nonnull])
- AX_GCC_FUNC_ATTRIBUTE([unused])
-+AX_GCC_FUNC_ATTRIBUTE([visibility])
- AX_GCC_FUNC_ATTRIBUTE([warn_unused_result])
- AX_GCC_FUNC_ATTRIBUTE([weak])
- 
-diff --git a/src/mapi/entry_x86-64_tls.h b/src/mapi/entry_x86-64_tls.h
-index 38faccc..c5262a1 100644
 a/src/mapi/entry_x86-64_tls.h
-+++ b/src/mapi/entry_x86-64_tls.h
-@@ -25,6 +25,11 @@
-  *Chia-I Wu 
-  */
- 
-+#ifdef HAVE_FUNC_ATTRIBUTE_VISIBIITY
-+#define HIDDEN __attribute__((visibility("hidden")))
-+#else
-+#define HIDDEN
-+#endif
- 
- __asm__(".text\n"
- ".balign 32\n"
-@@ -54,8 +59,8 @@ entry_patch_public(void)
- {
- }
- 
--static char
--x86_64_entry_start[];
-+extern char
-+x86_64_entry_start[] HIDDEN;
- 
- mapi_func
- entry_get_public(int slot)
-diff --git a/src/mapi/entry_x86_tls.h b/src/mapi/entry_x86_tls.h
-index 46d2ece..231b409 100644
 a/src/mapi/entry_x86_tls.h
-+++ b/src/mapi/entry_x86_tls.h
-@@ -27,6 +27,12 @@
- 
- #include 
- 
-+#ifdef HAVE_FUNC_ATTRIBUTE_VISIBIITY
-+#define HIDDEN __attribute__((visibility("hidden")))
-+#else
-+#define HIDDEN
-+#endif
-+
- __asm__(".text");
- 
- __asm__("x86_current_tls:\n\t"
-@@ -71,8 +77,8 @@ __asm__(".text");
- extern unsigned long
- x86_current_tls();
- 
--static char x86_entry_start[];
--static char x86_entry_end[];
-+extern char x86_entry_start[] HIDDEN;
-+extern char x86_entry_end[] HIDDEN;
- 
- void
- entry_patch_public(void)
-diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
-index ea7bacb..03d9735 100644
 a/src/mapi/entry_x86_tsd.h
-+++ b/src/mapi/entry_x86_tsd.h
-@@ -25,6 +25,11 @@
-  *Chia-I Wu 
-  */
- 
-+#ifdef HAVE_FUNC_ATTRIBUTE_VISIBIITY
-+#define HIDDEN __attribute__((visibility("hidden")))
-+#else
-+#define HIDDEN
-+#endif
- 
- #define X86_ENTRY_SIZE 32
- 
-@@ -58,8 +63,8 @@ __asm__(".balign 32\n"
- #include 
- #include "u_execmem.h"
- 
--static const char x86_entry_start[];
--static const char x86_entry_end[];
-+extern const char x86_entry_start[] HIDDEN;
-+extern const char x86_entry_end[] HIDDEN;
- 
- void
- entry_patch_public(void)
--- 
-cgit v0.10.2
-
diff --git a/meta/recipes-graphics/mesa/mesa-gl_12.0.1.bb 
b/meta/recipes-graphics/mesa/mesa-gl_12.0.2.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_12.0.1.bb
rename to meta/recipes-graphics/mesa/mesa-gl_12.0.2.bb
diff --git a/meta/recipes-graphics/mesa/mesa_12.0.1.bb 
b/meta/recipes-graphics/mesa/mesa_12.0.2.bb
similarity index 77%
rename from meta/recipes-graphics/mesa/mesa_12.0.1.bb
rename to meta/recipes-graphics/mesa/mesa_12.0.2.bb
index 80189e3..12a5495 100644
--- a/meta/recipes-graphics/mesa/mesa_12.0.1.bb
+++ b/meta/recipes-graphics/mesa/mesa_12.0.2.bb
@@ -2,12 +2,11 @@ require ${BPN}.inc
 
 SRC_URI = "ftp://ftp.freedesktop.org/pub/mesa/${PV}/mesa-${PV}.tar.xz \
file://replace_glibc_check_with_linux.patch \
-   file://clang-compile-PR89599.patch \
file://disable-asm-on-non-gcc.patch \
 "
 
-SRC_URI[md5sum] = "972fd5ad5a63aeabf173fb9adefc6522"
-SRC_URI[sha256sum] = 
"bab24fb79f78c876073527f515ed871fc9c81d816f66c8a0b051d8d653896389"

[OE-core] Topics & attendance for OEDEM

[Jeff Osier-Mixon]

This is a reminder about the OpenEmbedded General Assembly (GA) and
Developer's European Meeting (OEDEM) coming up on October 14 in
Berlin, following ELCE. If you are able to attend, please let us know
ASAP so we can plan. You can sign up for this event on the wiki at
this address:

GA: http://openembedded.org/wiki/Berlin,_2016
DEM: http://openembedded.org/wiki/OEDEM_2016

Note: these are on the same day. The GA will start at about 9am,
developers portion immediately after but not likely before 10am. More
details to come soon.

-- 
Jeff Osier-Mixon - Open Source Community Engineer, Intel Corporation
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Subjects for YP Developer Day at ELCE

[Jeff Osier-Mixon]

...nd HERE's the link
https://www.yoctoproject.org/yocto-project-developer-day-europe-2016

On Fri, Sep 9, 2016 at 8:51 AM, Jeff Osier-Mixon  wrote:
> Hi all - we are in the planning stages for DevDay at ELCE right now,
> particularly the advanced track. This track changes every session,
> usually to cover the things we are working on hardest - for example,
> in San Diego we covered CROPS, devtool, the latest Toaster features,
> and much more.
>
> Whether you are able to attend DevDay or not, we would be grateful to
> hear your suggestions for subjects to cover in the advanced track. We
> are currently planning talks about CROPS, devtool and the ESDK,
> Toaster, wic, smack, security, and a few other things. If you have a
> burning desire to hear about something specific, please let us know.
>
> Also, we'd love to see you at DevDay, here's the link:
>
> --
> Jeff Osier-Mixon - Open Source Community Engineer, Intel Corporation



-- 
Jeff Osier-Mixon - Open Source Community Engineer, Intel Corporation
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Subjects for YP Developer Day at ELCE

[Jeff Osier-Mixon]

Hi all - we are in the planning stages for DevDay at ELCE right now,
particularly the advanced track. This track changes every session,
usually to cover the things we are working on hardest - for example,
in San Diego we covered CROPS, devtool, the latest Toaster features,
and much more.

Whether you are able to attend DevDay or not, we would be grateful to
hear your suggestions for subjects to cover in the advanced track. We
are currently planning talks about CROPS, devtool and the ESDK,
Toaster, wic, smack, security, and a few other things. If you have a
burning desire to hear about something specific, please let us know.

Also, we'd love to see you at DevDay, here's the link:

-- 
Jeff Osier-Mixon - Open Source Community Engineer, Intel Corporation
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Status WW37

[Jolley, Stephen K]

Current Dev Position: YP 2.2 M4 (M3 Building rc1)

Next Deadline: YP 2.2 M4 which will be Oct. 3rd (5:00pm GMT)


SWAT team rotation: Alejandro -> Jussi

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

*M3 has continued to be problematic:

o   The qemuppc networking issue looks like it was a TCG bug in qemu which was 
fixed in qemu 2.7.0.

o   The upgraded qemu had build issues and didn't pass runtime sanity tests due 
to new dmesg warnings

o   The "Killed" smart failures turned out to be OOM issues, particular on 
x86_64 which we fixed

o   After fixing the OOM issues, we found other weird smart failures. We have a 
hack in place to work around this with small time delays so as not to delay M3 
any further.

o   There were several regressions identified in the runqemu changes which we 
ended up queuing patches for

o   There was a significant performance degradation in the build time and disk 
usage of the kernel after the 4.8 kernel merged. This was tracked down to 
misconfiguration of the kernel and has been fixed, solving the buildtime and 
space regressions.

o   The gtkdoc changes were found to cause too much of a build time 
degradation, even disabled. We fixed the performance of the disabled case in 
the end and merged with them disabled by default for now.

*With all the above either with fixes or workarounds in place, we now 
have M3-rc1 finally building and hope it will be good enough to make it into QA.

*We are seeing a downward turn in bug tracking metrics which is what we 
hope to see at this point in the cycle so that is at least some good news. It 
isn't quite at the level we started the release at though.

*We will try and run a krogoth test build as soon as M3 is dealt with 
as I know several people are waiting on things to merge there. Armin should 
have most things queued (thanks!).


Key YP 2.2 Dates:

*YP 2.2 M3 release would be: 9/9/16

*YP 2.2 M4 cut off would be: 10/3/16

*YP 2.2 M4 release would be: 10/28/16


Tracking Metrics:

WDD 2589 (last week 2651)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features


[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:   (208) 244-4460
* Email:stephen.k.jol...@intel.com

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

[OE-core] Yocto Bugzilla category cleanup

[Jolley, Stephen K]

All,



We are planning to spin up a team to look at redefining/cleaning up the 
categories in Yocto's bugzilla.  We will then work on the migration to these 
new categories and ensure each category has the correct default owner.   If you 
are interested in being an active participant, please let 
stephen.k.jol...@intel.com know.  The 
meeting will likely be at a time suitable for Americas and EU people since 
several key participants are in these time zones and will happen early in the 
2.3 cycle.



Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:   (208) 244-4460
* Email:stephen.k.jol...@intel.com

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

Re: [OE-core] [PATCH 00/28] Enable gtk-doc

[Richard Purdie]

On Mon, 2016-09-05 at 08:58 +0200, Anders Darander wrote:
> * Alexander Kanavin  [160902
> 17:08]:
> 
> > 
> > On 09/02/2016 12:59 AM, Randy MacLeod wrote:
> > > 
> > > > 
> > > > Gtk-doc generation happens if 'api-documentation' distro
> > > > feature is
> > > > enabled
> > > > (it is by default), and 'qemu-usermode' is in machine features.
> > 
> > > 
> > > Should this really be enabled by default?
> > > What does it do to a typical build wrt time and space?
> > 
> > The default distro feature list also includes all of the available
> > communication stacks, full x11 stack, pulseaudio etc. It seems to
> > me that
> > the aim is to enable as many various features as possible by
> > default.
> > Distros can and should trim the list to their specific needs.
> Sure, but as far as I remember, doc building is disabled in most
> cases.
> And personally, I'd prefer to have the doc-generation disabled per
> default. (As usually, most people I've met, won't use the doc's built
> here anyway).

There is a fairly big performance hit to enabling gtk-doc. We've
adjusted the patchset so when disabled, there isn't much of a
performance hit and I've merged things with the default being "off" for
now. We can then work through the other details and see if there is
anything we can do about the performance.

This is one of the reasons the patch series has taken a while to merge
and there were a number of issues trying to make the M3 build work and
pass testing (see the weekly status reports).

Cheers,

Richard


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

[OE-core] [PATCH] oeqa/parselogs: Don't use cwd for file transfers

[Richard Purdie]

If you run:

MACHINE=A bitbake  -c testimage
MACHINE=B bitbake  -c testimage

and A has errors in parselogs, machine B can pick these up and cause
immense confusion. This is because the test transfers the log files
to cwd which is usually TOPDIR. This is clearly bad and this patch
uses a subdir of WORKDIR to ensure machines don't contaminate each
other.

Also ensure any previous logs are cleaned up from any existing
transfer directory.

Signed-off-by: Richard Purdie 

diff --git a/meta/lib/oeqa/runtime/parselogs.py 
b/meta/lib/oeqa/runtime/parselogs.py
index 98a959e..8238a77 100644
--- a/meta/lib/oeqa/runtime/parselogs.py
+++ b/meta/lib/oeqa/runtime/parselogs.py
@@ -180,6 +180,9 @@ class ParseLogsTest(oeRuntimeTest):
 def getMachine(self):
 return oeRuntimeTest.tc.d.getVar("MACHINE", True)
 
+def getWorkdir(self):
+return oeRuntimeTest.tc.d.getVar("WORKDIR", True)
+
 #get some information on the CPU of the machine to display at the 
beginning of the output. This info might be useful in some cases.
 def getHardwareInfo(self):
 hwi = ""
@@ -217,16 +220,19 @@ class ParseLogsTest(oeRuntimeTest):
 
 #copy the log files to be parsed locally
 def transfer_logs(self, log_list):
-target_logs = 'target_logs'
+workdir = self.getWorkdir()
+self.target_logs = workdir + '/' + 'target_logs'
+target_logs = self.target_logs
 if not os.path.exists(target_logs):
 os.makedirs(target_logs)
+bb.utils.remove(self.target_logs + "/*")
 for f in log_list:
 self.target.copy_from(f, target_logs)
 
 #get the local list of logs
 def get_local_log_list(self, log_locations):
 self.transfer_logs(self.getLogList(log_locations))
-logs = [ os.path.join('target_logs',f) for f in 
os.listdir('target_logs') if os.path.isfile(os.path.join('target_logs',f)) ]
+logs = [ os.path.join(self.target_logs, f) for f in 
os.listdir(self.target_logs) if os.path.isfile(os.path.join(self.target_logs, 
f)) ]
 return logs
 
 #build the grep command to be used with filters and exclusions



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

Re: [OE-core] [PATCH] gst-player: include SRCPV in PV

[Burton, Ross]

On 9 September 2016 at 06:57, Markus Lehtonen <
markus.lehto...@linux.intel.com> wrote:

> +PV = "git${SRCPV}"
>

This breaks packaging for me, throwing interesting python exceptions.

gst-player has a version in configure.ac, so this should be
0.0.1+git${SRCPV} I guess.

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

Re: [OE-core] [RFC][PATCH] report-error.bbclass: Add support for autosending

[Beth 'pidge' Flanagan]

On Fri, 2016-09-09 at 11:31 +0200, Martin Jansa wrote:
> On Thu, Sep 08, 2016 at 11:26:01AM +0200, Elizabeth 'pidge' Flanagan
> wrote:
> > 
> > This commit pulls and extends the functionality of .oe-error-report 
> > into
> > local.conf. It maintains the functionality of .oe-error-report.
> > 
> > It also enables report-error to automatically send error reports to
> > a 
> > specified error report server. This patch enables infrastructure
> > ppl to
> > set development teams up so that we can gather error metrics
> > automatically.
> > 
> > This relies on a new set of variables:
> > 
> > REPORTERROR[autosend]="yes|no|ask"
> > REPORTERROR[user]=username
> > REPORTERROR[email]=email
> > REPORTERROR[server]=error-report-web instance
> > 
> > For autosend yes and no are pretty self explainatory. ask does not
> > pass
> > the -y flag to send-error-report, thus enabling the end user to
> > review
> > the report prior to submission.
> The same functionality was sent more than 2 years ago, but it was
> rejected, so I'm carrying it in our own fork since then:
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2014-March/
> 091222.html
> 

I'd be happy to defer to that patch if we can pull this functionality
in.

-b

> > 
> > Signed-off-by: Elizabeth 'pidge' Flanagan 
> > ---
> >  meta/classes/report-error.bbclass | 41
> > +--
> >  1 file changed, 39 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/classes/report-error.bbclass
> > b/meta/classes/report-error.bbclass
> > index 82b5bcd..909adf0 100644
> > --- a/meta/classes/report-error.bbclass
> > +++ b/meta/classes/report-error.bbclass
> > @@ -85,10 +85,47 @@ python errorreport_handler () {
> >  bb.utils.unlockfile(lock)
> >  failures = jsondata['failures']
> >  if(len(failures) > 0):
> > +
> >  filename = "error_report_" +
> > e.data.getVar("BUILDNAME", True)+".txt"
> >  datafile = errorreport_savedata(e, jsondata,
> > filename)
> > -bb.note("The errors for this build are stored in
> > %s\nYou can send the errors to a reports server by
> > running:\n  send-error-report %s [-s server]" % (datafile,
> > datafile))
> > -bb.note("The contents of these logs will be posted
> > in public if you use the above command with the default server.
> > Please ensure you remove any identifying or proprietary information
> > when prompted before sending.")
> > +
> > +cmd_s = "send-error-report %s" % datafile
> > +response_s = "The errors for this build are stored
> > in %s\n" % datafile
> > +sendit = False
> > +
> > +autosend =
> > e.data.getVarFlag("REPORTERROR","autosend")
> > +user = e.data.getVarFlag("REPORTERROR","user")
> > +email = e.data.getVarFlag("REPORTERROR","email")
> > +server = e.data.getVarFlag("REPORTERROR","server")
> > +
> > +if user is not None:
> > +cmd_s += " -n %s" % user
> > +if email is not None:
> > +cmd_s += " -e %s" % email
> > +if server is not None:
> > +cmd_s += " -s %s" % server
> > +
> > +if autosend is not None:
> > +if autosend == "yes":
> > +response_s += "The errors for this build
> > are set to automatically be sent.\n"
> > +cmd_s += " -y"
> > +sendit = True
> > +elif autosend == "ask":
> > +response_s += "The errors for this build
> > are set to automatically be sent.\n"
> > +sendit = True
> > +elif autosend is None:
> > +response_s += "You can send the errors to
> > a reports server by running:\n  %s\n" % cmd_s
> > +elif e.data.getVarFlags('REPORTERROR') is None:
> > +response_s += "You can send the errors to
> > a reports server by running:\n  %s [-s server]\n" % cmd_s
> > +response_s += "The contents of these logs
> > will be posted in public if you use the above command with the
> > default server.\n \
> > + Please ensure you remove any
> > identifying or proprietary information when prompted before
> > sending.\n"
> > +
> > +bb.note(response_s)
> > +
> > +if sendit == True:
> > +import shlex, subprocess
> > +args = shlex.split(cmd_s)
> > +subprocess.call(args)
> >  }
> >  
> >  addhandler errorreport_handler
> > -- 
> > 2.9.3
> > 
> > -- 
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 

Re: [OE-core] [PATCH] pango: add libpcre to DEPENDS

[Burton, Ross]

On 9 September 2016 at 10:32, Ioan-Adrian Ratiu  wrote:

> I cleared the build directory and sstate cache, started with a clean
> rebuild and I can't reproduce the error anymore. gen-all-unicode is
> built as expected and at runtime it links with libpcre as expected
> and the build succeeds. This is really weird, I didn't touch these
> packages at all, they just sporadically failed out of the blue and now
> they work.
>

That's good, right? :)

If you ever manage to replicate, please save the build directory for
inspection.

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

Re: [OE-core] [PATCH] perl: correct the path of perl used by ptest

[zhenbo]

Hi Bill,

Sorry that i just notice this email, sorry for the late reply.

I made this patch based on the following two points:
1. Please see commit 467eb93f and 84a39786, there has the following code 
in files automake_1.15.bb and autoconf.inc:

CACHED_CONFIGUREVARS += "ac_cv_path_PERL=${USRBINPATH}/perl"
2. The familiar modifications for other files are accepted by oe-core, 
like gobject-introspection groff texi2html quilt and so on...


Thanks,
Zhenbo


On 2016年08月31日 22:42, Bill Randle wrote:
Under what conditions is the explicit path to /usr/bin/perl required? 
Just before your added code, it creates a symlink from the installed 
perl location to the "t" directory where the tests are run. What if 
the perl that was built was an alternate version and installed in 
/usr/local/bin?


-Bill

On Tue, Aug 30, 2016 at 10:37 PM, Zhenbo Gao > wrote:


some files from perl-ptest depends on perl, which is located at
/usr/bin/

Signed-off-by: Zhenbo Gao >
---
 meta/recipes-devtools/perl/perl-ptest.inc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-devtools/perl/perl-ptest.inc
b/meta/recipes-devtools/perl/perl-ptest.inc
index d136c5c..94e40e6 100644
--- a/meta/recipes-devtools/perl/perl-ptest.inc
+++ b/meta/recipes-devtools/perl/perl-ptest.inc
@@ -24,6 +24,12 @@ do_install_ptest () {

ln -sf ${bindir}/perl ${D}${PTEST_PATH}/t/perl

+   # perl is located at /usr/bin/
+   p='^#![/.]*perl'
+   files=`grep -E ${p} ${D} -nr | grep -v -E 'Binary|win32' |
cut -d ':' -f 1`
+   for f in ${files}; do
+   sed -i -e "s:${p}:#! ${USRBINPATH}/perl:g" ${f}
+   done
 }

 python populate_packages_prepend() {
--
1.9.1

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core





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

Re: [OE-core] [PATCH] pango: add libpcre to DEPENDS

[Ioan-Adrian Ratiu]

On Thu, 08 Sep 2016, "Burton, Ross"  wrote:
> On 8 September 2016 at 11:37, Ioan-Adrian Ratiu  wrote:
>
>> No. It fails sporadically on the jenkins build machine when it's under
>> load. Somehow adding the pcre dependency directly to pango fixes the
>> build machine which is really weird. I can't replicate this on my dev
>> machine.
>>
>
> Can you get access to the build directory when it fails?  It would be
> interesting to see what ldd says the gen-all-unicode is linking to.

I cleared the build directory and sstate cache, started with a clean
rebuild and I can't reproduce the error anymore. gen-all-unicode is
built as expected and at runtime it links with libpcre as expected
and the build succeeds. This is really weird, I didn't touch these
packages at all, they just sporadically failed out of the blue and now
they work.

>
> Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH] report-error.bbclass: Add support for autosending

[Martin Jansa]

On Thu, Sep 08, 2016 at 11:26:01AM +0200, Elizabeth 'pidge' Flanagan wrote:
> This commit pulls and extends the functionality of .oe-error-report into
> local.conf. It maintains the functionality of .oe-error-report.
> 
> It also enables report-error to automatically send error reports to a 
> specified error report server. This patch enables infrastructure ppl to
> set development teams up so that we can gather error metrics automatically.
> 
> This relies on a new set of variables:
> 
> REPORTERROR[autosend]="yes|no|ask"
> REPORTERROR[user]=username
> REPORTERROR[email]=email
> REPORTERROR[server]=error-report-web instance
> 
> For autosend yes and no are pretty self explainatory. ask does not pass
> the -y flag to send-error-report, thus enabling the end user to review
> the report prior to submission.

The same functionality was sent more than 2 years ago, but it was
rejected, so I'm carrying it in our own fork since then:

http://lists.openembedded.org/pipermail/openembedded-core/2014-March/091222.html

> Signed-off-by: Elizabeth 'pidge' Flanagan 
> ---
>  meta/classes/report-error.bbclass | 41 
> +--
>  1 file changed, 39 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/report-error.bbclass 
> b/meta/classes/report-error.bbclass
> index 82b5bcd..909adf0 100644
> --- a/meta/classes/report-error.bbclass
> +++ b/meta/classes/report-error.bbclass
> @@ -85,10 +85,47 @@ python errorreport_handler () {
>  bb.utils.unlockfile(lock)
>  failures = jsondata['failures']
>  if(len(failures) > 0):
> +
>  filename = "error_report_" + e.data.getVar("BUILDNAME", 
> True)+".txt"
>  datafile = errorreport_savedata(e, jsondata, filename)
> -bb.note("The errors for this build are stored in %s\nYou can 
> send the errors to a reports server by running:\n  send-error-report %s [-s 
> server]" % (datafile, datafile))
> -bb.note("The contents of these logs will be posted in public 
> if you use the above command with the default server. Please ensure you 
> remove any identifying or proprietary information when prompted before 
> sending.")
> +
> +cmd_s = "send-error-report %s" % datafile
> +response_s = "The errors for this build are stored in %s\n" 
> % datafile
> +sendit = False
> +
> +autosend = e.data.getVarFlag("REPORTERROR","autosend")
> +user = e.data.getVarFlag("REPORTERROR","user")
> +email = e.data.getVarFlag("REPORTERROR","email")
> +server = e.data.getVarFlag("REPORTERROR","server")
> +
> +if user is not None:
> +cmd_s += " -n %s" % user
> +if email is not None:
> +cmd_s += " -e %s" % email
> +if server is not None:
> +cmd_s += " -s %s" % server
> +
> +if autosend is not None:
> +if autosend == "yes":
> +response_s += "The errors for this build are set to 
> automatically be sent.\n"
> +cmd_s += " -y"
> +sendit = True
> +elif autosend == "ask":
> +response_s += "The errors for this build are set to 
> automatically be sent.\n"
> +sendit = True
> +elif autosend is None:
> +response_s += "You can send the errors to a reports 
> server by running:\n  %s\n" % cmd_s
> +elif e.data.getVarFlags('REPORTERROR') is None:
> +response_s += "You can send the errors to a reports 
> server by running:\n  %s [-s server]\n" % cmd_s
> +response_s += "The contents of these logs will be 
> posted in public if you use the above command with the default server.\n \
> + Please ensure you remove any identifying or 
> proprietary information when prompted before sending.\n"
> +
> +bb.note(response_s)
> +
> +if sendit == True:
> +import shlex, subprocess
> +args = shlex.split(cmd_s)
> +subprocess.call(args)
>  }
>  
>  addhandler errorreport_handler
> -- 
> 2.9.3
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] gstreamer1.0-omx: inherit upstream-version-is-even

[Maxin B. John]

Since gstreamer1.0-omx follows the GStreamer versioning style, inherit
upstream-version-is-even for checking the upstream version of the package.

Signed-off-by: Maxin B. John 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
index aa3e820..41b04d6 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
@@ -7,7 +7,7 @@ LICENSE_FLAGS = "commercial"
 
 DEPENDS = "gstreamer1.0 gstreamer1.0-plugins-base gstreamer1.0-plugins-bad"
 
-inherit autotools pkgconfig gettext
+inherit autotools pkgconfig gettext upstream-version-is-even
 
 acpaths = "-I ${S}/common/m4 -I ${S}/m4"
 
-- 
2.4.0

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

[OE-core] [PATCH] bitbake.conf: Add BBSERVER to HASHBASE_WHITELIST

[Ed Bartosh]

Using BBSERVER variable in checksum calculations causes
unnecessary rebuilds when running memres bitbake.

Whitelisted BBSERVER variable to prevent this unwanted
behaviour.

[YOCTO #10201]

Signed-off-by: Ed Bartosh 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index c32a3f8..b6a1a68 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -802,7 +802,7 @@ BB_CONSOLELOG ?= 
"${LOG_DIR}/cooker/${MACHINE}/${DATETIME}.log"
 
 # Setup our default hash policy
 BB_SIGNATURE_HANDLER ?= "OEBasicHash"
-BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
+BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH BBSERVER 
DL_DIR \
 SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
 USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
 PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
-- 
2.1.4

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

Re: [OE-core] [PATCH 1/4] gstreamer1.0-omx: provide RECIPE_NO_UPDATE_REASON

[Maxin B. John]

Hi Ross,

>On Thu, Sep 08, 2016 at 05:04:26PM +0100, Burton, Ross wrote:
>>On 8 September 2016 at 16:46, Maxin B. John  wrote:
>>
>>   +RECIPE_NO_UPDATE_REASON = "Version 1.9.2 requires gstreamer-1.0 >= 1.9.2"
>
>Are they adopting the GStreamer versioning style, so we should inherit 
>upstream-version-is-even instead?
>

The number of gstreamer-1.0-omx releases seems to be pretty small compared
to other components of the gstreamer project. Seems like they are moving to
the GStreamer versioning style recently. 

I will update this as per your suggestion.

>   Ross

Thanks,
Maxin
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] weston startup problem

[Jussi Kukkonen]

On 24 August 2016 at 20:08, Tom Hochstein  wrote:

> Hi All,


Hi, sorry for missing this in the originally,


> The weston systemd startup implementation is not working correctly and I
> need some help fixing it.
>
> With systemd and pam on the image, the expected behavior is that
> XDG_RUNTIME_DIR would already be set when weston is launched from
> weston.service. Turns out XDG_RUNTIME_DIR is not set, and weston.service
> sets it itself. This is already a problem, and the problem would be worse
> except that weston happens to use a different folder. If weston.service is
> modified to use the same folder name, the folder ends up getting replaced
> later by pam.



I can see our XDG_RUNTIME_DIR handling indeed should be cleaned up but just
so I understand the whole issue: can you explain the problem you have in
detail? It seems one issue is that the variable isn't set outside of
 Xsession (it really should) but why is it a problem if weston.service
decides a runtime directory for itself? How does pam interfere with that?


Thanks,
 Jussi


>
>
>From looking at the weston-launch code and its pam handling, I thought to
> try the weston-launch option '--user=root' to force the creation of the pam
> session. This does seem to help, and I was able to get it mostly working by
> modifying the openvt args in weston-start, removing -e and adding -w:
>
> openvt -v -s -w -- weston-launch --user=root -- --modules=xwayland.so
> --log=/var/log/weston.log
>
> The problem I have now is that keyboard input goes to both weston and the
> desktop. I tried with and without the -s option, and there is no difference.
>
> I'm stuck at this point and would appreciate some help.
>
> Tom
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core