[meta-oe][PATCH 0/2] Fix parse errors

[meta-oe][PATCH 0/2] Fix parse errors

[Otavio Salvador]

The following changes since commit 15a5642b2a4df41dc0adf9d250cd5085eaf1d69b:

  libcap2: drop, it's in oe-core already (2011-06-28 14:57:03 +0200)

are available in the git repository at:
  git://github.com/OSSystems/meta-oe master
  https://github.com/OSSystems/meta-oe/tree/master

Otavio Salvador (2):
  systemd: set all packages PACKAGE_ARCH to MACHINE_ARCH
  task-x11: set all packages PACKAGE_ARCH to MACHINE_ARCH

 meta-oe/recipes-core/systemd/systemd_git.bb |    2 +-
 meta-oe/recipes-core/tasks/task-x11.bb      |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.7.2.5

[meta-oe][PATCH 1/2] systemd: set all packages PACKAGE_ARCH to MACHINE_ARCH

[Otavio Salvador]

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta-oe/recipes-core/systemd/systemd_git.bb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta-oe/recipes-core/systemd/systemd_git.bb b/meta-oe/recipes-core/systemd/systemd_git.bb
index dff299e..96875af 100644
--- a/meta-oe/recipes-core/systemd/systemd_git.bb
+++ b/meta-oe/recipes-core/systemd/systemd_git.bb
@@ -67,7 +67,7 @@ FILES_${PN}-gui = "${bindir}/systemadm"
 
 # This is a machine specific file
 FILES_${PN}-serialgetty = "${base_libdir}/systemd/system/serial-getty@.service ${sysconfdir}/systemd/system/getty.target.wants/getty@${@get_console(bb, d)}.service"
-PACKAGE_ARCH_${PN}-serialgetty = "${MACHINE_ARCH}"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 FILES_${PN} = " ${base_bindir}/* \
                 ${datadir}/dbus-1/services \
-- 
1.7.2.5

[meta-oe][PATCH 2/2] task-x11: set all packages PACKAGE_ARCH to MACHINE_ARCH

[Otavio Salvador]

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta-oe/recipes-core/tasks/task-x11.bb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta-oe/recipes-core/tasks/task-x11.bb b/meta-oe/recipes-core/tasks/task-x11.bb
index 66af8bd..0a48165 100644
--- a/meta-oe/recipes-core/tasks/task-x11.bb
+++ b/meta-oe/recipes-core/tasks/task-x11.bb
@@ -26,7 +26,7 @@ XSERVER_COMMON ?= "xserver-kdrive-common"
 XSERVER_COMMON_shr = "xserver-common"
 
 # This is also the reason why we have to make this package machine specific :/
-PACKAGE_ARCH_${PN}-server = "${MACHINE_ARCH}"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 RDEPENDS_${PN}-server = "\
   ${XSERVER} \
-- 
1.7.2.5

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28-06-11 16:40, Otavio Salvador wrote:
> The following changes since commit 15a5642b2a4df41dc0adf9d250cd5085eaf1d69b:
> 
>   libcap2: drop, it's in oe-core already (2011-06-28 14:57:03 +0200)
> 
> are available in the git repository at:
>   git://github.com/OSSystems/meta-oe master
>   https://github.com/OSSystems/meta-oe/tree/master
> 
> Otavio Salvador (2):
>   systemd: set all packages PACKAGE_ARCH to MACHINE_ARCH
>   task-x11: set all packages PACKAGE_ARCH to MACHINE_ARCH

I'm not going pull those in, since the whole point was to not make them
machine specific. RP has pushed a workaround for it so parsing
continues. I'll push a proper fix for systemd later.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFOCeqHMkyGM64RGpERAk+QAKCW9ftWIjd/MjH7+fmOoJl0rcEb9gCgrMry
VQA0yMOKkxirwJ9W7fp5GRA=
=AhO0
-----END PGP SIGNATURE-----

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Otavio Salvador]

On Tue, Jun 28, 2011 at 11:51, Koen Kooi <koen@dominion.thruhere.net> wrote:
> I'm not going pull those in, since the whole point was to not make them
> machine specific. RP has pushed a workaround for it so parsing
> continues. I'll push a proper fix for systemd later.

What's the difference if the package will be built from same source?

In case you change anything you'll need to rebuild all packages anyway
so I see no gain in having it per package.

Mind to clarify it?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28-06-11 16:59, Otavio Salvador wrote:
> On Tue, Jun 28, 2011 at 11:51, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> I'm not going pull those in, since the whole point was to not make them
>> machine specific. RP has pushed a workaround for it so parsing
>> continues. I'll push a proper fix for systemd later.
> 
> What's the difference if the package will be built from same source?
> 
> In case you change anything you'll need to rebuild all packages anyway
> so I see no gain in having it per package.

