Re: [Fink-devel] Apparently libXt isn't actually a leaf on the X11 library tree after all

2016-11-07 Thread Alexander Hansen 

> On Nov 3, 2016, at 17:26, Alexander Hansen  
> wrote:
> 
>> 
>> On Nov 3, 2016, at 16:56, Hanspeter Niederstrasser > > wrote:
>> 
>> On 11/2/16 6:48 PM, Alexander Hansen wrote:
>>> We had thought that libXt wasn’t actually linked in the X11 tree, but this 
>>> appears not to be so.
>>> 
>>> It’s linked by:
>>> /opt/X11/lib/libXaw6.6.dylib
>>> /opt/X11/lib/libXaw7.7.dylib:
>>> /opt/X11/lib/libXaw8.8.dylib:
>>> /opt/X11/lib/libXaw3d.8.dylib:
>>> (these may not matter since we’ve got libxaw3dxft2)
>>> /opt/X11/lib/libxkbui.1.dylib
>>> /opt/X11/lib/libXmu.6.dylib
>>> 
>>> The last one appears to be what is causing runtime failures with xemacs, 
>>> since xemacs links to /opt/X11/lib/libXmu.6.dylib and to 
>>> /opt/X11/lib/libXt.6.dylib, along with our libXaw.8.dylib 
>>> (libxaw3dxft-shlibs) which now links to Fink’s libxt.6.dylib from 
>>> libxt-shlibs.
>>> 
>>> Unfortunately, the whole rationale for having our own libxt (not so much 
>>> for libxt-flat) was to try to provide a consistent libXt so that people 
>>> wouldn’t have things break when updating from Xquartz 2.7.8 to later 
>>> versions where libXt has been mucked with.
>>> 
>>> Here are some options:
>>> 
>>> 1)  Ditch libxt, possibly libxt-flat, and roll our own Xquartz
>> 
>> I've been keeping an X11 set of packages mostly up to date: 
>> http://cvs.snaggledworks.com/viewvc.cgi/fink/10.7/main/finkinfo/x11 
>>  and 
>> x11-system directories.
>> 
>> The libraries are current. xorg-server is not current and I haven't used 
>> it in probably 3 years (and I was running 10.7 at the time). Although it 
>> ran, there were several things that still needed patching (xinit I 
>> believe was looking in wrong paths). Also, IIRC, StartupItems behavior 
>> has changed since then and would probably need to be fixed in these 
>> packages. Also, there currently is no xorg-libxt-flat package in my set.
>> 
>> I'm agnostic on rolling our own versus forcing an update to 2.7.11. The 
>> latter is less work, but we are at the mercy of another fix from upstream.
>> 
>> Hanspeter
>> 
>> 
> 
> Personally, I don’t see much point in not just dealing with what Xquartz 
> throws at us.  We didn’t elect to use our own X11 distro at the time 10.5 
> came out, so trying to do that now seems like a huge hassle if it is 
> installed in the Fink tree.  Installing outside of the Fink tree will also be 
> a hassle unless we use /opt/X11, and then we get into the alternative hassle 
> of dealing with manual overwrites.
> 
> --akh

Here’s my proposal:

1)  Merge a feature branch I created—this uses the Xquartz version in the 
system-xfree86* packages instead of always “2:7.2-2”.  
https://github.com/fink/fink/tree/show-xquartz-release-version

2) Update libxaw3dxft and packages which depend on it to carry:
BuildConflicts: libxt, libxt-flat
as well as *Depends on system-xfree86{-shlibs,-dev} (>= 3:2.7.112-3). (The 
versioning that I can extract from the Xquartz receipt gives 2.7.112 for 
Xquartz-2.7.11).

3) Get rid of libxt (not flat).  I guess as an alternative we could just have 
_it_ carry the system-xfree86 dependency and relegate it to a bundle which 
installs no files.

I’m not currently worried about libxt-flat and Motif-related packages because 
they work right now.




-- 
Alexander Hansen, Ph.D.
Fink User Liaison

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Apparently libXt isn't actually a leaf on the X11 library tree after all

2016-11-03 Thread Alexander Hansen 

