cleaning recipes

cleaning recipes

[Frans Meulenbroeks]

Dear all,

As some of you might have noticed I've been cleaning up our
recipes.during the last week or so.
As I had some time at hand this weekend, lots of cleaning has been done.
I did my very best to stay within the guidelines of the TSC (as
described in http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/020047.html),
but it is quite possible that at some point I made a mistake or so.
If so, let me know and I'll repair things and/or revert the commit. (I
feel if you make a mess you should also clean it yourself).

Rationale for doing so is that it makes the tasks as listed in
http://wiki.openembedded.org/index.php/OpenEmbeddedJanitors simpler
(because less recipes need to be looked at).

As it stands the job is not done. I've mainly peeked at all recipes
that had more than 10 versions.

I did not touch core directories like gcc, glibc/uclibc/eglibc,
binutils, although I feel some pruging of old stuff would be useful
there. E.g. is there still a use for gcc 4.1.0 ? )
Then again these are typically well maintained and looked after, so
there are probably hardly any issues that would require cleanup.

I also stayed away from core recipes like linux and u-boot (although I
can imagine some version scould be deprecated. Also the policy on when
to create a different recipe and when to modify an existing one is
vague at best.
Some harmonisation would be nice.

Then there are the opie dirs: bluelightning told me he would look into
this and expire the older versions.

X related stuff was also left untouched JaMa told me he was looking into that.

And I skipped the ti dir. I would propose the ti people look into it.
E.g. is there a need for 12 ti-xdctools recipes, 5 of wihch are pinned
(and yeah, I understand that these probably are closely linked to a
codec engine version, still 12 seems from a process point of view
quite a lot)

Anyway, if there are issues because of this action, or if you feel
removal of a recipe was not in accordance with the TSC guidelines, let
me know and I'll repair.

Have fun!
Frans

Re: cleaning recipes

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

Dear Frans,


Am Sonntag, den 15.08.2010, 16:59 +0200 schrieb Frans Meulenbroeks:

> As some of you might have noticed I've been cleaning up our
> recipes.during the last week or so.
> As I had some time at hand this weekend, lots of cleaning has been done.
> I did my very best to stay within the guidelines of the TSC (as
> described in http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/020047.html),
> but it is quite possible that at some point I made a mistake or so.
> If so, let me know and I'll repair things and/or revert the commit. (I
> feel if you make a mess you should also clean it yourself).

thank you for doing this “boring” and unrewarding(?) task. I appreciate
it.

In your commit summary I would just have listed the removed version, so
people wondering where it had gone, could see it in the log more easily.
But I guess everyone knows how to search for the recipe name and look
what that commit changed.

[…]


Thanks,

Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: cleaning recipes

[Mike Westerhof]

Frans Meulenbroeks wrote:
> Dear all,
> 
> As some of you might have noticed I've been cleaning up our
> recipes.during the last week or so.
...
> Anyway, if there are issues because of this action, or if you feel
> removal of a recipe was not in accordance with the TSC guidelines, let
> me know and I'll repair.

(This is NOT how I read the TSC guidelines, but I'm tired of arguing
with your obsession!)

Frankly, the issue isn't if YOU put back a missing recipe, or I do it.
I know how to use an SCM tool, it's about 30 seconds -- or less -- to do
it.  The problem, as I've mentioned before, is in finding that to be the
issue, of course.

What distros (and their package feeds) have you built to test your
assumptions?

> Have fun!

Well, thank you for your wishes.  But to be honest, it's more fun when I
can focus on fixing REAL problems, rather than worrying about artificial
ones introduced for no really useful reason -- although I understand
that you vehemently and stubbornly disagree.  I guess you win this
point, so it's fun for you at least!

> Frans
-Mike (mwester)

Re: cleaning recipes

[Frans Meulenbroeks]

2010/8/16 Mike Westerhof <mike@mwester.net>:
> Frans Meulenbroeks wrote:
>> Dear all,
>>
>> As some of you might have noticed I've been cleaning up our
>> recipes.during the last week or so.
> ...
>> Anyway, if there are issues because of this action, or if you feel
>> removal of a recipe was not in accordance with the TSC guidelines, let
>> me know and I'll repair.
>
> (This is NOT how I read the TSC guidelines, but I'm tired of arguing
> with your obsession!)

Well here's what the TSC said about it:

<quote>
Removing old versions
=====================
The TSC looked into the topic of when to remove versions.


