why is the OE dev branch such an unreliable piece of %^*&@#$*&^$??

i realize i'm going to antagonize all the wrong people with this
post but i've simply run out of patience with the monstrously
unreliable and broken piece of junk that is the OE development branch
when it comes to building for the beagleboard.

  as most people here have probably noticed, i like to work off of the
OE dev branch and bitbake the beagleboard-demo-image for testing
purposes. having tried this for the last quite some time, i can
safely say that i've managed to even get a successful *build* less
than 10 per cent of the time on my 64-bit ubuntu 10.04 system.

  there is *inevitably* some package that won't build, and those
packages keep changing. first it was firefox and abiword. then
firefox was fixed but abiword was still broken. then abiword was
miraculously repaired but firefox went back to being broken. this
went on for ***weeks***.

  and now? now both firefox and abiword build, but gnash won't
compile. and what i hear is, "well, it builds on *my* system." well,
good for you. but i can't believe that the current 64-bit release of
ubuntu is such a fringe distro that it can be ignored as a data point.
that's just ridiculous.

  i pull the OE dev branch and try a build at *least* once a day, and
i notice that there's quite a lot of development going on, *except*
when it comes to fixing known breakage, which is an absurd situation.
obviously, a development branch is going to be unreliable. that's
pretty much *by definition*. but breakage should be the *exception*,
not the *norm*. if i can't even build, i certainly can't do any
testing.

  i have to ask, is no one else seeing this? is absolutely no one
else running 64-bit ubuntu (and, yes, the 64-bit part is important
since i'm seeing errors that 32-bit versions don't see).

  the current situation is ridiculous. even on a development branch,
there should be a minimum level of testing and quality control so that
the branch at least *builds*. and i'll ask again, is no one else
running 64-bit ubuntu and seeing these build problems for the dev
branch?

  and, finally, after having vented, if this is something i've done in
terms of screwing up my build environment, i will of course apologize
profusely. but i've been fighting with this situation for months now
and i'm really, really tired of it. i want to test the dev branch on
my beagleboard. and i can't. and i'm tired of having to edit the
task or recipe files to exclude packages just to get a build.

  why is this such a perpetual state of affairs?

rday

2010/7/28 Robert P. J. Day <rpjday@crashcourse.ca>

i realize i’m going to antagonize all the wrong people with this
post but i’ve simply run out of patience with the monstrously
unreliable and broken piece of junk that is the OE development branch
when it comes to building for the beagleboard.

as most people here have probably noticed, i like to work off of the
OE dev branch and bitbake the beagleboard-demo-image for testing
purposes. having tried this for the last quite some time, i can
safely say that i’ve managed to even get a successful build less
than 10 per cent of the time on my 64-bit ubuntu 10.04 system.

there is inevitably some package that won’t build, and those
packages keep changing. first it was firefox and abiword. then
firefox was fixed but abiword was still broken. then abiword was
miraculously repaired but firefox went back to being broken. this
went on for weeks.

and now? now both firefox and abiword build, but gnash won’t
compile. and what i hear is, “well, it builds on my system.” well,
good for you. but i can’t believe that the current 64-bit release of
ubuntu is such a fringe distro that it can be ignored as a data point.
that’s just ridiculous.

i pull the OE dev branch and try a build at least once a day, and
i notice that there’s quite a lot of development going on, except
when it comes to fixing known breakage, which is an absurd situation.
obviously, a development branch is going to be unreliable. that’s
pretty much by definition. but breakage should be the exception,
not the norm. if i can’t even build, i certainly can’t do any
testing.

i have to ask, is no one else seeing this? is absolutely no one
else running 64-bit ubuntu (and, yes, the 64-bit part is important
since i’m seeing errors that 32-bit versions don’t see).

the current situation is ridiculous. even on a development branch,
there should be a minimum level of testing and quality control so that
the branch at least builds. and i’ll ask again, is no one else
running 64-bit ubuntu and seeing these build problems for the dev
branch?

and, finally, after having vented, if this is something i’ve done in
terms of screwing up my build environment, i will of course apologize
profusely. but i’ve been fighting with this situation for months now
and i’m really, really tired of it. i want to test the dev branch on
my beagleboard. and i can’t. and i’m tired of having to edit the
task or recipe files to exclude packages just to get a build.

why is this such a perpetual state of affairs?

Robert,

Cool down. Take a deep breath. Take a cold shower. Have a beer (or whatever). Relax.

General remark:
dev head == bleeding edge, so yes on occasions it does bleed. That is the risk of living on the edge.
(and yes: there is tension between “commit early; commit often” as practised by some and quality).

Wrt your specific problem.
I’m building openembedded on 64 bit ubuntu at work (but not gnash, we do headless embedded systems (the real embedded work)).
No issues there.
At home I sometimes build for beagle but that is opensuse 11.2 with pae, (D920 core) so that does not bring much either.

What you could do is:

  • analyse the problem and fix it (which is the preferred scenario as far as the community is concerned)
  • bother the owner of the recipe (whoever it is, but git can tell you who the people are that created it and who recently touched it
  • stalk you distro and trick them into fixing it
  • move to a differnt distro (if distro is the problem)
  • use a stable branch
  • move to e.g. debian

Have fun!
Frans

... my earlier venting snipped for brevity ...

Robert,

Cool down. Take a deep breath. Take a cold shower. Have a beer (or
whatever). Relax.

  always good advice. except for the cold shower part. :slight_smile:

General remark: dev head == bleeding edge, so yes on occasions it
does bleed. That is the risk of living on the edge. (and yes: there
is tension between "commit early; commit often" as practised by some
and quality).

  that's not quite the issue here, though. as i pointed out, yes, a
development branch is bleeding edge by definition. but even a dev
branch should have some level of quality control. and, IMHO, an
absolutely minimum level of QA would be to verify that the current
state of the branch *builds*. doesn't need to run properly, just
needs to build.

  on occasion, i've overseen the svn checkins on a software project,
and i had one cardinal rule -- you never, ever, ever commit something
that breaks the build. period. when that happened, i simply reverted
the commit and chewed out the person responsible. after a while,
everyone learned.

  and, as i said, what's particularly grating is that no sooner is one
package build fixed than another one breaks.

Wrt your specific problem. I'm building openembedded on 64 bit
ubuntu at work (but not gnash, we do headless embedded systems (the
real embedded work)). No issues there.

  sure, of course something like beagleboard-demo-image isn't
realistic for an actual production-level system. on the other hand,
it's a terrific stress test, which is what i'm using it for. so i
completely understand that most people won't run into these issues.

At home I sometimes build for beagle but that is opensuse 11.2 with
pae, (D920 core) so that does not bring much either.

  and i openly admitted that lots of folks *aren't* seeing these build
errors. my point there was that 64-bit ubuntu is a popular enough
distro that it should be considered a critical data point in the QA
cycle. if it doesn't build on my distro, that should be a red flag.

What you could do is:
- analyse the problem and fix it (which is the preferred scenario as far as the
community is concerned)
- bother the owner of the recipe (whoever it is, but git can tell you who the
people are that created it and who recently touched it
- stalk you distro and trick them into fixing it
- move to a differnt distro (if distro is the problem)
- use a stable branch
- move to e.g. debian

Have fun!
Frans

  and all of the above is reasonable, but i'm going to drag this
discussion back to my fundamental point -- it's not that the OE dev
branch is broken for me, it's that it's *perpetually* broken.
breakage is acceptable. perpetual breakage starts to lose its
entertainment value after a while.

rday