Gtk+ goes quartz-only #39868

tschoonj · 2015-05-18T11:31:19Z

This branch represents an effort to remove the X11 dependency completely from gtk+ and its dependencies cairo and pango.

The rationale behind this move is:

It is a major pain for homebrew to support simultaneously the X11 and quartz backends of gtk+. Some formulas require the quartz backend explicitly (like gtk-mac-integration, which for this reason is still not included in homebrew). See also e.g. without-x11 option removed in cairo, cairomm, pango and pangomm #38969 for a discussion about this (there are a lot more PRs and issues where this problem was brought up!)
In gtk+3, the X11 backend is not even supported anymore
X11 is very un-Mac OS X anyway and delivers an inferior user experience (IMHO)
~~Are there any packages that really need the gtk+ X11 backend to work properly anyway?~~ Apparently gtkglarea does, it will be moved to the boneyard...

My plan is basically to:

Remove X11 from the dependency list of cairo, pango and gtk+. Modify the configure argument list to ensure that no X11 bindings will get built. Explicitly enable quartz support. Update the revision number of these formulas
Update the revision number of all formulas in Homebrew/homebrew that depend on gtk+. This will be the most work since many of these formulas will not be audit --strict compliant (missing tests).
Update the revision number of all formulas in all other Homebrew taps that depend on gtk+. Will create separate pull request for each tap which should be pulled in when this PR is merged in.
1. science: Homebrew/homebrew-science#2311
2. x11: Homebrew/homebrew-x11#83
3. games: Homebrew/homebrew-games#268

It is possible that some formulas that depend only on cairo and/or pango will also need a revision bump if they depend explicitly on the cairo/pango dylibs that are linked to X11. Not sure how to identify these though.

TO DO list (will get longer...):

MikeMcQuaid · 2015-05-18T11:44:21Z

Library/Formula/cairo.rb

@@ -22,7 +21,6 @@ class Cairo < Formula
  depends_on "libpng"
  depends_on "pixman"
  depends_on "glib"
-  depends_on :x11 => :recommended


:optional, probably?

I vote no. Let's slay the X11 monster and keep it from showing its ugly head ever again in the gtk+ dependency graph.

I'm OK with that.

DomT4 · 2015-05-18T14:28:04Z

Library/Formula/gtk+.rb

  depends_on "gobject-introspection"
+  option "with-quartz-relocation"


Let's move the option above the dependencies, with space between the two blocks.

Also, option should have some explain message.

taken care of in latest commit

xu-cheng · 2015-05-18T16:25:58Z

Personally I think it's bad to put all of these inside on PR. It consumes too many ci resources.

tschoonj · 2015-05-18T16:28:15Z

Wouldn't it be better to configure ci to build only the last commit?

It's much easier to do this in one commit since this update will need to happen simultaneously for all packages involved

vszakats · 2015-05-18T16:30:52Z

Library/Formula/cairo.rb

@@ -1,10 +1,9 @@
-require "formula"
-
 class Cairo < Formula
  homepage "http://cairographics.org/"
  url "http://cairographics.org/releases/cairo-1.14.2.tar.xz"
  mirror "http://www.mirrorservice.org/sites/ftp.netbsd.org/pub/pkgsrc/distfiles/cairo-1.14.2.tar.xz"


It'd suggest https for this mirror, it does support it:
https://www.mirrorservice.org/sites/ftp.netbsd.org/pub/pkgsrc/distfiles/cairo-1.14.2.tar.xz

DomT4 · 2015-05-18T16:31:49Z

It's probably sensible to tuck them all inside the same PR so we can test they all actually work against the new changes, since a potential breakage and revert would be a nightmare given how deep GTK+ runs.

It's best to not push each change as you make it though, make them locally and then push the end result. Means we only need to whack the CI a few times rather than 40+ times.

tschoonj · 2015-05-18T16:36:57Z

fair enough, will make only pushes when I have to from now on.

still I think the best solution would be for the build-bot to look only to the latest commit

MikeMcQuaid · 2015-05-18T16:40:18Z

It does but if it's already started a job when you've pushed another it doesn't know to stop the existing job.

xu-cheng · 2015-05-18T16:42:08Z

Wouldn't it be better to configure ci to build only the last commit?