> On Nov 3, 2016, at 16:56, Hanspeter Niederstrasser  
> wrote:
> 
> On 11/2/16 6:48 PM, Alexander Hansen wrote:
>> We had thought that libXt wasn’t actually linked in the X11 tree, but this 
>> appears not to be so.
>> 
>> It’s linked by:
>> /opt/X11/lib/libXaw6.6.dylib
>> /opt/X11/lib/libXaw7.7.dylib:
>> /opt/X11/lib/libXaw8.8.dylib:
>> /opt/X11/lib/libXaw3d.8.dylib:
>> (these may not matter since we’ve got libxaw3dxft2)
>> /opt/X11/lib/libxkbui.1.dylib
>> /opt/X11/lib/libXmu.6.dylib
>> 
>> The last one appears to be what is causing runtime failures with xemacs, 
>> since xemacs links to /opt/X11/lib/libXmu.6.dylib and to 
>> /opt/X11/lib/libXt.6.dylib, along with our libXaw.8.dylib 
>> (libxaw3dxft-shlibs) which now links to Fink’s libxt.6.dylib from 
>> libxt-shlibs.
>> 
>> Unfortunately, the whole rationale for having our own libxt (not so much for 
>> libxt-flat) was to try to provide a consistent libXt so that people wouldn’t 
>> have things break when updating from Xquartz 2.7.8 to later versions where 
>> libXt has been mucked with.
>> 
>> Here are some options:
>> 
>> 1)  Ditch libxt, possibly libxt-flat, and roll our own Xquartz
> 
> I've been keeping an X11 set of packages mostly up to date: 
> http://cvs.snaggledworks.com/viewvc.cgi/fink/10.7/main/finkinfo/x11 
>  and 
> x11-system directories.
> 
> The libraries are current. xorg-server is not current and I haven't used 
> it in probably 3 years (and I was running 10.7 at the time). Although it 
> ran, there were several things that still needed patching (xinit I 
> believe was looking in wrong paths). Also, IIRC, StartupItems behavior 
> has changed since then and would probably need to be fixed in these 
> packages. Also, there currently is no xorg-libxt-flat package in my set.
> 
> I'm agnostic on rolling our own versus forcing an update to 2.7.11. The 
> latter is less work, but we are at the mercy of another fix from upstream.
> 
> Hanspeter
> 
> 

Personally, I don’t see much point in not just dealing with what Xquartz throws 
at us.  We didn’t elect to use our own X11 distro at the time 10.5 came out, so 
trying to do that now seems like a huge hassle if it is installed in the Fink 
tree.  Installing outside of the Fink tree will also be a hassle unless we use 
/opt/X11, and then we get into the alternative hassle of dealing with manual 
overwrites.

--akh--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Apparently libXt isn't actually a leaf on the X11 library tree after all

2016-11-03 Thread Jack Howarth 
On Thu, Nov 3, 2016 at 7:56 PM, Hanspeter Niederstrasser
 wrote:
>
> On 11/2/16 6:48 PM, Alexander Hansen wrote:
> > We had thought that libXt wasn’t actually linked in the X11 tree, but this 
> > appears not to be so.
> >
> > It’s linked by:
> > /opt/X11/lib/libXaw6.6.dylib
> > /opt/X11/lib/libXaw7.7.dylib:
> > /opt/X11/lib/libXaw8.8.dylib:
> > /opt/X11/lib/libXaw3d.8.dylib:
> > (these may not matter since we’ve got libxaw3dxft2)
> > /opt/X11/lib/libxkbui.1.dylib
> > /opt/X11/lib/libXmu.6.dylib
> >
> > The last one appears to be what is causing runtime failures with xemacs, 
> > since xemacs links to /opt/X11/lib/libXmu.6.dylib and to 
> > /opt/X11/lib/libXt.6.dylib, along with our libXaw.8.dylib 
> > (libxaw3dxft-shlibs) which now links to Fink’s libxt.6.dylib from 
> > libxt-shlibs.
> >
> > Unfortunately, the whole rationale for having our own libxt (not so much 
> > for libxt-flat) was to try to provide a consistent libXt so that people 
> > wouldn’t have things break when updating from Xquartz 2.7.8 to later 
> > versions where libXt has been mucked with.
> >
> > Here are some options:
> >
> > 1)  Ditch libxt, possibly libxt-flat, and roll our own Xquartz
>
> I've been keeping an X11 set of packages mostly up to date:
> http://cvs.snaggledworks.com/viewvc.cgi/fink/10.7/main/finkinfo/x11 and
> x11-system directories.
>
> The libraries are current. xorg-server is not current and I haven't used
> it in probably 3 years (and I was running 10.7 at the time). Although it
> ran, there were several things that still needed patching (xinit I
> believe was looking in wrong paths). Also, IIRC, StartupItems behavior
> has changed since then and would probably need to be fixed in these
> packages. Also, there currently is no xorg-libxt-flat package in my set.
>
> I'm agnostic on rolling our own versus forcing an update to 2.7.11. The
> latter is less work, but we are at the mercy of another fix from upstream.
>
> Hanspeter


Hanspeter,
  FYI, I have posted patches for fink to support sandboxing at
https://github.com/fink/fink/pull/135 which will allow you easily
blacklist /opt/X11. The patches use a %p/etc/fink.sb file containing a
simple list of directories to be blacklisted.
 Jack

>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Apparently libXt isn't actually a leaf on the X11 library tree after all

