testing branch 2010-10-29

testing branch 2010-10-29

[Cliff Brake]

testing-next is ready for clean builds.  I'm still working on my
process to get this branch created automatically--thanks for your
patience.

Last weeks testing failed in a number of areas.  The combinations that
worked at listed in the tag:
http://cgit.openembedded.org/cgit.cgi/openembedded/tag/?id=tested_2010-10-25

For more information on the testing effort:
http://wiki.openembedded.org/index.php/Testing

Thanks,
Cliff

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

Re: testing branch 2010-10-29

[Yuri Bushmelev]

2010/10/29 Cliff Brake <cliff.brake@gmail.com>:
> testing-next is ready for clean builds.  I'm still working on my
> process to get this branch created automatically--thanks for your
> patience.

I have joined to testing initiative with:

DISTROS="angstrom-2008.1 minimal"
MACHINES="tosa collie akita efikamx ben-nanonote qemux86 qemuarm"
IMAGES="x11-image opie-image"

Test-builder will build every image for every machine for every distro
from list.
Every build will be started with clean $TMPDIR for now at least (may
be changed - depends on time required for full build).

OE-stats will be published with 'Jay7-tb' builder name.
Test-builder is running inside LXC-container with Debian Lenny x64.

Feel free to request to add other machines and images.

-- 
Yuri Bushmelev

Re: testing branch 2010-10-29

[Koen Kooi]

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

On 31-10-10 22:03, Yuri Bushmelev wrote:
> 2010/10/29 Cliff Brake <cliff.brake@gmail.com>:
>> testing-next is ready for clean builds.  I'm still working on my
>> process to get this branch created automatically--thanks for your
>> patience.
> 
> I have joined to testing initiative with:
> 
> DISTROS="angstrom-2008.1 minimal"
> MACHINES="tosa collie akita efikamx ben-nanonote qemux86 qemuarm"
> IMAGES="x11-image opie-image"
> 
> Test-builder will build every image for every machine for every distro
> from list.
> Every build will be started with clean $TMPDIR for now at least

I mentioned this at OEDEM as well, only doing clean builds hides upgrade
path type of bugs (e.g. libcdio5 -> libcdio). It would be nice if an
incremental build going from testing-prev to testing-next would be done
as well before tagging.

regards,

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

iD8DBQFMzejnMkyGM64RGpERAh7bAJ4iEjXYNtQluY4igLuu1vnS6Syi2gCeK6g9
kQIbcn4jeMGUJ3IIhgzKbNY=
=XB9m
-----END PGP SIGNATURE-----

Re: testing branch 2010-10-29

[Yuri Bushmelev]

Hello!

>> Every build will be started with clean $TMPDIR for now at least
>
> I mentioned this at OEDEM as well, only doing clean builds hides upgrade
> path type of bugs (e.g. libcdio5 -> libcdio). It would be nice if an
> incremental build going from testing-prev to testing-next would be done
> as well before tagging.

I need a lot of HDD space then.
Should I do builds twice - clean and incremental?

Second question - is there any sense to clean/restore $TMPDIR between
building of different images (x11-image/opie-image) but same machine &
distro?

I mean following workflow

clean $TMPDIR/restore $TMPDIR from previous build of x11-image for
this machine/distro
build x11-image
clean $TMPDIR/restore $TMPDIR from previous build of opie-image for
this machine/distro
build opie-image
save $TMPDIR for next testing-next build

VS

clean $TMPDIR/restore $TMPDIR from previous build of this machine/distro
build x11-image
build opie-image
save $TMPDIR for next testing-next build

-- 
Yuri Bushmelev

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

2010/10/31 Yuri Bushmelev <jay4mail@gmail.com>:
> Hello!
>
>>> Every build will be started with clean $TMPDIR for now at least
>>
>> I mentioned this at OEDEM as well, only doing clean builds hides upgrade
>> path type of bugs (e.g. libcdio5 -> libcdio). It would be nice if an
>> incremental build going from testing-prev to testing-next would be done
>> as well before tagging.
>
> I need a lot of HDD space then.

:-)
Anyway if you are planning doing incremental builds, better have
INHERIT += "rm_work" in your local.conf to save space

> Should I do builds twice - clean and incremental?

That is upon you. Currently the agreement for the testing branch is to
start with a clean slate.
>
> Second question - is there any sense to clean/restore $TMPDIR between
> building of different images (x11-image/opie-image) but same machine &
> distro?

Not really. This has been discussed on the list and it was felt ok
build different testing recipes/images for the same machine/distro
without cleaning.
Inbetween cleaning will not help too much and takes quite some time.
it seems a good plan to mention that you did not clean inbetween (e.g.
by saying in same target-image cell that you did x11-image and
opie-image)

Actually you might want to do a bitbake x11-image opie-image as one command.
>
> I mean following workflow
>
> clean $TMPDIR/restore $TMPDIR from previous build of x11-image for
> this machine/distro
> build x11-image
> clean $TMPDIR/restore $TMPDIR from previous build of opie-image for
> this machine/distro
> build opie-image
> save $TMPDIR for next testing-next build
>
> VS
>
> clean $TMPDIR/restore $TMPDIR from previous build of this machine/distro
> build x11-image
> build opie-image
> save $TMPDIR for next testing-next build

As said before you can combine the build.

Wrt saving TMPDIR: if you want to do that a good solution is to define
TMPDIR as something like tmp-${DISTRO}-${MACHINE} or something like
that. No need to copy the tmp dir

An alternate solution is to use packaged staging to repopulate TMPDIR.

And thanks for your participation in the testing effort!
Frans

Re: testing branch 2010-10-29

[Cliff Brake]

On Mon, Nov 1, 2010 at 3:57 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
>> Second question - is there any sense to clean/restore $TMPDIR between
>> building of different images (x11-image/opie-image) but same machine &
>> distro?
>
> Not really. This has been discussed on the list and it was felt ok
> build different testing recipes/images for the same machine/distro
> without cleaning.
> Inbetween cleaning will not help too much and takes quite some time.
> it seems a good plan to mention that you did not clean inbetween (e.g.
> by saying in same target-image cell that you did x11-image and
> opie-image)

Agreed, I think it is most important to start clean with every cycle,
but I do not think it is necessary to remove TMPDIR between building
combinations.  As Koen mentioned, doing an incremental build before
cleaning and building is a good idea.

Thanks,
Cliff

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

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

2010/10/31 Koen Kooi <k.kooi@student.utwente.nl>:
> On 31-10-10 22:03, Yuri Bushmelev wrote:

>> Every build will be started with clean $TMPDIR for now at least
>
> I mentioned this at OEDEM as well, only doing clean builds hides upgrade
> path type of bugs (e.g. libcdio5 -> libcdio). It would be nice if an
> incremental build going from testing-prev to testing-next would be done
> as well before tagging.

From the wiki page [1], item 2:
"All volunteers start a clean build and build the combinations they
test, update the above chart, and report status/issues as replies to
the above email. "

But as far as I'm concerned feel free to run incremental tests and put
the results on the testing page (indicating that it is from an
incremental build).

I will remain starting with a clean tmp for now. As it stands:
- I don't have the space to store 6 tmp dirs
- There seem to be sufficient issues with a clean build
- My employer (who sponsors my testing activities by donating cpu
cycles and storage) is into embedded systems. Partial upgrades are not
relevant in our kind of embedded systems. A reliable and reproducible
build is much more important to us, hence my focus on clean builds.

Enjoy Frans.

PS: a few comments wrt the libcdio issue:

- it would have been nice if this was discussed with the recipe
maintainer. This is in accordance with our commit policy [2, 4th
block]. I strongly doubt that this has happened (and apologies if this
is a faulty assumption).
- I have strong doubts that the dependency change is sound. Actually
libcdio and libcddb are in a catch22 situation where both depend on
each other for some sample programs.
Solution is probably to make an additional package for the sample
progs (I seem to recall that is also the way debian handles this).
Haven't had time to dig into this and fix it.
- maybe some of the confusion and issues wrt libs is because the way
to do this is not really well documented. Eric had some questions on
this on irc on this yesterday too.
If you feel there is documentation, please pass a pointer, otherwise
please add some info to the wiki so the problem can be avoided.
(give a man a fish and he can eat a day, learn a man how to fish and
he can eat all his life).
I would have added the info to the wiki or manual myself, but I feel
my understanding of the issue and the way to handle it is not good
enough to be able to write a good section on it.

(btw: a good place would probably be [3] and yeah, I am aware of the
debian renaming [4], but I am also aware of [5] which as an example
says:
FILES_${PN} = "\
    ${bindir}/* \
    ${sbindir}/* \
    ${libexecdir}/* \
    ${libdir}/lib*.so.* \
    .....
which was exactly what was in the original commit [6]:
+FILES_${PN} = "${libdir}/lib${PN}${SOLIB}"
)

[1] http://wiki.openembedded.net/index.php/Testing#Testing_Procedure
[2] http://wiki.openembedded.net/index.php/Commit_Policy
[3] http://docs.openembedded.org/usermanual/usermanual.html#recipes_examples
[4] http://docs.openembedded.org/usermanual/usermanual.html#id593730
[5] http://docs.openembedded.org/usermanual/usermanual.html#id593138
[6] http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b672b28ba6a29e2715c91fcbbda8b2776b6f1105

Re: testing branch 2010-10-29

[Martin Jansa]

