When a new USB network interface is plugged in systemd
fails to rename the new interface (ethX) to a predictable
name [1] because connman locks it first.
Add a fix to connman that makes it to re-evaluate
a known but blacklisted ethernet interface for enabling
after it has got renamed.
Still a use
On 24 April 2017 at 23:00, Nathan Lynch wrote:
> Does adding this patch to lttng-modules work around it?
>
Yes, it fixes the build here. I'll throw it at the autobuilder now, can
you send a patch with a commit message that isn't "someone told me to try
this"? :)
Ross
--
__
On Mon, 2017-04-24 at 21:06 -0400, Bruce Ashfield wrote:
> On Mon, Apr 24, 2017 at 5:27 PM, Richard Purdie
> wrote:
> > On Mon, 2017-04-24 at 15:56 -0400, Bruce Ashfield wrote:
> > >
> > >
> > > On Mon, Apr 24, 2017 at 9:54 AM, Bruce Ashfield > mail
> > > .com> wrote:
> > > >
> > > >
> > > > On M
On Tue, Apr 25, 2017 at 9:09 AM, Richard Purdie wrote:
> On Mon, 2017-04-24 at 21:06 -0400, Bruce Ashfield wrote:
> > On Mon, Apr 24, 2017 at 5:27 PM, Richard Purdie
> > wrote:
> > > On Mon, 2017-04-24 at 15:56 -0400, Bruce Ashfield wrote:
> > > >
> > > >
> > > > On Mon, Apr 24, 2017 at 9:54 AM,
On 24 April 2017 at 03:12, Huang Qiyu wrote:
> Upgrade gperf from 3.0.4 to 3.1.
>
This breaks the libcap build:
| In file included from :0:0:
| ./_caps_output.gperf:71:80: error: unknown type name 'size_t'
| gperf_case_strncmp (register const char *s1, register const char *s2,
register size_t
Cleanup references to libasound-module since this code has been
completly removed from Bluez.
Signed-off-by: Marc Ferland
---
meta/conf/distro/include/default-providers.inc | 1 -
meta/recipes-connectivity/bluez5/bluez5.inc | 5 +
meta/recipes-core/packagegroups/packagegroup-b
New feautures/fixes in this version:
* fixes to BLE
* a new midi plugin
* support for single-mode controllers w/o public address
* most of the experimental tools have been promoted and are now part of
the official tools
* 'experimental' has been renamed to 'testing' (hence the addition of
the
Signed-off-by: Marc Ferland
---
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 4244fc8..687656e 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.in
Signed-off-by: Marc Ferland
---
meta/recipes-connectivity/bluez5/bluez5.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 687656e..71a5016 100644
--- a/meta/recipes-connectiv
V4:
* dropped the "rename readline 'config' option to 'client'" changes (reported
by Ross Burton)
* make references to libasound-module-bluez depend on bluez4 only (reported by
Ross burton)
V3:
* shell functions use tabs not spaces (reported by Khem Raj)
V2:
* upgrades to version 5.44
* renames
Signed-off-by: Marc Ferland
---
meta/recipes-connectivity/bluez5/bluez5.inc | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 71a5016..c8a240f 100644
--- a/meta/recipes-conne
The audio.conf file has been removed, stop installing it.
Signed-off-by: Marc Ferland
---
meta/recipes-connectivity/bluez5/bluez5.inc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index c8a240f..47
Signed-off-by: Marc Ferland
---
meta/recipes-connectivity/bluez5/bluez5.inc | 30 ++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 47d8f22..01ade7d 100644
On Tue, Apr 25, 2017 at 10:48:37AM -0400, Marc Ferland wrote:
> Signed-off-by: Marc Ferland
> ---
> meta/recipes-connectivity/bluez5/bluez5.inc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> b/meta/recipes-connectivity/
On Thu, 2017-04-20 at 01:01 +, Patchwork wrote:
> == Series Details ==
>
> Series: busybox: fix typo in CVE-2016-2147_2.patch Upstream-Status tag
> Revision: 1
> URL : https://patchwork.openembedded.org/series/6429/
> State : failure
>
> == Summary ==
>
>
> Thank you for submitting this p
There's no need to sed the Makefile (especially the wrong Makefile) when there's
a variable we can pass.
Signed-off-by: Ross Burton
---
meta/recipes-support/libcap/libcap_2.25.bb | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-support/libcap/libcap_2.25.bb
b/
== Series Details ==
Series: libcap: clean up gperf enabling logic
Revision: 1
URL : https://patchwork.openembedded.org/series/6502/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed o
Suppressing default version of etc.conf for systemd-tmpfiles-setup prevents at
least the name resolver from working as expected when using systemd-resolved.
The missing /etc/resolv.conf symlink breaks application relying on this for
name resolution (tested with ping from busybox).
This patch bring
On Tue, Apr 25, 2017 at 11:13 AM, Martin Jansa
wrote:
>
> On Tue, Apr 25, 2017 at 10:48:37AM -0400, Marc Ferland wrote:
> > Signed-off-by: Marc Ferland
> > ---
> > meta/recipes-connectivity/bluez5/bluez5.inc | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/
On Thu, 2017-04-20 at 07:01 +, Patchwork wrote:
> == Series Details ==
>
> Series: bash: CVE-2016-0634
> Revision: 1
> URL : https://patchwork.openembedded.org/series/6434/
> State : failure
>
> == Summary ==
>
>
> Thank you for submitting this patch series to OpenEmbedded Core. This is
>
This patch set contains several patches aimed to achieve reproducible binaries.
Building reproducible binaries may remove certain intentional
randomness intended for increased security. Hence, it is reasonable
to expect there will be cases where this is not desirable.
The user can select his/her pr
Conditionally set some environment variables in order to achieve
improved binary reproducibility. Providing BUILD_REPRODUCIBLE_BINARIES is
set to "1", we set the following environment variables:
export PYTHONHASHSEED=0
export PERL_HASH_SEED=0
export TZ="UTC"
We also export and set SOURCE_DATE_EPO
Conditionally support binary reproducibility of rootfs images.
If BUILD_REPRODUCIBLE_BINARIES = 1 then:
1. set /etc/timestamp to a reproducible value
2. set /etc/version to a reproducible value
The value for /etc/version is modified in a designated catch-all
post-rootfs function "rootfs_reproduci
Building reproducible binaries may remove certain intentional
randomness intended for increased security. Hence, it is reasonable
to expect there will be cases where this is not desirable.
The user can select his/her preferences via the variable
BUILD_REPRODUCIBLE_BINARIES. The variable defaults to
Conditionally support binary reproducibility in built images.
If BUILD_REPRODUCIBLE_BINARIES = 1 then:
1. Do not randomize library addresses
2. Set/export PRELINK_TIMESTAMP to a reproducible value.
The value is derived from the top git commit.
Signed-off-by: Juro Bystricky
---
meta/classes/i
Is using the last commit really that useful?
I would like to be able to compare 2 subsequent builds (ideally performed
on 2 different hosts with some small modification in metadata layers) and
the binaries not affected by those small metadata modifications should be
the same - which is not the cas
The idea is that both builds have reproducible timestamps. So there may be
different ways to determine the best way to get the stamp. My rationale was
that if the builds are from two different commits, the difference should be
reflected in the timestamp. But I agree that two different commits
m
On Tue, Apr 25, 2017 at 9:06 AM, Leonardo Sandoval
wrote:
> On Thu, 2017-04-20 at 01:01 +, Patchwork wrote:
>> == Series Details ==
>>
>> Series: busybox: fix typo in CVE-2016-2147_2.patch Upstream-Status tag
>> Revision: 1
>> URL : https://patchwork.openembedded.org/series/6429/
>> State :
On Mon, Apr 24, 2017 at 6:38 PM, Khem Raj wrote:
> On Mon, Apr 24, 2017 at 3:34 PM, Burton, Ross wrote:
>> Clearly there's some build difference between our configurations. Are you
>> building grub-git instead of grub_2.00? Should we delete grub_2.00 if its
>> that old? I'd say that it looks go
Avoid using LTTng's BUILD_RUNTIME_BUG_ON macro, as it appears to run
into a similar problem as Linux experienced with __builtin_constant_p
and dead code elimination.
Signed-off-by: Nathan Lynch
---
.../BUILD_RUNTIME_BUG_ON-vs-gcc7.patch | 43 ++
meta/recipes-kerne
"Burton, Ross" writes:
> On 24 April 2017 at 23:00, Nathan Lynch wrote:
>
>> Does adding this patch to lttng-modules work around it?
>>
>
> Yes, it fixes the build here. I'll throw it at the autobuilder now, can
> you send a patch with a commit message that isn't "someone told me to try
> this"
On Tue, Apr 25, 2017 at 2:14 PM, Juro Bystricky
wrote:
> The variable defaults to "0" (do not
> build reproducible binaries) in order to minimize any potential
> regressions. (Once the reproducible binaries code is mature enough,
> it can be set to "1".)
My guess is that people would prefer secur
On 4/25/17 3:33 PM, Nathan Lynch wrote:
> Avoid using LTTng's BUILD_RUNTIME_BUG_ON macro, as it appears to run
> into a similar problem as Linux experienced with __builtin_constant_p
> and dead code elimination.
>
Thanks for contributing. this patch looks ok to me.
> Signed-off-by: Nathan Lync
33 matches
Mail list logo