Re: only 4 packages left Re: Let's retire original glib and gtk+ (new report)

[Richard Shaw]

On Thu, Mar 17, 2022 at 12:16 AM Sérgio Basto  wrote:

> xconvers (maintained by: hobbes1069)
> xconvers-0.8.3-29.fc36.x86_64 requires libglib-1.2.so.0()(64bit)
>
> still only available on aur and Fedora
> https://repology.org/project/xconvers/versions


This can probably be retired. I'll check on the Fedora Linux Hams mailing
list and see if there's any response.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: only 4 packages left Re: Let's retire original glib and gtk+ (new report)

[Petr Pisar]

V Thu, Mar 17, 2022 at 08:36:55AM -, Leigh Scott napsal(a):
> > On Thu, 2022-03-10 at 00:15 +0200, Otto Urpelainen wrote:
> > xvattr (maintained by: ppisar, thias)
> > gxvattr-1.3-44.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib-
> > 1.2.so.0()(64bit), libgtk-1.2.so.0()(64bit)
> > 
> > seems xvattr can be build with gtk2 
> > http://sophie.zarb.org/rpms/88281125c921a2cc60abf2eea23e54de/deps
> 
I disabled GTK in xvattr-1.3-45.fc37.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: only 4 packages left Re: Let's retire original glib and gtk+ (new report)

[Leigh Scott]

> On Thu, 2022-03-10 at 00:15 +0200, Otto Urpelainen wrote:
> 
> Continuing I brought the corrections to Fedora 36 
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-db793ad26c
> 
> Now only 4 packages more gtk1+ depends on glib 
> 
> Depending packages (rawhide) (5): bubblemon gtk+ manedit xconvers
> xvattr
> 
> Depending on: glib (5), 
> 
> bubblemon (maintained by: sham1)
> bubblemon-1.46-31.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
> libgmodule-1.2.so.0()(64bit)
> 
> seems that can be build with gtk2
> https://gitweb.gentoo.org/repo/gentoo.git/tree/x11-plugins/bubblemon/bubb...

Who needs a gtk1 or 2 applet, is there any gtk1 based DE'S?

> 
> xvattr (maintained by: ppisar, thias)
> gxvattr-1.3-44.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib-
> 1.2.so.0()(64bit), libgtk-1.2.so.0()(64bit)
> 
> seems xvattr can be build with gtk2 
> http://sophie.zarb.org/rpms/88281125c921a2cc60abf2eea23e54de/deps


Have you tried gxvattr?, it's completely broken, the gui is unusable even if 
it's ported to gtk2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

only 4 packages left Re: Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

On Thu, 2022-03-10 at 00:15 +0200, Otto Urpelainen wrote:
> Leigh Scott kirjoitti 9.3.2022 klo 18.15:
> > > Sérgio Basto kirjoitti 7.3.2022 klo 18.17:
> > > Crossfire and freedroidrpg are games, so "is it needed?" and
> > > "does it
> > > have a replacement?" are not good questions to ask. A better
> > > question
> > > would be "does anybody want to play it?". Games do not really ever
> > > become obsolete, each is a unique experience and cannot be replaced
> > > by a
> > > "modern alternative to X with more features".
> > > 
> > > Personally, I have never played either of these games, and I
> > > suspect I
> > > will not ever play them. Retiring them is probably not a great loss
> > > to
> > > Fedora. But, if there is no pressing reason, security issue, lack
> > > of
> > > maintainer or such, to retire the compatibility lib, I would prefer
> > > to
> > > keep all the games that somebody is willing to maintain.
> > > 
> > > 
> > > Otto
> > 
> > Both those games don't use gtk+-devel.
> 
> Thank you for looking that up, and even more for fixing the packages.

Continuing I brought the corrections to Fedora 36 
https://bodhi.fedoraproject.org/updates/FEDORA-2022-db793ad26c

Now only 4 packages more gtk1+ depends on glib 

Depending packages (rawhide) (5): bubblemon gtk+ manedit xconvers
xvattr

Depending on: glib (5), 

bubblemon (maintained by: sham1)
bubblemon-1.46-31.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)

seems that can be build with gtk2
https://gitweb.gentoo.org/repo/gentoo.git/tree/x11-plugins/bubblemon/bubblemon-1.46-r3.ebuild

xvattr (maintained by: ppisar, thias)
gxvattr-1.3-44.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib-
1.2.so.0()(64bit), libgtk-1.2.so.0()(64bit)

seems xvattr can be build with gtk2 
http://sophie.zarb.org/rpms/88281125c921a2cc60abf2eea23e54de/deps


manedit (maintained by: pali)
manedit-1.2.1-27.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)

(manedit have replacment with https://tracker.debian.org/pkg/gmanedit

xconvers (maintained by: hobbes1069)
xconvers-0.8.3-29.fc36.x86_64 requires libglib-1.2.so.0()(64bit)

still only available on aur and Fedora 
https://repology.org/project/xconvers/versions 

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Bill Nottingham]

Peter Boy (p...@uni-bremen.de) said: 
> And, by the way, it is one of Linux’s (and Fedora Linux’s) core
> distinguishing features that it does not follow the short-term commercial
> life cycles, but enables long-term usability, for "old" hardware as well
> as software.  And we should not give that up lightly and without need. 

I don't think removing something that has not been the main supported
library version for literally *20 years* is caving to short-term
It's not caving to short-term commercial lifecycles to remove something
that has been the obsoleted library version for literally *20 years*.

It has been obsolete for longer than any Fedora supported architecture
has existed.

Bill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Otto Urpelainen]

Leigh Scott kirjoitti 9.3.2022 klo 18.15:

Sérgio Basto kirjoitti 7.3.2022 klo 18.17:
Crossfire and freedroidrpg are games, so "is it needed?" and
"does it
have a replacement?" are not good questions to ask. A better question
would be "does anybody want to play it?". Games do not really ever
become obsolete, each is a unique experience and cannot be replaced by a
"modern alternative to X with more features".

Personally, I have never played either of these games, and I suspect I
will not ever play them. Retiring them is probably not a great loss to
Fedora. But, if there is no pressing reason, security issue, lack of
maintainer or such, to retire the compatibility lib, I would prefer to
keep all the games that somebody is willing to maintain.


Otto


Both those games don't use gtk+-devel.


Thank you for looking that up, and even more for fixing the packages.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Leigh Scott]

> On Tue, 2022-03-08 at 16:01 +, Leigh Scott wrote:
> 
> Hi Leigh ,
> yes , it looks like glib-devel is not needed , I'm curious , how do you
> find these mistakes ? 
> 
> Thank you

I checked the built rpm requires and did mock test builds.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Leigh Scott]

> Sérgio Basto kirjoitti 7.3.2022 klo 18.17:
> Crossfire and freedroidrpg are games, so "is it needed?" and
> "does it 
> have a replacement?" are not good questions to ask. A better question 
> would be "does anybody want to play it?". Games do not really ever 
> become obsolete, each is a unique experience and cannot be replaced by a 
> "modern alternative to X with more features".
> 
> Personally, I have never played either of these games, and I suspect I 
> will not ever play them. Retiring them is probably not a great loss to 
> Fedora. But, if there is no pressing reason, security issue, lack of 
> maintainer or such, to retire the compatibility lib, I would prefer to 
> keep all the games that somebody is willing to maintain.
> 
> 
> Otto

Both those games don't use gtk+-devel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 08, 2022 at 05:51:35PM +, Richard W.M. Jones wrote:
> On Tue, Mar 08, 2022 at 01:41:30AM +0100, Kevin Kofler via devel wrote:
> > Michael Catanzaro wrote:
> > > The maintainer is unwilling to retire them.
> > > 
> > > I think we should ask FESCo to force them to be retired. It's confusing
> > > to have ancient versions of the packages in the distro, and they will
> > > stick around forever if not.
> > 
> > I do not see why we would want to force removing working, maintained 
> > packages from the distribution. That is a major disservice to users and 
> > basically a "screw you" to the maintainer. Whom does that help?
> > 
> > GLib 1 and GTK+ 1 are compatibility libraries. It is their whole purpose to 
> > "stick around forever", at least as long as somebody is willing to maintain 
> > them. They are needed to keep legacy applications working.
> > 
> > If FESCo wants to get involved at all (I do not really see any need for 
> > them 
> > to intervene in the first place), I ask FESCo to affirm that a 
> > compatibility 
> > library can remain in the distribution as long as it is maintained and to 
> > ask people to refrain from posting unhelpful threads such as this one.
> > 
> > Nobody is asking you to maintain those packages, so I do not see why you 
> > need to care at all about their existence.
> 
> Could they be renamed "glib1", etc?  That would remove any confusion
> that they cause with the latest glib, and as Kevin says above they can
> then be ignored by people who don't care about them.

Or at least the description changed to make it obvious that they
aren't-the-library-you-are-looking-for most of the time.

Right now glib %description is:

  GLib is a handy library of utility functions. This C library is
  designed to solve some portability problems and provide other useful
  functionality that most programs require.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

On Tue, 2022-03-08 at 16:01 +, Leigh Scott wrote:
> > On Mon, 07 Mar 2022 10:29:02 -0600
> > Michael Catanzaro  > 
> > 
> > I'm not unwilling to retire them, I just want their users to be
> > retired
> > first so I don't leave a bunch of broken dependencies behind.
> > 
> > Paul.
> 
> dillo, alsa-tools, gnubg,  and tilda don't rely on glib or gtk+, the
> package maintainers have made mistakes.

Hi Leigh ,
yes , it looks like glib-devel is not needed , I'm curious , how do you
find these mistakes ? 

Thank you 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