On Mon, Nov 01, 2010 at 08:49:32AM +0100, Frans Meulenbroeks wrote:
> 2010/10/31 Koen Kooi <k.kooi@student.utwente.nl>:
> > On 31-10-10 22:03, Yuri Bushmelev wrote:
> 
> >> Every build will be started with clean $TMPDIR for now at least
> >
> > I mentioned this at OEDEM as well, only doing clean builds hides upgrade
> > path type of bugs (e.g. libcdio5 -> libcdio). It would be nice if an
> > incremental build going from testing-prev to testing-next would be done
> > as well before tagging.
> 
> From the wiki page [1], item 2:
> "All volunteers start a clean build and build the combinations they
> test, update the above chart, and report status/issues as replies to
> the above email. "
> 
> But as far as I'm concerned feel free to run incremental tests and put
> the results on the testing page (indicating that it is from an
> incremental build).
> 
> I will remain starting with a clean tmp for now. As it stands:
> - I don't have the space to store 6 tmp dirs
> - There seem to be sufficient issues with a clean build
> - My employer (who sponsors my testing activities by donating cpu
> cycles and storage) is into embedded systems. Partial upgrades are not
> relevant in our kind of embedded systems. A reliable and reproducible
> build is much more important to us, hence my focus on clean builds.
> 
> Enjoy Frans.
> 
> PS: a few comments wrt the libcdio issue:
> 
> - it would have been nice if this was discussed with the recipe
> maintainer. This is in accordance with our commit policy [2, 4th
> block]. I strongly doubt that this has happened (and apologies if this
> is a faulty assumption).
> - I have strong doubts that the dependency change is sound. Actually
> libcdio and libcddb are in a catch22 situation where both depend on
> each other for some sample programs.
> Solution is probably to make an additional package for the sample
> progs (I seem to recall that is also the way debian handles this).
> Haven't had time to dig into this and fix it.
> - maybe some of the confusion and issues wrt libs is because the way
> to do this is not really well documented. Eric had some questions on
> this on irc on this yesterday too.
> If you feel there is documentation, please pass a pointer, otherwise
> please add some info to the wiki so the problem can be avoided.
> (give a man a fish and he can eat a day, learn a man how to fish and
> he can eat all his life).
> I would have added the info to the wiki or manual myself, but I feel
> my understanding of the issue and the way to handle it is not good
> enough to be able to write a good section on it.
> 
> (btw: a good place would probably be [3] and yeah, I am aware of the
> debian renaming [4], but I am also aware of [5] which as an example
> says:
> FILES_${PN} = "\
>     ${bindir}/* \
>     ${sbindir}/* \
>     ${libexecdir}/* \
>     ${libdir}/lib*.so.* \
>     .....
> which was exactly what was in the original commit [6]:
> +FILES_${PN} = "${libdir}/lib${PN}${SOLIB}"

It's OK, but much better if you also PR bump packages depending on it.
Because as long as "${bindir}/*" was included in FILES_${PN}, debian
naming didin't happen (because of multiple binaries in 1 package), the
same happens when you have multiple libraries in 1 package without
LEAD_SONAME defined.

So moving binaries to new FILES_${PN}-utils is probably good move, but
as side effects it renames libcdio to libcdio5. And because already
built packages have libcdio instead of libcdio5 in it's runtime depends,
those needs to be rebuilt (to pick libcdio5 as libcdio.so provider)

Not sure how to check all recipes depending on it (I don't trust DEPENDS
as some packages are voluntary linked to libcdio just because autotools
found it). So usually I notice it only when image build fails (opkg
complaining about missing packages), but that works only for packages
included in built image :/. And when I notice it, I usually do something
like:
find deploy/ipk/ -name Packages -exec grep -B 3 libcdio {} \;
to see where wrong Depends is and then PR bump those (which still fixes
only those recipes I'm building as part of some image or ie
task-shr-feed)

sometimes it gets even worse, like in this case:
http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=5fa427d06922297496fcf5ebd6c0a6a5c2adac46
when edbus.ipk gets empty after moving all libs to separate packages, so
it won't get upgrade on target and creates conflicts between old package
containing ie libehal.so.* and new edbus-ehal.ipk providing the same lib
in newer version.

Feel free to update wiki if you found this explanation (or at least some
part of it :)) understandable.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

2010/11/1 Martin Jansa <martin.jansa@gmail.com>:
> On Mon, Nov 01, 2010 at 08:49:32AM +0100, Frans Meulenbroeks wrote:

