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)maintainers    Status 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): pghmcfc(a)fedoraproject.org, rdieter(a)fedoraproject.org,
sham1(a)fedoraproject.org, limb(a)fedoraproject.org,
ppisar(a)fedoraproject.org, thias(a)fedoraproject.org,
fnux(a)fedoraproject.org, sway-sig(a)fedoraproject.org,
ivanromanov(a)fedoraproject.org, pali(a)fedoraproject.org,
hannes(a)fedoraproject.org, laxathom(a)fedoraproject.org,
hobbes1069(a)fedoraproject.org, konradm(a)fedoraproject.org,
perex(a)fedoraproject.org, timj(a)fedoraproject.org,
aarem(a)fedoraproject.org, atim(a)fedoraproject.org,
jhogarth(a)fedoraproject.org, sophiekovalevsky(a)fedoraproject.org,
mcermak(a)fedoraproject.org, pertusus(a)fedoraproject.org,
peter(a)fedoraproject.org, dcavalca(a)fedoraproject.org
-- 
Sérgio M. B.

[Michael Catanzaro]

On Mon, Mar 7 2022 at 04:17:09 PM +0000, Sérgio Basto 
<sergio(a)serjux.com&gt; 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.

[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 +0000, 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

[Paul Howarth]

On Mon, 07 Mar 2022 10:29:02 -0600
Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:

>  On Mon, Mar 7 2022 at 04:17:09 PM +0000, Sérgio Basto 
>  <sergio(a)serjux.com&gt; 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.

[Michael Catanzaro]

On Mon, Mar 7 2022 at 04:48:27 PM +0000, Paul Howarth 
<paul(a)city-fan.org&gt; 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

[Kevin Kofler]

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

[Leigh Scott]

>  On Mon, 07 Mar 2022 10:29:02 -0600
>  Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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.
>  
>  Paul. 
dillo, alsa-tools, gnubg,  and tilda don't rely on glib or gtk+, the package
maintainers have made mistakes.

[Sérgio Basto]

On Tue, 2022-03-08 at 16:01 +0000, Leigh Scott wrote:
>  > On Mon, 07 Mar 2022 10:29:02 -0600
>  > Michael Catanzaro <mcatanzaro(a)gnome.org&gt; 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.
>  > 
>  > 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.

[Leigh Scott]

>  On Tue, 2022-03-08 at 16:01 +0000, 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.

[Kevin Kofler]

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

[Peter Boy]

>  Am 08.03.2022 um 01:41 schrieb Kevin Kofler via devel
> <devel(a)lists.fedoraproject.org&gt;:
>  
>  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.

[Bill Nottingham]

Peter Boy (pboy(a)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

[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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure 
-- 
Sérgio M. B.

[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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 08, 2022 at 05:51:35PM +0000, 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

[Adam Williamson]

On Mon, 2022-03-07 at 16:17 +0000, 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_diffe...
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

[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

[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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure 
-- 
Sérgio M. B.

[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.

[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.

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/bubb...

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure 
-- 
Sérgio M. B.

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

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 -0000, 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

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 <sergio(a)serjux.com&gt; 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