It's not current configure. @MikeMcQuaid may have some opinion on this.

. probably sensible to tuck them all inside the same PR so we can test they all actually work against the new changes, since a potential breakage and revert would be a nightmare given how deep GTK+ runs.

I think the magnitude may be over the capacity that one PR can handle. As one of jacknagel's old advice, I would suggest to create a temporary tap and move all of gtk related formulae there. Therefore, we can test each commit one by one using Travis CI. After that, we can move these formulae back to core.

DomT4 · 2015-05-18T16:57:03Z

I think the magnitude may be over the capacity that one PR can handle.

Disagree personally. It handled OpenSSL before, and OpenSSL was a bigger PR with some significantly heftier formulae. I would be surprised if all the GTK+ changes here in the end stress the bot more than one Rust build does. We would have a similar, if not more PITA, problem with Travis in that the build would be likely to timeout or exceed the 5MB log limit imposed on free Travis.

If someone wants to follow Jack's advice I'm fine with that too, but I think Jack's suggestion was to not actually remove them from the core, just to copy them, remove the x11 tie in, and then merge them back in to core?

tschoonj · 2015-05-18T17:03:24Z

By the way: if someone wants to help out, I would really appreciate it if someone would move all Formulas from homebrew-x11 that depend on either gtk+ or gtk+3 to the homebrew tap. They have no longer any business being there.

jacknagel · 2015-05-18T20:42:53Z

if someone would move all Formulas from homebrew-x11 that depend on either gtk+ or gtk+3 to the homebrew tap

Please don't PR this yet, though.

jacknagel · 2015-05-18T20:43:37Z

Please remember that every time you push it starts a new CI job and does not kill those that are already queued. I understand this isn't ideal, but at this moment that's how it works, so let's try to ease up on the push frequency. Thanks!

tschoonj · 2015-05-19T06:55:45Z

It looks like the CI jobs stopped. Can anyone check whats going on?

MikeMcQuaid · 2015-05-19T07:05:34Z

They were probably manually killed and/or timed out.

DomT4 · 2015-05-19T07:23:12Z

The last build failed on gnome-icon-theme, which had a fairly insistent failure during the compile. Not sure why the PR here says Merge build triggered still, doesn't seem to be in the queue.

MikeMcQuaid · 2015-05-19T07:24:33Z

@BrewTestBot test this please

tschoonj · 2015-05-19T07:40:42Z

Thanks, the gnome-icon-theme problem is related to gdk-pixbuf and librsvg: during the gnome-icon-theme build, the rsvg-convert utility is invoked to convert svg files. This utility depends on libgdk_pixbuf to load the svg files but fails because it cannot load the svg plugin for some reason.

My latest commits have bumped the revision number of both gdk-pixbuf and librsvg, hoping it may fix this problem.

Could anyone have a look at the audit --strict I am getting for fontforge?

 * python modules have explicit framework links
 These python extension modules were linked directly to a Python
 framework binary. They should be linked with -undefined dynamic_lookup
 instead of -lpython or -framework Python.
   /usr/local/Cellar/fontforge/20150430_1/lib/python2.7/site-packages/fontforge.so
     /usr/local/Cellar/fontforge/20150430_1/lib/python2.7/site-packages/psMat.so

Thanks

DomT4 · 2015-05-19T07:42:30Z

Ignore the fontforge failure for now. I've already pinged Tim about it in an existing thread.

tschoonj · 2015-05-19T07:47:21Z

Ok, will do.

Any reason to keep libgnomecanvas and libgnomecamvasmm? No other formulas appear to use them and they haven't seen an update in 5 years.

MikeMcQuaid · 2015-05-19T08:09:20Z

Any reason to keep libgnomecanvas and libgnomecamvasmm? No other formulas appear to use them and they haven't seen an update in 5 years.

Seems a good enough reason to 💀 them to me.

tschoonj · 2015-05-19T08:11:25Z

Ok, will delete them then.

I was also thinking to remove libglade but it turns out mdk really needs it...

MikeMcQuaid · 2015-05-19T08:13:38Z

Also: if any of this stuff can be made to work with GTK+3 instead of 2 that'd be handy too.

DomT4 · 2015-05-19T08:14:58Z