It makes it easier to deploy updates for the main packages (e.g.
sysvinit, systemd) to all the targets without having to build it for all
targets. It's a weird optimization, but makes life a lot easier for
people needing to support a ton of machines :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFOCfSmMkyGM64RGpERAoC5AJ97bC6crQUztfiLKWXng6XTKPqt8gCfUMz/
pvcR4GzY/Ifm6b6coShOabk=
=4LMp
-----END PGP SIGNATURE-----

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Otavio Salvador]

On Tue, Jun 28, 2011 at 12:35, Koen Kooi <koen@dominion.thruhere.net> wrote:
> It makes it easier to deploy updates for the main packages (e.g.
> sysvinit, systemd) to all the targets without having to build it for all
> targets. It's a weird optimization, but makes life a lot easier for
> people needing to support a ton of machines :)

I didn't follow it; for example if you change PR of the recipe  it
will be rebuild n times (being n the number of machines) and each of
it will *overwrite* the non-machine packages. This seems wrong for me.

Can you describe a use case?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28-06-11 18:25, Otavio Salvador wrote:
> On Tue, Jun 28, 2011 at 12:35, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> It makes it easier to deploy updates for the main packages (e.g.
>> sysvinit, systemd) to all the targets without having to build it for all
>> targets. It's a weird optimization, but makes life a lot easier for
>> people needing to support a ton of machines :)
> 
> I didn't follow it; for example if you change PR of the recipe  it
> will be rebuild n times (being n the number of machines) and each of
> it will *overwrite* the non-machine packages. This seems wrong for me.
> 
> Can you describe a use case?

Rolling out a fix for the generic package without having to rebuild it N
times.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFOCgYIMkyGM64RGpERAoFEAJ9O58mXspRM3IAljyCO3Udrh1G40gCgrMza
Qmh+JOLkLvq6qUCbrnIcKSU=
=/YG8
-----END PGP SIGNATURE-----

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Otavio Salvador]

On Tue, Jun 28, 2011 at 13:49, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Can you describe a use case?
>
> Rolling out a fix for the generic package without having to rebuild it N
> times.

When doing this fix you should bump PR, right? in this case, this will
be (or ought to be) rebuild for all machines thus for me seems it will
be the same end result.

The only use case I see is very risky since it fully depends on the
developper to know which machine it needs to be build to and like.
This IMO is wrong and the risk of forget a need rebuild is bigger then
the reduction of build and cpu cycles.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Tom Rini]

On 06/28/2011 09:54 AM, Otavio Salvador wrote:
> On Tue, Jun 28, 2011 at 13:49, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>> Can you describe a use case?
>>
>> Rolling out a fix for the generic package without having to rebuild it N
>> times.
> 
> When doing this fix you should bump PR, right? in this case, this will
> be (or ought to be) rebuild for all machines thus for me seems it will
> be the same end result.

It will be, yes.  What Koen is saying is that if you're a feed using
distribution you don't NEED to kick off the build for N machines, just N
architectures (since you can use sysvinit-getty-r2 and sysvinit-r3 just
fine, if there weren't any changes to the getty subpackage).

-- 
Tom Rini
Mentor Graphics Corporation

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Otavio Salvador]

On Tue, Jun 28, 2011 at 14:16, Tom Rini <tom_rini@mentor.com> wrote:
> It will be, yes.  What Koen is saying is that if you're a feed using
> distribution you don't NEED to kick off the build for N machines, just N
> architectures (since you can use sysvinit-getty-r2 and sysvinit-r3 just
> fine, if there weren't any changes to the getty subpackage).

This is broken by design my POV; the right way to handle is to split
the package (as Koen has did) but IMO having this on /one/ binary
package of same recipe is wrong.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Frans Meulenbroeks]

2011/6/28 Koen Kooi <koen@dominion.thruhere.net>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 28-06-11 16:59, Otavio Salvador wrote:
> > On Tue, Jun 28, 2011 at 11:51, Koen Kooi <koen@dominion.thruhere.net>
> wrote:
> >> I'm not going pull those in, since the whole point was to not make them
> >> machine specific. RP has pushed a workaround for it so parsing
> >> continues. I'll push a proper fix for systemd later.
> >
> > What's the difference if the package will be built from same source?
> >
> > In case you change anything you'll need to rebuild all packages anyway
> > so I see no gain in having it per package.
>
> It makes it easier to deploy updates for the main packages (e.g.
> sysvinit, systemd) to all the targets without having to build it for all
> targets. It's a weird optimization, but makes life a lot easier for
> people needing to support a ton of machines :)
>