On Wed, 2022-03-09 at 08:20 +0200, Otto Urpelainen wrote:
> Sérgio Basto kirjoitti 7.3.2022 klo 18.17:
> > Hi,
> > In resume glib still required for 20 packages  [1],
> > apart of the sweet memories that some package bring to us , any of
> > these packages is needed ? or haven't replacement ?
> > 
> > Depending packages (rawhide) (20): crossfire crossfire-client
> > crossfire-maps
> > freedroidrpg

> Crossfire and freedroidrpg are games, so "is it needed?" and "does it
> have a replacement?" are not good questions to ask. 

ok , IMO games don't have replacement , unless we have the same game in
other platform . 

> A better question
> would be "does anybody want to play it?". 

yes 

> Games do not really ever 
> become obsolete, each is a unique experience and cannot be replaced
> by a 
> "modern alternative to X with more features".
> 
> Personally, I have never played either of these games, and I suspect
> I 
> will not ever play them. Retiring them is probably not a great loss
> to 
> Fedora. But, if there is no pressing reason, security issue, lack of 
> maintainer or such, to retire the compatibility lib, I would prefer
> to 
> keep all the games that somebody is willing to maintain.
> 
> 
> Otto
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Otto Urpelainen]

Sérgio Basto kirjoitti 7.3.2022 klo 18.17:

Hi,
In resume glib still required for 20 packages  [1],
apart of the sweet memories that some package bring to us , any of
these packages is needed ? or haven't replacement ?

Depending packages (rawhide) (20): crossfire crossfire-client crossfire-maps
freedroidrpg
Crossfire and freedroidrpg are games, so "is it needed?" and "does it 
have a replacement?" are not good questions to ask. A better question 
would be "does anybody want to play it?". Games do not really ever 
become obsolete, each is a unique experience and cannot be replaced by a 
"modern alternative to X with more features".


Personally, I have never played either of these games, and I suspect I 
will not ever play them. Retiring them is probably not a great loss to 
Fedora. But, if there is no pressing reason, security issue, lack of 
maintainer or such, to retire the compatibility lib, I would prefer to 
keep all the games that somebody is willing to maintain.



Otto
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Richard W.M. Jones]

On Tue, Mar 08, 2022 at 01:41:30AM +0100, Kevin Kofler via devel wrote:
> Michael Catanzaro wrote:
> > The maintainer is unwilling to retire them.
> > 
> > I think we should ask FESCo to force them to be retired. It's confusing
> > to have ancient versions of the packages in the distro, and they will
> > stick around forever if not.
> 
> I do not see why we would want to force removing working, maintained 
> packages from the distribution. That is a major disservice to users and 
> basically a "screw you" to the maintainer. Whom does that help?
> 
> GLib 1 and GTK+ 1 are compatibility libraries. It is their whole purpose to 
> "stick around forever", at least as long as somebody is willing to maintain 
> them. They are needed to keep legacy applications working.
> 
> If FESCo wants to get involved at all (I do not really see any need for them 
> to intervene in the first place), I ask FESCo to affirm that a compatibility 
> library can remain in the distribution as long as it is maintained and to 
> ask people to refrain from posting unhelpful threads such as this one.
> 
> Nobody is asking you to maintain those packages, so I do not see why you 
> need to care at all about their existence.

Could they be renamed "glib1", etc?  That would remove any confusion
that they cause with the latest glib, and as Kevin says above they can
then be ignored by people who don't care about them.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Leigh Scott]

> On Mon, 07 Mar 2022 10:29:02 -0600
> Michael Catanzaro  
> 
> I'm not unwilling to retire them, I just want their users to be retired
> first so I don't leave a bunch of broken dependencies behind.
> 
> Paul.

dillo, alsa-tools, gnubg,  and tilda don't rely on glib or gtk+, the package 
maintainers have made mistakes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

On Tue, 2022-03-08 at 01:41 +0100, Kevin Kofler via devel wrote:
> Michael Catanzaro wrote:
> > The maintainer is unwilling to retire them.
> > 
> > I think we should ask FESCo to force them to be retired. It's
> > confusing
> > to have ancient versions of the packages in the distro, and they will
> > stick around forever if not.
> 
> I do not see why we would want to force removing working, maintained 
> packages from the distribution. That is a major disservice to users and
> basically a "screw you" to the maintainer. Whom does that help?
> 
> GLib 1 and GTK+ 1 are compatibility libraries. It is their whole
> purpose to 
> "stick around forever", at least as long as somebody is willing to
> maintain 
> them. They are needed to keep legacy applications working.
> 
> If FESCo wants to get involved at all (I do not really see any need for
> them 
> to intervene in the first place), I ask FESCo to affirm that a
> compatibility 
> library can remain in the distribution as long as it is maintained and
> to 
> ask people to refrain from posting unhelpful threads such as this one.
> 
> Nobody is asking you to maintain those packages, so I do not see why
> you 
> need to care at all about their existence.


Quote from the first email of this thread 

"any of these packages is needed ? or haven't replacement ?  " 



>     Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Peter Boy]

> Am 08.03.2022 um 01:41 schrieb Kevin Kofler via devel 
> :
> 
> I do not see why we would want to force removing working, maintained 
> packages from the distribution. That is a major disservice to users and 
> basically a "screw you" to the maintainer. Whom does that help?
> 
> GLib 1 and GTK+ 1 are compatibility libraries. It is their whole purpose to 
> "stick around forever", at least as long as somebody is willing to maintain 
> them. They are needed to keep legacy applications working.


1+++ IMHO

And, by the way, it is one of Linux’s (and Fedora Linux’s) core distinguishing 
features that it does not follow the short-term commercial life cycles, but 
enables long-term usability, for "old" hardware as well as software. And we 
should not give that up lightly and without need.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Kevin Kofler via devel]

Michael Catanzaro wrote:
> Broken dependencies will be automatically retired if they are not fixed
> within a certain time, so it's really OK to do this. The broken
> packages won't stick around forever: they will eventually get cleaned
> up.

In other words, leaf applications that end users care about will eventually 
get dropped as well (which is no surprise if you remove the library they 
depended on). I do not see how that is "really OK to do" in any way.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Kevin Kofler via devel]

Michael Catanzaro wrote:
> The maintainer is unwilling to retire them.
> 
> I think we should ask FESCo to force them to be retired. It's confusing
> to have ancient versions of the packages in the distro, and they will
> stick around forever if not.

I do not see why we would want to force removing working, maintained 
packages from the distribution. That is a major disservice to users and 
basically a "screw you" to the maintainer. Whom does that help?

GLib 1 and GTK+ 1 are compatibility libraries. It is their whole purpose to 
"stick around forever", at least as long as somebody is willing to maintain 
them. They are needed to keep legacy applications working.

If FESCo wants to get involved at all (I do not really see any need for them 
to intervene in the first place), I ask FESCo to affirm that a compatibility 
library can remain in the distribution as long as it is maintained and to 
ask people to refrain from posting unhelpful threads such as this one.

Nobody is asking you to maintain those packages, so I do not see why you 
need to care at all about their existence.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Michael Catanzaro]

On Mon, Mar 7 2022 at 04:48:27 PM +, Paul Howarth 
 wrote:
I'm not unwilling to retire them, I just want their users to be 
retired

first so I don't leave a bunch of broken dependencies behind.


Hi, sorry, maybe I misunderstood your previous statements.

Broken dependencies will be automatically retired if they are not fixed 
within a certain time, so it's really OK to do this. The broken 
packages won't stick around forever: they will eventually get cleaned 
up.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Paul Howarth]

On Mon, 07 Mar 2022 10:29:02 -0600
Michael Catanzaro  wrote:

> On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto 
>  wrote:
> > Hi,
> > In resume glib still required for 20 packages  [1],
> > apart of the sweet memories that some package bring to us , any of
> > these packages is needed ? or haven't replacement ?  
> 
> The maintainer is unwilling to retire them.
> 
> I think we should ask FESCo to force them to be retired. It's
> confusing to have ancient versions of the packages in the distro, and
> they will stick around forever if not.

I'm not unwilling to retire them, I just want their users to be retired
first so I don't leave a bunch of broken dependencies behind.

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Rahul Sundaram]

Hi

On Mon, Mar 7, 2022 at 11:29 AM Michael Catanzaro  wrote:

> On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto



> > Hi,
> > In resume glib still required for 20 packages  [1],
> > apart of the sweet memories that some package bring to us , any of
> > these packages is needed ? or haven't replacement ?
>
> The maintainer is unwilling to retire them.
>
> I think we should ask FESCo to force them to be retired. It's confusing
> to have ancient versions of the packages in the distro, and they will
> stick around forever if not
>

Instead of forcing a mandate to remove it, perhaps a migration to Copr
would be a better way out of this

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Adam Williamson]

On Mon, 2022-03-07 at 16:17 +, Sérgio Basto wrote:
> Hi, 
> In resume glib still required for 20 packages  [1],
> apart of the sweet memories that some package bring to us , any of
> these packages is needed ? or haven't replacement ? 
> 
> Thanks 
> 
> alsa-tools (maintained by: perex, timj)
> alsa-tools-1.2.5-3.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36
> alsa-tools-firmware-1.2.5-3.fc36.x86_64 requires alsa-firmware = 1.2.4-
> 6.fc36
> 
> alsa-firmware (maintained by: perex, timj)
> alsa-firmware-1.2.4-6.fc36.noarch requires alsa-tools-firmware = 1.2.5-
> 3.fc36

These two seem like they would need addressing. Presumably we could
drop some graphical thing from alsa-tools and keep the rest.
> 
> fvwm (maintained by: jhogarth, mcermak, pertusus, peter)
> fvwm-2.6.9-7.fc36.src requires libstroke-devel = 0.5.1-45.fc36
> fvwm-2.6.9-7.fc36.x86_64 requires libstroke.so.0()(64bit)

At least *somebody* was using fvwm as recently as F34:
https://www.reddit.com/r/Fedora/comments/ounk85/f34_ive_been_trying_different_wm_and_at_the/
so I guess we might care about them? There appears to be an vfwm3:
https://github.com/fvwmorg/fvwm3
with tagged 1.0.x releases, but I've no idea how
usable/popular/packageable that is.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Michael Catanzaro]

On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto 
 wrote:

Hi,
In resume glib still required for 20 packages  [1],
apart of the sweet memories that some package bring to us , any of
these packages is needed ? or haven't replacement ?


The maintainer is unwilling to retire them.

I think we should ask FESCo to force them to be retired. It's confusing 
to have ancient versions of the packages in the distro, and they will 
stick around forever if not.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Let's retire original glib and gtk+ (new report)

[Sérgio Basto]

Hi, 
In resume glib still required for 20 packages  [1],
apart of the sweet memories that some package bring to us , any of
these packages is needed ? or haven't replacement ? 

Thanks 

 [1]
Depending packages (rawhide) (20): NsCDE alsa-firmware alsa-tools
bubblemon crossfire crossfire-client crossfire-maps dillo
freedroidrpg fvwm gnubg gtk+ hikari librcc libstroke manedit tilda
xconvers xdialog xvattr


Package   (co)maintainersStatus Change
==
glib  pghmcfc, rdieter   229 weeks ago

The following packages require above mentioned packages:
Depending on: glib (20), status change: 2017-10-10 (229 weeks ago)
bubblemon (maintained by: sham1)
bubblemon-1.46-31.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)

gnubg (maintained by: limb)
gnubg-1:1.06.001-14.fc35.src requires glib-devel = 1:1.2.10-64.fc36

gtk+ (maintained by: pghmcfc, rdieter)
gtk+-1:1.2.10-98.fc36.i686 requires libglib-1.2.so.0, libgmodule-
1.2.so.0
gtk+-1:1.2.10-98.fc36.src requires glib-devel = 1:1.2.10-64.fc36
gtk+-1:1.2.10-98.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)
gtk+-devel-1:1.2.10-98.fc36.i686 requires glib-devel(x86-32) =
1:1.2.10-64.fc36, pkgconfig(glib) = 1.2.10
gtk+-devel-1:1.2.10-98.fc36.x86_64 requires glib-devel(x86-64) =
1:1.2.10-64.fc36, pkgconfig(glib) = 1.2.10

xvattr (maintained by: ppisar, thias)
gxvattr-1.3-44.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib-
1.2.so.0()(64bit), libgtk-1.2.so.0()(64bit)

hikari (maintained by: fnux, sway-sig)
hikari-2.3.3-2.fc36.src requires glib-devel = 1:1.2.10-64.fc36

librcc (maintained by: ivanromanov)
librcc-gtk+-0.2.12-20.fc36.i686 requires libgdk-1.2.so.0, libglib-
1.2.so.0, libgmodule-1.2.so.0, libgtk-1.2.so.0
librcc-gtk+-0.2.12-20.fc36.x86_64 requires libgdk-1.2.so.0()(64bit),
libglib-1.2.so.0()(64bit), libgmodule-1.2.so.0()(64bit), libgtk-
1.2.so.0()(64bit)

manedit (maintained by: pali)
manedit-1.2.1-27.fc36.x86_64 requires libglib-1.2.so.0()(64bit),
libgmodule-1.2.so.0()(64bit)

tilda (maintained by: hannes, laxathom)
tilda-1.5.4-4.fc36.src requires glib-devel = 1:1.2.10-64.fc36

xconvers (maintained by: hobbes1069)
xconvers-0.8.3-29.fc36.x86_64 requires libglib-1.2.so.0()(64bit)

xdialog (maintained by: konradm)
xdialog-2.3.1-30.fc36.x86_64 requires libglib-1.2.so.0()(64bit)

alsa-tools (maintained by: perex, timj)
alsa-tools-1.2.5-3.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36
alsa-tools-firmware-1.2.5-3.fc36.x86_64 requires alsa-firmware = 1.2.4-
6.fc36

crossfire-client (maintained by: limb)
crossfire-client-1.75.2-2.fc36.src requires gtk+-devel = 1:1.2.10-
98.fc36

dillo (maintained by: aarem, atim)
dillo-3.0.5-14.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36

freedroidrpg (maintained by: limb)
freedroidrpg-1.0-0.fc37.rc2.8.src requires gtk+-devel = 1:1.2.10-
98.fc36

libstroke (maintained by: jhogarth, sophiekovalevsky)
libstroke-0.5.1-45.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36

alsa-firmware (maintained by: perex, timj)
alsa-firmware-1.2.4-6.fc36.noarch requires alsa-tools-firmware = 1.2.5-
3.fc36

crossfire (maintained by: limb)
crossfire-client-images-1.71.0-21.fc36.x86_64 requires crossfire-client
= 1.75.2-2.fc36

fvwm (maintained by: jhogarth, mcermak, pertusus, peter)
fvwm-2.6.9-7.fc36.src requires libstroke-devel = 0.5.1-45.fc36
fvwm-2.6.9-7.fc36.x86_64 requires libstroke.so.0()(64bit)

crossfire-maps (maintained by: limb)
crossfire-maps-1.71.0-12.fc36.noarch requires crossfire = 1.71.0-
21.fc36

NsCDE (maintained by: dcavalca)
NsCDE-1.4-2.fc36.src requires fvwm = 2.6.9-7.fc36
NsCDE-1.4-2.fc36.x86_64 requires fvwm = 2.6.9-7.fc36

Affected (co)maintainers
aarem: glib
atim: glib
dcavalca: glib
fnux: glib
hannes: glib
hobbes1069: glib
ivanromanov: glib
jhogarth: glib
konradm: glib
laxathom: glib
limb: glib
mcermak: glib
pali: glib
perex: glib
pertusus: glib
peter: glib
pghmcfc: glib
ppisar: glib
rdieter: glib
sham1: glib
sophiekovalevsky: glib
sway-sig: glib
thias: glib
timj: glib

Depending packages (rawhide) (20): NsCDE alsa-firmware alsa-tools
bubblemon crossfire crossfire-client crossfire-maps dillo
freedroidrpg fvwm gnubg gtk+ hikari librcc libstroke manedit tilda
xconvers xdialog xvattr


FTBFS (rawhide) (1): glib


FTBFS (rawhide) (depended on) (1): glib


FTBFS (rawhide) (not depended on) (0):

--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py

Report finished at 2022-03-07 16:01:58 UTC
Addresses (24): pghm...@fedoraproject.org, rdie...@fedoraproject.org,
sh...@fedoraproject.org, l...@fedoraproject.org,
ppi...@fedoraproject.org, th...@fedoraproject.org,
f...@fedoraproject.org, sway-...@fedoraproject.org,
ivanroma...@fedoraproject.org, p...@fedoraproject.org,
han...@fedoraproject.org, 

Re: Let's retire original glib and gtk+

[Jerry James]

On Fri, Jun 18, 2021 at 2:36 PM Jerry James  wrote:
> As far as I can tell, no Fedora package uses the gnomeui bindings in
> ocaml-lablgtk, so I'll arrange to drop the libgnomeui dependency in
> the next build of ocaml-lablgtk.

COPR builds of affected packages are here:

https://copr.fedorainfracloud.org/coprs/jjames/ocaml-lablgtk/

As soon as these 3 pull requests are merged, I will do all of the
necessary builds to purge the gnomeui bindings from ocaml-lablgtk:

https://src.fedoraproject.org/rpms/ocaml-cairo/pull-request/1
https://src.fedoraproject.org/rpms/ocaml-camlimages/pull-request/2
https://src.fedoraproject.org/rpms/ocaml-ocamlnet/pull-request/1

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Jerry James]

On Thu, Jun 17, 2021 at 9:46 AM Jerry James  wrote:
> Okay, that's good to know.  It looks like the gnomeui bindings in
> ocaml-lablgtk are optional.  I'll have to check whether anything
> sitting on top of ocaml-lablgtk uses those bindings.

As far as I can tell, no Fedora package uses the gnomeui bindings in
ocaml-lablgtk, so I'll arrange to drop the libgnomeui dependency in
the next build of ocaml-lablgtk.

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Jerry James]

On Thu, Jun 17, 2021 at 9:42 AM Michael Catanzaro  wrote:
> No, you need to drop the dependency on libgnomeui as well. That's been
> obsolete for over a decade now. If we manage to retire gconf2, that
> will go with it.

Okay, that's good to know.  It looks like the gnomeui bindings in
ocaml-lablgtk are optional.  I'll have to check whether anything
sitting on top of ocaml-lablgtk uses those bindings.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Michael Catanzaro]

On Thu, Jun 17 2021 at 09:29:52 AM -0600, Jerry James 
 wrote:

Got it.  None of the packages I listed depend directly on gconf2.
They seem to be on the list due to:

ocaml-lablgtk -> libgnomeui -> GConf2
  |
  ---> libgnome -> GConf2

which means no action is really needed for those packages, right?


No, you need to drop the dependency on libgnomeui as well. That's been 
obsolete for over a decade now. If we manage to retire gconf2, that 
will go with it.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Jerry James]

On Thu, Jun 17, 2021 at 6:58 AM Michael Catanzaro  wrote:
> Hi, nobody proposed removing gtk2. The problem there is gconf2. gtk2
> does not depend on gconf2.
>
> Packages to be retired:
>
>  * glib
>  * gtk+
>  * gconf2