2016-11-03 Thread Hanspeter Niederstrasser 
On 11/2/16 6:48 PM, Alexander Hansen wrote:
> We had thought that libXt wasn’t actually linked in the X11 tree, but this 
> appears not to be so.
>
> It’s linked by:
> /opt/X11/lib/libXaw6.6.dylib
> /opt/X11/lib/libXaw7.7.dylib:
> /opt/X11/lib/libXaw8.8.dylib:
> /opt/X11/lib/libXaw3d.8.dylib:
> (these may not matter since we’ve got libxaw3dxft2)
> /opt/X11/lib/libxkbui.1.dylib
> /opt/X11/lib/libXmu.6.dylib
>
> The last one appears to be what is causing runtime failures with xemacs, 
> since xemacs links to /opt/X11/lib/libXmu.6.dylib and to 
> /opt/X11/lib/libXt.6.dylib, along with our libXaw.8.dylib 
> (libxaw3dxft-shlibs) which now links to Fink’s libxt.6.dylib from 
> libxt-shlibs.
>
> Unfortunately, the whole rationale for having our own libxt (not so much for 
> libxt-flat) was to try to provide a consistent libXt so that people wouldn’t 
> have things break when updating from Xquartz 2.7.8 to later versions where 
> libXt has been mucked with.
>
> Here are some options:
>
> 1)  Ditch libxt, possibly libxt-flat, and roll our own Xquartz

I've been keeping an X11 set of packages mostly up to date: 
http://cvs.snaggledworks.com/viewvc.cgi/fink/10.7/main/finkinfo/x11 and 
x11-system directories.

The libraries are current. xorg-server is not current and I haven't used 
it in probably 3 years (and I was running 10.7 at the time). Although it 
ran, there were several things that still needed patching (xinit I 
believe was looking in wrong paths). Also, IIRC, StartupItems behavior 
has changed since then and would probably need to be fixed in these 
packages. Also, there currently is no xorg-libxt-flat package in my set.

I'm agnostic on rolling our own versus forcing an update to 2.7.11. The 
latter is less work, but we are at the mercy of another fix from upstream.

Hanspeter


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Apparently libXt isn't actually a leaf on the X11 library tree after all

2016-11-03 Thread Jack Howarth 
Daniel,
 I am seeing...

$ xemacs
Error: Couldn't find per display information

for

ii  xemacs 21.4.22-8  Highly customizable text editor
ii  libxaw3dxft1.6.2-6Athena widget set with 3D look
ii  libxaw3dxft-sh 1.6.2-6Athena widget set with 3D look
ii  libxt  1.1.5-2X toolkit library
ii  libxt-flat-shl 1.1.5-2X toolkit library
ii  libxt-shlibs   1.1.5-2X toolkit library

under Xquartz 2.7.11 despite the back port the Debian fix for
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327655.
The only thing that solves the issue here on 10.11 is to link both
libxaw3dxft and xemacs against the libXt from Xquartz.
  Jack

On Wed, Nov 2, 2016 at 7:48 PM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:

> We had thought that libXt wasn’t actually linked in the X11 tree, but this
> appears not to be so.
>
> It’s linked by:
> /opt/X11/lib/libXaw6.6.dylib
> /opt/X11/lib/libXaw7.7.dylib:
> /opt/X11/lib/libXaw8.8.dylib:
> /opt/X11/lib/libXaw3d.8.dylib:
> (these may not matter since we’ve got libxaw3dxft2)
> /opt/X11/lib/libxkbui.1.dylib
> /opt/X11/lib/libXmu.6.dylib
>
> The last one appears to be what is causing runtime failures with xemacs,
> since xemacs links to /opt/X11/lib/libXmu.6.dylib and to
> /opt/X11/lib/libXt.6.dylib, along with our libXaw.8.dylib
> (libxaw3dxft-shlibs) which now links to Fink’s libxt.6.dylib from
> libxt-shlibs.
>
> Unfortunately, the whole rationale for having our own libxt (not so much
> for libxt-flat) was to try to provide a consistent libXt so that people
> wouldn’t have things break when updating from Xquartz 2.7.8 to later
> versions where libXt has been mucked with.
>
> Here are some options:
>
> 1)  Ditch libxt, possibly libxt-flat, and roll our own Xquartz
> 2)  Ditch libxt, and force people to install Xquartz-2.7.11.  Right now
> we’d have to use the “system-pkgconfig-xorg-server” virtual package to do
> this.  In principle we could adjust system-xfree86* to get the aggregate
> Xquartz release version instead of the “2:7.2” that we’ve been using for
> ages, but I don’t know if that gets stored anywhere but the package
> receipt, and that’s somewhat fragile to rely on.
>
> We’d want to adjust the fink-package-precedence script appropriately for
> whichever option we pick.
>
> #2 seems like the least work in the short term, but I know that some folks
> in the community don’t like it when we force dependencies on particular
> versions of non-Fink tools (e.g. the Xcode CL tools).
> #1 would rely on some kind soul being willing/able to maintain a Fink
> Xquartz, and we’d have to modify our existing X11-using packages to use
> only a Fink Xquartz.
>
> Though I’m leaning towards the following options:
>
> 3)  Stop bothering with X11 packages
> 4)  Give the hell up
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel