hello...

hello...

[Tobias Pflug]

hey..

I just wanted to say hi to everyone on this list. I recently started
working with OpenEmbedded. I'm using it at work for an embedded solution
using the compulab boards. So far I am mostly enjoying the "openembedded
experience"..

The documenation could be a bit better and less scattered over different
places but well.. noone loves writing documentation. But I have received
good and friendly support from the #oe irc channel.

The next point will perhaps not make me many friends on this list, but
I am not exactly too fond of monotone. I for one would prefer if
openembedded used git. Mostly because it is *so* much faster. My machine
is fairly decent I would say and still the usage experience isn't that
great. (`mtn status` = zZzz :)

anyway, I look forward to using OE more and hopefully also contributing
to it.

best regards,
Tobi

Re: hello...

[Michael Krelin]

> The next point will perhaps not make me many friends on this list, but
> I am not exactly too fond of monotone. I for one would prefer if
> openembedded used git. Mostly because it is *so* much faster. My machine
> is fairly decent I would say and still the usage experience isn't that
> great. (`mtn status` = zZzz :)

So would I (and not only for performance reasons), but I doubt it's 
going to happen anytime soon ;-)

Love,
H

Re: hello...

[Holger Freyther]

Am 04.10.2007 um 13:18 schrieb Michael Krelin:

>> The next point will perhaps not make me many friends on this list,  
>> but
>> I am not exactly too fond of monotone. I for one would prefer if
>> openembedded used git. Mostly because it is *so* much faster. My  
>> machine
>> is fairly decent I would say and still the usage experience isn't  
>> that
>> great. (`mtn status` = zZzz :)
>
> So would I (and not only for performance reasons), but I doubt it's
> going to happen anytime soon ;-)

Hi,

If someone can host my mtn2git script and a git tree we can have a  
git mirror almost immediately. But yes I think there are some good  
reasons to stay with monotone as primary system.


z.

Re: monotone/git (was hello...)

[Tobias Pflug]

On Thu, 2007-10-04 at 14:40 +0200, Holger Freyther wrote:
> Am 04.10.2007 um 13:18 schrieb Michael Krelin:
> 

> Hi,
> 
> If someone can host my mtn2git script and a git tree we can have a  
> git mirror almost immediately. But yes I think there are some good  
> reasons to stay with monotone as primary system.
> 
> 
> z.

Well luckily I am not an ignorant git-fanboy :) Could you shortly point
out to me the reasons why you think monotone is favorable over git for
use with openembedded ? I will admit right away that my limitation with
SCMs in large projects is more than limited. So i can only speak of
my user experience with git vs my experience with monotone and i prefer
the first.

thanks.

-Tobi

Re: hello...

[Michael Krelin]

> Hi,
> 
> If someone can host my mtn2git script and a git tree we can have a  
> git mirror almost immediately. But yes I think there are some good  
> reasons to stay with monotone as primary system.

Does such script exist? I think the closest to it is 'tailor', which is
far from perfection. I was thinking about writing one when I get time...

And of course, provided you have conversion utility and hosting space
you get a git miror in no time ;-)

Love,
H

Re: monotone/git (was hello...)

[Holger Freyther]

Am 04.10.2007 um 14:55 schrieb Tobias Pflug:

> Well luckily I am not an ignorant git-fanboy :) Could you shortly  
> point
> out to me the reasons why you think monotone is favorable over git for
> use with openembedded ? I will admit right away that my limitation  
> with
> SCMs in large projects is more than limited. So i can only speak of
> my user experience with git vs my experience with monotone and i  
> prefer
> the first.

Hi,

this will be my only to this topic but I see that as following:


git:

	pros:
		+ Speed
		+ Momentum
		+ Merging

	cons:
		- Incompats with other versions
		- repacking (even if probably all known races are fixed)
		- shell mess with bashism and GNUism
		- still complicated to use
		- Does not track directories


