[RFC] make preferred openssl version match for -native recipe

[RFC] make preferred openssl version match for -native recipe

[Mike (mwester)]

I'd like to propose that we remove the "DEFAULT_PREFERENCE = "-1"" line
from openssl-native_0.9.8j.bb.

This is causing a problem in select cases (for example, python-native
fails "import md5"), because we build and stage openssl 0.9.8j, but the
corresponding -native that gets built and staged is openssl 0.9.7g.

The 0.9.8j version is currently selected as the PREFERRED_VERSION in the
preferred-om-2008-versions.inc file, as well as for SlugOS.  I've
successfully built it on both 32 and 64 bit hosts.

Unless there are objections, I'll commit a fix in a couple of days.

Regards,
Mike (mwester)

Re: [RFC] make preferred openssl version match for -native recipe

[Tom Rini]

On Mon, Mar 30, 2009 at 09:26:56PM -0500, Mike (mwester) wrote:
> I'd like to propose that we remove the "DEFAULT_PREFERENCE = "-1"" line
> from openssl-native_0.9.8j.bb.
> 
> This is causing a problem in select cases (for example, python-native
> fails "import md5"), because we build and stage openssl 0.9.8j, but the
> corresponding -native that gets built and staged is openssl 0.9.7g.
> 
> The 0.9.8j version is currently selected as the PREFERRED_VERSION in the
> preferred-om-2008-versions.inc file, as well as for SlugOS.  I've
> successfully built it on both 32 and 64 bit hosts.
> 
> Unless there are objections, I'll commit a fix in a couple of days.

Perhaps we should also make sure anyplace that defines a preferred
provide for one sets the same version for the other (with an appropriate
poke to the maintainer) ?

-- 
Tom Rini

Re: [RFC] make preferred openssl version match for -native recipe

[Henning Heinold]

Hi,

by the way the latest version is 0.9.8k with security fixes.

Bye Henning

Re: [RFC] make preferred openssl version match for -native recipe

[Mike (mwester)]

Mike (mwester) wrote:
> I'd like to propose that we remove the "DEFAULT_PREFERENCE = "-1"" line
> from openssl-native_0.9.8j.bb.
> 
> This is causing a problem in select cases (for example, python-native
> fails "import md5"), because we build and stage openssl 0.9.8j, but the
> corresponding -native that gets built and staged is openssl 0.9.7g.
> 
> The 0.9.8j version is currently selected as the PREFERRED_VERSION in the
> preferred-om-2008-versions.inc file, as well as for SlugOS.  I've
> successfully built it on both 32 and 64 bit hosts.
> 
> Unless there are objections, I'll commit a fix in a couple of days.

Fix committed. (To dev, not to the new stable branch.)

WARNING!  The "correct" thing to do would probably be to bump up the PR
on all recipes that might include, directly or indirectly, openssh libs
-- thus forcing them all to link against the new version...

However, that seemed to be an awful lot of packages, and given that at
least some of the distros already have over-rides to select matching
versions for openssl and openssl-native, this would seem to cause more
problems than it would solve.

So anticipate that your builds may fail if a new version of openssl is
built; the failure mode would be the inability for the app to find the
old version of the library in the staging area.

Quite frankly, I found it easier to just blow away tmpdir on the
nslu2-linux autobuilders; they needed a fresh start anyway. ;-)

And now python-native works correctly.

Regards,
Mike (mwester)

Re: [RFC] make preferred openssl version match for -native recipe

[Koen Kooi]

On 02-04-09 05:03, Mike (mwester) wrote:
> Mike (mwester) wrote:
>> I'd like to propose that we remove the "DEFAULT_PREFERENCE = "-1"" line
>> from openssl-native_0.9.8j.bb.
>>
>> This is causing a problem in select cases (for example, python-native
>> fails "import md5"), because we build and stage openssl 0.9.8j, but the
>> corresponding -native that gets built and staged is openssl 0.9.7g.
>>
>> The 0.9.8j version is currently selected as the PREFERRED_VERSION in the
>> preferred-om-2008-versions.inc file, as well as for SlugOS.  I've
>> successfully built it on both 32 and 64 bit hosts.
>>
>> Unless there are objections, I'll commit a fix in a couple of days.
>
> Fix committed. (To dev, not to the new stable branch.)
>
> WARNING!  The "correct" thing to do would probably be to bump up the PR
> on all recipes that might include, directly or indirectly, openssh libs
> -- thus forcing them all to link against the new version...
>
> However, that seemed to be an awful lot of packages, and given that at
> least some of the distros already have over-rides to select matching
> versions for openssl and openssl-native, this would seem to cause more
> problems than it would solve.
>
> So anticipate that your builds may fail if a new version of openssl is
> built; the failure mode would be the inability for the app to find the
> old version of the library in the staging area.

You mean like this: 
/OE/angstrom-dev/staging/x86_64-linux/usr/bin/edje_cc: error while 
loading shared libraries: libssl.so.0.9.7: cannot open shared object 
file: No such file or directory

Could you please do things properly and bump PR for the affected recipes?

Re: [RFC] make preferred openssl version match for -native recipe

[Mike (mwester)]