Hm. saving some CPU cycles and wall clock time makes life a lot easier.
Guess you haven't too much of a life then :-)
No kidding, why not keep things simple. and elegant.
(and actually people needing to maintain a lot of machines and keeping them
up to date is somewhat an oddity anyway; My experience is that most embedded
developers need to support only a few machines and typically freeze their
sources and stabilize their product).

Have fun!
Frans

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Tom Rini]

On 06/28/2011 10:14 AM, Frans Meulenbroeks wrote:
> 2011/6/28 Koen Kooi <koen@dominion.thruhere.net>
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 28-06-11 16:59, Otavio Salvador wrote:
>>> On Tue, Jun 28, 2011 at 11:51, Koen Kooi <koen@dominion.thruhere.net>
>> wrote:
>>>> I'm not going pull those in, since the whole point was to not make them
>>>> machine specific. RP has pushed a workaround for it so parsing
>>>> continues. I'll push a proper fix for systemd later.
>>>
>>> What's the difference if the package will be built from same source?
>>>
>>> In case you change anything you'll need to rebuild all packages anyway
>>> so I see no gain in having it per package.
>>
>> It makes it easier to deploy updates for the main packages (e.g.
>> sysvinit, systemd) to all the targets without having to build it for all
>> targets. It's a weird optimization, but makes life a lot easier for
>> people needing to support a ton of machines :)
>>
> 
> Hm. saving some CPU cycles and wall clock time makes life a lot easier.
> Guess you haven't too much of a life then :-)
> No kidding, why not keep things simple. and elegant.
> (and actually people needing to maintain a lot of machines and keeping them
> up to date is somewhat an oddity anyway; My experience is that most embedded
> developers need to support only a few machines and typically freeze their
> sources and stabilize their product).

Really?  One of those big requests we see a lot is for things like "how
can I support the N different revs of the board for this product".
Looking over at the kernel side of things that was one of the drivers
for device tree stuff.  So yes, outside of community based distributions
like Angstrom and SHR and SlugOS and ... there are commercial uses for
this change as well.  And it doesn't change the world of one machine
embedded products at all.

-- 
Tom Rini
Mentor Graphics Corporation

Re: [meta-oe][PATCH 0/2] Fix parse errors

[Frans Meulenbroeks]

2011/6/28 Tom Rini <tom_rini@mentor.com>

> On 06/28/2011 10:14 AM, Frans Meulenbroeks wrote:
> > 2011/6/28 Koen Kooi <koen@dominion.thruhere.net>
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 28-06-11 16:59, Otavio Salvador wrote:
> >>> On Tue, Jun 28, 2011 at 11:51, Koen Kooi <koen@dominion.thruhere.net>
> >> wrote:
> >>>> I'm not going pull those in, since the whole point was to not make
> them
> >>>> machine specific. RP has pushed a workaround for it so parsing
> >>>> continues. I'll push a proper fix for systemd later.
> >>>
> >>> What's the difference if the package will be built from same source?
> >>>
> >>> In case you change anything you'll need to rebuild all packages anyway
> >>> so I see no gain in having it per package.
> >>
> >> It makes it easier to deploy updates for the main packages (e.g.
> >> sysvinit, systemd) to all the targets without having to build it for all
> >> targets. It's a weird optimization, but makes life a lot easier for
> >> people needing to support a ton of machines :)
> >>
> >
> > Hm. saving some CPU cycles and wall clock time makes life a lot easier.
> > Guess you haven't too much of a life then :-)
> > No kidding, why not keep things simple. and elegant.
> > (and actually people needing to maintain a lot of machines and keeping
> them
> > up to date is somewhat an oddity anyway; My experience is that most
> embedded
> > developers need to support only a few machines and typically freeze their
> > sources and stabilize their product).
>
> Really?  One of those big requests we see a lot is for things like "how
> can I support the N different revs of the board for this product".
> Looking over at the kernel side of things that was one of the drivers
> for device tree stuff.  So yes, outside of community based distributions
> like Angstrom and SHR and SlugOS and ... there are commercial uses for
> this change as well.  And it doesn't change the world of one machine
> embedded products at all.
>
>
The vendors of embedded products I am aware of (and then I'm talking about
TV's, NAS-es, Audio systems etc etc but also boards running embedded linux
code) focus on stability. Actually none of my managers ever cared if we were
running the latest version of Linux. They do care about stability and
maturity. Some of the products I need to care about still use a 2.6.24
kernel. No way this is going to move. Customers are happy with the product,
and do not care about kernel etc, so for these products only some bug fixing
is done. And yes, we have boards with multiple revs, but we try to keep the
changes small and localized. This might mean some kernel fixes, but
generally no upgrades to newer versions or so.

Of course this is my experience and other places might do things
differently. And of course this is going off-topic.

Have fun! Frans.