[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#760986: RM: guile-1.8 -- ROM; replaced by guile-2.0



Hi,

(dropping most CCs)

Some personal observations.

On 2014-10-13 03:51, Rob Browning wrote:
Luca Falavigna <dktrkranz@debian.org> writes:

These are the reverse dependencies to be fixed before removing this
package:

Right -- I was hoping to try to reach a decision this week with respect
to jessie.

Here's what I hope is a reasonably accurate summary of the situation.

As a general comment, people on #guile (including one of the upstream
Guile maintainers) have said that at this point, they would prefer that
we remove packages from jessie that support Guile 2.0 upstream, but
still depend on 1.8 in Debian (though we might or might not keep them in
unstable).  This was mentioned in particular, with respect to g-wrap,
guile-cairo, and guile-gnome-platform.

I see no reason to keep many of the listed packages in unstable, let alone Jessie. I've outlined additional reasons inline. In most cases packages are abandoned or uncared for, and maintainers have had reasonable notice of your intent to remove guile-1.8 and friends. Therefore, with a couple of exceptions, I would support filing of removal bugs from unstable, and certainly we should consider removals from testing to complete removal of guile-1.8.

lilypond is a shame, especially as it has an active and caring maintainer, but if upstream support is not ready yet I don't think we should hold up for them. The alternative is supporting guile-1.8 ourselves, if it isn't upstream any longer.

In the end, the question is whether or not, on balance, we're better off
with or without guile-1.8 in jessie.

On balance I would say without, but I have no particular interest in any of the affected packages.

In not the same order as you originally wrote, easy first:

guile-1.8-non-dfsg/non-free

Should be removed iff guile-1.8 is.

Agreed.

g-wrap [1]

Only response wrt 2.0 is a mention of an upload that's been in
experimental for two years, but no response from the maintainer:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761210

Last non-experimental upload: 2012-05

guile-gnome-platform [1]

No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761211

Last non-NMU: 2012-06

g-wrap not in testing since August *2012*, and not in Wheezy.

guile-gnome-platform not in testing since October 2013, FTBFS since June 2013 with no maintainer response.

Maintainer has not responded to pings by MIA; https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=rotty%40debian.org makes me sad.

beast

No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745991
Last non-NMU: 2013-02

Has not been in testing since June, has not had an upload since Feb 2013 and a FTBFS bug became serious in May and has no maintainer response.

freetalk

No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745997
Last non-NMU: 2012-06

Has not been in testing since November 2013, and FTBFS since July 2013 with only a vague promise of an upload from the maintainer in July 2014.


These are all great candidates for removal from sid.

Less straightforward:

anubis

No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745989
Last non-NMU: 2009-09

Maintained by QA, but with no response to the guile-2.0 report becoming serious in September I don't think its long-term future looks viable. An RM/RoQA makes sense.

trackballs

No response wrt 2.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746011

Last non-NMU: 2007-12

Does look fairly stale, but is in testing. Probably worth removing from testing for guile-2.0, if we reach that stage.

drgeo

Some response from the maintainer in May, but nothing since:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707903

Last non-NMU appears to be 2012-05

I've also been told that drgeo no longer uses Guile upstream.

Is there any way to tell for sure?

texmacs

Last information was that upstream doesn't support 2.0 yet

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731787

but texmacs may also not be currently suitable for Debian for other
reasons?

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711383

It's not very clear from that bug report whether texmacs is undistributable in its current state in sid, but if so it should be removed for as long as the maintainer is unwilling to fix it anywhere except experimental. (Also stable, if affected, but that's another matter.)

swig2.0

I'm probably just missing something obvious, but I'm not sure why this
is still listed -- 2.0.12-1 appears to be in testing, and it is supposed to have migrated to guile-2.0. Looking in the control file I also don't
see any obvious guile-1.8 deps...

ftp-masters will be able to confirm, but I *think* swig2.0 version 2.0.11-1.1 (with its build-depends on guile-1.8-dev) is being kept around for sparc, where the new version does not yet build because of a missing build-dep on ruby2.1. Thus dak rightly complains when asked to remove it.

graphviz

Hmm, "dak ... -s testing -Rn guile-1.8" doesn't list it, but maybe "-s
testing" isn't working right?  In any case, I imagine it's the swig dep
above.

No - graphviz has its own build-dependency on guile-1.8-dev, and an old version is being kept around for sparc for the same reasons.

Finally:

guile-cairo [1]

Looks like this may just be waiting on a testing transition, which may
have been blocked by a (now fixed) problem with guile-2.0 on arm*.  If
so, it should just need a rebuild on arm*.

Scheduled rebuilds (given back), and they appear to have built.

HTH,

--
Jonathan Wiltshire                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

<directhex> i have six years of solaris sysadmin experience, from
            8->10. i am well qualified to say it is made from bonghits
			layered on top of bonghits


Reply to: