usbinit, weston-init, run-postinsts, qt-demo-init: Drop allarch

Submitted by Martin Jansa on June 19, 2014, 11:23 a.m.

Details

Message ID 1403177022-19086-1-git-send-email-Martin.Jansa@gmail.com
State New
Headers show

Commit Message

Martin Jansa June 19, 2014, 11:23 a.m.
* update-rc.d.bbclass now adds dependency on TUNE_PKGARCH initscripts, so these cannot be allarch

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/recipes-bsp/usbinit/usbinit.bb                      | 2 +-
 meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb | 2 +-
 meta/recipes-graphics/wayland/weston-init.bb             | 2 +-
 meta/recipes-qt/qt-demo/qt-demo-init_0.1.bb              | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

Patch hide | download patch | download mbox

diff --git a/meta/recipes-bsp/usbinit/usbinit.bb b/meta/recipes-bsp/usbinit/usbinit.bb
index aba44b4..bc36824 100644
--- a/meta/recipes-bsp/usbinit/usbinit.bb
+++ b/meta/recipes-bsp/usbinit/usbinit.bb
@@ -15,7 +15,7 @@  do_install() {
     install usb-gether ${D}${sysconfdir}/init.d
 }
 
-inherit update-rc.d allarch
+inherit update-rc.d
 
 INITSCRIPT_NAME = "usb-gether"
 INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb b/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
index 64f85c2..4eec578 100644
--- a/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
@@ -9,7 +9,7 @@  SRC_URI = "file://run-postinsts \
            file://run-postinsts.init \
            file://run-postinsts.service"
 
-inherit allarch systemd update-rc.d
+inherit systemd update-rc.d
 
 INITSCRIPT_NAME = "run-postinsts"
 INITSCRIPT_PARAMS = "start 99 S ."
diff --git a/meta/recipes-graphics/wayland/weston-init.bb b/meta/recipes-graphics/wayland/weston-init.bb
index 38b78bc..ae306c9 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -11,7 +11,7 @@  do_install() {
 	install -m755 ${WORKDIR}/init ${D}/${sysconfdir}/init.d/weston
 }
 
-inherit allarch update-rc.d
+inherit update-rc.d
 
 RDEPENDS_${PN} = "weston kbd"
 
diff --git a/meta/recipes-qt/qt-demo/qt-demo-init_0.1.bb b/meta/recipes-qt/qt-demo/qt-demo-init_0.1.bb
index fff3620..a2f51d4 100644
--- a/meta/recipes-qt/qt-demo/qt-demo-init_0.1.bb
+++ b/meta/recipes-qt/qt-demo/qt-demo-init_0.1.bb
@@ -11,7 +11,7 @@  do_install() {
 	install -m 0755 ${WORKDIR}/qtdemo-init ${D}${sysconfdir}/init.d/qtdemo
 }
 
-inherit update-rc.d allarch
+inherit update-rc.d
 
 INITSCRIPT_NAME = "qtdemo"
 INITSCRIPT_PARAMS = "start 99 5 2 . stop 19 0 1 6 ."

Comments

Paul Eggleton June 19, 2014, 1:54 p.m.
Hi Martin,

On Thursday 19 June 2014 13:23:42 Martin Jansa wrote:
> * update-rc.d.bbclass now adds dependency on TUNE_PKGARCH initscripts, so
> these cannot be allarch

As I've said before, I really dislike this change. The system should be made 
to handle the situation properly instead of working around the issue.

Cheers,
Paul
Martin Jansa June 19, 2014, 4:39 p.m.
On Thu, Jun 19, 2014 at 02:54:59PM +0100, Paul Eggleton wrote:
> Hi Martin,
> 
> On Thursday 19 June 2014 13:23:42 Martin Jansa wrote:
> > * update-rc.d.bbclass now adds dependency on TUNE_PKGARCH initscripts, so
> > these cannot be allarch
> 
> As I've said before, I really dislike this change. The system should be made 
> to handle the situation properly instead of working around the issue.