The TSC thinks there can not be a general rule of when to delete
a package. The TSC believes that in some cases a package should
never be deleted, e.g. with GCC/GLIBC to target a specific device
or distribution. For a series of major releases it seems plausible
to only keep the latest minor release of each release series around
given that the quality should increase with each minor release but
a removal of a minor release should not be done if there is a
PREFERRED_VERSION set. The TSC believes that 24 months can be a good
time to remove old major releases but it is certainly not the only
criteria for a removal.
</quote>

I've taken great care not to remove versions that are pinned by a
distro or that have a DEFAULT_PREFERENCE on them.
(but I cannot guarantee that I did not make a mistake). Also i avoided
deleting recent major releases (although major release is sometimes
something that is not too well defined).
I feel I did my best to stay within the guidelines of TSC, but if I
failed miserably to do so, I guess the TSC will tell me so (and I hope
they will be kind enough to accept a few things that have slipped).

>
> Frankly, the issue isn't if YOU put back a missing recipe, or I do it.
> I know how to use an SCM tool, it's about 30 seconds -- or less -- to do
> it.  The problem, as I've mentioned before, is in finding that to be the
> issue, of course.
>
> What distros (and their package feeds) have you built to test your
> assumptions?
>
>> Have fun!
>
> Well, thank you for your wishes.  But to be honest, it's more fun when I
> can focus on fixing REAL problems, rather than worrying about artificial
> ones introduced for no really useful reason -- although I understand
> that you vehemently and stubbornly disagree.  I guess you win this
> point, so it's fun for you at least!

Well it would help if recipe maintainers would do their thing and
clean up things instead of leaving a trail of old (and often broken)
recipes.

E.g. we've decided to abandon legacy staging and where possible go to
BBCLASSEXTEND = "native".
Unfortunately I see only few people taking action despite several
calls for action.
At least one of the reasons seem to be the large amount of recipes to
be converted. This is also due to the large trail of old versions we
keep around.
At least my action reduced the number of recipes to be looked at. Both
the amount of native recipes and the amount of recipes that use legacy
staging is reduced.

Instead of complaining about my actions, perhaps first answer the
question what you have done?
E.g. how many recipes have you converted from legacy staging? How many
recipes converted to BBCLASSEXTEND?
At least I *do* something, trying to bring this to manageable proportions.