>>
>> (btw: a good place would probably be [3] and yeah, I am aware of the
>> debian renaming [4], but I am also aware of [5] which as an example
>> says:
>> FILES_${PN} = "\
>>     ${bindir}/* \
>>     ${sbindir}/* \
>>     ${libexecdir}/* \
>>     ${libdir}/lib*.so.* \
>>     .....
>> which was exactly what was in the original commit [6]:
>> +FILES_${PN} = "${libdir}/lib${PN}${SOLIB}"
>
> It's OK, but much better if you also PR bump packages depending on it.
> Because as long as "${bindir}/*" was included in FILES_${PN}, debian
> naming didin't happen (because of multiple binaries in 1 package), the
> same happens when you have multiple libraries in 1 package without
> LEAD_SONAME defined.

Which (at least to me) is highly confusing. I did not expect that
adding/removing things from FILES_${PN} would change the lib renaming.
This seems highly counter-intuitive to me.

Actually I'mkinda  flabbergasted when renaming does and when it does not happen.
That is why I feel some doc is a good plan.

The same holds with the LEAD_SONAME and e.g. the GNU_HASH errors/warnings.
There are all quite common. It would be a good plan to have a page
somewhere describing the meaning of these messages and what to do with
them.
>
> So moving binaries to new FILES_${PN}-utils is probably good move, but
> as side effects it renames libcdio to libcdio5. And because already
> built packages have libcdio instead of libcdio5 in it's runtime depends,
> those needs to be rebuilt (to pick libcdio5 as libcdio.so provider)
>
> Not sure how to check all recipes depending on it (I don't trust DEPENDS
> as some packages are voluntary linked to libcdio just because autotools
> found it). So usually I notice it only when image build fails (opkg
> complaining about missing packages), but that works only for packages
> included in built image :/. And when I notice it, I usually do something
> like:
> find deploy/ipk/ -name Packages -exec grep -B 3 libcdio {} \;
> to see where wrong Depends is and then PR bump those (which still fixes
> only those recipes I'm building as part of some image or ie
> task-shr-feed)

You might want to extend your grep to DEPENDS lines.
Then again this is not trivial if DEPENDS is split over multiple lines
and the package same is something that occurs lots of times outside
the depends var.

In the case where you encounter a depends issue, I hope you also fix
DEPENDS (but actually I'm pretty sure you will :-) )
>
> sometimes it gets even worse, like in this case:
> http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=5fa427d06922297496fcf5ebd6c0a6a5c2adac46
> when edbus.ipk gets empty after moving all libs to separate packages, so
> it won't get upgrade on target and creates conflicts between old package
> containing ie libehal.so.* and new edbus-ehal.ipk providing the same lib
> in newer version.

Upgrading is sometimes a pita.

>
> Feel free to update wiki if you found this explanation (or at least some
> part of it :)) understandable.
>

See above.
The fact is that I am fairly time-constrained next few days. Came back
from elc/oedem last sun, have to leave for another trip upcoming sat
morning.

Have fun! Frans

Re: testing branch 2010-10-29

[Martin Jansa]

On Mon, Nov 01, 2010 at 11:37:25AM +0100, Frans Meulenbroeks wrote:
> 2010/11/1 Martin Jansa <martin.jansa@gmail.com>:
> You might want to extend your grep to DEPENDS lines.
> Then again this is not trivial if DEPENDS is split over multiple lines
> and the package same is something that occurs lots of times outside
> the depends var.

Yes this was really just stupid test to find those, before using it in
docs it should be improved or someone has much better way to detect
those..

> In the case where you encounter a depends issue, I hope you also fix
> DEPENDS (but actually I'm pretty sure you will :-) )

Well this DEPENDS depends :) on what is expected from distribution, IE
python DEPENDS have
${@base_contains('DISTRO_FEATURES', 'tk', 'tk', '', d)}
because not all distributions should be forced to build python with tk
support, but there isn't IIRC
EXTRA_OECONF += "${@base_contains('DISTRO_FEATURES', 'tk', '--enable-tk', '--disable-tk', d)}"

so even if your distro doesn't have tk in DISTRO_FEATURES then it gets
autodetected as available if you build tk laterbecause of some other 
recipe depending on it unconditionaly.

In the end every feature which is autodetected in configure should be
forced enabled or disabled in recipe to correspond with DEPENDS.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

2010/11/1 Martin Jansa <martin.jansa@gmail.com>:

>
> In the end every feature which is autodetected in configure should be
> forced enabled or disabled in recipe to correspond with DEPENDS.

I agree! This should be part of a sane recipe.
Janitors job?

Frans

Re: testing branch 2010-10-29

[Koen Kooi]

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

On 01-11-10 08:49, Frans Meulenbroeks wrote:

> PS: a few comments wrt the libcdio issue:
> 
> - it would have been nice if this was discussed with the recipe
> maintainer. This is in accordance with our commit policy [2, 4th
> block]. I strongly doubt that this has happened (and apologies if this
> is a faulty assumption).

Since I'm not sure if you're getting at the fix or breakage, I will talk
about the breakage commit:

I don't tend to discuss things with myself since it creeps people out :)
I created the cdio recipe myself in 2009 and pushed in januari 2010.
The funny thing is that all the breakage occured by this:

http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b672b28ba6a29e2715c91fcbbda8b2776b6f1105

That commit has no ACKs so SOBs from me, so I wonder why it went in.

> (btw: a good place would probably be [3] and yeah, I am aware of the
> debian renaming [4], but I am also aware of [5] which as an example
> says:
> FILES_${PN} = "\
>     ${bindir}/* \
>     ${sbindir}/* \
>     ${libexecdir}/* \
>     ${libdir}/lib*.so.* \
>     .....
> which was exactly what was in the original commit [6]:
> +FILES_${PN} = "${libdir}/lib${PN}${SOLIB}"

But there's no file called liblibcdio.so.x.y, only libcdio.so.x.y. The
original recipe already had a way to split all the libs automatically.

Thankfully the incremental angstrom autobuilder caught that issue and
was fixed shortly after.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMzn+yMkyGM64RGpERAhCeAKClVVlShXMOPZfX0E75/zdyfcgyngCgtFgO
eT/mGyAz6nqYFEI2HpAJ/oE=
=5WFz
-----END PGP SIGNATURE-----

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

2010/11/1 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01-11-10 08:49, Frans Meulenbroeks wrote:
>
>> PS: a few comments wrt the libcdio issue:
>>
>> - it would have been nice if this was discussed with the recipe
>> maintainer. This is in accordance with our commit policy [2, 4th
>> block]. I strongly doubt that this has happened (and apologies if this
>> is a faulty assumption).
>
> Since I'm not sure if you're getting at the fix or breakage, I will talk
> about the breakage commit:
>
> I don't tend to discuss things with myself since it creeps people out :)

:-)

The confusion was caused by the fact that this one:
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=92e23e98bdbd1bdacb23f5d2c848159cbab6d057
touches both libcdio.inc and libcddb_1.3.2.bb
In the latter one you removed among others:
-MAINTAINER = "Andreas Frisch <andreas.frisch@multimedia-labs.de>"

Have the changes in that file been discussed with Andreas ?

Also the libcdio 0.82 recipe was added by Khem on sep 30:
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=c5a250437273e98fd66a13cfa6f5088b9ae68a97
because 0.81 was not cross-compile safe, after which Andreas made some
improvements to it.
The MAINTAINERS file also does not list you as maintainer for this
recipe. Guess this is a good case why it is useful to list the
maintainer in the recipe.

Anyway that (and the fact that we are poor on ACK-ing recipes) caused
me to push Andreas' patch (after verifying that it builds).

> I created the cdio recipe myself in 2009 and pushed in januari 2010.
> The funny thing is that all the breakage occured by this:
>
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b672b28ba6a29e2715c91fcbbda8b2776b6f1105
>
> That commit has no ACKs so SOBs from me, so I wonder why it went in.

As explained above because you were not identified as the maintainer
as you did not write or push the 0.82 recipe and are not listed as
such in the MAINTAINERS file.

And (unrelated to this issue) I do not see the same prudence you
expect from others when you modify recipes that are maintained by
others.
"Do unto others as you would have them do unto you"

>
>> (btw: a good place would probably be [3] and yeah, I am aware of the
>> debian renaming [4], but I am also aware of [5] which as an example
>> says:
>> FILES_${PN} = "\
>>     ${bindir}/* \
>>     ${sbindir}/* \
>>     ${libexecdir}/* \
>>     ${libdir}/lib*.so.* \
>>     .....
>> which was exactly what was in the original commit [6]:
>> +FILES_${PN} = "${libdir}/lib${PN}${SOLIB}"
>
> But there's no file called liblibcdio.so.x.y, only libcdio.so.x.y. The
> original recipe already had a way to split all the libs automatically.

That code was still there.

+python populate_packages_prepend () {
+ glibdir = bb.data.expand('${libdir}', d)
+ do_split_packages(d, glibdir, '^lib(.*)\.so\..*', 'lib%s',
'gstreamer %s library', extra_depends='', allow_links=True)
+}

Not sure how well it applies with the FILES_${PN} breakage.

On a personal note:
I feel that python functions like this,  clever as they are, do
severely reduce the understandability and maintainability of the
recipe.
Not everybody is a python wiz. I feel recipes should be easy to
understand for the average developer.
Personally I would prefer just iterating the files in a FILES* assignment.
That makes things so much better understandable (and yes if a new file
is added in a newer version of the recipe it will not be added
automagically. However there will be a note to warn that the new file
is not packaged)

>
> Thankfully the incremental angstrom autobuilder caught that issue and
> was fixed shortly after.

Which is good :-)

Frans.

PS: since you are so concerned about libcdio, would you please fix the
dependencies or the configure.
configure --help says
...
  --enable-cddb           include CDDB lookups in cd_info (default enabled)
  --enable-vcd-info      include Video CD Info from libvcd
...

Seems like whatever is build depends on whether libcddb is build before or not.
Andreas fixed that by adding a dependency on libcddb, but you undid
that in http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=92e23e98bdbd1bdacb23f5d2c848159cbab6d057

And while you're at it perhaps add in the MAINTAINERS file that you
are the maintainer of this recipe.

Re: testing branch 2010-10-29

[Cliff Brake]

On Sun, Oct 31, 2010 at 6:08 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 31-10-10 22:03, Yuri Bushmelev wrote:
>> 2010/10/29 Cliff Brake <cliff.brake@gmail.com>:
>>> testing-next is ready for clean builds.  I'm still working on my
>>> process to get this branch created automatically--thanks for your
>>> patience.
>>
>> I have joined to testing initiative with:
>>
>> DISTROS="angstrom-2008.1 minimal"
>> MACHINES="tosa collie akita efikamx ben-nanonote qemux86 qemuarm"
>> IMAGES="x11-image opie-image"
>>
>> Test-builder will build every image for every machine for every distro
>> from list.
>> Every build will be started with clean $TMPDIR for now at least
>
> I mentioned this at OEDEM as well, only doing clean builds hides upgrade
> path type of bugs (e.g. libcdio5 -> libcdio). It would be nice if an
> incremental build going from testing-prev to testing-next would be done
> as well before tagging.

Good idea--I agree this would be good to do where possible, as it
would not cost much, and help us identify issues.  The main focus of
current testing is to identify good starting points for new users, or
people just looking for a build-able snapshot, so clean builds are
where we started.  I'll add a note to the wiki to build incremental
builds first if possible.  Based on the feedback of people doing the
actual testing work, perhaps it will make sense to do something else
in the future.

Thanks,
Cliff

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

Re: testing branch 2010-10-29

[Khem Raj]

On Mon, Nov 1, 2010 at 9:19 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
> On Sun, Oct 31, 2010 at 6:08 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 31-10-10 22:03, Yuri Bushmelev wrote:
>>> 2010/10/29 Cliff Brake <cliff.brake@gmail.com>:
>>>> testing-next is ready for clean builds.  I'm still working on my
>>>> process to get this branch created automatically--thanks for your
>>>> patience.
>>>
>>> I have joined to testing initiative with:
>>>
>>> DISTROS="angstrom-2008.1 minimal"
>>> MACHINES="tosa collie akita efikamx ben-nanonote qemux86 qemuarm"
>>> IMAGES="x11-image opie-image"
>>>
>>> Test-builder will build every image for every machine for every distro
>>> from list.
>>> Every build will be started with clean $TMPDIR for now at least
>>
>> I mentioned this at OEDEM as well, only doing clean builds hides upgrade
>> path type of bugs (e.g. libcdio5 -> libcdio). It would be nice if an
>> incremental build going from testing-prev to testing-next would be done
>> as well before tagging.
>
> Good idea--I agree this would be good to do where possible, as it
> would not cost much, and help us identify issues.  The main focus of
> current testing is to identify good starting points for new users, or
> people just looking for a build-able snapshot, so clean builds are
> where we started.  I'll add a note to the wiki to build incremental
> builds first if possible.  Based on the feedback of people doing the
> actual testing work, perhaps it will make sense to do something else
> in the future.
>

Hi Cliff

We should add another column identifying the build is from clean tmp
or an incremental one

> Thanks,
> Cliff
>
> --
> =================
> http://bec-systems.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: testing branch 2010-10-29

[Petr Štetiar]

Khem Raj <raj.khem@gmail.com> [2010-11-01 10:32:53]:

> We should add another column identifying the build is from clean tmp
> or an incremental one

No more columns please. I think, that I should receive a PhD just because I
can update that table :-) It's pure rocket science...