This one is new :) (I think) I had clean state (with my unmerged
changes) with dylan (now I'm testing dora, daisy, master as well), these
are "new" as the initscripts dependency was added recently.
Paul Eggleton June 19, 2014, 5:03 p.m.
On Thursday 19 June 2014 18:39:22 Martin Jansa wrote:
> On Thu, Jun 19, 2014 at 02:54:59PM +0100, Paul Eggleton wrote:
> > Hi Martin,
> > 
> > On Thursday 19 June 2014 13:23:42 Martin Jansa wrote:
> > > * update-rc.d.bbclass now adds dependency on TUNE_PKGARCH initscripts,
> > > so
> > > these cannot be allarch
> > 
> > As I've said before, I really dislike this change. The system should be
> > made to handle the situation properly instead of working around the
> > issue.
>
> This one is new :) (I think) I had clean state (with my unmerged
> changes) with dylan (now I'm testing dora, daisy, master as well), these
> are "new" as the initscripts dependency was added recently.

I'm aware that it's a new instance, but of the same situation.

Cheers,
Paul
Ross Burton June 23, 2014, 12:12 p.m.
On 19 June 2014 14:54, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>> * update-rc.d.bbclass now adds dependency on TUNE_PKGARCH initscripts, so
>> these cannot be allarch
>
> As I've said before, I really dislike this change. The system should be made
> to handle the situation properly instead of working around the issue.

Isn't this what the abi exclude thingy is for?

Ross
Martin Jansa June 23, 2014, 12:39 p.m.
On Mon, Jun 23, 2014 at 01:12:25PM +0100, Burton, Ross wrote:
> On 19 June 2014 14:54, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> >> * update-rc.d.bbclass now adds dependency on TUNE_PKGARCH initscripts, so
> >> these cannot be allarch
> >
> > As I've said before, I really dislike this change. The system should be made
> > to handle the situation properly instead of working around the issue.
> 
> Isn't this what the abi exclude thingy is for?

Do we want to maintain list of all recipes which inherit update-rc.c in
layer.conf?

That's what I did in one of our layers and the list is rather long.
Martin Jansa June 23, 2014, 12:44 p.m.
On Mon, Jun 23, 2014 at 02:39:22PM +0200, Martin Jansa wrote:
> On Mon, Jun 23, 2014 at 01:12:25PM +0100, Burton, Ross wrote:
> > On 19 June 2014 14:54, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> > >> * update-rc.d.bbclass now adds dependency on TUNE_PKGARCH initscripts, so
> > >> these cannot be allarch
> > >
> > > As I've said before, I really dislike this change. The system should be made
> > > to handle the situation properly instead of working around the issue.
> > 
> > Isn't this what the abi exclude thingy is for?
> 
> Do we want to maintain list of all recipes which inherit update-rc.c in
> layer.conf?
> 
> That's what I did in one of our layers and the list is rather long.

Ah sorry for possible confusion, I had to list *all* of them because we
have MACHINE_ARCH initscripts.

To fix current issues in oe-core we only need to list all recipes which
inherit allarch *and* update-rc.d (unless we want to exclude it
everywhere just for consistency).

> abi exclude thingy

is a bit dangerous, I still sometimes see issues when something is
supposed to be abisafe and in some cases it isn't and I need to manually
bump PR in the recipe which wasn't rebuilt.

So I'm trying to use SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS only in cases where
it's really safe or when the dependent recipe takes forever to build (so
I wan't to build it just once or once per TUNE_PKGARCH). For simple and
quickly built recipe I really don't mind "building" them multiple times
if it prevents "rebuilding" them every single time I change MACHINE.
Richard Purdie July 3, 2014, 4:45 p.m.
On Mon, 2014-06-23 at 14:44 +0200, Martin Jansa wrote:
> On Mon, Jun 23, 2014 at 02:39:22PM +0200, Martin Jansa wrote:
> > On Mon, Jun 23, 2014 at 01:12:25PM +0100, Burton, Ross wrote:
> > > On 19 June 2014 14:54, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> > > >> * update-rc.d.bbclass now adds dependency on TUNE_PKGARCH initscripts, so
> > > >> these cannot be allarch
> > > >
> > > > As I've said before, I really dislike this change. The system should be made
> > > > to handle the situation properly instead of working around the issue.
> > > 
> > > Isn't this what the abi exclude thingy is for?
> > 
> > Do we want to maintain list of all recipes which inherit update-rc.c in
> > layer.conf?
> > 
> > That's what I did in one of our layers and the list is rather long.
> 
> Ah sorry for possible confusion, I had to list *all* of them because we
> have MACHINE_ARCH initscripts.
> 
> To fix current issues in oe-core we only need to list all recipes which
> inherit allarch *and* update-rc.d (unless we want to exclude it
> everywhere just for consistency).
> 
> > abi exclude thingy
> 
> is a bit dangerous, I still sometimes see issues when something is
> supposed to be abisafe and in some cases it isn't and I need to manually
> bump PR in the recipe which wasn't rebuilt.
> 
> So I'm trying to use SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS only in cases where
> it's really safe or when the dependent recipe takes forever to build (so
> I wan't to build it just once or once per TUNE_PKGARCH). For simple and
> quickly built recipe I really don't mind "building" them multiple times
> if it prevents "rebuilding" them every single time I change MACHINE.

Can't we just add "initscripts" to the list there. There shouldn't be a
need to rebuild initscripts any time something depending on it changes,
it should have a safe ABI in that sense?

Cheers,

Richard
Ulf Samuelsson July 3, 2014, 5:19 p.m.
Running a Beaglebone with an LCD.
Running Yocto-1.5 with meta-oe, meta-ti, meta-arago, meta-qt5 added.

Would like to have boot process where the LCD looks like the following:

1. Boot LOGO
2. psplash
3. QT based application.

Between 2 and 3, I get an ugly login prompt.

Removed the FRAMEBUFFER_CONSOLE from the kernel build,
but then I do not get a Boot LOGO.
The screen is black, blinks and then psplash starts.

Any ideas?

Ulf Samuelsson
Ross Burton July 3, 2014, 8:31 p.m.
On 3 July 2014 18:19, Ulf Samuelsson <openembedded-core@emagii.com> wrote:
> Between 2 and 3, I get an ugly login prompt.

So something is chvt'ing away from psplash too early.  Is the Qt
application running on framebuffer, or Wayland, or X11, or what?

Ross
Ulf Samuelsson July 3, 2014, 8:36 p.m.
2014-07-03 22:31, Burton, Ross skrev:
> On 3 July 2014 18:19, Ulf Samuelsson <openembedded-core@emagii.com> wrote:
>> Between 2 and 3, I get an ugly login prompt.
> So something is chvt'ing away from psplash too early.  Is the Qt
> application running on framebuffer, or Wayland, or X11, or what?
>
> Ross
Running eglfs using the PowerVR omaplfb and da8xx-fb drivers.

The ugly login prompt disappears, if I don't have a console on the 
framebuffer.
But why don't I get a logo if I disable it???

BR
Ulf