Koen Kooi wrote:
> On 02-04-09 05:03, Mike (mwester) wrote:
>> Mike (mwester) wrote:
>>> I'd like to propose that we remove the "DEFAULT_PREFERENCE = "-1"" line
>>> from openssl-native_0.9.8j.bb.
>>>
>>> This is causing a problem in select cases (for example, python-native
>>> fails "import md5"), because we build and stage openssl 0.9.8j, but the
>>> corresponding -native that gets built and staged is openssl 0.9.7g.
>>>
>>> The 0.9.8j version is currently selected as the PREFERRED_VERSION in the
>>> preferred-om-2008-versions.inc file, as well as for SlugOS.  I've
>>> successfully built it on both 32 and 64 bit hosts.
>>>
>>> Unless there are objections, I'll commit a fix in a couple of days.
>>
>> Fix committed. (To dev, not to the new stable branch.)
>>
>> WARNING!  The "correct" thing to do would probably be to bump up the PR
>> on all recipes that might include, directly or indirectly, openssh libs
>> -- thus forcing them all to link against the new version...
>>
>> However, that seemed to be an awful lot of packages, and given that at
>> least some of the distros already have over-rides to select matching
>> versions for openssl and openssl-native, this would seem to cause more
>> problems than it would solve.
>>
>> So anticipate that your builds may fail if a new version of openssl is
>> built; the failure mode would be the inability for the app to find the
>> old version of the library in the staging area.
> 
> You mean like this:
> /OE/angstrom-dev/staging/x86_64-linux/usr/bin/edje_cc: error while
> loading shared libraries: libssl.so.0.9.7: cannot open shared object
> file: No such file or directory
> 
> Could you please do things properly and bump PR for the affected recipes?

I explained why I didn't.

I appreciate your comment, none-the-less; to be honest, I fixed this for
SlugOS and was happy with the result for me.  I was instructed to fix
this for everyone at the behest of one of the other core devs, despite
my misgivings over the disruption such a change would have -- disruption
that would have happened one way or another, regardless of whether I
bumped every ^&&^*&#%! PR in OE.

So clearly my initial thought was correct -- only the core members are
permitted to break anything.

Your feedback is filed, and will be prominently displayed (in commit
notices if necessary) to justify my preferred practice of making
SlugOS-private fixes.

Have a nice day.

Mike (mwester)

Re: [RFC] make preferred openssl version match for -native recipe

[Koen Kooi]

On 02-04-09 16:05, Mike (mwester) wrote:
> Koen Kooi wrote:
>> On 02-04-09 05:03, Mike (mwester) wrote:
>>> Mike (mwester) wrote:
>>>> I'd like to propose that we remove the "DEFAULT_PREFERENCE = "-1"" line
>>>> from openssl-native_0.9.8j.bb.
>>>>
>>>> This is causing a problem in select cases (for example, python-native
>>>> fails "import md5"), because we build and stage openssl 0.9.8j, but the
>>>> corresponding -native that gets built and staged is openssl 0.9.7g.
>>>>
>>>> The 0.9.8j version is currently selected as the PREFERRED_VERSION in the
>>>> preferred-om-2008-versions.inc file, as well as for SlugOS.  I've
>>>> successfully built it on both 32 and 64 bit hosts.
>>>>
>>>> Unless there are objections, I'll commit a fix in a couple of days.
>>>
>>> Fix committed. (To dev, not to the new stable branch.)
>>>
>>> WARNING!  The "correct" thing to do would probably be to bump up the PR
>>> on all recipes that might include, directly or indirectly, openssh libs
>>> -- thus forcing them all to link against the new version...
>>>
>>> However, that seemed to be an awful lot of packages, and given that at
>>> least some of the distros already have over-rides to select matching
>>> versions for openssl and openssl-native, this would seem to cause more
>>> problems than it would solve.
>>>
>>> So anticipate that your builds may fail if a new version of openssl is
>>> built; the failure mode would be the inability for the app to find the
>>> old version of the library in the staging area.
>>
>> You mean like this:
>> /OE/angstrom-dev/staging/x86_64-linux/usr/bin/edje_cc: error while
>> loading shared libraries: libssl.so.0.9.7: cannot open shared object
>> file: No such file or directory
>>
>> Could you please do things properly and bump PR for the affected recipes?
>
> I explained why I didn't.
>
> I appreciate your comment, none-the-less; to be honest, I fixed this for
> SlugOS and was happy with the result for me.  I was instructed to fix
> this for everyone at the behest of one of the other core devs, despite
> my misgivings over the disruption such a change would have -- disruption
> that would have happened one way or another, regardless of whether I
> bumped every ^&&^*&#%! PR in OE.
>
> So clearly my initial thought was correct -- only the core members are
> permitted to break anything.
>
> Your feedback is filed, and will be prominently displayed (in commit
> notices if necessary) to justify my preferred practice of making
> SlugOS-private fixes.

distro private != properly

Re: [RFC] make preferred openssl version match for -native recipe

[Jeremy Lainé]

>> So anticipate that your builds may fail if a new version of openssl is
>> built; the failure mode would be the inability for the app to find the
>> old version of the library in the staging area.

Some packages fail in a very un-obvious way, most notably "python-native" which will spew
the following error:

ImportError: No module named _md5

So far, I have found the following commonly used packages which need rebuilding:

cmake-native
python-native
git-native

Cheers,
-- 
Jeremy LAINE
Bolloré telecom | 11bis, rue Scribe | F-75009 Paris

Re: [RFC] make preferred openssl version match for -native recipe

[Mike (mwester)]

Koen Kooi wrote:

> distro private != properly

Ah, I see.  The clear conclusion is that unless I fix it "properly"
(defined by whom?), I should not fix it at all.

Very well.


Mike (mwester)