Got it.  None of the packages I listed depend directly on gconf2.
They seem to be on the list due to:

ocaml-lablgtk -> libgnomeui -> GConf2
  |
  ---> libgnome -> GConf2

which means no action is really needed for those packages, right?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Michael Catanzaro]

Hi, nobody proposed removing gtk2. The problem there is gconf2. gtk2 
does not depend on gconf2.


Packages to be retired:

* glib
* gtk+
* gconf2

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

and Gconf2 ? Re: Let's retire original glib and gtk+

[Sérgio Basto]

On Wed, 2021-06-16 at 18:42 -0600, Jerry James wrote:
> Sorry, didn't see this when it first came through.
> 
> On Mon, May 31, 2021 at 4:18 AM Sérgio Basto  wrote:
> > I propose, for F36, the retire of Gconf2 (1)
> > 
> > dnf repoquery --disablerepo='*' \
> > --enablerepo={rpmfusion-{non,}free-,}rawhide --recursive \
> > --whatrequires "libgconf*" --qf "%{repoid} %{sourcerpm}"  -q
> 
> [snip]
> 
> > rawhide frama-c-22.0-10.fc35.src.rpm
> > rawhide ocaml-cairo-0.6.1-11.fc35.src.rpm
> > rawhide ocaml-camlimages-4.2.5-28.fc35.src.rpm
> > rawhide ocaml-dose3-5.0.1-32.20200502git24316fe.fc35.src.rpm
> > rawhide ocaml-lablgtk-2.18.11-6.fc35.src.rpm
> > rawhide ocaml-ocamlgraph-1.8.8-25.fc35.src.rpm
> > rawhide ocaml-ocamlnet-4.1.8-4.fc35.src.rpm
> > rawhide ocaml-xmlrpc-light-0.6.1-61.fc35.src.rpm
> 
> These packages are very useful, and have active upstreams.  They are
> all in the process of switching from gtk2 to gtk3, but haven't
> completed the transition yet.  The ocaml-cairo package, for example,
> is an OCaml interface to cairo.  It has a cairo-gtk subpackage for
> rendering cairo on a gtk2 canvas, and a cairo-pango subpackage for
> using pango with cairo in OCaml programs.  The ocaml-lablgtk3 package,
> which is an OCaml interface to gtk3, depends on the non-gtk2 parts of
> ocaml-cairo.
> 
> We might be able to excise the gtk2 parts of these packages, but it
> would not be simple, nor something that could be done overnight.  A
> little more time for the upstreams to make more progress would be
> greatly appreciated.

In this point, I think, is about replace Gconf2 by gsettings (1)


(1)
https://github.com/rawstudio/rawstudio/issues/61



-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Jerry James]

Sorry, didn't see this when it first came through.

On Mon, May 31, 2021 at 4:18 AM Sérgio Basto  wrote:
> I propose, for F36, the retire of Gconf2 (1)
>
> dnf repoquery --disablerepo='*' \
> --enablerepo={rpmfusion-{non,}free-,}rawhide --recursive \
> --whatrequires "libgconf*" --qf "%{repoid} %{sourcerpm}"  -q

[snip]

> rawhide frama-c-22.0-10.fc35.src.rpm
> rawhide ocaml-cairo-0.6.1-11.fc35.src.rpm
> rawhide ocaml-camlimages-4.2.5-28.fc35.src.rpm
> rawhide ocaml-dose3-5.0.1-32.20200502git24316fe.fc35.src.rpm
> rawhide ocaml-lablgtk-2.18.11-6.fc35.src.rpm
> rawhide ocaml-ocamlgraph-1.8.8-25.fc35.src.rpm
> rawhide ocaml-ocamlnet-4.1.8-4.fc35.src.rpm
> rawhide ocaml-xmlrpc-light-0.6.1-61.fc35.src.rpm

These packages are very useful, and have active upstreams.  They are
all in the process of switching from gtk2 to gtk3, but haven't
completed the transition yet.  The ocaml-cairo package, for example,
is an OCaml interface to cairo.  It has a cairo-gtk subpackage for
rendering cairo on a gtk2 canvas, and a cairo-pango subpackage for
using pango with cairo in OCaml programs.  The ocaml-lablgtk3 package,
which is an OCaml interface to gtk3, depends on the non-gtk2 parts of
ocaml-cairo.

We might be able to excise the gtk2 parts of these packages, but it
would not be simple, nor something that could be done overnight.  A
little more time for the upstreams to make more progress would be
greatly appreciated.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Orcan Ogetbil]

On Thu, 27 May 2021 at 11:55, Tom Callaway  wrote:
>
> FWIW, I have retired xmms. Upstream is long gone, and it was being held 
> together by spider-webs anyways.

Is there any copr where this is somewhat maintained? gtk+ was the best
gtk (yeah just because of xmms), it's sad to see it go.

Thanks,
Orcan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Sérgio Basto]

On Mon, 2021-05-31 at 08:06 -0500, Michael Catanzaro wrote:
> On Mon, May 31 2021 at 11:18:25 AM +0100, Sérgio Basto 
>  wrote:
> > I propose, for F36, the retire of Gconf2 (1)
> 
> Good idea. I think we can go ahead and do it now, though, unless 
> somebody plans to try to help any of the above unloved packages upgrade
> to gsettings and needs extra time?
> 
> (Why does pulseaudio depend on gconf2?)

pulseaudio-module-gconf

dnf repoquery --disablerepo='*' --enablerepo=rawhide --recursive --
whatrequires "libgconf*"  -q | pkgname  | sort -u  (2)


I see some packages that I like to preserve 

celestia
fawkes
mail-notification
pdfmod
rawstudio
 

(2)
GConf2-devel
GConf2-devel
GtkAda-devel
GtkAda-devel
GtkAda-gnome
GtkAda-gnome
alleyoop
apcupsd-gui
cbrpager
ccgo
cdcollect
celestia
fantasdic
fawkes
fawkes-core
fawkes-core
fawkes-devel
fawkes-devel
fawkes-doc
fawkes-firevision
fawkes-firevision
fawkes-firevision-tools
fawkes-guis
fawkes-guis
fawkes-lua
fawkes-lua
fawkes-plugin-amcl
fawkes-plugin-amcl
fawkes-plugin-bblogger
fawkes-plugin-bbsync
fawkes-plugin-cedar
fawkes-plugin-clips
fawkes-plugin-clips
fawkes-plugin-clips-agent
fawkes-plugin-clips-executive
fawkes-plugin-clips-navgraph
fawkes-plugin-clips-pddl-parser
fawkes-plugin-clips-protobuf
fawkes-plugin-clips-protobuf
fawkes-plugin-clips-tf
fawkes-plugin-colli
fawkes-plugin-dynamixel
fawkes-plugin-execution-time-estimator
fawkes-plugin-execution-time-estimator
fawkes-plugin-flite
fawkes-plugin-gazebo
fawkes-plugin-gazebo
fawkes-plugin-gazsim-comm
fawkes-plugin-gazsim-depthcam
fawkes-plugin-gazsim-laser
fawkes-plugin-gazsim-localization
fawkes-plugin-gazsim-robotino
fawkes-plugin-gazsim-timesource
fawkes-plugin-gazsim-vis-localization
fawkes-plugin-gazsim-webcam
fawkes-plugin-gossip
fawkes-plugin-gossip
fawkes-plugin-hardware-models
fawkes-plugin-imu
fawkes-plugin-jaco
fawkes-plugin-joystick
fawkes-plugin-joystick-teleop
fawkes-plugin-katana
fawkes-plugin-laser
fawkes-plugin-laser-cluster
fawkes-plugin-laser-filter
fawkes-plugin-laser-lines
fawkes-plugin-laser-pointclouds
fawkes-plugin-luaagent
fawkes-plugin-map-lasergen
fawkes-plugin-navgraph
fawkes-plugin-navgraph
fawkes-plugin-navgraph-clusters
fawkes-plugin-navgraph-generator
fawkes-plugin-navgraph-generator
fawkes-plugin-navgraph-static-constraints
fawkes-plugin-openni
fawkes-plugin-openni
fawkes-plugin-openni-data
fawkes-plugin-openni-handtracker
fawkes-plugin-openni-pcl-frombuf
fawkes-plugin-openni-usertracker
fawkes-plugin-pantilt
fawkes-plugin-realsense
fawkes-plugin-realsense2
fawkes-plugin-refboxcomm
fawkes-plugin-robot-state-publisher
fawkes-plugin-robotino
fawkes-plugin-robotino-ir-pcl
fawkes-plugin-roomba
fawkes-plugin-rrd
fawkes-plugin-rrd
fawkes-plugin-skiller
fawkes-plugin-skiller
fawkes-plugin-skiller-simulator
fawkes-plugin-static-transforms
fawkes-plugin-tabletop-objects
fawkes-plugin-ttmainloop
fawkes-plugin-webview
fawkes-plugin-webview
fawkes-plugin-xmlrpc
frama-c
frama-c-doc
frama-c-emacs
frama-c-xemacs
gconf-editor
gconfmm26
gconfmm26
gconfmm26-devel
gconfmm26-devel
giver
glade2
gnome-commander
gnome-desktop-sharp-devel
gnome-desktop-sharp-devel
gnome-do
gnome-do-devel
gnome-do-devel
gnome-phone-manager
gnome-sharp
gnome-sharp-devel
gnome-sharp-devel
gnome-translate
gnome-vfs2
gnome-vfs2
gnome-vfs2-common
gnome-vfs2-devel
gnome-vfs2-devel
gnome-vfs2-monikers
gnome-vfs2-smb
grhino
gtk-sharp-beans
gtk-sharp-beans-devel
gtk-sharp-beans-devel
ignuit
libbonoboui
libbonoboui
libbonoboui-devel
libbonoboui-devel
libgnome
libgnome
libgnome-devel
libgnome-devel
libgnomeui
libgnomeui
libgnomeui-devel
libgnomeui-devel
librawstudio
librawstudio
librawstudio-devel
librawstudio-devel
linsmith
lucidlife
mail-notification
mdbtools-gui
mono-addins-devel
mono-addins-devel
mono-tools
mono-tools-devel
mono-tools-devel
mono-tools-gendarme
mono-tools-monodoc
monodevelop
monodevelop-debugger-gdb
monodevelop-devel
monodevelop-devel
morse2txt
mtn-browse
nautilus-search-tool
ocaml-cairo-gtk
ocaml-cairo-gtk
ocaml-cairo-gtk-devel
ocaml-cairo-gtk-devel
ocaml-cairo-pango
ocaml-cairo-pango
ocaml-cairo-pango-devel
ocaml-cairo-pango-devel
ocaml-camlimages
ocaml-camlimages
ocaml-camlimages-devel
ocaml-camlimages-devel
ocaml-dose3
ocaml-dose3-devel
ocaml-dose3-devel
ocaml-lablgtk
ocaml-lablgtk
ocaml-lablgtk-devel
ocaml-lablgtk-devel
ocaml-ocamlgraph
ocaml-ocamlgraph
ocaml-ocamlgraph-devel
ocaml-ocamlgraph-devel
ocaml-ocamlgraph-tools
ocaml-ocamlnet
ocaml-ocamlnet-devel
ocaml-ocamlnet-devel
ocaml-ocamlnet-nethttpd
ocaml-ocamlnet-nethttpd-devel
ocaml-ocamlnet-nethttpd-devel
ocaml-xmlrpc-light
ocaml-xmlrpc-light-devel
ocaml-xmlrpc-light-devel
pacmanager
pdfmod
perl-Gnome2
perl-Gnome2-GConf
perl-Gnome2-VFS
pinta
pulseaudio-module-gconf
rawstudio
regexxer
ruby-bonoboui2
ruby-bonoboui2-devel
ruby-bonoboui2-devel
ruby-gconf2
ruby-gconf2-devel
ruby-gconf2-devel
ruby-gnome2
ruby-gnome2-devel
ruby-gnome2-devel
ruby-gnomevfs
ruby-gnomevfs-devel
ruby-gnomevfs-devel
ruby-libglade2
ruby-libglade2-devel
ruby-libglade2-devel

