-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pango, pygtk: fixing up newer pango and pygtk #74282
Conversation
I don't think this will work because I tried it. You'd have to give pygtk it's own version of gtk overridden to use an older version of pango. And that's still a pretty poor solution, I didn't PR it. Edit: though I'm not opossed to this anymore. I'd consider those applications that still use this abandoned library unmaintained. So tier of quality... it won't matter to much there's another version of gtk2 for this. |
I also think there's probably a lot of packages we could either remove/update to not use pygtk. Edit: have wip work for this. |
@worldofpeace: Thanks for the pointers, I'll look into it. |
Opened #74295 to remove some pygtk users that are also probably abandoned. |
pygtk should build now, according to #65670 (comment) |
Hmm forgot about. Looking through my branches when I did my testing, I didn't look like I succeeded in getting it to build even with that. |
I must admit, this issue has been kinda sitting in my stash for a while, so I might need to refresh my memory a bit. I think I saw this commit "back then" too. I tried this now again, and think to remember that they for some reason did not bring back a part of the API. Building pygtk with the most recent pango 1.44.7 release I'm getting the following (without any adjustments to pygtk), even though there was a remark about a fix;
Maybe I'm missing something. @matthiasclasen: If possible, could you please advise? Were you able to compile pygtk 2.24.0 with 1.44.7? |
As far as we can, for sure! I was viewing this more as a defensive stance for the cases where we might not be able to, but maybe it's just pessimism. :) |
Something in this vein might work: diff --git a/pkgs/development/python-modules/pygtk/default.nix b/pkgs/development/python-modules/pygtk/default.nix
index 09ccb5c3d95..6741ac695b4 100644
--- a/pkgs/development/python-modules/pygtk/default.nix
+++ b/pkgs/development/python-modules/pygtk/default.nix
@@ -1,4 +1,4 @@
-{ stdenv, fetchurl, python, pkgconfig, gtk2, pygobject2, pycairo
+{ stdenv, fetchurl, fetchpatch, python, pkgconfig, gtk2, pygobject2, pycairo
, buildPythonPackage, libglade ? null, isPy3k }:
buildPythonPackage rec {
@@ -12,6 +12,19 @@ buildPythonPackage rec {
sha256 = "04k942gn8vl95kwf0qskkv6npclfm31d78ljkrkgyqxxcni1w76d";
};
+ patches = [
+ # not sure what this does but Fedora and Arch have it
+ (fetchpatch {
+ url = "https://src.fedoraproject.org/rpms/pygtk2/raw/93b36f49fdf19b3673c04f2f85310e88b1f0fcc6/f/0001-Fix-leaks-of-Pango-objects.patch";
+ sha256 = "031px4w5cshcx1sns430sdbr2i007b9zyb2carb3z65nzr77dpdd";
+ })
+ ];
+
+ postPatch = ''
+ # regenerate pango defs so it builds
+ python2 $(pkg-config pygobject-2.0 --variable codegendir)/h2def.py $(pkg-config pango --variable includedir)/pango-1.0/pango/*.h > pango.defs
+ '';
+
nativeBuildInputs = [ pkgconfig ];
buildInputs = stdenv.lib.optional (libglade != null) libglade;
|
So, I'm currently trying this, specifically for
Also, maybe interesting to keep an eye on, even though there was no apparent activity in 10 months: https://gitlab.gnome.org/GNOME/gimp/issues/339 |
I believe https://gitlab.gnome.org/GNOME/gimp/issues/339 is already solved on master (#67576). |
@jtojnar Ahh right ✨ The postPatch there is probably what I was missing and the issue. |
Does not seem to generate functions for me, though. |
Or just drop the single virtual call https://github.com/flathub/org.glimpse_editor.Glimpse/blob/master/patches/pygtk-Drop-the-PangoFont-find_shaper-virtual-method.patch. Alatiera is planning an upstream MR. |
adwaita is currently failing on staging, running bisect. |
That is just weird:
That is just weird as jasper did not propagate anything other than libjpeg, which is already a dependency of gdk-pixbuf. That should have no bearing on MIME sniffing. |
Continuing the discussion in #73586 |
Note for later: We probably want a release-notes entry and possibly doc adjustments to that one, regarding deprecated bitmap fonts. |
Would wording like this work:
|
I think the wording is good, but maybe we can find some other resource to link. I remember that I once had some release note PR and included the link to another PR in the description and the reviewers did not think linking to a nixpkgs PR was the best option. What do you think of maybe using https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/ ? |
IMHO the issue is better resource as it provides more details (including discussion about converting bitmap fonts). Only a small part of the blog post is dedicated to this and the link is in the issue OP for those interested. |
Alright, personally I'm fine with the issue link, so I'll just add it and then we'll see. |
* Removes an unused binding that prevents compilation with newer pango * Adds a patch to fix a memory leak
a patch to cmake to correctly locate harfbuzz: https://gitlab.kitware.com/cmake/cmake/issues/19531, needed for more recent pango.
8aa178c
to
c25d4ab
Compare
Can we wrap this up? It is blocking Nautilus update. Edit: did not see you already pushed the release notes. |
@jtojnar: From my side, yes, we can give it a go and deal with any unexpected fallout then. I was just waiting on reviewers approval/further change requests. |
Thanks for the support and help. I will try to watch for upcoming breakages, but otherwise, feel free to ping me. |
@d-goldin I believe I suggested not linking to our internal tracker or PRs, and to provide a better resource in the release notes. In this case it's an external issue so it's fine to link. |
Another broken abandoned package is Not sure it is worth it trying to fix it. |
Motivation for this change
We are currently on a rather old version of pango and are being kept back by
pygtk
, which in somesort of abandoned-but-beloved limbo.
This proposes a split into two pango versions to be able to movethe rest of the ecosystem along and just pin pygtk until we know what to do about it.
Edit: After the below discussion, we decided to not split and instead patch up pygtk.
This is related to some discussion in #71571 from a while ago.
Unfortunately, due to the size of the rebuild, I'm unable to rebuild this on my machine, so I'd be thankful if somebody could do a nix-review run.
Right now this requires a patch to cmake to correctly locate harfbuzz: https://gitlab.kitware.com/cmake/cmake/issues/19531 until we get 3.16 in (it was just released today, but has quite a lot of changes, so I'm leaving the patch in for now instead of bumping the version).
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)Notify maintainers
cc @7c6f434c as maintainer and @jtojnar because of context