mtn:
	cons:
		- Speed on rev pulling (I think mtn ls and status, diff is quite fast)
		- we can not easily merge the dreambox branch (this is why I wrote  
mtn2git)

	pros:
		+ trust (I don't feel like remembering the latest over night)
		+ awesome manual
		+ trusting the code base (git is catching up, Linus is a god...  
but...)
		+ certs attachable to revs
		+ attributes and other testresults are attachable to files and it  
is on my todolist to use them
		+ tracks directories
		+ portable


The last three/four reasons are the one why I would propose to stay  
with mtn as the main repository. I'm also working on a git2mtn script  
(after having merged the dreambox branch) which could make git a  
(semi) supported system for OE (if someone will host it).


z.

PS: I almost exclusively use git-svn for my work on WebKit, specially  
for git-reabse...

Re: monotone/git (was hello...)

[Michael Krelin]

> Well luckily I am not an ignorant git-fanboy :) Could you shortly point
> out to me the reasons why you think monotone is favorable over git for
> use with openembedded ? I will admit right away that my limitation with
> SCMs in large projects is more than limited. So i can only speak of
> my user experience with git vs my experience with monotone and i prefer
> the first.

Well, 1st - OE folks are used to monotone now. That's primary reason.
The second primary reason is that I know of some developers who seem to
dislike git. And if we're talking about technical reason, one I can
think of is that there's no non-ssh transport allowing push, which
complicates administration of our "central" repository. Basically,
monotone is not really used as a DSCM in OE, it's just a somewhat
centralized SCM which allows merges as well as forks.

Personally, I think the lack of tools like gitk makes mtn history almost
opaque which gets even more opaque and unreadable due to the lack of
features like rebase.

I do think also that potential corporate users of OE would appreciate
git (the mirror would mostly solve this, though) as *I* think it's much
easier with git to maintain own branch while picking the important
changes from our tree (contributing back will be more complicated, though).

The above is my personal opinion and I have to admit I may miss
something about monotone, since, although I've had no problems using it
both ways, I wouldn't say I'm a monotonic guru.

Love,
H

Re: monotone/git (was hello...)

[Darcy Watkins]

Hello,

If there is actually any real serious consideration of changing the
source control system, you should also consider mercurial as well as git
versus monotone.  At least consider adding a recipe to fetch package
source from a mercurial based upstream source.

Regards,

Darcy

Re: monotone/git (was hello...)

[Michael Krelin]

> this will be my only to this topic but I see that as following:

Why won't you clarify your points?

> git:
> 	cons:
> 		- Incompats with other versions

What do you mean?

> 		- repacking (even if probably all known races are fixed)

That's not a contra if we compare with monotone.

> 		- shell mess with bashism and GNUism

Very true and, likely to be a show-stopper, anyway.

> 		- still complicated to use

Well, if you use the monotone subset of git, it's not ;-)

> 		- Does not track directories

Is it a problem with OE?

> mtn:
> 	cons:
> 		- Speed on rev pulling (I think mtn ls and status, diff is quite fast)
> 		- we can not easily merge the dreambox branch (this is why I wrote  
> mtn2git)

Aha, now I know the script exists :-)

> 	pros:
> 		+ trust (I don't feel like remembering the latest over night)

Can you elaborate on the expression in parentheses?

> 		+ awesome manual

I wouldn't call it awesome when it goes beyond trivialities, but I don't 
think it's a problem with either SCM.

> 		+ trusting the code base (git is catching up, Linus is a god...  
> but...)

Well, OE relies on git codebase indirectly anyway ;-)

> 		+ certs attachable to revs
> 		+ attributes and other testresults are attachable to files and it  
> is on my todolist to use them
> 		+ tracks directories
> 		+ portable
> 
> 
> The last three/four reasons are the one why I would propose to stay  
> with mtn as the main repository. I'm also working on a git2mtn script  
> (after having merged the dreambox branch) which could make git a  
> (semi) supported system for OE (if someone will host it).

The bottom line is - we're not going to move anytime soon. And I agree 
it makes sense. I'm yet to see what are these attributes and other 
testresults attachable to files (sounds interesting), but I'm a bit 
afraid of your idea of (ab)using it, since that may make us get stuck 
with mtn in the future no matter what.

Love,
H

Re: monotone/git (was hello...)

[Michael Krelin]

> Hello,
> 
> If there is actually any real serious consideration of changing the
> source control system, you should also consider mercurial as well as git
> versus monotone.  At least consider adding a recipe to fetch package
> source from a mercurial based upstream source.

I think this is unrelated and if there are packages that require it, it 
should be done anyway.

Love,
H

Re: monotone/git (was hello...)

[Richard Purdie]

