Adding this todo for later. IIUC this amounts to adding xorg-server, which they explain how to build. They also include a build script, which may be of use. Also quartz-wm is probably needed to have some Window Manager. Hopefully this isn't too bad especially since we have all the X11 libraries thanks to @pkgw.
Looking at the Macports portfile, we need
requirements / build:
requirements/run:
test:
Thanks for putting this list together @epruesse.
Couple of questions. First, just to verify, checked means feedstock with packages? Second are there any of these that have open PRs associated? If so, it might be helpful to include the links in the list.
Also for libpixman, I believe we call it pixman unless I'm missing a subtle distinction being made here.
Yes, I believe that pixman provides what XQuartz would need.
@jakirkham Yes, checks means package is available. I didn't check for open PRs - this was more to get a list of things that definitely need to be there first. Since the build requirements seem to be all *proto, which in X.org lingo refers to header only libs / API definitions, they should be easy enough to add. Is it ok to bundle them in one PR?
PR #2817 adds 26 xorg*proto packages -- that's all but the two DRI ones.
Wow! Thanks @epruesse.
Is it ok to bundle them in one PR?
The only challenge is being able to hold someone's attention span long enough to review them all in one go. That said, we can always use that PR as a starting point and pull out individual recipes into separate PRs after checking them.
@jakirkham These are the "protocol" packages. They contain nothing but one or two header files, sometimes an xml file, and a pc (pkg-config) file. So it's all the same. If you diff two packages you'll see the only difference is in name/version/sha256.
I was debating whether to keep them in individual packages at all. But since X.org has them that way and the Distros seem to follow (e.g. xorg-printproto's "Print.h" is in Debian in x11proto-print-dev), I figured I'd just create 26 packages at once... They build very quickly, nothing much to do.
I've got a little further on this (see here). Build seems to work, but I can't test missing two major run time components: xorg-fonts and xkeyboard-config. The later unfortunately requires perl-xml-parser, which in turn requires quite a few perl packages. They are available in bioconda, though, so I could "merge" them into conda-forge. We're talking another two dozen packages though.
@conda-forge/core @bgruening Are there any plans WRT perl in conda-forge / migration of perl packages from bioconda to here?
@jakirkham The topic here may as well become "Xquartz and Xwin" -- both are the relevant pieces missing to get X11 apps actually running on non-Linux platforms w/o non-conda installs.
@ebolyen no plans yet. But we are happy to help as we did with the R packages. However, currently we are still busy with the R story and it is yet not clear howto update them. So I think we should solve this question before we start another bulk migration.
@jakirkham What do you think I should do re xkeyboard-config? Without that package, XQuartz will compile but not work properly.
Options:
By the R update story, @bgruening, are you referring to how things are pinned? ( https://github.com/conda-tools/conda-build-all/pull/86 ) Or are there other issues?
Sorry for the long delay here, @epruesse. Porting perl packages seems like the right thing to do. Though you would know best what sort of timeline this should happen on.
@jakirkham Well, I'm pondering whether I should wait for conda-build 3.* to make it into conda-forge before I create any more packages.
What features are you hoping to use from conda-build 3 that might make this easier?
The pinning and the outputs mainly. I've run into too many issues with conda pulling the wrong packages and am really hoping those things were addressed in the 3.
W.r.t #539 -- it's not just XQuartz, but also Xwin and Xvfb that would be desirable to have in conda directly. Xvfb in particular, as that would allow testing X based software during package build.
Better pinning will be nice. Though I don't think this will replace the need for an ABI tracker and some manual tweaks. Semantic versioning is still not used often enough.
I agree. We want working X11 on all platforms. Was just trying to address the PR author's motivations, which hinged around getting XQuartz on macOS.
Most helpful comment
PR #2817 adds 26 xorg*proto packages -- that's all but the two DRI ones.