I'd also prefer we keep libglade. It's heavily useful for quite a few formulae, and outside of Homebrew too.

MikeMcQuaid · 2015-06-16T16:10:42Z

@tschoonj Please don't push any more changes to this branch. I'll address these nits when I pull, thanks.

tschoonj · 2015-06-16T16:13:00Z

@DomT4 pangox-compat is a really weird package. It appears to have been made just for gtkglext, and requires indeed X11. From the git repository of gtkglext it looks like they dropped the need for pangox-compat in their master branch but I doubt they will ever release an update to it.

tschoonj · 2015-06-16T16:14:05Z

@MikeMcQuaid thanks Mike! After pulling in, can you restart the PRs in homebrew-x11 and homebrew-science?

DomT4 · 2015-06-16T16:16:53Z

@tschoonj Thanks for the explanation on pangox-compat. Given the nature of the PR, just wanted to check wasn't a typo. Nice work here getting this done 👍.

tschoonj · 2015-06-16T16:19:40Z

@DomT4 you're most welcome but we aren't done yet. As soon as this PR gets pulled in, after updating people will have runtime linking errors to their gtk-dependent homebrew-science and homebrew-x11 packages.

tschoonj · 2015-06-16T16:21:44Z

@MikeMcQuaid by the way I still need to boneyard two formulas here: qiv and gtkglarea. Shall I already proceed with that?

DomT4 · 2015-06-16T16:26:47Z

Once X11's PR is green I'll pull it there pretty quickly. I don't know how @MikeMcQuaid feels but potentially a lot of the GTK stuff can be moved back to the core now the X11 backend has been killed off.

tschoonj · 2015-06-16T16:30:15Z

Well all packages in x11 and science need to be rebuilt against the new gtk+, which I guess will take a few hours.

And yes a lot of those packages really won't belong there anymore, including those that depend on gtk+3.

victims of the transitioning to gtk-quartz-only: Homebrew/legacy-homebrew#39868 NOTE: these formulas will not be deleted with this PR, a separate will be opened for that later...

victims of the transitioning to gtk-quartz-only: Homebrew#39868 a PR has been opened in the boneyard: Homebrew/homebrew-boneyard#54

tschoonj · 2015-06-16T18:20:03Z

@DomT4 Just wondering about the migration to the boneyard: since I am not migrating out of the core tap, do I have to update the tap_migrations.rb in core with a separate PR? If not they will still be pointing in that file to the x11 tap instead of boneyard...

tschoonj · 2015-06-16T18:21:34Z

@DomT4 sorry wrong PR, this refers of course to the X11 tap migration

DomT4 · 2015-06-16T18:25:02Z

Theoretically if stuff has been migrated from homebrew/homebrew to homebrew/x11 and now to homebrew/boneyard we can change the lines in tap_migrations.rb in a separate PR in the core.

If they never existed in Homebrew/homebrew and aren't in the tap_migrations.rb list - Don't worry about it. Long-term my desire is to support tap_migrations from taps to other taps, or from taps to core, but for now there's no mechanism for that.

tschoonj · 2015-06-16T18:28:43Z

I checked and all three formulas are indeed mentioned in tap_migrations.rb. Will file a PR in core when all this is over.

tschoonj · 2015-06-17T15:36:36Z

@MikeMcQuaid thanks! I pushed my latest changes to homebrew-x11, the build has already started.

Can you manually restart the build in the homebrew-science PR?

MikeMcQuaid · 2015-06-17T15:38:12Z

@tschoonj On it. The rebottling will take priority but I'll get on this ASAP.

victims of the transitioning to gtk-quartz-only: #39868 a PR has been opened in the boneyard: Homebrew/homebrew-boneyard#54 Closes #40792. Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>

MikeMcQuaid · 2015-06-18T14:31:23Z

All PRs merged. Thanks for all your work here @tschoonj!

tschoonj · 2015-06-18T17:28:22Z

you're most welcome. I expect people will file issues now and then when their formulas with optional gtk+ dependency fail to compile (like the vim one this morning).

If so ping me and I will try to fix it

