On Wed, 2020-09-16 at 12:41 -0500, Michael Catanzaro wrote:
> On Wed, Sep 16, 2020 at 1:37 pm, Simo Sorce wrote:
> > note that one of the dependencies is gnome-vfs2, itself a dependency
> > for libgnome, which is a dependency for another dozen packages.
> >
> > All of them will likely go away
Ok, I'll just do the first layer and let the process work. I'll send an
announcement to devel outside this thread.
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with ProtonMail Secure
On Wed, 2020-09-16 at 18:26 +, Gwyn Ciesla wrote:
> I don't mind doing so. Just for the first layer of dependencies? Does someone
> have the deeper tree handy?
I only have part of it from the gnome-vfs2 side:
$ repoquery --releasever=33 --whatrequires gnome-vfs2
girl-0:10.0.0-10.fc33.x86_64
I don't mind doing so. Just for the first layer of dependencies? Does someone
have the deeper tree handy?
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with ProtonMail Secure Email.
On Wed, 2020-09-16 at 12:41 -0500, Michael Catanzaro wrote:
> On Wed, Sep 16, 2020 at 1:37 pm, Simo Sorce wrote:
> > note that one of the dependencies is gnome-vfs2, itself a dependency
> > for libgnome, which is a dependency for another dozen packages.
> >
> > All of them will likely go away
On Wed, Sep 16, 2020 at 1:37 pm, Simo Sorce wrote:
note that one of the dependencies is gnome-vfs2, itself a dependency
for libgnome, which is a dependency for another dozen packages.
All of them will likely go away because gnome-vfs2 is unlikely to be
changed.
I looked over the dependency
note that one of the dependencies is gnome-vfs2, itself a dependency
for libgnome, which is a dependency for another dozen packages.
All of them will likely go away because gnome-vfs2 is unlikely to be
changed.
Simo.
On Wed, 2020-09-16 at 12:56 -0400, Simo Sorce wrote:
> Do we need a more
Do we need a more involved plan than filing bugs for those packages and
let them drop if they do not react ?
I mean they are using very old dependencies, there are probably many
other ways in which they are broken at this point.
Simo.
On Wed, 2020-09-16 at 16:37 +, Gwyn Ciesla via devel
I'm the compat-openssl10 owner. I've updated kqoauth-qt5 and sipp, but the rest
are more involved. We need a plan for each package to be patched, updated to a
version supporting modern openssl, or retired.
--
Gwyn Ciesla
she/her/hers
in your
On Wed, 2020-09-16 at 14:58 +0200, Miro Hrončok wrote:
> On 16. 09. 20 14:29, Simo Sorce wrote:
> > Indeed compat-openssl10 really should go.
> > If there are still packages depending on it they should be ported or
> > dropped at this point.
> > Openssl1.0.2 is unmaintained upstream and only
On 16. 09. 20 14:29, Simo Sorce wrote:
Indeed compat-openssl10 really should go.
If there are still packages depending on it they should be ported or
dropped at this point.
Openssl1.0.2 is unmaintained upstream and only critical security fixes
are done in RHEL. But the team that handles them
On Wed, 2020-09-16 at 12:28 +0200, Tomas Mraz wrote:
> On Tue, 2020-09-15 at 19:33 +0200, Miro Hrončok wrote:
> > On 15. 09. 20 19:26, Tomas Mraz wrote:
> > > What is more important? Consistency between those two compat
> > > packages
> > > or strictly following the naming rules for the new
On Tue, 2020-09-15 at 19:33 +0200, Miro Hrončok wrote:
> On 15. 09. 20 19:26, Tomas Mraz wrote:
> > What is more important? Consistency between those two compat
> > packages
> > or strictly following the naming rules for the new package?
>
> Why not both? I.e. renaming compat-openssl10 to
On 16. 09. 20 9:55, Peter Robinson wrote:
On Wed, Sep 16, 2020 at 8:11 AM Miro Hrončok wrote:
On 16. 09. 20 2:20, Neal Gompa wrote:
Something that Mageia and openSUSE do sometimes is just not ship a
-devel package if the library is only there for runtime backwards
compatibility. That's
On Wed, Sep 16, 2020 at 8:11 AM Miro Hrončok wrote:
>
> On 16. 09. 20 2:20, Neal Gompa wrote:
> > Something that Mageia and openSUSE do sometimes is just not ship a
> > -devel package if the library is only there for runtime backwards
> > compatibility. That's something we could do for openssl1.0
On 16. 09. 20 2:20, Neal Gompa wrote:
Something that Mageia and openSUSE do sometimes is just not ship a
-devel package if the library is only there for runtime backwards
compatibility. That's something we could do for openssl1.0 and
eventually openssl1.1.
IIRC Tomas attempted to do this twice
On Tue, Sep 15, 2020 at 6:35 PM Michel Alexandre Salim
wrote:
>
> On Tue, 2020-09-15 at 14:10 -0400, Simo Sorce wrote:
> > On Tue, 2020-09-15 at 13:46 -0400, Neal Gompa wrote:
> > >
> > > The compat- prefix is no longer allowed. Instead we should be using
> > > versioned package names.
> >
> >
On Tue, 2020-09-15 at 14:10 -0400, Simo Sorce wrote:
> On Tue, 2020-09-15 at 13:46 -0400, Neal Gompa wrote:
> >
> > The compat- prefix is no longer allowed. Instead we should be using
> > versioned package names.
>
> Why?
> The "compat-" prefix clearly indicated the .so was provided
>
On Tue, Sep 15, 2020 at 2:29 PM Michael Catanzaro wrote:
>
> On Tue, Sep 15, 2020 at 1:46 pm, Neal Gompa wrote:
> > openssl1.0
>
> It reached EOL in December 2019. Probably time to remove it from Fedora?
>
Ideally, yes, but I think some things still use it, and I think it
tracks the RHEL 7
On Tue, Sep 15, 2020 at 1:46 pm, Neal Gompa wrote:
openssl1.0
It reached EOL in December 2019. Probably time to remove it from Fedora?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Tue, 2020-09-15 at 13:46 -0400, Neal Gompa wrote:
> On Tue, Sep 15, 2020 at 1:36 PM Nathanael D. Noblet wrote:
> > On Tue, 2020-09-15 at 19:26 +0200, Tomas Mraz wrote:
> > > I've submitted a new compat-openssl11 package for review but it was
> > > pointed out to me that according to the new
On Tue, 2020-09-15 at 13:46 -0400, Neal Gompa wrote:
> On Tue, Sep 15, 2020 at 1:36 PM Nathanael D. Noblet
> > My 2 cents would be consistency. If others disagree, perhaps
> > compat-
> > openssl10 should be renamed to compat-openssl1.0 and obsolete the
> > old
> > compat-openssl10? Its annoying
On Tue, Sep 15, 2020 at 1:36 PM Nathanael D. Noblet wrote:
>
> On Tue, 2020-09-15 at 19:26 +0200, Tomas Mraz wrote:
> > I've submitted a new compat-openssl11 package for review but it was
> > pointed out to me that according to the new format of the naming for
> > compat packages it should be
On Tue, 2020-09-15 at 19:26 +0200, Tomas Mraz wrote:
> I've submitted a new compat-openssl11 package for review but it was
> pointed out to me that according to the new format of the naming for
> compat packages it should be named openssl1.1. However there already
> is
> a compat-openssl10
On 15. 09. 20 19:26, Tomas Mraz wrote:
What is more important? Consistency between those two compat packages
or strictly following the naming rules for the new package?
Why not both? I.e. renaming compat-openssl10 to openssl1.0 while packaging
openssl1.1?
Note that I've always considered
On Tue, Sep 15, 2020 at 1:27 PM Tomas Mraz wrote:
>
> Hi Fedora developers,
>
> we need to introduce temporarily a compat package for OpenSSL as it is
> going to be rebased to the 3.0 version in Rawhide once the 3.0 release
> is stable.
>
> The 3.0 version should not break API from the 1.1.1, it
Hi Fedora developers,
we need to introduce temporarily a compat package for OpenSSL as it is
going to be rebased to the 3.0 version in Rawhide once the 3.0 release
is stable.
The 3.0 version should not break API from the 1.1.1, it just breaks the
ABI, so rebuilds should be quite easy. Of course
27 matches
Mail list logo