On Thu, 2007-10-04 at 06:50 -0700, Darcy Watkins wrote:
> If there is actually any real serious consideration of changing the
> source control system, you should also consider mercurial as well as git
> versus monotone.  At least consider adding a recipe to fetch package
> source from a mercurial based upstream source.

FWIW, the basics of a mercurial fetcher were added to bitbake trunk
recently.

Regards,

Richard

Re: monotone/git (was hello...)

[Chris Larson]

On 10/4/07, Michael Krelin <hacker@klever.net> wrote:
> > Well luckily I am not an ignorant git-fanboy :) Could you shortly point
> > out to me the reasons why you think monotone is favorable over git for
> > use with openembedded ? I will admit right away that my limitation with
> > SCMs in large projects is more than limited. So i can only speak of
> > my user experience with git vs my experience with monotone and i prefer
> > the first.
>
> Well, 1st - OE folks are used to monotone now. That's primary reason.
> The second primary reason is that I know of some developers who seem to
> dislike git. And if we're talking about technical reason, one I can
> think of is that there's no non-ssh transport allowing push, which
> complicates administration of our "central" repository.

That's not correct.  You can push to a git repository over http/webdav
to an apache2 server.
-- 
Chris Larson - clarson at kergoth dot com
Dedicated Engineer - MontaVista - clarson at mvista dot com
Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus

Re: monotone/git (was hello...)

[Tim Bird]

Chris Larson wrote:
> On 10/4/07, Michael Krelin <hacker@klever.net> wrote:
>>> Well luckily I am not an ignorant git-fanboy :) Could you shortly point
>>> out to me the reasons why you think monotone is favorable over git for
>>> use with openembedded ? I will admit right away that my limitation with
>>> SCMs in large projects is more than limited. So i can only speak of
>>> my user experience with git vs my experience with monotone and i prefer
>>> the first.
>> Well, 1st - OE folks are used to monotone now. That's primary reason.
>> The second primary reason is that I know of some developers who seem to
>> dislike git. And if we're talking about technical reason, one I can
>> think of is that there's no non-ssh transport allowing push, which
>> complicates administration of our "central" repository.
> 
> That's not correct.  You can push to a git repository over http/webdav
> to an apache2 server.

Theoretically.  My experience is that it often fails, at least with
the kernel.  But maybe this is just a git-tree maintenance issue for
the kernel devs.  Chris is correct, however, that the feature is
present in git.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: monotone/git (was hello...)

[Chris Larson]

On 10/4/07, Tim Bird <tim.bird@am.sony.com> wrote:
> Chris Larson wrote:
> > On 10/4/07, Michael Krelin <hacker@klever.net> wrote:
> >>> Well luckily I am not an ignorant git-fanboy :) Could you shortly point
> >>> out to me the reasons why you think monotone is favorable over git for
> >>> use with openembedded ? I will admit right away that my limitation with
> >>> SCMs in large projects is more than limited. So i can only speak of
> >>> my user experience with git vs my experience with monotone and i prefer
> >>> the first.
> >> Well, 1st - OE folks are used to monotone now. That's primary reason.
> >> The second primary reason is that I know of some developers who seem to
> >> dislike git. And if we're talking about technical reason, one I can
> >> think of is that there's no non-ssh transport allowing push, which
> >> complicates administration of our "central" repository.
> >
> > That's not correct.  You can push to a git repository over http/webdav
> > to an apache2 server.
>
> Theoretically.  My experience is that it often fails, at least with
> the kernel.  But maybe this is just a git-tree maintenance issue for
> the kernel devs.  Chris is correct, however, that the feature is
> present in git.

The only difficulty I've seen with it, in hosting my own projects, is
interrupted pushes.  An interrupted push seems able to leave behind a
stale webdav lock, which has to be manually fixed.. but that's more of
a webdav with apache issue than anything else.  Beyond that, you just
need to ensure your permissions are correct, and set the config
parameter on the repositories to indicate that they're shared, and set
a hook script to executable so it can add metadata to the repo on
pushes.

Course, that said, I'd much rather see a git-daemon with push capability :)
-- 
Chris Larson - clarson at kergoth dot com
Dedicated Engineer - MontaVista - clarson at mvista dot com
Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus

Re: monotone/git (was hello...)

[Michael Krelin]

> 
> That's not correct.  You can push to a git repository over http/webdav
> to an apache2 server.
>