-- ynezz

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

2010/11/1 Petr Štetiar <ynezz@true.cz>:
> Khem Raj <raj.khem@gmail.com> [2010-11-01 10:32:53]:
>
>> We should add another column identifying the build is from clean tmp
>> or an incremental one
>
> No more columns please. I think, that I should receive a PhD just because I
> can update that table :-) It's pure rocket science...
>
> -- ynezz
>

Put the table in a spreadsheet?
I think google docs can be used to share access to a common sheet (but
not fully sure).

Disadvantage of an incremental build is that you need to keep all the
tmp dirs around, which, at least for me, is probably prohibitive (I'll
verify this later)

Frans

Re: testing branch 2010-10-29

[Petr Štetiar]

Frans Meulenbroeks <fransmeulenbroeks@gmail.com> [2010-11-01 19:49:19]:

> > No more columns please. I think, that I should receive a PhD just because I
> > can update that table :-) It's pure rocket science...
> 
> Put the table in a spreadsheet?
> I think google docs can be used to share access to a common sheet (but
> not fully sure).

That's the question :-) Maybe some mod to the tinderbox client and if the
builder is building testing-next and the build succeeded, then update
something, somehwere automatically? Or does it need to be done manually at
all?

INHERIT += "oestats-client-testing-next"
OESTATS_HOST_DISTRO = "Ubuntu 10.04" (auto using lsb_release?)
OESTATS_WHATEVER = "..."