Re: Let's retire original glib and gtk+

[Michael Catanzaro]

On Mon, May 31 2021 at 11:18:25 AM +0100, Sérgio Basto 
 wrote:

I propose, for F36, the retire of Gconf2 (1)


Good idea. I think we can go ahead and do it now, though, unless 
somebody plans to try to help any of the above unloved packages upgrade 
to gsettings and needs extra time?


(Why does pulseaudio depend on gconf2?)

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Sérgio Basto]

On Wed, 2021-05-26 at 09:42 +0100, Peter Robinson wrote:
> On Tue, May 25, 2021 at 11:01 PM Michael Catanzaro <
> mcatanz...@gnome.org> wrote:
> > 
> > On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple
> >  wrote:
> > > I have no idea how significant this might be, but perhaps this
> > > should
> > > be discussed more publicly.
> > 
> > Use containers? Ship your own glib as a static lib? I'm impressed you
> > have software that still needs it tbh.
> 
> I think copr is the perfect place for these sort of things for those
> that care enough.

(off topic) Have we any copr that keeps python2 ? 

I propose, for F36, the retire of Gconf2 (1)

dnf repoquery --disablerepo='*' \
--enablerepo={rpmfusion-{non,}free-,}rawhide --recursive \
--whatrequires "libgconf*" --qf "%{repoid} %{sourcerpm}"  -q
rawhide GConf2-3.2.6-30.fc34.src.rpm
rawhide GtkAda-2.24.2-37.fc34.src.rpm
rawhide alleyoop-0.9.8-17.fc34.src.rpm
rawhide apcupsd-3.14.14-22.fc34.src.rpm
rawhide cbrpager-0.9.22-22.fc34.src.rpm
rawhide ccgo-0.3.6.5-15.fc34.src.rpm
rawhide cdcollect-0.6.0-35.fc34.src.rpm
rawhide celestia-1.6.2-0.5.beta3.fc34.src.rpm
rawhide fantasdic-1.0-0.17.beta7.fc34.4.src.rpm
rawhide fawkes-1.3.1-0.11.4923a6c.fc35.src.rpm
rawhide frama-c-22.0-10.fc35.src.rpm
rawhide gconf-editor-3.0.1-22.fc34.src.rpm
rawhide gconfmm26-2.28.3-25.fc35.src.rpm
rawhide giver-0.1.8-31.fc34.src.rpm
rawhide glade2-2.12.2-34.fc34.src.rpm
rawhide gnome-commander-1.12.1-1.fc35.src.rpm
rawhide gnome-desktop-sharp-2.26.0-42.fc34.src.rpm
rawhide gnome-do-0.95.3-19.fc34.src.rpm
rawhide gnome-phone-manager-0.69-35.fc35.src.rpm
rawhide gnome-sharp-2.24.2-28.fc34.src.rpm
rawhide gnome-translate-0.99-38.fc34.src.rpm
rawhide gnome-vfs2-2.24.4-35.fc34.src.rpm
rawhide gnome-vfs2-monikers-2.15.3-28.fc34.src.rpm
rawhide grhino-0.16.1-12.fc34.src.rpm
rawhide gtk-sharp-beans-2.14.0-28.fc34.src.rpm
rawhide ignuit-2.24.3-9.fc34.src.rpm
rawhide libbonoboui-2.24.5-20.fc34.src.rpm
rawhide libgnome-2.32.1-22.fc34.src.rpm
rawhide libgnomeui-2.24.5-24.fc34.src.rpm
rawhide linsmith-0.99.31-7.fc34.src.rpm
rawhide lucidlife-0.9.2-28.fc34.src.rpm
rawhide mail-notification-5.4-99.git.9ae8768.fc34.src.rpm
rawhide mdbtools-0.7.1-17.fc34.src.rpm
rawhide mono-addins-1.1-15.fc34.src.rpm
rawhide mono-tools-4.2-22.fc35.src.rpm
rawhide monodevelop-5.10.0-19.fc34.src.rpm
rawhide monodevelop-debugger-gdb-5.0.1-8.fc34.src.rpm
rawhide morse2txt-1.0.0-31.fc34.src.rpm
rawhide mtn-browse-1.20-11.fc34.src.rpm
rawhide nautilus-search-tool-0.3.0-34.fc34.src.rpm
rawhide ocaml-cairo-0.6.1-11.fc35.src.rpm
rawhide ocaml-camlimages-4.2.5-28.fc35.src.rpm
rawhide ocaml-dose3-5.0.1-32.20200502git24316fe.fc35.src.rpm
rawhide ocaml-lablgtk-2.18.11-6.fc35.src.rpm
rawhide ocaml-ocamlgraph-1.8.8-25.fc35.src.rpm
rawhide ocaml-ocamlnet-4.1.8-4.fc35.src.rpm
rawhide ocaml-xmlrpc-light-0.6.1-61.fc35.src.rpm
rawhide pacmanager-4.5.5.7-17.fc34.src.rpm
rawhide pdfmod-0.9.1-25.fc34.src.rpm
rawhide perl-Gnome2-1.048-3.fc35.src.rpm
rawhide perl-Gnome2-GConf-1.047-3.fc35.src.rpm
rawhide perl-Gnome2-VFS-1.084-3.fc35.src.rpm
rawhide pinta-1.7-3.fc34.src.rpm
rawhide pulseaudio-14.2-3.fc34.src.rpm
rawhide rawstudio-2.1-0.28.20210527.git58a8959.fc35.src.rpm
rawhide regexxer-0.9-29.fc34.src.rpm
rawhide ruby-gnome2-0.90.4-9.fc34.6.src.rpm
rawhide simdock-1.5.3-6.fc34.src.rpm
rawhide sirius-0.8.0-40.fc34.src.rpm
rawhide tomboy-1.15.9-14.fc34.src.rpm
rawhide tomoe-gtk-0.6.0-37.fc34.src.rpm
rawhide ucview-0.33-20.fc34.src.rpm
rawhide verbiste-0.1.47-4.fc34.src.rpm
rawhide xoo-0.8-17.fc34.src.rpm
rpmfusion-free-rawhide dvd95-1.7p0-12.fc34.src.rpm
rpmfusion-free-rawhide girl-10.0.0-11.fc34.src.rpm
rpmfusion-free-rawhide ogmrip-1.0.1-13.fc34.src.rpm



(1)
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A64MTJCHCZ66QFE46RMX3JLAKXF7NFAP/

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Hans de Goede]

Hi,

On 5/27/21 5:54 PM, Tom Callaway wrote:
> FWIW, I have retired xmms. Upstream is long gone, and it was being held 
> together by spider-webs anyways.

And I've just retired xarchon for similar reasons. xarchon was fun
for me as a fan of the original c64 Archon games, but it really is
time for gtk+ to get retired and I don't want a silly (and not
very polished) game like xarchon to block retiring gtk+.

Regards,

Hans