That's right, but I guess you also know of drawbacks of this method. To
mention one, having webdav *only* for push is somewhat strange, but
since at push time no hooks will be executed (which sucks by itself),
including update-server-info, the repository won't be quite
dumb-protocol-ready.

In short, your statement is theoretically correct, but the fact you
mentioned doesn't change anything.

I think I've heard about some patch providing push over git protocol,
which was dropped due to the lack of ssl connection support and there
were talks about reinstating it along with adding ssl support. But I
don't remember any details.

Love,
H

Re: monotone/git (was hello...)

[Michael Krelin]

> The only difficulty I've seen with it, in hosting my own projects, is
> interrupted pushes.  An interrupted push seems able to leave behind a
> stale webdav lock, which has to be manually fixed.. but that's more of
> a webdav with apache issue than anything else.  Beyond that, you just
> need to ensure your permissions are correct, and set the config
> parameter on the repositories to indicate that they're shared, and set
> a hook script to executable so it can add metadata to the repo on
> pushes.

Wait, how do you execute a hook when pushing via webdav?

> Course, that said, I'd much rather see a git-daemon with push capability :)

Agree on that ;-)

Love,
H

Re: monotone/git (was hello...)

[Chris Larson]

On 10/4/07, Michael Krelin <hacker@klever.net> wrote:
> > The only difficulty I've seen with it, in hosting my own projects, is
> > interrupted pushes.  An interrupted push seems able to leave behind a
> > stale webdav lock, which has to be manually fixed.. but that's more of
> > a webdav with apache issue than anything else.  Beyond that, you just
> > need to ensure your permissions are correct, and set the config
> > parameter on the repositories to indicate that they're shared, and set
> > a hook script to executable so it can add metadata to the repo on
> > pushes.
>
> Wait, how do you execute a hook when pushing via webdav?

post-update is executed in the remote repository when pushing to it.
In fact, the default post-update script in a new git init'd repository
is just a script that calls git-update-server-info, so all you have to
do is chmod +x foo.git/hooks/post-update and call it a day.  It works
just fine.
-- 
Chris Larson - clarson at kergoth dot com
Dedicated Engineer - MontaVista - clarson at mvista dot com
Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus

Re: monotone/git (was hello...)

[Chris Larson]

On 10/4/07, Michael Krelin <hacker@klever.net> wrote:
> >
> > That's not correct.  You can push to a git repository over http/webdav
> > to an apache2 server.
> >
>
> That's right, but I guess you also know of drawbacks of this method. To
> mention one, having webdav *only* for push is somewhat strange, but
> since at push time no hooks will be executed (which sucks by itself),
> including update-server-info, the repository won't be quite
> dumb-protocol-ready.

I think you're a bit behind :)  post-update works just fine for this,
and I'm not the only one using it on a daily basis.
-- 
Chris Larson - clarson at kergoth dot com
Dedicated Engineer - MontaVista - clarson at mvista dot com
Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus

Re: monotone/git (was hello...)

[Michael Krelin]

\>> Wait, how do you execute a hook when pushing via webdav?
> 
> post-update is executed in the remote repository when pushing to it.
> In fact, the default post-update script in a new git init'd repository
> is just a script that calls git-update-server-info, so all you have to
> do is chmod +x foo.git/hooks/post-update and call it a day.  It works
> just fine.

*Who* executes post-update script when you push to remote repository via
webdav?

Love,
H

Re: monotone/git (was hello...)

[Chris Larson]

On 10/4/07, Michael Krelin <hacker@klever.net> wrote:
> \>> Wait, how do you execute a hook when pushing via webdav?
> >
> > post-update is executed in the remote repository when pushing to it.
> > In fact, the default post-update script in a new git init'd repository
> > is just a script that calls git-update-server-info, so all you have to
> > do is chmod +x foo.git/hooks/post-update and call it a day.  It works
> > just fine.
>
> *Who* executes post-update script when you push to remote repository via
> webdav?

