any ETA on a working dev beagleboard demo image?

any ETA on a working dev beagleboard demo image?

[Robert P. J. Day]

  yes, i know i'm sounding like a broken record, but i have an invite
to give a short local demo of the beagleboard this tuesday and i'd
like to do it with an angstrom development demo image, just because i
prefer to live out there on the edge.

  at the moment, there is just the one package standing in the way --
guile-native -- and as i recall, someone posted what looked like a
manual fix.  is that being turned into a patch at any point?  i
realize i'm nagging, but it's literally been *weeks* since that
particular bitbake target actually built, and every time it looks like
it's getting close to being buildable, more packages break.

  i appreciate that development means exactly that but, at the very
least, even the development branch should *build*, even if there are
run issues.

rday

p.s.  perhaps it would be useful to start tagging the development
branch at points where it builds, just so someone can always retreat
to the most recent known good build.

or perhaps start a branch named, oh, "bleeding", which, when it builds
properly, can be merged back into development.  whatever.  but it
strikes me that it's overwhelmingly pointless to have a development
branch that doesn't build since that gives no one the opportunity to
actually test it.

--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: any ETA on a working dev beagleboard demo image?

[Marcin Juszkiewicz]

Dnia niedziela, 15 listopada 2009 o 15:56:36 Robert P. J. Day napisał(a):

>   yes, i know i'm sounding like a broken record, but i have an invite
> to give a short local demo of the beagleboard this tuesday and i'd
> like to do it with an angstrom development demo image, just because i
> prefer to live out there on the edge.

You can always move back to some revision before recent changes happened, you 
can use Angstrom narcissus to generate working image.
 
>   at the moment, there is just the one package standing in the way --
> guile-native -- and as i recall, someone posted what looked like a
> manual fix.  is that being turned into a patch at any point?  

Did you tried to make it a patch? Patches are always welcome.

> i realize i'm nagging, but it's literally been *weeks* since that
> particular bitbake target actually built, and every time it looks like
> it's getting close to being buildable, more packages break.

Maybe start tagging your copy of OE to know which version was buildable for 
you? It will make life easier to make 'git bisect' to find out what broke it.

> i appreciate that development means exactly that but, at the very
> least, even the development branch should *build*, even if there are
> run issues.

No, it is not 'org.openembedded.always-building' branch. This is development 
branch where everything can happen. At OEDEM it was decided that many core 
changes will be made and we accepted some breakage during that time. We are 
working on making it buildable again but testing takes time.
 
> p.s.  perhaps it would be useful to start tagging the development
> branch at points where it builds, just so someone can always retreat
> to the most recent known good build.

"where it builds" is not a definition. For me one revision builds for 
at91sam9263ek/x11-image target but not for progear/xfce-image for example. Or 
build on my Debian system but breaks in Ubuntu 9.04 virtual. There is no such 
thing as 'it builds for everyone' and you should know that from your xterm-207 
problem which was not a problem for me (as it was building under my Debian and 
I do not have a client who would use Fedora for builds).
 
> or perhaps start a branch named, oh, "bleeding", which, when it builds
> properly, can be merged back into development.  whatever.  but it
> strikes me that it's overwhelmingly pointless to have a development
> branch that doesn't build since that gives no one the opportunity to
> actually test it.

There is a tag on .dev branch which marks moment before OE core changes 
landed: "pre-nov2009-core-updates" - maybe checkout that version and just 
cherry-pick those updates which are needed to make OE buildable for you?

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: any ETA on a working dev beagleboard demo image?

[John (GMail)]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Robert P. J. Day
> Sent: Sunday, November 15, 2009 6:57 AM
> To: OpenEmbedded Development mailing list
> Subject: [oe] any ETA on a working dev beagleboard demo image?
> 
> 
>   yes, i know i'm sounding like a broken record, but i have an invite
> to give a short local demo of the beagleboard this tuesday and i'd
> like to do it with an angstrom development demo image, just because i
> prefer to live out there on the edge.
> 
>   at the moment, there is just the one package standing in the way --
> guile-native -- and as i recall, someone posted what looked like a
> manual fix.  is that being turned into a patch at any point?  i
> realize i'm nagging, but it's literally been *weeks* since that
> particular bitbake target actually built, and every time it looks like
> it's getting close to being buildable, more packages break.
> 
>   i appreciate that development means exactly that but, at the very
> least, even the development branch should *build*, even if there are
> run issues.
I also had problems building the DEV branch, but as of yesterday,
beagleboard-demo-image builds without errors on Ubuntu 9.10. I was having
problems with webkit-gtk, but Koen released a fix on Saturday and now the
build completes successfully.
> 
> rday
> 
> p.s.  perhaps it would be useful to start tagging the development
> branch at points where it builds, just so someone can always retreat
> to the most recent known good build.
> 
> or perhaps start a branch named, oh, "bleeding", which, when it builds
> properly, can be merged back into development.  whatever.  but it
> strikes me that it's overwhelmingly pointless to have a development
> branch that doesn't build since that gives no one the opportunity to
> actually test it.
> 
> --
> 
> =============================================================
> ===========
> Robert P. J. Day                               Waterloo, Ontario, CANADA
> 
>             Linux Consulting, Training and Kernel Pedantry.
> 
> Web page:                                          http://crashcourse.ca
> Twitter:                                       http://twitter.com/rpjday
> =============================================================
> ===========
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: any ETA on a working dev beagleboard demo image?