-- ynezz

Re: testing branch 2010-10-29

[Koen Kooi]

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

On 01-11-10 19:49, Frans Meulenbroeks wrote:

> Disadvantage of an incremental build is that you need to keep all the
> tmp dirs around, which, at least for me, is probably prohibitive (I'll
> verify this later)

rm tmp -rf
git checkout tag-for-testing-prev
bitbake foo
git checkout tag-for-testing-next
bitbake foo

That will only use slightly more diskspace than a build from scratch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMzxEaMkyGM64RGpERAlQSAJ0bGeZ6m/V9ZpBe7bgLmqdpUZIJMQCeINEV
nNvFg26kSX5BqwvVQaVM4CE=
=DyxS
-----END PGP SIGNATURE-----

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

2010/11/1 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01-11-10 19:49, Frans Meulenbroeks wrote:
>
>> Disadvantage of an incremental build is that you need to keep all the
>> tmp dirs around, which, at least for me, is probably prohibitive (I'll
>> verify this later)
>
> rm tmp -rf
> git checkout tag-for-testing-prev
> bitbake foo
> git checkout tag-for-testing-next
> bitbake foo
>
> That will only use slightly more diskspace than a build from scratch

Yes, but I don't think it will catch errors like the one we had with
introspection (and libgee failing to build).
Of course ideally both a clean and incremental build should work, but
if I must choose, I prefer that the clean build works.