> 
> ~spot
> 
> On Wed, May 26, 2021 at 4:43 AM Peter Robinson  > wrote:
> 
> On Tue, May 25, 2021 at 11:01 PM Michael Catanzaro  > wrote:
> >
> > On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple
> > mailto:bob.hep...@gmail.com>> wrote:
> > > I have no idea how significant this might be, but perhaps this should
> > > be discussed more publicly.
> >
> > Use containers? Ship your own glib as a static lib? I'm impressed you
> > have software that still needs it tbh.
> 
> I think copr is the perfect place for these sort of things for those
> that care enough.
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 
> 
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines 
> 
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
> 
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Tom Callaway]

FWIW, I have retired xmms. Upstream is long gone, and it was being held
together by spider-webs anyways.

~spot

On Wed, May 26, 2021 at 4:43 AM Peter Robinson  wrote:

> On Tue, May 25, 2021 at 11:01 PM Michael Catanzaro 
> wrote:
> >
> > On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple
> >  wrote:
> > > I have no idea how significant this might be, but perhaps this should
> > > be discussed more publicly.
> >
> > Use containers? Ship your own glib as a static lib? I'm impressed you
> > have software that still needs it tbh.
>
> I think copr is the perfect place for these sort of things for those
> that care enough.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Peter Robinson]

On Tue, May 25, 2021 at 11:01 PM Michael Catanzaro  wrote:
>
> On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple
>  wrote:
> > I have no idea how significant this might be, but perhaps this should
> > be discussed more publicly.
>
> Use containers? Ship your own glib as a static lib? I'm impressed you
> have software that still needs it tbh.

I think copr is the perfect place for these sort of things for those
that care enough.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Paul Howarth]

On Tue, 25 May 2021 17:00:31 -0500
Michael Catanzaro  wrote:

> On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple 
>  wrote:
> > I have no idea how significant this might be, but perhaps this
> > should be discussed more publicly.  
> 
> Use containers? Ship your own glib as a static lib? I'm impressed you 
> have software that still needs it tbh.
> 
> Anyway, there have been no other objections, and there's been no 
> comment from the package owner, so I wonder if any provenpackagers 
> would be willing to do the glib package retirement?

I'm the package owner and I'm prepared to retire glib/gtk+ once there
are no further dependencies on them in Fedora.

Paul,
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Jerry James]

On Tue, May 25, 2021 at 4:01 PM Michael Catanzaro  wrote:
> Anyway, there have been no other objections, and there's been no
> comment from the package owner, so I wonder if any provenpackagers
> would be willing to do the glib package retirement?

I forgot to mention that I looked at porting surf-geometry from gtk1
to gtk2.  It turned out to not be super difficult, so that has been
done in Rawhide.  The UI actually works better now.  It was pretty
broken.  Now it's only partially broken. :-)  I guess that's a
testament to nobody actually using it.  I'll try again to get hold of
the package maintainer to see if it can be retired.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Michael Catanzaro]

On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple 
 wrote:

I have no idea how significant this might be, but perhaps this should
be discussed more publicly.


Use containers? Ship your own glib as a static lib? I'm impressed you 
have software that still needs it tbh.


Anyway, there have been no other objections, and there's been no 
comment from the package owner, so I wonder if any provenpackagers 
would be willing to do the glib package retirement?


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Bob Hepple]

There may be more to that iceberg than appears above the surface in
the form of non-distributed or private software outside the realm of
the public repositories.

As for examples, I can only point to some of my own ancient binaries
which I would certainly not suggest as a plea to preserve glib1.

But there may be other more significant interests with software
vendors and large private users.

I have no idea how significant this might be, but perhaps this should
be discussed more publicly.

Cheers


Bob

On Sat, 8 May 2021 at 00:45, Michael Catanzaro  wrote:
>
> Hi, I'd like to retire the original glib, GLib 1 from the GNOME 1 era.
> This is would take out the gtk+ package (GTK 1) along with it. (I'm not
> proposing to remove GTK 2.) GLib 1 has been obsolete for 19 years now,
> since GLib 2 was released in March 2002. That's a real long time to
> maintain a compatibility package, so I'm not sympathetic to anything
> that still requires it.
>
> GLib 2 has been API and ABI stable for 19 years now, so it's not moving
> too fast for your package to depend on. :) The full list of packages
> still depending on GLib 1 is below. If you own one of the below
> packages, please consider upgrading to GLib 2. The only one that I
> recognize is Sagemath.
>
> $ sudo dnf repoquery --recursive --whatrequires glib
> Last metadata expiration check: 0:28:04 ago on Fri 07 May 2021 09:06:03
> AM CDT.
> Singular-0:4.1.1p3-24.fc34.x86_64
> Singular-doc-0:4.1.1p3-24.fc34.x86_64
> Singular-emacs-0:4.1.1p3-24.fc34.x86_64
> Singular-surfex-0:4.1.1p3-24.fc34.x86_64
> bubblemon-0:1.46-29.fc34.x86_64
> collectd-xmms-0:5.12.0-2.fc34.x86_64
> gap-pkg-happrime-0:0.6-5.20190208.edfbd41.fc34.noarch
> gap-pkg-happrime-doc-0:0.6-5.20190208.edfbd41.fc34.noarch
> gap-pkg-singular-0:2020.12.18-2.fc34.noarch
> gap-pkg-singular-doc-0:2020.12.18-2.fc34.noarch
> glib-devel-1:1.2.10-62.fc34.i686
> glib-devel-1:1.2.10-62.fc34.x86_64
> golang-github-mattn-gtk-devel-0:0-0.7.20200729gitaf2e013.fc34.noarch
> gtk+-1:1.2.10-96.fc34.i686
> gtk+-1:1.2.10-96.fc34.x86_64
> gtk+-devel-1:1.2.10-96.fc34.i686
> gtk+-devel-1:1.2.10-96.fc34.x86_64
> gxvattr-0:1.3-42.fc34.x86_64
> librcc-devel-0:0.2.12-18.fc34.i686
> librcc-devel-0:0.2.12-18.fc34.x86_64
> librcc-gtk+-0:0.2.12-18.fc34.i686
> librcc-gtk+-0:0.2.12-18.fc34.x86_64
> logjam-xmms-1:4.6.2-25.fc34.x86_64
> manedit-0:1.2.1-25.fc34.x86_64
> qepcad-B-0:1.74-1.fc34.x86_64
> sagemath-0:9.2-4.fc34.x86_64
> sagemath-core-0:9.2-4.fc34.x86_64
> sagemath-data-0:9.2-4.fc34.noarch
> sagemath-data-combinatorial_designs-0:9.2-4.fc34.noarch
> sagemath-data-conway_polynomials-0:9.2-4.fc34.noarch
> sagemath-data-elliptic_curves-0:9.2-4.fc34.noarch
> sagemath-data-elliptic_curves_large-0:9.2-4.fc34.noarch
> sagemath-data-etc-0:9.2-4.fc34.noarch
> sagemath-data-graphs-0:9.2-4.fc34.noarch
> sagemath-data-polytopes_db-0:9.2-4.fc34.noarch
> sagemath-jupyter-0:9.2-4.fc34.x86_64
> sagemath-sagetex-0:9.2-4.fc34.x86_64
> surf-geometry-0:1.0.6-29.fc34.x86_64
> xarchon-0:0.50-35.fc34.x86_64
> xconvers-0:0.8.3-27.fc34.x86_64
> xdialog-0:2.3.1-28.fc34.x86_64
> xmms-1:1.2.11-41.20071117cvs.fc34.x86_64
> xmms-devel-1:1.2.11-41.20071117cvs.fc34.i686
> xmms-devel-1:1.2.11-41.20071117cvs.fc34.x86_64
> xmms-flac-0:1.3.3-7.fc34.x86_64
> xmms-libs-1:1.2.11-41.20071117cvs.fc34.i686
> xmms-libs-1:1.2.11-41.20071117cvs.fc34.x86_64
> xmms-pulse-0:0.9.4-27.fc34.x86_64
>
> Michael
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Ariadne Conill]

Hi,

On Fri, 7 May 2021, Luna Jernberg wrote:


Could always use the newer forks of it https://audacious-media-player.org/ and 
https://qmmp.ylsoftware.com/


At this point, Audacious is probably not a great option for people looking 
for an XMMS replacement.  Though a Winamp skins interface still exists, 
we've rewritten it a few times now and a lot of the functionality is quite 
different than XMMS.


QMMP is likely a better alternative for a diehard XMMS user.

Ariadne
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Sérgio Basto]

