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
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)
> >
> >
> 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 xco
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
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
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
becom
> 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
> 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
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 con
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, al
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 ?
> >
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
f
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 wi
> 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
maintaine
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
> 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+
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 a
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 removin
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 automatica
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 h
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
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)
>
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 sh
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 cros
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.fedorainfracl
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
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-lablgt
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 m
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
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
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-,}r
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} %{s
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,
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 un
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 p
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
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
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
> > w
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 impress
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 im
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-
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
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.
B
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
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 wa
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 20
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 i
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
> >
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 -- dev
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 ge
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
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
_
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 rel
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
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!
--
M
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 co
56 matches
Mail list logo