[John (GMail)]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Marcin Juszkiewicz
> Sent: Sunday, November 15, 2009 4:01 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] any ETA on a working dev beagleboard demo image?
> 
> Dnia niedziela, 15 listopada 2009 o 15:56:36 Robert P. J. Day napisał(a):
> 
> >   yes, i know i'm sounding like a broken record, but i have an invite
> > to give a short local demo of the beagleboard this tuesday and i'd
> > like to do it with an angstrom development demo image, just because i
> > prefer to live out there on the edge.
> 
> You can always move back to some revision before recent changes happened,
> you
> can use Angstrom narcissus to generate working image.
I can confirm that beagleboard-demo-image builds successfully on both the DEV and the Stable branches using Ubuntu 9.10 x64. My last build was based on SHA1 ID: 916ed3c
> 
> >   at the moment, there is just the one package standing in the way --
> > guile-native -- and as i recall, someone posted what looked like a
> > manual fix.  is that being turned into a patch at any point?
> 
> Did you tried to make it a patch? Patches are always welcome.
> 
> > i realize i'm nagging, but it's literally been *weeks* since that
> > particular bitbake target actually built, and every time it looks like
> > it's getting close to being buildable, more packages break.
> 
> Maybe start tagging your copy of OE to know which version was buildable for
> you? It will make life easier to make 'git bisect' to find out what broke it.
> 
> > i appreciate that development means exactly that but, at the very
> > least, even the development branch should *build*, even if there are
> > run issues.
> 
> No, it is not 'org.openembedded.always-building' branch. This is development
> branch where everything can happen. At OEDEM it was decided that many core
> changes will be made and we accepted some breakage during that time. We are
> working on making it buildable again but testing takes time.
> 
> > p.s.  perhaps it would be useful to start tagging the development
> > branch at points where it builds, just so someone can always retreat
> > to the most recent known good build.
> 
> "where it builds" is not a definition. For me one revision builds for
> at91sam9263ek/x11-image target but not for progear/xfce-image for example. Or
> build on my Debian system but breaks in Ubuntu 9.04 virtual. There is no such
> thing as 'it builds for everyone' and you should know that from your xterm-207
> problem which was not a problem for me (as it was building under my Debian and
> I do not have a client who would use Fedora for builds).
> 
> > or perhaps start a branch named, oh, "bleeding", which, when it builds
> > properly, can be merged back into development.  whatever.  but it
> > strikes me that it's overwhelmingly pointless to have a development
> > branch that doesn't build since that gives no one the opportunity to
> > actually test it.
> 
> There is a tag on .dev branch which marks moment before OE core changes
> landed: "pre-nov2009-core-updates" - maybe checkout that version and just
> cherry-pick those updates which are needed to make OE buildable for you?
> 
> Regards,
> --
> JID:      hrw@jabber.org
> Website:  http://marcin.juszkiewicz.com.pl/
> LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: any ETA on a working dev beagleboard demo image?

[Petr Štetiar]

Robert P. J. Day <rpjday@crashcourse.ca> [2009-11-15 09:56:36]:

> or perhaps start a branch named, oh, "bleeding", which, when it builds
> properly, can be merged back into development.  whatever.  but it
> strikes me that it's overwhelmingly pointless to have a development
> branch that doesn't build since that gives no one the opportunity to
> actually test it.

Bleeding = dev, for me at least.

I had problems with building dev on Ubuntu 8.10(some weird host setup, like
gcc and includes) so I upgraded to 9.04 and I can build beagleboard-demo-image
again. Last time I tried it was yesterday.

-- ynezz

Re: any ETA on a working dev beagleboard demo image?

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3161 bytes --]

On Mon, 16 Nov 2009, Marcin Juszkiewicz wrote:

> Dnia niedziela, 15 listopada 2009 o 15:56:36 Robert P. J. Day napisał(a):
>
> >   yes, i know i'm sounding like a broken record, but i have an
> > invite to give a short local demo of the beagleboard this tuesday
> > and i'd like to do it with an angstrom development demo image,
> > just because i prefer to live out there on the edge.
>
> You can always move back to some revision before recent changes
> happened, ...

  except that i've been trying to build a beagleboard-demo-image from
the dev branch for the last few *weeks* and have yet to have a single
successful build.  i'd be *happy* to tag a working build if i ever get
one.

> > i appreciate that development means exactly that but, at the very
> > least, even the development branch should *build*, even if there
> > are run issues.
>
> No, it is not 'org.openembedded.always-building' branch. This is
> development branch where everything can happen. At OEDEM it was
> decided that many core changes will be made and we accepted some
> breakage during that time. We are working on making it buildable
> again but testing takes time.

  and therein lies the conflict -- if the branch can't even be
