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. CHANGES Makefile distinfo pkg-descr REMOVES 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 these changes. Thanks! --Chris
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 ' src/core/__init__.py.in 834: print \ src/core/database.py 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. https://github.com/FontManager/font-manager/releases
(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 them. 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. --Chris
> 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 be well. 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! --Chris
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.