FM

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFMzxEaMkyGM64RGpERAlQSAJ0bGeZ6m/V9ZpBe7bgLmqdpUZIJMQCeINEV
> nNvFg26kSX5BqwvVQaVM4CE=
> =DyxS
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: testing branch 2010-10-29

[Khem Raj]

On (01/11/10 19:49), Frans Meulenbroeks wrote:
> 2010/11/1 Petr Štetiar <ynezz@true.cz>:
> > Khem Raj <raj.khem@gmail.com> [2010-11-01 10:32:53]:
> >
> >> We should add another column identifying the build is from clean tmp
> >> or an incremental one
> >
> > No more columns please. I think, that I should receive a PhD just because I
> > can update that table :-) It's pure rocket science...
> >
> > -- ynezz
> >
> 
> Put the table in a spreadsheet?
> I think google docs can be used to share access to a common sheet (but
> not fully sure).

Wiki has good support for tables.
> 
> Disadvantage of an incremental build is that you need to keep all the
> tmp dirs around, which, at least for me, is probably prohibitive (I'll
> verify this later)

Disadvantage for you agreed but may not be for others who have space to keep the tmpdir
and care about saving time on complete rebuilds or upgrade paths etc.

> 
> Frans
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

2010/11/1 Khem Raj <raj.khem@gmail.com>:
> On (01/11/10 19:49), Frans Meulenbroeks wrote:
>> 2010/11/1 Petr Štetiar <ynezz@true.cz>:
>> > Khem Raj <raj.khem@gmail.com> [2010-11-01 10:32:53]:
>> >
>> >> We should add another column identifying the build is from clean tmp
>> >> or an incremental one
>> >
>> > No more columns please. I think, that I should receive a PhD just because I
>> > can update that table :-) It's pure rocket science...
>> >
>> > -- ynezz
>> >
>>
>> Put the table in a spreadsheet?
>> I think google docs can be used to share access to a common sheet (but
>> not fully sure).
>
> Wiki has good support for tables.

Better than what we have now? The layout somewhat sucks. I'd rather
see it as a table while editing, due to the different width of the
fields used, it is at the moment fairly difficult to match your cells
with the column caption (especially if you are near the end of the
table).

>>
>> Disadvantage of an incremental build is that you need to keep all the
>> tmp dirs around, which, at least for me, is probably prohibitive (I'll
>> verify this later)
>
> Disadvantage for you agreed but may not be for others who have space to keep the tmpdir
> and care about saving time on complete rebuilds or upgrade paths etc.

Oh yes, I fully agree, and I definitely do not want to stop anyone
from doing incremental builds.
The more diverse tests we do the more chance we have to find bugs.

FM

Re: testing branch 2010-10-29

[Yury Bushmelev]

2010/11/1 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:

>>> Put the table in a spreadsheet?
>>> I think google docs can be used to share access to a common sheet (but
>>> not fully sure).
>>
>> Wiki has good support for tables.
>
> Better than what we have now? The layout somewhat sucks. I'd rather
> see it as a table while editing, due to the different width of the
> fields used, it is at the moment fairly difficult to match your cells
> with the column caption (especially if you are near the end of the
> table).