*built*, it can't possibly be *tested*.  of course development
branches are going to break on occasion, everyone knows that.  but it
seems that, if the build itself fails, the first priority is to fix
that.  otherwise, if you leave it broken and keep developing, all
you're doing is layering more unknown code on top of something that
doesn't even build (at least for some people).  and you're explicitly
removing the ability to test from people that are willing to do that.
that strikes me as counter-productive.

  it's particularly counter-productive when it's nothing more than a
single package that's causing the problem.

> "where it builds" is not a definition. For me one revision builds
> for at91sam9263ek/x11-image target but not for progear/xfce-image
> for example. Or build on my Debian system but breaks in Ubuntu 9.04
> virtual. There is no such thing as 'it builds for everyone' and you
> should know that from your xterm-207 problem which was not a problem
> for me (as it was building under my Debian and I do not have a
> client who would use Fedora for builds).

  IMHO, the fact that you don't know anyone who uses a fedora build
host is not a compelling reason to ignore build breakage that happens
on a fedora build host.

  in any event, that's my $0.02.  build breakage is one thing.  but
breakage that's lasted for as long as i've been trying to build --
even on a development branch -- strikes me as a bad thing.

rday
--


========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: any ETA on a working dev beagleboard demo image?

[Phil Blundell]

On Mon, 2009-11-16 at 04:05 -0500, Robert P. J. Day wrote:
>   IMHO, the fact that you don't know anyone who uses a fedora build
> host is not a compelling reason to ignore build breakage that happens
> on a fedora build host.

That's true, but not having access to a host where the problem occurs
does make it much harder to do anything about it.

If you have a patch for the guile-native failure then I'm sure someone
can check it in.  But, otherwise, it is going to be a case of waiting
for someone with a suitable build host to investigate and debug whatever
is going wrong.  If this is blocking you from doing other work then you
could consider using ASSUME_PROVIDED, or not building whatever it is
that depends on guile-native, or building on a different host system.

p.

Re: any ETA on a working dev beagleboard demo image?

[Robert P. J. Day]

On Mon, 16 Nov 2009, Phil Blundell wrote:

> On Mon, 2009-11-16 at 04:05 -0500, Robert P. J. Day wrote:
> >   IMHO, the fact that you don't know anyone who uses a fedora
> > build host is not a compelling reason to ignore build breakage
> > that happens on a fedora build host.
>
> That's true, but not having access to a host where the problem
> occurs does make it much harder to do anything about it.

  which is why i'm more than happy to do that testing on my f12 beta
system, then report back with the relevant results.  and, AFAICT,
those reports have resulted in a couple subtle build issues being
fixed, at least for certain distros.

  i apologize for making such a big deal out of this, i didn't intend
to incite such a sh*tstrom, but here's the thing.  i've been told that
OE is most emphatically a "community" project.  of course it is -- i
understand that.  and i, as a long-time fedora user, am trying to
*contribute* to that community.  which is why i'm willing to check out
the dev branch, and keep it up to date, and burn off cycles trying to
build it on a regular basis, and report on build breakage and even try
to research that breakage to figure out what the problem might be and
how to fix it.

  i only wish i had the OE background to be able to debug and submit
patches for that breakage -- don't have it yet, but i'm working on it.
until then, i have to depend on the good graces of other OE folks to
help out.  but simply saying that, "hey, it builds on *my* distro, you
should use that distro" disqualifies a fairly huge part of a potential
community -- those folks that use fedora.

  and i'm willing to test as well, but i can't do that until i can
build -- it's as simple as that.  so, for now, the best i can do is
just keep running the stable version of angstrom on my beagleboard,
but keep pulling and trying to build until i get a working build which
i can use as a benchmark for future builds.  i just need to get there
first.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: any ETA on a working dev beagleboard demo image?

[Leon Woestenberg]

Hello,

On Mon, Nov 16, 2009 at 11:53 AM, Robert P. J. Day
<rpjday@crashcourse.ca> wrote:
> On Mon, 16 Nov 2009, Phil Blundell wrote:
>> On Mon, 2009-11-16 at 04:05 -0500, Robert P. J. Day wrote:
>> >   IMHO, the fact that you don't know anyone who uses a fedora
>> > build host is not a compelling reason to ignore build breakage
>> > that happens on a fedora build host.
>>

There has been talk about automated build tests (in fact, I have used
nightly builds to find regressions but no longer have the hardware
available to me).

I think it would be good to generate a set of "well-known good
building combo's" that build from scratch.

Which keys should be in there? I think: host system (uname output?),
target (MACHINE), bitbake target (image name), OE .dev revision (git
commit)

What can we extract from the tinderbox database?

Should we modify the oe-stats class so that we collect this
information automatically?

Maybe detect that the user is building from scratch (i.e. no
destination directory exists yet)

Regards,
-- 
Leon