Re: [Fink-devel] X11 Documentation
At 9:20 AM -0500 2/14/03, Alexander Hansen wrote: I've slowly started making some changes in the X11 docs. As of right now all that I've changed is the current stable version to install from fink, and added Apple X11 Beta 2 info. The next issue, then, is section 3.3: Official Binaries. I'd like to confirm that the proper sequence for Jaguar as of right now is: 1) Install the 4.2.0 XFree86.org binary The easiest thing is to install the Xinstall_10.1.sit binary from XonX, although the XFree86.org tarballs are identical. The XFree86.org tarballs are just harder to deal with since they require downloading separately and running a shell script. 2) Apply the 4.2.0->4.2.0.1 patch from XonX 3) Apply the 4.2.0.1->4.2.1.1 patch from XonX This is correct as of today. Very shortly this will change to just installing XFree86 4.3.0 which will be available from XonX and XFree86.Org as before. --Torrey --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] XFree86 4.3.0 close
The code freeze for XFree86 4.3.0 will be any day now. I believe the Mac OS X/Darwin part of the code base is pretty much in final form. Benjamin put together a package in fink unstable which builds something very close to the top of the tree. I would encourage as many people as possible to give it a try. The libraries and clients from this version will be used for Apple's final release of X11 although the X server will not be synced up until after 4.3.0 is out. Please let me know promptly if you find any bugs. There has been only one bug fix since Benjamin's package was put together: In 16-bit color pixmaps could sometimes appear shifted by 1 pixel from what was intended. --Torrey --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] GIMP's shared memory broken
At 8:00 AM -0800 1/13/03, Ben Hines wrote: On Monday, January 13, 2003, at 03:03 AM, Jakub Steiner wrote: Hello there, I noticed fink's GIMP package uses --no-shm --no-xshm because it's broken. This is a call for help if anyone's interested/has some idle cycles. I don't think your shm will ever work well on OS X. I assume you are using sys v shared memory - OS X by default has a very small sysv shared memory allocation, which you are likely to hit quickly. It looks like you are using SysV shm with shmat(). I think POSIX shm works better on OS X, and definitely mmap works fine. POSIX shm is more standard than sysv shm anyway, so you should probably switch. Of course the --no-xshm refers to using the MIT-SHM X extension. This is not something GNOME can do anything about. MIT-SHM only works with Sys V shared memory. I have thrown around the idea of writing an MIT-SHM2 which would abstract the shared memory API and allow us to write a POSIX shared memory implementation. Although the idea was well received, it requires time to write, time to become part of the next major XFree86 release, and time for application developers like the GNOME project to switch over to using the new X extension. A good idea that's not happening soon... --Torrey --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] X11 compatibilty problems
At 1:59 PM -0500 1/12/03, David R. Morrison wrote: Martin, My understanding is that the following upgrade path: XFree86-4.2 or Fink-4.2/ threaded-version / XFree86-4.3 or Fink-4.3 is expected to work just fine. Yes. This kind of problem is why I got bent out of shape awhile ago about Fink adding dynamic libraries that are only static in the standard distribution. It is essential that everyone can rely on compatibility between X11 libraries. I think as you say, Fink and XFree86 are on the same page now. However, as has become apparent this week, the libraries shipped by Apple are not binary compatible with other versions of the libraries. Yes indeed. There are other issues besides the wrong install name, but the Apple engineers are aware of them. I am fairly certain that Apple will address all these problems inn the final release. In the mean time I think the proper attitude is to treat Apple's X11 as the beta it is. You may well find mysterious breakages and you will likely have to rebuild everything you build with it again once the final version comes out. I'm not sure what we can do about this, other than to post a big warning on Fink's website. We can probably include a short list of Fink binaries which are known not to work with Apple's libraries. Apple is planning on syncing up their libraries with XFree86 4.3 for the final release. Making the public and Apple aware of the problems in the beta is probably all we can or need to do. The last thing Apple wants is to fork off the XFree86 mainline. --Torrey --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Who should Provide X11 ?
At 9:25 PM +0100 1/6/03, Martin Costabel wrote: Bruce Korb wrote: Jeff Whitaker wrote: Why force people to install xfree86-rootless if they don't really need to? Because is solves real, multi-hour problems. The cost is very marginal: systems that need x-base and not x servers and their price is only a few minutes of install time. The disk space is only worth mentioning that it is sub-marginal. Yes, exactly. I haven't been lurking on fink-devel long enough to have insight into what the earlier debates on this were, but I have always found it strange that fink still separates the server from rest of XFree86. Sure you can think of scenarios where someone might want the X libraries installed and not the X server, but these are largely artificial. As people have pointed out you are only saving 5-10% of the size of the distribution by separating out the server and there is a very real complexity cost for doing so. There are other parts of the XFree86 distribution one might want to separate out as well that save even more space. Why is the server special? I think the reason is largely historical. Back in the XFree86 4.1.0 days there was no rootless X server, only a full screen one. There was, however, a rootless X server that mostly worked under development in the top of the XFree86 CVS tree. Christoph Pfisterer wanted fink users to be able to use the rootless X server from the top of the tree without having to worry about upgrading the libraries and everything else as well. Thus he separated the packages, which worked at the time. These days it does not even make sense to use an X server and libraries from different XFree86 tags because the server depends on the libraries. Today people either live with the last stable version or the cutting edge, but they upgrade server and libraries together. Since there is no longer any desire to update the server and the rest of XFree86 separately, keeping the two in separate packages seems to complicate things for no reason. --Torrey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Accelerated OpenGL under OSX and X windows.
At 3:14 PM -0600 11/4/02, Stephen Hocking wrote: Has anyone in the XonX team sat down coded up the libGL stuff as a relatively thin wrapper around Apple's native implementation? (Probably not the ideal list for this question, but...) Yes. TOT XFree86 CVS. :-) --Torrey --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] xterm & xload permissions
At 6:45 PM +0200 10/18/02, Jorge Acereda Maci· wrote: Is this normal? [Silver:~] admin% ls -l /usr/X11R6/bin/xload -rws--x--x 1 root admin 22240 Oct 18 05:33 /usr/X11R6/bin/xload [Silver:~] admin% ls -l /usr/X11R6/bin/xterm -rws--x--x 1 root admin 275668 Oct 18 05:33 /usr/X11R6/bin/xterm [Silver:~] admin% Yes. A better question is whether it is necessary since it is undesirable. This has come up in XonX developer discussions, but we really haven't spent much time on it. It works as is so it has not been a high priority. If you have some thoughts on this it would be interesting to hear them. --Torrey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] lesstif and XFree86
The lesstif discussion reminded me that I should point out some important changes that are coming soon for XFree86. The XonX project will be releasing a bug fix update soonish to XFree86 from the 4.2 branch. In addition to fixing a few crashing bugs and adding Jaguar compatibility, it will also revert libXt to a flat-namespace image. When this becomes available, you will likely want to move the Fink distribution to using it. After having some time to look at this issue in more detail it is clear that libXt will never work properly with two-level namespace binding semantics. The Fink approach of using -force_flat_namespace will continue to work, but it will not be needed after the update. Keeping libXt as a two-level namespace image forced every application that used libXt to link _all_ their libraries as flat namespace images, even though only libXt needs it. In addition it became obvious that there were subtle problems in applications that used libXt without -force_flat_namespace, even if they did not fail as dramatically as lesstif. I think that only libXt consistently relies on the kind of binding semantics that make two-level namespace a problem, but please let me know if you think there are other X libraries that might need to be make flat. Hopefully when XFree86 4.3 release gets close we can move Fink's unstable XFree86 package to using the release candidate libraries so we don't have another surprise like the libXt-lesstif problem. --Torrey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [KDE-Darwin] Re: [Fink-devel] KDE-Fink library problem
At 4:17 PM -0400 5/31/02, David R. Morrison wrote: >Just to followup one more time: Torrey, we've had a bit more discussion >among fink developers on IRC, and it turns out that the problem which >Justin is having with xine is related to the lack of x-shm support on >Darwin. Somehow with the shared libs he can get around this (I wasn't >too clear about how). Do you know the status of x-shm support in Darwin? As far as I know x-shm support is still stuck at not good enough to be useable because of small number of shared memory segments Darwin supports. We may fix this issue in OpenDarwin. I also proposed, and the XFree86 Core Team embraced, an idea to write an update to the MIT-SHM extension that uses POSIX shared memory. In the mean time, x-shm basically doesn't work on Darwin. Now that I understand the problem I think the best compromise is do something like Justin suggested and put libXv and libXinerama shared libraries in a special package. (Actually I'm still not sure why you would need libXinerama, but once you've got the package you can go crazy if you want.) Those packages that need these shared libraries can depend on the "shared-lib" or "xfree86-extras" package. These shared libs should be installed somewhere in /sw so they do not pollute normal builds of X11 applications that don't need these non-standard shared libraries. The packages that need these shared libraries need only be modified with an extra -L to point to wherever you decide to store these libraries in /sw. This way everyone is happy. Those packages that need shared libraries will get them and everything else will remain binary compatible with mainline X11. Note that from what I have heard, KDE is not one of the packages that would need to depend on this shared library package. It only depends on them as an undesirable side-effect of revision 5 of the xfree86-base package. --Torrey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [KDE-Darwin] Re: [Fink-devel] KDE-Fink library problem
At 11:43 AM -0600 5/31/02, Justin Hallett wrote: >no there isn't. Plus why would you want to revert the change? It doesn't >hurt anything unless you try and mix to systems. hmmm...I think this >might end up being a problem with other pkgs for the bin dist as well. >shared libs and system pkgs are not gonna mix well in the bin dist. > >[EMAIL PROTECTED] writes: >>Fine. Remains the question: for what did you need xinerama/xv as >>shared libs, and why, and is there another way to get that package to > >work then? The main reason to revert the change is that most every X11 application binary distributed by Fink is in danger of being incompatible with any other X11 implementation other than Fink's. KDE was just the first such high profile example of this. Thus we will have fractured the X11 standard on Darwin/Mac OS X. This would hurt quit a bit. In one corner we would have Fink's binaries which only run with Fink's version of XFree86, and in the other corner we would have binaries from GNU-Darwin, XFree86, XTools, etc. that would run on any X11 implementation. When an application is linked with a shared version of libXv or libXinerama present, the linker will prefer this shared version over the static one. The resulting application will fail to run anywhere where the shared library does not exist. You might ask why we can't just get XFree86 to adopt your patch and start distributing shared versions of these libraries. I seriously doubt the XFree86 Core Team would accept such a change as: 1. Such changes should be made across all platforms. 2. There are good reasons why these libraries are not shared. 3. This has already come up before and Red Hat was bapped for doing exactly this. It can't be true that some packages can only be ported by using shared versions of libXv and libXinerama because no other platform provides shared versions. Darwin does have different binding semantics in some edge cases, but these can be worked around. For example, I saw one case in the mailing list archives where -lXv by itself produced as error, but -lXv should always be used with -lX11. If you have a specific package that works other the shared library problem, we can help get it working the right way. --Torrey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