I've appended bottom copy or header to that table. This will make life
a bit easier :)
Also we can setup own online spreadsheet (e.g.
http://www.simple-groupware.de/cms/Spreadsheet/Home).

>>> Disadvantage of an incremental build is that you need to keep all the
>>> tmp dirs around, which, at least for me, is probably prohibitive (I'll
>>> verify this later)
>>
>> Disadvantage for you agreed but may not be for others who have space to keep the tmpdir
>> and care about saving time on complete rebuilds or upgrade paths etc.
>
> Oh yes, I fully agree, and I definitely do not want to stop anyone
> from doing incremental builds.
> The more diverse tests we do the more chance we have to find bugs.

Clean build is enough for most people.
People who have free CPU and HDD resources can do incremental builds too.
I'll append 'Build type' field to wiki table.

-- 
Yury Bushmelev

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

2010/11/2 Yury Bushmelev <jay4mail@gmail.com>:
> 2010/11/1 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>
>>>> Put the table in a spreadsheet?
>>>> I think google docs can be used to share access to a common sheet (but
>>>> not fully sure).
>>>
>>> Wiki has good support for tables.
>>
>> Better than what we have now? The layout somewhat sucks. I'd rather
>> see it as a table while editing, due to the different width of the
>> fields used, it is at the moment fairly difficult to match your cells
>> with the column caption (especially if you are near the end of the
>> table).
>
> I've appended bottom copy or header to that table. This will make life
> a bit easier :)
> Also we can setup own online spreadsheet (e.g.
> http://www.simple-groupware.de/cms/Spreadsheet/Home).

Thanks.
We also might want to layout the table (in edit mode) in such a way
that also there it looks like a table.
Currently I see (taking a random snippet from the table):

|qemux86    ||minimal   ||native-sdk-image  ||Ubuntu 10.04 64-bit   ||
||[[User:khem]]      ||testing_2010-10-25||clean ||
|-
|qemumipsel    ||minimal   ||x11-image  ||Slackware 13.1 64-bit   ||
||grg      ||testing_2010-10-14||clean ||
|-
|qemuarm    ||angstrom-2010.x   ||x11-gpe-image  ||Fedora 12 32-bit
|| ||[[User:gthomas]]      ||testing_2010-09-07||clean
||testing_2010-09-13 fails to build xf86-input-mouse

Guess it would be better to have all || chars in the same column.

Frans

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

We've switched to 10.04 as host.
With that most things build fine.

With 8.04 I had some issues.
See the thread 'e2fsprogs build problems (with ubuntu 8.04 host)"

However, as the autobuilder moved to 10.04 I will cease to stop 8.04 testing.
Time permitting I will also put some info in the wiki on my setup (as
asked on irc).

Best regards, Frans

Re: testing branch 2010-10-29

[Cliff Brake]

On Mon, Nov 1, 2010 at 2:49 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/11/1 Petr Štetiar <ynezz@true.cz>:
>> Khem Raj <raj.khem@gmail.com> [2010-11-01 10:32:53]:
>>
>>> We should add another column identifying the build is from clean tmp
>>> or an incremental one
>>
>> No more columns please. I think, that I should receive a PhD just because I
>> can update that table :-) It's pure rocket science...
>>
>> -- ynezz
>>
>
> Put the table in a spreadsheet?
> I think google docs can be used to share access to a common sheet (but
> not fully sure).

Yes, with Google spreadsheets, multiple people can edit a google doc.
The following might be a good solution:

http://www.mediawikiwidgets.org/Google_Spreadsheet

Do all testers currently have google accounts?  I'm all for making it
less painful.

Thanks,
Cliff

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

Re: testing branch 2010-10-29

[Gary Thomas]

On 11/02/2010 06:00 AM, Cliff Brake wrote:
> On Mon, Nov 1, 2010 at 2:49 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com>  wrote:
>> 2010/11/1 Petr Štetiar<ynezz@true.cz>:
>>> Khem Raj<raj.khem@gmail.com>  [2010-11-01 10:32:53]:
>>>
>>>> We should add another column identifying the build is from clean tmp
>>>> or an incremental one
>>>
>>> No more columns please. I think, that I should receive a PhD just because I
>>> can update that table :-) It's pure rocket science...
>>>
>>> -- ynezz
>>>
>>
>> Put the table in a spreadsheet?
>> I think google docs can be used to share access to a common sheet (but
>> not fully sure).
>
> Yes, with Google spreadsheets, multiple people can edit a google doc.
> The following might be a good solution:
>
> http://www.mediawikiwidgets.org/Google_Spreadsheet
>
> Do all testers currently have google accounts?  I'm all for making it
> less painful.

Even if they don't have one already, getting one today is trivial.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: testing branch 2010-10-29

[Khem Raj]

On Tue, Nov 2, 2010 at 5:00 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
> On Mon, Nov 1, 2010 at 2:49 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2010/11/1 Petr Štetiar <ynezz@true.cz>:
>>> Khem Raj <raj.khem@gmail.com> [2010-11-01 10:32:53]:
>>>
>>>> We should add another column identifying the build is from clean tmp
>>>> or an incremental one
>>>
>>> No more columns please. I think, that I should receive a PhD just because I
>>> can update that table :-) It's pure rocket science...
>>>
>>> -- ynezz
>>>
>>
>> Put the table in a spreadsheet?
>> I think google docs can be used to share access to a common sheet (but
>> not fully sure).
>
> Yes, with Google spreadsheets, multiple people can edit a google doc.
> The following might be a good solution:
>
> http://www.mediawikiwidgets.org/Google_Spreadsheet
>
> Do all testers currently have google accounts?  I'm all for making it
> less painful.

sounds good. Dont they allow anonymous edit iow one who does not have
gmail/google account can still edit google docs ?

>
> Thanks,
> Cliff
>
> --
> =================
> http://bec-systems.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: testing branch 2010-10-29

[Leon Woestenberg]

Hello,

On Tue, Nov 2, 2010 at 7:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Nov 2, 2010 at 5:00 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
>> Do all testers currently have google accounts?  I'm all for making it
>> less painful.
>
> sounds good. Dont they allow anonymous edit iow one who does not have
> gmail/google account can still edit google docs ?
>
No, unfortunately not.

You can use your private email adres when you "login" and create a
password, but effectively that will then become your Google account
login.


Regards,
-- 
Leon

Re: testing branch 2010-10-29

[Frans Meulenbroeks]

My testing results are added.
As I will be afk next week most likely there will not be results for me.

Meanwhile I did carve a page on my testing script (as requested by some):
http://wiki.openembedded.net/index.php/TestingScript

I have also added a link to that page on the Testing page.

Feel free to improve...

Frans