Paul, Ross:
Please review (and if needed create new branch) in your morning for an RP
review. This will be RC1 of M3 and we need it to be as solid as possible
as M2 was a bit of a bust!
Please review the build status on the Autobuild, which is currently looking OK,
but not near enough finished.
On 07/29/2013 11:26 PM, Phil Blundell wrote:
On Mon, 2013-07-29 at 10:33 +0800, qi.c...@windriver.com wrote:
From: Chen Qi
This diretory needs to be writable, the following error will appear
at system start-up.
/etc/rc5.d/S20irattach: /etc/sysconfig/irda: Read-only file system
The whole
On 07/29/2013 11:56 PM, Burton, Ross wrote:
On 29 July 2013 03:33, wrote:
+echo "/www /var/volatile/www" > ${D}${sysconfdir}/default/readonly/lighttpd
/www is the default lighttpd document root, where the web sites are
stored, so putting them in a tmpfs would be very wrong indeed.
Why do
On 07/29/2013 11:59 PM, Burton, Ross wrote:
On 29 July 2013 03:33, wrote:
From: Chen Qi
If the rootfs is read-only and the ssh keys are not available at system
start-up, the init script will generate ssh keys into /etc/ssh, thus
causing a 'read-only file system' error.
Make this directory w
From: Chen Qi
The following changes since commit bd1c441a210cae03fb6006c996227211cc29056b:
bitbake: bitbake: runqueue: add warning if invalidating invalid task
(2013-07-29 15:25:09 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib ChenQi/opkg-remove-REDIR
From: Chen Qi
The REDIRECT_CMD variable is now obsolete, remove it.
Signed-off-by: Chen Qi
---
meta/recipes-devtools/opkg/opkg.inc |2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-devtools/opkg/opkg.inc
b/meta/recipes-devtools/opkg/opkg.inc
index f2c826b..fd11ccc 100644
--
On 7/26/13 5:48 AM, Paul Eggleton wrote:
Some users have been found to have an unnamed third-party piece of
software installed which sets chmod, chown and mknod as suid root as
part of its installation process. This interferes with the operation of
pseudo and can result in files really being owne
said the following on 2013-7-29 23:36:, Phil Blundell wrote:
> On Mon, 2013-07-29 at 12:02 +0800, Bian Naimeng wrote:
>> qemux86.conf: provide a common qemux86 machine configuration,
>> so developer/distributor can customize their specific one.
>>
>> Although, we can modify the meta/conf/machine/
From: Chen Qi
When building a qemu image inside the environment created by the
buildtools-tarball, the qemu image cannot be started, as the runqemu
script uses the tunctl binary which cannot be found inside the sysroot
directory of the buildtools-tarball.
The buildtools-tarball is inherently a t
From: Chen Qi
The following changes since commit 67864ca79da08df752487a3a4e1a975546da123d:
systemd: Remove systemd_unitdir if systemd is not in distro features
(2013-07-24 11:35:39 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib ChenQi/buildtools-env
On 07/30/2013 12:32 AM, Paul Eggleton wrote:
On Monday 29 July 2013 08:51:01 Saul Wold wrote:
Clearly having a bad morning!
This one drops the Recipe Re-names from Ema, should not have been
there.
Sau!
The following changes since commit 09deeef20ee5a0c12ad4fd89cace6e0fb832d5b1:
external-s
Thank you, Otavio!
On Mon, Jul 29, 2013 at 6:35 PM, Otavio Salvador
wrote:
> Hello Eric and Rogerio,
>
> On Mon, Jul 29, 2013 at 7:26 PM, Otavio Salvador
> wrote:
>> This allow the addition and removal of distro features easily. To add
>> a feature, use:
>>
>> EXTRA_DISTRO_FEATURES += "wayland"
Hello Eric and Rogerio,
On Mon, Jul 29, 2013 at 7:26 PM, Otavio Salvador
wrote:
> This allow the addition and removal of distro features easily. To add
> a feature, use:
>
> EXTRA_DISTRO_FEATURES += "wayland"
>
> and to remove, use '~' prefix, as:
>
> EXTRA_DISTRO_FEATURES += "~x11"
>
> This co
This allow the addition and removal of distro features easily. To add
a feature, use:
EXTRA_DISTRO_FEATURES += "wayland"
and to remove, use '~' prefix, as:
EXTRA_DISTRO_FEATURES += "~x11"
This code has been mostly copied from Mentor Graphics public layer but
changed the variable name for a mo
Changelog since 2013-07-21 until 2013-07-28. Projects included in this report:
bitbake: git://git.openembedded.org/bitbake
openembedded-core: git://git.openembedded.org/openembedded-core
meta-openembedded: git://git.openembedded.org/meta-openembedded
meta-angstrom: git://github.com/Angstrom-distr
In older versions of util-linux, swapon and swapoff were the
same binary, and it did runtime detection. But since v2.22
which is util-linux commit 6cf8d46ceefe9a7, they are separate
binaries.
This patch is necessary to make the util-linux version of
swapoff work at all - currently in OE swapoff =
On 29 July 2013 16:51, Saul Wold wrote:
> Clearly having a bad morning!
Join me in the Need More Coffee Club...
> The following changes since commit 09deeef20ee5a0c12ad4fd89cace6e0fb832d5b1:
>
> external-sourcery: add missing providers (2013-07-27 23:28:29 -0700)
>
> are available in the git r
On Monday 29 July 2013 08:51:01 Saul Wold wrote:
> Clearly having a bad morning!
>
> This one drops the Recipe Re-names from Ema, should not have been
> there.
>
> Sau!
>
> The following changes since commit 09deeef20ee5a0c12ad4fd89cace6e0fb832d5b1:
>
> external-sourcery: add missing provider
On 07/29/2013 09:17 AM, Richard Purdie wrote:
On Mon, 2013-07-29 at 16:49 +0100, Paul Eggleton wrote:
On Monday 29 July 2013 08:07:51 Saul Wold wrote:
Branch is updated, sorry not sure what happened with the
obex and texinfo, I thought I had removed them since they did not
show up in the summar
On Mon, 2013-07-29 at 16:49 +0100, Paul Eggleton wrote:
> On Monday 29 July 2013 08:07:51 Saul Wold wrote:
> > Branch is updated, sorry not sure what happened with the
> > obex and texinfo, I thought I had removed them since they did not
> > show up in the summary below (in the first email).
> >
>
On 29 July 2013 03:33, wrote:
> From: Chen Qi
>
> If the rootfs is read-only and the ssh keys are not available at system
> start-up, the init script will generate ssh keys into /etc/ssh, thus
> causing a 'read-only file system' error.
>
> Make this directory writable in case of a read-only root
On 29 July 2013 03:33, wrote:
> +echo "/www /var/volatile/www" >
> ${D}${sysconfdir}/default/readonly/lighttpd
/www is the default lighttpd document root, where the web sites are
stored, so putting them in a tmpfs would be very wrong indeed.
Why does lightttp need write access? If it's pu
Clearly having a bad morning!
This one drops the Recipe Re-names from Ema, should not have been
there.
Sau!
The following changes since commit 09deeef20ee5a0c12ad4fd89cace6e0fb832d5b1:
external-sourcery: add missing providers (2013-07-27 23:28:29 -0700)
are available in the git repository at
On Monday 29 July 2013 08:07:51 Saul Wold wrote:
> Branch is updated, sorry not sure what happened with the
> obex and texinfo, I thought I had removed them since they did not
> show up in the summary below (in the first email).
>
> Already basicly ACK'ed by Ross and Paul
>
> Thanks
> Sau!
>
> T
Signed-off-by: Ross Burton
---
meta/recipes-devtools/qemu/qemu.inc |4
1 file changed, 4 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 77045df..c43f1ef 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtoo
On 29 July 2013 15:34:29 Laszlo Papp wrote:
No, it should be disabled by default based on the fact most people do not
need this "rfkill" what even upstream has been disabling, and it would be
only enabled for those two utils out of the several thousand out there,
anyhow.
It was disabled just b
On Mon, 2013-07-29 at 12:02 +0800, Bian Naimeng wrote:
> qemux86.conf: provide a common qemux86 machine configuration,
> so developer/distributor can customize their specific one.
>
> Although, we can modify the meta/conf/machine/qemux86.conf to customize our
> configuration, but it's uncomforta
On 29 July 2013 16:07, Saul Wold wrote:
> Already basicly ACK'ed by Ross and Paul
Just to double-confirm:
Acked-By: Ross Burton
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/
On Mon, 2013-07-29 at 10:33 +0800, qi.c...@windriver.com wrote:
> From: Chen Qi
>
> This diretory needs to be writable, the following error will appear
> at system start-up.
>
>/etc/rc5.d/S20irattach: /etc/sysconfig/irda: Read-only file system
The whole chunk of code in that script that's t
Branch is updated, sorry not sure what happened with the
obex and texinfo, I thought I had removed them since they did not
show up in the summary below (in the first email).
Already basicly ACK'ed by Ross and Paul
Thanks
Sau!
The following changes since commit 09deeef20ee5a0c12ad4fd89cace6e0fb8
On 29 July 2013 15:36, Phil Blundell wrote:
>> Not sure we need the listdir(), why should the function only delete
>> the directory if it has contents? If it doesn't have contents you'll
>> be packaging an empty directory.
>
> The directory he's deleting is different to the one that he's listing.
This package isn't specific to qemux86 but all x86 machines that are using the
userspace VESA framebuffer kernel driver.
Signed-off-by: Ross Burton
---
meta/recipes-bsp/v86d/v86d_0.1.10.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/v86d/v86d_0.1.10.bb
On Mon, 2013-07-29 at 15:34 +0100, Burton, Ross wrote:
> On 29 July 2013 09:09, Shakeel, Muhammad wrote:
> > +# If systemd_unitdir contains anything, delete sysv_initddir
> > +if (os.path.exists(systemd_unitdir) and
> > os.listdir(systemd_unitdir)):
> > +shutil.rmtree(
On 29 July 2013 09:09, Shakeel, Muhammad wrote:
> +# If systemd_unitdir contains anything, delete sysv_initddir
> +if (os.path.exists(systemd_unitdir) and os.listdir(systemd_unitdir)):
> +shutil.rmtree(sysv_initddir)
Not sure we need the listdir(), why should the funct
Signed-off-by: Cristian Iorga
---
.../iproute2/{iproute2_3.9.0.bb => iproute2_3.10.0.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-connectivity/iproute2/{iproute2_3.9.0.bb =>
iproute2_3.10.0.bb} (64%)
diff --git a/meta/recipes-connectivity/ipr
Signed-off-by: Jonathan Liu
---
meta/recipes-devtools/syslinux/{syslinux_4.06.bb => syslinux_4.07.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/syslinux/{syslinux_4.06.bb => syslinux_4.07.bb}
(93%)
diff --git a/meta/recipes-devtools/syslinux/syslinu
No, it should be disabled by default based on the fact most people do not
need this "rfkill" what even upstream has been disabling, and it would be
only enabled for those two utils out of the several thousand out there,
anyhow.
I am just repeating myself as the same is questioned again, again, and
On 29 July 2013 14:20:05 Laszlo Papp wrote:
Oh, it is actually also in danny. I was looking into the "files" directory,
but it is in the other.
It is definitely not in denzil though.
Perhaps disable it only in the layer that pulls in these pre-2.6.31 kernel
headers?
Thanks,
On Mon, Jul
On 07/10/2013 07:45 PM, Martin Jansa wrote:
On Wed, Jul 10, 2013 at 06:39:20PM +0100, Paul Eggleton wrote:
Hi Mike,
On Wednesday 10 July 2013 15:05:23 Mike Looijmans wrote:
I added a buildserver that also exports its "sstate-cache" directory, so
that other build machines can grab their stuff
Oh, it is actually also in danny. I was looking into the "files" directory,
but it is in the other.
It is definitely not in denzil though.
On Mon, Jul 29, 2013 at 1:18 PM, Laszlo Papp wrote:
> Only _one_, not two.
>
>
> On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell wrote:
>
>> On Mon, 2013-
Only _one_, not two.
On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell wrote:
> On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
> > I disagree. This change should not have gone in the first place
> > causing the regression for the users. Please be consistent with the
> > history.
>
> If thi
On Mon, 2013-07-29 at 10:08 +0100, Burton, Ross wrote:
> On 28 July 2013 07:30, Saul Wold wrote:
> > This is part 2 of the C-Pull, part one was reviewed and ACK'ed on Friday,
> > these where some changes that have come in since, there are some additional
> > changes that I still need to review (Re
On Sat, 2013-07-27 at 23:30 -0700, Saul Wold wrote:
> Richard,
>
> This is ready to pull, this is the set that was ACK'ed on friday by Paul
> and Ross, I removed the git recipe renames as requested and moved my obex
> change to a part 2.
>
> I did include a couple of priority patches from friday,
"closed minded" is relative, and I have my personal opinion who could be
classified like that. So let us not do ping-pong "stop being closed minded"
games. :)
As written several times already, it is just as simple action for the rare
"rfkill" people to do enable this as for me? So, the *real* que
W dniu 29.07.2013 12:44, Laszlo Papp pisze:
> OK, I give up the contribution. I really cannot collaborate with
> people who think it is acceptable to break *many* users' life for the
> whole project without being able to use anything in favor of a very
> limited (!) people with only two (!) applica
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4942
On Mon, Jul 29, 2013 at 11:48 AM, Laszlo Papp wrote:
> Have you ever heard about project budgets and that updating a toolchain
> requires a lot of testing, and hence time, money, man power?
>
>
> On Mon, Jul 29, 2013 at 11:46 AM, Paul Barke
Why it does not make sense in my opinion is the fact that the many people
would already need to do this right now. Yet, you prefer a few people (if
any?) with only a very limited application set out of the 1000+, as it is
only two which is affected?
I do not understand how the gun can be compared
Have you ever heard about project budgets and that updating a toolchain
requires a lot of testing, and hence time, money, man power?
On Mon, Jul 29, 2013 at 11:46 AM, Paul Barker wrote:
> On 29 July 2013 11:42, Laszlo Papp wrote:
> > Not to mention, you would cause a "runtime" issue which is p
On 29 July 2013 11:42, Laszlo Papp wrote:
> Not to mention, you would cause a "runtime" issue which is pretty simple to
> fix for a very minor portion compared to a *large* user base using older
> toolchains. There is a huge difference between a few people cannot use
> rfkill for those application
On 29 July 2013 11:42, Laszlo Papp wrote:
> you would cause a "runtime" issue which is pretty simple to fix
Enabling rfkill would involve writing a bbappend and patching busybox,
when a PACKAGECONFIG would make everyone happy and configurable from
the distro. Even if we disagree on what the defa
OK, I give up the contribution. I really cannot collaborate with people who
think it is acceptable to break *many* users' life for the whole project
without being able to use anything in favor of a very limited (!) people
with only two (!) applications.
On Mon, Jul 29, 2013 at 11:42 AM, Burton, R
On 29 July 2013 11:20, Phil Blundell wrote:
> But in this particular case, your new patch seems to have more serious
> problems since it will cause rfkill to silently disappear for many
> people who do currently have it.
>
> If your distro selects a toolchain which doesn't contain the necessary
>
You *do* realize rfkill is a hardly common feature?
Not to mention, you would cause a "runtime" issue which is pretty simple to
fix for a very minor portion compared to a *large* user base using older
toolchains. There is a huge difference between a few people cannot use
rfkill for those applicati
On Mon, 2013-07-29 at 11:30 +0100, Laszlo Papp wrote:
> Not to mention, there is a huge difference between build time
> regression and run time,
Quite so, run-time regressions are much harder to detect and debug.
p.
___
Openembedded-core mailing l
Exactly, so you broke the update for the last two new versions on the
*build* level.
Anyway, if you do not have any sympathy for older users, then I am very
disappointed.
After this change, the image will build just fine for the "new" people.
Also, if you do not write a change on top of mine, it
On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
> I disagree. This change should not have gone in the first place
> causing the regression for the users. Please be consistent with the
> history.
If this was a recent change then I would have some (limited) amount of
sympathy for your position
Not to mention, there is a huge difference between build time regression
and run time, so I disagree.
a)-c) can just as well be done after this change with the same loss. Do not
blame me for introducing build (!) regressions, and then you have got a
situation like this. If you feel it serious, wri
I disagree. This change should not have gone in the first place causing the
regression for the users. Please be consistent with the history.
On Mon, Jul 29, 2013 at 11:20 AM, Phil Blundell wrote:
> On Mon, 2013-07-29 at 11:01 +0100, Laszlo Papp wrote:
> > No, that was intentional. That is why t
On Mon, 2013-07-29 at 11:01 +0100, Laszlo Papp wrote:
> No, that was intentional. That is why the change has been updated.
>
>
> I can update the commit message if that is what you wish?
As a general rule yes, please always make sure that the commit message
describes what the patch is actually d
Package recipe should contain version token in its name.
Signed-off-by: Emilia Ciobanu
---
...ative.bb => docbook-sgml-dtd-4.1-native_4.1.bb} |0
1 file changed, 0 insertions(+), 0 deletions(-)
rename meta/recipes-devtools/docbook-sgml-dtd/{docbook-sgml-dtd-4.1-native.bb
=> docbook-sgml-dt
Package recipe should contain version token in its name.
Signed-off-by: Emilia Ciobanu
---
...ative.bb => docbook-sgml-dtd-3.1-native_3.1.bb} |0
1 file changed, 0 insertions(+), 0 deletions(-)
rename meta/recipes-devtools/docbook-sgml-dtd/{docbook-sgml-dtd-3.1-native.bb
=> docbook-sgml-dt
The recipes have the local version of the packages appended to the
recipe name.
The following changes since commit 67864ca79da08df752487a3a4e1a975546da123d:
systemd: Remove systemd_unitdir if systemd is not in distro features
(2013-07-24 11:35:39 +0100)
are available in the git repository at:
No, that was intentional. That is why the change has been updated.
I can update the commit message if that is what you wish?
On Mon, Jul 29, 2013 at 11:00 AM, Phil Blundell wrote:
> On Mon, 2013-07-29 at 08:16 +0100, Laszlo Papp wrote:
> > This is necessary to get the build going, for instance
On Mon, 2013-07-29 at 08:16 +0100, Laszlo Papp wrote:
> This is necessary to get the build going, for instance with older Code
> Sourcery
> compilers.
You seem to have inadvertently sent a patch to busybox.inc as well as
the defconfig change that's described in the commit message.
p.
_
On 07/26/2013 05:35 PM, Jukka Rissanen wrote:
do_install_append() {
- install -d ${D}${sysconfdir}/init.d/
- install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
+if ${@base_contains('DISTRO_FEATURES','sysvinit','true','false',d)}; then
+install -d ${D}${sysconfdir}/ini
On 28 July 2013 07:30, Saul Wold wrote:
> This is part 2 of the C-Pull, part one was reviewed and ACK'ed on Friday,
> these where some changes that have come in since, there are some additional
> changes that I still need to review (Read-Only Rootfs specificly).
The contents of the branch sgw/sta
From: Andre McCurdy
A simple clone of the corresponding Gnome class. Without this, devshell
fails completely on a default installation of MATE desktop Linux Mint 15.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
---
meta/lib/oe/terminal.py | 4
1 file changed, 4 insertions
Hmm, this was meant to be sent as a cover letter only. Please ignore the 1/14
and treat it as if it was :)
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
h
These are mostly backports from master with one patch for mesa which
derives from part of a change in master. These have been tested on the
Yocto Project autobuilder in conjunction with the two bitbake 1.18
patches I just sent.
Note: I would normally not backport PACKAGECONFIG additions, however
t
From: Laurentiu Palcu
Spaces are not handled properly in some parts of oe-core and it's safer
to abort toolchain installation if path contains spaces. Even though
we fix space handling in the toolchain installation script, there are
various other parts in the toolchain (perl scripts, sysroot path
Bluez5 is migrating away from using separate .conf files
for different profiles. So only install profile configuration files
when they are found. This is needed so that the bluez5.inc file
can be used with latest bluez5 from git.
Signed-off-by: Jukka Rissanen
---
meta/recipes-connectivity/bluez5
On 29 July 2013 07:51, Jukka Rissanen wrote:
>> I think you should be using the ptest here instead of test and inherit
>> ptest, please see the ptest.bbclass.
>>
>> I realize that this is not new code, but if we are going to changes this
>> we should use the new ptest mechanism.
>
> If I am readin
From: Muhammad Shakeel
If systemd is enabled then syslog is handled through a service file
and related files in /etc/init.d are removed. This removes following
warning:
WARNING: busybox: NOT adding alternative provide /etc/init.d/syslog:
/etc/init.d/syslog.busybox does not exist
Signed-off-by:
From: Muhammad Shakeel
If systemd is supported DISTRO_FEATURE and sysvinit is not and also if
systemd_unitdir contains anything then no need to keep init.d scripts
for sysvinit compatibility.
Signed-off-by: Muhammad Shakeel
---
meta/classes/systemd.bbclass | 15 +++
1 file change
The previous patch to fix the installation of libopkg headers has been accepted
upstream and is the next commit after the SRCREV used by the opkg recipe.
Therefore the patch can be replaced by a simple update of the SRCREV.
Signed-off-by: Paul Barker
---
.../0001-Fix-libopkg-header-installation.
Let us fix the build issue first, and then you can improve the situation as
you wish.
On Mon, Jul 29, 2013 at 8:20 AM, Paul Barker wrote:
> On 29 July 2013 08:16, Laszlo Papp wrote:
> > - busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
> > - busybox_cfg('bluetooth',
On 29 July 2013 08:16, Laszlo Papp wrote:
> - busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
> - busybox_cfg('bluetooth', distro_features, 'CONFIG_RFKILL', cnf, rem)
It would be good to have some way to re-enable this if it is needed.
Maybe an 'rfkill' PACKAGECONFIG o
This is necessary to get the build going, for instance with older Code Sourcery
compilers.
It is also disabled in upstream due to this very reason. The details can be
found on the following links:
http://comments.gmane.org/gmane.linux.busybox/30999
http://git.busybox.net/busybox/commit/?h=1_21_st
78 matches
Mail list logo