Sorry, my mistake on the mechanisms.  The hook is only used,
obviously, when pushing over ssh, since you can't run a script
remotely over http.  It's just that git-http-push is smart enough to
update the remote info/* if the files already exist (run
git-update-server-info on the remote side once).
-- 
Chris Larson - clarson at kergoth dot com
Dedicated Engineer - MontaVista - clarson at mvista dot com
Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus

Re: monotone/git (was hello...)

[Michael Krelin]

>> \>> Wait, how do you execute a hook when pushing via webdav?
>>> post-update is executed in the remote repository when pushing to it.
>>> In fact, the default post-update script in a new git init'd repository
>>> is just a script that calls git-update-server-info, so all you have to
>>> do is chmod +x foo.git/hooks/post-update and call it a day.  It works
>>> just fine.
>> *Who* executes post-update script when you push to remote repository via
>> webdav?
> 
> Sorry, my mistake on the mechanisms.  The hook is only used,
> obviously, when pushing over ssh, since you can't run a script
> remotely over http.  It's just that git-http-push is smart enough to
> update the remote info/* if the files already exist (run
> git-update-server-info on the remote side once).

Good for the record, after we sorted it out on IRC. So, yes, it's 
theoretically possible, we'd all want to avoid it and I have no idea 
about its performance, which would probably need more elaborate 
research. I doubt, though, that onyone wants to conduct such a research 
at the moment ;-)

Love,
H

oe for two target boards at the same time

[Alex]

Hi all

How do I setup my directory structure to use oe for two target boards.

I have an AVR32 board and an AT91 board and would like to use oe for 
both of them with at less dublicated software as possible.

Thanks

Alex

Re: oe for two target boards at the same time

[Cliff Brake]

On 10/5/07, Alex <mailinglist@miromico.ch> wrote:
> Hi all
>
> How do I setup my directory structure to use oe for two target boards.
>
> I have an AVR32 board and an AT91 board and would like to use oe for
> both of them with at less dublicated software as possible.

As these are different architectures, I don't think you can use
multimachine.  What I typically do is just set up a system where I
share a common overlay (bbcollections), the openembedded directory,
and downloads directory.  The nslu2 master makefile what I started
with, but there are other ways.  Soft links are used to link the
common directories.  EG:

  openembedded
  openembedded.custom (bb collections overlay)
  bitbake
  downloads
  projectA
       openembedded.custom -> ../openembedded.custom
       openembedded -> ../openembedded
       bitbake -> ../bitbake
       downloads -> ../downloads
       tmp
       conf
  projectB
       openembedded.custom -> ../openembedded.custom
       openembedded -> ../openembedded
       bitbake -> ../bitbake
       downloads -> ../downloads
       tmp
       conf

I'd be interested in hearing how others set up their build directory.

Thanks,
Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com

Re: oe for two target boards at the same time

[Khem Raj]

I generally use a separate tmp directory for each machine and common
sources. This has worked well for me so far.

-Khem

On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote:
> On 10/5/07, Alex <mailinglist@miromico.ch> wrote:
> > Hi all
> >
> > How do I setup my directory structure to use oe for two target boards.
> >
> > I have an AVR32 board and an AT91 board and would like to use oe for
> > both of them with at less dublicated software as possible.
>
> As these are different architectures, I don't think you can use
> multimachine.  What I typically do is just set up a system where I
> share a common overlay (bbcollections), the openembedded directory,
> and downloads directory.  The nslu2 master makefile what I started
> with, but there are other ways.  Soft links are used to link the
> common directories.  EG:
>
>   openembedded
>   openembedded.custom (bb collections overlay)
>   bitbake
>   downloads
>   projectA
>        openembedded.custom -> ../openembedded.custom
>        openembedded -> ../openembedded
>        bitbake -> ../bitbake
>        downloads -> ../downloads
>        tmp
>        conf
>   projectB
>        openembedded.custom -> ../openembedded.custom
>        openembedded -> ../openembedded
>        bitbake -> ../bitbake
>        downloads -> ../downloads
>        tmp
>        conf
>
> I'd be interested in hearing how others set up their build directory.
>
> Thanks,
> Cliff
>
> --
> =======================
> Cliff Brake
> http://bec-systems.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: oe for two target boards at the same time

[Koen Kooi]

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

Cliff Brake schreef:
> On 10/5/07, Alex <mailinglist@miromico.ch> wrote:
>> Hi all
>>
>> How do I setup my directory structure to use oe for two target boards.
>>
>> I have an AVR32 board and an AT91 board and would like to use oe for
>> both of them with at less dublicated software as possible.
> 
> As these are different architectures, I don't think you can use
> multimachine. 

Multimachine works fine for things like that, except that we are *still* waiting for an OK
to merge the avr32 stuff into .dev

regards,

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

iD8DBQFHB0UbMkyGM64RGpERAgalAJ4j+ouRvC4msp8DZImB06lYyqvJtgCbBBEe
gVcJQX+e3nHCHBA2dQ0xfOY=
=qvpO
-----END PGP SIGNATURE-----

Re: oe for two target boards at the same time

[Marcin Juszkiewicz]

Dnia piątek, 5 października 2007, Cliff Brake napisał:
> On 10/5/07, Alex <mailinglist@miromico.ch> wrote:

> > How do I setup my directory structure to use oe for two target
> > boards.

> > I have an AVR32 board and an AT91 board and would like to use oe for
> > both of them with at less dublicated software as possible.

> As these are different architectures, I don't think you can use
> multimachine.

You can use multimachine even when TARGET_ARCH differ - only *-native 
utils will be the same - all cross tools will be built for both targets.

> What I typically do is just set up a system where I share a common
> overlay (bbcollections), the openembedded directory, 
> and downloads directory.

> I'd be interested in hearing how others set up their build directory.

http://blog.haerwu.biz/2006/11/22/my-openembedded-environment-ii/ is how I 
have it configured.

Re: oe for two target boards at the same time

[Cliff Brake]

On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote:
> On 10/5/07, Alex <mailinglist@miromico.ch> wrote:
> > Hi all
> >
> > How do I setup my directory structure to use oe for two target boards.
> >
> > I have an AVR32 board and an AT91 board and would like to use oe for
> > both of them with at less dublicated software as possible.

> I'd be interested in hearing how others set up their build directory.

After studying Marcin's build setup, and Koen's autobuilder script,
I've come up with the following which is very similiar to Marcin's
setup.  My needs are:

- track several machines and distros, and possibly in the future
different OE trees, etc
- easily to automatically produce time-stamped snapshot builds (not done yet)
- easy for me to replicate on other machines
- easy for customers to replicate on other machines

With the multimachine, you typically need one build directory per
distro, so the following is what I ended up with:

|-- Makefile
`-- oe
|    `-- custom (bbcollections overlay)
|    `-- org.openembedded.dev
`-- bitbake
`-- downloads
`-- build
    |-- angstrom-2007.1
    |   `-- conf
    |       |-- local.conf
    |       |-- auto.conf
    |       `-- site.conf -> ../../conf/site.conf
    |-- angstrom-2008.1
    |   `-- conf
    |       |-- local.conf
    |       |-- auto.conf
    |       `-- site.conf -> ../../conf/site.conf
    |-- conf
    |   `-- site.conf
    `-- openmoko
        `-- conf
            |-- local.conf
            |-- auto.conf
            `-- site.conf -> ../../conf/site.conf


There is a common site.conf file that contains settings for my build
machine.  local.conf contains the DISTRO variable, and thats about it.
 auto.conf contains MACHINE and uclibc settings and is changed between
builds.

The downside of multimachine is you need to reparse the OE directory
every time you change machine, but the benefit of sharing tmp
directories for a bunch of machines in a distro more than makes up for
that.

Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com

Re: oe for two target boards at the same time

[Koen Kooi]

Quoting Cliff Brake <cliff.brake@gmail.com>:

> On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote:
> > On 10/5/07, Alex <mailinglist@miromico.ch> wrote:
> > > Hi all
> > >
> > > How do I setup my directory structure to use oe for two target boards.
> > >
> > > I have an AVR32 board and an AT91 board and would like to use oe for
> > > both of them with at less dublicated software as possible.
>
> > I'd be interested in hearing how others set up their build directory.
>
> After studying Marcin's build setup, and Koen's autobuilder script,
> I've come up with the following which is very similiar to Marcin's
> setup.  My needs are:
>
> - track several machines and distros, and possibly in the future
> different OE trees, etc
> - easily to automatically produce time-stamped snapshot builds (not done yet)
> - easy for me to replicate on other machines
> - easy for customers to replicate on other machines
>
> With the multimachine, you typically need one build directory per
> distro, so the following is what I ended up with:

If you only need to build one distro version you can do:

TMPDIR = "/build/tmp/${DISTRO}"

in local.conf


> The downside of multimachine is you need to reparse the OE directory
> every time you change machine, but the benefit of sharing tmp
> directories for a bunch of machines in a distro more than makes up for
> that.

If you already built binutils you can remove MACHINE=<foo> from conf files and
set it in env, e.g. :

MACHINE=c7x0 bitbake mono ; MACHINE=fic-gta01 bitbake mono

that saves you a complete reparse.

regards,

Koen




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: oe for two target boards at the same time

[pHilipp Zabel]

On 10/9/07, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> Quoting Cliff Brake <cliff.brake@gmail.com>:
>
> > On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote:
> > > On 10/5/07, Alex <mailinglist@miromico.ch> wrote:
> > > > Hi all
> > > >
> > > > How do I setup my directory structure to use oe for two target boards.
> > > >
> > > > I have an AVR32 board and an AT91 board and would like to use oe for
> > > > both of them with at less dublicated software as possible.
> >
> > > I'd be interested in hearing how others set up their build directory.
> >
> > After studying Marcin's build setup, and Koen's autobuilder script,
> > I've come up with the following which is very similiar to Marcin's
> > setup.  My needs are:
> >
> > - track several machines and distros, and possibly in the future
> > different OE trees, etc
> > - easily to automatically produce time-stamped snapshot builds (not done yet)
> > - easy for me to replicate on other machines
> > - easy for customers to replicate on other machines
> >
> > With the multimachine, you typically need one build directory per
> > distro, so the following is what I ended up with:
>
> If you only need to build one distro version you can do:
>
> TMPDIR = "/build/tmp/${DISTRO}"
>
> in local.conf
>
>
> > The downside of multimachine is you need to reparse the OE directory
> > every time you change machine, but the benefit of sharing tmp
> > directories for a bunch of machines in a distro more than makes up for
> > that.
>
> If you already built binutils you can remove MACHINE=<foo> from conf files and
> set it in env, e.g. :
>
> MACHINE=c7x0 bitbake mono ; MACHINE=fic-gta01 bitbake mono
>
> that saves you a complete reparse.

Isn't the binutils MACHINE environment variable issue fixed by now?
I only just noticed that I don't know because I have MACHINE?=magician
somewhere and always seem to do the first build without the MACHINE
envvar set...

regards
Philipp

Re: oe for two target boards at the same time

[Richard Purdie]

On Tue, 2007-10-09 at 11:02 +0200, pHilipp Zabel wrote:
> On 10/9/07, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> > If you already built binutils you can remove MACHINE=<foo> from conf files and
> > set it in env, e.g. :
> >
> > MACHINE=c7x0 bitbake mono ; MACHINE=fic-gta01 bitbake mono
> >
> > that saves you a complete reparse.
> 
> Isn't the binutils MACHINE environment variable issue fixed by now?
> I only just noticed that I don't know because I have MACHINE?=magician
> somewhere and always seem to do the first build without the MACHINE
> envvar set...

The issue should be fixed. I regularly make builds with a MACHINE ?=
entry but with MACHINE set in the environment too and it all seems to
work.

People keep telling me there is a problem but I've not seen any
reproducible test case...

Cheers,

Richard

Re: oe for two target boards at the same time

[Graeme Gregory]

On Tue, 09 Oct 2007 12:36:22 +0200
Richard Purdie <rpurdie@rpsys.net> wrote:
> The issue should be fixed. I regularly make builds with a MACHINE ?=
> entry but with MACHINE set in the environment too and it all seems to
> work.
> 
> People keep telling me there is a problem but I've not seen any
> reproducible test case...
> 

NOTE: package binutils-cross-2.18-r0: task do_populate_staging:
completed

looks fixed to me, I never used to be able to do this.

Graeme

Re: oe for two target boards at the same time

[Graeme Gregory]

On Tue, 9 Oct 2007 13:18:12 +0200
Graeme Gregory <dp@xora.org.uk> wrote:

> On Tue, 09 Oct 2007 12:36:22 +0200
> Richard Purdie <rpurdie@rpsys.net> wrote:
> > The issue should be fixed. I regularly make builds with a MACHINE ?=
> > entry but with MACHINE set in the environment too and it all seems
> > to work.
> > 
> > People keep telling me there is a problem but I've not seen any
> > reproducible test case...
> > 
> 
> NOTE: package binutils-cross-2.18-r0: task do_populate_staging:
> completed
> 
> looks fixed to me, I never used to be able to do this.
> 
Spoke too soon

checking for libc-friendly stddef.h... yes
checking whether we need to use -P to assemble .S files... no
checking whether .text pseudo-op must be used... yes
checking for assembler global-symbol directive... .globl
checking for .set assembler directive... no
checking for assembler .type directive prefix... %
checking for .symver assembler directive... yes
checking for ld --version-script... no
*** WARNING: You should not compile GNU libc without versioning. Not
using *** versioning will introduce incompatibilities so that old
binaries *** will not run anymore.
*** For versioning you need recent binutils (binutils-2.8.1.0.23 or
newer). checking for .previous assembler directive... yes
checking for .protected and .hidden assembler directive... yes
checking whether __attribute__((visibility())) is supported... yes
checking for broken __attribute__((visibility()))... no
checking for broken __attribute__((alias()))... no
checking whether to put _rtld_local into .sdata section... no
checking for arm-angstrom-linux-gnueabi-readelf...
arm-angstrom-linux-gnueabi-re adelf
checking for .preinit_array/.init_array/.fini_array support... no
configure: error: Need linker with .init_array/.fini_array support.
FATAL: oe_runconf failed

This is what happens if MACHINE=spitz bitbake angstrom-devel-image

Graeme

Re: oe for two target boards at the same time

[Paul Sokolovsky]

Hello Cliff,

Monday, October 8, 2007, 11:20:14 PM, you wrote:

> On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote:
>> On 10/5/07, Alex <mailinglist@miromico.ch> wrote:
>> > Hi all
>> >
>> > How do I setup my directory structure to use oe for two target boards.
>> >
>> > I have an AVR32 board and an AT91 board and would like to use oe for
>> > both of them with at less dublicated software as possible.

>> I'd be interested in hearing how others set up their build directory.

> After studying Marcin's build setup, and Koen's autobuilder script,

  Is there a reason why this script is not in contrib/ in OE tree?

[]

> - easily to automatically produce time-stamped snapshot builds (not done yet)

  I wonder if someone would ever bother to produce *revision*-stamped
snapshots. Well, actually I wonder if in one sweet day in distant
years OE would have that as default. Because it's of course the only
reasonable way to ensure QAbility of snapshots. Yep, mtn's revisions
are ugly, but that's price of "distributed SCM" magic, right? Plus,
they can be trimmed to sane length.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: oe for two target boards at the same time

[Paul Sokolovsky]

Hello Richard,

Tuesday, October 9, 2007, 1:36:22 PM, you wrote:

> On Tue, 2007-10-09 at 11:02 +0200, pHilipp Zabel wrote:
>> On 10/9/07, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>> > If you already built binutils you can remove MACHINE=<foo> from conf files and
>> > set it in env, e.g. :
>> >
>> > MACHINE=c7x0 bitbake mono ; MACHINE=fic-gta01 bitbake mono
>> >
>> > that saves you a complete reparse.
>> 
>> Isn't the binutils MACHINE environment variable issue fixed by now?
>> I only just noticed that I don't know because I have MACHINE?=magician
>> somewhere and always seem to do the first build without the MACHINE
>> envvar set...

> The issue should be fixed. I regularly make builds with a MACHINE ?=
> entry but with MACHINE set in the environment too and it all seems to
> work.

> People keep telling me there is a problem but I've not seen any
> reproducible test case...

  Thanks for bringing this up. Not yet, not yet. Following patch was
produced to fix another manifestation of the issue, hopefully forever:

Index: lib/bb/data.py
===================================================================
--- lib/bb/data.py      (revision 974)
+++ lib/bb/data.py      (working copy)
@@ -370,18 +370,19 @@
     if type(val) is not types.StringType:
         return 0
 
-    if getVarFlag(var, 'matchesenv', d):
-        return 0
-
     if (var.find("-") != -1 or var.find(".") != -1 or var.find('{') != -1 or var.find('}') != -1 or var.find('+') != -1) and not all:
         return 0
 
     varExpanded = expand(var, d)
 
+    # Unexporting is the highest priority
     if unexport:
         o.write('unset %s\n' % varExpanded)
         return 1
 
+    if getVarFlag(var, 'matchesenv', d):
+        return 0
+
     val.rstrip()
     if not val:
         return 0


  The idea is simple: if a var is marked as unexported, then it should
be unset unconditionally regardless of any other circumstances ;-).

  So, I hit this issue on a RedHat-based system (FC5). Otherwise, it
seemed to have worked on Debian/Gentoo systems.

> Cheers,

> Richard


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com