But ofc I guess there is a good reason not to convert e.g.
upslug2-native, and that there are good reasons to keep 3 different
versions around, or to have upslug-native with do_stage.
I don't mind having a few versions around as long as they are useful
and maintained. However for a lot of recipes this does not seem to be
the case. People just add new versions leaving a trail of old junk.
Junk which is sometimes even dangerous (e.g. in case of the
openssh/openssl/openvpn recipes, where the old versions have known
security vulnerabilities.
If the recipe owners did their thing, this would not be needed (but
unfortunately the case is that some maintainers don't do their thing,
and that lots of other recipes are orphaned)

Leaving my soapbox. Have a nice day!
Frans.

Re: cleaning recipes

[Mike Westerhof]

Frans Meulenbroeks wrote:
...
> Anyway, if there are issues because of this action, or if you feel
> removal of a recipe was not in accordance with the TSC guidelines, let
> me know and I'll repair.

Well, here's the first one, docbook-sgml-dtd-3.1-native, full log below:

. ./setup-env; exec bitbake -k "slugos-packages"
NOTE: Handling BitBake files: / (7840/7840) [100 %]
NOTE: Parsing finished. 7266 cached, 496 parsed, 78 skipped, 1 masked.
NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for u-boot (u-boot, u-boot-omap3pandora);
NOTE: consider defining PREFERRED_PROVIDER_u-boot
ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-linux-gnueabi-gcc-2.95' but it wasn't found in any PACKAGE or RPROVIDES variables
NOTE: Runtime target 'virtual/arm-linux-gnueabi-gcc-2.95' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['virtual/arm-linux-gnueabi-gcc-2.95']
ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-linux-gnueabi-depmod-' but it wasn't found in any PACKAGE or RPROVIDES variables
NOTE: Runtime target 'virtual/arm-linux-gnueabi-depmod-' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['virtual/arm-linux-gnueabi-depmod-']
ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-linux-gnueabi-depmod-1.0' but it wasn't found in any PACKAGE or RPROVIDES variables
NOTE: Runtime target 'virtual/arm-linux-gnueabi-depmod-1.0' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['virtual/arm-linux-gnueabi-depmod-1.0']
NOTE: Runtime target 'iputils-arping' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['iputils-arping', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
NOTE: Runtime target 'task-proper-tools' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['task-proper-tools', 'iputils-arping', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
NOTE: Runtime target 'iputils-ping6' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['iputils-ping6', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
NOTE: Runtime target 'iputils-ping' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['iputils-ping', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
NOTE: Runtime target 'iputils' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['iputils', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'docbook-sgml-dtd-3.1-native' but it wasn't found in any PACKAGE or RPROVIDES variables
NOTE: Runtime target 'docbook-sgml-dtd-3.1-native' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['docbook-sgml-dtd-3.1-native']
NOTE: Preparing runqueue
ERROR: All buildable tasks have been run but the build is incomplete (--continue mode). Errors for the tasks that failed will have been printed above.


-Mike (mwester)

Re: cleaning recipes

[Khem Raj]

On (15/08/10 23:25), Mike Westerhof wrote:
> Frans Meulenbroeks wrote:
> ...
> > Anyway, if there are issues because of this action, or if you feel
> > removal of a recipe was not in accordance with the TSC guidelines, let
> > me know and I'll repair.
> 
> Well, here's the first one, docbook-sgml-dtd-3.1-native, full log below:


heh I am running into same problem  when building from scratch :) This is my temporary fix that I am
building with now at least it goes thru parse stage. I havent looked the
effects of bumping up this dependency version yet. May be its ok may be it
is wrong.

diff --git a/recipes/docbook-utils/docbook-utils-native_0.6.14.bb
b/recipes/docbook-utils/docbook-utils-native_0.6.14.bb
index 595aa50..52c2ebb 100644
--- a/recipes/docbook-utils/docbook-utils-native_0.6.14.bb
+++ b/recipes/docbook-utils/docbook-utils-native_0.6.14.bb
@@ -3,7 +3,7 @@ LICENSE = "GPL"
 
 PR = "r2"
 
-DEPENDS = "openjade-native sgmlspl-native docbook-dsssl-stylesheets-native docbook-sgml-dtd-3.1-native"
+DEPENDS = "openjade-native sgmlspl-native docbook-dsssl-stylesheets-native docbook-sgml-dtd-4.4-native"
 
 SRC_URI = "ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES/docbook-utils-${PV}.tar.gz"
 S = "${WORKDIR}/docbook-utils-${PV}"

> 
> . ./setup-env; exec bitbake -k "slugos-packages"
> NOTE: Handling BitBake files: / (7840/7840) [100 %]
> NOTE: Parsing finished. 7266 cached, 496 parsed, 78 skipped, 1 masked.
> NOTE: Resolving any missing task queue dependencies
> NOTE: multiple providers are available for u-boot (u-boot, u-boot-omap3pandora);
> NOTE: consider defining PREFERRED_PROVIDER_u-boot
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-linux-gnueabi-gcc-2.95' but it wasn't found in any PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'virtual/arm-linux-gnueabi-gcc-2.95' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['virtual/arm-linux-gnueabi-gcc-2.95']
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-linux-gnueabi-depmod-' but it wasn't found in any PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'virtual/arm-linux-gnueabi-depmod-' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['virtual/arm-linux-gnueabi-depmod-']
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-linux-gnueabi-depmod-1.0' but it wasn't found in any PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'virtual/arm-linux-gnueabi-depmod-1.0' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['virtual/arm-linux-gnueabi-depmod-1.0']
> NOTE: Runtime target 'iputils-arping' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['iputils-arping', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> NOTE: Runtime target 'task-proper-tools' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['task-proper-tools', 'iputils-arping', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> NOTE: Runtime target 'iputils-ping6' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['iputils-ping6', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> NOTE: Runtime target 'iputils-ping' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['iputils-ping', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> NOTE: Runtime target 'iputils' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['iputils', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'docbook-sgml-dtd-3.1-native' but it wasn't found in any PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'docbook-sgml-dtd-3.1-native' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['docbook-sgml-dtd-3.1-native']
> NOTE: Preparing runqueue
> ERROR: All buildable tasks have been run but the build is incomplete (--continue mode). Errors for the tasks that failed will have been printed above.
> 
> 
> -Mike (mwester)
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: cleaning recipes

[Frans Meulenbroeks]

2010/8/16 Khem Raj <raj.khem@gmail.com>:
> On (15/08/10 23:25), Mike Westerhof wrote:
>> Frans Meulenbroeks wrote:
>> ...
>> > Anyway, if there are issues because of this action, or if you feel
>> > removal of a recipe was not in accordance with the TSC guidelines, let
>> > me know and I'll repair.
>>
>> Well, here's the first one, docbook-sgml-dtd-3.1-native, full log below:
>
>
> heh I am running into same problem  when building from scratch :) This is my temporary fix that I am
> building with now at least it goes thru parse stage. I havent looked the
> effects of bumping up this dependency version yet. May be its ok may be it
> is wrong.
>
> diff --git a/recipes/docbook-utils/docbook-utils-native_0.6.14.bb
> b/recipes/docbook-utils/docbook-utils-native_0.6.14.bb
> index 595aa50..52c2ebb 100644
> --- a/recipes/docbook-utils/docbook-utils-native_0.6.14.bb
> +++ b/recipes/docbook-utils/docbook-utils-native_0.6.14.bb
> @@ -3,7 +3,7 @@ LICENSE = "GPL"
>
>  PR = "r2"
>
> -DEPENDS = "openjade-native sgmlspl-native docbook-dsssl-stylesheets-native docbook-sgml-dtd-3.1-native"
> +DEPENDS = "openjade-native sgmlspl-native docbook-dsssl-stylesheets-native docbook-sgml-dtd-4.4-native"
>
>  SRC_URI = "ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES/docbook-utils-${PV}.tar.gz"
>  S = "${WORKDIR}/docbook-utils-${PV}"
>

Seems a nice patch to me.
If desired also feel free to revert my removal patch.
Apparently I overlooked the case where recipes could DEPEND on
specific versions of a recipe.

There are probably a few more cases of this (easily identified as
bitbake will complain immediately if it bumps into one of these).
I'll peek at it tonight.

And wrt everyone hit by this: my apologies.
but hey: that is the risk if you want to live on the edge

Have fun! Frans

Re: cleaning recipes

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 3773 bytes --]

Hi,
I added this docbook stuff once. My source to understand how it is to be
built was linuxfromscratch.org. So one should have a look at this
again I think.

Chaning the version of the DTD should be fine. If it is incompatible you
would get loads of errors. :-)

Regards
Robert

Am 16.08.2010 06:25, schrieb Mike Westerhof:
> Frans Meulenbroeks wrote:
> ...
>   
>> Anyway, if there are issues because of this action, or if you feel
>> removal of a recipe was not in accordance with the TSC guidelines, let
>> me know and I'll repair.
>>     
> Well, here's the first one, docbook-sgml-dtd-3.1-native, full log below:
>
> . ./setup-env; exec bitbake -k "slugos-packages"
> NOTE: Handling BitBake files: / (7840/7840) [100 %]
> NOTE: Parsing finished. 7266 cached, 496 parsed, 78 skipped, 1 masked.
> NOTE: Resolving any missing task queue dependencies
> NOTE: multiple providers are available for u-boot (u-boot, u-boot-omap3pandora);
> NOTE: consider defining PREFERRED_PROVIDER_u-boot
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-linux-gnueabi-gcc-2.95' but it wasn't found in any PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'virtual/arm-linux-gnueabi-gcc-2.95' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['virtual/arm-linux-gnueabi-gcc-2.95']
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-linux-gnueabi-depmod-' but it wasn't found in any PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'virtual/arm-linux-gnueabi-depmod-' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['virtual/arm-linux-gnueabi-depmod-']
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/arm-linux-gnueabi-depmod-1.0' but it wasn't found in any PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'virtual/arm-linux-gnueabi-depmod-1.0' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['virtual/arm-linux-gnueabi-depmod-1.0']
> NOTE: Runtime target 'iputils-arping' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['iputils-arping', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> NOTE: Runtime target 'task-proper-tools' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['task-proper-tools', 'iputils-arping', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> NOTE: Runtime target 'iputils-ping6' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['iputils-ping6', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> NOTE: Runtime target 'iputils-ping' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['iputils-ping', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> NOTE: Runtime target 'iputils' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['iputils', 'docbook-utils-native', 'docbook-sgml-dtd-3.1-native']
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'docbook-sgml-dtd-3.1-native' but it wasn't found in any PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'docbook-sgml-dtd-3.1-native' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['docbook-sgml-dtd-3.1-native']
> NOTE: Preparing runqueue
> ERROR: All buildable tasks have been run but the build is incomplete (--continue mode). Errors for the tasks that failed will have been printed above.
>
>
> -Mike (mwester)
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>   



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

Re: cleaning recipes

[Koen Kooi]

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

You removed the default openssl version (0.9.8) without bumping PR for
recipes using that, so now my autobuilder is quite red due to do_rootfs
failures (among other build errors related to these removals).

I can really see how the quality of OE has increased due to removing
things. Good job.

On 15-08-10 16:59, Frans Meulenbroeks wrote:
> Dear all,
> 
> As some of you might have noticed I've been cleaning up our
> recipes.during the last week or so.
> As I had some time at hand this weekend, lots of cleaning has been done.
> I did my very best to stay within the guidelines of the TSC (as
> described in http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/020047.html),
> but it is quite possible that at some point I made a mistake or so.
> If so, let me know and I'll repair things and/or revert the commit. (I
> feel if you make a mess you should also clean it yourself).
> 
> Rationale for doing so is that it makes the tasks as listed in
> http://wiki.openembedded.org/index.php/OpenEmbeddedJanitors simpler
> (because less recipes need to be looked at).
> 
> As it stands the job is not done. I've mainly peeked at all recipes
> that had more than 10 versions.
> 
> I did not touch core directories like gcc, glibc/uclibc/eglibc,
> binutils, although I feel some pruging of old stuff would be useful
> there. E.g. is there still a use for gcc 4.1.0 ? )
> Then again these are typically well maintained and looked after, so
> there are probably hardly any issues that would require cleanup.
> 
> I also stayed away from core recipes like linux and u-boot (although I
> can imagine some version scould be deprecated. Also the policy on when
> to create a different recipe and when to modify an existing one is
> vague at best.
> Some harmonisation would be nice.
> 
> Then there are the opie dirs: bluelightning told me he would look into
> this and expire the older versions.
> 
> X related stuff was also left untouched JaMa told me he was looking into that.
> 
> And I skipped the ti dir. I would propose the ti people look into it.
> E.g. is there a need for 12 ti-xdctools recipes, 5 of wihch are pinned
> (and yeah, I understand that these probably are closely linked to a
> codec engine version, still 12 seems from a process point of view
> quite a lot)
> 
> Anyway, if there are issues because of this action, or if you feel
> removal of a recipe was not in accordance with the TSC guidelines, let
> me know and I'll repair.
> 
> Have fun!
> Frans

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

iD8DBQFMaP2uMkyGM64RGpERAjOWAJ9WJm8HhlfSwAgnQW2aBl8l8T0a7wCfebXQ
QBgE1zdw4WyTi9THZfejd2A=
=GUgf
-----END PGP SIGNATURE-----

Re: cleaning recipes

[Frans Meulenbroeks]

2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You removed the default openssl version (0.9.8) without bumping PR for
> recipes using that, so now my autobuilder is quite red due to do_rootfs
> failures (among other build errors related to these removals).

I will reinstate openssl 0.9.8
conf did not show any pinning but i missed the DEFAULT_PREFERENCE = "-1' in 1.0
seems a good plan to upgrade to 0.9.8o though as it fixes some
security vulnerabilities

Frans

Re: cleaning recipes

[Frans Meulenbroeks]

2010/8/16 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> 2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> You removed the default openssl version (0.9.8) without bumping PR for
>> recipes using that, so now my autobuilder is quite red due to do_rootfs
>> failures (among other build errors related to these removals).
>
> I will reinstate openssl 0.9.8
> conf did not show any pinning but i missed the DEFAULT_PREFERENCE = "-1' in 1.0
> seems a good plan to upgrade to 0.9.8o though as it fixes some
> security vulnerabilities
>

reverted the commit for removal of 0.9.8
I was unaware that a PR bump of recipes using another recipe needed to be done.

Best regards, Frans

Re: cleaning recipes

[Koen Kooi]

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

On 16-08-10 11:30, Frans Meulenbroeks wrote:
> 2010/8/16 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>> 2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> You removed the default openssl version (0.9.8) without bumping PR for
>>> recipes using that, so now my autobuilder is quite red due to do_rootfs
>>> failures (among other build errors related to these removals).
>>
>> I will reinstate openssl 0.9.8
>> conf did not show any pinning but i missed the DEFAULT_PREFERENCE = "-1' in 1.0
>> seems a good plan to upgrade to 0.9.8o though as it fixes some
>> security vulnerabilities
>>
> 
> reverted the commit for removal of 0.9.8
> I was unaware that a PR bump of recipes using another recipe needed to be done.

For libraries, certainly, as in this case SOVERSION changed, so the
resulting packagenames changes from
libssl0.9.8_0.9.8m-r12.0.5_armv7a.ipk to
libssl1.0.0_1.0.0-r12.2.5_armv7a.ipk. OE removes the first one, but
other packages still have it in DEPENDS.

And if SOVERSION doesn't change, bumping PR for dependant recipes is
needed for things that statically link to it (or even dynamically in
some case).

The ffmpeg recipes try to list the know offenders that break when
updating SRCREV, but I guess a bitbake tool (e.g. 'bitbake whatdepends
foo') would be nice for these kinds of things.

regards,

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

iD8DBQFMaRD0MkyGM64RGpERAusfAKCt0gfi9pt4VrKRIxthFlERfigcNQCghvNK
nyqESj8sCFlsPMyBoUaqraw=
=cX4G
-----END PGP SIGNATURE-----

Re: cleaning recipes

[Frans Meulenbroeks]

2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 16-08-10 11:30, Frans Meulenbroeks wrote:
>> 2010/8/16 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>>> 2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> You removed the default openssl version (0.9.8) without bumping PR for
>>>> recipes using that, so now my autobuilder is quite red due to do_rootfs
>>>> failures (among other build errors related to these removals).
>>>
>>> I will reinstate openssl 0.9.8
>>> conf did not show any pinning but i missed the DEFAULT_PREFERENCE = "-1' in 1.0
>>> seems a good plan to upgrade to 0.9.8o though as it fixes some
>>> security vulnerabilities
>>>
>>
>> reverted the commit for removal of 0.9.8
>> I was unaware that a PR bump of recipes using another recipe needed to be done.
>
> For libraries, certainly, as in this case SOVERSION changed, so the
> resulting packagenames changes from
> libssl0.9.8_0.9.8m-r12.0.5_armv7a.ipk to
> libssl1.0.0_1.0.0-r12.2.5_armv7a.ipk. OE removes the first one, but
> other packages still have it in DEPENDS.
>
> And if SOVERSION doesn't change, bumping PR for dependant recipes is
> needed for things that statically link to it (or even dynamically in
> some case).

Tanks for the explanation.
It would be nice if oe would detect those cases and force a rebuild.
>
> The ffmpeg recipes try to list the know offenders that break when
> updating SRCREV, but I guess a bitbake tool (e.g. 'bitbake whatdepends
> foo') would be nice for these kinds of things.

I've asked before about something like that, forgot why it was not
easy/possible.
i also did try a bitbake -g world to get a list of deps, but that also
failed for some reason.

I would expect that if you have the recipes in a parsed format, it
should not be overly difficult.
Anyhow, my pythonese is too limited to implement something like that.

Frans

Re: cleaning recipes

[Koen Kooi]

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

On 16-08-10 13:10, Frans Meulenbroeks wrote:
> 2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 16-08-10 11:30, Frans Meulenbroeks wrote:
>>> 2010/8/16 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
>>>> 2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> You removed the default openssl version (0.9.8) without bumping PR for
>>>>> recipes using that, so now my autobuilder is quite red due to do_rootfs
>>>>> failures (among other build errors related to these removals).
>>>>
>>>> I will reinstate openssl 0.9.8
>>>> conf did not show any pinning but i missed the DEFAULT_PREFERENCE = "-1' in 1.0
>>>> seems a good plan to upgrade to 0.9.8o though as it fixes some
>>>> security vulnerabilities
>>>>
>>>
>>> reverted the commit for removal of 0.9.8
>>> I was unaware that a PR bump of recipes using another recipe needed to be done.
>>
>> For libraries, certainly, as in this case SOVERSION changed, so the
>> resulting packagenames changes from
>> libssl0.9.8_0.9.8m-r12.0.5_armv7a.ipk to
>> libssl1.0.0_1.0.0-r12.2.5_armv7a.ipk. OE removes the first one, but
>> other packages still have it in DEPENDS.
>>
>> And if SOVERSION doesn't change, bumping PR for dependant recipes is
>> needed for things that statically link to it (or even dynamically in
>> some case).
> 
> Tanks for the explanation.
> It would be nice if oe would detect those cases and force a rebuild.

That doesn't help if you're using packagemanagement. Now you have
"foo_1.0-r0.ipk" in the feeds that statically linked to openssl 0.9.8
and "foo_1.0-r0.ipk" locally that statically links to 1.0.0. So users
still don't get the fixes that went into openssl.

regards,

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

iD8DBQFMaSKgMkyGM64RGpERAix5AJ4zlAIGz7P1C0RyH72fldJXE641lQCbB6XD
13E4ujSzXcPoW94ZdaqE9Ek=
=LGlu
-----END PGP SIGNATURE-----

Re: cleaning recipes

[Frans Meulenbroeks]

2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
would be nice if oe would detect those cases and force a rebuild.
>
> That doesn't help if you're using packagemanagement. Now you have
> "foo_1.0-r0.ipk" in the feeds that statically linked to openssl 0.9.8
> and "foo_1.0-r0.ipk" locally that statically links to 1.0.0. So users
> still don't get the fixes that went into openssl.

Agree.
I vaguely recall an idea (I believe from RP) to have a hash or so
derived from the whole dependency tree below it.
This discussion probably ran somewhere last winter.

Frans

Re: cleaning recipes

[Graeme Gregory]

 On 16/08/10 13:14, Frans Meulenbroeks wrote:
> 2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
> would be nice if oe would detect those cases and force a rebuild.
>> That doesn't help if you're using packagemanagement. Now you have
>> "foo_1.0-r0.ipk" in the feeds that statically linked to openssl 0.9.8
>> and "foo_1.0-r0.ipk" locally that statically links to 1.0.0. So users
>> still don't get the fixes that went into openssl.
> Agree.
> I vaguely recall an idea (I believe from RP) to have a hash or so
> derived from the whole dependency tree below it.
> This discussion probably ran somewhere last winter.
>
> Frans
>
A quick implementation would sum all PR in depends tree above us.

Graeme

Re: cleaning recipes

[Frans Meulenbroeks]

2010/8/16 Graeme Gregory <dp@xora.org.uk>:
>  On 16/08/10 13:14, Frans Meulenbroeks wrote:
>> 2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
>> would be nice if oe would detect those cases and force a rebuild.
>>> That doesn't help if you're using packagemanagement. Now you have
>>> "foo_1.0-r0.ipk" in the feeds that statically linked to openssl 0.9.8
>>> and "foo_1.0-r0.ipk" locally that statically links to 1.0.0. So users
>>> still don't get the fixes that went into openssl.
>> Agree.
>> I vaguely recall an idea (I believe from RP) to have a hash or so
>> derived from the whole dependency tree below it.
>> This discussion probably ran somewhere last winter.
>>
>> Frans
>>
> A quick implementation would sum all PR in depends tree above us.
>
> Graeme
>

That would be an elegant and simple solution.
There is a minor issue with it wrt lettering (but I guess these can be
skipped) and maybe cvs/svn/git numbers (i seem to recall some of these
are not monotonic).
A more difficult issue is if a dependency is removed. Then suddenly
the number will drop. The only solution I see right away is manually
add an offset to the recipe to accomodate for this (but it is not
really a nice solution).

Frans

Re: cleaning recipes

[Graeme Gregory]

 On 16/08/10 20:38, Frans Meulenbroeks wrote:
> 2010/8/16 Graeme Gregory <dp@xora.org.uk>:
>>  On 16/08/10 13:14, Frans Meulenbroeks wrote:
>>> 2010/8/16 Koen Kooi <k.kooi@student.utwente.nl>:
>>> would be nice if oe would detect those cases and force a rebuild.
>>>> That doesn't help if you're using packagemanagement. Now you have
>>>> "foo_1.0-r0.ipk" in the feeds that statically linked to openssl 0.9.8
>>>> and "foo_1.0-r0.ipk" locally that statically links to 1.0.0. So users
>>>> still don't get the fixes that went into openssl.
>>> Agree.
>>> I vaguely recall an idea (I believe from RP) to have a hash or so
>>> derived from the whole dependency tree below it.
>>> This discussion probably ran somewhere last winter.
>>>
>>> Frans
>>>
>> A quick implementation would sum all PR in depends tree above us.
>>
>> Graeme
>>
> That would be an elegant and simple solution.
> There is a minor issue with it wrt lettering (but I guess these can be
> skipped) and maybe cvs/svn/git numbers (i seem to recall some of these
> are not monotonic).
> A more difficult issue is if a dependency is removed. Then suddenly
> the number will drop. The only solution I see right away is manually
> add an offset to the recipe to accomodate for this (but it is not
> really a nice solution).
>
I never was a fan of the git rev being in the PR and Phil Blundell
checked in a method we can use to avoid this but is not used by any
distro so far AFAIK.

Graeme

Re: cleaning recipes

[Marc Olzheim]

On Sun, Aug 15, 2010 at 04:59:17PM +0200, Frans Meulenbroeks wrote:
> As some of you might have noticed I've been cleaning up our
> recipes.during the last week or so.
> As I had some time at hand this weekend, lots of cleaning has been done.
> I did my very best to stay within the guidelines of the TSC (as
> described in http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/020047.html),
> but it is quite possible that at some point I made a mistake or so.
> If so, let me know and I'll repair things and/or revert the commit. (I
> feel if you make a mess you should also clean it yourself).

Hmm, the "guidelines" do not mention anything about licenses. Thus the
only version you left of coreutils after
82dcd385984ba059b346a0e37fd3e14d536074ad is infected with GPLv3, while
the older (6.0) GPLv2 version works fine for us.  I do not know
whether other people mind about licenses, but we cannot use any GPLv3
software in our image, because of its viral nature.

Marc

Re: cleaning recipes

[Frans Meulenbroeks]

2010/8/16 Marc Olzheim <zlo@zlo.nu>:
> On Sun, Aug 15, 2010 at 04:59:17PM +0200, Frans Meulenbroeks wrote:
>> As some of you might have noticed I've been cleaning up our
>> recipes.during the last week or so.
>> As I had some time at hand this weekend, lots of cleaning has been done.
>> I did my very best to stay within the guidelines of the TSC (as
>> described in http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/020047.html),
>> but it is quite possible that at some point I made a mistake or so.
>> If so, let me know and I'll repair things and/or revert the commit. (I
>> feel if you make a mess you should also clean it yourself).
>
> Hmm, the "guidelines" do not mention anything about licenses. Thus the
> only version you left of coreutils after
> 82dcd385984ba059b346a0e37fd3e14d536074ad is infected with GPLv3, while
> the older (6.0) GPLv2 version works fine for us.  I do not know
> whether other people mind about licenses, but we cannot use any GPLv3
> software in our image, because of its viral nature.
>
> Marc

Valid point.
I did not consider licenses. Although the company I work for has no
problems with GPLv2, I understand your concern
What would be the most recent version of coreutils that is still using v2?
We can reinstate that one.

Thanks alot for your feedback.
Frans

Re: cleaning recipes

[Marc Olzheim]

On Mon, Aug 16, 2010 at 03:43:10PM +0200, Frans Meulenbroeks wrote:
> > Hmm, the "guidelines" do not mention anything about licenses. Thus the
> > only version you left of coreutils after
> > 82dcd385984ba059b346a0e37fd3e14d536074ad is infected with GPLv3, while
> > the older (6.0) GPLv2 version works fine for us.  I do not know
> > whether other people mind about licenses, but we cannot use any GPLv3
> > software in our image, because of its viral nature.
> >
> > Marc
> 
> Valid point.
> I did not consider licenses. Although the company I work for has no
> problems with GPLv2, I understand your concern
> What would be the most recent version of coreutils that is still using v2?
> We can reinstate that one.

In the case of coreutils, that is 6.0.
GPLv2 is ok here as well. The problem with GPLv3 here is that as soon as
we incorporate some GPLv3 package we need to provide the abilitiy for
customers to rebuild their image (Right to Tinker), which we cannot and
will not do.

> Thanks alot for your feedback.
> Frans

No problem, if I encounter any other license issues I'll let you know.

Marc

Re: cleaning recipes

[Koen Kooi]

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

On 16-08-10 16:00, Marc Olzheim wrote:
> On Mon, Aug 16, 2010 at 03:43:10PM +0200, Frans Meulenbroeks wrote:
>>> Hmm, the "guidelines" do not mention anything about licenses. Thus the
>>> only version you left of coreutils after
>>> 82dcd385984ba059b346a0e37fd3e14d536074ad is infected with GPLv3, while
>>> the older (6.0) GPLv2 version works fine for us.  I do not know
>>> whether other people mind about licenses, but we cannot use any GPLv3
>>> software in our image, because of its viral nature.
>>>
>>> Marc
>>
>> Valid point.
>> I did not consider licenses. Although the company I work for has no
>> problems with GPLv2, I understand your concern
>> What would be the most recent version of coreutils that is still using v2?
>> We can reinstate that one.
> 
> In the case of coreutils, that is 6.0.
> GPLv2 is ok here as well. The problem with GPLv3 here is that as soon as
> we incorporate some GPLv3 package we need to provide the abilitiy for
> customers to rebuild their image (Right to Tinker), which we cannot and
> will not do.

And the patent clause isn't fun if your company has tons of IP in that
area (like mine).

regards,

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

iD8DBQFMaWgWMkyGM64RGpERAg6PAJ4+ANeicD6Iwz5VOFF7FXwBNIdtXgCeMZKK
Ue6O0IThYTeDJ8RcCKbwIjE=
=Rn2H
-----END PGP SIGNATURE-----

Re: cleaning recipes

[Frans Meulenbroeks]

2010/8/16 Marc Olzheim <zlo@zlo.nu>:

>
> In the case of coreutils, that is 6.0.
> GPLv2 is ok here as well. The problem with GPLv3 here is that as soon as
> we incorporate some GPLv3 package we need to provide the abilitiy for
> customers to rebuild their image (Right to Tinker), which we cannot and
> will not do.

I do understand the implications of v3 too well. My previous employer
also didn't want GPLv3 in their products for IPR reasons.

I've reverted the coreutils removal and re-removed 7.1 and 7.2, so 6.0
is still there.
As you have an interest in this recipe you might be interested to move
to 6.9 (which seems the last GPLv2 version).
Also I would greatly appreciate it if you could see if you can move
the recipe to BBCLASSEXTEND = "native"
And this
do_install() {
        autotools_do_install
}
can also go as it inherits autotools

Frans