Homebrew has dropped support to X11 on every GTK+ related formula since (Homebrew/legacy-homebrew#39868). This change reflects this decision on go-gtk. By default, builds without support to X11. X11 support can be enabled by using the build flag `with-x11` for users containing a GTK+ installation with X11 support.

MikeMcQuaid reviewed May 18, 2015
View reviewed changes

tschoonj force-pushed the gtk+-goes-quartz-only branch from 7c828ea to ff78579 Compare May 18, 2015 13:25

DomT4 reviewed May 18, 2015
View reviewed changes

vszakats reviewed May 18, 2015
View reviewed changes

tschoonj added a commit to tschoonj/homebrew that referenced this pull request Jun 16, 2015

gtkglarea and qiv: migrating to homebrew/boneyard

c927e01

victims of the transitioning to gtk-quartz-only: Homebrew#39868 a PR has been opened in the boneyard: Homebrew/homebrew-boneyard#54

tschoonj mentioned this pull request Jun 16, 2015

gtkglarea and qiv: migrating to homebrew/boneyard #40792

Closed

MikeMcQuaid closed this in 2f35cc7 Jun 17, 2015

DomT4 mentioned this pull request Jun 17, 2015

Cannot install vim --with-client-server #40832

Closed

patmarion mentioned this pull request Jul 15, 2015

bot-vis does not build with new OS X systems that use XQuartz RobotLocomotion/libbot#3

Closed

ghost mentioned this pull request Jul 15, 2015

Solo3 failed to build on 10.10.2 ncareol/homebrew-lrose-solo3#1

Closed

tschoonj mentioned this pull request Aug 14, 2015

cairo: enable xcb when xquartz is installed #42949

Closed

juniorz mentioned this pull request Sep 21, 2015

Can't install go-gtk on Mac OSX Yosemite (10.10.4) mattn/go-gtk#245

Closed

juniorz mentioned this pull request Sep 21, 2015

Drops support to X11 on Mac OS X by default mattn/go-gtk#248

Merged

Homebrew locked and limited conversation to collaborators Jul 10, 2016

		depends_on "gobject-introspection"
		option "with-quartz-relocation"

Gtk+ goes quartz-only #39868

Gtk+ goes quartz-only #39868

Conversation

tschoonj commented May 18, 2015

MikeMcQuaid May 18, 2015

Choose a reason for hiding this comment

tschoonj May 18, 2015

Choose a reason for hiding this comment

MikeMcQuaid May 18, 2015

Choose a reason for hiding this comment

DomT4 May 18, 2015

Choose a reason for hiding this comment

xu-cheng May 18, 2015

Choose a reason for hiding this comment

tschoonj May 18, 2015

Choose a reason for hiding this comment

xu-cheng commented May 18, 2015

tschoonj commented May 18, 2015

vszakats May 18, 2015

Choose a reason for hiding this comment

DomT4 commented May 18, 2015

tschoonj commented May 18, 2015

MikeMcQuaid commented May 18, 2015

xu-cheng commented May 18, 2015

DomT4 commented May 18, 2015

tschoonj commented May 18, 2015

jacknagel commented May 18, 2015

jacknagel commented May 18, 2015

tschoonj commented May 19, 2015

MikeMcQuaid commented May 19, 2015

DomT4 commented May 19, 2015

MikeMcQuaid commented May 19, 2015

tschoonj commented May 19, 2015

DomT4 commented May 19, 2015

tschoonj commented May 19, 2015

MikeMcQuaid commented May 19, 2015

tschoonj commented May 19, 2015

MikeMcQuaid commented May 19, 2015

DomT4 commented May 19, 2015

MikeMcQuaid commented Jun 16, 2015

tschoonj commented Jun 16, 2015

tschoonj commented Jun 16, 2015

DomT4 commented Jun 16, 2015

tschoonj commented Jun 16, 2015

tschoonj commented Jun 16, 2015

DomT4 commented Jun 16, 2015

tschoonj commented Jun 16, 2015

tschoonj commented Jun 16, 2015

tschoonj commented Jun 16, 2015

DomT4 commented Jun 16, 2015

tschoonj commented Jun 16, 2015

tschoonj commented Jun 17, 2015

MikeMcQuaid commented Jun 17, 2015

MikeMcQuaid commented Jun 18, 2015

tschoonj commented Jun 18, 2015