Am Fri, 6 Oct 2017 18:12:40 +0200 schrieb Thomas Klausner <tk%giga.or.at@localhost>: > Since you add glproto.mk unconditionally anyway, > option turning it on by default. You lost me there. Glproto seems to be needed in any case, IMHO, unrelated to osmesa being chosen or not. I'd file it as unrelated change/bugfix. > Also, there seem to be unrelated changes, perhaps those can be split > up in two logically separate diffs. Apart from glproto … which changes do you mean? The SUBST_FILES and SUBST_SED lines? One of them probably comes from me trying a build without CC (CXX?) set. I guess I can remove the SUBST_SED line. The SUBST_FILES relate to code for osmesa that was not active before. > > I use it to build pkgsrc with graphical fun on headless servers, using > > osmesa as viable software rasterizer for X11 sessions over ssh. > > Can you tell me more about how that works? I confused terms in retrospect. No, the osmesa thing was added for offscreen GL rendering in math/octave. That's why I patch octave to depend on mesalib. I worked on octave with proper GUI as Matlab alternative (in case people really are desperate enough to run that over SSH) and for that, I needed osmesa. When I run an ssh session using `ssh -Y`, I get this OpenGL renderer string: Gallium 0.4 on softpipe … llvmpipe might also be interesting for this, but softpipe seems to work OK. This is not bandwidth-efficient, but rather reliable. DRI over SSH confuses me. So … you'd want two patches? 1. general fixup (like glproto) 2. osmesa option The mesalib package stays ugly/convoluted in any case … Alrighty then, Thomas -- Dr. Thomas Orgis Universität Hamburg RRZ / Basisinfrastruktur / HPC Schlüterstr. 70 20146 Hamburg Tel.: 040/42838 8826 Fax: 040/428 38 6270
Attachment:
smime.p7s
Description: S/MIME cryptographic signature