On 30 September 2015 at 18:33, Jussi Kukkonen
wrote:
> bluez5: Use upstream D-Bus policy
> dbus: Use the xuser policy file
> xuser-account: Take over xuser specific D-Bus policy
>
Please don't take the last two patches yet: I believe dbus itself does not
actually have to be modified and th
Here is the test result:
MACHINE = "qemux86-64"
- When multilib enabled:
$ bitbake core-image-sato -cpopulate_sdk
time: 6m5s -> 2m34s (Reduce 57% )
$ bitbake core-image-minimal -cpopulate_sdk
time: 2m1s -> 1m26s (Reduce 28% )
$ bitbake core-image-sato-sdk
time: 10m15s
It only matched name ony in the past, for example:
smart install busybox (matched)
but:
smart install busybox@core2_64 (didn't match)
The installation is very slow when no match since it would seach all the
packages in the repo, and what we use mostly in oe-core is the second
case, so the installa
On 10/01/2015 03:40 PM, Robert Yang wrote:
It only matched name ony in the past, for example:
smart install busybox (matched)
but:
smart install busybox@core2_64 (didn't match)
The installation is very slow when no match since it would seach all the
packages in the repo, and what we use mostly
Changes since v1:
- move the xuser policy file to {sysconfdir}/dbus-1/system.d/
as it works just fine from there.
original cover letter follows:
The major patch in the series is the bluez one: Bluez
D-Bus policy was incorrectly written so it actually allowed
access to system services _other
Move connmans xuser-related D-Bus policy to a separate file that
xuser-account installs: This way connman does not need to depend on
xuser-account. Add policies for bluez and ofono in the same file.
Signed-off-by: Jussi Kukkonen
---
meta/recipes-connectivity/connman/connman.inc | 1 -
.../
The Bluez D-Bus policy is much too open and affects not just bluez but
all system services: Use upstream policy configuration instead.
This change has a chance of affecting other D-Bus services: the bug
that is fixed here may have hidden problems in other policies.
[YOCTO #8414]
Signed-off-by: J
A machine-independent recipe must not have machine-specific changes,
as in TUNE_CCARGS_append_intel-core2-32. In the best case, that only
causes unnecessary rebuilds when switching machines with the same CPU
which otherwise could share sstate. In the worst case, it confuses PR
server and build hist
The name of the directory for local source files under srctree is
'oe-local-files', not 'local-files'. Fixes a bug that slipped through
in b7ab82485e4514e07ab8a76e554da27ddc92e6c0.
Signed-off-by: Markus Lehtonen
---
scripts/lib/devtool/standard.py | 2 +-
1 file changed, 1 insertion(+), 1 deleti
BROKEN support was removed from bitbake back in 2013. These lines just
increase parsing time, remove them.
Signed-off-by: Richard Purdie
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 738bf2b..bbfdf78 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
connman daemon forks during normal usage,
so this test is no longer valid and generates
sometimes false positives.
This reverts commit 7d01c595c96eb3d67b90caf71050c4e9345257de.
---
meta/lib/oeqa/runtime/connman.py | 23 ---
1 file changed, 23 deletions(-)
diff --git a/meta/li
* This is a cosmetic patch.
* Using ON/OFF instead of True/False is exactly the same for cmake
(is case insensitive).
* But WebKitGTK+ preffers (and uses) the first option. So when you
check which values were enabled for the build (at log.do_configure)
you will see that every op
* This adds some useful packageconfig options to the webkitgtk recipe.
* It switches also the CMake switches to ON/OFF (cosmetic)
Carlos Alberto Lopez Perez (2):
webkitgtk: Use ON/OFF for cmake switches.
webkitgtk: Add some PACKAGECONFIG options.
meta/recipes-sato/webkit/webkitgtk_2.8.5.
* Also default to enable X11/Wayland support or WebGL according
to enabled DISTRO_FEATURES.
Signed-off-by: Carlos Alberto Lopez Perez
---
meta/recipes-sato/webkit/webkitgtk_2.8.5.bb | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-sato/webkit/
Just a heads up for people that we've branched for release and that
jethro branches are now available. Bitbake branched as 1.28, I decided
to save bitbake 2.0 for another occasion.
These branches are going to track master for a while yet as we stabilise
the release.
Cheers,
Richard
--
On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
wrote:
> Just a heads up for people that we've branched for release and that
> jethro branches are now available. Bitbake branched as 1.28, I decided
> to save bitbake 2.0 for another occasion.
what would be the occasion ?
this time lets branch consi
On Thu, Oct 1, 2015 at 11:28 AM, Khem Raj wrote:
> On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
> wrote:
>> Just a heads up for people that we've branched for release and that
>> jethro branches are now available. Bitbake branched as 1.28, I decided
>> to save bitbake 2.0 for another occasion.
On 01/10/15 16:28, Khem Raj wrote:
> I would also suggest to not use codenames in branches
> but rather the numbered release. If we want to use codenames for
> branches then lets drop the numbered release names.
>
I suggest using both (codename+release_number).
Ex: jethro-2.0 or 2.0-jethro
(pro
On Thu, Oct 1, 2015 at 8:03 AM, Carlos Alberto Lopez Perez
wrote:
> On 01/10/15 16:28, Khem Raj wrote:
>> I would also suggest to not use codenames in branches
>> but rather the numbered release. If we want to use codenames for
>> branches then lets drop the numbered release names.
>>
>
> I sugges
Updates for distro_alias.inc. This should be pulled for jethro and
master branches.
Signed-off-by: Beth Flanagan
---
meta/conf/distro/include/distro_alias.inc | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/conf/distro/include/distro_alias.inc
b/meta/conf/distro/include/dis
On Thu, 2015-10-01 at 07:28 -0700, Khem Raj wrote:
> On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
> wrote:
> > Just a heads up for people that we've branched for release and that
> > jethro branches are now available. Bitbake branched as 1.28, I decided
> > to save bitbake 2.0 for another occasi
On Thu, 2015-10-01 at 11:41 -0300, Otavio Salvador wrote:
> I agree.
>
> The mix between codenames and version numbers cause a lot of confusion
> for outsiders. We, involved with the project development can handle it
> (even though sometimes I ask myself if one codename is older or newer
> than an
From: Armin Kuster
Signed-off-by: Armin Kuster
---
meta/conf/machine/include/tune-thunderX.inc | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 meta/conf/machine/include/tune-thunderX.inc
diff --git a/meta/conf/machine/include/tune-thunderX.inc
b/meta/conf/machin
This dependency isn't required now that systemd doesn't include gudev, so remove
it.
[ YOCTO #8398 ]
Signed-off-by: Ross Burton
---
meta/recipes-core/systemd/systemd_225.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/systemd/systemd_225.bb
b/meta/recip
> On Oct 1, 2015, at 8:37 AM, Richard Purdie
> wrote:
>
> On Thu, 2015-10-01 at 07:28 -0700, Khem Raj wrote:
>> On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
>> wrote:
>>> Just a heads up for people that we've branched for release and that
>>> jethro branches are now available. Bitbake branch
It was noticed today that the IMAGE_GEN_DEBUGFS implementation was not
complete. The version that was merged back in May only contained the
filesystem generation pieces, but not the pieces for creating the image
from that filesystem.
The code has been tested and is working. The only thing that
The companion debug filesystem, enabled with IMAGE_GEN_DEBUGFS, was
creating the companion filesystem but was missing the code to actually
package it into a usable filesystem.
The code (and associated documentation) will allow the debugfs to generate a
companion tarball or other image.
Signed-off
From: Mariano Lopez
These two patches add Unicode support for the report error bbclass
and the qemu bootlog.
[YOCTO #8225]
The following changes since commit eac61f37e36099f74485dab398b57f3812826d17:
build-appliance-image: Update to jethro head revision (2015-10-01 17:55:11
+0100)
are ava
From: Mariano Lopez
Currently error-report doesn't manage Unicode because
the files are opened with the default codec.
This patch changes the codec of the files to UTF-8,
this way the reports will include Unicode characters.
This is useful for the qemu output when doing the
testimage task.
[YOC
From: Mariano Lopez
The current state of qemurunner will drop the Unicode
characters received from qemu, this is because error
report web had problems with Unicode characters; now
that the server support Unicode, it is possible to
log all the output from qemu. So far the only Unicode
character se
On Wed, Sep 30, 2015 at 5:48 PM, Khem Raj wrote:
>
>> On Sep 30, 2015, at 3:03 PM, Andre McCurdy wrote:
>>
>> I'd like the rootfs manifest to be sorted when using .ipk packaging.
>> Would a patch to sort the result of OpkgPkgsList().list be acceptable?
>> Or would the sorting be better done elsew
On Thu, Oct 1, 2015 at 3:55 PM, Andre McCurdy wrote:
> On Wed, Sep 30, 2015 at 5:48 PM, Khem Raj wrote:
>>
>>> On Sep 30, 2015, at 3:03 PM, Andre McCurdy wrote:
>>>
>>> I'd like the rootfs manifest to be sorted when using .ipk packaging.
>>> Would a patch to sort the result of OpkgPkgsList().lis
On Thu, Oct 1, 2015 at 11:57 AM, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:
> On Thu, Oct 1, 2015 at 3:55 PM, Andre McCurdy wrote:
> > On Wed, Sep 30, 2015 at 5:48 PM, Khem Raj wrote:
> >>
> >>> On Sep 30, 2015, at 3:03 PM, Andre McCurdy
> wrote:
> >>>
> >>> I'd like the rootfs
This variable is used by librsvg_2.40.10.bb, but I can't find anybody who
processes it, at least not a bbclass.
Without adding an explicit do_populate_sysroot_setscene[depends] to the recipe,
gdk-pixbuf-native
will install from sstate after librsvg-native and clobber the svg loader. At
least i
On Thu, 2015-10-01 at 10:24 -0700, Khem Raj wrote:
> > If we want to discuss this all again, so be it, but on the eve of
> > release really isn't the time to start it all again.
>
> so when is the right time ? Do we have long enough pre-notice about
> when we the branching is going to happen?
We
The gma500_gfx driver will match certain devices on which it causes incorrect
functionality,
we want to avoid inserting this module, basicallly blacklist it for specific
hardware,
but still allow it to work on other hardware by default; usually when we have
an already working system,
using udev
On Thu, Oct 1, 2015 at 1:25 PM, Richard Purdie
wrote:
>> so when is the right time ? Do we have long enough pre-notice about
>> when we the branching is going to happen?
>
> We release approximately in April and October with a six month cadence.
>
> After the complaints about communication, there
On Thu, Oct 1, 2015 at 5:25 PM, Richard Purdie
wrote:
> On Thu, 2015-10-01 at 10:24 -0700, Khem Raj wrote:
>> > If we want to discuss this all again, so be it, but on the eve of
>> > release really isn't the time to start it all again.
>>
>> so when is the right time ? Do we have long enough pre-n
On Thu, 2015-10-01 at 17:30 -0300, Otavio Salvador wrote:
> I think what Khem means is that any time is time to discuss the
> release process as this is a community driven project and we must to
> be open for feedback and revisit our previous concepts.
There is a time and a place for such discussi
We enabled qemu-native debug builds for debug [YOCTO #8143] now
is fixed and we don't need it for release.
This reverts commit 1fa9a0cc6e4c80a5a2bf40331390ae9da71686c2.
Signed-off-by: Aníbal Limón
---
meta/recipes-devtools/qemu/qemu.inc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta
This update brings the kernel for genericx86* up to date with
the linux-yocto kernel and 4.1.8
Signed-off-by: Saul Wold
---
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-yocto-bsp/recipes-kernel/linux/lin
On Thu, 2015-10-01 at 19:24 +, Slater, Joseph wrote:
> This variable is used by librsvg_2.40.10.bb, but I can't find anybody
> who processes it, at least not a bbclass.
>
>
>
> Without adding an explicit do_populate_sysroot_setscene[depends] to
> the recipe, gdk-pixbuf-native
>
> will inst
On Thu, 2015-10-01 at 13:26 -0500, Mark Hatle wrote:
> It was noticed today that the IMAGE_GEN_DEBUGFS implementation was not
> complete. The version that was merged back in May only contained the
> filesystem generation pieces, but not the pieces for creating the image
> from that filesystem.
>
Without explicit sorting, the output generated by OpkgPkgsList().list
follows the order of packages in /var/lib/opkg/status, which appears
to be "random". Add sorting to make OpkgPkgsList().list behaviour
consistent with that of RpmPkgsList().list.
Signed-off-by: Andre McCurdy
---
meta/lib/oe/pa
On Thu, Oct 1, 2015 at 1:28 PM, Khem Raj wrote:
> On Thu, Oct 1, 2015 at 1:25 PM, Richard Purdie
> wrote:
>>> so when is the right time ? Do we have long enough pre-notice about
>>> when we the branching is going to happen?
>>
>> We release approximately in April and October with a six month cade
On Thu, Oct 1, 2015 at 2:16 PM, Richard Purdie
wrote:
> On Thu, 2015-10-01 at 17:30 -0300, Otavio Salvador wrote:
>> I think what Khem means is that any time is time to discuss the
>> release process as this is a community driven project and we must to
>> be open for feedback and revisit our previ
Armin
can we get rid of uppercase X
> On Oct 1, 2015, at 9:38 AM, Armin Kuster wrote:
>
> From: Armin Kuster
>
> Signed-off-by: Armin Kuster
> ---
> meta/conf/machine/include/tune-thunderX.inc | 19 +++
> 1 file changed, 19 insertions(+)
> create mode 100644 meta/conf/machine/
47 matches
Mail list logo