On Fri, 2021-05-07 at 14:45 +, Michael Catanzaro wrote:
> Hi, I'd like to retire the original glib, GLib 1 from the GNOME 1 era. 
> This is would take out the gtk+ package (GTK 1) along with it. (I'm not
> proposing to remove GTK 2.) GLib 1 has been obsolete for 19 years now, 
> since GLib 2 was released in March 2002. That's a real long time to 
> maintain a compatibility package, so I'm not sympathetic to anything 
> that still requires it.
> 
> GLib 2 has been API and ABI stable for 19 years now, so it's not moving
> too fast for your package to depend on. :) The full list of packages 
> still depending on GLib 1 is below. If you own one of the below 
> packages, please consider upgrading to GLib 2. The only one that I 
> recognize is Sagemath.
> 
> $ sudo dnf repoquery --recursive --whatrequires glib
> Last metadata expiration check: 0:28:04 ago on Fri 07 May 2021 09:06:03
> AM CDT.
> Singular-0:4.1.1p3-24.fc34.x86_64
> Singular-doc-0:4.1.1p3-24.fc34.x86_64
> Singular-emacs-0:4.1.1p3-24.fc34.x86_64
> Singular-surfex-0:4.1.1p3-24.fc34.x86_64
> bubblemon-0:1.46-29.fc34.x86_64
> collectd-xmms-0:5.12.0-2.fc34.x86_64
> gap-pkg-happrime-0:0.6-5.20190208.edfbd41.fc34.noarch
> gap-pkg-happrime-doc-0:0.6-5.20190208.edfbd41.fc34.noarch
> gap-pkg-singular-0:2020.12.18-2.fc34.noarch
> gap-pkg-singular-doc-0:2020.12.18-2.fc34.noarch
> glib-devel-1:1.2.10-62.fc34.i686
> glib-devel-1:1.2.10-62.fc34.x86_64
> golang-github-mattn-gtk-devel-0:0-0.7.20200729gitaf2e013.fc34.noarch
> gtk+-1:1.2.10-96.fc34.i686
> gtk+-1:1.2.10-96.fc34.x86_64
> gtk+-devel-1:1.2.10-96.fc34.i686
> gtk+-devel-1:1.2.10-96.fc34.x86_64
> gxvattr-0:1.3-42.fc34.x86_64
> librcc-devel-0:0.2.12-18.fc34.i686
> librcc-devel-0:0.2.12-18.fc34.x86_64
> librcc-gtk+-0:0.2.12-18.fc34.i686
> librcc-gtk+-0:0.2.12-18.fc34.x86_64
> logjam-xmms-1:4.6.2-25.fc34.x86_64
> manedit-0:1.2.1-25.fc34.x86_64
> qepcad-B-0:1.74-1.fc34.x86_64
> sagemath-0:9.2-4.fc34.x86_64
> sagemath-core-0:9.2-4.fc34.x86_64
> sagemath-data-0:9.2-4.fc34.noarch
> sagemath-data-combinatorial_designs-0:9.2-4.fc34.noarch
> sagemath-data-conway_polynomials-0:9.2-4.fc34.noarch
> sagemath-data-elliptic_curves-0:9.2-4.fc34.noarch
> sagemath-data-elliptic_curves_large-0:9.2-4.fc34.noarch
> sagemath-data-etc-0:9.2-4.fc34.noarch
> sagemath-data-graphs-0:9.2-4.fc34.noarch
> sagemath-data-polytopes_db-0:9.2-4.fc34.noarch
> sagemath-jupyter-0:9.2-4.fc34.x86_64
> sagemath-sagetex-0:9.2-4.fc34.x86_64
> surf-geometry-0:1.0.6-29.fc34.x86_64
> xarchon-0:0.50-35.fc34.x86_64
> xconvers-0:0.8.3-27.fc34.x86_64
> xdialog-0:2.3.1-28.fc34.x86_64
> xmms-1:1.2.11-41.20071117cvs.fc34.x86_64
> xmms-devel-1:1.2.11-41.20071117cvs.fc34.i686
> xmms-devel-1:1.2.11-41.20071117cvs.fc34.x86_64
> xmms-flac-0:1.3.3-7.fc34.x86_64
> xmms-libs-1:1.2.11-41.20071117cvs.fc34.i686
> xmms-libs-1:1.2.11-41.20071117cvs.fc34.x86_64
> xmms-pulse-0:0.9.4-27.fc34.x86_64
> 

I think it is better query by src.rpm 

dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires
glib --qf "%{repoid} %{sourcerpm}"  -q
rawhide bubblemon-1.46-29.fc34.src.rpm
rawhide collectd-5.12.0-3.fc35.src.rpm
rawhide flac-1.3.3-5.fc34.src.rpm
rawhide glib-1.2.10-62.fc34.src.rpm
rawhide gtk+-1.2.10-96.fc34.src.rpm
rawhide librcc-0.2.12-18.fc34.src.rpm
rawhide manedit-1.2.1-25.fc34.src.rpm
rawhide surf-geometry-1.0.6-29.fc34.src.rpm
rawhide xarchon-0.50-35.fc34.src.rpm
rawhide xconvers-0.8.3-27.fc34.src.rpm
rawhide xdialog-2.3.1-28.fc34.src.rpm
rawhide xmms-1.2.11-41.20071117cvs.fc34.src.rpm
rawhide xmms-pulse-0.9.4-27.fc34.src.rpm
rawhide xvattr-1.3-42.fc34.src.rpm

dnf repoquery --disablerepo='*' --enablerepo=rawhide --recursive --whatrequires 
glib --qf "%{repoid} %{sourcerpm}"  -q 
we got more 
rawhide Singular-4.1.1p3-24.fc35.src.rpm
rawhide gap-pkg-happrime-0.6-5.20190208.edfbd41.fc34.src.rpm
rawhide gap-pkg-singular-2020.12.18-2.fc34.src.rpm
rawhide golang-github-mattn-gtk-0-0.7.20200729gitaf2e013.fc34.src.rpm
rawhide logjam-4.6.2-25.fc34.src.rpm
rawhide qepcad-B-1.74-1.fc35.src.rpm
rawhide sagemath-9.2-4.fc35.src.rpm

> Michael
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: Let's retire original glib and gtk+

[Robert-André Mauchin]

On 5/7/21 4:45 PM, Michael Catanzaro wrote:
Hi, I'd like to retire the original glib, GLib 1 from the GNOME 1 era. 
This is would take out the gtk+ package (GTK 1) along with it. (I'm not 
proposing to remove GTK 2.) GLib 1 has been obsolete for 19 years now, 
since GLib 2 was released in March 2002. That's a real long time to 
maintain a compatibility package, so I'm not sympathetic to anything 
that still requires it.


GLib 2 has been API and ABI stable for 19 years now, so it's not moving 
too fast for your package to depend on. :) The full list of packages 
still depending on GLib 1 is below. If you own one of the below 
packages, please consider upgrading to GLib 2. The only one that I 
recognize is Sagemath.


$ sudo dnf repoquery --recursive --whatrequires glib
golang-github-mattn-gtk-devel-0:0-0.7.20200729gitaf2e013.fc34.noarch


This is a packaging mistake, it should depend on glib2.
I will be fixing this ASAP.

Best regards,

Robert-André
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Jerry James]

On Fri, May 7, 2021 at 11:24 AM Owen Taylor  wrote:
> GLib 2 was quite compatible with GLib 1 - there were lots of additions
> but few breaking changes. But it looks like the dependency in
> surf-geometry is a GTK 1 user interface (written in C++ with a bit of
> custom glue, with Xlib usage mixed in.) and a GTK 1 to GTK 2 port is
> more work. Not that hard for someone experienced in the GTK *of that
> time* , but at this point, it would be like translating Chaucer into
> Elizabethan English. And porting to GTK 3 or GTK 4 would be a bigger
> job. I think this pretty clearly falls into the "if someone cared
> about this GUI, they would have ported it from GTK 1 long ago" bucket.
>
> But it also looks like it could just be disabled without affecting
> anything else.

That's the conclusion I came to as well.  Paulo, will you be sad if we
turn off the surf-geometry GUI?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Owen Taylor]

On Fri, May 7, 2021 at 12:17 PM Jerry James  wrote:
>
> On Fri, May 7, 2021 at 9:45 AM Michael Catanzaro  wrote:
> > Um... not that I know of.
> >
> > Honestly, I don't know anything about GLib 1 other than that it's very
> > old. I think if I were trying to port Sagemath, I would just upgrade
> > the build system to GLib 2 and see how many compiler errors you get
>
> It turns out that surf-geometry is the only package on that list that
> directly depends on glib 1.  The others depend on surf-geometry,
> directly or transitively.  That's a very old (and, frankly, buggy)
> piece of software there.  I'll see what can be done with it.

GLib 2 was quite compatible with GLib 1 - there were lots of additions
but few breaking changes. But it looks like the dependency in
surf-geometry is a GTK 1 user interface (written in C++ with a bit of
custom glue, with Xlib usage mixed in.) and a GTK 1 to GTK 2 port is
more work. Not that hard for someone experienced in the GTK *of that
time* , but at this point, it would be like translating Chaucer into
Elizabethan English. And porting to GTK 3 or GTK 4 would be a bigger
job. I think this pretty clearly falls into the "if someone cared
about this GUI, they would have ported it from GTK 1 long ago" bucket.

But it also looks like it could just be disabled without affecting
anything else.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Vitaly Zaitsev via devel]

On 07.05.2021 17:00, Matthew Miller wrote:

Awww, rest in peace, xmms. It's a winamp-stytle music player from the 90s!


I'm still using Audacious with Winamp skin. :-)

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Jerry James]

On Fri, May 7, 2021 at 9:45 AM Michael Catanzaro  wrote:
> Um... not that I know of.
>
> Honestly, I don't know anything about GLib 1 other than that it's very
> old. I think if I were trying to port Sagemath, I would just upgrade
> the build system to GLib 2 and see how many compiler errors you get

It turns out that surf-geometry is the only package on that list that
directly depends on glib 1.  The others depend on surf-geometry,
directly or transitively.  That's a very old (and, frankly, buggy)
piece of software there.  I'll see what can be done with it.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Michael Catanzaro]

On Fri, May 7 2021 at 09:18:09 AM -0600, Jerry James 
 wrote:
Is there a (possibly 2 decades old!) glib 1 to glib 2 porting guide 
somewhere?


Um... not that I know of.

Honestly, I don't know anything about GLib 1 other than that it's very 
old. I think if I were trying to port Sagemath, I would just upgrade 
the build system to GLib 2 and see how many compiler errors you get


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Matthew Miller]

On Fri, May 07, 2021 at 05:15:49PM +0200, Luna Jernberg wrote:
> Could always use the newer forks of it https://audacious-media-player.org/

Yes, and audacious is already packaged. I don't think there's a need to keep
this... it just hit my nostalgia. :)

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Jerry James]

