Created attachment 212015 [details]
svn diff for x11-fonts/font-manager
x11-fonts/font-manager has been tagged for removal
on 2020-03-01 for it's use of python27. Python27
does not have this EOL. Do I raised a pr(1) on it,
also indicating my current work on this port.
( bug #244488 )
So now I'm raising another pr(1) with the results
of that work.
This carries a version jump from 0.5.7==>0.6.0
as this version requires python3. Leaving the
some points on the 0.5.x branch as need be.
files/ (this was a *real* patch-fest. the number of
required patches was intolerable. So this
version carries no backward support).
That's it! Please find attached the svn diff for
A quick sanity check shows that there are still a bunch of print
statements (unsupported in Python 3.x), so this is clearly not yet
ready and I suspect it would be buggy.
$ rg 'print '
834: print \
186: print font['filepath']
One thing I do not understood here is why you are switching to
your own fork instead of tracking upstream? Upstream seems to have
newer releases that no longer use Python, so why not update? That
would solve the Python problem too.
(In reply to Tobias Kortkamp from comment #1)
I happen to like the Python version. I've
tried the 7.x versions, and didn't care for
As to the print statements. I had/have no
troubles here. Python(3.5-7). I need a kludge
to run it on 3.8.
But I'll grant you, I still have some cleanup
to do, which I'm doing now.
> I happen to like the Python version. I've tried the 7.x versions, and didn't care for them.
This stance worries me since it basically violates POLA for people
coming from other systems who'd expect font-manager to be the version
as provided by upstream. You are also reserving the font-manager
package name for your own fork which will be confusing for committers
and users in the future.
If you insist on keeping the Python version around please do it
under a different name. We can then rename the port accordingly
and I can update x11-fonts/font-manager to the Vala version.
> As to the print statements.
This was only a quick sanity check from me. There are a lot more
issues. Please use 2to3 to find some of them.
Two more issues:
1. It still depends on x11-toolkits/pygtk2 which is Python 2.7 only.
2. textproc/gnome-doc-utils is gone.
Not sure how this can even remotely work like this.
You raise some good points, all of which I too
considered before embarking on this. After all
it would be a lot less work for me to just use
the 07x version on guithub. ;)
But like I said; I prefer the python version,
and given that the author isn't using the 06x
version numbers in any way. I think all will
As to (potential) confusion; I should probably
add a note in the README && other assorted
documentation indicating that the 06x version(s)
are a diversion from the authors tree. I also
thought it be useful to create a
font-manager-devel, or font-manager-vala on
the ports(7) tree.
That tracks the 07x+ version(s).
As to pygtk2 && gnome-doc-utils; I know. I
took a chance, and *surprisingly* it all still
worked with py3x. But I wanted to address gnome@
to see what, if any direction they were planning
considering py27 has already been EOLd, and
the portsmgr indicates it removel is on the
horizon. Gnome themselves still appear to be
developing them. So either *they* update, or
I pull only what's absolutely required, and
incorporate it into the port source. The
gnome-doc-utils is only needed for the build;
to create the docs. So I may well be able to
simply generate the docs, and incorporate them
in their built form.
Anyway. As you've already stated; I've still
got some work yet to do on all this. So I'll
get back to it. :)
Thanks for your input!
Well, if you going to keep this zombieware alive, you should also update the WWW in pkg-descr.
*** Bug 244488 has been marked as a duplicate of this bug. ***
(In reply to Chris Hutchinson from comment #5)
To be honest, I don't think our current gnome@ team has the capacity for your forking experiments. gnome-doc-utils is dead and buried, it was abandoned upstream at least six years ago.
As Tobik says, if you fork this all you do in the end is just confusing users and developers, so I'm going to be blunt and reject this patch. It would be better to update this port to version 7 to match upstream.
Preserving abandonware is one thing, but this request just does not make any sense.