Bug 513316 – dev-libs/openssl-{0.9.8z_p1-r2,1.0.1h-r2} and deps stable request

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Michał Górny 2014-06-15 09:39:15 UTC]

In order to avoid constant reverting of openssl multilib that breaks multilib systems, I'd like to make it possibly to easily stabilize future versions of openssl. For this reason, we'd need the following packages stable:

=dev-libs/openssl-0.9.8z_p1-r2 # alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=dev-libs/openssl-1.0.1h-r2    # alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=app-crypt/mit-krb5-1.12.1-r1  * alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=dev-libs/libverto-0.2.5-r1    # alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=dev-libs/libev-4.15-r1        #       amd64 arm hppa ia64 ppc ppc64 sparc x86
=dev-libs/libevent-2.0.21-r2   $ alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=sys-libs/tevent-0.9.21-r1     * alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=sys-libs/talloc-2.1.0-r1      # alpha amd64 arm hppa ia64 ppc ppc64 sparc x86

Packages marked as '#' have the same version stable already, so the only change is the multilib support (and the flag is usually masked, so you need only to check if it didn't break regular build).

Packages marked as '$' had earlier revision stable, so it's multilib + some other changes (USE=debug added in case of libevent).

Packages marked as '*' involve stabilizing a new version along with multilib support. If you believe the new version shouldn't go stable, please let me know and I'll backport multilib to a earlier one.

I've already committed all necessary package.use.stable.mask changes, and repoman is happy to stabilize them all for me. Please note, however, that this involves stabilizing circular dependency between openssl & libevent :).

@Maintainers, please let me know if the listed versions are fine to go stable. I'll CC arches then.

[Comment 1 Jeroen Roovers (RETIRED) 2014-06-15 12:32:05 UTC]

(In reply to Michał Górny from comment #0)
> =dev-libs/libevent-2.0.21-r2   $ alpha amd64 arm hppa ia64 ppc ppc64 sparc
> x86

I don't see why you'd pick that one. -r1 has been around longer, fits what you want to do, and should be good to go stable right now.

[Comment 2 Michał Górny 2014-06-15 12:44:50 UTC]

(In reply to Jeroen Roovers from comment #1)
> (In reply to Michał Górny from comment #0)
> > =dev-libs/libevent-2.0.21-r2   $ alpha amd64 arm hppa ia64 ppc ppc64 sparc
> > x86
> 
> I don't see why you'd pick that one. -r1 has been around longer, fits what
> you want to do, and should be good to go stable right now.

Ah, sorry, I read the diff the other way and thought -r1 was not multilib.

New list then:

=dev-libs/openssl-0.9.8z_p1-r2 # alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=dev-libs/openssl-1.0.1h-r2    # alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=app-crypt/mit-krb5-1.12.1-r1  * alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=dev-libs/libverto-0.2.5-r1    # alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=dev-libs/libev-4.15-r1        #       amd64 arm hppa ia64 ppc ppc64 sparc x86
=dev-libs/libevent-2.0.21-r1   $ alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=sys-libs/tevent-0.9.21-r1     * alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
=sys-libs/talloc-2.1.0-r1      # alpha amd64 arm hppa ia64 ppc ppc64 sparc x86

[Comment 3 Pacho Ramos 2014-07-05 11:07:42 UTC]

I guess this is being finally handled at bug 512506? (not sure if make this a duplicate... :/)

[Comment 4 Pacho Ramos 2014-07-06 18:40:20 UTC]

(In reply to Pacho Ramos from comment #3)
> I guess this is being finally handled at bug 512506? (not sure if make this
> a duplicate... :/)

No, it was for non-multilib versions

But I don't see why is this depending in bug 512506...

[Comment 5 Pacho Ramos 2014-07-18 19:33:31 UTC]

Will handle the remaining arches in parent bug as it's preferred by Ago and this can wait for those arches until the rest is done

*** This bug has been marked as a duplicate of bug 512012 ***