On Fri, May 7, 2021 at 8:45 AM Michael Catanzaro  wrote:
> Hi, I'd like to retire the original glib, GLib 1 from the GNOME 1 era.
> This is would take out the gtk+ package (GTK 1) along with it. (I'm not
> proposing to remove GTK 2.) GLib 1 has been obsolete for 19 years now,
> since GLib 2 was released in March 2002. That's a real long time to
> maintain a compatibility package, so I'm not sympathetic to anything
> that still requires it.
>
> GLib 2 has been API and ABI stable for 19 years now, so it's not moving
> too fast for your package to depend on. :) The full list of packages
> still depending on GLib 1 is below. If you own one of the below
> packages, please consider upgrading to GLib 2. The only one that I
> recognize is Sagemath.
>
> $ sudo dnf repoquery --recursive --whatrequires glib
> Last metadata expiration check: 0:28:04 ago on Fri 07 May 2021 09:06:03
> AM CDT.
> Singular-0:4.1.1p3-24.fc34.x86_64
> Singular-doc-0:4.1.1p3-24.fc34.x86_64
> Singular-emacs-0:4.1.1p3-24.fc34.x86_64
> Singular-surfex-0:4.1.1p3-24.fc34.x86_64
> bubblemon-0:1.46-29.fc34.x86_64
> collectd-xmms-0:5.12.0-2.fc34.x86_64
> gap-pkg-happrime-0:0.6-5.20190208.edfbd41.fc34.noarch
> gap-pkg-happrime-doc-0:0.6-5.20190208.edfbd41.fc34.noarch
> gap-pkg-singular-0:2020.12.18-2.fc34.noarch
> gap-pkg-singular-doc-0:2020.12.18-2.fc34.noarch
> glib-devel-1:1.2.10-62.fc34.i686
> glib-devel-1:1.2.10-62.fc34.x86_64
> golang-github-mattn-gtk-devel-0:0-0.7.20200729gitaf2e013.fc34.noarch
> gtk+-1:1.2.10-96.fc34.i686
> gtk+-1:1.2.10-96.fc34.x86_64
> gtk+-devel-1:1.2.10-96.fc34.i686
> gtk+-devel-1:1.2.10-96.fc34.x86_64
> gxvattr-0:1.3-42.fc34.x86_64
> librcc-devel-0:0.2.12-18.fc34.i686
> librcc-devel-0:0.2.12-18.fc34.x86_64
> librcc-gtk+-0:0.2.12-18.fc34.i686
> librcc-gtk+-0:0.2.12-18.fc34.x86_64
> logjam-xmms-1:4.6.2-25.fc34.x86_64
> manedit-0:1.2.1-25.fc34.x86_64
> qepcad-B-0:1.74-1.fc34.x86_64
> sagemath-0:9.2-4.fc34.x86_64
> sagemath-core-0:9.2-4.fc34.x86_64
> sagemath-data-0:9.2-4.fc34.noarch
> sagemath-data-combinatorial_designs-0:9.2-4.fc34.noarch
> sagemath-data-conway_polynomials-0:9.2-4.fc34.noarch
> sagemath-data-elliptic_curves-0:9.2-4.fc34.noarch
> sagemath-data-elliptic_curves_large-0:9.2-4.fc34.noarch
> sagemath-data-etc-0:9.2-4.fc34.noarch
> sagemath-data-graphs-0:9.2-4.fc34.noarch
> sagemath-data-polytopes_db-0:9.2-4.fc34.noarch
> sagemath-jupyter-0:9.2-4.fc34.x86_64
> sagemath-sagetex-0:9.2-4.fc34.x86_64
> surf-geometry-0:1.0.6-29.fc34.x86_64
> xarchon-0:0.50-35.fc34.x86_64
> xconvers-0:0.8.3-27.fc34.x86_64
> xdialog-0:2.3.1-28.fc34.x86_64
> xmms-1:1.2.11-41.20071117cvs.fc34.x86_64
> xmms-devel-1:1.2.11-41.20071117cvs.fc34.i686
> xmms-devel-1:1.2.11-41.20071117cvs.fc34.x86_64
> xmms-flac-0:1.3.3-7.fc34.x86_64
> xmms-libs-1:1.2.11-41.20071117cvs.fc34.i686
> xmms-libs-1:1.2.11-41.20071117cvs.fc34.x86_64
> xmms-pulse-0:0.9.4-27.fc34.x86_64

Several of these are from the sagemath stack, namely:
- Singular
- gap-pkg-happrime (this can probably be retired; nothing uses it)
- gap-pkg-singular
- qepcad-B
- sagemath
- surf-geometry

Is there a (possibly 2 decades old!) glib 1 to glib 2 porting guide somewhere?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Luna Jernberg]

Could always use the newer forks of it https://audacious-media-player.org/
and https://qmmp.ylsoftware.com/

On Fri, May 7, 2021 at 5:00 PM Matthew Miller 
wrote:

> On Fri, May 07, 2021 at 02:45:09PM +, Michael Catanzaro wrote:
> > below packages, please consider upgrading to GLib 2. The only one
> > that I recognize is Sagemath.
> [...]
> > xmms-1:1.2.11-41.20071117cvs.fc34.x86_64
>
> Awww, rest in peace, xmms. It's a winamp-stytle music player from the 90s!
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Matthew Miller]

On Fri, May 07, 2021 at 02:45:09PM +, Michael Catanzaro wrote:
> below packages, please consider upgrading to GLib 2. The only one
> that I recognize is Sagemath.
[...]
> xmms-1:1.2.11-41.20071117cvs.fc34.x86_64

Awww, rest in peace, xmms. It's a winamp-stytle music player from the 90s!


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Let's retire original glib and gtk+

[Michael Catanzaro]

Hi, I'd like to retire the original glib, GLib 1 from the GNOME 1 era. 
This is would take out the gtk+ package (GTK 1) along with it. (I'm not 
proposing to remove GTK 2.) GLib 1 has been obsolete for 19 years now, 
since GLib 2 was released in March 2002. That's a real long time to 
maintain a compatibility package, so I'm not sympathetic to anything 
that still requires it.


GLib 2 has been API and ABI stable for 19 years now, so it's not moving 
too fast for your package to depend on. :) The full list of packages 
still depending on GLib 1 is below. If you own one of the below 
packages, please consider upgrading to GLib 2. The only one that I 
recognize is Sagemath.


$ sudo dnf repoquery --recursive --whatrequires glib
Last metadata expiration check: 0:28:04 ago on Fri 07 May 2021 09:06:03 
AM CDT.

Singular-0:4.1.1p3-24.fc34.x86_64
Singular-doc-0:4.1.1p3-24.fc34.x86_64
Singular-emacs-0:4.1.1p3-24.fc34.x86_64
Singular-surfex-0:4.1.1p3-24.fc34.x86_64
bubblemon-0:1.46-29.fc34.x86_64
collectd-xmms-0:5.12.0-2.fc34.x86_64
gap-pkg-happrime-0:0.6-5.20190208.edfbd41.fc34.noarch
gap-pkg-happrime-doc-0:0.6-5.20190208.edfbd41.fc34.noarch
gap-pkg-singular-0:2020.12.18-2.fc34.noarch
gap-pkg-singular-doc-0:2020.12.18-2.fc34.noarch
glib-devel-1:1.2.10-62.fc34.i686
glib-devel-1:1.2.10-62.fc34.x86_64
golang-github-mattn-gtk-devel-0:0-0.7.20200729gitaf2e013.fc34.noarch
gtk+-1:1.2.10-96.fc34.i686
gtk+-1:1.2.10-96.fc34.x86_64
gtk+-devel-1:1.2.10-96.fc34.i686
gtk+-devel-1:1.2.10-96.fc34.x86_64
gxvattr-0:1.3-42.fc34.x86_64
librcc-devel-0:0.2.12-18.fc34.i686
librcc-devel-0:0.2.12-18.fc34.x86_64
librcc-gtk+-0:0.2.12-18.fc34.i686
librcc-gtk+-0:0.2.12-18.fc34.x86_64
logjam-xmms-1:4.6.2-25.fc34.x86_64
manedit-0:1.2.1-25.fc34.x86_64
qepcad-B-0:1.74-1.fc34.x86_64
sagemath-0:9.2-4.fc34.x86_64
sagemath-core-0:9.2-4.fc34.x86_64
sagemath-data-0:9.2-4.fc34.noarch
sagemath-data-combinatorial_designs-0:9.2-4.fc34.noarch
sagemath-data-conway_polynomials-0:9.2-4.fc34.noarch
sagemath-data-elliptic_curves-0:9.2-4.fc34.noarch
sagemath-data-elliptic_curves_large-0:9.2-4.fc34.noarch
sagemath-data-etc-0:9.2-4.fc34.noarch
sagemath-data-graphs-0:9.2-4.fc34.noarch
sagemath-data-polytopes_db-0:9.2-4.fc34.noarch
sagemath-jupyter-0:9.2-4.fc34.x86_64
sagemath-sagetex-0:9.2-4.fc34.x86_64
surf-geometry-0:1.0.6-29.fc34.x86_64
xarchon-0:0.50-35.fc34.x86_64
xconvers-0:0.8.3-27.fc34.x86_64
xdialog-0:2.3.1-28.fc34.x86_64
xmms-1:1.2.11-41.20071117cvs.fc34.x86_64
xmms-devel-1:1.2.11-41.20071117cvs.fc34.i686
xmms-devel-1:1.2.11-41.20071117cvs.fc34.x86_64
xmms-flac-0:1.3.3-7.fc34.x86_64
xmms-libs-1:1.2.11-41.20071117cvs.fc34.i686
xmms-libs-1:1.2.11-41.20071117cvs.fc34.x86_64
xmms-pulse-0:0.9.4-27.fc34.x86_64

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure